對於大多數科技公司來說，尋呼是不可避免的事實。當您的軟件出現重大問題時，您需要能夠迅速采取行動並作出響應的人員，以便將對您所服務的客戶的影響降至最低。manbetx万博全站客户端您的組織如何計劃和管理這一過程，將對您能夠如何成功地響應事件以及您能夠在多大程度上將這些情況對您的團隊造成的損失降至最低產生重大影響。

在Braze，我們在過去的一年中一直致力於對頁麵處理方式進行重大更改。從曆史上看，當涉及到頁麵時，我們的DevOps團隊一直站在前線——即使是引起問題的應用程序代碼，而不是基礎設施——並且沒有升級到產品工程團隊的明確途徑。這從來不是一個理想的方法，但到去年年初，情況變得很明顯，它不再適合我們的組織;我們需要找到方法來確保產品工程能夠為我們擁有的代碼提供全天候的支持。另外，我們的組織有提高係統穩定性和性能的宏偉目標。我們設定了雄心勃勃的服務水平目標(SLOs)，並且需要能夠確保當我們的係統出現問題時，能夠快速修複它們。釺焊多年來迅速增長我們現在每天發送超過20億條消息(並接收數十億個事件)，因此有必要創建一個更強大的生態係統，用於與我們大規模的實時係統相關的培訓、優先級排序和支持。

就其本身而言，這種組織範圍內的變化需要付出巨大的努力。但在Braze，有一個問題讓事情變得複雜:我們基礎設施的重心是一個龐然大物．使用標準的服務架構，頁麵從一個服務發送;然後，擁有該特定服務的團隊負責響應。然而，對於monolith，給定頁麵的所有權可能是不明確的。因為多個Braze團隊在這個整體中擁有自己的代碼，我們必須解決的一個主要問題是如何確保所有頁麵都被路由到適當的團隊。

請繼續閱讀下麵的故事，了解我們如何通過以下步驟為我們的龐然大物推出有效的覆蓋率:

• 通過堅持持續改進、增量變更和自動化的原則來優化我們的過程、基礎設施和代碼
• 利用敏捷工作流程並對頁麵處理進行每日檢查，以確保對每個頁麵進行根本原因分析……這一行動是為了防止再次發生
• 利用跨職能委員會的見解進行組織變革

第一步:組織一個委員會來推動結果

我們是通過從過去的成功中汲取靈感創建一個跨職能委員會來診斷、討論和實施我們需要對傳呼係統進行的更改。在推動組織變革方麵，這類委員會有多麼重要，我怎麼強調都不為過。擁有來自多個不同職能(和資曆級別)的不同團隊的代表會帶來巨大的好處，包括:

• 在整個過程中，更有代表性、更高數量和更高質量的投入
• 在持續的基礎上，從不同的團隊中征求和交付關鍵的見解
• 提前讓公司各個團隊的成員為委員會預期的變化做好準備，以減少摩擦，提高結果

而Braze並沒有明確地遵循亞馬遜著名的“兩個披薩”規則在會議規模方麵，我們努力確保所有委員會的規模都足夠小，以便進行真正的對話。(不過，不同機構的情況可能不盡相同。)然而，因為這項工作需要大量的跨團隊的頁麵排序和路由，以及特定於團隊的流程更新，所以確保我們有來自所有相關團隊的涉眾，並擁有他們需要的上下文來幫助推出更改，這對我們來說是必要的。

第二步:支持我們所創造的內容

在委員會最初的會議上，我們都一頭紮進了對主要問題的診斷中:

• 許多正在發送的頁麵是由應用程序代碼觸發的…但是處理這些代碼的是那些沒有寫過這些代碼的隊友
• 整個工程人員中的一小部分負責公司的所有非工作時間支持
• Braze的SLO目標隻能通過擴大支持來實現
• 在某些情況下，我們沒有有效地跟蹤頁麵，導致了可預防的複發

