マンデート

あるマンデートとは、誰も指示を出さない場合にCoroidが実行すべき作業内容を定めた恒久的な指示書です。具体的には、達成すべき目標、対象となるプロジェクト、週または月ごとの予算、終了条件などが含まれます。システムから届く要求——つまり作業受付用のAPI、自動化処理、連携機能、監視データ——は有効なマンデートに基づいて受理されますが、人間からの要求はそうではありません。詳細は以下をご覧ください。マンデートが対象とする要求。

マンデートは開始可能な作業を決定しますが、Coroidがコードをマージしたりデプロイしたりすることを許可するわけではありません。詳細は以下を参照してください。Coroidが決定する事項と、人間が判断を担う事項。

マンデートが有効なケース#

Coroidへの作業要求が個別に指示されることなく発生し、事前に実施可能な範囲を決めておきたい場合にマンデートを作成します。

• エラートラッカーや監視ツールから、作業受付用のAPIを通じてインシデント情報が報告される場合;
• GitHubからの通知やSlack、Telegram、Jiraのメッセージなどが該当します。作業の選定自動化処理が要求に変換される場合;
• サポートやフィードバックツールから顧客の報告内容が伝えられる場合;
• スキャナーやCIジョブが個別に結果を報告する場合。

マンデートが設定されていない場合、これらの要求は他の要求と同様に扱われ、要件を満たすと人間からの要求と同じエージェントスロットで待機しますが、独自の予算は割り当てられません。アラートが頻発する週にはキューが溢れる可能性があります。マンデートを設定すると、対象プロジェクト、週または月ごとの支出上限、同時に確保できるエージェントスロット数が明確になります。

要求の処理フロー#

図に示すマンデートは、請求処理用のAPIプロジェクト向けに作成されたものです。このプロジェクトのエラートラッカーが請求書出力時の新しい例外を検知すると、アラートルールのウェブフックが自社の小規模な中継装置を経由して、作業受付用の作業受付用のAPIに登録され、トラッカーの課題IDがシグナルの識別子となり、影響を受ける経路や、修正が完了と判断されるまでに発生する必要がある500件の要求数が記録されます。

1. 選定は他の要求と同様に処理され、機密情報や個人情報を除外し、現在のリリース版を確認し、重複を調べ、報告内容を検証して評価します。
2. 受理は請求処理用のAPIを対象とするマンデートを探し、以下の順で確認します：同じ問題が既に別のプロジェクトで対応中かどうか、評価結果が意図した挙動かどうか、マンデートが持つ2つのスロットのうち空きがあるかどうか、今週の予算に余裕があるかどうか、成果を測定可能かどうか。
3. 受理済みとなり、要求は予約済みのスロットと週次予算を割り当てられたタスクとなります。その後は通常通り、仕様策定、コーディング、テスト、品質チェック、QA、レビューを経てpull requestとして完成します。
4. 人間がマージしますタスクの 成果に関する契約には、そのマージで達成すべき事項が記録されます。具体的には、該当経路で500件の要求が発生した後、24時間以内に同じ問題が再発しないことです。

同じアラートが再度発生した場合、2番目の要求は既に解決済みとみなされ、最初の要求にリンクされます。悪いデプロイによって一気に6件の新規問題が発生した場合でも、マンデートの下で同時に処理されるのは最大2件のみで、残りは延期、その後、マンダートのスロットが空いたタイミングで1件ずつ受け入れられます。残りの2つのエージェントスロットは、チームが『新規作業』で依頼する作業用に確保されます。

マンダートの例#

本番環境のエラーが蓄積されるのを防ぐ#

APIサービスはエラーをエラートラッカーに報告しますが、修正作業は誰かが時間がある時に実施されます。

エラートラッカーから作業受付用のAPIを通じて要求が届き、各要求にはsignalトラッカーの課題ID、ルート、要求数が記載されています。1つの課題は最大で1件の作業となり、何度発火しても同様です。1週間あたりのコストは最大100米ドルです。ルートが指定されていないアラートは開始せずに待機状態になります。なぜなら、修正が成功したかどうかを判断する情報がないためです。ルートを指定するか、""を有効にしてください。成果が測定できない作業を受け入れる。

GitHubで報告されたバグを対応する#

ユーザーがウェブアプリのリポジトリに課題を作成する速度は、誰かがそれらを優先順位付けする速度を上回ります。

