架構層面的新問題架構師需要認識到控制平面不再是一個能默認在所有情況下都保持穩(wěn)定的無形層。因其屬于故障域一部分所以現在也是架構問題一部分。若工作負載、擴展邏輯等依賴該層正常運行控制平面故障影響遠超單個應用或區(qū)域部署。許多組織僅因具備冗余機制就自認為有彈性實則不夠控制平面以下冗余無法完全抵御上方故障影響即便底層設施正常也可能無法做必要調整確保關鍵系統運行這是架構盲點此類事件曝光后愈發(fā)明顯。多區(qū)域設計并不夠常見看法是多區(qū)域架構是解決方案但它只是部分答案。若兩區(qū)域依賴同一提供商控制機制等就存在共享依賴可能成常見故障點。架構師需更嚴謹地理隔離不等同運營獨立能應對本地基礎設施問題的設計未必能承受管理層中斷。即便能在區(qū)域間復制數據若編排依賴受損控制平面設計仍可能失敗。應敦促架構師跳出常規(guī)思維思考提供商管理平面不穩(wěn)定時恢復假設是否有效這問題難答且很多情況答案不樂觀。假設控制能力下降多數故障轉移計劃假設危機時環(huán)境可管理如儀表盤可用等。正常運營沒問題但控制平面出問題就危險。曾與團隊合作其災難恢復計劃評審出色實際壓力下卻失敗因恢復邏輯依賴受影響平臺這種情況比很多組織承認的更普遍他們將文檔、自動化、配置復雜性分別等同于彈性、獨立性、架構成熟度。要制定可行故障轉移策略需為控制能力下降做規(guī)劃如預設恢復路徑等還要測試無法依賴提供商管理層的場景否則無法了解恢復能力。是否應該采用多云策略不主張每個組織急于用多云策略很多情況會增加成本和復雜性卻無足夠價值。但應將對單一提供商管理層的依賴視為戰(zhàn)略風險而非僅實施細節(jié)。若可觀測性等與某提供商管理模式緊密相連要清楚影響可能承擔遠超預期風險不一定要放棄該提供商通常要設計得更獨立、有更強外部可見性對故障做更現實假設。架構師多年優(yōu)化速度等現在要在控制、彈性和恢復現實性間重新平衡這是云架構走向成熟標志。超越平臺的彈性過去認為在大型云平臺正確部署平臺會解決大部分復雜性問題現在很多方面依然如此大型提供商有卓越工程和運營能力。但仍需針對基礎設施層之上的共享依賴設計?？刂破矫婀收咸嵝盐覀冊瓶煽啃圆恢谷Q于工作負載運行位置更在于協調管理它們的因素當協調層不可靠時的選擇很關鍵這促使架構師重新思考彈性?？偨Y來說不要假設管理層不在故障規(guī)劃范圍內它是關鍵明白這點多區(qū)域設計等方面方法會朝正確方向改變。云架構從紙面上看可能具備高彈性但當云服務提供商的管理層受故障影響時仍可能嚴重失敗。不久前與一家自認為部署到位的企業(yè)合作該企業(yè)分散工作負載、復制關鍵數據存儲等看似成熟云部署但其核心云服務提供商出現控制平面問題管理層不穩(wěn)定團隊無法及時操作和信任環(huán)境狀態(tài)失敗的是云控制機制可靠的設想。這揭示云可靠性受重新審視更多故障由控制平面故障導致Uptime Institute報告強調此轉變值得架構師關注管理層問題影響范圍超預期。多年來行業(yè)從基礎設施角度討論彈性但云是圍繞多種系統構建的運營模式高階控制結構故障會使恢復計劃瓦解。