オペレーショナルエクセレンス設計の原則

[アーティクル]
11/15/2023

オペレーショナルエクセレンスの柱の中核となるのは、 標準化されたワークフローとチームのまとまりによってワークロードの品質を確保する DevOps プラクティスです。この柱は、 開発プラクティス、可観測性、リリース管理の運用手順を定義します。目標は、プロセスの分散、人的エラーの可能性、および顧客への中断を最小限に抑することです。運用の正常性を評価するには、次の質問から始めます。

規範を使用して操作を実行しますか?
顧客は、予測可能性を最大限に高め、ワークロードを使用していますか?
継続的な改善を推進するために、経験と収集されたデータからどのように学習しますか?

明確な所有権やリーダーシップがない場合、ワークロード操作は混沌としたプラクティスに陥る可能性があります。この種の環境では、チームは多くの場合、高い労力で実行され、結果が低く、ユーザーエクスペリエンスが低下する方法に頼ります。これらのアプローチは、短期的な目標のみを満たしています。長期的な利益は、 継続的な評価と戦略的投資によって実現されます。

設計原則は、 症状を治療するだけでなく、基になる原因に対処するために考慮する必要がある運用戦略のガイドラインを提供します。推奨されるアプローチから始めて、何が機能し、改善の領域を特定できないかを確認します。戦略を設定したら、 オペレーショナルエクセレンスチェックリストを使用して引き続きアクションを推進します。

ワークロードの運用要件は、ビジネス要件と同じくらい重要です。効率的なプロセスにより、コンプライアンスが組織か外部かに関係なく、コンプライアンスの制約内でワークロードがビジネス成果を達成します。重要なのは、一貫性のある繰り返し性を見つけることです。

オペレーショナルエクセレンスの柱の目標は 、正しいことを行い、それを正しい方法で行い、チームとして適切な問題を解決することです。

これらの目標を達成した場合、ワークロードは変更の時間帯でも確実かつ予測可能に実行されます。 運用要件を満たせないと、デプロイの失敗、ユーザーエクスペリエンスの一貫性が失われ、適切な計画と合理化された実行によって回避できたコストが追加される可能性があります。

DevOps カルチャを採用する

コラボレーション、共有責任、所有権の考え方と協力して、開発チームと運用チームがシステム設計とプロセスを継続的に改善できるようにします。

DevOps は、視点とスキルの多様性が 1 つのミッションに向かって推進する実践コミュニティです。チームは、サイロ化された学習ではなく 、共有された知識のコラボレーション環境を促進 する必要があります。共有関数を使用して、リソースの制約を克服します。

優れた DevOps カルチャは、共同責任で繁栄します。開発チームと運用チームは、目標と優先順位を顧客の期待に合わせ、ビジネスに集中する必要があります。開発チームは、フィードバックループに運用チームを含める必要があります。そのため、改善はアップストリームに推進され、他のチームも同様にメリットを得られます。逆に、運用チームは、ワークロードに関連するリソースとフィードバックを共有することで、開発チームがビジネス成果を成功させる責任があります。

同時に、DevOps プラクティスは、 明確な所有権と説明責任を各チームに適用します。アプリケーションの実行場所に関係なく、ワークロードチームはそのアプリケーションを担当します。

DevOps は、運用タスクを最適化して、効果的ですが負担がないようにします。 DevOps の利点を最大限に活用するには、テクノロジを使用してプロセスを最適化し、organizationのユーザーが透過的なコミュニケーションを促進するためのプロセスを用意する必要があります。

アプローチ	メリット
コミュニケーションと進捗の追跡のためにコラボレーション環境を促進する一般的なシステムとツールを使用します。	一般的なツールとプロセスにより、透過的な通信が可能になります。開発チームと運用チームの両方が、さまざまな環境での状況認識、一般的なサポートの問題、全体的な課題と勝利の恩恵を受けます。インシデントがある場合、Teams は既存のエスカレーションパスに既に慣れているでしょう。共有バックログを使用すると、新機能の作業やバグの修正などの優先順位が明確になります。
開発サイクル全体を通じて、継続的な学習と実験の考え方を構築します。チーム間での知識共有をサポートし、再利用のためにドキュメントを維持します。責任のない分析を実施し、リリース後やインシデント後のレビューを報告します。	A/B テストや概念実証の開発などの実験メカニズムを使用して、コストを低く抑えながらイノベーションを促進できます。チームが設計アプローチ、ツール、プロセスに習熟するコラボレーションを通じて知識を共有します。プロジェクトの後に振り返りを行うと、改善のための領域を特定し、成功を祝うのに役立ちます。
アクションの最適化に重点を置く実証済みの業界アジャイルプラクティスを採用します。手動および自動化されたプロセス、デプロイと品質保証のプラクティス、および可観測性のために、運用で "左にシフト" する機会を探します。	アジャイル開発プラクティスは、ビジネス価値の指標であるリリースライフサイクルの短縮につながります。多くの場合、問題の検出、解決、および以前の問題の防止は、プロセスに対する侵入が少なくなります。
すべての開発および運用手順の標準を設定し、定期的に確認および検証します。これらの手順には、定期的なタスク、帯域外プロセス、緊急訓練と状況、ツールの選択、監視手順、スキルプラン、さらには利害関係者や顧客の開示とのコミュニケーションが含まれます。自分の決定について意図的かつ明示的に行う。	標準により、運用に予測可能性が追加され、プロセスとプラクティスがスケーラブルになります。標準の検証は、改善点を引き出す優れた方法です。定期的な訓練を実施し、緊急時や復旧状況に備える。正確に実行し、ガバナンスを有効にして、リスクにつながる異常を防ぎます。
専門的なスキルと幅広い経験を持つ一元化された運用チームを活用します。	運用とリソースの両方に共有リソースを使用すると、コスト上のメリットがあります。ワークロードを所有していますが、一元化されたチームは、インシデント管理、監視に関するプロアクティブな視点、信頼を持つアウトソーシングの専門知識など、部門間のスキルを支援します。

