Managed Service Column <システム運用コラム>

Category: 運用設計編

2019.02.14

システム監視項目をどう定義するのか?」では、障害原因切り分けを迅速に行うための、監視ポイントの設置の仕方を見てきました。ここでは「障害対応の流れ」を見ていきます。

事前準備:障害対応レベル・フローの設計

運用設計とは?サービスを安定稼働させるための項目定義」で見たように、システム運用フェーズに入る前に、障害レベルに応じたフローや対応手順を予め定義しておくと、スムーズな障害対応が可能になります。

障害対応レベル、フローの定義

障害対応を行う前に、以下の情報を整理・定義しておきます。

  • 1.システム構成図

    管理対象システムの論理/物理ネットワーク図、グループポリシー、設定情報、ライセンス情報、データセンター情報などを、事前に収集します。

  • 2.障害対応レベル

    発生する障害のレベルによって、障害連絡先や連絡方法、必要な対応内容、対応時間が異なることは多いです。障害内容によって対応フローを変えたい場合は、障害レベルを定義します。

    障害対応レベル区分例:

    ※「下記表は指でスライドさせてご覧いただけます。」
    障害レベル 内容
    レベル1 サービス停止を伴う障害
    レベル2 単体ではサービス停止を伴わないが、多重に発生するとサービス停止につながる障害
    レベル3 これだけではサービス停止とならない障害
    ※対ユーザへの影響がない
    ※即時対応する必要がない
    レベル4 サービス停止を伴わない軽微な障害。念のための情報通知
  • 3.障害対応フロー

    障害対応に必要な事項を定義します。

    • 障害時の連絡先・連絡方法
    • 復旧対応終了条件
    • 復旧連絡先・連絡方法
    • 対応時間
    • インシデントの管理方法

    障害レベルによって、連絡先などの条件を変えたい場合は、レベルに応じたフローを作成します。

障害対応手順の定義

定義済みの各監視項目で障害が起きた場合の、対応手順を定義します。

  • 障害対応の概要
  • 状況確認方法
  • 状況判断方法
  • 復旧対応方法
  • 再発防止に向けて収集しておくべき情報

などを予め決めておくと、スムーズに対応できます。

障害対応の流れ

障害対応の流れは以下の通りです。

  • 1.影響範囲を確認する

    障害を検知したらまず、障害の影響範囲を見極めます。
    一般的に、障害は複数要素の複合的要因で発生します。障害が起きている箇所(プロセスやサービスなど)を特定し再起動を行うとともに、関連していると思われる障害が発生していないかを確認します。
    (※障害切り分けのための情報収集項目については、「システム監視項目をどう定義するのか?」をご参照ください。)

    URL応答障害や、DBへの接続障害が発生している場合は、サービス提供に影響している可能性があります。ブラウザで対象 URL にアクセスする、サーバーへリモートログインするなどして、状況の確認とサービスへの影響範囲を確認します。

  • 2.担当者へ連絡する

    サービス提供に影響が出る障害の場合は、速やかに障害連絡先と情報共有します。復旧に時間がかかりそうな時、また、復旧確認が取れた時にも、随時、連絡と情報共有を行います。
    サービス停止とならない障害の場合は、予め定めたフローに従って、連絡・情報共有します。

  • 3.復旧作業を行う

    定義済みの障害対応手順に沿って対応し、復旧確認を行います。障害が解消せず、手順書外の対応が必要な場合は、エンジニアのノウハウに基づき、障害原因の切り分け・特定・復旧対応を行います。

  • 一次対応

    まずは、サービスを継続させるための取り急ぎの復旧対応(一次対応)を行います。
    監視システムからのアラートをトリガに状況確認を行い、手順に沿った対応を実施します。
    それでも障害が解消しなかった場合は、エンジニアへエスカレーションし、ノウハウによる手順書外の対応を行います。

    • 1.監視システムによる自動復旧

      手順化できる障害対応は、監視システムが復旧処理を行い、結果障害が解消しなかった場合は、エンジニアにエスカレーションする、までを自動化します。
      一般的な例として、

      • 死活監視(pingによる疎通監視)
      • リソース監視(CPU使用率、メモリ使用率、ディスク使用率)
      • プロセス存在監視(httpd , vsftpd , sshd , postfix , qmail  等)
      • プロセス応答監視(http応答 , ftp応答 , ssh応答 , smtp応答 等)

      など、監視設計フェーズで定義した監視対象で障害が発生した場合や、

      • ログ監視で特定のパターンにマッチングした場合

      などに、監視システムが自動再起動処理を行います。
      再起動後も障害が解消しない場合は、監視システムが、担当エンジニアへエスカレーションを行うようにします。
      (※障害自動復旧例は、当社「システム監視・自動復旧プラン」の「自動復旧させる項目」に記載しています。併せてご参照ください。)

    • 2.エンジニアによる対応

      一次対応で障害が解消しなかった場合、エンジニアが原因の切り分け、復旧対応を行います。
      予め定義していない対応になるので、収集した情報をもとに、システム上のどこで何が起こったか、それがどういった理由で発生したのかをひとつずつ切り分け、障害原因を特定する必要があります。

      障害対応時の考え方については、「障害対応:階層を意識してシステムを理解する」をご覧ください。

    • 恒久対策の実施

      障害の再発防止を目的に、恒久対策を実施します。

      システム監視や一次対応で障害復旧はできますが、サービスを安定して提供するためには、障害の根本原因を解消する必要があります。

      例えば、Webサービスを提供しているシステムで、アクセス集中のためサービスの応答時間が非常に長くなるといった事象(対エンドユーザに影響が出るレベル)が発生した場合、まず、システムのパフォーマンス低下を招くボトルネックを特定します。

      Webサーバーのパフォーマンス不足が原因であれば、OSやミドルウェアの設定変更や、サーバーのインスタンス設定変更、サイズ変更、再構築等を実施します。 あるいは、冗長構成を見直し、耐障害性を向上させます。
      (※恒久対策の実施例は、当社「運用改善サービス」の「運用改善 作業例」に記載しています。併せてご覧ください)

      このように、より安定したサービス提供を実現する環境へ改善していくことも、障害防止には必要です。
      次は、「障害対応の考え方:階層を意識してシステムを理解する」で、エンジニアが障害対応を行う際の考え方を見ていきます。

      Tag: 運用設計 障害対応

Contactお問い合わせ

お見積もり・ご相談など、お気軽にお問い合わせください。

single.php