Давайте кратко подведем итоги инцидента с AWS и некоторые действия, которые я предпринял как SRE в стартапе AIGC, надеюсь, это поможет всем. С момента моего прихода на работу я заметил, что наши основные кластеры находятся в USE1, и я начал делать некоторые приготовления. Вот несколько вещей, которые я сделал: 1. Я создал многоместные резервные копии наших основных баз данных, сформировав резервные копии в USE1, Токио и Сингапуре. Таким образом, в экстремальных ситуациях мы можем потерять часть данных, но сможем гарантировать продолжение работы сервиса. 2. Я перестроил наш тестовый кластер в Сингапуре, который изначально был простым K3S на EC2, в стандартный кластер AWS EKS. Это позволяет быстро развернуть кластер в случае бедствия, повторно используя уже существующие компоненты AWS. Я минимизировал затраты на изменения манифеста. 3. Я составил простой SOP, включающий уведомления для пользователей, переключение DNS, закрытие версий и другие вопросы. Вернувшись к сегодняшнему дню, примерно через 10 минут после инцидента с AWS, я обнаружил, что в нашем контейнере есть новые Pod, которые не могут быть настроены. После подтверждения с поддержкой AWS, что это проблема USE1, я осознал, что событие ECR обязательно связано с другими событиями, поэтому я решительно начал обрабатывать инцидент, следуя своему плану Tier1 (для SRE такие вещи лучше ошибиться, чем упустить). T+0 мин, я выпустил уведомление для всех, начав режим чрезвычайной ситуации. Я организовал открытое собрание для всех сотрудников. Все могли присоединиться в любое время. T+2 мин, я подтвердил, что инцидент, как и ожидалось, постепенно расширяется, и я отдал два указания: 1. Полный запрет на любые слияния/коммиты кода (в основном, чтобы избежать создания новых ресурсов, что может привести к ротации Pod и, следовательно, повлиять на трафик), 2. Пожалуйста, подготовьте уведомление для пользователей. T+3 мин, я начал действовать согласно SOP и начал восстановление базы данных в регионе Сингапур, а также каскадное создание зависимостей, таких как OpenSearch / Redis и т.д. T+5 мин, мы начали официально подтверждать конкретные проблемы с зависимостями вверх и вниз по потоку, подтвердив, что новое основное сервисное приложение пострадало. T+10 мин, мы выпустили уведомление о приостановке работы и уведомление о влиянии на другие сервисы. T+10 мин, я попросил еще двоих помочь настроить новый ECR и очистить уже существующие ресурсы тестовой среды, а также синхронизироваться с CTO, в крайних случаях мы могли бы столкнуться с решением о сохранении опыта и потере данных. T+15 мин, мы окончательно подтвердили, что созданные ресурсы и направление входящего трафика не будут сильно затронуты. План переключения приостановлен, но мы продолжаем готовить соответствующие ресурсы. T+30 мин, мы завершили восстановление первой базы данных. T+40 мин, мы завершили восстановление второй базы данных. T+1ч, вся наша связанная основная инфраструктура, RDS/ES/Redis, находится в режиме ожидания, и мы настроили оптимизационные параметры, такие как мастер-слейв и т.д. В то же время мы начали запуск новых сервисов в новом кластере. К счастью, в конечном итоге сбой AWS не повлиял на все наши сервисы. Нам не пришлось сталкиваться со сложной работой по восстановлению данных после переключения трафика. Примерно через T+2ч до T+3ч я официально уведомил всех о снятии режима чрезвычайной ситуации. На всякий случай, сегодня вечером мы все еще закрываем функции. Оглядываясь на весь инцидент, я понимаю, что мог бы сделать больше: 1. Опубликовать SOP для крайних случаев, который я подготовил для себя, для всех сотрудников. Это обеспечит, что даже если меня не будет на месте, кто-то сможет меня заменить. 2. Мы могли бы провести некоторые предварительные репетиции. 3. Указания можно было бы давать более решительно. Вот и все, небольшая часть, надеюсь, это поможет всем.