こんな事言ってはいけないと思いますが、現実問題としてシステムの開発/運用をやっていれば障害が発生してしまうこともあります。このような障害発生時に「適切な対応を取れるか？取れないか？」は非常に重要なポイントです。
それは、障害対応のやり方次第でお客様「信頼を失うこと」も逆に「信頼を得ること」もあるからです。
今回の記事では、障害発生時の適切な対応について私なりの考えを記したいと思います。
まずは「障害の規模/業務インパクト」について合意する
最初に発生した障害が「どの程度の規模であるか？、どの程度業務インパクトがあるか？」をお客様と合意する必要があります。ここで重要なのは事前にSLAなどで共通認識を持っていない限り、障害規模は「お客様が決める」ということです。
ご自分の担当しているシステムであれば「障害規模について何となく把握している」ように思いがちですが、最初から「でもコレって大したことないですよね？」とか言ってしまったらアウトです。例えば、
・利用人数が少ないシステムでもお客様のエクゼクティブが使うシステムだったら…
・1日のトランザクション量が少なくてもお客様に大きな利益をもたらすシステムだったら…
など、我々システム屋はシステム障害に伴う業務インパクトについて正確に把握していないこともありますので、障害規模に対する一人りよがりの判断は絶対にしてはいけません。
障害対応時の注意点
障害が発生したら対応しなければならないわけですが、障害の回復を急ぐあまり、焦って別の障害を引き起こしてしまうこともよくあります。ですので障害対応の方法/手順については少なくとも誰かにレビューしてもらってください。万一レビューしてもらう人がいなくても、書き起こしてセルフレビューすることは必須です。
障害報告について
障害対応をする前か後かは状況によって違いますが、システム障害でお客様の業務に何らかの影響が出たとすれば必ず障害報告を行いましょう。一般的な報告の内容は以下の通りです。
XXXXX障害に関するご報告
拝啓、貴社ますますご清栄のこととお喜び申し上げます。平素は格別のご高配を賜り、厚く御礼申し上げます。
この度は20XX年X月X日(X)に発生いたしました、「XXXXX障害」によりお客様へ多大なるご迷惑をおかけしたことをお詫びいたします。
当障害に関する当社からの報告を以下に記載させていただきます。
記
(1) 障害事象について
=>障害の内容について記載します。
(2) 障害発生時間
=>障害した日時について記載する､必要に応じて時系列に記載します。
X/X XX:XX ～ XX:XX
(3) 障害による影響
=>ユーザー側への影響について記載します。
影響範囲(誰に)：XXXX担当者とか全社員とか・・・
影響内容(どんな)：XXXができない、XXXされない
(4) 原因について
=>障害を発生させた原因について記載します。
(5) 対応について
=>対応方法について記載します。とりあえず障害回復を優先とした暫定的な対応を行った場合は「暫定処置として」と記載します。
(6) 恒久対応と再発防止策について
=>（「(5) 対応について」が暫定対応だった場合は、今後行う「恒久対応」と「再発防止策」について記載します。
「再発防止策」については今回同様の事象が発生しないとご納得いただける内容を記載する必要があり、「担当者を変更します」とか「以後気を付けます」といった類いのものはあまり納得感がありません。
障害対応をスムースに行う為に
この記事の最初に「まずは障害規模の合意が必要」と書きましたが、これに関しては障害発生前にお客様と合意しておくことも可能ですよね。
システム屋「これ止まっちゃったらどのぐらいマズいっかねぇ？」
お客様「夜間、休日ならともかく平日の業務時間中だとかなりマズいね」
特に問題が発生していないタイミングで障害のことを話題にするのは難しいかもしれませんが、日々のコミュニケーションの中で障害発生時の業務インパクトについてヒアリングしておけば仮に障害が発生してもスムースな対応が可能になりますし、非機能の改善にも繋がります。是非心がけてみてください。
コメント