作者 |：Ian Miell

翻譯：大愚若智

作者 Ian Miell 通過本文探討了自己在全球最大線上遊戲網站的站點可靠性運維工作中積累的經驗。本文最初發佈於 Ian Miell 的部落格，經原作者授權由 InfoQ 中文站翻譯並分享。

概述

多年來，我負責管理著很多全球最大線上遊戲網站的站點可靠性運維工作，通過一家不怎麼知名的公司構建並執行著很多公司的後端線上軟體，這些公司的業務在峰值期間可以輕鬆產生每小時數千萬英鎊的收入。幾年前我從這家公司離職了，現在可以談談我在這段工作中積累的經驗。

從很多方面來看，我們的工作類似於一種 SRE 職能（就把我們也稱作 SRE 吧，不過當時並沒有這樣的稱呼）。我們需要隨時待命，需要對各種事件做出響應，需要對重構提供建議，需要為開發者和客戶團隊提供詳細的反饋，需要管理升級上報的事件和緊急情況，需要執行監視系統，等等等等。

我所在團隊有大約 5 名工程師（都曾任開發者和技術領導者角色），但在我離開時，已經增長為一個 50 人左右的跨地域團隊，大家在不同領域有著豐富的經驗。

本文將重點介紹我們的流程和文件，因為我覺得人們對這些內容的效用談的還不夠深入。

如果你還想進一步瞭解這個概念，建議閱讀 Google 的 SRE 手冊。

流程

流程對 SRE 運維的順利進行和升級上報至關重要，這是我們所有成果的核心。在我加入那個團隊時，當時大家的習慣很糟糕：雖然有一個工單系統，但對於解決方法的“一句話記錄”情況極為常見（“網站宕機，修復，結單”）。

SRE 運維基本上類似於一種處理資訊，並酌情執行操作的工廠。工廠的正常運轉需要通過一定的流程實現貨物的運轉，同理，知識密集型的 SRE 運維也需要妥善處理知識的流轉。

在流程方面，我聽到最多的一個異議是這種做法會“抑制創新”。實際上，有效的流程可以幫助我們通過更清晰的思路實現創新（但未能妥善實現的糟糕流程會搞砸一切！）。

關於這個主題有一本很不錯的書：清單革命，我們工作中的很多改進都受到這本書的啟發，團隊成員都曾認真拜讀。本書引用了航空業實現這一流程的方法作為範例，航空業曾通過智慧的自動化例行操作在巨大的壓力下實現了非凡創新。書中討論過的一個事件甚至被拍成了電影，飛行員稱這主要歸功於 檢查清單機制和例行操作 幫助自己通過快速思考實現了創新，並在面臨巨大壓力的情況下重新獲得了控制能力。實際上，我們自己也使用了一種類似的流程：緊急情況下，由有經驗的工程師負責深入研究查詢解決方案，與此同時，資歷淺的工程師則按照檢查清單進行逐項排查。

關於流程，還有另外一種看法認為，流程會抑制工作和協作的效用。如果將流程視作一種因其本身的存在，而非其他實際效果就認為合理的實體，這種看法當然是沒錯的。唯一能夠防範這種錯誤認識的恰恰是企業文化。下文還將詳細探討。

過程 – 工具的選擇

先需要準備一個合適的工單系統。與監視解決方案類似，很多人往往糾結於到底哪個工單系統才是最好的。這種想法本身就是錯誤的。在選擇工單系統時，最終的選擇將更加側重於熟悉與否。如果所選工單系統會產生或促進不好的流程，那麼這樣的系統無疑是最糟糕的。但糟糕的流程到底什麼樣，這取決於業務本身。

更重要的是選擇一個功能穩定，並且能比其他選項更好地為流程提供支援的工單系統。

這方面有個例子。在我任職期間，我們從 RT 更換為 JIRA。相比 RT，JIRA 提供了更多優勢，通常我都會建議選擇 JIRA 作為協作工具。然而我們更換後遇到的最大問題在於，JIRA 缺少我們在 RT 中構建的某些功能，而這些功能是我們必須的。RT 可以讓我們實時更新工單，這意味著我們可以在聊天和分配工單的過程中直接針對具體事件進行協作。相關記錄對事後審查工作非常重要。RT 還使得我們可以將某些內容對客戶隱藏起來，這樣的功能也是我們很難捨棄的。雖然克服了這些問題，但這些功能依然非常重要，因為它們已經融入到我們的流程和文化中。

在選擇或更換工單系統時，必須考慮對運維來說什麼才是真正重要的，而不要考慮那種在功能清單上看起來很漂亮的具體功能。對你而言，到底什麼最重要，這取決於各種因素，從看起來是否漂亮（說真的，如果你的品牌更有設計感，客戶也會更重視你）到報表功能是否足夠強大，各種原因不一而同。

