インフラ

システム障害時の対応フローを整理してみた

MMM Corporation
shimo

こんにちは、下條です。名古屋は最近は雨も多くちょっと涼しくなってきました。

弊社ではお客様の運用保守を請け負っているプロジェクトが多くありますが、専任の運用チームはなく、開発など他の作業をしながら運用保守をしている状況となっています。
その状況下で、システム障害時にどのようなフローで対応しているかを整理してみました。

トリアージ

まずは障害のトリアージを行い、どれだけ優先して対応する必要があるかを判断します。

優先度 説明 対応方針
超優先 お客様に重大なビジネス影響が出ている問題が発生している場合。 全ての他の作業はペンディングし最優先で対応する。
最優先 お客様にビジネス影響が出ている問題が発生している場合。 基本的に他の作業はペンディングし最優先で対応する。
優先 問題が発生しているがお客様に直接のビジネス影響がでていない場合。 可能な限り優先して対応する。

※障害ですので、最低でも優先としました。

原因切り分け・原因調査

自社で運用保守しているシステムにおいて、他社様と関連している部分もあるため、まずは原因を切り分けるのが最初のステップとなります。

  • 自社側のシステムに問題があるのか、ないのか切り分けを行います。
  • 自社側のシステムに問題がない場合は、適切な連絡先に通知して待機となる場合もありますし、自社側での回避策が取れないかできないか検討する場合もあります。
  • 自社側にシステムに問題がある場合は、引き続き原因調査を行います。

暫定対処の検討

  • 原因調査の一方で、お客様にビジネス影響が出ている場合、原因がはっきりしない状態でもサービスの復旧のため暫定対処ができないかを同時に考えていくことが重要です。例えば何らかのリソース不足が発生している場合に、根本原因の解明は後回しで再起動で復旧を試みるなど。ただし、暫定対処が原因で別の二次障害が発生することもあり得るため、暫定対処は慎重に検討します。特に原因に目星が付いていない状況での暫定対処は、それが余計に悪い事態を引き起こすことがないかどうか、万が一そういった自体が起きた場合に切り戻せるかを慎重に検討します。
  • 原因調査の結果、原因がプログラムのバグにあったとしても、プログラム修正にこだわらず、スピーディーに暫定復旧する回避方法がないかも考えます。

なお、障害時にはお客様は不安を抱えているため、適切に一報を入れるなど心がけます。その際には以下の点に気をつけます。

  • 事実を簡潔に伝える。
  • 明らかでないことは断定して伝えない。

例えば、DBコネクション数の急増によりサイトに繋がりづらい状態となったといった場合の一時報告例を記載してみます。あくまで架空の例です。

【現象】
2018年xx月xx日xx時xx分ごろから、サイトに繋がりづらい状態となっています。

【原因】
DBへのコネクション数が急増したことが原因と考えられますが、根本原因については調査中です。

【対処】
アプリケーションサーバの再起動で暫定的に回避できる可能性があるため、アプリケーション
サーバの再起動を実施いたします。
その上で、DBコネクション数増加の根本原因につきましては引き続き調査いたします。

暫定対処

  • 検討した暫定対処を実施します。暫定対処後には想定どおりの復旧がされているか、別の障害が発生していないか慎重に確認します。

恒久対処の検討

  • ここまで走り抜けてきましたが、もし暫定対処でサービス影響が回避できているのであれば、いったん落ち着きましょう。
  • 恒久対処はプログラムのバグ修正・インフラのリソース拡張・ミドルウェアの設定変更など様々なパターンがありますが、基本的には根本原因を取り除く方向で検討します。

恒久対処

  • 恒久対処を実施し、修正確認の後、お客様に報告します。

ナレッジのドキュメント化

  • 上記の対処が終わって一段落したら、システム障害でどのような調査をしたのか・原因が何だったのか・学んだことなどをドキュメント化します。これらは将来活用できるナレッジです。弊社では、あまり形式張った形でのレポートではなく、比較的フリーフォーマットで自由な形でドキュメント基盤に記述するようにしています。

障害対処時の心がけ

  • 必要に応じてメンバーを巻き込みます。弊社はリモートワークですので、緊急度が高い障害の場合、電話をつないぎながら対応することも多いです。
  • 焦らず、かつ急ぐことが大事です。そのためにも基本的なサーバオペレーション等はミスなく素早くできるよう日々鍛錬しておくことが大切です。

まとめ

以上、システム障害時の対処フローについてまとめてみました。もちろん決して障害を望んでいるわけではないですし、障害が起きにくいような設計にすることは前提としてありますが、障害対処は意外と楽しいものです。例えば以下のような楽しさがあります。

  • スリルを楽しむ: アドレナリンが出ます。
  • 謎解きパズルを楽しむ: 理詰めで原因を絞っていく過程はまさにリアル謎解きパズルと言えるでしょう。
  • 新たなスキルを深く身につけられる: 障害時に身を挺して調べて獲得した知識・スキルは深く身につきます。
  • 解決したあとの満足感: 自分の力を最大限発揮して調査した後、原因がはっきりしたときの快感は何とも言えないものがあります。

もちろんツラい部分があるのも確かですが、もしシステム障害が起きてしまったらこういう楽しみも見つけながら果敢に立ち向かっていきましょう!

AUTHOR
shimo
shimo
記事URLをコピーしました