止まらないシステムなど作れない、ITとおかねの話。

最近、大手航空会社のシステムトラブルが相次いだせいで「システム屋は無能」みたいなことを言い出すワカッテナイ人がいて中の人軽くイラっとしたのでちょっと真面目に書いておきますね。個別の案件には触れません。概要だけです。


まず前提として、

 稼働率が100%のシステムは絶対に作れません。

そして、

 稼働率はコストをかけることで上げられるが

 どれだけコストをかけるかを決めるのはSEではない



これを念頭に話を進めていきましょう。



稼働率が100%にならないのは、科学の世界に「100%」がありえないのと同じです。政治家はよく「100%ありえない」とかいいますが、自然界に100%なんてないんです。あなたが1秒後に隕石に当たって死ぬ確率は、限りなく低いですが、確率論として0にはなりません。0に非常に近いけれど、0ではないんです。

システム屋の世界では、「ファイブナイン」とか「シックスナイン」とかいう言葉が使われます。シックスナインは稼働率で9が6コ並ぶこと。すなわち、「99.9999%稼動する」(ただし一年の間に十数秒は停止する可能性がある)という想定のシステム。現在では、銀行の決済システムなど相当厳しく管理されているシステムでこのくらいです。それでも100%にはならない。

何故かは、故障の内容を見ていけば理解いただけると思います。



●ハードウェアの故障

システムの実態は、サーバやネットワーク機器などの物理です。クラウドとか仮想とか言われているものにだって実体はあります。それらは、実体であるがゆえに必ず故障します。故障した際にすぐにバックアップに切り替われば、障害時間は短くなりますよね? しかし、稼動している機械にバックアップを揃えるとなると、単純に考えて機材を買うお金が2倍かかることはお分かりいただけると思います。

故障時の切り替わりの早さには、ある程度、機械の性能が関わってきます。そして切り替えには、どう頑張っても数秒程度はかかってしまいます。稼働率を100%に出来ない大きな理由がここにあります。

機械自体の故障率を下げるという方法もありますが、いい機材を入れるにはやはりお金がかかります。


ハードディスクなど消耗品の故障ももちろんあります。システム停止要因にはなりませんが、放置することは出来ないので故障したら交換しないといけません。修理の早さは保守費用、つまりメーカーにいくら保守費用を積んでるかによります。故障連絡から4時間ですぐ部品を持ってきてくれるオンサイト対応とかは非常に高いです。土日対応なし/9時17時の保守は安いですが、連休中の夜中に故障が発生したら週明けまで放置になります。


定期的な機材の入れ替えも必要です。
機械の寿命はだいたい5年なので、5年くらい経つとシステム更改といって、新しいガワを作って移し変える必要が出てきます。ここにもやはりお金がかかります。更改費用がないからと放置しておくと、老朽化した機材が頻繁に故障して、システム稼働率がダダ下がりになるどころか、対応のための人件費もうなぎのぼりとなり、かえって高くつくこともあります…。


●外的要因による停止

発生確率は低いですが、発生すると致命的なのが地震などの天災や発電所のトラブルなどの事故。
東日本大震災のときは、工場にサーバマシンを置いてて、工場ごと流されてデータが全て吹っ飛んだ企業もありました。一般的なデータセンターであれば耐震・免振構造があり、自家発電所も備えているので、よほどのことがない限り天災や事故でのシステム停止はありません。が、良いデータセンターにシステムを置こうとすると間借り料が高いです。

自社に置いとけばタダ同然なところ、データセンターに入れると1ラック数十万とか百万とかするわけですから、どこまでリスクとコストの兼ね合いをするかは経営者の判断次第です。


また、過去には回線トラブルというケースもありした。いまどきインターネットに繋がってないシステムなどありえませんが、そのネット回線のキャリアがトラブルを起こしてネットに繋がらなくなってしまったというものです。コレを回避するためには、回線をニ系統引いておくという方法があります。たとえばNTTのフレッツ回線とau光を引いておいて、片方のキャリアが死んだときはもう片方に切り替えるというものですが、ニ系統契約するわけなので、もちろんお金は二倍近くかかります。


