SRE とは？

従来の運用エンジニアは手作業で監視・対応・メンテナンスをしていた。SREはソフトウェアエンジニアリングのスキルを使って運用業務を自動化する。繰り返しの手作業（トイル）を減らして、信頼性向上のためのシステム開発に時間を使う発想だよ。

SLI（Service Level Indicator）は「何を測るか」で、例えばリクエストの成功率やレスポンスタイム。SLO（Service Level Objective）は「どこまで許容するか」の目標値で、例えば「成功率99.9%以上」。SLA（Service Level Agreement）は顧客との契約上の約束。SLI→SLO→SLAの順に外向きになっていくイメージ。

「許容される障害量」のこと。SLOが99.9%なら、0.1%分は壊れてもいい。この0.1%がエラーバジェット。バジェットが残っていれば新機能リリースなどリスクのある変更ができる。使い切ったら信頼性回復を優先する。これで開発速度と安定性のバランスを数値で判断できる。

99.9%→99.99%にするコストは10倍以上かかることもある。しかもユーザーのネットワークやデバイスの信頼性がそれ以下なら、サーバー側だけ100%にしても意味がない。「ユーザー体験に必要十分な信頼性」を目標にして、残りのリソースを新機能開発に回す方が合理的、という考え方だね。

手動で繰り返す運用作業のこと。例えば手動でのサーバー再起動、アカウント作成、ログの目視確認、定型的なデプロイ作業など。Googleでは「SREの業務時間の50%以上をトイルに費やしてはいけない」というルールがある。残りの時間はトイルを自動化するコードを書くことに使う。

そんなことはない。SREの考え方は規模に関係なく使える。小さなチームでも「SLOを決めてエラーバジェットで判断する」「手作業を自動化する」は実践できる。専任のSREチームを持てなくても、開発チームがSREの原則を取り入れる「Embedded SRE」というアプローチもある。大事なのは役職名ではなく信頼性をエンジニアリングで解決する文化だよ。