AWS Well-Architected フレームワーク DevOps ガイダンスが発表されたのでサマってみた
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。
ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。
ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。
それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。
本家のドキュメントはこちらです。ぜひお読みになってください。
DevOps Guidance
要約と紹介
最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。
面白い一文があったので引用します。
There is no one-size-fits-all approach to adopting DevOps. Tailor these recommendations to suit your individual environment, quality, and security needs.
(機械翻訳) DevOps の導入に万能のアプローチはありません。これらの推奨事項は、個々の環境、品質、セキュリティのニーズに合わせて調整してください。
DevOps に関するフレームワークは世界中で数多くリリースされており、どこに正解が無いというのはご存知の通りだと思います。このガイダンスも同じでそのまま組織に当てはめるのではなく調整していくことが大切です。
DevOps ガイダンスの使用
次の手順に従うと効果的です。
- DevOps ガイダンスや Well-Architected フレームワークを理解する
- 組織の DevOps 現状を収集する
- 現状と DevOps ガイダンスや Well-Architected フレームワークを比較する
- 優先度を付ける
- ギャップに対処する
- 必要があれば専門家に相談する
DevOps Sagas
DevOps の実践には時間がかかり、相互に関連した一連の機能が必要なことを反映して「Saga」と名付けたそうです。センスがありますね。
大きな5つの Saga があります。
- 組織的な導入
- 開発ライフサイクル
- 品質保証
- 自動化されたガバナンス
- 可観測性
組織的な導入
人と文化を重視して DevOps を導入するアプローチを紹介します。
リーダーのスポンサーシップ
DevOps 導入の主導するリーダーが DevOps 導入の明確なビジョンを示し、目標を伝え、リソースを予算を割り当てます。
主導するリーダーのサポートが各組織の DevOps 実践の導入に必要不可欠です。
DevOps の組織への導入には専任にリーダーが必要です。DevOps 導入に専念し責任を負う人物です。
このリーダーには CxO からのサポートが必要です。
DevOps の導入は組織内で孤立したプロジェクトであってはなりません。DevOpsの導入と全体的なビジネス戦略は同期します。
成果と影響を示す KPI を作成し定期的なビジネスレビューを行います。多くの小規模チームが独自の運営をしている分散型運用モデルでも全体の可視性を保つことが可能になります。
DevOps におけるコミュニケーションは単なる情報交換ではありません。信頼、コラボレーション、連携を図ることが目的です。リーダーはオープンなコミュニケーションチャンネルを確立し、フィードバックを直接収集します。
DevOps の専門知識を有するチーム Center of Enablement を設立します。チームの DevOps プロセスを確立します。
指標
[OA.LS.1] DevOps 導入を主導する意思決定リーダーを任命する
[OA.LS.2] DevOps の導入をビジネス目標に合わせる
[OA.LS.3] ビジネスレビューを通じて継続的な改善を推進する
[OA.LS.4] リーダーシップとチーム間のオープンな対話
[OA.LS.5] 組織変革に焦点を当てた部門横断的な実現チームを編成する
サポート力のあるチームダイナミクス
DevOps の導入では、コスト最適化、運用、セキュリティ、可用性など新しい責任を引き受ける可能性があります。
これらをシームレスに取り込み、新しいビジネスニーズに迅速に対応するためにチームダイナミクスが不可欠です。
Team Topologies の4つのチームモデルを採用します。(Stream Aligned, Enabling, Complicated Subsystem, Platform)
これらに従ったチームを組織することで、コラボレーションを強化し効率的なチーム価値を提供します。
チームの能力と好みを考慮しながら運用モデルを採用します。全ての運用モデルが DevOps に適しているわけではありません。
集中制御モデルでは厳密な統制をとれますが迅速な改革は制限されます。分散化モデルではチームの柔軟性と自律性が向上しますがガードレールと自動化されたガバナンスが必要になります。
コラボレーションとオープンなコミュニケーションを促進し、チームワークと責任共有の文化を推奨します。
チームの成功を祝い、個人の成果よりチームの成果を優先します。
サービスの価値と有効性を最大化するには、構築される望ましいアーキテクチャを反映するチームを意図的に設計します。
逆コンウェイ戦略を採用することで、効率の向上とより効果的なコラボレーションを実現します。
チーム規範を確立するときはタックマンモデルを参考にします。形成期・混乱期・統一期・機能期の段階に留意しながらチームをサポートします。
「you build it, you run it」に従い、製品の価値と所有に責任を負うべきという考え方を持ちます。
一方で、責任を負うようになるとそれがボトルネックになる可能性があります。その場合には Guardian モデルを採用します。セキュリティ、品質などの専門家をチームに組み込みます。
チーム内にスキル、経験、背景が多様に組み合わされていると複雑な問題の解決が可能になります。チームを編成する際は、採用の偏見を避け、多様性と包括性を促進します。
指標
[OA.STD.1] チームを個別のトポロジ タイプに編成してバリュー ストリームを最適化する
[OA.STD.2] ビジネス ニーズとチームの好みに合わせて運用モデルを調整する
[OA.STD.3] 個人の成果よりも共有された責任を優先する
[OA.STD.4] 望ましいビジネス成果を中心にチームを構築する。その逆ではない
[OA.STD.5] 業務遂行を強化するチーム規範を確立する
[OA.STD.6] チームが製品のバリューストリーム全体の所有権を取得できるようにする
[OA.STD.7] 集中機能の規模と影響を拡大する
[OA.STD.8] チーム内の認知的多様性を促進する
チームインターフェース
DevOps 環境内のチーム間作業フロー。
効果的なチームインターフェースにより、プロセス合理化、ボトルネック軽減、生産性向上を目指します。
進行中の作業、ロードマップ、チームの目標を主要な関係者や他チームと共有します。チームの透明性を向上させ、チームの影響をよく理解するのに役立ちます。
チーム内のコラボレーション、ドキュメント共有、タスク、進捗状況を可視化するツールを使います。チームのコミュニケーションを合理化するため用語集、ストーリー、完了の定義などの規範を確立します。
チームが社内外の顧客からのフィードバックを収集できるチャンネルを確立します。フィードバックを受け取り、優先順位を付け、アクションを実行できるプロセスを作成します。
問題追跡システムなどエラー追跡と解決を促進するツールとプロセスを実装します。エラーは優先順位を付けて修正します。
スピード、安全性、機敏性を優先する承認プロセスを確立します。
バージョン管理システム、CI/CD パイプラインは自動化された承認プロセスを利用します。
エンドユーザーの期待を製品開発の中心に置きます。理想的なユーザー体験を視覚化し、そこから逆算して最善の方法を決定します。
Amazon Working Backwards が有名です。
コラボレーションツールを利用して文書、構成などを保管します。ドキュメントが最新であることを確認してチームが自律的に作業できるようにします。
定期的なコミュニケーションチャネルとフォーラムを確立して、情報共有を促進します。知識、ベストプラクティス、教訓を共有します。
インジケーター
[OA.TI.1] チームと関係者の間でワークフローと目標を伝達する
[OA.TI.2] ツールとプロセスを使用してチーム内のコミュニケーションを合理化する
[OA.TI.3] チームが顧客のフィードバックを収集および管理するためのメカニズムを確立する
[OA.TI.4] エラー追跡と解決を継続的に改善する
[OA.TI.5] 安全性を損なうことなく適応型承認ワークフローを設計する
[OA.TI.6] 最適なビジネス成果を実現するために顧客のニーズを優先する
[OA.TI.7] チームの統一された知識ソースを維持する
[OA.TI.8] 組織情報への簡単なアクセスを促進する
[OA.TI.9] API とドキュメントを介したセルフサービス コラボレーションを可能にする
[OA.TI.10] 最適な効率とコスト削減のための対話モードの選択
[OA.TI.11] チーム間コラボレーションのためのオプションの機会を提供する
バランスの取れた認知負荷
バランスの取れた認知負荷を維持することは、メンバーが圧倒されたり刺激に不足したりすることなく課題に取り組むのに役立ちます。
認知負荷に焦点をあてると個人の仕事の満足度を高め、情報を効果的に処理し、経験から学び、知識を保持し、結果としてパフォーマンスが向上します。
個人の目標と組織の目標が一致させ、自分の貢献を実感できるようにします。
目的意識によって動機付けられた社員は定着率向上、燃え尽き症候群の軽減など良い傾向が見られます。
トイルと呼ばれる反復的で時間のかかるタスクを特定し、自動化の可能性を評価します。自動化ツールとプロセスを実装し労力を削減しチームの効率を向上します。
中断頻度を減らし技術的負債に対処する取り組みに時間と労力を考慮するようチームに推奨します。その影響を測定できる指標を確立します。
進行中の作業 (WIP) を削減します。新しいタスクを開始するより終了するタスクを優先します。
進行中のタスクを効果的に管理しタイムリーにタスクを完了するためにプロジェクト管理ツールと方法論を導入します。
エスカレーションプロセスは文書化され、手順を全員に共有します。エスカレーションは恐れることではなく頻繁に行われ、全員がエスカレーションプロセスに従います。
成功と失敗の両方の実験について共有セッションを主催することで実験からの学習を推奨します。
メンバーがマイナスの結果を恐れることなくアイデアを共有し発言することが推奨されていると感じる安全な環境を育みます。
憲章を確立します。これは共同で作成する必要があり、チームの目的、目標、価値観、運営原則を示します。定期的に見直し更新してチームの目標と価値観を維持します。
主観的ではなく客観的に意思決定を行うためデータを活用します。
指標
[OA.BCL.1] 認知的健康を改善するための目的と方向性を明確にする
[OA.BCL.2] 反復的なタスクを自動化して労力を削減する
[OA.BCL.3] 継続的な改善を通じて消火活動と技術的負債を削減する
[OA.BCL.4] 進行中の作業を制限することでチームの効率を高める
[OA.BCL.5] 明確なエスカレーション パスを確立し、建設的な意見の相違を奨励する
[OA.BCL.6] チームが組織の目標に沿った意思決定を行えるようにする
[OA.BCL.7] 心理的に安全な実験文化を育む
[OA.BCL.8] 認知能力に基づいてチームの規模を決定する
[OA.BCL.9] チームの一貫した意思決定を行うための指針を使用する
[OA.BCL.10] データを使用して情報に基づいた意思決定を行う
適応的な作業環境
チームのパフォーマンスとコラボレーションを最大化するために、必要なツール、プロセス、サポートを提供します。状況の変化に対応できる作業環境を構築します。
分散したチーム間の効果的なコラボレーションツールを導入します。チャット、音声、ビデオ、ブレークアウト、インタラクティブなボードを通じて仮想コラボレーションをサポートします。
これらのツールはデスクトップ、タブレット、モバイルなどの様々なデバイスで利用できる必要があります。
役割に応じた柔軟な勤務方針を推奨します。異なるタイムゾーンや場所にまたがるチームメンバー間のコミュニケーションとコラボレーションを促進します。
柔軟で再構成可能な作業スペースを用意します。ニーズに合わせてカスタマイズ可能なコラボレーションとコミュニケーションが可能になります。(フルリモートの場合は除く)
定期的なチームビルディングや社交イベントを企画して、人間関係を築き、共同体意識を育み、コラボレーションを促進します。
これらの活動についてフィードバックを受け、どれだけ影響力があるか楽しいかに関するデータを収集します。
指標
[OA.AWE.1] 仮想コラボレーションのための機能豊富なツールをチームに装備する
[OA.AWE.2] 仮想コラボレーションとオンサイト コラボレーションの両方に包括的なオプションを提供する
[OA.AWE.3] 多様なグローバル チームの作業スケジュールのバランスを取る
[OA.AWE.4] 効果的なオンサイトコラボレーションのための適応可能なワークスペースを提供する
[OA.AWE.5] チームビルディング活動や社交イベントを企画して、コミュニティ意識を育み、コラボレーションを促進する
個人的および専門的な能力開発
リーダーはオープンさと包括的な文化を促進し、自主性と失敗から学ぶ機会を提供する必要があります。成功を認めて祝うと同時に建設的なフィードバックを提供します。
関連するスキルと知識のギャップを特定し、包括的なトレーニング計画を作成します。社内外のトレーニングに時間と予算を割り当てます。
優秀な人材の獲得、育成、維持に投資します。従業員からのフィードバックを収集して、ニーズを理解し、能力開発について情報を提供します。
ストレッチゴールを含む測定可能な学習目標を設定し、目標を達成するよう動機付ける有意義な報酬システムを設計します。
自分自身の専門知識を検証し、最新のテクノロジーを把握するため、認定資格取得を個人に推奨します。
知識共有の機会とスキルギルドへの参加を促進します。このガイダンスで紹介している DevOps Saga に焦点をあてたグループを作成することをおすすめします。
これらの機会をグループはサイロを打破し、コラボレーションを改善するのに役立ちます。
指標
- [OA.PPD.1] コラボレーション、イノベーション、学習、継続的な成長を奨励し、生成的な文化を育む
- [OA.PPD.2] 対象を絞ったトレーニングに時間と予算を割り当てる
- [OA.PPD.3] 多様でアクセスしやすいトレーニング オプションを提供する
- [OA.PPD.4] 優秀な人材の誘致、育成、維持に投資する
- [OA.PPD.5] 継続的な学習を評価し、報酬を与える
- [OA.PPD.6] チーム間の利益団体を通じて知識共有を促進する
開発ライフサイクル
ワークロードの開発、レビュー、構築、リリース能力を最適化し、デプロイ頻度をあげ、より安全に展開するためのアプローチを紹介します。
ローカル開発
ローカル開発では、本番環境を可能な限り反映する開発環境を確立することに重点が置かれます。
他のメンバーや共有環境に影響を与えることがなく、変更をすぐテストし正確なフィードバックを提供するための独自の開発環境を準備します。
ローカル開発環境の準備は、IaC やスクリプトによる自動化を使用します。これにより均一性が担保されます。
ローカル開発をしている最中、開発者は小規模で頻繁なコミットを行います。これにより完了した作業を失う怖さから開放されます。
プログラム言語と互換性のあるセキュリティツールを導入し、コミット前にセキュリティチェックを実施します。機密データの漏洩や信頼できないリポジトリへのプッシュなどを防ぎます。
リンターなどの静的スキャンツールを使い、プッシュ前にコードの品質と一貫性を向上させます。
IDE のプラグインや拡張機能を利用して開発者体験を向上させます。
開発者が新しいアイデアやテクノロジーを試すサンドボックス環境を用意します。サンドボックスボックスはネットワーク的に隔離します。また、支出制限を行います。
セキュリティを損なうことなく現実的なテストができるように、モックデータセットを用意します。
モックデータセットはランダムデータジェネレーターや生成 AI などを使う生成します。
開発ツール内で ML アルゴリズムを使用したコード補完を実装します。これによりコーティングプロセスが高速化され、エラーの可能性が減ります。
指標
[DL.LD.1] ローカル開発のための開発環境を確立する
[DL.LD.2] ローカル環境を一貫してプロビジョニングする
[DL.LD.3] ローカル変更を早期かつ頻繁にコミットする
[DL.LD.4] コミット前にセキュリティチェックを強制する
[DL.LD.5] コミット前にコーディング標準を強制する
[DL.LD.6] 拡張可能な開発ツールを活用する
[DL.LD.7] 支出制限のあるサンドボックス環境を確立する
[DL.LD.8] ローカル開発用のモック データセットを生成する
[DL.LD.9] ツール構成の共有
[DL.LD.10] 未使用の開発環境を管理する
[DL.LD.11] 機械学習によるスマート コード補完の実装
ソフトウェアコンポーネントの管理
開発ライフサイクル中に生成されるソフトウェアコンポーネントは多数あります。ソフトウェアサプライチェーンのセキュリティとガバナンスを強化するために、個々のコンポーネントを管理します。
バージョン管理システムにより、コードの変更追跡が可能になります。複数の開発者が同時プロジェクトに取り組み、変更履歴が提供され、ロールバックが可能になります。
バージョン管理システムにはアクセス制御を実装することを検討ください。
短命ブランチを利用したトランクベースの開発をお勧めします。
短命ブランチの主な利点は、継続的統合の促進です。メインブランチへのマージ時の混乱が防止され、確実にリリースできるようになります。
アーティファクトリポジトリへのエラーやバグ侵入を防ぐために、信頼できる自動化プロセスを使用します。アーティファクトリポジトリに手動生成されたアーティファクトを含めたり、手動変更を許可しないでください。
アクセス制御を利用してアーティファクトを保存および変更できるユーザーとシステムを制限します。
信頼できないソースコードとアーティファクトリポジトリの使用を制限します。信頼できないこれらは、ソフトウェア脆弱性が混入されたり機密コードが漏洩する可能性があります。
許可および禁止されている OSS リストを管理し、定期的に更新します。SCA ツールを使用して SBOM をスキャンすると許可および禁止されているリストを強制できます。
適切に構造化された有益なリポジトリドキュメントを作成します。多くの場合、README.md や CONTRIBUTING.md といったマークダウンで書かれます。
プロジェクトの概要、目的、デプロイ手順、コントリビュートのガイドライン、フィードバックの送信方法など保守性向上に役立つ内容が記載されています。
標準化された脆弱性開示ポリシーの実装は、セキュリティを促進し、リスクを管理し、発見された脆弱性の報告と処理を促進します。
全てのソフトウェアコンポーネントにバージョン管理仕様を適用します。セマンティックバージョニングなどの管理仕様を適用すると、さまざまな種類のリリース(メジャー、マイナー、パッチ)を追跡する体系的なアプローチが提供されます。
古いアーティファクト、ライブラリ、リポジトリなどを削除します。これらを削除するとストレージスペースの節約になるだけではなく、古いソフトウェアや脆弱性のあるコードが混入するのを防ぎます。
可能な場合は、ガバナンスツールなどで自動削除します。
指標
[DL.SCM.1] 適切なアクセス管理を備えたバージョン管理システムを使用する
[DL.SCM.2] 機能ブランチの存続期間を短くする
[DL.SCM.3] 認証と認可を強制したアーティファクト リポジトリを使用する
[DL.SCM.4] 信頼できるリポジトリにのみアクセスを許可する
[DL.SCM.5] 承認されたオープンソース ソフトウェア ライセンス リストを維持する
[DL.SCM.6] 有益なリポジトリドキュメントを維持する
[DL.SCM.7] 脆弱性開示プロセスを標準化する
[DL.SCM.8] バージョン管理仕様を使用してソフトウェア コンポーネントを管理する
[DL.SCM.9] 古いソフトウェア コンポーネントを非推奨および無効にするための計画を実装する
[DL.SCM.10] ビルドごとに包括的なソフトウェア インベントリを生成する
Everything as Code
IaC を効果的に編成すると、柔軟性、可読性、再利用性が向上すると同時に、インフラストラクチャのプロビジョニングとメンテナンスが合理化されます。
データ操作をコード化すると、データベーススキーマ、データ変換、データパイプラインをコードとして扱うことが可能です。品質保証、ガバナンスの適用、監査の提供など DevOps の有効な機能を使用できます。
IaC はアプリケーションコードのデプロイとは独立して構成変更できるようにします。
IaC コードの変更をトリガーに CI/CD を実行する自動化されたパイプラインを作成します。
汎用プログラム言語を用いた IaC を使用すると IaC の開発、管理、デプロイが変わります。AWS CDK などのツールを使うと予測可能で一貫性があり再現可能なプロセスが実現します。
インジケーター
[DL.EAC.1] スケールに合わせてインフラストラクチャをコードとして整理する
[DL.EAC.2] コードとしてのインフラストラクチャを通じてネットワークを最新化する
[DL.EAC.3] データ操作を成文化する
[DL.EAC.4] アプリケーション管理を強化するための継続的構成の実装
[DL.EAC.5] 技術文書と運用文書を開発ライフサイクルに統合する
[DL.EAC.6] 汎用プログラミング言語を使用してコードとしてのインフラストラクチャを生成する
[DL.EAC.7] コンピューティング イメージの生成と配布を自動化する
コードレビュー
コードレビューを実装すると、組織は変更プロセスを合理化し、品質を向上させ、責任を共有する文化を構築することが可能です。
組織で使用している主要なプログラム言語に合わせたコーディング標準を用意します。これらの標準はリンターとコード品質ツールに成文化して開発者体験を向上させます。
自動コードレビューツールを使用して潜在的な問題を検出します。手動レビューが行われる前に問題を修正できる可能性が高まります。手動レビュー担当者はコードスタイルの不一致や構文エラーなどの些細な問題をレビューせずにすみます。
すべての変更をマージする前に、少なくても1人以上の他の開発者によるレビューと承認される必要があります。バージョン管理システムには、1人以上のレビューを強制するルールが存在します。
コードレビューは、前向きで経緯を持った協力的なやり取りである必要があります。前向きなレビュー文化を育むにはコードレビューに期待することについての明確なガイドラインが必要です。
コードタスクの明確な完了基準を確立します。完了基準には、実行する必要があるテスト、必要なドキュメント、コードが満たす必要がある標準などを記述します。
指標
[DL.CR.1] コーディング慣行を標準化する
[DL.CR.2] コード変更のピアレビューを実行する
[DL.CR.3] コードタスクの明確な完了基準を確立する
[DL.CR.4] ビジネス ロジックに重点を置いた包括的なコード レビュー
[DL.CR.5] 建設的で包括的なレビュー文化を促進する
[DL.CR.6] プル リクエストを使用してコード レビューを開始する
[DL.CR.7] 仕様を使用して一貫性のある説明的なコミット メッセージを作成する
[DL.CR.8] 専門家レビューのためにコード所有者を指定する
暗号署名
開発ライフサイクルにおいて暗号署名を用いて不正な変更や悪意のある攻撃から保護します。
アーティファクトにデジタル署名を添付し、改ざんまたは偽造のリスクを最小限に留めます。
ビルドプロセス中にアーティファクトへ暗号署名を行います。署名はアーティファクトを検証するユーザーがアクセスできる場所に安全に保管します。
コードアーティファクトを使用する前に、暗号署名を検査して検証するステップを強制します。検証ステップはパイプラインに統合し自動化します。
インジケーター
[DL.CS.1] 自動デジタル証明書署名の実装
[DL.CS.2] 各ビルド後にコード アーティファクトに署名する
[DL.CS.3] 署名付きアーティファクトを使用する前に検証を強制する
[DL.CS.4] コミット署名を使用してトレーサビリティを強化する
継続的インテグレーション
コードベースに対する定期的な小さな変更を特徴とする小さなバッチでの作業により、ソフトウェア配信のパフォーマンスが向上します。
小さなバッチでの作業は規律が必要ですが、速度、セキュリティ、コラボレーション、コードベースの一貫性向上に繋がります。
CI ツールはソースコードリポジトリの変更を定期的に監視します。このトリガーによりアプリケーションの構築、テスト、デプロイを自動化します。
QA テストを CI パイプラインに追加すると、変更を検証し、迅速なフィードバックを受け取ることができます。
CI プロセスで失敗が発生した場合、開発者に対してフィードバックが送信され、解決のための実用的なガイダンスとともに失敗を説明する必要があります。
導入頻度、変更リードタイム、障害率、復旧までの時間などの指標を使用します。
監視およびログの可観測性をパイプラインに取り入れます。
ソースコードの特定のバージョンのビルドは、理想的には同じ入力から同じ出力を生成できる必要があります。再現可能なビルドを定期的にチェックして再現性を検証します。
指標
[DL.CI.1] コード変更を定期的かつ頻繁に統合する
[DL.CI.2] ソースコードの変更時にトリガーが自動的に構築される
[DL.CI.3] すべてのビルドの自動品質保証を保証する
[DL.CI.4] 一貫した実用的なフィードバックを開発者に提供する
[DL.CI.5] ビルド アクションを戦略的に順序付けして、迅速なフィードバックを実現する
[DL.CI.6] ビルドメトリクスを使用して統合パイプラインを調整する
[DL.CI.7] ビルドの再現性を検証する
継続的デリバリー
本番環境へのデプロイメントを頻繁に行うと、フィードバックループが促進され、問題の迅速な解決につながります。
デプロイはパイプラインにより自動化されます。
DevOps ではデプロイとリリースを区別することが重要です。機能フラグを使用し特定機能のリリースまたはロールバックを詳細に制御します。
デプロイメントは安全とみなされた、検証、テスト、統合されたアーティファクトのみを使用します。
デプロイプロセスは自動化します。QA、機能テスト、非機能テスト、データテストを自動化してパイプラインに取り入れます。
自動化の例外は承認です。承認は人手が介入します。
デプロイメントはオンデマンドで実行できる必要があります。ビジネスの中断を引き起こすことなく、通常の勤務時間内に実行できる必要があります。
Blue/Green、カナリアリリース、機能フラグ、ローリングアップデートなど高度なデプロイ戦略を採用する必要があります。
パイプラインの継続的な改善のため、詳細な指標と全体的な指標を使用します。
監視およびログの可観測性をパイプラインに取り入れます。
指標
[DL.CD.1] 変更を運用環境に頻繁にデプロイする
[DL.CD.2] 信頼できるアーティファクト リポジトリからのみデプロイする
[DL.CD.3] 品質保証を展開に統合する
[DL.CD.4] 導入プロセス全体を自動化する
[DL.CD.5] オンデマンド導入機能を確保する
[DL.CD.6] 継続的な改善のための指標を使用して配信パイプラインを調整する
[DL.CD.7] 継続的な展開を実践するために手動による承認を排除する
高度なデプロイ戦略
本番環境にデプロイする前に開発やテストなどの複数の環境にデプロイし、ソフトウェアを段階的に検証します。
自動ロールバックを実装すると、システムの信頼性を高め、サービス中断を最小限に抑えることが可能です。ロールバックは障害率、遅延率など様々なメトリクスにリンクされたアラームに基づいて開始します。
段階的なデプロイまたはリリースを行います。例えば、全体の33%は新しいコードに置き換えられ、残り67%は従来のコードのままです。
変更の影響を小さくすることで、問題が持ち込まれるリスクが軽減され、迅速なロールバックが可能になります。
増分機能リリース手法を採用すると変更に関するリスクが同様に軽減されます。ダークローンチ、機能フラグ、2フェーズデプロイ、カナリアリリースなどが含まれます。
データストアとスキーマの変更に対する下位互換性を確保すると、ロールバックしてもシステムの動作が保証されます。
異なるマイクロサービス間の変更が伴うシナリオでは順序の一貫性を維持することが重要です。
セルベースのアーキテクチャを採用します。セルは、独立してデプロイ可能なユニットです。セルベースのアーキテクチャは小規模で頻繁な変更を可能にし、影響範囲を限定し、迅速な回復を実現します。
指標
[DL.ADS.1] 運用前環境でのテスト展開
[DL.ADS.2] 失敗した展開に対する自動ロールバックを実装する
[DL.ADS.3] 段階的に導入およびリリース戦略を使用する
[DL.ADS.4] 増分機能リリース手法の実装
[DL.ADS.5] データ ストアとスキーマの変更に対する下位互換性を確保する
[DL.ADS.6] きめ細かい展開とリリースのためにセルベースのアーキテクチャを使用する
品質保証
コードの品質を優先することで、セキュリティ、可用性、信頼性、復元力しながら、俊敏性を確保します。
従来事後対応的であった品質保証プロセスを、開発ライフサイクルのプロアクティブで不可欠な部分に進化させます。
テスト環境の管理
品質保証テストを実施する専用の環境を用意します。これらの環境は限りなく本番環境に近く実際の状況をシミュレートします。
テストケースでは、所定の状態でテスト実行できるように条件とデータが必要です。正しい設定とデータでテストを実施するとテストの信頼性が高まります。
条件とデータのセットアップは自動化し、労力を削減します。
テスト結果の保存戦略を確立して、結果の整合性、関連性、可用性を維持します。
テスト反復にわたる結果の比較と分析が簡素化されます。
並列テストを実行します。モジュール化が進みマイクロサービス化するとテストケース数も増加します。テスト待ち時間を削減し、より高速な反復と頻繁なデプロイメントを可能にします。
Team Topologies のようなチーム構造と運用モデルが浸透するにつけ、品質保証チームの役割と責任も同時に進化させます。
1つの方法はプラットフォームチームを結成することです。開発者体験を向上させるような品質テスト環境のセットアップを迅速化させるなどの役割を担います。
もう1つの方法は、Enabling チームを作ることです。チームが品質テストの設計とテストを自給自足できるように教えることができます。
指標
[QA.TEM.1] 専用のテスト環境を確立する
[QA.TEM.2] テストベッドを使用して一貫したテスト ケースの実行を保証する
[QA.TEM.3] テスト結果の保存と管理
[QA.TEM.4] テスト効率を高めるための統合テスト データ リポジトリの実装
[QA.TEM.5] テストを並行して実行して結果を高速化する
[QA.TEM.6] スケーラブルな品質保証プラットフォームを通じて開発者のエクスペリエンスを向上
機能テスト
機能テストでは、システムが要件に従って動作することを検証します。
単体テストによってアプリケーションの1つの個別機能を評価します。単体テストの目的は、変更時に欠陥が生じるリスクを軽減し、迅速で徹底的なフィードバックを提供することです。
統合テストによってシステムを構成する複数のコンポーネント間の相互作用を評価します。統合テストの目的は、相互作用とデータフローが連携して機能することを確認することです。
受け入れテストではユーザーの観点からシステムの動作機能を評価します。ユーザーが期待するあらゆる側面を考慮することで、包括的な評価が行われます。
受け入れテストには様々な形式があります。(E2E、UAT、総合など)
並列化によるテストの最適化、古くなったテストの削除、テスト順序の最適化を行ったうえでも十分な結果を得られない場合は ML を使用する選択肢もあります。
過去のコード変更とテスト結果でトレーニングされた ML モデルを使用してテストするアプローチです。
指標
[QA.FT.1] 単体テストで個々のコンポーネントの機能を確認する
[QA.FT.2] 統合テストによるシステムの相互作用とデータ フローの検証
[QA.FT.3] 受け入れテストによるエンドユーザー エクスペリエンスと機能の正確性の確認
[QA.FT.4] 高度なテスト選択を使用して開発者のフィードバックとテスト カバレッジのバランスをとる
非機能テスト
非機能テストは、ソフトウェアが望ましいパフォーマンス、信頼性、使いやすさ、その他の非機能基準を満たしていることを確認します。
静的テストを通じてコードの品質を評価します。アプリケーションのソースコードだけではなく、設計成果物、ドキュメント、IaC などに使用できます。
静的テストは開発者がローカルで実行するだけではなく、パイプラインに組み込み自動的に実行する必要があります。
パフォーマンステストでシステムの応答性、スループット、信頼性、およびスケーラビリティを評価します。これによりアプリケーションがピーク負荷にさらされたときにユーザー体験を損なうことなく動作することを確認します。
UX テストを採用し、システムが変更されてもエンドユーザーにとって直感的で機能的であることを検証します。
ユーザー体験を向上させるにはユーザーの行動を評価し、ユーザーの共感を呼ぶ機能を開発します。
A/B テストを行うと大多数のユーザーから新機能を隠しながら小規模なサンプル内で機能をテストできます。潜在的な混乱が最小限に抑えられ詳細なデータが取得できます。
コンプライアンステストで内部および外部のコンプライアンス要件を満たしていることを検証します。
復元力テストでシステムの回復力を評価します。制御された障害を意図的に注入し、障害がどのように伝搬し他のコンポーネントに影響を与えるかについての洞察が得られます。
復元力テストには様々な種類があります。(カオスエンジニアリング、データ回復テスト、災害復旧テスト)
コントラクトテストでは、サービス間がシームレスに通信し、相互に互換性があることを検証します。
環境への影響を重視する組織によって持続可能性テストは有益です。
指標
[QA.NT.1] 静的テストを通じてコードの品質を評価する
[QA.NT.2] パフォーマンス テストによるシステムの信頼性の検証
[QA.NT.3] UX テストでユーザー エクスペリエンスを優先する
[QA.NT.4] 実験を通じて段階的にユーザー エクスペリエンスを向上させる
[QA.NT.5] 適合性テストを通じてコンプライアンス標準への遵守を自動化する
[QA.NT.6] 復元準備を構築するために復元力テストを使用して障害を実験する
[QA.NT.7] 契約テストによるサービス統合の検証
[QA.NT.8] 持続可能性テストによる環境に配慮した開発の実践
セキュリティテスト
セキュリティテストでは、システム内の潜在的な脆弱性、脅威、リスクなどを特定します。
自動化された脆弱性スキャンをパイプラインに統合して、セキュリティ脆弱性と改善に関するフィードバックを早い段階で開発者に提供します。
DevOps で脆弱性管理を効果的に実践するには、セキュリティが全員の責任という文化を採用することが重要です。
セキュリティツールの多様性を考慮すると、様々なソースから様々な結果を受け取ることがあります。ツールの多様性により混乱と非効率が生じる可能性を減らすために、共通フレームワークを採用します。例えば、CVSS のような認知されたスコアリングシステムを選択します。
ソフトウェア開発ライフサイクルのなかでセキュリティリスク評価を行います。ライフサイクルの初期段階では、セキュリティ専門家による設計レビューを取り入れます。
静的アプリケーションセキュリティテスト (SAST) はソースコード内の潜在的な脆弱性をアプリケーションに混入させる前に特定する対策です。
CI パイプラインに組み込みスキャンします。言語やフレームワークのサポート、修正コードの提示機能、誤検知率などを考慮します。
動的アプリケーションセキュリティテスト (DAST) は実行中のアプリケーションの脆弱性が検出されます。DAST は実行中のセキュリティの弱点を発見することで、本番環境で脆弱性が悪用される可能性を減らします。
ソフトウェア構成分析 (SCA) は OSS やサードパーティコンポーネントなどの外部依存関係に既知の脆弱性がないことを確認します。SCA は SBOM や依存関係マニフェストファイルなどをスキャンします。
ペネトレーションテスト、レッドチーム、脆弱性開示、バグ報奨金プログラムなどの探索的なセキュリティテスト活動を実施します。
インタラクティブアプリケーションセキュリティテスト (IAST) はエージェントを使用してアプリケーション内からリアルタイムでセキュリティリスクを観察します。
指標
[QA.ST.1] DevOps 実践に役立つ脆弱性管理プロセスを進化させる
[QA.ST.2] セキュリティ テストの結果を正規化する
[QA.ST.3] 安全なソフトウェア設計のためのアプリケーション リスク評価の使用
[QA.ST.4] 静的アプリケーション セキュリティ テストでソース コードのセキュリティを強化する
[QA.ST.5] 動的アプリケーション セキュリティ テストによるランタイム セキュリティの評価
[QA.ST.6] ソフトウェア構成分析を使用したサードパーティ コンポーネントの検証
[QA.ST.7] プロアクティブな探索的セキュリティ テスト活動を実施する
[QA.ST.8] インタラクティブなアプリケーション セキュリティ テストを使用してセキュリティ テストの精度を向上させる
データテスト
データテストの目的は、データの様々な属性を評価して、重複、欠落、エラーなどのデータ品質の問題を特定することです。
データ品質テストはアプリケーション内で使用されるデータの精度、一貫性、全体的な品質を評価します。事前定義されたルールに照らして検証を行います。
データプロファイルツールを使用してデータを分析し、不一致、外れ値、欠損値などの問題を特定します。ツールを使用してプロセスを自動化します。
データロジックテストは、アプリケーション内のデータ処理と変換の精度を検証します。
データ品質問題の可能性を示すメトリクスを分析して、データ異常検出を行います。 ML アルゴリズムと統計手法をデータ品質監視プロセスに統合します。
増分メトリクスを活用するとデータ品質を効率的に監視および維持できます。データ品質テストに費やす計算リソースと時間が削減されます。
指標
[QA.DT.1] データ品質テストでデータの整合性と正確性を確保する
[QA.DT.2] データ プロファイリングを通じてデータの理解を強化する
[QA.DT.3] データ ロジック テストによるデータ処理ルールの検証
[QA.DT.4] 異常検出によるデータの問題の検出と軽減
[QA.DT.5] 増分メトリクス計算を利用する
自動化されたガバナンス
ガバナンスを自動化することで、組織はリスク管理、コンプライアンス、セキュリティに対する標準化された一貫したアプローチを確保できます。これにより、手動による介入の必要性が減り、スケーラビリティが向上し、すべての管理対象環境全体でベストプラクティスが推進されます。
安全なアクセスと委任
チームに必要な自律性を提供しながら、きめ細かいアクセス制御を管理する方法を確立します。
フェデレーテッドアクセスと一時的な認証のための中央アクセス管理システムを実装します。SSO 機能を提供できると複数のシステムで個別の ID 管理システムを持たずにすみます。
特定のタスク向けに有効期間の短い一時的な認証を提供すると、不正アクセスやキー漏洩の損害を軽減できます。
分散型 IAM 責任モデルを作成します。ガードレール内でチームが動作する限り、個々のチームがロール作成や権限割り当てを処理できるようになります。
開発チームがセキュリティリスクを軽減しながら IAM タスクを管理できるようなバランスのとれたガードレールを定義します。
パイプラインは DevOps を実践する際のあらゆる側面において極めて重要になります。パイプラインにも最小権限の原則を適用します。このことで攻撃対象領域を減らし DevOps 全体のセキュリティを強化します。
DevOps モデルの開発ライフサイクルにおいてパイプラインが重要な役割を担うようにつれて、人間がアクセスする必要性が減少します。人間のユーザーのアクセス権を最小化します。
問題発生時などに強いアクセス権が必要になるケースがあります。明示的な要求と承認に基づいて、特定期間と目的に応じた権限がジャストインタイムで提供されるようにします。
緊急時のアクセス手順を確立します。ID プロバイダーの障害、セキュリティインシデントなど緊急事態が発生したときのためです。このアクセス手順も監査可能であること、ハードウェアベースの MFA を構成するなど厳密な制御が必要です。
組織の変化に合わせて役割と権限も変更されます。権限やガードレールの微調整が必要であるかレビューを実施します。
実際のアクティビティに基づいて権限を自動調整します。
シークレット、キー、証明書を定期的にローテーションすることは、リソース侵害の影響を限定するのに役立ちます。
パイプラインによって使用されるシークレット、キー、証明書を定期的にローテーションしましょう。
インジケーター
[AG.SAD.1] 一時的な認証情報の自動販売によるアクセスの集中化と連携
[AG.SAD.2] ID とアクセス管理の責任を委任する
[AG.SAD.3] パイプラインを実稼働リソースとして扱う
[AG.SAD.4] ジャストインタイム アクセスによる人間のアクセスの制限
[AG.SAD.5] ブレークグラス手順を実装する
[AG.SAD.6] ID およびアクセス管理の定期的なレビューを実施する
[AG.SAD.7] シークレット、キー、証明書のローテーション ポリシーを実装する
[AG.SAD.8] ゼロトラスト セキュリティ モデルを採用し、アイデンティティ中心のセキュリティ境界に移行する
データのライフサイクル管理
データライフサイクルを通じで、厳格なデータ管理、プライバシー、主権、セキュリティを強化します。
データ侵害のリスクを軽減するために、保存中および転送中のデータを暗号化します。
データパイプラインは、様々なソースからデータを収集、変換、保存のするためのステップです。データパイプラインを介したデータ管理は自動化します。
プライバシーやコンプライアンスの強化のため、データは機密レベルやタイプに基づいて識別、タグ付け、分類します。
高度なユースケースの場合、AI/ML ツールによってこれらは自動化されます。
データの保存と削除は複雑さと重要性が増しています。コンプライアンス遵守だけではなく、リスクの軽減、コスト最小化、運用効率向上などが目的です。
組織のデータライフサイクルポリシーを定義することから始めます。
コラボレーションと生産性向上のために一元化されたデータレイクを使用します。信頼できる単一のデータソースは、データのサイロ化と不整合の削減に役立ちます。
データ損失は致命的な事態をとなる可能性があります。データが維持され必要なときに使えるように自動バックアップメカニズムを実装します。
バックアップするデータの種類、頻度、保持期間を示すバックアップポリシーを定義します。
データ出所追跡を実装します。データの起源、いつどのように処理されたか、責任者を追跡します。追跡はデータの完全性、信頼性、トレーサビリティを確保する上で重要です。
指標
[AG.DLM.1] ビジネス継続性を維持するための復旧目標を定義する
[AG.DLM.2] 体系的な暗号化の適用によりセキュリティを強化する
[AG.DLM.3] パイプラインを使用してデータ プロセスを自動化し、信頼性の高い収集、変換、保存を行う
[AG.DLM.4] スケーラブルな分類戦略によるデータ コンプライアンスの維持
[AG.DLM.5] 体系的なデータ保持戦略によりリスクとコストを削減する
[AG.DLM.6] 共有データを一元化してガバナンスを強化する
[AG.DLM.7] 自動バックアッププロセスでデータの安全性を確保
[AG.DLM.8] データ出所追跡によるトレーサビリティの向上
動的な環境プロビジョニング
組織のランディングゾーン内で複数の環境を作成、維持管理するための戦略を確立します。
指定された構成状態またはベースラインと一致するように、個々の環境を定期的に確認します。これは大規模な環境全体で一貫性を確保し、エラーを最小限に抑え、
運用効率とガバナンスを強化します。
ランディングゾーンのベースラインに変更が加えられるたび、または、個々の環境で構成差異が検出されるたびに、対象の環境を変更します。
環境やアカウントを IaC または API コールでプロビジョニングします。チームはセルフサービス方式で自律的に環境を構築、管理できるようになります。
ランディングゾーンへの変更は組織内の多くのチームに影響を与える可能性があります。ランディングゾーンへの変更は、本番環境へデプロイする前にランディングゾーンテスト環境で動作検証を行います。
インジケーター
[AG.DEP.1] 制御された複数環境のランディング ゾーンを確立する
[AG.DEP.2] 環境のベースラインを継続的に管理してドリフトを管理する
[AG.DEP.3] ランディング ゾーンへのデプロイメントを有効にする
[AG.DEP.4] 環境自動販売機の体系化
[AG.DEP.5] 環境全体で共有リソースを標準化および管理する
[AG.DEP.6] ミラー化された非運用ランディング ゾーンでのランディング ゾーンの変更のテスト
[AG.DEP.7] スケーラブルな環境管理のためのメタデータの利用
[AG.DEP.8] セルフサービス環境管理のための統合開発者ポータルを実装する
自動化されたコンプライアンスとガードレール
ガードレールにより、指示的、発見的、予防的、対応的な処置を自動的に実施します。
DevOps でのコンプライアンス管理は、ペースが速く、反復的で、分散されているため従来よりも難しく感じることがあります。
NIST サイバーセキュリティフレームワーク、ISO 270001、CIS などのリスクベースコンプライアンスフレームワークは構造化された方法論を提供します。
自動化された一元的な検出機能を実装します。これにより潜在的なセキュリティ問題や構成ミスを検出します。
コンプライアンスを強制するために予防ガードレールを実装します。検出と予防をバランスよく使い、開発の迅速性とセキュリティ対策を両立させます。
ガードレール非準拠の問題を手動で特定して修正するには時間がかかり、エラーが発生しやすくなります。非準拠の修正は自動化します。
自動化されたコスト管理ツールによって、チームは予算を維持できます。 DevOps によりデプロイ頻度が増加するにつれて、コスト管理のガードレールを導入する重要さが高まります。
コストアラートなどの追跡メカニズムを導入します。
時間の経過とともに、休止中のサーバー、未使用のリソース、アイドル状態のコンテナなどが実験の副産物として残ります。これらのリソースはコスト増の原因、セキュリティリスクの増大につながる可能性があります。
自動スキャンを実装し、未使用リソースの検出と削除を行います。
インジケーター
[AG.ACG.1] リスクベースのコンプライアンス フレームワークを採用する
[AG.ACG.2] 新しいサービスと機能を導入するための制御された手順を実装する
[AG.ACG.3] 検出コントロールの展開を自動化する
[AG.ACG.4] ユビキタスな予防ガードレールでセキュリティ体制を強化する
[AG.ACG.5] データ規制とポリシーのコンプライアンスを自動化する
[AG.ACG.6] 非準拠の検出結果に対する自動修復を実装する
[AG.ACG.7] 自動化ツールを使用してスケーラブルなコスト管理を行う
[AG.ACG.8] 定期的なスキャンを実行して、未使用のリソースを特定して削除する
[AG.ACG.9] 開発ライフサイクル全体を通じてソフトウェアの出所追跡を統合する
[AG.ACG.10] 追跡システムでの検出結果の解決を自動化する
継続的な監査
構成や運用ポリシーを継続的に評価し、遵守状況を測定します。
包括的な監査証跡を保管します。監査証跡には全てのアクショのキャプチャ、記録が含まれます。
これによりセキュリティ監査に役立つログが提供され、不審なアクティビティの特定、コンプライアンス違反の証拠、問題の根本解決を行います。
DevOps は動的であり急速な変更が特徴です。急速な開発サイクルでは、一時的な例外を作成する場合があります。
これらの例外は必要ですが、適切に管理しないと予期せぬ問題が発生します。
例外の背後にある理由、いつ行われたか、誰が承認したか、例外の期間など文書化し、再検討されるようにします。
イベント駆動型の監査アプローチを採用します。これにより問題の即時検出と対応が可能になります。
指標
[AG.CA.1] 包括的な監査証跡を確立する
[AG.CA.2] 構成アイテム管理の最適化
[AG.CA.3] 体系的な例外追跡およびレビュー プロセスを実装する
[AG.CA.4] 反復的な内部監査の実践を可能にする
可観測性
外部出力を通じてシステムの内部状況を理解します。これにより、問題を効果的かつ効率的に検出、対処できるようになります。
戦略的インスツルメンテーションの導入
戦略的インスツルメンテーションは、アプリケーションやインフラから有意義で実用的なデータを取得する監視システムを設計および実装することを目的とした機能です。
テレメトリの収集、KPI の追跡、データ主導の意思決定が含まれます。
可観測性の影響を最大化するには、可観測性がビジネス目標と技術目標の両方と連携している必要があります。
システムのパフォーマンスやエラー率だけでなく、収益や顧客満足度にどのような影響を与えるか理解します。
可観測性戦略では、収集と分析に必要なメトリクス、ログ、トレース、イベントを特定し、これらを収集するツールとプロセスを規定します。
4つのゴールデンシグナル (遅延、トラフィック、エラー、飽和) に焦点をあてた最小限のメトリクスセットを作成します。
チームとリーダーは定期的にレビューし、メトリクスセットがビジネス目標と相関しているかを評価し適応させます。
可観測性ツールは、テレメトリデータの収集、正規化、集計をサポートする必要があります。ツールは手動介入をほとんど行わずにこれらを行います。
収集されたデータは最小権限のアクセス制御で保護される必要があります。
システム内の各サービスは、システムとその依存関係がどのように実行されているかのリアルタイムな洞察を得るためのヘルスチェックエンドポイントを含むよう構成します。
これは、ヘルスステータスを監視する重要なコンポーネントとして機能します。
顧客向けか内部使用かに関わらず、すべてのサービスの SLO を定義して文書化する必要があります。SLO 作成はビジネスチームと技術チームの両方が関与する共同作業です。
SLO は SMART である必要があります。
チームは SLO を測定、監視します。SLO を評価可能な SLI を作成します。
SLO がビジネス目標と技術目標に整合していることを確認するため、継続的な改善とレビューが必要です。
指標
[O.SI.1] ビジネスと技術的な成果を中心とした可観測性戦略
[O.SI.2] 合理化されたシステム計測とテレメトリ データ解釈のためのツールを一元化
[O.SI.3] 包括的なテレメトリ データ収集のためにすべてのシステムを計測する
[O.SI.4] すべてのサービスにヘルスチェックを組み込む
[O.SI.5] パフォーマンス標準に対するサービス レベル目標を設定および監視する
データの取り込みと処理
データの取り込みと処理を合理化することで、チームはより迅速かつ効果的な意思決定を行うことができます。
システム全体の包括的なビューを提供するために、複数のワークロードのログやイベントを集約します。
様々なソースからのログやイベント収集をサポートする集約ソリューションを実装します。
収集し視覚化するデータは以下のようなものがあります。
- セキュリティログやイベント
- 分散トレースデータ
- すべてのワークロードの健全性やステータスのメトリクス
- テレメトリデータ
指標
[O.DIP.1] ワークロード全体でログとイベントを集約する
[O.DIP.2] セキュリティ調査を強化するためにログを一元化する
[O.DIP.3] システム全体のリクエスト追跡のための分散トレースの実装
[O.DIP.4] ワークロード全体の健全性とステータスのメトリクスを集約する
[O.DIP.5] テレメトリ データのストレージとコストを最適化する
[O.DIP.6] テレメトリデータを共通フォーマットで標準化する
継続的な監視
一元的なアラートメカニズムを実装して、すべてのシステムの異常な動作を追跡します。
悪意のあるアクティビティ、侵害の兆候がある場合、自動的に通知される必要があります。
サービス停止や重大なセキュリティインシデントは、大規模イベント (LSE) を呼ばれます。
LSE を適切に管理し、ビジネスの継続性を確保し、顧客の信頼を維持します。
詳細な管理計画を作成し、LSE 発生時の役割、責任、プロセスの概要を示します。
インシデント後の振り返りを実施します。チームが今後のインシデントに備えて対応プロセスを最適化するためです。
すべての関係者が振り返りに参加します。
複雑なアプリケーションパフォーマンスの問題をプロアクティブに検出および診断するために、APM、RUN、合成モニタリングを実装します。
DEM はユーザーとアプリケーションの対話をシュミレートして、エンドユーザー観点からパフォーマンスと可用性を測定します。
ビジネスへの影響と重大度に基づいてアラートのルールとしきい値を最適化します。
効果のないアラートは削減しアラート疲れを軽減します。
指標
[O.CM.1] セキュリティとパフォーマンスの問題に対するアラートを自動化する
[O.CM.2] 大規模イベントの計画
[O.CM.3] 継続的な改善のためにインシデント後の分析を実施する
[O.CM.4] データ主導の意思決定を促進するビジネス指標に関するレポート
[O.CM.5] アプリケーション パフォーマンス監視を使用してパフォーマンスの問題を検出する
[O.CM.6] デジタル エクスペリエンス モニタリングを使用してユーザー エクスペリエンスに関する洞察を収集する
[O.CM.7] テレメトリ データをリアルタイムで視覚化する
[O.CM.8] データの透明性を確保するための運用レビュー会議を開催する
[O.CM.9] アラートを最適化して疲労を防ぎ、監視コストを最小限に抑える
[O.CM.10] AI/ML を使用して問題を積極的に検出する
Discussion