GitHub раскрыла причины трёх сбоев подряд на платформе с 9 по 11 мая

ntt2mz77moga-jiq_hl4jbkwj64.png

Платформа для хостинга IT-проектов GitHub раскрыла причины и технические детали трёх сбоев подряд в своих основных сервисах и службах с 9 по 11 мая. В рамках сбоев 8 из 10 систем GitHub были недоступны некоторое время, включая Actions, API Requests, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests и Webhooks.

«На прошлой неделе GitHub столкнулся с несколькими инцидентами доступности, как длительными, так и более короткими. Три подряд сбоя не имели между собой одинаковых причин, но вызвали подобные каскадные проблемы, включая недоступность подключения к базе данных платформы и ошибки при аутентификации на срок до десяти часов в каждом случае», — рассказал директор по безопасности и старший вице-президент по разработке GitHub Майк Хэнли.

По словам представителя GitHub, хотя основные причины трёх инцидентов не были связаны между собой, но в совокупности они негативно смогли повлиять на доступность услуг и сервисов платформы, которой многие организации и разработчики в мире доверяют. «Это неприемлемо и не является высоким стандартом безопасности, а также не соответствует цели повышения доступности и уровня оказания услуг, которой мы стараемся придерживаться», — уточнил Хэнли.

По данным Хэнли, 9 мая в восьми основных службах платформы произошёл серьёзный сбой из-за того, что разработчики внесли изменения в конфигурацию внутренней службы GitHub, обслуживающей данные Git. Это изменение было предназначено для предотвращения сатурации подключения и ранее было успешно внедрено в других частях серверной части Git. Но в этот раз что-то пошло не так. Вскоре после начала развёртывания обновления в основном кластере произошёл отказ. Разработчики отменили изменение конфигурации и попытались выполнить откат системы в течение нескольких минут, но этот процесс не удался из-за внутренней ошибки инфраструктуры. Этот сбой удалось локализовать только через несколько часов.

Второй сбой, произошедший 10 мая, повлиял на выдачу токенов аутентификации для приложений GitHub и был вызван высокой нагрузкой и неэффективной реализацией API, отвечающего за управление разрешениями приложений GitHub. В кластере базы данных, обслуживающем токены аутентификации приложения GitHub, наблюдалось 7-кратное увеличение задержки записи для разрешений приложения GitHub. Уровень отказов этих запросов токена аутентификации составлял 8–15% для большей части этого инцидента, но в течение короткого времени достиг пика в 76% процентов.

В ходе расследования этого инцидента в GitHub определили, что API для управления разрешениями приложений GitHub имеет неэффективную реализацию. При вызовах через API в определённых обстоятельствах это приводило к очень большим задержкам в операциях записи и сбою в работе механизма тайм-аута. Разработчики смогли оперативно внести корректировки для улучшения шаблона доступа к данным и устранили источник проблемных вызовов API.

Третий сбой GitHub, с которым столкнулись пользователи 11 мая, был связан с потерей реплик чтения (Read Replica) после того, как произошёл сбой кластера базы данных, обслуживающего данные Git, и активировался автоматический механизм аварийного переключения. Отработка отказа основного сервера прошла успешно, но в этом случае реплики чтения не были подключены. Первичный сервер не смог справиться с полной нагрузкой на чтение/запись, поэтому в среднем 15% запросов к данным Git были неудачными или медленными, с пиковым влиянием до 26% в начале инцидента. Разработчики устранили эту проблему, повторно подключив реплики чтения и восстановив основные сценарии для возобновления работы платформы.

Хэнли пояснил, что после череды сбоев инженеры GitHub продолжат уделять ей приоритетное внимание основным сервисам и будут оперативно устранять инциденты, так как в приоритете платформы сделать так, чтобы сервисы были максимально устойчивы к сбоям и не было снижения производительности служб GitHub.

«Сбой в распределённой системе неизбежен, но он не должен приводить к значительным перебоям в работе нескольких служб. Во всех трёх случаях наблюдалась быстрая деградация смежных сервисов. Не все эти инциденты были вызваны производственными изменениями со стороны GitHub. Мы признаём, что нам нужно более оперативно решать проблемы аварийного переключения систем, чтобы обеспечить полное восстановление сервисов после отказа как в автоматическом режиме, так и с помощью вмешательства инженеров в случае необходимости», — подытожил Хэнли.

© Habrahabr.ru