SLOの導入で失敗したこと.pdf

Transcript

1. SLOの導入で 失敗したこと 2021/12/20 ryotaro(twitter:@ryota_hnk)
2. Agenda 01 02 03 04 組織構成とSREチーム SLOの導入方法 振り返り 自己紹介
3. 1. 自己紹介
4. • 求人検索サービスのSRE • おっさんだけど業界歴は浅い フリーター → COBOLer → Oracle DBA → インフラエンジニ ア → SRE • 好きな技術：TCP/IP • 苦手な技術：正規表現 ryotaro @ryota_hnk
5. これからお話しすることは所属組織を代 表する意見ではなく、あくまでも個人とし ての振り返りです。 組織にSLOを導入する際の参考としてご 活用いただけると幸いです。
6. 2. 組織構成とSRE
7. • 各サービスごとにチームが分かれてる • 各チームが独立して運用している（イン フラ含めて） • SREは各チームに共通的な基盤や仕組 みを提供する • SREは各サービスに間接的に関わって いる • SREチーム≠運用チーム SREの立ち位置 UI/UX チーム SRE チーム 広告 チーム データ 基盤 チーム etc
8. 3. SLOの導入
9. • いろんな書籍や事例を参考に考えた • 各チームと話し合い、 CUJを中心とした SLOを作成 • エラーバジェットは水曜起算の 1週間 • エラーバジェットが枯渇した場合は、そ のスプリントはリリース禁止 • ルールを整備して、各チームにSLO運 用をお願いした（SREは運用補助） SLOを策定
10. • ユーザーが 1 つの目的を達成するため に行うサービスとの一連のインタラクショ ン（1 回のクリックやマルチステップ パイ プラインなど） • 複数サービスを跨ぐため、 SLOは複数 チームでの共同運用 となった（SREはそ の補助） CUJ（Critical User Journey） PCで求人一覧を見る PCから求人広告を出す
11. 4. 半年間の振返り
12. • POやMgrにはリリース禁止が痛す ぎた • リリース禁止が相次ぐと事業計画 に支障がでる • リリース作業を禁止されると、その スプリントの計画が崩れる 「リリース禁止」というワードが強すぎた • エラーバジェット枯渇時には信頼 性回復に努める • 話し合ってポストモーテムを作成 し、再発防止に努める やりたかったこと 現実
13. • リリース禁止が障害の原因ではな いチームにも適用されて割を食う • 守ることに目がいって、 SLO自体を 変えようとしなくなる オーナーシップ不在 • 各チームで協力して SLOを運用 • SLO違反時には情報を共有しあっ て解決 • SLO自体がおかしいと思ったら、 話し合いで変更する やりたかったこと 現実
14. • とりあえずDiscordに集まっただけ • 障害の原因になっていないチーム は時間のロスになる SLO違反の対応フローが整ってなかった • SLO違反時には各チームで協力 して対応、調査 やりたかったこと 現実
15. • 起算日はエラーバジェットが少な いので、起算日に障害が起きると あっという間に枯渇からリリース禁 止 • 逆に週末はエラーバジェットが溜 まってるので多少のエラーは大丈 夫というチート • リリースミスしてすぐに切り戻しても リリース禁止になった時の悲しさ エラーバジェットに起算日を設けた • スプリントを1週間（水曜スタート）に した。スクラム開発が基本なので、 スプリントの計画に盛り込みやす いように • 次のスプリントで障害対策をできる ので、チームの機動力が上がる やりたかったこと 現実
16. • 「え？リリース禁止？」だけが飛び交う Slack • リリース禁止が障害のペナルティに なった • SLIで品質をみて欲しい人生だった • 「俺たちは普通に運用監視も障害対 策もできてるのに、SLOを導入するメ リットがわからんです」 想いが伝えられなかった • システム健全性の可視化 • 機能開発か信頼性向上、どちらに リソースを割くかのパラメータに SLOを使う やりたかったこと 現実
17. Thanks! 総括 • 詰め込みすぎたのかなという印象 • 段階的導入も放置されるリスクがある • 「人にやってもらう」難しさ • テキストだと伝わらないのか 伝えすぎてしまうのか