Managed Service Column ＜システム運用コラム＞第12回：可用性を高めるための障害対応手順

システムのクラウド移行が加速する中、「クラウドサービスを活用しているが、クラウド毎に個別に監視・運用をしているため、運用が煩雑化している。どうすればよいか？」「オンプレミスとクラウドを併用することになり、運用管理体制を見直したい」といったお声をいただくことも多くなりました。

システムは構築して終わりではなく、安定稼働するための運用が重要です。そして、システム運用の品質を担保しながら効率を上げていくためには、運用設計が必要となります。

この連載では、運用設計の考え方やの取り組みについて、事例も交えて紹介します（全12回）。

はじめに

前回のコラム（「第11回：可用性を高めるための監視仕様」では、「可用性を維持するための監視がどうあるべきか」という視点から、監視設計の考え方をお話ししました。
今回は、監視仕様とセットの障害対応手順の作成の仕方についてお話しします。

監視とセットの障害対応、対応手順

監視仕様がまとまったら、それぞれの監視項目で障害を検知した場合の対応方法・手順を決める必要があります。
監視仕様を決めるにあたっては、システムがユーザーへ提供するサービスという視点から落とし込んでいきましたが、対応方法・手順を決める際も同様です。 ITILの定義に照らし合わせると、“ITサービス持続性管理” という項目があり、ここでは、ビジネス・インパクト分析と、リスク・アセスメントの結果を元に戦略を決定します。

実際の障害対応を想像してもう少しかみ砕くと、対応手順においても、

• サービス停止に対して、事業側の条件を満たす復旧手順を用意する
• サービス停止リスクを低減させる

という2つの視点が必要になります。

なお、直接的に障害対応手順とは関係しませんが、”ITサービス持続性管理” には、事業継続を脅かす脅威を洗い出し、選別された驚異の大きさ、現実となる可能性、軟弱性の分析を実施することも含まれます。これについては、障害対応手順の話をしたあとに補足説明として後述します。

では、2つの視点それぞれを見ていきます。

サービス停止に対する対応手順

サービスが停止しているわけですから、当然ですが迅速な復旧が求められます。ただ、内容によってはすぐに復旧できるものと、復旧にある程度時間を要するものがあります。復旧手順を用意するにあたって、より重要なのは後者を想定したものです。

例えば、あるプロセスの再起動だけ実施すれば復旧するような障害であれば、オペレーターが実施する手順を整備するよりも、システムにより自動復旧させる仕組みを用意したほうが明らかに効率的です。きっちり決まった手順の実施は、人よりもシステムの方が得意であり安全（人はミスを犯す、その可能性を下げる）です。
対応手順というと、システムに対する復旧のための操作方法というイメージを持っている方が多いかもしれませんが、それだけではなく関係各所への状況の伝達なども含め、より大きな枠で考える必要があります。

改めて、ECサイトを想定したhttps://example.com の例を見てみます。
仮に、このサイトで「既存ユーザーは商品購入含め何の問題もなく利用できるが、新規のユーザー登録ができない。」という障害が発生したとしましょう。原因は、DB に何らかの問題が発生し、新規ユーザー情報が書き込めなくなったものとします(ただし、障害検知時点ではこの原因はわからなかったものとします)。

この場合の対応フローは次のようになります。

1. サービス影響範囲の確認
2. サービスの状況についての顧客向けアナウンスの実施
3. 原因調査の実施
4. 復旧方針の策定
5. 復旧作業の実施、復旧確認
6. サービス復旧についての顧客向けアナウンスの実施
7. 再発防止策の検討

このフローに沿って具体的な手順に落とし込んでいきます。例えば次の通りです。

上記の例はまだ全体の概要レベルですが、システム的なオペレーションだけでなく、サービス復旧に向けて必要となる一通りの手順を定義していく必要がある事がわかるかと思います。

最初に書いた「DB に何らかの問題が発生し、新規ユーザー情報が書き込めなくなった」という原因は、ステップ3.の段階で判明することになるでしょう。完全復旧がすぐにできない状態であれば、一部のサービスに限定して仮復旧をするという判断も場面によってはあるかもしれません。そのための判断材料(情報)を集めたり仮復旧の決定をするためのフローも対応手順です。

サービス停止を低減させるための対応手順

監視仕様では、サービスの停止には直結しないものの監視をする項目を定義しました。システムとして冗長化されているような部分です。サービス停止ではないため緊急対応は不要ですが、サービス停止を事前に予防するという観点で、何らかの障害検知をした場合の対応手順を用意する必要があります。

サービス停止の場合と同様に、内容によってはすぐに復旧できるものと、復旧にある程度時間を要するものがあります。この場合ももちろん、あるプロセスの再起動だけ実施すれば復旧するような障害であれば、システムにより自動復旧させる仕組みを用意したほうが明らかに効率的です。そういったものはシステムに任せ、対応手順としては、予防のためにいつ何をするかを定義するような内容にするのがポイントです。

再びECサイトを想定したhttps://example.com の例を見てみます。仮に、このサイトで事前に想定していない事象で「冗長化しているWebサーバーのうちの1台が停止した」という障害が発生したとしましょう。冗長化しているうちの1台なのでサービスへの影響は出ていません。

この場合の対応フローは次のようになります。

1. 原因調査の実施
2. 復旧方針の策定
3. 復旧作業の実施、復旧確認
4. 再発防止策の検討

想定していない事象なので、サーバーに対する具体的な操作手順は事前に用意されていません。しかし、状況の把握や、今回の事象を復旧させるための専用の手順を準備するといった、想定外の事象を想定した全体の流れを定義した手順はあらかじめ用意できます。

このような手順をあらかじめ用意しておくことで、サービス停止に至る前の段階で原因調査や対策をしっかり検討することができ、サービス停止を低減させる運用体制を作ることにつながります。結果、サービスの可用性向上にもつながります。

もちろん、ハードディスクなど消耗品の故障などはあらかじめ想定できる障害ですので、こういったものについては障害検知した段階で対応方法を検討するのではなく、あらかじめ想定される障害として明確で具体的な手順を用意しておくべきです。

まとめ

以上、対応手順の作り方についてみてきました。対応手順は、単純にサーバーに対する操作(オペレーション)手順を定義するにとどまらず、システムが提供するサービス全体を視野に入れて考える必要があり、そうすることにより、障害予防、可用性の向上につながることがわかるかと思います。

本章の冒頭で ”ITサービス持続性管理” には、事業継続を脅かす脅威を洗い出し、選別された驚異の大きさ、現実となる可能性、軟弱性の分析を実施することも含まれると書きましたが、これを行った結果を元に各対応手順を考えてみると、またさらに細かくそれぞれの手順の定義が変わってくると思います。事業に直結するような障害と、サービスには影響のない内部だけのマイナーな障害では全く対応手順は異なるはずです。

当社が提供するシステム運用サービスでは、このような視点で実際の障害対応手順の定義を行っています。すでに運用されているシステムに対しても見直しをさせていただき、障害が減って可用性が上がったという例もあります。単純なオペレーションではなく設計の見直しから対応可能ですので、運用でお困りの方は是非ご相談ください。

Tag： 監視設計 運用設計

• 

  第11回：可用性を高めるための監視仕様

• 

  セキュリティを高めるには？クラウドとオンプレミスのセキュリティ比較