Резюме

  • GitHub открыла критический инцидент по Actions в 23:34 UTC 19 июля. Новые рабочие процессы могли запускаться с задержкой или не запускаться, а уже выполнявшиеся запуски могли завершаться сбоем.
  • Сбой распространился на API Requests, Pages и Issues. Позднее GitHub сообщила, что продолжительный простой Actions вызвал побочные эффекты, и объединила отдельный инцидент с Git LFS и API в то же расследование.
  • CircleCI сообщила о пайплайнах, которые не запускались или зависали, а OpenAI — о сбоях или задержках в процессах разработки, зависящих от GitHub. Обе записи независимо подтверждают, что сбой вышел за границы одной компании.
  • GitHub заявила, что причина выявлена, восстановила Actions к 04:43 UTC и закрыла инцидент минутой позже. Компания пообещала подробный анализ первопричины, но на момент подготовки этого материала он ещё не был опубликован.

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

GitHub сообщила об ухудшении работы Actions в 23:34 UTC 19 июля. Уже через несколько минут компания предупредила, что новые рабочие процессы могут запускаться с задержкой или не запускаться, а выполнявшиеся запуски могут завершаться сбоем. В 23:57 компания заявила, что причина выявлена и идёт восстановление сервиса, не раскрыв её.

Затем инцидент вышел за пределы пула раннеров. В 00:07 UTC начался частичный сбой API Requests. Ухудшилась работа Pages и Issues. Вторая запись сообщила о сбоях в некоторых операциях Git LFS и при загрузке файлов через API. В 01:11 GitHub указала причинную связь: продолжительный простой Actions начал вызывать побочные эффекты в других сервисах, а отдельно открытый инцидент оказался связанным.

Это заявление превращает набор красных индикаторов состояния в единое операционное событие.

Плоскость управления стала зоной поражения

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

Поэтому проблема с раннерами может распространяться и без полного отказа всех репозиториев или операций Git. Пуш может существовать, а пайплайн, который должен быть им запущен, не стартует. Задание может выполняться, а статус, который использует правило слияния или внешний сервис, оказывается устаревшим. Большой файл может присутствовать в LFS, а запрос к API, необходимый для его загрузки, завершается сбоем. Статический сайт может оставаться доступным, а новая сборка Pages не может продвинуться.

Хронология GitHub показывает это разделение. Восстановление Pages было отмечено в 01:37. За ним в 02:20 последовали Issues. GitHub сообщила, что Issues, API Requests и Pages восстановились к 02:43, но компания всё ещё восстанавливала задания Actions, использующие самостоятельно размещённые или более крупные размещаемые раннеры. API Requests были объявлены нормальными в 03:03. Actions переведены в режим наблюдения в 03:34, а полное восстановление зафиксировано в 04:43.

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

Связанные записи показывают расхождение состояний

Запись о состоянии CircleCI делает последствия конкретными. Компания связала зависшие в состоянии выполнения или не запустившиеся рабочие процессы с ошибками API GitHub. Она также сообщила об ошибках при обработке вебхуков push-событий. После восстановления уровня ошибок API GitHub CircleCI рекомендовала клиентам повторно запустить пайплайны, которые так и не стартовали, и отменить и перезапустить пайплайны, которые всё ещё отображаются как выполняющиеся.

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

OpenAI отдельно сообщила о сбоях или задержках в процессах разработки, зависящих от GitHub, и связала влияние с частичным сбоем API и ухудшением работы Actions. Запись не оценивает число пользователей, заданий или коммерческие потери. Её ценность уже: она подтверждает, что инцидент достиг внешнего рабочего процесса, клиентский интерфейс которого не принадлежит GitHub.

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

Собственный раннер не устранил зависимость от оркестрации

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

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

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

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

Восстановление требует сверки, а не только повторного запуска

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

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

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

Отсутствующее доказательство — это механизм

GitHub закрыла инцидент в 04:44 UTC и сообщила, что подробный анализ первопричины будет опубликован позже. Публичная хронология устанавливает затронутые поверхности и порядок восстановления. Она не раскрывает, какой компонент отказал первым, почему сбой затронул API и другие сервисы, было ли восстановление результатом одного или нескольких исправлений и какое изменение архитектуры предотвратит повторение.

На основе публичных данных нельзя утверждать о нарушении безопасности, потере исходного кода, неудачном развёртывании у клиента, потере данных, конкретном регионе или компенсации по SLA. Классификация GitHub «critical» описывает уровень влияния инцидента, а не измеряет потери каждого клиента.

Следующее полезное раскрытие должно объяснить зависимость, которая позволила инциденту с раннерами Actions затронуть пути API, LFS, Issues и Pages, и отделить первоначальный сбой от эффектов накопления очередей и восстановления. До этого обоснованный вывод остаётся операционным: GitHub восстановила цепочку сервисов, но клиентам необходимо проверить, согласуются ли их собственные записи о событиях, заданиях и развёртываниях, прежде чем считать инцидент завершённым.

Источники