Краткое содержание

  • 11 августа GitHub существенно дополнил описание инцидентаqcvjkzcs7j74; сам сбой в Actions продолжался с 15:05 UTC 6 августа до 00:14 UTC 7 августа.
  • На пике, по данным GitHub, 71\u00a0% запусков рабочих процессов столкнулись с отказами инфраструктуры, а 75\u00a0% остальных ожидали более пяти минут.
  • Рядовое развёртывание заменило поды, выявило существующую слабость ёмкости и параллелизма, перегрузило оставшуюся часть сервиса и распространило сбой по кластерам и зависимым системам.
  • Инженеры добавили ёмкость, ограничили обработку событий от вебхуков и увеличили пропускную способность обработки накопившихся задач, после чего им пришлось остановить раннеры, которые многократно получали уже недействительные задания.
  • Часть раннеров Actions Runner Controller потребовала ручного восстановления, а некоторые события push и pull request не удалось воспроизвести автоматически.
  • GitHub анонсировал более строгие защитные меры при развёртывании, улучшенный мониторинг, устойчивость очередей и автоматическое восстановление, однако разбор не доказывает, что эти средства уже развёрнуты или эффективны.

Развёртывание израсходовало собственный запас прочности

Триггером не был исключительный всплеск трафика. По словам GitHub, рядовое развёртывание заменило поды во внутреннем сервисе Actions, который превращает события в задания. Когда часть ёмкости вышла из ротации, оставшиеся ресурсы оказались перегружены, сервисы вышли из строя, а последствия распространились по нескольким кластерам и нижестоящим системам.

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

Два процента описывают разные группы

Пиковые показатели нельзя складывать или сводить к одной доле. GitHub сообщает об отказах инфраструктуры для 71\u00a0% запусков. Из оставшихся 29\u00a0% три четверти ждали более пяти минут. Таким образом, второй процент относится к подмножеству, а не ко всем рабочим процессам, и не означает, что остальные завершились штатно или вовремя.

Тем не менее такое раскрытие необычно полезно: оно показывает, что клиентская сторона столкнулась и с жёсткими отказами, и с длительным ожиданием в очередях, а для этого нужны разные проверки восстановления.

Восстановление ёмкости не очистило семантику заданий

На первом этапе восстановления использовались дополнительная ёмкость, снижение приёма вебхуков и более высокая скорость обработки накопившихся задач. Затем проявился второй сбой. Скрытая ошибка назначения предлагала раннерам задания, которые уже не были действительными; раннеры повторяли попытки получить их и не могли перейти к легитимной работе.

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

Восстановление оставило часть работы за пределами автоматических возможностей платформы

Некоторые раннеры Actions Runner Controller остались офлайн после того, как одна из мер по устранению непреднамеренно затронула их. GitHub откатил это изменение, но части раннеров потребовалось ручное восстановление. Отдельно некоторые события push и pull request не были обработаны и не могли быть воспроизведены автоматически.

Для клиентов инцидент завершился, таким образом, в двух местах: в состоянии сервиса провайдера и в пропущенной или застрявшей работе каждого репозитория. Командам пришлось решать, перезапускать ли рабочий процесс, повторить ли триггерное действие или восстановить раннер.

Решение проблемы появилось раньше подробного объяснения

GitHub устранил инцидент 7 августа; содержательный разбор появился в обновлении 11 августа. Эта более поздняя публикация и есть новостное событие в настоящем обзоре, а не новый сбой и не продление интервала воздействия.

Это различие важно для статистики инцидентов. Доступность относится к 6–7 августа. Раскрытие первопричины и средств контроля относится к 11 августа. Объединение этих сроков преувеличило бы длительность недоступности сервиса и скрыло бы задержку раскрытия.

Обещанные защитные меры — это план проверки, а не результат

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

Пока это будущие средства контроля — до тех пор, пока релизы, доказательства развёртывания или последующий инцидент не продемонстрируют их. Самым убедительным подтверждением было бы показать, какой запас ёмкости должно сохранять развёртывание, как выводятся недействительные задания и как застрявшие раннеры восстанавливаются без ручных действий.

Клиентам нужен собственный реестр сверки

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

Такой учёт превращает разбор провайдера в ограниченное по объёму упражнение по восстановлению. Он также отделяет фразу «GitHub Actions сейчас исправен» от утверждения «каждое изменение, которое должно было выполниться во время инцидента, учтено».

Источники