История сбоев Split

1. 27 октября 2026 г. в 19:52 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 27 октября 2026 г. в 19:58 UTCinvestigating

   Трубопроводы CI на VM-инфраструктуре терпят неудачу на этапе инициализации, потому что задача переходит к делегату за пределами предполагаемого пула

3. 27 октября 2026 г. в 21:15 UTCidentified

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

4. 27 октября 2026 г. в 22:16 UTCmonitoring

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

5. 27 октября 2026 г. в 22:24 UTCresolved

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

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

1. 19 октября 2026 г. в 07:46 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 19 октября 2026 г. в 08:02 UTCidentified

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

3. 19 октября 2026 г. в 08:04 UTCmonitoring

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

4. 19 октября 2026 г. в 08:21 UTCresolved

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

5. 23 октября 2026 г. в 18:21 UTCpostmortem

   ## ** Резюме** 19 октября 2026 года, примерно между 12:10 и 12:55 утра по местному времени, клиенты Prod4 столкнулись с ошибками и периодическим отсутствием услуг Harness Pipelines. Тяжелое выполнение трубопроводов привело к резкому росту использования процессора и памяти в трубопроводной службе, и в течение короткого периода все сервисные экземпляры были недоступны. Инженерия Harness масштабировала сервис как вертикально, так и горизонтально, что восстановило сервис. Исправление основного поведения разворачивается. ##**Корневая причина** 19 октября большое количество одновременных казней с очень большими графиками исполнения привело к резкому увеличению ресурсов кластера. Сервис хранит и извлекает этот полный график исполнения для целей визуализации и дальнейшего продвижения трубопроводов в следующие состояния. Наши автоскалеры на Prod4 заняли больше времени, чем обычно, для масштабирования ресурсов из-за резкого роста процессора и памяти. Как часть исправления, обновление графика исполнения теперь будет обрабатывать изменения графа постепенно вместо полного графа. Он развертывается поэтапно и будет полностью развернут в самое ближайшее время. ##**Влияние** Пострадавшие пользователи: клиенты на Prod4. * Симптом: отсутствие функциональности трубопровода в платформе Harness. * Данные: нет потери данных. * Предлагаемый обходной путь: не требуется от клиентов. Инженерная инженерия решила проблему. Продолжительность удара: около 20 минут полной недоступности и ухудшение производительности в течение 25 минут. Harness продолжила мониторинг после восстановления и подтвердила стабильность платформы с клиентами. ##**Реабилитация** ** Немедленно** Инженерия Харнесса масштабировала трубопроводную службу как вертикально (больше ресурсов на экземпляр), так и горизонтально (больше экземпляров), и удалила экземпляры в нездоровом состоянии. Количество экземпляров стабилизировалось, нормальная служба была восстановлена. Система будет масштабироваться до тех пор, пока исправление не будет полностью развернуто. **Постоянное исправление и элементы действия** Чтобы подобные проблемы не повторились, Харнесс 1. Настройка процесса автоматического заживления / масштабирования так, чтобы воздействие было минимальным. 2. Оптимизация потока графиков выполнения так, чтобы большие графы могли обрабатываться быстрее.

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

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

   В настоящее время мы расследуем этот вопрос.

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

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

3. 15 октября 2026 г. в 10:27 UTCresolved

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

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

1. 15 октября 2026 г. в 08:04 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 15 октября 2026 г. в 08:05 UTCidentified

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

3. 15 октября 2026 г. в 08:09 UTCmonitoring

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

4. 15 октября 2026 г. в 08:15 UTCresolved

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

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

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

   В настоящее время мы расследуем этот вопрос.

2. 13 октября 2026 г. в 01:07 UTCidentified

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

3. 13 октября 2026 г. в 01:56 UTCmonitoring

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

4. 13 октября 2026 г. в 04:29 UTCresolved

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

5. 23 октября 2026 г. в 03:16 UTCpostmortem

   . .

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

1. 12 октября 2026 г. в 15:25 UTCinvestigating

   В настоящее время мы испытываем ошибки HTTP 429 (ограничение скорости), когда Harness Cloud создает доступ к Maven Central, что может повлиять на выполнение сборки. Наша команда активно работает с Sonatype, чтобы решить проблему как можно быстрее. Мы будем предоставлять дальнейшие обновления по мере продвижения вперед.

2. 12 октября 2026 г. в 19:31 UTCresolved

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

3. 23 октября 2026 г. в 03:06 UTCpostmortem

   tldr: \(Было краткое ограничение скорости по maven central\) Больше деталей, чтобы следовать

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

1. 8 октября 2026 г. в 10:23 UTCmonitoring

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

2. 8 октября 2026 г. в 10:53 UTCresolved

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

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

