運用しているシステムに障害が起きてしまったとき、どうすればいいのか分からないかもしれません。また、障害が起きたときのために、どのように対応をするかを学んでおきたいこともあると思います。
この記事を読むことで、障害が起きたときの業務フローを学ぶことができます。また、実際に障害が起きたときに見ながら対応することで、復旧につなげることもできます。さらに、障害が起こらないための準備についてもまとめています。
私はエンジニアとしてシステムを開発や運用してきました。この中で経験した障害対応で得た知見をもとに解説します。
この記事では、ウェブサービスやモバイルアプリの障害対応を想定して書いています。他の領域における障害対応でも参考になるかもしれませんが、当てはまらないこともあることをご承知おきください。また、想定している読者の方としては、エンジニアとしての実務経験が1〜3年目の方としています。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
障害対応とは
障害対応とは、システムに障害が起きたときに、正常な状態に戻すための対応のことをいいます。ここでいう障害とは、なんらかの問題が起きたときに「今すぐ対応すべき」と判断したものを障害としています。
障害対応の業務フロー
障害対応の業務フローは、主に次の7つのプロセスからなります。このプロセスのうち、復旧までにかかる時間をできるだけ短くすることが重要だといえます。障害の大きさによらず、3の「ユーザーへのフォロー」までは努力次第で確実に早くできるので、そのための準備をしておくとよさそうです。
| 順番 | 項目 |
|---|---|
| 1 | 関係者への周知 |
| 2 | 体制構築 |
| 3 | ユーザーへのフォロー |
| 4 | 復旧 |
| 5 | 復旧の共有 |
| 6 | 再発防止 |
| 7 | 関係者への共有 |
私もかつてはそうでしたが、運用の経験がない方にとっては、障害対応というと「復旧」だけだと思いがちだと思います。ただ、復旧は障害対応の一部に過ぎません。上の7つのプロセスをしっかりと押さえておきたいところです。
1. 関係者への周知
それでは障害対応についてひとつずつ見ていきます。まずは関係者への周知についてです。このプロセスでは、システムに関わるメンバーに障害について周知します。とくに、2の「体制構築」に関わるメンバーには確実に共有できるようにします。
周知の方法については、社内で使っているチャットツールなど、全体に通知できる方法を用います。書く内容としては、次のような項目が考えられます。
- 障害の内容
- いつ発生したか
- 原因はなにか
- 影響範囲
- 障害対応にあたるメンバーおよびリーダー
- 対応内容
- 完了目処
周知の段階で、わからないことは一旦未定でいいと思います。障害対応に進捗があったとき、必要に応じて随時周知を行います。
2. 体制構築
障害対応を行うための体制を構築します。たとえば次のようなメンバーで構成します。
- ユーザーとのフロントに立つセールスやカスタマーサクセスなどのメンバー
- 技術的な復旧対応にあたるエンジニア
- その他、影響範囲を確認したり、状況を関係者に報告する、ドメイン知識が豊富なプロダクトマネージャなど
障害対応における体制構築において重要なことは、ひとりで解決しようとしないことです。複数人で行えば、後述する復旧対応を複数の視点から行えます。一方で復旧を間違えると二次、三次の障害が発生し、被害が拡大してしまいます。
なにより、障害対応はやることがたくさんあります。個人開発などひとりでしか行えないケースを除いて、複数人であたるようにします。たとえば「インシデント指揮官トレーニングの手引き」では「インシデント指揮官」をはじめとする4つの役割で障害対応にあたるとしています。
3. ユーザーへのフォロー
障害対応にあたる体制を構築したら、まずはユーザーにフォローを入れます。フォローを入れる方法としては、障害の種類や影響範囲、プロダクトの種類に応じて次の中から使い分けます。
- システム上にメッセージを掲載する
- メールで通知する
- 電話などで個別に連絡する
4. 復旧
復旧は、システムを問題なく使用できるようにすることを目的とします。復旧は次のようなプロセスになります。
- 復旧のゴールを決める
- 情報を収集する
- 調査する
- ソースコード等の変更を行う
- 変更を適用する
障害対応における復旧の最終的なゴールは、障害が起こる前の状態に戻すことです。ただ、復旧には時間を要する場合もあります。このときは、暫定的なゴールとしてひとまず問題なく使える状態にします。
次に情報を収集します。発生した障害を体験したユーザーにコンタクトが取れる場合は、情報をヒアリングします。このときユーザーのアカウント情報を得ることで、後述する調査のときにログ等と照らし合わせることができます。
情報収集と合わせて調査を行います。障害対応の起点となるのはエラー監視ツールによる通知の場合が多いと思いますが、まずはエラー監視ツールを見て、問題を切り分けます。
切り分けた対象を元にリソース監視ツールやプロセス監視ツールを確認し、障害の要素を見つけます。また、関連するログも見ます。アプリケーションやサーバ、それぞれのアクセスログやエラーログなどを見ていきます。このとき、障害が発生した時間やユーザーのアカウント情報と照らし合わせて確認することで、原因を突き止めやすくなると思います。
調査して原因がわかったら、ソースコード等を変更し適用します。このとき、データの変更などで本番環境に負荷がかかる場合があります。必要に応じてメンテナンスモードへの移行やバックアップ、リストア手順の確認などを行います。
5. 復旧の共有
システムの障害が復旧したら、あるいは復旧のメドが立ったが時間を要する場合にも、ユーザーに共有します。これも3の「ユーザーへのフォロー」と同じ考え方で行います。
6. 再発防止
システムが障害から復旧できたら障害対応は終わり、ではありません。なぜ障害が起こったのか、再発しないためになにをするかを決めていきます。たとえばインスタンスのサイズを上げたり、レビューのプロセスを改善する具体的な方法を決めたりします。
障害対応のプロセス自体に問題があったときも、再発防止策として改善したいところです。
7. 関係者への共有
再発防止の内容を元に、今回の障害について関係者に共有します。同じ障害が起きない安心感を与えたり、似た障害が起きたときに再度報告してもらうことにつながります。
また、障害対応のプロセスに問題があったときに、第三者の目から見て客観的に問題を指摘してもらい、次につなげることができます。
システムに障害を起こさないために
この記事では障害対応の業務フローについて書いてきましたが、そもそも障害が起こる前に防げたらそれに越したことはありません。そのために重要なのが、次のようなことになります。
- コードレビューを行う
- 自動テストを導入する
- 運用監視ツールを導入する
変更しようとするソースコードに問題があったとき、ソースコードレビューや自動テストの実行で検出することができます。また、運用監視ツールでは急激なアクセスの増加などで問題が起こりそうなときに、前もって検出することができます。
この3つについては次の記事でも説明しています。あわせてご覧ください。
まとめ
障害が起きたときの業務フローについて書きました。システムに障害が起きたら、ひとりで焦って対応せずに、関係者への共有からひとつずつやっていきましょう。また、運用監視ツールの導入など、障害が起きないための準備もしてみてください。
