サイト信頼性エンジニア(SRE)履歴書ガイド — 面接を獲得する履歴書の書き方
Glassdoorは米国のSRE平均年収を169,680ドルと報告しており、Indeedでは154,351ドルとされています。トップ企業のシニアSREは総報酬で定期的に200,000ドル以上を超えています [1][2]。BLSはSREの職種をソフトウェア開発者(2034年まで15%の成長予測)およびネットワーク/システム管理者に分類しており、Googleが体系化し、現在すべての主要テクノロジー企業が実践するこの複合的な分野の性質を反映しています [3]。SREチームは大規模システムの信頼性の屋台骨であり、あなたの履歴書はサービスを稼働させ続けながら同時に改善できることを証明する必要があります。
このガイドでは、ソフトウェアエンジニアリングスキルと運用の深さの両方を示すSRE履歴書の書き方を解説します。
要点まとめ
- 信頼性メトリクスで始める:可用性のパーセンテージ、SLO/SLIのパフォーマンス、MTTRの削減、インシデント頻度の改善。
- 運用するだけでなくコードが書けることを証明する — SREは運用課題に適用されるソフトウェアエンジニアリングの分野です。
- インフラストラクチャの規模を定量化する:毎秒リクエスト数、サービス数、クラスターサイズ、データ量、地理的分布。
- トイル削減のナラティブを示す:手作業の自動化、自己修復システムの構築、運用負担を排除するツールの作成。
- オンコール経験、インシデントレスポンスのリーダーシップ、ポストモーテム文化への貢献を含める。
リクルーターはSREの履歴書で何を探すのか?
SREの採用はソフトウェアエンジニアリングとシステムエンジニアリングの評価を組み合わせます。リクルーターと採用マネージャーが確認するのは:
- ソフトウェアエンジニアリング能力 — Python、Go、Javaなど。SREは本番コードを書きます:自動化ツール、監視システム、デプロイパイプライン、自己修復インフラ [4]。
- 大規模システム — 数百万のリクエストを処理し、複数のリージョンにまたがり、99.9%以上の可用性が必要なシステムの運用経験。
- オブザーバビリティとモニタリング — Prometheus、Grafana、Datadog、PagerDuty、OpenTelemetry。システムを計装し、ダッシュボードを構築し、異常を検出できますか?
- インシデント管理 — オンコール参加、インシデントコマンダー経験、ポストモーテムの執筆、測定可能なMTTR改善。
- Infrastructure as Codeと自動化 — Terraform、Ansible、Pulumi、Kubernetes。インフラをコード化し手作業を排除する能力。
Googleの SRE本は、この分野の基礎テキストとして、SREを「ソフトウェアエンジニアに運用機能を設計するよう依頼したときに起こること」と定義しています。あなたの履歴書はそのアイデンティティを反映すべきです [4]。
SREに最適な履歴書フォーマット
- 長さ:1〜2ページ。5年未満の経験なら1ページ、豊富なインシデントレスポンスおよびプラットフォームエンジニアリング経験を持つシニアSREなら2ページ。
- レイアウト:逆時系列。エンジニアリング採用はフォーマットに保守的です。
- 技術スキルセクション:カテゴリ別に整理:言語、クラウド/インフラ、オブザーバビリティ、CI/CD、データベース、ネットワーキング。
- セクション順序:概要 → スキル → 経験 → プロジェクト/OSS → 学歴 → 資格。
- オンコールとインシデントメトリクス:役割の説明内に含め、別セクションにしない。
主要スキル
ハードスキル
- プログラミング言語(Python、Go、Java、Bash、Ruby)
- Linuxシステム管理(systemd、ネットワーキング、パフォーマンスチューニング)
- Kubernetes(デプロイ、スケーリング、オペレーター、Helm、サービスメッシュ)
- クラウドプラットフォーム(AWS、GCP、Azure)— VPC、IAM、コンピュート、ストレージ、ネットワークサービス
- Infrastructure as Code(Terraform、Pulumi、CloudFormation、Ansible)
- CI/CDパイプライン(Jenkins、GitHub Actions、GitLab CI、Argo CD、Spinnaker)
- オブザーバビリティ(Prometheus、Grafana、Datadog、New Relic、OpenTelemetry)
- インシデント管理(PagerDuty、OpsGenie、Incident.io)
- 分散システム(コンセンサス、CAP定理、メッセージキュー、サービスメッシュ)
- データベース運用(PostgreSQL、MySQL、Redis、DynamoDB、Cassandra)
- コンテナオーケストレーション(Docker、Kubernetes、ECS、Nomad)
- サービスメッシュ(Istio、Envoy、Linkerd)
- カオスエンジニアリング(Gremlin、Litmus、Chaos Monkey)
- ロードバランシングとトラフィック管理(NGINX、HAProxy、Envoy、AWS ALB/NLB)
- SLO/SLI/SLAの定義とエラーバジェット管理
ソフトスキル
- インシデントリーダーシップとプレッシャー下でのコミュニケーション
- ポストモーテムのファシリテーションと無責文化
- プロダクトチームおよび開発チームとのチーム横断的な協力
- テクニカルドキュメントとランブック作成
- オンコールメンタリングとエスカレーショントレーニング
- 信頼性作業vs.機能開発の優先順位付け
- ステークホルダーへの信頼性メトリクスのコミュニケーション
職歴の箇条書き
エントリーレベル(0〜2年)
- 200万DAUにサービスを提供する15の本番マイクロサービスのオンコールローテーションを管理し、アラートチューニングとランブック自動化により6ヶ月でアラート量を40%削減。
- AWS環境(ECS、RDS、ElastiCache)向けのTerraformベースのインフラプロビジョニングシステムを構築し、標準化されたセキュリティ設定で新サービスのデプロイ時間を3日から2時間に短縮。
- インシデント中に5つのサービスにわたるエラーパターンを自動相関するPythonベースのログ分析ツールを開発し、平均トリアージ時間を45分から12分に短縮。
- 20サービスのKubernetesクラスター向けにPrometheusモニタリングとGrafanaダッシュボードを実装し、150+カスタムメトリクスをカバーし、チーム初の正式SLO定義に情報を提供するSLIベースラインを確立。
- Cert-Managerとカスタム Kubernetesオペレーターを使用して50+ドメインのSSL証明書ローテーションを自動化し、以前8時間を要し期限切れリスクがあった四半期ごとの手動プロセスを排除。
ミッドキャリア(3〜7年)
- 3つのAWSリージョンと12のクラスターにまたがるマルチリージョンKubernetesプラットフォームを設計・運用し、200+マイクロサービスで日間5000万リクエストを99.95%の可用性でサポート。
- 1000万ユーザーにサービスを提供するプラットフォームのSLOプログラムをリードし、30サービスのレイテンシ(p99 < 200ms)、可用性(99.9%)、スループットのSLIを定義し、信頼性と機能開発速度のバランスを取るエラーバジェットポリシーを確立 [4]。
- PagerDuty、Slack、カスタム診断ツールを統合した自動インシデントレスポンスシステムを構築し、平均復旧時間(MTTR)を90分から15分に短縮。アラート発火から3分以内に推定根本原因を特定。
- Gremlinを使用したカオスエンジニアリングプログラムを実施し、50+の実験を行い、本番システムで12の重大障害モードを特定。うち3つはピークトラフィック時に数時間の停止を引き起こすものだった。
- Argo CDとHelmを使用したGitOpsベースのデプロイパイプラインを構築し、60サービスで週200+のデプロイを自動カナリア分析と自動ロールバックで可能にし、デプロイ関連インシデントを75%削減。
シニアレベル(8+年)
- 300マイクロサービスで年間20億ドル+の取引量を処理するプラットフォームを担当する10名のSREチームを構築・リードし、99.99%の可用性を維持し3年間で5倍のトラフィック成長をサポート。
- OpenTelemetry、Prometheus、Jaeger、Grafanaを使用して企業のオブザーバビリティプラットフォームを設計し、500+サービスにわたる統合メトリクス、トレース、ログを提供し、平均検出時間を25分から3分未満に短縮。
- モノリシックアプリケーションからマイクロサービスアーキテクチャへのゼロダウンタイム移行を設計・実行し、50万行のコードベースを18ヶ月で40の独立デプロイ可能なサービスに分解。全期間を通じて99.95%のSLOを維持。
- 重大度分類、インシデントコマンダーローテーション、ポストモーテムプロセス、四半期信頼性レビューを含む企業のインシデント管理フレームワークを確立し、2年間でSEV-1インシデントを四半期12件から3件に削減。
- 2,000ノードのクラウド環境で、ライトサイジング、スポットインスタンス自動化、リザーブドキャパシティプランニング、Kubernetesリソース最適化により、インフラコストを年間420万ドル削減。
職務要約の例
エントリーレベル:200万+DAUにサービスを提供する本番Kubernetes環境とオンコール運用の管理に2年の経験を持つサイト信頼性エンジニア。Python、Terraform、Prometheus、AWSに精通し、自動化、モニタリング、インシデントレスポンスに注力。アラートチューニングとランブック自動化によりアラート量を40%削減。
ミッドキャリア:マルチリージョンプラットフォームの設計、SLOプログラムの定義、日間5000万リクエストを処理するサービス向けのデプロイ自動化構築に6年の経験を持つSRE。Kubernetes、Terraform、オブザーバビリティツール(Prometheus、Grafana、OpenTelemetry)のエキスパート。MTTRを90分から15分に短縮し、GitOps自動化でデプロイインシデントを75%削減した実績。
シニア:年間20億ドル+の取引を処理するプラットフォームの信頼性エンジニアリングチームの構築・リードに12+年の経験を持つシニアSREリーダー。分散システムアーキテクチャ、オブザーバビリティプラットフォーム設計、インシデント管理フレームワークのエキスパート。99.99%の可用性維持、年間420万ドルのインフラコスト削減、10名チームを率いながらのプラットフォーム5倍スケーリングの実績。
学歴と資格
SREの職種は実証された技術力を優先します:
- 学士号 — コンピューターサイエンス、ソフトウェアエンジニアリングまたは関連分野。期待されますが、強力なシステム経験があれば常に必須ではありません。
- 独学またはブートキャンプ — ポートフォリオ付き。実証された本番運用とコーディングスキルがあれば可能。
関連資格:
- AWS Solutions Architect(Associate/Professional) — クラウドインフラ設計を検証(Amazon Web Services)[5]。
- CKA(Certified Kubernetes Administrator) — Kubernetes運用の専門性を検証(CNCF)。
- CKAD(Certified Kubernetes Application Developer) — Kubernetes開発スキルを検証(CNCF)。
- Google Professional Cloud DevOps Engineer — GCPでのSREプラクティスをカバー(Google Cloud)。
- HashiCorp Terraform Associate — Infrastructure as Codeの能力を検証(HashiCorp)。
- AWS DevOps Engineer Professional — AWSでのCI/CDと自動化を検証(Amazon Web Services)。
よくある履歴書の間違い
- システム管理者として位置づける — SREはソフトウェアエンジニアリングの分野です。履歴書がコーディングのないシステム管理者のように読めると、エンジニアリング採用のフィルターを通過しません。ソフトウェアエンジニアリングの貢献で始めてください。
- 信頼性メトリクスが欠如 — 可用性のパーセンテージ、MTTR、SLOコンプライアンス、エラーバジェットのパフォーマンスはSREのコアメトリクスです。すべての役割記述に含めるべきです。
- スケール指標がない — 「Kubernetesクラスターを運用」は曖昧です。「3リージョンにまたがる12のKubernetesクラスターを運用し、200+マイクロサービスと日間5000万リクエストをサポート」は能力を伝えます。
- トイル削減を無視 — SREの核心的使命は自動化によるトイルの排除です [4]。何を自動化したか、節約した時間、排除した運用負担を示してください。
- 汎用的なツールリスト — コンテキスト付きでツールを列挙:「Prometheus(5,000+カスタムメトリクス、200+アラートルール)」であって単なる「Prometheus」ではなく。
- インシデント管理のナラティブが欠如 — オンコール経験、インシデントレスポンスのリーダーシップ、ポストモーテムへの貢献は期待されます。月あたりのアラート数、MTTR、解決事例を含めてください。
- コーディングの証拠がない — 書いたコード(自動化ツール、内部プラットフォーム、モニタリングソリューション)を示せない場合、GitHubリンクを追加するか、具体的なエンジニアリングプロジェクトを記述してください。
SREのATSキーワード
Site Reliability Engineering、SRE、DevOps、Kubernetes、Docker、AWS、GCP、Azure、Terraform、Infrastructure as Code、CI/CD、モニタリング、オブザーバビリティ、Prometheus、Grafana、Datadog、インシデント管理、オンコール、MTTR、SLO、SLI、SLA、エラーバジェット、自動化、Python、Go、Linux、分散システム、マイクロサービス、信頼性、可用性、スケーラビリティ、カオスエンジニアリング、GitOps、Argo CD、Helm、サービスメッシュ、ロードバランシング、ポストモーテム、トイル削減、クラウドインフラ
最終まとめ
- SREは信頼性のためのソフトウェアエンジニアリングです — 履歴書は運用とともにコーディングを示す必要があります。
- 信頼性メトリクス(可用性、MTTR、SLOコンプライアンス)はSRE履歴書の核心的通貨です。
- インフラの規模を定量化:サービス、クラスター、毎秒リクエスト、取引量。
- トイル削減のナラティブを示す:何を自動化し、どのような影響があったか。
- インシデント管理の経験とオンコールへの貢献を含める。
Resume GeniでATS最適化されたサイト信頼性エンジニアの履歴書を作成しましょう — 無料で始められます。
よくある質問
Q: 履歴書でSREとDevOpsの違いは? A: SREはDevOps原則の特定の実装であり、信頼性エンジニアリング、SLOベースの管理、エラーバジェットに焦点を当てています。DevOpsはより広範な文化的・プロセス的フレームワークです。職種名がSREならば、信頼性メトリクス(SLO、MTTR、エラーバジェット)、インシデント管理、トイル排除を強調してください。DevOpsならば、CI/CD、自動化、インフラを強調してください [4]。
Q: SREはコーディングを知る必要がありますか? A: はい。SREは明確に運用に適用されるソフトウェアエンジニアリングの役割です。GoogleのSREチームは通常、候補者にソフトウェアエンジニアと同じコーディング面接に合格することを求めます [4]。少なくとも、本番コードの例でPythonまたはGoの習熟度を示してください。
Q: CKA資格は取得する価値がありますか? A: はい、特に毎日Kubernetesを使用している場合。CKAは実践的なKubernetes管理スキルを検証し、業界全体で認知されています。従来のシステム管理者からSREに移行する候補者にとって特に価値があります。
Q: オンコール経験をどう記述すべきですか? A: ローテーションの頻度(「4週に1週」)、アラート量(「月15件のアラート、9件に削減」)、MTTRメトリクス、および診断アプローチを示す具体的なインシデント解決の例を含めてください。
Q: GitHubプロフィールを含めるべきですか? A: 強く推奨します。SREの採用マネージャーはコーディング能力の証拠を探します。インフラ自動化、モニタリングツール、内部プラットフォームプロジェクトを示すリポジトリをピン留めしてください。READMEが明確でコードが整理されていることを確認してください。
Q: システム管理者からSREに移行するには? A: 履歴書で自動化プロジェクト、スクリプティング(Python/Go/Bash)、モニタリングの実装、SLOや信頼性に関する作業を強調してください。OSS貢献や個人のSREツールを示すプロジェクトセクションを追加してください。現代的なスキルを検証するためにCKAとクラウド資格を取得してください。
Q: どのクラウドプラットフォームに焦点を当てるべきですか? A: ターゲット企業に合わせてください。AWSはエンタープライズSRE採用を支配し、GCPはGoogleおよびGoogle隣接ツールを使用する企業で顕著であり、Azureはエンタープライズで成長しています。マルチクラウド経験はますます評価されています。