こんにちは。Pentagonでアプリ開発している難波です。
一般的なアプリ開発の予算・開発期間において、障害発生をゼロにすることは困難だと言えます。そして、アプリが本番環境で稼働している限り、予期せぬ問題やバグに対処する必要があります。そのため、効果的な障害対応フローを持つことは、プロジェクトの成功に不可欠です。
この記事では、障害対応フローの各ステップ、重要な判断基準、効果的なコミュニケーション、およびデグレを防ぐための方法について詳しく説明します。また、特に注力すべき点として、過去の経験から得られたナレッジについても触れていきます。
【こんな人に読んで欲しい】
- アプリ運用で問題が発生したことのあるプロジェクトマネージャー、エンジニア
【この記事を読むメリット】
- アプリ運用で障害が発生した場合のさばき方がわかり、適切かつ迅速に障害を対応できるようになります
【結論】
この記事では、弊社の対応事例をもとに障害対応フローを作成し、関係者の共通認識として活用できるようにしました。
受託開発において、アプリ運用はクライアントから信用いただいた結果、辿り着いたフェーズです。信用に応えられるよう、障害発生時にこそクライアントに寄り添った対応を心掛けましょう！
障害対応フロー
障害対応は次のような流れで進めていきます。
- 障害レベル判断
- 優先度判断
- 改修見通し検討
- 対応方針検討
- アサイン
- 調査（再現確認、原因特定、対策検討）
- 改修（実装、レビュー）
- 検証（開発元テスト、受け入れテスト）
- リリース
障害の重大度にもよりますが、いずれのタスクにおいてもタイムリーな報連相を行うことを心掛けましょう。エンジニア側で懸命に作業しているつもりでも、状況がクライアントに伝わらない場合、作業しているのか後回しにしているのか区別がつきません。その場合、クライアントから誤った依頼が発生する可能性もゼロではなく、現場の混乱に繋がる可能性があります。
障害対応フローの各ステップについて説明します。
1. 障害レベル判断
障害が発生した際、クライアントと開発元が正しく判断された優先度の共通認識を持って対応することが重要です。優先度の決定に最も影響する要因は障害レベルです。以下のテーブルを参考に障害レベルを判断します。
| レベル | 説明 |
|---|---|
| 5 | 全ユーザーに影響。セキュリティ問題。データ損失。など |
| 4 | クリティカルパスの不具合。離脱につながる不具合。など |
| 3 | 一部機能が正常に動かない。など |
| 2 | 読み込みが遅い。など |
| 1 | デザイン誤り。誤記。など |
障害レベルと合わせて、緊急で対応が必要かを判断するため、以下の内容も確認しておきます。
- 環境確認：「本番環境」か「ステージング環境」かを確認します。ステージング環境のみで発生し、本番環境で起こり得ないケースであれば優先度は下がります。
- 不具合or要望：「不具合」か「要望」かを判断します。まれに両方が混ざった報告となることもあります。要望であれば優先度は下がります。
2. 優先度判断
通常は障害レベルにより、優先度を決定します。
複数の同レベルの障害がある場合、クライアントと協議して優先度を判断します。また、障害レベルが4以下であれば、改修にかかる日数の長さが優先度判断の要因となることがあります。その場合、後述する「改修見通し検討」「対応方針検討」を先に行った上で、クライアントと協議して優先度を判断します。
3. 改修見通し検討
優先度を決定するため、障害の改修見通しを検討します。以下のような作業のトータル日数を、概算ですばやく算出します。
- 調査（再現確認、原因特定、対策検討）
- 改修（実装、レビュー）
- 検証（開発元テスト、受け入れテスト）
- リリース
この後、実際に作業した際に差分がある場合、差分の理由を含めてタイムリーな報告を行いましょう。
4. 対応方針検討
障害を完全に解消できることがベストですが、対応に時間がかかる場合、一時的な措置を行って問題を緩和するようなケースも考えられます。
1〜2日程度におさまるのであればやりきる判断で良いと考えます。3日以上かかる場合、簡単に実施可能な一時的な措置を挟むのが良いと考えます。ただし、これらの日数は目安であるため、状況に応じてクライアントとの協議が必要となることもあります。
5. アサイン
プロジェクトマネージャーが改修対応に必要なメンバーをアサインします。
保守体制でカバーできるタスクサイズであれば調整は難しくありませんが、改修困難が予想される場合、プロジェクト外部のメンバーのアサインも検討します。
6. 調査
再現確認、原因特定、対策検討を実施します。
これらに時間がかからない場合は、プロジェクトマネージャーからクライアントへ再現確認結果、原因、対策をまとめて報告します。しかし、再現できない、原因がわからない、対策がわからないといった事象が発生した場合、対応に想定外の時間がかかることを報告します。クライアントの不安を取り除くため、問題解消の目標タイムをセットで報告しましょう。
7. 改修
次に、実装、レビューを実施します。
実装に時間がかかるなどの問題がある場合、対応に想定外の時間がかかることを報告します。問題がなくても、元々時間がかかる想定の実装であれば、クライアントの不安を取り除くため、進捗状況とともにデイリーで報告するようにしましょう。
改修作業でデグレが流出すると、問題が悪化します。デグレが発生し続けると、エンドユーザーに悪印象を与え、クライアントと開発元がともに疲弊する結果につながります。デグレが発生しないよう、影響範囲を加味したレビューを実施しましょう。
8. 検証
開発元テスト、受け入れテストを実施します。
テストNGがあれば調査・改修のやり直しが発生するため、その場合はタイムリーに報告を上げるようにします。問題がなくても、元々時間がかかるテストであれば、クライアントの不安を取り除くため、進捗状況とともにデイリーで報告するようにしましょう。
9. リリース
リリースを実施します。
アプリのみの改修であれば、できるだけ早急なリリースを実施します。バックエンドの改修もある場合、アクティブなエンドユーザーへの影響を考慮し、適切な方法・タイミングでのデプロイ後、アプリをリリースする必要があります。
まとめ
障害発生は避けることが難しい事象であり、発生時にはエンドユーザーが不利益を被るのはもちろんのこと、プロジェクトチームや関係者の業務にも大きな影響を与えます。問題がビジネス的なダメージとして蓄積しないよう、被害が拡大しないよう、細心の注意を払いながら、迅速な対応を心掛けましょう。
また、タイムリーな報連相は、クライアントの不安を取り除き、クライアントと開発元の間の心理的障壁を取り除くことに繋がります。心理的障壁があると、それがさらに遅延の原因を作り出すような負のスパイラルが発生する可能性もありますので、問題が起きた時こそ、コミュニケーションをとるよう心掛けましょう。
このブログでは「アプリ運用における障害対応フロー」についてまとめました。障害対応フローが存在することで、別プロジェクトでの障害対応状況についても、対応がどの段階であるのか共通認識を持つことができます。障害のキャッチアップも早くなり、支援に入る際のギャップも少なくなります。
障害発生は誰か一人の責任ではありません。一人で問題を抱え込まず、関係者全員で解決するチームを醸成していきましょう！
