次の方法で共有

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

  • [アーティクル]

Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

OE:09 人間が介入することによる洞察や適応性のメリットがなく、手続きがかなり確立されており、自動化に投資すると利益が得られる有効期間を持つ、すべてのタスクを自動化します。 可能であれば、自動化にはカスタム実装ではなく既製のソフトウェアを選びます。 すべての自動化をワークロード コンポーネントと同じように扱い、Well-Architected フレームワークの柱を設計と実装に適用します。

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

主要な設計戦略

ワークロードを開発するときは、管理の負担を軽減し、人為的エラーを最小限に抑えるため、自動化を活用する機会を探します。 これらの機会を評価し、組織にもたらされる価値を検討します。 自動化への投資の価値を最大にするには、単純で、手続き的であり、有効期間の長いタスクを優先します。 自動化の適用は、オール オア ナッシングの戦術ではありません。 ワークストリームには、意思決定ポイントのような人間の介入を必要とする操作を含むものがある場合があります。 このようなワークストリームでも、他のタスクの実行を自動化するとメリットがあります。

自動化するタスクを評価する

次の推奨事項を検討して、自動化のメリットが最も大きいタスクを優先するようにします。

  • 取り組みやすいものを対象にします。 手続きが確立されていて、人的エラーの影響を受けやすいタスクに注目します。 このようなタスクは簡単に自動化できます。 これらは明確に定義されており、複雑さを増す変数がなく、通常の操作の一部として実行されます。 逆に、変化しやすい事柄のために複雑なスクリプトを書く必要があるタスクや、あまり発生しないタスクの自動化は優先しないでください。

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

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

  • 投資収益率に注目する。 価値の高い自動化では、管理オーバーヘッドを最小限に抑える必要があり、効率が明らかに向上します。 たとえば、データベース入力を自動化して運用チームの作業を毎日 1 時間減らせると、それだけ他の改善領域を見つけるための時間が増えます。

自動化を実装する領域

開発から日々の管理まで、ワークロードのライフサイクル全体にわたって自動化を導入します。 次に示す例の一覧は、自動化を使うとメリットがあるワークロード ライフサイクルの広範な領域を検討するのに役立ちます。 次のことを自動化できます。

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

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

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

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

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

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

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

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

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

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

  • 監視とアラート: 監視プラットフォームが提供する自動化機能を活用します。 新しいデバイスを自動的に登録して異常の監視とアラートを行います。

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

独自の自動化を社内で開発すると時間がかかり、それを管理する負担を開発チームが負う可能性があります。 社内の自動化ツールは、他の社内ソフトウェアと同様に自分たちで維持する必要があります。 ニーズを満たすことができるときは常に、既製のツールを使うことをお勧めします。 市販、オープンソース、クラウド プラットフォーム提供のツールでは、多くのオプションを利用できます。 おそらく、さまざまなツールを使って、必要な自動化を構築することになります。 ツールを評価するときは、社内の専門家の助言を参考にして決定します。 チームは、特定の開発言語やフレームワークのことを他よりよく知っている可能性があります。 最初は、苦労して学習しなくても使用できる既製のツールに焦点を当てることができます。 自動化で対処する予定のタスクをよく検討し、それらのタスクに特に対処できるツールに投資します。 一般的な好みのツールを買った後でタスクを検討する、といったことはしないでください。

バージョンのロックインやプラグインの過剰使用など、自動化を構築するときに操作が複雑になる可能性がある要因に注意してください。 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: Azure 用 GitHub 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 Deployment Environments: Deployment Environments を使うと、開発チームはプロジェクト ベースのテンプレートを使って一貫性のあるアプリ インフラストラクチャをすばやく作成できます。 これらのテンプレートは、セットアップ時間を最小にして、セキュリティ、コンプライアンス、コスト効率を最大にします。 デプロイ環境は、定義済みのサブスクリプションにデプロイされる 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 を使って定義できます。

例

Automation と他の Azure サービスを併用する例については、Azure Event Grid を使った運用の自動化に関する記事をご覧ください。 この例では、Logic Apps と Event Grid を使って運用タスクを自動化しています。

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

レコメンデーションの完全なセットを参照してください。

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