SREとは（仕事・歴史・向いている人）

Google で SRE チームを立ち上げた Ben Treynor Sloss は、SRE を「ソフトウェアエンジニアに運用チームの設計を任せたら起きること」と説明しています。運用を人の頑張りで支えるのではなく、コード・自動化・データで回るようにするのが SRE です。

→ SLO・エラーバジェット・ポストモーテムは第2章で詳しく

ある1週間の例：

「サービスの信頼性を上げる」という目的は、どの会社の SRE でも同じです。ただ、SRE に何を任せるか・仕事の範囲がどこまでかは会社によって大きく違います。同じ「SRE」という肩書きでも、ほぼインフラエンジニアの仕事のこともあれば、アプリのコードを直して性能を上げる仕事が中心のこともあります。

応募・配属のときに確かめること

• SRE は何人で、どのサービス・どの範囲（インフラ・アプリ・DB）を見ているか
• オンコールはあるか、回数と体制は
• SLO は決まっているか、エラーバジェットで判断しているか
• アプリのコードを触るか、インフラのコード（IaC）が中心か
• チームの形（SRE チームの形のどれに近いか）

求人票の「SRE」だけで仕事を決めつけず、面接の逆質問で「1週間の仕事」「最近いちばん時間を使ったこと」を聞くと、実際の重心が分かります。

DevOps は「開発と運用の壁をなくす」文化・考え方、SRE はそれを SLO・エラーバジェット・トイルの上限などの具体的なルールで実践するやり方、と整理するとわかりやすいです。会社によって呼び方と範囲は大きく違うので、求人では仕事内容を確かめます。

Google Cloud のブログで紹介された6つの形です。実際は組み合わせることが多く、面接では「応募先がどの形か」を聞くと仕事のイメージがつかみやすくなります。

逆に「決まった作業を確実にこなすのが好き」「1つの技術だけを深く極めたい」人は、運用のくり返しや範囲の広さを負担に感じることがあります。オンコール（夜間・休日の呼び出し）がある職場も多いので、体制や回数も確かめておきます。

SRE になる道は、インフラ・運用エンジニアから（自動化・ソフトウェアを伸ばす）と、バックエンドエンジニアから（インフラ・運用を伸ばす）の2つが多いです。どちらから来ても、コードを書いて運用を楽にした経験が強みになります。

→ アプリ出身とインフラ出身で、得意なことと伸ばすことの違い

→ 職種ごとの深さ（ホームの表）で、他の職種との違いも見られます

SRE になる人は、アプリケーションエンジニア（バックエンドなど）出身と、インフラエンジニア（サーバー・ネットワーク・運用）出身が多いです。目指すところは同じでも、出発点が違うので、得意なことと最初に伸ばすことが違います。

どちらが有利ということはなく、足りない側を埋めて「アプリからインフラまでを通して原因を追える」状態を目指すのは同じです。チームとしては両方の出身者がいると、障害の切り分けや設計レビューで死角が減ります。

面接では「自分はどちら出身で、何が強みか・何を伸ばしているか」を一言で言えるようにしておくと、応募先の SRE の重心（会社によって違う SRE の仕事）と結び付けて話せます。

各章の終わりには、まとめ・クイズ・面接の質問があります。クイズで間違えた問題は「今日の復習」で間隔を空けて出し直されます。