amazon 用雲伺服器可以嗎（每個公司都有on-call）

2023-04-23 19:56:28 2

amazon 用雲伺服器可以嗎?對於每個程式設計師來說，進入市值萬億的Amazon工作，似乎都是一件值得驕傲的事，但只要在網絡上一提起Amazon，關於它的on call 機制的吐槽就會此起彼伏要知道在國內網際網路公司，on call應該是非常普遍的現象，但為什麼大家對Amazon的on call文化如此反感呢？，我來為大家科普一下關於amazon 用雲伺服器可以嗎?以下內容希望對你有幫助!

amazon 用雲伺服器可以嗎

對於每個程式設計師來說，進入市值萬億的Amazon工作，似乎都是一件值得驕傲的事，但只要在網絡上一提起Amazon，關於它的on call 機制的吐槽就會此起彼伏！要知道在國內網際網路公司，on call應該是非常普遍的現象，但為什麼大家對Amazon的on call文化如此反感呢？

Amazon的on call真的不一般

別的公司on call 可能只有少部分部門參與，但是Amazon的範圍很廣，基本上90%的組都要on call，甚至可以說只要在Amazon做技術基本都有過on call的經歷。

其次是時間長，基本是每隔x周就要接受一周的on call，x等於團隊人數。而且每天需要24小時處於待命狀態！也就是說7*24小時的on call！看到這裡相信很多技術小哥哥的雙腿已經開始顫抖了，別急，後面還有更厲害的！

亞馬遜把故障分成幾個等級，當遇到 sev-2 級別的問題，負責人要在收到告警簡訊15分鐘內處理問題，否則就會收到經理的電話。

如果是白天告警，15分鐘內處理其實難度不大，但Amazon是一個全球公司，業務分布在各個時區，所以夜裡出現問題的機率就很大了！當夜裡收到告警簡訊，負責人就要馬上醒來處理問題，最坑的是業務方會不斷詢問進度，如果解決的不是很好，還是會通知經理！

高強度on call的情況下，大家會有很大壓力，要是幾次沒處理好估計就要做好跑路的準備了，這種情況下被吐槽是難免的！

如何建設好的on call機制？

Amazon的on call機制是其「客戶至上「文化的有力實踐，但其對內部員工來說強度過高。事實上，太多公司的on call機制讓團隊成員感到焦慮痛苦了。那麼從運維的角度來看，該如何建立一個好的on call 機制呢？我們總結了以下四點：

一、建立on call機制的時間要越早越好

一般來說on call是在監控之後的環節，但其實在做監控之前我們就應該做好on call機制，因為故障問題的反饋渠道不只有監控系統，還有用戶反饋、團隊成員告知等。

在企業初創期，網站出現故障，第一個知道的往往是用戶。監控只是給我們一種從數據發現問題的視角，並不能保障準確，而用戶則是故障的直接體驗者。

而且，監控可以不斷優化，故障則隨時會發生，優先恢復業務是最高優先級。好的on call機制既能保障業務，還能把數據反饋給監控，進一步優化監控體系。

二、建設故障處理sop

谷歌SRE應急時間處理策略的一條是：由萬能工程師解決生產問題，向手持《運維手冊》的經過演練的on-call工程師演進，其核心思路是建設故障處理SOP，保證SRE可以處理大多數故障。

運維手冊就是故障處理sop，由經驗豐富的運維工程師總結撰寫各種故障的處理方式，可以讓on call成員通過看sop，快速了解問題，保障能有效處理大部分故障。

三、建立職責清晰、多層次的支撐團隊

發生故障時如果是一個混亂無序的團隊去處理，溝通成本就非常高了，效率肯定也會大打折扣。對於網際網路公司來說，故障處理的時間是至關重要的，而要想迅速有效的處理故障，就要搭建一個職責清晰、多層次的支撐團隊。

根據團隊和項目的情況，可以建立一線、二線、三線支撐團隊：

一線通常是7*24小時的值班運維同學，可以根據團隊成員進行排班，降低成員壓力。

二線通常是資深工程師，或者是對應的應用開發／測試同學。在故障處理的時候經常被忽視的一點是，通常第一時間響應的是運維，業務開發關鍵人無法響應，但業務開發其實是對相關業務最了解的人。

三線一般是主管或者是外部的廠家，如涉及硬體、IDC機房等相關服務方。故障問題很多時候都和硬體或者伺服器、系統有關，而外部廠商是最了解產品的人，與他們合作可以解決不少的問題。

有了多層次的支撐團隊，我們還要有相應的升級策略。出現故障時，不是這三線團隊都一起處理，也不是所有問題都是一線團隊處理，這兩種極端思路都不可取。合理的思路是讓資源利用最大化，核心是給運維授權，當一線運維發現無法解決問題時，可以升級問題給二線、三線團隊，甚至公司cto。

四、合理使用運維工具

on call離不開監控和告警，再好的流程機制無法有效執行也是空談，而好的工具可以有效的把機制落地，讓on call有跡可循，國外的有pagerduty、國內的睿象雲智能告警平臺都做的不錯。這些工具解決了on call 機制的幾個問題：

1、不管是大公司還是小公司，都可能會使用多個監控工具。故障出現時可能會發出大量的告警簡訊，而這些告警沒有去重就會產生告警風暴，還難以進行精準的分派到匹配的人員手中，無法在大量的告警中快速的定位問題，又會加大告警處理的難度，形成一個惡性循環。

一個比較好的方法就是告警匯集，比如把Zabbix、Nagios、Promethues等多種工具告警源接入匯集到一個平臺，然後可以對這些告警分析去重，分析告警相關性，幫助故障處理，還可以集中處理監控。

2、支撐團隊的團隊排班和升級策略環節，如果用excel或者就是群裡通知效果很差，用工具可以很好實現。類似日程安排的排班管理功能，可以快速落地告警響應機制，精準分派相關人員。靈活的通知規則，可以保障告警觸達，比如先郵件通知，若5分鐘沒響應就簡訊通知，若10分鐘還是沒響應就電話通知，可以保障重要告警不再遺漏！

3、告警方式除了電話、簡訊和郵件，國內使用微信、釘釘更多一點，而監控工具自帶的告警對國產im軟體的支持有限。國內的平臺支持渠道更豐富，包括微信、釘釘、平臺原生 App 端等都支持。

4、然後是告警的去重降噪，一成不變的人工設定的告警規則無法適應一直在變的業務。要想做好好告警的去重降噪，比較好的就是結合運維大數據和人工智慧，實現人工智慧分析把相同事件自動去重，還可以自定義壓縮規則，按規則合併或壓縮相似告警信息。

總之流程機制是軟的，要靠人去推動執行有諸多不便，而把機制落地到軟體，執行推動效果更好，機器還省去了很多重複工作，更簡單高效。如果我們做好了以上幾點，相信運維團隊會有一個不錯的進步，能更好地做好故障處理。

我是睿象雲智能告警平臺，專注人工智慧提升運維效率！碼字不易，歡迎大家關注點讚收藏轉發～