次の方法で共有

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

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

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

明確な所有権やリーダーシップがない場合、ワークロード操作は無秩序なプラクティスに陥る可能性があります。 この種の環境では、チームは多くの場合、多大な労力を要する方法に頼り、低い成果しか得られず、これがユーザー エクスペリエンスの低下につながります。 これらのアプローチで達成できるのは、短期的なゴールだけです。 長期的な利益は、 継続的な評価と戦略的投資によって実現されます。

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

ワークロードの運用要件は、そのビジネス要件と同じくらい重要です。 効率的なプロセスであれば、コンプライアンスが組織的か外部的かに関わらず、該当するコンプライアンスの制約内でワークロードによるビジネス成果の達成を保証できます。 重要なのは、一貫性のある再現性を見つけることです。

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

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

DevOps 文化を受け入れる

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

DevOps とは、多様な観点とスキルを持つ人々が共に 1 つのミッションに向かって進む実践共同体です。 チームは、サイロ化された学習ではなく 、共有された知識のコラボレーション環境を育成 する必要があります。 共有される機能を使用して、リソース制約の克服を目指します。

優れた DevOps 文化は、共同責任に基づいて発展します。 開発チームと運用チームそれぞれのゴールと優先事項を顧客の期待にそろえるともに、ビジネスの焦点を常に念頭に置く必要があります。 開発チームはフィードバック ループに運用チームを関与させる必要があります。これで改善がアップストリームで推進され、他のチームも同様にメリットを得られます。 逆に、運用チームには開発チームのビジネス成果を実現させるという責任があり、そのためにワークロードに関連するリソースとフィードバックを共有します。

同時に、DevOps のプラクティスでは、 明確な所有権と説明責任が各チームに適用されます。 アプリケーションがどこで実行されるかにかかわらず、ワークロード チームはそのアプリケーションに対する責任を負います。

DevOps によって、運用タスクは効果的でありながら負担を抑えるように最適化されます。 DevOps のメリットを最大限に得るには、テクノロジを通じてプロセスを最適化するとともに、組織内の人々のために透明性のあるコミュニケーションを促進するプロセスを制定する必要があります。

方法 メリット
コミュニケーションと進捗の追跡のためにコラボレーション環境を促進する一般的なシステムとツールを使用します。 一般的なツールとプロセスにより、 透過的な通信が可能になります。 開発チームと運用チームの両方にとって、さまざまな環境、共通のサポートの問題、および全体的な課題と成功のすべてにわたって状況を認識できることは有益です。

インシデントが発生した場合でも、各チームは既存のエスカレーション パスをよく理解している状態になっています。

バックログが共有されるので、優先事項 (新機能の作業やバグの修正など) が明確になります。
開発サイクル全体を通して 、継続的な学習と実験の考え方 を構築します。

チーム間での知識共有をサポートし、再利用のためにドキュメントを維持します。

責任のない分析を実施し、リリース後やインシデント後のレビューを報告します。		 A/B テストや概念実証の開発などの実験メカニズムを通じて、コストを低く抑えながらイノベーションを促進することができます。

コラボレーションを通して知識を共有することによって、設計アプローチ、ツール、プロセスにおけるチームの能力を高めることができます。

プロジェクトの後に振り返りを行うと、 改善の領域を特定 し、成功を祝うのに役立ちます。
アクションの最適化に焦点を当てた実証済みの業界のアジャイル プラクティスを採用します。

手動および自動化されたプロセス、展開と品質保証のプラクティス、および可観測性のために、運用で "左にシフト" する機会 を探します。		 アジャイル開発プラクティスは、ビジネス価値の指標であるリリース ライフサイクルの短縮につながります。

多くの場合、問題の検出、解決、および以前の問題の防止は、プロセスへの侵入が少なくなります。
すべての開発および運用手順の標準を設定し、定期的に確認および検証します。

この手順に含まれるものとしては、定型的タスク、帯域外プロセス、緊急事態訓練と状況、ツールの選択、監視手順、スキル向上計画などがあり、さらには利害関係者とのコミュニケーションや顧客への情報開示も含まれます。

意思決定について意図的かつ明示的に行ってください。		 標準を設定しておくと、運用の予測可能性が高まるとともに、プロセスとプラクティスがスケーラブルになります。 標準が有効であることの確認は、改善点を引き出すための優れた方法です。

定期的な訓練を実施すると、緊急事態発生と復旧の状況に備えることができます。

正確に実行し、ガバナンスを有効にして、リスクにつながる 異常を防ぎます 。
特殊なスキルと豊富な経験を持つ一元化された運用チームを活用します。 運用とリソースの両方に共有リソースを使用すると、コスト上のメリットがあります。

