蘑菇街SRE體系建設實踐

趙成，蘑菇街技術總監，資深DevOps和運維專家，專欄作家，著有《進化：運維技術變革與實踐探索》一書，騰訊雲TVP，現任蘑菇街集團技術總監。

趙成：專家和資深，更多是外部對我的稱呼。我覺得最重要的是一個人在職場上是否可以腳踏實地的解決實際問題，幫助公司成長。回到問題上，我認為傳統運維和DevOps之間並沒有什麼嚴格的界限。這個轉變更多的還是跟隨軟體架構的演進，一步步發展過來的，或者準確的說，軟體架構發展的同時，也給運維帶來了更多的發展空間。

我早期在華為負責的電信軟體產品更多的是單體或分層架構，少部分是服務化架構。這些軟體迭代週期比較長，並且遵循嚴格的IPD研發流程，因此，上線後的軟體質量一般都相對可靠。所以在這種情況下，一線運維的同事關注的焦點更多的是在硬體和系統層面，只需要將系統層面的事情運維好即可。

但是隨著網際網路行業的高速發展，服務化、分散式、微服務這樣的軟體架構被廣泛採用，運維所面臨的問題就變得完全不一樣了，軟體模組，也就是我們常說的應用數量突然變多，變化頻繁（每天釋出），所以作為運維，要關注的焦點自然會偏移到應用層面。這種新的場景必須要有新的解決方案去應對，於是DevOps、SRE等優秀的理念和實踐也就誕生了。而傳統運維和DevOps之間的轉變就順其自然地發生了。

所以，總結下來就是我的第一句話所表達的意思：不管是做開發，還是做運維，需要時刻擁抱變化，腳踏實地解決每一個問題。

趙成：傳統運維更加關注物理裝置層面的維護，但是DevOps會更加強調應用層面的運維。或者準確說，是需要具備從應用的視角去做運維的思路。

由於軟體架構的演進以及雲端計算行業的飛速發展，底層的基礎設施被做的越來越完善。你會發現越底層的東西變得越來越標準化，比如阿里雲的ECS和AWS的EC2，從使用的角度來說，其實差別並不大。這就給傳統運維帶來了很大的挑戰，除了上面第一個問題中提到的場景挑戰，還有兩個主要的挑戰：一個是發展空間受限；另一個是崗位需求量在趨於萎縮。所以，在思路上做轉變在職責上轉型就很必要了，或者更準確的說是面對新的場景，不得不轉，這是個倒逼的過程。

從蘑菇街的經驗來看，我們當時轉型的時候，一方面從大廠招聘有經驗的應用運維比如從阿里等，來作為經驗的輸入；另一方面不斷向外部學習，看別人是怎麼做的。最後就是我們自己去摸索實踐。當時我們內部制定了一個原則：一定要站在開發和業務的角度解決實際問題。從實際問題出發的好處之一就是不會被各種理念、概念和技術搞的雲裡霧裡，也不會不知從何入手。所有的技術應用都是為了解決問題。依靠這個原則去做事情也會更腳踏實地一些。

在轉變的過程中，前期會痛苦些，因為根本找不著北。但是一旦摸到了方向，並堅持做下去就會越來越有感覺，越來越知道自己應該做什麼。方向對了，路再遠也不怕。

趙成：簡單來講，要從意識入手、形成標準、再到文化建設。這是一個體系性的工程。

之所以從意識入手，其原因是在一開始甚至是穩定性建設過程中，我們的工具和體系有時候還不夠完善。此時我們很難直接依賴技術手段來保證系統穩定，很多變更操作也沒法一下子全部透過自動化的工具完成。

在這個階段，為了避免一些重大、低階、人為的失誤，就需要在意識上進行加強。最簡單有效的方式就是制定高壓線。制定高壓線就是規劃好底線，觸碰底線就要受到處罰。比如白天不允許操作網路裝置，不允許做大表變更、不允許做拔插網線等操作。雖然看上去好像不是那麼高大上，但是往往最有效，可以避免很多低階失誤造成的嚴重故障。

其次是高壓線一旦制定出來，就要把它變成一種習慣。當每個人對線上的敬畏心理形成後，高壓線的震懾力就顯現出來了。別說高壓線不敢碰，就是一般的電線和電源在處理之前，都需要掂量下這種操作是不是有危險。所以，在很多流程規範約束不到的地方，這種方式就可以起到很好的補充作用。

2015年我到蘑菇街的時候，有一段時間故障頻發。雖然我們制定了各種很細節的流程規範，但這些規範的效果並不好。後來就制定了高壓線，簡單易記，並且約定一旦違反就要受到處罰。透過此種方法，我們基本可以避免較大的故障。其實這其中的關鍵是人一旦形成意識並主動思考，就會主動規避風險。而如果是被動執行，那麼有時候往往就不會考慮這麼全面。

