Фатальные 43 секунды, вызвавшие ежедневную деградацию сервиса На прошлой неделе что-то произошло на GitHub. инцидент , что привело к ухудшению качества обслуживания на 24 часа 11 минут. Инцидент затронул не всю платформу, а лишь несколько внутренних систем, в результате чего отображалась устаревшая и противоречивая информация.
В конечном итоге никакие пользовательские данные не были потеряны, но ручная сверка нескольких секунд записей в базу данных все равно производится.
В большинстве случаев сбоев GitHub также не мог обрабатывать веб-перехватчики, а также создавать и публиковать сайты GitHub Pages. Все мы в GitHub хотели бы искренне извиниться за проблемы, которые это вам всем причинило.
Мы знаем, что вы доверяете GitHub, и гордимся созданием отказоустойчивых систем, обеспечивающих высокую доступность нашей платформы.
Мы подвели вас этим инцидентом и нам глубоко жаль.
Хотя мы не можем обратить вспять долгосрочную деградацию платформы GitHub, мы можем объяснить, что произошло, какие уроки были извлечены и какие шаги компания может предпринять, чтобы лучше защититься от подобных сбоев в будущем.
Фон Большинство пользовательских сервисов GitHub работают самостоятельно.
Топология центра обработки данных разработана таким образом, чтобы обеспечить надежную и расширяемую периферийную сеть перед несколькими региональными центрами обработки данных, поддерживающими вычислительные системы и системы хранения данных.
Несмотря на уровни избыточности, встроенные в физические и логические компоненты проекта, сайты все равно могут в течение некоторого времени не иметь возможности взаимодействовать друг с другом.
21 октября в 22:52 UTC плановые профилактические работы по замене неисправного оптического оборудования 100G привели к потере связи между сетевым участком Восточного побережья США и основным центром обработки данных на Восточном побережье.
Соединение между ними было восстановлено через 43 секунды, но этот короткий сбой спровоцировал цепочку событий, которые привели к ухудшению качества обслуживания на 24 часа 11 минут. 
Высокоуровневая сетевая архитектура GitHub, включающая два физических центра обработки данных, 3 точки POP и одноранговое облачное хранилище в нескольких регионах.
Ранее мы обсуждали, как мы используем MySQL для хранения метаданных GitHub , а также наш подход к предоставлению Высокая доступность MySQL .
GitHub управляет несколькими кластерами MySQL размером от сотен гигабайт до почти пяти терабайт. Каждый кластер имеет десятки реплик чтения для хранения метаданных, отличных от Git, поэтому наши приложения обеспечивают запросы на включение, проблемы, аутентификацию, фоновую обработку и дополнительные функции, выходящие за рамки объектного хранилища Git. Разные данные в разных частях приложения хранятся в разных кластерах с помощью функционального шардинга.
Чтобы повысить производительность в масштабе, приложения направляют запись на соответствующий основной сервер для каждого кластера, но в подавляющем большинстве случаев делегируют запросы на чтение подмножеству серверов-реплик.
Мы используем Оркестратор для управления топологиями кластера MySQL и автоматического переключения при сбое.
В ходе этого процесса Orchestrator учитывает ряд переменных и строится на основе Плот для последовательности.
Orchestrator потенциально может реализовать топологии, которые не поддерживаются приложениями, поэтому вы должны убедиться, что ваша конфигурация Orchestrator соответствует ожиданиям уровня приложения.
В типичной топологии все приложения выполняют чтение локально с низкой задержкой.
Хроника происшествия
21.10.2018, 22:52 МСК
Во время вышеупомянутого разделения сети Оркестратор в главном дата-центре начал процесс отмены выборов руководства в соответствии с алгоритмом консенсуса Raft. Центр обработки данных Западного побережья и узлы Orchestrator общедоступного облака на Восточном побережье смогли достичь консенсуса и начали аварийное переключение кластеров для маршрутизации записей в западный центр обработки данных.Orchestrator начал создавать топологию кластера баз данных на Западе.
Как только соединение было восстановлено, приложения немедленно отправили трафик записи на новые главные серверы на западе США.
На серверах баз данных восточного дата-центра в течение короткого периода времени находились записи, которые не были реплицированы в западный дата-центр.
Поскольку кластеры баз данных в обоих центрах обработки данных теперь содержали записи, которых не было в другом центре обработки данных, мы не смогли безопасно переместить основной сервер обратно в восточный центр обработки данных.
21.10.2018, 22:54 МСК
Наши внутренние системы мониторинга начали генерировать оповещения, указывающие на многочисленные системные сбои.За это время несколько инженеров отвечали и работали над сортировкой входящих уведомлений.
К 23:02 инженеры группы быстрого реагирования определили, что топологии нескольких кластеров баз данных находятся в неожиданном состоянии.
При запросе API Orchestrator отображалась топология репликации базы данных, содержащая только серверы западного дата-центра.
21.10.2018, 23:07 МСК
На этом этапе группа реагирования решила вручную заблокировать внутренние инструменты развертывания, чтобы предотвратить внесение дополнительных изменений.В 23:09 группа создана желтый статус производительность сайта.
Это действие автоматически обозначило ситуацию как активный инцидент и отправило предупреждение координатору инцидента.
В 23:11 к работе подключился координатор и через две минуты принял решение.
21.10.2018, 23:13 UTC
На тот момент было ясно, что проблема затронула несколько кластеров баз данных.К работе были привлечены дополнительные разработчики из группы разработки баз данных.
Они начали изучать текущее состояние, чтобы определить, какие шаги необходимо предпринять, чтобы вручную настроить базу данных Восточного побережья США в качестве основной базы данных для каждого кластера и перестроить топологию репликации.
Это было непросто, поскольку к этому моменту западный кластер баз данных принимал записи с уровня приложений уже почти 40 минут. Кроме того, в восточном кластере было несколько секунд записей, которые не были реплицированы на запад, что препятствовало репликации новых записей обратно на восток.
Защита конфиденциальности и целостности пользовательских данных — высший приоритет GitHub. Поэтому мы решили, что более 30 минут данных, записанных в западном дата-центре, оставили нам только одно решение ситуации, чтобы сохранить эти данные: отказоустойчивость.
Однако приложения на Востоке, которые зависят от записи информации в западный кластер MySQL, в настоящее время не могут справиться с дополнительной задержкой из-за того, что большая часть их вызовов к базе данных пересылается туда и обратно.
Это решение сделает наш сервис непригодным для использования для многих пользователей.
Мы считаем, что долгосрочное ухудшение качества обслуживания стоило того, чтобы обеспечить согласованность данных наших пользователей.
В плохой топологии репликация с запада на восток нарушается, и приложения не могут читать данные из текущих реплик, поскольку для поддержания производительности транзакций им нужна низкая задержка.
21.10.2018, 23:19 UTC
Запросы о состоянии кластеров баз данных показали, что необходимо остановить выполнение заданий, записывающих метаданные, например push-запросов.Мы сделали выбор и сознательно пошли на частичную деградацию сервиса, приостановив вебхуки и создав GitHub Pages, чтобы не ставить под угрозу данные, которые мы уже получили от пользователей.
Другими словами, стратегия заключалась в том, чтобы поставить целостность данных выше удобства использования сайта и быстрого восстановления.
22.10.2018, 00:05 МСК
Инженеры группы реагирования начали разработку плана устранения несогласованности данных и инициировали процедуры аварийного переключения MySQL. Планировалось восстановить файлы из резервной копии, синхронизировать реплики на обеих площадках, вернуться к стабильной топологии сервиса, а затем возобновить обработку заданий в очереди.Мы обновили статус, чтобы сообщить пользователям о том, что мы собираемся выполнить управляемый переход на другой ресурс внутренней системы хранения.
План восстановления включал движение вперед, восстановление из резервных копий, синхронизацию, откат и проработку задержки перед возвратом в зеленый статус.
Хотя резервные копии MySQL создаются каждые четыре часа и хранятся в течение многих лет, они хранятся в удаленном облачном хранилище BLOB-объектов.
Восстановление нескольких терабайт из резервной копии заняло несколько часов.
Передача данных из службы удаленного резервного копирования заняла много времени.
Основная часть времени ушла на процесс распаковки, проверку контрольной суммы, подготовку и загрузку больших файлов резервных копий на свежеподготовленные MySQL-серверы.
Эта процедура проверяется ежедневно, поэтому каждый имел хорошее представление о том, сколько времени займет восстановление.
Однако до этого инцидента нам ни разу не приходилось полностью пересобирать целый кластер из резервной копии.
Другие стратегии, такие как отложенные реплики, всегда работали.
22.10.2018, 00:41 UTC
К этому времени процесс резервного копирования был запущен для всех затронутых кластеров MySQL, и инженеры следили за его ходом.В то же время несколько групп инженеров изучали способы ускорения передачи и восстановления без дальнейшего ухудшения качества сайта или риска повреждения данных.
22.10.2018, 06:51 UTC
Несколько кластеров восточного центра обработки данных завершили восстановление из резервных копий и начали репликацию новых данных на западное побережье.Это привело к замедлению загрузки страниц, выполнявших операцию записи между странами, но чтение страниц из этих кластеров БД возвращало актуальные результаты, если запрос на чтение попадал во вновь восстановленную реплику.
Другие более крупные кластеры баз данных продолжали восстанавливаться.
Наши команды определили путь восстановления непосредственно с Западного побережья, чтобы преодолеть ограничения пропускной способности, вызванные загрузкой с внешнего хранилища.
Стало почти на 100% ясно, что восстановление будет успешным, а время создания работоспособной топологии репликации зависело от того, сколько времени займет догоняющая репликация.
Эта оценка была линейно интерполирована на основе доступной телеметрии репликации, а страница состояния была обновлено чтобы установить время ожидания в два часа в качестве расчетного времени восстановления.
22.10.2018, 07:46 UTC
опубликовано на GitHub информационный пост в блоге .Мы сами используем GitHub Pages, и все сборки были приостановлены несколько часов назад, поэтому публикация потребовала дополнительных усилий.
Мы приносим извинения за задержку.
Мы намеревались отправить это сообщение гораздо раньше и позаботимся о том, чтобы будущие обновления публиковались с учетом этих ограничений.
22.10.2018, 11:12 МСК
Все первичные базы вновь были перенесены на Восток.В результате сайт стал гораздо более отзывчивым, поскольку записи теперь направлялись на сервер базы данных, расположенный в том же физическом центре обработки данных, что и наш уровень приложений.
Хотя это значительно повысило производительность, по-прежнему оставались десятки реплик чтения базы данных, которые на несколько часов отставали от основной копии.
Эти отложенные реплики привели к тому, что пользователи видели противоречивые данные при взаимодействии с нашими сервисами.
Мы распределяем нагрузку чтения по большому пулу реплик чтения, и каждый запрос к нашим сервисам имеет хорошие шансы попасть в реплику чтения с задержкой в несколько часов.
На самом деле время догона отстающей реплики уменьшается экспоненциально, а не линейно.
Когда пользователи в США и Европе проснулись, процесс восстановления занял больше времени, чем ожидалось, из-за возросшей нагрузки на запись в кластеры БД.
22.10.2018, 13:15 UTC
Мы приближались к пиковой нагрузке на GitHub.com. Группа реагирования обсудила дальнейшие действия.Было ясно, что задержка репликации до состояния консенсуса увеличивалась, а не уменьшалась.
Ранее мы начали предоставлять дополнительные реплики чтения MySQL в общедоступном облаке Восточного побережья.
Как только они стали доступны, стало проще распределять поток запросов на чтение между несколькими серверами.
Снижение средней нагрузки на реплики чтения ускорило наверстывание репликации.
22.10.2018, 16:24 UTC
После синхронизации реплик мы вернулись к исходной топологии, устранив проблемы с задержкой и доступностью.В рамках сознательного решения отдать приоритет целостности данных над быстрыми исправлениями, мы сохранил красный статус сайт, когда начали обрабатывать накопленные данные.
22.10.2018, 16:45 UTC
На этапе восстановления необходимо было сбалансировать возросшую нагрузку, связанную с отставанием в работе, потенциально перегружающую наших партнеров по экосистеме уведомлениями, и как можно быстрее вернуться к 100% времени безотказной работы.В очереди осталось более пяти миллионов событий перехвата и 80 тысяч запросов на создание веб-страниц.
Когда мы снова включили обработку этих данных, мы обработали около 200 000 полезных задач веб-перехватчика, которые превысили внутренний TTL и были отклонены.
Узнав об этом, мы остановили обработку и нажали увеличение TTL. Чтобы избежать дальнейшего снижения надежности наших обновлений статуса, мы оставили статус деградации до тех пор, пока не завершим обработку всех накопившихся данных и не будем уверены, что сервисы явно вернулись к нормальному уровню производительности.
22.10.2018, 23:03 МСК
Все ожидающие события веб-перехватчика и сборки страниц были обработаны, а целостность и правильная работа всех систем подтверждена.Статус сайта обновлен до зеленого цвета .
Дальнейшие действия
Разрешение несогласованности данных
При восстановлении мы записывали бинарные логи MySQL с записями в основном дата-центре, которые не были реплицированы в западный.Общее количество таких записей относительно невелико.
Например, в одном из самых загруженных кластеров за эти секунды всего 954 записи.
В настоящее время мы анализируем эти журналы, чтобы определить, какие записи можно согласовать автоматически, а какие потребуют помощи пользователя.
В этой работе задействовано несколько команд, и наш анализ уже выявил категорию записей, которые пользователь затем повторил — и они были успешно сохранены.
Как указано в этом анализе, наша основная цель — поддерживать целостность и точность данных, которые вы храните на GitHub.
Коммуникация
Стремясь предоставить вам важную информацию во время инцидента, мы опубликовали несколько общедоступных оценок времени восстановления, основанных на скорости обработки накопившихся данных.Оглядываясь назад, можно сказать, что наши оценки не учитывали все переменные.
Приносим извинения за возникшую путаницу и постараемся предоставить более точную информацию в будущем.
Технические меры
Этот анализ выявил ряд технических мер.Анализ продолжается, список может быть расширен.
Настройте конфигурацию Оркестратора, чтобы предотвратить перемещение основных баз данных через границы региона.
Оркестратор работал так, как было настроено, хотя уровень приложения не поддерживал это изменение топологии.
Выбор лидера внутри региона обычно безопасен, но основной причиной этого инцидента стало внезапное возникновение задержки из-за межконтинентального трафика.
Это эмерджентное, новое поведение системы, поскольку раньше мы не сталкивались с внутренним участком сети такого масштаба.
Мы ускорили переход на новую систему отчетности о статусе, которая обеспечит лучшую платформу для более четкого и четкого обсуждения активных инцидентов.
Хотя многие части GitHub были доступны на протяжении всего инцидента, мы могли выбрать только зеленый, желтый и красный статусы для всего сайта.
Мы признаем, что это не дает точного представления о том, что работает, а что нет. Новая система будет отображать различные компоненты платформы, чтобы вы знали статус каждой услуги.
За несколько недель до этого инцидента мы запустили общекорпоративную инженерную инициативу по поддержке обслуживания трафика GitHub из нескольких центров обработки данных в архитектуре «активный-активный-активный».
Целью этого проекта является поддержка резервирования N+1 на уровне центра обработки данных, чтобы выдержать сбой одного центра обработки данных без внешнего вмешательства.
Это большая работа и займет некоторое время, но мы считаем, что несколько хорошо связанных между собой дата-центров в разных регионах обеспечат хороший компромисс.
Последний инцидент еще больше подтолкнул эту инициативу.
Мы будем играть более активную роль в проверке наших предположений.
GitHub быстро растет и за последнее десятилетие накопил изрядную долю сложности.
Становится все труднее уловить и передать новым поколениям сотрудников исторический контекст компромиссов и принятых решений.
Организационные меры
Этот инцидент сильно повлиял на наше восприятие надежности сайта.Мы поняли, что ужесточение оперативного контроля или сокращение времени реагирования не являются достаточными гарантиями надежности в такой сложной системе обслуживания, как наша.
Чтобы поддержать эти усилия, мы также начнем систематическую практику тестирования сценариев сбоев до того, как они действительно произойдут. Эта работа включает в себя намеренное внесение сбоев и использование инструментов хаос-инжиниринга.
Заключение Мы знаем, насколько вы полагаетесь на GitHub в своих проектах и бизнесе.
Мы больше всех заботимся о доступности нашего сервиса и безопасности ваших данных.
Рассмотрение этого инцидента позволит продолжить поиск способов лучше обслуживать вас и заслужить ваше доверие.
Теги: #github #Хранение данных #Администрирование сервера #Высокая производительность #Тестирование ИТ-систем #MySQL #репликация #БД #согласованность #инжиниринг хаоса #Orchestrator #внедрение ошибок
-
Защита От Шпионского По
19 Oct, 24 -
Плюсы И Минусы Разработки Через Тестирование
19 Oct, 24 -
Форма: Подкаст №2
19 Oct, 24
