Обзор инцидента
Неисправный релиз в последовательности восстановления VM запустил операцию восстановления, в результате чего 282 виртуальные машины (VM) в eu-north1регионе были перезапущены. 164 из этих VM столкнулись с длительным простоем, требующим ручного вмешательства для восстановления работы. Это вызвало перерывы в рабочих нагрузках клиентов.
Мы искренне приносим извинения всем клиентам, пострадавшим от этого инцидента. Мы намерены извлечь из этого урок и предпринимаем конкретные шаги, чтобы гарантировать, что это не повторится.
Влияние
Перезапущено 282 виртуальные машины. 196 из них не смогли успешно перезапуститься и зависли.
32 виртуальные машины были перезапущены или удалены пользователями.
164 виртуальные машины не смогли запуститься и оставались в автономном режиме примерно 2–3 часа.
Хронология
- 13:48 Развертывание нового релиза в eu-north1. Цепочка событий, приведших к инциденту, началась
- 13:48 Массовый перезапуск ВМ: затронуто 282 ВМ.
- 13:50 86 виртуальных машин успешно перезапущены автоматически.
- 14:03 Были запущены оповещения о большом количестве застрявших виртуальных машин, и проблема была сообщена внутри компании. Первый отчет клиента получен через Slack; проблема была классифицирована как инцидент.
- 14:21 Команда начала анализировать причины происходящего и способы смягчения последствий, не усугубляя ситуацию.
- 15:00 Выявлена основная причина и определена стратегия смягчения последствий.
- 15:00 — 15:37 Исследовали способы смягчения последствий инцидента без возникновения дальнейших проблем и создали план смягчения, одновременно тестируя решение на отдельных виртуальных машинах. К этому времени 32 виртуальных машины были либо восстановлены пользователями, либо удалены.
- 15:37 — 16:39 163 ВМ восстановлены партиями.
- 17:40 Подтвержден успешный запуск всех затронутых ВМ. Инцидент решен
Первопричина
Чтобы обеспечить четкое понимание событий, которые привели к этому инциденту, мы опишем некоторые внутренние процессы, способствовавшие возникновению проблемы.
Служба Compute API столкнулась с проблемой, когда она неправильно предполагала, что некоторые виртуальные машины неработоспособны. Это было вызвано ошибочным предположением о порядке обработки событий в системе, отвечающей за отслеживание обновлений ресурсов. В результате Compute API ошибочно определил некоторые виртуальные машины как отсутствующие и инициировал ненужные операции восстановления.
Другим фактором, способствовавшим возникновению проблемы, стало то, что на момент инцидента системы не были оптимизированы для такого количества операций восстановления, из-за которых виртуальные машины зависали.
Действия по смягчению последствий
Мы начали с определения первопричины инцидента и остановки всех операций автоматического восстановления, чтобы предотвратить дальнейшее воздействие.
Затем мы разделили затронутые ВМ на две группы: те, которые успешно перезапустились, и те, которые застряли и требовали ручного вмешательства.
Чтобы решить проблему, мы разработали и тщательно протестировали процедуры смягчения. Они включали остановку затронутых ВМ для прерывания всех застрявших процессов и их последующий перезапуск контролируемыми партиями для обеспечения успешного перезапуска.
Наконец, эти процедуры смягчения последствий были успешно применены ко всем виртуальным машинам, требующим ручного восстановления, что завершило процесс.
Результаты реагирования на инциденты
Наши внутренние системы мониторинга обнаружили проблему, когда некоторые виртуальные машины зависли. Это вызвало немедленные телефонные звонки дежурным инженерам, и в течение 15 минут мы оценили воздействие, официально объявили об инциденте, собрали группу реагирования и начали работу по смягчению последствий. Благодаря быстрым действиям группы мы определили первопричину в течение 35 минут.
Процесс восстановления следовал поэтапному подходу, который оказался эффективным, но потребовал ручного вмешательства и тщательного мониторинга для обеспечения надежного восстановления. Этот инцидент показал, что нам нужна лучшая автоматизация процедур восстановления, которая могла бы значительно сократить время реагирования в подобных ситуациях.
План действий после инцидента
Наш план действий после инцидента направлен на улучшение трех ключевых областей: проверка перед развертыванием, эксплуатация и связь.
Для проверки перед развертыванием мы введем дополнительное тестирование сценариев восстановления и усилим проверку изменений состояния виртуальной машины.
В операционной деятельности мы планируем добавить ограничение скорости для процессов восстановления, улучшить мониторинг и обнаружение аномалий в деятельности виртуальных машин, а также усилить процедуры развертывания с помощью дополнительных проверок безопасности.
В сфере коммуникаций мы стремимся обеспечить более быструю эскалацию масштабных событий, связанных с виртуальными машинами, улучшить уведомления и взаимодействие с клиентами, а также усовершенствовать внутренние протоколы коммуникации для оптимизации наших усилий по реагированию на инциденты.
Важное отраслевое изменение срока действия сертификатов подписи кода вступит в силу с 15 июня 2025 года. Данное изменение было введено CA/Browser Forum, организацией, которая устанавливает стандарты в индустрии цифровых сертификатов.