こんにちは、プロダクト開発本部SREチームの松嶋です。
delyのSREチームは、2020年末頃まで最大2人体制の少数で奮闘してきましたが、嬉しいことにこの1年でメンバーが4人と倍増しました。
それまでは、リソース不足であったため足元にある緊急度の高い課題を解決していくことがSREのメインイシューで、長期的に取り組んでいく必要のある改善業務に着手することが困難な状態でした。
しかし、SREのプラクティスを何も実践できていなかった訳ではなく、想定外の複雑さを減らし、今以上に増やさないための文化づくりを意識的にしてきたので、サービスの信頼性が大きく下がることはほとんどなく、アラート対応に追われる状況に陥ることは防げていたと思います。
実際どのように想定外の複雑さを減らす取り組みをしていたのかは、現CTOの井上が「SRE NEXT 2020」にて発表しているので、興味のある方はこちらの記事をご覧ください。 tech.dely.jp
メンバーが増員したことでリソース不足からは解消されたのですが、本来SREとして何をすべきなのか役割が曖昧であること、またチームとして機能するための仕組みがないことが浮き彫りとなりました。
そこで本記事では、ここ1年で自分たちがサービスや組織に提供できる価値を改めて再考し、SREがチームとして効果的に機能するために現在まで取り組んできたことについて紹介したいと思います。
1. チームミッションの再考
最初に取り組んだのは、SREチームのミッションの再考です。 delyのバリューとミッションが更新された同時期にちょうどメンバーが4人になったため、SREは会社のバリューを体現していくためにチームとして何を成し遂げていくのかを議論しました。
delyのバリューは、「Trade on」、「Deliver Passion & Happines」、「Good to Great」、「Heart to Heart」の4つがあるのですが、これらのバリューに沿ってSREとして何を実現していくのかチーム内で話し合い、また開発部の他チームの意見も取り入れた上でミッションを決定しました。
delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。 その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。
このミッションには、何故私たちSREはシステムの設計と運用を改善していくのかの想いが込められています。SREは直接的にプロダクトの機能開発に貢献している訳ではないですが、信頼性と開発速度の2つの指標を追っているのは、ユーザーの満足度と事業の成功度を高めるためであり、その手段としてシステムの設計、運用を改善していることを日頃から意識していくことが重要だと考えています。したがって、会社として大切にしている「delyが持つ熱量と幸せをできるだけ多くの人に届けられる」、「プロダクトの価値最大化」という文言をミッションに入れることにしました。
ミッションを再定義することで、delyのSREらしさが可視化されたと思いますし、チームとしての共通認識が生まれ、足元が揃いやすくなったのではないかと感じています。
delyのバリューについて詳しく知りたい方は、こちらのカルチャーデックをご覧ください。 https://speakerdeck.com/delyinc/delyculturespeakerdeck.com
2. 役割スコープの策定
続いて、ミッションに沿ったSREの役割スコープを定めました。
役割スコープとは、SREの責任範囲や業務内容を明確にするためのものです。
何故ミッションだけではなく役割スコープも定義したかというと、SREの業務は組織やフェーズによってやるべきことが変わってくるので、責任範囲を決めることで、SREメンバーの認識のずれを最小限にし、チーム間のコミュニケーションを取る上でもSREまたは開発者がボールを持ったほうが良いのか判断しやすくするためです。
SRE本の第1章には、GooleのSREの責任範囲について以下のように書かれています。
ワークフローの細かい部分、優先順位、日々の運用は SRE のチームによって異なっていますが、 サポートするサービスに対する一連の基本的な責任と、中核となる信条の尊重は、すべてのSRE チームに共通するものです。概して、SRE チームは、サービスの可用性、レイテンシ、パフォー マンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負います。私たちは、SRE チームはどのように環境とやりとりすべきか、業務の規範を明文化しました。 この環境には、実働環境のみならず、プロダクト開発チーム、テスティングチーム、ユーザーなども含まれます。これらのルールや作業のプラクティスは、運用の作業ではなく、エンジニアリング作業に集中し続けるのに役立っています。
1.3 SRE の信条/Site Reliability Engineering
しかし、delyとサービスの規模やフェーズも全く異なるため、Googleの考えを取り入れつつもdelyのSREが現状取り組んでいることを踏まえて役割スコープを11個定めました。
決定したdelySREの役割スコープは、以下のとおりです。
1. サービスのSLOを下回ることなく、変更の速度の最大化を追求する 2. モニタリング 3. 緊急対応 4. 変更管理 5. 需要の予測とキャパシティプランニング 6. パフォーマンス 7. インフラコストの管理 （AWS/GCPのコスト管理） 8. コンサル/オンボーディング （開発者へのインフラオンボーディング、サーバーサイド設計レビュー） 9. ローンチ調整 （新規サービス立ち上げ時のコンサルティング、新規サービスのインフラ設計・構築・運用） 10. サービスのセキュリティ （インフラ周りのセキュリティ対策、AWS/GCPのアカウント・権限管理） 11. サービスの復旧準備 （永続データのバックアップ設計・運用）
※項目7~11が、dely独自の役割スコープなので注釈をつけています。
SRE本でも言及されている項目も含まれていますが、delyのSREが今までやってきたこと、これからもやっていくべきことを考慮した上で、新しくスコープを定めた方が自分たちの業務範囲を認識しやすく、今まで以上に円滑なコミュニケーションや意思決定ができると考えたため、独自のスコープを定義しました。
3. 課題の洗い出し＆優先度決め
ミッション及び役割スコープが決定し、チーム内の共通認識が出来上がったところで次に取り組んだのは、現状システムが抱えている課題の洗い出しと各課題の優先度付けです。 SREが解決していくべき課題は大小様々ありますが、基本的に上述した役割スコープに紐づくものになっています。 また、課題が可視化されていても各課題の優先度が数値化されていないと、メンバーが着手しやすいものや影響度の小さい課題ばかり取り組んでしまう可能性があり、優先度の判断が個々に委ねられてしまうので、SREチームの価値を最大限発揮することができません。
そこで、課題の優先度を客観的な指標で決定できるように、「信頼性」、「開発速度」、「運用効率化」、「工数」の4つの指標を用いて優先度を算出する方式を採用しました。 「信頼性」、「開発速度」、「運用効率化」の3指標には3~4段階のウェイトを割り振り、それぞれを掛け合わあせたものを「工数」で割って算出した値が高いほど優先度が高い課題となり、その課題から取り組んでいくようにしました。
「優先度」=「信頼性」×「開発速度」×「運用効率化」/「工数」
各課題における「信頼性」、「開発速度」、「運用効率化」の重み付けは、以下のような重み付け表で定義しているので、課題に最も近いポイントを選択するようにしています。
# 信頼性 - サービスダウンやパフォーマンス悪化等、ユーザー体験が著しく損なわれる可能性が高い or 既にユーザーへ悪影響がでている ->4 - 信頼性を下げている原因となっているが、現段階ではユーザー体験が著しく損なわれる可能性が低い ->3 - 現状は問題として顕在化していないが、解消するとより信頼性の向上につながる ->2 - 信頼性の向上には影響がない ->1 # 開発速度 - 全体、または各Squadの機能開発速度を既に大きく妨げている原因となっている or 開発速度を著しく下げている可能性が高い ->4 - 開発速度を下げる要因の１つではあるが、現段階では致命的な問題になっている可能性が低い ->3 - 現状は問題として顕在化していないが、解消するとより開発速度の向上につながる ->2 - 開発速度の向上には影響がない ->1 # 運用効率化 - SREの運用業務の負荷が既に高く、自動化することで運用コストが大幅に削減できる ->3 - SREの運用業務の負荷がそこまで高くないが、自動化することで運用コストが削減できる ->2 - 運用作業の自動化によって運用コストの削減につながらない ->1
実際にSREチームで運用している課題表はこのようになっています。
基本的に優先度が高い順に着手していくルールにはなっていますが、運用開始時点からルールで縛りすぎると柔軟に対応しづらくなってしまうので、多少の前後は許容することにしました。 また、システム自体も日々刻々と変化しており、課題も時間が経つにつれ優先度も変動があるはずなので、定期的に見直し会を開催し優先度をすり合わせたりと運用面も改善していっています。
4. 運用負荷の計測
皆さんご存知の通り、Googleでは手作業による運用業務の割合がSREが受け持つ全業務のうち50％以下に抑え、それ以外の時間は長期間のエンジニアリングプロジェクトのために時間を費やすことを目指しています。 「手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する」*1という特徴を持つ作業はトイルと呼ばれており、エンジニアリング作業の進捗を妨げるものです。 delyのSREチームでも自分たちがプロジェクト業務に時間を割けているのかどうかの判断が肌感覚になっていたので、GoogleSREのこちらの記事を参考に計測、トラッキングしていくことにしました。
Googleと異なっている点は、トイルだけではなく、プロジェクト業務（SRE課題の取り組み）とオーバーヘッド（MTG、1on1、評価等）以外のものは全て計測対象にしたことです。 何故ならトイル自体が明確にトイルである、トイルではないと二分することが難しく、スペクトラムとして考えるほうが良いので*2、トイルのみを洗い出して計測するよりも運用業務全般を対象にしたほうが負荷が高いタスクが可視化されやすく、改善のためのアクションを取ることができると判断しました。
実際の計測方法は、1週間で運用業務に費やした時間と対応した回数を記録していき、1週間の勤務時間あたりどの程度運用業務に使っているか割合を出しています。 最近の運用負荷の変動と内訳を集計した結果は以下のとおりです。
運用開始時は、ちょうどテレビ番組にてクラシルのレシピ紹介が大きく取り上げる機会が近かったこともあり、負荷対策に時間を使っていたため一時的に運用負荷が高い割合となっていましたが、レビューが一部のメンバーに集中していたり、開発者依頼の運用タスクが一部負担が大きく効率が悪かったので、この部分は改善に取り組んできました。 レビューに関しては、一部のメンバーに偏らないようランダムアサイン方式に変更したり、運用タスクに関しては自動化や開発者自身でも対応できる部分を増やすために環境整備を実施してきたので、運用負荷は徐々に減少しています。
5. SRE月報の実施
最後にSREの社内認知の拡大のために取り組んでいる内容について紹介します。
SREの存在価値を最大限発揮してしていくためには、他のチームやステークホルダーのサポートや理解が必要不可欠です。 しかし、現状delyのSREチームは、他のチームから見るとSREが普段どのようなことに取り組んでおり、何を改善しているのかが見えづらく、SREの役割を理解しづらいという問題があります。
SRE自体の認知が低い状態でSREのプラクティスを実践していっても、浸透しなかったり形骸化してしまいますし、まずは自分たちが普段どんなことに取り組み、何を改善して成果をあげているのかを可視化し、知ってもらうことが必要だと考えたので、システムの現在の状態や傾向、その月に発生した障害の話やSREメンバーが改善した項目について月ごとに共有していくことにしました。
もちろんこれだけでSREの認知度や理解度が上がる訳ではないので、今後他にも社内認知拡大のための取り組みを実施していく予定です。
最後に
今回は、SREチームが自分たちの価値を最大限発揮できるように取り組んできたことを5つ紹介しました。 淡々と今までやってきたことを書いていますが、現在に至るまで様々な紆余曲折がありました。 まだチームとして始動したばかりで発展途上だと思うので、これからも良いプロダクトを作っていくために、システム設計、運用を改善していきたいです。
私たちがチーム立ち上げ期にどのようなことに苦戦し、乗り越えてきたかなど少しでも興味を持っていただけたら、是非カジュアルにお話ししませんか。
https://meety.net/articles/t2--tr6k9sxi_jomeety.net
delyでは全職種採用強化中です。気になる方は以下のリンクから募集職種一覧がご覧いただけます。 speakerdeck.com
