作為 DevOps 難免遇到各種 alert 和 incident，如何高效可靠地管理這些意外事件成了 DevOps 工作流程中不可避免的話題。本篇文章為大家介紹我們的 incident 工作流，和一些實踐過程中總結的經驗。
Incident 來源
Incident 的來源有許多，例如客服團隊人工上報、監控系統發出的 alert 等。我們絕大多數 incident 都源自後者，而 alert 則分別來自白盒、黑盒、基礎設施的監控。
白盒監控
所謂白盒監控，重點在於關注應用內部的指標，例如每秒請求數。力求在使用者可察覺的意外發生前，將它們扼殺在源頭。
我們採用的是 Prometheus + Alertmanager 的組合。Prometheus 通過 exporters 採集各個應用內部的指標，計算告警規則表示式，並將符合規則的告警傳送給 Alertmanager。
Node Exporter <---+
Kube-state-metrics <---| +------------+
Nginx exporter <-------+ Prometheus |
Redis exporter <---| +------+-----+
... <---+ |
|
+------+ | +-------+
| ^ v v |
| Evaluate alert rules |
+----------+-----------+
|
Send alerts if |
any condition hits |
|
+-------v------+
| Alertmanager |
+-------+------+
|
v
+--+--+
| ? |
+-----+我們在之前的文章中有梳理過 Prometheus 配合 Alertmanager 的詳細用法，本文不再展開相關內容。
黑盒監控
黑盒監控更多關注的是「正在發生的事件」，例如某應用響應時間過高。它們常常與使用者的角色一致，與使用者可觀察到的現象一致。儘可能在意外發生時，能夠及時上報問題，而不是等待使用者的反饋。
曾經我們選用的是 StatusCake 作為探針，定時向我們的服務發起請求，若出現超時、拒絕連線、響應未包含特定內容等問題則觸發告警。但後來偶然一次被我們發現，部分監控意外停止超過一個小時，此時服務當機完全沒有任何告警，StatusCake 官方也沒有及時告知這一問題，後續跟 StatusCake Support 確認是 bug：
Hi there,
We’ve since resolved this issue and we have credited a half month’s credit to your account to be deducted from the next subscription cost. The issue at the time was related to an error on a single testing server.
My apologies for the inconvenience here and won’t see that happen again!
Kind regards,
StatusCake Team
我們不確定此前是否有過類似事件我們沒有發現，加上使用者互動體驗較差等因素，我們決定徹底放棄 StatusCake 轉向 Pingdom。
+---------+
| Pingdom |
+---+--+--+
| |
Continuously sending | | Send alerts if
requests to probe | | the services are
the black box | | considered down
+------+ |
| |
+------v---+ +v----+
| Services | | ? |
+----------+ +-----+
從圖中可以看到我們建立了大量的監控項，儘可能多地覆蓋每個專案、每個環境、每個獨立元件，讓 Pingdom 幫助我們時刻關注著各項服務的狀態。
對於定時任務的監控我們選用了 Cronitor，在之前的文章有過詳細介紹。
以上這些監控項我們全部使用 Terraform 程式碼化管理。同時，我們強烈建議使用第三方服務作為黑盒監控，而不是基於 AWS、Azure 之類的雲服務自主搭建。例如 StatusCake 就在幫助文件中 明確表示 有大量合作供應商，絕對不用 AWS 或者 Azure 的節點，以避免單點故障問題。我們認為黑盒監控是 incident 工作流中非常重要的一環，需要盡最大可能避免由於雲服務商出現大規模故障而導致監控失效。雖然這種可能性非常非常之小，但不是沒有發生過，例如當年 AWS S3 出現故障導致無法更新 status dashboard，因為警告圖示就存放在當機的服務上。
基礎設施監控
除了應用的白盒監控、服務的黑盒監控之外，基礎設施監控也是比較重要的一環。我們的主要雲服務提供商是 AWS，使用了 RDS、SQS、ElastiCache 等 AWS managed 的服務，因此也需要關注它們的指標和告警資訊。這部分我們採用的是 AWS 官方的 Amazon CloudWatch。
限於篇幅，基礎設施的告警通常比較少見，此處不再詳細展開。
Incident 通知
Incident 發生後，相關資訊應當通知到 DevOps。我們目前規定了兩個主要途徑作為 Incident 的「出口」。
Slack
作為我司內部的即時溝通工具，Slack 同時承擔了大量的訊息通知工作，包括 GitLab、Cronitor 等。我們為告警資訊建立了一個單獨的 channel 叫做 #ops-alerts。
DevOps 團隊成員將該頻道的 Notification Preferences 改為 Every new messages，或是在全域性 Preferences -> Notifications -> My keywords 中配置好例如 failed、warning 之類的關鍵字，即可確保通知訊息能夠及時送達 iPhone、iMac 等終端。
On-call
國內 on-call 工作機制似乎不太普遍，簡單來說，就是隨時做好接聽「告警通知電話」的準備。
雖然 DevOps 工程師會盡可能關注 Slack 通知，但還有些時候不一定能夠及時收到告警資訊，例如：
- 非工作時間，
- 漏看訊息，
- 正在處理其它問題等。
如果發生比較緊急的告警，例如 production down，需要立刻被處理。於是我們配置了 on-call，由 DevOps 工程師輪流值班，根據 on-call schedule，將優先順序較高的 incident 通過文字轉語音（TTS）撥打電話通知到人。
另外，DevOps 團隊還會把告警的電話號碼加入 iPhone 聯絡人，並開啟 Emergency Bypass，這樣就不用擔心誤觸靜音開關或是勿擾模式接不到電話了。
連線來源與通知並規劃工作流
Opsgenie 是一款 Atlassian 旗下的 incident 管理產品。它提供了大量的 integrations，從 AWS CloudWatch、Pingdom 之類的監控系統，到 Slack、RingCentral 等通訊工具。這使得它幾乎能從任何來源接收 alert、建立 incident，又能把這些 incident 以各種各樣的方式通知到負責人員。
例如在上文中提到的幾款產品：
另外，在工程師收到告警通知後，應當第一時間 acknowledge，表示已知悉：
如果沒有在特定時間內 acknowledge，該報警資訊將會被 escalate，將通知資訊傳送給更高等級的負責人。
Opsgenie 還提供了一個清晰的 dashboard。它能夠在 DevOps 收到通知後，提供詳細的 incident 資訊；另外由於多個來源的 alert 彙總在同一頁面，這會幫助 DevOps 瞭解此時整個系統的巨集觀狀態，有助於排查問題的根本原因。
我們還對不同來源、tag 的 alert 標記了不同的優先順序，例如 P1 和 P3。在上圖中的兩個 Watchdog 告警均為 P3 優先順序。P1 優先順序的 incident 將會 On-call 通知，其它優先順序則通過 Slack 訊息。
+--------------+ +---------+ +------------+
| Alertmanager | | Pingdom | | CloudWatch |
+------+-------+ +---+-----+ +---------+--+
| | |
| | |
+-----------v v v---------------+
+-----+------+
| |
| Opsgenie |
| |
+----+--+----+
| |
P1| |P3
Alerts| |Alerts
| |
+---------+ | | +-------+
| On-call | <---+ +---> | Slack |
+---------+ +-------+總結
以上就是我們的 incident 工作流，歡迎與我們分享你的經驗。
請關注我們的微信公眾號「rightcapital」
本作品採用《CC 協議》，轉載必須註明作者和本文連結