こんにちは。delyのSREの井上です。
delyは先日開催されたSRE NEXT 2020にGOLDスポンサーとして協賛をさせていただきました！当日はセッション枠を頂き、「delyにおける安定性とアジリティ両立に向けたアプローチ」をテーマに発表もさせていただきました。
セッションでは、
- 前半：SRE本に則った理論の話
- SREはプロダクト開発の速度を安全に高めるために存在しているということ
- プロダクト開発の速度を安全に高めるためには単純さを追求することが重要であること
- 後半：前半の理論に則ったdelyでの実践の話
をしました。スライドは公開済みですが、それだけだと伝わりにくい内容も含めてブログにも投稿させていただきます。
当日は多くの方が参加されていました！
SRE NEXTに参加してみて
SRE Loungeの勉強会は#5以降の会は全て参加させて頂いているのですが、いつも有意義な情報が得られて登壇者や運営の方には感謝しかないなと思っていました。なので、SRE NEXTでスポンサーという形でコミュニティに貢献できたことは良かったなと感じています。登壇の機会を頂けたことも感謝しかなく、今後も引き続きよろしくお願いしますという感じです。
個人的にすごく印象に残ったのはSREの今後というトピックでした。時代の変化でアジャイル開発やスクラム開発が当たり前の存在になったように、おそらくSLOやエラーバジェットも今後何かのフレームワークに落とし込まれて開発文化に取り入れられていくのだろうと思いました。そうなるとSREの存在意義はほとんどなくなるので、どういった形に役割が変化していくのかなというところを考えるのも面白そうだなと思いました。
目次
SREの存在意義
SREは「信頼性を高めるため」ではなく、「プロダクト開発の速度を安全に高める」ために存在しているということを出来る限り分かりやすく伝えるべく、SRE本に記載されている内容を元に順序立てて説明をしていきました。
SREが成し遂げようとしていることは結局SREだけでは達成できず、必ずプロダクト開発チームやマネジメント層との連携が必要になります。他組織と連携するためにもSREが何をしようとしているのかを誰もが理解できるように、可能な限り噛み砕いてスライドに落とし込みました。
旧来のサービス運用と組織分離
AWSやGCPが存在しない時代における「システム管理者」の業務は、既存ソフトウェアの活用だったので、サービスの運用業務はソフトウェアの開発業務とは別のスキルセットが必要とされました。
サービスが成長してくると、必然的に運用業務に人手が必要になるので人員調達の観点からほとんどの企業で開発と運用の組織が分離されました。
この組織分離には人員調達以外の点で大きなデメリットが存在します。
組織分離によって発生するコストとSRE
組織分離によるデメリットは直接的なコストと間接的なコストに分けられます。
- 直接的なコスト
- 手作業の運用業務による人件費の増加
- 間接的なコスト
- 目標の違いが引き起こす対立構造による開発スピードと安定性の低下
- 開発組織の「新しい機能を早くリリースする」という目標
- 運用組織の「サービスに問題が起きないようにしたい」という目標
- 目標の違いが引き起こす対立構造による開発スピードと安定性の低下
これらのコストに対するGoogleのとったアプローチがSREになります。
コストに対するSREのプラクティス
SRE本に記載のあるいくつかのプラクティスをコスト別に分類してみました。
直接的なコストに対するアプローチは主に、「運用作業をどのように自動化するのか」と「自動化に使える時間をどうやって維持するか」の大きく２種類に分かれます。
間接的なコストに対するアプローチは主に「組織間の対立構造をどのように解消するか（発生させないか）」に焦点を当てたものになり、SLOやエラーバジェットはこちらに分類されると考えています。
SRE NEXTでもどちらの内容をテーマにするのか発表ごとに分かれていて、どちらに課題感を大きく感じているのかを考察しつつ聞くのもまた面白かったです。delyの発表では間接的なコストの方に対するアプローチについてお話しました。
対立構造が引き起こすプロダクト開発速度の低下
SRE本の中で「間接的なコスト」として語られている内容を図に落とし込みました。開発と運用の目標の違いが最終的にプロダクト開発速度を低下させる構造になっています。
重要なポイントとしては、開発／運用の組織体制が開発／SREという組織体制になったからといって、ただそれだけでこの対立構造が解消するわけではないという点です。
開発速度／安定性のバランスのコントロール
プロダクト開発速度を最大化させるには、開発速度／安定性のバランスをコントロールする必要があります。
ある項目において開発速度と安定性どちらを取るのか決めなければいけないタイミングが多々あると思いますが、客観的なデータがない限り交渉力のある人であったり立場のある人の一声で最後は決まってしまうと思います。
その場合、誰かの感覚がバランスを取っているということになると思うのですが、その「誰か」はどこかの組織に属しているはずなので結局、対立構造は解消しないということになってしまいます。
エラーバジェット
「誰かの感覚」に終止符を打つSREのプラクティスがエラーバジェットです。
予算がなくなった時点でリリースできなくなるという超強力なポリシー・・・！
機能のリリース速度を最大化するためにエラーバジェットの導入をSREの目標としましょうという内容がSRE本には記載されています。
エラーバジェットによって目標を統一することで、開発速度と安定性をコントロールしプロダクト開発速度の最大化を図ることが可能になります。
SREの存在意義の再確認
エラーバジェットの仕組みからも読み取れる通り、SREはSLOやエラーバジェット等のプラクティスを駆使して組織の対立構造を解消し、プロダクト開発の速度を安全に高めるために存在しているということが言えると思います。
エラーバジェットとは別のアプローチ
とはいってもエラーバジェット導入の難易度って時間がかかりますよね。なので、SRE本に載ってるプロダクト開発の速度を安全に高めるための別のアプローチも同時に紹介しました。
エラーバジェット導入の難易度
エラーバジェット導入の難易度はとても高いです。
「その期間のエラーバジェットを消費しきったら残りの期間リリースができなくなる」というルールは、運用しているサービスのビジネスモデルによってはかなり厳しいポリシーだと思います。
もちろん、SREの文化を浸透させ最終的にはエラーバジェットの導入を目指すべきだとは思いますが、導入しようと思って数日でできるような手軽なアプローチではないことは間違いないです。
SRE本においてはエラーバジェット以外にもプロダクト開発の速度を安全に高めるためにSREがすべきことについて触れており、発表ではその内容について紹介しました。
それは想定外の複雑さの削減と単純さの追求です。
想定外の複雑さとSRE
SRE本においては開発速度と安定性がどちらも低下する要因として想定外の複雑さを挙げています。
具体例としては、ソフトウェアの領域においては密結合なソースコード、インフラの領域においては手作業で構築されたサーバなどが挙げられます。
想定外の複雑さはレイヤーに関係なく発生しますが、どこに存在していたとしても開発速度と安定性のどちらも低下させる要因になってしまいます。
SRE本には想定外の複雑さに対してSREがとるべき行動が記載されています。
- 受け持っているシステムに想定外の複雑さが生じていたら差し戻す。
- 関わっているシステムや、運用を受け持つことになるシステムから複雑さを取り除く努力を継続的に行う。
単純さの追求による開発速度と安定性の両方の向上
ソフトウェアやインフラなどの領域に関わらず、想定外の複雑さを継続的に削減していくことと、想定外の複雑さを新たに作り込まないことが、開発速度と安定性を両方高めていくためには必要です。
delyでの実践
後半はdelyにおける実践の話をしました。
正直なところ、他社の参考にできそうな奇抜な施策が出来ている状況ではないです。そもそも当たり前なことがまだちゃんと出来ていない状態なので、ひとつひとつの課題解消を愚直に進めつつ基盤を整えているフェーズです。
そういったフェーズの会社が他にも存在すると思ったので、やっていることは割と普通なのですが、dely自体のことも知ってもらえる良い機会だと思いいくつか紹介させて頂きました。
規模とフェーズ
サービスや組織のフェーズをまず知ってほしいと思ったので、サービスの規模とメンバーの増加傾向がわかるようにグラフを見て頂きました。
おかげさまでサービスは年々成長を続けていて、開発のメンバー数も増加傾向にあるのですが、注目してほしいのは2016年から2018年までの2年間、サーバサイドがほぼ１人での開発だったというところです。
この頃の状況は下記の２つの記事から読み取ることが可能です。
2019年前半までとにかく機能リリース優先でやってきたこともあり、最近になってサービスの成長に伴って品質やセキュリティなどの点でいろいろな問題が発生し始めました。
課題
クラシルは開発開始から４年ほどが経っています。当然のように様々な課題を抱えています。
現状の課題が多いからといって、今までの選択が決して悪かったというわけではないですが、フェーズが変われば課題も変わるということは事実なので、話し合うべきなのは 「これからどうしていくか」というところだと思っています。
具体的なアプローチ
delyでは直近１年をかけて想定外の複雑さを減らし、今以上に増やさないための文化づくりをしてきました。
下記の３つの視点でアプローチを行いました。
- 何が複雑なのかを認識し共有することにより可視化する
- 複雑なものを減らす計画
- 複雑なものを新たにつくらない仕組みづくり
想定外の複雑さを減らすアプローチ
改善MTG
複雑さの箇所を可視化するために行っているのが改善MTGです。想定外の複雑さを一番把握しているのは現場のメンバーですが、改善MTGを実施することでその感覚を言語化し、メンバー間で共有することを目的にしています。
想定外の複雑さも誰かの感覚の中にある限り、解消することは理論上不可能です。しかしMTGを行いメンバー間で議論を行うことで、感覚の先の根本的な課題が明確になっていき、どういった対応が考えられるのかや解消によって得られる効果などが言語化されます。PdM等のタスクの優先順位付けに決定権を持つ人が、機能開発タスクより改善タスクの優先度を上げるという意思決定をできるように可視化しておくことが想定外の複雑さを解消するためには必須であると考えています。
改善MTGの詳細については既に記事があるので興味があればこちらを読んでみてください。
課題洗い出し会
改善MTGも運用開始直後においては課題の提案が特定のメンバーに偏るという課題がありました。その課題に対して行ったのがこの課題洗い出し会になります。
課題が潜んでいそうな技術分野をリストアップし、メンバー間で回答が見えないようにそれぞれの分野に対する課題感を回答してもらいました。その回答をマージして課題感がメンバー間でずれている箇所に対して議論をします。議論した内容をもとに課題を登録してもらうことで、今までなかった観点の課題が提案されるようになりました。
課題の提案もある程度慣れが必要な部分だとは思うので、不得意なメンバーでも提案しやすくなるような仕組みや、新しいメンバーが遠慮してしまわないような工夫が重要だと考えています。
リファクタリング計画
改善MTGはあくまで可視化までが目的になっているので、解消していく工程については別途、別の手段で進める必要があります。誰か１人が進めるのではなく分担して解消していく必要があるので、やみくもに進めるのではなく計画をたてるようにしています。
スプレッドシートに今抱えている課題を一覧化して、重要度と緊急度の観点から優先順位を議論して決めます。優先順位に伴って、誰がどの課題を解消するのか担当を埋めていきます。あとは担当者が愚直に解消していくという感じで進めています。
詳細については既に記事があるので興味があればこちらを読んでみてください。
想定外の複雑さを増やさないアプローチ
設計レビュー
増やさないためのアプローチの一つとしては設計レビューを紹介しました。
想定外の複雑さを解消していっても、別のところで随時新しく生まれていたら削減している意味がないです。
サーバサイドエンジニアの数が増えてきたタイミングで、コードを書き始める前に設計完了時点でレビューをするように開発フローに組み込みましたが、SREもSLOの維持に責任を持っているので、アーキテクチャの観点など想定外の複雑さが発生していないかレビューできるようにSREも参加を必須にしています。
内容によってはかなり時間をかけて議論を行っていて、コードを書く前から全員で徹底的に議論を行うような文化が出来ています。
このあたりの内容はコアすぎてあまり書けないのですが、何かの振り返りのタイミングで記事を書いて共有できればと考えています。
意識
目的と手段の可視化
いろいろなアプローチを考えつつ複雑さを解消しているのですが、複数人で分担していくと、ついついリファクタリングすること自体に目がいってしまいがちで、本来の目的を見失うことが少なからず発生してしまいます。
リファクタリングすること自体が目的化してしまうと、つい必要のないところまで手を伸ばしてしまうと思うのですが、それをやってしまうと今やらなくてよいものまで実施してしまうことになるので、今までのアプローチの効果が薄れてしまいます。
なので目的と手段を可視化することで、今やっているタスクが何の目的の手段にあたるのかということを常に意識できるようにしています。
例えば、リファクタリングや開発ガイドラインの見直しなどはタスクに分解すると、不足しているテストの作成や開発フローの見直しなどになりますが、これらのタスク自体も手段であって目的のために行っているという状態になっているはずです。意識しなければいけないのは目的の方であり「開発速度と安定性の両方の向上」や更にその上の事業の成長になります。
さいごに
偉そうなことべらべら書いてる割にdelyのSREは実は全然始まってすらいません。少しづつ始めている内容は下記の記事にかいてあるので是非読んで頂きたいです。
もちろんSREを絶賛募集しています！クラシルの開発スピードを落とさず、信頼性も担保するという難易度の高い課題に挑戦したい方はぜひ声をかけてください！
delyの開発チームについて詳しく知りたい方はこちらもあわせてどうぞ
