模拟几个工作场景
1
开发：新部署的程序在线上环境跑不起来，但是在测试环境运行正常，运维帮忙看看是不是环境安装有问题
运维：所有软件都是原模原样从测试机拷贝过来的，怎么可能有问题。你是不是配置写错了，所有软件的地址、端口、用户名、密码都检查下看看
开发：怎么可能范这种低级错误，你确定不是防火墙问题
运维：你要怎么样自己过来弄
开发咚咚咚穿过几间办公司到运维跟前
开发：把堆栈跟踪打来，我要看报了什么错
运维放下手头工作噼噼啪啪打了一串命令
开发：咦，奇怪，怎么看不出来啊
运维：瞧你写的破程序，连错误日志都记录
开发：你让开，我要线上直接改代码调试
运维：……
半天后
开发：好像问题定位到了，错误在这个函数里
开发：好像缓存没起作用
运维：怎么可能，你刚才也看到了，缓存软件是可用的
开发：真的见鬼了
半天后
开发：找到原因的，缓存软件的编程组件你起作用，你没编译吧
运维：不可能哦，你稍等，我查查哈
半天后
运维：我重新编译了一下，应该没问题了，你再试试运行下程序
开发：我试下
开发：欧克，没问题了，能正常运行
开发：辛苦辛苦
运维：惭愧，下次一定注意
2
产品：xxx内部系统早上无法登录 @开发
开发：稍等，我查下
开发：@运维。检查环境，是不是出问题了
运维：可能是昨天晚上断电的缘故，但是早上我把nginx、apache、MySQL都启动了呀，应该没问题了
开发：memcached呢
运维：我看看哈
……
……
运维：嘿嘿，我启动下，你再看看
开发：还是不行啊
运维：我检查下防火墙啊
运维：环境应该没问题，是不是你代码有问题
开发：昨天晚上还好好的，断个电就不行了，肯定是你环境的问题
运维：……那我没办法了，你先找找原因吧，我有个比这更紧急的是要处理
开发：干（心里）
很久以后
开发：你mongodb是不是没启动
运维：草，程序里还有这东西呀，我不知道哇
运维：启动了，你再看看吧
开发：……
开发：系统可以登录了 @产品
产品：欧克
……
吃午饭
3
开发：最近有个项目要上线，帮忙部署下环境
运维：要装什么告诉我
开发：PHP、apache、MySQL、radius、mongodb、nginx，还有PHP各个相关的组件
运维：你等等，我现在忙，下周帮你弄
开发：装个环境还要下周啊，我等着上线呢
运维：好，忙好忙你弄
开发：尽快哦
运维：好
一天后
开发：好了吗
运维：等等哈
一天后
开发：好了吗
运维：再等等哈，马上弄
一天后
开发：好了吗
运维：在弄呢
开发：什么时候弄好
运维：我怎么知道，这么多东西呢
开发：……
开发：你就别抱怨了，你装好环境我调试更麻烦
工作中像环境配置、错误定位与修复这些看似细枝末节的东西确是最恼人最花时间的，而且最没有成就感。
在上面模拟的对话中，好像运维一直处于弱势，被开发步步紧逼，但是到最后还是逃脱不了背锅侠的命运。
问题究竟出在哪里？看似运维工作不力，然而背后真正的原因，却是开发没从根源上杜绝问题的发生，换言之，是开发的程序设计的太烂了。
我们设计的程序时随着进度的推进，往往会有各式各样的需求出现，比如对于某些结构的数据存储，关系数据库满足不了灵活存储的需求；再比如说某些需要常驻内存的临时数据的存储。有时候这些需求的迫切程度甚至在项目开发前的规划阶段就显出了一些端倪。
显然，能用来满足这些需求的组件自然而然会被程序员引入到了项目之中。此外，新奇的技术对于程序员有天生的吸引力，能把一样高大上的技术在项目中用上一用，会产生无与伦比的满足感。
但是，在决定将某样技术引入到项目中之前，请先暂时顶住诱惑，仔细的思考一下以下问题
引入这种技术能带来什么好处
引入这种技术会带来什么副作用
好处是否能抵消的了副作用
有没有比这种技术更好的替代方案
拿memcached来说，一个非常常用的编程组件，它是一个内存数据库，通常用来存储一些需要频繁访问的，对实时性要求不高的数据，作用就是减少IO开销，提高程序性能。
然而实际上在很多项目中，只要不适合在关系数据库中存储的数据都会被放到memcacahed中，最常见的就是对于每个http请求来说都不会有变化但又需要频繁访问的数据。比如说，用户登录后，每个用户的信息都会被放入memcached中，以达到拿数据时不用查关系数据库，而是直接走内存的效果；再比如说，某一组菜单数据在每个页面中都会被展示，于是这也会被放入memcached之中，以提高访问性能。
但是，由此带来的性能提升真的是有意义的吗？在着手提升程序性能前，请先确认是否真的会存在性能问题，多读几次数据库真的不是什么大不了的事情，无意义的性能优化只会拖整个项目质量的后腿，增加维护成本和项目复杂度就不说了，反正这个坑还是要由开发人员自己来填的。
但是，增加程序的组件依赖，连运维的同事都坑了这就有点说不过去了。要知道大多数程序在性能优化上是根本没有到达使用缓存的级别，就算偶尔发现有慢的，那也是程序结构或者代码有问题，这样的项目拿缓存来解决问题也是治标不治本的。换句话说，这代表着运维替开发所做的工作完全是没有意义的，纯粹的浪费时间而已。
从运维的角度来说，如果每次部署环境只需要装程序的基础运行环境和数据库，那他们不但工作量减少了，部署和调试的进度也会加快，省心、简单、高效。
从上面的分析可以发现，使用memcached带来的副作用远远大于使用它所带来的好处，而且，这种所谓的好处是否真的有效还有待商榷。
做前端的同学应该深有体会，自己的特效明明在本地环境下是正常的，上传到线上后运行结果却不一定是正常的，排查后的原因是因为调用后端的ajax接口返回的数据有问题。这其实和后端程序员发现自己程序在不同环境下运行结果不一致是一个范畴内的问题，因为程序依赖的组件在不同环境下有时候也会不一样。简单粗暴的解决方案就是尽量少让自己的程序依赖别的组件或环境，以达到从根源上解决问题的目的。
再激进一点，如果运维每次部署程序，连运行环境都不用装，把程序拷贝到服务器上就直接运行，这是最省时省力的做法。对于开发来说，也不必再解决因为依赖的环境而产生的莫名其妙的问题。从这个角度来说c/c 、golang这类不依赖运行环境的直接生成本机码的语言最能达到这种纯粹的效果。而像JAVA、.NET、Python之类的语言，若要让程序跑出来，动不动就要装一堆环境，很大程度上增加了出现问题的几率。