開発標準を確立する

体系的な変更管理を通じて、開発プラクティスを標準化し、品質ゲートを適用し、進行状況と成功を追跡することで、生産性を最適化します。

開発チームは、リリース前のワークロードの問題に最小限の摩擦で対処する責任があります。開発者の効率性に注意し、コーディングからテスト結果まで、 迅速なターンアラウンドサイクルに合わせて最適化してください。技術的な活動を計画および標準化し、チームと利害関係者の合意を促進する、効果的で適切なサイズのプロセスを実装します。

アプローチ	メリット
ワークロード機能を文書化し、顧客の利点を把握します。アーキテクチャのスコープと詳細な機能要件と非機能要件を派生させます。サイズ見積もりモデルを作成して、関連するタスクのスコープとコストについてレポートします。	優れた仕様により、より生産的で合理化された開発サイクルをサポートすることで、運用コストと障害の可能性を削減できます。開発者は、コーディングサイクルを開始する前に、技術的な設計、目標、および完了基準を理解します。適切なドキュメントにより、新しいチームメンバーの繰り返し可能なコミュニケーションとオンボーディングが容易になります。
ワークロードとチームサイズのニーズに合わせて適切に調整された業界標準のソフトウェア開発手法を使用します。すべてのロール間で共有されるバックログを維持します。	既知の手法を採用すると、プロジェクトのリズムが設定されます。チームメンバーに明確な期待と説明責任を与えることで、プロセスのあいまいさを取り除きます。一般的なリストに対して追跡することで、標準のプラクティスを使用してタスクを絞り込み、優先順位を付けることができます。このプロジェクトは、時間に応じて提供される可能性が高くなります。標準的な手法は、リスク管理に役立ちます。詳細なマイルストーンレビューを使用すると、開発者はショートッパーになる前に潜在的な問題に対処できます。
すべてのコード、スクリプト、デプロイテンプレート、パイプライン定義、および関連ドキュメントに統合ソース管理を使用します。分岐戦略では、独立した相互依存機能、バグ修正プログラム、修正プログラムの摩擦のないリリースをサポートする必要があります。 organization全体で共有ナレッジを使用して、ブランチ戦略とデプロイプロセスを構築します。	ソース管理を適切に使用することは、同時変更とバージョン管理をサポートする上で重要です。さまざまなサイズとリスクの変更をリリースするための反復可能なワークフローを維持し、プロセスの一環としてピアレビューを実施し、監査証跡を保持します。
開発ライフサイクルの早い段階でテストを重視する品質保証プロセスを実施します。機能リリースまたは更新プログラムの一部であるアプリケーションコンポーネント、インフラストラクチャ、データプレーン操作など、計画されたテスト手順のすべての成果物を含めます。成果物は、環境を通じて昇格されるときに不変として扱い、品質ゲートを通過するたびに信頼を得ます。実用的な場合は、ルーチンチェックを自動化します。	品質保証により、機能要件と非機能要件が確実に満たされ、顧客へのプラスの影響が生まれます。テスト計画を立て、品質と完全性を確保し、考えられる障害ケースを考慮します。品質ゲートを使用すると、リスクを軽減するためのベストプラクティスを適用できます。不変性は、テストするシステムがリリースされたシステムであることを保証するため、信頼度をもたらします。品質基準が満たされない限り、テストサイクルによって進行状況が効率的にブロックされます。
規則を適用するスタイルガイドとツールを使用して一貫性を高め、開発、テスト、利害関係者とのコミュニケーションに共通のツールチェーンを採用します。開発者向けのテクノロジ標準では、パターン、API 設計、ログ記録、例外処理、その他のプロセスの実装が必要です。	コードの一貫性により、読みやすく、メンテナンスが容易になります。また、複雑さが軽減され、コードの再利用が可能になります。一般的なツールと規則は、チームが 1 回限りの選択に対処することなくプロセスを最適化するのにも役立ちます。
記述されているコードの開発者ドキュメントを一貫して意図的に主張します。	コードドキュメントを明確にすると、古いコードを再検討する必要がある場合や、開発チームがローテーションするときに、ロジックと機能を簡単に理解できます。
進捗状況と傾向を報告して効率を測定します。	バグ、失敗した更新、デプロイまでの時間、フィードバックループ、その他のメトリックの傾向が公開され、改善が促進されます。

