自分の中の「SRE」を言語化してみる

僕はいま自分の職種を「SRE（Site Reliability Engineer)」と名乗っています。
こういうと「SREってなんですか？」とよく聞かれます。
一言で説明はしてみるものの、抽象的すぎて伝わっていない様子。
そして具体的に説明しようと思ったら、やってることが多くて説明が散らかってしまい伝わらない。

なので一度自分の職種を見つめ直し、ちゃんと言語化しようと思いました。
これから書くのは「Google」のSREとは違うかもしれませんし、みなさんの会社の「SRE」とも違うかもしれません。
あくまで僕がいままで学んだことや、やってきたことを基に考えた「主観」です。

※適宜修正していきます

SREを一言でいうと？

サービスの可用性を守るお仕事

どんな仕事をするのか

• 可用性があるサーバーアーキテクチャの検討・構築・運用
• 上記の構築の自動化
• キャパシティプランニング
• 安定したデプロイを行える基盤構築・運用
• 監視を行う基盤構築・運用
• サービスの状態を見るためのログ収集基盤の構築・運用
• 可用性につながるアプリケーションの開発・保守
• パフォーマンスチューニング
• オンコール対応
• 可用性につながるテスト実施（負荷試験）
• セキュリティの担保
• 開発チームの考案したアーキテクチャレビュー
• 開発チームのアプリケーションのソースコードレビュー

エンドユーザにとっての「SRE」の価値

• サービスをいつでも提供できること
• 障害が起きても即座に復旧できること
• パフォーマンスを向上させ、ユーザ体験を良くする

会社にとっての「SRE」の価値

• サービスの可用性を上げ機会損失を減らす
• 運用コストを減らし、よりビジネスに注力する
• 適切なアーキテクチャを考え、ランニングコストを抑える
• 開発チームに開発を注力してもらい、さらにビジネスを加速させる

開発チームとの関わり方

• 開発チームのリリースまでの流れを妨げてはならない
  • よりリリースをスムーズにできる仕組みづくりが必要
  • 例外もあり、ユーザ体験に難ありの場合は開発チームと話し合い止めることもある
• 可用性という観点で開発チームのソースコードやアーキテクチャをレビューする
  • スケーラビリティを考慮していないアーキテクチャになっているときがある
  • DBクエリー、N+1問題などパフォーマンスに影響のあるところを注意する
• 開発チームとSREチームはともに可用性という観点で同じ目標を持つ
  • 対立構造を作らないため

最後に

こう言語化してみると、カバーしなくてはいけない技術が非常に多いです。
サーバーの構築・運用だけではなく、アプリケーション開発の領域まで踏み込むこともありますので
プログラミング能力は絶対に必要になってきます。
またアジャイルのように高頻度でリリースを行う場合、そのリリースを安定化させる仕組みづくりも必要です。

このような「可用性」を守るためにあらゆる努力をするのがSREだと思ってます。
これらの領域の学習をするのはとても大変ですが、がんばっていきたいと思います…！

---

いま1人でSREやってるんですが相談できる相手がいなくて辛いです(´・ω・｀)
SREの方はぜひお話しましょう！！

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム