1. 工業機器人

1.1. 具有多層防護措施，防止對人員、機器和設施造成損害

1.2. 防護措施能限制機器人的動作和感測器的感知

1.3. 機械臂的旋轉範圍會遠遠小於它可以達到的全部運動範圍

2. 自動化

2.1. 它更像是工業機器人

2.1.1. 掌握控制層感知系統的當前狀態

2.1.2. 將其與期望的狀態進行對比

2.1.3. 對系統施加影響，使當前狀態進入到期望狀態

2.2. 自動化系統並未簡單地按照人類管理員的意願行事

2.2.1. 自動化平臺與管理員關於系統預期狀態的不同“信念”的衝突，引發了2016年8月11日鏈接聚合網站Reddit遭遇停機事故

2.2.2. 刻意的手動更改與自動化平臺之間的衝突

2.3. 自動化使得管理員能夠花費較少的努力進行大量的操作，這就是一個力量倍增器

2.4. 自動化系統面對兩套相互衝突的指令時，也會卡殼

2.5. 由自動化所引發的操作，需要花時間才能完成

2.5.1. 這段時間通常會比監控的時間間隔要長，因此請務必考慮到系統需要經過一些延遲後，才能對操作做出響應

3. 控制層

3.1. 控制層中的軟體主要管理基礎設施和應用程式，而不是直接交付用戶功能

3.1.1. 日誌記錄

3.1.2. 監控

3.1.3. 調度程式

3.1.4. 擴展控制器

3.1.5. 負載均衡器

3.1.6. 配置管理

3.2. 基礎設施管理工具可以迅速對系統產生巨大的影響，要在其內部構建限制器和防護措施，防止其快速毀掉整個系統

3.3. 控制層軟體中實現類似工業機器人的防護措施

3.3.1. 如果軟體觀測器顯示系統中80%以上的部分不可用，那麼與系統出問題相比，軟體觀測器出問題的可能性更大

3.3.1.1. 被隔離的節點無法正確地感知當前狀態

3.3.1.2. 控制系統會感知環境，但它們有可能被愚弄

3.3.2. 運用滯後原則

3.3.2.1. 快速啟動機器

3.3.2.2. 要慢慢關機

3.3.2.3. 啟動新機器要比關閉舊機器更安全

3.3.3. 當期望狀態與觀測狀態之間的差距很大時，要發出確認信號，這相當於工業機器人上的大型黃色旋轉警示燈在報警

3.3.4. 那些消耗資源的系統應該設計成有狀態的，從而檢測它們是否正在試圖啟動無限多個實例

3.3.5. 構建減速區域，緩解勢能

3.3.5.1. 控制層雖然每秒都能感知到系統已經過載，但它啟動一臺虛擬機處理負載需要花費5分鐘

3.3.5.2. 大量負載依然存在的情況下，要確保控制層不會在5分鐘內啟動300個虛擬機

4. 緩慢的響應

4.1. 通常由過度的需求引起

4.2. 爭著使用已經供不應求的資料庫連接，會使響應變慢，進而加劇這種爭用，導致惡性迴圈

4.3. 記憶體泄漏經常表現為響應緩慢

4.3.1. 記憶體泄漏會導致垃圾收集器過度運行，從而引發響應緩慢

4.4. 低層級的低效協議會導致網路停頓，從而導致響應緩慢

4.5. 對網站來說，響應緩慢會招致更多的流量

4.5.1. 那些等待頁面響應的用戶，會頻繁地單擊重新載入按鈕，為已經過載的系統施加更多的流量

4.6. 緩慢的響應會將調用系統和被調用系統中的資源拖得動彈不得

4.6.1. 生成響應較慢比拒絕連接或返回錯誤更糟

4.7. 緩慢的響應傾向於逐層向上傳播，並逐漸導致層疊失效

4.7.1. 一旦陷入響應緩慢，上游系統本身的處理速度也會隨之變慢，並且當響應時間超過其自身的超時時間時，會很容易引發穩定性問題

4.8. 快速返回系統失效信息，能使調用方的系統快速完成事務處理，最終成功或是系統失效，取決於應用程式的邏輯

4.9. 讓系統具備監控自身性能的能力，就能辨別其何時違背SLA

4.9.1. 系統能跟蹤自己的響應情況，那麼就可以知道自己何時變慢

4.9.2. 系統平均響應時間超出系統所允許的時間時，可以考慮發送一個即時錯誤響應

4.9.3. 當平均響應時間超過調用方的超時時間時，應該發送這樣的響應