可観測性を使用して操作を進化させる

システムを可視化し、分析情報を導き出し、データドリブンの意思決定を行います。

ワークロードを監視し、Azure Well-Architected Framework のすべての柱 を考慮することで、品質 を継続的に向上させるカルチャを構築します。必要なデータ、統計、傾向を提供することで、チームと利害関係者が多くの面で短期的および長期的な意思決定を行えるようにします。データから学習し、改善を推進します。

可観測性を目的として構築された運用は、アプリケーション、品質とセキュリティの保証、容量計画、製品管理のプロアクティブなメンテナンスの鍵となります。

監視の重要な側面は、 正常性モデリングを使用したアプリケーションであり、インシデントになる前に問題を予測 し、カスタマーエクスペリエンスに影響を与えるのに役立ちます。効率的な監視により、インシデント管理に費やされる事後対応サイクルが削減されます。

アプローチ	メリット
独自のスタックとフローを使用して監視システムを構築します。監視システムは、そのユーティリティから切り離されたワークロードのディメンションとして扱います。スタックは、インフラストラクチャ、アプリケーションの正常性、ビルドとリリースのプロセスを含むすべてのレイヤーをカバーする必要があります。ビジネスデータのキャプチャまたはサンプリングは、監視の実装の範囲外です。	監視とワークロードスタックを分離して、機能要件と可観測性の要件を分離し、独立した進化を可能にします。コードの変更は監視に影響を与えるべきではありません。また、その逆も同様です。監視要件は機能要件とは別であるため、構成の変更や停止の監視によってビジネスデータが中断されることはありません。
データソースの種類ごとに収集プロセスの一貫性を高めます。テレメトリ、インフラストラクチャメトリックの収集、ツールの業界標準を使用して、コード内のインストルメンテーションを標準化します。	一貫性は、類似したリソース間の知識により、データの関連付けと分析に費やされる時間が短縮されるため、検出と測定の分散を防ぎます。問題を予測するための包括的な視点があります。
実行フローの主要なポイントを関連付け、さまざまなレベルの粒度でエンドツーエンドのビューを提供するアプリケーションコードからテレメトリを生成します。	重大度レベルに基づいてアクションに優先順位を付け、その詳細度を考えるとコンテキストを理解します。この情報は、トラブルシューティングの目的で重要です。
データシンクが複数のチームによって共有され、中央チームによって管理されている場合でも、データの出力と収集の責任を負います。	監視データをワークロード環境にローカライズすることで、チームはログとメトリックにアクセスしてワークロードの懸念に対処できます。
十分なデータだけを収集し、十分な時間だけ保持します。データのログ記録と格納に関連するコストのトレードオフを検討します。	意図的なデータ収集は、必要以上のデータ収集に関連する財務コストと運用コストを最適化するのに役立ちます。ノイズを最小限に抑え、分析中の集中的な計算を回避し、不要になったデータを格納するコストを削減します。
プロファイル、ログ、メトリック、トレースなど、さまざまな監視シグナルを区別します。適切な目的で各シグナルを使用します。メトリックを使用して、数値測定に依存するアクションをトリガーする優先順位を付けます。プロファイルを使用して、システムへのメモリ割り当てなどの低レベルの可視性を取得します。ログとトレースの使用を予約して、フローと依存関係のコンテキストを提供します。	シグナルを適切な目的で使用することで、監視システムの非効率的な実装を防ぐことができます。たとえば、アクションにログを使用するには解析が必要です。メトリックを使用すると、同じ目標をより速く達成できる場合があります。
ダッシュボード内のデータを集計して視覚化し、対象ユーザーに対応し、ビジネスコンテキストを念頭に置いた監視データを表示します。状況ダッシュボードを使用してデータを表示し、関係者の意識を高めます。インシデント対応などのオペレーターアクティビティに対してドリルダウン機能を備えた運用ダッシュボードとブックを使用します。ダッシュボードを頻繁に更新し、詳細なデータを提供します。	視覚化を使用すると、傾向の分析、ビジネスターゲットに対する追跡、インシデントの管理を行うことができます。顧客の関心に合わせて調整されたダッシュボードは、解釈を関連させ、検出とアクションの時間を短縮します。
標準化された説明と重大度レベルを使用して説明責任のあるロールに通知することで、アラートをアクション可能にします。さまざまなソースから照合された情報を提供し、ビジネスターゲットからの逸脱を追跡します。アクションを必要とするインシデントに対してのみアラートをトリガーします。低下した状態が障害になる前にアクションを開始する、プロアクティブで思考を刺激するアラートに努めます。	アラートは、organizationによって定義されている重要なイベントに注意を向けます。適切なアラートシステムは、アクションと重大度を識別し、明確さと目的を推進するのに十分なデータのみを提供します。オペレーターは、修復を遅延なく開始できます。

