История сбоев Circle Ci

1. 21 октября 2026 г. в 19:31 UTCidentified

   Некоторые пользователи могут столкнуться с увеличением времени ожидания работы в Docker 2-го поколения из-за проблем с пропускной способностью.

2. 21 октября 2026 г. в 20:03 UTCidentified

   Мы добавляем дополнительные возможности, чтобы помочь смягчить проблему. Примечание: мы все еще видим задержки до 20 минут на 2xlarge.

3. 21 октября 2026 г. в 20:22 UTCidentified

   Время ожидания 2-кратного увеличения рабочих мест докера восстанавливается. Мы будем продолжать обновляться по мере появления возможностей в Интернете.

4. 21 октября 2026 г. в 20:35 UTCidentified

   Время ожидания 2-кратного увеличения рабочих мест докера теперь составляет менее 60 секунд. Время ожидания для других размеров ресурсов не было затронуто этим инцидентом и остается менее 10 секунд.

5. 21 октября 2026 г. в 20:40 UTCmonitoring

   Мы наблюдаем полное восстановление времени ожидания докерских работ.

6. 21 октября 2026 г. в 20:54 UTCresolved

   Время ожидания для работы в Docker 2-го поколения восстановилось, и рабочие места работают в обычное время ожидания.

7. 22 октября 2026 г. в 23:29 UTCpostmortem

   ##Резюме С 15:44 до 20:55 UTC 21 октября клиенты, работающие в Gen 2 Docker, стали чаще ждать начала работы. Задержки были самыми длительными в классе ресурсов 2xlarge, где рабочие места ждали до 20 минут. Инцидент был вызван ограниченной доступностью облачных экземпляров, которые мы настроили для удовлетворения спроса, особенно для 2-х крупных рабочих мест. В ответ наша команда инженеров настроила дополнительные типы экземпляров, настроила дополнительные кластеры докеров Gen 2. К 20:55 UTC время ожидания пришло в норму, и инцидент был разрешен. После того, как инцидент был урегулирован, мы расширили наш флот докеров поколения 2 в дополнительные облачные области, и мы продолжаем активно поддерживать дополнительные облачные области для предотвращения подобных инцидентов в будущем. Первоначальную страницу статуса можно найти здесь: [21 октября - Увеличение времени ожидания Docker gen2] (https://status.circleci.com/incidents/5jb50gh55gtj). ## Предыстория Когда CircleCI выполняет работу Docker, мы запланируем ее на одном из нескольких кластеров облачных экземпляров, и каждый экземпляр способен выполнять несколько изолированных заданий. Планирование работы в облачном экземпляре - это классическая [проблема пакетирования контейнеров] (https://en.wikipedia.org/wiki/Bin packing problem): поиск доступной емкости, которая соответствует процессору, памяти и памяти запрашиваемого класса ресурсов. Большие классы ресурсов, такие как 2xlarge, сложнее подойдут, чем меньшие, которые плотнее упаковываются вместе. Мы предоставляем облачные экземпляры, используя ранжированный список типов экземпляров. Если поставщик облачных услуг не может предоставить наш первый выбор, мы возвращаемся к следующему типу в списке. Мы также поддерживаем минимальный размер парка: минимальное количество экземпляров остается работоспособным, так что мы не отказываемся от мощности, когда спрос низкий. Выше этого минимального размера парка мы добавляем примеры по мере роста спроса. Когда нет достаточной мощности для выполнения рабочей нагрузки, мы выстраиваем очередь, которая работает, пока емкость не станет доступной. ##Что случилось Все времена UTC Начиная с 15:44 21 октября, спрос на ресурс класса Gen 2 2xlarge резко вырос, и мы не обеспечили дополнительные мощности достаточно быстро, чтобы не отставать. Наша инженерная команда начала расследование. К 19:25 время ожидания для класса ресурсов Gen 2 2xlarge достигло 20 минут, а время ожидания для других классов ресурсов также увеличилось. К 19:56 наша инженерная команда настроила дополнительные типы экземпляров для флота Gen 2, чтобы получить больше мощности в Интернете, и к 19:59 мы обеспечивали эти типы экземпляров. В 20:11 мы добавили несколько дополнительных кластеров Gen 2 и увеличили минимальный размер флота на этих кластерах. К 20:35 количество рабочих мест в очередях вернулось к нормальному уровню, а к 20:41 95% из 2-х крупных рабочих мест начали работу в течение 4 секунд. Мы разрешили инцидент в 20:55. После устранения этого инцидента мы добавили дополнительные облачные области для рабочих мест Docker, чтобы сделать больше возможностей. ##Профилактика и совершенствование процессов Мы уже предприняли следующие шаги для улучшения времени начала работы, в том числе по привлечению ресурсов из большего количества мест, резервированию больших ресурсов и внедрению более быстрого обеспечения. ** Мы добавили дополнительные регионы для рабочих мест Docker.** Недавно мы добавили дополнительные облачные области для рабочих мест Machine, и теперь мы сделали то же самое для рабочих мест Docker. Мы будем активно продолжать добавлять дополнительные облачные области как для Docker, так и для Machine. ** Добавлены дополнительные кластеры Gen 2**. Мы настроили несколько дополнительных кластеров Gen 2, чтобы быстрее планировать рабочие места и увеличить общую пропускную способность. Мы расширили набор типов облачных экземпляров, которые мы используем, и увеличили наш минимальный размер парка. Мы настроили дополнительные типы экземпляров. Мы также увеличили минимальный размер парка для Gen 2, чтобы удовлетворить текущий базовый спрос. ** Мы изменили график работы, чтобы расставить приоритеты при планировании больших классов ресурсов. Мы изменили то, как мы планируем рабочие места, чтобы сбалансировать время ожидания более справедливо по классам ресурсов и более эффективно использовать доступные экземпляры. ## Заключение Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за терпение, пока наша команда работала над разрешением этого инцидента. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 15:58 UTCinvestigating

   Мы наблюдаем увеличение времени ожидания некоторых заданий macOS с использованием класса ресурсов m4pro.large. Мы расследуем и вскоре предоставим еще одно обновление. Спасибо за ваше терпение.

2. 20 октября 2026 г. в 16:32 UTCmonitoring

   Клиенты, работающие с macOS в классе ресурсов m4pro.large, все еще видят увеличение времени ожидания, а некоторые рабочие места ждут до 30 минут. Мы продолжаем следить за этим и вскоре поделимся еще одним обновлением.

3. 20 октября 2026 г. в 17:02 UTCmonitoring

   Время ожидания m4pro.large все еще остается повышенным из-за большого спроса. Все m4pro.medium в норме. Мы активно следим, ценим терпение.

4. 20 октября 2026 г. в 17:31 UTCmonitoring

   Время ожидания работы macOS в классе ресурсов m4pro.large восстанавливается. Рабочие места, использующие Xcode 27.0, теперь ждут в среднем около ~ 3,5 минут, по сравнению с примерно ~ 40 минутами на пике. Рабочие места, использующие Xcode 26.6 и 26.4.1, все еще работают через отставание. Время ожидания на m4pro.medium нормальное. Мы поделимся еще одним обновлением, как только продолжим мониторинг.

5. 20 октября 2026 г. в 18:14 UTCresolved

   Время ожидания работы macOS в классе ресурсов m4pro.large пришло в норму. Мы благодарим вас за терпение, в то время как отставание прояснилось.

Автоматический перевод официального обновления инцидента.

1. 14 октября 2026 г. в 14:47 UTCinvestigating

   С 14:00 UTC клиенты, работающие с macOS, которые используют Xcode 26.6.0 на M4 Pro, испытывают задержки с началом работы. Время ожидания достигло 30 минут и более. Спасибо за ваше терпение, пока наши инженеры ведут расследование. Мы предоставим еще одно обновление к 15:30 UTC.

2. 14 октября 2026 г. в 15:17 UTCidentified

   Задержки с запуском заданий macOS, использующих Xcode 26.6.0, восстановлены. Начиная примерно с 15:11 UTC, задания macOS, использующие Xcode 26.4, начинаются с задержки, время ожидания составляет около 30 минут. Спасибо за ваше терпение, пока наши инженеры работают над этим. Мы предоставим еще одно обновление к 15:45 UTC.

3. 14 октября 2026 г. в 16:01 UTCresolved

   Между 14:00 UTC и 15:51 UTC 14 октября клиенты, работающие с macOS, которые используют Xcode 26.6.0 или Xcode 26.4, испытывали задержки с началом работы. Примерно с 14:00 UTC рабочие места, использующие Xcode 26.6.0 на M4 Pro большого класса ресурсов, ждали 30 минут или более, и эти задержки восстановились примерно в 15:12 UTC. Примерно с 15:11 по UTC рабочие места, использующие Xcode 26.4, ждали около 30 минут. Проблема решена, и вся затронутая функциональность вернулась в нормальное русло. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

Автоматический перевод официального обновления инцидента.

1. 9 октября 2026 г. в 11:33 UTCidentified

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

2. 9 октября 2026 г. в 13:00 UTCidentified

   Что повлияло: Клиенты запускают трубопроводы, а клиенты полагаются на исходящие веб-хуки и уведомления по электронной почте и Slack. Чего можно ожидать С 11:15 UTC: Трубопроводы все еще создаются, пока это продолжается, но еще не обработано, поэтому ретриггеринг может привести к дублированию трубопроводов. Исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не отправляются. Трубопроводные статусы могут быть не видны. Данные об использовании на странице использования проекта будут устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над этим. Следующее обновление: Мы предоставим еще одно обновление к 13:30 UTC.

3. 9 октября 2026 г. в 13:30 UTCidentified

   Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Что повлияло: Клиенты запускают трубопроводы, а клиенты полагаются на исходящие веб-хуки и уведомления по электронной почте и Slack. Чего можно ожидать: С 13:00 UTC трубопроводы снова обрабатываются и начинаются рабочие места. Большинство рабочих мест в настоящее время начинаются примерно через 4 минуты, а некоторые ждут до 10 минут. Трубопроводы, запущенные во время инцидента, все еще обрабатываются и могут занять больше времени. - Возобновились исходящие веб-хуки и уведомления. Трубопроводы все еще обрабатываются из-за отставания, поэтому ретриггеринг может привести к дублированию трубопроводов. Спасибо за ваше терпение, пока наши инженеры работают над этим. Следующее обновление: Мы предоставим еще одно обновление к 14:00 UTC.

4. 9 октября 2026 г. в 14:00 UTCidentified

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Что повлияло Клиенты, выполняющие рабочие процессы и задания, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать Трубопроводы снова обрабатываются, в том числе срабатывающие во время инцидента. С 13:25 UTC рабочие процессы и рабочие места начинаются с растущих задержек. Большинство рабочих мест в настоящее время начинаются примерно через 10 минут, а некоторые ждут до 25 минут. Мы рассчитываем проработать это отставание примерно к 14:35 UTC. Рабочие потоки из трубопроводов, запущенных во время инцидента, все еще ждут начала, поэтому повторный запуск может привести к дублированию рабочих процессов. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над этим. Следующее обновление Мы предоставим еще одно обновление к 14:30 UTC.

5. 9 октября 2026 г. в 14:29 UTCidentified

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Что повлияло Клиенты, выполняющие рабочие процессы и задания, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать Задержки с началом рабочих процессов и рабочих мест улучшаются. Большинство рабочих мест начинаются примерно через 3 минуты, по сравнению с 10 минутами в 13:50 UTC. Некоторые рабочие процессы из трубопроводов, запущенных во время инцидента, все еще ждут около 40 минут для начала. - Работа над отставанием занимает немного больше времени, чем ожидалось. Теперь мы рассчитываем очистить его примерно к 14:45 UTC. Рабочие потоки из трубопроводов, запущенных во время инцидента, все еще ждут начала, поэтому повторный запуск может привести к дублированию рабочих процессов. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над этим. Следующее обновление Мы предоставим еще одно обновление к 15:00 UTC.

6. 9 октября 2026 г. в 14:43 UTCidentified

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Что повлияло Клиенты, выполняющие рабочие процессы и задания, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать Отставание рабочих процессов от трубопроводов, вызванных во время инцидента, устранено примерно в 14:40 по UTC. Большинство рабочих мест начинаются примерно через 30 секунд, а некоторые ждут до 3 минут. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры продолжают работать над основной проблемой. Следующее обновление Мы предоставим еще одно обновление к 15:10 UTC.

7. 9 октября 2026 г. в 14:54 UTCmonitoring

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Что повлияло Клиенты, выполняющие рабочие процессы и задания, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать - Отставание трубопроводов и рабочих процессов от инцидента устранено. С 14:45 UTC большинство рабочих процессов и рабочих мест начинаются примерно через 15 секунд, а время начала работы продолжает возвращаться к норме. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры следят за восстановлением. Следующее обновление Мы предоставим еще одно обновление к 15:20 UTC.

8. 9 октября 2026 г. в 15:32 UTCmonitoring

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Что повлияло Клиенты просматривают трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, а клиенты просматривают данные об использовании на странице использования проекта. Чего можно ожидать Рабочие процессы и рабочие места выполняются вовремя. Интерфейс CircleCI отстает примерно на 30 минут. Новые рабочие процессы и изменения статуса могут занять много времени. Наши инженеры активно работают над ускорением обработки, чтобы пользовательский интерфейс мог догнать. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над сокращением этой задержки. Следующее обновление Мы предоставим еще одно обновление к 16:00 UTC.

