自動化を実装するための推奨事項

この Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:09 人間の介入の洞察と適応性の恩恵を受けないすべてのタスクを自動化し、高度な手続きを行い、自動化投資に対するリターンを生み出す有効期限を持ちます。 可能であれば、自動化用とカスタム実装用の既製ソフトウェアを選択します。 すべての自動化をワークロード コンポーネントと同じように扱い、Well-Architected Framework の柱を設計と実装に適用します。

このガイドでは、ワークロードで自動化を採用するための推奨事項について説明します。 反復的で人為的なエラーが発生しやすいタスクを自動化して、チームが効率を高め、標準に従うのに役立ちます。 タスクを自動化して、ワークロードを合理化し、一貫性を保ちます。 自動化により、運用チームとエンジニアリング チームは、他の改善に取り組む時間が長くなるため、より効率的になります。 自動化は、ワークロード管理のあらゆる側面で強力なツールです。 organizationを強化するための自動化を慎重に実装します。

主要な設計戦略

ワークロードを開発するときに、管理負荷を軽減し、人的エラーを最小限に抑えるために、自動化を活用する機会を探します。 これらの機会を評価し、organizationにもたらす価値を検討します。 自動化への投資の価値を最大限に高めるために、簡単で手続き型で、有効期間が長いタスクに優先順位を付けます。 自動化を適用することは、すべてまたは何もない戦術ではありません。 意思決定ポイントなど、人間の介入を必要とする操作がある可能性があるワークストリームがあります。 これらのワークストリームは、他のタスクを実行する自動化の恩恵を受けることができます。

自動化するタスクをターゲットにする

自動化のメリットが最も高いタスクに優先順位を付けるために、次の推奨事項を検討してください。

  • 簡単な勝利を目指す。 手続き性が高く、人的エラーの影響を受けやすいタスクに重点を置く。 これらのタスクは高度に自動化できます。 これらは明確に定義されており、複雑さを増す変数から解放され、通常の操作の一部として実行されます。 逆に、複雑なスクリプトを記述して、変動する現象や、めったに発生しないタスクを考慮する必要があるタスクを自動化することに優先順位を付けないでください。

    高度に自動化できるタスクの例としては、サーバーの再起動、アカウントの作成、データ ストアへのログの転送などがあります。 これらのタスクは、イベントまたは監視アラートへの応答として、または外部要因に基づいて必要に応じて、スケジュールに基づいて発生する可能性があります。

  • オペレーターを支援し、中小企業を解放する方法を探します。 不要なエスカレーションに依存しているorganizationの専門家がいる場合があります。 たとえば、新しい顧客をマルチテナント ソリューションにオンボードするときに、データベース管理者が新しいデータベースの作成要求を定期的に受け取る場合があります。 ヘルプ デスク チーム用のセルフサービス ポータルを作成する場合は、空のデータベースを安全に作成できるようにすることができます。 または、中間ステップとして、実行するスクリプトを作成することで、SME の要求と実行手順を自動化できます。

  • 投資収益率に重点を置く。 価値の高い自動化では、最小限の管理オーバーヘッドが必要であり、実証可能な程度の効率が向上します。 たとえば、データベース エントリを自動化して運用チームを毎日 1 時間節約できる場合は、改善のために他の領域を見つける時間を与えます。

自動化を実装する領域

開発から日常的な管理まで、ワークロードライフサイクル全体を通じて自動化を採用します。 次の例の一覧を使用して、自動化の恩恵を受ける可能性のあるワークロード ライフサイクルの広範な領域を検討します。 次の自動化を行うことができます。

  • パイプラインの定義、実行、管理: Azure DevOps や他の DevOps ツールなどの継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールを使用して、パイプラインとその実行方法を自動的に定義します。 これらのツールは、CI/CD タスクやその他のタスク (レポートの作成など) を自動化するのに役立ちます。

  • デプロイ: Azure Resource Manager テンプレート、Bicep、Terraform、Ansible などのツールを使用して、ワークロードの開発およびリリース プロセスを自動化します。 コードとしてのインフラストラクチャ (IaC) アプローチを使用して、同じ自動化プラットフォームでインフラストラクチャをデプロイおよび更新します。

  • テスト: テスト プロセスを自動化するために、多くのツールを使用できます。 これらのツールを使用すると、品質保証チームの大きな負担を軽減し、テストが標準化され、信頼性が確保されます。

  • スケーリング: プラットフォーム提供の機能やオーケストレーション ツールなどの他のツールを使用して、負荷が増減したときにインフラストラクチャを自動的にスケーリングします。

  • 監視とアラート: 監視ソリューションで使用できるツールを使用して、新しくデプロイされたリソースを自動的に登録し、アラートによってトリガーされるアクションを構成して、問題が発生したときに修復を急ぐのに役立ちます。

  • 自己復旧: 監視システムによって生成されたアラートを使用して、アクションを自動化し、誤動作しているコンポーネントまたはジョブを回復します。 詳細については、「 自己修復と自己保存に関する推奨事項」を参照してください。

  • 構成管理: オーケストレーションとポリシー ツールを使用して、すべてのリソースが同じ構成を実行し、ワークロード全体にコンプライアンス要件が適用されるようにします。

  • その他の管理タスク: スクリプトを使用して、データベース レコードや DNS レコードの更新などの反復的なタスクを自動化します。

  • 承認: システムが定義済みのルールに基づいて承認の決定を自動的に行い、承認ゲートを持つワークフローの効率を向上させることができます。 この方法により、標準化されたフォームとテンプレートの使用が促進され、プロセスの効率が向上します。 高い環境での自動承認は危険な場合があります。 自動化された承認に厳密に焦点を合わせてテストし、承認を付与するために特定の条件が定義されていることを確認します。

  • 新しいユーザーと新しい従業員のオンボード: データベースの更新や資格情報の作成など、新しいアプリケーション ユーザーまたは新しい従業員のオンボードに関連する多くのタスクを自動化できます。

  • 監視とアラート: 監視プラットフォームで提供される自動化機能を利用します。 異常を監視およびアラートするために、新しいデバイスを自動的に登録します。