自信を持ってデプロイする

予測可能性を使用して、デプロイの目的の状態に到達します。

ワークロードのホスティングプラットフォーム、アプリケーション、データ、および構成リソース全体で、すべての環境で予測可能性の目標を一貫して達成できるワークロードサプライチェーンを構築します。 デプロイメカニズムは、自動化、テスト、監視、バージョン管理が可能である必要があります。モジュール化し、オンデマンドで実行する準備ができている必要があります。モノリシックなエンドツーエンドプロセスとして表すべきではありません。サプライチェーンは、必ずしも実行速度を向上させるのではなく、複数のイテレーションで一貫性と自己文書化を実現するためです。

ワークロードチームは、自身のワークロードに関連するため、サプライチェーンに対して責任を負います。

アプローチ	メリット
コードとしてのインフラストラクチャ (IaC) を使用して、生産準備ができているサプライチェーンの反復可能な側面を定義します。命令型メソッドよりも宣言型のアプローチを優先します。	宣言型 IaC テクノロジは、自動化と再利用性を念頭に置いて設計されています。インフラストラクチャのデプロイを個人からツールにオフロードし、一貫した品質を実現できます。インフラストラクチャの観点から見ると、テクノロジの選択肢が少ないほど、ツールの差異が取り除き、構成ドリフトを検出しやすくなります。メンテナンスも簡単になります。チームの既存のスキルセットに選択肢を合わせれば、チームは簡単に採用できます。
選択した IaC テクノロジを使用するようにチームを準備します。その機能拡張モデル、機能、制限事項について説明します。チーム内の特殊化を活用し、organization内で知識を共有します。	スキルアップは生産性を向上させ、共有学習を通じてコラボレーションの環境を促進します。雇用の代わりにトレーニングでギャップを埋めることができます。
IaC の開発とメンテナンスに関するソフトウェアの推奨事項に従います。モデレートでモジュール化します。カスタムまたは低価値の抽象化は避けてください。さまざまなライフサイクルを反映するために、階層化されたアプローチに従います。下位レイヤーが一定であり、必要に応じて上位レイヤーが変更される基本レイヤーを形成します。アプリケーションバイナリ、IaC テンプレート、パラメーターなどのデプロイ成果物は、攻撃対象領域の一部です。シークレット管理、アクセス制御、セキュリティの柱のその他の原則などの保証を適用します。	成果物には、アプリケーションコードと同じレベルのエンジニアリングの厳しさが発生します。ピアレビューとテストによる品質管理により、デプロイに自信が持てる。階層化されたアプローチにより、メンテナンスが容易になり、明確な責任線を確立する境界が作成されます。成果物にセキュリティ制御を追加すると、デプロイプロセス中にシステムを強化するのに役立ちます。
すべての環境で使用される共通の配置マニフェストを開発します。そのマニフェストを、グリーンフィールドプロジェクト、増分ワークロード更新、またはディザスターリカバリーの既定のメカニズムとして使用します。	複数の資産を維持するオーバーヘッドを取り除く。障害が発生した場合は、即席環境を作成する代わりに、試行済みのテスト済みマニフェストをデプロイできるため、復旧は迅速かつ信頼性が高くなります。
IaC 自動化を通じてデプロイされる不変の一時的なインフラストラクチャに努めます。	構成ドリフトを禁止し、デプロイをべき等にします。この種のインフラストラクチャにより、修正プログラムの適用など、運用上の大きな負担が軽減されます。また、ブルーグリーンインフラストラクチャのデプロイなど、主要な検証シナリオにもメリットがあります。

注意

ポータルの使用状況の範囲を、繰り返し実行されていない調査タスクのみに減らします。

効率を高める自動化

繰り返しの手動タスクを、より迅速に完了し、一貫性と精度を高め、リスクを軽減するソフトウェア自動化に置き換えます。

ワークロードには、チームメンバーが、人間の知性を実際に必要としない日常的で反復的で時間のかかるタスクを実行するプロセスを含むワークフローがある場合があります。頻度によっては、これらの作業にかなりの時間を費やし、ワークロードの増加に合わせてより多くの時間を投資する場合があります。また、これらのプロセスは、人間の入力によってエラーが発生しやすいことがよくあります。

自動化により、時間、労力、コストを節約し、間違いを回避できます。

