《運維全球最大游戲網站過程中積累的SRE經驗》要點：
本文介紹了運維全球最大游戲網站過程中積累的SRE經驗，希望對您有用。如果有疑問，可以聯系我們。

作者 |：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 所做的某項變更導致的”),此外還采取了一系列其他措施.

在這些自動化機制的支持下,我們基于 Pexpect 為自己構建了一個自動化工具：http://ianmiell.github.io/shutit/,不過這就是另一個故事了.基本上在適應這些后我們養成了持續改進的良性循環.

回歸流程本身

準備好所有這些資產后,如何預防這些資源隨著時間流逝而貶值?此時流程本身非常重要.

為確保一切可以繼續平滑運轉,我們制定了兩個重要流程：驗傷(Triage),以及事后審查.

流程 – 驗傷

 

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

將需要采取的操作數量精簡為必須的最少步驟

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

專注于通過流程節約成本

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

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

驗傷流程的審閱

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

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

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

輪值任務

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

流程 – 事后審查

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

為此需要填寫一個標準化的表單,如果有任何意見建議,可添加到后續“改進”任務列表中,并劃分出優先級.這為我們造成了大量等待解決的技術／流程債務.

文化

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

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

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

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

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

辦公室政治

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

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

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

作者：Ian Miell,英文原文：Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Siteshttps://zwischenzugs.wordpress.com/2017/04/04/things-i-learned-managing-site-reliability-for-some-of-the-worlds-busiest-gambling-sites/#comment-746

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4132.html