9. 9 октября 2026 г. в 16:02 UTCmonitoring

   С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Что повлияло Клиенты, выполняющие рабочие процессы и рабочие места, клиенты, просматривающие трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать С 15:15 UTC рабочие процессы и рабочие места начинаются с растущих задержек. Большинство рабочих мест в настоящее время начинаются примерно через 4 минуты, а некоторые ждут до 20 минут. Пользовательский интерфейс CircleCI в среднем отстает на 30 минут, а некоторые обновления занимают больше времени. Новые рабочие процессы и изменения статуса могут занять много времени. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над сокращением этих задержек. Следующее обновление Мы предоставим еще одно обновление к 16:30 UTC.

10. 9 октября 2026 г. в 16:32 UTCmonitoring

    С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Примерно с 15:15 UTC рабочие процессы и рабочие места снова начинаются с задержек. Что повлияло Клиенты, выполняющие рабочие процессы и рабочие места, клиенты, просматривающие трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать Задержки с началом рабочих процессов и рабочих мест перестали увеличиваться и начинают ослабевать. Большинство рабочих мест начинаются примерно через 4 минуты, а некоторые ждут до 25 минут. - UI CircleCI теперь отстает примерно на 20 минут, по сравнению с 30 минутами. Новые рабочие процессы и изменения статуса могут занять много времени. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над сокращением этих задержек. Следующее обновление Мы предоставим еще одно обновление к 17:00 UTC.

11. 9 октября 2026 г. в 17:06 UTCmonitoring

    С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Примерно с 15:15 UTC рабочие процессы и рабочие места снова начинаются с задержек. Что повлияло Клиенты, выполняющие рабочие процессы и рабочие места, клиенты, просматривающие трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать Задержки с началом рабочих процессов и рабочие места остаются стабильными. Большинство рабочих мест начинаются примерно через 4 минуты, а некоторые ждут до 8 минут, по сравнению с примерно 25 минутами. Пользовательский интерфейс CircleCI в среднем отстает на 20 минут, а некоторые обновления занимают больше времени. Новые рабочие процессы и изменения статуса могут занять много времени. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над сокращением этих задержек. Следующее обновление Мы предоставим еще одно обновление к 17:30 UTC.

12. 9 октября 2026 г. в 17:34 UTCidentified

    С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Примерно с 15:15 UTC рабочие процессы и рабочие места снова начинаются с задержек. Что повлияло Клиенты, запускающие трубопроводы и работающие рабочие процессы и рабочие места, клиенты, просматривающие трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего можно ожидать - С 17:00 UTC задержки значительно возросли. Большинство рабочих мест в настоящее время занимают около 12 минут, а некоторые ждут до 30 минут. С 17:15 UTC некоторые рабочие места не начинаются. Трубопроводы обрабатываются медленнее, поэтому некоторым может потребоваться больше времени для начала. Интерфейс CircleCI отстает более чем на час. Новые рабочие процессы и изменения статуса могут занять много времени. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Спасибо за ваше терпение, пока наши инженеры работают над этим. Следующее обновление Мы предоставим еще одно обновление к 18:00 UTC.

13. 9 октября 2026 г. в 18:08 UTCidentified

    С 11:15 UTC клиенты испытывают перебои в работе трубопроводов и уведомлений. Между 11:15 UTC и примерно 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и транзакционные уведомления (Slack и электронная почта) не были отправлены. Между 13:00 UTC и 14:40 UTC рабочие процессы и рабочие места начались с задержками. Примерно с 15:15 UTC рабочие процессы и рабочие места снова начинаются с задержек. Что повлияло Клиенты, запускающие трубопроводы и работающие рабочие процессы и рабочие места, клиенты, просматривающие трубопроводы, рабочие процессы и рабочие места в пользовательском интерфейсе CircleCI, и клиенты, просматривающие данные об использовании на странице использования проекта. Чего ожидать - С 17:00 UTC мы наблюдаем увеличение задержек. Большинство рабочих мест теперь занимают около 25 минут, а некоторые ждут до часа. Начиная примерно с 17:15 по UTC, некоторые рабочие процессы не увенчались успехом, и небольшое количество рабочих мест не может начаться. Новые трубопроводы стоят в очереди и требуют больше времени для запуска. Интерфейс CircleCI отстает более чем на час. Новые рабочие процессы и изменения статуса могут занять много времени. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Данные о плате за использование на странице использования проекта в настоящее время являются устаревшими. Наши инженеры продолжают работать над решением проблемы. Следующее обновление Мы предоставим еще одно обновление к 18:30 UTC.

14. 9 октября 2026 г. в 18:32 UTCidentified

    Что изменилось с момента последнего обновления UI CircleCI отстает примерно на час, а для некоторых обновлений до 90 минут. Рабочие процессы и рабочие места могут уже работать или могут работать, даже если пользовательский интерфейс показывает их как не запущенные или не показывает их вообще. Работа, которая работает, начинается быстрее. Большинство из них начинаются примерно через 15 минут, по сравнению с 28 минутами, хотя некоторые все еще ждут более часа. Новые трубопроводы все чаще задерживаются. Некоторые рабочие процессы все еще терпят неудачу. Рабочие процессы, которые не могли быть обработаны вовремя, помечаются как неудачные. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. Все еще продолжается: Данные о плате за использование на странице использования проекта являются устаревшими. Следующее обновление Мы предоставим еще одно обновление к 19:00 UTC.

15. 9 октября 2026 г. в 18:57 UTCidentified

    Что изменилось с момента последнего обновления * Работа начинается быстрее. Большинство из них начинаются примерно через 8 минут, с 15 минут, а самое продолжительное ожидание сократилось с более чем часа до 45 минут. * Интерфейс CircleCI начинает догонять, но он все еще отстает. Рабочие процессы и рабочие места могут уже работать или могут работать, даже если пользовательский интерфейс показывает их как не запущенные или не показывает их вообще. Трубопроводы обрабатываются быстрее, но новые трубопроводы все еще задерживаются. Все еще продолжается Некоторые рабочие процессы и рабочие места все еще терпят неудачу. Пожалуйста, избегайте повторного запуска рабочих процессов, которые еще не отображаются в пользовательском интерфейсе, так как это может создавать дубликаты. * Данные о плате за использование на странице использования проекта являются устаревшими. Следующее обновление Мы предоставим еще одно обновление к 19:30 UTC.

16. 9 октября 2026 г. в 19:29 UTCidentified

    С момента последнего обновления рабочие места начинаются быстрее: большинство из них начинаются примерно через 6 минут, по сравнению с 8 минутами. Интерфейс CircleCI набирает обороты, но все еще отстает примерно на час. Новые трубопроводы обрабатываются по мере их поступления. Рабочие места могут уже работать, даже если пользовательский интерфейс еще не показывает их, поэтому, пожалуйста, избегайте повторного запуска рабочих процессов, которые не отображаются в пользовательском интерфейсе. Мы предоставим еще одно обновление к 20:00 UTC.

17. 9 октября 2026 г. в 20:06 UTCidentified

    Рабочие места начинаются быстрее, и меньше терпят неудачу: большинство рабочих мест начинаются примерно через 4 минуты, по сравнению с 6 минутами, а самое продолжительное ожидание сократилось с 30 минут до 20 минут. Трубопроводы из ранее произошедшего в настоящее время прорабатываются. Пользовательский интерфейс CircleCI все еще отстает, и некоторые старые обновления могут занять больше времени. Рабочие места могут уже работать, даже если пользовательский интерфейс еще не показывает их, поэтому, пожалуйста, избегайте повторного запуска рабочих процессов, которые не отображаются в пользовательском интерфейсе. Мы предоставим еще одно обновление к 20:30 UTC.

18. 9 октября 2026 г. в 21:22 UTCidentified

    С 20:48 UTC новые рабочие процессы и рабочие места не начинаются. Мы временно приостановили начало новой работы, чтобы наши системы могли наверстать упущенное, включая отложенные обновления интерфейса CircleCI и API. Более старые обновления теперь появляются в пользовательском интерфейсе и API, поскольку это отставание очищается. Новые трубопроводы все еще принимаются и стоят в очереди Пожалуйста, избегайте повторного запуска трубопроводов или рабочих процессов в течение этого времени, так как это может создать дубликаты после возобновления работы. Мы предоставим еще одно обновление к 22:00 UTC.

19. 9 октября 2026 г. в 22:09 UTCidentified

    С момента нашего последнего обновления большинство трубопроводов, которые были отложены ранее в результате инцидента, теперь обработаны, и их рабочие процессы стоят в очереди. Новые рабочие процессы и рабочие места остаются приостановленными, пока мы готовимся к безопасному возобновлению работы. Отложенные обновления продолжают появляться в интерфейсе CircleCI и API. Пожалуйста, продолжайте избегать повторного запуска трубопроводов или рабочих процессов, так как это может создать дубликаты после возобновления работы. Мы предоставим еще одно обновление к 22:30 UTC.

20. 9 октября 2026 г. в 22:28 UTCidentified

    С момента последнего обновления мы начали постепенно возобновлять работу, и некоторые рабочие процессы и рабочие места снова начинаются. Большинство стоящих в очереди работ все еще ждут, а рабочие места, которые действительно начинаются, возможно, ждали более часа. Мы тщательно увеличиваем скорость, чтобы избежать перегрузки наших систем. Отложенные обновления продолжают появляться в интерфейсе CircleCI и API. Пожалуйста, продолжайте избегать повторного запуска трубопроводов или рабочих процессов, так как это может создавать дубликаты в виде очередей. Мы предоставим еще одно обновление к 23:00 UTC.

21. 9 октября 2026 г. в 23:00 UTCidentified

    Началось большое количество очередей и заданий, а пользовательский интерфейс и API CircleCI догнали и показывают обновления обычно с небольшими задержками. Мы продолжаем работать над оставшейся очередью работой. Рабочие места из очереди, возможно, ждали около часа или больше, чтобы начать, и некоторые рабочие места Linux ждут до 10 минут для емкости. Пожалуйста, продолжайте избегать повторного запуска, в то время как очерченная работа продолжает обрабатываться. Мы предоставим еще одно обновление к 23:30 UTC.

22. 9 октября 2026 г. в 23:38 UTCidentified

    Мы все еще работаем над значительным отставанием очередей рабочих процессов и рабочих мест. Время ожидания улучшается, но они остаются дольше, чем обычно, и некоторые рабочие места ждали более часа. CircleCI UI и API остаются в актуальном состоянии. Пожалуйста, избегайте повторного запуска трубопроводов или рабочих процессов, пока отставание очищается, так как это может создать дубликаты. Мы предоставим еще одно обновление к 00:00 UTC.

23. 9 октября 2026 г. в 23:59 UTCidentified

    С момента нашего последнего обновления отставание в очередях рабочих процессов и рабочих мест сократилось примерно с 23:47 по UTC. Рабочие процессы и рабочие места начинаются в течение нескольких секунд, а интерфейс CircleCI и API обновлены. Мы внимательно следим за нашими системами, чтобы они оставались стабильными. Мы предоставим еще одно обновление к 00:30 UTC.

24. 10 октября 2026 г. в 00:45 UTCidentified

    Рабочие процессы и рабочие места продолжаются нормально, в течение нескольких секунд, а интерфейс CircleCI и API остаются в актуальном состоянии. Уведомления Slack и по электронной почте, отложенные ранее в связи с инцидентом, все еще поступают. Данные о плате за использование на странице использования проекта являются устаревшими. Мы продолжаем внимательно следить за нашими системами и предоставим еще одно обновление к 01:15 UTC.

25. 10 октября 2026 г. в 01:23 UTCmonitoring

    Рабочие процессы и рабочие места начинаются и работают нормально, а интерфейс CircleCI и API обновлены. Мы продолжаем внимательно следить за нашими системами, чтобы они оставались стабильными. Мы предоставим еще одно обновление к 02:00 UTC.

26. 10 октября 2026 г. в 02:08 UTCresolved

    Между 11:15 UTC и 23:47 UTC 9 октября клиенты испытывали задержки и сбои в трубопроводах, рабочих процессах и рабочих местах, а также задержки в пользовательском интерфейсе CircleCI, API и уведомлениях. С 11:15 до 13:00 UTC были созданы, но не обработаны трубопроводы, а исходящие веб-хуки и уведомления Slack и электронной почты не отправлялись. Примерно с 13:00 до 14:40 UTC рабочие процессы и рабочие места начались с задержками, пока мы работали над отставанием. Примерно с 15:15 до 20:48 UTC рабочие процессы и рабочие места начались с увеличением задержек примерно до часа, а интерфейс CircleCI и API отставали примерно на 2 часа. В течение этого времени некоторые рабочие места не смогли начаться, а некоторые рабочие процессы не увенчались успехом. С 20:48 до 22:10 UTC мы временно приостановили запуск новых рабочих процессов и рабочих мест, чтобы наши системы могли восстановиться. За это время были приняты и поставлены в очередь новые трубопроводы. Примерно с 22:10 до 23:47 UTC рабочие процессы и рабочие места возобновлялись и обрабатывались. Некоторые из них ждали около 2 часов. Проблема решена, и вся затронутая функциональность вернулась в нормальное русло. Данные о плате за использование на странице «Использование проекта» еще не обновлены и будут обновлены, как только наши данные будут заполнены. Клиенты, чья работа потерпела неудачу во время этого окна, могут возобновить работу. Мы благодарим вас за терпение, пока наши инженеры работали над внедрением исправления.