アプローチ	メリット
複雑さ、労力、頻度、精度、タイムライン、有効期間の適切なレベルにある条件に対して、すべてのワークフローを評価します。その評価に基づいてワークフローを自動化し、期待される最高のリターンでワークフローに優先順位を付けます。冗長なワークフローを削除するか、人の努力を正当化する価値を追加します。	価値の高い作業でチームの能力を再投資し、生産性と一貫性を向上させることができます。ワークフローのインベントリを作成すると、適切なタスクを確実に自動化できます。冗長タスクを削除すると、複雑さとエラーが軽減されます。
カスタムツールを構築するか、ソフトウェアを購入するかを評価するときは、決定について明確にしてください。高度に特殊化された価値の高い作業のために、ビルの自動化を予約します。	既製のソフトウェアを購入し、サポート契約を活用することで、メンテナンスコストを節約できます。ソフトウェアを構築することで、より多くの制御が可能になり、チームとワークロードに固有のユースケースに対応できます。ただし、コストへの影響があります。ツールの選択は、運用に標準化のレベルをもたらします。トレーニングを使用すると、導入に対する統一レベルの準備を実現できます。
自動化機能をサポートするようにワークロードコンポーネントを設計します。	システム設計の自動化の欠如により、反復的なタスクのアンチパターンが促進され、成長が遅くなり、技術的負債の蓄積が開始される状況を回避します。
すべての自動化をワークロードの重要な依存関係として扱います。ワークロードの予想される成長に適応します。自動化ツールはワークロードの不可欠な部分であり、5 つの Well-Architected Framework の柱に従う必要があります。	セキュリティ上の脅威などのリスクに耐えられるようにオートメーションコンポーネントを設計します。適用されたベストプラクティスを使用すると、実装のスプロールを回避できます。この依存関係が機能し、安全に保たれている場合、ワークロードは引き続き高レベルの保証で動作します。
ワークロード以外のオプションを調べ、大規模な自動化を行います。新しいプロジェクトをオンボードし、既存の設計と実装の再利用を促進するためのテンプレートとフレームワークを提供することで、"設計を 1 回、どこでも実行" モデルを優先します。	テスト済みのメソッドを採用し、失敗の可能性を減らします。

安全な展開方法を採用する

エラーや予期しない状態の影響を最小限に抑えるために、デプロイプロセスにガードレールを実装します。

開発サイクル中、ワークロード成果物は、実装とテスト、バグの修正に合わせて多くの変更を行います。

デプロイプロセスは、標準の操作手順に従う必要があります。 すべての変更は、同じレベルの厳格さを使用してデプロイする必要があります。この原則は、コード、構成、および関連するすべての成果物に等しく適用されます。重要なのは、運用環境で予測可能になるように、できるだけ早く安全なプラクティスを適用することです。エラーが顧客に到達した場合でも、復旧の変更をできるだけ早くロールアウトできる必要があります。

アプローチ	メリット
パイプラインなどの自動デプロイプロセスを使用して、変更をデプロイするプロセスを標準化します。すべての環境でパイプラインを使用する必要があります。環境ごとに資産とバージョンを分類して、簡単に追跡および識別できるようにします。	一貫したデプロイ方法により、プロセスエラーと差異によって発生する問題を減らし、ワークロードの問題に集中できます。標準化により、デプロイが安全かつ確実に、繰り返し可能に完了します。分類を使用すると、発生した以前のデプロイと問題のログを簡単に表示できます。その情報を使用して、ロールバック操作とロールフォワード操作を高速化できる場合があります。
定期的に小さな増分更新をデプロイします。	頻繁にテスト済みの小さな更新プログラムを使用すると、リリースの検証が簡単になります。フットプリントが小さいため、お客様への影響を最小限に抑えながら、より迅速にトラブルシューティングを行うことができます。
開発ライフサイクル全体でさまざまなメカニズムを使用して、更新プログラムを厳密にテストします。	開発の初期段階で問題をキャッチします。反復的な修正と一貫したデプロイプラクティスにより、更新プログラムが運用環境に対応できるようになるまでに問題が先細りになります。
デューデリジェンスを使用して、更新プログラムを段階的にロールアウトします。すべてのユーザーが更新プログラムを安全に採用するまで、インスタンスと顧客の数を徐々に増やすために制御できるデプロイモデルを使用します。	運用環境の早い段階で問題が修正されるように、各更新プログラムを制御された方法でテストします。顧客ベース全体に影響を与える問題のある更新プログラムをロールアウトしないようにします。更新プログラムが下位互換性と前方互換性があるかどうかをテストします。
デプロイエラーから迅速に復旧するための軽減戦略を用意します。この戦略では、問題の重要度に基づいてロールバックまたは転送に関する意思決定をカバーする必要があります。標準的なデプロイパイプラインを使用して修正プログラムを迅速にロールアウトできる、明確に定義されたプロセスと自動化されたシステムを用意します。	潜在的な影響の期間を短縮します。システムを以前の動作バージョンに戻すか、完全にテストされた修正プログラムを含むバージョンにロールフォワードします。
緊急時にシステムを稼働状態にリセットし、予期しない障害から回復するフォールバック計画を作成します。この戦略は、必要な場合と承認がある場合にのみ使用します。時間の経過に伴う計画の改善に努めます。	セキュリティ修復など、優先度の高い修正を迅速に追跡できます。高速パイプラインには、標準の運用手順のすべてのチェックが含まれていない場合がありますが、影響の低い障害を上回る、可能な限り最速の方法で安全なバージョンに顧客を取得できます。

