こんにちは、SmartHRで人事評価機能の開発を担当している@takeshi_o4です。本記事では、人事評価機能開発チームでSLOを導入して改善したプロセスを書いていきます。
2024年に人事評価機能開発チームにSLOを導入しました
現在SmartHRではSLOの導入が推奨されています。
これに先立って、人事評価機能開発チームでは2024年にSLOを導入し運用を開始していました。
直面した課題
SLOを導入して運用してみると、以下のような課題に直面しました。
- 外部APIのパフォーマンス低下が、直接SLO違反につながってしまう
- 対応工数が莫大なことで、SLO対応が後回しになってしまう
- しきい値の設定難易度が高い
外部APIのパフォーマンス低下が、直接SLO違反につながってしまう
人事評価機能では、従業員情報はSmartHR基本機能のAPI（外部API）から取得しているため、対象SLIの中でどうしても外部APIのパフォーマンスに依存が発生してしまいます。 そのため、チーム内で開発していたこと以外の要因でもSLO違反が発生してしまう状況でした。
対応工数が莫大なことで、SLO対応が後回しになってしまう
上記の問題を解決するにはSmartHR基本機能に対して修正が必要になるのですが、コードベースが巨大で影響度も大きいためロードマップになかなか組み込めません。
その結果として、対応ができないままSLOのモニタリングが形骸化してしまうという課題がありました。
しきい値の設定難易度が高い
そもそもな話ですが、SLOとして設定するしきい値が本当に正しい値かどうか確信を持てていませんでした。 当初はえいやで設定していましたが、値に理由があって、目指すべき指標かどうかは判断することが難しい状態にありました。
また、実際にSLO違反が起きた時にサービスに大きな影響があったかと言われるとそうではありません。 そのため、「守らないでも問題ないのだから設定していても意味ないじゃん」といった心境にチームがなってしまったと考えられます。
改善アプローチ
これらの課題に対応するため、SmartHRのSREユニットと連携をして以下の改善を実施しました。
- SLOへの考え方を修正する
- SLOのしきい値を緩めるという選択肢を追加する
SLOに対する考え方を修正
導入時点で、SLOに対しては「絶対に守らないといけない不変なもの」という考えがありました。
この問題に対応するために、SLOの認識を以下のように修正しました。
「SLOは可変であり、サービスの信頼性を保ちつつ開発を継続するための指標」
SLOのしきい値を緩めるという選択肢を追加
SLOが可変になったので、実際に違反した場合は状況を鑑みてしきい値を緩める選択肢を入れました。
これによって、実際にサービスがユーザー様の信頼性を損なう（解約やお問い合わせの増加につながる）しきい値を探りつつ、開発を進めることができるようになることが期待されます。 適切なしきい値を探ることができるので自動的にしきい値への確信も高まり、守るべき指標という認識を持つこともできます。
実際に今まで運用をしてみたところ、SLOのモニタリングが形骸化せずにチームの開発も進められています。
今後の展望
今回の改善により、開発と信頼性担保の両輪を回せる体制が整いつつあります。 しかし、SmartHR基本機能に起因したSLO対応には依然として大きな工数が必要なため、今後他チームとも連携して改善予定です。
まとめ
SLOの運用を通じて、以下の知見を得ることができました。
「サービスの信頼性は、固定的な目標値ではなく、継続的な改善プロセスとして捉えることが重要」
今後も、サービスの信頼性を維持しながら、効率的な開発を進めていきたいと考えています。
We Are Hiring!
SmartHR では一緒に働く仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
