が、発表された資料がちと読みづらかったのでザッとまとめてみました。
コマンドミスにより、初期障害が発生
公開された資料（PDF）によれば、auは16日にメールシステムの更新を行うため、現行のサーバとバージョンアップ後の新サーバを切り替える作業を行なっていたようです。初めにユーザー認証サーバの切り替え作業を行ったものの、新しいレプリカのユーザ認証サーバにアクセスするところを現行のサーバにアクセスするよう誤ってコマンドを打ってしまい、ユーザ認証エラーが発生。
認証エラーの原因は、現行サーバのマスタとレプリカ間でユーザ情報が不一致となっていたこととされています。
このエラーは新サーバへアクセスするように作業を行ったところ、復旧したとのこと。
そして、一連の障害で最大規模の第2障害が発生
復旧したことで更新作業を続行、次は現行のプロキシサーバを新しいプロキシサーバに切り替えたところタイムアウトが発生。予期せぬエラーが発生したため現行のユーザー認証サーバにアクセスするよう切り替えたところ、複数ある新しいユーザ認証サーバの一部にハードウェア障害が発生。残されたサーバも過負荷によりダウンし、メールの送受信が不可能になったようです。
復旧作業として現行のユーザ認証サーバ（マスタ）に接続したところメールサービスが一時的に利用可能になったようです。
第2障害の復旧作業の不備により第3障害が発生
第2障害の復旧作業内にてメールBOXサーバを現行のユーザ認証サーバに接続するため再起動を行いましたが、再起動中にメールが滞留。さらに再起動の手順不備により、今度はメールBOXサーバが高負荷になったため、メールサービスが利用しづらくなったとのこと。
復旧作業としてメールBOXサーバへのデータ流入をコントロールしたところ高負荷状態が解消され、メールサービスが再度利用可能になったようです。
大規模な第2、第3の障害を発生させたタイムアウトエラーの原因については言及されず
auが一連の障害に対する原因として以下3つを発表しています。・手順書記載ミスによるコマンド誤り（事前検証試験不足）
・HW障害（片系）と二重障害時の対策準備不足
・メールBOXサーバ再起動手順の考慮不足
コマンドミスるわ、一方のサーバがハードウェア障害で使えなくなったら片方が高負荷で使えなくなるわ、メールBOXの再起動ミスるわで、これは酷いとしか言えないわけですが、ここに挙げられていない事象として気になるのは、新プロキシサーバへの切り替え後タイムアウトエラーが発生したため、現行のサーバへ再度切り替えたという判断ですね。
第2障害と第3障害を発生させた大元となっていますが、今回公開された資料にはその判断や対策が語られていません。
タイムアウトエラーが発生していたが、サービスは正常に利用できたとあるのでそのまま状況観察していたらどうなっていたんだろうとか考えちゃいますね。
アナウンスされていない小規模な不具合が起きていたことも明らかに
auが公開した資料によれば、4月16日〜19日にかけて以下3件の障害が起こっていたとのこと。1.2013年4月16日00時35分～01時41分 ー 100人に影響
2.2013年4月16日08時08分～13時29分 ー 288万人に影響
3.2013年4月16日13時29分～4月19日02時54分 ー 127万人に影響
2と3の障害についてはauのサイトでもアナウンスされていたものの、1の小規模な障害についてはアナウンスされていませんでした。
公開された資料によると、1の障害に対して復旧作業を行なっていることが明らかになっているため、auは障害を検知していながらアナウンスしていなかったことになります。
思ったよりもauってボロボロなんですな・・・。
【2013年4月15日 17:20 追記】
1の障害に関しては小規模であり、報告義務がないという指摘を受けました。
義務はなく、通常の障害であれば報告がなくても言及しませんが、今回の障害は連鎖的に発生したため、2の障害が復旧した時点で報告があっても良かったのではないかという意味合いで記載しています。
コメントを残す