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

OPS去承擔(dān)起開發(fā)自己OPS工作的系統(tǒng)這個比較容易理解，最大的原因在于自己的痛其實(shí)只有自己最清楚，很多家公司估計(jì)都嘗試過讓一個專職的團(tuán)隊(duì)來開發(fā)OPS用的系統(tǒng)，結(jié)果就是專職的這個團(tuán)隊(duì)和OPS團(tuán)隊(duì)挺容易引發(fā)爭執(zhí)，然后系統(tǒng)也通常不能很好的解決問題，而一旦轉(zhuǎn)變?yōu)镺PS自己來做系統(tǒng)給自己用，那問題被解決的可能性會大幅提高，而且有不少公司確實(shí)也是OPS采用OnCall輪轉(zhuǎn)的機(jī)制，Oncall的時候?qū)Ｐ母蒓PS的活，不OnCall的同學(xué)則專心寫系統(tǒng)解決自己之前OnCall的時候手工干的活，不過這種方式下比較容易碰到的一個問題可能是寫出來的系統(tǒng)的質(zhì)量不夠理想，例如對于運(yùn)維系統(tǒng)來說，在成功率的要求上會遠(yuǎn)比在線系統(tǒng)高，但在性能、并發(fā)這兩點(diǎn)上會遠(yuǎn)比在線系統(tǒng)低。

?

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

?

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

?

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。