很明顯，現狀需要改變。例如，如果產品工程團隊的工程師編寫了性能不高的代碼，導致我們的排隊係統一夜之間發送了一個頁麵，那麼做出響應的DevOps團隊成員將缺乏如何修複該問題的關鍵上下文，以及解決遞回問題的清晰路徑。鑒於此，我們需要編寫特定代碼段的團隊在生產環境中完全支持它——無論是在分類能力方麵，還是在執行預防性步驟和增強功能方麵。

第三步:確定誰擁有什麼

一旦我們同意我們組織中的團隊需要擁有並為他們的離散的、單獨部署和測試的庫、服務和組件提供24/7的支持，我們就需要找出實現這一目標的步驟。第一個?分離DevOps頁麵和產品工程頁麵。畢竟，我們不能按團隊路由頁麵，除非我們已經通過按部門路由頁麵奠定了基礎。

為了執行第一步，我們重新組織了整個PagerDuty配置，確保我們有:

• 代表我們整個基礎設施的PagerDuty服務
• 路由到DevOps升級的頁麵
• 路由到產品工程升級的頁麵

那看起來像什麼?嗯，例如，這意味著DevOps接收到與數據庫故障相關的頁麵，產品工程接收到與大量未處理的異常相關的頁麵，而當我們的作業隊列不健康時，兩個部門都接收到頁麵。(也就是說，我們仍然在一段時間內繼續對DevOps升級進行分頁，直到產品工程升級人員配備齊全。)我們還將PagerDuty配置移動到terraform，以使將來的更改更容易、更透明。

通過采取這一步驟，我們能夠為未來所有促進有效頁麵分類和預防複發的努力奠定基礎。

第四步:讓團隊隨時待命

為了繼續前進，我們的下一步是定義一個輪換的工程師，他們已經準備好並能夠根據頁麵對生產中的問題進行分類。為了實現這一點，我們知道我們需要有效地為輪崗配備人員，提供相關的培訓和支持，並快速迭代以納入對這個主要工作流更改的反饋。

當我們分離正在發送的頁麵時，我們優先確保每個頁麵都有一個與之關聯的運行簿，並且正確地設置了培訓和許可協議。在這個過程中，我們認為擁有一套合適的運行手冊是至關重要的，這使得任何工程師都可以對大多數生產問題進行分類。但是，雖然編寫運行手冊很有用，但我們發現:

• 大多數簡單的運行手冊都已經自動化了——沒有理由讓人來做計算機可以做的事情
• 沒有可自動化運行簿的頁麵往往是由複雜的問題引起的，需要快速解決，以允許我們大規模的高性能係統維護我們的SLOs;這意味著在這些情況下麵臨的問題太複雜了，以至於我們無法在任何合理的時間框架內編寫運行手冊

除了在為大多數頁麵創建簡單的運行簿時遇到的困難之外，我們還發現我們收到的大多數頁麵本質上都是這樣的:某個地方的某個東西運行得不夠快，我們的排隊係統正在備份。很明顯，分類頁麵是一項需要教授的技能，因為大多數團隊目前不具備處理這些操作問題的知識。

考慮到這一點，我們決定從一組工程師開始，在一個單一的巨石旋轉上工作。我們的計劃是對這些工程師進行核心技能培訓，使他們能夠在大規模分布式係統中診斷問題並及時解決問題——然後讓新工程師輪崗，並通過文檔、跟蹤和現場培訓為他們做好準備。

下一步呢?形成工程分類隨叫隨到，並開始測試我們的培訓和實現過程。

當我們實際推出時，我們發現讓工程師在白天執行真正的係統緩解，例如禁用或限製活動隊列的處理，是最有價值的培訓之一。在解決問題的過程中，這些策略是比較常見的步驟之一，但當生產問題正在進行時，很難優先考慮讓學員執行該操作，而且更糟糕的是，他們不得不這樣做，這對他們來說很可怕。事實證明，在安靜的環境中練習這些可怕的步驟是非常有價值的。

第五步:“現場”

我們的新輪崗開始得很慢，從周一到周五，早上8點到晚上8點。對我們來說，重要的是我們沒有以24/7的方法開始，因為我們知道我們的計劃可能有需要改進的方麵，並且在我們迭代的時候會產生噪音。為了讓我們能夠采用這種方法，我們的DevOps團隊在每一頁上都與我們合作。

