この記事は CAMPHOR- Advent Calendar 2021 23日目の記事です．22日目の記事は @sanposhiho の「Pod Topology Spread Constraintsのすべて」でした．
この記事では，CAMPHOR- 卒業後に Site Reliability Engineer (サイト信頼性エンジニア・SRE) として働いてきた経験をもとに，SRE とはどういう仕事をしているのか，どのようなスキルを利用しているかなどを紹介します．これまで対外的に SRE について文章を書いたことはあまりなかったのですが，SRE の役割はまだまだ広く知られておらず「SRE って結局なに?」と思っている人も多くいるように感じるので，せっかくの機会を生かして自分の経験を書いてみようと思います．
対象読者
主に SRE について興味のある学生やジュニアなエンジニアの方を想定して書いています．具体的なプラクティスや技術については深く説明はしていないため，シニアなエンジニアの方にとっては少し内容が薄く感じられるかもしれません．また，具体的な SRE の業務内容や必要なスキル等は各企業によって大きく異なる場合があるので，あくまで一例として読んでいただけると幸いです．
SRE とは何か?
「SRE とは何か?」 というのはやはり難しい質問です．SRE について色々解説されている記事等もありますが，これについてはまずは原点とも言える SRE 本を読んでいただきたいです．この本によると Site Reliability Enginnering は以下のように説明されています．
SRE is what happens when you ask a software engineer to design an operations team.
Site Reliability Engineering より
Site Reliability Engineer はこの SRE を実践する役職ということになります．
(詳細は後述しますが) 自分のような特定のプロダクト (製品・サービス) のチームに埋め込まれた SRE の役割を一言で説明すると，「プロダクトの信頼性を高めることを目的とするエンジニア」ということになると思います．もちろんただ信頼性を高めれば良いのではなく，機能の開発やリリースの頻度等とのバランスを取りながら実行していかなければなりません．より具体的な SRE の考え方，指針，実装等については SRE 本等を参照してください．
SRE とは何でないか
SRE の業務内容というと，具体的な技術 (クラウド，カオステスティング，Infrastructure as Code，etc.) やツールの名前 (Kubernetes，AWS，Terraform, etc.) が挙がってくることがよくあるように思います．ここで注意しなければならないのは，これらはプロダクトの信頼性を高めるために使える手段の例であり，目的ではないということです．
例えば「SRE は Kubenetes を使う役職」というのは誤った認識と言えます．これは，サービスを Kubernetes 上で実行すること自体は，必ずしも任意のプロダクトの信頼性を高める上で重要度の高いこととは言えないためです．Kubernetes はあくまで手段であり，SRE としてはそれぞれのプロダクトの信頼性上の問題点をきちんと理解した上で，それらの問題を優先順位付けして，適切な手段で解決していくことが重要です．
注: ここでは Kubernetes を一例として挙げましたが，Kubernetes が良い・悪いといったことを主張する意図は全くありません．個人的には，多くの場合で Kubernetes は信頼性の高いサービスを実現する上で有益な技術になり得ると思います．
SRE として何をしているのか
ここまで SRE の目的や手段について簡単に説明したので，もう少し具体的に自分の SRE としての業務について紹介します．現在 Indeed という会社の求人検索のプロダクト のチームに埋め込まれる形の SRE として働いています．チームはソフトウェアエンジニア (SWE) を中心にエンジニアリングマネージャー (TDM・EM) やプロダクトマネージャー (PM) など様々な役職のメンバーで構成されており，埋め込まれるというのはその中の一員として働いているという意味です．(企業によって SRE を独立したチームとして運用している場合もあります．) 業務内容は多岐に渡りますが，簡単にまとめると以下のようになります:
- 埋め込まれたチームの信頼性を向上するための業務
- SLI・SLO の設定
- モニタリング・トラブルシューティング
- キャパシティプランニング
- 信頼性向上のためのアーキテクチャの改善・設計・実装，コードレビュー
- OKR の設定・他チームとの調整など
- 全社での SRE に関する業務
- トイルの自動化・ツールの開発
- オンコール・障害対応
- SRE のトレーニングなど
- その他，全社でのエンジニアリングに関する業務
- SREを含むエンジニア等の面接・採用
- Python に関する取り組み (注: これは本来の SRE の責任範囲外ですが，Python に少し詳しい人として色々としています)
具体的なプロジェクトの内容については今回の記事には収まり切りそうにもないので，また機会があれば紹介したいと思います．
SRE として働いて役に立ったこと
最後に SRE として働く上でのスキルについて，大きくハードスキルとソフトスキルの二つに分けて紹介してみます．SRE という仕事は一般的に SWE と比べて幅広いスキルが必要になることが多いように思います．これは，前述のように信頼性向上のためには様々な手段があり業務範囲が広くなりがちであることや，自分のプロダクトの信頼性向上のためには他のプロダクトや全体のインフラ等についても知っておく必要があるからだと考えられます．
一人で全ての範囲を深くカバーすることは現実的に不可能ですが，様々な技術を知って身につけておくことは，将来の信頼性上の問題を解決する際に利用できる引き出しを増やすことにつながります．また，多様なスキルが求められるということは，多様な人材が活躍しやすい役職と言えるかもしれません．
ハードスキル
まず，ソフトウェアエンジニア (SWE) として働くために必要なスキルは必要です．プロダクトのコードを読み書きしたり，運用の自動化 (トイルの削減) を行うためのツールの開発にはどうしても SWE と同等またはそれに近いスキルが必要になってきます．この部分に不安がある場合は，まずは SWE としてキャリアを始めるという選択も十分に考えられると思います．SRE としてもコーディングする機会はありますが SWE と比べると相対的に機会は少なくなるため， SWE として働いた方が早く身につけやすいかもしれません．
次に OS やネットワーク等の技術が挙げられます．これらはソフトウェアエンジニアとしても必要なスキルですが，SRE としてトラブルシューティング等の業務を行う際により深い知識が必要になることがあります．まずは大学のコンピューターサイエンスの過程で習うような範囲をきちんと固めておくのは良いスタート地点かもしれません．
最後に，信頼性向上のために利用できる様々な技術やツールです．これらは多岐にわたるため，具体的な内容はこちらの DevOps Roadmap などを参考にしてみてください． これら全ての技術を実際にすぐに使う機会があるかはわかりませんが，それぞれの技術がどのような問題をどのような方法で解決しようとしているのか，また余裕があれば実際に自分自身で少し使ってみておくのが良いでしょう．また，CAP 定理のような分散システムの理論的な面についても知っておくと，それぞれの技術をより深く理解できます．
これまで何度も述べてきたように SRE の業務内容は多岐に渡り，それぞれのプロダクトによって信頼性向上のために利用するべき手段は異なります．SRE としては新しいことを柔軟に取り入れたり，新しい技術を柔軟に適用していくような姿勢を身につけておく必要があります．
ソフトスキル
実際の SRE としての業務を通じて，技術的なスキルに加えてソフトスキルも重要であると感じられました．例えば，ある種のコミュニケーション能力が必要になります．これはいわゆる「コミュ力」を身につけて誰とも仲良く話さなければならないと言ったものではありません．信頼性上の問題を解決するためには他のチームや特定の技術に詳しいメンバーと協力しなければならない機会は多くあるため，技術的な情報を的確に伝えることが必要になります．また，チーム内でも機能の追加と信頼性の向上といった一見利害が衝突するかのような議論においても，SLO やエラーバジェットといった考え方を用いつつ，うまく妥協点を見つける必要があります．
オンコールやトラブルシューティングを行う際も問題解決のスキルが必要になります．これは，勘に頼るのではなく論理的・統計的に問題を調査して解決する能力や，複雑な問題に粘り強く対応したり，予想外の事態が発生したときに落ち着いて障害を緩和したりできるような精神的な面も含まれます．この辺りは大学の研究活動に近いものもあるかもしれません．
運輸や医療といった他の先行分野からも学べることもあります．例えば，日本の運輸安全委員会は事故の報告書をインターネット上で公開しています．一般的なソフトウェアのポストモーテムと比べてとても詳細に記述されており，一般の Web サービスより高い信頼性が求められる航空分野がどのように事故から学びを得ているのか，興味深く読むことが出来ます．また国によっては事故調査結果を訴訟で証拠として採用することに制限が加えられているなど blameless の文化の一端も見ることが出来ます．
さいごに
SRE は必ずしもソフトウェアエンジニアほどたくさんコードを書いたり，分かりやすい新機能を実装するようなことは少ない役職です．しかしながら，業務・責任範囲も広く様々な技術・スキルを活用することができる面白い役職だと思っています．この記事を読んで少しでも多くの方が SRE という仕事に興味を持ってもらえれば幸いです．
SRE に興味が出てきた方へ
まだ読まれていないのであれば，Site Reliability Engineering を読んでみることをお勧めします．原典とも言える書籍ですし，内容は多くの SRE の間で共通認識・知識として利用されていると思います．英語版は CC BY-NC-ND 4.0 のライセンスで無料で公開されていますし，日本語訳も出版されています．こちらを読み終わっている方は他の書籍を読んだり，様々な技術を勉強しても良いかもしれません．
実際のSREの業務に興味を持った方は，ぜひ各社の求人情報を見てみてください．各社・各プロダクトでそれぞれ違う問題や SRE としての責任範囲が期待されているので，それぞれを見比べてみると面白いと思います．
弊社も SRE を日本を含む世界の様々なオフィスで募集しています．国やタイムゾーンの制限はありますが基本的にリモートでも働けるので，興味のある方は是非求人を確認して応募してみてください．学生の方向けにはインターンシップ (SRE・SDE) や新卒 (SDE) の募集も行っています．もし応募する前にもう少し話を聞いてみたいという方がいれば，ぜひお気軽にご連絡ください．
CAMPHOR- Advent Calendar 2021 24日目はお休みで，25日目の担当は @kmconer です．お楽しみに!
(2021-12-25 更新) 24 日目の記事として「【pixiv】Webフロントエンドを学ぼう ~ CSSアニメーション・画像変換・配信エンジン ~ を開催しました！」が公開されました．