27. 12 октября 2026 г. в 22:32 UTCpostmortem

    ## Summary Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications. * From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent. * From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog. * From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed. * From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time. * From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up to about 2 hours. * By 23:47, the incident was mitigated. The status page for this incident can be found at [October 9 - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Customers experienced a similar incident earlier in the week at [October 6 - Delays in pipelines, workflows, UI data, and notifications](https://status.circleci.com/incidents/z4hbq8h49j8c). Multiple CircleCI services use Temporal backed by Postgres as a reliable queueing mechanism, and both incidents had the same cause: the rate of writes to Temporal's Postgres instance were faster than Postgres’s transaction log could archive those writes. In both cases, this caused multi-hour delays in processing both pipelines and status notifications. We evaluated several mitigations, then paused new workflow starts so the system could recover safely, and ramped back up gradually. We then throttled work back up until our systems returned to normal. To permanently resolve the bottleneck, we have split work across multiple Temporal instances, each with its own independent database and worker clusters, and we load-balance across them. We had already scheduled infrastructure work starting the week of October 12 that would have removed this exact bottleneck and prevented these incidents. So starting 19:11 on October 9 our engineering team implemented, tested, and rolled out a simpler version of these changes within a few hours. We further added new alerting and tuned the underlying databases for better performance under high load. Customers whose jobs failed during this window may rerun them. ## Background To run customer jobs, CircleCI executes a series of steps: we accept customer pipelines; we assign jobs for those pipelines to workers; we deliver status updates for those pipelines and jobs; and we charge customers for the credits those jobs consume. Each of these steps is implemented by an independent service, with reliable queues in between. Historically we have implemented these reliable queues with RabbitMQ on top of durable storage, with exponential backoff and dead letter queues for reliability. Over the last year, we have increasingly reimplemented our reliable queues on [Temporal](https://temporal.io/), which provides far better durability and reliability guarantees over a simpler and more powerful programming model. Our build service \(which turns a pipeline config into an executable plan\), our workflow orchestrator service \(which distributes tasks onto workers\), our notification service \(which delivers status updates\), and our charging service \(which charges customers for credits\) all now use Temporal. Temporal stores the state for its workflows and activities \(called “history”\) in a database, and this is the only component in a Temporal instance that is synchronous and stateful. As a consequence, a Temporal instance’s ability to accept and execute workflows is dependent on the write rate of its backing database. We have also configured Temporal to delete completed workflows and activities from its history 3 days after they complete. At the time of this incident, we used a single clustered Temporal instance backed by a Multi-AZ Postgres RDS instance for all of these reliable queues. While a Multi-AZ RDS instance is resilient to zone failures, it maintains database consistency via a single write-ahead-log \(WAL\). At the time we had configured our Postgres instance to store its WAL on a Dedicated Log Volume \(DLV\) so log writes did not compete with data writes. The database archives the log continuously to backup storage, and it can only reuse space on the volume after the log has been archived. If the database writes logs faster than it archives, the volume fills and Postgres has no space to the write its WAL log. Then the database stops accepting incoming writes and goes entirely read-only. An RDS DLV is limited to 1TB of storage and 3000 IOPS and per AWS these limits are hardcoded and cannot be increased. ## What Happened _\(All times UTC\)_ One of the contributing factors to the October 6 incident was that we were processing a high rate of Temporal history deletions at the same time as incoming work, which in turn put pressure on the backing database. To resolve the October 6 incident, we changed cleanup settings on Temporal’s largest tables and moved the transaction log back to its dedicated volume. These changes eliminated the major source of transaction log writes, but did not consider the additional log writes from scheduled deletions. Because we have configured Temporal to delete completed workflows and activities from its history 3 days after they complete, the October 6 history was scheduled to be deleted on October 9. Starting at 08:00 on October 9, Temporal began processing those scheduled deletions, and as a consequence free space on the Postgres DLV began dropping precipitously, from 0.8TB at 08:00 to 0.1TB by 10:10. Our monitoring alerted at 10:28 and we declared an incident at 10:31. While our infrastructure team was investigating, at 11:15 the DLV ran out of space and the Postgres instance went read-only. This stopped all Temporal processing in its tracks. At 11:42, we restarted Postgres to move the WAL log from the DLV onto the data volume and use the spare disk space and IOPS there. This maneuver had mitigated the incident on October 6, and we knew it would take roughly 60 minutes. While the database was restarting, we began implementing several load-shedding techniques upstream of Temporal: * We began investigating whether we should shed incoming workloads altogether to keep the rest moving, but ultimately decided that this would provide no value. * At 12:29, we flagged off credit charging updates, which represented 12% of Temporal activities. This left the Pipeline Usage page with stale charging data, until we would backfill it, but would not lose data or prevent pipelines from running. At 12:59, the database was back up and began processing work that had queued since 11:15 and by 14:40, this backlog had cleared and jobs were starting on time. However, by 15:15, delays returned as database’s routing cleanup had fallen far behind on the tables Temporal uses to track queued and scheduled work. Those tables normally hold tens of thousands of deleted rows awaiting cleanup, but by late afternoon, they held tens of millions of rows. Every Temporal operation had to read past those rows, so the database spent much more processing time on each one and Temporal ran slower. This resulted in customers continuing to see hour-long delays in starting pipelines and in status updates. For the next several hours we attempted various mitigations, including: * Manipulating Temporal configuration values to reduce database pressure. This had minimal effect. * Running manual vacuum jobs to clean up dead rows in Postgres. This ended up competing for CPU with queries themselves, and was ultimately counterproductive. We cancelled them at 17:45 to relieve the pressure on the database load. * We began trying to move all of the notification usecases to a separate Temporal instance. This represented 18% of Temporal activities. We successfully finished moving notifications by 17:07. * At 17:16, we successfully implemented an optimization in our representation of pipeline state, which reduced it by 5%. That in turn reduced the size of database writes and therefore data pressure on the Postgres WAL log. None of these fully mitigated the issue. By 20:48, we realized that Postgres was now thrashing on database CPU and was no longer bottlenecked on log writes. We further realized that our upstream systems were both submitting new work and also retrying work that had earlier been submitted and failed. Recognizing that we were in a classic retry storm, we paused all incoming and retry work and let it queue up, in order to allow the database to fully complete in-process work. We then slowly throttled up queued work from 22:07 to keep the database at a sustainable load. This fully succeeded by 23:47 when all queued work had started, and we closed the incident at 02:08 on October 10. ## Future Prevention and Process Improvement ### Multiple Temporal Instances In parallel with incident mitigation and resolution, starting at 19:11 on October 9, we also began standing up multiple sharded Temporal instances and implementing the ability to load-balance incoming work between them. Each of the multiple Temporal instances maintains its own independent database and worker clusters, and so is isolated from the others. As a postmortem action item from the October 6 incident, we had already scheduled infrastructure work that would have removed the bottleneck of a single Temporal instance and Postgres database, starting October 12 and expecting to take 2 weeks. On October 9, we realized that this work simply could not wait, so our engineering team implemented, tested, and rolled out a simpler version of the planned changes within a few hours. These changes completed successfully at 01:45 on October 10. **In addition, we are changing how we store and monitor transaction logs.** Our Temporal database no longer uses the fixed-size log volume. We are adding alerts on how far log archiving falls behind and how fast the database writes logs, so we can act hours earlier than we did on October 9. **We are also revisiting the Temporal's deletion schedule.** Temporal deletes finished work a few days after it runs, so a busy day returns as database load later in the week. We are changing when and how quickly those deletions run. **We are changing how our systems retry when Temporal is slow.** On October 9, our systems retried failed work against Temporal and added to its load. As we committed after the October 6 incident, we are changing our systems to wait for Temporal to recover so work is not dropped. ## Conclusion Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve these incidents. Please reach out to our support team with any questions or concerns.

Автоматический перевод официального обновления инцидента.

1. 8 октября 2026 г. в 13:00 UTCidentified

   Клиенты могут испытывать повышенное время ожидания рабочих мест. Мы работаем над решением этой проблемы.

2. 8 октября 2026 г. в 13:34 UTCidentified

   Потребители, использующие рабочие места в Linux, испытывают повышенное время ожидания, в среднем около 11 минут, причем самое длительное ожидание превышает 30 минут на средних, средних и больших ресурсных классах. Наши инженеры определили проблему и работают над исправлением. Мы предоставим еще одно обновление к 14:00 UTC.

3. 8 октября 2026 г. в 14:04 UTCidentified

   Клиенты, использующие рабочие места в Linux, испытывают повышенное время ожидания, в среднем около 40 минут, при этом самое длительное ожидание превышает 50 минут. Большинство классов машинных ресурсов Linux затронуты, включая средние, большие, xlarge, 2xlarge и их эквиваленты Arm. Наши инженеры определили проблему и работают над исправлением. Мы предоставим еще одно обновление к 14:30 UTC.

4. 8 октября 2026 г. в 14:37 UTCidentified

   Клиенты, использующие рабочие места в Linux и удаленный Docker, испытывают повышенное время ожидания. Время ожидания начало уменьшаться и теперь в среднем составляет около 20 минут, причем самое длительное ожидание превышает 40 минут на некоторых классах ресурсов. Наши инженеры определили проблему и работают над исправлением. Мы предоставим еще одно обновление к 15:00 UTC.

5. 8 октября 2026 г. в 15:01 UTCidentified

   Время ожидания сокращается, но клиенты, использующие рабочие места в Linux и удаленный докер, все еще испытывают задержки. Время ожидания в настоящее время в среднем составляет около 11 минут, при этом самое длительное ожидание превышает 35 минут на некоторых классах ресурсов. Мы работаем над тем, чтобы как можно быстрее добавить мощности. Мы предоставим еще одно обновление к 15:30 UTC.

6. 8 октября 2026 г. в 15:31 UTCidentified

   Время ожидания продолжает сокращаться, но клиенты, использующие Linux, все еще испытывают задержки. Время ожидания в настоящее время в среднем около 6 минут. Самые длинные ожидания, до 20 минут, на 2xlarge, arm.2xlarge и gpu.nvidia. Малые классы ресурсов. Мы работаем над тем, чтобы как можно быстрее добавить мощности. Мы предоставим еще одно обновление к 16:00 UTC.

7. 8 октября 2026 г. в 15:59 UTCidentified

   Время ожидания продолжает сокращаться, но клиенты, использующие Linux, все еще испытывают задержки. Время ожидания в настоящее время в среднем составляет около 90 секунд, при этом самое длительное ожидание составляет около 6 минут на некоторых классах ресурсов. Мы работаем над тем, чтобы как можно быстрее добавить мощности. Мы предоставим еще одно обновление к 16:30 UTC.

8. 8 октября 2026 г. в 16:09 UTCmonitoring

   Время ожидания клиентов, использующих Linux, и удаленный Docker вернулись к норме. Мы отслеживаем, чтобы подтвердить, что время ожидания остается стабильным, пока мы продолжаем добавлять мощности. Мы предоставим еще одно обновление к 16:30 UTC.

9. 8 октября 2026 г. в 16:35 UTCresolved

   Между 12:40 UTC и 16:00 UTC 8 октября клиенты, использующие рабочие места Linux и удаленный Docker, испытали повышенное время ожидания. Проблема решена, и время ожидания пришло в норму. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

10. 8 октября 2026 г. в 17:54 UTCpostmortem

    ##Резюме С 1 октября клиенты CircleCI столкнулись с многочисленными инцидентами, которые привели к задержкам и сбоям в исполнении трубопровода. Есть две причины, обе из которых команда инженеров CircleCI активно смягчает: * Доступность облачных вычислений * Внутренняя инфраструктура ## Доступность облачных вычислений Проблема: спрос на высокопроизводительные облачные экземпляры чрезвычайно быстро растет во всей отрасли, что оказывает давление на типы экземпляров облачных провайдеров, которые мы используем для выполнения рабочих мест клиентов. ***Инциденты**: * [Повышенное время ожидания работы машины] (https://status.circleci.com/incidents/jn756xtsy4xg) * [Увеличение времени ожидания задачи для Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [Повышенный уровень инфра-провалов на рабочих местах клиентов] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [Задержка в запуске машинных заданий] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [Задержки с началом работы докера поколения 2] (https://status.circleci.com/incidents/22mrv46g6n7g) **Смягчения и резолюции**: Мы расширяем наш набор областей облачных вычислений, чтобы включить дополнительные области с доступными высокопроизводительными экземплярами. Мы также работаем над тем, чтобы обеспечить дополнительные гарантированные мощности наших партнеров по облачным вычислениям в наших существующих регионах. Мы продолжаем расширять набор типов экземпляров, которые мы можем предложить клиентам. Мы опубликуем подробный отчет об инцидентах 9 октября 2026 года. ##Внутренняя инфраструктура ***Проблема: Мы присваиваем рабочие процессы клиентов нескольким вычислительным провайдерам через службу оркестровки рабочих процессов. В настоящее время эта услуга защищена пропускной способностью записи одной базы данных. **Инциденты:** * [Задержки в трубопроводах, рабочих процессах, данных пользовательского интерфейса и уведомлениях] (https://status.circleci.com/incidents/z4hbq8h49j8c) * [Экстренное обслуживание инфраструктуры] (https://status.circleci.com/incidents/g60yc9bvvkmx) **Смягчения и резолюции**: К 23 октября 2026 года мы планируем внедрить несколько избыточных экземпляров службы оркестровки рабочего процесса, каждый со своей базой данных, что позволит нам разделить нагрузку на оркестровку между ними. ## Наша приверженность Чтобы избежать сомнений, Эти конкретные инциденты не связаны с продолжающимися отключениями в Github. В настоящее время мы не мигрируем нашу инфраструктуру или услуги. * В настоящее время мы не подвергаемся кибератакам. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за их терпение, в то время как наша команда работала над разрешением этих инцидентов и работает над предотвращением будущих инцидентов. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 18:54 UTCidentified

   Увеличилось время ожидания работы на Docker Gen2.

