入門記事単語書籍

障害対応の業務フロー。システム開発における障害対応の手順、体制

読者のイメージ

システムに障害が起きちゃった! どうすればいいの?

読者のイメージ

障害が起きたときのために、どう障害対応をすればいいか学んでおきたいな。

といった悩みに記事でお答えしていきます。

この記事を読むことで、障害が起きたときの業務フローを学ぶことができます。実際に障害が起きたときに見ながら対応することで、復旧につながっていきます。また、障害が起こらないための準備についてもまとめています。

私は上場企業やスタートアップなどでBtoBやBtoCのシステムを開発・運用してきました。ここで経験した障害対応得た知見をもとに、記事としてまとめています。

この記事の前提

この記事では、Webサービスやモバイルアプリの障害対応を想定して書いています。他の領域における障害対応でも参考になるかもしれませんが、当てはまらないこともあることをご承知おきください。

また、想定している読者の方としては、エンジニアとしての実務経験が1〜3年目の方としています。

障害対応とは

読者のイメージ

そもそも障害対応ってなに?

障害対応とは、『システムに障害が起きたときに、正常な状態に戻すための対応のこと』をいいます。ここでいう障害とは、なんらかの問題が起きたときに『今すぐ対応すべき』と判断したものを障害としています。

障害対応の業務フロー

障害対応の業務フローは、次の7つのプロセスからなります:

順番項目
1関係者への周知
2体制構築
3ユーザへのフォロー
4復旧
5復旧の共有
6再発防止
7関係者への共有

上のプロセスのうち、復旧までにかかる時間をできるだけ短くすることが大切だといえます。障害の大きさによらず、3の『ユーザへのフォロー』までは努力次第で確実に早くできるので、そのための準備をしておくといいですね。

私もそうでしたが、運用の経験がない方にとっては障害対応=4の『復旧』だと思いがちだと思います。ただ、復旧は障害対応の一部に過ぎません。上の7つのプロセスをしっかりと押さえておきましょう。

システムの復旧は障害対応の一部に過ぎない

障害対応において、システムの復旧はもちろん重要な要素です。ただ、その前に関係者への周知や障害対応の体制構築、ユーザへのフォローなど、確実に行っておきたいプロセスがあります。まずはプロセス全体を把握しておきましょう。

1. 関係者への周知

それでは障害対応についてひとつずつ見ていきます。まずは関係者への周知についてですね。このプロセスでは、システムに関わるメンバーに障害について周知します。とくに、2の『体制構築』に関わるメンバーには確実に共有できるようにします。

周知の方法については、社内で使っているチャットツールなど、全体に通知できる方法を用います。書く内容としては、次のような項目がいいでしょう:

  • 障害の内容
  • いつ発生したか
  • 原因はなにか
  • 影響範囲
  • 障害対応にあたるメンバーおよびリーダー
  • 対応内容
  • 完了目処

周知の段階で、わからないことは一旦未定でいいと思います。障害対応に進捗があったとき、必要に応じて随時周知を行います。

2. 体制構築

障害対応を行うための体制を構築します。たとえば次のようなメンバーで構成します:

  • ユーザとのフロントに立つセールスやカスタマーサクセスなどのメンバー
  • 技術的な復旧対応にあたるエンジニア
  • その他、影響範囲を確認したり、状況を関係者に報告する、ドメイン知識が豊富なプロダクトマネージャなど

障害対応における体制構築において大切なことは、ひとりで解決しようとしないことです。複数人で行えば、後述する復旧対応を複数の視点から行えます。一方で復旧を間違えると二次、三次の障害が発生し、被害が拡大してしまいます。

なにより、障害対応はやることがたくさんあります。個人開発などひとりでしか行えないケースを除いて、複数人であたるようにします。たとえば『インシデント指揮官トレーニングの手引き』では『インシデント指揮官』をはじめとする4つの役割で障害対応にあたるとしています。

3. ユーザへのフォロー

障害対応にあたる体制を構築したら、まずはユーザにフォローを入れます。フォローを入れる方法としては、障害の種類や影響範囲、プロダクトの種類に応じて次の中から使い分けます:

  • システム上にメッセージを掲載する
  • メールで通知する
  • 電話などで個別に連絡する