文件

除了流程，文件也是很重要的東西，這兩者是密切相關的。

關於文件也足夠寫本書了，因為許多人關注了錯誤的方向。有一個重點需要明確：和其他內容一樣，文件本身也是一種資產。與任何業務資產類似，文件：

• 若能加以擅用，將提供多倍的投資回報
• 需要不斷的投入以進行維護（和設施或工廠一樣）
• 過時的文件如果繼續使用將產生更高成本（就像過時的庫存清單）
• 如果質量或易用性不佳，將成為一種負擔而非資產

這些特點不存在任何爭議，很少有人會覺得足夠好的文件不能提供巨大的幫助。重點在於：文件工作該如何進行？

文件 – 我們原本處於怎樣的情況中

我們原本處於這樣的一種情況：我們所獲得的文件沒什麼用（例如開發人員提供的文件說：“網路分割槽並未覆蓋這裡，因為這基本不可能實現”。你猜後來怎樣！而就算這樣的文件他們也寫得不情不願……），或者我們只能依賴以前記錄下來的調查結果（這次我們終於詳細記錄了一切資訊），藉此確定下次遇到類似的問題之後該如何解決。

這種情況讓所有人感覺沮喪，在決定自行撰寫相關文件前，我們還花了大量時間抱怨為啥沒有田螺姑娘來幫助我們。

文件 – 我們做了什麼

我們做了這些事。

• 我花了兩年時間對事件劃分優先順序（例如所觸發的事件，或本應觸發的事件，或下班時間的工作電話）並進行了仔細研究。各種事件的總數超過 1700 條。
• 隨後按照問題型別進行分類。
• 接下來仔細檢視每類問題，並總結了解決不同問題，或對問題進行升級上報之前所需執行的步驟。

上述活動花了我七個月的全職工作時間。我是資深員工，由我坐在那裡寫這些東西，耗費了公司不小的成本。由於得到了老闆的支援，他從未質疑過這樣做是否值得。他很信任我（依然是文化的作用！）。另外我得說，完成這一切四個月後，我的努力才獲得了回報。現在想起來，那四個月時間真是不堪回首，我原本需要用於運維的精力都被花在別人認為無意義的事情上，無謂地浪費了僱主發給我的工資，還遭遇了尷尬的失敗。

為什麼不交給初級員工來做？有幾個原因。這件事太重要了，以前從未做過，因此我需要自行確認具體做法是妥善無誤的。我完全清楚自己需要什麼，因此親自做這事至少可以確保能得到對我來說最為有用的結果。我本人也是一個有經驗的作者（藝術學院畢業，曾擔任記者），因此我覺得由自己來寫是一種更妥善的做法。

我們按照 ITIL 將其稱之為“事件模組”，但其實也可以叫做“執行手冊”、“小抄”之類的。名字不重要，重要的是：

• 它們非常易於查詢／搜尋
• 可以很容易判斷它們與自己遇到的情況是否匹配
• 其中不包含重複的內容
• 所有內容都是可信的

我們將這些文件以純文字形式儲存在工單系統一個單獨的 JIRA 專案內。

文件團隊瞭解到我們的所作所為，希望通過施壓讓我們轉為使用一個內部維基。他們的決定很快被我們拒絕，原因也很合理：文件與工單系統的共存意味著文件的搜尋和更新不會遇到相互矛盾不匹配的情況。純文字格式的內容可以用非常快速簡單的方式更新，並且可以保持一切內容井然有序。他們所要求的流程會讓我們當時希望打造的工具夭折，我們自然是拒絕的。

文件和整理工作的關鍵性

最開始我們為這些事件模組設計了一種架構，那是一種很美觀的架構，涵蓋了可能出現的所有場景和情況。

但最後發現這完全是浪費時間。最終我們使用的是一種非常愚蠢的結構，其中包含：

• 對問題的描述
• 所需執行的 1-n 步操作
• 進一步／更深入的討論，以及相關條款

就是這樣。希望徹底改進結構的企圖完全失敗了，也許因為新的結構會讓新人感到困惑，會給管理人員造成太多負擔，或覆蓋面還不夠廣。一些條款會隨著時間的流逝形成與具體任務更匹配的專有架構，新的分類（例如“跳轉”條款可以告訴你需要參閱哪些條款）也會隨著時間流逝逐漸完善。我們並未提前設計好這些東西，因為我們不知道到底什麼是可行的，什麼又是不可行的。

如果願意，可以將其稱之為“敏捷文件”，敏捷是目前的熱門（以前最熱的是 ITIL）。當然，重點在於 簡化和實用性 勝過其他一切。

會寫文件的田螺姑娘並不存在

在文件方面花費那麼多時間和精力後，自然而然就得出了這樣的結論。