ワークロードを所有しているが、一元化されたチームは、インシデント管理、監視に関するプロアクティブな視点、信頼を持つ専門知識のアウトソーシングなど、部門間のスキルを支援します。

開発標準を確立する

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

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

方法 メリット
ワークロード機能を文書化 し、顧客の利点を把握します。

アーキテクチャ のスコープと詳細な機能要件と非機能要件 を導き出します。

関連するタスクのスコープとコストをレポートするサイズ見積もりモデルを作成します。		 優れた仕様により、生産性と合理化された開発サイクルをサポートすることで、 運用コストと障害の可能性を削減 できます。

開発者は、コーディング サイクルを開始する前に 、技術的な設計、目標、および完了条件 を理解します。

適切なドキュメントにより、新しいチーム メンバーの反復可能な コミュニケーション と オンボーディングが 容易になります。
ワークロードとチーム サイズのニーズ に合わせて適切に調整された業界標準のソフトウェア開発手法 を使用します。

すべてのロール間で共有されるバックログを維持します。		 既知の手法を採用すると、 プロジェクトのリズムが設定されます。 期待されていることと説明責任が明確にチーム メンバーに伝えられるので、プロセスのあいまいさがなくなります。

一般的なリストに対して追跡することで、標準のプラクティスを使用して タスクを絞り込み、優先順位 を付けることができます。 プロジェクトを時間どおりに完了できる見込みが高くなります。

標準的な手法は 、リスク管理に役立ちます。 粒度の高いマイルストーン レビューによって、開発者は潜在的な問題がプロジェクトの進行を止めてしまう前に対処することができます。
すべてのコード、スクリプト、デプロイ テンプレート、パイプライン定義、および関連ドキュメントに統合ソース管理を使用します。

分岐戦略では、独立した相互に依存する機能、バグ修正、修正プログラムの摩擦のないリリースをサポートする必要があります。

組織全体で共有された知識を使用して、ブランチ戦略と展開プロセスを構築します。		 ソース管理を適切に使用することは、 同時変更 とバージョン管理をサポートする上で重要です。

さまざまなサイズとリスクの変更をリリースするための反復可能なワークフローを維持し、プロセスの一部としてピア レビューを実施し、監査証跡を保持します。
開発ライフサイクルの早い段階でテストを重視する 品質保証 プロセスを用意する。

機能のリリースまたは更新の一部であるアプリケーション コンポーネント、インフラストラクチャ、データ プレーン操作など、計画されたテスト手順のすべての成果物を含めます。

成果物は、ある環境から別の環境へと昇格されるときに不変として扱います。これで、品質ゲートを通過するたびに信頼が得られます。

可能であれば、定型的チェックを自動化します。		 品質保証によって、機能要件と非機能要件が確実に満たされているという確信を持つことができ、このことは顧客へのプラスのインパクトにつながります。

テスト計画を用意することで、品質と完全性が確保され、考えられる障害ケースが考慮されます。

品質ゲートを使用すると、リスクを軽減するためのベスト プラクティスを適用できます。

不変性は、テストするシステムがリリースされたシステムであることを保証するため、自信をもたらします。

テスト サイクルは、品質基準が満たされない限り、進行状況を効率的にブロックします。
規則を適用するスタイル ガイドとツールを使用して一貫性を促進し、開発、テスト、関係者とのコミュニケーションに共通のツール チェーンを採用します。

開発者向けのテクノロジ標準では 、 パターン、API 設計、 ログ記録、例外処理、およびその他のプロセスの実装が必要です。		 コードの一貫性により、読みやすく、メンテナンスが容易になります。 また、複雑さが軽減され、コードの再利用が可能になります。

一般的なツールと規則は、チームが 1 回限りの選択に対処することなくプロセスを最適化するのにも役立ちます。
コードが書かれる際、一貫して意図的に開発者にドキュメントの作成を求めます。 明確なコード ドキュメントにより、古いコードを再検討する必要がある場合や開発チームがローテーションするときに、ロジックと機能を簡単に理解できます。
進捗状況と傾向を報告して 効率を測定します。 バグ、失敗した更新、デプロイ時間、フィードバック ループ、その他のメトリックの傾向が公開され、改善が促進されます。

監視により運用を進化させる

目標アイコン システムを可視化し、分析情報を導き出し、データ主導の意思決定を行います。

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

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

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

方法 メリット
独自のスタックとフローを使用して監視システムを構築します。

監視システムは、そのユーティリティから切り離されたワークロードのディメンションとして扱います。 スタックは、インフラストラクチャ、アプリケーションの正常性、ビルドとリリースのプロセスを含むすべてのレイヤーをカバーする必要があります。