4. 復旧

復旧は、システムを問題なく使用できるようにすることを目的とします。復旧は次のようなプロセスになります:

  1. 復旧のゴールを決める
  2. 情報を収集する
  3. 調査する
  4. ソースコード等の変更を行う
  5. 変更を適用する

障害対応における復旧の最終的なゴールは、障害が起こる前の状態に戻すことです。ただ、復旧には時間を要する場合もあります。このときは、暫定的なゴールとしてひとまず問題なく使える状態にします。

次に情報を収集します。発生した障害を体験したユーザにコンタクトが取れる場合は、情報をヒアリングします。このときユーザのアカウント情報を得ることで、後述する調査のときにログ等と照らし合わせることができます。

障害を調査する

情報収集と合わせて調査を行います。障害対応の起点となるのはエラー監視ツールによる通知の場合が多いと思いますが、まずはエラー監視ツールを見て、問題を切り分けます。

切り分けた対象を元にリソース監視ツールやプロセス監視ツールを確認し、障害の要素を見つけます。また、関連するログも見ます。アプリケーションやサーバ、それぞれのアクセスログやエラーログなどを見ていきます。

このとき、障害が発生した時間やユーザのアカウント情報と照らし合わせて確認することで、原因を突き止めやすくなると思います。

調査して原因がわかったら、ソースコード等を変更し適用します。このとき、データの変更などで本番環境に負荷がかかる場合があります。必要に応じてメンテナンスモードへの移行やバックアップ、リストア手順の確認などを行います。

5. 復旧の共有

システムの障害が復旧したら、あるいは復旧のメドが立ったが時間を要する場合にも、ユーザに共有します。これも3の『ユーザへのフォロー』と同じ考え方で行います。

6. 再発防止

システムが障害から復旧できたら障害対応は終わり、ではありません。なぜ障害が起こったのか、再発しないためになにをするかを決めていきます。たとえばインスタンスのサイズを上げたり、レビューのプロセスを改善する具体的な方法を決めたりします。

障害対応のプロセス自体に問題があったときも、再発防止策として改善したいですね。

7. 関係者への共有

再発防止の内容を元に、今回の障害について関係者に共有します。同じ障害が起きない安心感を与えたり、似た障害が起きたときに再度報告してもらうことにつながります。

また、障害対応のプロセスに問題があったときに、第三者の目から見て客観的に問題を指摘してもらい、次につなげることができます。

読者のイメージ

障害対応って、調査と解決以外にもやることがたくさんあるんだね。実際に障害が起きたら、焦らずまわりに協力してもらいつつ、ひとつずつやっていこうl

システムに障害を起こさないために

この記事では障害対応の業務フローについて書いてきましたが、そもそも障害を起こさない方がいいですよね。そのために重要なのが:

  • コードレビューを行う
  • 自動テストを導入する
  • 運用監視ツールを導入する

などです。変更しようとするソースコードに問題があったとき、ソースコードレビューや自動テストの実行で検出することができます。また、運用監視ツールでは急激なアクセスの増加などで問題が起こりそうなときに、前もって検出することができます。

この3つについては次の記事でも説明しています。あわせてご覧くださいね:

loading...

loading...

loading...

まとめ

障害が起きたときの業務フローについて書きました。システムに障害が起きたら、ひとりで焦って対応せずに、関係者への共有からひとつずつやっていきましょう。また、運用監視ツールの導入など、障害が起きないための準備もしておきたいですね。

技術ブログを書く・読むのが好き🧑‍💻 Webエンジニア←プログラミング教育で起業←東大院←熊本高専。

Follow @zenizh
\ 記事をシェアしよう /

この記事を気に入っていただけましたら、ぜひフォロワーの方にシェアしてくださいね

ツイート画面をひらく
関連記事関連書籍
現場で使えるRuby on Rails 5

共著で『現場で使えるRuby on Rails 5(マイナビ出版)』を書きました。

Amazonでみる
Product Development IO
ゼロからWebエンジニアになるためのブログ
お問い合わせ
ご意見・ご質問やお仕事のご依頼などは下記よりお願いいたします
お問い合わせ
© Product Development IO