這個話題比較大，關於標準和文化部分，我先不展開講了，這是我12月份演講的主要內容，大家可以關注我的演講。

趙成：首先SRE(Site Reliability Engineering)是指站點可靠性工程師，最初由Google提出並實施推廣。SRE的主要職責是保證站點的可用性，因為他需要對站點系統、元件節點、服務呼叫等較為熟悉，並需要關注生產的服務狀況。在Google SRE中還提出了SLI，SLO，SLA的機制。我認為以下幾點是這套理念的核心關注點：

1.SLO穩定性標準。根據系統執行的實際情況來設定合理的指標範圍。SRE設定了SLO之後，無論開發、運維還是管理者都必須遵照這套標準處理問題。

2.50%原則。這一點主要強調SRE並不能被瑣事纏身。無論他多忙，都要有50%的時間用來開發工具，從而解決重複的瑣事。從另外一個角度，這也說明SRE更加強調技術解決問題，而不是靠管理以及流程之類來保證系統穩定性。

3.事後總結。Google非常重視從故障案例中總結提取經驗，從而找到改進措施。我之前也提到過：故障永遠是表象，背後的技術和管理問題才是本質。當這些問題積累到一定程度就會爆發出來。因此，故障最能夠體現一個團隊的技術和管理能力，也能暴露現存的問題。所以我們可以從中瞭解到：案例學習是一種非常簡單且有效的提升手段。

4.No Blame文化。這一點主要是指就事論事，永遠不要指責、抱怨團隊和隊友。只有在這樣的環境下，大家才能敞開心扉，並且真正站在如何改進的角度去考慮問題、去解決問題，而不是擔心自己被指責、被處罰。

這四個點，也將是我在這次大會演講中分享的觀點，歡迎大家關注。

趙成：我們依賴的是公有云廠商的基礎設施和基礎服務發展。這裡主要有兩個原因：

第一個是基礎設施和服務越來越趨於標準化。無論是虛擬機器、網路、資料庫，還是軟體層面的分散式快取、物件儲存、訊息等，這些都已經非常標準通用了。這些產品在大的雲廠商公有云服務上都有很長時間的執行和使用，所以既然已經有現成的服務了，為什麼自己還要再重複造輪子呢?

第二個點是基礎設施和分散式服務的搭建和運維較為複雜。技術難度和複雜度曲線在大規模應用的場景下會變的異常陡峻。因此需要有持續的、規模性的專家人力投入。對於一般企業來說，這項投入消耗太大，靠自己力量去投入實施不太現實。而且即使自己做，也不見得比業界廠商做的好。所以從這個角度出發，我們就更沒有必要自己去做了。

我們會將更多的精力專注在業務技術發展上，讓技術更多地為業務創造價值。

趙成：簡單講只有四個字：膽大心細。為什麼會這麼講呢？

我認為問題和坑總會有的。因為雖然雲服務肯定是趨於標準和通用的，但是我們每個公司的業務都是非常個性化的。所以，本質上我們遇到的問題都是通用和個性之間的差異造成的。這種情況靠任何一方單方的力量都不會有太大效果，必然需要雙方共同配合，一起改進和適配。

所以重要的經驗就是跟雲廠商做好充分合作，並給予雲廠商充分的信任。我覺得現在業界有一個非常不好態度，那就是總說雲廠商不靠譜、不穩定。其實達到靠譜穩定這個目標是需要有個過程的，是需要多一些耐心和容忍度的。

談到具體到實施層面，首要問題是解決資料遷移的問題，包括關聯式資料庫、大資料以及其它各類NoSQL儲存。因為資料是有狀態的，所以這裡的難點是如何做好資料同步，以及確保最終資料一致性的問題，當時我們也為此開發了很多自動化的校驗工作來做保證。

其次就是解決中介軟體這一層的部署，這裡主要是指各類服務發現和選主的策略設定以及隔離。

最後是應用層的部署。如果這方面的架構設計的好，系統應該都是無狀態的。所以從複雜度上相對簡單，只是需要投入更多的部署和測試。

透過這整個過程的介紹，你會發現，工具的完善程度、架構的合理性、應用開發的規範等都會直接影響到遷移的效率和穩定，所以應該把更多的工作放到做到平時來做。

趙成：我會分享一下我們在SRE方面的一些實踐。雖然每家公司都在做一些同樣的事情，但是SRE給我們提供了一個很好的思路和指導思想，讓我們做的事情能更加充分地發揮價值。前面已經劇透了很多，這裡就不再詳細描述了，大家可以關注我的演講。