システム障害が立て続けに起こるカラクリとは

お疲れさまです。ゆとりのコアラです。

先週の日曜日に障害発生、その後ぞろぞろと別の障害が・・・。

久しぶりの更新となってしまいました。というのもまさに掲題の件、先週の日曜日以降、システム障害の対応に追われてしまい、帰宅時は無気力になっていたためです。

言い訳はほどほどに、システム障害には様々な種類があります。例えば、回線が取れたとか、機器が熱暴走するという純粋なハードウェアトラブル。または、想定していなかったデータ量が瞬時に発生して起こるアクセス負荷、そもそも考慮不足のデータが入力されることによって起こるソフトウェア不具合、使い方が悪くて発生するヒューマンエラー・・・、などなどキリがありません。

しかも、１つ起こると続々と障害は多発するものです。その原因は何なのでしょうか。

１．障害対応の精度は属人的になる

冒頭で述べた通り、システム障害を引き起こす原因は無限と言ってもいいほど多岐にわたります。それこそ、システムで構成した膨大な全ての分岐より多いのです。よって、具体的な復旧作業を事前にマニュアルとして残しておくことは困難です。

大抵のプロジェクトでは、障害対策マニュアルや、復旧マニュアルが存在するでしょう。しかし、このマニュアルに記載されているのは、電源を入れ直すや、回線を繋ぎ直すといった、システムの取り扱い説明書ではなく、「障害発生から〇〇分以内に、責任者へ連絡をする」「障害対応担当者をアサインする」「対応チームは、顧客調整、後続影響調査、横並び調査、普及作業、・・・に分けて平行稼働する」・・・といったチームの配置に関するものです。

このようなマニュアル自体は必須なものであり、問題ではありませんが、それぞれの作業ノウハウは担当者の経験に頼るしかないことが実情です。新任しかいないチームであれば、どれだけ連絡のスピードが速く、マニュアルに従ってアサインしたとしても、知識不足や経験不足により、原因特定には時間が掛かりますし、最悪、普及出来ないかもしれません。

そして、復旧作業に着手する全員が完璧な作業を出来ることは少なく、誰かのミスによって二次障害が引き起こされてしまうのです。

２．設計時に時系列の考慮が漏れやすい

システム開発時に、リリース後の稼働しているシステムを具体的に想像できるエンジニアは恐らく少ないでしょう。私も100%の自信を持って、障害が起きない設計を出来るとは言えません。（もちろん、どのように障害が起こるかを制御するよう努めますが）

特に時系列に関する設計では、考慮が漏れがちです。

例えば、この英数字チェック処理には、10万件のデータが投入され、処理に20分掛かる。ABEND発生した場合には、現地へ駆けつけるのに2時間、原因特定に1時間、原因データの除去に20分、再実行に20分掛かり、復旧までに3時間40分掛かる。

だから、成果物の作成時間には、納品リミットに対して4時間ほどバッファを持たせて、早く終了する必要があるのだ。という設計を、開発時にすることは困難でしょう。

そもそも、リリース後何年で10万件のデータが発生するようになるか、この処理と平行に稼働する他の処理はどのくらいあるか、システムへの負荷はどれくらいか、といったたくさんの情報が、開発時には提供されていないものです。

また、こういった情報集めは一次請けのベンダーが担うことになり、一次請けの担当者にシステム保守の経験が無ければ、残念なことに思いつきもしないのではないのでしょうか。

３．ヒューマンエラー対応は同時に起こる

ユーザーの使い方が悪く、意図しない動き方をしてしまうことはよくあります。例えば、生年月日を3016年と登録してしまうとか。これが後からユーザー自身では修正できないDB項目だったりすることもあります。

仕方なくシステム担当者がDBリペアを実施するハメになるのですが、こういったヒューマンエラーは1人が起こせば、20人が起こすと言いたくなるほど、同時多発的に発生するものです。

１つの対応中に次が起こり、また次、また次、・・・と緊急対応に追われるうちに元の開発案件などは進行出来ず、スケジュール遅延。リカバリのために、土日出勤で急いでやるが、十分に見直す時間が取られず不具合を作りこみ、今度はソフトウェア不具合での障害発生・・・。というのはよくあるパターンです。

この怒りをユーザーや、フェイルセーフ設計をしていなかった全員者へぶつけたいものですが、どちらも周りにはいませんから泣き寝入り。ヒーヒーいいながら自分で作りこんでしまった不具合を対応し、ヒューマンエラー解消のためのシステム改修を提案し、費用対効果を示し、やっと案件化できる・・・というような重労働をすることになるのですね。

４．障害対応中は交代出来ない空気

障害発生から復旧まで一気通貫で作業し、24時間労働を突破するというのも意外と見られます。（見られますよね！？）本来は、昼夜で違うメンバーと交代し作業したいところですが、引き継ぎ不足だったり、後任者への事象説明や、スキルがマッチしなかったり、あらゆる理由で突き抜けることがあります。

しかも、作業中は管理者が後ろに立ちっぱなしでいつ直るか、いつ直るか、とプレッシャーを掛けてきます。もちろん、管理者はこの間、2回ほど人員が交代しているのですが、トイレ・食事にも行きづらい空気、そんなんいいから早く直せというプレッシャーが数時間ごとに交代してやってくる元気な管理者から発せられているのです。

肉体労働ではありませんから、なんとか最後までやり遂げられていますが、なかなか人間として限界のところまで来ています。最後の方にやってる作業なんて本当に合っているのやら、終わってみてから不安になるほど朦朧としています。

それでも今のところミスなく完了しているので仕事が続いていますが、他チームではこれが原因では？と思う二次障害もちらほら・・・、この空気は論理的には全く役に立っていないと思われます。

おわりに

いかがでしょうか。

今回、記載させて頂いた内容はエンジニアであれば、いつかは遭遇する事態だと思われます。これが毎月のプロジェクトは相当病んでます。私のところは幸いにも、数年に1度ほどの頻度です。リリース後、初期の頃は多かった（年に数回）ですが、最近は安定していますね。

障害が立て続けに起こるカラクリは恐らく100%避けることは不可能でしょう。コンピュータが誕生してから数十年、いまだに無くならず、新技術が次々と生まれるこの業界において、間違いなく言えることは、障害はなくならない。ということ。

かといって、障害は起こります。なんて提案で言ったら殴られそうですけどね。でも、起こります。起こらないように作るけど、起こったときにどうするかを考えます。エンジニアは潔癖症の方の方が合うかもしれません。

以上！

システムはなぜダウンするのか