首先，我們不再寄希望於接受其他團隊提供的文件。如果他們給程式碼加了註釋，這挺好；如果我們能在維基中找到對自己有幫助的資訊，這也挺好。但在接手不同專案時，我們已經不再“要求對方提供文件”，相反我們會安排與負責設計專案，並且有經驗的 SRE 約個時間一起討論。

一般來說（假設沒有運維經驗的話），開發者往往更關注自己開發的東西及其工作原理，這些東西通常會經歷徹底的測試，出錯的可能性是最低的。

與之相對的，SRE 最關注弱點，以及可能出錯的東西。“如果為網路劃分分割槽會怎樣？如果資料庫磁碟空間不足會怎樣？能否通過日誌判斷使用者為什麼沒有收到錢？”

隨後我們會自行編寫自己的文件，並讓相關工程師進行簽發，這是一種與傳統工作流截然不同的方法！他們通常會給出非常有用的意見，並針對整個流程為我們提供更深入的見解。

我們注意到的第二件事是，我們的工程師依然不願意更新文件，除非是他們自己會用到的文件。然而文件依然需要交給他們處理。領導層只能不斷地強調這也是工程師自己的文件，不是世代相傳的石碑，如果不進行持續不斷的維護，文件很快將變的毫無用處。

這其實是一種文化方面的問題，需要花費很長時間才能解決。解決這個問題還需要能通過流程強制對文件進行修訂。

最後我發現，我們的日常工作中約有固定 10% 的工作時間被用來維護和編寫文件。在最開始 7 個月的突擊之後，這 10% 的時間主要被用於維護文件，而不是繼續建立新的內容。

文件 – 收益

文件工作全部完成後，我們所獲的的收益遠遠超過了那 10% 的工作時間。例如：

新員工更易於上手

在實施這樣的流程之前，我們不願意僱傭沒經驗的人員。但實施之後人員的上手過程更加順暢了。此外事件發生之後進行的培訓也逐漸培養了更多有經驗的人員。新員工首先需要幫我們維護文件，這一過程也有助於他們對自己的知識和技能進行查漏補缺。

更好的培訓

文件為我們提供了豐富的資源，可以幫助我們確定培訓需求。進而我們可以為任何工程師提供完成工作所需掌握的工具和技術。

簡化的升級上報流程有助於減少壓力

這個收益非常重要。在使用循序漸進的事件模型前，何時進行升級上報是一個壓力重重的決策。一些工程師因為過早升級上報而著稱，大家都無法自信地確定在非工作時間聯絡負責的技術主管前是否“漏掉了某些顯而易見的狀況”。SRE 也經常因為升級上報不夠及時而頭疼！

事件模型解決了這個問題。很快，負責處理升級上報後問題的技術人員開始首先詢問：“你是否已經按照事件模型進行過處理？”如果是，並且存在某些明顯的疏忽，那麼問題就變的非常明確，可以快速解決。很快，非 SRE 人員在處理過升級上報的問題之後會開始忙著更新和維護文件，進而形成了一種良性迴圈。

更好的紀律

對於團隊來說，文件最明確的價值在於可以幫助團隊改進其他方面的紀律。有趣的是，以前 SRE 被譽為“最吵雜”的團隊，他們經常會進行各種“爭論”，並且整個團隊的社交屬性十分強。這其實也挺合理，因為我們畢竟需要相互支援著才能搞定各種大型的技術領域，滿足通常不具備技術背景的客戶預期，而知識和文化的分享很重要。

隨著流程的推廣，這個團隊變的越來越安靜，部分是因為有了專門的交流環節，逐漸開始推行遠端工作，以及團隊逐漸變的國際化，但同時也是因為大部分工作都變成了一種例行任務：遵循事件模型的指導，任務完成後或者有什麼不理解的地方時，可以升級上報給更資深的人員。

自動化

通過這種方式對調查過程實現自動化，意味著還可以藉助軟體對其實現更高程度的自動化。

通過制定指標將不同工單連線到不同的事件模型，這也意味著我們知道需要將自己的精力專注在何處。我們編寫了在後臺對日誌檔案進行梳理的指令碼，藉此更快速簡單地找出與程式碼有關的問題，同時通過自動化方式響應客戶的需求（“此問題是應用管理員使用者 XXX 所做的某項變更導致的”），此外還採取了一系列其他措施。

迴歸流程本身

準備好所有這些資產後，如何預防這些資源隨著時間流逝而貶值？此時流程本身非常重要。

為確保一切可以繼續平滑運轉，我們制定了兩個重要流程：驗傷（Triage），以及事後審查。

流程 – 驗傷

我們有 5%-10% 的時間花在驗傷流程中。另外，為了確定最準確的流程，之前已經付出了大量時間，不過這些付出獲得了巨大的回報：

