以下の内容はhttps://tech.andpad.co.jp/entry/2026/02/05/100000より取得しました。


SRE Kaigi 2026で「コスト版ポストモーテム」の導入とその後の改善について発表しました

FinOpsチームのテックリードの吉澤です。去年まではSREチーム所属だったのですが、1月からは新設されたFinOpsチーム(旧:インフラコストマネジメントプロジェクト)の専任になりました。

このチームの活動に関連した内容を、2026/1/31(土)に中野で開催されたSRE Kaigi 2026にて発表してきました。

今回の記事では、この発表スライドの内容や、時間の都合で省いた詳細の補足、そしてAsk the SpeakerやXで頂いた質問への回答をご紹介します。

発表スライド:予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善

「ポストモーテム」はすでに多くのSREにとって馴染みのあるプラクティスだと思います。発表では、このポストモーテムを、不必要なコストの増加(弊社社内では「コスト障害」と定義)に適用した「コスト版ポストモーテム」の導入事例をご紹介しました。

例えば、

  • コスト削減を進めた結果、ポストモーテムが必要と考えるようになった理由
  • コスト版ポストモーテムの具体的なフォーマット
  • コスト版ポストモーテムを書く2つのパターン
  • コスト異常発生時の具体的なワークフローや役割分担

などをご紹介していますので、以下のスクリーンショットを見て少しでも興味が湧いた方は、是非スライド全体を読んでみてください!

コスト削減を進めて実感したこと

コスト版ポストモーテムの具体的なフォーマット

コスト版ポストモーテムを書く2つのパターン

コスト異常発生時のフローチャート

発表で特に伝えたかったこと

発表の冒頭で「仕事で少しでもインフラコスト削減に関わっている人」に挙手してもらったところ、私の見た限りでは会場の約7〜8割の方が挙手されていました。長年SREとして働いてきた自分の経験からも、SREはインフラ全体を把握しているため、インフラコスト削減を求められやすいと思います。

そのような聴衆の方々に向けて、発表の最後に私から「自分が過去に関わったコスト削減についてコスト版ポストモーテムを書いてみる」ことをおすすめしました。

コスト版ポストモーテムを書く2つのパターンのうち、「コスト削減後」のほうは、本セッションでご紹介したワークフローを整備しなくてもすぐに始められます。一度書いてみるだけでも気づきがあると思いますし、実際に私の場合は、この発表で話したような色々な気づきが得られました。

まとめ

時間の都合で省いた詳細:FinOpsとの関係

今回の発表では、私たちのチーム名(FinOpsチーム)を除いて、「FinOps」という用語をあえて使いませんでした。

その理由は主に2つあり、1つは「FinOps」という単語の知名度がまだ低いため、きちんと理解してもらおうと思うと説明に時間がかかること。もう1つは、今回のテーマである「コスト版ポストモーテム」を理解してもらうために「FinOps」という用語は必ずしも必要ないと判断したためです。

そのような理由でFinOpsという用語を用いなかっただけで、私たちは新しいチームの名前に「FinOps」と入れていますし、FinOpsの考え方を積極的に取り入れようとしています。特に、クラウドFinOps 第2版はチーム全員で読んで参考にさせてもらっています。

また、最近はFinOps Frameworkに沿ってチームの活動を整理しています。FinOps FrameworkのCapabilityのなかにAnomaly Management(異常管理)という項目があり、ポストモーテムは成熟度レベル「Run(高度)」に含まれています。

Analysis results in full root cause analysis post-mortem where appropriate

今回の発表は、この部分の具体的な実践の紹介と言えます。

FinOpsとの関連については、もう少し自分たちの理解が深まった段階で、このテックブログなどで発表します。また、今年はSRE関連のイベントに加えて、FinOps関連のイベントにも参加したいと考えています。

Ask the Speakerでの反響

Ask the Speakerは非常に盛況で、5名の方と詳しいお話ができました。そのうち複数の方から、「自分たちでもコスト版ポストモーテムを書いてみる」というコメントを頂けて、とても嬉しかったです。

以下、頂いた質問の一部をご紹介します。

Q. 自分はSREチーム所属だが、開発チームとの関係は共通の悩みだと思う。開発チームにコスト意識をどのように芽生えさせるか?

