背景 《SRE Google運維解密》里提到SRE自動化系統的一個bug導致幾乎所有的數據中心機器被成功下線併進行硬碟擦除。當然這本書出版之後又業界也進行了很多的演進。在我們團隊現在很難發生這樣的事情。因為團隊內人人要遵循的一個設計原則是：原則上禁止批量操作。如需批量，需要有審核流程。批量設置上限。 ...
背景
《SRE Google運維解密》里提到SRE自動化系統的一個bug導致幾乎所有的數據中心機器被成功下線併進行硬碟擦除。當然這本書出版之後又業界也進行了很多的演進。在我們團隊現在很難發生這樣的事情。因為團隊內人人要遵循的一個設計原則是：原則上禁止批量操作。如需批量，需要有審核流程。批量設置上限。
這個原則在我以後會發佈的系列文章《架構設計「三大紀律八項註意」》中也會介紹一些。今天先從另一個角度系統的看這個問題。
配額管控策略-邏輯管控
我所在的HULK調度系統團隊因為從大的方面將調度系統分成資源和調度兩個方面，所以衍生出來就有物理和邏輯兩個層次。在運用方面可以用一個簡單的例子來解釋：秒殺。
在秒殺場景中，假設實際物品庫存有10件。這是一個物理概念，被別人訂走一個少一個。但是秒殺開始的時候，有100個請求過來，每個人都不知道下一時刻庫存有多少。這時候實時感知物理上有多少庫存來給用戶反饋顯然是不合適的。這時候就衍生出來邏輯的概念。
這個邏輯的庫存可以用一個計數器來實現，或者是漏斗，不重要。關鍵是邏輯庫存要卡住流程，不能讓物理庫存為負數。
在我們HULK調度系統中，涉及到硬體資源，一個策略是為應急場景留下一定配額。對於不同的來源的請求給予不同的配額以避免一個來源方未知問題導致所有的資源耗盡。
總結一下上面提到的策略：物理感知是必要的，但是不能代替邏輯管控。邏輯管控包括：不能讓資源總量低於實際；必要時留有配額；針對不同來源需要不同的配比。
配額管控策略-批量管控
「核心流程都需要是點對點的。保障流程原則上禁止批量操作。如需批量，需要有審核流程。批量設置上限。」這是我們團隊的一個重要的設計原則。
舉個我們團隊的具體應用：是人都是要死的，是機器都是要壞的。機器故障既然不可避免，那就需要進行自動化處理。HULK調度系統這邊有專門的物理機宕機流程。這個流程在設計中做了下麵兩件事情：1是限量，2是限速。
限量：
按照物理機宕機率統計數據來看，一天理論上不可能有100台物理機同時宕機。如果1天中宕機數超過一定配額，則停止自動化宕機處理，併發出異常報警。
限速：
如果1秒中100台機器同時宕機，更可能發生的事情是網路抖動之類的其他現象。而非真宕機，所以此時也會停止自動化宕機處理，併發出異常報警。
總結
與用戶一同工作，以像用戶一樣思考 --《程式員修煉之道》
相關閱讀