次の手順

その他の概念を調べるには、オペレーショナルエクセレンスチェックリストを確認することをお勧めします。

オペレーショナルエクセレンスチェックリスト

アプローチ	メリット
コミュニケーションと進捗の追跡のためにコラボレーション環境を促進する一般的なシステムとツールを使用します。	一般的なツールとプロセスにより、透過的な通信が可能になります。開発チームと運用チームの両方が、さまざまな環境での状況認識、一般的なサポートの問題、全体的な課題と勝利の恩恵を受けます。インシデントがある場合、Teams は既存のエスカレーションパスに既に慣れているでしょう。共有バックログを使用すると、新機能の作業やバグの修正などの優先順位が明確になります。
開発サイクル全体を通じて、継続的な学習と実験の考え方を構築します。チーム間での知識共有をサポートし、再利用のためにドキュメントを維持します。責任のない分析を実施し、リリース後やインシデント後のレビューを報告します。	A/B テストや概念実証の開発などの実験メカニズムを使用して、コストを低く抑えながらイノベーションを促進できます。チームが設計アプローチ、ツール、プロセスに習熟するコラボレーションを通じて知識を共有します。プロジェクトの後に振り返りを行うと、改善のための領域を特定し、成功を祝うのに役立ちます。
アクションの最適化に重点を置く実証済みの業界アジャイルプラクティスを採用します。手動および自動化されたプロセス、デプロイと品質保証のプラクティス、および可観測性のために、運用で "左にシフト" する機会を探します。	アジャイル開発プラクティスは、ビジネス価値の指標であるリリースライフサイクルの短縮につながります。多くの場合、問題の検出、解決、および以前の問題の防止は、プロセスに対する侵入が少なくなります。
すべての開発および運用手順の標準を設定し、定期的に確認および検証します。これらの手順には、定期的なタスク、帯域外プロセス、緊急訓練と状況、ツールの選択、監視手順、スキルプラン、さらには利害関係者や顧客の開示とのコミュニケーションが含まれます。自分の決定について意図的かつ明示的に行う。	標準により、運用に予測可能性が追加され、プロセスとプラクティスがスケーラブルになります。標準の検証は、改善点を引き出す優れた方法です。定期的な訓練を実施し、緊急時や復旧状況に備える。正確に実行し、ガバナンスを有効にして、リスクにつながる異常を防ぎます。
専門的なスキルと幅広い経験を持つ一元化された運用チームを活用します。	運用とリソースの両方に共有リソースを使用すると、コスト上のメリットがあります。ワークロードを所有していますが、一元化されたチームは、インシデント管理、監視に関するプロアクティブな視点、信頼を持つアウトソーシングの専門知識など、部門間のスキルを支援します。

