コスト異常をチケット化し、誰かがSlackを読む前に適切なチームへ

重大度、請求スコープ、検出方法に基づいて、異常をリソースの所有チームへJira、Linear、GitHubのIssueとしてルーティングします。

異常検知の課題は、検知そのものではなく「届け方」にあります。検知が作動すると、Slackチャンネルや受信トレイに通知があふれ、購読している全員に届きます。小規模なチームならそれでも機能します。しかし、チェックアウトチームとデータプラットフォームチームがそれぞれ別の請求アカウント群を管理し、クリティカルな案件はすべてプラットフォームエンジニアリングが担うような組織では、同じ通知が40人に届き、そのうち38人は何も対処できません。数週間もすればチャンネルはミュートされます。その間、誤設定されたスケジュールを修正できたはずの2人は、財務部門から問い合わせが来て初めて事態を知ることになるのです。

Threadsに自動化ルールが加わりました。どの異常(またはインサイト)がどのチームのものか、Issueをどこに作成すべきかを定義しておけば、条件に一致する異常が検出された瞬間に、Cloud Intelligence™がそのチームのバックログにスレッドを作成します。

できること

ルールは、条件と作成先の組み合わせです。条件には異常そのものの詳細情報を使います。重大度、検出された請求スコープ、請求データ由来かリアルタイム使用量由来か、トリアージステータス、ラベル/タグなどです。作成先は、トラッカー(Jira、Linear、GitHub)のプロジェクト、チーム、またはリポジトリに加え、担当者、ラベル、Issueタイトルの指定です。たとえば「クリティカルな異常はすべて」プラットフォームエンジニアリング向けのGitHub Issueに、「チェックアウト請求アカウントの中程度の異常」はチェックアウトチーム向けのJiraチケットに、「分析プロジェクトのリアルタイム異常」はデータプラットフォームチーム向けのLinear Issueになります。それ以外の人に通知が飛ぶことはありません。スレッドを受け取るのは、実際に対処できる人だけです。

ルールは有効化する前に、直近の異常に対してプレビューできます。プレビュー中は何も作成されません。ルールは上から順に評価され、最初に一致した有効なルールがその異常を処理します。そのため、条件が具体的なルールを広範なルールより上に配置してください。ルールは削除せずに一時停止することも可能です。

異常に最初に一致したルールが、プライマリのThreadを作成します。内容は手動で作成したスレッドと同じで、何がどこで検出されたか、観測値と期待値の差、スパイクへのリンクが含まれます。異常は静的なものではありません。同じ異常の後続リビジョンが引き続き条件を満たす場合、ルールは2つ目のIssueを作るのではなく、既存のIssueにコメントを追加します。Issueがすでにクローズされていても同様です。また、担当者やステータスなど、エンジニアが設定した内容には一切手を加えません。ルールの変更はすべて不変のリビジョンとして保存され、実行ログ(Run log)では、どのルールが動作し、何を作成し、なぜそうなったのかを確認できます。

Threads向けにJira、Linear、GitHub Issuesをすでに連携済みであれば、新たにインストールするものはありません。自動作成と手動作成は1つのレコードを共有するため、同僚が先に手動でスレッドを作成していた場合、ルールはそれを認識し、重複を作りません。さらに、アカウントごとに1日あたりの作成上限が設けられているため、通知が多発する朝でもバックログがあふれることはありません。

利用を開始する

1. まだの場合は、Jira、Linear、またはGitHub Issuesを連携します。
2. 異常検知が対象としたい範囲をカバーしていることを確認します。ルールの一致条件に使いたいアロケーションも含めてください。ルールが認識できるのは、検知機能が生成した異常のみです。
3. Threadsを開き、Thread automationを選択して、最初のルールを作成します。

自動化ルールは、Thread Manager権限を持つすべてのアカウントで利用できます。いま私たちが最も知りたいのは、実際の1か月分の異常に対してルールがどう動いたかです。本来動くべきでないのに動いたルールはどれか、利用可能な条件ではどうしても届かなかったチームはどこか、ぜひお聞かせください。