mar 其它 一起 鏈路跟蹤 在一起 中心 conf ces 方法

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的核心理念。

DevOps都玩不好還想玩AIOps?