こんにちは、テクノロジー本部の木村です。障害報告のデータによる障害傾向分析やレポーティングの取り組みについてご紹介します。
障害管理の改善を目指す方々に参考になれば幸いです。
障害管理の運用事例についての記事は以下をご覧ください。 www.lifull.blog
LIFULLでは様々なサービスを開発していますが、主要サービスで発生した障害は発生から再発防止までの経緯を報告するルールが定着しています。
一つひとつの障害分析の情報はそれだけでも価値があるのですが、私たちは品質管理部門としてそれをさらに分析する取り組みを始めました。
情報をまとめて整理すれば障害の傾向やサービス横断での共通課題なども見えてくることがありますし、再発防止や改善に向けた大きな対策の必要性が見えてきたりもします。
障害報告の入力項目
分析に利用している障害報告の入力項目は以下のようなものがあります。
| 入力項目 | 入力形式 | 入力内容 |
|---|---|---|
| 障害の内容 | テキスト形式 | その時点でわかる範囲の障害の箇所・影響・対応予定など |
| 検知時間 発生時間 解消時間 |
テキスト形式 | おおよその日時 起票優先のため曖昧さを許容。 正確な時間は別項目として用意 |
| 主管部署・担当者 | テキスト形式 | 障害対応の担当部署 |
| 原因 | テキスト形式 | 原因となった変更内容・現象など |
| 対象ユーザー | 複数選択：エンドユーザー/クライアント/社内 | 影響を受けたユーザー |
| 影響範囲 | テキスト形式 | 影響を受けた時期・条件・データなど |
| 起因工程 | 複数選択：基盤/開発・設計・テスト/運用/外部要因/その他 | 原因となった変更などの工程 |
| 起因となった変更内容 | テキスト形式 | 変更チケットのURLなど |
| 対応内容 | テキスト形式 | 暫定対応・恒久対応の実施情報・予定など |
| サイト・サービス停止時間 | 数値 | 停止に至った具体的な時間（分単位） |
| 再発防止策 | テキスト形式 | 再発させないための根本原因対応 |
集計項目とツール
集計に使用しているツールは以下のとおりです。
障害報告：JIRA
障害情報データ蓄積：BigQuery
可視化：スプレッドシート、LookerStudio
障害報告に入力されたデータはデイリーでBigQueryへ送り、集計内容に応じてスプレッドシートからアクセスして必要な形にして取得しています。
可視化ツールのLookerStudioではそのスプレッドシートの情報を参照していますので、前日の状態が自動でデータ反映されて可視化されます。
LookerStudioのダッシュボードでは様々な集計を行っていますが、例えば4keysの指標にもなっている障害発生率やMTTR（平均復旧時間）があります。
集計している項目をいくつか抜粋して紹介します。
障害発生率（当月の開発系起因の障害件数/当月のリリース件数）
当月の開発リリース件数（別集計）と、当月発生した開発系起因の障害件数から、障害発生率を算出しています。例えば外部環境が要因の障害などは集計対象に含めていません。
障害が発生した月で集計しているので過去から発生していた障害が新たに見つかった場合、過去の結果が変わることがあります。
報告月で集計した場合は、過去から発生していたものが今月の結果に影響するため、発生した月で集計することにしました。
障害が発生した月で集計すれば、その月にリリースされた件数と比較することで発生率として意味のある数値になります。
検出時間・対応時間・復旧時間の月平均推移
障害の発生日時・検知日時・復旧日時から、検出・対応・復旧時間を算出しています。
サービスに大きな影響のある障害だけでなく軽微なものについても算出対象としました。
このうち開発系起因の障害に関する復旧時間の平均を4keysのMTTRとして使用しています。
想定損害金額
想定損害金額としていますが、実際の損害金額ではなく損害規模を相対的に推し量るための数値を独自の計算式で算出しています。
障害のあったサービスのマーケット売り上げに対して、障害レベルに応じた係数と発生から解消までの時間で算出しています。
（該当サービスの1日の売上×インシデントレベルによる係数×障害日数（発生→解消））
傾向分析
サービス別、リポジトリ別、要因別（コミュニケーションロス、テスト漏れなど）、起因工程別など様々な観点から傾向を探ることで隠れていた傾向や課題が見つかることもあります。
例えば、
・同じ時期に別々のサービスで同じような事象で障害が発生していた
・〇〇のアップデートをした際に過去に同じような障害起こしてた
・一方のサービスでは監視をおこなっていて気づけたのにもう一方のサービスでは監視が至らず障害に至った
・エンドユーザーへの自動配信メールの記述内容のような監視しにくい部分において検知が遅れる傾向がある
など、中には防げたはずの障害が浮き彫りになったりします。
まとめ
上記で計測・分析した結果は月次および半期ごとに社内に公開しています。
障害に関する情報が継続的に集計・可視化されることで、以下のような効果がみられたと感じています。
１．サービスによってややばらつきのあった障害対応の意識改善
２．監視体制強化の意識
３．別々のサービス管轄部署で同じ原因で発生していた障害の課題発見、対応方法の共有
障害が無くなることはありませんが、継続的に見ていくことで地道に対策がおこなわれることで障害発生率やMTTRが減少してきました。
しっかりと障害と向き合えていることで、サービスの質にも良い影響が出ているのではないかと思います。
最後に、LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。