A作業を選定する新しいGitHub上で自動化が各課題ファイルを作成します。選定処理により重複課題や既に修正済みの現行リリースに関する課題、再現不可と判断された課題が除外されます。測定可能性のスイッチがオンの場合、課題に経路やトラフィックの記載がないため成果の契約を測定できず、スイッチがオフの場合はすべての課題が保留状態になってしまいます。書き込み権限を持つユーザーが開いた課題は自動的に開始されますが、それ以外の課題は誰かが開始するのを待つ必要があり、詳細は以下を参照してください。作業が開始されるとき。

顧客からの報告内容に対応する#

サポートツールが顧客からの報告を収集しますが、緊急度の高い報告はエンジニアリングチームに届くのが遅れがちです。

サポートツールがサービスアカウントを使い、各報告を作業受付APIを通じてファイル化します。選定処理により再現不能な報告が除外され、マンデートの制限により多忙な週の報告がエージェントの枠の半分または予算を超えることが防がれます。

締め切り前にクリーンアップを完了する#

利用中の決済SDKが次四半期でサポート終了となり、廃止された呼び出しが2つのサービスに分散しています。

CIジョブが呼び出し箇所ごとに1件の要求をファイル化し、ファイル名と行番号をシグナルの指紋として使用します。次回実行時に同じ呼び出し箇所が見つかると、既に対応中の作業にリンクされます。Coroidはまだ対象を読み取っていません。最後の呼び出しがなくなったら、「完了」を選択してください。完了自分で行ってください。

承認が不要な場合#

• 人々が依頼する作業新規作業で作成またはインポートされた要求は、要件を満たせば受理され、決して先送りされることはなく、承認の予算を使うこともありません。
• スケジュールとフォローアップの設定これらは直接タスクを作成し、品質管理の手続きを経ずに処理されるため、承認の制限を受けません。代わりに低い優先度を設定してください。詳細はスケジュール。
• 一回限りの取り組み形が明確で終了点が定まっている作業は 計画、承認ではありません。
• 重複する承認同じプロジェクトに対して複数の有効な承認が存在する場合、最も古い承認がその要求を管理します。各プロジェクトには一つの承認のみを割り当ててください。

承認の配置場所#

「品質管理」を開く品質管理 → 承認。品質管理内のすべての範囲——組織のデフォルト設定および各プロジェクト——は同一のリストにリンクされています。承認は組織に属し、自らプロジェクトを指定するからです。プロジェクトの範囲を開いてもリストは絞り込まれません。

オーナーと管理者が承認を作成・変更できます。メンバーはそれを閲覧可能です。エージェントやサービスアカウントは承認を変更することはできません。

承認に含まれる内容#

種類。 有限承認には目標があり、それに達した時点で終了します。例えば「未解決のセキュリティ問題をゼロにする」といった具合です。継続的承認は保守作業であり、「本番環境のルートで未処理の例外が発生しないようにする」といったものです。目標ではなくレビュー日が設定されます。

目的。何が実現されるべきかを一言で表す記述です。これが承認を理解するための基準となります。受理の判断は範囲、予算、ステータスに基づいて行われます。

ベースライン。承認の評価基準となる指標とその出典です。指標名を指定し、測定値はCoroidが収集し、手入力されることはありません。設定のエクスポートにも含まれません。新しい承認にはまだ測定値なし。

目標。有限の承認の場合：完了を意味する指標とその値です。

優先度。一行につき一つ。作業がリソースを競合する場合、最初の優先度が優先されます。

範囲。

