ノースバージニア州ではAmazon S3バスケットが利用できないため、Dockerのレジストリハブ、GitHub、GitLab、Quora、Medium、Twitch.tv、Heroku、Courser、Bitbucketなどのサービスが中断されました。
/写真エミリオ・キュッファー CC
Amazonのエンジニアは、日中に状況の制御を取り戻し、すべての情報を更新することができました。 公式声明によると、サービスの機能は最初のバグレポートが表示されてから5時間以内に復元されました。
3月2日、Amazonは状況とそれを引き起こした問題に関する詳細なレポートを提供しました 。 同社は、シャットダウンは支払いシステムの問題を解決している従業員によって引き起こされたと主張しています。 彼は生産環境で間違ったチームを作成し、生産性を向上させました。
「Amazon Simple Storage Serviceチームは、S3課金システムの低速化の問題を解決しました。 太平洋標準時の午前9時37分（モスクワ時間19時37分）に、承認された計画を使用してチームメンバーが、S3サブシステムの1つから少数のアクティブなサーバーを削除するはずのチームを紹介しました。 「残念ながら、オペレーターの1人が誤って入力されたため、さらに多くのサーバーが削除されました。」
S3は過去数年間で驚異的な成長を遂げているため、サービスの再起動とサポート、および必要なセキュリティチェックの実行には、サポートチームで予想されていたよりも長い時間がかかりました。
同様の状況は、最も著名なプロバイダーでも発生する可能性があります。 私たち自身、非常に異なる性質の問題を経験しました。 重要なのは、そのような状況に企業がどのように反応するかです。人的要因が大きな役割を果たします。 多くの場合、誤動作の主な原因です。
わが国で発生した最大の事故の1つは、総顧客数の約10％に影響を及ぼしました。 クラウドとの境界でネットワークサービスの完全な障害が発生しましたが、数時間以内に機能不全を特定し、その発生につながったアクションを分析することができました。
そのような状況での迅速な分析は、そのような問題を解決した経験と、夜間でも連絡を取り合う十分な数の有能な専門家の可用性に基づいてのみ可能です。 最初に行うのは、明白な評価です。 これは、次の営業日を待つことを少しも考えずに、緊急電話会議を収集することで行ったものです。
これに続いて、顧客への通知が行われます。この中で、この時点で収集される最も完全な情報を提供することが重要です。 より詳細な調査の結果に基づいて、SLAに従って補償として顧客への支払い額を決定する価値があります。
数時間以内にサービスが利用できなくなった場合、特定のクライアントの支払い額はそれほど重くないように見えるかもしれませんが、新しいIaaSプロバイダーにとっては、報酬は財政に大きな打撃を与える可能性があります。 あなたの強さを計算し、評判のリスクを比較検討することが重要です。
私たちにとって、顧客との良好な関係は、一時的な節約よりもはるかに価値があります。 したがって、SLAの支払いをより大きな側に「切り上げる」ことにしました。 この動きは、問題の迅速な解決と相まって、私たちの行動の肯定的な評価を伴う膨大な数のレビューの流入に貢献しました。
そのようなイベントの結果として、エラーの処理は常に続きます。 Amazonは、潜在的な損害を減らすために、デバッグツールの機能を制限したり、サービスを小さなセルに分割したりするなど、将来的に同様の状況を回避するための予防措置を講じると言います。 また、監査プロセスを改善して、必要なすべての監査を整理することも計画しています。
すべての開発者がアプリケーションを複数のデータセンターに分散しているわけではないため、多くのサービスがAmazonエラーの影響を受けていることに注意してください。 これは、1つのキーポイントの障害がプラットフォーム全体をドラッグしないようにするために必要です。 IaaSプロバイダーを選択するときは、この要素に注意する必要があります。 ITインフラストラクチャは、考えられる障害を考慮し、何らかの要素に障害が発生した場合に負荷を分散する必要があります。
PS次のシリーズでは、さまざまな支払いゲートウェイの経験、対応する接続の問題、およびソリューションについて説明します。
PPSその他の資料：
- クラウド、データセンター、サービス開発の要約
- クラウド神話（ パート1 、 パート2、およびパート3 ）
- 始める前にIaaSプロバイダーについて知っておくべきこと