taxin.dev

SRE NEXT 2026 に参加しました

2026年7月10日〜11日に開催された SRE NEXT 2026 に両日参加してきました。

SRE NEXT 2026

今年はスタッフではなく、一般参加者としてSRE NEXTに参加しました。2025年までスタッフとして参加していた（4年連続4回目）ので、例年とは違った新鮮な気持ちで楽しめました。運営スタッフの皆様に感謝の気持ちでいっぱいです。本当にありがとうございました。

SRE NEXT2025にコアスタッフとして参加しました - taxin's notes
07/11 (金) - 07/12 (土) の2日間でSRE NEXT 2025が開催されました。今年もコアスタッフとして運営のお手伝いをさせていただきました。 sre-next.dev SRE NEXTの運営スタッフとして参加するのは4年連続4回目です。一番最初にSRE NEXTのスタッフとして参加したのが4年前と考えると、感慨深いものがありますね。 taxintt.hatenablog.com taxintt.hatenablog.com taxintt.hatenablog.com 今年は、去年に引き続きRoad To SRE NEXTの運営と当日はTrack Aのチームリーダーを担当し…
taxin's notes

参加するにあたって、Mackerelというプロダクトやその開発に持ち帰れる知見や個人としての学びを得るという狙いがあったのですが、その目的は一定達成できたかと思います。私が所属している はてな（Mackerel）はロゴスポンサーでブース出店がなかったので、スポンサーブースで参加者の方々と会話する機会はありませんでしたが、その代わりに自由に移動して様々な人と好き勝手に話ができました。

SRE NEXTの前日には、Day0という名の飲み会をしていたり

懇親会の後にも、ふらっと向かった場所で別の集団と合流して二次会に参加していましたね

SRE NEXT 2026 では、以下のセッションを聴講しました。いずれも面白いセッションでした。

この記事では、セッション間や懇親会での雑談で盛り上がった話題をまとめておこうと思います。セッションの内容にも一部触れます。

コンフィグミスの難しさ

コンフィグミスというキーワードはメルカリの小山さんのセッションで出てきたワードです。セッションの中ではシステム障害について主要な障害原因パターンの一つとして紹介されていました。

OSINT for SRE: 
学術論文とポストモーテムから探る
システム障害の共通パターン / SRE NEXT 2026
Speaker Deck

その中でも、まとめページにも記載されている「ユーザーの意図と実際のソフトウェアの挙動を比較する方法が確立されず」という点で、コンフィグミスの難しさを再認識しました。

例えば、Terraformで考えてみます。Terraform Provider（その裏にいるAPI）にとってinvalidなパラメータが渡された場合は、terraform plan（apply）のタイミングでエラーが返ってくるので、コンフィグミスとして検出しやすいでしょう。

難しいのは、Terraform Providerにとってはvalidだが、自分達のサービス基盤のコンテキストに照らし合わせるとinvalidな設定である場合です。システムのコンテキストに依存しない汎用的なパターンであれば、tflintやtfsecといったチェックツールを使って一定は検知できるかもしれません。しかしコンテキストに依存する設定では、「あるべき状態」と照らし合わせて初めて「invalidである」と判定できます。そして、この「あるべき状態」はサービスの目的や運用ポリシーから導かれる情報であり、コードや設定単体からは復元できません。ここが取得の難所です。

最近だと、AI Agentを思い浮かべる人もいるかと思いますが、出力内容が非決定的であるAI Agentをどこまで信用できるのでしょうか？ あるいは、Availability / Latencyみたいな定量的なテレメトリーデータを基に正常状態を表現し、そことの比較で検知するというやり方もあるかもしれません。あまり筋のいいアプローチが思いついていないので、良いアイデアがあれば教えてください。

障害情報を統計データとして扱う

障害情報を統計データとして蓄積・分析することで、リアクティブな事後対策の個別最適から一歩踏み出せないか。これは、セッションではなく立ち話の中で挙がった話題でした。障害対応は、障害が発生する → 復旧する → 事後対策を考える、という具合に基本的にリアクティブな動きの連続で、事後対策も個別最適に陥りがちです。一方で、ポストモーテムの文化が根付いていれば、障害情報が統計データとして蓄積されます。この蓄積を統計的に分析すれば、全体最適かつプロアクティブな予防として障害に向き合えるはずです。（とはいえ、全体最適すぎると再発防止という観点では不十分な対策となるリスクもあるかもしれません）