• プロジェクト。承認が適用されるプロジェクトです。チェックが付いていない場合は、後から作成されるプロジェクトを含め、組織内のすべてのプロジェクトが対象となります。該当するプロジェクトにチェックを入れてください。特定のリポジトリ向けに作成された承認は、そのプロジェクト名を指定するべきです。
• 領域。各プロジェクト内のパスパターンを1行ずつ記載します。例: apps/api-*/src/**。空欄の場合はどこでも適用されます。
• 変更クラスを指定します。マンデートが対象とする変更の種類です。例: exception_fix。
• 成果が測定できない作業を許可します。デフォルトでは無効です。無効の場合、以下のリクエストは成果契約が測定できないと、開始前に待機状態になります。

予算Coroidが各期間にマンデートに費やせる金額は、米ドルおよびエージェント時間で、週単位または月単位で指定します。週は月曜日の00:00に始まり、月はその初日に始まります。予算は自動的に再開されます。:00UTC時間で計算され、 月はその初日に始まります。予算は自動的に再開されます。

停止条件予算が尽きた時、目標に達した時、連続して不確定な結果が一定数出た時、または指定日になると停止します。

レビュー日進行中のマンデートの場合：担当者が更新または終了させる日付です。

ドリフトルール進行中のマンデートの場合：ベースラインメトリックの上限値です。この値を期間内に超えると、オーナーへのエスカレーションが発生します。

ステータスとバージョン#

マンデートは最初は下書き。公開すると有効となり、有効なマンデートのみ作業を許可します。

公開済みのマンデートを変更すると、新しいバージョンが公開されます。以前のバージョンは、誰が公開したかと公開日時と共に保持されます。

各公開およびステータス変更は、マンデートにおける決定事項です。来歴作成者と共に、組織の監査ログ内のイベントも記録されます(mandate.created、mandate.published、mandate.pausedなど)。

マンデートが管理するリクエスト#

マンデートは、Coroidに担当者がいない状態で届くリクエストを管理します。これにはワークインテイクのAPI、GitHubやJira課題などの自動化・連携機能、およびモニタリングからのリクエストが含まれます。

人が「新規作業」またはインポートで作成したリクエストは、マンデートの対象外です。適格であれば常に受理され、延期されることもなく、マンデートの予算を消費することもありません。依頼したのは人間なので、エージェントスロットにそのままキューされます。

無人のリクエストは、最も古く活動中のマンデートに割り当てられます。該当マンデートのプロジェクトにリクエストのプロジェクトが含まれるか、すべてのプロジェクトをカバーするマンデートが対象です。どのマンデートにも該当しないリクエストは、通常のリクエストとして受理されます。

受理の判断内容#

受理は「適格性判定」の最終段階です。モデルによる判断は行いません。各リクエストに対して以下のいずれかを決定します：

• 受理作業が作成され、エージェントスロットの確保と、マンデート下では予算の一部が割り当てられます。その後、自動的に開始されるかどうかはソースに従い、以下に記載の通りです。 作業が開始されるタイミング。
• 既に解決済み同じシグナル、つまりトラッカーやモニタリング内の同じ課題、または同じ障害が、組織内の他のプロジェクトで既に処理中である場合、そのリクエストは該当作業にリンクされ、新たな作業は作成されません。
• 変更不要適格性判定の結果、報告された挙動が意図通りであると判断されたため、新たな作業は作成されません。
• 延期リクエストは受理可能だが、現在は開始すべきではありません。マンデートが利用できるエージェントスロットが使われている、指定期間の予算が尽きた、または成果が測定不能でマンデートがそれを許容しない場合が該当します。

各決定とその理由は、リクエストと共に記録されます。

延期されたリクエスト#

Coroidは毎分延期されたリクエストを再確認し、スロットや予算が空いた時点でマンデートの現在バージョン下で受理します。マンデートの予算を増額するか、スロットを占有している別のマンデートを一時停止すれば、次回のチェックで延期が解除されます。直接開始するための上書き機能はありません。

マンデートの指定期間（1週間や1ヶ月など）を超えて待機したリクエスト、またはマンデートが非アクティブになったリクエストは、作業なしで終了します。

マンデート作業がリソースをどのように配分するか#

マンデート作業が占有できるエージェントスロットは、組織全体の最大半分までです。エージェントスロット同時に稼働中の作業や受理済みだがまだ開始されていない作業も含まれます。残りのスロットは人々の要望に応じるために確保されます。プランでスロット数に制限がない場合は、月次の支出予算に対して同じ割合が適用されます。

受理されたリクエストは、タスクが開始されるまで30分間予約が保持されます。その時間が経過すると予約は無効になります。作業がまだ作成されていないリクエストは延期状態に戻り、既存のタスクは他のタスクと同様にスロットを待ちます。

設定のエクスポート内では#

マンデートは「設定のエクスポート」内に記載されます： 種別、目的、対象、優先度、範囲、予算、停止条件、レビュー日、ドリフトルール。プロジェクトは安定したキーで照合され、オーナーは役割で特定されます。ベースラインはエクスポートされず、元の組織の測定値としてのみ存在します。新しい目的を持つマンデートは、公開するための下書きとして送信されます。既存のマンデートと目的が一致する場合は、下書きであればそれを更新し、そうでなければ新しい公開バージョンとして作成されます。

関連項目#

• 成果物契約
• Coroidが決定する内容と、あなたが管理する内容
• リソースとエージェントスロット
• 新規作業と資格審査
• 来歴