適切な自動化ツールを選択する

独自の自動化を社内で開発することは時間のかかる作業であり、開発チームに管理上の負担が生じる可能性があります。 他の社内ソフトウェアと同様に、社内自動化ツールを維持する必要があります。 必要に応じて、既製のツールを使用することをお勧めします。 商用、オープンソース、クラウド プラットフォームで提供されるツールの間には、多くのオプションがあります。 さまざまなツールを使用して、必要な自動化を構築する可能性があります。 ツールを評価する際に意思決定を導くために、社内の専門知識に頼ってください。 チームは、特定の開発言語とフレームワークに精通している可能性があります。 最初は、学習曲線が高くなくても使用できる既製のツールに集中できます。 自動化を使用して対処する予定のタスクを振り返り、それらのタスクに特に対処できるツールに投資します。 一般的に好むツールを調達し、その後でタスクを検討しないでください。

バージョンロックインやプラグインの過剰使用など、自動化を構築するときに操作を複雑にする可能性のある要因に注意してください。 Jenkins や Azure DevOps プラグインなどのプラグインは、機能を追加するための優れた方法です。 自動化の目標にメリットがある場合は、プラグインを採用する必要があります。 ただし、複数のプラグインを使用して 1 つのタスクを実行すると、自動化の更新とトラブルシューティングが困難になる可能性があります。 プラグインの使用には慎重に取り組みます。 また、フレームワークバージョンの依存関係を持つソリューションは、時間の経過と同時に維持する負担であるため、避けてください。 このような問題のリスクを最小限に抑えるために、自動化ツールとプラグインの選択を標準化し、すべてのオートメーション プロジェクトにソース管理を使用します。

自動化をワークロードに統合する

オートメーションの構築に使用するツールの場合は、オペレーターが簡単にアクセスでき、管理しやすくします。 ワークロード チームに明確で使いやすいインターフェイスを提供します。 CI/CD パイプライン、API、およびライブラリへのアクセスを提供できます。 自動化がサポートするワークロードと同様に、自動化を包括的に管理する必要があります。 他のワークロード コンポーネントと同じ程度に自動化をセキュリティで保護します。 自動化を監視し、他のワークロード コンポーネントと同じテスト プロトコルに従います。

考慮事項

  • 既製のソリューションが要件に適合しない場合、自動化によって得られる効率が、独自のソリューション開発の管理負担を上回る場合があります。 このような場合は、開発作業に慎重に取り組みます。 既製のソリューションでは解決できないギャップをカバーするために必要なものだけを開発し、依存関係などの複雑さを最小限に抑えます。

  • 高度なメンテナンスを必要とする複雑な自動化は、運用チームが管理およびトラブルシューティングを行うのが困難な場合があります。 自動タスクは、個別のジョブの実行のみに集中し続けます。 他のツールまたはコンポーネントへの依存関係を最小限に抑えてみてください。

  • 手動プロセスを使用する場合は注意が必要です。 操作を自動化しない場合は、オペレーターのステップ バイ ステップ チェックリストを作成して、手動プロセスを十分に文書化します。 この方法では、オペレーターが誤って間違ったプロセスを実行しているなど、人的エラーの可能性を減らします。 このドキュメントは、将来そのプロセスの自動化を設計するのにも役立ちます。

  • ハイブリッド手動および自動アプローチを使用する場合は、特に注意する必要があります。 スクリプトがほとんどのプロセスを実行し、特定の部分または決定のために人間に延期する場合は、情報に基づいた意思決定を行うために必要なコンテキストと情報をユーザーに提供することが重要です。

Azure ファシリテーション

Azure には、ワークロードのタスクを自動化するのに役立つ多くのツールが用意されています。

