DevOps中開發的作用和主動性

前段時間接到右軍的命題作文，要聊聊DevOps中開發的作用和主動性這個話題。

命題作文的好處就是，逼迫自己從不同的角度去思考同一個事物，這段時間以來也讓我不斷回顧和琢磨，對這個問題又有了很多新的認識。

我們講現在的DevOps和運維，之所以越來越受到重視，跟分散式架構在業界的廣泛實施這個背景是緊密相關的。

也就是，DevOps是分散式架構場景下的DevOps，運維是分散式架構場景下的運維，會更加的準確，後面我們介紹的案例基本都會以此為背景。

回到開發的作用和主動性的命題上，其實我的理解，應該是在這種背景下：

系統複雜度遠遠超出人力掌控範圍，超出人腦認知範圍，開發和運維必然要緊密協作，共同面對新挑戰和新場景的問題。

也就是，除了合作，別無選擇，如果有任何一方不主動，就會造成效率的極大下降，以及穩定性的極大損害。

面對這樣的場景，多少有些“被動”意味，所以所謂的“主動性”更多的是被現實場景，被業務場景倒逼出來的。

這裡，我根據不同公司的做法，總結了三種典型的模式來參考，以便於後面更深入的分析：

第一種，文化使然，開發主導模式。

最典型的就是Netflix的“Freedom and Responsibility”，Netflix號稱是沒有運維崗位的，連SRE角色也只有極少數，與此類似的還有Amzon，他們的運維工作基本都是由開發自助完成。

無論極致的Netflix，還是大名鼎鼎的Google，還是老牌的Amzon，正是在這種自由和責任共存的文化驅動下，無論開發還是架構師，天然地對自己的系統、平臺甚至是應用端到端負責，從而逐步構建起了能夠支撐海量業務的基礎設施和服務平臺。

這樣到了後期，很多繁雜和重複的工作，開發都可以基於平臺自助完成，而不是依賴運維的人來完成。

所以，我們仔細觀察，你會發現，國外的大廠其實極少提DevOps這個概念，因為他們天然就是這麼幹的，是理所當然的一種研發模式。

這種模式對於組織來講是最為高效的，但是文化導向之所以能夠發揮這麼大的作用，也有一個極為重要的前提就是技術團隊和人才的能力問題，只有當團隊能力足夠強的時候，才能夠支撐起如此完善的體系建設，再加上國外強烈的工程師文化，讓他們能夠耐住性子，沉下心來，穩紮穩打。

反觀國內，一個是技術人才的能力還達不到這個程度，再就是，國內的公司和產品往往追求業務增速和發展，往往會犧牲一些非功能性的能力。

單純從技術角度來看，國內公司在這方面很明顯是落後很多的。

第二種，自上而下的決策，開發和運維“被動”執行模式。

最典型的就是阿里的DevOps轉型，阿里應該是在2015年左右，甚至更早，就啟動了DevOps轉型。

體現在組織架構上，最明顯的就是取消了PE應用運維這個崗位。

這個轉型有兩個必要因素：

第一個，多年技術積累，基礎設施和平臺非常完善。

原來基礎能力不夠的時候，很多運維工作也是要依賴PE這樣的角色人肉去完成，但隨著平臺不斷完善，有很多事情，開發完全可以基於平臺自助完成，而不再需要多一個PE這樣的環節去做。

所以，從技術角度，阿里已經完全具備了DevOps的基礎條件，從組織效率角度，提升研發整體的交付效率也勢在必行。

第二個，也是最關鍵的一點，自上而下的決策執行。

雖然基礎條件具備了，這時無論是開發還是運維，都不具備能力去做組織層面的調整和融合。

但是，從研發高層的角度，當意識到DevOps轉型時機成熟，且經過論證和實踐是可以帶來效率極大提升的時候（國外大廠的模式已經證明），組織上的職責和崗位調整，就勢在必行了。

我在幾個大會上聽到的分享，以及線下與經歷DevOps轉型的工程師交流，可以看到，上面的決策一下達，研發團隊就制定了非常詳細的交接和培訓計劃，原PE團隊職責逐步交接到開發團隊，經過多輪培訓和交接後，歷時兩年左右，完成了整個DevOps的轉型。

講到這裡，我們可以看到，對於兩個團隊來說，都有一些被動的意味。但是，這個結果的達成，是離不開前期這麼多年，技術能力不斷積累完善這個前提條件的。

所以，準確一點講，應該是結果達成的階段相對被動，但是前期的準備和積累階段，都是主動的。

稍微總結一下，以上兩種模式的案例，我們可以看到都是大廠的案例，他們有一個共同的規律，就是基礎設施和基礎平臺完善且強大到一定程度後，DevOps轉型和落地更多的是水到渠成的結果。

但是，上面的案例已經是結果，但是對於一般企業，DevOps的演進過程應該什麼樣的，這個過程中，開發應該怎麼做？運維應該怎麼做？

下面我就結合蘑菇街的案例講一些更細節的部分。

第三種，技術戰略專案切入，開發和運維合作共建

所謂技術戰略專案，可以理解為當業務發展到一定程度或某個階段時，技術層面為了更好的適應業務趨勢和場景，而做出的一些整體技術架構調整，這裡可能包括軟體架構、研發組織架構、基礎設施建設等等。

我回顧了下，蘑菇街整個DevOps體系的逐步形成，基本就是在這些技術戰略專案的執行中，不斷形成和完善的。

