Prod2 был временно недоступен
Pending
Затронутые компоненты
Platform
- investigating
В настоящее время мы расследуем этот вопрос.
- resolved
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
82 Split 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 выполнила или взяла на себя обязательство предпринять следующие действия для предотвращения таких проблем. ** Действие** [править] | Хорошо настроить оповещение о задержке репликации так, чтобы любая задержка сверх определенного порога была уведомлена Добавьте панель задержки репликации на стандартную плату мониторинга платформы, чтобы здоровье трубопровода было видно по вызову по умолчанию. | Уменьшить амплификацию записи от модулей со-арендатора через ограничение скорости модуля или фильтрацию объекта в потоке репликации |
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
# ** Резюме** 31 июля 2026 года загрузки артефактов, выполненные по трубопроводу в кластере EU1, начали выходить из строя с ошибкой аутентификации. Загрузки, инициированные вручную \(вне трубопровода\), не были затронуты, и способность извлекать существующие артефакты \(загрузки\) также не была затронута — это было выделено на конкретный путь загрузки трубопровода в одном кластере. #**Влияние** Загрузки артефактов, выполненные по трубопроводу в кластере EU1, не удались с ошибкой аутентификации в течение примерно 4 часов и 34 минут. * Не было затронуто извлечение существующих артефактов. * Не была затронута ручная загрузка артефактов за пределы трубопровода. * Этот вопрос не затронул другие группы/регионы. **Корневая причина** Компонент, ответственный за обработку загрузок артефактов на основе трубопровода, распределяется в виде изображения контейнера. В кластере EU1 это изображение извлекается из внутреннего реестра, который отражает публичный источник изображения; в других кластерах то же самое изображение извлекается непосредственно из публичного источника. Ошибка публикации в процессе выпуска привела к тому, что новая сборка этого компонента была опубликована с использованием уже используемой версии, а не была назначена новая, уникальная версия. В результате два разных изображения оказались связаны с одной и той же версией в общедоступном источнике. Наш внутренний реестр отражает изображения из общедоступного источника с помощью автоматизированного процесса репликации. Из-за того, как эта репликация была запущена, он скопировал оригинальное изображение, связанное с этой версией, а не исправленное. Это означало, что кластер EU1, который вытягивается из внутреннего зеркала, в конечном итоге получил иное, дефектное изображение, чем другие кластеры, которые вытягивают непосредственно из публичного источника и, следовательно, получают исправленное изображение. Дефектное изображение содержало проблему аутентификации, которая привела к отказу загрузки трубопровода. #**Смягчение** * Вернул затронутую учетную запись в последнюю известную версию компонента загрузки, немедленно восстановив загрузку трубопровода. * Опубликована исправленная, постоянная версия компонента для решения проблемы во всех кластерах. **Следующие шаги** * Исправьте шаг загрузки, чтобы удалить основной дефект контейнера, который сделал возможным этот режим отказа. Обновите наш конвейер выпуска для этого компонента, чтобы публикация изображения никогда не могла перезаписать существующую версию - каждая публикация должна создать новую, отдельную версию в будущем.
Автоматический перевод официального обновления инцидента.
Резюме - Мы периодически сталкиваемся с проблемами сетевого подключения, поскольку наша Build VM не может подключаться к внешним ресурсам. В настоящее время мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Мы продолжаем расследование этого вопроса.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Мы продолжаем работать над решением этой проблемы.
Реализовано исправление, и мы отслеживаем результаты.
Мы продолжаем отслеживать любые дополнительные проблемы.
Этот инцидент был урегулирован.
# Резюме Во время недавнего развертывания производства из-за дефекта в нашем инструменте внутреннего развертывания две критически важные службы работали с неправильными, непроизводственными значениями конфигурации в нашей производственной среде. Это привело к связанному набору из четырех различных симптомов: неправильное поведение конфигурации, периодические сбои входа в систему / доступа, проблема доступа к файловому магазину, затрагивающая одну клиентскую среду, и задержка обновления статуса конвейера в пользовательском интерфейсе. Мы определили и внедряем постоянное исправление основного дефекта конфигурации и уже ввели изменения ресурсов и емкости, которые устраняют симптом задержки пользовательского интерфейса. Ни в какой момент во время этого инцидента сами казни не были потеряны, повреждены или оставлены в застрявшем состоянии. Там, где поведение исполнения было затронуто, оно ограничивалось задержками в видимости статуса, а не в основной обработке. #Инцидентные подробности ## Неправильные производственные конфигурационные значения Наша инженерная команда подтвердила дефект в конвейере развертывания Service Manager, который привел к развертыванию определенных производственных услуг с использованием значений конфигурации, предназначенных для другой среды, а не правильной конфигурации производства. **Корневая причина** Служба, отвечающая за получение конфигурации, переопределяет во время запросов развертывания внутренний API, который возвращает максимум 1000 результатов за запрос. Общее количество услуг в области охраны окружающей среды в последнее время превысило этот предел. В результате, любая услуга после первой 1000 возвращенных не была включена в ответ, и конвейер развертывания молча вернулся к значениям конфигурации по умолчанию для этих услуг. Это подтвержденный дефект пагинации в инструменте развертывания, а не проблема с самими значениями конфигурации. ** Резолюция** Инженеры подтвердили механизм и внедряют постоянное исправление для устранения этого связанного с ограничением разрыва в трубопроводе развертывания. ## Прерывистый вход / сбои доступа Во время развертывания диспетчера услуг, о котором говорилось выше, некоторые пользователи испытывали периодические сбои входа в систему или доступа. При нормальной работе ранее запущенные экземпляры должны продолжать обслуживать трафик без перерыва, пока происходит новое развертывание. В этом инциденте резервное поведение произошло не так, как ожидалось, что способствовало сбоям доступа во время окна развертывания. ##Проблема доступа к архиву Была выявлена проблема доступа к файловому магазину, которая была характерна для среды Prod-3 и затрагивала среду одного клиента. **Корневая причина** Это связано с конфигурацией разрешения IAM / storage-bucket на диспетчере служб, потенциально вызванной откатом. ## Отсроченные обновления статуса выполнения трубопровода в UI Некоторые пользователи заметили, что график выполнения трубопровода в пользовательском интерфейсе медленно обновляется и не отражает последний статус быстро. Важно отметить, что это была только задержка видимости: не было никакого влияния на фактические казни трубопроводов, и никакие казни не были застряли или не были выполнены в результате этого вопроса. **Корневая причина** График выполнения трубопровода полагается на поток сообщений (журнал оркестровки) для получения обновлений статуса. Во время окна инцидента пользовательская обработка этого потока отставала от \(высокий потребительский лаг\), что задерживало то, как быстро обновления статуса достигли пользовательского интерфейса. Это было вызвано тем, что базовая база данных находилась в середине запланированной операции масштабирования в то же время, и всплеск трафика во время этого окна еще больше усугубил задержку. Пользователи восприняли это как очевидную медлительность трубопровода, хотя основные исполнения выполнялись нормально. ** Резолюция** Мы увеличили емкость ресурсов для пострадавших компонентов, чтобы сохранить более 50% запасного зала, снижая чувствительность к аналогичным пикам нагрузки. Это изменение было реализовано и в настоящее время проверяется в рамках долгосрочного закаливания этой части платформы. # Краткое описание воздействия Менеджер услуг и менеджер лицензий работали с неправильными значениями конфигурации в средах Prod-1 и Prod-3. Некоторые пользователи испытывали периодические сбои входа или доступа во время затронутого окна развертывания. Одна клиентская среда в Prod-3 столкнулась с проблемой доступа к файловому магазину. Пользователи в затронутых средах видели отсроченные обновления статуса исполнения трубопровода в пользовательском интерфейсе; основные исполнения трубопровода продолжали работать правильно и не были потеряны, застряли или повреждены. #Превентивные меры Выявлены следующие корректирующие и профилактические действия. **Превентивные действия** [править] Исправьте предел пагинации в службе поиска конфигурации, чтобы все услуги были возвращены и оценены, независимо от общего количества. Добавьте защитные меры, чтобы служба, которая не может восстановить свою конфигурацию, вышла из строя безопасно (например, предупреждает и блокирует развертывание), а не молча возвращалась к непроизводственным по умолчанию. ! Увеличить запасной ресурс Postgres и Messaging-pipeline \(цель: более 50% запасной мощности\) для снижения чувствительности к одновременной нагрузке и масштабированию событий. ! Мы признаем влияние этого инцидента на несколько областей платформы и ценим ваше терпение, поскольку мы работаем над полным разрешением
Автоматический перевод официального обновления инцидента.
Мы расследуем проблему, затрагивающую панели AIDI. Пользователи могут испытывать повышенное время загрузки или периодические сбои при доступе к панели инструментов. Наша команда активно работает над выявлением первопричины и восстановлением нормальной работы. Мы будем предоставлять обновления по мере поступления дополнительной информации.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### 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 issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Автоматический перевод официального обновления инцидента.
В настоящее время мы расследуем этот вопрос.
Этот вопрос был определен, и в настоящее время осуществляется исправление.
Реализовано исправление, и мы отслеживаем результаты.
Этот инцидент был урегулирован.
# Резюме 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. * Удалить затронутые промежуточные версии изображения из обращения после проверки исправленного выпуска.
Автоматический перевод официального обновления инцидента.