金融監督庁報告もののシステム障害という地獄を経験した話

30年もIT通信の業界に身を投じていると、それなりにでっかいトラブルというものを経験します。

実運用に入っているシステムに障害が発生し、業務やサービスが提供できないというものですが、その障害が企業の業績に重大なインパクトを与えるような障害の場合、復旧後の対応はとんでもない地獄となります。

今回は、とある証券会社で経験した大障害について書いてみたいと思います。

１．とある証券会社が契約したスペシャルサービス

ある中堅証券会社がサービスを契約してくださいました。

サービスの内容は、専任のエンジニアがそのお客様のネットワークシステム、電話システムを把握し、重要障害が発生した場合にはそのエンジニアが率先して解決にあたるというものです。

通常、障害が発生した場合には、その障害の深刻度に応じてお客様が技術サポートセンター（TACと呼ばれていました）に連絡を入れ、障害内容に応じてエンジニアがアサインされ、対応をしていきます。

ただし、この場合どのエンジニアが担当になるかはわかりません。なので、お客様はTACに連絡を入れる際、都度システムの内容や環境を都度説明する必要があります。

お客様が購入してくださったサービスは、専任のエンジニアがお客様を担当し、あらかじめお客様の環境を把握しておくことで、重大障害発生時の初動を迅速に行うということができるというものです。

わたしは、その専任エンジニアとしてアサインされました。

実は、私にとって初めてサービスを担当するお客様でした。

２．平常時はバリューを見せられない障害対応サービス

入社してから鬼のように勉強し、CCIEもがんばって取得しましたがいかんせん経験がありません。

障害対応ってまさに経験がものをいうわけで、仮に発生してもいろんな人の助けを借りないとまったく対応できないという不安を抱えたままサービスは始まったのでした。

もちろんそんな懐事情はお客様に見せるわけにいきません。私は、いろんな方のサポートをもらいながらサービス対応を行っていきました。

このサービスは障害が発生したときにこそ価値が発揮されるものなので、平常時はサービスの価値を見せられないというジレンマもありました。

価値を見せるために、結局は軽微な障害に対しても対応をするという感じでした。それでも件数はそこまでなかったんですよね。本当にシステムは安定していました。

３．突如発生した、とてもとても深刻な重大障害

そうして契約満了期間の1年がそろそろくるかなというある日、それは発生しました。

そろそろランチの時間と思っていた時、技術サポートセンターにお客様から緊急連絡が入りました。

障害の重要度はプライオリティでP1～P4にランク分けされているのですが、その連絡は最重要障害「P1」でした。

メールの内容を見ると、

「西日本全拠点でお客様からの電話が着信できない」

というものでした。

おいおい、、まじかよ。。。

この障害、どれだけ深刻なものかわかるでしょうか。

この金融業界は、今でこそネットでの取引が盛んになっていますが、当時の主流は電話での注文でした。

午前中の株取引の時間を「午前の場」と呼びます。その午前中、お客様からの売買注文が一切受けられなくなってしまったのです。

会社側からするとまるまる利益を生み出す行為ができない、ということになりますし、株主からしても売買で利益を生む機会を損失したということにもなるのです。

４．障害の詳細がわかってきた

私たちに連絡が入ったのは、その仮復旧後のことでした。

私にとって、P1のケースは初めての経験です。

しばらくすると、現場の状況が詳しくわかってきました。

障害報告を連絡してきたSI会社の担当と会話をすると、そもそも外線が着信しないだけではなく、内線電話もものすごくつながりが悪くなっていることがわかりました。

SI会社は電話の呼制御をつかさどるサーバを再起動。それでいったんは復旧したかに見えましたが、まだ外線着信ができない現象が続きます。

各拠点の電話回線は「ボイスゲートウェイ」という装置から接続されています。各拠点に設置されているボイスゲートウェイををリモート操作で1台ずつ再起動していきます。

おそらく全部で100台規模の再起動を行ったと思いますが、ひとまずは電話が使えるようになり、午後の場からは復旧しました。

しかし、今回の障害となった原因が全くわかりません。

電話の障害対応を長年経験してきた先輩エンジニアでも、すぐには特定できません。

ここからなぜその問題が発生したのか、再発防止のためになにをしなければならないのかを迅速に解析し、手を打っていく必要があります。

障害対応のためのサービスを購入いただいているわけです。ここから迅速に対処ができないと、なんのためのサービスなのか、となってしまいます。

現地には営業さんがかけつけててお客様との会話をしてくれています。その会話の中で、実はお客様で独自開発されたアプリを電話システムに連携していたことが判明しました。

それは、私たちの知らないところでされていたのです。

問題が発生した変化点は、明らかにそのシステムをつないだことです。

