AIGC スタートアップ SRE としての AWS の運用のいくつかを簡単に確認しましょう。 オンボーディングの初めから、メインクラスターが USE1 であることに気づき、いくつかの準備を始めました。 これらは私が行う主なことです 1. コアデータベースのいくつかを複数の場所にバックアップし、USE1、東京、SGのバックアップを形成しています。 このようにして、極端な場合にはデータの一部が失われますが、サービスの継続を保証することもできます 2. SGテストクラスターを元のEC2自体のK3Sから標準のAWS EKSクラスターに再構築します。 これにより、災害発生時にクラスターを迅速にウォームアップし、既存の AWS コンポーネントを再利用できます。 マニフェスト変更のコストを最小限に抑える 3. ユーザーのお知らせ、DNS 切り替え、バージョンのブロックなどを含む SOP を簡単に整理します 今日、AWS インシデントから約 10 分後に、コンテナ内にセットアップできない新しいポッドがあることを発見しました。 USE1の問題であることをAWSサポートに確認した結果、ECRイベントは残りのイベントに関連しているに違いないと気づき、自分の計画に従ってTier1レベルのイベントの処理を開始することにしました(SREの場合、この種のことは見逃すよりは間違えたほうがいいです) T+0分、全スタッフアナウンスを発し、緊急モードに入り始めました。 私は全員参加の公開会議を開催しました。 すべての人がいつでも参加できます T+2分、予想通りイベントが徐々に拡大していることを確認し、2つの指示を出しました。 コードのマージ/コミットを全面的に禁止する(主に、新しく作成されたリソースがポッドのローテーションによってトラフィックに影響を与えるのを防ぐため)、2. 操作学生へのお知らせをご用意ください T+3分、SOPに従い始め、SGリージョンでデータベースの復旧を開始し、カスケードしてOpenSearch/Redisなどの依存関係を作成しました T+5分後、上流と下流の依存関係の具体的な問題を正式に確認し始め、新しく開始されたコアサービスが影響を受けていることを確認しました T+10分、サービス停止のお知らせと残りのサービスの影響を受けるお知らせが発行されます T+10分後、私は他の2人に新しいECRのセットアップとテスト環境内の既存のリソースのクリーンアップを同時に支援し、CTOを同期するように依頼しましたが、極端な場合、エクスペリエンスを保持してデータを失うという決定を下す可能性があります。 T+15分で、これまでに作成したリソースとインバウンドトラフィックの方向に大きな影響はないということをようやく確認しました。 切り替えは保留中ですが、関連するリソースの準備は引き続き行っています T+30分、最初のデータベースが復元されます T+40分、2番目のデータベースが復元されます T+1h では、関連するすべてのコア インフラストラクチャ、RDS/ES/Redis がスタンバイされ、マスター/スレーブなどの最適化オプションが本番アーキテクチャに従って設定されます。 同時に、新しいクラスターで新しいサービスも開始しています ありがたいことに、最終的に AWS のクラッシュはすべてのサービスに影響を与えませんでした。 トラフィック切り替え後の複雑なデータ修復作業に対処する必要はありません T+2hからT+3hくらいで、全スタッフに正式に通知し、緊急事態宣言が解除されました。 念のため、今夜も特集は休業となります。 事件全体を振り返ってみると、もっとできたはずだ 1. 私が直接準備した極端なケースSOPを全従業員に公開する。 これにより、私がオンラインでなくても、誰かが私の代わりになることが保証されます 2. 事前訓練を行うことができます 3. 注文はより決定的になる可能性があります もうすぐです、ちょっとした共有、みんなのお役に立てば幸いです