はじめに

こんにちは、クラシル開発部SREチームの松嶋です。

今年の10月に「SREがプロダクトの価値を最大化するためにチームとして取り組んできたこと」と題して、私たちが足元課題解決型の体制から脱却し、チームとして効果的に機能するために取り組んできたことについて5つ紹介しました。 tech.dely.jp

こちらの記事で紹介している取り組みは、クラシルというプロダクトの成長を加速させていくために私たちは何をすべきなのか議論し、必要なことを地道に取り組んできただけなので、「これをやれば上手くいく！」というような銀の弾丸になるアクションは特にありませんし、SREがチームとして価値を発揮できるようになるまでにも約1年と長い時間がかかっています。

「SREの追求」の3.1章*1でも述べられている通り、「適切に機能するSREチームには時間をかけて熟成される文化があり、組織であらたににチームを始めるのは、長期に及び多大な取り組みを要するプロジェクトとなる」とありますし、SREを自分たちの所属する組織に適用させていくことの難しさ、大変さをこの期間に身を持って感じました。

しかし、日々チームメンバーと議論を重ね、トライアンドエラーを繰り返してきたので、Googleが提唱しているSREの信条に基づいた上で現状のクラシルの規模やフェーズにあったSRE文化を確立するための基盤ができつつあると思います。

その中でも私たちが特にこだわってきた部分は、データ駆動型のアプローチを取れるチームにすることでした。なぜなら、拡張可能なチーム体制を構築していくには、メンバー間の共通認識を増やし、できる限り客観的な判断を下すために数値に落とし込む必要があったためです。

実際に私たちがこのアプローチを取れる状態になってからは、以前より意思決定がしやすくなり、運用改善スピードが格段に向上したと感じているので、本記事では、前回触れなかったSREチーム体制を構築する上で意識したことやそれによって得られた成果について書きたいと思います。

徹底して言語化する

データ駆動で動こうとする前に、まずは自分たちの目指していくゴールや役割を徹底的に言語化し足元を固めることが重要だと思います。なぜなら、ゴールが定まっていない状態で何らかの数値を取得、計測し始めても、その値は自分たちが目指すべきゴールに向かうために必要な指標になっているとは限らず、本質的なアプローチができないと考えているからです。

また、言語化するということはメンバー間の共通認識を増やし、認識齟齬を最小限にすることにも役に立つので、自分たちの核になる部分は早いうちに言葉に落とし込んだ方が、普段のコミュニケーションや業務を円滑に進められるのではないかと思います。

例えば、現在の私たちのミッションは「delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。」となっていますが、このミッションに辿り着くまでにも何度も議論と推敲を重ねてきました。

下記のミッション決定までの変遷を見ると、delyのバリュー*2がSREのミッションと紐付けられ、「事業継続性」の言葉が持つ意味が噛み砕かれて「プロダクトの価値最大化」に置き換えられていることが分かります。「事業継続性」という言葉を置き換えたのは、SRE以外の開発部メンバーにもヒアリングを行ったところ、この言葉の受け取り方が人によって異なっていたためです。ミッションはチームの顔でもあり、SRE以外のメンバーにも私たちの考えが正確に伝わる必要があると考えているため、delyのSREらしさを表現できる「プロダクトの価値最大化」という言葉を採択しました。

# 再考前
クラシルの信頼性や事業継続性を担保しつつ、ユーザーに価値を素早く提供できるように設計と運用を改善し続ける。

# 仮決定
delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、事業継続性の維持・向上をシステム運用において担保する。 
その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。

# 本決定
delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。
その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。

このように、SREチームの目指すべきところを明確に言語化することで、「私たちはプロダクトの価値最大化を実現するために、システムの設計と運用において最善なアプローチは何か」という思考を持って業務に取り組めるようになったと思います。

また、SREが解決していくべき課題のアプローチ方法として、「信頼性」、「開発速度」、「運用効率化」の指標に重みを付けているという話は前回の記事で書きましたが、こちらも同様で、メンバーによって重みの定義の解釈が異ならないように具体性を持たせ、重みの判断に迷わないようにしました。

