次の方法で共有

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

  • [アーティクル]

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

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

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

設計原則は、単に症状に対応するのではなく、根本原因に対処するために考慮すべき運用戦略のガイドラインを示すものです。 推奨されるアプローチから始めて、何が機能し、何が機能しないかを観察し、改善すべき領域を特定します。 戦略を設定したら、オペレーショナル エクセレンス チェックリストを使用して引き続き措置を進めます。

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

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

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

DevOps 文化を受け入れる

目標アイコン 開発チームと運用チームがコラボレーション、共同責任、所有権について同じマインドセットを持って共同作業することによって、システム設計とプロセスを継続的に向上させていくことができるようにします。

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

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

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

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

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

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

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

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

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

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

プロジェクトの後に振り返りを行うと、改善の余地がある領域を特定し、成功を祝うことができます。
アクションの最適化に重点を置いた、業界の実績あるアジャイル プラクティスを採用します。

手動と自動のプロセス、デプロイと品質保証のプラクティス、監視の運用の中で "シフト レフト" できる機会を探します。		 アジャイル開発プラクティスは、ビジネス価値の指標となるリリース ライフサイクルの短縮につながります。

多くの場合、早期に問題を検出し、解決し、予防すると、プロセスに対する影響が少なくなります。
すべての開発および運用手順の標準を設定し、定期的に確認して検証します。

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

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

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

正確に実行し、ガバナンスを有効にしてリスクにつながる異常を防止します。
専門スキルと幅広い経験を持つ集中型運用チームを利用します。 運用とリソースの両方に共有リソースを使用すると、コスト面での利点があります。

ワークロードは自分が所有しますが、集中型チームは、インシデント管理、監視に関するプロアクティブな視点、信頼できるアウトソーシングの専門知識など、部門横断的なスキルを提供します。

開発標準を確立する

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

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

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

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

サイズ設定推定モデルを作成して、関連するタスクのスコープとコストを報告します。		 適切な仕様を作成し、より生産的で合理化された開発サイクルをサポートすることで、運用コストと失敗の可能性を削減できます。

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

適切なドキュメントを作成すると、反復可能なコミュニケーションと新しいチーム メンバーのオンボードが簡単になります。
ワークロードとチームの規模のニーズに合わせて適切に調整した業界標準のソフトウェア開発手法を使用します。

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

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

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

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

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

さまざまな規模やリスクの変更をリリースする際の反復可能なワークフローを維持し、プロセスの一環としてピア レビューを実施し、監査証跡を残します。
開発ライフサイクルの初期段階でのテストに重点を置いた品質保証プロセスを用意します。

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

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

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

テスト計画を立てることで、品質と一貫性を確保し、起こり得る失敗のケースを考慮できます。

品質ゲートを設定することで、ベスト プラクティスを適用してリスクを軽減できます。

不変性により、テスト対象のシステムがリリースしたものとまったく同じであることが保証されるので、自信を持つことができます。

テスト サイクルでは、品質条件を満たすまで進行が効率的にブロックされます。
スタイル ガイドとツールを使用して一貫性を高め、規約を適用し、開発、テスト、関係者とのコミュニケーションに共通のツール チェーンを採用します。

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

共通のツールと規約があると、一度限りの選択に対処する必要がなくなり、チームがプロセスを最適化するのにも役立ちます。
コードの記述に従って開発者ドキュメントを作成するように、一貫して、また意識的に求めます。 明確なコード ドキュメントがあると、古いコードを再検討する必要がある場合や開発チームが交代する場合に、ロジックと機能を簡単に理解できます。
進行状況と傾向を報告して効率を測定します。 バグ、失敗した更新、デプロイ時間、フィードバック ループ、その他のメトリックの傾向が公開され、それが改善につながります。

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

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

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

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

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

アプローチ メリット
独自のスタックとフローを持つ監視システムを構築します。

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

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

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

テレメトリ、インフラストラクチャ メトリックの収集、ツールについて業界標準を使用することで、コード内のインストルメンテーションを標準化します。		 一貫性を保つと、検出と測定にばらつきが生じません。似たリソースに慣れることで、データの関連付けと分析に費やす時間を短縮できるからです。 全体的な視点を持っているため、問題を予測できます。

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

