Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
NTT、ネットワーク障害の原因を推定するAI技術を開発。従来のネットワークエンジニアによる分析と切り分けを不要に
NTT、ネットワーク障害の原因を推定するAI技術を開発。従来のネットワークエンジニアによる分析と切り分けを不要に NTTは、ネットワーク障害時にネットワーク機器などから発生するさまざまな警告などを分析し、障害の原因を分析、推定するAI技術を開発したと発表しました。 NTTによるとこのAI技術は、ネットワーク障害の対応履歴などを基にネットワーク機器などからのアラームと真の障害原因を教えていくことで、障害の原因を推定するルールそのものを自動的に作り出せるというもの。そしてこのAI技術によって、これまでネットワーク障害時に技術者が行っていた障害の切り分けや分析作業をAIが実行できるようになるとのこと。 本技術を用いた障害原因推定がシステム化されると、これまで数時間から数日かかることもあった分析作業を数秒程度に短縮することができ、スキルフリーで迅速なネットワーク障害対応が可能となります。 （プレス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
