コトラ（広報チーム） 
SREは、サービスを安定して提供しながら、開発や改善のスピードも高めるための考え方と実践方法です。インフラ、クラウド、プログラミング、監視など幅広い知識が関わるため、未経験者は「何から学ぶべきか」と迷いやすい領域でもあります。
本記事では、SREの役割とインフラエンジニアとの違いを整理したうえで、未経験から優先して身に付けたいスキル、実務で信頼性を高める考え方、経験別の生かし方を解説します。
SREとは何か：役割とインフラエンジニアとの違い
SREが目指すサービスの信頼性と開発速度の両立
SREはSite Reliability Engineeringの略で、日本語では「サイト信頼性エンジニアリング」と呼ばれます。Googleが提唱した、ソフトウェア開発の考え方を運用に取り入れる方法論です。
SREが目指すのは、単にシステムを止めないことではありません。利用者が必要なときにサービスを使え、十分な速さで操作でき、新機能も安全に届けられる状態を継続することです。そのため、安定性を優先して変更を抑え込むのではなく、変更によるリスクを把握し、自動化や監視を整えながら開発速度とのバランスを取ります。
SREの主な業務：監視・障害対応・自動化・改善
SREの業務は、サービスの状況を把握し、問題に対応し、同じ問題を繰り返さない仕組みを作ることにあります。代表的な業務は以下の通りです。
- システムの状態を把握する監視やログ収集の整備
- 障害発生時の復旧対応と関係者への情報共有
- 障害原因の分析と再発防止策の実施
- 繰り返し発生する手作業の自動化
- リリース手順やテストの改善
- 将来の利用増加を見据えた性能と容量の見直し
- アクセス権限や脆弱性など、セキュリティ面の確認
重要なのは、障害対応だけに追われないことです。障害を復旧した後に、監視、設計、手順、自動化のどこを変えれば再発しにくくなるかを考え、継続的に改善します。
インフラエンジニアとSREの役割・仕事の進め方の違い
インフラエンジニアは、サーバー、ネットワーク、データベース、クラウド環境など、システムの土台を設計、構築、運用する役割です。一方のSREは、インフラに加え、アプリケーション、開発プロセス、利用者への影響も含めて、サービス全体の信頼性を改善します。
両者の境界は企業やチームによって異なりますが、SREにはプログラミングや自動化の比重が高い傾向があります。手順に沿って運用するだけでなく、手順そのものをコード化し、再現しやすく、間違いにくい形へ変えていくことが求められます。
また、インフラエンジニアが安定稼働の維持を中心に担うのに対し、SREは開発チームと協力し、安全なリリースや性能改善を進めます。運用と開発を分けるのではなく、共通の目標に向けて連携する点が特徴です。
未経験者がSREを目指す前に理解したい前提
SREは幅広い知識が必要なため、完全な未経験者が最初から担当するには難易度が高い職種です。まずはインフラ運用、クラウド構築、バックエンド開発、テスト、社内システム運用などで基礎的な実務経験を積み、そこから信頼性や自動化の領域を広げる進み方が現実的です。
ただし、未経験の段階からSREの考え方を学ぶことには意味があります。サービスがどのように動き、どこで止まり、どうすれば早く気付けるかを意識して学習すれば、インフラや開発の基礎学習にも目的が生まれます。
SREに必要なスキルの全体像
必須スキルとあると有利なスキルの違い
SREに必要なスキルは多岐にわたりますが、すべてを同時に習得する必要はありません。まず必要なのは、システムの基本構造を理解し、小さな運用作業を安全に行える力です。その後、クラウド、自動化、監視、障害対応を実践的に身に付けていきます。
必須となりやすいのは、Linux、ネットワーク、データベース、クラウド、プログラミング、監視に関する基礎です。一方で、コンテナ、Kubernetes、Infrastructure as Code、CI/CD、分散システムの深い知識は、担当するサービスの構成によって重要度が変わります。
システムの基礎：Linux・ネットワーク・データベース
SREは、問題が発生した場所を切り分ける必要があります。そのため、OS、ネットワーク、データベース、Webサーバー、アプリケーションがどのようにつながっているかを理解することが重要です。
Linuxでは、ファイル、プロセス、メモリ、ディスク、権限、ログを扱う基本操作を身に付けます。ネットワークでは、IPアドレス、DNS、HTTP、HTTPS、TCP、負荷分散の役割を理解します。データベースでは、データの保存方法、SQL、インデックス、接続数、バックアップと復元の基本を押さえます。
クラウド環境を構築・運用するスキル
多くのWebサービスでは、クラウド環境が利用されています。SREには、仮想サーバー、ストレージ、ネットワーク、アクセス権限、監視などをクラウド上で設定し、運用する力が必要です。
特定のサービス名を暗記するよりも、ネットワークを分ける理由、アクセス権限を最小限にする理由、障害に備えて複数の場所に配置する理由を理解することが重要です。クラウドは操作が容易に見える一方、設定ミスが障害や情報漏えいにつながるため、設計意図を説明できるレベルを目指します。
プログラミングと自動化のスキル
SREでは、繰り返し作業を減らし、設定や手順を再現可能にするためにプログラミングを使います。最初はPythonやシェルスクリプトで、ファイル処理、ログ集計、APIの呼び出し、定期作業の自動化を行えるようになると実務に役立ちます。
大規模なツール開発ができることよりも、手作業の課題を見つけ、処理の流れを整理し、安全に自動化する力が重要です。コードを読む力も必要です。障害時には、アプリケーションの変更内容やエラー処理を確認する場面があるためです。
監視・障害対応・セキュリティに関するスキル
監視では、CPU使用率などの機器の状態だけでなく、利用者がサービスを正常に使えているかを確認します。エラー率、応答時間、成功率、処理件数などを組み合わせて見ることが重要です。
障害対応では、状況を正確に把握し、影響を小さくし、関係者に分かりやすく伝える力が求められます。セキュリティでは、アクセス権限、認証、暗号化、脆弱性への対応、ログの保全といった基本を理解し、信頼性と安全性を両立させます。
最優先で身に付けるべき基礎スキル
Linuxの基本操作とサーバーの仕組み
SREを目指すなら、Linuxの基本操作を優先して学びます。ディレクトリやファイルの操作、権限の確認、プロセスの停止、ログの閲覧、ディスク使用量の確認などは、障害対応や日常運用の基礎になります。
あわせて、サーバーではアプリケーションがプロセスとして動き、メモリやCPU、ディスク、ネットワークを使っていることを理解しましょう。例えば、応答が遅い原因は、CPU不足だけでなく、メモリ不足、ディスク入出力の遅延、外部サービスへの接続待ちなどにもあります。
Webサービスの流れを理解するネットワークの基礎
Webサービスでは、利用者のブラウザやアプリからの要求がネットワークを通り、サーバー、アプリケーション、データベースへ届きます。この一連の流れを理解することが、障害の切り分けにつながります。
特に、DNSが名前から接続先を探す仕組み、HTTPがWeb通信のルールであること、HTTPSが通信を暗号化すること、ロードバランサーがアクセスを複数のサーバーへ分散することは、早い段階で押さえたい知識です。
データベース・Webサーバー・アプリケーションの基礎
Webサービスは、Webサーバーが要求を受け取り、アプリケーションが処理し、データベースに保存された情報を参照・更新する構造が一般的です。各部分の役割を理解すると、エラーや遅延が起きたときに確認すべき場所を考えやすくなります。
データベースについては、SQLでデータを検索、登録、更新できることに加え、遅い検索がサービス全体の遅延につながることを理解します。アプリケーションについては、入力を受け取り、処理し、外部サービスやデータベースと連携して結果を返す流れを把握します。
クラウドサービスの基本的な使い方
クラウド学習では、仮想サーバーを作成するだけでなく、ネットワーク、アクセス権限、ストレージ、監視、バックアップを一連で扱うことが大切です。公開したサーバーに誰が接続できるか、データをどこに保存するか、障害時にどう復元するかを考えながら構築します。
最初は一つのクラウドを選び、基本サービスを実際に操作する方法がおすすめです。複数のクラウドに手を広げるよりも、基本的な設計判断を説明できることを優先します。
Pythonやシェルスクリプトによる簡単な自動化
未経験者は、日常的な作業を題材にして自動化を学ぶと効果的です。例えば、指定したディレクトリの容量を確認する、ログから特定のエラーを数える、定期的にAPIの応答を確認する、といった処理です。
自動化では、正常時だけでなく、失敗時にどう知らせるかも考えます。実行結果を記録する、エラーを表示する、処理対象を誤らないよう確認するなど、安全性を意識した作り方がSREの実務につながります。
SREの実務で求められる信頼性を高めるスキル
サービスの状態を測る指標と目標値を決める考え方
SREでは、サービスの品質を感覚だけで判断せず、数値で把握します。代表的な考え方として、SLI、SLO、SLAがあります。
- SLIは、サービスの状態を測る指標です。成功率、応答時間、エラー率などが該当します。
- SLOは、チームが目指す目標値です。例えば、一定期間における成功率や応答時間の目標を定めます。
- SLAは、利用者や顧客との契約上の水準です。未達の場合の対応が定められることもあります。
良い指標は、利用者の体験と結び付いています。サーバーのCPU使用率だけでは、利用者が購入や検索を正常に完了できたかは分かりません。重要な操作が成功した割合や、その操作に必要な時間を測ることが重要です。
監視とログの整備で異常に早く気付く方法
監視は、異常を検知するだけでなく、原因を調べやすくするために整備します。メトリクス、ログ、トレースを組み合わせると、状況を多面的に確認できます。
メトリクスは数値の変化を見る情報です。ログは処理の記録です。トレースは、利用者からの一つの要求が複数のサービスをどう通過したかを追う情報です。これらがそろうと、「遅くなった」という事実から、「どの処理で時間がかかっているか」まで調べやすくなります。
通知は多すぎても機能しません。利用者への影響が大きく、対応が必要な事象を中心に通知を設定し、不要な通知は見直します。
障害対応の手順と原因を振り返る進め方
障害時は、まず利用者への影響を抑えることを優先します。状況の把握、影響範囲の確認、一時的な回避策、復旧作業、関係者への共有を落ち着いて進めるため、手順をあらかじめ整えておくことが重要です。
復旧後は、ポストモーテムと呼ばれる振り返りを行います。ここでは、個人を責めるのではなく、なぜ問題を防げなかったのか、なぜ発見が遅れたのか、なぜ復旧に時間がかかったのかを仕組みの観点で確認します。
振り返りでは、発生時刻、影響、原因、対応内容、再発防止策を記録します。手順書、監視、テスト、設計、権限管理などに改善を反映し、学びをチームに残すことが大切です。
手作業を減らす自動化と運用改善
繰り返し発生し、判断が少なく、手順が決まっている作業は自動化の候補です。手作業は時間がかかるだけでなく、担当者によるばらつきや操作ミスを生みやすいためです。
ただし、自動化そのものを目的にしてはいけません。まず作業の目的、入力、出力、例外時の対応を整理し、本当に必要な作業かを見直します。そのうえで、効果が大きく、失敗時の影響を管理しやすい作業から自動化します。
インフラ構成をコードで管理する方法や、テストからリリースまでを自動化する仕組みは、変更の再現性と安全性を高めるうえで有効です。
性能・容量・セキュリティを継続的に見直す方法
サービスは、利用者数、データ量、機能、外部連携の増加によって変化します。そのため、現在問題がない状態でも、将来に備えて性能と容量を確認する必要があります。
性能では、応答時間、処理件数、エラー率を継続的に確認します。容量では、CPU、メモリ、ディスク、データベース接続数、ネットワーク帯域などの増加傾向を見ます。急な利用増加に備え、必要なときに拡張できる仕組みも検討します。
セキュリティでは、不要な権限を残さないこと、利用していないアカウントを放置しないこと、更新プログラムを適切に適用すること、重要な操作を記録することが基本です。
技術以外に必要なSREのスキルと考え方
開発チームと運用チームの間をつなぐコミュニケーション
SREは、開発と運用のどちらか一方だけで完結する仕事ではありません。開発側には、どのような変更が信頼性に影響するかを伝えます。運用側には、なぜ変更が必要なのか、どのように安全性を確保するかを共有します。
技術用語を並べるだけでなく、利用者への影響、対応の優先順位、必要な判断を分かりやすく説明する力が求められます。障害時には、確定している事実と調査中の内容を分けて伝えることも重要です。
問題を個人の責任にせず仕組みとして改善する姿勢
障害や操作ミスが起きたとき、個人の注意不足だけを原因にすると、同じ問題を防げません。人は疲れ、急ぎ、判断を誤ることがあります。だからこそ、確認しやすい画面、承認の仕組み、自動テスト、段階的なリリース、分かりやすい手順書などで失敗しにくい環境を作ります。
個人を責めない振り返りは、責任を曖昧にすることではありません。事実に基づき、改善すべき仕組みを見つけ、次回の被害を減らすための姿勢です。
優先順位を付けて改善効果を見極める力
SREには改善すべき課題が多く集まります。しかし、すべてを同時に解決することはできません。利用者への影響、発生頻度、復旧にかかる時間、実施コスト、将来のリスクを踏まえて優先順位を付ける必要があります。
例えば、頻度は低くてもサービス停止につながる問題は優先度が高い場合があります。一方で、細かな手作業でも毎日多くの時間を使っているなら、自動化による効果が大きくなることがあります。データと現場の状況を踏まえて判断する力が重要です。
利用者や事業への影響から信頼性を考える視点
SREの信頼性は、技術指標だけで決まりません。利用者が重要な操作を完了できるか、事業にどの程度の影響が出るかという視点が必要です。
例えば、画面表示が少し遅いことと、決済や登録ができないことでは影響が異なります。サービスの中で特に重要な機能を把握し、その機能を優先して監視、改善、障害対応の対象にすることが、事業に役立つSREにつながります。
未経験からSREを目指す学習ロードマップ
ステップ1：IT・Webサービス・インフラの基礎を固める
最初に、Linux、ネットワーク、HTTP、DNS、データベース、Webアプリケーションの基本を学びます。用語を覚えるだけでなく、ブラウザからの要求がどのようにサーバーへ届き、アプリケーションとデータベースを経て応答が返るかを説明できる状態を目指します。
あわせて、Gitによるソースコード管理、基本的なコマンド操作、SQL、Pythonまたはシェルスクリプトも学びます。
ステップ2：クラウド上でWebサービスを構築する
次に、クラウド上で小規模なWebサービスを構築します。仮想サーバー、ネットワーク、アクセス権限、データベース、ストレージを使い、インターネットから安全にアクセスできる構成を作ります。
この段階では、構築した理由を記録することが重要です。なぜこのネットワーク設定にしたのか、なぜこの権限が必要なのか、障害時にどう復旧するのかを説明できるようにします。
ステップ3：監視・ログ収集・障害の再現を試す
サービスを作ったら、CPUやメモリだけでなく、応答時間、エラー率、アクセス数を確認できるようにします。アプリケーションのログも収集し、エラーが起きたときに原因を探せる状態にします。
さらに、意図的にサーバーを停止する、接続先を誤らせる、負荷をかけるなど、検証環境で障害を再現します。障害時に何が起きるか、どの情報があれば原因を特定しやすいかを体験することが有効です。
ステップ4：プログラムで定型作業を自動化する
手作業で行っている確認や集計を洗い出し、Pythonやシェルスクリプトで自動化します。例えば、ログからエラーを集計する、複数のURLの応答を確認する、バックアップ結果を確認する処理などが題材になります。
自動化した処理には、入力チェック、エラー時の終了、実行ログの記録を加えます。便利なスクリプトを作るだけでなく、他の人も安全に使える形に整えることが重要です。
ステップ5：成果物をまとめて実務で生かせる形にする
学習成果は、構成図、手順書、ソースコード、監視画面、障害対応の記録として整理します。何を作ったかだけではなく、どの課題に対して、どのように設計し、何を改善したかをまとめましょう。
成果物には、以下の内容を含めると実務とのつながりを示しやすくなります。
- 構築したサービスの全体構成
- 使用した技術と選定理由
- 監視する指標と通知条件
- 想定した障害と対応手順
- 自動化した作業と削減できる手間
- 今後の改善案と課題
今の経験をSREの実務に生かす方法
開発経験者が生かせるコード・リリース・性能改善の知識
開発経験者は、アプリケーションの構造、テスト、コードレビュー、リリース手順を理解している点が強みです。SREでは、障害時にコードや変更履歴を確認し、原因を開発チームと一緒に調べる場面があります。
さらに、テストの自動化、段階的なリリース、性能測定、エラー処理の改善などに取り組むことで、開発経験を信頼性向上に直接生かせます。次に補うべきは、Linux、ネットワーク、クラウド、監視の知識です。
インフラ経験者が広げたい自動化・開発・信頼性設計の視点
インフラ経験者は、サーバー、ネットワーク、監視、障害対応の知識を持っているため、SREへの移行と相性が良いといえます。特に、安定稼働のために必要な設計や運用上の注意点を理解していることは大きな強みです。
一方で、プログラミング、Infrastructure as Code、CI/CD、アプリケーションの仕組みを広げると、よりSREらしい改善ができるようになります。手順を守るだけでなく、手順をコード化して改善する視点を持つことが重要です。
運用経験者が生かせる監視・障害対応・改善の経験
運用経験者は、実際の障害で起きる混乱、利用者への影響、復旧手順の重要性を理解しています。この経験はSREにおいて価値があります。監視の通知が多すぎる問題、手順が分かりにくい問題、情報共有が遅れる問題など、現場の課題を改善につなげられるためです。
運用経験を生かすには、対応記録を残し、発生頻度や対応時間を可視化し、自動化や手順改善の提案まで行うことが有効です。あわせて、クラウドやプログラミングを学ぶことで改善の選択肢が広がります。
学習したスキルを実務経験として伝えるポイント
SREを目指す際は、ツール名や資格だけを並べるのではなく、課題に対して何を考え、どのように行動したかを伝えることが重要です。「監視ツールを使った」ではなく、「エラーの検知が遅れる課題に対して、利用者が失敗した操作を検知する指標を設定し、通知条件を見直した」のように説明します。
実務未経験の場合も、個人開発や学習環境での成果を具体的に示せます。構成図、コード、手順書、障害対応の記録を用意し、再現性と改善の考え方を伝えましょう。SREでは、幅広い技術を知っていることに加え、サービスを安定して改善し続ける姿勢が評価されます。