データのログと格納に関連付けられたコストのトレードオフを考慮します。		 意図的なデータ収集は、必要以上のデータを収集することに伴う財務と運用のコストを最適化するのに役立ちます。

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

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

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

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

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

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

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

顧客の関心に合わせて調整されたダッシュボードにより、適切に解釈できるようになり、検出とアクションまでにかかる時間が短縮されます。
標準化された説明と重大度レベルを責任者に通知することで、アラートに対処できるようにします。 さまざまなソースから収集した情報を表示し、ビジネス目標からの逸脱を追跡します。

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

機能低下状態が障害になる前にアクションを開始する、プロアクティブで示唆に富むアラートを目指します。		 アラートを使って、組織が定義した重要なイベントに注意を向けます。

是正措置と重大度を特定し、明確さと目的を推進するのに十分なデータを提供するのが優れたアラート システムです。 オペレーターは遅滞なく修復を開始できます。

信頼できるデプロイ

目標アイコン 予測可能性を備えた配置の望ましい状態に到達します。

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

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

アプローチ メリット
コードとしてのインフラストラクチャ (IaC) を使用して、運用に対応したサプライ チェーンの反復可能な側面を定義します。

命令型メソッドよりも宣言型のアプローチを優先します。		 宣言型 IaC テクノロジは、自動化と再利用性を念頭に置いて設計されています。 インフラストラクチャの配置を個人からツールにオフロードすると、一貫した品質を実現できます。

インフラストラクチャの観点からは、テクノロジの選択肢が少ないことにより、ツールのばらつきがなくなり、構成のドリフトを検出しやすくなります。 メンテナンスも容易になります。 選択肢をチームの既存のスキル セットに合わせれば、チームは簡単にそれを採用できます。
選択した IaC テクノロジを使用できるようにチームを準備します。 その拡張性モデル、機能、制限について学習します。

チーム内の専門性と組織内の共有知識を利用します。		 スキルアップによって生産性を高め、共有学習を通じてコラボレーション環境を育むことができます。

雇用するのではなくトレーニングでギャップを埋めることができます。
IaC の開発とメンテナンスについては、ソフトウェアの推奨事項に従ってください。

モジュール化は適度に行います。 カスタムまたは低価値の抽象化は避けます。

階層型アプローチに沿って、さまざまなライフサイクルを反映します。 下位レイヤーが一定のままで、上位レイヤーが必要に応じて変化する基本レイヤーを形成します。

アプリケーション バイナリ、IaC テンプレート、パラメータなどの配置成果物は、攻撃面の一部です。 シークレットの管理、アクセス制御、セキュリティの柱のその他の原則など、保証を適用します。		 成果物には、アプリケーション コードと同じレベルのエンジニアリングの厳密さが適用されます。 ピア レビューとテストを用いた品質管理により、配置に自信を持つことができます。

階層化されたアプローチにより、メンテナンスが容易になり、責任の明確な線引きを設定する境界が作成されます。

成果物にセキュリティ コントロールを追加すると、配置プロセス中にシステムを強化できます。
すべての環境で使用される共通のデプロイ マニフェストを開発します。 そのマニフェストを、グリーンフィールド プロジェクト、増分ワークロード更新、またはディザスター リカバリーの既定のメカニズムとして使用します。 複数の資産を維持するオーバーヘッドをなくします。

障害が発生した場合、即席の環境を作成するのではなく、十分にテストされたマニフェストを配置できるため、迅速かつ信頼性の高い復旧が可能になります。
IaC 自動化を通じてデプロイされる不変かつ短期のインフラストラクチャを目指します。 構成のドリフトを禁止し、デプロイをべき等にします。

この種のインフラストラクチャにすると、パッチの適用などの運用上の大きな負担が軽減されます。 また、ブルーグリーン インフラストラクチャのデプロイなど、コアの検証シナリオにも利点があります。

Note

ポータルの使用スコープを、反復しない調査タスクのみに限定します。

