SLI/SLOの設定を進めるその前にアラート品質の改善に取り組んだ話

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 短期的な成果をどこに置くか SLI/SLO設定は長期戦になるので、逆に短期的な成果も大事。初期の成果はチームに勢いをもたらすだけでなく、周囲の信頼を得るきっかけにもなる。最初の成果として「アラート品質の向上」に狙いを定めた。アラート自体はサービスレベルマネジメントのコアなプラクティスではありませんが以下の理由から最初の一歩として選びました。 ● 開発組織の困り事として挙がることが多かった（課題が明確にあった） ● サービス品質の向上につながる 5

Slide 6

Slide 6 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. アラート品質改善のコンセプト設計ヒアリングや自身の開発体験をもとに課題の整理を行い、アラートにおける課題を以下の 3 つに絞りました。 ● どのアラート通知チャンネルを見るべきかわからない ● アラートが多すぎてどれが重要かわからない ● アラートが出たとしても何をしていいのかわからないコンセプト「アラートが通知されたときにすぐに気づいて次のアクションを起こせるか」 6

Slide 7

Slide 7 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. どのアラート通知チャンネルを見るか Slackのアラート通知先チャンネルの整理を行いました。 ● 過去の組織体制に合わせて作成されたもの ● 開発プロジェクト単位で作られたもの ● 内容が重複するものなどが乱立しており「どのチャンネルを見ればよいのか」が分かりにくい状態でした。この課題を解決するため、以下の通りにアラート通知チャンネルの再編を進めました。 1. チャンネルのpreﬁx, suﬃx 2. 緊急度でチャンネルを分ける 3. サービスの重要度で分ける 7

Slide 8

Slide 8 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 1. チャンネルのprefix, suffix チャンネルの検索性と視認性を向上させるため、prefix と suffix の命名規則を定めました。これにより、Slack 上で関連チャンネルがまとまって表示されるようになりました。チャンネル名の prefix notif- チャンネル名の suffix 環境を表す -prd, -stg, -dev 8

Slide 9

Slide 9 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 2. 緊急度でチャンネルを分ける通知の緊急度に応じてチャンネルを分けることで、即時対応が必要なアラートに集中しやすい構成としました。分類の基準は syslog の重大度レベルを参考にしています。即時対応が必要なもの notif-alert- 即時対応は不要だが念の為通知しておきたいもの notif-warn- プログラムの動作確認やデバッグのための情報を通知する（利用後の通知削除を推奨） notif-info- 9

Slide 10

Slide 10 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 3. サービスの重要度で分けるサービスの重要度は、「BASE」の主要機能（決済やショップ管理画面）と社内向けの管理画面ではやはり異なります。サービスごとの重要度を Tier1 から Tier3 に分類し、Tier毎のチャンネル作成方針を作りました。 Tier1 サービス毎に alert レベルのチャンネルを作り通知する。 warn, info レベルではチャンネルをまとめる。 Tier2 alert レベルのチャンネルをまとめる。 warn, info レベルのチャンネルは必要に応じて作成する。 Tier3 alert レベルのチャンネルをまとめる warn, info レベルのチャンネルは必要に応じて作成する。 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. アラートが多すぎてどれが重要か不明チャンネルの役割や命名規則を整えたことでチャンネルを集約し見るべきチャンネルがわかりやすくなりました。次に取り組んだのがアラート数の削減です。以下の順番で取り組みを進めました。 1. エラーを一気に減らした 2. 週 1 回 1 時間の定例でアラート設定の見直しとエラー解消を進めた 12

Slide 13

Slide 13 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 1. アラートを一気に減らす約 1 ヶ月間で 100 件近くのプルリクエストを作成し、エラーの根本的な解決とアラート設定の見直しを集中的に行いました。ノイズが減ったことで、アラート検知をきっかけに緊急性が高い不具合を見つけることにもつながっています。 Sentry の Issue を 970 件→0 件 13

Slide 14

Slide 14 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 2. アラート棚卸し会次のステップとして日々新たに発生するアラートへの対応プロセスを確立させる必要がありました。そのために週1回1時間のアラートの棚卸し会を実施しています。棚卸し会では Sentry や New Relic で未対応となっているアラートを確認し、解決方針を定めて開発チームのバックログに登録→エラーの解消をしています。棚卸し会の取り組みを始めて約半年ほど経過しましたが、平均して週に 1-2 件のペースでエラーとアラート通知の削減を実現できています。 14

Slide 15

Slide 15 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. 通知を受けて何をしていいのかわからないアラート対応の効率化を目的とした対応手順書（runbook）の整備を行いました。アラートの意図や対応方法が不明確だったり、時間の経過で設定者も内容を忘れ迅速な対応が難しいケースも見られました。そこで、アラート設定者含む誰もが素早く対応方法を把握できるように、runbookの作成と運用を始めました。 runbookの運用開始 15 New Relic のアラートには runbook のリンクを登録できる機能があり、アラートから直接 runbook にアクセスできて便利です（画像左下）

Slide 16

Slide 16 text

© 2012-2019 BASE, Inc. © 2012-2025 BASE, Inc. まとめアラート品質を向上させるために以下の取り組みを行いました。 ● アラート通知チャンネルの役割整理と統廃合 ● アラート通知数の削減 ● runbook の作成課題解決はもちろんですが、「サービス品質の改善に取り組んでいるチーム」であると社内の認知と信頼を獲得することができました。関わりたいと手を挙げてくれるメンバーも増え、SLI/SLO設定にも協力を得られやすくなったと感じています。まだまだ道半ばですが、これからも泥臭く取り組んでいくことで、サービスの信頼性の向上につなげていけたらと考えています。 16