ビジネス データのキャプチャまたはサンプリング は、監視の実装の範囲外です。		 監視とワークロード スタックを分離して 、機能要件と可観測性の要件を分離 し、独立した進化を可能にします。 コードの変更は監視に影響を与えるべきではありません。その逆も同様です。

監視要件は機能要件とは別であるため、構成の変更や停止の監視によってビジネス データが中断されることはありません。
データ ソースの種類ごとに収集プロセスの一貫性を促進します。

テレメトリ、インフラストラクチャ メトリックの収集、ツールの業界標準を使用して、コード内のインストルメンテーションを標準化します。		 類似リソース間の知識により 、データの関連付けと分析に費やす時間が短縮されるため、一貫性によって検出と測定の分散が防止されます。 あなたは、問題を予測するための包括的な視点を持っています。

実行フローの重要なポイントを関連付け、さまざまなレベルの細分性でエンドツーエンドのビューを提供するアプリケーション コードからテレメトリを出力します。 重大度レベルに基づいてアクションに優先順位を付け、冗長さを考慮してコンテキストを理解します。 この情報は、トラブルシューティングを行う上で非常に重要です。
データ シンクが複数のチームによって共有され、中央チームによって管理されている場合でも、データの出力と収集の責任を負います。 監視データをワークロード環境にローカライズすることで、チームはログとメトリックにアクセスしてワークロードの問題に対処できます。
十分なデータを収集し、十分な時間だけ保持します。

データのログ記録と格納に関連するコストのトレードオフについて考えてみましょう。		 意図的なデータ収集は、必要以上のデータの収集 に関連する財務コストと運用コストを最適化 するのに役立ちます。

ノイズを最小限に抑え 、分析中の集中的な計算を回避し、不要になったデータを格納するコストを削減します。
プロファイル、ログ、メトリック、トレースなど、さまざまな監視シグナルを区別します。 適切な目的で各シグナルを使用します。

メトリックを使用して、数値測定値に依存するアクションをトリガーする優先順位を付けます。

プロファイルを使用して、メモリ割り当てなどの 低レベルの可視性をシステムに取得します。

ログとトレースの使用を予約して、フローと依存関係のコンテキストを提供します。		 信号を適切な目的に使用することで、監視システムの非効率的な実装を防ぐことができます。

たとえば、アクションにログを使用するには解析が必要です。 メトリックを使用すると、同じ目標をより迅速に達成できる場合があります。
ダッシュボードのデータを集計して視覚化し、対象ユーザーに対応し、ビジネス コンテキストを念頭に置いた監視データを表示します。

状況ダッシュボードを使用してデータを表示し、関係者の意識を高めます。

インシデント対応などのオペレーター アクティビティのドリルダウン機能を備えた運用ダッシュボードとブックを使用します。 ダッシュボードを頻繁に更新し、詳細なデータを提供します。		 視覚化を使用すると、傾向の分析、ビジネス ターゲットに対する追跡、インシデントの管理を行うことができます。

顧客の関心に合わせて調整されたダッシュボードは、解釈に関連し、検出とアクションの時間を短縮します。
標準化された説明と重大度レベルで説明責任のあるロールに通知することで、アラートを実行可能にします。 さまざまなソースから照合された情報を提供し、ビジネス ターゲットからの逸脱を追跡します。

アクションが必要なインシデントに対してのみアラートをトリガーします。

プロアクティブで示唆に富んだアラートを追求し、機能低下状態が失敗に至る前にアクションを開始します。		 アラートは、組織で定義されている重要なイベントに注意を向けます。

適切なアラート システムは、アクションと重大度を識別し、明確さと目的を促進するのに十分なデータを提供します。 オペレーターは、修復を遅延なく開始できます。

効率を高める自動化

目標アイコン 繰り返しの手動タスクをソフトウェア自動化に置き換えます 。これにより、一貫性と精度が向上し、リスクが軽減されます。

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

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

方法 メリット
複雑さ、作業量、頻度、精度、タイムライン、有効期間の適切なレベルにある条件に対して、すべてのワークフローを評価します。

その評価に基づいてワークフローを自動化し、期待されるリターンが最も高いワークフローに優先順位を付けます。

冗長なワークフローを削除 するか、人の努力を正当化する価値を追加します。		 より価値の高い作業でチームの能力を再投資し、生産性と一貫性を高めることができます。

ワークフローのインベントリを作成すると、確実に適切なタスクを自動化できます。 冗長タスクを削除すると、複雑さとエラーが軽減されます。
カスタム ツールを構築するかソフトウェアを購入するかを評価する際は、決定を明確にしてください。

高度に特殊化された価値の高い作業のために、ビルの自動化を予約します。		 既製のソフトウェアを購入し、サポート契約を利用することで、メンテナンスコストを節約できます。

