オペレーショナル エクセレンスの取り組みは継続的な改善の 1 つであり、各ステージは最後に構築され、ワークロードの設計、実装、サポート全体の効率と有効性を向上させます。
その中核となるのは、デプロイ、監視、テスト、自動化などの主要なプラクティスを合理化することです。 この取り組みは、共有ボキャブラリ、標準化されたプラクティス、コラボレーションと安定性を促進する DevOps の考え方という強力な基盤から始まります。 そこから標準化により、プロセスに一貫性と予測可能性が導入されます。 チームの能力が高まるにつれて、個々のタスクは統合ワークフローに進化し、自動化されたテスト、インテリジェントな監視、継続的インテグレーションなどの運用対応機能によってサポートされます。
システムが運用環境で稼働すると、運用がさらに高度になります。 Teams は、迅速かつ確実に変更を管理し、品質ベンチマークを満たして、自信を持って製品所有者からの機能要求を実装する機能を備えています。
最も成熟した段階は、最適化とイノベーションに関するすべてです。 ここでは、チームは大規模な運用を行い、進化するビジネス ニーズと技術シフトを満たすためにシステムをリアルタイムで継続的に適応させます。 ただし、これは固定の宛先ではありません。それは常に改善し、常に適応することの動的な考え方です。
モデルは 5 つの異なる成熟度レベルに構成され、それぞれが主な目標と一連のコア戦略を持ちます。 意味のある生産性の向上のために、最初から AI を運用に埋め込むことができる場所の評価を開始します。 各レベルを調べるには、以下のタブ付きビューを使用します。 また、読み進める中で、ハイライトされたトレードオフと関連するリスクも必ず確認してください。
AI 駆動型ツールを意図的に埋め込むことで業務プロセスを最新化し、手作業によるエラーが発生しやすい作業を減らし、測定可能な価値を実現します。
運用ワークフローをエンド ツー エンドで評価して、AI が一貫性と生産性を向上できる場所を特定し、コスト、リスク、価値までの時間を実際にバランスを取ります。
購入: 既製の GenAI ソリューション
既製の GenAI ツールには、組み込みの AI 機能があります。 これらは、意図によって大まかに分類できます。 カテゴリの 1 つは、コンテキストに依存し、さまざまなタスクに使用できる、GitHub Copilotなどの一般的な対話型支援ツールです。 これらのツールは、ほとんどまたはまったくセットアップを必要とせず、既存の開発者ワークフローに直接埋め込まれたコンテキスト対応の支援を提供します。 もう 1 つのカテゴリは、特定の機能用に設計された、展開エージェントや Site Reliability Engineering (SRE) エージェントなどの専用のツールとエージェントです。 IDE および CLI アシスタントを使用して、開発者の生産性のために統合できます。
一部のAzure サービスには AI 機能も統合されており、追加コストが発生する可能性があります。
カスタムの実装を用いたGenAIを構築する
Custom GenAI は、特定のワークロードに合わせて調整された運用および開発ワークフローに AI を直接埋め込みます。 カスタム エージェントは、チケット、コード リポジトリ、メトリック、監視システムからコンテキストをプルして、操作の現在の状態を反映し、定義された境界内で動作する分析情報を生成できます。
より高度な実装では、内部標準に対してコードまたはインフラストラクチャを生成して検証し、専門知識や可用性に基づいて作業をルーティングし、特殊な予測にカスタム 機械学習モデルを適用できます。 このアプローチにより、自動化が深まり、組織のプロセスとの連携が強化されますが、エンジニアリング、データ品質、ガバナンス、セキュリティ、メンテナンスへの継続的な投資が必要です。
AI の機能パターン
実際に使用される最も一般的で近い AI 機能の一部を次に示しますが、この一覧は網羅的ではありません。 この一覧を使用して、生産性を向上させるために AI を挿入できる操作の場所を評価します。
注
導入は時間の経過とともに意図的に進行する必要があります。 概要作成やコンテンツ生成などの重点的なユース ケースから始めて、機能と信頼度が高まるにつれてタスクやワークフローを推論するエージェント インターフェイスを導入します。 より高いレベルの成熟度では、マルチエージェント システムは統合システムとデータ全体で動作し、より複雑な運用シナリオをサポートします。
-
要約。 ドキュメント、レポート、ログ、または会話から情報を読み取って圧縮し、ユーザーが理解する言語と用語を使用する簡潔な概要と重要なポイントを生成する AI ツール。
-
推奨事項。 複数のデータ ソースを一緒に分析してパターンを検出し、運用上の意思決定のためのコンテキストに対応した推奨事項を提供する AI ツール。
-
成果物の生成。 定義された標準に準拠しながら、記述された要件を実行可能コード、インフラストラクチャ定義、自動テストに変換する AI ツール。
-
ポリシーの検証。 ポリシー、標準に照らしてコード、構成、ワークフローを確認し、ドキュメントを設計してコンプライアンスを適用する AI ツール。
-
最適化アクション。 アーティファクト間で分析情報を使用して作業をルーティングし、意思決定に対するアクションを実行する AI ツール。
注意事項
エージェントを使用する場合、セーフガードは架空ではありません。 1 つのチェックされていないモデル、1 つの不適切な自動化、または 1 つの制限を超えるアクセス設定によって、エラーの伝達、機密データの漏えい、大規模な運用の整合性の侵害が発生する可能性があります。
機密データを保護するには、すべてのプラットフォームで、厳密な個人データ マスクとセキュリティ トリミングを適用する必要があります。 ユーザーは、アクセスが許可されている出力のみを表示する必要があります。 その結果、AI の出力は不完全である可能性がありますが、潜在的な露出のコストによって完全な可視性が得られます。
ヒューマン レビューは、特にアーキテクチャ、セキュリティ、運用上の問題に関する要件のままです。 レビューでは、意図とリスクに焦点を当て、低レベルの構文ではなく組織の標準に適合する必要があります。 プロンプト、テンプレート、標準を継続的に改善できるように、レビューからのフィードバックを取り込む必要があります。
✓ 要約エージェント
要約エージェントは、通常、単純なCopilotスタイルのアーキテクチャを使用し、簡単な取得と応答の生成を行います。これにより、比較的簡単に実装および操作できます。
リスク: 要約には本質的に正確性のリスクがあり、特にエージェントが複数の文書にまたがる情報を統合する場合にその傾向が強まります。 エラーを完全に排除することはできませんが、説明可能性と増分ナビゲーションを実装することで運用上のリスクを軽減できます。 システムは、要約されたコンテンツを明確に示し、ユーザーが検証のためにソース マテリアルにドリルダウンできるようにする必要があります。
推論コストは時間の経過と同時に蓄積される可能性があります。 単純な要求をより小規模で低コストのモデルにルーティングし、複雑なマルチドキュメント合成のためにより高度なモデルを予約します。このアプローチで必要になる可能性がある追加のオーケストレーションを受け入れます。 簡潔な初期概要を提供し、ユーザーがサポートの詳細とソース コンテンツにドリルダウンできるようにします。
データ管理では、追加の非表示コストが発生します。 古いドキュメントや冗長バージョンによってインデックスが肥大化するのを防ぐために、データライフ サイクルを積極的に管理します。 履歴コンテキストが必要な場合は、制御されていない重複ではなく、意図的なバージョン管理によって以前のコンテンツを保持します。
ユーザーからの直接のフィードバックは貴重です。 概要の品質と有用性に関する入力をキャプチャし、それを使用して、モデル ルーティングの決定、インデックスの有効性、およびキャッシュまたは前処理戦略の影響を評価します。
例示
-
OE:01 DevOps 文化。 非構造化ドキュメントから、アクション アイテム、所有者、期限、リスク ステートメントなどの構造化された要素を抽出します。
-
OE:08 インシデント対応。 インシデント、事後分析、セキュリティ結果、監査レポートを要約して、スコープ、影響、結果をすばやく理解します。
推奨エージェント
推奨事項を提供する AI エージェントは、複数のデータ ソースを分析できる推論指向モデルに依存します。 これらのモデルには、軽量または純粋な生成アプローチに依存するのではなく、ソース間の相関関係をサポートするのに十分な分析深度が必要です。
トレードオフ： より広い範囲で価値を生み出すことができますが、相互参照されるソースの重み付けが間違ったり、元の意図に誤りがある可能性があります。 このような AI によって生成された応答に過度に依存すると、エラーが増幅され、問題が反復的な呼び出しと複合化する可能性があります。
クロスリファレンス ソースでは、通常、要求ごとのコストと推論の待機時間が増加します。 多くのきめ細かいクエリよりも、より少なくリッチなクエリを優先して、外部呼び出しを最小限に抑えます。 実行時に複数の外部ソースにアクセスして関連付けるのはコストがかかる可能性があるため、データ アクセスを並列化し、可能な場合は共有インデックスにデータを事前に読み込みます。
複数のソースを操作すると、統合が複雑になります。 1 つのソースのエラーは、推奨事項パイプラインを通じて伝達される可能性があります。 入力を組み合わせるときに検証とセキュリティ ガードレールを適用します。 低待機時間が必要な場合は、クエリ ソースを並列で実行します。 分類、エンリッチメント、ルックアップなど、特定の要求に依存しない手順を前処理します。 中間結果と頻繁に使用される機能をキャッシュして、繰り返し計算を減らします。
推奨エンジンは、ブラック ボックスではなく意思決定サポート システムとして扱います。 説明可能性は、信頼と運用上の信頼性を構築する上で中心的な役割を担います。 システムは、推奨事項の明確な根拠を提供し、主要なシグナルを強調し、データ ソースを提供する必要があります。 ダウンストリーム システムまたはユーザーが信頼性を測定するのに役立つ信頼度インジケーター (たとえば、0 ~ 100%) を含めるとします。
例示
-
OE:06 ワークロードサプライチェーンの設計。 検出が困難で、テスト スイートに含めるのが見落とされることが多い、顧客中心のエッジ ケースとシナリオを見つけます。
-
OE:08 インシデント管理。 AI を使用してベンダー移行計画を検証し、提供されているドキュメント、プレイブック、正常性モデル、エスカレーション パスのみを使用してベンダー サポート チームをシミュレートします。 シミュレーションでは、ハンドオフの前にギャップと非表示の依存関係が強調表示されます。
-
OE:10 オートメーション設計。 自動化コード、テレメトリ、インシデント データを評価して、どの自動化を改善、廃止、または拡張するかを推奨します。
✓ アーティファクト生成エージェント
AI エージェントは、コード、インフラストラクチャ定義、テストを生成するのに役立ちますが、その出力が運用環境のワークロードの一部になる可能性があります。 コード生成は本質的に非決定的であり、自然言語の要件を実行可能な成果物に変換すると、元の意図とは異なる結果が生成される可能性があります。 このため、明確な所有権、明示的な制御、既存のエンジニアリング プラクティスへの統合が不可欠です。 AI は、問題領域が十分に理解されていて、バリエーションが限られている場合 (たとえば、反復的または標準化されたコーディング タスク)、出力を導くためにガードレールを適用する必要がある場合に最も効果的です。
適切なモデルを選択することは重要です。 コードの生成とツールの実行に適したモデルを使用し、必要に応じてそれらを組み合わせます。 推論モデルは、システム分析、計画、または分解に役立ちます。コードに重点を置いたモデルは成果物自体を生成でき、追加のモデルはテストまたはデプロイの手順をサポートできます。
生成は、テンプレート、参照実装、コーディングガイドライン、および組織および業界標準を反映した例に基づく必要があります。 明確な標準は、ドリフトを検出し、一貫性を強制するのに役立ちます。 テンプレートを使用すると、AI の出力がより予測可能になります。
ほとんどのエージェントと同様に、コード ジェネレーターは複数のソースから描画できます。 すべての出力は、検証されるまで信頼されていないものとして扱う必要があります。 最小特権の原則を適用して、ツールの実行のアクセス許可とスコープを制限します。 エージェントは、明示的な承認なしに運用リソースをデプロイまたは変更しないでください。
生成された成果物を標準の開発者ライフ サイクルに統合します。 このサイクルには、プル要求、コード レビュー、自動テスト、セキュリティ スキャンが含まれます。 信頼性とコンプライアンスを確保するために、依存関係チェックやコードとしてのインフラストラクチャ (IaC) スキャンなど、人間が作成したコードに適用するのと同じ厳しさを適用します。
トレードオフ： ヒューマン レビューは引き続きコスト モデルの一部であり、ROI に組み込む必要があります。 さらに、アーティファクトの生成が増加すると、スループットの負荷が下流に移ります。 新しいボトルネックが発生しないように、テスト、検証、デプロイのワークフローを適宜スケーリングする必要があります。 リンター、テスト、静的分析、ポリシー チェックを使用して検証を可能な限り自動化することは、エンドツーエンドのフローと価値への時間を維持するために不可欠です。
例示
-
OE:02 業務を標準化する。 組織の標準に準拠したコード成果物とドキュメント成果物を生成し、資産の進化に合わせて標準ドキュメントを更新し続けます。
-
OE:07 監視システムを設計する。 ソース間で適切なメトリックを自動的に選択することで、エンジニアリング メトリックをビジネス成果に合わせた統合ダッシュボード構成を生成します。
-
OE:10 オートメーション設計。 運用環境で構成ドリフトを自律的に監視し、意図した状態を推測し、ブートストラップ定義を更新して、時間の経過と同時にシステムを調整します。
✓ ポリシー検証エージェント
AI エージェントは、ポリシーと標準に対する資産の確認と検証に役立ちます。 彼らの役割は、意思決定をサポートし、逸脱にフラグを設定し、コンプライアンスを適用することです。 人間は最終的な監視を維持します。
検証は、ロールアウト前に慎重な評価とテストから始まります。 標準はバージョン管理する必要があり、各資産は適用可能なポリシーを明確に参照する必要があります。これにより、追跡可能性が確保されます。 ポリシーが進化するにつれて、メンテナンスのオーバーヘッドを考慮し、それに応じて検証プロセスを更新する必要があります。 可能であれば、レビューをバッチ処理して並列化し、すべての資産を再スキャンするのではなく、変更に対する増分チェックに焦点を当てます。
コストとパフォーマンスのバランスを慎重に取る必要があります。 正確な予測を行うために必要な履歴データの量を考慮しますが、ストレージ、処理、待機時間への影響も考慮してください。 データが少なすぎると信頼性が低下しますが、コストが大きすぎます。
セキュリティは引き続き重要な要素です。 機密情報が確実に保護されるように、検証出力へのアクセスは、セキュリティ レビュー担当者などの承認されたユーザーに制限する必要があります。
有効性は、想定されずに測定されます。 ダッシュボードを使用して、検出された問題と運用環境の問題、誤検知、カバレッジなどのメトリックを追跡します。 これらの分析情報を検証ロジック、プロンプト、運用プロセスにフィードバックして、エージェントの貢献度を継続的に調整します。
例示
✓ アクション最適化エージェント
アクションの最適化エージェントは、直接的な運用アクションを実行することで、分析と推奨事項を超えて拡張されます。 出力によってシステムまたはプロセスが変更される可能性があるため、これらのエージェントには、ワークフローへの慎重な設計、監視、統合が必要です。
リスク： セキュリティは主な懸念事項です。 エージェントは、運用環境で実行する前に提案されたアクションをレビューして承認する、ループ内の人間のワークフロー内で動作するのが理想的です。 ツールとシステムへのアクセスは、最小限の特権の原則に従い、エージェントをタスクの実行に必要なアクセス許可のみに制限する必要があります。 詳細な監査は不可欠であり、提案されたアクション、承認者、および追跡可能な実行ログをキャプチャします。
各変更の範囲を制限することで、最小のブラスト半径を適用するガードレールを実装します。 ツールの実行は、安全な再試行を可能にするためにべき等である必要があり、システムには検証とロールバックのメカニズムが含まれている必要があります。 チェックポイント、バックアップ、またはその他の復旧戦略は、意図しない変更の安全な修正をサポートできます。
例示
-
OE:08 インシデント管理。 アラートが発生するとすぐに、コンテキストを自動的に収集し、データを関連付け、初期トリアージを実行します。 これにより、エンジニアは、手動でデータを収集する代わりに、明確なインシデント画像から開始できます。
-
OE:10 オートメーション設計。 監視データの分析から推論された値を使用して、人間が定義した境界内で、キャッシュ サイズやタイムアウト値などのリスクの低い運用設定を継続的に最適化します。
-
OE:11 安全な展開のプラクティス。 最適なロールアウトのタイミングと、カナリア デプロイの適切なターゲット セグメントと割合を自律的に識別することで、プログレッシブ 露出デプロイ戦略を自動化します。
問題解決におけるチームワークと一貫性を強調し、後の段階で一貫した安定した運用を生み出す強力な基盤を確立します。
将来の戦略を確実に成功させるために、レベル 1 で DevOps の考え方を確立します。 プロセス効率を向上させるために、確立された DevOps 手法を実装します。 安定した運用のために、不可欠で一般的なボキャブラリ、プロセス、ツールの構築に重点を置きます。
主な戦略
✓コラボレーションを奨励し、非難のない文化を育む
チームの取り組みをビジネス ニーズに合わせ、コラボレーション文化を育てます。
一元化されたチームのメンバー、ワークロード機能専用のフルタイム スタッフ、パートナー、またはベンダーは、多くの場合、ワークロード操作を管理します。 これらの個人は、互いの専門知識を尊重し、認め合い、集団的な力として機能する必要があります。 チームが独立したパーツとして動作すると、複雑さと摩擦が発生する可能性があります。 独立したチームは、ビジネス成果を推進する単一の効率的なシステムとして機能するという目標を損ないます。
分離された所有権の感覚を減らすには、問題解決のための統一されたアプローチを推奨します。 すべての努力は、ビジネスのニーズに対応する必要があります。 成功と失敗の両方を共有結果として表示します。
ワークロードに合わせて開発効率を向上させる、業界で実証済みのツールとソフトウェア開発ライフサイクル (SDLC) プロセスから始めます。 多くの場合、高い摩擦が発生するため、実証済みの方法から逸脱し、カスタム手法を回避しないでください。
アジャイル、スクラム、かんばんボードなど、一般的な選択肢があります。 ほとんどの経験豊富な開発者、DevOps エンジニア、製品所有者は、これらのツールに精通しているため、新入社員の学習曲線が最小限に抑えられます。
最初は、確立された業界標準を使用して標準化を組み込みます。 後でプロセスを最適化します。 選択したツールが、最先端のソリューションへの切り替えを途中で必要とせずに、ニーズに合わせて成長できることを確認します。
✓ ソース管理プロセスを設定する
アプリケーションの規模に基づいて、ソース コードの構造を決定します。 大規模なシステムの場合、各チームには、担当するコンポーネントを構築および展開するための独自のプロセスが必要です。 コンポーネントの検出可能性とシステムの他の部分との共有を可能にするインターフェイスが明確に定義されている必要があります。 ソース管理テクノロジを選択し、チーム メンバーが互いの作業に干渉しないようにプロセスを設定します。
同様に、小規模なアプリケーションでは、1 つのデプロイ パイプラインの方が効果的な場合があります。 これにより、調整が簡略化され、信頼性も向上する可能性があります。 ただし、システムの特定の部分を更新または移行するのは困難な場合があります。
✓ コードとしてのインフラストラクチャ (IaC) をプライマリ デプロイ アプローチとして使用する
デプロイの標準として宣言型アプローチを使用して、一貫性、再現性、および自動化、自己文書化、変更履歴などの長期的な利点を確保します。
一貫性のない構成やテストの欠如によるリスクを回避するには、ポータルのデプロイよりも IaC デプロイを優先します。 特定のプログラムに制限されているコンパイル済みの言語または独自の形式は使用しないでください。
Bicep や Terraform など、Azure がネイティブにサポートするツールを使用して、適切な基盤から始めます。 ツールを評価して、将来の作業を簡略化します。 テクノロジ プロバイダーに適切なドキュメントと信頼性の高いサービス サポート プログラムがあることを確認します。
リスク： 最新化の機会を逃したことをリスクと考えてください。 たとえば、オンプレミス ソリューションで使用するツールとプロセスを最新化する必要があります。 クラウドに移行する場合、多くの場合、これらのツールでは管理が困難なカスタム スクリプトが必要であり、最新化しないと問題が発生する可能性があります。
このリスクを軽減するには、最新のテクノロジ オプションを調べて、オンプレミス のプロセスを更新します。
IaC を採用するための目標の 1 つは一貫性です。 さまざまな環境にデプロイするのに十分な柔軟性を持つテンプレートを作成します。 パラメーター、変数、および構成ファイルを使用して、各環境のリソース設定を変更します。 必要な設定のみを抽象化し、ほとんど変更されない設定の過剰な抽象化を避けます。 また、広範なテンプレート ライブラリに依存して、ソリューションの複雑化を避けてください。 この方法は、メンテナンスの課題につながる可能性があります。
将来のレベルで展開とシステム管理の最適化のためのより多くの機会を作成するための強固なIaC基盤を確立します。 たとえば、目的の状態構成や GitOps を追加できます。
✓最初からセキュリティに優先順位を付ける
この初期段階でもセキュリティに優先順位を付けます。 セキュリティ対策は、多くの場合、ロール、リソース、ネットワークなどのセグメント化に基づいており、複雑さが生まれます。 チームは、これらの複雑さを認識し、早期にセキュリティ対策を構築し、時間の経過に伴うセキュリティへの投資を計画する必要があります。 この方法では、セキュリティ実装を後のステージに遅延させるのを回避できます。
リスク： 開発、サポート、運用のプロセスは摩擦を生む可能性があります。 多くの場合、セキュリティの取り組みは、チームが善意で強いスタートを切っても抵抗に直面します。
リスクを軽減するには、バックログにセキュリティ タスクを追加します。 このプラクティスにより、チーム内のアカウンタビリティが確保され、開発タスクと共に進行状況を追跡できるようになります。
ツールとプロセスを透過的にし、監査とピア レビューを通じて脆弱性を簡単に検出できるようにします。 脆弱性スキャンとセキュリティ制御をサポートする業界標準のツールを、まだ完全に実装していない場合でも確認します。
さまざまな ID コントロール プレーンを最小限に抑えるために、ツールとデプロイのプラクティスで運用環境と同じ ID プロバイダーが使用されていることを確認します。
基本プロセスを標準化します。このアプローチにより、意思決定の責任が合理化され、システムの展開と監視の要件が定義されます。
レベル 2 では、チームはより構造化されたアプローチを採用し、開発アクティビティをワークロードのコア機能に集中させる必要があります。 一貫性を早期に確立することで、後の段階で運用上の負担を最小限に抑えることができます。
主な戦略
✓ チームの役割と意思決定の責任を定義する
製品の考え方を採用する。 ワークロードをツール、テクノロジ、またはジョブ機能の統合として見るのではなく、最終的な目標に明確に焦点を当てたまとまりのある製品として扱います。 レベル 2 では、各ロールが明確に定義され、尊重される、より構造化されたアプローチを適用します。
チーム内の専門知識は、多くの場合、異なります。 この多様性は、さまざまな職務間で意思決定を分散するのに役立ちます。 たとえば、特定のチーム メンバーは技術的な決定を行うのに優れていますが、他のチーム メンバーは、エコシステムで競争力を維持するためにビジネス成果を定義する専門家である可能性があります。
リスク： 一部のワークロード チームはコンセンサス主導のカルチャを採用し、全員が同意した場合にのみタスクにコミットします。 この文化は包摂性を促進しますが、完全なコンセンサスが達成されないとイニシアチブを妨げることがよくあります。
次の原則を使用して、適切に構造化された意思決定プロセスを確保します。
意思決定がチーム メンバー間で分散され、1 人のユーザーと一元化されるのではなく、専門知識の領域と一致するように、直接責任を持つ個人を指定します。
意思決定者を文書化し、この情報を新入社員のオンボーディング資料に含めます。
特定の役割と責任を明確に定義する意思決定手法を採用することを検討してください。 これらのアプローチは、部門を作成し、製品の目標からフォーカスをシフトできることに注意してください。 チェックとバランスを確立して、サイロ化された意思決定を防ぎ、摩擦を軽減します。
✓ どんなに小さくても改善に努める
継続的な改善の考え方を育てることは、今日、彼らが明日洗練されることを理解して意思決定を行うことを意味します。
変更を遅らせると、チームは現在の改善の機会を逃す可能性があります。 考え過ぎや優柔不断は避けてください。 完璧なソリューションを追求すると、小さいながら意味のある進歩が妨げられる可能性があります。 改善の方法を継続的に追求しながら、今すぐ改善することに重点を置く。
技術的負債は、短期的な意思決定をキャプチャするための開発における戦略的ツールです。 増分更新の動機として機能し、不要な蓄積を防ぐことができます。 技術的負債をバックログの定期的なタスクとして扱います。
✓ 基本プロセスの標準化
ワークロードのさまざまなクラスには、固有の特性に合わせて調整された独自のプロセス要件があります。 たとえば、AI ワークロードは、機械学習操作と生成型 AI 操作に依存して、データ パイプラインをモデルに駆動します。 ミッション クリティカルなワークロードは、サイトの信頼性エンジニアが迅速に操作できるリアルタイム監視ダッシュボードに優先順位を付けます。
ワークロード クラス内では、一貫性を強化し、運用上の負担を軽減するための標準化に努めます。 判別モデルと生成モデルの両方を含む AI ワークロードの場合は、データ操作に関するプロセスを標準化します。 これらの操作には、モデルまたは地上生成 AI モデルのトレーニングに使用される前のデータ アクセス、クレンジング、変換が含まれます。
次のユース ケースでは、標準化をお勧めします。
| プロセス |
メリット |
| 問題の追跡と管理 |
ロール間のより良いコミュニケーションを容易にし、優先順位付けに役立ち、過去の問題の履歴分析に必要です |
| 通信ツールとプロセス(特にインシデントを処理するため) |
コミュニケーションミスのリスクを最小限に抑え、チーム メンバー間の調整を改善して問題をより迅速に解決します |
| コード スタイル、リソースの名前付け規則、ドキュメント標準 |
ガイドラインを確立することで、コードの読みやすさと保守容易性を向上させる |
| プロシージャのテスト |
すべての変更が選択した一連のテストを通過することを保証します。これにより、品質保証が提供されます |
| 継続的インテグレーションと継続的配置 |
コード変更の自動テスト、統合、デプロイを保証し、結果としてより信頼性の高いリリースを実現します |
リスク： 継続的な改善とイノベーションは、多くの場合、チームが確立された標準から若干逸脱して、より良いアプローチを探るときに発生します。 これらの偏差は推奨されますが、構造化されている必要があります。 たとえば、イノベーションの日をホストすることで、チームは事前に選択された改善プロジェクトに集中でき、新しいアイデアや実験が促進されます。
標準化されたプロセスには、効果的な実装に必要なツールが含まれます。 このレベルでは、カスタムビルドのソリューションではなく、既製のソリューションに優先順位を付けます。このソリューションは、後で特殊なユース ケースについて再検討できます。
ワークロード用の日常的なツールには、開発、テスト、監視、デプロイ のツールが含まれます。 購入したツールはワークフローを合理化し、一貫性を確保します。 この一貫性により、チームはカスタム ソリューションの開発と保守の複雑さなしで機能の提供に集中できます。
リスク： ツールを検討する場合、多くの場合、ツールの機能拡張と将来の可能性を、そのコア機能ではなく過大評価する傾向があります。 この段階では、実用的で、現在の問題に対処し、現在のワークフローに適合するツールに焦点を当てます。
✓ ワークロード全体で自動化を採用する
新規または既存のワークロードを開発するときは、自動化を統合する機会を求めます。 最初から自動化を念頭に置いて新しいワークロードを設計すると、将来の導入がシームレスになります。 同様に、既存のワークロード ( ブラウンフィールド ワークロード) に自動化を組み込むことで、ライフサイクルの早い段階で効率を高め、一貫性を維持することができます。
導入を効率化するには、ソリューションをゼロから構築するのではなく、クラウド プラットフォームと互換性のある成熟した使い慣れた既製ツールを使用します。 クラウド プロバイダーのネイティブ自動化ツールを調べて、設計を簡略化します。 たとえば、多くの Azure サービスでは、ディザスター リカバリーのパフォーマンスとフェールオーバーの機能に対する自動スケールがサポートされています。 Microsoft 以外のツールを評価する場合は、チームの専門知識と関連するビジネス標準を考慮します。
自動化の利点は次のとおりです。
監視やアラート、更新管理などの日常的な運用タスク
展開やテストなどのソフトウェア開発ライフサイクル タスク
リソースのスケーリングなどのワークロード パフォーマンスの最適化
スキャンやポリシーの適用など、セキュリティとガバナンスのメカニズム
バックアップと回復のアクティビティ
リソースの割り当て解除やシャットダウンなどのコストの最適化
リスク： ワークロード開発の初期段階では、ワークロードの提供から運用環境への注意を転用する可能性があるため、自動化の構築または統合に重点を置きすぎないように注意してください。 開発速度を維持しながらワークロードを管理できるように、測定されたアプローチを取ります。
トレードオフ： 人間が頻繁に、効率的に安全にタスクを実行できる場合は、自動化する価値がない可能性があります。 たとえば、証明書の年次更新を自動化しても、開発サイクルの投資が正当化されない場合があります。
レベル 1 では、アプリケーション コード用のインフラストラクチャとパイプラインをデプロイするために、コードとしてのインフラストラクチャ (IaC) ツールを採用することに重点を置きます。 レベル 2 では、そのプラクティスを拡張して、デプロイされたインフラストラクチャとアプリケーションの構成と管理を含めます。
目的の状態構成アプローチを使用して、リソースをブートストラップし、構成の誤差を回避します。 タスクやプラットフォームが異なると、さまざまな自動化ツールが必要になります。 たとえば、Ansible は仮想マシン (VM) の望ましい状態構成を管理するのに適していますが、Flux などの GitOps ソリューションは Kubernetes クラスターに適しています。
デプロイ後のタスクに適したレベルの自動化を決定し、設計をシンプルにしながら運用上の負担を最小限に抑えます。 証明書のインストール、OS 構成、データベースのシード処理などのタスクはすべて、自動化に適したオプションです。 また、新しくデプロイされた VM またはコンテナー ホストでのアプリのデプロイと構成を含むように自動化を拡張することを検討してください。
リスク： 不要なツールの無秩序な拡大を避けます。 異なるアプローチとテクノロジを使用する開発者または開発チームは、ツール エコシステムが破壊される可能性があります。 要件を満たすワークロードの選択された数のツールを標準化し、ワークロード チームがそれらのツールでトレーニングされていることを確認します。 ツールに関する組織標準の採用には慎重になってください。 ワークロードに過度のリスクを追加するツールを組織が提案している場合は、より適切な代替ツールを評価します。
✓ ワークロードのデプロイ戦略を定義する
デプロイ戦略は、オペレーショナル エクセレンスの重要なコンポーネントです。 適切に設計されたデプロイ戦略により、更新または変更中のダウンタイムを削減または排除することで、ユーザーがサービスを引き続き利用できるようになります。 変更を運用環境にデプロイする方法とタイミングについて、利害関係者から合意を得る。 次の点を考慮してください。
許容されるダウンタイムを定義します。 重大な問題や財務上の損失を引き起こすことなく、ワークロードがダウンタイムをサポートできるかどうかを判断します。 ダウンタイムゼロが定期的なデプロイの要件であるかどうかを明確に指定します。
デプロイの頻度を確立します。 機能開発に基づいてデプロイの頻度を決定します。 スケジュールは毎日、毎週、四半期ごと、または他の適切な方法で決定します。 可能な場合は、シナリオに合わせて、より小規模で頻繁なデプロイに優先順位を付けます。
緊急展開を計画する。 セキュリティ修正プログラムなど、緊急展開を管理する手順を実装するための計画を策定します。 このアプローチにより、チーム メンバーは自分の責任を理解し、必要に応じて迅速に行動できます。
エラーを最小限に抑え、一貫性を確保するために自動化できる反復可能なデプロイ システムを設計します。 前回のデプロイでエラーが発生した場合にシステムを機能状態に復元するためのロールバックのプロビジョニングを含めます。
✓ ワークロード監視スタックを設計する
監視システムを設計するには、監視する対象を選択し、ユーザーに対するこれらのメトリックの重要性を理解する必要があります。
まず、ワークロード内のすべてのコンポーネントからログとメトリックを収集します。 プラットフォームが提供する監視ツールを利用します。 これらのツールはサービスと統合され、機能と運用に関する分析情報を少ない構成で提供します。 このデータは、分析のために照会できる信頼できるストレージ ソリューションに安全に格納します。
リスク： ノイズが発生し、コストが増加する可能性があるため、過剰なデータを収集しないようにします。 まず、CPU、メモリ使用量、ストレージ使用量などの基本的なメトリックから始めます。 時間の経過に伴う便利なアプリケーションの正常性メトリックを追加します。
最初の分析に基づいて、利害関係者と協力して、ワークロードの正常な状態と異常な状態の両方の意味を定義します。 この情報は、その正常性状態を正確に反映する正常性モデルを開発するために、後の段階で使用します。
リスク： 監視パイプラインは、チャージバック、トランザクション サービス レベル アグリーメント、容量保証、売上合計など、ビジネス メトリックを収集するためのツールとして機能します。 ワークロードの正常性メトリックとビジネス メトリックを明確に区別します。
監視構成ではなく、アプリケーション機能としてビジネス メトリックを収集します。 監視データ ストリームはサンプリングでき、通常は障害発生時に復旧できません。 ビジネス クリティカルなデータをワークロード データとして扱い、ワークロードの正常性シグナルとは別に保ちます。
ダウンタイムが発生する可能性があるデプロイ エラーのリスクを軽減します。ダウンタイムが発生した場合は、サイトの信頼性エンジニアが分析のためにメトリックの収集に時間を無駄にすることなく、重大な問題に集中できることを確認します。
以前のレベルでは、ソフトウェア開発ライフサイクルを標準化し、展開方法、テスト、テレメトリ収集に関する重要な決定を行います。
レベル 3 では、運用を成熟させ、デプロイの信頼性を高める必要があります。 テストは、安全で安定したデプロイを確保するための稼働状態の要件になります。 デプロイ プロセスも進化し、自動化されたパイプラインを採用してワークロードを構築し、運用環境にデプロイします。 リスクの爆発半径を最小限に抑えるために、基本的なリソースとアプリケーション コードの間で適切なセグメント化が維持されます。
監視のプラクティスも成熟しています。 監視システムは、運用上の知識を実用的な分析情報に変える正常性モデルを実装するように拡張されています。 アラートはビジネス コンテキストに合わせて合理化されるため、無関係なアラートでは誤ったアラームが発生せず、監視システムに不信感が生じません。
主な戦略
このレベルでは、公開前に正式な変更制御プロトコルとして リリースプロモーション を確立することが重要です。 このプロセスは、品質ゲートを使用してさまざまな段階を通じて提案された変更を進行します。 各ステージは徹底的なテストを受け、変更はこれらのチェックに合格して承認を受けた場合にのみ進みます。
開発/テスト、品質保証、ユーザー受け入れテスト (UAT)、運用環境など、さまざまなステージに個別の環境を作成します。 この方法により、次のステージに進む前に検証が徹底されます。 この考え方は、爆発半径を最小限に抑えるためにエラーを早期にキャッチする必要があるため、より低い環境でリスクを管理することです。
このレベルでは、システムの重要な部分に対してテストが優先される戦略を決定します。 堅牢なテスト戦略を確保するには、次の手順を使用します。
テスト ケースを定義します。 アプリケーション コード、インフラストラクチャ テンプレート、および構成のテスト ケースを作成します。
さまざまな種類のテストを実施します。 環境ごとに異なる種類のテストを実行します。 リスクの低い環境でリスクの高い変更のテストを開始します。 信頼度が高まるにつれて、リスクの高い変更をリスクの高い環境に徐々に移行します。
個別のテスト環境を設定します。 さまざまなテスト アクティビティ用に個別の環境を作成します。 たとえば、UI テストを行う場合は、開発環境と運用環境の両方とは別の専用環境を作成します。
理想的には、開発環境とテスト環境を運用環境とできるだけ似た状態に保ちます。 サンプルのみの場合でも、テスト データが運用環境のデータと密接に一致することを確認します。 リソースも同等である必要があります。 たとえば、数 MB のデータを含む小規模なテスト データベースで十分な場合もありますが、実際のパフォーマンスを評価するには、数テラバイトのほぼ実稼働サイズのデータベースを使用して機能を検証することが不可欠です。
トレードオフ： これらの環境を近くに保つことは重要ですが、考慮すべきトレードオフがあります。 運用環境のフル スケールを開発中にデプロイすることはできません。
運用環境との近接性と、コスト効率の高い非運用環境とのバランスを見つけます。 たとえば、一時的な開発/テスト環境を作成することを検討してください。この環境は、テストに合格した後に取り壊されます。
テスト ケースに従って環境のサイズを設定します。 単体テストでは、小規模なセットアップで一致するライブラリと OS のバージョンのみが必要になる場合があります。 回復性テストでは、同じサービス SKU を持つ実稼働前環境が必要になる場合があります。 パフォーマンス テストでは、運用環境規模のデプロイが必要になる場合があります。
✓可能な限りテストやその他の品質チェックを自動化する
自動化は、一貫性を確保し、予期しない構成変更をすばやく見つけるのに適しています。 自動テストを通じて確認できる変更を決定します。 たとえば、セキュリティ スキャンは、開発環境に移行する際の自動化に最適です。 すべてのテストを自動化する必要はありません。また、一部のテストを自動化することはできません。 たとえば、UAT では、実装をユーザーの期待と比較し、承認を得る必要があります。
注
高度に自動化された環境でも、意思決定者は不可欠です。 人間の関与のレベルは異なる場合がありますが、誰かが常に次の環境に移行する責任を負います。 このプロセスには、自動チェックのルールの定義や手動レビューの実施を含めることができます。 リスク許容度が低い後の環境では、手動チェックが必要になる場合があります。
自動テストを調整するための Azure Load Testing や Azure Pipelines など、さまざまな種類のテストを自動化および合理化するためのさまざまなテスト ツールを使用できます。
✓ 承認プロセスを設定する
デプロイが異なる環境を移動する場合は、テストプロセスと承認プロセスを使用して変更を検証することが重要です。 この検証は成熟し、時間の経過と伴ってより厳格になる必要があります。 たとえば、開発者ワークステーションから共有開発環境に移行する場合、通常は基本的なセキュリティ スキャンとピア レビューで十分です。 しかし、後で、ビジネス利害関係者を含める必要がある場合があります。 構造化された効率的なデプロイ プロセスを確保するには、次のガイドラインを考慮してください。
定期的なリリースの承認: 通常のリリースに関しては、ステージングから運用環境への移行には、異なる一連の条件が必要です。 運用環境への移行などのリリースに関する決定には、利害関係者からの承認、明確なドキュメント、またはその両方が必要です。 ワークロード チームは、承認プロセスの一部であるユーザーとその責任を定義する必要があります。 規制の場合によっては、監査者が意思決定プロセスに含まれることもあります。 レベル 2 でこれらの役割と責任を確立します。
修正プログラムの別のプロセスがあります。 セキュリティ パッチのデプロイなどの重大な状況では、即興展開プロセスが必要になる場合があります。 緊急プロセスを作成して、これらの優先度の高い修正プログラムを高速化します。 このプロセスには、主要な利害関係者と技術メンバーからの承認のみが含まれる場合があります。 または、一部の承認をバイパスするパイプラインを開発して、デプロイを迅速に行うことができます。
スキップする手順を決定するときは、ビジネスまたは顧客に対するリスクを考慮してください。 高い投資とリスクの低いテストは緊急時にはスキップできますが、高リスクと低投資のテストは常に実行する必要があります。 直接責任ある個人 (DRI) は、主要な利害関係者や技術的な意思決定者からの意見を得て最終的な意思決定を行う必要があります。
✓ 自動デプロイを実装する
予想される変化率に基づいて、異なるレイヤーに対して個別のデプロイ サイクルを維持します。 場合によっては、相互依存関係とダウンタイムの要件によっては、サイクルの組み合わせが必要になる場合があります。 ただし、ほとんどの場合、最小限の特権で各レイヤーを個別に管理することで、細分性を追求します。 1 つのレイヤーの変更が他のレイヤーに影響しないようにします。
たとえば、ネットワーク インフラストラクチャの変更の頻度は、アプリケーション コードの変更よりも少なくなります。 これらの変更は、品質管理による合理化されたプロセスによって個別に管理します。 プロセスを作成するには、ワークロード レイヤーに合わせて配置パイプラインを構築します。 運用環境にデプロイする前に、制御された環境でコードとしてのインフラストラクチャ資産に対してテストを実行します。
✓ 健康モデルの開発
基本的な監視システムを用意したら、ビジネス コンテキストと監視データを組み合わせて、ワークロード コンポーネントの全体的な正常性状態と全体的な状態を定量化します。 この演習は 、正常性モデリングと呼ばれ、ビジネス コンテキストを使用してインフラストラクチャとアプリケーションからの監視値をコンテキスト化することを含みます。 効果的な正常性モデルを構築するには、次の重要な原則を検討してください。
システムが監視するデータ コンテキストを指定します。 しきい値の設定は、正常性モデリングの重要な部分です。 しきい値がワークロードにとって意味のあるものになるように、コンテキストを使用して数値を指定します。 たとえば、70% から 90% の CPU 使用率が高い場合、一般的に 1 つのワークロードで 異常 な状態を示している場合は、使用可能なリソースを効率的に使用する別のワークロードでは 正常 である可能性があります。
変更に関するアラート。 これらの値の変化は健康状態の変化を示しており、DRIsからの対応を促す必要があります。 そのため、アラートは正常性モデリングのもう 1 つのコア コンポーネントです。 標準メトリックを有効にして、すべてのアラートをサポート センターに送信することは避けてください。 代わりに、健康モデルの変更に基づいてアラートを発します。 アラートに含まれる情報は、調査または是正措置を必要とする特定の問題について適切なチームに通知する、意味のある実用的な情報である必要があります。
あなたの健康モデルを視覚化します。 監視プラットフォームの視覚化ツールを使用して、ワークロードの正常性シグナルをさまざまな利害関係者と簡単に共有できます。 一部の利害関係者は、アプリケーションの可用性など、特定の統計情報を必要とする場合があります。 また、運用チームは、すべての正常性シグナルにアクセスする必要があります。 異なるダッシュボードを設定すると、各チームに必要な情報を提供するのに役立ちます。
時間の経過とともに、ワークロードの正常性に関する履歴の傾向を追跡し、分析する戦略を策定します。
✓ インシデント管理プロセスを設定する
ワークロードが運用環境にある場合は、プラットフォームの停止、データの破損などのインシデントに対処するのが普通です。 重要なのは、ワークロードに設定したターゲット内でこれらのインシデントを効果的に処理することです。 そのため、運用環境に移行する前に、インシデント管理の最初のステップとして構造化されたサポート 計画を用意します。
通話中のユーザー、その職務、およびオンコール担当者間のハンドオフの管理方法を定義して、サポート操作を正式化します。 理想的には、通話中のローテーションにギャップがあってはなってはいけません。また、誰もがインシデントをいつでも処理する責任を誰もが知っているはずです。
インシデントの種類ごとに、明確に定義されたプレイブックまたは対応プロセスがあることを確認します。 たとえば、エラー モード分析 (FMA) またはセキュリティ ベースラインの結果を使用できます。
正常性モデルを使用して、インシデント管理の準備に関する基本的なテストを実行します。オペレーターは、シミュレートされた問題の影響を監視しますが、開発者が通話中に問題のトラブルシューティングを行う必要がある場合があります。
: システムがユーザーに約束されている品質基準を満たし、サービス レベルアグリーメントの違反を防ぎます。
以前のレベルでは、ワークロード チームは機能の構築とシステムの運用環境への移行に重点を置いています。 このレベルでは、機能の構築からライブ システムの維持と改善に焦点が移ります。 実際のユーザーがそれに依存するようになったため、優先順位は、トリアージ、メンテナンス、アップグレード、トラブルシューティングなどの 2 日目の効率的な操作によって変更管理になります。
主な戦略は、実際のエクスペリエンスを使用して運用を改善することです。 また、テストは、変更に関連するリスクを軽減するための交渉不可能なプラクティスでもあります。 バグの修正から機能の追加、インシデント対応の改善まで、開発のあらゆる部分にテストを統合する必要があります。 それがなければ、深刻な問題は運用環境に到達するまで検出されない可能性があります。
このレベルでは、技術的負債が本当の懸念事項になります。 理想的ではない実装は稼働する可能性があり、メンテナンスが複雑になる可能性があります。 チームは、メンテナンスの負担を分析し、それを減らすことに重点を置く必要があります。
主な戦略
✓ 安全な展開方法を使用する
運用環境の後、通常、3 つの主要な種類の変更には、定期的な更新プログラム、新機能の更新プログラム、緊急更新プログラムが含まれます。 安全な展開プラクティスを使用して、これらの変更中にシステムを安定した状態に保ちます。 変更の種類に関係なく、すべての変更をワークロードのユーザーの潜在的な障害点として扱います。
次の戦略を変更管理プロセスに統合します。
継続的かつ包括的に検証します。 開発ライフサイクル全体を通して、またさまざまな環境で変化が進むにつれて、早い段階で頻繁にテストします。 アーティファクトが変更されるたびに、それらの変更に重点を置いたテストを作成するのが理想的です。 その後、完全なテスト スイートを実行して、フローをエンドツーエンドで検証します。 テスト結果は検証データを提供しますが、ビジネス関係者は引き続きこれらの変更を承認する必要があります。
トレードオフ： テスト スイート全体を実行すると、デプロイの信頼性が高くなります。 ただし、時間とコストが原因で、すべての変更に対して実用的でない場合があります。 徹底的なテストとコストに関する考慮事項のバランスを取る。 変更の影響に基づいて承認プロセスを調整します。 軽微な変更には簡単な手順が必要ですが、新機能などの大幅な変更には徹底的なレビューが必要です。
このレベルでは、リージョンフェールオーバーなどの高度な運用概念を採用できます。 目標は、ほとんどのシナリオで自己復旧に焦点を当てて、これらのプロセスを完全に自動化することです。 これらのプロセスも広範囲にテストする必要があります。
API のバージョン管理を実装します。 下位互換性を確保するために、データ モデルの変更を慎重に管理します。 API のバージョン管理戦略は、変更がデプロイされた後も既存のシステムがスムーズに動作し続けるのに役立ちます。 振り返りバージョン管理は困難な場合があるため、早い段階で戦略を立てることもできます。
増分更新を展開します。 レベル 3 では、デプロイ プロセスは、すべての環境で自動化されたパイプラインを使用して標準化されます。 レベル 4 の成熟度で、ワークロードは運用中です。 リリース サイクルの管理など、増分更新の調整に焦点が移ります。
小規模で頻繁な更新プログラムをデプロイして、小規模な変更セットの検証を簡略化します。 ロード テスト、テスト環境へのデプロイ、A/B テストなどの検証タスクを自動化します。
注
カナリアデプロイやブルーグリーンデプロイなどの安全なデプロイパターンは、サイドバイサイドデプロイを通じて柔軟性と信頼性を提供します。 たとえば、ブルーグリーンデプロイでは、新しい環境が構築され、トラフィックがシフトされ、古い環境は使用停止になります。 その他のデプロイ手法には、機能フラグやダーク 起動が含まれます。 これらの方法を使用すると、すべてのユーザーに変更がロールアウトされる前に運用環境でテストできます。 この機能は、デプロイ スロット間で段階的にスワップすることで更新プログラムをロールアウトできる、Azure App Service などの特定の Azure サービスで使用できます。
デプロイ エラーから復旧します。 一部の更新が失敗することが予想されます。 問題が発生した場合、増分更新によりトラブルシューティングが迅速化します。 障害が発生した場合は、システムを停止してさらなる損傷を防ぎ、変更を実装して問題を解決します。 バックアップからの復元は、継続性が維持される場合に許容されます。 目標は、ロールバック プロシージャだけに依存するのではなく、安定したバージョンに移行することです。
✓ ビルド操作を最適化する
レベル 3 では、アーキテクチャのレイヤーごとに、変更率に基づいて個別のデプロイ サイクルが必要です。 少なくとも、インフラストラクチャとコード パイプラインを維持します。
ワークロードが運用環境に入ったので、階層化アプローチを見直します。 可能であれば、アーキテクチャ コンポーネントをさらに分離して、より柔軟なリリース周期を実現します。 この方法では、遅延を減らし、個々のコンポーネントの障害を最小限に抑えます。 また、テストと実行時間の長いプロセスを並列ジョブとして実行して、時間を節約し、開発者の生産性を向上させます。
✓ インシデント対応プロセスを検証する
レベル 3 では、プレイブックを使用してオンコール サポート システムを確立し、インシデントへの対応を定義します。 ただし、プレイブックを持つことは最初のステップにすぎません。 ワークロードが運用環境になったので、インシデント管理プロセスの有効性を検証して強化し、堅牢なコミュニケーション計画を策定する必要があります。 次のプラクティスを検討してください。
インシデントへの対応をテストします。 テクノロジ、人、プロセスからの応答を組み込みます。 検証作業に現実性を導入するには、ゲームデーを実施することをお勧めします。 ゲームデーは、問題を検出して解決するチームの能力をテストするために障害が導入される計画イベントです。 このアプローチにより、チームは適切なツール、リソース、手順を確実に配置できます。 カオス エンジニアリングは、制御された中断を導入して結果を観察するもう 1 つの貴重な手法です。 または、グローバル ロード バランサーでバックエンドを無効にしたり、データベース フェールオーバーを実行したりするなどの手動の方法を使用して、応答をテストすることもできます。
コミュニケーション計画を立てる。 ワークロード チーム、サポート チーム、緊急対応担当者全体のコミュニケーション責任を明確に定義します。 ビジネス利害関係者に対する内部状態の更新の頻度と形式を標準化することで、透明性と信頼が促進されます。 セキュリティ侵害などの特定のシナリオでは、エンド ユーザーへの責任ある開示が必要です。 これらの外部通信では、適切な種類とレベルの情報が明確に定義されていることを確認します。
インシデント レビューを実施します。 すべてのインシデントを運用環境から学ぶ機会として扱います。 このプロセスを使用して、デプロイと開発プロセスの弱点を特定し、システムの改善にコミットします。
✓ 運用環境の監視データを使用して運用を最適化する
レベル 4 では、高度な監視は、ビジネス コンテキスト内でメトリックを出力、関連付け、分析する必要があります。 このレベルでは、運用環境から学習することで精度を向上させます。 監視データを使用して、最適な推測に基づいて構築されたプロセスを調整します。 次の主な例を考えてみましょう。
レベル 3 の主な焦点は、ワークロードの正常性モデルの開発です。 レベル 4 では、アラート システムを微調整し、現実的な目標とサービス レベルのインジケーターを設定します。
2 日目の操作の一環として、構成の誤差を最小限に抑えることが重要な優先順位である必要があります。 このフォーカスがないと、ランタイム環境は意図した状態から徐々に分岐する可能性があります。 まず、既知の適切な構成のスナップショットをキャプチャします。 次に、運用環境の可観測性メトリックを利用して、現在の動作をそのベースラインと比較します。 このアプローチにより、意図したシステム状態との継続的な整合が保証されます。
このレベルは、フィードバック ループを導入して、システムが特定のストレス要因の下でどのように動作するかを理解し、新機能の影響を予測するのに最適です。 システム テレメトリは、ワークロードの変化を予測し、潜在的な問題に対するプロアクティブなソリューションを形成するのに役立つ重要な分析情報を提供することで、これらのフィードバック ループをガイドします。 このデータを使用して、技術的負債の優先順位付けを行うこともできます。
一般的なプラクティスとして、運用環境の監視データとパターンに基づいて監視スタックを微調整します。 次のプラクティスを検討してください。
✓ メンテナンスの自動化
レベル 3 では、自動化の取り組みは主に運用環境へのデプロイに重点を置きます。 レベル 4 では、チームは継続的インテグレーションと継続的デリバリー パイプラインを使用してビルド、テスト、デプロイのプロセスを自動化することで、手動作業を大幅に削減しました。 品質ゲートと同様に、特定の承認も自動化されたワークフローを通じて管理される場合があります。
レベル 4 では、運用の自動化は実際の運用エクスペリエンスによって推進され、技術的負債への対処に重点を置く必要があります。
次の day-2 自動化の例を考えてみましょう。
| プロセス |
メリット |
| 証明書、API キー、およびその他のシークレットのローテーションを自動化します。 |
自動化により、タイムリーなローテーションが保証されるため、手動による介入が不要になり、時間が節約され、人為的ミスの可能性が減少します。 |
| インフラストラクチャの定期的なメンテナンスを自動化します。 |
定期的なインフラストラクチャのメンテナンスには、広範なテストと調整が必要です。 自動化により、これらのタスクを迅速化し、手動作業を減らし、リスクを最小限に抑えることができます。 |
| 緊急対応プロセスを自動化します。 |
適切な自動化がなければ、緊急リリース時に急いで調整されていないアクションに頼り、さらに問題が発生する可能性があります。 |
| 負荷の急増と低下に対するリソースのスケーリングを自動化します。 |
自動スケールにより、リソースが需要に基づいて動的に割り当てられます。 この割り当てにより、リソースの効率的な使用が行われます。これは、需要が減少するとリソースが割り当て解除され、過剰な運用オーバーヘッドが発生しないためです。 |
| データの取得と配信を自動化します。 |
この方法により、ユーザーから送信されたデータ要求を満たすために必要な時間と労力が削減されます。 データベースに手動でアクセスする代わりに、データベースへのアクセス、関連するデータの取得、ユーザーへの送信のためにスクリプトがトリガーされます。 |
| 特定の条件に基づいて開発者環境の作成を自動化します。 |
このアプローチにより、チームの 2 日目の運用の一環として、ワークロードの安全な変更を容易にするために環境が一貫して作成されます。 |
注
デプロイ自動化戦略を開発するときは、既知の予測可能なタスクから始めます。 共通の故障点を考慮に入れます。 これらのポイントが自動化された後、対応範囲を広げて予期しない問題に対処します。その一部には手動での介入が必要な場合もあります。 たとえば、インフラストラクチャの更新などの日常的なタスクの管理が容易になるため、まず自動化します。 その後、不明な障害シナリオが含まれる可能性があるため、緊急ホットフィックスに取り組みます。
たとえば、チームは、すべての地域のユーザーに対して制御された露出を使用して、ワークロードを定期的にデプロイする場合があります。 このプロセスの完了には数日かかる場合があります。 また、特定の手順をスキップして、ホットフィックスをより早くデプロイする機能も必要です。 自動化プロセスは、これらの迅速なデプロイを考慮する必要があります。
主な目標は、期限のために以前の段階で見落とされていた可能性のある反復的な人間主導のタスクを特定することです。 しかし、すべてを自動化するべきではありません。 投資収益率は自動化を導く必要があります。 まったく新しいツールから始めるのではなく、既存のテクノロジと知識を使用することをお勧めします。 軽量工具が必要な場合は、そのライフサイクルとメンテナンス要件を評価します。
レベル 4 の成熟度では、エンジニアリングの資産とプロセスを評価して運用効率を上げます。 どの資産が重要で、ビジネスの中核ではないかを特定します。
これらの資産については、次の点を考慮してください。
事前構築済みの資産にはサポート チャネルが付属しており、カスタム ソリューションを置き換えることができます。 このアプローチにより、チームが作成したソリューションの運用上の負担が軽減されます。 これらのリソースがニーズをどの程度満たしているかを評価し、残りのギャップを特定します。
ワークロードの次の領域を確認します。
カスタム コードを評価します。 解析などのタスクのカスタム コードを記述する代わりに、業界標準と見なされるオープン ソース ソリューションを評価します。 これらのツールを使用すると、コードのメンテナンスの必要性が減り、コード ベースが小さくなります。 組織内で既に使用可能なオプションを確認します。 認証などの日常的なタスクを処理するためにワークロードに統合できる既存のライブラリが存在する可能性があります。
ツール チェーンを評価します。 同様のツールを使用する他のチームに依存できる領域を評価します。 それに応じて、ライブラリ、テンプレート、およびモジュールの使用を調整します。 組織全体にコードとしてのインフラストラクチャ ツールを配置して、運用を効率化します。
プロセスを評価します。 セキュリティ スキャンなど、自分で実装した可能性のあるタスクを実行できる一元化されたプロセスを特定します。 NuGet パッケージの独自の検疫プロセスを管理する代わりに、ワークロードで使用されているモジュールを通知することで、組織の既存のセキュリティ チームのプロセスを使用します。
サポート可能性はもう 1 つの重要な領域です。 初期の段階では、多くの場合、開発チームはメトリックを監視し、ライブの問題を修正することで、自身のサポートを処理します。 この段階では、オンコール エンジニアなどの専用ロールを設定することを検討してください。 組織に共有サポート チームがある場合は、それを使用して開発者のサポート負荷を軽減します。
注
可能であれば、日常のサポートを外部ベンダーに移行します。 ベンダーは、開発チームやワークロードを運用環境に移行するアーキテクトのような深いコンテキストを持っていません。 仕入先にタスクを渡す前に、システムが運用環境で安定していることを確認し、管理タスクを明確に定義します。 ベンダーが成功するには、重要な要素が必要です。 正常性モデルで、 正常、 異常、および 低下状態 を表すしきい値を定義します。 プレイブック、ツール、その他のトラブルシューティング リソースについてベンダーをトレーニングします。 原因を特定できない場合は、問題をエスカレートしてワークロード チームにルーティングするための明確に定義された経路を設定します。
✓ 定期的に技術的負債を管理する
技術的負債は、開発時に期限を満たすために実行するショートカットの結果であり、実装が理想的ではない可能性があります。 チームは、メンテナンスの複雑さと時間を分析することで、この負債の削減に取り組む必要があります。 技術的負債に対処しないと、システムがより複雑になり、保守やスケーリングが困難になる可能性があります。 この複雑さは、開発者が新しい機能に取り組む代わりに問題の修正に多くの時間を費やすので、イノベーションが遅くなります。
技術的負債を処理するための次の戦術的な推奨事項を検討してください。
技術的負債は、開発の通常の部分であり、改善の機会です。 新機能が追加されると、負債が蓄積されます。 既存の技術的負債を返済する努力と、新機能の開発による新たな技術的負債の管理とのバランスを取ります。
改善と適応を続けますが、完了したとは決して想定しないでください。
レベル 1 からレベル 4 に進むにつれて、Azure で適切に設計されたワークロードを確立します。 設計では、運用用にシステムを準備する監視、テスト、デプロイ、自動化などの運用プラクティスを設定します。 システムが運用環境に入った後は、ユーザー エクスペリエンスを保護するために、運用の安定化と変更の管理に重点を置きます。
最後の段階での成熟度とは、ワークロードを大規模に運用し、信頼性と最新の状態を維持することです。 また、現在の設計が限界に達している領域を特定し、ビジネス要件の変更に備える能力も必要です。 制約に関する前提は、エコシステムの進化に伴って古くなる可能性があります。 環境、プラクティス、およびツールは進化し続けているため、静的な場合は回帰が発生する可能性があります。 レベル5のアプローチに投資しないと、ワークロードが遅れるリスクがあります。
レベル 5 は、最終的な目標でも技術的なチェックポイントでもない。 文化、プロセス、ツール、テクノロジの最新化に重点を置いた考え方の転換です。 運用は、ワークロードのアプリケーションが受け取るのと同じ厳密さ、投資、イノベーションで処理されます。
主な戦略
✓観察された成長と将来の可能性に基づいてアーキテクチャの再構築のチャンスを見つける
ワークロード アーキテクチャは、制約を使用して意図的に設計されており、有効期間が限られています。 レベル 4 を通じて、アーキテクチャはビジネス要件を効果的に満たしている可能性があります。 このレベルでは、システムが新しい使用パターン、テクノロジ、成長、運用上の課題をどのように処理するかを評価します。
たとえば、何千人ものユーザーに対して機能するソリューションは、数万人にスケーリングすると失敗する可能性があります。 データ量の増加によって原子性の問題が発生する可能性があります。一方、パフォーマンスとコンプライアンスに対する要求が増える一方で、アーキテクチャをその限界まで押し上げることができます。 これらの圧力により、新機能の提供を防ぎ、スケーリングのボトルネックを生み出すことができます。
このレベルでは、チップポイントを認識し、 再設計が必要な領域を特定します。 次の領域について考えてみましょう。
ツール、フレームワーク、プラットフォーム サービスの最初の選択は、ビジネス ニーズに適している可能性があります。 ただし、システムの進化に伴い、これらのツールは堅牢または密に結合され、ライブラリの拡張性が不足し、プラットフォーム サービスが終了し、既存の依存関係が破損する可能性があります。
強力なサポートと広範なコミュニティ導入を提供する広範なエコシステム内のツールとサービスについて説明します。 交換やアップグレードを容易にするために、モジュール式の疎結合アーキテクチャを選択します。
以前のレベルでは、ワークロード チームが 技術スタック全体を管理する場合があります。 このアプローチは最初は有効ですが、システムのスケーリングに伴って圧力と運用オーバーヘッドが増加することがよくあります。 この負担を軽減するには、ネットワーク、セキュリティ、監視に重点を置くチームなど、専門チームに責任をオフロードすることを検討してください。 その専門知識により、コア ワークロード チームは製品価値の提供に専念できます。
顧客専用 (またはシングルテナント) インスタンスを管理すると、コストと運用上のオーバーヘッドの両方が増加する可能性があります。 多くの場合、この課題はマルチテナント アーキテクチャを採用する必要性を示しています。 この移行には、テナントのオンボードやデータ アクセスの分離の処理など、より広範なアーキテクチャと運用への投資が必要です。
デプロイ戦略を再検討して、予測可能にスケーリングし、障害の分離とパフォーマンスを大規模に処理します。 デプロイ スタンプ パターンなどの実証済みのプラクティスについて説明します。
スケール ユニット は、個別に監視されている間、負荷の増加を処理するために一緒にスケーリングするリソースの論理グループです。 これらのユニットは、定義されたしきい値に基づいて繰り返し可能なブロックとして自動的にデプロイされ、必要に応じてレプリケートできます。
ただし、このアプローチにより、特定のサービスのスケーリングが過剰になり、コストが追加される可能性があります。
詳細については、「 スケール ユニットアーキテクチャ」を参照してください。
不変環境 とは、デプロイ後にシステムが変更されない展開セットアップです。 デプロイ スタンプを更新する代わりに、古いスタンプを破棄し、必要な変更を加えて再デプロイします。 このアプローチでは、ブルーグリーン デプロイなどのサイド バイ サイド デプロイ モデルが必要です。 このプラクティスを採用するには、ハイパースケールを処理したり、異常なユニットを置き換えたりするために、新しいスタンプを自動的にデプロイするパイプラインを準備する必要があります。
レベル 4 の安全なデプロイプラクティスでは、この移行に備えて準備する必要があります。 回帰は必要なく、ユーザーは新しいスタンプにスムーズに移行する必要があります。
✓自動化を使用して摩擦をさらに減らす
レベル 4 からレベル 5 への移行は、自動化の向上だけではありません。 また、自動化を使用して摩擦を減らし、これらのタスクを実行するタイミングを決定する方法についても説明します。
次の例を考えてみましょう。
ローカル開発者環境の自動作成: 同じ一連のツール、ライブラリ バージョン、およびその他の開発資産を使用して各開発者ワークステーションを構成することで、標準化されたエクスペリエンスを提供します。 この一貫性により、エクスペリエンス レベルに関係なく、すべての開発者が統一された環境にアクセスできるようになります。 また、コラボレーション、知識共有、オンボーディングも容易になります。 仮想化された開発環境を使用して、このプロセスを簡略化します。
自動アラートトリアージと解決ワークフロー: 自動化を使用して、定義済みのルールに基づいてアラートを分類および優先順位付けし、解決ワークフローをトリガーします。 優先度の高いアラートの場合、システムは関連するチームに通知し、解決プロセスを開始して応答時間を短縮できます。
自動インシデント修復: 問題が検出されたときにサービスを自動的に再起動したり、ワークロードを移行したりする自己復旧スクリプトを実装します。 たとえば、Web サーバーがクラッシュした場合、スクリプトはサービスを再起動したり、トラフィックをバックアップ サーバーに再ルーティングしたりしてダウンタイムを最小限に抑えることができます。
リソースの自動使用: 他の柱の成熟度が進むにつれて、その目標をサポートするための自動化を導入する必要があります。 たとえば、重要でないリソースと環境をピーク時間外にスケジュールして、コストを削減し、リソースの使用を最適化できます。
テナント管理の自動化: マルチテナント環境でのテナントのオンボードとオフボードを効率化します。 新しいテナントがサインアップすると、自動化でユーザー アカウントの作成、リソースのプロビジョニング、設定の構成を行うことができます。
✓ 機能や変更ごとに開発環境を作成する
Day-2 操作では、安全な変更の実装に重点を置いています。 各変更は、開発、テスト、セキュリティなどの特定の目的で設定されたさまざまな環境を通過します。 レベル 4 のガイダンスに従うことで、これらの環境の作成が自動化されていることを前提としています。
レベル 1 から 4 とは異なり、運用環境の準備状況を内部的に確認し、ワークロードの変更を管理することに重点を置いているレベル 5 は、ワークロード チームが組織全体の他のワークロードと設計、成功、失敗を共有する機会です。 負荷分散チームは、失敗を回避する方法を先人から事前に学ぶことができる場合、自ら失敗を経験する必要はありません。
✓ 知識を共有し、組織の成熟度に貢献する
レベル 1 から 4 は、内部の準備とワークロードの変更の管理に重点を置いています。 レベル 5 は、ワークロード チームが組織全体の他のチームと設計、成功、失敗を共有する機会を作るため、異なります。 同様の課題を経験した他のユーザーから学べる場合、チームは失敗を直接経験する必要はありません。
この移行には、個々のワークロード レベルのオペレーショナル エクセレンス原則から、一元化された運用に投資する組織への移行が含まれます。 これらの一元化されたチームは、ガードレール、自動化、可観測性、テストを備えた展開ツールを構築する専用のエンジニアリング グループで構成されています。
ワークロード チームは、ピア チームと効果的な手法、ツール、分析情報を共有する必要があります。 まず、ワークロードが依存するチームと連携します。 その後、ワークロードに依存するチームと接続します。 経験と成果を共有するときは、それらのチームから学びます。 共有プラットフォーム、ドキュメント、コミュニティエンゲージメントを通じて、知識共有が増えることがわかります。
✓ ワークロードのさまざまな職務に対するセルフサービス機能を有効にする
ワークロードの日常的な開発責任内で計画外のタスクが繰り返し発生する場合は、チーム メンバーが必要なときに責任を持って呼び出すことができるスクリプト ソリューションとして提供する必要があるかどうかを評価します。 計画外のタスクのセルフサービス機能を構築して維持し、チームの機敏性と自律性を高めます。
セルフサービス ソリューションとしてワークロード チームに提供するためにコスト効率の高い、時間のかかるタスクやエラーが発生しやすい計画外のタスクから始めます。 ソリューションでは、チーム メンバーの時間を最適化し、これらのタスクに一貫性を組み込む必要があります。 このアプローチにより、セルフサービス ソリューションの有効期間に対する投資収益率が得られます。
「プラットフォーム エンジニアリング体験を開始する」で説明されているアプローチと機能に従ってください。
AI の機会