IaC ツール: IaC デプロイには Terraform、Bicep、Azure Resource Managerを使用できます。 要件とツールに関するチームの知識によっては、リソースのデプロイと管理にこれらのツールを 1 つ以上使用する場合があります。

Azure Functions: Azure Functionsは、任意の開発言語を使用してタスクを自動化するために使用できるサーバーレス ツールです。 Functions には、関数を他のサービスに接続するイベント ドリブン トリガーとバインドの包括的なセットが用意されています。 追加のコードを記述する必要はありません。

Azure のGitHub Actions: AzureGitHub Actionsを使用して、CI/CD プロセスを自動化できます。 GitHub Actionsは、デプロイを簡略化するために Azure と統合されます。 リポジトリ内のすべての pull request をビルドしてテストするワークフローを作成したり、マージされた pull request を運用環境にデプロイしたりできます。

GitHub Actionsは DevOps だけでなく、リポジトリ内で他のイベントが発生したときにワークフローを実行できます。 たとえば、ワークフローを実行して、他のユーザーがリポジトリに新しいイシューを作成したときに適切なラベルを自動的に追加できます。

Azure Automation: PowerShell と Python は、運用タスクを自動化するための一般的なプログラミング言語です。 これらの言語を使用して、サービスの再起動、データ ストア間でのログの転送、需要に合わせたインフラストラクチャのスケーリングなどの操作を実行します。 これらの操作をコードで表現し、必要に応じて実行できます。 これらの言語だけでは、一元管理、バージョン管理、または実行履歴のためのプラットフォームは提供されません。 言語には、監視駆動型アラートなどのイベントに応答するためのネイティブ メカニズムも用意されています。 これらの機能を提供するには、自動化プラットフォームが必要です。

Automation は、クラウド環境とオンプレミス環境 (Azure と Azure 以外の両方) で PowerShell と Python コードをホストおよび実行するための Azure でホストされるプラットフォームを提供します。 PowerShell と Python コードは、Automation Runbook に格納されます。 Automation を使用して次の操作を行います。

  • オンデマンド、スケジュール、または Webhook を使用して Runbook をトリガーします。

  • 実行履歴とログ記録。

  • シークレット ストアを統合する。

  • ソース管理を統合する。

Azure Update Manager: Update Manager は、仮想マシンの更新プログラムの管理と管理に役立つ統合サービスです。 ワークロード全体で Windows と Linux の更新プログラムのコンプライアンスを監視できます。 また、Update Manager を使用して、リアルタイムの更新を行ったり、定義されたメンテナンス期間内にスケジュールを設定したりすることもできます。 Update Manager を使用して次の処理を行います。

  • マシンのフリート全体のコンプライアンスを監視します。
  • 定期的な更新プログラムをスケジュール設定する
  • 重要な更新プログラムを展開する

Azure デプロイ環境: デプロイ環境 を使用すると、開発チームはプロジェクト ベースのテンプレートを使用して一貫性のあるアプリ インフラストラクチャをすばやく作成できます。 これらのテンプレートは、セットアップ時間を最小限に抑え、セキュリティ、コンプライアンス、コスト効率を最大化します。 デプロイ環境は、定義済みのサブスクリプションにデプロイされる Azure リソースのコレクションです。 開発インフラストラクチャ管理者は、エンタープライズ セキュリティ ポリシーを適用し、定義済みの IaC テンプレートのキュレーションされたセットを提供できます。

開発インフラストラクチャ管理者は、デプロイ環境をカタログ 項目として定義します。 カタログ アイテムは、カタログと呼ばれる GitHub または Azure DevOps リポジトリでホストされます。 カタログ アイテムは、IaC テンプレートと manifest.yaml ファイルで構成されます。

デプロイ環境の作成をスクリプト化し、プログラムで環境を管理できます。

Azure Logic Apps と Microsoft Power Automate: 承認フローや ChatOps 統合の構築などのワークロード タスクを処理するカスタム デジタル プロセス自動化 (DPA) を構築する場合は、 Logic Apps または Power Automate の使用を検討してください。 組み込みのコネクタとテンプレートからワークフローを構築できます。 Logic Apps と Power Automate は、基になる同じテクノロジに基づいて構築されており、どちらもトリガーベースまたは時間ベースのタスクに適しています。

自動スケーリング: 多くの Azure テクノロジには、自動スケーリング機能が組み込まれています。 API を使用して、他のサービスを自動的にスケーリングするようにプログラムすることもできます。 詳細については、「信頼性の 高いスケーリング戦略を設計するための推奨事項」を参照してください。

Azure Monitor アクション グループ: アラートがトリガーされたときに自己復旧操作を自動的に実行するには、 Azure Monitor アクション グループを使用します。 これらの操作は、Runbook、Azure 関数、または Webhook を使用して定義できます。

他の Azure サービスと連携して Automation を使用する例については、「Azure Event Gridを使用した操作の自動化」を参照してください。 この例では、Logic Apps と Event Grid を使用して運用タスクを自動化します。

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

推奨事項の完全なセットを参照してください。