SRE工程師-實習生
首先，讓我自我介紹一下。 我 - ，組內前端工程師 GitLab。 上週，我有幸與我們的一位待命 SRE 工程師一起實習。 目的是觀察值班人員如何應對日常事件並獲得實際工作經驗。 我們希望我們的工程師能夠更了解用戶的需求 監控::健康狀況。
我得跟著SRE工程師到處走一週。 也就是說，我在交接時在場，監控相同的警報通道，並在事件發生時做出回應。
事件
一週內發生了 2 起事件。
1. 加密礦工
GitLab.com 週三的使用量激增 'a，是由於試圖利用跑步者的分鐘數來挖掘加密貨幣而引起的。 該事件是使用我們自己的違規中和工具處理的，該工具會停止運行者的任務並刪除與其關聯的項目和帳戶。
如果這個事件沒有被注意到，自動化工具就會捕捉它，但在這種情況下，SRE 工程師首先註意到了違規行為。 事件任務已創建，但其資訊已關閉。
2. Canary 和主要應用的效能下降
該事件是由於 Gitlab.com 上的 Canary 和主要 Web 應用程式的速度變慢和錯誤頻率增加所引起的。 違反了多個 Apdex 值。
開啟事件任務：
主要發現
以下是我在值班期間學到的一些事情。
1. 警報在偵測到偏離正常情況時最有用。
警報可以分為幾種類型：
- 基於特定閾值的警報，例如「每秒發生 10 個 5xx 錯誤」。
- 閾值是百分比值的警報，例如「給定時間請求總量的每 5% 出現 10xx 錯誤的頻率」。
- 基於歷史平均值的警報，例如「第 5 個百分點出現 90xx 錯誤」。
一般來說，類型 2 和類型 3 對於值班的 SRE 更有用，因為它們揭示了流程中與規範的偏差。
2. 許多警報從未升級為事件。
SR 工程師需要處理源源不絕的警報，其中許多警報實際上並不重要。
那麼為什麼不將您的警報限制為僅真正重要的警報呢？ 然而，透過這種方法，您可能無法識別早期症狀，這些症狀將滾雪球般發展成可能造成重大損害的真正問題。
待命的 SRE 的工作是確定哪些警報實際上表明存在嚴重問題，以及是否需要升級和處理這些警報。 我懷疑這也是由於警報不靈活造成的：如果有多個級別或“智能”方式來根據上述情況配置警報，那就更好了。
功能建議：
3.我們的SRE值班使用了許多工具。
內部的：
- GitLab 基礎設施專案：這裡有運作手冊、輪班/週作業、事件回應任務。
- GitLab 問題：調查、審查和維護也在問題中進行追蹤。
- GitLab 標籤：自動化任務使用特定標籤啟動，機器人使用這些標籤來追蹤任務活動。
外部的：
- PagerDuty：警報
- Slack：PagerDuty/AlertManager 訊息流在此。 與斜線命令整合以執行各種任務，例如關閉警報或升級為事件。
- Grafana：關注長期趨勢的指標視覺化。
- Kibana：提供視覺化/日誌搜索，能夠更深入地挖掘特定事件。
- Zoom：Zoom 中有一個持續運作的「分組討論室」。 這使得 SRE 工程師能夠快速討論事件，而無需浪費寶貴的時間來創建房間和連結參與者。
還有很多很多其他的。
4.用GitLab監控GitLab.com是單點故障
如果 GitLab.com 遇到重大服務中斷，我們不希望它影響我們解決問題的能力。 可以透過啟動第二個 GitLab 實例來管理 GitLab.com 來停止它。 事實上，這已經對我們有用了： .
5. 需要考慮一些添加到 GitLab 的功能
- ，類似於 Google 文件。 這將有助於完成活動期間的事件任務以及報告任務。 在這兩種情況下，多個參與者可能需要即時添加一些內容。
- 更多用於任務的 Webhook。 從內部運行不同的 GitLab 工作流程步驟的能力將有助於減少您對 Slack 整合的依賴。 例如，能夠透過 GitLab 問題中的斜線命令在 PagerDuty 中允許發出警報。
結論
SRE 工程師面臨著許多複雜的困難。 很高興看到更多 GitLab 產品解決這些問題。 我們已經在對產品進行一些補充，以使上述工作流程變得更加容易。 詳情請參閱 .
我們將在 2020 年擴大團隊規模，將所有這些出色的功能整合在一起。 如果有興趣，請查看 ，如有任何疑問，請隨時聯繫我們團隊中的任何人。
來源： www.habr.com