2. 7 октября 2026 г. в 19:00 UTCidentified

   Примечание: задержки будут более заметны для людей, работающих на Docker «большой» и выше.

3. 7 октября 2026 г. в 19:52 UTCmonitoring

   Мы все еще видим всплески времени ожидания задач, но в среднем время ожидания лучше для всех Docker Gen2.

4. 7 октября 2026 г. в 20:05 UTCresolved

   Этот инцидент был урегулирован.

5. 8 октября 2026 г. в 17:54 UTCpostmortem

   ## ** Резюме** С 1 по 8 октября 2026 года клиенты CircleCI пережили пять отдельных инцидентов, в которых рабочие места ждали дольше, чем обычно, чтобы начать или не смогли начать. Три инцидента были вызваны ограниченной доступностью экземпляров от нашего облачного провайдера. Одна была вызвана проблемой конфигурации в нашей инфраструктуре планирования, а другая — ограничениями памяти на внутреннюю службу, которые мы подняли во время инцидента. 1 октября с 07:57 до 10:24 UTC: ** Работа Docker Gen 2 ждала до 30 минут для начала. Проблема конфигурации помешала серверам планирования Gen 2 использовать свои высокопроизводительные локальные диски. Во время всплеска трафика резервные диски насыщались, а трудоустройство замедлялось. ** 7 октября, 13:27 - 14:06 UTC:** Рабочие места машин ждали дольше, чем обычно, потому что мы не могли приобрести достаточное количество виртуальных машин у нашего облачного провайдера. ** 7 октября 14:24 до 15:21 UTC:** Некоторые рабочие места потерпели неудачу из-за ошибки инфраструктуры, и рабочие процессы были отложены. Сервис, который дает каждой работе свою конфигурацию при запуске, исчерпал память и перезапустился. ** 7 октября 18:49 до 20:05 UTC:** Рабочие места Docker Gen 2 ждали дольше, чем обычно, потому что мы не могли получить достаточно экземпляров от нашего облачного провайдера. ** 8 октября с 12:48 до 16:00 UTC:** Рабочие места Linux и удаленные рабочие места Docker ждали до 50 минут. У нашего облачного провайдера не было достаточного количества запрашиваемых типов экземпляров, а дефект в логике выбора другого типа экземпляров не позволял нам использовать альтернативы. Работы, которые ждали во время этих инцидентов, были отложены, а не потеряны. Клиенты, чьи рабочие места потерпели неудачу с ошибкой инфраструктуры во время инцидента 7 октября с 14:24 до 15:21 UTC, могут повторно запустить их. Оригинальные страницы статуса можно найти ниже: * [1 октября - Задержки с началом работы докера поколения 2] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 октября - Задержка в запуске машинных заданий] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 октября - Повышенный уровень инфра-сбоев на рабочих местах клиентов] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 октября - Увеличение времени ожидания задачи для Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 октября - Повышенное время ожидания работы машины] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** Справочная информация** Каждая работа, выполняемая на CircleCI, требует вычислений. Откуда берется этот вычислитель, зависит от исполнителя. Задания Docker работают на кластерах серверов, которые планируют работу на флоте экземпляров. Планировщик - это программное обеспечение на тех серверах, которое решает, какой экземпляр выполняет каждую работу. Рабочие места в Gen 2 Docker работали на одном из таких кластеров во время инцидента 1 октября. Работа Докера поколения 1 распределена по нескольким кластерам. Машинные задания, включая удаленные задания Docker, получают выделенную виртуальную машину. Удаленная работа Docker обрабатывается как работа машины Linux от подачи до предоставления. Наша служба предоставления машин запрашивает каждую машину у нашего облачного провайдера в одном из двух регионов, которые мы обычно используем для работы машин. Когда поставщик не может предоставить запрашиваемый нами тип экземпляра, услуга возвращается: он запрашивает другой тип экземпляра или другой регион из списка, который мы поддерживаем. Работа ждет, пока машина будет доступна. Когда какая-либо работа начинается, она запрашивает услугу настройки работы для своей конфигурации. Этот сервис работает как набор блоков, которые являются небольшими копиями одной и той же программы. Если слишком много стручков останавливается, оставшиеся стручки несут больше нагрузки, и рабочие места не могут начаться, пока служба не восстановится. Эти пути зависят от трех видов пропускной способности: пропускной способности наших систем планирования, поставки экземпляров от нашего облачного провайдера, а также памяти и количества копий сервисов, которые запускают рабочие места. Недостаток в любой из них заставляет работу ждать или терпеть неудачу. ##**Что случилось** Все времена UTC ###**Октябрь 1: Работа Docker Gen 2 откладывается до 30 минут** В 07:44 активность дисков на серверах, которые планируют работу в Gen 2 Docker, выросла до 90% емкости и осталась там. В 07:57 число рабочих мест Докера, ожидающих начала, начало расти, и время ожидания выросло вместе с ним. Автоматическое оповещение о вызове инженера в 08:08. Мы объявили об инциденте в 08:42. В 08:43 инженеры определили высокую задержку диска на серверах планирования. Сначала они полагали, что диски слишком медленные для загрузки, поэтому они подготовили изменение на более быстрый тип диска. В 09:01 команда согласовала два рабочих потока: переместить серверы на более быстрые диски и добавить второй кластер Gen 2, чтобы рабочие места разделились на два кластера. В 09:41 инженеры нашли первопричину. Каждый сервер планирования имеет быстрые диски, подключенные непосредственно к нему, и планировщик предназначен для хранения своих рабочих данных. Эти серверы работают на защищенном изображении операционной системы, и на этом изображении не используются быстрые диски. Вместо этого планировщик записывал свои данные на более медленные сетевые диски. Сценарий, настраивающий быстрые диски, вышел из строя без ошибки, а пробел в регистрации на этих серверах скрыл сбой. Движение 2-го поколения также становилось все более оживленным. Более медленные диски насыщались во время этих всплесков, и планировщик отставал. Время ожидания достигло пика в 09:54, когда рабочие места в классе средних ресурсов Gen 2 ждали до 30 минут. В 09:55 инженеры применили исправление, которое правильно настроило быстрые диски. В 10:11 планировщик начал быстрее размещать рабочие места, что подтвердило, что серверы могут идти в ногу с новыми рабочими местами. Время ожидания для среднего поколения 2 упало до 13 минут в 10:14, 7 минут в 10:17 и 1 минуты 30 секунд в 10:20. Мы перенесли страницу статуса на мониторинг в 10:24 и разрешили инцидент в 10:45. В 11:20 второй кластер Gen 2 начал работать. ### ** 7 октября, с 13:27 до 14:06: Повышенное время ожидания для машинных рабочих мест ** Мы объявили об инциденте в 13:27 после того, как увидели увеличенные очереди и время ожидания. Мы разместили на странице статуса в 13:31. В 13:31 инженеры увидели, что мы изо всех сил пытаемся приобрести виртуальные машины для машинных заданий, и что число рабочих мест, ожидающих начала, было высоким в основном для машинных заданий. В 13:34 время ожидания было увеличено. В 13:48 время ожидания начало восстанавливаться, когда стало доступно больше машин, и мы разрешили инцидент в 14:06. ### ** 7 октября, с 14:24 до 15:21: сбои в работе и задержки рабочего процесса** Вскоре после того, как предыдущий инцидент был отмечен как урегулированный, мы объявили о новом инциденте в 14:24 из-за резкого сокращения числа рабочих мест, представленных нашим системам исполнения. В 14:26 инженеры увидели, что стручки службы конфигурации работы перезапускаются. Подвески, которые перезагружаются, оставляют меньше копий сервиса для ответа на запросы, а рабочие места, которые не смогли восстановить свою конфигурацию после повторных попыток, потерпели неудачу с ошибкой инфраструктуры. Рабочие процессы, которые уже работали, ждали обновлений от рабочих мест, которые еще не начались. В 14:35 инженеры увеличили объем доступной памяти стручкам и увеличили количество стручков, что дало сервису больше копий для совместного использования нагрузки. Мы также увеличили объем доступной памяти, и количество сообщений, проходящих через нашу систему рабочего процесса, вернулось к нормальному уровню. В 14:44 мы перенесли страницу статуса на мониторинг. Подушки в службе настройки работы достигли пределов памяти и перезапустились. Мы увеличили выделение памяти и количество капсул, и сервис восстановился. В 15:13 мы увеличили количество случаев в наших кластерах докеров 2-го поколения, чтобы мы могли быстро справиться с отставанием в ожидании работы. Мы разрешили инцидент в 15:21. ### ** 7 октября, 18:49 до 20:05: Повышенное время ожидания для рабочих мест Docker Gen 2** Мы объявили о новом инциденте в 18:49 после того, как время ожидания Docker Gen 2 выросло. В 18:51 инженеры подтвердили, что нехватка доступных экземпляров не позволила нам приобрести достаточное их количество, что увеличило время ожидания. Время ожидания отличалось по размеру ресурсного класса. В 19:52 среднее время ожидания было ниже, чем за час до того, как стало доступно больше емкости, хотя короткие всплески продолжались, и мы переместили страницу статуса для мониторинга. Мы разрешили инцидент в 20:05. 8 октября: Машина Linux и удаленные рабочие места Docker ждут до 50 минут Мы объявили об инциденте в 12:48 после того, как увидели большое количество рабочих мест, ожидающих начала, и долгое время ожидания для машинных и удаленных рабочих мест Docker. В 12:49 инженеры увидели, что наш облачный провайдер не может предоставить достаточно экземпляров. Задержки продолжали расти по мере нашего расследования. В 13:13 мы начали изучать логику, которая выбирает другой тип экземпляра или область, когда наш первый выбор недоступен. В 13:24 мы заподозрили, что дефект в этой логике мешает нам использовать другие типы экземпляров в нашем первичном регионе, поэтому мы отключили наш запасной регион и подтвердили причину дефекта. Инженеры начали работать над исправлением и развернули его в 14:49. Сервис начал запрашивать другие типы экземпляров и запускал машины в большом количестве. В 14:58 очередь рабочих мест в ожидании машины неуклонно падала. Среднее время ожидания в классах ресурсов продолжало падать в течение следующего часа, когда мы работали над отставанием в ожидании. В 16:00 очередь рабочих мест в ожидании машины очистилась и количество рабочих мест в ожидании вернулось к норме. Мы перенесли страницу статуса на мониторинг в 16:09 и разрешили инцидент в 16:35. ##** Предотвращение и улучшение процессов в будущем** Мы предпринимаем следующие шаги для повышения устойчивости времени начала работы, включая диверсификацию поставок, логику резервного копирования и раннее обнаружение. ** Мы расширяем наши вычислительные области.** В инцидентах 7 и 8 октября наш облачный провайдер не смог предоставить достаточное количество экземпляров в регионах, которые мы использовали. Мы добавляем новые регионы в нашу резервную логику, чтобы справиться с пиками спроса, которые опережают наши предпочтительные регионы. ** Мы фиксируем логику, которая выбирает другой тип экземпляра.** 8 октября неисправность механической службы не позволила использовать другие типы экземпляров в том же регионе. Мы внедрили исправление во время инцидента и сейчас пересматриваем и рефакторизируем эту логику в целом с помощью тестов, так что нехватка одного типа экземпляров переходит в другой. Мы расширяем типы экземпляров, которые мы предлагаем, и обеспечиваем дополнительную емкость. Мы работаем с нашим облачным провайдером, чтобы зарезервировать дополнительные мощности в наших существующих регионах, и мы добавляем типы экземпляров, на которых могут работать рабочие места. Спрос на высокопроизводительные вычисления в отрасли растет. Мы диверсифицируем, где и как мы добываем мощности, чтобы наши клиенты были изолированы от изменений поставок. Мы добавили второй кластер докеров поколения 2, поэтому всплески трафика распределяются по двум кластерам. Мы также добавляем оповещения о планировании насыщения серверного диска и о том, как быстро планировщик размещает рабочие места, и оповещение, которое включается, когда сервер запускается без использования его быстрых дисков. Мы сделали так, что скрипт настройки диска вышел из строя с ошибкой, и мы восстановили доставку журналов с этих серверов, чтобы подобная проблема была видна раньше. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за их терпение, в то время как наша команда работала над разрешением этих инцидентов. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 14:27 UTCinvestigating

   Мы расследуем рост инфра-провалов для рабочих мест клиентов.

2. 7 октября 2026 г. в 14:44 UTCmonitoring

   Мы видим признаки восстановления. Время ожидания Docker Gen2 немного увеличено, и мы следим за этим.

3. 7 октября 2026 г. в 15:21 UTCresolved

   Этот инцидент был урегулирован.