1. 6 октября 2026 г. в 21:46 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 6 октября 2026 г. в 21:47 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 6 октября 2026 г. в 22:03 UTCidentified

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

4. 6 октября 2026 г. в 22:30 UTCmonitoring

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

5. 6 октября 2026 г. в 22:30 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты. У нас есть подтверждение этого решения вопроса.

6. 6 октября 2026 г. в 22:44 UTCresolved

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

7. 23 октября 2026 г. в 02:12 UTCpostmortem

   # 1 Краткое содержание 6 октября 2026 года трубопроводы, содержащие стадию IaCM, не смогли запуститься на Prod1 около двух часов. Пострадавшие пользователи увидели ошибку, когда трубопровод попытался создать свой план выполнения. Трубопроводы, которые не использовали стадию IaCM, продолжали нормально работать. Основной причиной был внутренний дефект лесозаготовки в сервисе, который обрабатывает выполнение этапа IaCM: при определенном, редком условии времени, собственная система лесозаготовок этой службы может в конечном итоге ждать себя бесконечно, что, в свою очередь, застопорило более широкий процесс, ответственный за подготовку планов выполнения трубопровода. Проблема была вызвана необычно большим всплеском активности журнала из трубопровода одного клиента. Мы устранили немедленный эффект, переведя сервис обратно в его предыдущую стабильную версию, и в настоящее время тестируется постоянное исправление кода. #2 Влияние Все трубопроводы, использующие стадию IaCM на Prod1, не могли начаться в течение примерно двух часов. Пострадали несколько клиентов в кластере Prod1. Трубопроводы, которые не использовали стадию IaCM, не пострадали и продолжали работать нормально. * Данные не были потеряны в результате инцидента. * В качестве побочного эффекта отката, используемого для разрешения этого инцидента, временно было отменено несвязанное исправление для одного клиента (продление срока действия определенного токена аутентификации во время длительных трубопроводов). Это исправление было повторно применено в тот же вечер. # 3 Коренная причина Служба, отвечающая за этапы трубопровода IaCM, регистрирует свою деятельность через внутреннюю очередь: лог-сообщения размещаются в очереди, а один фоновый работник непрерывно читает из нее и записывает сообщения. Отдельно этот сервис имеет фильтр, который может переписать тяжесть определенных сообщений журнала обратно в ту же очередь. При определенном, узком временном условии это создавало тупик, если очередь была полностью заполнена в тот момент, когда переписанное сообщение было отправлено обратно на нее, один рабочий, ответственный за освобождение пространства в очереди, сам застрял в ожидании освобождения пространства, состояние, которое он никогда не мог решить, поскольку это было единственное, что могло освободить это пространство. Как только это произошло, каждая другая часть службы, которая должна была регистрировать что-либо, также застряла в ожидании, которое каскадировалось в процесс создания трубопровода, не сработав для любого трубопровода с использованием стадии IaCM. # 4 Резолюция Вернул сервис в его последнюю стабильную версию, которая устранила немедленный инцидент. # 5 Профилактические действия 1.**Оптимизировать основной дефект**: Оптимизируйте и настройте фильтр регистрации так, чтобы переписывание серьезности сообщения происходило на потоке, который генерировал линию журнала, а не повторно отправлялся через ту же очередь фонового рабочего, полностью устраняя состояние тупика. 2.** Усилить мониторинг состояния здоровья в очереди регистрации**: добавьте метрики и оповещения об этой внутренней очереди, чтобы этот класс насыщения страницы нашей команды по вызову автоматически, а не полагаться на отчеты клиентов. 3.** Оценить пределы и выполнить высокие стресс-тесты с очень большими трубопроводами**:

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

1. 16 октября 2026 г. в 10:41 UTCresolved

   7 октября 2026 года, с 08:00 UTC до 11:00 UTC (1:30 вечера до 4:30 вечера IST), в некоторых исполнениях трубопроводов на кластере Prod 7 наблюдались периодические сбои в оценках шагов политики (OPA).

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

1. 6 октября 2026 г. в 12:54 UTCmonitoring

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

2. 6 октября 2026 г. в 15:35 UTCresolved

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

