“過去最悪”といわれる通信障害を起こしたKDDI(au)または「フールプルーフ」
タイトル写真は、「おわび返金、全契約者に 障害の影響、特定難しく ＫＤＤＩ」朝日新聞、２０２２年７月３０日記事から引用。
この表には、トラブル発生から解消までの時間が載っていないが、２０１８年のソフトバンクでは４時間半、２０２１年のドコモでは２９時間、そして今回のＫＤＤＩでは８６時間だった。影響人数とトラブル解消までにかかった時間の両方で、今回は携帯電話サービスとして過去最大のトラブルだった。
ＫＤＤＩ（au）の出した報告書が、下のものである。
この報告書をわかりやすくしようとした努力はわかる。しかしそれでも、ネットワーク技術を学んで、実際に仕事で携わった人でないと、原因部分の理解は難しいと思う。例えば、PGWという言葉が説明なく登場しているが、これはPacket data network Gatewayの略称である（そう書いてもわからないだろうけれど）。そこで、去年のドコモのトラブルと比較した表を見てみよう。
２０２１年のドコモのトラブルと比較した記事の中にある、上の表にあるように、ドコモもKDDIも、自分たちが行った作業が原因でトラブルを起こしている。また、その作業が元になって、通信の大混雑（輻輳）が起き、それを解消するまでに相当の時間がかかったことも共通している。
ＫＤＤＩのトラブルの原因は、この記事によると、「古い手順書を誤って使ってしまった」ということだ。
東京都多摩市のＫＤＤＩの拠点で２日未明、データの仕分けをする「コアルーター」の保守作業において設定ミスをしたという。
機器を交換する一般的な作業で、データの経路を切り替える際に古い手順書を誤って使った。
手順書には新しいものと古いものがあり、作業時は気づかなかったという。
吉村和幸専務は会見で、「管理の問題。古い手順書の方を選べるような状態になってしまった」と話す。
設定ミスによってデータが「片側通行」の状態になった。利用者の端末の位置登録などが何度も再送され、回線が渋滞する「輻輳（ふくそう）」が起きた。（中略）
信号などの流通量は最大で通常時の約７倍に上ったという。
通信量を規制しながら復旧しようとしたが新たな異常も見つかり、障害が解消するまで約６１時間かかった。
また、別の記事では、このように書かれている。
「（今回の通信障害は）防がなければならなかったものと思っている。（ルーターの）設定ミス（が原因）と言っているが、作業における指示ミスだった。オペレーターは指示通り作業した」
上の発言は、７月２９日にKDDIの高橋誠社長の会見の場でなされた。つまり、オペレータに指示する人が、間違った手順書を渡したということである。
フールプルーフ(foolproof)、またフェイルセーフ(fail safe)という言葉がある。下の記事に詳しい説明が載っている。
フェイルセーフとフールプルーフは「人がミスをすること」を前提として設計されることは共通しています。失敗したとしても安全を守るのがフェイルセーフ、そもそも失敗しないようにするのがフールプルーフです。
今回のKDDIのトラブルに当てはめると、フールプルーフとして、手順書を取り違えない工夫はこのようなことが考えられる。例えば、古い手順書は別のフォルダに入れて、「古い」ことを強調するようにしておくこと、手順書が正しいものかどうか、最低二人で確認することなどが考えられる。
また、フェイルセーフとして考えられるのは、輻輳が起きても、すぐ解消できるように備えておくことだろう。
KDDIはドコモの障害の発生後、輻輳が発生してもすぐに復旧できる手順の確保とシステムの設計見直しを実施しており、今回の障害発生後に、ドコモと同様の復旧手順を取った。しかし、それでも収まらなかった
このような対策はＫＤＤＩも行っていたが、それでもトラブルは起きた。どのような準備を、どのような人数で、どのように管理して行ったのかの具体的な情報は公表されていない。しかし、何かが足りなかったことは確かである。
事前にテスト環境でリハーサルをしたのだろうか。普段、模擬訓練をやっているのだろうか。あるいは、何回も行ってきた作業なので、作業者が油断していたのか。そのようなことを質問してみたい。
＜２０２２年８月１日補足＞
この方の記事内で紹介されている、記者会見の詳細記事を読みました。
手順書はマスター手順書というかたちで、本番環境と、シミュレーションしたテスト環境で、手順をすべて確認しています。
手順を確認した手順書が2種類あり、古い手順書と新しい手順書があり、今回は古い手順書のほうを間違って指示してしまったかたちになります。
古い手順書も古い環境では試験していますし、新しい手順書は新しい環境で試験をしていて、どちらも手順書としては正しいものです。ただ、指示するものが間違っていたというのが今回の事象となっています。
手順書に基づいてどういう作業をするかということについて、必ず承認作業があります。その作業のなかで、手順書が最新のファイルかどうかという確認はしましたが、承認のなかでミスに気づきませんでした。
慣れていない人が担当したのか、勘違いがあったのか、見落としたのか、詳細はわからないが、恥ずかしいことである。システムが巨大すぎて、人の手に余るのかもしれない。
＜ここまで補足＞
７月３日に、KDDIの高橋誠社長は、トラブルについての記者会見を開き、自らが状況を説明している。普通、システムに関わる説明は、技術担当責任者や、CIOなどが行うことが多いが、社長が記者の質問にすぐ回答できることについて、インターネット上では、称賛の感想を見かけた。
セブン・ペイのトラブル時の記者会見とは月とすっぽんであるのは確かである。しかし質問への受け答えがよくても、こんな重大事故を起こした経営者は無能である。
報道された、この人の経歴を見ると、経営者には珍しく、技術者としての能力が高いのかもしれない。
しかし、自分の技術力が高くても、部下を動かす管理能力が高いとは限らない。できる人は自分を基準にしがちだから、部下たちが自分並みにできると思ってしまいがちだという事例は過去に何回も聞いた。しかし、社長に最も求められるのは、部下にきちんと仕事を遂行させる力である。
上の記事が正しいかどうかはわからない。経費を減らさざるを得なかったのは、私が書いた記事のような事情があったせいかもしれない。
しかし、この記事の内容が正しければ、労働者の意欲をそいでおきながら、きちんとやれという経営者はいるべきでない。経営職をちゃんとした人に引き継ぐべきである。
年収２億円は、それにふさわしい人がもらうべきである。
IT企業は、相変わらず労働集約型である。いずれAIが人のやっている領域をカバーするようになるかもしれないが、当分は変わらないだろう。
KDDI's Worst Communication Failure Ever, or "Foolproof"
The title photo is taken from the Asahi Shimbun, July 30, 2022 article, "Apology refund, impact of disability on all contractors, difficult to identify KDDI".
This table does not show the time from the occurrence of the trouble to the resolution, but it was four and a half hours at Softbank in 2018, 29 hours at DoCoMo in 2021, and 86 hours at KDDI this time. This was the biggest trouble ever for a mobile phone service, both in terms of the number of people affected and the time it took to resolve the problem.
I understand the effort to make the report issued by KDDI easier to understand. However, even so, I think it is difficult to understand the cause unless you are a person who has learned network technology and was actually involved in the work. For example, the word PGW appears without explanation, which is an abbreviation for Packet data network Gateway (though you wouldn't know if it was written that way). So, let's take a look at a table that compares with last year's DoCoMo troubles.
As you can see in the table in the article comparing DoCoMo's troubles in 2021, both DoCoMo and KDDI are having troubles due to the work they have done. It is also common that, based on that work, heavy communication congestion occurred, and it took a considerable amount of time to resolve it.
According to this article, the cause of KDDI's trouble is that "An operator accidentally used an old runbook."
It is said that a setting error was made in the maintenance work of the "core router" that sorts data at the KDDI base in Tama City, Tokyo on the early morning of the 2nd. In the general task of exchanging equipment, operators mistakenly used old runbooks when switching data paths. There are new and old runbooks, and he didn't notice them during the work. At the press conference, Managing Director Kazuyuki Yoshimura said, "It's a management problem. The execution instructor is now in a state where he can choose the old runbook." Due to a setting error, the data became "one-sided". The location registration of the user's terminal was retransmitted many times, causing "congestion" in which the line was congested. (Omitted) It is said that the distribution volume of signals, etc. has increased up to about 7 times that of normal times. A technician tried to recover while controlling the traffic, but a new abnormality was found and it took about 61 hours for the failure to be resolved.
Also, in another article, it is written like this.
"I think (this communication failure) had to be prevented. I said that it was a misconfiguration (of the router), but it was an instruction error in the work. The operator worked as instructed. "
The above remark was made at the press conference of KDDI President Makoto Takahashi on July 29th. In other words, the person instructing the operator gave the wrong runbook.
There is the word foolproof and fail safe. You can find a detailed explanation in the article below.
Failsafe and foolproof are commonly designed on the premise that "people make mistakes". Fail-safe is to protect safety even if it fails, and fool-proof is to prevent it from failing in the first place.
Applying this to the KDDI trouble, as a foolproof measure, this is what can be done to prevent procedure manuals from being misplaced. For example, old procedure manuals should be placed in a separate folder to emphasize that they are "old," and at least two people should check whether the procedure manual is correct. Another possible fail-safe would be to be prepared to resolve congestion as soon as it occurs.
After the occurrence of DoCoMo's failure, KDDI has secured a procedure to recover immediately even if congestion occurs and is reviewing the system design. After this failure, KDDI took the same recovery procedure as DoCoMo. However, it still did not fit.
KDDI also took such measures, but problems still occurred. No specific information has been released on what kind of preparations were made, how many people, and how they were managed. But it is certain that something was missing.
"Did you rehearse in the test environment in advance?" "Do you usually do mock training?" "Or was the worker off guard because the work had been done many times?" I would like to ask such questions.
<Supplementary article on August 1, 2022>
I read the detailed article of the press conference introduced in this person's article.
The procedure manual is in the form of a master procedure manual, and all the procedures are confirmed in the production environment and the simulated test environment. There are two types of procedure manuals that confirm the procedure, the old procedure manual and the new procedure manual, and this time the old procedure manual is instructed incorrectly. The old runbook is also being tested in the old environment, and the new runbook is being tested in the new environment, both of which are correct runbooks.
However, the fact that the instructions were wrong is the event this time.
There is always approval work on what to do based on the runbook. During that process, I checked to see if the runbook was the latest file, but the approver didn't notice the mistake.
I don't know the details, but it's embarrassing, whether it was handled by an unfamiliar person, misunderstood, or overlooked. The system may be too big for humans.
<Supplementary article so far>
On July 3, KDDI President Makoto Takahashi held a press conference on the trouble and explained the situation himself. Usually, the explanation about the system is often given by the person in charge of technology or the CIO. On the Internet, I saw praise for the president's ability to answer the reporter's questions immediately.
Compared to the terrible press conference at the time of the Seven Pay trouble, it was certainly handled properly. However, even if his answers to questions are good, the manager who caused such a serious accident is incompetent.
Looking at the reported history of Mr.Takahashi, he may be a highly skilled engineer, which is rare for a manager. However, even if one's own technical ability is high, it does not necessarily mean that one has the managerial skills to run subordinates.
I have heard many times in the past of cases where capable people tend to set themselves as the standard and thus tend to think that their subordinates are as capable as they are. However, what is most required of the president is the ability to get his subordinates to do their jobs properly.
I am not sure if this article is correct. It may be that the reason they had to reduce expenses was because of the circumstances described in the article I wrote.
However, if this article is correct, there should not be a manager who discourages workers but tells them to do it properly. The management position should be handed over to someone who does it right. The annual salary of 200 million yen should be given to someone who is worthy of it.
IT companies remain labor-intensive. AI may eventually come to cover the areas that people are doing, but for the time being, this is not likely to change.
この記事が気に入ったらサポートをしてみませんか？