4. 8 октября 2026 г. в 17:55 UTCpostmortem

   ## ** Резюме** С 1 по 8 октября 2026 года клиенты CircleCI пережили пять отдельных инцидентов, в которых рабочие места ждали дольше, чем обычно, чтобы начать или не смогли начать. Три инцидента были вызваны ограниченной доступностью экземпляров от нашего облачного провайдера. Одна была вызвана проблемой конфигурации в нашей инфраструктуре планирования, а другая — ограничениями памяти на внутреннюю службу, которые мы подняли во время инцидента. 1 октября с 07:57 до 10:24 UTC: ** Работа Docker Gen 2 ждала до 30 минут для начала. Проблема конфигурации помешала серверам планирования Gen 2 использовать свои высокопроизводительные локальные диски. Во время всплеска трафика резервные диски насыщались, а трудоустройство замедлялось. ** 7 октября, 13:27 - 14:06 UTC:** Рабочие места машин ждали дольше, чем обычно, потому что мы не могли приобрести достаточное количество виртуальных машин у нашего облачного провайдера. ** 7 октября 14:24 до 15:21 UTC:** Некоторые рабочие места потерпели неудачу из-за ошибки инфраструктуры, и рабочие процессы были отложены. Сервис, который дает каждой работе свою конфигурацию при запуске, исчерпал память и перезапустился. ** 7 октября 18:49 до 20:05 UTC:** Рабочие места Docker Gen 2 ждали дольше, чем обычно, потому что мы не могли получить достаточно экземпляров от нашего облачного провайдера. ** 8 октября с 12:48 до 16:00 UTC:** Рабочие места Linux и удаленные рабочие места Docker ждали до 50 минут. У нашего облачного провайдера не было достаточного количества запрашиваемых типов экземпляров, а дефект в логике выбора другого типа экземпляров не позволял нам использовать альтернативы. Работы, которые ждали во время этих инцидентов, были отложены, а не потеряны. Клиенты, чьи рабочие места потерпели неудачу с ошибкой инфраструктуры во время инцидента 7 октября с 14:24 до 15:21 UTC, могут повторно запустить их. Оригинальные страницы статуса можно найти ниже: * [1 октября - Задержки с началом работы докера поколения 2] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 октября - Задержка в запуске машинных заданий] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 октября - Повышенный уровень инфра-сбоев на рабочих местах клиентов] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 октября - Увеличение времени ожидания задачи для Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 октября - Повышенное время ожидания работы машины] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** Справочная информация** Каждая работа, выполняемая на CircleCI, требует вычислений. Откуда берется этот вычислитель, зависит от исполнителя. Задания Docker работают на кластерах серверов, которые планируют работу на флоте экземпляров. Планировщик - это программное обеспечение на тех серверах, которое решает, какой экземпляр выполняет каждую работу. Рабочие места в Gen 2 Docker работали на одном из таких кластеров во время инцидента 1 октября. Работа Докера поколения 1 распределена по нескольким кластерам. Машинные задания, включая удаленные задания Docker, получают выделенную виртуальную машину. Удаленная работа Docker обрабатывается как работа машины Linux от подачи до предоставления. Наша служба предоставления машин запрашивает каждую машину у нашего облачного провайдера в одном из двух регионов, которые мы обычно используем для работы машин. Когда поставщик не может предоставить запрашиваемый нами тип экземпляра, услуга возвращается: он запрашивает другой тип экземпляра или другой регион из списка, который мы поддерживаем. Работа ждет, пока машина будет доступна. Когда какая-либо работа начинается, она запрашивает услугу настройки работы для своей конфигурации. Этот сервис работает как набор блоков, которые являются небольшими копиями одной и той же программы. Если слишком много стручков останавливается, оставшиеся стручки несут больше нагрузки, и рабочие места не могут начаться, пока служба не восстановится. Эти пути зависят от трех видов пропускной способности: пропускной способности наших систем планирования, поставки экземпляров от нашего облачного провайдера, а также памяти и количества копий сервисов, которые запускают рабочие места. Недостаток в любой из них заставляет работу ждать или терпеть неудачу. ##**Что случилось** Все времена UTC ###**Октябрь 1: Работа Docker Gen 2 откладывается до 30 минут** В 07:44 активность дисков на серверах, которые планируют работу в Gen 2 Docker, выросла до 90% емкости и осталась там. В 07:57 число рабочих мест Докера, ожидающих начала, начало расти, и время ожидания выросло вместе с ним. Автоматическое оповещение о вызове инженера в 08:08. Мы объявили об инциденте в 08:42. В 08:43 инженеры определили высокую задержку диска на серверах планирования. Сначала они полагали, что диски слишком медленные для загрузки, поэтому они подготовили изменение на более быстрый тип диска. В 09:01 команда согласовала два рабочих потока: переместить серверы на более быстрые диски и добавить второй кластер Gen 2, чтобы рабочие места разделились на два кластера. В 09:41 инженеры нашли первопричину. Каждый сервер планирования имеет быстрые диски, подключенные непосредственно к нему, и планировщик предназначен для хранения своих рабочих данных. Эти серверы работают на защищенном изображении операционной системы, и на этом изображении не используются быстрые диски. Вместо этого планировщик записывал свои данные на более медленные сетевые диски. Сценарий, настраивающий быстрые диски, вышел из строя без ошибки, а пробел в регистрации на этих серверах скрыл сбой. Движение 2-го поколения также становилось все более оживленным. Более медленные диски насыщались во время этих всплесков, и планировщик отставал. Время ожидания достигло пика в 09:54, когда рабочие места в классе средних ресурсов Gen 2 ждали до 30 минут. В 09:55 инженеры применили исправление, которое правильно настроило быстрые диски. В 10:11 планировщик начал быстрее размещать рабочие места, что подтвердило, что серверы могут идти в ногу с новыми рабочими местами. Время ожидания для среднего поколения 2 упало до 13 минут в 10:14, 7 минут в 10:17 и 1 минуты 30 секунд в 10:20. Мы перенесли страницу статуса на мониторинг в 10:24 и разрешили инцидент в 10:45. В 11:20 второй кластер Gen 2 начал работать. ### ** 7 октября, с 13:27 до 14:06: Повышенное время ожидания для машинных рабочих мест ** Мы объявили об инциденте в 13:27 после того, как увидели увеличенные очереди и время ожидания. Мы разместили на странице статуса в 13:31. В 13:31 инженеры увидели, что мы изо всех сил пытаемся приобрести виртуальные машины для машинных заданий, и что число рабочих мест, ожидающих начала, было высоким в основном для машинных заданий. В 13:34 время ожидания было увеличено. В 13:48 время ожидания начало восстанавливаться, когда стало доступно больше машин, и мы разрешили инцидент в 14:06. ### ** 7 октября, с 14:24 до 15:21: сбои в работе и задержки рабочего процесса** Вскоре после того, как предыдущий инцидент был отмечен как урегулированный, мы объявили о новом инциденте в 14:24 из-за резкого сокращения числа рабочих мест, представленных нашим системам исполнения. В 14:26 инженеры увидели, что стручки службы конфигурации работы перезапускаются. Подвески, которые перезагружаются, оставляют меньше копий сервиса для ответа на запросы, а рабочие места, которые не смогли восстановить свою конфигурацию после повторных попыток, потерпели неудачу с ошибкой инфраструктуры. Рабочие процессы, которые уже работали, ждали обновлений от рабочих мест, которые еще не начались. В 14:35 инженеры увеличили объем доступной памяти стручкам и увеличили количество стручков, что дало сервису больше копий для совместного использования нагрузки. Мы также увеличили объем доступной памяти, и количество сообщений, проходящих через нашу систему рабочего процесса, вернулось к нормальному уровню. В 14:44 мы перенесли страницу статуса на мониторинг. Подушки в службе настройки работы достигли пределов памяти и перезапустились. Мы увеличили выделение памяти и количество капсул, и сервис восстановился. В 15:13 мы увеличили количество случаев в наших кластерах докеров 2-го поколения, чтобы мы могли быстро справиться с отставанием в ожидании работы. Мы разрешили инцидент в 15:21. ### ** 7 октября, 18:49 до 20:05: Повышенное время ожидания для рабочих мест Docker Gen 2** Мы объявили о новом инциденте в 18:49 после того, как время ожидания Docker Gen 2 выросло. В 18:51 инженеры подтвердили, что нехватка доступных экземпляров не позволила нам приобрести достаточное их количество, что увеличило время ожидания. Время ожидания отличалось по размеру ресурсного класса. В 19:52 среднее время ожидания было ниже, чем за час до того, как стало доступно больше емкости, хотя короткие всплески продолжались, и мы переместили страницу статуса для мониторинга. Мы разрешили инцидент в 20:05. 8 октября: Машина Linux и удаленные рабочие места Docker ждут до 50 минут Мы объявили об инциденте в 12:48 после того, как увидели большое количество рабочих мест, ожидающих начала, и долгое время ожидания для машинных и удаленных рабочих мест Docker. В 12:49 инженеры увидели, что наш облачный провайдер не может предоставить достаточно экземпляров. Задержки продолжали расти по мере нашего расследования. В 13:13 мы начали изучать логику, которая выбирает другой тип экземпляра или область, когда наш первый выбор недоступен. В 13:24 мы заподозрили, что дефект в этой логике мешает нам использовать другие типы экземпляров в нашем первичном регионе, поэтому мы отключили наш запасной регион и подтвердили причину дефекта. Инженеры начали работать над исправлением и развернули его в 14:49. Сервис начал запрашивать другие типы экземпляров и запускал машины в большом количестве. В 14:58 очередь рабочих мест в ожидании машины неуклонно падала. Среднее время ожидания в классах ресурсов продолжало падать в течение следующего часа, когда мы работали над отставанием в ожидании. В 16:00 очередь рабочих мест в ожидании машины очистилась и количество рабочих мест в ожидании вернулось к норме. Мы перенесли страницу статуса на мониторинг в 16:09 и разрешили инцидент в 16:35. ##** Предотвращение и улучшение процессов в будущем** Мы предпринимаем следующие шаги для повышения устойчивости времени начала работы, включая диверсификацию поставок, логику резервного копирования и раннее обнаружение. ** Мы расширяем наши вычислительные области.** В инцидентах 7 и 8 октября наш облачный провайдер не смог предоставить достаточное количество экземпляров в регионах, которые мы использовали. Мы добавляем новые регионы в нашу резервную логику, чтобы справиться с пиками спроса, которые опережают наши предпочтительные регионы. ** Мы фиксируем логику, которая выбирает другой тип экземпляра.** 8 октября неисправность механической службы не позволила использовать другие типы экземпляров в том же регионе. Мы внедрили исправление во время инцидента и сейчас пересматриваем и рефакторизируем эту логику в целом с помощью тестов, так что нехватка одного типа экземпляров переходит в другой. Мы расширяем типы экземпляров, которые мы предлагаем, и обеспечиваем дополнительную емкость. Мы работаем с нашим облачным провайдером, чтобы зарезервировать дополнительные мощности в наших существующих регионах, и мы добавляем типы экземпляров, на которых могут работать рабочие места. Спрос на высокопроизводительные вычисления в отрасли растет. Мы диверсифицируем, где и как мы добываем мощности, чтобы наши клиенты были изолированы от изменений поставок. Мы добавили второй кластер докеров поколения 2, поэтому всплески трафика распределяются по двум кластерам. Мы также добавляем оповещения о планировании насыщения серверного диска и о том, как быстро планировщик размещает рабочие места, и оповещение, которое включается, когда сервер запускается без использования его быстрых дисков. Мы сделали так, что скрипт настройки диска вышел из строя с ошибкой, и мы восстановили доставку журналов с этих серверов, чтобы подобная проблема была видна раньше. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за их терпение, в то время как наша команда работала над разрешением этих инцидентов. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 7 октября 2026 г. в 13:40 UTCinvestigating

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

2. 7 октября 2026 г. в 13:52 UTCmonitoring

   Мы видим признаки восстановления и следим за ситуацией.

3. 7 октября 2026 г. в 14:06 UTCresolved

   Инцидент был урегулирован. Спасибо за ваше терпение

