SREとは？インフラ運用との違いを、障害対応の具体例で理解する

SRE（Site Reliability Engineering）は、ソフトウェアの開発やシステムの設計を通じて、サービスの信頼性を継続的に改善する取り組みです。その仕事を担う職種もSREと呼ばれます。障害を復旧させる力に加え、同じ問題が繰り返されにくい仕組みを作る力が求められます。

インフラの監視や障害対応を経験しているなら、その経験は出発点になります。求人の「SRE」という肩書きを理解するには、担当する製品名よりも、復旧後にどこまで改善できる仕事なのかを見ると具体像をつかめます。

インフラ運用の経験は、SREの仕事につながる

GoogleのSREの解説では、運用をソフトウェアエンジニアリングの問題として捉えています。人が対応を続けるほど負担が増える状況を、設計やコードによって変えていく考え方です。

インフラエンジニアも自動化や設計改善を行いますし、SREも監視や障害対応を担います。両者の業務には重なりがあります。違いを見極めるには、信頼性の目標をどう決め、その達成に向けた改善を誰が継続して進めるのかを確認します。

たとえば、障害原因をネットワーク、OS、データベース、アプリケーションに切り分ける経験は、改善すべき場所を見つけるために使えます。復旧手順を熟知していれば、手作業のどこを安全に自動化できるか、どこに人の判断が必要かも検討できます。

毎週、同じ障害で呼び出されるとしたら

ここからは説明用の架空の例です。毎週月曜の夜、バッチ処理とWebサービスのアクセスが重なると、データベースへの接続が足りなくなり、商品検索が失敗するシステムを考えます。担当者は呼び出しを受け、バッチを止めて復旧させています。

障害中は利用者への影響を抑えることが先です。安全を確認した手順で負荷を下げ、検索が戻ったことを確かめます。そのうえで翌週の再発を防ぐには、発生時刻、接続数、処理時間、直前の変更などから原因を追う必要があります。

調査によってバッチの同時実行数が原因だと確認できたなら、実行数を制限し、検索への影響を負荷試験で確かめる案が考えられます。変更後も、本番で検索の失敗が減ったか、バッチが必要な時刻までに終わるかを確認します。接続上限だけを増やすと、今度はデータベースの負荷が問題になる可能性もあるため、測定して選ぶ必要があります。

この例で成果として残るのは、翌週も使う停止手順だけでなく、問題を起こしにくくした設定やコード、その効果を確かめる測定です。開発チームと一緒にアプリケーションを直すこともあれば、実行基盤や運用設計を変えることもあります。

繰り返す手作業を減らす「トイル削減」

毎週同じ通知を受け、同じ操作で元に戻す作業は、SREでいう「トイル」を考える例になります。Googleは、反復的で自動化でき、サービスの成長とともに増えやすい運用作業などをトイルの特徴として挙げています。

初めての障害を調べることや、長く使える改善を設計することまで、まとめて無駄と呼ぶ言葉ではありません。この例なら、停止操作を自動化する案と、停止自体が不要になるよう処理を変える案を比べます。自動化にも保守が必要なので、なくせる作業を先に探すと選択肢が広がります。

「どこまで安定させるか」を利用者の操作から決める

改善の候補は一つとは限りません。検索の失敗を減らすことと、画面を速くすることのどちらに時間を使うか。その判断には、利用者にとって必要な品質を測る指標と目標が役立ちます。

SLIはサービスの品質を測る指標、SLOはその目標です。先ほどの検索サービスなら、次のような設定が考えられます。数値は仕組みを説明するための仮定であり、推奨値ではありません。

用語	この例での意味
SLI	測定対象の検索リクエストのうち、正常な結果を返せた割合
SLO	直近28日間で、その割合を99.9%以上にする目標
エラーバジェット	目標を守る範囲で許容する失敗の割合。この例では0.1%

対象が10万リクエストなら、この目標で許容する失敗は100件です。ただし、何を対象に数えるかで結果は変わります。アプリケーションまで到達しなかった失敗を除外してしまうと、利用者が検索できない状態を見落としかねません。成功の条件、測定場所、除外するリクエストは目標と一緒に決めます。

GoogleのSLO実践ガイドは、利用者に適した目標について関係者が合意し、改善の優先順位に使うことを重視しています。目標の未達が続くときに信頼性改善へ時間を振り向けるなど、測定結果から何を変えるかまで開発側やプロダクト責任者と決めておく必要があります。

先ほどの障害なら、検索の失敗が目標を脅かしていることを示せれば、バッチ改修に時間を使う理由を説明できます。サーバーが動いているかという監視に、利用者が検索できたかという判断が加わります。

求人では、改善する範囲とチームの役割を読む

SREという職種名が同じでも、求められる仕事の範囲は募集ごとに確認が必要です。2026年9月18日に確認した国内企業の公式採用ページには、次の例があります。

KINTOテクノロジーズのSRE募集は、プロダクトチームへの伴走と、複数プロダクトで使う仕組みの設計を挙げています。SLOを起点とする運用設計や、他組織への導入支援も業務に含まれます。技術的な改善を、複数チームへ展開する役割まで読む必要がある例です。

GENEROSITYのSRE募集は、クラウドインフラの設計・構築・運用を中心に、監視、CI/CD、コスト最適化やセキュリティ管理を挙げています。こちらは基盤を作り、日々動かして改善する経験との接点を見つけやすい内容です。

いずれも正社員の募集例です。業務委託で受けられることや、国内のSRE全体の傾向を示すものではありません。応募時には最新の募集内容を確認してください。

なお、隣接する「DevOps」は開発と運用の協働を促す考え方です。GoogleはSREをその具体的な実践の一つとして説明しています。DevOpsとSREを完全に別の仕事として分けるより、誰がどの責任を持つ組織なのかを読むほうが、募集の理解に役立ちます。

自分の経験を、改善の前後で説明する

これまでの仕事を振り返るなら、使ったツールの一覧に、何がどう変わったかを一つ添えてみてください。インフラ運用の経験者なら、頻発する障害を調査し、設定変更や自動化につなげた経験が候補になります。バックエンド開発の経験者なら、処理の遅延や失敗を測り、コードやデータベースの使い方を改善した経験が候補です。

「監視を担当した」から一歩進めて、どんな異常を検知できず困っていたのか、何を測るように変えたのか、変更後にどう確かめたのかを説明します。実測していない削減率や件数を補う必要はありません。確認できた変化と、まだ分からないことを分けるだけでも、判断の過程が伝わります。

経験が足りないと感じる場合は、繰り返し発生する作業を一つ選び、発生条件、対応時間、改善案、効果の確かめ方を書き出すところから始められます。検証環境で変更を試し、レビューを受ける経験を積めば、運用の知識を設計やコードへつなげられます。

応募や参画の前には、その改善を実行できる体制かも確かめたいところです。

• 夜間・休日の呼び出しは誰が担当し、頻度や交代体制はどうなっているか。
• 障害対応の後、再発防止を進める時間と担当者が確保されているか。
• 信頼性の目標や改善の優先順位を、誰と決めるのか。
• アプリケーションや基盤を変更するとき、どこまで担当し、誰のレビューを受けるのか。

フリーランスとして参画する場合も、募集文の技術名に加えて、この担当範囲を照合すると経験との接点を探せます。現在掲載中の案件を見るときは、運用対応と改善開発のどちらが期待されているか、募集文で分からない点を面談で確認する材料にしてください。