日経ITProのシステムトラブルに対する記事に違和感

日経ITProの編集長が「木村岳史の極言暴論！」というシリーズもので記事を掲載しています。毎回、いろいろと考えさせられたり、納得させられたりする記事が多いのですが、今回掲載された「馬鹿に付ける薬があった！　システム障害を絶対に起こす猿を見習え」は読んでいて少し違和感がありました。「システム障害は絶対に起こしてはならない」ということが非常識だということを説く内容です。

「システム障害は絶対に起こしてはならない」というのは非常識であることはその通りだと思うのですが、気持ち的には「システム障害は絶対に起こさないように心掛けて運用しなければいけない」というのは必要だと思います。

システムを構成するのは、主にハードウエアとソフトウエアの二種類になります。ハードウエアはあくまでも機械ですので、初期不良や経年劣化で必ず壊れます。一台が壊れても大丈夫なように冗長化していたりもしますが、それでも単一障害点が残っていたり、切替先のハードでも不具合があったりして全面障害に陥ってしまう場合があります。ソフトウエアについても絶対にバグの無いプログラムを作るのは難しく、例えば発生頻度が極端に低い異常系のロジックにバグが残っていたりすることもあります。このような発生頻度が極端に低いロジックを通るような事象がたまたま発生してバグが顕在化しシステムが異常をきたす場合があります。

開発の段階では、このような問題を発生させないように幾度もの動作テストを実施し、開発しているメンバーは、本番運転後にこのようなシステム障害を発生させないように努力しますし、本番運転後にもこのような問題が発生しないように、運用保守の手順をしっかりと整備して、オペレーションミスが発生したり、ハードウエアの不調の予兆をあらかじめ検知して予防保守をしたりします。このような日々の取組があって、システムは安定して運用する面があります。ただ、このような地道な努力を積み上げているにも関わらず、システムが安定して動いていると利用している顧客側は毎年の保守費を削っていったりします。不具合なく動いていることは実は素晴らしいことなのですが、顧客にとってはこれが当然になってしまっていくのは実に残念なことだと思います。このように保守費を削りつつ「システム障害は絶対に起こしてはならない」というのは馬鹿げたことだと思います。

もちろんベンダー側は毎年の運用保守を通じて効率的に出来るところは効率化して、原価を削減していく努力をしなければいけませんし、顧客側も一部の作業はベンダー側から作業を引き取ってベンダーと顧客側の仕事の分担ラインを効率的になるように見直す、ベンダーへの作業指示の仕方を見直すといったような努力もしなければいけません。顧客側とベンダー側の協力体制が出来ていてはじめて、システムは安定運用も出来るし、保守運用の効率化も進むものだと思います。一方的に顧客側からベンダー側に費用削減の要請だけを繰り返しているような現場では、安定運用はままならなくなっていくでしょう。

記事の中では「たかだか数万人の顧客に迷惑をかけた程度なのに」という表現が出てきます。例に挙げているのがNETFLIXなので、もしもシステムが止まったとしても生死に影響するようなシステムではありませんが、故障を繰り返していれば中長期的にはお客さんが離れて行ってしまうので、やはりNETFLIXではシステム障害は起こってほしくないものだと思います。金融系のシステムなどお金を扱うようなシステムや飛行機の管制システム等では、「たかが数万人」という言葉は絶対に許されないでしょう。

「システム障害は絶対に起こしてはならない」という言葉がいつの間にか「障害は絶対に起こらない」にすり替わるというのも違和感がありました。どんなに安定して動いているシステムでも、ヒヤリ・ハット系の中小のトラブルはある程度の頻度で発生するためです。これらのトラブルを通じて、大きなトラブルに発展しなくて良かったと胸をなでおろしつつ、監視や運用の手順を見直していき、再発を防止する仕組みを作っていくという営みを繰り返し根強く実施していきます。さらには大きな障害が発生したことを仮定して故障回復演習を実施しているシステムも多いです。この気持ちがある限り、「障害は絶対に起こらない」という気持ちにすり替わることはないと思います。

記事としては、故障回復演習に相当するような取組みをした方が良いという話しになっていきますが、これは全くその通りです。大きなシステム故障を何年も経験していないと、大きなトラブルが発生した際に対応が混乱して回復に大きな時間がかかったり、二次被害を発生させてしまったりします。このトラブル対応力が風化してしまう原因は、システムの根幹部分に関する知識が薄くなったり、ログの見方が判らなくなったりといったテクニカルな部分もあります。しかし、もっと基本動作面でも問題が顕在化します。例えば、初期段階で誰を集めておくか、製品提供ベンダーの連絡先が判らない、白板等で情報を集約していないので対応メンバーが同じように状況を認識できていない、社内でどこの階層まで報告しておけば良いか判らないといった事象です。これらの基本動作面も含めて演習をすることが大切です。

どうしても、システムの運用保守を実施しているメンバーは地道な仕事が多いこともあって注目されることは少ないのですが、実はシステムを安定運用できていること自体が素晴らしいことなので、もっと注目したり研究されていって良い分野だと思います。今後は運用保守の仕組みの中にRPAや人工知能といった要素も取り込まれていき、アカデミックな要素が増えていくのではないでしょうか。