こんにちは。テクノロジー本部の岡より、障害管理運用のより具体的な取り組み内容を紹介していきます。
障害管理に関わる方の参考になれば幸いです。
私たちの部署では、LIFULLのさまざまな事業開発に関する活動や適切性のモニタリングとレポーティングを通して横断・間接的に必要な支援・助言・監督を行う責任を担っています。
事業運営に携わるエンジニアによる、障害分析の取り組みはこちらの記事もぜひ読んでみてください。
障害報告のおおまかな流れ
LIFULLでは、専用の障害報告管理ボードを使って障害発生から恒久対応完了までを報告することになっています。
「障害・バグが疑われる事象」「サクセスレートの低下によるエラー通知」などの問題が起きたら、誰でもすぐに報告チケットを起票できます。（起票は一部自動化がされています）
その後の調査報告や対応後のステータス更新が行われ、最終的には開発責任者が報告完了まで責任を持ちます。
具体的な障害ステータスと報告内容
障害対応のステータスごとにどんな入力項目を記載することになっているか、具体的に紹介します。
以下に記載している入力項目は必須入力項目です。ステータスを変更する際に未入力の場合は必ず入力を求められ、記載漏れが起きないようにしています。
これらの入力項目以外にも、できるだけ記載に時間をかけず抜け漏れなく記入できるように、選択式の入力項目が多数あり、その時点で判明していることを記載していきます。
| 報告ステータス | 入力項目 | |
|---|---|---|
| １ | 継続中 不具合が解消しておらず、対応が進行中の状態 |
報告書タイトル（障害の要約） 検知日時 |
| ２ | 暫定解消 不具合が復旧または自然解消し、正常稼働している状態 |
概要 発生日時 解消日時 事業領域 影響内容の詳細 対象利用者 対象デバイス 障害起因となった変更内容 対応内容 |
| ３ | 本解消 障害分析と再発防止策が記入され、障害対応が終了した状態 |
原因 再発防止策（次のいずれか） ・再発防止（恒久対応）完了報告 ・再発防止対応計画の管理資料の明記 ・許容判断（恒久対応不要）理由 開発担当部署の責任者 |
| ４ | 報告完了 障害分析と再発防止策が記入され、障害対応が終了した状態 （担当部署の責任者が確認） |
再発防止（恒久対応）内容の最終チェック |
| ５ | 完了 問題解決プロセスが終了した状態 （モニタリング部署が確認） |
分岐する別経路として、以下のようなステータスもあります。この場合モニタリング部署も内容確認を行います。
- 経過観察
- 原因不明、一時的エラーで対応保留などの状態
- 無効
- 開発担当者が調査後に障害ではないと判断された状態
- 原因重複（別対応中）
- 同じ原因の複数障害報告が存在している状態
最近の運用改善事例
開発担当者は、まず不具合解消を最優先に動きますが、解消後はさまざまな要因で報告が完了しないことも起こり得ます。
障害報告の運用は定着してきているものの、対応状況の確認や適切な情報共有に課題感がありました。
そこで、報告が未完了のままとなってしまいがちな主な要因を分類し、改善策を運用ルールに追加しました。
- 原因不明や再現性がなく調査困難な軽微なエラー
- 改善策: 「経過観察」ステータスを追加し、軽微なエラーや再発が少ないものについては一定期間経過を見て問題がなければ、モニタリング部署が完了とする - 同じ要因で発生した障害が複数報告される
- 改善策: 一つの障害報告に情報集約し、それ以外は「原因重複（別対応中）」ステータスにてモニタリング部署が管理する - 不具合解消後、ルーズボールになり情報更新がされにくくなる
- 改善策: リマインドを可能な限り自動化、リマインド時に次に取るべき行動も都度伝える - 恒久対応の難易度や優先度により恒久対応時期が未定
- 解決策: 恒久対応の課題管理がされていることを条件に完了とする
まとめ
必要な対応に集中できるよう報告時の開発者負担を減らしたり状況をわかりやすくするなど、運用改善を少しずつ試みた結果、障害状況の見える化が進み、未完了の障害削減にもつながりました。
全体として障害対応が迅速化し、効率的な管理運用が実現できています。
状況の変化に対応しながら、今後も引き続きより良い運用方法を模索していきたいと思います。
次回は、この障害報告のデータによる障害傾向分析やレポートについて紹介する予定です。
最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。
