経歴のスタート地点
新卒でデータセンター運用企業に入社し、24時間365日の監視オペレーターとして5年間働いてきた。シフト勤務でモニターを睨み、アラートが鳴ったら手順書通りに一次切り分けをして、必要なら担当者にエスカレーションする——それが日常だった。
最初の2年は学ぶことが多くて充実していた。サーバーやネットワークの基本、障害対応のフロー、お客様への報告作法。けれど3年目を過ぎたあたりから、同じアラートに同じ手順で対応する自分に気づき始めた。「このランブック、3年前から一文字も変わってないな」と。深夜2時にディスク容量アラートで起こされ、決まりきった手順でログを削除し、起票して報告書を書いて寝る——その繰り返しに、未来が見えなくなっていった。
最初のつまずき
危機感を覚えて、まずやったのはシェルスクリプトでログ収集を自動化することだった。けれど、書いたスクリプトはレビューで先輩から「動くけど怖い」と却下された。エラーハンドリングも、冪等性も、テストも何もない。プログラミングの基礎が決定的に足りていなかった。
さらに痛感したのは、自分が「インフラを運用している」つもりで、実は「他人が作った設定を眺めているだけ」だったということ。サーバーがどう構成されているかをコードで記述する——いわゆるIaCの世界が、自分には全く見えていなかった。Terraformって何？という状態だった。同期の中にはAWS資格を取り始めた者もいて、自分だけが置いていかれる感覚が強くなった。
転機
転機は、運用支援で入った顧客先のSREチームと一緒に障害対応をしたときだった。彼らはアラートが鳴ると、まず「これは検知の精度の問題か、本当の障害か」を議論してから動き始めた。そして対応後、必ずポストモーテムを書いた。「なぜそれが起きたか」「再発防止に何を自動化するか」を真剣に議論する文化があった。
私たちオペレーターは、アラートを「処理する」ことが仕事だった。彼らSREは、アラートを「減らす」ことが仕事だった。同じ現象を見ているのに、見ている問題のレイヤーが全く違う。「自分もあちら側に行きたい」と強く思った。その夜、帰り道で「1年以内にSREに転身する」と決めた。
いま振り返る選書
SREへの転換を決めてから、計画的に本を読み込んだ。
- 『SRE サイトリライアビリティエンジニアリング』：Googleの教科書。最初は概念が難しすぎて挫折したが、半年現場で揉まれてから読み返すと、すべての章が腹に落ちた。エラーバジェットの考え方は衝撃だった。
- 『はじめようSRE』：日本のSRE導入事例が豊富で、自分の組織でどう適用するかを考える起点になった。日本企業特有の「100%可用性を求められる文化」とどう戦うかのヒントが満載。
- 『SRE Workbook』：SLI/SLOを実際に設計してみる演習書。社内のサービスで試作したSLOが、いまの運用改善のベースになっている。
- 『新しいLinuxの教科書』：オペレーター時代に「コマンドを叩く」ことしかしてこなかった自分が、Linuxの仕組みを体系的に学び直した。プロセス、シグナル、ファイルシステムの章は何度も読み返した。
- 『Infrastructure as Code』：Terraform本に進む前にこれを読んだのが正解だった。なぜコード化するのか、その思想を理解できた。
- 『入門 監視』：監視の哲学が変わった。「とりあえず全部監視」から「ユーザー体験に基づくシグナルだけを監視」へ。
現場での実践
読書と並行してやったのは、業務の中で小さくIaC化を進めることだった。手順書で行っていたサーバー初期構築をAnsibleでコード化し、レビューを受け、Gitで管理する。最初はプルリクエストの書き方すら知らなかった。3ヶ月かけて10個のplaybookを作り、運用が劇的に楽になったとき、初めて「自分はSREの入り口に立てた」と実感した。
転職活動では、これらのGitHubリポジトリと、社内で書いたポストモーテム（公開可能な形に書き直したもの）をポートフォリオにした。コードの品質ではなく、「課題に気づいて自動化に持ち込んだプロセス」が評価されて内定をもらえた。
これから挑む人へ
オペレーターからSREへの道は、コードが書けない自分を肯定する勇気から始まる。最初のスクリプトはダサくていい。レビューで叩かれていい。「同じ作業を繰り返している」という違和感を、自動化の起点に変えられる人が、SREに向いている。
監視画面を見続けた5年間は、決して無駄じゃなかった。障害の手触りを知っているオペレーター出身者ほど、信頼性を設計できるSREになれると、私は信じている。アラートに鳴かされ続けた夜の数が、いまの自分の財産になっている。
