2020 年 4 月に Site Reliability Engineer (SRE) にジョブチェンジしてから丸四年が経過した。それから会社を変えながらも、同じ SRE として働き続けている。飽き性の自分にとって意外と長く続いていることに驚いている。SRE として働く魅力について、改めて振り返ってみよう。
サービスの信頼性を担保するという職務を全うするためには、関わるサービスのアーキテクチャを大体把握する必要がある。特定のマイクロサービスや技術に深く造詣を持つ以上に、幅広い平均的な理解と洞察が求められる。その意味で、プロフェッショナルというよりジェネラリストに近い職種だと認識している。
したがって、自然とアーキテクチャを俯瞰してみる能力を鍛える必要が出てくる。仕事の中で、アーキテクチャ図を書いたり、データフローを理解したり、セキュリティモデルを考えたりする中で、サービスの全体が見通せるようになってくる。そこに知的好奇心を覚える。
そもそもコードを書いて自動化しないと運用が回らない数のマシンを捌いているので、コードを書くことを求められる。どのようなコードを書くのかについては所属チームや所属企業によって大きく異なるが、手運用だけで一年間過ごす、ということは無い。
メンバー間のスキル差によって、デバッグが得意な人、プログラミングが得意な人、プロジェクトマネジメントが得意な人というように棲み分けが出てくるが、誰もがある程度のコーディング力を求められる。
SRE の全員がコードが書けるというわけでもなく、Ruby の会社に勤めながら IRB がわからない Staff Engineer の手助けをしたこともあるが、例外として扱われる。少なくともコードが書けない SRE は、仕事ができない SRE という認識がある。
要求が高い現場では、妥協ができない。そこから、技術的なチャレンジが生まれる。そこそこ速くて動けばいい MVP を作れば良い、というスタートアップ初期の環境では、妥協したコードを書いてしまうこともあるかもしれない。というか、むしろ計算量を考え詰めるより、早く市場に出してフィードバックを受ける方が価値がある。
一方で、サービスが成長し安定運用を求められる現場では、レイテンシーにしろエラー率にしろ、ユーザーがついてきているので妥協ができない。妥協ができないので、あの手この手を駆使して障害をしらみ潰しに無くしていく必要がある。
そのような環境では、大規模にマシンを複数リージョンに展開しているのが当然であるので、少しの変更が大きな影響を与える。仕事のインパクトが数字として出やすいし、障害を出せばニュースにもなる。そこに社会への責任感や、スケールの大きさからくる興奮を感じる。
他にも魅力はたくさんあるだろうが、三つあげるとしたら自分の場合は上記の三つになるだろう。
今 SRE として働いている読者の方がいたら、あなたにとっての魅力をぜひ教えてほしい。これから SRE になろうとする読者の方がいたら、どのような魅力に惹かれて SRE になろうとしているのか、ぜひ聞いてみたい。