「今ならこうする！SLO導入の失敗と4つの教訓」タイミー 岡野 兼也

基調講演はこちらからご覧ください

●Event report信頼性と品質 / システム運用と管理

「SRE入門：『SLO サービスレベル目標』監修者が解説する実践とメリット」 グーグル合同会社 山口 能迪

2023.08.14

約4分

タイミー社でバックエンドエンジニアを務める岡野さん。2年半のSLO導入・推進で得たメリットや失敗・教訓を紹介します。

タイミーとは？

タイミーは「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービスです。単純なマッチングサービスではなく、案外複雑で、成長速度が速いということを念頭に置いたうえでSLOの事例を紹介させてください。

開発組織とSLOの歴史

SLOを導入する2年半の間の組織編成をまとめました。

SLOを導入した2つの理由

もともとエラー発生頻度は少なく、500系エラーは全て対応できる体制（1回のエラーでもオンコール対応が可能な運用）でした。しかし会社が急成長すると、運用が困難になり、500系エラーの修正が後回しにされる頻度が多くなりました。また、可用性100%を目指すことで、99.99%を目指しているときよりも信頼性が下がっていると感じ、適切な高さの目標（ = SLO）を導入することになりました。

SLO導入の成果

左は2023年6月の結果です。4つのSLOを設定しています。iOSは、障害の影響で少し数値が下がっていますが、全体的には高い水準を保てていると思います。右は、導入直後との比較です。iOSのクラッシュフリーレートはもともとの数値が良かったので大幅な数値の改善は見込めないものの、ほとんどの項目で数値の向上がわかります。もちろん様々なエンジニアの努力の賜物ですが、サービスを成長させながら信頼性向上に成功したことは大きな成果だと思っています。100%を目指さないことによる信頼性の回復を実現できたと考えています。

失敗から学んだ4つの教訓

成功の裏にはたくさんの失敗があります。失敗から学んだ4つの教訓を共有します。

失敗と教訓 1.  一緒に働く同僚の納得を大事にする

SLO導入時、非技術職の方々には信頼性100%を目指さない方が良い理由や、SLOで実現したいことを丁寧に説明しました。一方、エンジニアへの事前相談は簡易的なものでした。それは、SLO導入へ強い反対がなかったこと、また「話の理屈さえ通していけば、行動を変えてくれるだろう」という思い込みからの行動です。結果的にスムーズな行動変容は起こりませんでした。戦略を成功させるためには「文化」が必要だったんです。

文化は戦略を朝食として食べ、技術を昼食にプロダクトを夕食に、その後全てを飲み込んでしまいます。これはMITの教授の言葉で、組織の成功のためには、文化を戦略的に作ることが大事だと語っています。SLO導入がうまくいかないことを上長に相談した際「3割の人間の行動を変えてください」と教わりました。組織の中で3割の集団ができると、組織全体の文化に影響を与えることができるのだそうです。

具体的には、興味を持ってくれていて、行動が変わりやすそうな 30%の人を見付けると良いとのこと。これまでエンジニアと対話するときは、筋道を立てて全体と会話することが大事だと思っていたので、すごく驚きました。

重要なのは文化の醸成、SLOはあくまで手段

結局のところ、作りたいのは文化です。文化を作れるのなら、SLOは不要だとも考えています。ただ、言葉だけで文化を作っていくのはかなり難易度が高いので、SLOを利用して3割の人間の行動を変えることで、組織の文化が醸成していくという道筋になるのではないでしょうか。

今ならこうする！

本当にやるべきことは、外部からの承認よりも隣のエンジニアの行動を変えることでした。マネージャーや他部署の承認や理解を得ることで、問題なく事が運ぶと考えていましたが、結果は違いました。「今ならこうする！」と思うことをまとめたので参考にしてみてください。

まず、興味を持ってくれそうな30％の人を事前に探して、俗に言う根回しをします。そのうえで周りを固めます。実際に行動を変える人（エンジニア）の足枷になりそうな懸念点があれば、可能な限り排除しておきましょう。

なぜ事前に人を探すのか

人の関心は物事が始まった瞬間が最も強いです。この瞬間に仲間をつくることを意識すると良いでしょう。

失敗と教訓 2.  変化しやすいものに依存させない

タイミーにおいてチームの運用が安定しているか？答えはノーです。タイミーは法律や労務などの要件が多く機能も豊富です。そのほかにも、いくつもの要因が重なり、結果としてソフトウェアは現時点でもモノリスです。

こんな状態だと、チームのミッションはビジネスに対する解像度が上がったタイミングで整理されます。多くの場合、ミッションに合わせ、様々な運用も見直されます。スクラムイベントも同様です。

私はスクラムイベントにSLOの運用を依存させていたため、フェーズ5への移行時に、全部作り直すことになりました。今のSLO運用はマッチング領域に持たせています。フェーズ3・4を経て、マッチングとスポットワークシステムの切れ目は安定したと思ったためです。一方でプロダクトマネジメントの単位はチームです。結果としてエンジニアがチームに対して干渉しにいく必要があり、そこまでうまく回せている自覚がないのも事実です。この運用に関しては模索中なので、良い方法があれば教えてください。

運用を考え直すのは、結構エネルギーが必要です。

失敗と教訓 3.  重要すぎる指標をSLIにしない

APIのWriteアクセス成功率をSLIにしていた時期があり、そのなかでもマッチングや給与振込、勤怠に関しては少数のエラー発生を許容できず、オンコール対応や改善を行っていました。これは「信頼性の高さ」という観点では問題ありませんが、「信頼性と機能開発のバランス」においては、SLOの意義がありません。結果的には、削除することになりました。

重要すぎるAPIに対し、割合でエラーを許容するようなSLOを作ってしまったこと、あとは30日という期間が長すぎたことが原因だと考えています。現在は、短期間のエラー数に基づいたアラートを作成する形で対応をしています。

この件があってから「非機能要件の緩やかな低下を防ぐ」というSLOの目的を追加しました。このあたりは、SRE界隈でよく言われるクリティカルユーザージャーニーの考えと合致しないような気もしていますが、自分の中では結構すっきり整理されてます。

失敗と教訓 4.  とにかく続ける

SLO導入は、推進者の心が折れると全てが終わります。私の実体験ですが、振り返り、課題提起、実施を1人で行っていると「何やってんだろ」という気持ちになったり、結果が伴わないとつらいです。こんな状態が続くとモチベーションがうまく管理できず、せっかく思い付いたアクションもなかなか実行に移せません。私の場合は、SLOの取り組みを続けるために運用のクオリティを落とすことにしました。

仲間をつくる・一人でも続ける

可能であれば仲間をつくってください。とはいえ、1人で何とかしないといけないときってのもありますよね。そんなときでも、続けた方がいいんじゃないかなと思ってます。私は続けるためにクオリティを落とす選択をしましたが、結果としては良かったです。

余談 カジュアル面談しませんか？

毎週、SLO改善をしているのですが、ご覧のとおり、近い未来に根本的な対策が必要です。ぜひ、助けてもらえたら嬉しいです。カジュアル面談を実施しているので、ぜひ来てください。