亞馬遜云科技 《韌性系統(tǒng)生命周期建設框架》白皮書

AmazonPrescriptiveGuidance：韌性系統(tǒng)生命周期建設框架版權所有?2023亞馬遜云科技及/或其附屬公司。保留所有版權。這些所有者可能附屬于亞馬遜云科技、與亞馬遜云科技有關聯(lián)或由亞馬遜云科技贊助，也可能不是如此。目錄引言 1術語和定義 2持續(xù)韌性 3第1階段：設定目標 4確定關鍵應用 4確定用戶故事 4設定衡量指標 5創(chuàng)建額外的衡量指標 5第2階段：設計和實施 7AmazonWell-ArchitectedFramework 7理解依賴關系 7災難恢復策略 8制定持續(xù)集成和持續(xù)交付（CI/CD）策略 8開展運行就緒性檢查 9了解亞馬遜云科技故障隔離邊界 9選擇響應方式 9韌性建模 10故障安全 10第3階段：評估和測試 部署前活動 環(huán)境設計 集成測試 自動化部署管線 12負載測試 12部署后活動 12開展韌性評估 12災難恢復測試 13漂移檢測 13合成測試 13混沌工程 13第4階段：運營 15可觀察性 15事件管理 15持續(xù)韌性 16第5階段：響應和學習 17創(chuàng)建事件分析報告 17實施運營審查 18審查警報性能 18警報精確度 18假陽性 18假陰性 18重復的警報 19實施指標審查 19提供培訓和賦能 19創(chuàng)建事件知識庫 19深入實施韌性 20結論和資源 21撰稿人 22文檔歷史 23韌性系統(tǒng)生命周期建設框架：實現(xiàn)韌性優(yōu)化的持續(xù)方法亞馬遜云科技2023年10月（文檔歷史（23頁））如今，現(xiàn)代公司面臨著越來越多與韌性相關的挑戰(zhàn)，這在客戶日益期望服務“永遠在線、永遠可用”的背景下尤其如此。公司需要構建遠程團隊和復雜的分布式應用，同時也需滿足客戶對新應用程序不斷增長的需求。因此，公司及其應用均需比以往更具韌性。（和瞬態(tài)網(wǎng)絡問題等相關的中斷）或從中斷中恢復的能力（參見《AmazonWell-ArchitectedFramework可靠性支柱文件》中的“韌性和可靠性組件”部分）。然而，為了達到期望的韌性水平，公司通常需要進行權衡，需要對操作復雜性、工程復雜性和成本進行評估和相應調整。在與客戶和內部團隊展開多年合作的基礎上，亞馬遜云科技開發(fā)了一個韌性系統(tǒng)生命周期建設您都可以運用相應的策略、服務和機制來優(yōu)化韌性狀態(tài)。設定目標設定目標運行設計和實施響應和學習評估和測試這些階段將在本指南后續(xù)章節(jié)中予以討論：1階段：設定目標（42階段：設計和實施（7頁）3階段：評估和測試（11頁）4階段：運行（15頁）5階段：響應和學習（17頁）術語和定義每個階段的韌性概念適用于從單個組件到整個系統(tǒng)的不同層面。概念的實施需要明確定義幾個術語：或者甚至服務器、數(shù)據(jù)存儲和多因素身份驗證（MFA）亞馬遜云科技帳戶和地區(qū)的多組件集合。（和災難恢復）；以及管理這些任務的操作人員。中斷是指阻止應用程序正常實現(xiàn)其業(yè)務功能的事件。受損是指如果中斷得不到緩解而將對應用程序產生的影響。如果應用程序遭受一系列中斷，它們可能會因此受損。持續(xù)韌性有所不同，具體取決于應用程序的要求。不過，每個階段越完整，應用程序的韌性也就越大。出現(xiàn)。我們建議您在生命周期的各個階段逐步深化實踐。第1階段：設定目標了解需要什么級別的韌性以及如何進行衡量是目標設定階段的基礎。如果你沒有目標或無法對其進行衡量，那么改進將難以實現(xiàn)。的其他功能，比如貨物空間或燃油效率等等。所以，這種配置是合理權衡的結果。（27頁和415頁））進行觀測和控制，以了解是否達到目標。確定關鍵應用因此公司可以容忍一段故障停機時間，同時也不會對業(yè)務能力產生負面影響。以一家零售公司的訂單管理應用程序為例。如果該訂單管理應用程序的組件受損并且不能正常更加積極的韌性目標，但不會進行大量投資來確保網(wǎng)頁應用的韌性。確定用戶故事或一組應用程序互動時期望獲得的體驗。設定衡量指標和是用來評估既定系統(tǒng)韌性99.99%的請求可得到響應議并不會讓應用程序變得更具韌性。AmazonResilienceHub對應用程序架構進行評估，以便發(fā)現(xiàn)與韌性相關的潛在弱點。AmazonResilienceHub將根據(jù)AmazonWell-ArchitectedFramework最佳實踐來評估應用程序架構，并就需要改進的具體方面給出補救指導，以幫助您實現(xiàn)恢復點目標和恢復時間目標。創(chuàng)建額外的衡量指標40%98%（MTTR）x%建符合業(yè)務需求的目標可幫助您預測應用程序可容忍的故障類型，還可以幫助您確定降低應用程序受損可能性的方法。如果在丟失5%2階段：設計和實施（7）一節(jié)中所描述的不同架構模式。測性在4階段：運行（15頁）一節(jié)中有更詳細的介紹。第2階段：設計和實施實踐。AmazonWell-ArchitectedFrameworkAmazonWell-ArchitectedFrameworkWell-ArchitectedFramework的六大支柱提供以下是AmazonWell-ArchitectedFramework如何幫助您設計和實施符合韌性目標的應用程序的示例：可靠性支柱：可靠性支柱序的重要性。例如，AmazonWell-ArchitectedFramework建議采用微服務架構，使應用找到最佳實踐的詳細描述，通過使用節(jié)流、指數(shù)回退重試、快速故障（減載）定工作、斷路器和靜態(tài)穩(wěn)定性來構建應用程序。全面檢查：AmazonWell-ArchitectedFramework并確定需要改進的地方。風險管理：AmazonWell-ArchitectedFramework害。AmazonWell-ArchitectedFramework強調持續(xù)AmazonWell-ArchitectedFramework理解依賴關系（比如第三方應用程序編程接口和企業(yè)自有的共享服務AmazonX-Ray災難恢復策略（DR）策略的選擇取決于您對應用程序的特定需求、您設定的恢復時間目標和恢復點目標以及您的預AmazonElasticDisasterRecovery有關更多信息，請參見亞馬遜云科技網(wǎng)站上的DisasterRecoveryofWorkloadsonAmazonWebServices和AmazonMulti-RegionFundamentals。制定持續(xù)集成和持續(xù)交付（CI/CD）策略導致應用程序受損的一個常見原因是代碼或其他變更改變了應用程序之前的已知工作狀態(tài)。如（從而提高生產力），同時通過自動化對每項變更進行高級別的檢查。一些基本策略包括：整個流程包括應用程序的構建、測試、部署甚至監(jiān)控。自動化管線有助于降低人為錯誤的可能性，確保一致性，并使流程更加可靠和高效。測試驅動開發(fā)（TDD）：中運行，以便驗證變更。頻繁提交和集成：集成成為可能。不可變基礎設施：是修改基礎設施；利用經(jīng)測試的代碼構建新的基礎設施，并通過管線進行部署。回滾機制：如果出現(xiàn)問題，確保能有一個簡單、可靠且經(jīng)頻繁測試的更改回滾方式。能夠輕輕一按便可以恢復到以前的狀態(tài)，或者也可以完全自動化，警報一響便可啟動。這可以幫助您輕松地跟蹤更改，并在需要時恢復更改。金絲雀部署和藍/藍/綠兩種環(huán)境，這可以幫助您在生產中驗證更改行為，并在必要時快速回滾。被視為是一種失敗的經(jīng)歷，而是一種學習的體驗。開展運營就緒審查運營就緒性審查（ORR）有助于確定運營和和程序上的差距。在亞馬遜云科技，我們確立了運輸入這些故障模式或故障原因。有關更多信息，請參見AmazonWell-ArchitectedFramework網(wǎng)站上的運行就緒檢查（ORRs）。了解亞馬遜云科技故障隔離邊界網(wǎng)站上的AmazonFaultIsolationBoundaries。選擇響應方式根本不對警報做出響應而造成的潛在商業(yè)損失的函數(shù)。器進程，但是實施和維護成本有所不同。注意30因此，他們可能會創(chuàng)建一個自動擴展組，設置一個新的虛擬服務器來恢復應用服務器進程。300應用程序團隊和企業(yè)選擇的響應方式應反映出企業(yè)希望通過前期工程時間的投入來抵消運營開然后做出相應考慮。韌性建模性分析框架為韌性模型的開發(fā)提供指導。該框架可以幫助您預測中斷及其可能對應用程序產生框架——也就是在設計階段預測中斷并在生產部署前后測試應用程序——有助于減少事故發(fā)生；利用韌性分析框架開發(fā)韌性模型也有助于實現(xiàn)韌性目標。安全的故障操作模式。第3階段：評估和測試27頁此結束。在4（15頁）評估和測試階段進一步分為兩個階段，即部署前活動（11頁）和部署后活動（12頁）部署前活動包括在將應用程序部署于任何環(huán)境之前應該完成的各種任務，比如部署軟件的新版節(jié)將對這些階段進行詳細討論。部署前活動環(huán)境設計測試和評估應用程序的環(huán)境會影響測試的徹底程度，也會影響您對測試結果準確反映生產環(huán)境AmazonDynamoDB（DynamoDBDynamoDB）之類您就測試環(huán)境采用分階段或管線方法，模擬生產環(huán)境將出現(xiàn)在管線的后期階段。集成測試集成測試是測試應用程序中定義明確的組件在使用外部依賴項時能否正確執(zhí)行其功能的過程。確性的單元和集成測試。我們建議您針對已實施的韌性模式（比如斷路器模式或減載模式（參見第2階段：設計和實現(xiàn)（第7AmazonFaultInjectionSimulator（AmazonFIS）之類的功能，有意地在測試環(huán)境中制造中斷場景。理想狀態(tài)是，您需將所有的集成測試作為持續(xù)集成/持續(xù)交付管線的一部DevOps請參見亞馬遜云科技網(wǎng)站上的“亞馬遜云科技平臺上DevOps簡介”。自動化部署管線們建議您設置一系列逐步接近生產配置的測試環(huán)境。您可以利用這一系列環(huán)境來反復測試應用添加服務并進行擴展，以更好地反映生產環(huán)境。（請參閱本指南后面的“報警精度”（請參閱本指南前面的“制定持續(xù)集成/略AmazonBuildersLibrary于應用程序的復雜程度及其依賴項的類型。壓力測試預期負載下的響應情況以及在負載超出預期時的行為非常重要。這有助于驗證是否已經(jīng)實施了見AmazonSolutionsLibrary中“亞馬遜云科技平臺上的分布式負載測試“。部署后活動（比如持續(xù)的韌性評估的一些活動。開展韌性評估考慮的因素。AmazonResilienceHub行自動化評估，甚至將它們集成到持續(xù)集成/持續(xù)交付工具中，正如亞馬遜云科技博客文章《AmazonResilienceHub和AmazonCodePipeline》所述。自動化評估是最佳實踐，因為它有助于確保您在生產中持續(xù)評估韌性狀態(tài)。災難恢復測試在2（7頁（DR）4偏差檢測“偏差”AmazonCloudFormationAmazonCloudFormationAmazonControlTower文檔中的“AmazonControlTower中的偏差”。合成測試合成測試“金絲雀（灰色故障通常就是這種情況以提供早期警告?；煦绻こ膛旁诘土髁科陂g，并且隨時可以獲得有效的工程支持。亞馬遜云科技建議您在非生產環(huán)境中開始混沌工程實驗。您可以利用AmazonFaultInjectionSimulator（AmazonFIS）工程實驗。第4階段：運營完成3（11頁運營為這些實踐制定標準和一致性。可觀察性從不同的角度進行檢測，這意味著需要從服務器側和客戶側進行測量-通常使用金雀絲。測量與故障隔離界限相一致的范圍如AmazonCloudWatch復雜性折中。以下鏈接提供了檢測應用程序和創(chuàng)建警報的最佳實踐：監(jiān)控Amazon的生產服務（AmazonWebServicesre:Invent2020演示）AmazonBuilders'Library：Amazon的卓越運營（AmazonWebServicesre:Invent2021演示）Amazon（AmazonWebServicesre:Invent2022演示）對分布式系統(tǒng)進行檢測以實現(xiàn)運營可視性（AmazonBuildersLibrary文章）構建儀表板以實現(xiàn)運營可視性（AmazonBuildersLibrary）事件管理（化的方式審查指標，可實現(xiàn)顯著效益，但需要自上而下的支持和時間投入。以下鏈接提供了關于建立儀表板和運營指標審核的最佳實踐：構建儀表板以實現(xiàn)運營可視性（AmazonBuildersLibrary）Amazon（AmazonWebServicesre:Invent2019演示）持續(xù)韌性在2（7頁和3（11頁運營您應通過AmazonWell-ArchitectedFrameworkreviews、OperationalReadinessReviews(ORRs)、以及韌性分析框架現(xiàn)以前未曾預料到的中斷，并幫助您找到新的化解措施。在預生產環(huán)境中成功運行gameday和混沌工程實驗后，您可能還會考慮在生產環(huán)境中運行這些實驗。gameday用于模擬已知事件，而針對這些事件，您已經(jīng)建立起加以緩解的韌性機制。例如，gameday可能會模擬亞馬遜云科技區(qū)域服務受損并實施多區(qū)域故障轉移。雖然實施這些活動可能需要大量努力，但這兩種實踐都有助于讓您相信您的系統(tǒng)能夠承受您所設計的故障模式。多種機會。第5階段：響應和學習對破壞性事件，這對提高可靠性也至關重要。響應和學習其中還包括幫助您從運營團隊和工程師的經(jīng)驗中提煉出極多知識和教訓的實踐。創(chuàng)建事件分析報告的學習成果，并應在業(yè)務部門間廣泛共享。注在進行事件分析時，至關重要的是不要指責任何一方。要假設所有操作人員都根據(jù)所掌握的信息優(yōu)選非常適合的行動方案。請勿在報告中使用操作人員或工程師的姓名。將人為錯誤當作造成損害的原因，可能會導致團隊成員為了自我保護而心懷戒備，從而導致獲取的信息有誤或不完整。-AmazonCorrectionofError（COE）程序-（通常是來自監(jiān)控儀表板的指標和屏幕截圖導致他們得出結論的信息。該報告還應詳細說明不同指標的性能-們解決問題的速度以及在化解破壞方面的有效程度。可以提高團隊的直覺。詳細事件報告庫還可以成為操作人員的培訓材料來源。團隊可以使用事故報告為桌面或現(xiàn)場gamedayday障排除技能，令其更輕松地預測和排解相關問題。負責應用程序可靠性的中央團隊應將這些報告保存在可供整個企業(yè)查閱的中心庫中。該團隊還現(xiàn)整個業(yè)務中可通過軟件庫、架構模式或團隊流程變更而加以解決的趨勢。實施運營審查如4（15頁這為整個企業(yè)內的工程師提供了學習他人經(jīng)驗和提出問題的機會。向公司內的工程社區(qū)分享運營審查結果，讓他們更多地了解運行業(yè)務的IT應用程序以及可能會遇到的問題類型。在他們?yōu)闃I(yè)務設計、實施和部署其他應用程序時，將也記得這些知識。審查警報性能如運營Ticket確性和有效性進行審查，提高警報精確度，降低假陽性并合并重復的警報。警報精確度（例如恢復程序這些警報，使其盡可能清晰且簡潔。您不可能預料到應用程序可能出現(xiàn)的所有受損情況，因此總會出現(xiàn)一些需要操作人員分析和診數(shù)量。理想情況下，警報與自動或人工響應之間應該是一一對應的關系。假陽性（假陽性改進警報。假陰性出告警的警報可能會失效。在事件分析的過程中，您應該審查本應發(fā)出但實際上并未發(fā)出的警多警報，用于映射由不同的征兆引發(fā)的相同受損情況。重復的警報損害應用程序的破壞可能會引發(fā)多種征兆，并可能導致多個警報。應定期或在事件分析的過程個警報消息。實施指標審查要的時間、確定原因所需要的時間、補救時間以及創(chuàng)建的Ticket、發(fā)送的警報和發(fā)出的呼叫數(shù)（提供培訓和賦能gameday師小組（工程師須通過定期審查而分享見解）的情況下預測故障。創(chuàng)建事件知識庫事件報告是事件分析的標準輸出結果。即使應用程序并未受損，您也應該使用相同或類似的報gameday這些標準化報告存放在中心庫中，供企業(yè)內的所有工