Amazon の大規模な AWS 停止からの教訓

by マーク・ハリス 2017 年 3 月 22 日

人間は完璧ではないというのは速報ではありません。 しかし、多くの組織は、IT チームが決して間違いを犯さないという非現実的な期待に依存しています。 Uptime Institute の進行中の調査によると、IT 部門は実際にはシステムとサービスの実行を維持するのに遅れをとっており、より多くの停止が報告されており、それぞれの期間が長くなり、ビジネスへの悪影響が大きくなっています。 そして、IT サービスをクラウド プロバイダーに移行することは答えではありません。

この 2017 年のアマゾン ウェブ サービス (AWS) の停止 完璧な例です。 大規模な停止の後にはヒステリー状態が続き、そのときに IT チームに課せられるプレッシャーは、問題を迅速に特定して修正することに圧倒される可能性があります。 それでも、タイプミスのようなありふれたことが問題の原因になる可能性があります。 単純な人為的ミスでありながら、フォーチュン 2000 企業全体に大混乱を引き起こしました。

Amazon の場合、エンジニアが請求システムの問題に対処しようとしたときに、まさにそれが起こりました。

「承認された S3 チームメンバーが 確立された戦略 S3 請求プロセスで使用される S3 サブシステムの XNUMX つに対して少数のサーバーを削除することを目的としたコマンドを実行しました。 残念ながら、 コマンドへの入力の XNUMX つが入力されました 意図したよりも多くのサーバーが削除されました。」

ほとんどの人的エラーと同様に、これは、もう少し注意して入力するだけでなく、回避できた可能性があります。 実際、個々のデバイスに変更を加えると、これらのデバイスを通過する IT サービスが意図せず影響を受けることがあります。 ネットワークの世界では、この問題は非常に深刻な場合があります。 従来、ネットワーク エンジニアリングでは、データ収集から手作業によるトラブルシューティングまで、多くの手作業が必要でした。 手作業、特に退屈な手作業は、多くの場合、人的ミスにつながります。 また、変更されたデバイスに関連するすべてのアプリケーションとサービスが、完全に動作していることを保証するために事前に品質管理を実行することはめったにありません。 AWS の場合、エンジニアは確立されたプレイブックに取り組んでいて、単純なタイプミスを犯しましたが、変更が正しく行われたことは容易にあったかもしれませんが、IT サービスに意図しない結果をもたらしました。 それはいつも起こります。

At NetBrain、実行可能ファイルを介してネットワーク自動化を実装することにより、退屈で一貫性のない手動作業を最小限に抑えるために、ネットワーク問題診断自動化システム全体を設計しました。 Runbook秒。 また、ネットワークのリアルタイム モデルと期待される結果を活用することで、変更がビジネスにとって良いものであることを確認できます。

知識が紙に書かれていたり、専門家チームに孤立していたり​​する従来の草の根的な取り組みに頼る代わりに、ネットワーク エンジニアは、実証済みのベスト プラクティス プロセスを実行ファイルにコード化して同僚と共有し、最小限の人的介入で対応できます。インテント ベースの自動化の威力は、エラーの削減だけにとどまりません。高度なタスクの作業負荷を複数のチーム メンバーに分散しながら、トラブルシューティング時間を短縮することもできます。これにより、部族の知識への過度の依存が軽減され、ネットワーク、セキュリティ、変更管理の各チーム間でより強力なコラボレーション文化が構築されます。これは、あらゆる組織で知識と経験を拡大する手段です。

ベスト プラクティスをデジタル化し、その実行を自動化することが重要です。 AWS が Executable に似たものを活用していた場合 Runbooks、停止が回避された可能性は十分にあります。 私たちの世界では、ネットワーク チームは簡単に実行可能ファイルを作成、実行、共有できます。 Runbook秒。 また、問題のトラブルシューティング、ネットワークの遅さの診断、設定ミスに対するプロアクティブな保護などを行うことができます。太い指の女性が歌うことを恐れることはありません。

リソース 実行可能ファイルの詳細 Runbooks また、ネットワーク エンジニアが知識を共有し、手作業を減らし、ネットワークを改善する方法。