當產品工程收到我們的第一頁時，我們每周對我們的工具進行改進，以監控和分類生產中的問題。我們的事件管理儀表板也得到了一係列迭代改進，增強了我們團隊的可見性和可用性，包括:

• 創建一個Slack頻道，記錄與Braze平台相關的任何特性翻轉，使調試最近狀態變化的問題變得更容易
• 使用我們的內部事件管理工具，在任何時候采取行動，都可以自動化Slack帖子，從而快速查看之前工程師所采取的行動

我們還同時努力徹底改革我們處理這類事件的角色、責任和流程。通過實施正式的事件指揮官和溝通聯絡員，對所有事件進行回溯，並定期檢查與頁麵相關的行動項目，我們發現確實發生的事件運行得更順利，有更好的結果，並且後續處理更可靠。

第六步:減少頁麵

當產品工程團隊致力於24/7擁有相關頁麵時，我們也優先考慮盡我們所能減少頁麵。為了確保我們對即將到來的頁麵進行清晰的跨團隊溝通，我們采取了幾個關鍵步驟。

跟蹤頁麵與JIRA

每收到一頁，我們都會把它記錄到一個JIRA為此目的而創建的董事會。董事會記錄了對頁麵響應的五個階段:接收新頁麵、根本原因分析、正在進行的跟蹤、完成的跟蹤和完成的事件。

在我們的新流程下，在與該頁相關的潛在問題被修複之前，一張卡片必須留在棋盤上。這可能意味著修複錯誤、更改頁麵配置或發布性能增強。

在日常會議中查看頁麵

為了確保後續工作得到處理，我們每天召開一次會議，審查收到的頁麵以及正在采取的處理步驟。會議包括來自整個工程團隊的利益相關者的輪流小組，確保我們擁有確定根本原因所需的集體知識，倡導下一步，並有效地處理後續工作。

這一努力得到了回報。自從開始這些項目以來，盡管我們增加了更多的團隊和更多的服務，但我們的頁麵數量卻在下降。作為一個產品工程團隊，通過跟蹤係統中我們用於核心工作流的頁麵，我們能夠將它們深度集成到現有的工作流中。擁有一個分類和解決頁麵背後原因的最佳流程，可以使所有團隊更好地理解影響係統的問題並采取預防措施——與正確的人員組合進行每日會議，可以有效地遵循這一流程。

第七步:全天候工作

一旦我們達到了這一點，我們決定我們已經準備好了，我們將推出一個24/7的產品工程輪崗。我們必須采取的關鍵下一步是決定誰來為我們的“非工作時間”輪崗工作。我們決定嚐試以誌願者的方式為其提供工作人員，如果這還不夠的話，我們會采取額外的措施;值得慶幸的是，我們能夠獲得足夠的誌願者人數，這使得24/7隨叫隨到的直播成為可能。

第一周有點艱難。首先，事實證明，一些按正常工作時間校準的頁麵不需要像設置的那樣頻繁地啟動。但是我們幾乎每天都在頁麵審查會議上做一些改變，在非工作時間輪換的第二周，我們發現事情完全可以控製。

最終的想法

展望未來，釺焊產品工程團隊將繼續專注於迭代改進我們的工藝和在生產中的應用。與此同時，我們將開始確保我們的代碼被更清晰地分割成可以獨立測試、部署和支持的部分。

正在考慮重新設計分頁方法?從我們的經驗中學習以下幾點:

• 使用跨團隊的委員會來監督過程，可以確保您獲得關於變更的最佳輸入，並且組織中的其他人可以就事物的狀態向他們谘詢
• 創建頁板可能是一種轉變，它可以量化係統中的風險，並更有效地對後續工作進行優先級排序，並且有必要定期召開頁評審會議，以確保頁板得到有效使用
• 從長遠來看，不斷改進和自動化頁麵流程可以提高整體效率，並節省大量時間和精力

想加入Braze工程團隊嗎?查看我們的這裏的空缺職位．