Microsoft Azure DevOps, набор служб жизненного цикла приложений, прекратил работу в регионе Южная Бразилия в среду примерно на десять часов из-за основной ошибки кода.
В пятницу Эрик Маттингли, главный менеджер по разработке программного обеспечения, принес извинения за сбой и раскрыл причину сбоя: простая опечатка, которая привела к удалению семнадцати производственных баз данных.
Мэттингли объяснил, что инженеры Azure DevOps иногда делают моментальные снимки рабочих баз данных, чтобы изучить обнаруженные проблемы или протестировать улучшения производительности. И они полагаются на фоновую систему, которая работает ежедневно и удаляет старые снимки по истечении заданного периода времени.
Во время недавнего спринта — группового проекта на жаргоне Agile — инженеры Azure DevOps выполнили обновление кода, заменив устаревшие пакеты Microsoft.Azure.Managment.* поддерживаемыми пакетами Azure.ResourceManager.* NuGet.
Результатом стал большой запрос на внесение изменений, который заменял вызовы API в старых пакетах вызовами в более новых пакетах. В запросе на вытягивание произошла опечатка — изменение кода, которое необходимо проверить и объединить с соответствующим проектом. И это привело к удалению фонового снимка, чтобы удалить весь сервер.
«В этом запросе на вытягивание была скрыта ошибка-опечатка в задании на удаление моментального снимка, которая заменила вызов для удаления базы данных SQL Azure вызовом, который удаляет Azure SQL Server, на котором размещена база данных», — сказал Маттингли.
В Azure DevOps есть тесты для обнаружения таких проблем, но, по словам Маттингли, ошибочный код работает только при определенных условиях и, следовательно, не полностью охватывается существующими тестами. Эти условия, по-видимому, требуют наличия моментального снимка базы данных, который достаточно стар, чтобы его мог перехватить сценарий удаления.
Мэттингли сказал, что Sprint 222 был развернут внутри (кольцо 0) без инцидентов из-за отсутствия каких-либо баз данных моментальных снимков. Несколько дней спустя изменения программного обеспечения были развернуты в клиентской среде (кольцо 1) для единицы масштабирования в Южной Бразилии (кластер серверов для определенной роли). В этой среде была база данных моментальных снимков, достаточно старая, чтобы вызвать ошибку, из-за которой фоновое задание удалило «весь Azure SQL Server и все семнадцать рабочих баз данных» для единицы масштабирования.
Все данные были восстановлены, но на это ушло более десяти часов. По словам Маттингли, на это есть несколько причин.
Во-первых, поскольку клиенты не могут самостоятельно восстанавливать серверы Azure SQL Server, этим должны были заниматься дежурные инженеры Azure, что у многих занимало около часа.
Другая причина заключается в том, что у баз данных были разные конфигурации резервного копирования: некоторые были настроены для резервного копирования с избыточностью зоны, а другие были настроены для более поздней резервной копии с избыточностью геозоны. Устранение этого несоответствия добавило много часов процессу восстановления.
«Наконец, — сказал Маттингли, — даже после того, как базы данных начали возвращаться в оперативный режим, вся единица масштабирования оставалась недоступной даже для клиентов, чьи данные хранились в этих базах данных, из-за сложного набора проблем с нашими веб-серверами».
Эти проблемы возникали из-за задачи прогрева сервера, которая повторяла список доступных баз данных с помощью тестового вызова. Базы данных, находящиеся в процессе восстановления, выдали ошибку, которая привела к тому, что тест прогрева «выполнил повторную попытку с экспоненциальной отсрочкой, в результате чего прогрев занял в среднем девяносто минут, а не доли секунды в обычной ситуации».
Еще больше усложняло ситуацию то, что этот процесс восстановления был поэтапным, и как только один или два сервера снова начинали принимать клиентский трафик, они перегружались и отключались. В конечном счете, для восстановления службы потребовалось заблокировать весь трафик на единицу масштабирования South Brazil до тех пор, пока все не будет достаточно готово для повторного подключения к балансировщику нагрузки и обработки трафика.
Были внесены различные исправления и реконфигурации, чтобы предотвратить повторение проблемы.
«Еще раз приносим свои извинения всем клиентам, которых затронул этот сбой», — сказал Маттингли. ®