# 信頼性
4pt: サービスダウンやパフォーマンス悪化等、ユーザー体験が著しく損なわれる可能性が高い or 既にユーザーへ悪影響がでている
3pt: 信頼性を下げている原因となっているが、現段階ではユーザー体験が著しく損なわれる可能性が低い
2pt: 現状は問題として顕在化していないが、解消するとより信頼性の向上につながる
1pt: 信頼性の向上には影響がない 

# 開発速度
4pt: 全体、または各Squadの機能開発速度を既に大きく妨げている原因となっている or 開発速度を著しく下げている可能性が高い 
3pt: 開発速度を下げる要因の１つではあるが、現段階では致命的な問題になっている可能性が低い 
2pt: 現状は問題として顕在化していないが、解消するとより開発速度の向上につながる
1pt: 開発速度の向上には影響がない 

# 運用効率化  
3pt: SREの運用業務の負荷が既に高く、自動化することで運用コストが大幅に削減できる
2pt: SREの運用業務の負荷がそこまで高くないが、自動化することで運用コストが削減できる 
1pt: 運用作業の自動化によって運用コストの削減につながらない

細かい部分ではありますが、自分たちのコアとなる部分の共通認識を揃えることで、課題レビュー時の観点としても流用できるので、レビュイー、レビュアー双方の議論も円滑に進みやすくなったと感じています。

効果が伝わりやすい指標を持つ

SREのようなシステム運用に責務を持っているチームは、ビジネスや機能開発を担うチームと異なりKPIとなり得る指標を定めることが難しい側面を持ち合わせていますが、SREが行った改善業務がどの程度システムにインパクトを与えるものなのかを定量的に示す指標がある方が良いと考えています。なぜなら、チーム内の意思決定を円滑にするだけではなく、チーム外のメンバーにも私たちSREの成果を伝えやすくするためです。

SREと言えば、SLO/SLIで使われている信頼性や開発速度を表すメトリクスに対して目標値を設定し、チームのKPIとして定めるのが分かりやすいですが、これらの指標計測だけだと私たちの改善業務がどれくらいのインパクトを与えるものなのかはチームや部署が異なると伝わりづらいのではないかと思います。*3

その理由について、クラシルを支えるシステムを例に説明します。

クラシルは、デプロイ起因やAWSの障害によって一時的に信頼性の指標が悪化することはありますが、SLO違反することはほとんどなく安定した状態を保っています。これは、想定外の複雑さによって信頼性が低下することを防ぐために、SREがサーバーサイドの設計レビューに参加していたり、サーバーサイドのメンバー自身も意識的にアプリケーションエラーの改善に取り組む文化が既に形成されているからです。

このような安定したシステムにおいて、例えば、信頼性が下がるリスクを未然に防ぐような改善を実施したとしても、SLOに定めている指標の変化は微々たるもので、他のチームから見るとSREの改善業務による影響度が小さく感じてしまうかもしれません。

このような問題の有効な解決案の1つとして考えられるのは、私たちのチームが課題の優先度を決定するときにも使っている信頼性、開発速度、運用効率化の指標でSREの改善業務の影響度を示すことです。これらの指標は、私たちが解決すべき課題の優先度順を定量的に表している値ですが、これはシステムに対してどの程度インパクトを与える改善なのか示す指標でもあるので、業務内容を詳しく知らないチームから見てもシステムの改善状況や影響度を理解することが容易になり、自分たちが上げた成果がより伝わりやすくなります。

SLOで定めている指標の他にもSREの改善業務のインパクトを示す指標を持っておくことで、複数の側面からSREが成し遂げた成果について話すことができますし、数値データがあることによって客観的な判断を下すことが容易になるので感情論を挟まなくても良くなるでしょう。

単純さを保つ

「SRE サイトリライアビリティエンジニアリング」の9章「単純さ」*4にも、システムの想定外の複雑さを減らし単純さを追求することが信頼性と開発速度の向上につながると書かれている通り、運用負荷の計測など直接システムに関わらない業務においても、できる限り単純さを保つことはチームの負担とストレスを増大させないためにも重要だと思います。

