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

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