orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

人間は愚者であることを頭に入れればシステム障害は減る件

f:id:orangeitems:20200907122840j:plain

 

ちょっとドライな話ですが・・。

私は運用保守の仕事をしているので、システム障害が大嫌いです。どうすれば無くなるのだろうと日々、運用改善に取り組んでいます。

システムというのは、構築をし、テストをし、本番リリースします。そして修正を繰り返していき、利用を終えたら運用終了、となります。

これらのライフサイクルを何度も経験してきて、障害に至るパターンというのはほぼほぼわかっています。

障害が発生するのは、得てして、システムに変更を加える場合です。

だって、テストをしてクリアしたわけですから、その条件範囲の中では障害は起こりません。システム障害が起こるのは条件が変わった時です。条件変更は、システムの変更で起きます。

アプリケーションの機能を追加したとき。ハードウェアを追加したとき。ネットワークのポリシー変更を行ったとき。いろいろなケースで変更は発生し、その変更が、システム障害の起因となります。

何も人為的に変化させなかったとしても、インターネットやテレビなどでユーザー数が急激に増えたり、ハードウェアが壊れたり、など突発的な変化も起こります。ですから100%システム障害を避けることは難しいとしても、その変化の予兆をつかみ対応することは非常に大事です。予兆を見逃すことで大きな変化が起こってしまい、障害に巻き込まれます。

さて、このように、変化を管理していくことが大事な運用保守。その中で一番コントロールしやすいのは何か、というと、ヒトです。ヒューマンエラーの削減です。

変化は、ハードウェアトラブル以外は、人間が引き起こします。人間のうち、変化を最も大きく与えるのは、運用メンバーの変更作業です。この変更作業で、作業手順のミスによりシステム障害を与えることを、ヒューマンエラーと呼びます。

このヒューマンエラー、引き起こさないために、作業者単独で作業をさせず、確認者を付け二人体制で作業させる、というのはよくある対応です。作業を実施するときは、緊急時以外は二人で作業させるというのを、私の周りでも徹底しています。

では、二人で作業をしていれば、ヒューマンエラーは減るか。これは確かに減りはするのですが、もう一段上の対応が私は必要だと思っています。作業をする前の段階の作業手順書の作成。いわゆる計画段階で、かなりのヒューマンエラーを防げます。

作業するとき、ではなく作業をする前、でエラーが減らせるというのは、結構忘れ去られがちなので気を付けた方がよいです。

人間は愚者である。エラーをする生き物です。

一万回、ボールを穴に入れる作業があるとします。穴は十分な大きさです。ボールをつかんで手を放して穴に入れるだけの作業です。一万回です。数千回成功したとします。そしてあるとき、なぜか一度だけ失敗するのです。それは慣れによる気のゆるみなのか、私生活がうまくいかず集中できなかったのか、体力の不調なのか、何なのかはわかりません。

しかし、一万回のうち、一度はエラーをしてしまう存在、それが人間。

そんな人間が、失敗してはいけない作業をするのです。いくら、何度でも成功した熟練者だとしても、エラーをする前提で、作業前のレビューを行うべきです。

その視点を踏まえた場合に、作業準備を見ていくと、エラーを誘発しそうな手順の書かれ方をする場合があります。例えば、同様の手順をコピーしたときに、前回のパラメーターが残っているとき。コピーしたから当然ですが、そのパラメーターを作業者が誤って入れてしまうかもしれない。手順書作成者は、当然作業者は目的に応じて変更してくれるだろうと思う。しかし、作業するのは人間です。人間が愚者であることを前提に、準備しなければいけない。

システム保守の仕事が長いせいか、私は自分も含めて、仕事において人を信用していません。絶対ミスすると思っている。だから、ミスしないよう、あらゆる側面から、理詰めでエラーを誘発するような要素をかたっぱしから消していくような仕事を心掛けています。

人間をそんなに信用できないなら、コンピューターで自動化させればよい・・。それも確かな意見ですが、その自動化の仕組みも人間が作っているということも忘れてはいけません。愚者のプログラムは愚かなロジックを組み入れているかもしれません。

人間は愚者。これは性悪説とは違います。悪意はないのです。愚かなのです。最近はゼロトラスト、「社内外問わず誰も信頼できない」という前提に興味を持っています。

なんとなく、システム運用保守の仕事が私にフィットするのもわかってきた・・。人生観と似ているのかもしれない。