基礎知識

SREとは何か。信頼性を技術で担保する考え方と実務

SREという役割が広く採用されるようになりました。運用担当と何が違うのか、何を目指す考え方なのか。この記事では、その中身を整理します。

SREとは何か

SRE（Site Reliability Engineering）は、システムの信頼性を、技術で担保するという考え方です。Googleが提唱し、広く採用されるようになりました。

従来の運用は、人手で監視し、問題が起きたら対処する形でした。SREは、運用の課題をソフトウェアで解決するという発想に立ちます。

具体的には、手作業を自動化し、監視の仕組みを作り、障害が起きにくい構成を設計することが中心になります。

従来の運用担当との違いは、コードを書くことです。設定作業ではなく、仕組みそのものを作ります。

SLOという考え方

SREの中心にある概念が、目標値の設定です。

SLIは測る指標です。稼働率、応答時間、成功率など。

SLOはその目標値です。「稼働率99.9%」のように定めます。

重要なのは、100%を目指さないことです。完全な安定を求めると、費用が無限に増え、変更もできなくなります。

エラーバジェットという考え方があります。SLOが99.9%なら、0.1%は許容される。この余裕の範囲で、新機能の投入や変更を行うという運用です。

余裕を使い切ったら、安定化を優先する。開発と運用の対立を、数字で調停する仕組みだと言えます。

手作業を減らす

SREでは、繰り返しの手作業をトイルと呼び、削減の対象とします。

対象となるのは、手動で、繰り返しがあり、自動化でき、価値を生まない作業です。定期的な再起動、ログの確認、証明書の更新など。

削減の方法は自動化です。スクリプトを書き、監視から自動で対処する仕組みを作ります。

Googleでは、運用作業の割合に上限を設けるという運用が知られています。上限を超えたら、改善に時間を割く。

この考え方は、規模の小さい組織でも有効です。手作業が増え続ける状態は、いずれ限界を迎えます。

障害への向き合い方

SREの特徴的な考え方に、個人を責めない振り返りがあります。

障害が起きたとき、「誰がミスしたか」ではなく「なぜその操作が可能だったか」を問います。

人は必ず誤ります。誤りが起きたときに被害が出る構造のほうが問題だ、という立場です。

実務的な効果は、情報が出てくることです。責められる文化では、担当者が事実を隠します。原因が分からなければ、再発も防げません。

振り返りでは、時系列、影響範囲、原因、再発防止策を記録します。この記録が蓄積されることで、組織の学習になります。

求められるスキル

SREとして働くために必要なものを整理します。

• インフラの知識／サーバー、ネットワーク、クラウド。土台になる
• プログラミング／自動化のためのコード。PythonやGoが多い
• 監視の設計／何を測り、どの閾値で通知するか
• 構成管理／IaC。環境をコードで再現できる状態にする
• 障害対応／切り分けの手順、影響の判断

従来の運用担当から移行する場合、2つ目が課題になります。設定はできてもコードが書けない、という状態からの脱却が必要です。

開発者から移行する場合、1つ目が課題です。コードは書けても、ネットワークやサーバーの理解が浅い場合があります。

組織としての導入

SREを取り入れる場合の現実的な進め方を示します。

名称を変えるだけでは意味がありません。運用担当をSREと呼び替えただけの例は珍しくありません。

最初に着手すべきは、指標の設定です。何を安定と呼ぶのかを定義しないと、判断ができません。

次に、手作業の可視化。どの作業にどれだけ時間を使っているかを記録します。

そのうえで、自動化する時間を確保します。運用に追われたままでは、改善が始まりません。時間を確保する意思決定が、最も重要な一歩になります。

この役割の価値

最後に、なぜこの役割の需要が高いのかを整理します。

システムが止まる影響が大きくなったためです。24時間動くサービスが増え、停止が直接的な損失になります。

構成が複雑になったことも要因です。クラウド、コンテナ、複数のサービスの連携。手作業では管理できない規模になっています。

開発の速度を落とさずに安定させるという要求も強まりました。従来は、安定と変更の速さは相反するものでした。SREはこれを両立させる方法論です。

単価は月額75〜120万円の範囲が中心で、扱える人材が限られる領域です。この数字は民間各社の集計で、公的統計ではありません。

小規模組織での実践

SREは大企業の話に見えますが、規模が小さくても取り入れられます。

専任を置く必要はありません。開発担当が一部の時間を運用改善に充てる形でも成立します。

まず着手すべきは、繰り返しの手作業を1つ自動化することです。効果が見えれば、次の投資も判断しやすくなります。

指標も単純なもので足ります。「サービスが使えているか」を測る監視が1つあれば、出発点になります。

記録を残す習慣も、費用がかかりません。障害が起きたら、時系列と原因を書く。それだけで組織の学習が始まります。

完全な形を目指すより、1つずつ積み上げるのが現実的です。

開発チームとの関係

SREが機能するかどうかは、開発側との関係で決まります。

対立が生じやすい構造があります。開発は変更を出したい、運用は安定させたい。目的が相反して見えます。

エラーバジェットは、この対立を数字で調停する仕組みです。余裕がある間は変更を優先し、使い切ったら安定化を優先する。感情ではなく数字で判断できます。

もう1つの方法が、責任の共有です。開発した機能の運用にも、開発側が関わる。障害の連絡を開発者も受ける。

運用を別組織に切り離すと、作る側に品質の動機が働きにくくなります。この構造をどう避けるかが、組織設計の要点になります。