3. 10 октября 2026 г. в 01:57 UTCpostmortem

   ###Резюме Клиенты на Prod 2 испытывали периодические сбои нескольких шагов проверки при запуске. Поврежденные шаги потерпели неудачу вскоре после запуска с сообщением, указывающим, что Continuous Verification не может достичь внутренней службы Harness. Проблема возникла из-за недавнего обновления службы, которое ввело объединение соединений для повышения производительности и надежности с установкой Keep-alive, несовместимой с тайм-аутом службы приема. Данные клиентов не были потеряны или повреждены. ###Влияние на клиента Клиенты, использующие шаги CV Verify на Prod-2, видели периодические сбои шагов во время окна инцидента. Показатели отказов были низкими - большинство казней были успешно завершены через окно. Трубопроводы, которые не использовали шаги CV Verify, не пострадали. ###Коренная причина В недавнем обновлении службы CV было введено объединение соединений с внутренним компонентом платформы с продолжительностью ожидания дольше, чем простое время ожидания этого компонента. Соединения, которые достаточно долго простаивали, были бесшумно закрыты сервером; служба CV не обнаружила этого и не имела логики повторных попыток для таких сбоев, в результате чего они всплыли непосредственно как сбои шага Verify. Проблема была прерывистой, потому что она затрагивала только те связи, которые оставались бездействующими достаточно долго, чтобы истечь. ###Смягчение Продолжительность сохранения соединения была сокращена до периода простоя службы приема. Неудачи немедленно упали почти до нуля, и никаких дальнейших сбоев этого типа не наблюдалось ни в одной производственной среде. ### Следующие шаги Чтобы предотвратить повторение, Харнесс: ***Установка соединения: ** Настройка по умолчанию Keep-alive и включенная автоматическая повторная запись на сбоях соединения, чтобы ошибки застойного соединения обрабатывались прозрачно. ** Добавить устойчивость на этапе запуска: ** Введите повторную попытку с обратным выключением для внутреннего вызова службы при запуске шага Verify, чтобы изолированные переходные сбои не всплыли как немедленные сбои шага. *** Усилить оповещение:** Улучшенный мониторинг внутренних ошибок подключения.

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

1. 6 октября 2026 г. в 11:58 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 6 октября 2026 г. в 11:59 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 6 октября 2026 г. в 12:24 UTCidentified

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

4. 6 октября 2026 г. в 16:21 UTCresolved

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

5. 9 октября 2026 г. в 18:48 UTCpostmortem

   ##Резюме Во вторник, 6 октября 2026 года**, трубопроводы IaCM, которые используют плагин **OpenTofu** в **Prod1**, периодически терпели неудачу для производственного счета. Один и тот же трубопровод часто преуспевал на повторных испытаниях без изменения конфигурации. Типичные неудачные казни длились около 90 минут. Другие модули Harness не сильно пострадали. У нас нет сообщений о потере данных клиентов. Трубопроводы, которые закончились в течение срока службы токена, не были затронуты этим дефектом. ##Коренная причина На этапах IaCM чеканились токены аутентификации, срок действия которых истекал через час. Проверки политики позже в долгосрочной перспективе затем отклонили токен, поэтому шаг был отсрочен или не удалось аутентификации. Этот час жизни был установлен. Пробеги продолжительностью около 90 минут пересекли отметку в один час, поэтому сбои проявлялись на более длинных трубопроводах и часто прояснялись на более коротком повторе. Отдельный набор ошибок плана в той же учетной записи произошел от настройки учетных данных в рабочем пространстве клиента и находится за пределами этого инцидента. # # Влияние *** Продукция:** Трубопроводы IaCM используют плагины IaCM, разговаривающие с OPA sdk. *** Опыт работы с клиентами: ** прерывистые тайм-ауты и сбои аутентификации после секретной инъекции, при пробежке более часа. ** Окружающая среда:** Prod1, один производственный счет **Данные:** О потере данных не сообщается. ## Восстановление ** Немедленно:** Открыл страницу состояния для затронутой учетной записи Prod1 и отправил временное изменение менеджера IaCM для одного класса наблюдаемых сбоев при создании исправления плагина. ** Постоянная:** Отключил исправление плагина OpenTofu, поэтому истечение срока действия токена настраивается. При производстве срок службы был увеличен примерно до 6 часов, поэтому длинный трубопровод не переживет токен. Hotfix был проверен в QA и развернут в Prod1. Мы приносим извинения за причиненный ущерб. Пожалуйста, обратитесь в службу поддержки Harness, если у вас есть какие-либо дополнительные вопросы.

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

1. 5 октября 2026 г. в 22:01 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 5 октября 2026 г. в 23:50 UTCidentified

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

3. 6 октября 2026 г. в 00:26 UTCmonitoring

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

4. 6 октября 2026 г. в 00:26 UTCmonitoring

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

5. 6 октября 2026 г. в 00:39 UTCresolved

   Проверил исправление и решил вопросы ССО.

