orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

KDDI障害報告、雑感

 

KDDIの大規模障害の報告内容を見て、思ったこと。

 

japan.zdnet.com

 KDDIは7月29日、同月2~4日に発生した通信障害の原因や再発防止策、顧客への補償などについて明らかにした。通信障害はコアルーターの経路設定ミスが発端となったことが分かった。

 

全方面に対策されていて、さすがだな、とは思った。

その反面、結局は人間による作業ミスがトリガーになっている。始めはハードウェアエラー基因みたいな話だっただが、突き詰めると結構そこに行きつくよね、という話は多い。ハードウェアがなかなか壊れることもなく、ソフトウェアのバグをつかまされることはあれど、そのバグですら人が作業したことをトリガーにすることが多い。

だから、できるだけ何もしないことが、障害を少なくすることの秘訣だということを知っている。

でも、作業はしなきゃいけないので、ここが技術者として腕を試されるところだ。できるだけやりたくない、は別にやる気がないわけじゃないのだ。何かやるから何かが起きる。作業を指示する方は、ここにあまり共感してくれないので、できるだけ問題が起きないようにするには現場で工夫するしかない。

さて、今回はヒューマンエラーが基因とは言うけど、現場の技術者としては、ちょっと作業を間違えたくらいで、こんな73億円の損害賠償にまで発展するような大事故になるような「設計」がおかしいよね、なんて思う。

人間が作業する以上は、失敗するのだ。失敗しても問題が大きくならないような設計が大事で、今回については「大規模化」という原因と対策がそれにあたる。問題がある輻輳をネットワーク全体に広げない。問題が起こった部分が問題を起こすのはこれはしようがない。技術者もベストは尽くすが、尽くしたところで必ず失敗しない保証はない。「徹底して撲滅して解消します!」というのが対策になったとしたら、報告書としてやり直しだが、KDDIの報告が優れているのはこの点だ。作業担当者が失敗しないようにするための工夫をしつつ、失敗しても大規模化しないための対策も着手している。

だから、今回は作業を失敗したこと自体も一つの要素であり、大規模化し、かつそれを収拾することに時間がかかったことの方が問題になっている点が、文脈として素晴らしいと思った。

ただし、結局は一か所の障害が全体障害につながるような設計について、インフラエンジニアとしては私は設計段階で、極力避ける。全体障害ということは、その下にぶら下がる顧客が同時にしびれる。でもこちらは一人なので、口は一個しかない。連絡に手間取り、問題解決をするリソースがなくなる。

マンションの建築などもそうだが、一つの家が火事を起こしても、建物全体が火事にならないような設計をしている。非常階段は、建物内部で火災が起きても火が移らないように工夫をしている。また、防火扉を適切に配置し、狭い箇所での被害に納まるように工夫されている。そういう意味では、火災と建物の関係と、システム障害への対策はすごく似ているような気もした。

初動から中間報告、そして対策まで、今回の件は教科書に載ってもいい模範的なプロセスだったと感じる。一方で、大規模システムの場合の、問題を大規模化させない設計については、大きな責任を負っていることを、設計観点から提起した。ぜひ、業界全体のためにも教材となってほしい一件である。