まずは開発チームのリーダー(テックリード)の方に、普段なににどのくらいのコストがかかっているか理解してもらうことで、協力を得やすくなると考えています。そのため今後は、開発チームのリーダーに向けたコストダッシュボードの提供や、その使い方についての情報共有を進めていくつもりです。

Q. このような活動について、会社からのサポートは最初からあったか

FinOpsチームの前身であるインフラコストマネジメントプロジェクトは2024年6月に開始しました。この時、活動案の1つとして、開発者のコスト意識を高めるFinOps的な活動も提案したのですが、その際はコスト削減をまず優先という結論になりました。ちなみに、振り返ってみて、このときの判断は正しかったと思います。

その後、1年以上コスト削減の実績を積み上げてきました。その結果、コスト最適化は継続的に行う必要があるという共通認識が得られたことで、このような活動についてサポートが得られるようになったと考えています。

Q. 56ページの「事例2:Datadogのログの増加」でコスト障害ではないと判断したのはなぜ?

Datadogへのログの送信量が急増したという報告を受けて緊急調査したところ、データの見方に誤解があり、実際はコスト影響が出るほどの増加ではないことがわかりました。そのため、コスト障害ではないと判断しました。

Xでの反響

Xでもハッシュタグ#srekaigi_hallで、非常にたくさんのコメントを頂きました。ありがとうございます!

そのなかにあった、いくつかの疑問について補足説明させてください。

Q. コスト障害への対応プロセスを既存のインシデントプロセスに統合しなかったのはなぜ?

x.com

これはとても鋭い指摘で、弊社社内でも、コスト障害対応をインシデント対応の一種とみなしてCREチームに集約できないかという議論はありました。しかし、最終的には集約しませんでした。理由は大きく2つあります。

1つ目の理由は、必要な知識が異なるためです。インシデント対応はプロダクトと顧客に関する深い知識が必要ですが、コスト障害対応ではコストに関する深い知識が必要です。

2つ目の理由は、関係者が異なるためです。インシデント対応では顧客とのコミュニケーションが重要になるため、クライアント広報の関係者もSlackチャンネルに招集されます。一方、コスト障害対応ではその必要はありません。

そのため、インシデント対応はCREチーム、コスト障害対応はFinOpsチームという整理をして、ワークフローも別のものとしました。しかし、これは現在そうしているというだけで、将来的に統合できる可能性はあります。

Q. 実際にどのようなアクションアイテムが出て、どう社内に伝搬させているか

x.com

ここでいう「アクションアイテム」とは、コスト版ポストモーテムに記載する「再発防止策」のことを指していると思いますので、そのつもりで例を1つご紹介します。

本セッションでご紹介したプロダクトAの事例では、STSへの過剰アクセスの不具合を含むコードは、社内向けのライブラリの一部でした。このライブラリは他のプロダクト(プロダクトAよりも規模が小さいもの)でも使用されていました。

そのため、再発防止策として以下の2点を決めました。

  1. このライブラリのアップグレード
  2. このライブラリの利用者すべてが不具合解決後のバージョンにアップグレードしていることの確認

プロダクトAの開発チームがこれらを実施し、FinOpsチームがその完了を確認しました。

発表を通じての感想

インフラコストに関する発表は珍しいこともあってか、ホールで発表する機会に恵まれて、非常に多くの方にご参加いただきました。また、Ask the Speakerでは、自分事と捉えてくれた熱のある方から、いろいろな意見や質問を伺うことができました。発表して本当によかったと感じています。

SREはインフラに精通しているため、インフラコスト削減の主導・実施を求められがちです。その一方、コストに関する取り組みは社外発表しづらいこともあり、なかなか他社の事例を聞く機会がありません。今回の発表が、SREのFinOps的な活動の共有を促すきっかけになれば幸いです。

最後に、このような貴重な機会を提供してくれた、SRE Kaigi 2026のすべてのスタッフ、スポンサー、関係者の皆様に御礼申し上げます。また、会場に来て励ましてくれたアンドパッドのSRE、CREチームの皆様もありがとうございました。

We are hiring!

アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。FinOpsチームは、求人一覧にあるSREやソフトウェアエンジニアの業務の一部になります。アンドパッドのマルチプロダクト戦略を支える開発組織にご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。

hrmos.co




以上の内容はhttps://tech.andpad.co.jp/entry/2026/02/05/100000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14