営業さんからお客様を説得してもらい、いったんこのシステムを切り離してもらうことにしました。(お客様はかなり嫌がられたのですが、営業さんが強引にやらせた、という感じでした。この措置は、正しかったと思います。）

５．上司の障害に対するアンテナの感度はとても高かった

さて、当時の私の上司は、それはもうとんでもない鉄人でした。

いったい、いつ寝ているんだろうというくらいハードワークをこなされ、しかも判断も頭の回転も速い。

P1のメールが入った瞬間に自分の席に飛んで来られました。その顔は、これまで見たこともないような険しい表情です。

それはそうです。使えて当たり前の電話が使えないという状況なのです。オ恥ずかしながら私はこの上司の表情でようやく事の重大さを理解しました。

お腹の中に、ヒンヤリとしたものがたまってきて、それがズシッと感じられます。

６．障害対応チームの精鋭、解析に動く

そこからは緊急体制で障害対応チームが動きます。

私の上司が陣頭指揮をとり、電話障害対応チームメンバーがほぼ全員関わって対応することになりました。

SI会社から届くログ情報の解析の他に、再現試験を実施するため、環境構築にも入ります。

ログ解析は徹夜であたることになります。（ここから私はほとんど寝れない日がしばらく続くことになります。）

すると先輩エンジニアからログの解析結果から、呼制御サーバのCPUに高負荷がかかり、システムの正常化を図るために電話の処理を一時的に制限していたということがわかったとの情報が入ります。

問題は、CPUに高負荷がかかるような状態がなぜ発生したのかです。

また、外線の着信ができないという問題は、この現象からは説明がつきませんでした。

こちらは別のチームでボイスゲートウェイのログ等から解析が行われます。

すると、ボイスゲートウェイ側の問題はソフトウェアのバグであることが判明。修正されているバージョンにあげることで修正されることがわかりました。

７．地獄の経過報告

そしてお客様先への経過報告です。報告は、翌日に行うことになりました。

全てが判明しているわけではないので、経過報告となります。

この時点で辛かったのが、確実な原因が不明なので、この先問題は発生しない状態です、と言い切れないことでした。

お客様は、IT部の実質最高責任者まで参加されています。この障害は、金融監督庁への報告事案になっているようです。皆一様に険しい表情です。

報告は、私の上司が行うこととなりました。

お客様が連携した独自システムが明らかに怪しいのですが、まだこの時点では犯人だと言い切れません。

お客様としても、このシステムに対してそれなりに投資して用意されています。おいそれと主犯であってほしくはありません。

お客様の口調は厳しいものとなり、「いったいなにをやっているんだ！」と叱責が飛びます。

８．被疑システムの負荷検証を実施

CPUの負荷が高くなったことは事実なので、お客様が連携されたシステムがCPUに影響を与えないか私たちがテスト環境を構築して検証することとしました。

ここからは検証環境の準備とお客様のシステムを容易いただくなどの段取りでてんやわんやです。

サーバに対し、負荷をかけるストレスツールを使って負荷をかけ、連携したシステムを稼働しつつ検証を続けます。

結果、同じ現象はでませんでした。

実際にはありえないくらいの負荷をかけたときに呼処理の制限がみられたが、実際の現場でそこまでの呼量があったとは考えられません。

お客様に結果の報告を行う時が来ました。お客様も金融監督庁に報告するレベルの事案になっているので、きっちりとした対処をおこなわなければなりません。

結局、お客様が実施したシステム連携でなんらかの理由でCPU使用率が激上がりするどれかの不具合にひっかかったのだろう、と結論づけることとしました。

９．お客様への最終報告と対応策

最終的には、以下のような対応方針しました。

・サーバのスペックをより高いものに交換かつ代数を増やして処理のキャパシティを大きくする
・現在のソフトウェアバージョンに内包される、システム連携によりCPU使用率が100%に張り付く不具合にヒットしたと思われるので、それらが解消したバージョンにアップグレードする
・ボイスゲートウェイのソフトウェアをアップグレードする

お客様に報告し、了承を得ました。

その後、これらの作業を1年がかりで対処し、障害対応は完結したのでした。同様の問題は発生しませんでしたので、対処としては正しかったのだろうと思います。

10．上司から要求された対応内容とスピードはとてつもなく高い壁だった

当時、先輩エンジニアほどの障害対応ができるわけでもなく、経験も少なかったので、かなりマネージャから厳しい指摘を受けました。

いろいろ要求されるのですが、自分の処理がおいつかなくって、何度も真っ白になってしまいました

あのマネージャの要求するボリュームと速度の処理をやってのけられたら、それは間違いなくスーパーエースになれると思います。

経験をそれなりに積んだ今であれば、マネージャがなにをしようとしていなのか理解できますが、あのスピード感で対処できたかというと、今でもそれは厳しいかもと思います。。

ログ解析も、検証も、報告書も、ほとんど先輩方が対応してくださり、それを専任エンジニアという立ち位置で報告するという形はつらかったなぁ。

何よりも、自分の力量不足には本当に情けなく思いました。

12．大きな障害対応は自分の貴重な財産

それでも、この経験は、以降の自分のエンジニアとしての大きな経験となりました。

電話のように使えて当たり前のシステムが止まってしまう事がどれだけ深刻な事態になるかを痛いくらい勉強させてもらいました。

そして、障害を復旧させても、本当に勝負なのは原因究明と対策を見出すことだということも身をもって経験させてもらいました。

また、連日のプレッシャーと徹夜の連続が原因なのか、突発性難聴を発症してしまいました。。片耳が聞こえないんですね。昔一度経験したことがあったのですが、まあなっても不思議ではないかと思いました。

長年ITの世界を生き抜いてきた人は、大なり小なりこういった地獄を経験してきていると思います。

一つ言えることは、こういった経験は必ず自分の財産となっていくということですね。

成功体験よりも、こういった経験のほうがよっぽど役に立ちますよね。

そんな経験のひとつをご紹介させていただきました。

それではまた！

日々感謝 m(_ _)m