SRE

SRE とは

SRE (Site Reliability Engineering) は、ソフトウェアエンジニアリングの手法でシステムの信頼性を高める実践である。Google の Benjamin Treynor Sloss が 2003 年に 7 人のエンジニアからなる本番運用チームを任されたところから始まり、書籍『Site Reliability Engineering』(オライリー・2016 年) として体系化された。原典は「ソフトウェアエンジニアに運用チームを設計させたら何が起きるか」という一文で自らを定義しており、運用を人手の作業ではなくソフトウェアで解く対象として扱う点が出発点にある。

この姿勢を制度として支えているのが作業時間の上限である。Google は SRE 全体の運用作業 (チケット対応・オンコール・手作業) に 50% の上限を置き、残りをシステムを改善するエンジニアリング作業に充てる。上限を決めずに「運用も自動化も担う」と宣言すると、障害対応が常に優先されて自動化は後回しになり続ける。DevOps との関係は、続編『The Site Reliability Workbook』(2018 年) の第 1 章が「class SRE implements interface DevOps」という表現で説明している。DevOps が掲げる考え方に対して、SRE はその実装の 1 つという位置づけだ。

SRE の核となる概念

SRE は SLI (サービスレベル指標: レイテンシ、エラー率)、SLO (サービスレベル目標: 99.9% の可用性)、エラーバジェット (SLO で許容される障害の量)、トイル (手動で繰り返す運用作業)、ポストモーテム (障害後の非難なしの振り返り) を核とする。

このうちトイルは「手作業が多い」だけでは判定できない。原典が挙げる特徴は、手動である・繰り返しである・自動化できる・戦術的で受動的である・恒久的な価値を生まない・サービスの成長に比例して増える、の 6 つである。最後の 1 つが要点で、利用者が 2 倍になれば作業量も 2 倍になる性質の作業は、放置すれば人を増やし続けるしかなくなる。逆に、繰り返しでも量が増えない作業や、判断が必要で自動化できない作業はトイルとは呼ばない。

SLI / SLO / SLA

3 つの違いは「測る」「自分で決める」「相手と約束する」のどこに位置するかである。

概念	定義	例
SLI	測定可能な指標	P99 レイテンシ、エラー率
SLO	内部目標	P99 < 500ms、可用性 99.9%
SLA	顧客との契約	可用性 99.9%、違反時に返金

内部の SLO は顧客へ示す SLA より厳しく設定する。原典も、公表する値は保守的にし、内部目標を締めておくことで慢性的な問題に対応する余地が生まれるとしている。SLA を 99.9% と約束するなら内部 SLO は 99.95% に置く、といった具合だ。逆にすると、内部目標を割った時点で契約違反が確定していて、手を打つ時間が残らない。

エラーバジェットの運用

エラーバジェットは 100% から SLO を引いた残りである。SLO が 99.9% なら 30 日 (43,200 分) の 0.1% にあたる約 43 分が、その月に使ってよい停止時間になる。この数字があると、信頼性と開発速度のどちらを取るかという議論を、その場の力関係ではなく事前の合意で裁けるようになる。

SLO: 99.9% → エラーバジェット: 月 43 分

バジェット残り > 50%: 新機能を積極的にリリース
バジェット残り < 25%: 信頼性改善を優先
バジェット = 0%: 機能リリースを凍結

図の残量の閾値は運用例であり、原典が定めた数値ではない。どの水準で機能リリースを止めるかを事前に文書化しておくこと自体が本質である。

そもそも SLO を 100% に置くとエラーバジェットは 0 になり、この仕組みは動かない。原典も、SLO を常に 100% 満たすという要求は非現実的で望ましくもなく、過度に保守的な作りや開発速度の低下を招くと述べている。逆に SLO を大きく上回り続けるのも問題で、利用者が現在の性能を前提にしてしまう。Google の Chubby では、この依存を断つために計画的な停止をあえて設けた例が紹介されている。

トイルの削減

手動デプロイは CI/CD パイプラインに、手動スケーリングは Auto Scaling に、手動アラート対応はランブックの自動化 (SSM) に、手動証明書更新は ACM の自動更新に置き換える。

原典が置く目標は、各 SRE の時間の少なくとも 50% をエンジニアリング作業に充て、トイルを 50% 未満に保つことである。トイルが半分を超える状態が続くなら、自動化が追いついていないか、そもそも人手で支える設計になっている。感覚で判断すると必ず過小評価になるので、オンコール対応やチケット処理にかけた時間を記録して比率を出すところから始めたい。

サーバーレスと SRE

サーバーレスではサーバーの監視やパッチ適用、スケーリングの手当てが基盤側へ移るため、SRE はアプリケーションの信頼性に注力しやすくなる。ただし信頼性の管理そのものが消えるわけではない。SLI と SLO は引き続き自分で定義する必要があり、同時実行数などのクォータ、コールドスタートによるレイテンシの分布、マネージドサービス自体の障害は、自分では直せない依存として残る。運用の対象がサーバーの世話から依存先の挙動の把握へ移ったと捉えるほうが実態に近い。

ポストモーテム

ポストモーテムに書く項目は次の 4 つで、並び順にも意味がある。

1. タイムライン: 何が起きたか
2. 影響: ユーザーへの影響
3. 根本原因: なぜ起きたか
4. アクションアイテム: 再発防止策
→ 非難なし (Blameless) が原則

非難なしを原則にするのは、担当者への配慮というより事実を集めるためである。責任追及の場になると、当事者は判断の過程や見落としを語らなくなり、再発防止に必要な情報が出てこない。原因を人ではなく仕組みの側に置き、同じ操作をした別の人でも同じ結果になったはずだと考える。アクションアイテムには担当と期限を付ける。付けずに公開したポストモーテムは、次の障害の予告になる。

導入でよく失敗するのは 2 つの型である。1 つは運用チームの名前を SRE に変えただけで、作業時間の上限を設けずに従来の運用を続ける型。もう 1 つは SLO を実質 100% に置き、エラーバジェットが常に枯渇して判断材料にならない型である。どちらも、信頼性の目標を数字で決めて開発側と運用側の合意を作る、という中心が抜けている。