6. 9 октября 2026 г. в 16:17 UTCpostmortem

   ## Okta Application SP-Initiated SSO Login Failures # Резюме Между 5 октября 2026 года, 18:18 UTC и 6 октября 2026 года, 00:26 UTC, некоторые клиенты Harness не смогли войти на сервер Harness Hosted MCP через SAML Single Sign-On (SSO). Основная аутентификация пользователей Harness Portal оставалась полностью работоспособной. Пострадавшие пользователи видели ошибки входа или были перенаправлены на недействительную страницу SSO вместо завершения входа. Проблема была вызвана изменениями в обновлении версии службы идентификации Harness. Мы исправили его серией исправлений, и логин SSO был полностью восстановлен для всех пострадавших клиентов. #Влияние Пользователи, подписавшиеся на Harness MCP через SAML SSO, не смогли пройти аутентификацию. Существующие MCP-сессии, которые полагались на SSO, не могли быть обновлены, поэтому некоторые пользователи должны были войти снова. Во время большей части инцидента работали логины Non-SSO в Hosted MCP. Данные клиентов не были потеряны или раскрыты. Клиенты, использующие собственную общую конфигурацию приложения SAML 2.0 в Окте, не пострадали. #Коренная причина 29 сентября 2026 года в Okta Integration Network была опубликована обновленная версия приложения Harness. В обновлении добавлена поддержка регистрации нескольких URL-адресов ответов (ACS), чтобы клиенты, работающие с Harness в нескольких регионах или средах, могли настроить более одного URL-адреса обратного вызова. Harness включает значение AssertionConsumerServiceURL в запросе на аутентификацию SAML, который он отправляет в Окту. До этого обновления Okta не проверяла это значение для экземпляров приложений без настроенных дополнительных URL-адресов ACS и вместо этого вернула утверждение SAML в URL-адрес ACS по умолчанию приложения. После обновления эта валидация стала активной во всех существующих приложениях, включая те, где клиент никогда не настраивал дополнительный URL-адрес ACS. Поскольку запрашиваемое значение не присутствовало в зарегистрированном списке экземпляра, Okta вернула ошибку HTTP 400. Обновленное приложение прошло через стандартный обзор OIN Okta, который включает проверку обратной совместимости с существующими установками опубликованной интеграции. Это изменение в поведении проверки, например, без дополнительных настроенных URL-адресов ACS, не было обнаружено во время этого обзора, поэтому оно достигло клиентов во время выпуска. # Восстановление ** Немедленный ответ** На странице статуса были опубликованы два обходных пути: вход из плитки Harness в Okta \(IdP-инициированный логин\), который не был затронут, или регистрация URL-адреса Okta SSO приложения в поле Дополнительных URL-адресов ACS приложения Harness Okta. Harness привлек каждого зарегистрированного пострадавшего клиента напрямую и подтвердил их регистрацию. ** Резолюция** Перенос приложения на предыдущую версию был намеренно предотвращен, так как это только отсрочит тот же самый сбой в следующем выпуске. Вместо этого каждый затронутый клиент был разблокирован через регистрацию URL-адресов ACS, и мы работаем с Okta, чтобы сделать валидацию URL-адресов ACS условной снова, так что экземпляры без дополнительных URL-адресов ACS настроены вести себя точно так же, как они делали раньше, и никаких действий клиента не требуется. # Пункты действия Чтобы предотвратить повторение подобных проблем, Харнесс примет следующие меры: 1.Работая с Okta, чтобы восстановить условную валидацию URL-адресов ACS, экземпляры без дополнительных настроенных URL-адресов ACS ведут себя точно так же, как и раньше, и не требуется никаких действий клиента. 2. Опубликовать специальное руководство по конфигурации для приложения Harness OIN в документации Harness, включая требования к URL-адресу ответа \(ACS\). 3. Добавить независимый шаг предварительной проверки против существующих конфигураций клиентов для любого будущего обновления опубликованного приложения Okta, наряду с собственным обзором Okta. 4. Переместить аутентификацию пользователя в Harness ID, что полностью устраняет зависимость от этого поведения проверки.

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

1. 29 сентября 2026 г. в 20:31 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 29 сентября 2026 г. в 20:31 UTCidentified

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

3. 29 сентября 2026 г. в 20:57 UTCidentified

   Мы выявили проблему, которая относится только к логину, инициированному SP, через опубликованное приложение Harness Okta. После недавнего обновления этого приложения эти попытки входа вернули ошибку HTTP 400, когда настроенный URL SSO отсутствовал в дополнительных URL-адресах ACS. Конфигурации SAML 2.0 в Окте не затронуты. Немедленные решения: Используйте логин, инициированный IDP. Запустите логин из плитки приложения Harness в Окте. Или Добавьте свой URL-адрес Harness SSO в дополнительные URL-адреса ACS в опубликованном приложении Harness Okta.

4. 2 октября 2026 г. в 00:33 UTCresolved

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

