

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 將投資報酬率轉換為混沌工程作為策略必要性
<a name="strategic-necessity"></a>

雖然監控投資報酬率很吸引人，但衡量混沌工程價值的挑戰通常會導致組織優先考慮立即的短期效率，而不是策略彈性投資。這種方法忽略了混沌工程作為恢復能力的關鍵驅動因素，以及避免中斷的競爭優勢。混沌工程的真實價值是防止未來的故障。Chaos 工程支援長期業務持續性。

與其專注於投資報酬率，而是將混沌工程視為網路安全。如 *Forbes* [文章網路安全作為策略投資中所說明：ROI 最佳化如何導致更安全的未來](https://www.forbes.com/councils/forbestechcouncil/2023/08/16/cybersecurity-as-a-strategic-investment-how-roi-optimization-can-lead-to-a-more-secure-future/)，網路安全不應被視為組織的成本中心或強制性費用，因為這種思維無法識別強大的網路安全措施可以隨著時間提供的策略價值。相反地，作者認為透過轉移觀點將網路安全視為可推動競爭優勢的長期投資，組織可以在其各自市場中釋放創新、營運效率和差異性的新途徑。透過採用這種方法，作者得出的結論是，資訊安全長 (CISOs) 可以更好地保護領導層的接受和資金。然後，他們可以將公司定位在風險越來越高的網路環境中超越競爭對手。這種長期的網路安全策略價值建立與混沌工程實務中固有的持續改善平行。

雖然安全保護組織操作和保護資產的能力，但混沌工程有助於確保核心系統和服務的可用性、可靠性和可復原性。為了實現長期價值和競爭優勢，請將混沌工程視為核心功能和策略必要性，而不是需要持續理由的倡議。

下圖顯示混沌工程從草根演變到目標和投資報酬率，成為策略。



![從基層努力、目標、投資報酬率到必要策略的演變。](https://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-chaos-engineering-journey/images/chaos-engineering-evolution.png)


在基層，個別團隊通常會根據當地需求獨立實驗。這些實驗由熱衷的工程師擁護，他們透過減少事件並改善可觀測性來展現價值。

當這些工作成功時，團隊可以將其學習提升為領導力。透過這種可見性，努力會轉換為目標驅動的階段。組織設定恢復能力和復原的正式目標，以資源和對更廣泛的實作的支援為後盾。

最後，混沌工程不僅需要持續的 ROI 理由才能被視為策略必要性，類似於網路安全。在這個階段，混沌工程會完全整合到組織程序中。實作著重於長期彈性，而非短期指標。混沌工程被視為維持競爭優勢和客戶信任的重要核心功能。

## 將混沌工程整合至您的組織
<a name="integration"></a>

若要將混沌工程提升到與安全性相同的重要性層級，請考慮下列建議：
+ **將混沌工程建立為不可協商的實務** ‒ 就像網路安全被視為組織的基本需求一樣，將混沌工程視為確保系統彈性和可靠性的強制性實務。將混沌工程整合到組織的程序、工具和文化中，而不是將其視為選擇性或選擇性活動。如需詳細資訊，請參閱[彈性生命週期架構](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-lifecycle-framework/introduction.html)指南。
+ **安全執行層級的接受和支援** ‒ 與安全計畫一樣，混沌工程工作必須獲得執行領導層的接受和積極支援。這包括配置專用資源、預算和人員，以在整個組織中實作和維持混沌工程實務。
+ **實作控管和監督** ‒ 與 CISO 和安全控管架構類似，請建立專用的混沌工程團隊或首席應變長。此團隊或角色負責監督和協調不同團隊和業務單位的混沌工程工作。
+ **將混沌工程整合到開發和操作週期**中 ‒ 就像安全實務整合到軟體開發和部署程序中一樣，讓混沌工程成為軟體開發和交付生命週期的無縫部分。
+ **定期執行混沌工程演練和模擬 –** 類似於安全漏洞模擬和事件回應演練，定期執行混沌工程實驗，以驗證事件回應功能並主動識別潛在的盲點。
+ **使用混沌工程來維護 Runbook** ‒ 如同執行安全性審查一樣，使用混沌工程實驗來驗證 Runbook 的有效性和準確性，以回應事件和復原。此外，混沌工程實驗可作為逼真的模擬，讓待命工程師練習執行 Runbook 程序。模擬可協助工程師維護其操作肌肉記憶體，以及處理真實世界事件的準備程度。
+ **培養彈性文化** ‒ 如同安全意識訓練一樣，投資於混沌工程教育和知識分享計畫，以培養彈性文化。包括訓練計畫、跨職能協同合作，以及針對採用混沌工程實務之團隊的獎勵。
+ **測量和報告彈性指標** ‒ 定期監控彈性指標，並向利益相關者報告。使用本文件中討論的量化和定性指標作為起點。
+ **將彈性視為競爭優勢** ‒ 網路安全措施可提供競爭優勢。同樣地，請將您的混沌工程和彈性功能視為差異化因素，以協助您為客戶提供更可靠且值得信賴的服務。

## 取得高階主管的支持
<a name="executive-buy-in"></a>

混沌工程通常缺乏 C-suite 傳統責任中的明確擁有者。CEO 關心成長、獲利能力和市場領導力。CFO 專注於財務績效、成本控制和風險管理。CTO 優先考慮技術策略、產品藍圖和卓越工程。CISO 會監督安全與合規。

如果沒有真正擁有彈性的單一主管，通常很難獲得接受和支援。不過，系統故障會影響營收、客戶滿意度和品牌評價，這是 CEO 和 CFO 的考量。CTO 和 CISO 的任務是實作彈性措施，但他們可能缺少組織要求。這種模棱兩可的情況可能會阻礙進行策略投資，並使組織符合常見的彈性策略。

這種模棱兩可的情況也讓獲得高管接受彈性計畫，例如混沌工程，變得具有挑戰性。畢竟，C 級領導者正在處理許多策略優先順序：成長、創新、客戶體驗、合規等。

若要有效地將混沌工程的價值傳達給 C 級主管，請考慮下列方法：
+ **判斷高階主管的主要考量和決策驅動因素。**

  例如，高階主管是否擔心客戶流失、法規遵循、成本降低或競爭壓力？ 將混沌工程定位為力乘數，以符合公司的獨特挑戰和目標。
+ **識別共同目標和策略成果。**

  您的混沌工程策略如何支援整個組織的成長策略、客戶體驗、市場機會和營運效率？ 根據目標、業務影響、投資報酬率和不執行措施的風險來排定措施的優先順序。
+ **使用關鍵彈性指標，以可量化的詞彙傳達混沌工程策略的有效性。**

  從這四個關鍵彈性指標開始：可用性、偵測時間、回應時間和復原時間。將這些直接連結到業務成果，例如營收、成本節省和品牌評價。
+ **請勿在技術詳細資訊中遺失。**

  專注於整體情緒和可衡量的業務影響。C-suite 關心推動成長、增強客戶信任和促進創新的結果。

## 預防矛盾
<a name="prevention-paradox"></a>

當故障在資訊清單之前成功緩解時，說服利益相關者了解所採取預防措施的價值和必要性會變得具有挑戰性。此現象稱為*預防矛盾*。預防矛盾是將混沌工程整合為策略必要性的最大障礙，源自於人類認知中的固有偏差。

Y2K 錯誤可做為此矛盾的絕佳說明。數年的準備和數十億美元投入於更新全球的電腦系統。不過，許多 已將順利轉換為 2000 年，作為 Y2K 問題過度膨脹本質的證明。很少發現預防性工作的成功。

這種預防矛盾繼續挑戰現今投資於混沌工程的組織。當透過主動措施成功避免潛在的中斷時，完全沒有災難可能會使用於預防的資源難以合理化。

此現象的根本原因在於我們思維處理資訊的方式。人類認知程序旨在回應和記住實際事件和可見結果。防止災難時，沒有可保留或共用的戲劇性敘述。預防矛盾的另一個層面是後視偏差。發生意外之後，個人傾向於做出沒有發生什麼事的結論，因此這不是真正的問題。無法識別適當的預防措施防止實際問題的可能性。這個心理盲點為組織帶來了永久的挑戰。您越成功預防和恢復能力，在回顧方面，您的工作就越不必要。

為了解決預防矛盾問題，您的組織可以採取特定步驟，讓預防的隱形工作可見、可測量且受到重視。可能的步驟包括下列項目：
+ 記錄並模擬在沒有預防措施的情況下可能發生的情況。
+ 分享預防性措施避免潛在災難的事件案例。
+ 指向未準備且因此遭受後果的對等組織。
+ 在潛在影響的情況下呈現預防成本。
+ 將預防工作細分為可見的里程碑和成就。
+ 建立機構記憶體，了解預防措施的存在原因及其歷史重要性。
+ 定期教育利益相關者有關彈性和混沌工程實務的價值。