アンチウィルスの定義ファイルの不具合で一部のサーバが起動しなくなる、といったケースもありました。
これも前もって予期することが難しく、防ぐのが難しいです。回避策として、ウィルス定義は本番用サーバと同一構成の検証用サーバに導入し、問題ないことを確認してから本番用に適用する、ということをやってるシステムもありましたが、検証用サーバのぶんハードウェアの購入費が上がるのはもちろんのこと、検証する人を確保する人件費も余分にかかるのはお分かりいただけると思います。


**** ********

という感じで、ここまでの原因では、システムと稼働率は、 ひたすらお金との兼ね合い であることが何となくお分かりいただけましたでしょうか…。中の人は基盤屋なのであくまで基盤屋視点ですが。どこまでお金かけてシステム作るの? と言うのを決めるのはSEではありません。システムを発注したお客さん側の経営者です。


 あるシステム停止原因の発生確率はどのくらいか。

 発生した場合にとられる対応と、対応にかかる時間はどのくらいか。

 システムが停止することでどれだけの損失が生じるのか。


といったデータを元に判断が下されます。
航空会社のシステムなんかは、停止すると飛行機の運行も停止する可能性があり、大損害を齎すので、このへんはさすがにお金はかけてると思います。

では次に、SE起因となりうるシステム停止原因を書きます。


************

●未知のバグ

システム構築時に稼動テストが行われますが、(あってはならないことですが)そのテストに抜けもれがあり、バグを潰しきれていないということは、稼動開始から間もないシステムではよく起こります。お役所系のシステムは4月いっぴに稼動開始になることが多く、年度初めに障害を起こしてたりすると「あぁ…。」って感じでお察しになったり…。

しかしこれは、必ずしもシステム開発を任されたシステム屋の責任ではないこともあります。
特定の条件でしか発生しないバグや発生確率の非常に低いバグが紛れ込んでいることは多く、あとから発覚して修正されます。
また、新しくシステムを構築しようとした場合、新規で構築されたプログラムのみで作られることはまずないです。導入する機器のファームウェア、監視用の汎用ツール、サーバOSなど、別メーカー製の既存のプログラムが多数導入されます。

分かりやすい例だとWindowsサーバです。家庭用のWindowsにバグが見つかって定期的にアップデートがかかっていることを思い出してください。それと同じで、サーバOS用のWindowsでも、バグが発見されるたび定期的に修正されています。修正前にバグに引っ掛かると、運が悪ければシステム停止を引き起こします。(先日のA●Aの障害なんかはまさにソレ。ネットワーク機器の新規バグでしたね…)


さて、バグが見つかった場合、我々システム屋に必要とされるのは「いかにしてシステムを早急に復旧させるか」というスキルです。原因解明ではないです。稼動し続けることが前提のシステムの場合、原因はあとでゆっくり確認するとして、とりあえずログだけ取得して暫定でもシステムを動かそうとします。

停止時間=企業損失(お金) なわけですので。

しかし復旧のために飛んできてくれる or 現場に常駐しているSEも、お金次第です。
優秀なSEほどトラブル対処が的確で早いですが、人件費はスキルと比例します。常駐要員がおらず、システムに熟知した要員も確保していなかった場合、臨時で人をかき集めるところから始まるので当然復旧に時間がかかります。我々としても契約のないお客さんのシステムは助けに行けません…。


「万が一」の時のために保険としていくらお金を払うか。これを決めるのも、やはりシステム発注側の経営者だったりします。



●異常の見逃し

システムは、構築後に運用フェーズに入ります。日々動いているのを監視するという平和で退屈な部分です。具体的に言うと、システムが何かエラーを出さないか、オペレーションルームでモニター見てる、というような感じ。故障や異常を検知すると、対処方法が決まっているものはオペレーターが対処し、そうでない場合は上級SEに報告して判断を仰ぐことになります。

常時稼動が前提で、シックスナイン(稼働率99.9999%目標)などのシビアなシステムの場合、専用監視ルームに24時間、監視要員が複数常駐することになります。当然、そのぶん電気代や人件費は嵩みます。特に人件費が大きいです。オペレーターはスキルがなくても出来る単純労働とみなされているので、月収が20万台前半で夜勤頑張ってるような人もいます。でもその人たちのお陰でシステムは日々問題なく動いているわけです。彼らが異常を見逃すと、あとあと大惨事になることもありえるわけですから。。。


