NTTビズリンクのデータセンターで電源設備故障が発生、その影響で13自治体のWebサイトの名前解決ができなくなるなどのトラブル 43
ストーリー by hylom
最近よく聞くデータセンターの電源トラブル 部門より
最近よく聞くデータセンターの電源トラブル 部門より
自治体などに向けたクラウドサービスを手がけるスマートバリューの「SMART CMS」および「いくくるウェブ」で6月4日夜から障害が発生し、同サービスを利用している自治体のWebサイトが閲覧できない状態になっていたとのこと。すでに障害は復旧しているという（同社の発表、日経xTECH）。
同サービスで利用していたDNSサーバーが、データセンターの電源設備故障で停止したのが原因とのこと。同社はDNSサーバーの運用を外部に委託しており、その委託先が使っていたNTTビズリンクのデータセンターで不具合が発生していたという（NTTビズリンクの発表）。これによると、データセンターのUPS設備内で短絡が発生してデータセンター内への電源供給が停止していたという。さらに分電盤内の突入電流防止装置が経年劣化しており、復電作業時に白煙が出るトラブルも発生したとのこと。
障害対応がお粗末すぎて (スコア:3, 参考になる)
まぁ見事に障害に巻き込まれました。
しかし障害発生に気付いたのは、5日朝にクライアントからの「繋がらない」の連絡で。
問い合わせ窓口のページはダウンに巻き込まれてアクセスできず、
サポート電話は繋がらず、
ようやく繋がった電話アナウンスで予備のサポートアドレスを知りアクセスするも情報は遅々として発信されず。
問い合わせフォームから「状況連絡欲しい」旨を伝えるも返信は4時間後。
その後も、1〜3時間毎にホームページに進捗状況をちょこっと載せるだけで、連絡一切無し。
その後、復旧の連絡はおろか、謝罪の連絡など全くありません。
データセンターの対応ってこんなもんなんですかね。
Re:障害対応がお粗末すぎて (スコア:2)
いわゆサービスレベルとかサポート体制とかであらかじめ合意してるんじゃないの？
それ以下なら怒るところだろうけど、それなりならそんなもんという話なんでは？
Re: (スコア:0)
そんなもんですよ。
幾ら払ってるか考えたらわかるでしょ。
Re: (スコア:0)
翌朝に気づく程度の運用の御社に言われてもね
Re: (スコア:0)
その程度のメール番でお給金いただける身に感謝だね☆
どうしたNTTグループ (スコア:0)
NTTコミュニケーションズで「水平移動」型の不正アクセス、621社の情報流出の恐れ
https://security.srad.jp/story/20/05/29/1620256/ [security.srad.jp]
Re: (スコア:0)
この事例によってほかの設備の点検も入れば行幸なんだが…
Re: (スコア:0)
僥倖？
Re: (スコア:0)
すみません誤変換です
予防定期交換 (スコア:0)
UPSにしても突入電流防止装置にしても、電源関係を定期的に老朽化の予防交換していないのって怠慢じゃないか？
でも、定期交換するUPSのバッテリーって費用が馬鹿にならないんだよなあ。制御装置の方も定期的に交換が必要だしな。
Re:予防定期交換 (スコア:1)
> 6.今後の対応について
> ・分電盤内部品については、耐用年数内であるものの、経年劣化による故障発生の恐れがあるため、７月以降改修を実施
耐用年数とは。
Re:予防定期交換 (スコア:2)
Re:予防定期交換 (スコア:1)
Re: (スコア:0)
換気不足等で雰囲気の温度が、データシートと異なっていたとかいうオチだったら笑うしかない。
じじいのぼやき (スコア:0)
「経年変化による劣化」がいつの間にやら「経年劣化」
「よろしかったでしょうか」並みに気持ちが悪い。
マイナスモデよろ。
Re:じじいのぼやき (スコア:1)
「年を経て劣化する」、経年劣化は経年変化の一種であって
それを誤用とするソースも見つからなかったんだけど
いったい何が気持ち悪いんだろうか、気持ち悪い。
Re: (スコア:0)
省略しようにも、経年変化だけだと、経年変化による音質の向上（えーじんぐ）とわかりづらいからでは（適当）
Re: (スコア:0)
建屋自体が古くてメンテナンス性悪いとかありそう
Re: (スコア:0)
UPSは予防交換以前にそもそも1系統故障してなんで停電するのって話じゃない?
Re: (スコア:0)
自前で施設も設備もハードウェアも持たずに月額課金するほうが安い事のほうがおかしいと思いますけどね。
安かろう悪かろう。
Re: (スコア:0)
普通に、各個に小規模な設備＆人員を持つより、それらを集約した大規模な設備等に委託したほうが安いのは
よくある話だと思うが？
Re: (スコア:0)
Google Colaboratory Proの契約しちゃった。thpr
微妙にずれてる (スコア:0)
自治体では無いが、うち系列でも葛西のデーターセンターで電源設備の障害が起きてネットが止まった。
件の時系列より遅くに発生し復旧は遅かった
Re: (スコア:0)
初動翌日昼過ぎってなめてるの？
1拠点だけなの？ (スコア:0)
クラウドサービスを提供するならDCが1つ死んだ程度で落ちる構成にしないでほしい
Re:1拠点だけなの？ (スコア:1)
きっとDon't Careなのでしょう。
DCだけに。
Re:1拠点だけなの？ (スコア:1)
ACならいくらでも予備がいるのにな
Re: (スコア:0)
スラド棚のウラはACの卵でいっぱいだー！
Re: (スコア:0)
誰AC卵留年
Re: (スコア:0)
ソースのコメントにびっしり卵がありそうでやだな。
変換して気付いたけど、🥚とか🍳とか余裕で出してきやがりますね。
玉子の絵文字にタピオカが無いかと探したけど見つからなかったAC
セカンダリDNSは? (スコア:0)
DNSなんてプライマリだけで運用してるようなところはほぼ無いと思うんだけど。
なんか隠してる雰囲気がプンプンするぜ。
Re:セカンダリDNSは? (スコア:1)
やだなあ。セカンダリなんて隣のラックに置いてあるに決まってるじゃないですかハハハ。
※実際問題キチンとセカンダリNSを分散させてあるところって少ないと思う。IPアドレスが隣だったりするし。
※勿論IPアドレスが隣でも分散させる方法はあるがわざわざそんなことするか？
Re: (スコア:0)
意外と政令市くらいまではきっちりやってそうだよ。
tracert しただけだけど。
しかし、東京はカネモッテルナァ
Re: (スコア:0)
物理的には複数の場所にミラーが置いてあって、インターネットに対してはanycastしているなら、
見えているIPアドレスが隣同士でも問題ない。
でも、出来れば権威DNSサーバは複数のものを別ASに分散させておいた方がいいよね。
Re: (スコア:0)
だから、
> ※勿論IPアドレスが隣でも分散させる方法はあるがわざわざそんなことするか？
となるわけで。
わざわざanycastするようならせめてDCだけでも分けて、おっしゃるように素直に別ASで、つまり連番じゃないIPアドレスでサーブするでしょ？って話で。
Re: (スコア:0)
ウチなんか、同じ筐体に入って（仮想化してるから）いるから、コンテンツサーバ（プライマリ、セカンダリ）、キャッシュサーバの全部が、一つのハードウェアが死亡すると全落ちするッス。
一部、特にキャッシュサーバを、（地理的に 30㎞ くら離れた）あそこの事業所にしましょうよと進言（理由もリスクも問題が顕在化したときの状況も説明済）しましたが、予算がおりませんでしたので、傍観してます。「だから、言っていたのに・・・」という事態になる前に逃げ切れればいいな。
Re: (スコア:0)
同じラックじゃないだけまし・・・
Re: (スコア:0)
わざわざっていか、public cloudなら普通はanycastじゃね？（てきとー
国産データセンタの障害原因 (スコア:0)
なんでこう毎度毎度お粗末な原因ばかりなんだろうな。
しかもお約束のように出てくる「委託先」って奴。
もちろん米国系クラウドも障害は起こすが、ソフトウェアの不具合とか大規模DDoS攻撃とか・・・
言ったら「技術者らしい不具合」って感じなんだけど。
Re: (スコア:0)
日本の場合、特に運用関係なんて「未経験者歓迎」で集めたド素人の中から簡単PGやテスターすらアウトだった人間送るトコになってるから。
そいつ等に保守作業割当できるように、なんてするから余計な手間が多く複雑怪奇なシステムになって開発し辛い→炎上の一因。
立て直しの時、そもそも余計な作業不要な設計にしたら凄まじかったからね抵抗が。
まあユーザー企業リーダーがマトモだったので押し切れたけど。
Re: (スコア:0)
え、AWSの北米の初期リージョンは停電とかしょっちゅうじゃん
結局会社じゃなくて場所によりけりじゃないの？
Re: (スコア:0)
AWSはデータセンター全断も設計時点で考慮されている仕様なので。
リージョン全落ちしない限りは想定内の挙動だし、ユーザもそれを踏まえて構築する。
本当に障害と言えるのは去年の東京リージョンの障害とかだけど、制御システムの不具合。