4. 8 октября 2026 г. в 17:55 UTCpostmortem

   ## ** Резюме** С 1 по 8 октября 2026 года клиенты CircleCI пережили пять отдельных инцидентов, в которых рабочие места ждали дольше, чем обычно, чтобы начать или не смогли начать. Три инцидента были вызваны ограниченной доступностью экземпляров от нашего облачного провайдера. Одна была вызвана проблемой конфигурации в нашей инфраструктуре планирования, а другая — ограничениями памяти на внутреннюю службу, которые мы подняли во время инцидента. 1 октября с 07:57 до 10:24 UTC: ** Работа Docker Gen 2 ждала до 30 минут для начала. Проблема конфигурации помешала серверам планирования Gen 2 использовать свои высокопроизводительные локальные диски. Во время всплеска трафика резервные диски насыщались, а трудоустройство замедлялось. ** 7 октября, 13:27 - 14:06 UTC:** Рабочие места машин ждали дольше, чем обычно, потому что мы не могли приобрести достаточное количество виртуальных машин у нашего облачного провайдера. ** 7 октября 14:24 до 15:21 UTC:** Некоторые рабочие места потерпели неудачу из-за ошибки инфраструктуры, и рабочие процессы были отложены. Сервис, который дает каждой работе свою конфигурацию при запуске, исчерпал память и перезапустился. ** 7 октября 18:49 до 20:05 UTC:** Рабочие места Docker Gen 2 ждали дольше, чем обычно, потому что мы не могли получить достаточно экземпляров от нашего облачного провайдера. ** 8 октября с 12:48 до 16:00 UTC:** Рабочие места Linux и удаленные рабочие места Docker ждали до 50 минут. У нашего облачного провайдера не было достаточного количества запрашиваемых типов экземпляров, а дефект в логике выбора другого типа экземпляров не позволял нам использовать альтернативы. Работы, которые ждали во время этих инцидентов, были отложены, а не потеряны. Клиенты, чьи рабочие места потерпели неудачу с ошибкой инфраструктуры во время инцидента 7 октября с 14:24 до 15:21 UTC, могут повторно запустить их. Оригинальные страницы статуса можно найти ниже: * [1 октября - Задержки с началом работы докера поколения 2] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 октября - Задержка в запуске машинных заданий] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 октября - Повышенный уровень инфра-сбоев на рабочих местах клиентов] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 октября - Увеличение времени ожидания задачи для Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 октября - Повышенное время ожидания работы машины] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** Справочная информация** Каждая работа, выполняемая на CircleCI, требует вычислений. Откуда берется этот вычислитель, зависит от исполнителя. Задания Docker работают на кластерах серверов, которые планируют работу на флоте экземпляров. Планировщик - это программное обеспечение на тех серверах, которое решает, какой экземпляр выполняет каждую работу. Рабочие места в Gen 2 Docker работали на одном из таких кластеров во время инцидента 1 октября. Работа Докера поколения 1 распределена по нескольким кластерам. Машинные задания, включая удаленные задания Docker, получают выделенную виртуальную машину. Удаленная работа Docker обрабатывается как работа машины Linux от подачи до предоставления. Наша служба предоставления машин запрашивает каждую машину у нашего облачного провайдера в одном из двух регионов, которые мы обычно используем для работы машин. Когда поставщик не может предоставить запрашиваемый нами тип экземпляра, услуга возвращается: он запрашивает другой тип экземпляра или другой регион из списка, который мы поддерживаем. Работа ждет, пока машина будет доступна. Когда какая-либо работа начинается, она запрашивает услугу настройки работы для своей конфигурации. Этот сервис работает как набор блоков, которые являются небольшими копиями одной и той же программы. Если слишком много стручков останавливается, оставшиеся стручки несут больше нагрузки, и рабочие места не могут начаться, пока служба не восстановится. Эти пути зависят от трех видов пропускной способности: пропускной способности наших систем планирования, поставки экземпляров от нашего облачного провайдера, а также памяти и количества копий сервисов, которые запускают рабочие места. Недостаток в любой из них заставляет работу ждать или терпеть неудачу. ##**Что случилось** Все времена UTC ###**Октябрь 1: Работа Docker Gen 2 откладывается до 30 минут** В 07:44 активность дисков на серверах, которые планируют работу в Gen 2 Docker, выросла до 90% емкости и осталась там. В 07:57 число рабочих мест Докера, ожидающих начала, начало расти, и время ожидания выросло вместе с ним. Автоматическое оповещение о вызове инженера в 08:08. Мы объявили об инциденте в 08:42. В 08:43 инженеры определили высокую задержку диска на серверах планирования. Сначала они полагали, что диски слишком медленные для загрузки, поэтому они подготовили изменение на более быстрый тип диска. В 09:01 команда согласовала два рабочих потока: переместить серверы на более быстрые диски и добавить второй кластер Gen 2, чтобы рабочие места разделились на два кластера. В 09:41 инженеры нашли первопричину. Каждый сервер планирования имеет быстрые диски, подключенные непосредственно к нему, и планировщик предназначен для хранения своих рабочих данных. Эти серверы работают на защищенном изображении операционной системы, и на этом изображении не используются быстрые диски. Вместо этого планировщик записывал свои данные на более медленные сетевые диски. Сценарий, настраивающий быстрые диски, вышел из строя без ошибки, а пробел в регистрации на этих серверах скрыл сбой. Движение 2-го поколения также становилось все более оживленным. Более медленные диски насыщались во время этих всплесков, и планировщик отставал. Время ожидания достигло пика в 09:54, когда рабочие места в классе средних ресурсов Gen 2 ждали до 30 минут. В 09:55 инженеры применили исправление, которое правильно настроило быстрые диски. В 10:11 планировщик начал быстрее размещать рабочие места, что подтвердило, что серверы могут идти в ногу с новыми рабочими местами. Время ожидания для среднего поколения 2 упало до 13 минут в 10:14, 7 минут в 10:17 и 1 минуты 30 секунд в 10:20. Мы перенесли страницу статуса на мониторинг в 10:24 и разрешили инцидент в 10:45. В 11:20 второй кластер Gen 2 начал работать. ### ** 7 октября, с 13:27 до 14:06: Повышенное время ожидания для машинных рабочих мест ** Мы объявили об инциденте в 13:27 после того, как увидели увеличенные очереди и время ожидания. Мы разместили на странице статуса в 13:31. В 13:31 инженеры увидели, что мы изо всех сил пытаемся приобрести виртуальные машины для машинных заданий, и что число рабочих мест, ожидающих начала, было высоким в основном для машинных заданий. В 13:34 время ожидания было увеличено. В 13:48 время ожидания начало восстанавливаться, когда стало доступно больше машин, и мы разрешили инцидент в 14:06. ### ** 7 октября, с 14:24 до 15:21: сбои в работе и задержки рабочего процесса** Вскоре после того, как предыдущий инцидент был отмечен как урегулированный, мы объявили о новом инциденте в 14:24 из-за резкого сокращения числа рабочих мест, представленных нашим системам исполнения. В 14:26 инженеры увидели, что стручки службы конфигурации работы перезапускаются. Подвески, которые перезагружаются, оставляют меньше копий сервиса для ответа на запросы, а рабочие места, которые не смогли восстановить свою конфигурацию после повторных попыток, потерпели неудачу с ошибкой инфраструктуры. Рабочие процессы, которые уже работали, ждали обновлений от рабочих мест, которые еще не начались. В 14:35 инженеры увеличили объем доступной памяти стручкам и увеличили количество стручков, что дало сервису больше копий для совместного использования нагрузки. Мы также увеличили объем доступной памяти, и количество сообщений, проходящих через нашу систему рабочего процесса, вернулось к нормальному уровню. В 14:44 мы перенесли страницу статуса на мониторинг. Подушки в службе настройки работы достигли пределов памяти и перезапустились. Мы увеличили выделение памяти и количество капсул, и сервис восстановился. В 15:13 мы увеличили количество случаев в наших кластерах докеров 2-го поколения, чтобы мы могли быстро справиться с отставанием в ожидании работы. Мы разрешили инцидент в 15:21. ### ** 7 октября, 18:49 до 20:05: Повышенное время ожидания для рабочих мест Docker Gen 2** Мы объявили о новом инциденте в 18:49 после того, как время ожидания Docker Gen 2 выросло. В 18:51 инженеры подтвердили, что нехватка доступных экземпляров не позволила нам приобрести достаточное их количество, что увеличило время ожидания. Время ожидания отличалось по размеру ресурсного класса. В 19:52 среднее время ожидания было ниже, чем за час до того, как стало доступно больше емкости, хотя короткие всплески продолжались, и мы переместили страницу статуса для мониторинга. Мы разрешили инцидент в 20:05. 8 октября: Машина Linux и удаленные рабочие места Docker ждут до 50 минут Мы объявили об инциденте в 12:48 после того, как увидели большое количество рабочих мест, ожидающих начала, и долгое время ожидания для машинных и удаленных рабочих мест Docker. В 12:49 инженеры увидели, что наш облачный провайдер не может предоставить достаточно экземпляров. Задержки продолжали расти по мере нашего расследования. В 13:13 мы начали изучать логику, которая выбирает другой тип экземпляра или область, когда наш первый выбор недоступен. В 13:24 мы заподозрили, что дефект в этой логике мешает нам использовать другие типы экземпляров в нашем первичном регионе, поэтому мы отключили наш запасной регион и подтвердили причину дефекта. Инженеры начали работать над исправлением и развернули его в 14:49. Сервис начал запрашивать другие типы экземпляров и запускал машины в большом количестве. В 14:58 очередь рабочих мест в ожидании машины неуклонно падала. Среднее время ожидания в классах ресурсов продолжало падать в течение следующего часа, когда мы работали над отставанием в ожидании. В 16:00 очередь рабочих мест в ожидании машины очистилась и количество рабочих мест в ожидании вернулось к норме. Мы перенесли страницу статуса на мониторинг в 16:09 и разрешили инцидент в 16:35. ##** Предотвращение и улучшение процессов в будущем** Мы предпринимаем следующие шаги для повышения устойчивости времени начала работы, включая диверсификацию поставок, логику резервного копирования и раннее обнаружение. ** Мы расширяем наши вычислительные области.** В инцидентах 7 и 8 октября наш облачный провайдер не смог предоставить достаточное количество экземпляров в регионах, которые мы использовали. Мы добавляем новые регионы в нашу резервную логику, чтобы справиться с пиками спроса, которые опережают наши предпочтительные регионы. ** Мы фиксируем логику, которая выбирает другой тип экземпляра.** 8 октября неисправность механической службы не позволила использовать другие типы экземпляров в том же регионе. Мы внедрили исправление во время инцидента и сейчас пересматриваем и рефакторизируем эту логику в целом с помощью тестов, так что нехватка одного типа экземпляров переходит в другой. Мы расширяем типы экземпляров, которые мы предлагаем, и обеспечиваем дополнительную емкость. Мы работаем с нашим облачным провайдером, чтобы зарезервировать дополнительные мощности в наших существующих регионах, и мы добавляем типы экземпляров, на которых могут работать рабочие места. Спрос на высокопроизводительные вычисления в отрасли растет. Мы диверсифицируем, где и как мы добываем мощности, чтобы наши клиенты были изолированы от изменений поставок. Мы добавили второй кластер докеров поколения 2, поэтому всплески трафика распределяются по двум кластерам. Мы также добавляем оповещения о планировании насыщения серверного диска и о том, как быстро планировщик размещает рабочие места, и оповещение, которое включается, когда сервер запускается без использования его быстрых дисков. Мы сделали так, что скрипт настройки диска вышел из строя с ошибкой, и мы восстановили доставку журналов с этих серверов, чтобы подобная проблема была видна раньше. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за их терпение, в то время как наша команда работала над разрешением этих инцидентов. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 6 октября 2026 г. в 16:00 UTCinvestigating

   Что повлияло Клиенты, использующие конвейеры и рабочие процессы CircleCI, включая отображение данных пользовательского интерфейса, исходящие уведомления и исходящие веб-хуки. Чего можно ожидать Задержки в создании трубопроводов и в рабочих процессах и начале работы. Работа, рабочий процесс и данные конвейера могут занять до 15 минут, чтобы появиться в пользовательском интерфейсе. Отходящие уведомления и веб-хуки задерживаются до 1 минуты. Следующее обновление Мы предоставим еще одно обновление в течение 30 минут или по мере получения дополнительной информации.

2. 6 октября 2026 г. в 16:10 UTCinvestigating

   Начиная с 15:47 UTC, клиенты могут также видеть неудачные рабочие места, в дополнение к задержкам, о которых сообщалось ранее. Наши инженеры продолжают исследовать и смягчать проблему.

3. 6 октября 2026 г. в 16:31 UTCidentified

   По состоянию на 16:02 UTC трубопроводы полностью выходят из строя, поэтому никаких новых рабочих процессов или рабочих мест на данный момент не происходит. Это в дополнение к задержкам и неудачным рабочим местам, о которых сообщалось ранее. Наши инженеры продолжают работать над смягчением проблемы, и мы поделимся дополнительной информацией, как только она появится.

4. 6 октября 2026 г. в 16:42 UTCidentified

   По состоянию на 16:39 UTC мы начинаем наблюдать восстановление новых трубопроводов и рабочих процессов, и рабочие места снова начинают работать. Наши инженеры продолжают работать над восстановлением и поделятся дополнительной информацией, как только она появится.

5. 6 октября 2026 г. в 17:21 UTCidentified

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

6. 6 октября 2026 г. в 18:04 UTCidentified

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

7. 6 октября 2026 г. в 18:55 UTCidentified

   Клиенты продолжают испытывать более длительные, чем обычно, задержки до начала рабочего процесса и работы, в некоторых случаях до 30 минут. Это улучшилось по сравнению с предыдущим инцидентом, но задержки остаются. Улучшились задержки в исходящих уведомлениях. Мы благодарим вас за терпение, пока наши инженеры продолжают работать над восстановлением нормального времени начала работы. Мы поделимся еще одним обновлением в течение следующих 30 минут или раньше, если появится дополнительная информация.

8. 6 октября 2026 г. в 19:16 UTCidentified

   Клиенты продолжают испытывать задержки. Большинство из них начинаются примерно через 20 минут, улучшившись примерно за 40 минут до инцидента. Очень небольшое количество рабочих процессов могло подождать более 1 часа. Наши инженеры внесли изменения, которые улучшили стабильность обслуживания, а оставшаяся задержка связана с отставанием в работе, которое накопилось во время инцидента. Отставание сокращается, и мы сосредоточены на его более быстрой очистке. Мы будем делиться дополнительной информацией по мере продвижения вперед. Мы благодарим вас за терпение, пока наши инженеры работают над отставанием. Мы поделимся еще одним обновлением в течение следующих 30 минут или раньше, если появится дополнительная информация.

9. 6 октября 2026 г. в 19:51 UTCidentified

   Задержки на начало рабочих процессов и рабочих мест продолжают сокращаться. Большинство из них начинаются примерно через 10 минут, улучшившись примерно за 40 минут до инцидента. Очень небольшое количество рабочих процессов могло подождать более 1 часа. Если ваша работа не началась, пожалуйста, повторите работу. Улучшились задержки в исходящих уведомлениях. Оставшаяся задержка связана с отставанием в работе, которое накопилось во время инцидента, и это отставание сократилось более чем наполовину. Мы ожидаем, что отставание будет устранено примерно через 15 минут. Мы поделимся еще одним обновлением после его очистки или в течение следующих 30 минут.

