GitHub раскрыл подробности об инциденте, из-за которого 28 января сервис оказался выведен из строя более чем на два часа. Имел место достаточно сложный каскадный сбой, в котором проявились как недоработки в программном обеспечении GitHub, так и ошибки в прошивках серверов, что потребовало значительного времени на выяснение причин и возвращение сайта к жизни.

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

В том числе перезагрузка затронула серверы ChatOps, обеспечивающие механизмы взаимодействия разработчиков на GitHub. После завершения перезагрузки и восстановления работы кластера серверов ChatOps, работа сайта не восстановилась. Ситуацию усугубила неразбериха, вызванная тем, что первые 8 минут после сбоя на странице status.github.com отображался нормальный статус функционирования сервиса, хотя фактически запросы приводили к ошибке.

Первичный разбор причин неработоспособности серверов ChatOps показал, что проблема заключалась в невозможности установить сетевое соединение с кластером СУБД Redis. Первые предположения были связаны с возможным влиянием DDoS-атаки, но через какое-то время, которое было потрачено на диагностику работы сети и организацию защиты от DDoS, стало ясно, что причина не в атаке. Дальнейшее пошаговое инспектирование инфраструктуры показало, что имеет место перезагрузка некоторых бэкенд-серверов для которых в централизованной системе мониторинга данные перезагрузки не были отражены.

Далее выяснилось, что почти все недоступные серверы построены на базе оборудования одного класса и разнесены по разным стойкам и кластерам в центре обработки данных. Также стало ясно, что обеспечивающие работу сервиса приложения после перезагрузки не запустились, из-за невозможности подключиться к кластеру СУБД Redis попытка запуска процессов привела к преждевременному завершению их работы. Разработчики изменили скрипты запуска, добавив обязательную проверку работы Redis и ожидание его доступности перед запуском приложений.

Проблемы с Redis были вызваны аппаратным сбоем серверов - прошивка не смогла распознать имеющиеся диски после кратковременного прекращения питания. Диски удалось подключить после дополнительной холодной перезагрузки, после чего потребовался достаточно длительный перенос данных проблемных узлов на запасные серверы. В итоге, кластер Redis был восстановлен и, шаг за шагом, все некорректно перезагруженные серверы с приложениями были возвращены к работе.

Для предотвращения подобных ситуаций в будущем будет пересмотрен процесс применения обновлений прошивок к серверам и анализа логов для оценки возможных аномалий. Тестовый набор будет расширен средствами для проверки влияния работоспособности внешних компонентов на функционирование приложений. Также планируется реализовать возможность частичного снижения функциональности для сохранения общей работоспособности в экстренном режиме, в условиях недоступности определённых вторичных бэкенд-серверов.