アプローチ	メリット
独自のスタックとフローを使用して監視システムを構築します。監視システムは、そのユーティリティから切り離されたワークロードのディメンションとして扱います。スタックは、インフラストラクチャ、アプリケーションの正常性、ビルドとリリースのプロセスを含むすべてのレイヤーをカバーする必要があります。ビジネスデータのキャプチャまたはサンプリングは、監視の実装の範囲外です。	監視とワークロードスタックを分離して、機能要件と可観測性の要件を分離し、独立した進化を可能にします。コードの変更は監視に影響を与えるべきではありません。また、その逆も同様です。監視要件は機能要件とは別であるため、構成の変更や停止の監視によってビジネスデータが中断されることはありません。
データソースの種類ごとに収集プロセスの一貫性を高めます。テレメトリ、インフラストラクチャメトリックの収集、ツールの業界標準を使用して、コード内のインストルメンテーションを標準化します。	一貫性は、類似したリソース間の知識により、データの関連付けと分析に費やされる時間が短縮されるため、検出と測定の分散を防ぎます。問題を予測するための包括的な視点があります。
実行フローの主要なポイントを関連付け、さまざまなレベルの粒度でエンドツーエンドのビューを提供するアプリケーションコードからテレメトリを生成します。	重大度レベルに基づいてアクションに優先順位を付け、その詳細度を考えるとコンテキストを理解します。この情報は、トラブルシューティングの目的で重要です。
データシンクが複数のチームによって共有され、中央チームによって管理されている場合でも、データの出力と収集の責任を負います。	監視データをワークロード環境にローカライズすることで、チームはログとメトリックにアクセスしてワークロードの懸念に対処できます。
十分なデータだけを収集し、十分な時間だけ保持します。データのログ記録と格納に関連するコストのトレードオフを検討します。	意図的なデータ収集は、必要以上のデータ収集に関連する財務コストと運用コストを最適化するのに役立ちます。ノイズを最小限に抑え、分析中の集中的な計算を回避し、不要になったデータを格納するコストを削減します。
プロファイル、ログ、メトリック、トレースなど、さまざまな監視シグナルを区別します。適切な目的で各シグナルを使用します。メトリックを使用して、数値測定に依存するアクションをトリガーする優先順位を付けます。プロファイルを使用して、システムへのメモリ割り当てなどの低レベルの可視性を取得します。ログとトレースの使用を予約して、フローと依存関係のコンテキストを提供します。	シグナルを適切な目的で使用することで、監視システムの非効率的な実装を防ぐことができます。たとえば、アクションにログを使用するには解析が必要です。メトリックを使用すると、同じ目標をより速く達成できる場合があります。
ダッシュボード内のデータを集計して視覚化し、対象ユーザーに対応し、ビジネスコンテキストを念頭に置いた監視データを表示します。状況ダッシュボードを使用してデータを表示し、関係者の意識を高めます。インシデント対応などのオペレーターアクティビティに対してドリルダウン機能を備えた運用ダッシュボードとブックを使用します。ダッシュボードを頻繁に更新し、詳細なデータを提供します。	視覚化を使用すると、傾向の分析、ビジネスターゲットに対する追跡、インシデントの管理を行うことができます。顧客の関心に合わせて調整されたダッシュボードは、解釈を関連させ、検出とアクションの時間を短縮します。
標準化された説明と重大度レベルを使用して説明責任のあるロールに通知することで、アラートをアクション可能にします。さまざまなソースから照合された情報を提供し、ビジネスターゲットからの逸脱を追跡します。アクションを必要とするインシデントに対してのみアラートをトリガーします。低下した状態が障害になる前にアクションを開始する、プロアクティブで思考を刺激するアラートに努めます。	アラートは、organizationによって定義されている重要なイベントに注意を向けます。適切なアラートシステムは、アクションと重大度を識別し、明確さと目的を推進するのに十分なデータのみを提供します。オペレーターは、修復を遅延なく開始できます。

アプローチ	メリット
コードとしてのインフラストラクチャ (IaC) を使用して、生産準備ができているサプライチェーンの反復可能な側面を定義します。命令型メソッドよりも宣言型のアプローチを優先します。	宣言型 IaC テクノロジは、自動化と再利用性を念頭に置いて設計されています。インフラストラクチャのデプロイを個人からツールにオフロードし、一貫した品質を実現できます。インフラストラクチャの観点から見ると、テクノロジの選択肢が少ないほど、ツールの差異が取り除き、構成ドリフトを検出しやすくなります。メンテナンスも簡単になります。チームの既存のスキルセットに選択肢を合わせれば、チームは簡単に採用できます。
選択した IaC テクノロジを使用するようにチームを準備します。その機能拡張モデル、機能、制限事項について説明します。チーム内の特殊化を活用し、organization内で知識を共有します。	スキルアップは生産性を向上させ、共有学習を通じてコラボレーションの環境を促進します。雇用の代わりにトレーニングでギャップを埋めることができます。
IaC の開発とメンテナンスに関するソフトウェアの推奨事項に従います。モデレートでモジュール化します。カスタムまたは低価値の抽象化は避けてください。さまざまなライフサイクルを反映するために、階層化されたアプローチに従います。下位レイヤーが一定であり、必要に応じて上位レイヤーが変更される基本レイヤーを形成します。アプリケーションバイナリ、IaC テンプレート、パラメーターなどのデプロイ成果物は、攻撃対象領域の一部です。シークレット管理、アクセス制御、セキュリティの柱のその他の原則などの保証を適用します。	成果物には、アプリケーションコードと同じレベルのエンジニアリングの厳しさが発生します。ピアレビューとテストによる品質管理により、デプロイに自信が持てる。階層化されたアプローチにより、メンテナンスが容易になり、明確な責任線を確立する境界が作成されます。成果物にセキュリティ制御を追加すると、デプロイプロセス中にシステムを強化するのに役立ちます。
すべての環境で使用される共通の配置マニフェストを開発します。そのマニフェストを、グリーンフィールドプロジェクト、増分ワークロード更新、またはディザスターリカバリーの既定のメカニズムとして使用します。	複数の資産を維持するオーバーヘッドを取り除く。障害が発生した場合は、即席環境を作成する代わりに、試行済みのテスト済みマニフェストをデプロイできるため、復旧は迅速かつ信頼性が高くなります。
IaC 自動化を通じてデプロイされる不変の一時的なインフラストラクチャに努めます。	構成ドリフトを禁止し、デプロイをべき等にします。この種のインフラストラクチャにより、修正プログラムの適用など、運用上の大きな負担が軽減されます。また、ブルーグリーンインフラストラクチャのデプロイなど、主要な検証シナリオにもメリットがあります。