5. 7 октября 2026 г. в 18:30 UTCpostmortem

   # 1 Краткое содержание Начиная с 29 сентября 2026 года клиенты, которые вошли в Harness через опубликованное приложение Harness в Okta Integration Network \(OIN\), не смогли завершить вход в систему SSO, инициированный SP. Пострадавшие пользователи вместо входа в систему получили ошибку HTTP 400 от Okta. Проблема была введена изменением того, как Okta подтвердила запрашиваемый ответ \(ACS\) URL для существующих установок опубликованного приложения Harness. В течение часа после первого отчета были опубликованы обходные пути, и каждый пострадавший клиент был разблокирован. #2 Влияние * Воздействие было ограничено пользователями, использующими опубликованное приложение Harness от Okta Integration Network для SP-инициированного входа в систему. Эти попытки вернули ошибку HTTP 400 из Окты. Инициированный IdP логин, начатый с плитки Harness в Окте, продолжал работать повсюду. Клиенты, использующие собственную общую конфигурацию приложения SAML 2.0 в Окте, не пострадали. * Данные клиентов не были потеряны или раскрыты. # 3 Коренная причина 29 сентября 2026 года в Okta Integration Network была опубликована обновленная версия приложения Harness. В обновлении добавлена поддержка регистрации нескольких URL-адресов ответов (ACS), чтобы клиенты, работающие с Harness в нескольких регионах или средах, могли настроить более одного URL-адреса обратного вызова. Harness включает значение AssertionConsumerServiceURL в запросе на аутентификацию SAML, который он отправляет в Окту. До этого обновления Okta не проверяла это значение для экземпляров приложений, которые не имели дополнительных URL-адресов ACS, и просто вернула утверждение SAML на URL-адрес ACS по умолчанию приложения. После обновления эта валидация активировалась на всех существующих экземплярах приложения, в том числе на тех, где клиент никогда не настраивал дополнительный URL-адрес ACS. Поскольку запрашиваемое значение не присутствовало в зарегистрированном списке, Okta отклонила запрос на аутентификацию с ошибкой HTTP 400. Обновленное приложение прошло через стандартный обзор OIN, который включает в себя проверку обратной совместимости с существующими установками опубликованной интеграции. Это изменение в поведении проверки, например, без дополнительных настроенных URL-адресов ACS, не было обнаружено во время этого обзора, поэтому оно достигло клиентов при выпуске. #4 Реабилитация ** Немедленный ответ** На странице статуса были опубликованы два обходных пути: вход из плитки Harness в Okta \(IdP-инициированный логин\), который не был затронут; или регистрация URL-адреса Okta SSO приложения в поле Дополнительных URL-адресов ACS приложения Harness Okta. Поддержка вовлекала каждого пострадавшего клиента напрямую и проверяла вход с ними. ** Резолюция** Перенос приложения на предыдущую версию был намеренно предотвращен, так как это только отсрочит тот же самый сбой в следующем выпуске. Вместо этого каждый затронутый клиент был разблокирован через регистрацию URL-адресов ACS, и мы работаем с Okta, чтобы сделать валидацию URL-адресов ACS условной снова, так что экземпляры без дополнительных URL-адресов ACS настроены вести себя точно так же, как они делали раньше, и никаких действий клиента не требуется. #5. Пункты действия Чтобы подобные проблемы не повторились, мы работаем над этим. *** Постановление** [править] Работа с Okta для восстановления условной проверки URL-адресов ACS, поэтому экземпляры без дополнительных настроенных URL-адресов ACS ведут себя точно так же, как и раньше, и никаких действий клиентов не требуется. ! Опубликовать специальное руководство по конфигурации для приложения Harness OIN в документации Harness, включая требования к URL ответа \(ACS\). Добавьте независимый шаг предварительной проверки против существующих конфигураций клиентов для любого будущего обновления опубликованного приложения Okta, наряду с собственным обзором Okta. Перенесите аутентификацию пользователя в Harness ID, что полностью устранит зависимость от этого поведения проверки.

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

1. 29 сентября 2026 г. в 18:45 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 29 сентября 2026 г. в 21:55 UTCmonitoring

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

3. 29 сентября 2026 г. в 22:01 UTCresolved

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

