弊社におけるSREという考え方の推進
はじめに
締切をしょっぱなから遅れてすみません。 この記事はSREアドベントカレンダー1の2日目 (12/2) の記事となります。
SREという部署/役割がない会社に所属しています @reizist と申します。12/2担当です。 普段はバックエンドを専門的に見ていて、アプリケーション開発をしつつインフラ周りの運用/負債返済をやっているようなロールになります。
弊社においてはインフラを見るメンバーはチームごとに何人かずつ（自分のチームは最近までずっと1人だった）アサインされ、各担当者がそれぞれ思ったように推進形成いくというような構成になっております。 入社から半年ほど経過した時点で、似たような作業をしているにもかかわらずチーム間で知識の横展開等がなく共通知も薄いので各自試行錯誤している部分が少なからずあるように感じるようになりました。
ここから横展開を意識した共通知の形成という観点でSREという概念を扱い、どのような努力を行い、どのように改善しているか、を述べたものが本記事になります。
SREという概念の捉え方
今更ですが、改めて。 SREとは何でしょうか。
ご存知の通りSite Reliability Engineering の略で、日本語ではサイト信頼性エンジニアリングなどと言われていますが、 サイト信頼性と言われて何をするべきか分かる人はまずいないと思います。
SRE本では
サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負う
と述べられていて(SRE本1.3章 SREの信条)、サービスに関する一切の動作に関して責務を負うことを考えると、
SREのRはResponsibilityだと思ってる
— masahiro nagano (@kazeburo) 2018年11月27日
とあるように Site Responsibility Engineering と認識したほうがなんとなく実態に近いと思います。
ここで最も一番重要な話ですが、SREは何を目的として上記のような非機能要件に責任を負うのでしょうか。
SRE本で
ゴミが散らかったりしないように環境を保つことによってイノベーションにまっすぐ焦点を当て続け本物のエンジニアリングが前進できるようにしているのです
とあるように(9.8章 単純な結論)、あくまで最終的なゴールはサービスの価値向上です。 サービスの価値向上のために運用をエンジニアリングの観点で行うためのベストプラクティスがSRE、と認識しても良いと思います。
自分のケース
現在、自分が所属するチームにおいてはインフラを見る人と機能開発をする人、 というなんとなくの区分けでチーム開発が行われていて、もう少しうまいこと回らないものかと考えあぐねていました。 非機能開発を全てインフラ側にタスクを投げてしまえばインフラ側（少し前まで1人だった）の手が回らなくなってしまう。 とはいえ、インフラを見る人間は、ただインフラを見ているだけでいいかと言われれば、そうではないと思う。 とはいえ手が回らない...結構ありがちな悩みではないでしょうか。
導入事例
前述の通り会社全体としてはSREという概念は存在しておらず、優秀な他社ではどのようなインフラを含めた開発体制（特にSREという文脈で）が敷かれているか非常に興味がありました。 自分がSREという観点でまだまだ経験・認識不足が多いこともあり、 SRE Loungeに参加したところSREの輪読会をやっている話を聞き、これをきっかけに SRE本読書会を始めました。
まずは自分がSREについて自分なりに定義して会社に落とし込み推進できれば、と思い最小コストを意識して初めてみましたが、 嬉しいことに会社内に興味を持ってくれるメンバーが多くいて、現在は8人前後で定期的に開催しており、現在18章まで読み進めることができました。
SRE本読書会の恩恵としては、まずポストモーテムという文化の推進が挙げられると思います。 現時点では2件のみしか事例がありませんが、本来恥ずかしい、隠したい、と考えてしまいがちな失敗事例をポストモーテムとして全体に公開していく、これはまさにGoogleのSREが推進している文化で、失敗による学びを最大化することを目的に行っています。
また、他チームの優秀なエンジニアの方々に知見の共有を頂きながら、SLOの策定やメトリクス/監視系の再設計などを行い始めました。
今後の展望
とはいえ、まだまだ自分に未熟な点が多く大量に課題が残っています。 まだまだ運用安定化のための可視化が足りてないし、開発効率化の観点での負債の返済もできていないし、ユーザーに影響のあるレベルでのパフォーマンス改善は可能な箇所が多く残っています。
日々の運用が快適になるに連れ、チームのメンバーはシステム開発を次のレベルへ進めることを考え始めた
とあるように(SRE本7.4章 自分の仕事の自動化)、運用について悩んでいる間はシステム開発それ自体のレベルが上げるのは難しいと考えているので、サービスのコアバリュー向上という最大の目標に向かってガンガン開発するためにも、 地道に泥臭いところの改善を行っていこうとしています。
まとめ
インフラを扱うにあたり会社内において共通知の形成/知識の横展開が薄かったため、SRE本の勉強会を定期開催することでSREという概念を取り入れ、目線の統一を推進しました。 推進の結果、SLOの策定、ポストモーテムの共有、メトリクス/監視系の再設計など小さいながらも少しずつSRE的な活動が始まっており、今後も更にSREの観点でサービス改善を加速していきたいと考えています。
最後に
SRE本で僕が好きな節と、読書会中に弊社エンジニアが発した名言を一部紹介してこの記事を終えようと思います。
