2022/3/17 福島地震における通信障害状況まとめ

通信業者

NTT 固定電話の安定感が抜群。

通信に関しては NTTドコモが一番復旧は遅かった。

地震直後、NTTドコモの伝送経路故障というのがあるが、楽天には出ておらず、通信は何とかできる状態ではあったと思う。

どの通信業者も地震後5時間するとバッテリーが切れるので、地震後5時間以内に連絡を取り合ったほうが良さそうだ。

理由2022/3/16 23:362022/3/17 5:002022/3/17 7:002022/3/17 9:302022/3/17 12:022022/3/17 15:032022/3/17 17:47
NTT DoCoMo停電, 伝送経路故障福島県二本松市
福島市,
南相馬市
伊達市
福島県二本松市
福島市
南相馬市
伊達市
福島県二本松市
福島市
解消
KDDI基地局バッテリー枯渇相馬市
南相馬市
解消
ソフトバンク停電,宮城県白石市
村田町
川崎市
福島県相馬市
南相馬市
解消
楽天モバイル停電,宮城県
福島県
解消
ドコモを利用しているため
NTT東 固定電話 ネット障害無し

こういうことがあるとやっぱり電源も独立しているNTT固定電話もあったほうが良いなあ。

データセンタ

ソフトバンク系列IDCフロンティア

福島白河データセンタを運用しているが障害無し。

GMO iCLUSTA+ byGMO ラピッドサイト共用

実は我が社GMOのレンタルサーバーだった。その為一日以上メールが停止してしまい、仕事が楽お客様に多大なる影響を与えてしまった。だからあれほど Google Workspace(旧称 G Suite)にしとけって言ったのに(下請けさんが既に導入済み)。

社内的にもメールが使えず、結果としてTEL / FAX が登場。リモートワークの人には USB で持ってきてもらうという時代に逆戻り。

ところで GMO 社の対応を纏めてみた。仮復旧までに1日半かかっている。

2022/3/16 23:36電源障害
2022/3/17 6:50電源障害復旧
起動
2022/3/17 11:21サーバ確認
調整
2022/3/17 12:12サーバ調整
サーバ起動
2022/3/17 13:12サーバ調整
サーバ起動
2022/3/17 13:58サーバ調整
サーバ起動
2022/3/17 15:05サービスサーバーの一部問題が解決に向かいそうな状況です。
2022/3/17 16:55現在メールサーバーの起動を確認しております。
受信については順次回復の見込みとなります。
2022/3/17 18:40メールサーバーにつきましては、一部除きメールの送受信が可能な状況となり、
ほぼ復旧を確認しております。
2022/3/18 5:48Web表示につきましても順次復旧している状況でございます。
2022/3/18 7:00Webサーバー、メールサーバー、コントロールパネルの起動が完了し、
現在確認作業を実施しております。
2022/3/18 8:00すべての起動作業完了、ほとんどのサービスにて回復を確認し、
現在、仮復旧となっております。
2022/3/18 9:00サービスの回復を確認し仮復旧となっており、
経過観察を行っております。

一本ドラマ出来そう。戦うIT土方が上司と反発しまた同僚(いるのか?)と結託し活躍しそうだ。

地震より間隔
2022/3/16 23:36電源障害0
2022/3/17 6:50電源障害復旧
起動
07:14:0007:14:00
2022/3/17 11:21サーバ確認
調整
11:45:00
2022/3/17 12:12サーバ調整
サーバ起動
12:36:00
2022/3/17 13:12サーバ調整
サーバ起動
13:36:00
2022/3/17 13:58サーバ調整
サーバ起動
14:22:00
2022/3/17 15:05サービスサーバーの一部問題が解決に<<<向かいそうな状況>>>です。15:29:00
2022/3/17 16:55現在メールサーバーの起動を確認しております。
受信については順次回復の見込みとなります。
17:19:0010:05:00
2022/3/17 18:40メールサーバーにつきましては、<<<一部除き>>>メールの送受信が可能な状況となり、
ほぼ復旧を確認しております。
19:04:00
2022/3/18 5:48Web表示につきましても<<<順次>>>復旧している状況でございます。30:12:00
2022/3/18 7:00Webサーバー、メールサーバー、コントロールパネルの起動が完了し、
現在確認作業を実施しております。
31:24:0014:05:00
2022/3/18 8:00すべての起動作業完了、<<<ほとんど>>>のサービスにて回復を確認し、
現在、仮復旧となっております。
32:24:00
2022/3/18 9:00サービスの回復を確認し仮復旧となっており、
経過観察を行っております。
33:24:0002:00:00

「向かいそうな」「一部を除き」「順次」「ほとんど」等あやふやな言葉連発。

大体だけど

  • 電源回復まで7時間
  • ハードウェア?起動・メールサーバの起動に10時間越え
  • Webサーバ・コントロールパネルの起動に14時間以上

ここまでの作業時間31時間。作業員の方お疲れ様です。一個一個の VM に access して systemctl してたら呆れるけどね。

BCP(事業継続計画)は?

そしてここまで時間が掛かる理由は、停電に備えてリカバリーする手順とプログラムが無かった。という事でしょうね。

最近電力会社のお陰で本当に停電しなくなったので、こういった事態に備えてなかったのでしょう。

「クラウド」とは名ばかり

この件て「クラウド」と冠されていても実際には一つのサーバしかない事。そして「クラウド」だから安心ではない事。「クラウド」だからダウンタイムが短いわけではない。

という良い教訓という事で。今回データが吹っ飛ばないだけよかったんだよ。きっと。

引用
https://xtech.nikkei.com/atcl/nxt/column/18/01994/031700001/
https://support.gmocloud.com/info/?c=support_all
https://support.gmocloud.com/info/detail.html?no=73647
https://support.gmocloud.com/info/detail.html?no=73636

InterQ (いつものプロバイダーにつながらなければQ2へ) by GMO

OLE を oleview で調査し regedit する

OLEが上手く起動してくれない。個人的には一つのファイルの中にデータを埋め込める OLE は大好きだ。あんまり流行らなかったけど。

oleview.exe を探す。C:\Program Files\Windows Resource Kits\Tools で発見。

このツールは OLE/COM のオブジェクトを見れる。

Object Classes – Grouped by Component Category – Embeddable Object

が、OLE オブジェクト新規作成の時に出てくるリスト。この中から機能しないものを探す。

機能しないエントリの中の CLSID をメモする。

天下の regedit.exe を管理者モードで起動。CLSID で検索し、関連するエレメントを削除。

追記

正式にOLE登録 削除は

regsvr32

を使用。