4. 2 октября 2026 г. в 22:40 UTCpostmortem

   ###Резюме Между примерно **11:37 AM и 3:01 PM PDT \(18:37-22:01 UTC\) 29 сентября 2026 года** клиенты, использующие автономные облачные бегуны Harness CI в **prod1/prod2 \(us-west1\)**, испытывали периодические сетевые сбои во время выполнения трубопровода — в первую очередь Git/network тайм-ауты при извлечении исходного кода. **Корневая причина** Это было связано, прежде всего, с насыщением нашего NAT, которое в дальнейшем усугублялось временной вычислительной мощностью облачного провайдера, что предотвращало появление новых виртуальных машин. ###Воздействие * Клиенты, работающие под управлением Linux CI, строит в us-west1 видели ** прерывистые сбои сборки / трубопровода **, а не полное отключение. * Наблюдаемые ошибки, связанные с клиентами, включали тайм-ауты Git fetch, например, «Не удалось подключиться к порту 443 github.com: соединение отключено» ** Восстановление** ** Немедленно:** Сбалансированная нагрузка ARM build-VM от насыщенного пути us-west1 к центральному1 \(частично ограниченная емкостью Central1\); перезапуск затронутых шлюзов Cloud NAT, что стабилизировало сеть трубопроводов. ** Пункты действия** 1. Обеспечить дополнительный шлюз NAT/IP \(В процессе реализации\) 2. Улучшить обнаружение насыщения NAT и оповещение перед воздействием на клиента. 3. Оценка непредвиденных обстоятельств, связанных с межрегиональным потенциалом, с тем чтобы нехватка вычислений в одном регионе не препятствовала смягчению последствий отказов.

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

1. 29 сентября 2026 г. в 14:41 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 29 сентября 2026 г. в 15:54 UTCmonitoring

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

3. 29 сентября 2026 г. в 15:57 UTCmonitoring

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

4. 29 сентября 2026 г. в 18:49 UTCresolved

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

5. 2 октября 2026 г. в 05:37 UTCpostmortem

   ** Резюме** Клиенты Prod-2 испытывали повышенные показатели отказов в трубопроводах непрерывной проверки. Проверка рабочих мест не смогла завершить или сообщить об ошибках, потому что сотрудники CV не могли общаться с платформой, которая координирует их работу. Это было вызвано неожиданным всплеском трафика в одной из наших бэкэнд-систем. Сервис был восстановлен за счет масштабирования затронутого компонента платформы. Ни потери данных, ни коррупции не произошло. ** Влияние клиента** Клиенты, использующие Continuous Verification на Prod-2, увидели, что рабочие места в проверочном трубопроводе вышли из строя или вышли из строя во время окна инцидента. Значительная часть вакансий по проверке, которые проводились в течение этого периода, закончились неудачей. Трубопроводы, не использующие CV, продолжали работать нормально. **Корневая причина** Большой автоматический запуск резервирования создал значительное количество постоянных сотрудников по мониторингу резюме в коротком окне, что перегрузило компонент общей платформы. Внезапное увеличение одновременных исходящих вызовов исчерпало доступные сетевые соединения в каждом экземпляре службы. **Смягчение** Был повышен максимальный предел масштабирования для CV-сервиса, что позволило ему расширить мощности для удовлетворения спроса. Неудачи прекратились вскоре после завершения масштабирования. ** Следующие шаги** Чтобы предотвратить повторение, Харнесс: *** Увеличить запас хода и добавить ограждение:** Повышение лимита масштабирования CV-сервиса для поддержания залов под лопнувшими нагрузками и введение ограничения скорости для объемного предоставления контролируемых услуг. ** Улучшить устойчивость:** Добавьте экспоненциальную обратную связь и джиттер для рабочих повторных попыток и используйте пул многоразовых соединений, чтобы уменьшить накладные расходы и предотвратить переходные сбои от соединения при высокой параллели. ** Улучшить мониторинг и оповещение:** Усилить оповещение о ненормальных темпах роста на одного работника, поэтому аналогичные условия обнаруживаются и действуют ранее.

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

1. 29 сентября 2026 г. в 13:12 UTCresolved

   28 сентября 2026 года мы наблюдали проблему с копированием файлов из Harness Filestore на этапе экспорта, где файлы копировались как нулевые / пустые файлы. В результате во время окна инцидента были заблокированы все трубопроводы с использованием API Filestore. Проблема была вызвана развертыванием Feature Flag, которое было отменено после обнаружения проблемы. Все операции вернулись в норму.

