コスト異常を、Jira・Linear・GitHubのissueとして担当チームへ

Cloud Intelligence™のThreadsが、コスト異常から起動できるようになりました。証拠を添えたissueを起票し、異常ページからステータスを追跡。エンジニアリングの対応完了まで、しっかり見届けられます。

異常対応で難しいのは、検知そのものではありません。検知エンジンがアラートを発し、FinOpsチームはあるプロジェクトのBigQuery費用が一晩で3倍になったことに気づきます。しかしそこから先、この発見はチーム間のグレーゾーンに入り込みます。FinOpsには異常が見えても、修正はできません。修正できるエンジニアは、Cloud Intelligence™を日常的に開いているわけではなく、JiraやLinear、GitHubの中で仕事をしています。

そこで誰かがSlackにメッセージを書くか、数値を手作業で貼り付けたチケットを起票します。その瞬間から、2つの「真実」が乖離し始めます。チケット側は費用が元に戻ったかどうかを知らず、異常側は誰かが対応中かどうかを知りません。1か月後には、あの2,800ドルがどうなったのか誰も説明できず、同じ設定ミスのスケジュールがひっそりと再び動いています。

本日より、異常と対応作業はひとつのレコードになります。検知された異常からThreadを開くと、Jira・Linear・GitHubのissueとして起票されます。issueには証拠があらかじめ記載されています。何が、どこで、どのサービスで検知されたのか、想定に対して実際にいくら観測されたのか、そしてCloud Intelligence™上の該当スパイクへ直接飛べるリンク。issueは、そのプロジェクトを所有するチームのバックログに、普段から計画に使っているツールの中に届きます。そのステータスは異常ページに反映されます。InsightsやCloudFlowですでにお使いかもしれないスレッドの仕組みと同じものが、説明責任が最も問われる瞬間で使えるようになりました。

Slackメッセージではなくスレッドを起票する理由

異常とは、特定のチームに向けられた問いです。「この支出は意図したものですか?」——スレッドは、この問いを消えないものにします。担当者とステータスがあり、誰かのスプリントに組み込まれるため、たまたまチャンネルを読んだ人に依存するのではなく、他の作業と対等に優先順位を競えます。対応するエンジニアは、数値、タイムスタンプ、コンソールへのリンクをチケットの中で受け取れます。「何が問題だったのか」をFinOpsに聞きに行く必要は誰にもありません。修正が反映されissueがクローズされると、FinOpsは誰にも確認することなく異常ページで「Done」を把握し、異常そのものに結果を記録できます。

この最後のステップは意図的な設計です。異常のレビューステータスとissueの状態は、あくまで独立しています。エンジニアリングはissueを所有します(To Do、In Progress、Done)。FinOpsは判定を所有します(レビュー中、異常を確認、異常ではない)。チケットがクローズされても異常が勝手にレビュー済みになることはなく、「異常ではない」という判定が、まだ対応中のチケットをクローズすることもありません。互いの状態は見えますが、どちらも相手の状態を上書きできません。時間が経つにつれ、異常の一覧は「誰かがたぶん見た」スパイクのリストではなく、対応作業が紐づいた意思決定の記録になっていきます。

FinOpsの実践を築いている段階のチームにとって、これこそが実務における説明責任の姿です。名前のある担当者、可視化されたステータス、記録された結果。検知は一元的に、修復は各チームに分散して行われます。Threadsは、発見をリソースの所有チームに引き渡し、対応中も可視性を保ち、異常が「認知される」だけでなく「解決される」ことを組織に示すための手段です。

始め方

1. まだの場合は、Jira・Linear・GitHubを連携します:Jira、Linear、GitHub Issues
2. コスト異常から異常を開き、Create threadを選択します。
3. 異常ページまたはThreadsから対応状況を追跡します。