SRE とは サイトリライアビリティエンジニアリング入門
要約
SRE は、信頼性の目標を数字で決め、その数字で機能開発と安定化のどちらを優先するかを決める考え方です。個人開発では、ヘルスチェック、SLO一つ、burn rateによる通知の三つから始めれば十分です。エラーバジェットの考え方を使えば、リリース速度と安定性の議論を感覚ではなく数字で進められます。
個人開発のアプリが落ちたとき、最初に気づくのはたいてい利用者からのメールです。「動いている」の基準が決まっていないと、確認できるのは感覚だけになります。このガイドでは SRE とは サイトリライアビリティエンジニアリング の考え方を、一人で回せる規模まで縮めて説明します。
SRE は運用を「数字」で決めるという考え方
出発点は Google の SRE 本の導入部 です。SRE は、ソフトウェアエンジニアに運用チームを設計させたら何が生まれるか、という問いへの答えだとされています。人が手作業でサーバーを再起動する代わりに、それをやるコードを書き、結果を測ります。
本では三つの考え方が中心になっています。信頼性は「なんとなく良い」ではなく、目標を持つ機能であること。繰り返しの手作業（本では toil と呼ばれます）は、自動化すべきバグであること。そして障害は起きるものとして、責任追及ではなく学びに変えること。
DevOps と SRE は重なる部分が多いです。実務上の違いを挙げるなら、DevOps はコードを作る人と動かす人を一緒にする文化で、SRE はその議論を数字で行うための具体的な道具を与えてくれます。数字を使うのに、陣営を選ぶ必要はありません。
SLI、SLO、SLA: 3つの言葉を一つずつ整理する
SLI（Service Level Indicator）は測るものです。Web アプリなら、成功したリクエストの割合や、300 ms 以内に応答した割合が一般的です。指標は一つか二つに絞ります。十個も追うと、どれも見なくなります。
SLO（Service Level Objective）は、その指標に置く目標値です。「30日間で成功率 99.9%」のように書きます。これは社内向けで、自分への約束です。
SLA（Service Level Agreement）は顧客との契約で、達成できなければ返金などが伴うことがほとんどです。稼働率に対してお金を払ってくれる顧客がいないなら、まだ SLA は存在しません。料金ページのコピーに間違って書かないようにしましょう。
エラーバジェット: 開発速度と安定性の折り合いをつける
エラーバジェットは、100% から SLO を引いたものです。30日で 99.9% の目標なら、許容される停止時間は約43分です。この余白を、リスクのあるデプロイ、移行、実験に使えます。
大事なのは、そこに紐づくルールです。予算が残っている間は出荷します。予算を使い切ったら、機能の出荷を止めて、信頼性が回復するまで直します。SRE 本のリスクの章は、「速く動きたい」と「壊したくない」の議論を、交渉ではなく共有された数字で決める方法として説明しています。
もう一つ、繰り返す価値のある指摘があります。100% は、ほぼ正しい目標になりません。不安定なモバイル回線で使っている利用者は、99.99% と 99.9% の違いを体感できません。そして9が一つ増えるごとに、コストは大きく跳ね上がります。完璧な目標ではありませんが、運用できる目標です。
指標の選び方と最初の目標の書き方を具体的に知りたい場合は、SRE workbook の SLO 実装の章が最も実用的で、短くまとまっています。
SRE の一日と、フィーチャーフラグという道具
大企業の SRE は、オンコール、インシデント対応、キャパシティ計画、自動化の作業に時間を分けています。Google の本では、運用作業の負荷を技術者の時間の半分程度に抑えるよう書かれています。残りはエンジニアリングに回すためです。この上限は、あれば良いものではなく、設計上の制約です。
日常の仕事は、おおむね次のようなものです。
プロダクトチームと SLO を決め、予算の消費速度でアラートを出す（一回ごとのエラーには反応しない）
オンコールの当番を回し、深夜3時の通知にチェックリストで対応できるよう runbook を書く
インシデント対応を率いて、責任追及をしない振り返りを書く
三回以上手作業でやったことは自動化する
本番に出る前に、リリースの信頼性リスクをレビューする
フィーチャーフラグは、この考え方をよく表す道具です。フラグがあれば、悪いリリースを再デプロイなしで数秒で止められ、エラーバジェットを守れます。ホストされたツールが必要かどうかは、フラグの数によります。最初の三つ程度なら、環境変数で十分です。
一人で作っているなら SRE は必要か
やる理由は三つ、やらない理由は一つです。
やる理由: 自分のプロジェクトでも、いずれ深夜に呼び出されます。目標を書いておけば、過剰な設計を止められます。そして「SLO を決めて本番を運用している」と言えることは、誰かが開発者を雇うか信頼するかを決めるときに効きます。
やらない理由: まだ利用者がいないなら、起きていない問題への練習になります。まず作り、誰かが頼り始めたら測りましょう。
だから、フルセットの仕組みは要りません。趣味のアプリに監視サービスを契約する必要も、真面目に見せるために Kubernetes を動かす必要もありません。実際の利用者が10人でもいるなら、ヘルスチェック、SLO 一つ、壊れたときに見る場所。この三つは作る価値があります。
一晩でできる最小構成と、通知の設計
ここからは、1万ユーザー程度でも持ちこたえそうな最小構成を紹介します。作業は一晩で終わります。テスト済み。最適ではない。それでもこの構成を使う理由は、退屈で、退屈なものは生き残るからです。
まず SLI を一つ選びます。HTTP リクエストのうち、5xx 以外を返した割合です。次に SLO を30日で 99.5% に置きます。これは約3.6時間分の予算になります。最初は緩くして、後で締めれば十分です。最後に、実際に壊れる箇所を見る本物のヘルスエンドポイントに対して、外部の死活監視を設定します。
ヘルスチェックは、プロセスが生きているかだけでなく、実際に壊れる要素を確認するべきです。
// GET /healthz
app.get("/healthz", async (req, res) => {
try {
await db.query("select 1"); // DB に届くか
await cache.ping(); // キャッシュに届くか
res.status(200).json({ ok: true });
} catch (err) {
res.status(503).json({ ok: false });
}
});通知は、メールの受信箱ではなく、スマホのプッシュ通知で確実に目に入る場所へ送ります。そして障害のたびに、postmortems.md というプレーンテキストに四行を追加します。何が起きたか、なぜ、どれくらい続いたか、何を変えるか。このファイルは、あなたが持つ信頼性の道具の中で最も過小評価されているものです。
通知の設計で大事なのは、単発のエラーに反応しないことです。よくある初心者のミスは、リクエストが一つ失敗するたびに自分を呼び出すことです。一週間でチャンネルをミュートすることになります。代わりに見るべきは burn rate、つまりエラーバジェットを消費する速さです。目標を期限ぴったりで使い切るペースと比べて、今どれくらい速く使っているかを示します。
個人開発なら、大雑把で十分です。直近10分のエラー率が5%を超えたらプッシュ通知を送り、週単位のエラー率が SLO を割りそうならメールで週次の要約を送ります。レベルは二つです。今すぐ起きるか、月曜に見るか。もっと凝った仕組みは、一段目の通知で利用者から苦情が来るようになってから考えれば十分です。
障害対応: AI に任せる部分と、人が決める部分
AI アシスタントは、トイルの側面でよく役立ちます。ヘルスチェックの作成、アップタイム監視用の Terraform、runbook の下書き、5xx 率を集計するログ解析スクリプトなどです。一方で、SLO を決めるのは苦手です。それはプロダクトの判断、つまり利用者がどこまで我慢できるかという問題だからです。
障害対応中は慎重になってください。もっともらしい修正案を提案されて、中身を読まずに深夜2時に本番へ適用してしまうことがあります。AI は、スタックトレースの説明や、障害後の振り返りの下書きに使い、ロールバックの判断は起きている人間が持ちましょう。
コード品質のゲートも、この全体像に含まれます。多くの障害は、レビューでは無害に見えた変更に行き着きます。CI の静的解析で信頼性が手に入るわけではありませんが、予算を使う前に、初歩的なミスの一群を減らせます。
振り返り（ポストモーテム）は、短く、責任追及をしない形で書きます。責任追及なし、は誰も責任を負わないという意味ではありません。どのシステムの仕組みがミスを許したのかを問うことです。チームが自分一人のときは、これがより重要になります。落ち込んで、書くのを飛ばしたくなるからです。
見出しは四つで足ります。何が起きたか、なぜ起きたか、利用者が何時間影響を受けたか、何を変えるか。最後の項目には、実際にやると決めた行動を期日付きで書きます。「もっと注意する」は行動ではありません。「次のリリース前に、マイグレーションのステージング確認を追加する」が行動です。
一年続けると、そのファイルは自分の弱点の地図になります。同じ原因が二度目に出たら、自動化してください。証明書の期限切れで三回止まったときは、更新監視を追加するのに一晩かかりました。それ以来、再発していません。
SRE をキャリアにするなら、まず次に作るもの
SRE の仕事が向いているかは、何を楽しいと感じるかによります。システムや障害のパターン、自動化が好きな人に合います。通知を静かにすることに満足を感じるなら、きっと楽しめます。新機能をユーザーがクリックするのを見たい人には、あまり向かないでしょう。
入口は、たいていバックエンドかインフラの仕事です。サービスのデプロイとアラートを担当し始め、その信頼性を少しずつ引き受けていきます。持ち運べるスキルは、Linux の基礎、ネットワーク、一つのクラウドプロバイダー、監視スタック、そして書き残す習慣です。個人開発は、これらをすべて身につける場として適しています。開発チームの全員があなただからです。
ここまで読んだら、今すでに動かしているものを一つ選んでください。無料枠のアプリでも構いません。その SLI、SLO、そして予算を使い切ったときに取る具体的な行動を書き出します。止める作業が言えないなら、その数字は飾りです。あなたのプロジェクトのうち、利用者が教えてくれる前に落ちたと気づけるのはどれでしょうか。