マンデート

「マンデート」とはマンデートは、誰も指示を出せないときにCoroidが取り組む内容を定めた恒常的な方針です。目的、対象プロジェクト、週または月ごとの予算、終了時期を定めます。作業受付用API、自動化、連携機能、監視など、システムから届くリクエストは有効なマンデートに基づいて受け付けられます。人からのリクエストは対象外です。詳しくはマンデートが適用されるリクエストとは。

マンデートは作業開始の可否を決定しますが、Coroidがコードをマージしたりデプロイしたりすることを許可するわけではありません。詳細は以下をご覧ください。Coroidが決定する事項と、ユーザーが管理する事項。

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

Coroidへの作業依頼が個別に指示されることなく届き、どの程度の作業を許可するかを事前に決めたい場合にマンデートを作成します。

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

マンデートがなければ、こうしたリクエストは他のリクエストと同様に扱われ、選定された後は人間からの依頼と同じエージェントスロットで待機し、独自の予算は設定されません。アラートが頻発する週にはキューが埋まってしまう可能性があります。マンデートを設定すれば、対象となるプロジェクト、週または月ごとの支出上限、同時に確保できるエージェントスロット数を明確にできます。

リクエストの処理フロー#

図中のマンデートは請求処理用のAPI向けに設定されています。このシステムのエラートラッカーが請求書出力時の新しい例外に関するアラートを発報します。アラートルールのウェブフックがユーザー自身のリレーを経由して作業受付用のAPIに情報を送信します。作業受付用のAPI、トラッカーが記録した課題IDをシグナルの識別子とし、影響を受けるルートや修正が完了するまでに必要な500件のリクエスト数も併せて送信されます。

1. 選定他のリクエストと同様に処理が行われ、機密情報や個人情報が除去され、現在のリリース版が確認され、重複がチェックされ、報告内容が検証されて評価が下されます。
2. 受理請求処理用のAPIを対象とするマンデートを探し、以下の順で確認が行われます：同じ課題が既に処理中かどうか（同一プロジェクト内または他プロジェクトで）、評価結果が想定通りの動作かどうか、マンデートで定められた2つのスロットのうち空きがあるかどうか、今週の予算に余裕があるかどうか、成果が測定可能かどうか。
3. 受理済み受理されると、リクエストは予約済みのスロットと週ごとの予算内のタスクとなり、通常のフロー――仕様策定、コーディング、テスト、品質チェック、QA、レビュー――を経てpull requestとして完成します。
4. 人間がマージしますそのタスクの 成果契約には、そのマージで達成すべき内容が記録されます。例えば、該当ルートで500件のリクエストが発生した後、24時間以内に同じ課題が再発しないことなどです。

同じアラートが再度発報された場合、2番目のリクエストは既に解決済みとして最初のリクエストにリンクされます。不良なデプロイによって一気に6件の新規課題が発生した場合でも、マンデートで許可されるのは同時に2件までであり、残りの課題は延期され、マンデートのスロットが空いたら順次受理されます。残りの2つのエージェントスロットは、チームが新規作業で依頼する内容のために確保されます。

マンデートの例#

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

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

エラートラッカーから作業受付用のAPIを通じてリクエストが届き、それぞれにsignal命名成果が測定できない作業を受理する。

GitHubに報告されるバグの対応#

ユーザーがウェブアプリのリポジトリに課題を登録する速度が、誰かがそれを分類する速度を上回っています。

A作業の適格性を判定する新規のGitHub課題ファイルごとに自動化が実行される。適格性判定により重複課題や既に修正済みの現行リリースに関する課題、再現不可能な課題が除外される。測定可能性の切り替えがオンになっているのは、課題で経路やトラフィックが指定されておらず、成果の契約を測定できないためだ。この切り替えをオフにすると、すべての課題が待機状態になる。書き込み権限を持つユーザーが作成した課題は自動的に開始され、それ以外の課題は誰かが開始するのを待つ。詳細は以下を参照。作業が開始されるタイミング。

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

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

サポートツールがAPIを介してサービスアカウントで各報告を作業受付に登録する。適格性判定で再現できない報告は除外され、この仕組みにより多忙な週にエージェントの作業枠の半分以上や予算を超える報告が発生するのを防ぐ。

期限前にクリーンアップを完了させる#

利用中の決済SDKが次四半期にサポート終了を迎え、その非推奨な呼び出しが2つのサービスに分散している。