2. 1 октября 2026 г. в 17:28 UTCpostmortem

   ###Резюме 28 сентября 2026 года некоторые клиенты на Prod-2 испытали сбои в шагах конвейера CD, которые считывали контент File Store с использованием выражений конвейера \(например, '\). Поврежденные выражения возвращались в нуль вместо ожидаемого содержимого файла, в результате чего зависимые шаги терпели неудачу или вели себя неправильно. Проблема была прослежена до обновления платформы, которое ужесточило проверку авторизации на API файлового магазина. Обновление было отменено, и с тех пор выражения в файловом магазине работают нормально. ###Влияние на клиента * Были затронуты только шаги трубопровода на Prod-2, которые считывают контент File Store через выражения. Трубопроводы, которые не используют выражения файлового магазина, не пострадали. * Поврежденные выражения, разрешенные к нулю, в результате чего шаги, зависящие от конфигурации или настроек файлов, выходят из строя или производят неправильный вывод. * Содержимое файлового магазина не было изменено. Никакие файлы, секреты, учетные данные или артефакты не были раскрыты, и никакие данные не были потеряны. ###Коренная причина В рамках текущей инициативы по безопасности Harness развернул более строгие проверки авторизации на нескольких API-интерфейсах платформы, включая API, который обслуживает контент File Store. Когда конвейер оценивает выражение File Store, одна внутренняя служба Harness вызывает другую для извлечения файла. Новые проверки авторизации не увенчались успехом, в результате чего запросы были отклонены, а выражения были аннулированы. ###Смягчение Как только обновление платформы было идентифицировано как причина, оно было перенесено в производственную среду. Выражения файлового магазина были правильно решены после отката. Никаких действий клиентов не требуется. Профилактические меры и следующие шаги ** Аудиторские API:** Просмотрите все API-интерфейсы, где были применены более строгие проверки авторизации для обеспечения правильного учета внутренних вызовов между службами. *** Улучшить охват испытаниями:** Улучшение автоматизированных наборов тестов для включения оценки экспрессии файлового магазина в пути выполнения конвейера

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

1. 23 сентября 2026 г. в 20:17 UTCinvestigating

   В настоящее время мы изучаем проблемы подключения, затрагивающие клиентов, чьи среды защищены брандмауэрами Palo Alto Networks. Эти брандмауэры блокируют соединения с API Harness, что может привести к: Неудачные казни трубопроводов Невозможность развертывания приложений Периодические тайм-ауты при доступе к функциям платформы Harness Интеграция сбоев со сторонними инструментами Делегатская связь с платформой Harness Эта проблема вызвана не отключением службы Harness, а правилами брандмауэра на вашей стороне сети. Мы советуем клиентам сделать исключение для наших конечных точек DNS.

2. 24 сентября 2026 г. в 08:43 UTCmonitoring

   Смягчение: трафик, заблокированный политикой сетевой безопасности Мы выявили проблему, когда некоторые клиенты могут быть не в состоянии получить доступ к Harness, потому что трафик Harness классифицируется как «AI-Platform» по средствам управления сетевой безопасностью Palo Alto и впоследствии блокируется политикой брандмауэра / INET клиента. Если вы испытываете эту проблему: Пожалуйста, свяжитесь с командой вашей организации Network/Firewall/CyberSecurity и попросите, чтобы требуемый трафик Harness был разрешен через вашу политику брандмауэра Palo Alto. В качестве смягчения последствий клиенты могут разрешить категорию URL «AI-Platform» для требуемых конечных точек Harness или добавить затронутые домены Harness / FQDN в утвержденный / разрешенный список своей организации в соответствии с их политикой безопасности. После обновления политики брандмауэра доступ к Harness должен быть восстановлен. Важно: Политика брандмауэра управляется командой сетевой безопасности клиента. Если конечная точка Harness неправильно категоризирована Palo Alto, клиенты также могут запросить обзор категории URL от Palo Alto Networks.

3. 25 сентября 2026 г. в 17:10 UTCresolved

   После консультации с Palo Alto Networks мы можем подтвердить это 23 сентября 2026 года. io был классифицирован как сервис платформы ИИ командой Palo Alto Networks. В августе Palo Alto Networks направила клиентам уведомление о реклассификации. Это изменение может привести к тому, что сервис платформы AI будет работать по другой политике, чем App.harness. Предыдущие правила классификации io, компьютер и интернет-информация. Применяемая политика зависит от настроек клиента. Клиенты Harness должны обсудить эту категоризацию и оповещения со своей внутренней сетевой командой и Palo Alto Networks.

4. 13 октября 2026 г. в 04:50 UTCpostmortem

   .

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

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

   В настоящее время мы расследуем этот вопрос.

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

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

3. 22 сентября 2026 г. в 18:01 UTCmonitoring

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

4. 22 сентября 2026 г. в 18:38 UTCresolved

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