ソフトウェアを構築することで、より多くの制御が可能になり、チームやワークロードに固有のユース ケースに対応できます。 ただし、コストに影響があります。

ツールの選択は、運用に標準化のレベルをもたらします。 トレーニングを使用すると、導入に対する一貫したレベルの準備を実現できます。
自動化機能をサポートするようにワークロード コンポーネントを設計します。 システム設計での自動化の欠如により、反復的なタスクのアンチパターンが促進され、成長が鈍化し、技術的負債が蓄積し始める、という状況を避けてください。
すべての 自動化をワークロードの重要な依存関係として 扱います。 ワークロードの予想される成長に適応します。

自動化ツールはワークロードの不可欠な部分であり、Well-Architected フレームワークの 5 つの柱に従う必要があります。		 セキュリティ上の脅威などのリスクに耐えられるように自動化コンポーネントを設計します。 適用されたベスト プラクティスを使用すると、実装の無秩序な拡大を回避できます。

この依存関係が機能し、安全な状態に保たれている場合、ワークロードは引き続き高いレベルで保証され動作し続けます。
ワークロード以外のオプションを調べ、大規模な自動化を行います。

新しいプロジェクトをオンボードし、既存の設計と実装の再利用を促進するためのテンプレートとフレームワークを提供することで、"設計を 1 回、どこでも実行する" モデルを優先します。		 試行およびテストされた方法を採用し、失敗の可能性を減らします。

安全なデプロイ プラクティスを採用する

目標アイコン ガードレールを使用してデプロイの一貫性を実現し、エラーや予期しない状態の影響を軽減します。

自動化されたモジュール型のワークロードサプライ チェーンを構築し、すべての環境で一貫した、予測可能で反復可能なデプロイを確保します。 安全なプラクティスを早期に適用することで、運用環境の信頼性が確保され、問題が顧客に到達した場合の迅速な復旧が可能になります。

コード、構成、成果物など、すべての変更は、同じレベルの厳密な状態でデプロイする必要があります。 一貫性を実現するための一般的なプラクティスは、テスト、監視、およびバージョン管理です。

方法 メリット
コードとしてのインフラストラクチャ (IaC) を使用 して、すべてのインフラストラクチャの望ましい状態を定義します。

モジュール式の階層化されたアプローチを使用しますが、不要な抽象化は避けてください。

レイヤーをライフサイクルのニーズに合わせて調整し、基本レイヤーの安定性を維持します。		 IaC は、デプロイの自動化と一貫性を実現し、トレースに使用できる自己ドキュメントとして機能します。 IaC アーティファクトはソフトウェア開発ライフサイクルの一部となり、テストと品質レビュープロセスが可能になります。

IaC は、構成の誤差を検出して軽減するのにも役立ちます。
頻繁にデプロイされる小さな増分更新を優先します。 更新プログラムを小さくすると、同時エラーの数を減らすことで検証が簡略化されます。 複数の不良変更が同時にリリースされると、ブラスト半径が大幅に増加する可能性があります。
すべての環境で 自動化されたパイプライン を使用して、すべてのコードとインフラストラクチャの変更をデプロイします。 一貫性のあるデプロイ方法により、エラーと分散が減り、デプロイの信頼性と再現性が向上します。 デプロイ プロセス自体が文書化され、各実行によってアクティビティのレコードが作成されます。
運用前環境と運用環境で、開発ライフサイクル全体を通じて厳密に更新プログラムをテストします。 早期テストでは、問題をより早くキャッチし、反復的な修正を可能にし、更新プログラムが運用環境に対応できるようになるまでに問題を減らします。

実稼働前環境が複数あると、さまざまな種類のテストが可能になり、運用環境のリリースを成功させる自信が高くなります。
ユーザーによる段階的な露出と段階的な導入を可能にするデプロイ パターンを使用して新機能をロールアウトします。

下位互換性と前方互換性をテストします。		 更新プログラムのロールアウトを制御することで、欠陥による広範な問題のリスクが軽減されます。 徐々に露出を増やすと、互換性と安定性が確保され、リリースに対する信頼性が高まります。
運用環境で 障害のあるデプロイや重大な欠陥から復旧 するための補正アクションを準備します。

テストによってサポートされる自動化を使用して、修正プログラムをロールアウトします。

緊急更新プログラムの場合は、利害関係者によって事前に承認された迅速なプロセスを作成します。		 軽減計画を立てると、潜在的な影響の期間が短縮されます。

セキュリティ パッチなどの緊急の修正プログラムを迅速に展開して、ユーザーの安全なバージョンをより迅速に取得できます。

次のステップ

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

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