おはようございます。
本日も私のブログをお読み頂きありがとうございます。
docomoの通信障害の原因が明らかになりました。報道によると、IOT関連の設備工事に不備があり、その対応として原状復帰（元のシステムに戻す）作業を行ったところ、旧システムに対する通信が集中して、２００万人以上の利用者に影響が出たそうです。
何とも、耳の痛いお話です。障害系の事前テストは、なかなか困難なテストです。正常系の移行テストは、正常である事を確認すればOKですが、異常系は、何が起こるか予測不可能な点が沢山あるため、ある特定のシナリオに沿って確認するのが普通です。
今回のような大規模のトラブルは、往々にして、小さな障害のリカバリーミスの積み重ねよより発生します。小さなミスの対応にミスを重ね、その結果大きな障害になり、回復までに長期間を擁するのです。昔の思い出が蘇って来て、胃が痛くなってきました。
記事を読んでいると、現場が大きく混乱している状況が目に浮かびます。東京の一つの工事が、全国に波及するなんて、現場で作業している人は想像だにしていなかったと思います。ミスを犯した直後は、ちらほらと、コールセンターの電話の量が増えてきたでしょう。そして、瞬く間に、コールセンターの通信回線がパンクしたでしょう。
本部では、何が発生しているのかを特定する事すらできず、右往左往する姿が見えます。
多分、今回の工事は、日常的な作業だったと予想されます。だから、ルーチンワーク化され、マニュアル通りに進めていたのですが、その時に、小さなミスを犯してしまったのでしょう。
発生時刻からも、その作業がルーチンワークであった事を物語っています。発生が１７時頃でした。大規模な作業なら、ユーザーの少ない深夜に行うはずです。
このように、大きな危険は、日々の作業の中に潜んでいます。熟練した人が難なく行っていた作業（仕事）は、その人のスキル、可視化されない知識や手順によるところが多いのです。
その隠れた情報を作業マニュアルに落とし込むことは至難の業です。作業マニュアルは、ある一定のスキルや知識を前提に作成せざるをえません。
特にITエンジニアや、経理や人事など、人の出入りが少ない部門では、よくある話です。だから、問題が発生していない、イコール、最適な状況ではないのです。偶然に問題が発生していないと考えた方が正しい認識であると思います。
コスト意識が高まるにつれ、バックオフィース系への合理化圧力が高ります。そのような限界状態で仕事を続けると、不測の事態に対応する弾性が無くなり、小さなミスが大きな問題に波及してしまいます。
効率化も重要ですが、その部門が担っている業務の重要性を認識し、つねに、事務や作業内容の見直し、文書化などの対策を行う事が出来るだけの余裕を与える。そのような仕事は、なんだか後ろ向きな仕事に見えますが、実はとても重要な仕事なのです。
docomoの障害の原因を聞いた感想でした。
終