Runbook の設計
重要
このバージョンの Orchestrator はサポート終了に達しました。 Orchestrator 2022 にアップグレードすることをお勧めします。
新しい Runbook を計画するときは、自動化する定義済みのプロセスから始める必要があります。 このプロセスにより、Runbook アクティビティの選択が決まります。 具体的には、次のことを決定します。
- Runbook はいつ、どのくらいの頻度で実行されますか?
- ワークフローを構成する手順は何ですか?
- ワークフローの手順を反映するアクティビティは何ですか?
- ワークフローを開始するために必要なデータの種類は何ですか?
- 各アクティビティから生成されるデータは何ですか?
- ワークフローの最後にどのような結果が生成されますか?
- Runbook の結果はどのように報告されますか?
Runbook を設計するときは、次の点を考慮してください。
失敗と警告のリンク - アクティビティのすべての結果を処理することが重要です。 アクティビティは既定の成功文字列を提供しますが、既定の失敗ケースは提供しません。 アクティビティを元に戻すか、ログ ファイルに結果を書き込む必要があるかどうかを検討してください。
既定の文字列を置き換える - Runbook でワークフローを確認すると、ラベルによって個々のアクティビティの実行内容が識別されます。 リンクとアクティビティ ラベルの名前をわかりやすい名前に変更します。
リンクの色 - 条件または分岐がある場合にリンクの色を変更します。 成功として GREEN を使用し、警告または失敗に RED を使用するのが一般的です。 標準の関連付けを使用する必要がありますが、使用する色が多すぎるか、説明的な目的が失われます。
Runbook ごとのアクティビティの数を制限する - 1 つの Runbook でアクティビティが多すぎると、管理とトラブルシューティングが困難になります。 Runbook を複数のサブタスクに分割し、それらのサブタスクごとに子 Runbook を作成することを検討してください。 親 Runbook から子 Runbook を呼び出すことができます。 これらの子 Runbook は、他のワークフローで再利用できます。
Runbook ログ - 既定では、Runbook のログ オプションは無効になっています。 ログ記録を有効にすると、データによってデータベースのサイズが大幅に増加します。 別の方法として、外部システムまたはファイルにログを記録することもできます。
次の手順
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示