SREの仕事｜業務・必要スキル・企業選び

役割と仕事の目的

サービスの信頼性をソフトウェアの仕組みで支える役割です。GoogleのSRE書籍では、サービスの目標や運用作業の扱いなどを整理しています。単に監視担当を英語で呼ぶものとは限りません。

業務の流れを工程で分ける

利用者にとって必要な信頼性を定義し、指標を測り、障害と手作業を分析し、改善を実装します。公開の頻度と安定稼働を、観測できる情報を使って調整します。

技術だけでは決まらない判断

SLIは何を測るか、SLOはどこまでを目標にするかという区別です。全てのリクエストを同じ重さで扱うか、主要操作を対象にするかはサービスごとの判断になります。

成果物と経験の説明

運用手順の自動化、復旧時間の短縮、通知の見直し、障害後の改善を説明します。平均値だけでなく、利用者の一部に長い待ち時間が生じていないかも見ます。

監視の練習では、通知が届いた件数と、利用者へ影響が出た件数を分けて考えます。多くの通知が届いても、対応が必要な事象を見逃すなら役に立ちません。何を検知したら、誰が、どの判断をするかを対応付けます。改善の成果は手作業を減らした時間だけでなく、誤操作、復旧のばらつき、引継ぎの難しさがどう変わったかでも説明できます。運用を止めることが難しい状況で、安全に変更した過程を記録すると具体性が増します。

他の担当者との境界

アプリ開発者と信頼性の責任を共有し、インフラやセキュリティ担当と変更を調整します。SREが全ての障害を引き受ける構成なのか、開発チーム自身も対応するのかを確認します。

信頼性の指標は集めるだけでなく、設計や公開の判断へどう使うかを確認します。集計全体が良好でも、特定の機能や利用者の条件で問題が続いていないかを調べます。応募時には、自分が扱った指標の意味と、実際に判断を変えた場面を説明すると、監視画面を作ったこと以上の役割が伝わります。

具体例から仕事を考える

例として、毎晩発生する手動復旧を考えます。手順を自動で繰り返すだけでは原因が残る場合があります。処理が止まる条件、検知の遅れ、回復の安全性を調べ、原因修正と運用削減の両方を検討します。

応募前に確認したいこと

SLOの定義、オンコールの分担、改善開発に使える時間、障害後の振り返り、プロダクト側との意思決定の関係を聞きます。名称から待遇や勤務時間を推定しないでください。

企業を比べるときは、担当したい対象、日常の成果物、判断できる範囲を分けます。特定のツールを使うという一致だけで決めず、誰の何を支える仕事かを確認しましょう。未公表の配属、評価、勤務条件は公開資料から補わず、面談や正式な条件の確認で埋める必要があります。

学習と経験の広げ方

運用の経験にコードによる改善を重ねる道と、開発経験から可観測性や復旧設計へ広げる道があります。障害を個人の失敗として終わらせず、仕組みの改善へ戻す力を磨きます。

職種の説明は、技術資料と公表された役割の枠組みをもとに整理しています。企業ごとの必須要件や採用中の職務を示すものではありません。同じ肩書でも、設計、実装、検証、顧客対応の配分は異なります。募集要項の業務と、自分が経験した工程を一つずつ対応付けてください。