SHARE

目次

目次

SHARE

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

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

sre-slo-implementation-failures-lessons-learned-new-img
この記事は、2023年7月11日発売 『SLO サービスレベル目標―SLI、SLO、エラーバジェット導入の実践ガイド』翻訳・監修者の山口 氏による connpass勉強会 から タイミー社による事例講演 を再編集し、記事化したものです。

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

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

タイミーとは?

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

開発組織とSLOの歴史

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

フェーズ1(入社当初):組織は直納によってモバイルチーム、バックエンドチーム、SREチームに別れていた。専任のSREチームがあり、SLOの下準備を開始し、フェーズ2の組織再編を前に準備が整った。

フェーズ2:組織は職能ベースから顧客ベースに再編成され、ワー​​カーチームとクライアントチームになる。SLOはバックエンドチームに対象を絞り(意思決定できる部署を限定)、月に一度の振り返りと実験を行いながら運用を始める。スクラム運用と連携があまり密接ではなく、一部のエンジニアが参加している状態。

フェーズ 3:SLO の運用に慣れてきたので、開発へのフィードバックを重視。スクラムイベントで SLO を確認し、PPI(Product Performance Indicator)を SLO の状態に応じて追加。

現在:マッチング領域とスポットワークシステム領域に複数のチームが存在する状態に変化。マッチング領域にSLOの運用責任を持たせ、スポットワークシステム領域でもSLOの運用が始まる。

 

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割の人間の行動を変えることで、組織の文化が醸成していくという道筋になるのではないでしょうか。

今ならこうする!

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

  • 前準備が大切
    • やりたいことに対して興味を持ってくれそうな少数を探す
    • 興味を持ってくれそうな人に相談してみる
  • 実行
    • 上長や他部署䛾方より前に、同僚䛾行動を1人ずつ変えていく
    • 行動を変えるうえで足枷になりそうなことを排除する

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

    なぜ事前に人を探すのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

    Forkwellキャリア相談

    フォークウェルプレス編集部

    Follow

    記事一覧へ

    本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

    岡野 兼也
    岡野 兼也
    株式会社タイミー

    バックエンドエンジニア

    大学卒業後、2019年に株式会社サイバーエージェントに入社。2020年6月から現職。タイミーでは主にマッチングを担当するチームで機能開発を行う。サービスの信頼性と機能開発のバランスをどうやってとるかを模索している。