Google Cloud вызвал сбой, проигнорировав обычные защиты качества кода.

Google Cloud объяснила масштабный сбой, произошедший на прошлой неделе, ошибочным обновлением кода в системе Service Control, которое спровоцировало глобальный цикл аварийных перезапусков из-за отсутствия обработки ошибок и защиты с помощью feature flags. Как сообщает The Register, объяснение Google начинается с того, что API-интерфейсы и сервисы Google Cloud обслуживаются через наши плоскости управления и управления API. Обе эти плоскости распределены по регионам и отвечают за проверку авторизации каждого входящего API-запроса, применение политик и выполнение необходимых проверочек, таких как квоты, для достижения конечных точек. Основной бинарный файл, входящий в состав этой системы проверки политик, известен как Service Control.

29 мая Google добавила новую функцию в Service Control для включения "дополнительных проверок политики квот". "Это изменение кода и выпуск бинарного файла прошли поэтапное развертывание по регионам, но путь кода, который привел к сбою, не был протестирован в ходе этого развертывания, поскольку требовал изменения политики, которое бы активировало этот код", – объясняется в отчете об инциденте Google. Похоже, Google опасалась этого изменения, поскольку оно поставлялось с "красной кнопкой" для отключения конкретного пути обслуживания политик. Однако изменение "не имело надлежащей обработки ошибок и не было защищено feature flags. Отсутствие надлежащей обработки ошибок привело к тому, что нулевой указатель вызвал сбой бинарного файла".

Google использует feature flags для выявления проблем в своем коде. "Если бы это было защищено feature flags, проблема была бы обнаружена на этапе тестирования". Этот незащищенный код работал в Google до 12 июня, когда компания изменила политику, содержащую "непреднамеренные пустые поля". Далее произошло следующее: "Service Control, а затем региональные проверки квот на политиках в каждом региональном хранилище данных. Это привело к извлечению пустых полей для этого конкретного изменения политики и активировало путь кода, который вызвал нулевой указатель, что привело к бесконечному циклу аварийных перезапусков бинарных файлов. Это произошло глобально, учитывая развертывание в каждом регионе".

В сообщении Google говорится, что ее команда Site Reliability Engineering обнаружила и начала анализ инцидента в течение двух минут, определила первопричину в течение 10 минут и смогла начать восстановление в течение 40 минут. Однако в некоторых крупных регионах Google Cloud "по мере перезапуска задач Service Control возник эффект стадного поведения на базовой инфраструктуре, от которой она зависит... перегружая инфраструктуру". Service Control не был рассчитан на это, поэтому потребовалось почти три часа, чтобы решить проблему в ее крупных регионах. Команды, обслуживающие продукты Google, которые вышли из строя из-за этого сбоя, затем должны были выполнить собственные процедуры восстановления. В будущем Google пообещала внести несколько оперативных изменений, чтобы предотвратить повторение этой ошибки: "Мы улучшим нашу внешнюю коммуникацию, как автоматизированную, так и осуществляемую людьми, чтобы наши клиенты получали необходимую информацию как можно быстрее, чтобы реагировать на проблемы, управлять своими системами и помогать своим клиентам. Мы обеспечим, чтобы наша инфраструктура мониторинга и коммуникаций оставалась работоспособной, чтобы обслуживать клиентов, даже когда Google Cloud и наши основные продукты мониторинга выходят из строя, обеспечивая непрерывность бизнеса".