10. 6 октября 2026 г. в 20:13 UTCidentified

    Задержка в работе была устранена, и рабочие процессы начинаются снова без задержек в уведомлениях. Тем не менее, клиенты, использующие Docker и Linux в нескольких классах ресурсов, включая средний, большой и 2xlarge gen2, теперь могут видеть рабочие места, ожидающие в очереди в течение нескольких минут, прежде чем они начнут. Наши инженеры продолжают работу по смягчению этой проблемы. Если ваша работа не началась, пожалуйста, повторите работу. Мы благодарим вас за терпение, пока наши инженеры работают над этим. Мы поделимся еще одним обновлением в течение следующих 30 минут или раньше, если появится дополнительная информация.

11. 6 октября 2026 г. в 20:31 UTCmonitoring

    Рабочие процессы и рабочие места начинаются нормально, и время ожидания рабочих мест Docker и Linux вернулось к норме. Наши инженеры продолжают следить за этим вопросом. Если ваша работа не началась, пожалуйста, повторите работу. Мы благодарим вас за терпение, пока наши инженеры работают над этим. Мы поделимся еще одним обновлением в течение следующих 30 минут или раньше, если появится дополнительная информация.

12. 6 октября 2026 г. в 21:18 UTCresolved

    Между 15:30 UTC и 20:30 UTC 6 октября 2026 года клиенты испытывали задержки и сбои, влияющие на трубопроводы, рабочие процессы и рабочие места. Примерно с 16:02 до 16:39 UTC трубопроводы вышли из строя, и новые рабочие процессы или рабочие места не могли начаться. После возобновления работы рабочие процессы и рабочие места продолжались с задержками до 20:00 UTC. Время начала работы в среднем составляло около 40 минут на пике, и очень небольшое количество рабочих процессов ждало более 1 часа. Отходящие уведомления и веб-хуки также задерживались примерно до 19:00 UTC, обычно примерно на минуту. По мере устранения отставания в работе, вызванное этим увеличение спроса оказало давление на нашу производительность, что привело к дальнейшим задержкам в работе с Docker и Linux. Примерно с 19:45 до 20:30 до начала работы эти рабочие места ждали в очереди дольше, чем обычно. На пике, около 20:05 UTC, ожидания достигали примерно 8 минут для 2xlarge gen2, 6 минут для xlarge gen2 и менее 5 минут для нескольких других классов ресурсов. Проблема решена, и вся затронутая функциональность вернулась в норму. Клиенты, чья работа потерпела неудачу во время этого окна, могут возобновить работу. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

13. 7 октября 2026 г. в 22:08 UTCpostmortem

    ## Summary On October 6, 2026, from 15:30 to 20:30 UTC, CircleCI customers experienced delays creating pipelines and starting workflows and jobs. From 15:48 to 16:38 UTC, no workflows or jobs started, and pipelines triggered from 16:02 UTC failed. Shorter, intermittent delays began earlier, at 13:30 UTC. Data in the CircleCI UI, notifications, and commit status updates to version control providers were also delayed. The incident started in the database behind our workflow orchestration service, which coordinates every pipeline, workflow and job on CircleCI. Routine maintenance on the database's largest tables wrote transaction logs faster than the database could archive them, and the logs filled the storage volume set aside for them. To keep the database from becoming read-only, our engineers moved the logs to the database's main storage volume. That move took the database offline for 50 minutes. When the database came back, it processed work at about half its normal rate until our engineers changed a database setting at 18:19 UTC. We then worked through the backlog, and job start times returned to normal by 20:30 UTC. Customers whose jobs failed during this window may rerun them. The original status page can be found [here](https://status.circleci.com/incidents/z4hbq8h49j8c). ## Background When you trigger a pipeline, CircleCI hands it to a workflow orchestration service. That service tracks the state of every workflow and job, decides when each job is ready to run, and passes ready jobs to our execution fleet. It also drives the job data you see in the UI and the notifications and commit statuses we send when work finishes. The orchestration service stores its state in a database. The database writes every change to a transaction log before applying it, and it keeps those logs on a dedicated storage volume. It archives the logs continuously so it can reuse that space. If archiving falls behind and the volume fills, the database stops accepting writes, and no new work can move forward. The database also runs a periodic maintenance process \(autovacuums\) on each table to keep its internal records valid over time. On a very large table, this process reads every page of the table and writes a large volume of transaction logs. ## What Happened _\(All times UTC\)_ From 10:02 on October 6, our monitoring raised short-lived alerts about errors in the orchestration service. Each alert cleared on its own within about 15 minutes. Our engineers had seen similar brief alerts before, and the system showed no other signs of stress, so they followed the runbook each time, and each alert cleared on its own partway through and also started work to make the alerts less sensitive. Around 12:40, along with the regular workload which generates its own transaction logs, the maintenance process on several of the database's largest tables began writing additional transaction logs faster than the database could archive them, and the log volume started to fill. At 13:30, the orchestration service began to slow down. Through 15:30, some pipelines and jobs took longer to start, in short bursts. At 13:35, our monitoring alerted again, this time alongside related alerts from several other services. Infrastructure Engineers followed the alert runbooks, clearing up some of the alerts. The alerts returned again at around 14:30 and after investigating further, we declared an incident at 14:54. We should have recognized the combination of alerts sooner, and we have covered how we are fixing that below. After declaring the incident, our engineers traced the slowdown to the maintenance process \(anti-wraparound autovacuum\). The database restarts this process automatically if it is cancelled, so our engineers changed its settings to help it finish faster. By 15:30, the delays were continuous, and some jobs began to fail. At 15:43, the transaction log volume was close to full. If it filled, the database would stop accepting writes and no work could run. Our engineers decided to move the transaction logs onto the database's main storage volume, which had plenty of free space. The move required the database to go offline, and we could not predict in advance how long that would take. The move started at 15:47. From 15:48 to 16:38, the orchestration service could not process any work. Customers could still trigger pipelines, but no workflows or jobs started, and from 16:02 newly triggered pipelines failed. We posted to our status page at 15:58 and raised it to a major outage at 16:20. While the database was offline, our engineers prepared a replacement database as a fallback. The original database came back first, so we kept it in service. At 16:38, the database came back online and work started flowing again. With transaction logs and regular data now sharing the same storage, the database ran more slowly than before. From 16:38 to 18:19, the orchestration service processed work at about half its normal rate, and jobs waited tens of minutes to start, up to about 50 minutes at the longest. During that time, the database had to finish archiving its backlog of transaction logs before we could move them back to a dedicated volume. We also investigated and implemented several database parameter changes to stop further maintenance runs from starting and prepared ways to reduce the work reaching the service. Along with the replacement database, we also prepared a complete stack of the service during that time so that we could move to it at the risk of data loss and opted against that move. At 18:19, our engineers changed a database setting to cut the time each write spent waiting on storage. Processing speed recovered, and the backlog began to clear. To clear it faster, we added database and server capacity to the systems that hand jobs to our execution fleet. By about 19:55, new jobs were again starting on time. The backlog then reached our execution fleet. From 19:49 to 20:30, some Docker jobs on larger resource classes waited up to about 10 minutes to start while capacity scaled up. By 20:30, job start times were back to normal. We moved the status page to monitoring at 20:32 and resolved the incident at 21:19. About 3,500 jobs failed to start during the incident. Customers may rerun these jobs. We found no evidence that CircleCI ran any job more than once. Customers who reran a workflow while the original run was still delayed may have seen both runs complete. Annual plan customers can work with their account team to review usage. ## Future Prevention and Process Improvement We are taking the following steps to prevent a recurrence and improve our response time: **We are adding alerts on the conditions that caused this incident.** Our monitoring caught the slowdown, but we had no alert on how full the transaction log volume was or on how far archiving had fallen behind. We are adding alerts on both, along with alerts on the database maintenance that drives them, so we can act earlier. We are also revisiting all our alerts to ensure noisy or sensitive alerts don’t hide real issues. **We are tuning how maintenance process \(autovacuum\) runs on our database.** We are looking at the frequency and the aggressiveness with which the autovacuums run on our database. We are also tracking the size of these tables over time so they stay within safe limits. **We are removing the single transaction log bottleneck.** All of the orchestration service's writes currently go through one database and one transaction log, so when that log fell behind, every pipeline, workflow and job slowed down with it. We are evaluating two approaches: splitting the service across multiple database instances, each with its own transaction log, and moving it to a distributed database built to spread writes across many nodes. Either approach would limit the effect of a backlog to part of the workload. **We are making our systems wait for the orchestration service to recover.** During the incident, some jobs failed because our systems gave up after retrying. We are working on changing that behavior. **We are improving our status page updates during long incidents.** Customers told us our early updates did not give enough detail. We are updating our guidance so updates include specific impact and timing sooner. ‌ Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve this incident. Please reach out to our support team with any questions or concerns.

Автоматический перевод официального обновления инцидента.

1. 1 октября 2026 г. в 09:06 UTCinvestigating

   Клиенты могут столкнуться с задержками при запуске Docker Gen 2. Мы работаем над увеличением пропускной способности системы для размещения этого.

2. 1 октября 2026 г. в 09:47 UTCidentified

   Мы определили первопричину и активно работаем над исправлением. Спасибо за ваше терпение.

3. 1 октября 2026 г. в 10:13 UTCidentified

   Было исправлено, и мы начинаем наблюдать восстановление.

4. 1 октября 2026 г. в 10:24 UTCmonitoring

   Мы видим, что время очередей возвращается к нормальному уровню и продолжает контролировать.

5. 1 октября 2026 г. в 10:45 UTCresolved

   Этот инцидент был урегулирован.

