技術界一直就是新名詞不斷的風格，DevOPS這個詞話說出來也挺長時間了，一直以來對這個不算太明白，以為就是指OPS應該不僅僅做OPS的工作，而是應該同時承擔起開發自己OPS工作的系統，注意指的是系統，而不是腳本，因為很多的OPS操作是一個流程式的多步驟組成，并且多集群，多系統的交互，這個時候用腳本去實現是會比較難的，而且還要處理諸多的異常等，系統是一個工程性的東西，不僅僅是功能的實現，還要考慮很多異常、穩定性等的問題，但最近的一些思考，讓自己對DevOPS有了更多的看法。

OPS去承擔起開發自己OPS工作的系統這個比較容易理解，最大的原因在于自己的痛其實只有自己最清楚，很多家公司估計都嘗試過讓一個專職的團隊來開發OPS用的系統，結果就是專職的這個團隊和OPS團隊挺容易引發爭執，然后系統也通常不能很好的解決問題，而一旦轉變為OPS自己來做系統給自己用，那問題被解決的可能性會大幅提高，而且有不少公司確實也是OPS采用OnCall輪轉的機制，Oncall的時候專心干OPS的活，不OnCall的同學則專心寫系統解決自己之前OnCall的時候手工干的活，不過這種方式下比較容易碰到的一個問題可能是寫出來的系統的質量不夠理想，例如對于運維系統來說，在成功率的要求上會遠比在線系統高，但在性能、并發這兩點上會遠比在線系統低。

?

除了上面這個點外，運維團隊通常還很容易碰到的一個問題是研發交付的系統可運維性不太好，這種時候通常只能是純操作方面的事運維先人肉頂著，但碰到一些故障的時候，如果系統可運維性比較差，會導致排查過程極度復雜，耗時長，而在有研發和運維這兩個獨立崗位的時候，這種現象很容易導致的結果就是運維在苦逼的處理一堆的這樣的事情，研發呢反正也不是很能感受到這樣的痛（因為一個研發可能就負責一兩個系統的開發，但一個運維通常可能負責幾十個甚至更多系統的運維工作），于是也不是很在乎，最終導致很容易出現的現象就是運維推著研發做很多可運維性的改造，無論是運維體系標準的建設，監控體系標準的建設等，但這個推動通常其實不會那么容易，最重要的原因我自己覺得主要是體感的問題。

?

所以我現在理解中的DevOPS，我覺得是消除OPS這個獨立崗位，讓研發和運維合并成同一崗位，研發系統的團隊輪值安排OnCall，這樣會讓研發系統的同學深刻感受到系統設計不靠譜的時候給運維階段帶來的痛苦，從而把本來就應該在設計階段考慮的可運維性考慮進去，同時也避免了兩個團隊帶來的協調成本等，并且對于研發而言，由于“偷懶”的特性，很容易就會去打造系統來解決手工干的活，站在這樣的角度，我覺得就很容易理解為什么叫DevOPS，而不是OPSDev。

?

大家也可以探討下你所感受到的運維是怎么樣，你覺得變成什么樣是比較不錯的。

總結

以上是生活随笔為你收集整理的探讨下DevOPS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。