監視できていなかった項目で異常が見逃され、システム停止原因になったケースなどもあります。
その場合は監視を設計したSEの責任です。ゴメンナサイ。



●オペレーションミス

最後に、SEが原因となる障害について書いておこうと思う。エエ、当然やらかします。だって人間だもの。
何らかの設定変更や、日々の保守作業でのコマンドミス、障害対応失敗などでシステム停止または障害を発生させるケース。このケースでのシステム停止が発生した場合は、いいぜ、俺らを殴ってくれ…(´・ω・`)

本来は起きてはならないですが、人間が関わる限りヒューマンエラーはゼロには出来ません。これは言い訳ではなく現実としてそうなんです。そのため、システムの設計にはリスク回避として、ヒューマンエラーが発生した場合でも 影響を最低限にする/発生した場合に速やかに対応する という視点も考慮されることが求められます。しかしそこにもやはり、リスク回避のためのコスト、という問題が出てきます。



最初に書いたように、 システム稼働率を100%にすることは出来ません

コストをかければ稼働率を上げることは出来ますし、より多くの起こりうるリスクへの対処が可能となりますが、そこには「想定外」「現実的に対処が難しい」といった限界が存在します。

そしてまた、SEが原因でシステムが止まることは実は「あまり無い」。これまで稼動していたシステムが何かトラブルを起こした場合は、新しく何か追加したのでない限りはシステム屋が悪いわけではない可能性が高い、ということをご理解いただけましたら、幸いでございます。

だから

 システムトラブルのニュースが流れるたびに システム屋をいじめないでください。 (´・ω・`)


止めちゃいけないシステムなのに、必要なお金を払ってないケースも多いんです。…。


************

というわけで、このクッソ長い文章で伝えたかったことが、もう一つあります。
それは、

 システムは 作るときより

  稼動させ続けるのにお金がかかる


ということです。これをランニングコストといいます。

具体的には機材の運用・保守費用。故障・老朽化したときの機械の入れ替え費用と、人件費です。特に人件費が高い。システム屋も安値で買い叩かれてる業界です。専門職なのに運用監視の人の給料がやたら安いという現実は書いたとおりです。IT業界の人手不足は、ある意味、買い叩くお客さん側のせいでもあります。あんま大きな声じゃ言えないですけどねー!

見積もりを出すと、「なんでこんなに高いんだ」と文句を言ってくるお客さんもいます。
そんな時、必ず説明するのが、「このシステムによって生み出される利益と、もし停止した場合に生じる損失を考えて下さい」ということです。

今や、システムは業務運営にとってなくてはならないものだと思います。たとえばメールシステムが一日止まったとすれば、その日は一日、仕事が出来ないですよね? ファイルサーバも同じですよね? その一日の損失は、取引が停止した分の損失だけでなく、「出社していた社員全員ぶんの一日の人件費+後日そのぶんを取り戻すために費やされる稼動時間の人件費」です。一日止まると一億損するシステムを、年間数千万かけて止まってもすぐ復旧させられる状態に維持するのは安いはずです。

お金をかけずに、稼働率のいいシステム/故障確率の低いシステムは作れないです。
スキルの高いSEを抱え続けることも出来ません。
こればっかりは、精神論とかど根性ではどうにもならんのです。

必要なら…お金払ってください…。



************

なお、新しく作ったシステムを動かしたときや、システム改訂後に発生するシステム停止トラブルについては、大半が「納期重視で、そもそも完成レベルのシステムではないものを動かしている」といった論外なケースですので、ここには入れてません。(´・ω・`) 現実問題として、お客さんが無茶なスケジュールをごり押ししてきて「出来てない? 知るか、いいから動かせ!」みたいな言われることもあります…。

出来てないと判ってるものをSEが出来てるフリをして(ウソをついて)納品するということは普通ありえません。最終責任者は発注側なので、発注側がOK出さないと本番稼動させられないです。SEが無能であるよりは、最初からスケジュールが無茶だったり、資金不足のまま最低限の工数で無理やり作らされていたりるケースが多いですが、そのへん言い出すと言い訳すんなとキレる人もいるので^^; 

ただ、システム開発を委託する先を決めてるのもお客さんなんでね・・・。