將需要採取的運算元量精簡為必須的最少步驟

將盡可能多的任務包含在驗傷流程中，這種做法對我們有很大的吸引力，但更重要的是確保流程本身的價值而非完整性。任何不常執行的操作通常會被跳過，並從驗傷流程中忽略掉。

專注於通過流程節約成本

通過查詢重複的內容，找到相關事件模型，更快速回復客戶的諮詢，並且儘可能早得進行升級上報，這些舉措大幅降低了每個工單的成本。這樣做還可以避免其他工程師在思考其他問題時被打擾而產生不良後果。這些舉措的實際收益很難衡量，但我們可以用更少的人手，更容易地處理更多事件。這些都被高管和客戶看在眼裡。

將所有工作的詳情記錄起來也可以幫我們節約時間，（例如）當工程師接到驗傷工單後，可以看到在歷史事件中搜索的驗傷結果，進而找出有待改進的地方。這也意味著可以由更有經驗的人員隨時審閱驗傷流程的質量。

驗傷流程的審閱

有經驗的人員需要定期審閱驗傷流程，以確保流程得以有效地運用。

當我轉崗到另一個運維團隊（是一個我不太瞭解的領域）後，通過恰當應用這些技術，我用了大約三天時間就將事件佇列中積壓的事件減少了一半。驗傷流程是現成的，但大家在執行時並未仔細思考或進行有效監管，並且將這些責任交給了一個不能勝任的初級員工。大錯特錯。驗傷流程的執行或監管，必須由具備嫻熟經驗的人負責，雖然看上去這是一種例行的乏味工作，但其實包含了大量重要決策，必須由經驗提供支撐。

沒錯，我就是新的負責人，我決定將第一週的工作時間用於這種“沒技術含量”的驗傷任務。畢竟我覺得這個工作還是很重要的。

輪值任務

沒人希望長時間負責驗傷工作，因此我們採取了每週輪值的做法。藉此可以實現一定程度的連續性和一致性，但也可以有效避免工程師反覆在相同任務上花費大量時間而抓狂。

流程 – 事後審查

驗傷流程相對的是“事後審查”。每個工單都會由有經驗的團隊成員進行審查，這個過程大約需要佔用 5% 的工作時間，但同樣是值得的。

為此需要填寫一個標準化的表單，如果有任何意見建議，可新增到後續“改進”任務列表中，並劃分出優先順序。這為我們造成了大量等待解決的技術／流程債務。

文化

上文曾多次提到文化，只要打算進行任何型別的變更，都不得不考慮文化問題，畢竟文化已經根植於一系列概念框架中，而我們的所有行動都需要遵循這些框架的規定。

另外我還提到過，人們通常會糾結於“錯誤的事情”。我曾多次聽說有人專注於工具和技術，而非專注於文化。沒錯，工具和技術很重要，但如果不能有效運用，所造成的後果甚至會比完全沒使用時更糟糕。你也許可以加入全球最棒的高爾夫俱樂部，但你連揮杆都不會，只會打棒球，那麼這個俱樂部對你而言有何意義？

文化所需的投入遠遠超過技術本身（別忘了，單單為了寫文件我就花了大半年時間）。如果具備合適的文化，人們將能在需要時找到合適的工具和技術。

在決定將時間和金錢花在哪裡時，一定要以文化為第一選擇。雖然需要耗費大量預算，但可以強有力地剔除“無用”的團隊成員，這是我在接管其他團隊後做的最棒的事。那人離開後，其他團隊成員表現好了很多，不再受到他那過激行為的影響，很多以前做不到的事情都順利完成了。

我們還用很小的預算構建了一個高效能團隊，預算小到什麼程度呢，負責招募的人甚至在電話裡衝我嚷嚷說我的目標是“不可能”的。但只要專注於恰當的行為，針對找到的人員不吝付出時間，準備好妥善的流程，我們實現了效能的大幅提升，並且形成了一個高忠誠度的團隊，開始在公司內部和外部（其實主要還是內部！）實現了更大規模，也更出色的壯舉。

辦公室政治

簡單說說辦公室政治。你可能要隨時投入“戰鬥”。很可能你得不到所需的資源，所以搞不定的工作需要適時放棄。

沒錯，你需要監視解決方案，需要更好的文件，需要訓練有素的出色人員，需要更多測試……除非有印鈔機，否則不可能得到自己想要的所有東西，因此還是確定最重要的事情，試著優先解決它們吧。如果試圖同時在所有方面進行改進，最終很可能會失敗。

除了流程和文件，我還曾試著破解“可再現環境”的謎題。最終決定選擇 Docker，這是我職業生涯的一次重大轉變。我曾在 這裡 和 這裡 簡單探討了這些問題。

文章來自微信公眾號：高效開發運維