効率を高める自動化

目標アイコン反復的な手動タスクをソフトウェア自動化に置き換えます。これにより、より迅速に完了し、一貫性と正確性を高め、リスクを軽減することができます。

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

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

アプローチ メリット
複雑さ、労力、頻度、正確性、適時性、有効期間の適切なレベルである条件に照らしてすべてのワークフローを評価します。

その評価に基づいてワークフローを自動化し、見込まれる利益が最も高いワークフローを優先します。

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

ワークフローのインベントリを作成すると、確実に適切なタスクを自動化できます。 冗長タスクを削除すると、複雑さとエラーが軽減されます。
カスタム ツールを構築するかソフトウェアを購入するかを検討する際には、自分の判断を明確に伝えます。

ビルディング オートメーションは、専門性が高く価値の高い作業にのみ使用します。		 既製のソフトウェアを購入し、サポート契約を利用することで、メンテナンス コストを節約できます。

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

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

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

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

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

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

目標アイコン デプロイ プロセスにガードレールを実装して、エラーや予期しない状態の影響を最小限に抑えてください。

開発サイクル中、ワークロードの成果物は、実装されテストされるときや、バグが修正されるときに、多くの変更が実行されます。

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

アプローチ メリット
パイプラインなどの自動デプロイ プロセスを使用して、変更をデプロイするプロセスを標準化します。

すべての環境でパイプラインを使用する必要があります。

資産とバージョンを環境ごとに分類して、追跡と識別が簡単にできるようにします。		 プロセス エラーや差異に起因する問題が一貫したデプロイ方法で減らし、ワークロードの問題に集中して取り組むことができます。

標準化により、デプロイが安全かつ確実に、再現性を備えた状態で完了することが保証されます。

分類により、以前のデプロイと以前に発生した問題のログを簡単に表示できます。 その情報を使用すると、ロールバック操作とロールフォワード操作を迅速に処理できる場合があります。
小規模な増分更新プログラムを定期的にデプロイします。 頻繁な十分にテストされた小規模な更新プログラムにすることで、リリースの検証が容易になります。

占有領域が小さいため、顧客への影響を最小限に抑え、迅速にトラブルシューティングできます。
開発ライフサイクル全体を通して、さまざまなメカニズムを使用して更新プログラムを厳密にテストします。 開発の初期段階で問題を捉えます。 反復的な修正プログラムと一貫したデプロイのプラクティスにすることで、更新プログラムを運用環境にリリースできるようになるまでには、問題を段階的に軽減することができます。
デュー デリジェンスを使用して、更新プログラムを段階的にロールアウトします。

すべてのユーザーが更新プログラムを安全に導入するまで、インスタンスと顧客の数を段階的に増やす制御を実現できるデプロイ モデルを使用します。		 運用環境の早い段階で問題が修正されるように、適切な方法で各更新をテストします。 顧客ベース全体に影響を与える不具合のある更新をロールアウトしないようにします。

更新に下位互換性と上位互換性があるかどうかテストします。
デプロイの失敗から迅速に回復するための軽減戦略を立てます。

問題の重要性に基づいてロールバックまたはフォワードに関する意思決定をカバーする戦略にする必要があります。

標準のデプロイ パイプラインを使用して修正プログラムを迅速にロールアウトできる、明確に定義されたプロセスと自動化システムを用意します。		 潜在的な影響の期間を短縮します。

システムを以前の機能するバージョンに戻すか、十分にテストされた修正プログラムが組み込まれたバージョンにロール フォワードします。
緊急時にシステムを稼働状態にリセットし、予期しない障害から復旧するフォールバック計画を用意します。 この戦略は、必要な場合にのみ、承認を得て使用します。

時間の経過と共に計画を改善するように努めます。		 セキュリティ修復など、優先度の高い修正プログラムを迅速に実行できます。

高速パイプラインには、標準の操作手順のすべてのチェックが含まれていない可能性がありますが、影響度の低い障害よりも、可能な限り最短時間で顧客を安全なバージョンに導くことができます。

次のステップ

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

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