CIジョブが呼び出し先ごとに1件のリクエストを登録し、ファイル名と行番号をシグナルの指紋として使用する。これにより次回実行時に同じ呼び出し先が見つかると、既に対応中の作業にリンクされる。Coroidはまだ対象を読み取っていない。最後の呼び出しがなくなったら、完了自分で行ってください。

マンデートが不要な場合#

• 人々が依頼する作業新規作業で作成またはインポートされたリクエストは適格性を満たせば受理され、延期されることもマンデートの予算を使うこともない。
• スケジュールとフックによるフォローアップこれらは適格性判定なしで直接タスクを作成するため、マンデートによる制限を受けない。代わりに低い優先度を設定してください。詳細はスケジュール。
• 一回限りの取り組み形状が明確で終了時期が定まっている作業は 計画であり、マンデートではない。
• 重複するマンデート複数の有効なマンデートが同じプロジェクトを対象とする場合、最も古いマンデートがそのリクエストを管理する。各プロジェクトには1つのマンデートを割り当ててください。

マンデートの存在場所#

開く品質管理 → マンデート。品質管理内のすべての範囲（組織のデフォルト設定および各プロジェクト）は同じリストにリンクされる。マンデートは組織に属し、自身で対象プロジェクトを指定するためだ。プロジェクトの範囲を開いてもリストは絞り込まれない。

オーナーと管理者がマンデートを作成・変更できる。メンバーは閲覧のみ可能。エージェントとサービスアカウントはマンデートを変更できない。

マンデートに含まれる内容#

種類 限定マンデートには目標があり、達成されると終了する。例：「未解決のセキュリティ脆弱性をゼロにする」。継続中マンデートは保守作業であり、例：「本番環境の経路に未処理の例外が発生しないようにする」。目標ではなくレビュー日が設定される。

目的達成すべき状態を記述した1文。これがマンデートを理解するための基準となる。受理の判断は範囲、予算、ステータスに基づく。

ベースラインマンデートの測定基準およびその出典。基準名を指定し、測定値はCoroidが収集する。手入力は不可。設定エクスポートにも含まれない。新規マンデートにはまだ測定値なし。

目標限定マンデートの場合：測定基準と完了を意味する値。

優先度1行につき1件。作業が処理能力を競合する場合、最も上位の優先度が優先される。

範囲

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

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

停止条件です。予算が使い切られた時、目標に達した時、連続して一定数の不確定な結果が出た時、または指定日になると停止します。

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

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

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

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

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

公開とステータス変更のすべてはマンデートの来歴に記録され、実行者と組織の監査ログ内のイベントが関連付けられます(mandate.created、mandate.published、mandate.pausedなど)。

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

マンデートは、Coroid内に担当者がいない状態で届くリクエストを管理します。ワークインテイクのAPI、GitHubやJira課題などの自動化・統合機能、監視システムからのリクエストです。

人が新規作業で作成したりインポートしたりしたリクエストはマンデートの対象外です。要件を満たせば常に受け入れられ、延期されることもなく、マンデートの予算を消費しません。要望したのは人間であり、エージェントスロットに単にキューされるだけです。

無人のリクエストは、最も古い有効なマンデートのプロジェクトに含まれるか、すべてのプロジェクトをカバーするマンデートに割り当てられます。どのマンデートにも該当しないリクエストは通常のリクエストとして受け入れられます。

受け入れの判断内容#

受け入れは資格審査の最後のステップです。モデルによる判定は行いません。各リクエストに対して次のいずれかを決定します:

• 受け入れられました。作業が作成され、エージェントスロットと、マンデートの場合は予算の一部が確保されます。開始の有無はソースに従い、次のように決定されます: 作業の開始タイミング。
• すでに解決済み。同じシグナル—追跡システムや監視システム内の同じ問題、または同じ障害—が組織内の別のプロジェクトで既に処理中である場合、その作業にリンクされ、新規の作業は作成されません。
• 変更不要。資格審査の結果、報告された挙動が意図通りであると判断されたため、新規の作業は作成されません。
• 延期されました。リクエストは受け入れ可能だが、現在は開始すべきではありません。マンデートが使用できるエージェントスロットが使われている、ウィンドウ内の予算が尽きた、または成果が測定できずマンデートがそれを許可していない場合です。

各判断とその理由はリクエストとともに記録されます。

延期されたリクエスト#

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

マンデートのウィンドウ（週または月）より長く待機したリクエスト、またはマンデートがもはや有効でない場合は、作業なしで終了します。

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

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

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

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

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

関連項目#

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