今年2月から、ソフトウェアエンジニアからインフラに転身しましたゆるふわヒーラーです🦥
直近の動きとしては、Terraformに静的解析やAIレビューを導入し、開発チーム側でもインフラを構築できるようにするなど、プラットフォームエンジニアリング的なことをしています。
そんな中、今まさに開催されているSRE NEXT 2026のDay1に参加してきました！
今回参加した理由としては、自分自身もSRE的なことをやっていると勝手に思い込んでいたからでした。
正直SREをよくわかっていないのに、「SREもやってるよ」とか周りに言っていたかもしれません。
そのレベルの人間ですが、各セッションはすごく共感できるものが多かったです。
ただ、同時にわからないものもたくさんありました。
「あ〜わかるわかる」☺️
「ん、わからん（えらーばじぇっと？といる？）」🤔
「わかるー」☺️
「ん、わからん（ぽすともーてむ？）」🤔
私があまりわかっていないということは、SREで言われる「プロダクトの目標値（SLO）」を各プロジェクトと合意しようとした時に、上手くできなさそうです。
Day2に参加する前に、基礎的な単語を理解しておこうと思います。
指標・予算に関する単語（SLI / SLO / エラーバジェット）
この3つはすべてセットで捉えるものです。
SLI（Service Level Indicator：サービスレベル指標）
システムの健康状態を測るための「ものさし」 です。
具体的には「リクエストの成功率（%）」や「レスポンスが返ってくるまでの時間（ミリ秒）」など、測定可能な具体的な数値を指します。
何を監視すればいいか迷った場合は、Googleが推奨する 「4つのゴールデンシグナル（レイテンシ、トラフィック、エラー、サチュレーション）」 をまず設定するのが基本のようです。
SLO（Service Level Objective：サービスレベル目標）
インフラ（SRE）側と、各プロダクトの開発チーム（プロジェクト側） で合意した、システムの 「目標値（合格ライン）」 です。
「過去30日間で、SLI（成功率）を99.9%以上に保つ」といった設定をします。
100%を目指さないのがSREの前提 となります。
エラーバジェット（Error Budget：エラーの予算）
システムが 「これくらいなら失敗してもいい」という許容量 です。
計算式としては「100% - SLO」で、SLOが99.9%の場合、エラーバジェットは0.1%になります。
この予算が残っているうちは新機能のリリースなど 攻めの挑戦 ができますが、障害が多発して予算がゼロになったら、新規リリースを止めてシステムの 安定化（守り）に全力 を出すという、チームの行動指針になります。
業務・文化に関する単語（トイル / ポストモーテム）
トイル（Toil：労力）
サービスが成長するほど増えていく、「手作業で、繰り返しの、自動化可能な、頭をあまり使わない作業」 です。
毎回手動で行うアカウント発行や、定型的なアラート対応などが該当します。
エンジニアリングで自動化できるはずなのに手作業でやっている不毛な仕事を指し、SREはこれを減らすことが役割 となります。
ただし、いきなりすべてを自動化するのではなく、コストとベネフィットで判断した方が良さそうです。
ポストモーテム（Post-Mortem：事後検証）
障害が起きた後に作成する、「原因究明と再発防止のためのレポート」 です。
SREでは必ず「Blameless（非難なき）」という姿勢で行われます。
ミスをした人を責めるのではなく、「なぜシステムはそのミスを防げなかったのか？」という仕組みの課題に焦点を当て て改善を考えます。
現時点の理解まとめ
調べてみて、現時点では以下のように理解しました。
まず対象プロダクトの指標（SLI） を決めて計測し、それを元に目標値（SLO） を決める。
決めたSLOをベースに各プロジェクトと合意形成する。
SLOを維持できている（エラーバジェットがある） 限りは攻めの挑戦を行い、超えてしまった場合は守りに徹する。
不毛な作業（Toil） は極力自動化するが、コストも見極める。
障害が起きたときは人を非難せず（ブレイムレス） 、仕組みの課題を解決するために事後検証（ポストモーテム） を行う。
とりあえず付け焼き刃で身につけた知識ですが、これでDay2も楽しめそうです！
この記事を投稿したら出発しようと思います。
おまけ
けろぺんの由来ってなんだろう？