Prod2 был временно недоступен
Pending
Затронутые компоненты
Platform
- investigating
В настоящее время мы расследуем этот вопрос.
- resolved
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
88 Harness incidents · март 2026 г. — official updates, affected components, duration and resolution details.
В настоящее время мы расследуем этот вопрос.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
Трубопроводное исполнение застряло в Prod1. Мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
##Резюме В период с 27 по 28 августа 2026 года клиенты столкнулись с проблемой, когда некоторые трубопроводы, развертывания и связанные с ними ресурсы появились как не найденные в интерфейсе Harness и API. Проблема возникла во время запланированного обновления внутренней инфраструктуры, которое повлияло на связь между службами внутренней платформы. В результате запросы, которые зависели от решения по учетным записям, организации и масштабу проекта, не смогли успешно завершиться, что привело к тому, что не найденные ответы были возвращены клиентам для существующих организаций. Инженеры выявили проблему, отменили изменения и восстановили нормальное обслуживание. Данные клиентов не были потеряны или удалены во время инцидента. ##Коренная причина Проблема была вызвана ошибкой конфигурации, введенной во время запланированного обновления внутренней маршрутизации службы в Производстве. Служба внутренней платформы, отвечающая за решение вопросов, связанных с учетной записью, организацией и контекстом проекта, не смогла подтвердить запросы от других служб Harness после того, как было применено изменение. Поскольку этот этап проверки требуется до того, как многие организации прочитают и могут предпринять действия, связанные с трубопроводом, неудавшиеся запросы всплыли на поверхность для клиентов, поскольку не были обнаружены ошибки для ресурсов, которые продолжали существовать нормально. Проблема ограничивалась затронутой производственной средой и решалась путем возврата изменений и восстановления прежнего пути служебной связи. # # Влияние Некоторые клиенты видели, что существующие трубопроводы, развертывания и связанные с ними объекты появляются как не найденные в пользовательском интерфейсе и API. Некоторые операции, связанные с трубопроводом, включая прогрессирование исполнения, запуски с помощью веб-хука, запланированную оценку триггера и листинг организаций, были временно нарушены. Проблема затронула доступность и видимость существующих объектов, но не удалила данные и не изменила конфигурацию клиентов. * Несанкционированного доступа не было, а потери данных клиентов не наблюдалось. ## Восстановление ** Немедленно:** Обновлена конфигурация инфраструктуры и восстановлен ранее работающий сервисный путь связи. *** Валидация восстановления:** Проверено, что затронутые поиски объектов, трубопроводные операции и зависимые API нормально функционировали после отката. ** Постоянная:** Исправлена обработка конфигурации, связанная с обновлением, поэтому подобные проблемы не мешают аутентификации обслуживания в будущих развертываниях. ## Пункты действия Чтобы подобные проблемы не повторились, Харнесс 1. Улучшить валидацию конфигурации за счет улучшения тестов перед развертыванием для проверки внутренней служебной связи до изменения производственного трафика. 2. Улучшить мониторинг и оповещение о сбоях внутренней аутентификации, чтобы проблемы могли быть обнаружены раньше. 3. Улучшить обработку ошибок, чтобы сбои в работе с зависимостями с меньшей вероятностью казались клиентам не найденными ошибками.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем проблему, о которой сообщается в трубопроводах IACM в кластерах Prod-1, Prod-2, Prod-4 и EU1.
Мы продолжаем расследование этого вопроса.
Мы вернули изменения, которые вызвали эту проблему во всех кластерах.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
В настоящее время мы изучаем сообщения о том, что пользовательский интерфейс FME не загружается. Клиенты, пытающиеся получить доступ к консоли FME, могут столкнуться с ошибками или неотзывчивыми страницами. Оценка функционального флага и трафик SDK, как полагают, не затронуты. В ближайшее время последует еще одно обновление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
##Резюме Начиная с 23:42 UTC 23 августа 2026 года, несколько клиентов FME сообщили о сбоях загрузки интерфейса FME. Артефакты FME UI, обслуживаемые из CDN, истекли из-за политики удержания, в результате чего пользовательский интерфейс FME не загружался. Любые изменения запроса флага через API, доставка изменений и конвейер данных продолжали работать без перерывов. ##Коренная причина FME UI обслуживается от CDN. Артефакты пользовательского интерфейса были выселены из-за политики удержания, в результате чего пользовательский интерфейс не загружался для всех пользователей. # # Влияние * Пользовательский интерфейс FME не мог загружаться для всех пользователей во всех производственных средах. ###Что не удалось сделать? * Функциональность SDK и оценка флага времени выполнения * Административные вызовы API * Конфигурация флага клиента * Потеря данных не произошла ## Восстановление FME UI был восстановлен в CDN благодаря развертыванию Восстановление подтверждено во всех производственных средах до закрытия инцидента. ## Пункты действия Улучшить политику хранения активов, чтобы активная версия никогда не подвергалась выселению.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Медлительность может вызвать любой из нижеперечисленных симптомов: Трубопроводы не начинаются - Задержки в исполнении Трубопроводы отменяются из-за тайм-аута
Наш облачный провайдер сталкивается с активным инцидентом, и мы следим за ним.
Мы продолжаем расследование этого вопроса.
Наш облачный провайдер подтвердил текущий инцидент, влияющий на несколько регионов. Трубопроводы Harness не испытывали сбоев в результате, хотя некоторые пользователи могут продолжать испытывать медлительность. Мы внимательно следим за ситуацией и будем предоставлять обновления по мере поступления дополнительной информации.
Мы наблюдаем улучшенные задержки по всем направлениям после исправления, реализованного нашим облачным провайдером. Мы продолжаем внимательно следить за ситуацией и будем предоставлять дальнейшие обновления по мере необходимости. Мы отметили некоторые застрявшие казни для CI для нескольких клиентов, которые мы расследуем
Этот инцидент был урегулирован.
# Резюме 20 августа 2026 года, начиная примерно с 15:00 UTC, платформа Harness испытала повсеместное ухудшение производительности во всех производственных средах. Трубопроводные казни, которые обычно заканчиваются примерно за две минуты, занимали от семи до десяти минут. Повлияли непрерывная доставка, непрерывная интеграция, оркестровка конвейера и управление функциями и экспериментирование. Google Cloud Platform столкнулась с инцидентом с несколькими продуктами в регионе US-west1, затрагивающим Bigtable, Compute Engine, Google Kubernetes Engine и инфраструктуру производства постоянного диска. Деградация увеличила задержку работы базы данных с примерно 2 мс до более 10 мс на 95-м процентиле, что, в свою очередь, вызвало задержку обработки очередей сообщений и распространилось на каждую услугу, которая зависит от своевременного доступа к базе данных. #Влияние Это была деградация, а не сбой. Трубопроводы продолжали успешно выполняться и завершаться; они были медленными, а не неудачными. Никакие данные не были потеряны, и ни одна работа с клиентами не была прекращена в результате этого инцидента. ** Коренная причина** Инфраструктура производства Harness в затронутых средах работает на постоянных дисках Google Cloud Platform в регионе US-west1. Когда этот слой хранения деградировал, эффект распространялся через платформу в предсказуемой цепи: **Постоянная деградация диска ввода/вывода в США-Западе1.** На облачной платформе Google произошел инцидент с несколькими продуктами, влияющими на Bigtable, Compute Engine, Google Kubernetes Engine и постоянную производительность диска. Это был сбой инфраструктуры в среде провайдера, вне контроля Harness. ** Профилактические действия** Harness не может предотвратить сбой инфраструктуры облачного провайдера. Действия, приведенные ниже, направлены на то, чтобы быстрее обнаружить один из них и лучше действовать на него. ** Действие** [править] Продолжить рутинное предварительное тестирование целевых отказов межрегиональной базы данных, как это было сделано во время этого инцидента, чтобы поддерживать готовность к отказу проверенной, а не предполагаемой. Оценить полнофункциональную многорегиональную отказоустойчивость для будущих сценариев, в которых межрегиональная задержка была бы неприемлемой
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
###Резюме 20 августа 2026 года, между 10:24 и 14:55 UTC, подмножество FME пишет неудачно. Письма, сделанные из пользовательского интерфейса FME и записи, сделанные с помощью токенов доступа Harness (PAT и SAT), не были затронуты. Оценка флага времени выполнения продолжала работать нормально. Проблема была смягчена недавним изменением аутентификации в службе общего управления, и затронутые записи вернулись к нормальному состоянию к 14:55 UTC. Статус: [https://status.harness.io/incidents/rhthgm7d5dkz] (https://status.harness.io/incidents/rhthgm7d5dkz) ###Коренная причина Изменение того, как служба совместного управления аутентифицировала входящие звонки, привело к тому, что некоторые записи FME были отклонены. Эти записи использовали учетные данные службы обслуживания, которые служба управления больше не могла проверить после изменения. FME выдает клиенту отказ в управлении как HTTP 499, тот же статус, который используется, когда политика управления намеренно отрицает изменение. Поскольку 499 является действительным, ожидаемым ответом на этот путь отказа, сбои не выглядели как отключение в наших оповещениях, и инцидент был идентифицирован из отчетов клиентов, а не внутреннего обнаружения. ###Воздействие Подмножество записей FME не удалось во время окна, в основном те, которые были сделаны с использованием устаревших ключей API Split или планирования запросов на изменение. * Записи, сделанные из интерфейса FME, не были затронуты. * Записи с использованием токенов доступа Harness \(PATs и SATs\) не были затронуты. Оценка флага времени выполнения продолжалась нормально. * Потеря данных не произошла. Неудачные статьи не применялись. ### Восстановление Возврат к изменению аутентификации служб управления. Пострадавшие писатели немедленно вернулись к нормальной жизни. ### Элементы действия Чтобы подобные проблемы не повторились, Харнесс вернет отчетливую ошибку \(не 499\), когда запись не удается, потому что управление не может быть оценено, поэтому его не путают с преднамеренным отрицанием политики. Добавьте оповещение об оценке управления, а не полагайтесь на код статуса, ориентированный на клиента. * Расширить поддержку аутентификации для оценки политики. * Расширение автоматизированного покрытия для дополнительных сценариев написания.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Мы продолжаем расследование этого вопроса.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
** Резюме** 19 августа 2026 года между 12:35 и 17:29 UTC служба безопасности приложений Harness испытала значительные сбои, влияющие как на консоль, ориентированную на клиента, так и на конвейер приема данных в регионах SaaS Production и US1. **Корневая причина** Служба внутренней настройки, которая обеспечивает настройки времени выполнения почти для каждого другого компонента, перегружена и вступила в повторный цикл перезапуска. Поскольку от него зависит так много сервисов, эффекты были широкими: консольные страницы, такие как политики защиты, просмотры осанки, журналы активности, инвентарь API и пользовательская политика не загружались или не отсчитывались, а обработка вниз по течению застопорилась в ожидании конфигурации, которую она не могла получить. #** Влияние клиента** | **Dimension** | **Detail** [править править код] | Влияние консоли \(UI\) | Несколько страниц не смогли загрузить или отсрочить, включая политики защиты, страницы событий осанки и представления осанки внутри панелей инструментов и страниц прозрения, запросы журнала активности, экраны инвентаря API, пользовательскую политику и просмотры конфиденциальных данных и виджеты. ! Обработка телеметрии безопасности сильно ухудшилась и в некоторых направлениях полностью прекратилась. Потребительское отставание росло на этапах нормализации, группировки, обнаружения аномалий, генерации и связанных с ними этапах обработки. ! Подмножество телеметрии, проглоченной во время сбоя, было навсегда удалено. ! **Смягчение** Несколько промежуточных смягчений дополнительных процессоров и памяти, расслабленные пороги проверки здоровья, перезапуск базы данных и больший пул соединений облегчили проблему. Отключение новой функции в обоих пострадавших регионах резко и надолго восстановило пропускную способность. Инцидент был урегулирован в 17:29 UTC. ** Профилактические действия** Следующие действия совершаются и отслеживаются внутренне до завершения. Функция, которая вызвала этот инцидент, остается отключенной и не будет повторно включена, пока работа ниже не будет завершена и подтверждена. ** Действие** [править] | Оптимизируйте код путем настройки параметров, таких как выселение и удержание кэша, оцените пагинацию на основе курсора для извлечения оптовых правил по мере роста числа правил. Добавить специально построенный индекс базы данных для шаблона доступа к сервис-шопингу Обратная семантика восстановления трубопровода, чтобы потребители безопасно воспроизводили после потери позиционного маркера вместо пропуска отставания | Мандатное поэтапное развертывание для переопределений конфигурации, которые изменяют шаблоны запросов вниз по течению: кластер с низким объемом, затем средний объем, затем большой объем | Добавьте защиту от обратного давления и параллелизма в службу конфигурации: разрыв цепи, ограниченные очереди и изоляция тайм-аута. Улучшить наблюдаемость, используя более подробные метрики
Автоматический перевод официального обновления инцидента.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Мы отслеживаем застрявшие трубопроводы в prod2. Новые казни проходят, поскольку мы постоянно следим за услугами.
Мы отслеживаем застрявшие трубопроводы в prod2. Для клиентов, которые все еще видят застрявшие трубопроводы, мы просим вас прервать и повторно запустить.
Этот инцидент был урегулирован.
## ** Резюме** 6 августа 2026 года некоторые клиенты, работающие в производственной среде Prod2, наблюдали за выполнением трубопроводов, которые перестали прогрессировать — этапы, которые не продвинулись и не произвели никаких дальнейших обновлений производительности или состояния. Об этом сообщили пострадавшие клиенты. Инженеры Харнесса определили причину, смягчили воздействие, и трубопроводы вернулись к нормальной работе. Проблема была вызвана самореферентным выражением трубопровода. Веб-хук Git вызвал конвейер, который ссылался на содержимое полезной нагрузки веб-хука, а сама полезная нагрузка содержала дополнительные копии того же выражения. Таким образом, каждый раунд разрешения выражения производил больше выражений для разрешения, удваивая объем работы каждый раз. Это истощило ресурсы сервисного экземпляра, обрабатывающего это исполнение, и другие исполнения, назначенные тому же экземпляру, не могли прогрессировать, пока он находился в этом состоянии. ##**Влияние** Во время окна инцидента (приблизительно с 6:11 до 11:23 утра 6 августа 2026 года): Некоторые заказчики исполнения трубопроводов на Prod2 застопорились в середине исполнения и не добились дальнейшего прогресса. * Поврежденные казни не привели к новым результатам или обновлению статуса, и их пришлось прервать и возобновить после смягчения последствий. Поведение было ограничено выполнением, обрабатываемым пострадавшим сервисным экземпляром — трубопроводы, обрабатываемые другими экземплярами, продолжали выполняться нормально. Не было потери данных **. Определения трубопроводов, история исполнения и сохраненное состояние не были затронуты. Большинство трубопроводов на Prod2 продолжали успешно выполняться на протяжении всего инцидента; основное влияние заключалось в том, что некоторые казни в полете не могли быть завершены и должны были быть повторены после того, как проблема была смягчена. ##**Корневая причина** Трубопроводы Harness поддерживают выражения, которые разрешаются во время выполнения — например, выражение, которое вставляет содержимое полезной нагрузки Git webhook, которая вызвала трубопровод. В этом случае сообщение Git commit содержало буквальный текст самого выражения полезной нагрузки, дважды, и конвейер ссылался на то же самое выражение полезной нагрузки. Поскольку сообщение о совершении является частью полезной нагрузки Webhook, разрешение выражения вставляет всю полезную нагрузку, включая две буквальные копии выражения, переносимого в сообщении о совершении. Эти вновь вставленные копии затем рассматривались как выражения, подлежащие разрешению, и каждый пропуск вставлял еще две полные копии полезной нагрузки. Таким образом, размер обрабатываемой стоимости и работа, необходимая для ее обработки, удваивались на каждом проходе и росли экспоненциально, а не конвергентно. У Харнесса есть гарантия, призванная остановить именно это: разрешение выражения ограничено максимальной глубиной гнездования, за которой разрешение останавливается, а трубопровод выходит из строя с явной ошибкой. Недостаток этой гарантии означал, что предел не применялся в этом конкретном случае самореференции, поэтому решение оставалось без контроля. Разрешение экспрессии работает на нитях, которые начинают шаги трубопровода. Поскольку каждый проход потреблял все больше памяти и процессора, не завершая его, экземпляр службы, выполняющий эту работу, перестал прогрессировать, и каждое исполнение, назначенное этому экземпляру, застопорилось. ## **Смягчение** Harness завершила следующие немедленные шаги по смягчению последствий: * Определил трубопровод и шаблон выражения, отвечающий за разрешение побега. * Остановил пострадавший сервисный экземпляр, чтобы он больше не работал. Остальные здоровые экземпляры обычно подбирали и обрабатывали казни в очередях. Подтверждено, что казни на трубопроводах вернулись к норме и закрыли инцидент. Эти действия восстановили нормальное поведение при выполнении трубопровода и устранили воздействие на клиента. ##**Деятельность** Для снижения риска рецидива и улучшения выявления на различных стадиях реализации находятся следующие действия: Исправьте дефект в глубине выражения и защитите петлю обнаружения, чтобы самореферентные выражения были пойманы и быстро вышли из строя с явной ошибкой вместо потребления ресурсов без ограничений. * Предотвратить разрешение выражений полезной нагрузки из содержимого полезной нагрузки триггера, полностью удалив самореферентный путь. * Усилить максимальную глубину вложения экспрессии и оценить явное обнаружение петли в дополнение к существующему пределу глубины. Усилить автоматизированные тесты в предпроизводственных средах, которые воспроизводят самореферентные шаблоны выражения и проверяют, что защита обнаруживает и останавливает их. * Добавить мониторинг для этого шаблона в выполнение трубопровода, чтобы он был обнаружен проактивно.
Автоматический перевод официального обновления инцидента.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
В настоящее время мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
# ** Резюме** В период с 25 июля по 4 августа 2026 года панели мониторинга исполнения трубопроводов и обзорные страницы в кластерах Harness Prod 2 и Prod 3 отображали данные, которые находились между ними в режиме реального времени. Сами трубопроводы продолжали строить, развертывать и выполнять обычно; проблема ограничивалась тем, как быстро записи выполнения копировались в базу данных, которая обслуживает отчеты и просмотры панели инструментов. ** Данные о клиентах не потеряны.** Каждая затронутая запись хранилась и воспроизводилась в хранилище аналитических данных после устранения основного ограничения. Harness перенес пострадавшие кластеры в горизонтально масштабируемую версию компонента репликации с поддержкой очередей 1 августа 2026 года и завершил целевые списки данных для всех затронутых учетных записей. ** Коренная причина** Harness поддерживает компонент захвата данных изменений, который непрерывно копирует записи выполнения конвейера из основного операционного хранилища данных в отдельное хранилище данных временных рядов, оптимизированное для панелей мониторинга и запросов отчетности. Панели мониторинга читают исключительно из хранилища аналитических данных. Когда репликация отстает, панели приборов отображают точный, но более старый взгляд на мир, в то время как само исполнение не влияет. Это было вызвано резким, устойчивым увеличением объема записи базы данных из другого модуля платформы Harness, использующего тот же путь репликации, который превысил потолок пропускной способности более старой версии этого компонента, все еще работающей в Prod 2 и Prod 3. Сформировалось и выросло отставание. ** Профилактические действия** Компания Harness выполнила или взяла на себя обязательство предпринять следующие действия для предотвращения таких проблем. ** Действие** [править] | Хорошо настроить оповещение о задержке репликации так, чтобы любая задержка сверх определенного порога была уведомлена Добавьте панель задержки репликации на стандартную плату мониторинга платформы, чтобы здоровье трубопровода было видно по вызову по умолчанию. | Уменьшить амплификацию записи от модулей со-арендатора через ограничение скорости модуля или фильтрацию объекта в потоке репликации |
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
# **Summary** On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster. # **Impact** * Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes. * Retrieving existing artifacts \(downloads\) was not affected. * Manually uploading artifacts outside of a pipeline was not affected. * Other clusters/regions were not affected by this issue. # **Root Cause** The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source. A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source. Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail. # **Mitigation** * Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads. * Published a corrected, permanent version of the component to resolve the issue across all clusters. # **Next steps** * Fix the upload step to remove the underlying container-related defect that made this failure mode possible. * Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Автоматический перевод официального обновления инцидента.
Резюме - Мы периодически сталкиваемся с проблемами сетевого подключения, поскольку наша Build VM не может подключаться к внешним ресурсам. В настоящее время мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
##Резюме Начиная с 4 августа 2026 года, бегуны CI в регионах US-west1 и US-central1 периодически испытывали тайм-ауты подключения примерно 134 секунды при достижении внешних сервисов, таких как GitHub и Bitbucket, через исходящие сетевые шлюзы. # # Влияние CI-раннеры в пострадавших регионах периодически испытывали тайм-ауты подключения примерно 134 секунды при достижении внешних сервисов \(например, GitHub, Bitbucket\) через наши исходящие сетевые шлюзы. Проблема была прерывистой, а не постоянной — соединения преуспевали при нормальной нагрузке, а сбои группировались в периоды высокого объема исходящего трафика. * Данные не были потеряны или повреждены. Это была проблема сетевого подключения и емкости, а не проблема целостности данных. США-Запад1 и США-Централ1 были затронутыми регионами; другие регионы не были затронуты этим вопросом. ##Коренная причина Балансировщик нагрузки распределяет исходящий трафик по нескольким шлюзам NAT, используя метод хеширования, основанный на деталях соединения (адрес источника / назначения и порт). Для любого отдельного соединения эти детали остаются постоянными на протяжении всей жизни этого соединения. У нас был устойчивый всплеск трафика в течение нескольких секунд, который перегрузил шлюзы. ## Пункты действия Чтобы подобные проблемы не повторились, Харнесс Увеличьте пропускную способность исходящих соединений на наших шлюзах NAT, предоставив дополнительные внешние сетевые интерфейсы, предоставляя каждому шлюзу значительно больший пул соединений, которые он может обслуживать одновременно.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Мы продолжаем расследование этого вопроса.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Мы продолжаем работать над решением этой проблемы.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
# Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. **Root Cause** The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. **Resolution** Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity. ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._
Автоматический перевод официального обновления инцидента.
Мы расследуем проблему, затрагивающую панели AIDI. Пользователи могут испытывать повышенное время загрузки или периодические сбои при доступе к панели инструментов. Наша команда активно работает над выявлением первопричины и восстановлением нормальной работы. Мы будем предоставлять обновления по мере поступления дополнительной информации.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
##Резюме Клиенты в кластерах Prod1, Prod2 и Prod3 испытывали периодические сбои в нагрузке виджетов и увеличение времени загрузки при доступе к приборным панелям AIDI 2.0 22 июля 2026 года. Не все виджеты были затронуты одновременно, проблема проявлялась как спорадические сбои, а не полное отключение. Данные клиентов не были потеряны. Клиенты SEI 1.0 не пострадали. ##Коренная причина Со временем рутинный процесс обслуживания баз данных не работал на определенных таблицах в нашей аналитической базе данных, в результате чего эти таблицы накапливали большой объем внутренних метаданных, используемых для отслеживания удаленных записей. Когда база данных планировала запросы к этим таблицам, она загружала все эти накопленные метаданные в память, в результате чего использование памяти на пораженных узлах повторялось. Эти повторяющиеся всплески вызвали автоматический механизм безопасности, который перезапускает узел, когда он обнаруживает чрезмерное давление памяти, и в результате пораженные узлы начали перезапускаться в петле. Это вызвало прерывистую, ухудшенную производительность запросов на приборных панелях AIDI 2.0 в течение всего инцидента. # # Влияние Клиенты в кластерах Prod1, Prod2 и Prod3 могут испытывать периодические сбои в нагрузке виджетов или увеличение времени загрузки на панели инструментов AIDI 2.0. **Продолжительность:** 22 июля 2026 года, 07:58 PDT – 16:16 PDT \(~8 часов 18 минут\), с перебоями виджетов; система была перезапущена и находится под активным мониторингом с 08:25 PDT и далее. ###Что не удалось сделать? * Проглатывание и обработка данных SEI 1.0 Клиенты * Интеграция и потоки метаданных Данные клиентов не были потеряны. ## Восстановление При выявлении проблемы пораженные узлы базы данных были перезапущены в 08:25 PDT, что восстановило начальную стабильность. Мы продолжали внимательно следить за системой, и когда после этого все еще наблюдалась прерывистая деградация, мы применили несколько дополнительных исправлений: * Скорректированные настройки конфигурации базы данных для ограничения объема памяти, используемой для обработки накопленных метаданных, и настроенные настройки планирования запросов для снижения давления памяти. * Проверка работы по очистке, чтобы уменьшить отставание от накопленных метаданных на затронутых таблицах. * Увеличение пропускной способности затронутых узлов базы данных для обеспечения дополнительного зала заседаний. Эти изменения постепенно стабилизировали систему, и инцидент был полностью разрешен в 16:16 PDT. ## Пункты действия Чтобы предотвратить повторение, мы реализуем следующее: 1. Мы обновили бэкэнд, который включает в себя основные улучшения, которые обрабатывают всплески памяти, вызванные чрезмерным удалением файлов. 2. Мы развернули автоматизированные рабочие места уплотнения для недавно введенных таблиц, чтобы предотвратить накопление файлов в будущем.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
# Резюме 17 июля 2026 года, после рутинного развертывания кода, клиенты на более старых версиях делегатов \(858xx и ниже \) начали испытывать задержки CI сборок на Harness Cloud-хостинг сборок с использованием нашей глобальной возможности построения очереди. Пострадавшие здания испытали неожиданную паузу примерно до 8 минут на стадии «ожидания инфраструктуры», прежде чем продолжить, а не продолжать в течение ожидаемого субсекундного времени. Общая медлительность строительства была прерывистой. #Влияние Все сборки CI потенциально могут быть отложены; влияние было наиболее выраженным для сборок на инфраструктуру, размещенную в Harness Cloud, с использованием функции глобальной очереди сборки. Пострадавшие сборки пережили необъяснимую паузу примерно за 8 минут до продолжения, за которой последовал более медленный «холодный старт», поскольку предварительно зарезервированный компьютерный слот не был доступен — это представлялось пользователям как медленные сборки, а не сбои сборки. * Аккаунты, работающие на новых версиях делегатов \(858xx и выше\) не были затронуты. Никакие сборки не потерпели неудачу прямо в результате этой проблемы, и никакие данные не были потеряны. #Коренная причина Основной причиной было внутреннее изменение кода, которое непреднамеренно нарушило то, как конкретная запись очередей сборки была прочитана из нашей базы данных после сборки, которая уже была поставлена в очередь в соответствии с предыдущей версией кода. Мы устранили непосредственное воздействие путем очистки затронутых записей и возврата основного изменения кода, и мы реализуем несколько мер предосторожности, чтобы предотвратить повторение этого класса проблем. # Следующие шаги Мы оцениваем риск аналогичного рецидива как низкий, поскольку нижеследующие действия не учитываются. Конкретный путь кода, который вызвал этот инцидент, уже был возвращен, и мы реализуем структурные гарантии, чтобы этот общий класс проблем не мог повториться, независимо от того, где в кодовой базе это могло бы произойти в противном случае. **Превентивные действия** [править] Добавьте явные, стабильные идентификаторы во все внутренние классы данных, которые хранятся в нашей базе данных, чтобы будущие внутренние реорганизации кода не могли нарушить способность системы считывать ранее сохраненные записи. ! Внедрить тестирование отката и обратной совместимости в нашей предпроизводственной среде, специально разработанной, чтобы поймать этот класс выпуска, прежде чем он достигнет производства.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
# Резюме В период с 19 июня по 17 июля 2026 года встроенный шаг Git Clone — и любой шаг трубопровода с использованием плагина клона дрона — не удалось на ARM64 Kubernetes построить инфраструктуру с ошибкой exec /usr/local/bin/clone: ошибка формата exec. AMD64 \(Intel/AMD\) сборки, сборки Windows и VM без контейнеров двоичный путь не были затронуты. Основной причиной был дефект в нашем внутреннем процессе публикации изображений, который привел к тому, что изображения, помеченные ARM64, на самом деле содержат двоичные файлы AMD64. Мы идентифицировали и смягчили проблему в тот же день, когда было сообщено об этом, вернув изображение с беспилотника в последнюю известную хорошую версию. Не требуется никаких действий клиента или изменения конфигурации. #Коренная причина 19 июня 2026 года реконструкция системы безопасности изменила способ создания изображения дрона. Сборки AMD64 обновлялись правильно, но конвейер сборки ARM64 не создавал файлы ARM64 напрямую — он адаптировал файл сборки AMD64 через замену текста и скомпилировал его на инфраструктуре ARM64. Изменение 19 июня изменило файл AMD64 так, что замена бесшумно отменялась вместо отказа, поэтому конвейер опубликовал изображение с пометкой ARM64, чьи двоичные файлы Git Clone и Git LFS все еще были скомпилированы для AMD64. #Влияние Пострадал: Встроенный шаг Git Clone и любой шаг трубопровода с использованием плагина клона-дрона, работающего на ARM64 Kubernetes, создают инфраструктуру во всех учетных записях в период с 6 по 17 июля 2026 года. * Симптом: На этапе Git Clone сборки потерпели неудачу с ошибкой формата exec /usr/local/bin/clone. * Не затронуты: AMD64 \(Intel/AMD\) Kubernetes и VM сборки, Windows сборки, VM без контейнера путь выполнения, и наш закаленный вариант изображения. #Смягчение Мы вернули версию изображения, используемую во всех затронутых службах, к последнему известному выпуску. Это полностью устранило сбои в выполнении ARM64; никаких изменений конфигурации клиента не требовалось. # Следующие шаги Чтобы подобные проблемы не повторились. Восстановите конвейер публикации изображений ARM64, чтобы напрямую создавать файлы ARM64, а не адаптировать файлы сборки AMD64. * Усильте автоматическую проверку после публикации для каждого выпуска изображения: проверьте, соответствует ли двоичная архитектура тегу изображения, и запустите функциональный тест дыма, прежде чем изображение будет считаться выдаваемым. Расширить автоматизированное покрытие испытаний, включив в него сценарии сборки ARM64 Kubernetes. * Удалить затронутые промежуточные версии изображения из обращения после проверки исправленного выпуска.
Автоматический перевод официального обновления инцидента.