システム障害は何からもたらされるか
システム運用エンジニアに長く従事していると、システム障害は必然によって引き起こされる部分も数多くある、ということを感じます。
もちろん、偶然による部分も否定できませんが、偶然偶然言っていたらいつまでも幸せにはなりません。システム障害報告書における「ごくまれに」という言葉や、「徹底する」という言葉は、言い逃れにしかなっていないケースが多いです。これらの甘えから来る発想を捨て、再現性のある方法で再発防止を考えていくこと。これを積み重ねていくことで新規のシステム構築時に生きてきます。そうやって作られたシステムというのは不思議なことにシステム障害発生率がとても低く抑えられるものです。
ということで、私の経験が教えてくれる「システム障害の原因」をまとめてみたいと思います。特に私はシステム運用を行う「人間」に興味があるので、人間系の話が中心となります。
考察
無知
オペレーターの無知からくるシステム障害。
もしくはオペレーターの計画に対してレビューするマネージャーが無知のため発生するシステム障害。
何しろ、「そういう手順が危険であることを知らなかった」ということを無知と言っています。
無知って怖いですよ。本人に何の悪気もない。
無知の人間に罰を与えても、何の解決策にもなりゃしません。説教しても何の意味もないですよ。なぜなら知らなかったのですから。
わかりました、もうしません、が関の山です。
しかし、無知によるシステム障害はできるだけゼロにしたいものです。ベテランの彼がやっていれば防げただろう、自分がやっていたらそんなことにならなかっただろう。
こつこつと、無知が多い人に知識を授けていくしかありません。いろんな作業を後ろに立たせて見せながら、このためにこうやってやるんだよ、と。
そしてその人が「知」を身に着けたという判断をしたら、やらせるけれども、できるだけ二人組でやらせる。
それぐらい、無知には警戒をしています。
一方で、自分自身も「知」を積み重ねていかないと、技術はどんどん進歩していきますから、「未知」の「無知」によって迷惑をこうむるかもしれない。
過信
信頼が過ぎる、過信。
クラウドを使えば絶対に障害は起きないだろう。
子のベンダーは頼りになるから任せっきりでいいだろう。
彼にお願いすれば問題なくやりきるだろう。
どこかで信頼がオーバードライブし、過信に代わる瞬間があります。
システム運用にかかわる人は、慎重すぎるぐらい慎重でいいと思います。
決して、「今流行の技術」だからといって簡単に手を出してはいけません。
流行の技術は、デザインセンスにあふれた技術資料がどんどん市場に流れます。これで実装したらすごいことになる。いいことだらけだ、と。
営業資料などは信頼をハックするためのテクニックですから、それに乗ってはいけません。過信しないこと。十分実績のある設計や技術要素こそ信用すること。
浅はかな信頼ほど障害原因を作りこむことになりがちだと思います。
モチベーションの低下
システム運用の世界は、100回同じ手順で実施して、100回成功させる部類の仕事です。
モチベーション。意欲と言いましょうか、会社に対する満足度、上司や同僚、部下との信頼関係、自分の健康状態、私生活の順調さ。いろいろな要素がこのモチベーションを左右します。
このモチベーションの低下が、100回同じ手順を実施したときの中の1回や2回の失敗要因となりうるのです。
もうどうでもいいや、ということです。
場合によっては悪質な事故や事件につながる場合もあります。
システム運用は、それを支える人間のモチベーションによって、大きく質が変わってきます。モチベーションが低いと、会社のみならず取引先への対応や世間への対応でも差別要因になってきます。
組織のモチベーションの状態を正確にとらえること。それに対する問題意識。低い場合の対応。それぞれ人間系の話ですが、システム運用品質に大きく関わってくるので面白いと思います。
慣れ/飽きを排除する
システム運用の現場は、毎日のログ確認が非常に重要です。
いきなり重大な障害が起こることもありますが、大抵は、何か予兆となるエラーを残しているものです。
この一行を、いかに重大に扱い素早く対処するかが運用品質を左右します。
サービスイン直後は、緊張感を持ってエラーメッセージに対処します。
そのうち、これは無視してよい、などのローカルルールが生まれます。
大多数が対処不要のエラーメッセージであることが多く、できるだけ不要なメッセージを出さないように監視条件を日々カスタマイズしていきます。
そんな運用を一年程度続けていると「慣れ」が発生します。
まあ今回も無視でいいだろう、と。
本来はエスカレーションした上ですぐに対処しなければいけないのですが、「いつものように」無視と報告して終わりにしてしまう。
そのうち、「飽き」が来て、そもそもログ確認自体適当にやってしまう。
そうやって重要なログをおざなりに対応してしまい、痛い目に合うことがあります。
マネージャーは「慣れ」や「飽き」を防ぐために、適度にメンバーに緊張感を与えなければいけません。なぜこのアラートは無視なのか。なぜ対応していないのか。
緊張感を継続するのは結構大変なことなのですが、マネージャーには自覚が求められると思います。
技術論だけではないシステム運用
システム障害のニュースを見るとだいたいが技術論に終始するのですが、人間系の話のほうがよっぽど大事だと思うことがあります。
人間系の方に問題を抱えているので、その結果技術的にありえない設計をしてしまったり手順を選んでしまう。
昔、ある原子力発電所にて、マニュアルにて汚染水の処理方法が決まっていたのに、明らかにスキルの低い作業員がバケツで汚染水を毎日廃棄していて、被爆してしまったという事件がありました。
いくら技術論からマニュアルを作成したって、現場の人が守らなければ意味がありません。またそんな危険なことを「無知」によってやってしまうという典型的な事例でした。
人間系に踏み込んで考えることが、ITと密接に関係しているのだということをたくさんの人が知り議論してほしいなと思う次第です。