# 卓越營運 **Topics** + [組織](a-organization.md) + [準備](a-prepare.md) + [營運](a-operate.md) + [演進](a-evolve.md) # 組織 **Topics** + [OPS 1  如何決定您的優先事項？](w2aac19b5b5b5.md) + [OPS 2  如何建構組織以支援業務成果？](w2aac19b5b5b7.md) + [OPS 3  您的組織文化如何支援您的業務成果？](w2aac19b5b5b9.md) # OPS 1  如何決定您的優先事項？ 每個人都必須了解自己在實現商業價值過程中的角色。擁有共同目標以設定資源優先順序。這會充分發揮您所做努力的優勢。 **Topics** + [OPS01-BP01 評估外部客戶需求](ops_priorities_ext_cust_needs.md) + [OPS01-BP02 評估內部客戶需求](ops_priorities_int_cust_needs.md) + [OPS01-BP03 評估管控要求](ops_priorities_governance_reqs.md) + [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) + [OPS01-BP05 評估威脅態勢](ops_priorities_eval_threat_landscape.md) + [OPS01-BP06 評估權衡](ops_priorities_eval_tradeoffs.md) + [OPS01-BP07 管理收益和風險](ops_priorities_manage_risk_benefit.md) # OPS01-BP01 評估外部客戶需求 讓關鍵利害關係人 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些外部客戶需求上。這將確保您對實現想要的業務成果所需的營運支援有透徹的了解。 **常用的反模式：** + 您已決定不在核心上班時間以外的時間提供客戶支援，但尚未檢閱歷史支援請求資料。您不知道這是否會影響您的客戶。 + 您正在開發新功能，但尚未與客戶互動，以了解是否需要該功能，若需要又應以何種形式提供，而且未進行試驗以驗證交付的需求和方法。 **建立此最佳實務的優勢：** 需求獲得滿足的客戶更有可能持續回購。評估和了解外部客戶的需求，將讓您了解如何安排工作的優先順序來實現商業價值。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 了解業務需求：只有業務、開發及營運團隊等利害關係人擁有共同的目標並達成共識，方能讓業務取得成功。 + 審查外部客戶的業務目標、需求和優先事項：與關鍵利害關係人 (包括業務、開發和營運團隊) 進行互動，以討論外部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。 + 建立共識：在以下方面建立共識：工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。 ## 資源 **相關文件：** + [AWS Well-Architected Framework 概念 – 反饋迴圈](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) # OPS01-BP02 評估內部客戶需求 讓關鍵利害關係人 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些內部客戶需求上。這將確保您對實現業務成果所需的營運支援有透徹的了解。 利用您制定的優先事項，聚焦於改善作業，因為它們能發揮最大的影響力 (例如，發展團隊技能、改善工作負載效能、降低成本、自動化執行手冊或提升監控力)。根據需求變更更新您的優先順序。 **常用的反模式：** + 您已決定在不向產品團隊諮詢的情況下，變更他們的 IP 地址配置，以便更輕鬆地管理網路。您不知道這會對您的產品團隊造成什麼影響。 + 您正在實作新的開發工具，但尚未與內部客戶互動，以了解是否需要該工具或其是否與現有的實務相容。 + 您正在實作新的監控系統，但尚未聯絡內部客戶，以了解他們是否有應該考慮的監控或報告需求。 **建立此最佳實務的優勢：** 評估和了解內部客戶的需求，將讓您了解如何安排工作的優先順序來實現商業價值。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 了解業務需求：只有業務、開發及營運團隊等利害關係人擁有共同的目標並達成共識，方能讓業務取得成功。 + 審查內部客戶的業務目標、需求和優先事項：與關鍵利害關係人 (包括業務、開發和營運團隊) 進行互動，以討論內部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。 + 建立共識：在以下方面建立共識：工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。 ## 資源 **相關文件：** + [AWS Well-Architected Framework 概念 – 反饋迴圈](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) # OPS01-BP03 評估管控要求 確保您了解由貴組織所定義的、可能要求或強調特定重點的準則或義務。評估內部因素，例如組織政策、標準和要求。確認您設有確定管控變更的機制。如果未確定管控要求，請確保您已對此決定進行盡職調查。 **常用的反模式：** + 您正在接受稽核，並經要求需提供內部管控的合規證明。您從未評估合規要求，因此您不知道自己是否合規。 + 您已遭受導致經濟損失的洩露。您發現，可能涵蓋經濟損失的保險取決於您是否實作了特定安全控制措施，而您的管控要求實作這些控制措施，但其尚未落實到位。 + 您的管理帳戶遭到入侵，導致公司網站遭到破壞，並使得客戶信任受損。您的內部管控要求使用多重因素驗證 (MFA) 來保護管理帳戶的安全。您未使用 MFA 保護管理帳戶的安全，可能受到處罰。 **建立此最佳實務的優勢：** 評估和了解組織套用到工作負載的管控要求，將可讓您了解如何安排工作的優先順序來實現商業價值。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 了解管控要求：評估內部管控因素，例如，計畫或組織政策、計畫政策、問題或系統特定政策、標準、程序、基準和準則。確認您設有確定管控變更的機制。如果未確定管控要求，請確保您已對此決定進行盡職調查。 ## 資源 **相關文件：** + [AWS 雲端 合規](https://aws.amazon.com/compliance/) # OPS01-BP04 評估合規要求 評估外部因素，例如合規要求和產業標準，以確保您了解可能要求或強調特定重點的準則或義務。如果未確定合規要求，請確保對此決定進行盡職調查。 **常用的反模式：** + 您正在接受稽核，並經要求需提供產業規範的合規證明。您從未評估合規要求，因此您不知道自己是否合規。 + 您的管理帳戶遭到入侵，導致客戶資料遭到下載，並使客戶信任受損。您的產業最佳實務要求使用 MFA 來保護管理帳戶的安全。您未使用 MFA 保護管理帳戶的安全，可能受到客戶訴訟。 **建立此最佳實務的優勢：** 評估和了解套用到工作負載的合規要求，可讓您了解如何安排工作的優先順序來實現商業價值。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 了解合規要求：評估外部因素，例如合規要求和產業標準，以確保您了解可能要求或強調特定重點的準則或義務。如果未確定合規要求，請確保已對此決定進行盡職調查。 + 了解法規合規要求：確定您在法律上有義務滿足的法規合規要求。根據這些要求來找到工作重點。範例包括隱私權和資料保護法規定的義務。 + [AWS 合規](https://aws.amazon.com/compliance/) + [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) + [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) + 了解產業標準和最佳實務：識別適用於工作負載的產業標準和最佳實務要求，例如，支付卡產業資料安全標準 (PCI DSS)。根據這些要求來找到工作重點。 + [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) + 了解內部合規要求：確定您的組織建立的合規要求和最佳實務。根據這些要求來找到工作重點。範例包括資訊安全政策和資料分類標準。 ## 資源 **相關文件：** + [AWS 雲端 合規](https://aws.amazon.com/compliance/) + [AWS 合規](https://aws.amazon.com/compliance/) + [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) + [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) # OPS01-BP05 評估威脅態勢 評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，並將最新的資訊保存在風險登記表內。決定工作重點的領域時，加入風險影響。 AWS Well-Architected 架構 [強調](https://aws.amazon.com/architecture/well-architected/) 學習、衡量和改善。它為您提供可評估架構並實作將隨時間擴展之設計的一致方法。AWS 提供 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) ，以協助您在部署前檢閱方法、在生產前檢閱工作負載狀態，以及檢閱生產中的工作負載狀態。您可以將它們與最新的 AWS 架構最佳實務做比較、監控工作負載的整體狀態，以及深入了解潛在風險。 AWS 客戶還有資格獲得對其關鍵任務工作負載的指導式 Well-Architected 審查， [進而依循 AWS 最佳實務](https://aws.amazon.com/premiumsupport/programs/) 衡量其架構。企業支援客戶有資格進行 [營運審查](https://aws.amazon.com/premiumsupport/programs/)，該審查旨在助其識別在雲端營運的方法的差距。 這些審查的跨團隊參與有助於建立對您的工作負載以及團隊角色可如何助力成功的共識。透過審查識別的需求可以助您確定優先順序。 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 是一款可存取核心檢查集的工具，這些檢查提出了優化建議，可能有助您確定優先事項。 [商業和企業支援客戶](https://aws.amazon.com/premiumsupport/plans/) 可存取針對安全性、可靠性、效能和成本優化的其他檢查，從而進一步協助確定他們的優先事項。 **常用的反模式：** + 您在產品中使用舊版的軟體程式庫。您不知道，程式庫的安全性更新是否存在可能對工作負載產生意外影響的問題。 + 您的競爭對手剛發佈的產品版本，可解決客戶對您產品的許多抱怨。您尚未排定處理這些已知問題之事項的優先順序。 + 監管機構一直在追尋像您這樣不符合法律法規合規要求的公司。您尚未排定處理任何未解決合規要求之事項的優先順序。 **建立此最佳實務的優勢：** 識別和了解組織和工作負載所面臨的威脅，讓您可以判斷要解決哪些威脅、它們的優先順序，以及執行此作業所需的資源。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 評估威脅態勢：評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，以便您在決定工作重點時考量其影響。 + [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) + 維護威脅模型：建立和維護用於識別潛在威脅、已規劃和就地緩解措施及其優先順序的威脅模型。審查顯示為事件的威脅的機率、從這些事件中復原的成本、導致的預期傷害，以及防止這些事件的成本。當威脅模型的內容變更時，修改優先順序。 ## 資源 **相關文件：** + [AWS 雲端 合規](https://aws.amazon.com/compliance/) + [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) # OPS01-BP06 評估權衡 評估在相互衝突的利益或替代方法之間做出權衡的影響，以幫助您在確定工作重點或選擇行動方案時做出明智的決定。例如，新功能加速上市可能是成本優化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以便更輕鬆地遷移系統，而非遷移至針對您的資料類型優化的資料庫並更新您的應用程式。 AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。您應使用 [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)， [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa)和 [AWS 支援中心](https://console.aws.amazon.com/support/home/)) 和 [AWS 文件](https://docs.aws.amazon.com/) 資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 AWS 也分享了我們透過 [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/)營運 AWS 所學到的最佳實務和模式。您可透過 [AWS 部落格](https://aws.amazon.com/blogs/) 和 [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 **常用的反模式：** + 您使用關聯式資料庫來管理時間序列和非關聯式資料。有針對支援您使用的資料類型進行最佳化的資料庫選項，但您並不了解其優點，因為您尚未評估解決方案之間的權衡。 + 您的投資者要求您證明支付卡產業資料安全標準 (PCI DSS) 的合規性。您沒有考量滿足要求和繼續您目前開發工作之間的權衡取捨。相反地，您繼續開發工作，而不證明合規性。由於對平台安全性及其投資的擔憂，您的投資者會停止對公司的支援。 **建立此最佳實務的優勢：** 了解您所選擇的影響和後果，讓您可以排定選項的優先順序。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 評估權衡：評估在相互衝突的利益之間做出權衡的影響，以幫助您在確定工作重點時做出明智的決定。例如，相比成本優化更強調新功能加速上市。 + AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。您應使用 AWS 支援 (AWS 知識中心、AWS 論壇和 AWS 支援 中心) 和 AWS 文件中的資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 + AWS 也分享了我們透過在 Amazon Builders' Library 中營運 AWS 所學到的最佳實務和模式。您可透過 AWS 部落格和官方 AWS 播客獲得其他各種實用資訊。 ## 資源 **相關文件：** + [AWS 部落格](https://aws.amazon.com/blogs/) + [AWS 雲端 合規](https://aws.amazon.com/compliance/) + [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa) + [AWS 文件](https://docs.aws.amazon.com/) + [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/) + [AWS 支援](https://aws.amazon.com/premiumsupport/) + [AWS 支援中心](https://console.aws.amazon.com/support/home/) + [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) + [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/) # OPS01-BP07 管理收益和風險 管理收益和風險，以便在確定工作重點時做出明智的決定。例如，部署具有未解決問題的工作負載可能有益，以便可以為客戶提供重要的新功能。相關風險可能得以減輕，也可能出現無法接受風險存在的事實，在此情況下，您將需要採取動作來解決風險。 您可能會發現，您在某個時間點會想要強調一小部分的優先事項。長期利用平衡的方法，以確保開發所需的功能和管理風險。根據需求變更更新您的優先順序 **常用的反模式：** + 您已決定包含一個程式庫，該程式庫會執行其中一個開發人員在網際網路上找到的您所需的任何項目。您尚未評估從未知來源採用此程式庫的風險，並且不知道它是否包含弱點或惡意程式碼。 + 您已決定開發和部署新功能，而不是修正現有問題。在部署功能之前，您一直未評估將問題置之不理的風險，而且不知道會對客戶造成什麼影響。 + 由於合規團隊的不明疑慮，您決定不部署客戶經常請求的功能。 **建立此最佳實務的優勢：** 識別您選擇的可用優勢，並了解組織面臨的風險，讓您可以做出明智的決策。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 管理收益和風險：在決策的收益與所涉及的風險之間取得平衡。 + 確定收益：根據業務目標、需求和優先事項確定收益。範例包括上市時間、安全性、可靠性、效能和成本。 + 確定風險：根據業務目標、需求和優先事項確定風險。範例包括上市時間、安全性、可靠性、效能和成本。 + 評估風險與收益並做出明智決定：根據關鍵利害關係人 (包括業務、開發和營運團隊) 的目標、需求和優先事項，確定收益和風險的影響。評價收益的價值時要考慮發生風險的可能性及其代價。例如，強調上市速度優先於可靠性，可能提供競爭優勢。不過，如果發生可靠性問題，則可能會縮短正常執行時間。 # OPS 2  如何建構組織以支援業務成果？ 您的團隊必須了解其在達成業務成果中所扮演的角色。團隊需要了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。 **Topics** + [OPS02-BP01 已為資源識別擁有者](ops_ops_model_def_resource_owners.md) + [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md) + [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md) + [OPS02-BP04 團隊成員知道他們負責的項目](ops_ops_model_know_my_job.md) + [OPS02-BP05 存在機制用來識別責任和擁有權](ops_ops_model_find_owner.md) + [OPS02-BP06 存在用於請求新增、變更和例外狀況的機制](ops_ops_model_req_add_chg_exception.md) + [OPS02-BP07 團隊之間的責任為預先定義或經過協商](ops_ops_model_def_neg_team_agreements.md) # OPS02-BP01 已為資源識別擁有者 了解誰擁有各個應用程式、工作負載、平台和基礎設施元件、該元件提供什麼商業價值，以及該擁有權為何存在。透過了解這些個別元件的商業價值，以及其如何支援業務成果，可得知對元件套用的流程和程序。 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 已為資源識別擁有者：定義擁有權對環境中的資源使用案例的意義。指定並記錄資源的擁有者，至少包括名稱、聯絡資訊、組織和團隊。借助使用中繼資料 (例如標籤或資源群組) 的資源來儲存資源擁有權資訊。使用 AWS Organizations 建構帳戶並實作政策，以確保擷取擁有權和聯絡資訊。 + 定義擁有權形式及其指派方式：擁有權在您具有不同使用案例的組織中可能有多個定義。您可能希望將工作負載擁有者定義為承擔工作負載營運風險和責任的個人，以及最終有權對工作負載做出決策的個人。在將擁有權累計到父組織時，您可能希望根據財務或管理責任來定義擁有權。開發人員可能是其開發環境的擁有者，並負責其操作造成的事件。他們的產品主管可能自行負擔與開發環境營運相關的財務成本。 + 定義擁有組織、帳戶、資源集合或個別元件的人員：在可適當存取的位置中定義和記錄擁有權，該位置已經過組織，可支援探索。更新變更的定義和擁有權詳細資訊。 + 擷取資源中繼資料中的擁有權：使用標籤或資源群組等中繼資料擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建構帳戶並確保擷取擁有權和聯絡資訊。 # OPS02-BP02 已為流程和程序識別擁有者 了解誰具有個別流程和程序的擁有權、為何使用特定流程和程序，以及為何該擁有權存在。了解使用特定流程和程序的原因，能夠幫助發現改進機會。 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 已為流程和程序識別負責其定義的擁有者：擷取環境中使用的流程和程序，以及負責其定義的個人或團隊。 + 識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 + 定義擁有流程或程序定義的人員：唯一識別負責活動規格的個人或團隊。他們負責確保具備適當技能的團隊成員能夠成功執行該活動，且該團隊成員具備正確許可、存取權和工具。如果執行該活動時發生問題，執行該活動的團隊成員需負責提供改善活動所需的詳細回饋。 + 擷取活動成品中繼資料中的擁有權：在 AWS Systems Manager 等服務中，透過文件和做為函數的 AWS Lambda 自動化的程序，支援以標籤形式擷取中繼資料資訊。使用標籤或資源群組擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建立標記政策，並確保擷取擁有權和聯絡資訊。 # OPS02-BP03 已為營運活動識別負責其效能的擁有者 了解誰負責在已定義的工作負載上執行特定活動，以及為什麼該責任存在。透過了解誰負責執行活動，可得知誰將會進行活動、驗證結果，以及提供回饋給活動擁有者。 **建立此最佳實務的優勢：** 透過了解誰負責執行活動，可得知在需要採取動作時通知誰，以及誰將會執行動作、驗證結果，以及提供回饋給活動擁有者。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 已為營運活動識別負責其效能的擁有者：擷取執行環境中所使用之流程和程序的責任 + 識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 + 定義負責執行每個活動的人員：識別負責活動的團隊。確保他們擁有活動的詳細資訊，以及執行活動所需的技能和正確的許可、存取權和工具。他們必須了解活動執行條件 (例如，事件或排程)。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 # OPS02-BP04 團隊成員知道他們負責的項目 透過了解您角色的責任以及您為業務成果做出貢獻的方式，可得知任務的優先順序以及您的角色為何很重要。如此可讓團隊成員辨識需求並適當地回應。 **建立此最佳實務的優勢：** 透過了解您的責任，可得知您所做的決定、您採取的動作，以及如何將活動交給其適當的擁有者。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 確保團隊成員了解其角色和責任：識別團隊成員的角色和責任，並確保他們了解其角色的期望。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 # OPS02-BP05 存在機制用來識別責任和擁有權 如果沒有識別個人或團隊，就會有定義的向某人向上呈報的路徑，該人員有權指派擁有權或為需解決的需求進行規劃。 **建立此最佳實務的優勢：** 透過了解有責任或擁有權的人員，讓您可以聯絡適當的團隊或團隊成員，以提出請求或轉換任務。擁有有權指派責任或擁有權或為解決需求進行規劃的已識別人員，可降低無作為和需求得不到解決的風險。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 存在機制用來識別責任和擁有權：為您的組織成員提供可存取的機制，以探索和識別擁有權和責任。這些機制讓他們可以針對特定需求識別要聯絡的人員 (團隊或個人)。 # OPS02-BP06 存在用於請求新增、變更和例外狀況的機制 您可以向流程、程序和資源的擁有者提出請求。評估收益和風險後，若可行並經判斷是合適的行為，則應制定明智的決策以核准請求。 **建立此最佳實務的優勢：** 機制存在的目的應為請求新增、變更和例外狀況，以支援團隊的活動。如果沒有此選項，目前狀態就會成為創新的限制。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 存在用於請求新增、變更和例外狀況的機制：當標準很嚴格時，創新會受到限制。為您的組織成員提供機制，讓他們可向流程、程序和資源的擁有者提出請求，以支援其業務需求。 # OPS02-BP07 團隊之間的責任為預先定義或經過協商 團隊間已定義或協商說明如何相互配合及支援的協議 (例如，回應時間、服務等級目標或服務等級協議)。透過了解團隊工作對於業務成果和其他團隊及組織成果的影響，可得知其任務的優先順序，並讓他們能做出適當的回應。 如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時處理必要的活動，在解決這些需求時還會出現冗餘和可能相互衝突的工作。 **建立此最佳實務的優勢：** 透過建立團隊、目標和溝通需求之方法之間的責任，可簡化請求的流程，並協助確保提供必要的資訊。此舉可減少團隊之間的轉換任務所造成的延遲，並協助支援達成業務成果。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 團隊之間的責任為預先定義或經過協商：指定團隊互動的方法以及彼此支援所需的資訊，有助於將請求反覆審查和釐清時產生的延遲降到最低。擁有定義期望的特定協議 (例如，回應時間或履行時間)，讓團隊可以適當地制定有效的計畫和資源。 # OPS 3  您的組織文化如何支援您的業務成果？ 為您的團隊成員提供支援，讓他們能夠更有效地採取動作以及支援業務成果。 **Topics** + [OPS03-BP01 高層的支持](ops_org_culture_executive_sponsor.md) + [OPS03-BP02 授權團隊成員在成果有風險時採取動作](ops_org_culture_team_emp_take_action.md) + [OPS03-BP03 鼓勵向上呈報](ops_org_culture_team_enc_escalation.md) + [OPS03-BP04 溝通需及時、清楚且可行](ops_org_culture_effective_comms.md) + [OPS03-BP05 鼓勵進行試驗](ops_org_culture_team_enc_experiment.md) + [OPS03-BP06 團隊成員得以並受到鼓勵來維持和發展自己的技能集](ops_org_culture_team_enc_learn.md) + [OPS03-BP07 適當地為團隊提供資源](ops_org_culture_team_res_appro.md) + [OPS03-BP08 鼓勵並尋求來自團隊內部和跨團隊的多樣化建議](ops_org_culture_diverse_inc_access.md) # OPS03-BP01 高層的支持 資深領導階層清楚地設定對組織的期望並評估成功情況。資深領導階層是採用最佳實務和組織演進的發起者、倡導者和推動者 **建立此最佳實務的優勢：** 積極參與的領導階層、清楚傳達的期望和共同目標，能夠確保團隊成員知道對他們的期望。評估成功情況可識別成功的障礙，因此可藉由發起者、倡導者及其代表的介入來解決這些障礙。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 高層的支持：資深領導階層清楚設定對組織的期望並評估成功情況。資深領導階層是採用最佳實務和組織演進的發起者、倡導者和推動者 + 設定期望：為您的組織定義和發佈目標，包括衡量目標的方式。 + 追蹤目標的達成情況：定期衡量目標逐步達成的情況，並分享結果，以便在成果有風險時採取適當的動作。 + 提供實現目標所需的資源：根據新資訊、目標的變更、責任或您的業務環境等，定期檢閱資源是否仍然適當，或者是否需要其他資源。 + 倡導您的團隊：保持與團隊的合作，讓您了解團隊的情況，以及是否有外部因素正影響著他們。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。找出阻礙您團隊進度的障礙。代表您的團隊來協助解決障礙並消除不必要的負擔。 + 成為採用最佳實務的推動者：確認提供量化效益的最佳實務，並認可建立者和採用者。鼓勵進一步採用，以擴大已達成的效益。 + 成為團隊演變的推動者：建立持續改進的文化。鼓勵人員和組織的成長和發展。提供需要隨時間逐步達成的長期奮鬥目標。調整這個願景，以在需求、業務目標以及業務環境變化時，配合您的需求、業務目標和業務環境。 # OPS03-BP02 授權團隊成員在成果有風險時採取動作 工作負載擁有者已定義指引和範圍，授權團隊成員在成果有風險時做出回應。當事件超出定義的範圍時，採取向上呈報機制來取得方向。 **建立此最佳實務的優勢：** 透過及早測試和驗證變更，您能以最低的成本來解決問題，並限制對客戶的影響。在部署前進行測試，可將引入的錯誤數量降到最低。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 授權團隊成員在成果有風險時採取動作：為您的團隊成員提供許可、工具和機會，以練習有效回應所需的技能。 + 讓您的團隊成員有機會練習回應所需的技能：提供替代的安全環境，在其中可安全地測試和培訓流程及程序。執行演練日，讓團隊成員可以在模擬的安全環境中獲得回應實際事件的體驗。 + 定義並認可團隊成員採取動作的權限：透過指派許可和對其支援的工作負載和元件的存取權，明確地定義團隊成員採取動作的權限。認可他們有權在成果有風險時採取動作。 # OPS03-BP03 鼓勵向上呈報 如果團隊成員認為成果有風險，則其機制可協助將疑慮向上呈報至決策制定者和利害關係人，而且我們鼓勵這麼做。應該儘早且經常向上呈報，以便識別風險，並防止風險引發事件。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 鼓勵儘早且經常向上呈報：組織認可儘早且經常呈報是最佳實務。組織認可並接受，向上呈報可能經證明是毫無根據的，然而有機會防止事件的發生，則好過於不向上呈報而錯過該機會。 + 制定向上呈報的機制：制定定義進行向上呈報的時機與方式的記錄程序。記錄擁有越來越多採取動作或核准動作的權限的人員及其聯絡資訊。向上呈報應持續進行，直到團隊成員確信已將風險交給能夠解決問題的人員，或已聯絡承擔工作負載營運風險和責任的人員。該人員最終負責與工作負載相關的所有決策。向上呈報的內容應包括風險的本質、工作負載的關鍵性、受影響者、影響為何，以及緊急性 (也就是預期影響的時間為何)。 + 保護向上呈報的員工：如果團隊成員圍繞無回應決策制定者或利害關係人向上呈報，則制定保護團隊成員免受報復的政策。制定機制以識別是否發生此情況，並適當地做出回應。 # OPS03-BP04 溝通需及時、清楚且可行 存在的機制可用來及時通知團隊成員已知的風險和計劃的事件。提供必要的內容、詳細資訊和時間 (如果可能) 來支援判斷是否需要採取動作、需要什麼動作，並及時採取動作。例如，提供軟體漏洞的通知，以便加快修補的速度，或提供計劃的銷售促銷活動的通知，如此就能實作變更凍結，避免服務中斷的風險。 計劃的事件可以記錄在變更行事曆或維護排程中，讓團隊成員可以確定哪些活動待處理。 在 AWS 上， [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) 可用來記錄這些詳細資訊。它支援以程式設計方式檢查行事曆狀態，以判斷行事曆在特定時間點是否有活動。可根據特定已核准時段來規劃 *營運活動，* 該特定時段是針對潛在破壞性活動而預留。AWS Systems Manager Maintenance Windows 可讓您針對執行個體和其他 [支援的資源](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html#supported-resources-console) 來排定活動，以自動化活動並讓這些活動可供探索。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 溝通需及時、清楚且可行：已設立機制，以清楚且可行的方式提供風險或計劃事件的通知，並提供足夠的通知，以便適當的回應。 + 記錄變更行事曆上計劃的活動，並提供通知：提供可存取的資訊來源，您可以在其中發現計劃的事件。提供來自相同系統之計劃事件的通知。 + 追蹤可能影響工作負載的事件和活動：監控漏洞通知和修補程式資訊，了解外部漏洞以及與工作負載元件相關的潛在風險。提供通知給團隊成員，以便讓他們可以採取動作。 ## 資源 **相關文件：** + [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) + [AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) # OPS03-BP05 鼓勵進行試驗 試驗可加速學習，讓團隊成員保持興趣和參與度。不理想的結果是成功的試驗，因其已識別出不會助力成功的路徑。團隊成員不會因取得不理想結果的成功試驗而受懲罰。必需要經由試驗才能實現創新，並讓想法轉化為成果。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 鼓勵進行試驗：鼓勵試驗以支援學習和創新。 + 試驗各種技術：鼓勵對現在或未來可能具有適用性的技術進行試驗，以實現業務成果。這些知識可能會幫助未來的創新。 + 帶著目標進行試驗：鼓勵對團隊成員要達成的特定目標進行試驗，或對近期可能具有適用性的技術進行試驗。這些知識可能會幫助您的創新。 + 提供實驗的結構化時間：指定團隊成員可以免於其正常責任的特定時間，讓他們可以專注於自己的試驗。 + 提供資源以支援試驗：為進行試驗所需的資源提供資金 (例如，軟體或雲端資源)。 + 認可成功：識別由試驗所產生的價值。了解含有不理想成果的試驗是成功的，並且這種試驗識別了不會助力成功的路徑。團隊成員不會因試驗而來的不理想成果受到懲罰。 # OPS03-BP06 團隊成員得以並受到鼓勵來維持和發展自己的技能集 團隊必須發展自己的技能集，以採用新技術，並支援需求和責任的變更，以支援您的工作負載。新技術的技能成長通常是團隊成員滿意度的來源，並可支援創新。支援團隊成員追求和維持產業認證，以驗證和認可他們不斷成長的技能。交叉培訓以促進知識轉移，並在失去熟練的、經驗豐富且具備機構知識的成員時，降低重大影響的風險。提供學習專用的結構化時間。 AWS 提供了許多資源，包括 [AWS 入門資源中心](https://aws.amazon.com/getting-started/)， [AWS 部落格](https://aws.amazon.com/blogs/)， [AWS 線上技術會談](https://aws.amazon.com/getting-started/)， [AWS 活動和網路研討會](https://aws.amazon.com/events/)以及 [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)，而這些資源均提供了可教育您的團隊的說明、範例和演練。 AWS 也分享了我們透過 [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) 操作 AWS 所學到的最佳實務和模式，以及透過 [不同途徑獲得的各種教材，例如 AWS 部落格](https://aws.amazon.com/blogs/) 和 [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 您應該利用 AWS 提供的教育資源，例如 Well-Architected 實驗室、 [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)， [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa)和 [AWS 支援中心](https://console.aws.amazon.com/support/home/)) 和 [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 [AWS 培訓 和認證](https://aws.amazon.com/training/) 透過 AWS 基礎原理自主進度數位課程提供一些免費培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 團隊成員得以並受到鼓勵來維持和發展自己的技能集：若要採用新技術、支援創新、需求和責任的變更以支援工作負載，必需進行持續的教育。 + 為教育提供資源：提供專門的結構化時間、培訓教材和實驗室資源存取權，並支援參與會議和專業組織，這些會議和組織可為教育工作者和同儕提供學習的機會。為資淺團隊成員提供接近資深團隊成員的機會，讓資深團隊成員成為導師，或允許資深團隊成員伴隨資淺團隊成員工作，並展示他們的方法和技能。鼓勵學習與工作不直接相關的內容，以便取得更廣泛的視野。 + 團隊教育和跨團隊參與：針對團隊成員持續的教育需求進行規劃。為團隊成員提供機會 (暫時或永久地) 加入其他團隊，以分享讓整個組織受益的技能和最佳實務 + 支援產業認證的追求和維持：支援團隊成員取得與維持可驗證所學知識並認可其成就的產業認證。 ## 資源 **相關文件：** + [AWS 入門資源中心](https://aws.amazon.com/getting-started/) + [AWS 部落格](https://aws.amazon.com/blogs/) + [AWS 雲端 合規](https://aws.amazon.com/compliance/) + [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa) + [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) + [AWS 線上技術會談](https://aws.amazon.com/getting-started/) + [AWS 活動和網路研討會](https://aws.amazon.com/events/) + [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/) + [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) + [AWS 培訓 和認證](https://aws.amazon.com/training/) + [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)， + [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) + [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 # OPS03-BP07 適當地為團隊提供資源 維持團隊成員能力，並提供工具和資源，以支援您的工作負載需求。為團隊成員指派過多的任務會增加因人為錯誤所造成的事件風險。對工具和資源的投資 (例如，為經常執行的活動提供自動化) 可以提高團隊的有效性，讓他們能夠支援其他的活動。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 適當地為團隊提供資源：確保您了解團隊的成功，以及促成他們成功或不成功的因素。以適當的資源來支援團隊。 + 了解團隊效能：衡量團隊營運成果的達成情況與資產的開發。追蹤一段時間內輸出和錯誤率的變更。與團隊合作，了解影響他們的工作相關挑戰 (例如，責任增加、技術變更、人員損失或客戶支援增加)。 + 了解對團隊效能的影響：保持與團隊的合作，讓您了解團隊的情況，以及是否有外部因素正影響著他們。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。找出阻礙您團隊進度的障礙。代表您的團隊來協助解決障礙並消除不必要的負擔。 + 提供團隊取得成功所需的資源：定期檢閱資源是否仍然適當、或是否需要額外資源，並做出適當的調整以支援團隊。 # OPS03-BP08 鼓勵並尋求來自團隊內部和跨團隊的多樣化建議 利用跨組織的多樣性，尋求多種獨特的觀點。使用此觀點來增加創新、挑戰假設，並降低確認偏差的風險。在團隊中增加包容性、多樣性和可及性，以獲得有益的觀點。 組織文化對團隊成員工作滿意度和留任率有直接影響。讓團隊成員參與其中並習得能力，以便讓業務得以成功。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 尋求多樣化的意見和觀點：鼓勵每個人做出貢獻。為代表性不足的群體發聲。在會議中輪換角色和責任。 + 擴展角色和責任：為團隊成員提供機會，以擔任他們可能不會擔任的角色。他們會透過角色，以及與他們可能不會與之互動的新團隊成員互動，而獲得經驗和觀點。他們會將自己的經驗和觀點帶到新的角色，並帶給和他們互動的團隊成員。隨著觀點增加，可能會出現額外的商機，或者可能識別出新的改進機會。讓團隊內的成員輪流處理其他人通常執行的常見任務，以了解執行這些任務的需求和影響。 + 提供安全且友善的環境：制定政策與控制措施，保護組織內團隊成員在精神和身體上的安全。團隊成員應該能夠在不擔心報復行為的情況下進行互動。當團隊成員感到安全且受歡迎時，他們才更有可能參與進來並具備生產力。您的組織越多樣化，您就越能了解所支援的人員，包括您的客戶。當您的團隊成員感到安心、可以自在的暢所欲言，而且有信心他們的聲音不會被淹沒，他們才更有可能分享寶貴的洞見 (例如，行銷機會、可及性的需求、尚未有服務的市場區段、環境中未確認的風險)。 + 讓團隊成員能夠充分參與：提供員工充分參與所有與工作相關的活動所需的資源。面對日常挑戰的團隊成員已發展出解決挑戰的技能。這些以獨特方式發展的技能可為組織提供顯著的效益。為團隊成員提供必要住宿支援，將可提高從他們的貢獻中所獲得的效益。 # 準備 **Topics** + [OPS 4  您如何設計工作負載以便了解其狀況？](w2aac19b5b7b5.md) + [OPS 5  您如何減少缺陷、幫助輕鬆修復，以及改善生產流程？](w2aac19b5b7b7.md) + [OPS 6  您如何緩解部署風險？](w2aac19b5b7b9.md) + [OPS 7  您如何知道自己準備好支援工作負載？](w2aac19b5b7c11.md) # OPS 4  您如何設計工作負載以便了解其狀況？ 設計工作負載，以便它為您提供了解其內部狀態所需的跨全部元件 (例如指標、日誌和追蹤) 的資訊。這讓您能在適當時機提供有效回應。 **Topics** + [OPS04-BP01 實作應用程式遙測](ops_telemetry_application_telemetry.md) + [OPS04-BP02 實作和設定工作負載遙測](ops_telemetry_workload_telemetry.md) + [OPS04-BP03 實作使用者活動遙測](ops_telemetry_customer_telemetry.md) + [OPS04-BP04 實作相依性遙測](ops_telemetry_dependency_telemetry.md) + [OPS04-BP05 實作交易可追溯性](ops_telemetry_dist_trace.md) # OPS04-BP01 實作應用程式遙測 應用程式遙是工作負載可觀察性的基礎。您的應用程式應該發出遙測，讓您洞悉應用程式的狀態和業務成果的成就。從疑難排解到衡量新功能的影響，應用程式遙測可告知您建置、操作和發展工作負載的方式。 應用程式遙測由指標和日誌組成。指標是診斷資訊，就如您的脈搏或體溫。指標是共同用來描述應用程式的狀態。隨時間收集指標可以用來開發基準和偵測異常。日誌是應用程式傳送的訊息，其中關於內部狀態或發生的事件。錯誤碼、交易識別碼和使用者動作都是所記錄事件的範例。 **預期成果：** + 您的應用程式會發出指標和日誌，讓您洞悉其運作狀態和業務成果的成就。 + 所有應用程式的指標和日誌會集中儲存在工作負載中。 **常用的反模式：** + 您的應用程式不會發出遙測。當發生錯誤時，您必須仰賴客戶來告知您。 + 客戶已回報，您的應用程式沒有回應。不親自使用應用程式來了解目前的使用者體驗，您便沒有遙測功能，且無法確認問題存在或描述問題特性。 **建立此最佳實務的優勢：** + 您可以了解應用程式的運作狀態、使用者體驗，以及業務成果的成就。 + 您可以快速反映應用程式運作狀態中的變更。 + 您可以開發應用程式運作狀態趨勢。 + 您可以做出明智的決策，改善您的應用程式。 + 您可以更快地偵測並解決應用程式問題。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 實作應用程式遙測包含三個步驟：識別儲存遙測的位置、識別描述應用程式狀態的遙測，以及檢測要發出遙測的應用程式。 舉例來說，商務公司具有以微型服務為基礎的架構。作為架構設計程序的一部分，他們識別了應用程序遙測，而其會協助他們了解每個微型服務的狀態。例如，使用者購物車服務已發出遙測，其中包括關於新增到購物車、放棄購物車，以及將商品新增到購物車所需時間長度等事件。所有微型服務都會記錄錯誤、警告和交易資訊。遙測會傳送至 Amazon CloudWatch 進行儲存和分析。 **實作步驟** 第一步是針對工作負載中的應用程式識別儲存遙測的中心位置。如果您沒有現有的平台， [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) 會提供遙測收集、儀表板、分析和事件產生功能。 若要識別您需要的遙測，請參考下列問題： + 我的應用程式的運作狀態是否良好？ + 我的應用程式是否實現了業務成果？ 您的應用程式應該發出日誌和指標，並共同回答這些問題。如果您無法使用現有的應用程式遙測來回答這些問題，請與商務和工程利害關係人合作，以建立可以回答這些問題的遙測清單。當識別並開發新的應用程式遙測時，您可以向 AWS 帳戶 團隊要求專家技術建議。 一旦識別了其他應用程式遙測，請與您的工程利害關係人合作，以檢測您的應用程式。 [適用於 Open Telemetry 的 AWS Distro](https://aws-otel.github.io/) 提供 API、程式庫和代理程式，收集應用程式遙測。 [此範例示範如何使用自訂指標檢測 JavaScript 應用程式。](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr)。 客戶若想要了解 AWS 提供的可觀察性服務，可以透過自己的 [一個觀察工作坊](https://catalog.workshops.aws/observability/en-US) 來運作或向其 AWS 帳戶 團隊要求支援來指引他們。此工作坊會透過 AWS 的可觀察性解決方案指引您，並提供如何使用它們的實際操作範例。 如需更深入探討應用程式遙測，請閱讀 Amazon Builder’s Library 中的 [偵測分散式系統，以了解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 一文。它會說明 Amazon 如何檢測應用程式，以及如何指引您開發自己的檢測指導方針。 **實作計劃的工作量：** 中 ## 資源 **相關的最佳實務：** [OPS04-BP02 實作和設定工作負載遙測](ops_telemetry_workload_telemetry.md) – 應用程式遙測是工作負載遙測的元件。若要了解整體工作負載的運作狀態，您必須了解構成工作負載之個別應用程式的運作狀態。 [OPS04-BP03 實作使用者活動遙測](ops_telemetry_customer_telemetry.md) – 使用者活動遙測通常是應用程式遙測的子集。新增至購物車事件、點擊流或已完成交易等使用者活動，可讓您洞悉使用者體驗。 [OPS04-BP04 實作相依性遙測](ops_telemetry_dependency_telemetry.md) – 相依性與應用程式遙測相關，而且可能會配備至您的應用程式。如果您的應用程式依賴 DNS 或資料庫等外部相依性，您的應用程式可以發出有關連線能力、逾時和其他事件的指標和日誌。 [OPS04-BP05 實作交易可追溯性](ops_telemetry_dist_trace.md) – 跨工作負載追蹤交易需要每個應用程式發出其如何處理共用事件的相關資訊。個別應用程式處理這些事件的方式是透過其應用程式遙測發出的。 [OPS08-BP02 定義工作負載指標](ops_workload_health_design_workload_metrics.md) – 工作負載遙測是工作負載的重要運作狀態指標。重要應用程式指標是工作負載指標的一部分。 **相關文件：** + [AWS Builders' Library – 偵測分散式系統，以瞭解運作狀態](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) + [適用於 OpenTelemetry 的 AWS Distro](https://aws-otel.github.io/) + [AWS Well-Architected 卓越營運支柱白皮書 – 設計遙測](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html) + [使用篩選條件從日誌事件建立指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + [使用 Amazon CloudWatch 實作記錄和監控](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html) + [使用適用於 OpenTelemetry 的 AWS Distro 監控應用程式運作狀態和效能](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/) + [新增功能 – 如何使用 Amazon CloudWatch Agent 更好地監控自訂應用程式指標](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/) + [AWS 的可觀測性](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/) + [案例 – 將指標發佈至 CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html) + [開始建置 – 如何有效率地監控您的應用程式](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/) + [使用 CloudWatch 搭配 AWS SDK](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html) **相關影片：** + [AWS re:Invent 2021 - 可觀察性開放原始碼方式](https://www.youtube.com/watch?v=vAnIhIwE5hY) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體收集指標和日誌](https://www.youtube.com/watch?v=vAnIhIwE5hY) + [如何輕鬆地為您的 AWS 工作負載設定應用程式監控 - AWS 線上技術會談](https://www.youtube.com/watch?v=LKCth30RqnA) + [精通無伺服器應用程式的可觀察性 - AWS 線上技術會談](https://www.youtube.com/watch?v=CtsiXhiAUq8) + [搭配 AWS 的開放原始碼可觀察性 - AWS 虛擬研討會](https://www.youtube.com/watch?v=vAnIhIwE5hY) **相關範例：** + [AWS 記錄和監控範例資源](https://github.com/aws-samples/logging-monitoring-apg-guide-examples) + [AWS 解決方案：Amazon CloudWatch 監控架構](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card) + [AWS 解決方案︰集中式記錄](https://aws.amazon.com/solutions/implementations/centralized-logging/) + [一個觀察工作坊](https://catalog.workshops.aws/observability/en-US) # OPS04-BP02 實作和設定工作負載遙測 設計和設定您的工作負載，以發出有關其內部狀態和當前狀況的資訊，例如 API 呼叫量、HTTP 狀態碼和擴展事件。使用此資訊來協助確定何時需要回應。 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 這類服務彙總工作負載元件的日誌和指標 (例如， [AWS CloudTrail 的 API 日誌](https://aws.amazon.com/cloudtrail/)、 [AWS Lambda 指標](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)， [Amazon VPC 流程日誌](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)和 [其他服務](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html)) 建立持續整合/持續部署 (CI/CD) 管道。 **常用的反模式：** + 您的客戶在抱怨效能不佳。您的應用程式最近無變更，因此您懷疑工作負載元件發生問題。您沒有可分析的遙測資料，以判斷哪個或哪些元件造成效能不佳。 + 您的應用程式無法連線。您缺乏遙測資料來判斷它是否為網路問題。 **建立此最佳實務的優勢：** 了解工作負載內部發生的情況，讓您可以視需要做出回應。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 實作日誌和指標遙測：檢測您的工作負載，以發出有關其內部狀態、狀況和業務成果實現情況的資訊。使用此資訊來確定何時需要回應。 + [使用 Amazon CloudWatch 更好地了解您的 VM - AWS 線上技術會談](https://youtu.be/1Ck_me4azMw) + [Amazon CloudWatch 的運作方式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html) + [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) + 實作和設定工作負載遙測：設計和設定您的工作負載，以發出有關其內部狀態和當前狀況的資訊 (例如 API 呼叫量、HTTP 狀態碼和擴展事件)。 + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) + [什麼是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) + [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) ## 資源 **相關文件：** + [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) + [Amazon CloudWatch 文件](https://docs.aws.amazon.com/cloudwatch/index.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [Amazon CloudWatch 的運作方式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) + [什麼是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) + [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) + [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) **相關影片：** + [AWS 上的應用程式效能管理](https://www.youtube.com/watch?v=5T4stR-HFas) + [使用 Amazon CloudWatch 更好地了解您的 VM](https://youtu.be/1Ck_me4azMw) + [使用 Amazon CloudWatch 更好地了解您的 VM - AWS 線上技術會談](https://youtu.be/1Ck_me4azMw) # OPS04-BP03 實作使用者活動遙測 檢測您的應用程式程式碼，以發出有關使用者活動的資訊 (例如，點按流或已開始、已放棄和已完成的交易)。使用此資訊來了解應用程式如何被使用、使用模式以及確定何時需要回應。 **常用的反模式：** + 您的開發人員已部署新功能，而不需使用者遙測功能，而且使用率也已提升。您無法判斷提高的使用率是來自新功能的使用，還是新程式碼產生的問題。 + 您的開發人員已部署新功能，而不需使用者遙測功能。若不主動詢問您的客戶，您無法判斷客戶是否正在使用它。 **建立此最佳實務的優勢：** 了解客戶如何使用您的應用程式來識別使用模式、意外行為，並讓您能夠在必要時做出回應。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 實作使用者活動遙測：設計您的應用程式程式碼，以發出有關使用者活動的資訊 (例如，點按流或已開始、已放棄和已完成的交易)。使用此資訊來了解應用程式如何被使用、使用模式以及確定何時需要回應。 # OPS04-BP04 實作相依性遙測 設計和設定您的工作負載，以發出有關其相依資源之狀態 (例如，可達性或回應時間) 的資訊。外部相依性的範例可包含外部資料庫、DNS 和網路連線。使用此資訊來確定何時需要回應。 **常用的反模式：** + 若未手動執行檢查來查看您的 DNS 供應商是否正常運作，您將無法判斷應用程式無法存取的原因是否是 DNS 問題。 + 您的購物車應用程式無法完成交易。如果沒有聯絡信用卡處理供應商進行驗證，您就無法判斷是否是供應商的問題。 **建立此最佳實務的優勢：** 了解依存項目的運作狀態，讓您可以視需要做出回應。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 實作相依性遙測：設計和設定您的工作負載，以發出有關其所依賴系統的狀態和狀況的資訊。此處提供的一些範例包括：外部資料庫、DNS、網路連線和外部信用卡處理服務。 + [Amazon CloudWatch Agent 與 AWS Systems Manager 整合 - 適用於 Linux 和 Windows 的統一指標和日誌收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) ## 資源 **相關文件：** + [Amazon CloudWatch Agent 與 AWS Systems Manager 整合 - 適用於 Linux 和 Windows 的統一指標和日誌收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) **相關範例：** + [Well-Architected 實驗室 – 相依性監控](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) # OPS04-BP05 實作交易可追溯性 實作您的應用程式程式碼並設定您的工作負載元件，以發出有關整個工作負載交易流的資訊。使用此資訊來確定何時需要回應，並幫助確定問題的根本原因。 在 AWS 上，您可以使用 [AWS X-Ray](https://aws.amazon.com/xray/)等分散式追蹤服務，在交易通過工作負載時收集和記錄追蹤、產生地圖以查看交易如何在不同的工作負載和服務之間流動、深入了解元件之間的關係，以及即時確定和分析問題。 **常用的反模式：** + 您已實作跨多個帳戶的無伺服器微型服務架構。您的客戶遇到了間歇性的效能問題。因為缺少讓您能找出應用程式中存在效能問題及造成問題原因的軌跡，所以您無法找出哪個函數或元件應該負責。 + 您正嘗試判斷工作負載中效能瓶頸的位置，以便在開發工作中解決這些瓶頸。您無法查看應用程式元件和與其互動的服務之間的關係，以判斷瓶頸的位置，原因是您缺少讓自己可深入檢視影響應用程式效能的特定服務和路徑之軌跡。 **建立此最佳實務的優勢：** 了解工作負載中的交易流程，讓您可以了解工作負載交易的預期行為，以及工作負載中預期行為的變化，讓您能夠在必要時做出回應。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 實作交易可追溯性：設計您的應用程式和工作負載，以發出有關跨系統元件的交易流的資訊，例如交易階段、作用中元件和完成活動的時間。使用此資訊確定正在進行的活動、已經完成的活動以及已完成活動的結果。這可以幫助您確定何時需要回應。例如，某個元件內的交易回應時間比預期的長，可能表示該元件存在問題。 + [AWS X-Ray](https://aws.amazon.com/xray/) + [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) ## 資源 **相關文件：** + [AWS X-Ray](https://aws.amazon.com/xray/) + [什麼是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) # OPS 5  您如何減少缺陷、幫助輕鬆修復，以及改善生產流程？ 採用改善改變生產流程的方法，藉此重構、快速提供品質意見回饋及修復錯誤。這會加快有助益的改變發揮作用的速度、限制部署問題，並快速識別和修復部署活動造成的問題。 **Topics** + [OPS05-BP01 使用版本控制](ops_dev_integ_version_control.md) + [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md) + [OPS05-BP03 使用組態管理系統](ops_dev_integ_conf_mgmt_sys.md) + [OPS05-BP04 使用建置和部署管理系統](ops_dev_integ_build_mgmt_sys.md) + [OPS05-BP05 執行修補程式管理](ops_dev_integ_patch_mgmt.md) + [OPS05-BP06 共用設計標準](ops_dev_integ_share_design_stds.md) + [OPS05-BP07 實作用於提高程式碼品質的實務](ops_dev_integ_code_quality.md) + [OPS05-BP08 使用多個環境](ops_dev_integ_multi_env.md) + [OPS05-BP09 進行頻繁、細微和可逆的變更](ops_dev_integ_freq_sm_rev_chg.md) + [OPS05-BP10 完全自動化整合和部署](ops_dev_integ_auto_integ_deploy.md) # OPS05-BP01 使用版本控制 使用版本控制來追蹤變更和發佈。 許多 AWS 服務都提供版本控制功能。使用修訂版或原始程式碼控制系統 (例如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) )，管理程式碼和其他成品，例如基礎架構之版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 範本。 **常用的反模式：** + 您已在工作站上開發和存放程式碼。您在遺失程式碼的工作站上發生無法復原的儲存失敗。 + 在您的變更覆寫現有的程式碼之後，您需重新啟動應用程式，且它將無法再運作。您無法還原為變更版本。 + 您對另一人需要編輯的報告檔案加上了寫入鎖定。他們會與您聯絡，要求您停止處理該檔案，以便他們完成任務。 + 您的研究團隊一直在進行詳細的分析，以塑造您未來的工作。某人意外地將他們的購物清單儲存在最終報告中。您無法還原變更，且必須重新建立報告。 **建立此最佳實務的優勢：** 透過使用版本控制功能，您可以輕鬆回復為已知的良好狀態、舊版本，並限制資產遺失的風險。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 使用版本控制：在版本控制的儲存庫中維護資產。此舉可實現變更追蹤、新版本部署、對現有版本的變更偵測以及還原到先前的版本 (例如，在發生故障時復原到已知的良好狀態)。將組態管理系統的版本控制功能整合到您的程序中。 + [AWS CodeCommit 簡介](https://youtu.be/46PRLMW8otg) + [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) ## 資源 **相關文件：** + [什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) **相關影片：** + [AWS CodeCommit 簡介](https://youtu.be/46PRLMW8otg) # OPS05-BP02 測試並驗證變更 測試和驗證變更以幫助限制和偵測錯誤。自動化測試以減少由手動程序引起的錯誤，並減少測試工作量。 許多 AWS 服務都提供版本控制功能。使用修訂版或原始程式碼控制系統 (例如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) )，管理程式碼和其他成品，例如基礎架構之版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 範本。 **常用的反模式：** + 您將新程式碼部署到生產環境中，然後客戶開始來電，因為您的應用程式不再運作。 + 您可以套用新的安全群組，以增強週邊安全。它在運作時隨附意外後果；您的使用者無法存取您的應用程式。 + 您可以修改新函數所叫用的方法。另一個函數也依賴該方法，且不再運作。問題無法偵測到並進入生產環境。另一函數有一段時間不會被叫用，最後在生產環境中失敗，而無原因的任何關聯。 **建立此最佳實務的優勢：** 透過及早測試和驗證變更，您能以最低的成本來解決問題，並限制對客戶的影響。在部署前進行測試，可將引入的錯誤數量降到最低。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 測試並驗證變更：應該在生命週期的所有階段 (例如，開發、測試和生產) 測試變更並驗證結果。使用測試結果來確認新功能，並減輕失敗部署的風險和影響。自動執行測試和驗證，以確保檢閱的一致性，減少由手動程序引起的錯誤，並減少工作量。 + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [對 AWS CodeBuild 本機建置支援](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/) ## 資源 **相關文件：** + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [對 AWS CodeBuild 本機建置支援](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/) + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) # OPS05-BP03 使用組態管理系統 使用組態管理系統進行和追蹤組態變更。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。 靜態組態管理在初始化資源時設定值，這些值預期在資源的整個生命週期內保持一致。部分範例包括在執行個體上設定 Web 或應用程式伺服器的組態，或定義 AWS 服務 (在 [AWS 管理主控台](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) 內) 的組態，或透過下列項目定義該組態： [AWS CLI](https://aws.amazon.com/cli/)。 動態組態管理在初始化時設定值，這些值可以預期在資源的整個生命週期內保持一致。例如，您可以設定功能切換，透過組態變更啟用程式碼中的功能，或者在事故期間變更日誌詳細資訊等級以擷取更多資料，然後在事故後改回來，這會消除目前不需要的日誌及其相關費用。 如果您在執行個體、容器、無伺服器功能或裝置上執行的應用程式中具有動態組態，則可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 跨您的環境管理和部署它們。 在 AWS 上，您可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 跨帳戶和區域持續監控 AWS [資源組態](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)。它可讓您追蹤其組態歷史紀錄、了解組態變更如何影響其他資源、以及針對預期或所需的組態稽核它們，方法是使用 [AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 和 [AWS Config 合規套件](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)。 在 AWS 上，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。 製作變更行事曆，並追蹤可能受到變更實作影響的計劃的重要業務或營運活動或事件。調整活動以管理這些計畫的風險。 [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) AWS Systems Manager 變更行事曆提供一種機制，可將時間區塊記錄為變更開啟或變更關閉， [以及紀錄原因，](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar-share.html) 並與其他 AWS 帳戶 分享該資訊。AWS Systems Manager Automation 指令碼可設定為遵照變更行事曆狀態。 [AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) 可用來在指定的時間排程 AWS SSM Run Command 或 Automation 指令碼、AWS Lambda 叫用或 AWS Step Functions 活動的效能。在變更行事曆中標記這些活動，以便將它們納入您的評估中。 **常用的反模式：** + 您跨機群手動更新 Web 伺服器組態，而且由於更新錯誤，許多伺服器無法回應。 + 您在數小時內手動更新應用程式伺服器機群。變更期間的組態不一致會導致未預期的行為。 + 某人已更新您的安全群組，無法再存取您的 Web 伺服器。若不知道發生了什麼變更，您需花大量時間來調查問題，從而延長復原的時間。 **建立此最佳實務的優勢：** 採用組態管理系統可減少進行和追蹤變更的工作量，以及手動程序造成的錯誤頻率。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 使用組態管理系統：使用組態管理系統來追蹤和實作變更，以減少由手動程序引起的錯誤，並減少工作量。 + [基礎設施組態管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/) + [AWS Config](https://aws.amazon.com/config/) + [什麼是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) + [AWS CloudFormation 簡介](https://youtu.be/Omppm_YUG2g) + [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [AWS OpsWorks](https://aws.amazon.com/opsworks/) + [什麼是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html) + [AWS Elastic Beanstalk 簡介](https://youtu.be/SrwxAScdyT0) + [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) ## 資源 **相關文件：** + [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [AWS OpsWorks](https://aws.amazon.com/opsworks/) + [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) + [AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) + [基礎設施組態管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/) + [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [什麼是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) + [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) + [什麼是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html) **相關影片：** + [AWS CloudFormation 簡介](https://youtu.be/Omppm_YUG2g) + [AWS Elastic Beanstalk 簡介](https://youtu.be/SrwxAScdyT0) # OPS05-BP04 使用建置和部署管理系統 使用建置和部署管理系統。這些系統可減少由手動程序引起的錯誤，並減少部署變更的工作量。 在 AWS 中，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。 **常用的反模式：** + 在開發系統中編譯程式碼之後，您將可執行檔複製到生產系統中，然後其無法啟動。本機日誌檔案指出其因缺少相依性而失敗。 + 您在開發環境中使用新功能成功建置應用程式，並將程式碼提供給品質保證 (QA)。它的 QA 失敗，原因是它缺少靜態資產。 + 在花費大量精力之後的星期五，您已在開發環境中成功手動建置應用程式，包括您新編碼的功能。在星期一，您無法重複讓您成功建置應用程式的步驟。 + 您執行為新版本建立的測試。然後，您會在下週設定測試環境，並執行所有現有的整合測試，接著執行效能測試。新的程式碼具有無法接受的效能影響，必須重新開發，然後重新測試。 **建立此最佳實務的優勢：** 透過提供用於管理建置和部署活動的機制，您可以減少執行重複性任務的工作量，讓團隊成員專注於高價值的創意任務，並限制手動程序引入錯誤。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。 + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) ## 資源 **相關文件：** + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) **相關影片：** + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) # OPS05-BP05 執行修補程式管理 執行修補程式管理以獲取功能，解決問題並保持遵循管控。自動化修補程式管理，以減少由手動程序引起的錯誤，並減少修補工作量。 修補程式和漏洞管理屬於您利益和風險管理活動的一部分。最好擁有不可變的基礎設施，並在已驗證的已知良好狀態下部署工作負載。如果這不可行，可選擇剩餘的方法，即實施修補程式。 更新機器映像、容器映像或 Lambda [或 Lambda 自訂執行階段和其他程式庫](https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html) 以移除漏洞，屬於修補程式管理的一部分。您 [應該](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 使用 [EC2 Image Builder，](https://aws.amazon.com/image-builder/)管理適用於 Linux 或 Windows Server 映像的 Amazon Machine Image (AMIs) 更新。您可以使用 [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 搭配現有管道來 [管理 Amazon ECS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) 和 [管理 Amazon EKS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html)。AWS Lambda 包含 [版本](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 管理功能。 若未首先在安全環境中進行測試，就不應在生產系統上執行修補程式。只有在修補程式能夠支援營運或業務成果時，才應套用修補程式。在 AWS 上，您可以使用 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 自動化受管系統的修補程序，以及 [使用 AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)。 **常用的反模式：** + 您必須在兩小時內套用所有新的安全性修補程式，結果導致應用程式與修補程式不相容而致使多次停機。 + 未修補的程式庫會導致意外後果，因為未知方利用其中的漏洞來存取您的工作負載。 + 您自動修補開發人員環境，而未通知開發人員。您收到來自開發人員的多個投訴，開發人員表示其環境如預期停止運作。 + 您尚未在持久性執行個體上修補商用現成軟體。當您有軟體問題並聯絡廠商時，他們會通知您該版本不受支援，您必須修補至特定程度才能獲得任何協助。 + 您使用的加密軟體的最新修補程式可大幅改善效能。未修補的系統因未修補仍存在效能問題。 **建立此最佳實務的優勢：** 透過建立修補程式管理程序 (包括修補的條件和跨環境分佈的方法)，您將能夠實現其優勢並控制其影響。這樣一來，便能採用所需的功能和特性、消除問題，並持續遵循管控要求。實作修補程式管理系統和自動化，以減少部署修補程式的工作量，並限制手動程序引起的錯誤。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 修補程式管理：修補系統以補救問題，獲得所需的功能或特性，並保持符合管控政策和供應商支援要求。在不可變系統中，部署適當的修補程式集以實現所需的結果。自動化修補程式管理機制，以縮短修補時間，減少由手動程序引起的錯誤並降低修補工作量。 + [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) ## 資源 **相關文件：** + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) **相關影片：** + [AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) + [設計時考量 OPS](https://youtu.be/uh19jfW7hw4) **相關範例：** + [Well-Architected 實驗室 – 庫存和修補程式管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) # OPS05-BP06 共用設計標準 在團隊之間共用最佳實務，以提高認識並最大化開發工作的效益。 在 AWS 上，可使用程式碼方法來定義和管理應用程式、運算、基礎設施和營運。如此一來，您可輕鬆進行發佈、分享及採用。 許多 AWS 服務和資源旨在跨帳戶進行分享，從而讓您可跨團隊分享已建立的資產和經驗。例如，您可將 [CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) 儲存庫、 [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) 函數、 [Amazon S3 儲存貯體](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/)和 [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 分享給特定帳戶。 發佈新資源或更新時，請使用 Amazon SNS 提供 [發佈通知](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)。訂閱者可以使用 Lambda 獲得新版本。 如果您的組織中強制執行共用標準，則必須存在用於請求標準新增、變更及例外狀況的機制，以支援團隊的活動。如果沒有此選項，標準就會限制創新。 **常用的反模式：** + 您已建立自己的使用者身份驗證機制，且組織中的每一個其他開發團隊也是一樣。您的使用者必須針對要存取的系統的每一部分，維護一組單獨的登入資料。 + 您已建立自己的使用者身份驗證機制，且組織中的每一個其他開發團隊也是一樣。必須滿足的新合規要求已加諸於您的組織。每個開發團隊現在都必須投資資源來實作新要求。 + 您已建立自己的畫面版面配置，且組織中的每一個其他開發團隊也是一樣。您的使用者抱怨很難導覽不一致的介面。 **建立此最佳實務的優勢：** 使用共用標準來支援最佳實務之採用，並在標準滿足多個應用程式或組織的要求時，將開發工作的效益發揮到最大。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 共用設計標準：在團隊之間分享現有的最佳實務、設計標準、檢查清單、操作程序以及指導和管控要求，以降低複雜性並最大化開發工作的收益。確保存在用於請求對設計標准進行變更、新增和例外的程序，以支援持續的改進和創新。確保團隊了解發佈的內容，以便他們可以利用內容，限制重新作業以及工作上徒勞無功。 + [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) + [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) + [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) + [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) + [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) + [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) ## 資源 **相關文件：** + [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) + [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) + [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) + [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) + [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) **相關影片：** + [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) # OPS05-BP07 實作用於提高程式碼品質的實務 實作實務以提高程式碼品質並將缺陷降至最少。部分範例包括測試驅動的開發、程式碼檢閱和標準採用。 在 AWS 上，您可以整合 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 這類服務與管道，以自動 [識別潛在程式碼和安全問題，](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/how-codeguru-reviewer-works.html) 方法為使用程式分析和機器分學習。CodeGuru 提供如何實作 AWS 最佳實務來解決這些問題的建議。 **常用的反模式：** + 為了能夠更快測試您的功能，您已決定不整合您的標準輸入清理程式庫。測試之後，您忘記要完成程式庫合併，就遞交程式碼。 + 對於正在處理的資料集，您的經驗不多，且不知道資料集中可能存在一連串邊緣案例。這些邊緣案例與您實作的程式碼不相容。 **建立此最佳實務的優勢：** 透過採用提高程式碼品質的實務，您可以協助將引入生產中的問題降至最低。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 實作用於提高程式碼品質的實務：實作實務以提高程式碼品質，將缺陷和缺陷被部署的風險降至最低。例如，測試驅動的開發、結對程式設計、程式碼審查和標准採用。 + [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) ## 資源 **相關文件：** + [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) # OPS05-BP08 使用多個環境 使用多個環境進行實驗、開發和測試您的工作負載。當環境接近生產環境時使用更高的控制等級，以確保您的工作負載在部署後將按預期執行。 **常用的反模式：** + 您在共享開發環境中進行開發，而另一名開發人員覆寫您的程式碼變更。 + 對共享開發環境的限制性安全控制，讓您無法試驗新服務和功能。 + 您對生產系統執行負載測試，並給使用者造成停機。 + 在生產環境中發生導致資料遺失的嚴重錯誤。在您的生產環境中，您嘗試重新建立導致資料遺失的條件，以便您能夠識別其發生情況並防止再次發生。為防止更多資料在測試期間遺失，您必須讓使用者無法使用應用程式。 + 您正在操作多租用戶服務，且無法支援客戶對專用環境的要求。 + 您可能不一定總是進行測試，但當在生產環境中時，請務必測試。 + 您認為簡單的單一環境會覆寫環境內變更的影響範圍。 **建立此最佳實務的優勢：** 透過部署多個環境，您可以支援多個同時開發、測試和生產環境，而不會在開發人員或使用者社群之間產生衝突。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 使用多個環境：為開發人員沙盒環境施加最少的控制，以推動實驗。提供多個單獨的開發環境，以使並行工作成為可能，從而提高開發敏捷性。在接近生產的環境中實作更嚴格的控制，以允許開發人員創新。使用基礎設施即程式碼和組態管理系統，以部署設定了與生產環境一致控制的環境，從而確保系統在部署時能夠按預期執行。當不使用環境時，關閉環境以避免與空閒資源相關的成本 (例如，在夜間和周末關閉開發系統)。進行負載測試時，部署與生產環境等效的環境，以獲得有效結果。 + [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [如何使用 AWS Lambda 定期停止和啟動 Amazon EC2 執行個體？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/) ## 資源 **相關文件：** + [如何使用 AWS Lambda 定期停止和啟動 Amazon EC2 執行個體？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/) + [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) # OPS05-BP09 進行頻繁、細微和可逆的變更 頻繁、細微和可逆的變更會縮小變更的範圍和影響。這樣可以簡化故障診斷，實現更快的修復，並提供回復變更的選項。 **常用的反模式：** + 您在每一季都部署應用程式的新版本。 + 您經常變更資料庫結構描述。 + 您執行手動就地更新，並覆寫現有的安裝和組態。 **建立此最佳實務的優勢：** 您透過經常部署小的變更，更快認識到開發工作帶來的效益。當變更很小時，可更容易識別它們是否會產生意外的後果。如果變更可逆，由於復原得到簡化，實作變更的風險會更小。 **若未建立此最佳實務，暴露的風險等級為：** 低 ## 實作指引 + 進行頻繁、細微、可逆的變更：頻繁、細微和可逆的變更可縮小變更範圍和變更影響。這樣可以簡化故障診斷，實現更快的修復，並提供回復變更的選項。它還可以提高您為企業帶來價值的速度。 # OPS05-BP10 完全自動化整合和部署 自動化工作負載的建置、部署和測試。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。 依照一致的標記策略，使用 [資源標籤](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 來套用 [中繼資料，](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 以識別您的資源。標記您的資源，以用於組織、成本會計、存取控制，以及將自動執行營運活動設為目標。 **常用的反模式：** + 週五，您完成了為功能分支編寫新程式碼。週一，在執行您的程式碼品質測試指令碼和每個單位測試指令碼之後，您將針對下一排程版本來檢查程式碼。 + 系統會指派您編寫修正程式碼，以解決影響生產環境中大量客戶的重大問題。測試修正後，您遞交程式碼和電子郵件變更管理內容，以請求核准將其部署到生產環境中。 **建立此最佳實務的優勢：** 透過實作自動化建置和部署管理系統，您可以減少手動程序引起的錯誤，以及部署變更的工作量，讓您的團隊成員能夠專注於提供商業價值。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。 + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) ## 資源 **相關文件：** + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) **相關影片：** + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) # OPS 6  您如何緩解部署風險？ 採用可快速提供品質意見回饋，並從成果不盡理想的改變中快速復原的方法。使用這些實務可緩解部署變更所帶來問題的影響。 **Topics** + [OPS06-BP01 為失敗變更進行規劃](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) + [OPS06-BP02 測試並驗證變更](ops_mit_deploy_risks_test_val_chg.md) + [OPS06-BP03 使用部署管理系統](ops_mit_deploy_risks_deploy_mgmt_sys.md) + [OPS06-BP04 使用有限的部署進行測試](ops_mit_deploy_risks_test_limited_deploy.md) + [OPS06-BP05 使用平行環境進行部署](ops_mit_deploy_risks_deploy_to_parallel_env.md) + [OPS06-BP06 部署頻繁、細微和可逆的變更](ops_mit_deploy_risks_freq_sm_rev_chg.md) + [OPS06-BP07 完全自動化整合和部署](ops_mit_deploy_risks_auto_integ_deploy.md) + [OPS06-BP08 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md) # OPS06-BP01 為失敗變更進行規劃 計劃在變更未達到理想成果時，恢復到已知的良好狀態，或者在生產環境中進行補救。透過這樣準備可加快回應速度，以縮短復原時間。 **常用的反模式：** + 您執行了部署，而您的應用程式變得不穩定，但系統中似乎有作用中使用者。您必須決定是否要復原變更並影響作用中使用者，或在知道使用者無論如何都會受到影響的情況下，等待復原變更。 + 在進行路由變更後，您可以存取新的環境，但其中一個子網路變成無法連線。您必須決定是否要復原所有項目，或嘗試修正無法存取的子網路。當您做出該決定時，子網路仍無法連線。 **建立此最佳實務的優勢：** 具有適當的計劃可減少從不成功變更中復原的平均時間 (MTTR)，從而減少對最終使用者的影響。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 為失敗變更進行規劃：計劃在變更未達到理想成果時，恢復到已知的良好狀態 (即回復變更)，或者在生產環境中進行補救 (即向前回復變更)。當您確定無法回復的變更時，在提交之前應進行盡職調查。 # OPS06-BP02 測試並驗證變更 在生命週期所有階段測試變更並驗證結果，以確認新功能，並將失敗部署的風險和影響降至最低。 在 AWS 上，您可以建立臨時平行環境，以降低試驗和測試的風險、工作量及成本。使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 自動化這些環境的部署，以確保臨時環境的一致實作。 **常用的反模式：** + 您為應用程式部署一個很酷的新功能。但它無法運作。您不知道。 + 您更新憑證。您不小心將憑證安裝到錯誤的元件。您不知道。 **建立此最佳實務的優勢：** 透過在部署之後測試和驗證變更，您可以及早識別問題，藉此降低對客戶造成的影響。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 測試並驗證變更：在生命週期所有階段 (例如，開發、測試和生產) 測試變更並驗證結果，以確認新功能，並將失敗部署的風險和影響降至最低。 + [AWS Cloud9](https://aws.amazon.com/cloud9/) + [什麼是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) + [在交付程式碼之前，如何在本機測試和偵錯 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) ## 資源 **相關文件：** + [AWS Cloud9](https://aws.amazon.com/cloud9/) + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [在交付程式碼之前，如何在本機測試和偵錯 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) + [什麼是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) # OPS06-BP03 使用部署管理系統 使用部署管理系統來追蹤和實作變更。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。 在 AWS 中，您可以使用 [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) 等服務 (例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)) 建立持續整合/持續部署 (CI/CD) 管道。 **常用的反模式：** + 您手動將更新部署到跨整個機群的應用程式伺服器，而由於更新錯誤，許多伺服器無法回應。 + 您在數小時內手動部署到應用程式伺服器機群。變更期間的版本不一致會造成未預期的行為。 **建立此最佳實務的優勢：** 採用部署管理系統可減少部署變更的工作量，以及手動程序造成的錯誤頻率。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 使用部署管理系統：使用部署管理系統來追蹤並實作變更。這可減少由手動流程引起的錯誤，並減少部署變更的工作量。從程式碼簽入到測試、部署和驗證，自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並進一步降低工作量。 + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) + [什麼是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) ## 資源 **相關文件：** + [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/) + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [什麼是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) + [什麼是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) **相關影片：** + [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) # OPS06-BP04 使用有限的部署進行測試 繼續現有系統現有系統的同時，在有限的部署中進行測試，以在大規模部署之前確認理想成果達成與否。例如，使用部署 Canary 測試或一體式部署。 **常用的反模式：** + 您一次性將失敗的變更部署至所有生產環境。您不知道。 **建立此最佳實務的優勢：** 透過在受限部署之後測試和驗證變更，您可以及早識別出問題，並將對客戶的影響降至最低，從而有機會進一步緩解對客戶的影響。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 使用有限的部署進行測試：使用有限的部署搭配現有系統進行測試，以在大規模部署之前確認理想成果達成與否。例如，使用部署 Canary 測試或一體式部署。 + [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) + [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) + [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) ## 資源 **相關文件：** + [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) + [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) + [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) # OPS06-BP05 使用平行環境進行部署 在平行環境中實作變更，然後轉換到新環境。維護先前的環境，直到確認已成功部署為止。此舉可透過還原到先前的環境來將還原時間減至最少。 **常用的反模式：** + 您透過修改現有系統來執行可變部署。發現變更失敗之後，您必須再次修改系統以還原延長復原時間的舊版本。 + 在維護時段期間，您停用舊環境，然後開始建置新的環境。執行程序多個小時之後，您發現部署無法復原的問題。雖然非常疲倦，但您仍被迫找到先前的部署程序，並開始重建舊環境。 **建立此最佳實務的優勢：** 透過使用平行環境，您可以預先部署新的環境，並在需要時轉換至這些環境。如果新環境不成功，您可以轉換回原始環境來快速復原。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 使用平行環境進行部署：在平行環境上實作變更，然後轉換到切換新環境。維護先前的環境，直到確認已成功部署為止。此舉可透過還原到先前的環境來將還原時間減至最少。例如，將不可變的基礎架構用於藍/綠部署。 + [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) + [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) + [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) ## 資源 **相關文件：** + [AWS CodeDeploy 使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [使用 AWS Elastic Beanstalk 進行藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) + [設定 API Gateway Canary 版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) + [在 AWS CodeDeploy 中使用部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) **相關影片：** + [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw) # OPS06-BP06 部署頻繁、細微和可逆的變更 透過頻繁、細微和可逆的變更來縮小變更範圍。透過回復變更，可以更輕鬆地進行故障診斷並加快修復速度。 **常用的反模式：** + 您在每一季都部署應用程式的新版本。 + 您經常變更資料庫結構描述。 + 您執行手動就地更新，並覆寫現有的安裝和組態。 **建立此最佳實務的優勢：** 您透過經常部署小的變更，更快認識到開發工作帶來的效益。當變更很小時，可更容易識別它們是否會產生意外的後果。如果變更可逆，由於復原得到簡化，實作變更的風險會更小。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 部署頻繁、細微、可逆的變更：透過頻繁、細微和可逆的變更來縮小變更範圍。透過回復變更，可以更輕鬆地進行故障診斷並加快修復速度。 # OPS06-BP07 完全自動化整合和部署 自動化工作負載的建置、部署和測試。此舉可減少由手動程序引起的錯誤，以及部署變更的工作量。 依照一致的標記策略，使用 [資源標籤](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 來套用 [中繼資料，](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 以識別您的資源。標記您的資源，以用於組織、成本會計、存取控制，以及將自動執行營運活動設為目標。 **常用的反模式：** + 週五，您完成了為功能分支編寫新程式碼。週一，在執行您的程式碼品質測試指令碼和每個單位測試指令碼之後，您將針對下一排程版本來檢查程式碼。 + 系統會指派您編寫修正程式碼，以解決影響生產環境中大量客戶的重大問題。測試修正後，您遞交程式碼和電子郵件變更管理內容，以請求核准將其部署到生產環境中。 **建立此最佳實務的優勢：** 透過實作自動化建置和部署管理系統，您可以減少手動程序引起的錯誤，以及部署變更的工作量，讓您的團隊成員能夠專注於提供商業價值。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 使用建置和部署管理系統：使用建置和部署管理系統來追蹤和實作變更，以減少由手動流程引起的錯誤，並減少工作量。從程式碼簽入到建置、測試、部署和驗證，完全自動化整合和部署管道。此舉可減少前置時間，增加變更頻率，並降低工作量。 + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) + [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw) ## 資源 **相關文件：** + [在 AWS CodeDeploy 中嘗試範例藍/綠部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) + [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [什麼是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) **相關影片：** + [軟體開發持續整合最佳實務](https://www.youtube.com/watch?v=GEPJ7Lo346A) + [深入了解使用 AWS 的進階持續交付技術](https://www.youtube.com/watch?v=Lrrgd0Kemhw) + [AWS CodeDeploy 簡介 - 使用 Amazon Web Services 進行自動化軟體部署](https://www.youtube.com/watch?v=Wx-ain8UryM) + [Slalom：AWS 上適用於無伺服器應用程式的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) # OPS06-BP08 自動化測試和復原 自動測試部署的環境，以確認理想成果達成與否。當無法實現結果時，自動還原到先前的良好狀態，以最大限度縮短還原時間，並減少由手動程序引起的錯誤。 **常用的反模式：** + 您將變更部署至工作負載。在看到變更完成之後，您開始部署後測試。在您看到它們完成之後，您會發現工作負載無法運作，且客戶中斷連線。然後您開始復原到之前的版本。經過長時間偵測問題後，手動重新部署會延長復原時間。 **建立此最佳實務的優勢：** 透過在部署之後測試和驗證變更，您可以立即識別出問題。透過自動復原至舊版本，將對客戶的影響降至最低。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 自動化測試和還原：自動測試部署的環境，以確認理想成果達成與否。當無法實現結果時，自動還原到先前的良好狀態，以最大限度縮短還原時間，並減少由手動程序引起的錯誤。例如，在部署後執行詳細的綜合使用者事務，驗證結果，並在失敗時復原。 + [使用 AWS CodeDeploy 重新部署和回復部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) ## 資源 **相關文件：** + [使用 AWS CodeDeploy 重新部署和回復部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) # OPS 7  您如何知道自己準備好支援工作負載？ 評估工作負載、流程和程序及人員的營運準備度，了解工作負載相關營運風險。 **Topics** + [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) + [OPS07-BP02 確保對營運準備度進行一致的審查](ops_ready_to_support_const_orr.md) + [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md) + [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md) + [OPS07-BP05 做出部署系統和變更的明智決策](ops_ready_to_support_informed_deploy_decisions.md) # OPS07-BP01 確保人員能力 建立一種機制，用於驗證您有適當數量受過培訓的人員來為營運需求提供支援。培訓人員並根據需要調整人員能力，以保持有效的支援。 您需要擁有足夠的團隊成員，以妥善應對所有活動 (包括隨時待命)。確保您的團隊具備取得成功所需的必要技能，並進行工作負載、操作工具和 AWS 的培訓。 AWS 提供了許多資源，包括 [AWS 入門資源中心](https://aws.amazon.com/getting-started/)， [AWS 部落格](https://aws.amazon.com/blogs/)， [AWS 線上技術會談](https://aws.amazon.com/getting-started/)， [AWS 活動和網路研討會](https://aws.amazon.com/events/)以及 [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)，而這些資源均提供了可教育您的團隊的說明、範例和演練。此外， [AWS 培訓 和認證](https://aws.amazon.com/training/) 透過 AWS 基礎原理自主進度數位課程提供一些免費培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。 **常用的反模式：** + 在沒有能夠支援使用中平台和服務的熟練團隊成員之情況下，部署工作負載。 + 在預期支援時數內無團隊成員可用的情況下部署工作負載。 + 在團隊成員休假或生病請假而無足夠團隊成員提供支援的情況下，部署工作負載。 + 在未檢閱對支援該工作負載和其他工作負載之團隊成員的額外影響情況下，部署額外工作負載。 **建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 人員能力：驗證人員是否已經過充分培訓，可有效支援工作負載。 + 團隊規模：確保擁有足夠且訓練有素的團隊成員，以妥善應對營運活動，包括隨時待命。 + 團隊技能：確保您的團隊成員就 AWS、工作負載和營運工具獲得足夠培訓，可履行其職責。 + [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/) + [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/) + 審查能力：隨著營運條件和工作負載變化，審查團隊的規模和技能，以確保有足夠能力維持卓越營運。進行調整以確保團隊規模和技能與團隊支援的工作負載的營運要求相匹配。 ## 資源 **相關文件：** + [AWS 部落格](https://aws.amazon.com/blogs/) + [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/) + [AWS 入門資源中心](https://aws.amazon.com/getting-started/) + [AWS 線上技術會談](https://aws.amazon.com/getting-started/) + [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/) **相關範例：** + [Well-Architected 實驗室](https://wellarchitectedlabs.com/) # OPS07-BP02 確保對營運準備度進行一致的審查 使用營運準備度審查 (ORR)，來確認您可以運行工作負載。 ORR 是在 Amazon 開發的機制，可確認團隊是否可放心地運行工作負載。ORR 是使用需求檢查清單的審查和檢查程序。ORR 是一種自助服務體驗，團隊會透過此體驗來進行工作負載的認證。ORR 包含的最佳實務皆汲取我們多年來建置軟體所獲得的經驗。 ORR 檢查清單包含架構建議、營運程序、事件管理和發行品質。錯誤糾正 (CoE) 程序是這些項目的主要驅動要素。您專屬的事件後分析應有助於專屬 ORR 的發展。ORR 不只是遵循最佳實務，還能防止先前發生過的事件再發。最後，ORR 中也能夠包含安全性、管控和合規需求。 在工作負載啟動以全面供應前，並在整個軟體開發生命週期執行 ORR。在啟動前執行 ORR 可改善安全運行工作負載的能力。定期針對工作負載重新執行 ORR 可捕捉最佳實務中的任何偏移。您可以為新服務的推出制定 ORR 檢查清單，並為定期審查制定 ORR。此可協助您掌握新出現的最佳實務最新狀態，並採納從事件後分析獲得的經驗。隨著您可以更熟練地使用雲端後，您就可以在架構中建置 ORR 需求作為預設值。 **預期成果：**  您制定 ORR 檢查清單，內含組織的最佳實務。ORR 會在工作負載啟動前執行。ORR 會在工作負載生命週期的過程中定期執行。 **常見的反模式：** + 您啟動工作負載，但不知道自己是否能夠運行工作負載。 + 啟動工作負載的認證中未納入管控和安全性需求。 + 不會定期重新評估工作負載。 + 工作負載啟動，但不需設置必要的程序。 + 您可以在多個工作負載中看到重複出現的相同根本原因失敗。 **建立此最佳實務的優勢：** + 工作負載包含架構、程序和管理最佳實務。 + 經驗已納入 ORR 程序中。 + 工作負載啟動時，已設置必要的程序。 + ORR 會在工作負載的整個軟體生命週期執行。 **若未建立此最佳實務的風險等級：** 高 ## 實作指引 ORR 有兩個部分：程序和檢查清單。貴組織應採用 ORR 程序，並由執行主辦人支援此程序。至少，必須在工作負載啟動以全面供應前執行 ORR。在整個軟體開發生命週期執行 ORR，使其與最佳實務或新需求保持同步。ORR 檢查清單應包含組態項目、安全性和管控需求，以及來自貴組織的最佳實務。在經過一段時間後，您可以使用服務，例如 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)、 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)，和 [AWS Control Tower 防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)，來將 ORR 中的最佳實務建置在防護機制中，以便自動偵測最佳實務。 **客戶範例** 在發生數個生產事件後，AnyCompany Retail 決定實作 ORR 程序。他們建立了一份檢查清單，其中由最佳實務、管控和合規需求，以及從中斷中汲取的經驗教訓所組成。在工作負載啟動前，新的工作負載會執行 ORR。每個工作負載每年都會使用一部分的最佳實務來執行 ORR，以便納入在 ORR 檢查清單中新增的最佳實務和需求。經過一段時間後，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 來偵測最佳實務，進而縮短 ORR 程序的時間。 **實作步驟** 若要進一步了解 ORR，請閱讀 [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)。其中提供詳細的資訊，說明 ORR 程序的歷史、如何建立您專屬的 ORR 實務，以及如何制定 ORR 檢查清單。以下步驟是該文件的精簡版本。如需深入了解 ORR 是什麼，以及如何建立您專屬的 ORR，我們建議閱讀該白皮書。 1. 召集關鍵利害關係人，包含安全性、營運和開發等團隊的代表人員。 1. 請每位利害關係人提供至少一個需求。對於第一次的反覆測試，請嘗試將項目數限制在三十個以下。 + [附錄 B：來自「營運準備度審查 (ORR)」白皮書的](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) ORR 問題範例包含您可以開始使用的範例問題。 1. 將需求集中放在試算表中。 + 您可以使用 [在](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) AWS Well-Architected Tool 中 [使用自訂聚焦](https://console.aws.amazon.com/wellarchiected/) 來制定 ORR 並在帳戶和 AWS 組織之間進行共用。 1. 找出要在其中執行 ORR 的一個工作負載。啟動前的工作負載或內部工作負載是理想的選擇。 1. 演練 ORR 檢查清單，並記下任何所探索的項目。如果採取緩解措施，那就可能無法進行探索。對於缺少緩解措施的任何探索，請將那些探索新增至項目的待辦清單中，然後在啟動前加以實作。 1. 隨著時間持續在 ORR 檢查清單中新增最佳實務和需求。 使用 Enterprise Support 的 支援 客戶可請求 [「營運準備度審查」研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (透過其技術客戶經理)。研討會是互動式的 *逆向思維* 課程，可讓您制定自己的 ORR 檢查清單。 **實作計劃的工作量：** 高。在組織中採用 ORR 實務需要高層和利害關係人的支持。使用貴組織提供的各方意見，來建立和更新檢查清單。 ## 資源 **相關的最佳實務：** + [OPS01-BP03 評估管控要求](ops_priorities_governance_reqs.md) – ORR 檢查清單原本就很適合用來管控需求。 + [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) – ORR 檢查清單中有時會包含合規需求。有些時候，它們會是獨立的程序。 + [OPS03-BP07 適當地為團隊提供資源](ops_org_culture_team_res_appro.md) – 團隊能力是 ORR 需求的絕佳候選項。 + [OPS06-BP01 為失敗變更進行規劃](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 啟動工作負載前，必須先建立回復或向前回復計劃。 + [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) – 若要支援工作負載，您必須具備所需的人員。 + [SEC01-BP03 識別和驗證控制目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全性控制目標是絕佳的 ORR 需求。 + [REL13-BP01 定義停機和資料遺失的復原目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 災難復原計劃是絕佳的 ORR 需求。 + [COST02-BP01 根據貴組織的需求制定政策](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 將成本管理政策納入 ORR 檢查清單是很棒的做法。 **相關文件：** + [AWS Control Tower - AWS Control Tower 中的防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) + [AWS Well-Architected Tool - 自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) + [Adrian Hornsby 提供的營運準備度審查範本](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) + [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) **相關影片：** + [AWS 支援 為您提供支援 \$1 建立有效的營運準備度審查 (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8) **相關範例：** + [營運準備度審查 (ORR) 聚焦範例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens) **相關服務：** + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) + [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) + [使用自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) # OPS07-BP03 使用執行手冊執行程序 路由層 *執行手冊* 是為了實現特定結果而記錄的程序。執行手冊由一系列可供遵循以完成某項工作的步驟組成。早在航空器製造初期，操作過程中就會使用執行手冊。在雲端操作中，我們使用執行手冊來降低風險及達到預期成果。簡言之，執行手冊就是完成一項工作的檢查清單。 執行手冊是工作負載的運作不可或缺的部分。從新團隊成員的上線到部署主要版本，執行手冊無論由誰使用，都是可提供一致結果的編碼程序。執行手冊應在集中發佈，並隨著程序的演進而更新，因為更新執行手冊是變更管理程序的重要環節。其中也應包含關於問題發生時的錯誤處理、工具、許可、例外狀況和呈報的指引。 隨著組織的成熟，您可以開始將執行手冊自動化。請從簡短且常用的執行手冊開始著手。使用指令碼語言自動執行步驟，或使步驟較容易執行。前幾個執行手冊完成自動化後，您會專注於將較複雜的執行手冊自動化。經過一段時間後，您大多數的執行手冊應該都已做了某種程度的自動化。 **預期成果：** 您的團隊有一系列執行工作負載任務的逐步指南。執行手冊中包含預期成果、必要的工具和許可，以及錯誤處理指示。這些執行手冊會集中存放，並且經常更新。 **常見的反模式：** + 憑藉記憶完成程序中的每個步驟。 + 手動部署變更而不使用檢查清單。 + 不同的團隊成員執行相同程序，但使用的步驟不同，或結果不同。 + 執行手冊失去與系統變更和自動化的同步。 **建立此最佳實務的優勢：** + 降低手動工作的錯誤率。 + 以一致的方式執行操作： + 新的團隊成員可更快開始執行工作。 + 可將執行手冊自動化以節省人力。 **未建立此最佳實務時的曝險等級：** 中 ## 實作指引 根據組織的成熟度，執行手冊採取數種形式。其中至少應包含逐步說明文字文件。預期成果應明確指出。明確記載必要的特殊許可或工具。提供詳細指引，說明在發生狀況時應如何處理錯誤及呈報。列出執行手冊擁有者，並將其集中發佈。執行手冊列入文件後，應請團隊的其他成員加以執行，以進行驗證。隨著程序的演進，請根據您的變更管理程序更新執行手冊。 隨著組織逐漸成熟，您的文字執行手冊應該要自動化。使用諸如 [AWS Systems Manager 自動化的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，您可以將一般文字轉換為可對工作負載執行的自動化。這些自動化可作為事件的應變動作來執行，以降低您維持工作負載的操作負擔。 **客戶範例** AnyCompany Retail 必須在軟體部署期間執行資料庫結構描述更新。雲端維運團隊與資料庫管理團隊共同建置用來手動部署這些變更的執行手冊。執行手冊以檢查清單格式列出了程序中的每個步驟。其中包含相關發生狀況時進行錯誤處理的章節。他們將執行手冊發佈於內部 Wiki，與其他執行手冊放在一起。雲端維運團隊規劃要在未來的衝刺期間將執行手冊自動化。 ## 實作步驟 如果您沒有現有的文件儲存庫，版本控制儲存庫將是您開始建置執行手冊程式庫的絕佳選擇。您可以使用 Markdown 來建置執行手冊。我們提供了範例執行手冊範本，讓您用來開始建置執行手冊。 ``` # 執行手冊標題 ## 執行手冊資訊 | 執行手冊 ID | 描述 | 使用的工具 | 特殊許可 | 執行手冊作者 | 上次更新日期 | 呈報 POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | 此執行手冊的用途為何？ 預期成果為何？ | 工具 | 許可 | 您的名稱 | 2022-09-21 | 呈報名稱 | ## 步驟 1.步驟一 2.步驟二 ``` 1. 如果您沒有現有的文件儲存庫或 Wiki，請在您的版本控制系統中建立新的版本控制儲存庫。 1. 識別沒有執行手冊的程序。經常執行、步驟數較少，且失敗的影響程度不高的程序，就是理想的程序。 1. 在您的文件儲存庫中，使用範本建立新的草稿 Markdown 文件。填入 `「執行手冊標題」` 和必要欄位 (在 `「執行手冊資訊」底下)`。 1. 從第一個步驟開始，填入執行手冊的 `「步驟」` 部分。 1. 將執行手冊提供給團隊成員。讓他們使用執行手冊來驗證步驟。如有任何事項缺漏或需要釐清，請更新執行手冊。 1. 將執行手冊發佈至您的內部文件存放區。發佈後，請告知團隊和其他利害關係人。 1. 一段時間後，您會建置執行手冊程式庫。隨著該程式庫的擴增，您應開始設法將執行手冊自動化。 **實作計劃的工作量：** 低。執行手冊的最低標準是逐步文字指南。將執行手冊自動化可能會增加實作工作量。 ## 資源 **相關的最佳實務：** + [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：執行手冊應有擁有者負責加以維護。 + [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊識別出根本原因時，就會觸發執行手冊。 + [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：執行手冊是良好事件、事故和問題管理實務的一部分。 + [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應提醒。一段時間後，這些因應動作應該要自動化。 + [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護執行手冊是知識管理的重要環節。 **相關文件：** + [使用自動化的執行手冊和程序手冊達成卓越營運](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) + [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) + [AWS 大型遷移的遷移程序手冊 - 任務 4：改進您的遷移執行手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) + [使用 AWS Systems Manager 自動化執行手冊完成營運任務](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) **相關影片：** + [AWS re:Invent 2019：執行手冊、事故報告和事故應變的 DIY 指南 (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [如何使用 AWS \$1 Amazon Web Services 將 IT 營運自動化](https://www.youtube.com/watch?v=GuWj_mlyTug) + [將指令碼整合到 AWS Systems Manager 中](https://www.youtube.com/watch?v=Seh1RbnF-uE) **相關範例：** + [AWS Systems Manager：自動化演練](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) + [AWS Systems Manager：從最新的快照執行手冊還原根磁碟區](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html) + [使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事故應變執行手冊](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) + [Gitlab - 執行手冊](https://gitlab.com/gitlab-com/runbooks) + [Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫](https://github.com/Nurtch/rubix) + [使用 Document Builder 建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) + [Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) **相關服務：** + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) # OPS07-BP04 使用程序手冊來調查問題 程序手冊是用來調查事件的逐步指南。事件發生時，我們會使用程序手冊來調查、確認影響範圍和找出根本原因。程序手冊可用於各種情境，從部署失敗到安全性事件皆涵蓋在內。在許多案例中，程序手冊可釐清根本原因，而執行手冊則用來緩解該根本原因。程序手冊是組織事件應變計劃的關鍵要素。 優良的程序手冊有幾個重要的特點。它會透過探索的過程來逐步引導使用者。請試著從各種角度思考，我們應遵循哪些步驟來診斷事件？ 透過程序手冊明確定義，在程序手冊中是否需要特殊工具或提高權限。制定溝通計劃，向利害關係人告知調查的最新狀態是關鍵要素。在無法釐清根本原因的狀況下，程序手冊應具備呈報計劃。如果已確定根本原因，程序手冊應指向執行手冊，後者會描述如何解決該根本原因。程序手冊應集中存放並定期維護。如果您使用程序手冊來發出特定警示，請為團隊提供警示中該程序手冊的指標。 隨著組織逐漸成熟，將程序手冊自動化。從涵蓋低風險事件的程序手冊開始。使用指令碼來自動化探索步驟。確保您有配套執行手冊來緩解常見的根本原因。 **預期成果：** 您的組織具備常見事件的程序手冊。該程序手冊存放在集中的位置，可供團隊成員使用。程序手冊會頻繁更新。對於任何已知的根本原因，都已建立配套執行手冊。 **常見的反模式：** + 調查事件並沒有標準的方法。 + 團隊成員依賴肌肉記憶或機構知識，來針對失敗的部署進行疑難排解。 + 新團隊成員會學習如何透過試錯來調查問題。 + 各個團隊間並未共用調查問題的最佳實務。 **建立此最佳實務的優勢：** + 程序手冊可為您省下緩解事件所需的心力。 + 不同的團隊成員可以使用相同的程序手冊，以一致的方式找出根本原因。 + 您可以為已知的根本原因制定執行手冊，進而縮短復原時間。 + 程序手冊可協助團隊成員更快開始做出貢獻。 + 團隊可以透過可重複的程序手冊擴展其程序。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 您如何根據組織的成熟度來建立和使用程序手冊。如果您剛接觸雲端，請在中央文件儲存庫中建立文字形式的程序手冊。隨著組織逐漸成熟，您就可以透過 Python 之類的指令碼語言將程序手冊半自動化。您可以在 Jupyter 筆記本中執行這些指令碼來加快探索速度。先進的組織具有全自動化的程序手冊，這些手冊適用於透過執行手冊自動修復的常見問題。 透過列出在您工作負載中發生的常見事件，來開始建立程序手冊。為低風險以及根本原因的範圍已縮減至幾個問題的事件選擇程序手冊，然後開始。在您為較簡單情境建立程序手冊後，請接著嘗試風險較高或尚未確定根本原因的情境。 隨著組織逐漸成熟，應將您的文字程序手冊自動化。使用諸如 [AWS Systems Manager Automations 的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，可以將一般文字轉換為自動化。您可以針對工作負載執行這些自動化來加快調查速度。您可以啟動這些自動化來回應事件、縮短事件探索和解決的平均時間。 客戶可使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來回應事件。此服務提供單一介面，來分類事件、在探索和緩解期間通知利害關係人，並在整個事件期間進行合作。其使用 AWS Systems Manager Automations 來加快偵測和復原速度。 **客戶範例** 生產事件會影響 AnyCompany Retail。待命的工程師使用程序手冊來調查問題。隨著透過步驟取得進展時，該工程師會確保程序手冊中識別的重要利害關係人都能了解最新進展。他發現根本原因是後端服務中的一項競賽條件。該工程師使用執行手冊，重新啟動服務，使 AnyCompany Retail 重新上線。 ## 實作步驟 如果您沒有現有的文件儲存庫，我們建議為程序手冊程式庫建立版本控制儲存庫。您可以使用 Markdown 建立程序手冊，Markdown 與多數程序手冊自動化系統都相容。如果您是從頭開始建立，請使用以下範例程序手冊範本。 ``` # Playbook Title ## Playbook Info | Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? | ## Steps 1.Step one 2.Step two ``` 1. 如果您沒有現有的文件儲存庫或 Wiki，請在版本控制系統中為程序手冊建立新的版本控制儲存庫。 1. 找出需要調查的常見問題。應存在根本原因僅限於幾個問題的情境，解決方案的風險很低。 1. 使用 Markdown 範本，填寫 `程序手冊名稱` 區段以及程序手冊資訊 `下的欄位`。 1. 填寫疑難排解步驟。盡可能清楚說明要執行哪些動作或應調查哪些地方。 1. 將程序手冊提供給團隊成員，讓成員透過該手冊來進行驗證。如果缺少任何資訊或內容不清楚，請更新程序手冊。 1. 在文件儲存庫中發佈程序手冊，並通知團隊和任何利害關係人。 1. 此程序手冊程式庫會隨著您新增更多程序手冊而成長。在您有數本程序手冊後，請開始使用 AWS Systems Manager Automations 之類的工具來進行自動化，進而確保自動化和程序手冊都能保持同步。 **實作計劃的工作量：** 低。程序手冊應為集中存放的文字文件。越來越多發展成熟的組織會開始自動化程序手冊。 ## 資源 **相關的最佳實務：** + [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：程序手冊應有擁有者，擁有者會負責維護這類手冊。 + [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊找出根本原因時，就會使用執行手冊。 + [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：程序手冊是正常事件、事故和問題管理實務的一部分。 + [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應警示。一段時間後，應將這些因應措施自動化。 + [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護程序手冊是知識管理的重要環節。 **相關文件：** + [ 使用自動化的執行手冊和程序手冊達成卓越營運 ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) + [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) + [ 使用 AWS Systems Manager Automation 執行手冊解決營運任務 ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) **相關影片：** + [AWS re:Invent 2019：執行手冊、事件報告和事件應變的 DIY 指南 (SEC318-R1) ](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [AWS Systems Manager Incident Manager - AWS 虛擬研討會 ](https://www.youtube.com/watch?v=KNOc0DxuBSY) + [ 將指令碼整合到 AWS Systems Manager 中 ](https://www.youtube.com/watch?v=Seh1RbnF-uE) **相關範例：** + [AWS 客戶程序手冊架構 ](https://github.com/aws-samples/aws-customer-playbook-framework) + [AWS Systems Manager：自動化演練 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) + [ 使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事件應變執行手冊 ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) + [ Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫 ](https://github.com/Nurtch/rubix) + [ 使用 Document Builder 建立自訂執行手冊 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) + [ Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化 ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) + [ Well-Architected 實驗室：使用 Jupyter 事件應變程序手冊 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/) **相關服務：** + [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) + [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) # OPS07-BP05 做出部署系統和變更的明智決策 評估團隊支援工作負載的能力以及工作負載對管控的遵從性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，以做出明智決策。 事前剖析是一種演練，其中團隊會模擬失敗以開發緩解策略。使用事前剖析可預測失敗並適時建立程序。當您變更您用於評估工作負載的檢查清單時，請計劃如何處理不再合規的即時系統。 **常用的反模式：** + 在不了解工作負載中存在安全性風險的情況下，決定部署工作負載。 + 在不了解工作負載是否符合您的管控和標準的情況下，決定部署工作負載。 + 在不了解您的團隊是否能支援此工作負載的情況下，決定部署工作負載。 + 在不了解工作負載對組織有何好處的情況下，決定部署工作負載。 **建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。 **若未建立此最佳實務，暴露的風險等級為：** 低 ## 實作指引 + 做出部署工作負載和變更的明智決策：評估團隊支援工作負載的能力以及工作負載對管控的合規性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，並做出明智的決策。 # 營運 **Topics** + [OPS 8  您如何了解工作負載的運作狀態？](w2aac19b5b9b5.md) + [OPS 9  您如何了解營運狀況？](w2aac19b5b9b7.md) + [OPS 10  您如何管理工作負載和營運事件？](w2aac19b5b9b9.md) # OPS 8  您如何了解工作負載的運作狀態？ 定義、擷取和分析工作負載指標，掌握工作負載事件，以便採取適當行動。 **Topics** + [OPS08-BP01 識別關鍵績效指標](ops_workload_health_define_workload_kpis.md) + [OPS08-BP02 定義工作負載指標](ops_workload_health_design_workload_metrics.md) + [OPS08-BP03 收集和分析工作負載指標](ops_workload_health_collect_analyze_workload_metrics.md) + [OPS08-BP04 建立工作負載指標基準](ops_workload_health_workload_metric_baselines.md) + [OPS08-BP05 了解工作負載的預期活動模式](ops_workload_health_learn_workload_usage_patterns.md) + [OPS08-BP06 在工作負載結果有風險時發出提醒](ops_workload_health_workload_outcome_alerts.md) + [OPS08-BP07 在偵測到工作負載異常時發出提醒](ops_workload_health_workload_anomaly_alerts.md) + [OPS08-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_workload_health_biz_level_view_workload.md) # OPS08-BP01 識別關鍵績效指標 根據所需的業務成果 (例如，訂單率、客戶保留率以及獲利與營運支出的對比) 與客戶成果 (例如，客戶滿意度)，識別關鍵績效指標 (KPI)。評估 KPI 以確定工作負載是否成功。 **常用的反模式：** + 企業領導階層會詢問您工作負載如何成功滿足業務需求，但您卻沒有可判斷成功與否的參考框架。 + 您無法判斷為組織營運的商用現成應用程式是否具成本效益。 **建立此最佳實務的優勢：** 藉由識別關鍵績效指標，您可以實現業務成果，做為對工作負載運作狀態和成功的測試。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 識別關鍵績效指標：根據所需的業務和客戶成果識別關鍵績效指標 (KPI)。評估 KPI 以確定工作負載是否成功。 # OPS08-BP02 定義工作負載指標 定義工作負載指標以衡量 KPI 的實現情況 (例如，捨棄的購物車、下單的訂單、成本、價格和分配的工作負載支出)。定義工作負載指標以衡量工作負載的運作狀態 (例如，界面回應時間、錯誤率、提出的請求、完成的請求和使用率)。評估指標以判斷工作負載是否取得了預期的成果，並了解工作負載的運作狀態。 您應該將日誌資料傳送到 CloudWatch Logs 這類服務，並從必要日誌內容的觀察中產生指標。 CloudWatch 擁有專業功能，例如 [適用於 .NET 和 SQL Server 的 Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-what-is.html) 和 [Container Insights，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 這些功能可協助您在各個特定支援應用程式資源和技術堆疊之間識別並設定關鍵指標、日誌和警示。 **常用的反模式：** + 您已定義與任何 KPI 無關或針對任何工作負載量身打造的標準指標。 + 您的指標計算中有錯誤，這會產生無效的結果。 + 您尚未為工作負載定義任何指標。 + 您只衡量了可用性。 **建立此最佳實務的優勢：** 透過定義和評估工作負載指標，您可以判斷工作負載的運作狀態，並衡量業務成果的實現情況。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 定義工作負載指標：定義工作負載指標以衡量 KPI 的實現情況。定義工作負載指標，以衡量工作負載及其各個元件的運作狀態。評估指標以確定工作負載是否取得了預期的成果，並了解工作負載的運作狀態。 + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) ## 資源 **相關文件：** + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) # OPS08-BP03 收集和分析工作負載指標 定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。 您應該將應用程式、工作負載元件、服務和 API 呼叫的日誌資料彙總至像是 CloudWatch Logs 等服務中。從必要日誌內容的觀察中產生指標，以深入了解營運活動的效能。 在 AWS 上，您可以分析工作負載指標並識別操作問題，方法為使用 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)機器學習功能。AWS DevOps Guru 會提供操作問題的通知，隨附 [針對性和主動](https://docs.aws.amazon.com/devops-guru/latest/userguide/view-insights.html) 建議，以解決問題並維護應用程式運作狀態。 在 AWS 共同責任模式中，監控部分可透過下列項目提供給您： [AWS Health 儀板表](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)。此儀表板會在 AWS 發生可能影響您的事件時，提供提醒與修補指導。商業和企業支援訂閱客戶還可存取 [AWS Health API](https://docs.aws.amazon.com/health/latest/ug/getting-started-api.html)，進而可以整合至其事件管理系統。 在 AWS 上，您可以 [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 或者 [直接傳送日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 至 [Amazon S3](https://aws.amazon.com/s3/) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/)，在 Amazon S3 中探索和準備日誌資料，以進行分析並將關聯的中繼資料儲存在 [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena](https://aws.amazon.com/athena/)Amazon Athena，透過與 AWS Glue 的原生整合，可用來分析日誌資料，並使用標準 SQL 進行查詢。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料。 另一個 [解決方案](https://aws.amazon.com/solutions/centralized-logging/?did=sl_card&trk=sl_card) 是使用 [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) 和 [OpenSearch 儀表板](https://aws.amazon.com/elasticsearch-service/the-elk-stack/kibana/) 跨多個帳戶和 AWS 區域 收集、分析和顯示 AWS 上的日誌。 **常用的反模式：** + 網路設計團隊會詢問您目前的網路頻寬使用率。您提供目前的指標，網路使用率為 35%。由於時間點測量並未反映使用率趨勢，因此它們降低電路容量，以作為節省成本的措施，這導致廣泛的連線問題。 + 您的路由器失敗。它一直在記錄非關鍵的記憶體錯誤，隨著頻率越來越大，直到完全失敗。您未偵測到此趨勢，因此在路由器造成服務中斷之前，並未取代出錯的記憶體。 **建立此最佳實務的優勢：** 透過收集和分析工作負載指標，您可以了解工作負載的運作狀態，並深入了解可能影響工作負載或達成業務成果的趨勢。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 收集和分析工作負載指標：定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。 + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) ## 資源 **相關文件：** + [Amazon Athena](https://aws.amazon.com/athena/) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [AWS Glue](https://aws.amazon.com/glue/) + [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html) + [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) + [AWS Health 儀板表](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) + [Quick](https://aws.amazon.com/quicksight/) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) # OPS08-BP04 建立工作負載指標基準 為指標建立基準，以提供期望值，做為比較和識別效能欠佳和過剩的元件的基礎。識別用於改善、調查和介入的閾值。 **常用的反模式：** + 伺服器在 95% 的 CPU 使用率下執行，系統會詢問您情況是好或壞。該伺服器的 CPU 使用率尚未進行基準比較，因此您不知道這是好或壞。 **建立此最佳實務的優勢：** 透過定義基準指標值，您可以評估目前的指標值和指標趨勢，以判斷是否需要採取動作。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 為工作負載指標建立基準：為工作負載指標建立基準，以提供期望值做為比較的基礎。 + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) ## 資源 **相關文件：** + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) # OPS08-BP05 了解工作負載的預期活動模式 建立工作負載活動模式以識別異常行為，以便您可以在需要時做出適當回應。 CloudWatch 透過 [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能套用統計和機器學習演算法，以產生代表一般指標行的預期值範圍。 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 可以用來透過事件關聯性、日誌分析和套用機器學習分析您的工作負載遙測來識別異常行為。當偵測到非預期行為時，它會提供 [相關的指標和事件，](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 隨附處理行為的建議。 **常用的反模式：** + 您正在檢閱網路使用率日誌，並看到網路使用率在上午 11:30 到下午 1:30 之間增加，然後在下午 4:30 到下午 6:00 之間再次增加。您不知道這是否應該視為正常。 + 您的 Web 伺服器每天凌晨 3:00 重新開機。您不知道這是否是預期的行為。 **建立此最佳實務的優勢：** 透過學習行為模式，您可以識別意外行為，並在必要時採取動作。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 了解工作負載的預期活動模式：建立工作負載活動模式，以確定行為何時超出預期值，以便您在需要時做出適當的回應。 ## 資源 **相關文件：** + [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) # OPS08-BP06 在工作負載結果有風險時發出提醒 當工作負載結果有風險時發出提醒，以便您可以在必要時做出適當的回應。 理想情況下，您先前已識別可對其發出警示的指標閾值，或已識別可用來觸發自動回應的事件。 在 AWS 上，您可以使用 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 建立 Canary 指令碼，來監控您的端點和 API，方法為執行與客戶相同的動作。產生的遙測和 [取得的洞見](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) 可讓您在客戶受到影響之前識別問題。 您也可以使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) ，透過專門打造的查詢語言，以互動的方式搜尋並分析日誌資料。CloudWatch Logs Insights 會自動 [探索 AWS 服務日誌中的欄位，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) 以及 JSON 中的自訂日誌事件。它可以隨日誌量和查詢複雜性進行擴展，並在幾秒鐘內提供答案，以協助您搜尋事件的影響因素。 **常用的反模式：** + 您沒有網路連線能力。沒有人注意到。沒有人嘗試找出原因，或採取動作來恢復連線。 + 套用修補程式之後，您的持久性執行個體不可用，從而中斷使用者。您的使用者已開啟支援案例。沒有人收到通知。沒有人採取動作。 **建立此最佳實務的優勢：** 透過識別業務成果已產生風險，並提醒採取動作，您就有機會防止或緩解事件的影響。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 在工作負載結果有風險時發出提醒：當工作負載結果有風險時發出提醒，以便您在需要時做出適當的回應。 + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) ## 資源 **相關文件：** + [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) + [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) # OPS08-BP07 在偵測到工作負載異常時發出提醒 當偵測到工作負載異常時發出提醒，以便您可以在必要時做出適當的回應。 透過長時間分析工作負載指標能夠建立可充分量化的行為模式，以定義事件或發出警示來回應。 經過訓練後， [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能可用於對偵測到的異常發出 [警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) ，或提供重疊的預期值至指標資料 [圖形](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 上，以便進行持續比較。 **常用的反模式：** + 您的零售網站銷售額突然大幅增加。沒有人注意到。沒有人試圖找出導致此激增的原因。沒有人採取動作，以確保額外負載下的優質客戶體驗。 + 應用程式套用修補程式之後，您的持久性伺服器會經常重新啟動，從而中斷使用者。您的伺服器通常重新開機最多三次，但不會更多次。沒有人注意到。沒有人試圖找出發生此問題的原因。 **建立此最佳實務的優勢：** 透過了解工作負載行為的模式，您可以識別意外行為，並在必要時採取動作。 **若未建立此最佳實務，暴露的風險等級為：** 低 ## 實作指引 + 在偵測到工作負載異常時發出提醒：當偵測到工作負載異常時發出提醒，以便您在需要時做出適當的回應。 + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) ## 資源 **相關文件：** + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) # OPS08-BP08 驗證結果的實現以及 KPI 和指標的有效性 建立工作負載營運的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。 AWS 還可透過 AWS 服務 API 和 SDK (例如 Grafana、Kibana 和 Logstash) 支援第三方日誌分析系統和商業智慧工具。 **常用的反模式：** + 頁面回應時間從來未被視為有助於提高客戶滿意度的因素。您從未建立頁面回應時間的指標或閾值。您的客戶對於緩慢問題抱怨不已。 + 您尚未達到最低回應時間目標。為改善回應時間，您已擴展應用程式伺服器。您現在已大幅超出回應時間目標，而且已付費容量中還有大量未使用。 **建立此最佳實務的優勢：** 透過審查和修訂 KPI 和指標，您可以了解工作負載如何支援業務成果的達成，並找出達成業務目標需要改善的地方。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 驗證結果的實現以及 KPI 和指標的有效性：建立工作負載營運的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。 + [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [什麼是日誌分析？](https://aws.amazon.com/log-analytics/) ## 資源 **相關文件：** + [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [什麼是日誌分析？](https://aws.amazon.com/log-analytics/) # OPS 9  您如何了解營運狀況？ 定義、擷取和分析營運指標，掌握營運事件，以便採取適當行動。 **Topics** + [OPS09-BP01 識別關鍵績效指標](ops_operations_health_define_ops_kpis.md) + [OPS09-BP02 定義營運指標](ops_operations_health_design_ops_metrics.md) + [OPS09-BP03 收集和分析營運指標](ops_operations_health_collect_analyze_ops_metrics.md) + [OPS09-BP04 建立營運指標基準](ops_operations_health_ops_metric_baselines.md) + [OPS09-BP05 了解營運活動的預期模式](ops_operations_health_learn_ops_usage_patterns.md) + [OPS09-BP06 在營運成果有風險時發出警示](ops_operations_health_ops_outcome_alerts.md) + [OPS09-BP07 在偵測到營運異常時發出提醒](ops_operations_health_ops_anomaly_alerts.md) + [OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_operations_health_biz_level_view_ops.md) # OPS09-BP01 識別關鍵績效指標 根據所需的業務成果 (例如，交付的新功能) 和客戶成果 (例如，客戶支援案例)，識別關鍵績效指標 (KPI)。評估 KPI 以確定營運是否成功。 **常用的反模式：** + 企業領導階層會詢問您是否成功完成業務目標，但您卻沒有可判斷成功與否的參考框架。 + 您無法判斷您的維護時段是否會影響業務成果。 **建立此最佳實務的優勢：** 藉由識別關鍵績效指標，您可以實現業務成果，做為對營運運作狀態和成功的測試。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 識別關鍵績效指標：根據所需的業務和客戶成果識別關鍵績效指標 (KPI)。評估 KPI 以確定營運是否成功。 # OPS09-BP02 定義營運指標 定義營運指標以衡量 KPI 的實現情況 (例如，成功部署和失敗部署)。定義營運指標以衡量營運活動的運作狀態 (例如，偵測事件所需的平均時間 (MTTD)，以及從事件中復原所需的平均時間 (MTTR))。評估指標以判斷營運是否取得理想成果，並了解您的營運活動的運作狀態。 **常用的反模式：** + 您的運營指標是以團隊認為合理的內容為基礎。 + 您的指標計算中有錯誤，這會產生不正確的結果。 + 您尚未為營運活動定義任何指標。 **建立此最佳實務的優勢：** 透過定義和評估營運指標，您可以判斷營運活動的運作狀態，並衡量業務成果的實現情況。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 定義營運指標：定義營運指標以衡量 KPI 的實現情況。定義營運指標以衡量營運及其活動的狀況。評估指標以確定營運是否取得理想成果，並了解營運狀況。 + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) ## 資源 **相關文件：** + [AWS Answers：集中式記錄](https://aws.amazon.com/answers/logging/centralized-logging/) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [使用 Amazon CloudWatch Events 偵測管道狀態中的變更並做出反應](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html) + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [搜尋和篩選日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) **相關影片：** + 制定監控計劃 # OPS09-BP03 收集和分析營運指標 定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。 您應該將執行營運活動和操作 API 呼叫的日誌資料彙總至 CloudWatch Logs 這類服務中。從必要日誌內容的觀察中產生指標，以深入了解營運活動的效能。 在 AWS 上，您可以 [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 或者 [直接傳送日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 至 [Amazon S3](https://aws.amazon.com/s3/) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/)，在 Amazon S3 中探索和準備日誌資料，以進行分析並將關聯的中繼資料儲存在 [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena](https://aws.amazon.com/athena/)Amazon Athena，透過與 AWS Glue 的原生整合，可用來分析日誌資料，並使用標準 SQL 進行查詢。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料。 **常用的反模式：** + 我們將新功能的一致交付視為關鍵績效指標。您無法測量部署發生的頻率。 + 您記錄部署、復原的部署、修補程式和復原的修補程式，以追蹤您的營運活動，但沒有人審查指標。 + 您的復原時間目標為可在 15 分鐘內還原遺失的資料庫，該目標設定於系統已部署且沒有使用者時。您現在有一萬名使用者，並已營運兩年。最近的還原時間花費超過兩小時。未記錄此項目，也沒有人知道。 **建立此最佳實務的優勢：** 透過收集和分析營運指標，您可以了解營運的運作狀態，並深入了解可能影響營運或達成業務成果的趨勢。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 收集和分析營運指標：定期對指標進行主動審查，以確定趨勢並確定需要在哪些地方採取適當回應。 + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) ## 資源 **相關文件：** + [Amazon Athena](https://aws.amazon.com/athena/) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [Quick](https://aws.amazon.com/quicksight/) + [AWS Glue](https://aws.amazon.com/glue/) + [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html) + [使用 CloudWatch Agent 從 Amazon EC2 執行個體和內部部署伺服器收集指標和日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) # OPS09-BP04 建立營運指標基準 為指標建立基準，以提供期望值，做為比較和識別效能欠佳和過剩的營運活動的基礎。 **常用的反模式：** + 您需告知預計部署的時間為何。您尚未測量部署所需的時間，也無法判斷預期的時間。 + 您需告知從應用程式伺服器問題中復原需要多長時間。對於從第一次聯絡客戶起計算的所需復原時間，您沒有相關資訊。對於從監控得知的第一次識別問題起計算的所需復原時間，您沒有相關資訊。 + 您需告知您在週末需要多少名支援人員。您不知道週末有多少個典型支援案例，且無法提供預估值。 + 您的復原時間目標為可在 15 分鐘內還原遺失的資料庫，該目標設定於系統已部署且沒有使用者時。您現在有一萬個使用者，並已營運兩年。對於資料庫還原時間為什麼變更的原因，您沒有相關資訊。 **建立此最佳實務的優勢：** 透過定義基準指標值，您可以評估目前的指標值和指標趨勢，以判斷是否需要採取動作。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 了解營運活動的預期模式：建立營運活動模式，以確定行為何時超出預期值，以便您可以在需要時做出適當的回應。 # OPS09-BP05 了解營運活動的預期模式 建立營運活動模式以識別異常活動，以便您可以在必要時做出適當的回應。 **常用的反模式：** + 最近，您的部署失敗率大幅增加。您獨立解決每次失敗。您不知道失敗源於不熟悉部署管理系統的新員工執行的部署。 **建立此最佳實務的優勢：** 透過學習行為模式，您可以識別意外行為，並在必要時採取動作。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 了解營運活動的預期模式：建立營運活動模式，以確定行為何時超出預期值，以便您可以在需要時做出適當的回應。 # OPS09-BP06 在營運成果有風險時發出警示 每當營運成果有風險時，就必須發出警示並據以行動。營運成果是可支援生產中工作負載的任何活動。其中包含從部署新版應用程式到從中斷復原的所有作業。您必須以與業務成果一樣的重要性來看待營運成果。 軟體團隊應找出關鍵的營運指標和活動，並為其建立警示。警示必須及時且可據以採取行動。發出警示時，應包含相應執行手冊或程序手冊的參考。發出警示，但未提供相應的動作可能會導致警示疲勞。 **預期成果：** 當營運活動有風險時，就會傳送警示來促進行動。警示包含為何發出警示的背景資訊，並指向要調查的程序手冊和要採取緩解措施的執行手冊。盡可能自動化執行手冊並傳送通知。 **常見的反模式：** + 您正在調查事件，以及正在將支援案例歸檔。支援案例違反服務水準協議 (SLA)，但未發出任何警示。 + 由於最後一刻的程式碼變更，預定於午夜進行的生產部署遭到延遲。未發出任何警示，而部署發生懸置。 + 發生生產中斷，但未傳送任何警示。 + 您的部署時間一直落後於預估值。未採取任何調查動作。 **建立此最佳實務的優勢：** + 當營運成果有風險時，發出警示可以協助您透過預先發現問題來支援工作負載。 + 營運成果的運作狀態良好，業務成果因而獲得改善。 + 營運問題的偵測和修復也獲得改善。 + 整體營運運作狀態也有所改善。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 必須先定義營運成果，才能針對這些成果發出警示。透過定義哪些營運活動對貴組織最重要來開始。是否要在兩小時內將其部署至生產，或是在固定的時間內回應支援案例？ 貴組織必須定義關鍵營運活動，以及如何衡量這些活動，如此才能夠監控、改善這些活動，並據以發出警示。您需要一個中心位置，來存放和分析工作負載及營運遙測。相同的機制應能夠在營運成果有風險時發出警示。 **客戶範例** CloudWatch 警示會在 AnyCompany Retail 的例行部署期間觸發。超過部署的前置時間。Amazon EventBridge 已在 AWS Systems Manager OpsCenter 中建立 OpsItem。雲端營運團隊使用程序手冊來調查問題，並發現結構描述的變更花費的時間比預期更長。他們向待命的開發人員發出警示，並持續監控部署。在部署完成後，雲端營運團隊就會解析 OpsItem。該團隊會在事後分析事件。 ## 實作步驟 1. 如果您還沒有確定營運 KPI、指標和活動，請著手實作先前所述的此問題的最佳實務 (OPS09-BP01 至 OPS09-BP05)。 + 使用 [企業支援的 支援 客戶](https://aws.amazon.com/premiumsupport/plans/enterprise/) 可以要求 [營運 KPI 研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) (透過其技術客戶經理)。此協作研討會可協助您定義與業務目標一致的營運 KPI 和指標，而不需額外費用。聯絡技術客戶經理來進一步了解。 1. 在您建立營運活動、KPI 和指標後，請在可觀察性平台設定警示。警示應具備與其關聯的動作，例如程序手冊或執行手冊。應避免發出不含動作的警示。 1. 經過一段時間後，您應能評估營運指標、KPI 和活動來找出待改善的地方。擷取執行手冊和程序手冊中來自操作人員的回饋，找出在回應警示時待改善的地方。 1. 警示應包含將待改善地方標示為誤判的機制。這會導致對指標閾值的審查。 **實作計劃的工作量：** 中。在實作此最佳實務前，必須實作幾個最佳實務。在確定營運活動與建立營運 KPI 後，也應建立警示。 ## 資源 **相關的最佳實務：** + [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md)：每個營運活動和成果都應有確定的負責擁有者。當成果有風險時，該擁有者就應收到警示。 + [OPS03-BP02 授權團隊成員在成果有風險時採取動作](ops_org_culture_team_emp_take_action.md)：發出警示時，團隊中應有專員採取行動來修復此問題。 + [OPS09-BP01 識別關鍵績效指標](ops_operations_health_define_ops_kpis.md)：針對營運成果發出警示，從確定營運 KPI 開始。 + [OPS09-BP02 定義營運指標](ops_operations_health_design_ops_metrics.md)：先建立此最佳實務，再開始產生警示。 + [OPS09-BP03 收集和分析營運指標](ops_operations_health_collect_analyze_ops_metrics.md)：您必須集中收集營運指標，才能建立警示。 + [OPS09-BP04 建立營運指標基準](ops_operations_health_ops_metric_baselines.md)：營運指標基準讓您能夠調整警示並避免警示疲勞。 + [OPS09-BP05 了解營運活動的預期模式](ops_operations_health_learn_ops_usage_patterns.md)：您可以透過了解營運事件的活動模式，來改善警示的準確性。 + [OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性](ops_operations_health_biz_level_view_ops.md)：評估營運成果的達成情形，來確保 KPI 和指標是有效的。 + [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：每個警示應具備相關的執行手冊或程序手冊，並為收到警示的人員提供背景資訊。 + [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md)：在收到警示後執行事件後分析，來找出待改善的地方。 **相關文件：** + [AWS 部署管道參考架構：應用程式管道架構](https://pipelines.devops.aws.dev/application-pipeline/) + [GitLab：開始使用敏捷 / DevOps 指標](https://about.gitlab.com/handbook/marketing/strategic-marketing/devops-metrics/) **相關影片：** + [使用 AWS Systems Manager OpsCenter 彙總和解決營運問題](https://www.youtube.com/watch?v=r6ilQdxLcqY) + [將 AWS Systems Manager OpsCenter 與 Amazon CloudWatch 警示整合](https://www.youtube.com/watch?v=Gpc7a5kVakI) + [使用 Amazon EventBridge 將資料來源整合至 AWS Systems Manager OpsCenter](https://www.youtube.com/watch?v=Xmmu5mMsq3c) **相關範例：** + [使用 Amazon EC2 Systems Manager Automation 和 AWS Health 自動化 Amazon EC2 通知及其他方面的修復動作](https://aws.amazon.com/blogs/mt/automate-remediation-actions-for-amazon-ec2-notifications-and-beyond-using-ec2-systems-manager-automation-and-aws-health/) + [AWS 管理與管控工具研討會 - 2022 年營運 ](https://mng.workshop.aws/operations-2022.html) + [在 AWS 上使用 DevOps 監控儀表板來擷取、分析和視覺化指標](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/welcome.html) **相關服務：** + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [支援 主動服務 - 營運 KPI 研討會 ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) + [AWS Systems Manager OpsCenter，](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) + [CloudWatch 事件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) # OPS09-BP07 在偵測到營運異常時發出提醒 在偵測到營運異常時發出提醒，以便您可以在必要時做出適當的回應。 透過長時間分析營運指標能夠建立可充分量化的行為模式，以定義事件或發出警示來回應。 經過訓練後， [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 功能可用於對偵測到的異常發出 [警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) ，或提供重疊的預期值至指標資料 [圖形](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 上，以便進行持續比較。 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 可以用來透過事件關聯性、日誌分析和套用機器學習分析您的工作負載遙測來識別異常行為。AWS Well-Architected [洞見](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 會呈現出來，隨附相關資訊和建議。 **常用的反模式：** + 您正將修補程式套用到您的執行個體機群。您已在測試環境中成功測試修補程式。對於機群中的大部分執行個體，修補程式失敗。您不採取任何動作。 + 您注意到，有部署動作從週五結束日開始。您的組織已預先定義星期二和星期四的維護時段。您不採取任何動作。 **建立此最佳實務的優勢：** 透過了解營運行為的模式，您可以識別意外行為，並在必要時採取動作。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 在偵測到營運異常時發出提醒：在偵測到營運異常時發出提醒，以便您可以在需要時做出適當的回應。 + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) ## 資源 **相關文件：** + [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) + [CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) + [建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) + [使用 Amazon CloudWatch Events 偵測管道狀態中的變更並做出反應](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html) + [使用 Amazon SNS 通知呼叫 Lambda 函數](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) # OPS09-BP08 驗證結果的實現以及 KPI 和指標的有效性 建立營運活動的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。 AWS 還可透過 AWS 服務 API 和 SDK (例如 Grafana、Kibana 和 Logstash) 支援第三方日誌分析系統和商業智慧工具。 **常用的反模式：** + 部署頻率已隨著開發團隊數量的成長而增加。您定義的預期部署數量為每週一次。您一直每天定期部署。當您的部署系統有問題，而無法部署時，數天都不會偵測到該問題。 + 當您的公司先前只在週一至週五的核心上班時間提供支援時。您已針對事件建立下個工作日回應時間目標。您最近開始提供全年無休支援涵蓋範圍，並隨附兩小時回應時間的目標。您的夜班員工不堪重負，客戶也不滿意。沒有事件回應時間發生問題的跡象，原因是您的通報違背下個工作日目標。 **建立此最佳實務的優勢：** 透過審查和修訂 KPI 和指標，您可以了解工作負載如何支援業務成果的達成，並找出達成業務目標需要改善的地方。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 驗證結果的實現以及 KPI 和指標的有效性：建立營運活動的業務層級檢視，以幫助您確定需求是否得到滿足，並確定需要改進以實現業務目標的領域。驗證 KPI 和指標的有效性，並在必要時進行修訂。 + [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [什麼是日誌分析？](https://aws.amazon.com/log-analytics/) ## 資源 **相關文件：** + [使用 Amazon CloudWatch 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) + [什麼是日誌分析？](https://aws.amazon.com/log-analytics/) # OPS 10  您如何管理工作負載和營運事件？ 準備和驗證回應事件的程序，大幅降低工作負載中斷情形。 **Topics** + [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md) + [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md) + [OPS10-BP03 根據業務影響確定營運事件的優先順序](ops_event_response_prioritize_events.md) + [OPS10-BP04 定義向上呈報路徑](ops_event_response_define_escalation_paths.md) + [OPS10-BP05 啟用推送通知](ops_event_response_push_notify.md) + [OPS10-BP06 透過儀表板傳達狀態](ops_event_response_dashboards.md) + [OPS10-BP07 自動回應事件](ops_event_response_auto_event_response.md) # OPS10-BP01 使用程序進行事件、事故和問題管理 您的組織具有處理事件、事故和問題的程序。*事件* 是發生於工作負載、但可能無需由您介入的事項。*事故* 是需要介入的事件。 *問題* 是重複發生而需要介入或無法解決的事件。您需要相關程序來減輕這些事件對業務的影響，並確保您能夠適當因應。 當工作負載發生事故和問題時，您需要有相關程序來加以處理。您如何讓利害關係人得知事件的狀態？ 應變由誰監控？ 您使用哪些工具來減輕事件的影響? 在此舉例說明一些您為了獲得可靠的應變程序而有待解答的問題。 程序必須集中記載，並且提供給涉及工作負載的每個人使用。如果您沒有集中的 Wiki 或文件存放區，可以使用版本控制儲存庫。您將隨著程序的演進而保有最新計劃。 問題是可以自動化的。這些事件佔據的時間會影響到您的創新能力。請開始建置可重複的程序，以減輕問題。經過一段時間後，您將著重於緩解措施的自動化或修正基礎問題。如此您即有時間投入於工作負載的改進。 **預期成果：** 您的組織具有處理事件、事故和問題的程序。這些程序會集中記載並存放。這些文件會隨著程序的變更而更新。 **常見的反模式：** + 週末發生了事故，而值班工程師不知該如何處理。 + 客戶傳送電子郵件給您，指出應用程式已關閉。您將伺服器重新開機，試著修正問題。此狀況頻繁地發生。 + 有一項事故讓多個團隊各自獨立試著加以解決。 + 您的工作負載中發生了部署，但並未記錄。 **建立此最佳實務的優勢：** + 您的工作負載中有事件的稽核軌跡。 + 您的事故中復原的時間減少了。 + 團隊成員可用一致的方式解決事故和問題。 + 調查事故的人力會更加整合。 **未建立此最佳實務時的曝險等級：** 高 ## 實作指引 實作此最佳實務，意味著您會追蹤工作負載事件。您具有處理事故和問題的程序。這些程序會經常記載、共用及更新。問題經識別後會定出優先順序，然後獲得修正。 **客戶範例** AnyCompany Retail 有某部分的內部 Wiki 專門用來處理事件、事故和問題管理。所有事件都會傳送至 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)。問題會在 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 中識別為 OpsItems，並定出修正的優先順序，以減少無特殊專長人力。程序變更後，會隨即在其內部 Wiki 中更新。他們使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來管理事故及協調緩解工作。 ## 實作步驟 1. 事件 + 追蹤發生在工作負載中的事件，即使無需人為介入亦然。 + 與工作負載利害關係人共同擬定應追蹤的事件清單。範例包括已完成的部署或成功的修補。 + 您可以使用諸如 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 或者 [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 等服務來產生要追蹤的自訂事件。 1. 事故 + 首先請定義事故的溝通計劃。哪些利害關係人必須獲得通知？ 您如何維繫其參與度? 協調工作由誰監控？ 我們建議建立內部交談管道，以利溝通和協調。 + 為支援工作負載的團隊定義呈報路徑，尤其是團隊未設置當班輪值時。根據您的支援等級，您也可以向 支援 申請立案。 + 建立用來調查事件的程序手冊。其中應包含溝通計劃和詳細的調查步驟。在您的調查中納入對 [AWS Health 儀板表](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 的檢查。 + 記載您的事故應變計劃。傳達事故管理計劃，讓內部與外部客戶都了解互動的規則及其應有的預期。對您的團隊成員進行其使用訓練。 + 客戶可使用 [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來設定及管理其事故應變計劃。 + Enterprise Support 客戶可以要求 [事件管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) (透過其技術客戶經理)。這個指導研討會將測試您現有的事故應變計劃，並協助您識別改善的領域。 1. 問題 + 問題必須在 ITSM 系統中受到識別及追蹤。 + 識別所有已知問題，並按照修正的工作量以及對工作負載的影響定出優先順序。 ![\[用來排定問題優先順序的動作優先順序矩陣\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/impact-effort-chart.png) + 先解決高影響、低工作量的問題。這些問題解決後，再接著解決位於低影響、低工作量象限的問題。 + 您可以使用 [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) 來識別這些問題、將執行手冊連結至問題，並加以追蹤。 **實作計劃的工作量：** 中。必須同時具備程序和工具，才能實作此最佳實務。記載您的程序，並且讓工作負載的任何相關人員都可加以使用。經常加以更新。您具有管理問題和加以緩解或修正的程序。 ## 資源 **相關的最佳實務：** + [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)：已知問題需要相關聯的執行手冊，讓緩解工作保有一致性。 + [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)：事件需使用程序手冊來調查。 + [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md)：從事故復原後務必要執行事後檢討。 **相關文件：** + [Atlassian - DevOps 時代的事故管理](https://www.atlassian.com/incident-management/devops) + [AWS 安全事故應變指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) + [DevOps 和 SRE 時代的事故管理](https://www.infoq.com/presentations/incident-management-devops-sre/) + [PagerDuty - 什麼是事故管理？](https://www.pagerduty.com/resources/learn/what-is-incident-management/) **相關影片：** + [AWS re:Invent 2020：分散式組織中的事故管理](https://www.youtube.com/watch?v=tyS1YDhMVos) + [AWS re:Invent 2021 - 使用事件驅動架構建置新一代的應用程式](https://www.youtube.com/watch?v=U5GZNt0iMZY) + [AWS 為您提供支援 \$1 探索事故管理桌上模擬演練](https://www.youtube.com/watch?v=0m8sGDx-pRM) + [AWS Systems Manager Incident Manager - AWS 虛擬研討會](https://www.youtube.com/watch?v=KNOc0DxuBSY) + [AWS 下一步 ft. Incident Manager \$1 AWS 事件](https://www.youtube.com/watch?v=uZL-z7cII3k) **相關範例：** + [AWS 管理與管控工具研討會 - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html) + [AWS 主動服務 – 事故管理研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) + [使用 Amazon EventBridge 建置事件驅動應用程式](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/) + [在 AWS 上建置事件驅動架構](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/) **相關服務：** + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) + [AWS Health 儀板表](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) + [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) + [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) # OPS10-BP02 每個提醒建立一個程序 對於引發提醒的任何事件，建立明確定義的回應 (執行手冊或程序手冊)，並指明。此舉可確保對營運事件的有效而迅速的回應，並防止需採取動作的事件被無價值的通知所淹沒。 **常用的反模式：** + 您的監控系統會將核准的連線串流以及其他訊息一起提供給您。訊息數量如此龐大，以至於您錯過需要您介入的定期錯誤訊息。 + 您收到提醒，指出網站運作中斷。發生這種情況時沒有已定義的程序。您必須採取臨機操作方法來診斷和解決問題。隨需開發此程序會延長復原時間。 **建立此最佳實務的優勢：** 只有在需要採取動作時才發出提醒，可防止低值提醒隱藏高值提醒。透過讓每個可採取動作的提醒都具有一個程序，您可針對環境中的事件實現一致且迅速的回應。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 每個提醒建立一個程序：對於引發提醒的任何事件，都應建立明確定義的回應 (執行手冊或程序手冊)，並指明負責人 (例如，個人、團隊或角色) 來對成功完成的程序負責。回應的執行可以自動化，也可以由另一個團隊完成，但負責人要對確保流程交付預期結果負責。透過建立這些程序，您可以確保對營運事件做出迅速有效的回應，並防止需採取行動的事件被無價值的通知所淹沒。例如，自動調整規模功能可能應用於調整 Web 前端規模，但營運團隊可能需負責確保自動調整規模規則和限制符合工作負載需求。 ## 資源 **相關文件：** + [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/) + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) **相關影片：** + [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU) # OPS10-BP03 根據業務影響確定營運事件的優先順序 確保在有多個事件需要介入時，首先解決對業務最重要的事件。影響可能包括人員傷亡、經濟損失或聲譽或信用受損。 **常用的反模式：** + 您收到為使用者新增印表機組態的支援請求。處理此問題時，您收到支援請求，而其指出您的零售網站運作中斷。為使用者完成印表機組態後，您便開始處理網站問題。 + 您收到零售網站和薪資系統運作中斷的通知。您不知道應該優先處理哪一個。 **建立此最佳實務的優勢：** 將對業務影響最大的事件回應排定優先順序，讓您能夠管理該影響。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 根據業務影響，排定操作事件的優先順序：確保在有多個事件需要介入時，首先解決對業務最重要的事件。影響可能包括人員傷亡、經濟損失、違反法規或聲譽或信用受損。 # OPS10-BP04 定義向上呈報路徑 在您的執行手冊和程序手冊中定義向上呈報路徑，包括觸發向上呈報的條件以及向上呈報的程序。明確確定每個動作的擁有者，以確保對營運事件做出迅速有效的回應。 在採取行動之前，確定何時需要人為決策。與決策者合作，事先做出該決策，並預先核准行動，如此就不會延長 MTTR 等待回應的時間。 **常用的反模式：** + 您的零售網站已運作中斷。您不了解用於恢復網站的執行手冊。您開始打電話給同事，希望有人能夠幫助您。 + 您收到應用程式無法連線的支援案例。您沒有管理系統的許可。您不知道誰有這個許可。您嘗試聯絡開立此案例的系統擁有者，但沒有回應。您沒有此系統的聯絡人，而且您的同事對此不熟悉。 **建立此最佳實務的優勢：** 透過定義向上呈報、向上呈報觸發條件和向上呈報程序，您可以針對影響以適當的速率將資源系統性地新增到事件中。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 定義向上呈報路徑：在您的執行手冊和程序手冊中定義向上呈報路徑，包括觸發向上呈報的條件以及向上呈報的程序。例如，當執行手冊無法解決問題或經過預定時間，將問題從支援工程師向上呈報給資深支援工程師。適當的向上呈報途徑還有，當程序手冊無法確定工作負載的補救途徑或經過預定時間，從高級支援工程師向上呈報給開發團隊。明確確定每個動作的擁有者，以確保對營運事件做出迅速有效的回應。向上呈報可以包括第三方。例如，網路連接提供商或軟體供應商。向上呈報可以包括受影響系統的指定授權決策者。 # OPS10-BP05 啟用推送通知 就您的使用者所用之服務受到影響以及服務再次恢復正常，直接與使用者溝通 (例如，透過電子郵件或簡訊)，以便使用者能夠採取適當動作。 **常用的反模式：** + 您的應用程式正遭遇分散式阻斷服務事故，且已數天沒有回應。沒有錯誤訊息。您尚未傳送通知電子郵件。您尚未傳送文字通知。您尚未在社交媒體上分享資訊。您的客戶感到沮喪，正在尋找能夠支援他們的其他廠商。 + 週一，您的應用程式在進行修補之後發生問題，並中斷運作了幾個小時。週二，您的應用程式在程式碼部署之後發生問題，且效能不可靠的情況持續數小時。週三，您的應用程式在進行程式碼部署 (以減輕與失敗修補相關之安全性弱點的影響) 後出現問題，且無法使用的情況持續數小時。週四，沮喪的客戶開始尋找可以支援他們的其他廠商。 + 這個週末您的應用程式將會中斷運作以進行維護。您沒有通知客戶。您的部分客戶已排定會用到您應用程式的活動。他們在發現您的應用程式無法使用時感到非常沮喪。 **建立此最佳實務的優勢：** 透過定義通知、通知觸發條件和通知程序，讓您的客戶可以在工作負載的問題影響他們時，收到通知和回應。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 啟用推送通知：就服務受到影響以及服務恢復正常，直接與您的使用者溝通 (例如，透過電子郵件或 SMS)，以便使用者能夠採取適當措施。 + [Amazon SES 功能](https://aws.amazon.com/ses/details/) + [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) + [設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) ## 資源 **相關文件：** + [Amazon SES 功能](https://aws.amazon.com/ses/details/) + [設定 Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) + [什麼是 Amazon SES？](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) # OPS10-BP06 透過儀表板傳達狀態 提供針對其目標受眾 (例如，內部技術團隊、領導和客戶) 量身定制的儀表板，以傳達業務的當前營運狀態，並提供感興趣的指標。 您可以使用 [Amazon CloudWatch 儀表板](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 建立儀表板，它位於 CloudWatch 主控台中的自訂首頁上。您可以使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧服務，建立和發佈工作負載和營運運作狀態 (例如，下單率、連線的使用者和交易時間) 的互動式儀表板。建立儀表板，以顯示指標的系統和業務等級檢視。 **常用的反模式：** + 根據要求，您執行應用程式目前使用率的報告來進行管理。 + 在事故期間，相關系統擁有者每 20 分鐘就會聯絡您一次，想知道問題是否已修正。 **建立此最佳實務的優勢：** 透過建立儀表板，您可以自助存取資訊，讓您的客戶能夠自行獲得相關資訊並自行判斷是否需要採取動作。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 透過儀表板溝通狀態：提供針對其目標受眾 (例如，內部技術團隊、領導階層和客戶) 量身定制的儀表板，以傳達企業的當前營運狀況，並提供感興趣的指標。提供自助獲取狀態資訊選項，減少因回應營運團隊狀態請求而造成的干擾。範例包括 Amazon CloudWatch 儀表板和 AWS Health 儀板表。 + [CloudWatch 儀表板建立和使用自訂指標檢視](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) ## 資源 **相關文件：** + [Quick](https://aws.amazon.com/quicksight/) + [CloudWatch 儀表板建立和使用自訂指標檢視](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) # OPS10-BP07 自動回應事件 自動對事件進行回應，以減少由手動程序引起的錯誤，並確保快速一致的回應。 有多種方式可以在 AWS 上將執行手冊和程序手冊動作自動化。若要回應來自 AWS 資源狀態變更的事件，或您自己的自訂事件，您應建立 [CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 透過 CloudWatch 目標觸發回應 (例如，Lambda 函數、Amazon Simple Notification Service (Amazon SNS) 主題、Amazon ECS 任務，以及 AWS Systems Manager Automation)。 要回應超過資源臨界值的指標 (例如，等待時間)，您應使用建立 [CloudWatch 警示，](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 來執行一個或多個動作，方法為使用 Amazon EC2 動作、Auto Scaling 動作，或將通知傳送至 Amazon SNS 主題。如果您需要執行自訂動作來回應警示，則請透過 Amazon SNS 通知叫用 Lambda。使用 Amazon SNS 發佈事件通知和向上呈報訊息，以使人們了解情況。 AWS 還可透過 AWS 服務 API 和 SDK 支援第三方系統。AWS 合作夥伴和第三方提供了許多監控工具，可用於監控、通知和回應。其中一些工具包含 New Relic、Splunk、Loggly、SumoLogic 和 Datadog。 當自動化程序失敗時，您應保留重要的手動程序以供使用 **常用的反模式：** + 開發人員檢查其程式碼。此事件原本可能用於啟動建置，然後執行測試，不過沒有發生任何情況。 + 您的應用程式會在停止運作之前記錄特定錯誤。您應非常了解重新啟動應用程式的程序，且可以編寫此程序的指令碼。您可以使用日誌事件來叫用指令碼，並重新啟動應用程式。相反地，當星期日凌晨 3 點發生錯誤時，您做為負責修正系統的待命資源將被喚醒。 **建立此最佳實務的優勢：** 透過對事件使用自動回應，您可以縮短回應時間，並限制手動活動引入錯誤。 **若未建立此最佳實務，暴露的風險等級為：** 低 ## 實作指引 + 將事件的回應自動化：自動對事件進行回應，以減少由手動流程引起的錯誤，並確保快速、一致的回應。 + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) + [建立隨事件觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) + [使用 AWS CloudTrail 建立隨 AWS API 呼叫觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) + [來自所支援服務的 CloudWatch Events 事件範例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) ## 資源 **相關文件：** + [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/) + [來自所支援服務的 CloudWatch Events 事件範例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) + [使用 AWS CloudTrail 建立隨 AWS API 呼叫觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) + [建立隨事件觸發的 CloudWatch Events 規則](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) + [什麼是 Amazon CloudWatch Events？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) **相關影片：** + [制定監控計劃](https://www.youtube.com/watch?v=OMmiGETJpfU) **相關範例：** # 演進 **Topics** + [OPS 11  您如何改善營運？](w2aac19b5c11b5.md) # OPS 11  您如何改善營運？ 投入時間和資源持續逐漸改善，以加強營運的效果和效率。 **Topics** + [OPS11-BP01 建立持續改進程序](ops_evolve_ops_process_cont_imp.md) + [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md) + [OPS11-BP03 實作回饋迴圈](ops_evolve_ops_feedback_loops.md) + [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md) + [OPS11-BP05 定義改進驅動因素](ops_evolve_ops_drivers_for_imp.md) + [OPS11-BP06 驗證洞見](ops_evolve_ops_validate_insights.md) + [OPS11-BP07 執行營運指標審查](ops_evolve_ops_metrics_review.md) + [OPS11-BP08 記錄和分享獲得的經驗](ops_evolve_ops_share_lessons_learned.md) + [OPS11-BP09 分配改進時間](ops_evolve_ops_allocate_time_for_imp.md) # OPS11-BP01 建立持續改進程序 定期評估改進機會並排定其優先順序，以專注於它們可在其中提供最大效益的工作。 **常用的反模式：** + 您已記錄建立開發或測試環境所需的程序。您可以使用 CloudFormation 將該程序自動化，但您卻從主控台手動執行程序。 + 您的測試顯示，應用程式內絕大多數的 CPU 使用率都屬於一小組缺乏效率的功能。您可以專注於改進這些功能並降低成本，但您的任務是建立新的可用性功能。 **建立此最佳實務的優勢：** 透過持續改進提供一種機制，以定期評估改進機會、排定機會的優先順序，並專注於它們可在其中提供最大效益的工作。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 + 定義持續改進程序：定期評估改進機會並確定優先級，以將精力集中在可以帶來最大收益的機會上。實作變更以改善結果，並進行評估以確定成功與否。如果結果未能達到目標，並且改進仍然是優先事項，則使用其他行動方案重複進行。您的營運流程應設立專門的時間和資源，用於持續逐漸改善。 # OPS11-BP02 執行事故後分析 審查影響客戶的事件，並識別造成問題的因素和預防性措施。使用此資訊來開發緩解措施，以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。 **常用的反模式：** + 您管理應用程式伺服器。大約每 23 小時 55 分鐘，所有作用中工作階段都會終止。您已嘗試識別應用程式伺服器上發生了什麼問題。您懷疑這反而可能是網路問題，但無法與網路團隊合作，因為他們太忙而無法為您提供支援。您缺少可遵循的預先定義程序來取得支援與收集必要資訊，以判斷發生的情況。 + 您的工作負載內發生資料遺失問題。這是第一次發生，原因尚不確定。您確定它並不重要，因為您可以重新建立資料。資料遺失以影響客戶的較高頻率開始發生。當您還原遺失的資料時，這也會為您帶來額外的操作負擔。 **建立此最佳實務的優勢：** 透過預先定義的程序來判斷造成事件的元件、條件、動作和事件，讓您能夠找出改進機會。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 使用程序判斷成因：審查所有影響客戶的事故。建立程序來識別和記錄事件的成因，以便您可以制定緩解措施來限制或防止事件再次發生。另外，您還可以制定快速有效地做出回應的程序。根據目標受眾的不同以適當的方式告知根本原因。 # OPS11-BP03 實作回饋迴圈 回饋迴圈提供可推動決策的可行洞察。在程序和工作負載中建立回饋迴圈。此可協助您找出問題和需要改善的地方。回饋迴圈也會驗證在改善中所做的投資。這些回饋迴圈是持續改善工作負載的基礎。 回饋迴圈分為兩種： *即時回饋* 和 *追溯性分析*。透過審查營運活動的績效和成果來收集即時的回饋。此回饋來自團隊成員、客戶或活動的自動化輸出。接收 A/B 測試和交付新功能等方面的即時回饋，對於快速檢錯非常重要。 定期進行追溯性分析，以從對營運成果和指標的審查中獲取回饋。這些追溯性分析會在衝刺結束，按規律或在主要版本或事件後發生。這類回饋迴圈會驗證對營運或工作負載所做的投資。其可協助您衡量成功並驗證策略。 **預期成果：** 您使用即時回饋和追溯性分析來推動改善。存在可擷取使用者和團隊成員回饋的機制。追溯性分析會用來找出可推動改善的趨勢。 **常見的反模式：** + 您推出新功能，但沒有辦法收到客戶對該功能的回饋。 + 針對營運改善投入資源和時間後，您無法執行追溯性分析來進行驗證。 + 您收集客戶的回饋，但未能定期審查回饋。 + 回饋迴圈讓我們得以提議行動項目，但軟體開發程序中未納入這些項目。 + 客戶沒有收到他們提議之改善的回饋。 **建立此最佳實務的優勢：** + 您可以反過來與客戶合作來推動新功能。 + 您的組織文化可以更快速地應對變化。 + 趨勢會用來找出改善的機會。 + 追溯性分析可驗證對工作負載和營運所做的投資。 **若未建立此最佳實務，暴露的風險等級：** 高 ## 實作指引 實作此最佳實務表示您同時使用即時回饋和追溯性分析。這些回饋迴圈可推動改善。有許多機制可用來處理即時回饋，包含調查、客戶投票和回饋表單。組織也會使用追溯性分析來找出改善的機會並驗證計劃。 **客戶範例** AnyCompany Retail 建立網頁表單，客戶可在其中提供回饋或回報問題。在每週 Scrum 期間，軟體開發團隊會評估使用者回饋。該團隊會定期使用回饋來為其平台的發展釐清方向。他們會在每次衝刺結束時執行追溯性分析，來找出他們想要改善的項目。 ## 實作步驟 1. 即時回饋 + 您需要制定機制來接收來自客戶和團隊成員的回饋。您也可以設定營運活動來提供自動化的回饋。 + 組織需要制定程序來審查此回饋、判斷需要改善的項目，並安排改善項目。 + 您必須將回饋新增至軟體開發程序。 + 在您著手改善後，請與回饋提交者追蹤後續進展。 + 您可以使用 [AWS Systems Manager OpsCenter，](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 以 OpsItems 的形式 [建立和追蹤這些改善](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html)。 1. 追溯性分析 + 在開發週期結束時，以固定的規律或在主要版本之後，執行追溯性分析。 + 召集工作負載中參與的利害關係人，進行回顧會議。 + 在白板或試算表建立三個欄位：停止、開始和持續。 + *停止* 是您希望團隊停止做的任何事。 + *開始* 是您希望開始執行的想法。 + *持續* 是您希望持續執行的項目。 + 詢問在場人士的想法，收集利害關係人的回饋。 + 排列回饋的優先順序。將動作和利害關係人指派至任何「開始」或「持續」項目。 + 將動作新增至軟體開發程序中，並在您執行改善項目時向利害關係人告知最新的狀態。 **實作計劃的工作量：** 中。若要實作此最佳實務，您需要找到方法來擷取即時回饋並進行分析。此外，您需要建立追溯性分析程序。 ## 資源 **相關的最佳實務：** + [OPS01-BP01 評估外部客戶需求](ops_priorities_ext_cust_needs.md)：回饋迴圈是一種機制，可收集外部客戶的需求。 + [OPS01-BP02 評估內部客戶需求](ops_priorities_int_cust_needs.md)：內部利害關係人可以使用回饋迴圈來表達需要和需求。 + [OPS11-BP02 執行事故後分析](ops_evolve_ops_perform_rca_process.md)：事件後分析是在事件後執行的追溯性分析的一種重要形式。 + [OPS11-BP07 執行營運指標審查](ops_evolve_ops_metrics_review.md)：營運指標審查會找出趨勢和待改善的地方。 **相關文件：** + [建置 CCOE 時應避開的 7 大陷阱](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) + [Atlassian 團隊程序手冊 - 追溯性](https://www.atlassian.com/team-playbook/plays/retrospective) + [電子郵件定義：回饋迴圈](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/) + [根據 AWS Well-Architected Framework 審查建立回饋迴圈](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/) + [IBM Garage Methodology - 進行回顧](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) + [Investopedia – PDCS 週期](https://www.investopedia.com/terms/p/pdca-cycle.asp) + [最大化開發人員的效能 (作者：Tim Cochran)](https://martinfowler.com/articles/developer-effectiveness.html) + [營運準備度審查 (ORR) 白皮書 - 反覆執行](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) + [TIL CSI - 持續服務改善](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement) + [當 Toyota 遇見電子商務：Amazon 的精實原則](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) **相關影片：** + [建立有效的客戶回饋迴圈](https://www.youtube.com/watch?v=zz_VImJRZ3U) **相關範例： ** + [Astuto - 開放原始碼客戶回饋工具](https://github.com/riggraz/astuto) + [AWS 解決方案 - AWS 上的 QnABot](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) + [Fider - 整理客戶回饋的平台](https://github.com/getfider/fider) **相關服務：** + [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) # OPS11-BP04 知識管理 存在的機制讓您的團隊成員可以及時探索他們所需的資訊、存取資訊，並識別其是否為最新且完整的資訊。存在的機制是用來識別所需的內容、需要重新整理的內容，以及應存檔的內容，以便該內容不再供其他人參考。 **常用的反模式：** + 一個感到沮喪的客戶開立了新產品功能請求的支援案例，以處理感知的問題。它會新增到優先改進項目的清單中。 **若未建立此最佳實務，暴露的風險等級為：** 高 ## 實作指引 + 知識管理：確保存在的機制讓您的團隊成員可以及時探索他們所需的資訊、存取資訊，並識別其是否為最新且完整的資訊。維護機制，以識別所需的內容、需要重新整理的內容，以及應存檔的內容，以便該內容不再供其他人參考。 # OPS11-BP05 定義改進驅動因素 確定改進驅動因素，以幫助您評估改進機會並排定其優先順序。 在 AWS 上，您可以彙整所有營運活動、工作負載和基礎設施的日誌，以建立詳細的活動歷史記錄。然後，您可以使用 AWS 工具，分析某段時間內的營運和工作負載運作狀態 (例如，識別趨勢、將事件和活動與成果關聯，以及在環境間和跨系統進行比較和對比)，根據驅動因素來發現改善機會。 您應使用 CloudTrail 追蹤 API 活動 (透過 AWS 管理主控台、CLI、SDK 和 API)，以了解整個帳戶中發生的情況。使用 CloudTrail 和 CloudWatch 追蹤您的 AWS 開發人員工具部署活動。這樣會將部署及其成果的詳細活動歷史記錄新增至 CloudWatch Logs 日誌資料中。 [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，您可以探索和準備 Amazon S3 中的日誌資料以進行分析。使用 [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，透過與 AWS Glue 原生整合來分析日誌資料。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料 **常用的反模式：** + 您有一個可運作但不巧妙的指令碼。您投入時間來重新撰寫它。現在該指令碼相當出色。 + 您的新創公司正嘗試從創投家獲得另一批資金。他們希望您證明 PCI DSS 的合規性。您想要讓客戶滿意，因此您以文件記錄合規情況，但錯過提供給客戶的交付日期，而失去該客戶。做這件事沒有錯，但現在您不知道這是否是對的。 **建立此最佳實務的優勢：** 藉由決定您想要用於改進的條件，您可以將事件型動機或情緒投資的影響降到最低。 **若未建立此最佳實務，暴露的風險等級為：** 中 ## 實作指引 + 了解改進驅動因素：僅在支援理想結果時才對系統進行變更。 + 所需能力：在評估改進機會時，評估所需的功能和能力。 + [AWS 最新消息](https://aws.amazon.com/new/) + 不可接受的問題：在評估改進機會時，評估不可接受的問題、錯誤和弱點。 + [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) + 合規要求：在審查改進機會時，評估保持法規、政策的遵從性或保持受到第三方支援所需的更新和變更。 + [AWS 合規](https://aws.amazon.com/compliance/) + [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) + [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) ## 資源 **相關文件：** + [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) + [Quick](https://aws.amazon.com/quicksight/) + [AWS 合規](https://aws.amazon.com/compliance/) + [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) + [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) + [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) + [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) + [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) + [AWS 最新消息](https://aws.amazon.com/new/) # OPS11-BP06 驗證洞見 與跨職能團隊和企業擁有者一起審查您的分析結果和回應。透過這些審查建立共識，確定其他影響並確定行動方案。適當調整回應。 **常用的反模式：** + 您看到系統上的 CPU 使用率為 95%，並優先找出降低系統負載的方法。您確定最佳行動方案是擴充。該系統是轉碼器，系統會擴展到一直以 95% 的 CPU 使用率執行。系統擁有者可能向您解釋情況，並讓您聯絡他們。您的時間被浪費了。 + 系統擁有者堅稱系統是任務關鍵性系統。系統未放置在高安全性的環境中。為改善安全性，您實作任務關鍵性系統所需的額外偵測和預防性控制措施。您通知系統擁有者工作已完成，且其需為其他資源支付相應費用。在此通知之後的討論中，系統擁有者了解了其系統不符合的任務關鍵系統的正式定義。 **建立此最佳實務的優勢：** 透過與企業擁有者和領域專家驗證洞見，您可以建立共識並更有效地引導改進。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 驗證洞見：與企業擁有者和領域專家互動，確保您收集資料的意義得到眾人理解和同意。識別其他疑慮、潛在影響，並確定行動方案。 # OPS11-BP07 執行營運指標審查 與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。透過這些審查確定改進機會、可能的行動方案並分享獲得的經驗。 尋找所有環境 (例如開發、測試和生產) 中的改善機會。 **常用的反模式：** + 您的維護時段中斷了重要的零售促銷。如果還有其他影響企業的事件，企業仍然不知道是否有可能會延遲的標準維護時段。 + 您使用組織中常用的錯誤程式庫，因此您經歷了長時間的中斷。之後您已遷移到可靠的程式庫。組織中的其他團隊不知道他們正面臨風險。如果你們定期會面並審查此事故，他們就會注意風險。 + 轉碼器的效能一直在穩定地下降，並影響媒體團隊。這還不是很令人震驚。除非該情況嚴重到足以造成事故，否則您將無法查明該情況。如果您與媒體團隊審查營運指標，則有機會識別指標及其體驗的變更並解決問題。 + 您沒有審查對客戶 SLA 的滿意度。您有不符合客戶 SLA 的趨勢。不符合客戶 SLA，會產生相關的財務處罰。如果你們定期會面，並審查這些 SLA 的指標，您將有機會識別並解決問題。 **建立此最佳實務的優勢：** 透過定期會議以審查營運指標、事件和事故，您可以在團隊間維持共識、分享獲得的經驗，並可以排定改進項目的優先順序並鎖定改進目標。 **若未建立此最佳實務，暴露的風險等級：** 中 ## 實作指引 + 營運指標審查：與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。與包括業務、開發和營運團隊在內的利害關係人進行互動，以驗證您從即時回饋和追溯性分析獲得的發現，並分享經驗教訓。利用這些洞見確定改進機會和可能的行動方案。 + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) ## 資源 **相關文件：** + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) + [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) + [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) # OPS11-BP08 記錄和分享獲得的經驗 記錄並分享從營運活動中獲得的經驗，以便您可以在內部以及跨團隊使用它們。 您應分享您的團隊獲得的經驗，以提高整個組織的效益。您希望分享資訊和資源，以防止可避免的錯誤並簡化開發工作。如此可讓您聚焦於提供所需的功能。 使用 AWS Identity and Access Management (IAM) 定義權限，從而實現對您希望在帳戶內及帳戶間分享的資源的受控存取。然後，您使用版本控制的 AWS CodeCommit 儲存器來分享應用程式程式庫、執行指令碼的程序、程序文件及其他系統文件。透過分享對 AMI 的存取以及授權跨帳戶使用 Lambda 函數，進而分享您的運算標準。您還應將基礎設施標準作為 AWS CloudFormation 範本進行分享。 透過 AWS API 和 SDK，您可以整合外部和第三方工具及儲存器 (例如 GitHub、BitBucket 和 SourceForge)。分享您獲得的經驗和開發的知識時，請小心建構權限，以確保分享的儲存器的完整性。 **常用的反模式：** + 您使用組織中常用的錯誤程式庫，因此您經歷了長時間的中斷。之後您已遷移到可靠的程式庫。組織中的其他團隊不知道他們正面臨風險。如果您在此程式庫中記錄和分享您的經驗，他們會注意風險。 + 您已在內部共用的微型服務中找出導致工作階段終止的邊緣案例。您已更新對服務的呼叫，以避免此邊緣案例。組織中的其他團隊不知道他們正面臨風險。如果您在此程式庫中記錄和分享您的經驗，他們會注意風險。 + 您已找到一個方法，可大幅降低其中一個微型服務所需的 CPU 使用率。您不知道是否有任何其他團隊可以利用此技術。如果您在此程式庫中記錄和分享您的經驗，其他團隊將有機會這樣做。 **建立此最佳實務的優勢：** 分享獲得的經驗以協助改進並將經驗的好處發揮到最大。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 記錄和分享獲得的經驗：制定程序來記錄從執行營運活動和追溯性分析中學到的經驗教訓，以便其他團隊可以使用。 + 分享經驗：制定程序來在團隊之間分享經驗教訓和相關成品。例如，透過可存取的 Wiki 分享更新的程序、指引、管控和最佳實務。透過公共儲存庫共用指令碼、程式碼和程式庫。 + [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) + [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) + [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) + [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) + [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) + [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) ## 資源 **相關文件：** + [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) + [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) + [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) + [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) + [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) **相關影片：** + [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) # OPS11-BP09 分配改進時間 在流程中投入時間和資源，以持續逐漸改善。 在 AWS 上，您可以建立臨時環境複本，從而降低試驗和測試的風險、工作量及成本。這些重複的環境可用於測試從您的分析、試驗和開發得出的結論，以及測試計劃的改善。 **常用的反模式：** + 您的應用程式伺服器存在已知的效能問題。它會新增到每個計劃功能實作的待辦項目中。如果計劃功能的新增速率保持不變，則效能問題永遠不會解決。 + 為協助持續改進，您核准管理員和開發人員使用他們額外的時間來選取和實作改進項目。進改永遠不會有完成的一天。 **建立此最佳實務的優勢：** 透過在程序中投入時間和資源，您可以實現持續逐漸改善。 **若未建立此最佳實務，暴露的風險等級：** 低 ## 實作指引 + 分配改進時間：在流程中投入時間和資源，以持續逐漸改善。實作變更以改進和評估結果，從而確定成功與否。如果結果未能達到目標，並且改進仍然是優先事項，則應採取替代行動方案。