KDDIが4月16日から19日にかけて発生したiPhone/iPadでのメール障害の調査結果を発表 42
Androidには問題ないのに 部門より
au版iPhone/iPadで4月16日から19日にかけて発生したメール障害について、KDDIがその調査結果を発表している（Eメールリアルタイム送受信システムの通信障害について）。
発生した障害は3つに分けられており、最初（2013年4月16日00時35分～01時41分）および2回目（2013年4月16日08時08分～13時29分）の障害では「サービスが利用不可」、3回目（2013年4月16日13時29分～4月19日02時54分）の障害では「サービスが利用しづらい状況」となっており、合計で68時間近く、最大で288万人に影響があったという。
障害の原因は、システムのバージョンアップ作業時のトラブル。事前にバージョンアップ後のソフトウェアを導入したサーバーを用意しておき、サーバーの接続を切り替えることでサービスの停止なしにアップデートを行う予定だったとのことだが、手順書のミスによって認証サーバーのマスター/レプリカ間でのデータ不一致が起きていたために一部ユーザーでメールが利用できない状況が発生したという。
この問題の修正後、続いて切り替えを進めたところ、「予期せぬエラー」が発生したためにアップデート作業を中止、現行設備への切り戻しを行ったが、その作業中にユーザー認証サーバーの片系がハードウェア障害でダウン、残りも過負荷でダウンしてサービスが停止、多くのユーザーでメールが利用できない状況になったそうだ。
さらにこの問題を修正後、「再起動手順上の問題および中継サーバに滞留した受信メールにより、62台中24台のサーバの高負荷状態が継続」したそうで、端末からのアクセス急増もありメール送受信が利用しづらい状況になったという。
これを受けて、今回の障害の原因として
- 手順書記載ミスによるコマンド誤り（事前検証試験不足）
- HW障害（片系）と二重障害時の対策準備不足
- メールBOXサーバ再起動手順の考慮不足
が挙げられており、4月～5月にかけて作業フローの見直しなどの対策を、そして8月末までにハードウェアの増強や負荷対策を行うとしている。
技術に詳しく無い人にも判りやすく書ける人はいなかったの？ (スコア:5, 興味深い)
利用者からしてみれば問題の本質がパッと判り、対策が効果的で安心と納得できる事が重要だと思うんだけど、今回の資料は下請けの担当者が作成した内部報告書をそのまま貼り付けた印象を受ける。
例えば、
となっているんだけど、
事象②（新ユーザ認証サーバの両系ダウン）の詳細と原因として
が報告されているが、残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない。これだと元々冗長システムとして機能していなかったのではないかと言う疑念が残る。二重障害が起こったのはその結果ではないだろうか。
また、事象③（一部のメールBOXサーバにて高負荷が継続）の対策内容として
となっているが、性能不足を改善する内容を挙げているにもかかわらず、「今回の原因」では触れていない。チグハグな報告によりどこまで問題点を整理できているのだろうかと不安が残る。
KDDIには、報告書としての抜けや矛盾点を指摘して、もっと判りやすく纏める人はいなかったのだろうか。
それにサービスの安定性や性能目標の視点から今回の問題を分析し利用者が安心できる情報を提供しようという姿勢が欠けている気がする。
Re: (スコア:0)
まったく同意です。
Re: (スコア:0)
>>残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない
２つある鯖の片方がダウンしたから残っていた鯖に負荷が集中してダウンしたんでしょ？
分析はしているんじゃ？
Re:技術に詳しく無い人にも判りやすく書ける人はいなかったの？ (スコア:1)
それだと同じ能力のサーバだったと仮定して、倍の負荷で落ちたことになる。一台がHW障害で落ちたときにもう一台が倍の負荷で落ちるのは、認証サーバの重要性から考えると設計(性能見積り)ミスではないだろうか。分析というのはそういう視点も含むと思う。
Re: (スコア:0)
データ消失と同じでは？ (スコア:2, 興味深い)
連絡先が表示できない時の対処方法に、
ＳＤカードから、復旧とかituneから復旧って手順が載ってるけど、
これって、障害が復旧と言ってるけど、
結局、データ消失と同じことだよね。
復旧できないお客様は、ショップにお持ちいただければ
復旧いたしますというならわかるけど、
ちゃっかり最後に、お客のバックアップに頼ってるあたりが、
やっぱりAuだなと思う。
Re: (スコア:0)
まあ、勝手に消えちゃうって仕様が糞なのは確かだが、勝手にバックアップとり始めるってのもどうかと思うし。
危険性は以前から認識していたようで、保存先を変えるか、自動バックアップ対象になるよう移行するかアナウンスはしていたらしい。
auユーザじゃないから知らないけども。そこのところどうなの？
もしやSBMは優秀なのか (スコア:1)
ドコモもまさかの鯖のダウングレードでやらかしてたし、auは手順書ミスときたもんだ。
スマフォ、iPhoneの先駆けであるSBMは、私は寡聞にして同様の問題を知らない。
これは運用にかけてはSBMは優秀ということなのだろうか。
Oh!MZ、Oh!X以外は全力で孫くんを避けてきた私だが、見直す時がきた
ということなのだろうか。
Re:もしやSBMは優秀なのか (スコア:2, おもしろおかしい)
ヒント：パッチ未適用。
…とかだったりして。（嗤ｴﾅｲｗ
Re: (スコア:0)
そのかわりSBMは業務システムでやらかしてくれるから…
Re: (スコア:0)
Re: (スコア:0)
メールに関しては、既にJの時代からの遺産なので
そもそも改修できる人材がいないのでノータッチ。
ネットワークに関しては、ガンガンやらかしてるけど
そもそも通常運用状態で、レイテンシも遅いし、パケットロスもあるので
多少問題を起こしても誰も気づかない。
# という噂を某社の中から聞きましたが
## ええ噂ですよ。噂
Re:もしやSBMは優秀なのか (スコア:2)
J-PHONE時代からのシステムそのままでドメイン追加やiPhoneへの対応ができるかどうか
すこし考えるくらいしないと、頭がもったいないですよ
Re:もしやSBMは優秀なのか (スコア:1)
他は改修しないと対応できないのに
手をつけられないのに対応できてるんだから超優秀ってことだな。
当人はディスってるつもりなんだろうけどロジック的に褒めているという……
わかってる気分になってるバカな人の典型ではあるね。
Re: (スコア:0)
つまりあれだ、いつも繋がらないなので事故かどうかわからんと。
いつこけるか不安な電話会社 [wdic.org]→docomo,au
いつまともに繋がるか不明な電話会社 [wdic.org]→ソフトバンク
Re: (スコア:0)
いろんな評判を聞くと単にどっかの電力会社以上に事故隠しがうまいのではないかと。
指定通信事業者も逃げ回ってたぐらいだから、総務省への事故報告義務もNTT docomoやau by KDDIほど厳しくないし。
Re: (スコア:0)
Re: (スコア:0)
志村～、タイトル、タイトル
Re: (スコア:0)
同じような障害起きていても、隠しているだけだと
本気で言っているなら、正気を疑います
そもそも指定通信業者も逃げ回るってｗ
Re: (スコア:0)
ソフトウェア卸の頃のソフトバンク社を（取引先として）知っている身としても、出版物等を買うこと（払った額だけ諦めれば済むもの）はともかく、中長期にわたるおつきあいだけは避けるようにしてきました。
その後のYahoo! BBのADSLモデム街頭配布や、NTT局舎のコロケーションスペース占拠等のやり口を見るにつけ、三つ子の魂百までとはこのことだなぁ、と思ってもいました。
はてさて、移動体通信産業においてはどうなのか。
私はまだ、見直す時かどうか迷っています…。
# ま、それ以前に。田舎在住なので、自分の生活圏で使い物にならない移動体通信は選択肢になりませんけどね。
# 商品／サービスとして使い物になるようになったときが判断の時かな。まぁ、選択肢が増えるか増えないかだけですけどね。
# 仮にそうなったとしても、親方日の丸α／βとSBMしか選択肢がないのはつらいなぁ…。
Re: (スコア:0)
そのレベルの中央側トラフィックが発生する前に無線側がパンクしてしまう、というオチだったりするのでは?
すごい組み合わせ (スコア:1)
サーバーはExchangeらしい [impress.co.jp]
Re: (スコア:0)
最近、iOSのバグでExchange Serverと過剰な通信が発生するのが発覚したらしいし、その辺りのサーバへの過負荷が関係しているんじゃないかと思ってる。
iOSのバージョンアップで挙動や仕様が変わり、前は問題なく使えていたものがおかしくなるという事例はよくある。
Exchangeが悪いんじゃなくて、iOSが悪いんだよな。
クロユリ団地楽しみ (スコア:0)
ぞっと背筋の凍る話ですね
同じ障害の話をなんどもなんども… (スコア:0)
Re: (スコア:0)
過去のトピックに追記しても誰も見ないからじゃ？
# 2ページ目以降なんて面倒くさくて読まないよな
内情はgdgd (スコア:0)
って印象ですね。もっとgdgdそうな所もありそうだけど。
Re: (スコア:0)
手順書記載ミスによるコマンド誤りって、まともにテストできる環境がなかったとかスケジュールに無理があったとか、もっと根本の原因があるんでないかい？
これで報告終わりだとすると、きっとまたらやかすな。
Re: (スコア:0)
スケジュールの問題ではないでしょう。
テスト環境に関しては、大規模になるほど用意するのが猛烈に困難になるから
難しい問題ですな。
中小企業の社内システムだったら全然問題ないんだけどね・・・。
Re: (スコア:0)
基本的に、今現状での役員、上層から見た現場は「手順書あれば誰でもできるんでしょ？」
という認識止まりなのが、この手のトラブルが無くならない一因ではありますね。
本来、ここで必要とされる人間は通常作業はできて当たり前、トラブル時に
瞬間的に状況把握して対処、もしくは現状報告して、無理なら無理といえる人なんですけど
普段のコストカットでそういう人間をどんどん切って、安い使えない人間ばかりを
こういうところに投入してきた結果なので、自業自得ですね
特にエンジニアが現場判断で障害回避しても、そんな指示してないと
怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
ちょっと冷遇されすぎですよね
Re: (スコア:0)
特にエンジニアが現場判断で障害回避しても、そんな指示してないと
怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
ちょっと冷遇されすぎですよね
サーバの新規導入でconfigが間違ってて、とあるプロセスが動かなかった。
ここで、現場の作業員が何を考えたか自分でconfig修正してプロセス動かして、
動かしたあとに修正を元に戻して、作業完了の報告を上げやがった。
数カ月後の計画停電で発覚、その作業員は出禁、といったことを思い出した。
Re: (スコア:0)
貴方の発想は危険すぎて論外です。学生さんですか？
まさに「手順書あれば誰でもできるんでしょ？」の状態が正しいんです。
そこに持っていくために力を尽くすのがエンジニアであり、その露払いをするのがマネージャです。
Re:内情はgdgd (スコア:1)
ええ、いってることは正しいんですよ、ただ現実にはまず実現不可能というだけで
で結果として元ACがいってたような事態に陥るわけよ
Re: (スコア:0)
自称社会人 vs 自称社会人
ファイッ!!
Re: (スコア:0)
その手順書至上主義の問題点は、「人間はミスをするものだ」という当たり前の視点の欠如と、現場での臨機応変な対応の否定にあると思います。
現場での作業ミスと手順書作成時のミスは、両方とも発生する恐れがあることに変わりはないはずなのに、手順書は優秀な人間が作るものであるから大丈夫とでも思われているのか、そこでのミス回避の方策は あまり練られていないのが実情ではないでしょうか。
そして、確かに現場で勝手なことをやられては収拾がつかなくなるので、「手順書に書かれてあること以外はやるな」と指示するのは間違ってないんです。間違ってな
Re:内情はgdgd (スコア:1)
手順書を作る開発側と、本番環境の作業を担当する運用側との、業務の違いや役割分担を理解してからコメントしてくれ。
ミス回避の方策として、まず切り戻し手順の整備、危険工程を手順書に書くようになっている。
作業前に開発と運用で手順書の読み合わせをして、手順書に間違いや記載不足があれば、当然運用から指摘が入る。
元コメでは「臨機応変な対応」をえらく称賛しているが、それはやっちゃいけない禁じ手だよ。
Re: (スコア:0)
「この手順書のこの箇所、間違ってるんじゃない？」と判断した現場の人が、往々にしてトラブルを引き起こすんですけどね。
Re: (スコア:0)
今回の件ではどうだったか知りませんが、難易度の高い作業だと手順書を作成した担当者も同席することがあります。
ただし本番環境は触れないので、運用担当者が実行したコマンドの結果チェックなどをやります。
Re: (スコア:0)
そもそも想定外の障害（事象①）を起こした時点で作業中断、切り戻しするのが普通だよね。
事前に検証をしてれば想定外の事象は起こらないかっていうとそんなことない。
そんな時また作業中断の判断ができず先に進むようだと、またやらかすよ。
本当に必要なのは適切な切り戻し手順と、その判断基準。
Re: (スコア:0)
しかし検証不足で切り替えがトラブった挙げ句、いざというときの切り戻しもトラブって大規模障害発生ってなんというお約束。
キャリアメールからの脱却の時期か (スコア:0)
MNPで他社で移る際にも面倒が少ないし、キャリアメールからの脱却を考えてもいいと思う。
Re: (スコア:0)
キャリアメール使わなくなりましたね。
若い世代もLINEとかにシフトしてしまってキャリアメール使っていないと思う。