パスワードを忘れた? アカウント作成
8541378 story
インターネット

KDDIが4月16日から19日にかけて発生したiPhone/iPadでのメール障害の調査結果を発表 42

ストーリー by hylom
Androidには問題ないのに 部門より
insiderman 曰く、

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月末までにハードウェアの増強や負荷対策を行うとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2013年04月26日 5時25分 (#2370904)

    利用者からしてみれば問題の本質がパッと判り、対策が効果的で安心と納得できる事が重要だと思うんだけど、今回の資料は下請けの担当者が作成した内部報告書をそのまま貼り付けた印象を受ける。

    例えば、

    今回の原因:
     •手順書記載ミスによるコマンド誤り(事前検証試験不足)
     •HW障害(片系)と二重障害時の対策準備不足
     •メールBOXサーバ再起動手順の考慮不足

    となっているんだけど、

    事象②(新ユーザ認証サーバの両系ダウン)の詳細と原因として

    2)切戻し作業中に新ユーザ認証サーバ(レプリカ)の片系がHW障害でダウン。その後、残っていた片系も過負荷となりダウン、Eメール送受信が不可となった。(4/16 08:08)

    が報告されているが、残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない。これだと元々冗長システムとして機能していなかったのではないかと言う疑念が残る。二重障害が起こったのはその結果ではないだろうか。

    また、事象③(一部のメールBOXサーバにて高負荷が継続)の対策内容として

    1)ディスクの処理能力を考慮した早期復旧手順の見直し
     •サーバ起動台数制限
     •流量調整手順の追加
    2)流量調整ツールの導入
     •メールボックス単位でのきめ細かい流量調整を可能とするツールの導入
    3)二重障害時でも十分なメールサーバ/ストレージの増強対策、ストレージの負荷対策
    4)社内の全システムのディスク処理能力の点検

    となっているが、性能不足を改善する内容を挙げているにもかかわらず、「今回の原因」では触れていない。チグハグな報告によりどこまで問題点を整理できているのだろうかと不安が残る。

    KDDIには、報告書としての抜けや矛盾点を指摘して、もっと判りやすく纏める人はいなかったのだろうか。

    それにサービスの安定性や性能目標の視点から今回の問題を分析し利用者が安心できる情報を提供しようという姿勢が欠けている気がする。

    • by Anonymous Coward

      まったく同意です。

    • by Anonymous Coward

      >>残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない

      2つある鯖の片方がダウンしたから残っていた鯖に負荷が集中してダウンしたんでしょ?
      分析はしているんじゃ?

  • by Anonymous Coward on 2013年04月25日 23時07分 (#2370837)

    連絡先が表示できない時の対処方法に、
    SDカードから、復旧とかituneから復旧って手順が載ってるけど、

    これって、障害が復旧と言ってるけど、
    結局、データ消失と同じことだよね。

    復旧できないお客様は、ショップにお持ちいただければ
    復旧いたしますというならわかるけど、

    ちゃっかり最後に、お客のバックアップに頼ってるあたりが、
    やっぱりAuだなと思う。

    • by Anonymous Coward

      まあ、勝手に消えちゃうって仕様が糞なのは確かだが、勝手にバックアップとり始めるってのもどうかと思うし。
      危険性は以前から認識していたようで、保存先を変えるか、自動バックアップ対象になるよう移行するかアナウンスはしていたらしい。
      auユーザじゃないから知らないけども。そこのところどうなの?

  • by Anonymous Coward on 2013年04月25日 22時17分 (#2370813)

    ドコモもまさかの鯖のダウングレードでやらかしてたし、auは手順書ミスときたもんだ。

    スマフォ、iPhoneの先駆けであるSBMは、私は寡聞にして同様の問題を知らない。

    これは運用にかけてはSBMは優秀ということなのだろうか。
    Oh!MZ、Oh!X以外は全力で孫くんを避けてきた私だが、見直す時がきた
    ということなのだろうか。

    • Re:もしやSBMは優秀なのか (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2013年04月25日 23時00分 (#2370836)

      ヒント:パッチ未適用。

      …とかだったりして。(嗤エナイw

      親コメント
    • by Anonymous Coward

      そのかわりSBMは業務システムでやらかしてくれるから…

      • by Anonymous Coward
        SBMの業務システム…?
    • by Anonymous Coward

      メールに関しては、既にJの時代からの遺産なので
      そもそも改修できる人材がいないのでノータッチ。

      ネットワークに関しては、ガンガンやらかしてるけど
      そもそも通常運用状態で、レイテンシも遅いし、パケットロスもあるので
      多少問題を起こしても誰も気づかない。

      # という噂を某社の中から聞きましたが
      ## ええ噂ですよ。噂

    • by Anonymous Coward

      いろんな評判を聞くと単にどっかの電力会社以上に事故隠しがうまいのではないかと。
      指定通信事業者も逃げ回ってたぐらいだから、総務省への事故報告義務もNTT docomoやau by KDDIほど厳しくないし。

      • by Anonymous Coward
        主語がわからん
        • by Anonymous Coward

          志村~、タイトル、タイトル

          • by Anonymous Coward

            同じような障害起きていても、隠しているだけだと
            本気で言っているなら、正気を疑います

            そもそも指定通信業者も逃げ回るってw

    • by Anonymous Coward

      Oh!MZ、Oh!X以外は全力で孫くんを避けてきた私だが、見直す時がきた

      ソフトウェア卸の頃のソフトバンク社を(取引先として)知っている身としても、出版物等を買うこと(払った額だけ諦めれば済むもの)はともかく、中長期にわたるおつきあいだけは避けるようにしてきました。
      その後のYahoo! BBのADSLモデム街頭配布や、NTT局舎のコロケーションスペース占拠等のやり口を見るにつけ、三つ子の魂百までとはこのことだなぁ、と思ってもいました。
      はてさて、移動体通信産業においてはどうなのか。
      私はまだ、見直す時かどうか迷っています…。

      # ま、それ以前に。田舎在住なので、自分の生活圏で使い物にならない移動体通信は選択肢になりませんけどね。
      # 商品/サービスとして使い物になるようになったときが判断の時かな。まぁ、選択肢が増えるか増えないかだけですけどね。
      # 仮にそうなったとしても、親方日の丸α/βとSBMしか選択肢がないのはつらいなぁ…。

    • by Anonymous Coward

      そのレベルの中央側トラフィックが発生する前に無線側がパンクしてしまう、というオチだったりするのでは?

  • by Anonymous Coward on 2013年04月26日 2時27分 (#2370887)
    • by Anonymous Coward

      最近、iOSのバグでExchange Serverと過剰な通信が発生するのが発覚したらしいし、その辺りのサーバへの過負荷が関係しているんじゃないかと思ってる。

      iOSのバージョンアップで挙動や仕様が変わり、前は問題なく使えていたものがおかしくなるという事例はよくある。

      Exchangeが悪いんじゃなくて、iOSが悪いんだよな。

  • by Anonymous Coward on 2013年04月25日 18時12分 (#2370632)

    ぞっと背筋の凍る話ですね

  • by Anonymous Coward on 2013年04月25日 18時50分 (#2370673)
    過去のトピックに追記すれば十分でしょうに
    • by Anonymous Coward

      過去のトピックに追記しても誰も見ないからじゃ?

      # 2ページ目以降なんて面倒くさくて読まないよな

  • by Anonymous Coward on 2013年04月25日 19時08分 (#2370694)

    って印象ですね。もっとgdgdそうな所もありそうだけど。

    • by Anonymous Coward

      手順書記載ミスによるコマンド誤りって、まともにテストできる環境がなかったとかスケジュールに無理があったとか、もっと根本の原因があるんでないかい?
      これで報告終わりだとすると、きっとまたらやかすな。

      • by Anonymous Coward

        スケジュールの問題ではないでしょう。
        テスト環境に関しては、大規模になるほど用意するのが猛烈に困難になるから
        難しい問題ですな。

        中小企業の社内システムだったら全然問題ないんだけどね・・・。

      • by Anonymous Coward

        基本的に、今現状での役員、上層から見た現場は「手順書あれば誰でもできるんでしょ?」
        という認識止まりなのが、この手のトラブルが無くならない一因ではありますね。

        本来、ここで必要とされる人間は通常作業はできて当たり前、トラブル時に
        瞬間的に状況把握して対処、もしくは現状報告して、無理なら無理といえる人なんですけど
        普段のコストカットでそういう人間をどんどん切って、安い使えない人間ばかりを
        こういうところに投入してきた結果なので、自業自得ですね

        特にエンジニアが現場判断で障害回避しても、そんな指示してないと
        怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
        ちょっと冷遇されすぎですよね

        • by Anonymous Coward

          特にエンジニアが現場判断で障害回避しても、そんな指示してないと
          怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
          ちょっと冷遇されすぎですよね

          サーバの新規導入でconfigが間違ってて、とあるプロセスが動かなかった。
          ここで、現場の作業員が何を考えたか自分でconfig修正してプロセス動かして、
          動かしたあとに修正を元に戻して、作業完了の報告を上げやがった。
          数カ月後の計画停電で発覚、その作業員は出禁、といったことを思い出した。

        • by Anonymous Coward

          貴方の発想は危険すぎて論外です。学生さんですか?

          まさに「手順書あれば誰でもできるんでしょ?」の状態が正しいんです。
          そこに持っていくために力を尽くすのがエンジニアであり、その露払いをするのがマネージャです。

          • by Anonymous Coward on 2013年04月26日 1時13分 (#2370872)
            別ACだけど貴方のいうことこそまさに学生っぽい机上の空論だな
            ええ、いってることは正しいんですよ、ただ現実にはまず実現不可能というだけで

            で結果として元ACがいってたような事態に陥るわけよ
            親コメント
            • by Anonymous Coward

              自称社会人 vs 自称社会人
              ファイッ!!

          • by Anonymous Coward

            その手順書至上主義の問題点は、「人間はミスをするものだ」という当たり前の視点の欠如と、現場での臨機応変な対応の否定にあると思います。

            現場での作業ミスと手順書作成時のミスは、両方とも発生する恐れがあることに変わりはないはずなのに、手順書は優秀な人間が作るものであるから大丈夫とでも思われているのか、そこでのミス回避の方策は あまり練られていないのが実情ではないでしょうか。

            そして、確かに現場で勝手なことをやられては収拾がつかなくなるので、「手順書に書かれてあること以外はやるな」と指示するのは間違ってないんです。間違ってな

            • by Anonymous Coward on 2013年04月27日 7時09分 (#2371601)

              手順書を作る開発側と、本番環境の作業を担当する運用側との、業務の違いや役割分担を理解してからコメントしてくれ。

              ミス回避の方策として、まず切り戻し手順の整備、危険工程を手順書に書くようになっている。
              作業前に開発と運用で手順書の読み合わせをして、手順書に間違いや記載不足があれば、当然運用から指摘が入る。

              元コメでは「臨機応変な対応」をえらく称賛しているが、それはやっちゃいけない禁じ手だよ。

              親コメント
            • by Anonymous Coward

              「この手順書のこの箇所、間違ってるんじゃない?」と判断した現場の人が、往々にしてトラブルを引き起こすんですけどね。

            • by Anonymous Coward

              今回の件ではどうだったか知りませんが、難易度の高い作業だと手順書を作成した担当者も同席することがあります。
              ただし本番環境は触れないので、運用担当者が実行したコマンドの結果チェックなどをやります。

      • by Anonymous Coward

        そもそも想定外の障害(事象①)を起こした時点で作業中断、切り戻しするのが普通だよね。
        事前に検証をしてれば想定外の事象は起こらないかっていうとそんなことない。
        そんな時また作業中断の判断ができず先に進むようだと、またやらかすよ。

        本当に必要なのは適切な切り戻し手順と、その判断基準。

    • by Anonymous Coward
      あっちこっちから派遣された人ばかりで作業の意味すらわかってる人が殆どいないなんてことは普通にどこもありそう。

      しかし検証不足で切り替えがトラブった挙げ句、いざというときの切り戻しもトラブって大規模障害発生ってなんというお約束。
  • by Anonymous Coward on 2013年04月26日 4時22分 (#2370899)

    MNPで他社で移る際にも面倒が少ないし、キャリアメールからの脱却を考えてもいいと思う。

    • by Anonymous Coward

      キャリアメール使わなくなりましたね。
      若い世代もLINEとかにシフトしてしまってキャリアメール使っていないと思う。

typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...