6. 9 октября 2026 г. в 22:36 UTCpostmortem

   ## ** Резюме** С 1 по 8 октября 2026 года клиенты CircleCI пережили пять отдельных инцидентов, в которых рабочие места ждали дольше, чем обычно, чтобы начать или не смогли начать. Три инцидента были вызваны ограниченной доступностью экземпляров от нашего облачного провайдера. Одна была вызвана проблемой конфигурации в нашей инфраструктуре планирования, а другая — ограничениями памяти на внутреннюю службу, которые мы подняли во время инцидента. 1 октября с 07:57 до 10:24 UTC: ** Работа Docker Gen 2 ждала до 30 минут для начала. Проблема конфигурации помешала серверам планирования Gen 2 использовать свои высокопроизводительные локальные диски. Во время всплеска трафика резервные диски насыщались, а трудоустройство замедлялось. ** 7 октября, 13:27 - 14:06 UTC:** Рабочие места машин ждали дольше, чем обычно, потому что мы не могли приобрести достаточное количество виртуальных машин у нашего облачного провайдера. ** 7 октября 14:24 до 15:21 UTC:** Некоторые рабочие места потерпели неудачу из-за ошибки инфраструктуры, и рабочие процессы были отложены. Сервис, который дает каждой работе свою конфигурацию при запуске, исчерпал память и перезапустился. ** 7 октября 18:49 до 20:05 UTC:** Рабочие места Docker Gen 2 ждали дольше, чем обычно, потому что мы не могли получить достаточно экземпляров от нашего облачного провайдера. ** 8 октября с 12:48 до 16:00 UTC:** Рабочие места Linux и удаленные рабочие места Docker ждали до 50 минут. У нашего облачного провайдера не было достаточного количества запрашиваемых типов экземпляров, а дефект в логике выбора другого типа экземпляров не позволял нам использовать альтернативы. Работы, которые ждали во время этих инцидентов, были отложены, а не потеряны. Клиенты, чьи рабочие места потерпели неудачу с ошибкой инфраструктуры во время инцидента 7 октября с 14:24 до 15:21 UTC, могут повторно запустить их. Оригинальные страницы статуса можно найти ниже: * [1 октября - Задержки с началом работы докера поколения 2] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 октября - Задержка в запуске машинных заданий] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 октября - Повышенный уровень инфра-сбоев на рабочих местах клиентов] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 октября - Увеличение времени ожидания задачи для Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 октября - Повышенное время ожидания работы машины] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** Справочная информация** Каждая работа, выполняемая на CircleCI, требует вычислений. Откуда берется этот вычислитель, зависит от исполнителя. Задания Docker работают на кластерах серверов, которые планируют работу на флоте экземпляров. Планировщик - это программное обеспечение на тех серверах, которое решает, какой экземпляр выполняет каждую работу. Рабочие места в Gen 2 Docker работали на одном из таких кластеров во время инцидента 1 октября. Работа Докера поколения 1 распределена по нескольким кластерам. Машинные задания, включая удаленные задания Docker, получают выделенную виртуальную машину. Удаленная работа Docker обрабатывается как работа машины Linux от подачи до предоставления. Наша служба предоставления машин запрашивает каждую машину у нашего облачного провайдера в одном из двух регионов, которые мы обычно используем для работы машин. Когда поставщик не может предоставить запрашиваемый нами тип экземпляра, услуга возвращается: он запрашивает другой тип экземпляра или другой регион из списка, который мы поддерживаем. Работа ждет, пока машина будет доступна. Когда какая-либо работа начинается, она запрашивает услугу настройки работы для своей конфигурации. Этот сервис работает как набор блоков, которые являются небольшими копиями одной и той же программы. Если слишком много стручков останавливается, оставшиеся стручки несут больше нагрузки, и рабочие места не могут начаться, пока служба не восстановится. Эти пути зависят от трех видов пропускной способности: пропускной способности наших систем планирования, поставки экземпляров от нашего облачного провайдера, а также памяти и количества копий сервисов, которые запускают рабочие места. Недостаток в любой из них заставляет работу ждать или терпеть неудачу. ##**Что случилось** Все времена UTC ###**Октябрь 1: Работа Docker Gen 2 откладывается до 30 минут** В 07:44 активность дисков на серверах, которые планируют работу в Gen 2 Docker, выросла до 90% емкости и осталась там. В 07:57 число рабочих мест Докера, ожидающих начала, начало расти, и время ожидания выросло вместе с ним. Автоматическое оповещение о вызове инженера в 08:08. Мы объявили об инциденте в 08:42. В 08:43 инженеры определили высокую задержку диска на серверах планирования. Сначала они полагали, что диски слишком медленные для загрузки, поэтому они подготовили изменение на более быстрый тип диска. В 09:01 команда согласовала два рабочих потока: переместить серверы на более быстрые диски и добавить второй кластер Gen 2, чтобы рабочие места разделились на два кластера. В 09:41 инженеры нашли первопричину. Каждый сервер планирования имеет быстрые диски, подключенные непосредственно к нему, и планировщик предназначен для хранения своих рабочих данных. Эти серверы работают на защищенном изображении операционной системы, и на этом изображении не используются быстрые диски. Вместо этого планировщик записывал свои данные на более медленные сетевые диски. Сценарий, настраивающий быстрые диски, вышел из строя без ошибки, а пробел в регистрации на этих серверах скрыл сбой. Движение 2-го поколения также становилось все более оживленным. Более медленные диски насыщались во время этих всплесков, и планировщик отставал. Время ожидания достигло пика в 09:54, когда рабочие места в классе средних ресурсов Gen 2 ждали до 30 минут. В 09:55 инженеры применили исправление, которое правильно настроило быстрые диски. В 10:11 планировщик начал быстрее размещать рабочие места, что подтвердило, что серверы могут идти в ногу с новыми рабочими местами. Время ожидания для среднего поколения 2 упало до 13 минут в 10:14, 7 минут в 10:17 и 1 минуты 30 секунд в 10:20. Мы перенесли страницу статуса на мониторинг в 10:24 и разрешили инцидент в 10:45. В 11:20 второй кластер Gen 2 начал работать. ### ** 7 октября, с 13:27 до 14:06: Повышенное время ожидания для машинных рабочих мест ** Мы объявили об инциденте в 13:27 после того, как увидели увеличенные очереди и время ожидания. Мы разместили на странице статуса в 13:31. В 13:31 инженеры увидели, что мы изо всех сил пытаемся приобрести виртуальные машины для машинных заданий, и что число рабочих мест, ожидающих начала, было высоким в основном для машинных заданий. В 13:34 время ожидания было увеличено. В 13:48 время ожидания начало восстанавливаться, когда стало доступно больше машин, и мы разрешили инцидент в 14:06. ### ** 7 октября, с 14:24 до 15:21: сбои в работе и задержки рабочего процесса** Вскоре после того, как предыдущий инцидент был отмечен как урегулированный, мы объявили о новом инциденте в 14:24 из-за резкого сокращения числа рабочих мест, представленных нашим системам исполнения. В 14:26 инженеры увидели, что стручки службы конфигурации работы перезапускаются. Подвески, которые перезагружаются, оставляют меньше копий сервиса для ответа на запросы, а рабочие места, которые не смогли восстановить свою конфигурацию после повторных попыток, потерпели неудачу с ошибкой инфраструктуры. Рабочие процессы, которые уже работали, ждали обновлений от рабочих мест, которые еще не начались. В 14:35 инженеры увеличили объем доступной памяти стручкам и увеличили количество стручков, что дало сервису больше копий для совместного использования нагрузки. Мы также увеличили объем доступной памяти, и количество сообщений, проходящих через нашу систему рабочего процесса, вернулось к нормальному уровню. В 14:44 мы перенесли страницу статуса на мониторинг. Подушки в службе настройки работы достигли пределов памяти и перезапустились. Мы увеличили выделение памяти и количество капсул, и сервис восстановился. В 15:13 мы увеличили количество случаев в наших кластерах докеров 2-го поколения, чтобы мы могли быстро справиться с отставанием в ожидании работы. Мы разрешили инцидент в 15:21. ### ** 7 октября, 18:49 до 20:05: Повышенное время ожидания для рабочих мест Docker Gen 2** Мы объявили о новом инциденте в 18:49 после того, как время ожидания Docker Gen 2 выросло. В 18:51 инженеры подтвердили, что нехватка доступных экземпляров не позволила нам приобрести достаточное их количество, что увеличило время ожидания. Время ожидания отличалось по размеру ресурсного класса. В 19:52 среднее время ожидания было ниже, чем за час до того, как стало доступно больше емкости, хотя короткие всплески продолжались, и мы переместили страницу статуса для мониторинга. Мы разрешили инцидент в 20:05. 8 октября: Машина Linux и удаленные рабочие места Docker ждут до 50 минут Мы объявили об инциденте в 12:48 после того, как увидели большое количество рабочих мест, ожидающих начала, и долгое время ожидания для машинных и удаленных рабочих мест Docker. В 12:49 инженеры увидели, что наш облачный провайдер не может предоставить достаточно экземпляров. Задержки продолжали расти по мере нашего расследования. В 13:13 мы начали изучать логику, которая выбирает другой тип экземпляра или область, когда наш первый выбор недоступен. В 13:24 мы заподозрили, что дефект в этой логике мешает нам использовать другие типы экземпляров в нашем первичном регионе, поэтому мы отключили наш запасной регион и подтвердили причину дефекта. Инженеры начали работать над исправлением и развернули его в 14:49. Сервис начал запрашивать другие типы экземпляров и запускал машины в большом количестве. В 14:58 очередь рабочих мест в ожидании машины неуклонно падала. Среднее время ожидания в классах ресурсов продолжало падать в течение следующего часа, когда мы работали над отставанием в ожидании. В 16:00 очередь рабочих мест в ожидании машины очистилась и количество рабочих мест в ожидании вернулось к норме. Мы перенесли страницу статуса на мониторинг в 16:09 и разрешили инцидент в 16:35. ##** Предотвращение и улучшение процессов в будущем** Мы предпринимаем следующие шаги для повышения устойчивости времени начала работы, включая диверсификацию поставок, логику резервного копирования и раннее обнаружение. ** Мы расширяем наши вычислительные области.** В инцидентах 7 и 8 октября наш облачный провайдер не смог предоставить достаточное количество экземпляров в регионах, которые мы использовали. Мы добавляем новые регионы в нашу резервную логику, чтобы справиться с пиками спроса, которые опережают наши предпочтительные регионы. ** Мы фиксируем логику, которая выбирает другой тип экземпляра.** 8 октября неисправность механической службы не позволила использовать другие типы экземпляров в том же регионе. Мы внедрили исправление во время инцидента и сейчас пересматриваем и рефакторизируем эту логику в целом с помощью тестов, так что нехватка одного типа экземпляров переходит в другой. Мы расширяем типы экземпляров, которые мы предлагаем, и обеспечиваем дополнительную емкость. Мы работаем с нашим облачным провайдером, чтобы зарезервировать дополнительные мощности в наших существующих регионах, и мы добавляем типы экземпляров, на которых могут работать рабочие места. Спрос на высокопроизводительные вычисления в отрасли растет. Мы диверсифицируем, где и как мы добываем мощности, чтобы наши клиенты были изолированы от изменений поставок. Мы добавили второй кластер докеров поколения 2, поэтому всплески трафика распределяются по двум кластерам. Мы также добавляем оповещения о планировании насыщения серверного диска и о том, как быстро планировщик размещает рабочие места, и оповещение, которое включается, когда сервер запускается без использования его быстрых дисков. Мы сделали так, что скрипт настройки диска вышел из строя с ошибкой, и мы восстановили доставку журналов с этих серверов, чтобы подобная проблема была видна раньше. Опыт работы с клиентами является нашим главным приоритетом, и мы обязуемся постоянно повышать надежность наших систем, чтобы соответствовать доверию, которое наши клиенты оказывают нам. Мы благодарим наших клиентов за их терпение, в то время как наша команда работала над разрешением этих инцидентов. Пожалуйста, обратитесь к нашей команде поддержки с любыми вопросами или проблемами.

Автоматический перевод официального обновления инцидента.

1. 23 сентября 2026 г. в 18:13 UTCidentified

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

2. 23 сентября 2026 г. в 20:06 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 21 сентября 2026 г. в 16:22 UTCinvestigating

   Клиенты могут столкнуться с задержками при запуске работы на Linux Machine. Мы проводим расследование.

2. 21 сентября 2026 г. в 16:48 UTCmonitoring

   Время ожидания задач для Linux Machine возвращается к норме.

3. 21 сентября 2026 г. в 17:09 UTCresolved

   This incident has been resolved.

Автоматический перевод официального обновления инцидента.

1. 16 сентября 2026 г. в 14:55 UTCinvestigating

   Мы расследуем задержку в доступе к данным трубопровода. Трубопроводы все еще работают, но данные о них могут быть отложены в интерфейсе или API.

2. 16 сентября 2026 г. в 15:29 UTCidentified

   Мы определили проблему и работаем над исправлением. Спасибо за ваше терпение.

3. 16 сентября 2026 г. в 17:34 UTCidentified

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

4. 16 сентября 2026 г. в 18:22 UTCmonitoring

   Все данные трубопровода теперь доступны в обычном режиме. Мы продолжим следить за восстановлением.

5. 16 сентября 2026 г. в 19:30 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 15 сентября 2026 г. в 14:42 UTCinvestigating

   В настоящее время мы наблюдаем задержку появления данных в UI.

2. 15 сентября 2026 г. в 15:14 UTCidentified

   Мы начинаем видеть некоторое восстановление.

3. 15 сентября 2026 г. в 17:02 UTCresolved

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

Автоматический перевод официального обновления инцидента.

1. 14 сентября 2026 г. в 11:59 UTCinvestigating

   Из-за возросших сетевых ошибок и задержек мы наблюдаем увеличение времени ожидания работы в macOS. Мы расследуем это с нашим хостинг-провайдером macOS.

2. 14 сентября 2026 г. в 12:36 UTCinvestigating

   Время ожидания работы macOS сокращается, и мы продолжаем расследование.

3. 14 сентября 2026 г. в 12:48 UTCmonitoring

   Наш провайдер хостинга macOS внедрил смягчение последствий, и мы увидели улучшенные задержки. Мы продолжим мониторинг.

4. 14 сентября 2026 г. в 12:59 UTCresolved

   Время ожидания работы macOS возвращается к норме.

Автоматический перевод официального обновления инцидента.

1. 10 сентября 2026 г. в 20:25 UTCidentified

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

2. 10 сентября 2026 г. в 20:25 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

3. 10 сентября 2026 г. в 20:26 UTCresolved

   Этот инцидент был урегулирован. Небольшое число клиентов, которые создали трубопроводы между 18:53 UTC и 19:24 UTC, которые содержали конфигурацию с использованием устаревшего синтаксиса конфигураций, увидят, что их рабочие места не могут начаться. Клиенты, чьи рабочие места или трубопроводы потерпели неудачу, могут возобновить их.

Автоматический перевод официального обновления инцидента.

1. 4 сентября 2026 г. в 15:16 UTCinvestigating

   Мы обнаружили проблемы с сетью, влияющие на нашу инфраструктуру Mac. Мы расследуем и вскоре предоставим обновления. Клиенты могут испытывать очереди в течение этого времени.

2. 4 сентября 2026 г. в 15:43 UTCidentified

   Мы идентифицировали сетевую проблему с нашим поставщиком инфраструктуры Mac и работаем с ними, чтобы решить эту проблему. Мы начинаем видеть некоторое восстановление, но мы ожидаем, что клиенты все еще могут увидеть некоторые очереди. Скоро мы обновимся.

3. 4 сентября 2026 г. в 16:19 UTCmonitoring

   Наш поставщик инфраструктуры Mac исправил эту сетевую проблему, и мы видим, что время в очереди возвращается к норме. Мы будем продолжать следить за вещами еще некоторое время. Скоро мы обновимся.

4. 4 сентября 2026 г. в 16:55 UTCresolved

   Мы не видели дальнейшего влияния на время очередей, и все вернулось в нормальное русло. Мы ценим ваше терпение, пока мы работали над решением и мониторингом этой проблемы.

Автоматический перевод официального обновления инцидента.

1. 26 августа 2026 г. в 15:43 UTCidentified

   Клиенты могут испытывать периодические ошибки при просмотре интерфейсов использования плана или вызове API использования плана. Мы выявили проблему и активно работаем над тем, чтобы смягчить эти ошибки.

2. 26 августа 2026 г. в 16:04 UTCmonitoring

   Мы смягчили проблему с использованием API-интерфейсов, и соответствующие страницы в пользовательском интерфейсе загружаются правильно.

3. 26 августа 2026 г. в 16:10 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 25 августа 2026 г. в 23:20 UTCresolved

   Между 19:49 UTC и 21:07 UTC 25 августа 2026 года клиенты, пытающиеся войти в CircleCI с помощью GitHub, не смогли войти и получили ошибку от GitHub, заявив, что обратный URL-адрес недействителен. Клиенты, которые уже вошли в систему, не пострадали. Проблема решена, и логин GitHub работает нормально. Мы благодарим вас за терпение, пока наша команда работала над внедрением исправления.

Автоматический перевод официального обновления инцидента.

1. 17 августа 2026 г. в 21:06 UTCidentified

   Причина проблемы выявлена, и мы работаем над ее устранением.

2. 17 августа 2026 г. в 21:36 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

3. 17 августа 2026 г. в 21:37 UTCresolved

   Данные Insights снова хороши. Спасибо за ваше терпение.

Автоматический перевод официального обновления инцидента.