では、障害情報を統計データとして扱うとき、どのような指標で評価すると良いのでしょうか。Google SRE - Incident Management: Postmortem Analysis にある binary push のような大別した原因分類のほか、影響を受けたコンポーネントやユーザー数といった影響範囲など、切り口は様々に考えられます。

自社の事例で言うと、過去数年分の障害情報の履歴を、コンポーネントごとの障害件数、発生時刻と修正時刻、障害に気づいたきっかけ、種類やタイプといった軸でスプレッドシートに集計しています。そこから見えてくる傾向を分析し、障害対応の改善に活用したという事例もありました。障害情報の集計自体は今も継続して行なっています。その上で、障害とプロアクティブに向き合ううえで、切り口をどう選ぶかで、蓄積したデータが実際の改善に結びつくかが分かれます。他社では障害情報をどのような軸で分析し、どのように活用しているのか、その事例が体系的に共有される場があれば話をしてみたいなという気持ちがあります。

SRE座談会 - 株式会社はてな
はてなのSREが語る、チームを横断した標準化活動と働き方
採用情報

こういった社外には出てきにくい話題こそオフラインで話したいですね。ポストモーテムカンファレンスというワードも見聞きましたが、すごく興味があります。

どのようにError Budgetを消費するかを設計する

Resilient なシステム設計というテーマは、1日目のメルカリ 渋谷さんのセッションで強く印象に残りました。そこでは、「壊れない」から「壊れても派手には壊れない」への転換というキーワードとともに、分散システムにおけるカスケード障害を止めるための（ネットワークリクエストを中心とした）実装パターンが語られていました。この話題を出発点に、2日目の懇親会や二次会の会話を経て考えていました。

分散システム、なんですぐ死んでしまうん？耐障害性を高めたいあなたのためのレジリエンスパターン入門
Speaker Deck

Availabilityを 0.1% 改善するのと同じくらい、エラーバジェットの消費（-0.1%）をどのように想定するのかも、サービスの実装時に同じ土俵で判断する必要があるでしょう。Blast Radiusを小さくする、MTTR（平均復旧時間）を短くするなど様々な観点があり、それらを実現するための実装パターンがあります。AWSが紹介しているCell-Based Architectureもその一つでしょう。システム全体を「セル」という独立した小さな単位に分けて、一つのセルが壊れても他のセルに影響しないようにすることで障害の影響範囲(Blast Radius)を最小限に抑えるという設計手法です。

What is a cell-based architecture? - Reducing the Scope of Impact with Cell-Based Architecture
docs.aws.amazon.com

エラーバジェットの中で効果を最大化する(最もユーザー影響が少ない形でエラーバジェットを消費する)という意味では「遠足のおやつ代」みたいなアナロジーで表現できるのではないかと思いました。実装にあたって、インフラコストという制約があるのは自明ですが、こういった観点もあるかなと思います。

2日目の基調講演の木村さんのスライドでも似たような話題が語られていました。

誰のためのReliability？
Speaker Deck

プロダクトの信頼性をビジネスドメインの観点から解釈することも重要であるはずです。例えば、サービスの可用性が一定時間損なわれたとして、顧客が求める品質においてどういう扱いになるのでしょうか。昼間・夜間など時間帯によってサービスダウンの影響度合いが変わるといった観点もあります。エラーバジェットの中で効果を最大化するという先述の観点では、時間帯によってダウンタイムが重み付けされて最終的な評価値になるとしたら、その評価値をベースにした最小化を図るというアプローチもあるでしょう。サービスのアクセス傾向を基にピークタイムにサーバーリソースを増強するみたいなのはわかりやすい事例だとは思います。

まとめ

内容が割と発散的になってしまいましたが、セッションを聞いたり人と話した中で色々なアイデアが出てきました。まだ、綺麗にまとまったものではないですが、このカンファレンスで得た知見をSREとしての仕事に活かしていきたいですね。