アプローチ	メリット
複雑さ、労力、頻度、精度、タイムライン、有効期間の適切なレベルにある条件に対して、すべてのワークフローを評価します。その評価に基づいてワークフローを自動化し、期待される最高のリターンでワークフローに優先順位を付けます。冗長なワークフローを削除するか、人の努力を正当化する価値を追加します。	価値の高い作業でチームの能力を再投資し、生産性と一貫性を向上させることができます。ワークフローのインベントリを作成すると、適切なタスクを確実に自動化できます。冗長タスクを削除すると、複雑さとエラーが軽減されます。
カスタムツールを構築するか、ソフトウェアを購入するかを評価するときは、決定について明確にしてください。高度に特殊化された価値の高い作業のために、ビルの自動化を予約します。	既製のソフトウェアを購入し、サポート契約を活用することで、メンテナンスコストを節約できます。ソフトウェアを構築することで、より多くの制御が可能になり、チームとワークロードに固有のユースケースに対応できます。ただし、コストへの影響があります。ツールの選択は、運用に標準化のレベルをもたらします。トレーニングを使用すると、導入に対する統一レベルの準備を実現できます。
自動化機能をサポートするようにワークロードコンポーネントを設計します。	システム設計の自動化の欠如により、反復的なタスクのアンチパターンが促進され、成長が遅くなり、技術的負債の蓄積が開始される状況を回避します。
すべての自動化をワークロードの重要な依存関係として扱います。ワークロードの予想される成長に適応します。自動化ツールはワークロードの不可欠な部分であり、5 つの Well-Architected Framework の柱に従う必要があります。	セキュリティ上の脅威などのリスクに耐えられるようにオートメーションコンポーネントを設計します。適用されたベストプラクティスを使用すると、実装のスプロールを回避できます。この依存関係が機能し、安全に保たれている場合、ワークロードは引き続き高レベルの保証で動作します。
ワークロード以外のオプションを調べ、大規模な自動化を行います。新しいプロジェクトをオンボードし、既存の設計と実装の再利用を促進するためのテンプレートとフレームワークを提供することで、"設計を 1 回、どこでも実行" モデルを優先します。	テスト済みのメソッドを採用し、失敗の可能性を減らします。

アプローチ	メリット
パイプラインなどの自動デプロイプロセスを使用して、変更をデプロイするプロセスを標準化します。すべての環境でパイプラインを使用する必要があります。環境ごとに資産とバージョンを分類して、簡単に追跡および識別できるようにします。	一貫したデプロイ方法により、プロセスエラーと差異によって発生する問題を減らし、ワークロードの問題に集中できます。標準化により、デプロイが安全かつ確実に、繰り返し可能に完了します。分類を使用すると、発生した以前のデプロイと問題のログを簡単に表示できます。その情報を使用して、ロールバック操作とロールフォワード操作を高速化できる場合があります。
定期的に小さな増分更新をデプロイします。	頻繁にテスト済みの小さな更新プログラムを使用すると、リリースの検証が簡単になります。フットプリントが小さいため、お客様への影響を最小限に抑えながら、より迅速にトラブルシューティングを行うことができます。
開発ライフサイクル全体でさまざまなメカニズムを使用して、更新プログラムを厳密にテストします。	開発の初期段階で問題をキャッチします。反復的な修正と一貫したデプロイプラクティスにより、更新プログラムが運用環境に対応できるようになるまでに問題が先細りになります。
デューデリジェンスを使用して、更新プログラムを段階的にロールアウトします。すべてのユーザーが更新プログラムを安全に採用するまで、インスタンスと顧客の数を徐々に増やすために制御できるデプロイモデルを使用します。	運用環境の早い段階で問題が修正されるように、各更新プログラムを制御された方法でテストします。顧客ベース全体に影響を与える問題のある更新プログラムをロールアウトしないようにします。更新プログラムが下位互換性と前方互換性があるかどうかをテストします。
デプロイエラーから迅速に復旧するための軽減戦略を用意します。この戦略では、問題の重要度に基づいてロールバックまたは転送に関する意思決定をカバーする必要があります。標準的なデプロイパイプラインを使用して修正プログラムを迅速にロールアウトできる、明確に定義されたプロセスと自動化されたシステムを用意します。	潜在的な影響の期間を短縮します。システムを以前の動作バージョンに戻すか、完全にテストされた修正プログラムを含むバージョンにロールフォワードします。
緊急時にシステムを稼働状態にリセットし、予期しない障害から回復するフォールバック計画を作成します。この戦略は、必要な場合と承認がある場合にのみ使用します。時間の経過に伴う計画の改善に努めます。	セキュリティ修復など、優先度の高い修正を迅速に追跡できます。高速パイプラインには、標準の運用手順のすべてのチェックが含まれていない場合がありますが、影響の低い障害を上回る、可能な限り最速の方法で安全なバージョンに顧客を取得できます。

オペレーショナル エクセレンス設計の原則