第一個，Java服務化體系的建設

2015年初，蘑菇街研發部啟動業務架構的服務化專案，對原來的PHP單體架構改造。

當時，這個專案是為了能夠快速響應業務變化而做出的改變，並不是單純為了DevOps的目的。

不過，後來專案進行過程中，我們遇到了分散式架構體系下的一系列效率問題，比如應用釋出、資源申請，快速擴容、問題定位以及故障響應等，統統跟不上節奏了。

到了這個階段，我們發現效率上不去，工具跟不上，最關鍵的問題就在於各種標準缺失。

所以，我們花了大量時間和精力做了標準制定，從機型選擇、OS版本、系統引數、到應用命名、部署目錄、依賴管理，配置管理再到後面分散式元件和框架的標準約束等等。

再往後，我們開始基於標準又配套提供了很多解決棘手問題的工具平臺，一開始這些平臺很簡陋，但是能解決問題，再往後慢慢完善和重構，能力就越來越強大了，比如持續交付系統。

開發在這個階段，最主要的作用就是與開發共同制定標準，並在後續的架構設計和研發過程中，嚴格遵從標準，否則，接入不了工具平臺，效率和穩定也就談不上了。

一開始強制約束，不按標準來，不給資源、不給釋出，開發感覺非常不靈活，被限制了創造力，但是隨著後來效率的提升，大家都慢慢認可了這種模式，而且會主動執行。

這個過程下來，我們所理解的DevOps，其實是被現實場景倒逼出來的，開發和運維必須更緊密的合作，一步步嘗試和探索，才能讓團隊運轉下去，其它別無選擇。

第二個，電商大促的常態化

電商企業的大促越來越頻繁，已經呈現出日常化的形態。

蘑菇街也不例外，為了保證業務峰值狀態下的穩定，技術手段上，對線上壓測、故障模擬、預案演練以及容量評估等，提出了更高的要求，從這個維度，又在驅動著整個穩定系體系的不斷完善。

這裡要做的非常關鍵的一點，穩定性的標準化，並且在開發階段嚴格執行。舉個例子，我們要做限流，在開發的程式碼中，哪些API、函式需要限流？限流的閾值多少？限流對外部的影響是什麼？

這就需要對業務和程式碼都非常熟悉才可以，不然限流的點的方式不對，穩定性就無從談起。

對於容量評估、全鏈路壓測等等也是一樣，只懂技術，不瞭解業務場景和模型，就沒法有效實施。

所以，在這種場景下，開發是要發揮核心作用的，運維可以透過指標和模擬等手段去推到，但是始終是黑盒，作用終究有限。

第一和第二個專案中涉及的平臺建設細節，我就不再贅述了，大家如果感興趣可以看我公眾號的文章或者極客時間專欄文章。

第三個專案，業務上雲

到了2018年，我們決定業務整體上雲，依託於騰訊雲完善的基礎設施體系，將更多的精力專注在業務研發領域。

這裡帶來的一個變化就是，很多服務都是現成的，如雲主機、快取、訊息、資料庫等等，申請即用，大大提升了我們資源和服務交付的效率，但是面臨的問題，就是大量的服務例項成本如何管理的問題。

最簡單的方式，就是將能力暴露出來，由開發自助使用，而不是再透過運維稽核或控制，最終透過成本分攤來控制合理使用。

之前，自建IDC模式，伺服器一旦採購，成本就已經形成，用與不用，成本並不會有差別。

但是上雲之後，按需付費，開發就要開始形成成本意識，必須要對自己所做事情，對自己的設計和寫的程式碼的的ROI，有明確的分析。

場景不同，要求也就完全不一樣了。

限於篇幅原因，這部分內容，包括我們在雲上的雙活站點建設，我會再開新文章來介紹我們的經驗。

三個部分做個總結，我們可以看到運維更像是技術運營，在驅動一些事情，但是真正的落地和執行，仍然在開發。同時，我們可以感受到，雙方合作是否順暢和緊密，心態和意願，也是關鍵的要素。

最後，總結

上述的過程，如果倒過來看，其實就是一個公司隨著業務發展和增長，技術體系演進的一個縮影。

也就是，業務場景驅動，組織手段推進，文化導向覆蓋。

蘑菇街從無到有的建設，隨著體系完善，終究會走向阿里DevOps轉型後的模式，而阿里隨著轉型的完成，更深入的發展，必然會朝著Netflix的文化導向的趨勢發展，讓團隊中每一個技術人員都能夠具備端到端意識。

所以，DevOps的實施和落地，不是某個點的改變，它必然一個體系的要求，比如業務上，體量和場景達到一定規模，技術層面必須達到一定高度，組織層面必須具備足夠的力度和決心，同時文化宣導上覆蓋要足夠廣，足夠徹底。

而開發在這個過程中的落地執行，無疑又有著決定性的作用。

作者介紹：

趙成（謙益），美麗聯合集團運維經理，負責美麗聯合集團（原蘑菇街、美麗說）運維團隊的管理及運維體系建設工作。擁有近10年研發和運維經驗，見證和參與了多個電信級和網際網路產品從無到有的創造、從微量到海量的成長過程，也經過多輪煉獄般的磨練和蛻變積累了非常豐富的電信級和網際網路業務研發和運維經驗。

《技術瑣話》坐館老司機: