こんにちは、ばいおです。
今回は、SAPプロジェクトで本番障害を発生させてしまった際の対応方法について記載しました。
皆様は、自分のミスが原因で本番障害を引き起こしてしまったことはありますか？私はあります。
本番障害はとても怖いものです。本番障害を起こしてしまうと、モノにもよりますが、クライアントからの信頼を失ってしまうのは勿論のこと、内部からも強烈に詰められることとなります。
詰められるというのは、天性のドMの方ならばまだしも、あまり気分のいいものではありません。
この時ばかりは、今更どうしようもないことはわかっているものの、過去の自分の楽観的な考えを恨み、枕を濡らすこととなります。
一度本番障害を引き起こしたが最後、「あれは大丈夫なんだっけ？」「これも心配になってきた」というような不安が次々と襲い、色々手がつかなくなることも。。
しかし、どんなに注意していても、人間ミスをするときはしてしまうもの。起きてしまったものはもう仕方がないので、次なる最善手を速やかに打てるようにしましょう。
それでは、少し話がそれてしまいましたが、本題へと話を進めていきます。
本番障害を発生させてしまった時の対処法
①から④までのステップごとに解説をしていきます。
①障害の直接原因は何かを特定する
まずは、障害の元となった直接の原因を特定しましょう。
余程複雑なプログラムでもない限り、不具合の状況・データを確認すれば、何が悪さをしているかを特定するのはそう難しくないと思います。
この時、単に原因を特定すればそれで終わり、という訳ではなく、同時に考えておくべきことが２点あります。
１点目は「血が流れ続けているかどうか」です。
つまり、プログラムが実行不可能等の理由で直ちに誰かが困る状況が今尚続いているのか、ということです。
もしくは、障害となった不具合が原因で、誤データが量産され続けている状態であるという場合も、早急な対応が必要となってくるでしょう。
もし血が流れ続けているならば、早急に止血しなくてはなりません。止血が遅くなればなるほど、被害は広がっていくので、障害対応のスピード感を早める必要があります。
２点目は「後続に影響を与えていないか」です。
SAPはその特性上、広範にわたる領域・システムとデータを連携しています。
例えば、購買領域で作成したデータを会計領域で使用するという場合も多々ありますし、SAPを飛び越えて別のシステムとIF（インターフェース）連携している場合もあるでしょう。
もし貴方が購買領域の担当者だとしたら、会計領域に発生した誤データを修正するのは至難の業でしょうし、別システムに至っては直すことは不可能です。
なので、不具合が他領域・他システムにまで影響を与えてしまっていたら、その事実をそれぞれの担当者に伝え、修正してもらわなくてはなりません。
後続に影響している可能性が少しでもあるのならば、早々にそのことを伝え、調査してもらうのがベターです。
②障害の直接原因を取り除く対応をする（暫定的な対応）
②のステップは、前項①で言うところの「止血」にあたります。ここで実施する対応が根本的な解決となっていない場合は、「暫定対応」とも呼ばれます。
多くの場合、本番移送や本番リカバリ作業を伴うので、プロジェクトで定められた本番環境を触る上でのルールを守り、確実に止血しましょう。
ここの作業でミスがでると、察していただけると思いますが、二次被害につながります。
二次被害が出ると、どんな顔して謝ればいいかわからなくなるので、くれぐれも注意しましょう。
二次被害を防ぐポイントとしては、テストを適切に行えているかにかかっていると思います。
実施する対応が本当に不具合の解決になるかを確かめるために、テストをすると思いますが、ここでのテスト条件は可能な限り本番環境と同等の状況にするのが肝要です。
そうしないと、思わぬところで足を掬われることがあるかもしれません。
私の過去の苦い経験ですが、テストで使用したユーザと異なるユーザで本番リカバリ作業をしてしまったがために、想定外の代入処理が行われ、二次災害を引き起こしたことがあります。
やらかしが判明した時の私の絶望、想像していただけるでしょうか。。
③障害の根本原因は何かを特定する
無事止血が完了したら、次は障害を引き起こした根本の原因を調査する作業です。
ここが一番の詰められポイントです。
テストケースの考慮が不足していた、他領域との連携が不足していた、設計書と実装内容が異なることに気付かなかった、色々な理由が考えられますが、経験則から言って大抵の場合は「なんでこんなこともできなかったんだ。。。」という残念な理由です。
偉い人の無慈悲な正論攻撃を受け止めつつ、もう二度とこんな耐え難い苦しみは経験すまいと唇を噛み締めながら反省します。
そうして人は成長していくのです（何）
④再度同じ障害が発生しないよう対応する（恒久的な対応）
最後のステップ、障害の根本原因への対応を行い、同じ障害が再発しないようにする作業です。
②のステップで対応しきれていない不具合への対応をすることもあります。逆に、②で実施した作業以外に対応することがないのならば、④のステップは②と同一と見なし、スキップすることもあります。
③のステップで、障害を引き起こしてしまった根本の原因を特定できたと思うので、同じ不具合が起こる可能性があるものについて、総当りで確認していきます。
例えば、あるPGMの書式変換の仕様に不具合があったとすると、同じ書式変換のロジックを使用しているPGMを洗い出して総当りで問題ないか確認する作業を行います。
④のステップまでくると、既に緊急性は薄れていることが多いので、なあなあにしてしまいがちな部分ではありますが、ここの対応で手を緩めてしまうと、同じ内容の障害を発生させてしまうリスクに繋がりかねません。
もし、確認不足であったが故に、同じ内容の障害を二度引き起こしてしまったら、貴方は原因を何と説明しますか。私には弁明できる言葉が見つからない。。
また、これは②のステップと同じですが、本番移送・本番リカバリ作業を伴う場合は二次災害にご注意くださいませ。
ここでの対応をもって、障害対応を終えることから、「恒久対応」と呼ぶこともあります。
しかし、現実には、恒久対応したはずの不具合がゾンビのように復活することがあります。
不思議ですね。
おわりに
今回は、SAPプロジェクトで本番障害を発生させてしまった際の対応方法について記事にしました。
実際に本番障害を検知した時のポイントですが、まずは冷静になりましょう。
「あれ、これやばいんじゃね？」と思った瞬間から動悸を感じ始め、ダメだと判明した瞬間のあの絶望は何度味わっても耐え難いものです。「ヤバい！」と慌てる気持ちもわかりますが、慌てたところで事態が改善するわけでもないので、今回記事にした内容を参考にして、次の打ち手を冷静に判断しましょう。まあ、私も障害に直面したら未だに慌てますけど。
（ベテランの方でしたら、障害の１つや２つどんと来い！の心境なのでしょうか、、、）
まあ、別に本番障害を起こしたからといって死んでしまうわけでもないので、萎縮し過ぎるのも精神衛生上よろしくないですね。
大切なのは、適度な緊張感を持ってプロジェクトを進めることです。
本番障害は起こさないのが一番ですが、起きてしまったらしょうがないです！
気持ちを切り替えて、最善の対応ができるよう心構えしておきましょう。
ここまで読んでいただきありがとうございました。