5. 2 октября 2026 г. в 22:05 UTCpostmortem

   # Резюме 22 сентября 2026 года три наших исходящих сетевых шлюза в одном регионе стали нездоровыми и начали отказываться от небольшого процента новых попыток исходящего подключения. Проблема была решена в тот же день полностью без дальнейшего повторения или последующего воздействия. Основной причиной был насыщенный внутренний буфер мониторинга трафика на этих шлюзах, что привело к тому, что их проверки здоровья реагировали слишком медленно и маркировались нездоровыми. #Влияние * Пострадали только три шлюза в одном регионе; другие регионы и другие шлюзы в том же регионе не пострадали. * Не было каскадного сбоя, проблема была полностью решена с одним раундом перезапуска шлюза, и никаких последующих проблем не произошло после этого. #Коренная причина Наши исходящие сетевые шлюзы запускают внутренний компонент, который контролирует сетевой трафик для оперативной видимости. При устойчивом высоком трафике внутренний буфер этого компонента стал насыщенным, что создало достаточно сильное обратное давление, чтобы замедлить собственные реакции проверки здоровья шлюза за пределами тайм-аута, который позволяет наш балансировщик нагрузки. Как только этот тайм-аут был превышен, балансировщик нагрузки отметил поврежденные шлюзы нездоровыми и начал отклонять часть новых соединений, предназначенных для них. На протяжении всего инцидента продолжала нормально работать фактическая пересылка пакетов. Это была, в частности, проблема проверки состояния здоровья и мониторинга, а не сбой основного пересылочного потенциала шлюзов. # Резолюция Три пострадавших шлюза были перезапущены вручную, что позволило очистить насыщенный буфер мониторинга и немедленно восстановить нормальное поведение. Отказ от подключения прекратился, как только перезапуск завершился, и дальнейшее вмешательство не потребовалось. #Превентивные меры ** Действие** [править] Замените текущий подход к мониторингу трафика на всех шлюзах более эффективной реализацией с более низкими расходами, которая не может насыщать таким образом, и которая предупреждает задолго до любого видимого воздействия на клиента. Реализуйте автоматическую, периодическую замену длительных шлюзовых экземпляров по фиксированному графику, поэтому ни один экземпляр не может накопить тип возрастной деградации, наблюдаемой в этом инциденте. ! | Миграционные шлюзы в оптимизированную для сети инфраструктуру с существенно большей выделенной пропускной способностью сети, лучше подходящей для устойчивого трафика с высокой пропускной способностью. Улучшить использование существующего буфера мониторинга при развертывании долгосрочной замены. Улучшить оповещение, особенно на задержке ответа на проверку здоровья шлюза, чтобы поймать ранние признаки деградации, прежде чем он станет видимым для клиента.

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

1. 22 сентября 2026 г. в 14:00 UTCidentified

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

2. 22 сентября 2026 г. в 14:08 UTCmonitoring

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

3. 22 сентября 2026 г. в 14:20 UTCresolved

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

4. 2 октября 2026 г. в 22:10 UTCpostmortem

   Как и предыдущая первопричина.

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

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

   В настоящее время мы расследуем этот вопрос.

2. 21 сентября 2026 г. в 17:12 UTCidentified

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

3. 21 сентября 2026 г. в 18:27 UTCmonitoring

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

4. 21 сентября 2026 г. в 18:33 UTCresolved

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

5. 29 сентября 2026 г. в 22:39 UTCpostmortem

   ##Резюме 21 сентября 2026 года клиенты Prod 2 испытали ухудшение состояния, а затем в течение примерно трех часов оставались недоступными для развертывания. Проблема была вызвана набором аналитических запросов за этими приборными панелями, считывающими гораздо больше данных, чем им нужно, что исчерпало возможности базы данных, обслуживающей их. Перезапуск затронутого сервиса полностью восстановил приборные панели, и с тех пор платформа стабильна. ##Влияние на клиента Страницы панели инструментов загружаются медленно или отсчитываются между 14:48 и 18:11 UTC. Запись выполнения и развертывания трубопроводов ведется на отдельной инфраструктуре и продолжает работать в штатном режиме. Ни потери данных, ни коррупции не произошло. ##Коренная причина В запросах приборной панели отсутствовал фильтр диапазона времени на столбце, используемый для разделения самой большой таблицы на еженедельные сегменты, поэтому каждый запрос считывал все исторические данные вместо только запрашиваемого периода. Корректность никогда не затрагивалась — приборные панели возвращали правильные результаты; только количество прочитанных данных было чрезмерным. По мере роста объема данных стоимость этих считываний превышала то, что могла обслуживать база данных, а повторные запросы по неисправным запросам добавляли дополнительную нагрузку, поэтому состояние не прояснялось до перезапуска службы. ##Смягчение * Выполнил перезапуск пострадавшей службы, что остановило цикл повторного запуска и позволило базе данных завершить выдающуюся работу * Подтвержденная задержка приборной панели и использование подключения к базе данных вернулись к нормальным уровням ## Следующие шаги Чтобы предотвратить повторение, Харнесс: * Добавить недостающий фильтр диапазона времени к затронутым запросам панели инструментов, чтобы каждый считывал только запрошенный период * Заменить немедленные повторные записи ограниченными, резервными Улучшить обнаружение путем добавления оповещения об использовании подключения к базе данных и стоимости выполнения каждого запроса

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