アカウント名:
パスワード:
利用者からしてみれば問題の本質がパッと判り、対策が効果的で安心と納得できる事が重要だと思うんだけど、今回の資料は下請けの担当者が作成した内部報告書をそのまま貼り付けた印象を受ける。
例えば、
今回の原因： •手順書記載ミスによるコマンド誤り（事前検証試験不足） •HW障害（片系）と二重障害時の対策準備不足 •メールBOXサーバ再起動手順の考慮不足
となっているんだけど、
事象②（新ユーザ認証サーバの両系ダウン）の詳細と原因として
２）切戻し作業中に新ユーザ認証サーバ（レプリカ）の片系がHW障害でダウン。その後、残っていた片系も過負荷となりダウン、Eメール送受信が不可となった。（4/16 08:08）
が報告されているが、残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない。これだと元々冗長システムとして機能していなかったのではないかと言う疑念が残る。二重障害が起こったのはその結果ではないだろうか。
また、事象③（一部のメールBOXサーバにて高負荷が継続）の対策内容として
1）ディスクの処理能力を考慮した早期復旧手順の見直し •サーバ起動台数制限 •流量調整手順の追加2）流量調整ツールの導入 •メールボックス単位でのきめ細かい流量調整を可能とするツールの導入3)二重障害時でも十分なメールサーバ/ストレージの増強対策、ストレージの負荷対策4)社内の全システムのディスク処理能力の点検
となっているが、性能不足を改善する内容を挙げているにもかかわらず、「今回の原因」では触れていない。チグハグな報告によりどこまで問題点を整理できているのだろうかと不安が残る。
KDDIには、報告書としての抜けや矛盾点を指摘して、もっと判りやすく纏める人はいなかったのだろうか。
それにサービスの安定性や性能目標の視点から今回の問題を分析し利用者が安心できる情報を提供しようという姿勢が欠けている気がする。
まったく同意です。
>>残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない
２つある鯖の片方がダウンしたから残っていた鯖に負荷が集中してダウンしたんでしょ？分析はしているんじゃ？
それだと同じ能力のサーバだったと仮定して、倍の負荷で落ちたことになる。一台がHW障害で落ちたときにもう一台が倍の負荷で落ちるのは、認証サーバの重要性から考えると設計(性能見積り)ミスではないだろうか。分析というのはそういう視点も含むと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
技術に詳しく無い人にも判りやすく書ける人はいなかったの？ (スコア:5, 興味深い)
利用者からしてみれば問題の本質がパッと判り、対策が効果的で安心と納得できる事が重要だと思うんだけど、今回の資料は下請けの担当者が作成した内部報告書をそのまま貼り付けた印象を受ける。
例えば、
となっているんだけど、
事象②（新ユーザ認証サーバの両系ダウン）の詳細と原因として
が報告されているが、残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない。これだと元々冗長システムとして機能していなかったのではないかと言う疑念が残る。二重障害が起こったのはその結果ではないだろうか。
また、事象③（一部のメールBOXサーバにて高負荷が継続）の対策内容として
となっているが、性能不足を改善する内容を挙げているにもかかわらず、「今回の原因」では触れていない。チグハグな報告によりどこまで問題点を整理できているのだろうかと不安が残る。
KDDIには、報告書としての抜けや矛盾点を指摘して、もっと判りやすく纏める人はいなかったのだろうか。
それにサービスの安定性や性能目標の視点から今回の問題を分析し利用者が安心できる情報を提供しようという姿勢が欠けている気がする。
Re: (スコア:0)
まったく同意です。
Re: (スコア:0)
>>残っていた片系が何故過負荷になりダウンしたのか分析と報告が成されていない
２つある鯖の片方がダウンしたから残っていた鯖に負荷が集中してダウンしたんでしょ？
分析はしているんじゃ？
Re:技術に詳しく無い人にも判りやすく書ける人はいなかったの？ (スコア:1)
それだと同じ能力のサーバだったと仮定して、倍の負荷で落ちたことになる。一台がHW障害で落ちたときにもう一台が倍の負荷で落ちるのは、認証サーバの重要性から考えると設計(性能見積り)ミスではないだろうか。分析というのはそういう視点も含むと思う。
Re: (スコア:0)