例えば、私たちのチームの運用負荷計測におけるルールは、基本的に以下の3つです。

プロジェクト業務（SRE課題の取り組み）とオーバーヘッド（MTG、1on1、評価等）以外のものは全て計測対象すること
計測対象の運用業務に費やした時間と対応した回数を記録すること
1週間の運用負荷が50%を超過する場合、対応フローに沿ってネクストアクションを決めること

ルール自体はシンプルさを保ち、あらかじめ振り返り観点・高負荷時の対応フローを明確に定義しておけば、運用コストを最小限に抑えられます。

f:id:akngo22:20211220212130p:plain — 高負荷時における対応フロー

何かしら新しい仕組みを導入するときは、人間の判断疲れを防ぐためにもどの程度の負荷であれば許容できるのかメンバーと話し合って設計してください。必要かもしれないという理由だけで最初から多数の計測を始めてしまうと、自分たちの目的からずれて意味のない計測になってしまったり、管理コストだけでなくチームのストレスが蓄積してしまったりするので気をつけましょう。

また、単純さを保つためには、定期的な振り返りや見直しも必要だと思います。 delyはクォーター制を導入しており、3ヶ月に1回目標設定するタイミングがあるので、その機会に合わせて運用負荷計測やSRE課題の運用方法について振り返り会を実施しています。振り返り会以外にも「これやりづらいのでは？」と感じたらSlack上でヒアリングしたり、サクッと口頭で話し合うようにしているので、微調整は随時行うことで運用が形骸化しないように工夫しています。

SREチームの半年間の成果

私たちのSREチームが本格的に始動してから約半年が経過したので、実際にどれくらいの改善が進んでいるか報告したいと思います。

SRE課題

私たちのプロジェクト業務であるSRE課題の取り組みの進捗は、全51個の課題中8個の課題が対応完了し、優先度の消費ポイントに換算すると全体の29.4%の改善が進みました。実際にどんな課題が解消されたかというと、アプリケーション動作に対する権限付与の最小化や動画変換で使われている自社開発基盤のブラックボックス化の解消、その他運用効率化のための改善業務が実施されました。

f:id:akngo22:20211221095001p:plain — SRE課題表

また、対応完了した課題はSRE月報にも記載するようにしており、Slackの開発部チャンネル上でも共有を兼ねて報告しています。どんな取り組みが行われたかについては、より多くのメンバーに興味を持ってもらえるようにポップ感と分かりやすさを重視しています。

f:id:akngo22:20211221004324p:plain — SRE月報を発行したときのお知らせ

運用負荷の変動

運用負荷に関しては、8月に計測を始めてから次第に減少傾向を示し、現在は20％付近で推移しています。運用負荷が減少傾向であるのは、この半年間で取り組んだ課題が運用負荷に影響を与えるものが多く含まれていたことや変動が可視化されることで自分たちの意識が運用負荷やその偏りを減らす方向に向くようになってきたことも要因の1つかと思います。

f:id:akngo22:20211220183156p:plain — 運用負荷の計測

最後に

今回は、前回の記事では触れなかったSREチーム体制を整備する上で意識したことやそれによって得られた成果について書きました。書かれていることは当たり前のことではあるのですが、当たり前だと思っていても意識していなければおざなりになりやすい部分でもあると思います。そういった部分を改めてチームで議論し、クラシルのSREはプロダクトに対してどのようにアプローチするのがベストなのかを考えられたので、時間はかかってしまいましたが良い機会だったと感じました。

実際に取り組みを進めていくと、チームの暗黙知になっていた部分が可視化されたことで隠れたストレスが減少したり、数値データに基づいて意思決定できるのでチームが自律的に動けるようになったなど、メリットが大きいと感じています。これからも、よりSREの価値を最大化しプロダクトの成長を加速させていくために、システム設計、運用を改善していきたいです。

最後になりますが、クラシル開発チームでは、現在以下の職種を絶賛大大大募集中です！