Eight における SLO の策定と浸透

■イベント


【Sansan Tech Meetup】インフラエンジニアが考えるプロダクトと組織
https://sansan.connpass.com/event/287609/

■登壇概要

タイトル：Eight における SLO の策定と浸透

登壇者：技術本部 Eight Engineering Unit Infraグループ　中鉢 雅樹



■Sansan 技術本部 採用情報

https://media.sansan-engineering.com/

Transcript

1. Sansan技術本部 Eight における SLO 策定と浸透 Eight Engineering Unit Infra グループ 中鉢 雅樹
2. 中鉢 雅樹 Sansan株式会社 Eight Engineering Unit Infra グループ - インフラ・SREとしてプロバイダーやWeb系企業など を経て 2021/07 Sansan に join - Infra グループとして Eight インフラの拡充に貢献 - 好きなものは旅⾏と温泉とVtuber
3. https://8card.net/ 相⼿の名刺、⾃分の名刺、紙の名刺やオンライン名刺。 あらゆる名刺をEightにスキャンするだけで、これまで培ってきた⼈脈やスキル、 職歴などを中⼼に、⾃分だけのキャリアプロフィールが⾃動で作成されます。 キャリアプロフィール「Eight」が、ビジネスのライフタイムに伴⾛し、 昇進や転職、キャリアチェンジした後も変わることなく、キャリア形成にエッジを ⽴てるお⼿伝いをします。 キャリアプロフィール「Eight」
4. アジェンダ - インフラチームについて - SLOの策定 > きっかけ > SLO策定 - SLO運⽤と⽂化の浸透 - 振り返り > 反省 > 今後の展望
5. インフラチームについて
6. インフラチームについて 過去 (2021/07) - ⼊社時点で 3名、それまではしばらく2名体制 > プロダクト側からの開発依頼、セキュリティ対応などで⼀杯⼀杯 - インフラはインフラだけが⾒る > アラート対応はベストエフォート。基本はインフラが⾒て各所に振る > 構築系は基盤チーム(サーバーサイド)と共に作業することが多い
7. インフラチームについて 現在 - SLO構想は3⼈時。現在は5名体制(社員4/インターン1) > 徐々に内部にも⽬を向けられるように - ⺠主化が徐々に進む > アラートは徐々にアプリ側が積極的に確認するようになってきた > SLOやDB定期観測などが徐々に浸透 > ポストモーテム等の横断的なナレッジ共有 > 設計段階からインフラ観点で意⾒できるように > 定期メンテナンスの実施
8. SLOの策定
9. きっかけ - ⼈数も増え、内部に⽬を向ける時間が増えた - インフラを定量的に評価できるようにしたい - 指標が存在しないので成⻑が⾒えない - 開発速度と運⽤コストのバランスが曖昧・属⼈的 実施に当たって - SRE本の輪読会等でインプットは進めていた - まずはできることから始めようというモチベーション
10. SLOの策定 - チーム内で議論
11. SLOの策定 議論 - 現在計測・取得できているもの、できていないものを整理 - 組織として⽬標となりうる指標を洗い出す - カテゴライズを経てSLIを定義 - SLIからSLOとしての運⽤するための閾値を決定 - まずは形にすることを⽬標に、今あるものから昇華させていった - 完成形のイメージが想像しやすい - はじめにまとまった時間でガッと議論することでベースができた - 完成形まで⾒通しが付き、やるべきことが明確になった
12. SLO運⽤と⽂化の浸透
13. 運⽤ 運⽤を開始 - ダッシュボードを⽣成 - 週次のチーム定例時に振り返りを実施 > 原因調査と対応は定形タスクとして実施 > SLO⾃体の精度も確認 - monitor (アラート)はインシデントとは別チャネルで この時の所感 - SLO⾃体がまだ未成熟 > ユーザー影響に繋がらない指標 > 暫定だった⽬標値に対して徐々に現在地が⾒えてくる - 改善の優先度が低い > 指標として⼗分に重要視されない
14. SLO⽂化の浸透のために SLOを⽤いて信頼性を評価するという⽂化を浸透させる - SLOが⽬的にならないように - インフラ以外でも信頼性を意識するように インフラ内での運⽤を経て、徐々に EU、事業部へ - SLO 策定中から EU へ共有を実施 > 定例等不定期に共有 > SLO という⾔葉の説明から実施
15. SLO⽂化の浸透のために 実際に開発側でも向き合ってもらうように - SLO 運⽤ポリシの策定 - 週次でのEU定例に振り返り取り⼊れる - サービス側で SLO を⽣成してもらう > APIやキーとなるバッチに対して設定 事業部への周知・振り返り実施 - ⽉次の部会にて SLO 振り返り実施
16. SLO⽂化の浸透のために SLO の認知向上 - 徐々に社内でも SLO という⾔葉が使われるように - 改善時の優先度が⾃然と上がった 信頼性との向き合い⽅ - パフォーマンスと向き合う機会が増えた - 信頼性を損なうようなパフォーマンス劣化を⾃然と意識するように
17. 振り返り
18. 反省 ボトムアップで進めた良い点 / 悪い点 ナレッジの少ない中学習しながら進めるのには良かった - 関係者の理解度を⾼めつつ取り⼊れることができた 運⽤のイメージを持ちながら進められた メトリックなどシステム的な指標に寄ってしまった - ユーザー体験と⾔うよりもシステム全体がターゲットとなっていた 浸透のスピードは遅め - 認知・周知する時間が必要 - 他チームとしても優先順位を上げにくい
19. 展望
20. 直近 改めて向き合い⽅を議論した - 1年後 SLO 99.95% に向けて課題を確認 > ボトルネックとなるメンテナンスとの向き合い⽅ > SLOの精度向上・さらなる啓蒙 > 問題(障害)発⽣時の対応速度向上 > ナレッジ共有や対応体制の強化 今Q実施していること - メンテナンス時間の短縮 - CUJの定義・SLOのブラッシュアップ - オブザーバビリティの強化
21. これから プロダクト側が使える指標にする - SLO⾃体の精度を更に信頼できるものへ昇華 > インシデント判断へ取り⼊れる - リリース判断 > エラーバジェットの導⼊ - 対外的に掲げられるように 開発スピードを落とさず導⼊する - Eight として必要なモノ・タイミングを判断しつつ進める