devops出来没几年，很多媒体又开始宣传aiops，实际上，据笔者了解，devops落地得好的公司并不多。为了实践devops，很多公司为此做了很多工作，比如：
1、把部门名字变了，比如以前叫运维中心，现在叫devops中心，以前叫运维部，现在和测试部合并成了devops部,让开发，测试和运维坐在一起办公。
2、引入了很多devops工具链或者流水线，最出名的比如jenkins pipeline，或者其它一些商业CI/CD工具
3、引入了配置管理工具，比如disconf，或者基于某开源软件比如consul自研配置中心
4、引入了全链路跟踪工具，可以监控到rpc级别的问题
OK，即便做了这么多，有时候还是感觉devops的效果不是那么理想，比如：
1、发布不够流畅，经常出问题
2、遇到线上业务问题，往往研发，架构，运维三方出马也难以快速定位。
自动化运维不等于devops，但是自动化运维做不好，devops一定做不好。而要做自动化，一定要做标准化，标准化包括方方面面的内容，比如配置标准化，以一个3节点mq集群的配置为例：
第一种配置方法：
jms1.url=tcp://10.0.50.100:61616
jms1.username=xxx
jms1.password=xxx
jms1.maxconnections=10
jms2.url=tcp://10.0.50.101:61616
jms2.username=xxx
jms2.password=xxx
jms2.maxconnections=10
jms3.url=tcp://10.0.50.102:61616
jms3.username=xxx
jms3.password=xxx
jms3.maxconnections=10
第二种配置方法：
jms.url=tcp://10.0.50.100:61616,tcp://10.0.50.101:61616,tcp://10.0.50.102:61616
每一种配置类型，都需要被标准化，当架构决定用某个mq的时候，模块如何配置连接mq就需要被标准化，而不是等模块上线了再去做规范，这也是很多公司实施devops效果不好的关键之一，没有一个强有力的组织在事前进行规范定义，或者说有规范，但推行力度远不够。
另外，如果研发和运维还是按照原来的分工模式，比如研发专注写代码和修bug，运维专注基础环境维护，比如网络，dba，服务器管理等，这样子devops多半也做不好，任何工具或者流程的执行者都是人，不能绕开人的作用，因此，笔者建议：
1、研发往后退一步，要熟悉自己开发的模块的运行环境，比如网络，dns，cdn，nginx，es，kafka等
2、运维往前进一步，要熟悉各业务场景以及对应的数据流，如此不仅能强化线上问题分析能力，还能更好地支持业务运营，毕竟，dev和ops的紧密互动才是devops的核心理念。
原文地址：http://blog.51cto.com/weikle/2069205