構建強大的專案on-call文化
在運營和管理中，on-call的團隊通常負責確保服務和應用程式的可靠性和可用性。如果沒有建立一個高效的on-call團隊，將對業務造成明顯的不良影響。一個不健康的on-call團隊文化會在一個管理組織中產生壓力和挫折感。本文中將描述Button團隊on-call管理的最佳實踐。
當我第一次加入Button的on-call團隊時，我非常擔心被排班。如果我在我值班時睡過去了怎麼辦?那服務怎麼辦?我應該盯著哪個儀表盤看呢?從那以後，我幾乎一年的時間都在輪班，值班了無數次。雖然我不能說我喜歡做on-call的工作，但我可以證明，作為on-call輪班的一員肯定是我在Button工作的一個亮點——在很大程度上是由於我們on-call團隊的 ofollow,noindex" target="_blank">支援和文化 。
什麼是on-call，其文化為什麼重要？
在運營和管理中，on-call的團隊通常負責確保服務和應用程式的可靠性和可用性。如果沒有建立一個高效的on-call團隊，將對業務造成明顯的後果——直接收入損失和聲譽損害。一個不健康的on-call團隊文化會在一個管理組織中產生壓力和挫折感。工程與軟體的維護和構建同樣重要。如果你一直需要為生產開發中斷而擔心，那麼構建可擴充套件性的軟體是很困難的!
如果處理不當，凌晨2點的宕機可能對公司造成損害，也可能讓起床處理相關問題的個人感到沮厭煩和不爽。對於一種健康的on-call文化來說，關注這兩點問題都很重要。在本文中，我將描述Button團隊on-call管理的最佳實踐。
Button公司的on-call
Button的on-call貼紙，由 Cori Huang 設計
在Button，構建服務的產品工程師還負責保證所有關鍵服務的24/7正常執行時間。為了做到這一點，我們保持每週的on-call迴圈，從週五中午開始，我們會進行一個物理WiFi熱點切換。同時確保總有兩個人能隨叫隨到——一個是主負責人，一個是後備人員。如果主伺服器在接收到由於停機而觸發的初始頁面請求沒有響應或不可用時，該頁面請求就會被轉到備伺服器。還會給工程on-call團隊配一個業務團隊對應人員，負責處理合作夥伴業務的升級和外部通訊中斷問題。
最後同樣重要的是，處於隨時待命狀態是自願的。並不是所有的產品工程師都需要參與on-call，他們也可以隨時加入或離開。因為on-call是一種獨特的責任，而且往往需要作出特別的犧牲，作為回報，Button每月會給on-call團隊的每一個成員適當的獎金獎勵。
促使我們on-call團隊成功的因素是什麼？
以下是我們團隊on-call文化的一些核心理念:
- 做好入職流程
- 設定正確的目標
- 確定一個關鍵負責人
- 無保留的檢視問題
- 我們的告警理念
- 鼓勵自我照顧
做好入職流程
從一開始就要為目標的達成做準備。我們不只是在on-call的輪換過程中增加人員，並期望他們能做好。我們的入職流程如下:
- 跟隨一個當前on-call的工程師學習。
- 在一週的工作時間內成為主要負責人員，並在實際工作中逐步提升。
- 自己處理升級——我們會為新工程師模擬升級以便發現問題並解決問題。
- 加入on-call的排班序列中。
設定正確的目標
負責升級並不一定意味著你最終要解決每個問題並找到它們背後的根本原因，也不意味著你需要擁有這樣做的專業知識。
下面引用我們升級手冊中的一段話:
把它想象成一個醫院：急診室的醫生在那裡對病人進行前期處理和病情分類，然後把病人送到更專業的護理人員那裡。
當我們真的需要處理現場問題時，我們並不需要解決所有問題——我們需要評估問題，確定對業務的影響是什麼，通過我們的狀態頁面進行外部溝通，並儘可能地減少損失。通常情況下，需要執行後續任務以確保升級問題完全解決，而不會讓它成為重複發生的事故。我們非常信任我們的工程師能夠做出最好的判斷，在升級過程中不斷做出正確的判斷需要經驗和實踐。
確定一個關鍵負責人
有時高壓升級可能是混亂的。可能有很多人蔘與其中，或者有很多系統在起作用，因此跟蹤升級中的變化以及誰在做什麼變得非常重要。我們遵循的理念是，在任何時候都由一個關鍵人物來負責升級響應。
我們的手冊是這樣描述的：
在升級過程中，該人對所有決策負責，包括生產變更，以及決定與其他方進行溝通的時間和內容。如果你不是關鍵人物，你就不應該做這些事情，除非關鍵人物明確要求並指示你去幫助他。
在升級過程中，關鍵人員可以更改;只要它是明確的(例如，“生產問題已經解決，Barry將接過任務作為新的關鍵負責人。”)
無保留地檢視問題
我們努力從自己的錯誤中吸取教訓，其中很大一部分是一種不要進行指責的事後自檢文化。
不進行指責的事後分析讓我們能夠誠實而大膽地談論我們本可以做得更好的事情，並反思我們所學到的東西。這些是工程師們提倡對現有流程進行關鍵基礎設施改進或更改的地方。這為公司的其他成員提供了一個機會來權衡和討論業務影響，並設定未來的期望。
問題檢視也是深入研究問題根源的方式。我們堅信會有一個神祕的刺針——如果我們的生產系統以一種我們沒有預料到的方式執行，我們想知道原因。
我們的告警理念
普羅米修斯的logo
我們使用 普羅米修斯 作為告警文化的一部分。告警規則會提交給 Github 和同行評審。 Alertmanager 向 PagerDuty 、email和Slack傳送告警提醒。我們有三種不同型別的告警:
- 非分頁警報:僅向電子郵件和Slack傳送警報 。
- 日間分頁提醒:在白天向PagerDuty傳送提醒，但在其他情況下只發送到電子郵件和Slack。
- 尋呼警報:隨時向PagerDuty、email和Slack發出警報。
團隊中的任何工程師都有權新增或刪除警報，但所有警報都應該是可操作的，並且必須有一個問題報告。我們的報告應該是簡短的，說明當警報被觸發時可以採取的具體行動。每個報告條目都包含對業務影響、有用的bash命令和到適當指示板的連結的簡要描述。我們的目標是讓任何工程師，不管他們有多少上下文，都能夠使用報告中的資訊來快速定位問題。
為了追蹤我們的警報是否真正具有可操作性，我們借用了一些資料科學的概念，並測量了警報的 準確率和召回率 。在本例中，準確率指的是觸發可操作性告警的百分比，召回率指的是警報通知我們的可操作性事件的百分比。當準確率較低時，我們會評估是否應該禁用或修改特定警報以在較低的閾值上觸發。當召回率低的時候，我們試著看看是否有更好的訊號來衡量我們應該應對的實際症狀。
鼓勵自我照顧
無論是晚上被打電話，還是要重新安排晚餐時間，on-call都可能破壞你的個人生活。然而，如果設定得當，on-call不應該成為任何個人的不應有的負擔。下面是Button的on-call團隊確保我們的工程師不會精疲力竭的幾種方法:
- 在一週結束的時候，我們會盡量安排另外的人進行輪換。如果有明確的問題，我們會關閉它們或將它們交給產品團隊去處理。
- 我們維護一個on-call的歷史記錄，所以如果升級時某個問題重新出現，你可以看到以前的工程師是如何處理和解決它的。
- 在處理升級時，我們的on-call工程師使用Slack來一步步的溝通他們的決策和操作行為，以便其他人能夠跟進。
- 我們的on-call日程很靈活。如果有人需要休息幾個小時，我們會檢視運營狀態表，看看是否有人可以替代。如果某人是今晚的主要負責人，第二天我們鼓勵換一個人做這件事，這樣他們就可以得到他們應該得到的休息。
- 我們被鼓勵並準備好在工作時間內外尋求幫助。沒有什麼比看到一個你根本不知道如何下手的任務更令人沮喪的了。我們知道，尋求幫助總是比按照錯誤的假設行事更好。我們將on-call的團隊的聯絡資訊儲存在值班表中，以便在工作時間以外出現緊急情況時，我們能夠聯絡到相關人員。
互相支援
Button現在的規模不適合期望每個工程師都知道每個服務是如何工作的。我們的on-call工程師不僅來自不同的工程學科，而且在Button的不同產品團隊中工作。不是每個人都是DevOps專家，當然也不是每個人都熟悉我們系統中的每一個軟體。然而，我們作為一個團隊互相支援，幫助對方成長為我們的優勢，克服挑戰，學習新的技能。on-call的經歷教會了我如何設計和構建更好的軟體，如何清晰地溝通，以及如何成為一個更有同理心的隊友。