标签:因此 代码 dev url iops 内容 nginx 节点 自动化
devops出来没几年,很多媒体又开始宣传aiops,实际上,据笔者了解,devops落地得好的公司并不多。为了实践devops,很多公司为此做了很多工作,比如: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的核心理念。
标签:因此 代码 dev url iops 内容 nginx 节点 自动化
原文地址:http://blog.51cto.com/weikle/2069205