Split 장애 기록

1. 2026년 9월 5일 AM 9:40 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 9월 5일 AM 9:40 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 9월 3일 AM 10:00 UTCinvestigating

   파이프 실행은 Prod1에 붙어 있습니다. 우리는 문제를 조사하고 있습니다.

2. 2026년 9월 3일 AM 10:28 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

3. 2026년 9월 3일 AM 11:40 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 28일 AM 7:04 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 28일 AM 7:16 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 28일 AM 7:29 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 28일 AM 7:35 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 9월 2일 PM 10:15 UTCpostmortem

   ## 요약 8월 27일과 8월 28일 사이에, 고객은 일부 파이프라인, 배포 및 관련 리소스가 하네스 UI 및 API에서 발견되지 않았기 때문에 기존 데이터가 그대로 남아있는 문제를 경험했습니다. 이 문제는 내부 플랫폼 서비스의 영향을받는 내부 인프라 업데이트 중 발생했습니다. 결과적으로, 계정에 의존하는 요청, 조직 및 프로젝트 범위 해상도는 성공적으로 완료 할 수 없었다, 이는 기존 엔티티티에 대한 고객에게 반환되지 않은 응답을 찾을 수 없습니다. 공학은 문제를 확인, 변경을 압연, 그리고 정상적인 서비스를 복원. 고객 데이터는 사건 중 손실되거나 삭제되지 않았습니다. ## 뿌리 원인 이 문제는 생산에 계획 된 내부 서비스 라우팅 업데이트 중에 도입 된 구성 오류에 의해 발생했습니다. 계정, 조직 및 프로젝트 컨텍스트를 해결하는 데 책임있는 내부 플랫폼 서비스는 변경 후 다른 하네스 서비스에서 요청을 유효하지 못했습니다. 이 웹 사이트는 귀하가 웹 사이트를 탐색하는 동안 귀하의 경험을 향상시키기 위해 쿠키를 사용합니다. 이 쿠키들 중에서 필요에 따라 분류 된 쿠키는 웹 사이트의 기본적인 기능을 수행하는 데 필수적이므로 브라우저에 저장됩니다. 이 문제는 영향을받는 생산 환경에 제한되어 이전 서비스 통신 경로를 반전하여 해결되었습니다. ## 충격 * 일부 고객은 기존의 파이프라인, 배포 및 관련 엔티티티가 UI 및 API에서 찾을 수 없습니다. * 일부 파이프라인 관련 작업, 실행 진행을 포함, webhook-triggered 시작, 예정된 트리거 평가, 그리고 조직 목록, 일시적으로 중단. * 기존 엔티티티티의 가용성 및 가시성에 영향을 미치는 문제는 데이터 또는 고객 구성을 변경하지 않았습니다. * 무단 액세스가 발생하지 않으며 고객 데이터 손실이 관찰되지 않았습니다. ## 구제 * ** 멀티미디어:** 인프라 구성 업데이트 및 이전 작업 서비스 통신 경로를 복원. * ** 복구 유효성:** 영향을받는 기업 검색, 파이프라인 운영 및 의존 API는 일반적으로 롤백 후 기능을 수행했다. * ** 영구:** 업데이트와 관련된 구성 취급을 수정하므로 유사한 문제는 향후 롤아웃에서 서비스 인증을 방해하지 않습니다. ## 작업 항목 다시 일어나고 있는 그런 문제를 방지하기 위하여, 마구 의지 1. 생산 트래픽을 이동하기 전에 내부 서비스 통신을 확인하기 위해 사전 배포 테스트를 강화하여 구성 검증을 향상시킵니다. 2. 내부 인증 실패에 대한 모니터링 및 경고를 강화하기 때문에 문제는 이전에 감지 될 수 있습니다. 3. 오류 처리가 너무 의존성 실패는 오류를 발견하지 않는 자원으로 고객에게 나타나는 가능성이 적습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 26일 AM 8:38 UTCinvestigating

   우리는 현재 Prod-1, Prod-2, Prod-4 및 EU1 하네스 클러스터에 IACM 파이프라인에보고 된 문제를 조사하고 있습니다.

2. 2026년 8월 26일 AM 8:43 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 8월 26일 AM 9:05 UTCmonitoring

   우리는 모든 클러스터에서이 문제를 발생시키는 변화를 회상했습니다.

4. 2026년 8월 26일 AM 9:10 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 24일 AM 12:57 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 24일 AM 1:01 UTCinvestigating

   우리는 현재 조사 보고서는 기능 관리 및 실험 (FME) 사용자 인터페이스가 로드에 실패한다는 것입니다. FME 콘솔에 액세스하려고 하는 고객은 오류 또는 응답 페이지가 발생할 수 있습니다. 기능 플래그 평가 및 SDK 트래픽은 영향을받지 않습니다. 더 많은 업데이트가 곧 따를 것입니다.

3. 2026년 8월 24일 AM 1:08 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 24일 AM 1:12 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 27일 PM 11:36 UTCpostmortem

   ## 요약 * 부터 **23:42 UTC** 에 8월 23, 2026, 몇몇 FME 고객은 FME UI를 적재하는 실패를 보고했습니다. * FME UI Artifacts는 보존 정책으로 인해 만료 된 CDN에서 제공되며, FME UI가 로드에 실패합니다. * API를 통해 어떤 깃발 요구든지, 납품을 바꾸고, 자료 파이프라인은 중단 없이 일하기 위하여 계속합니다. ## 뿌리 원인 * FME UI는 CDN에서 제공됩니다. UI artifacts는 유지 정책으로 인해 evicted를 얻었으며 UI가 모든 사용자를 위해로드하지 못했습니다. ## 충격 * FME UI는 모든 생산 환경에서 모든 사용자를 로드할 수 없습니다. ### 어떤 영향을 미치지 않았습니까? * SDK 기능과 런타임 플래그 평가 * Admin API 호출 * 고객 플래그 설정 데이터 * 데이터 손실 없음 ## 구제 * FME UI는 배포를 통해 CDN에 복원 * 복구는 사건을 닫기 전에 모든 생산 환경에서 확인. ## 작업 항목 * 자산 유지 정책을 개선하기 때문에 현재 활성 버전은 퇴거 할 수 없습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 20일 PM 3:37 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 20일 PM 4:05 UTCinvestigating

   슬픔은 다음과 같은 증상을 일으킬 수 있습니다. - 시작하지 않는 파이프 라인 - 실행 지연 - timeouts로 인한 파이프 라인

3. 2026년 8월 20일 PM 4:22 UTCinvestigating

   우리의 클라우드 공급자는 적극적인 사건을 직면하고 있으며 우리는 다음과 같습니다.

4. 2026년 8월 20일 PM 4:32 UTCinvestigating

   이 문제를 조사하고 있습니다.

5. 2026년 8월 20일 PM 4:50 UTCidentified

   우리의 클라우드 공급자는 여러 지구에 영향을 미치는 지속적인 사건을 확인했습니다. 하네스 라인은 결과적으로 실패를 경험하지 못했습니다. 일부 사용자는 느린 경험을 계속할 수 있습니다. 우리는 상황을 밀접하게 감시하고 더 많은 정보로 업데이트를 제공할 것입니다.

6. 2026년 8월 20일 PM 5:17 UTCmonitoring

   우리는 우리의 클라우드 공급자에 의해 구현 된 수정을 따르는 보드를 통해 향상된 latencies를 관찰하고 있습니다. 우리는 상황을 밀접하게 모니터링하고 더 많은 업데이트를 보장 할 것입니다. CI에 대한 몇 가지 갇힌 실행을 언급했습니다

7. 2026년 8월 20일 PM 7:23 UTCresolved

   이 사건은 해결되었습니다.

8. 2026년 8월 26일 AM 4:57 UTCpostmortem

   # 요약 20 8월 2026일, 대략 15:00 UTC에 시작된 하네스 플랫폼은 모든 생산 환경에 걸쳐 광범위한 성능 평가를 경험했습니다. 일반적으로 약 2 분 만에 완료하는 파이프 라인 실행은 7 ~ 10 분 정도 걸립니다. 지속적인 납품, 지속적인 통합, 파이프라인 관현관 및 특징 관리 & 실험은 전부 영향을 미쳤습니다. Google Cloud Platform은 Bigtable, Compute Engine, Google Kubernetes Engine 및 persistent-disk I/O. 하네스 프로덕션 인프라에 영향을 미치는 us-west1 지역의 멀티 제품 사고를 경험했습니다. degradation는 대략 2개 ms에서 95 %ile에 10 ms에 대략 2개 ms의 데이타베이스 가동 지연을 올리고 적시 데이타베이스 접근에 달려 있는 각 서비스에 propagated. # 충격 이것은 학대가 아니었다. 파이프 라인은 성공적으로 수행하고 완료하기 위해 계속; 그들은 실패보다 느리다. 데이터가 손실되지 않았고, 고객이 이 사건의 결과로 떨어졌다. # ** 루트 원인 ** 영향을받는 환경에서 생산 인프라는 Google Cloud Platform persistent disks에서 실행됩니다. 저장 층이 degraded 때, 예측 가능한 사슬에 있는 플랫폼을 통해 전파되는 효력: **우리-서부1에서 독립 디스크 I/O 분해.** Google Cloud Platform은 Bigtable, Compute Engine, Google Kubernetes Engine 및 persistent-disk 성능에 영향을 미치는 멀티 제품 사건을 경험했습니다. 이것은 공급자의 환경, 외부 마구의 통제에 있는 인프라 실패입니다. # ** 사전 행동 ** 하네스는 클라우드 공급자 인프라 실패를 방지할 수 없습니다. 아래 작업은 더 빠르게 감지하고 더 나은 행동을 목표로합니다. |**액션** | 인포메이션 | Continue routine는 이 사건에서 수행되는 것과 같이, 타겟이 횡단식 데이터베이스 장애를 사전에 테스트하여, 실패를 읽을 수 있도록 합니다 | | 횡단보도의 횡단보도의 횡단보도의 횡단보도의 횡단보도 대응 |

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 20일 PM 2:32 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 20일 PM 2:47 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 20일 PM 2:56 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 20일 PM 3:02 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 23일 PM 9:45 UTCpostmortem

   ### 요약 에 8월 20, 2026, 사이 10:24 과 14:55 UTC, 하위 세트의 FME 쓰기 실패. FME UI에서 작성하고 하네스 액세스 토큰 \(PATs 및 SATs\)로 만든 쓰기는 영향을 미치지 않았습니다. Runtime flag 평가는 일반적으로 작동합니다. 이 문제는 공유 관할 서비스에서 최근의 인증 변경을 반전하고 14 : 55 UTC에 의해 정상으로 돌아올 수 있습니다. 상태: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ### 뿌리 원인 FME가 거부되는 몇 가지 FME 글에 결과된 공유지속 서비스(SharedGovernance Service)가 호출되는 방법에 대한 변화. 이러한 사용 된 서비스 - 서비스 자격 증명을 작성하여 지배적 서비스가 변경 후 더 이상 확인 할 수 없습니다. FME 표면은 HTTP 499로 클라이언트에 거버넌스 실패, 지배 정책 의도적으로 변화에 따라 사용되는 동일한 상태. 499는 유효하기 때문에, 그 deny 경로에 있는 예상된 응답, 실패는 우리의 경고에 정전 같이 보고하지 않았다, 그리고 사건은 내부 탐지 보다는 오히려 고객 보고에서 확인되었습니다. ### 충격 * FME의 하위 설정은 윈도우에서 실패, 주로 레거시 Split API 키 또는 변경 요청 스케줄링을 사용하여 만든. * FME UI에서 작성된 글은 영향을받지 않았습니다. * 하네스 액세스 토큰 \ (PATs 및 SATs \)를 사용하는 것은 영향을받지 않았습니다. * Runtime flag 평가는 일반적으로 계속됩니다. * 데이터 손실이 발생하지 않습니다. 실패는 적용되지 않았다. ### 구제 주관 서비스 인증 변경을 거쳤습니다. Affected는 즉시 정상적인에 반환. ### 활동 항목 이런 문제를 다시 발생시키려면 * 하네스는 통치자가 평가되지 않았기 때문에 쓰기가 실패할 때 별도의 오류 \(499\)를 반환합니다. 따라서 의도적 정책에 혼동되지 않습니다. * 지분 평가에 대한 경고 추가는 클라이언트의 상태 코드에 의존하는 것보다 자체로 호출됩니다. * 정책 평가에 대한 인증 지원 확장. * 추가 쓰기 시나리오에 대한 자동화 적용 확대.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 19일 PM 1:22 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 19일 PM 2:55 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 8월 19일 PM 3:13 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

4. 2026년 8월 19일 PM 3:22 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

5. 2026년 8월 19일 PM 3:33 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

6. 2026년 8월 19일 PM 4:07 UTCresolved

   이 사건은 해결되었습니다.

7. 2026년 8월 26일 PM 5:20 UTCpostmortem

   ** 일정 ** 19 8 월 2026 사이 12 : 35 및 17 : 29 UTC, 하네스 응용 프로그램 보안 서비스는 고객 회의 콘솔과 SaaS 생산 및 US1 지역의 데이터 섭취 파이프라인에 영향을 미치는 중요한 혼란을 경험했습니다. ** 루트 원인 ** 런타임 설정을 거의 모든 다른 구성 요소에 공급하는 내부 구성 서비스는 과부하되고 반복된 재시작 사이클을 입력했습니다. 그래서 많은 서비스는 그것에 달려 있기 때문에, 효력은 넓었습니다: 보호 정책과 같은 콘솔 페이지, 자세 전망, 활동 기록, API 재고목록 및 주문 정책은 적재하거나 밖으로 실패하고, 윤곽을 위해 기다리는 동안 가동 중단한 처리는 그것을 얻을 수 없었습니다. # ** 고객 영향** 인포메이션 인포메이션 인포메이션 인포메이션 인포메이션 | 콘솔 \(UI\) 충격 | 다중 페이지는 보호 정책, 자세 이벤트 페이지 및 자세 보기를 포함하여 로드 또는 시간이 지남에 실패했습니다. 대시보드 및 통찰력 페이지, 활동 로그 쿼리, API 재고 화면, 사용자 정의 정책 및 민감한 데이터보기 및 위젯. · | Ingestion impact | 보안대칭 처리가 심각하고, 일부 경로에서 완전히 중단되었습니다. 소비자 래그는 정상화, 그룹화, anomaly 탐지, 세대 및 관련 처리 단계의 맞은편에 성장합니다. · | Data loss | 끊임이 영구적으로 떨어졌습니다. · ** 소송 ** 여러 중간 완화 추가 CPU 및 메모리, 편안한 건강 검사 임계 값, 데이터베이스 재시작, 그리고 더 큰 연결 풀은 문제를 격리. 영향을받는 지역 모두에서 새로운 기능을 비활성화하여 처리 된 처리량을 급격히 회복하고 durably. 사건은 17:29 UTC에서 해결되었습니다. # ** 사전 행동 ** 다음과 같은 행동은 내부적으로 완료됩니다. 이 사건을 트리거 한 기능은 비활성화되어 아래 작업이 완료되고 검증 될 때까지 재 활성화되지 않습니다. |**액션** | 인포메이션 |한국어 | 시렁 퇴치 및 유지와 같은 튜닝 매개 변수에 의해 코드를 OPtimize, 규칙 개수로 벌크 규칙 retrieval에 대한 커서 기반 pagination을 평가합니다 | | 서비스 이용을 위한 목적으로 만들어진 데이터베이스 인덱스를 추가| | Remediate 파이프라인 복구 semantics so consumer replay safe after position-marker loss 대신 Skipping backlog | | 설정 오버라이드를 위한 위임된 롤아웃은 다운스트림 요청 패턴을 변경합니다: 저하량 클러스터, 그중량, 그중량 | | 구성 서비스에 대한 backpressure 및 concurrency 보호 추가 : 회로 끊기, 경계 queues, 및 타임 아웃 고립 | | 더 상세한 메트릭으로 관찰 가능 |

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 6일 PM 2:30 UTCinvestigating

   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.

2. 2026년 8월 6일 PM 2:32 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026년 8월 6일 PM 3:46 UTCidentified

   The issue has been identified and a fix is being implemented.

4. 2026년 8월 6일 PM 4:01 UTCresolved

   This incident has been resolved.

5. 2026년 8월 10일 PM 6:24 UTCpostmortem

   ## 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.

1. 2026년 8월 6일 PM 1:50 UTCmonitoring

   Prod2에 있는 붙어 있는 파이프라인을 감시하고 있습니다. 새로운 실행은 우리가 지속적으로 서비스를 모니터링 하는 역할을 합니다.

2. 2026년 8월 6일 PM 4:58 UTCmonitoring

   Prod2에 있는 붙어 있는 파이프라인을 감시하고 있습니다. 아직도 붙어 있던 파이프라인을 보인 고객을 위해, 우리는 당신을 구부리고 re-trigger 요구합니다.

3. 2026년 8월 6일 PM 6:21 UTCresolved

   이 사건은 해결되었습니다.

4. 2026년 8월 17일 PM 6:40 UTCpostmortem

   ## **Summary ** 8 월 6, 2026 \ (morning PDT \), Prod2 생산 환경에서 파이프라인을 실행하는 일부 고객은 진행을 중단 한 파이프라인 실행을 관찰 - 더 출력 또는 상태 업데이트하지 않았다 단계. 문제는 영향을받는 고객에 의해보고되었습니다. 하네스 엔지니어는 원인을 확인, 충격을 감소, 파이프라인 실행은 정상 작동에 반환. 이 문제는 자체 공시 파이프라인 표현에 의해 발생했습니다. Git webhook는 webhook 페이로드의 내용을 참조하는 파이프라인을 트리거하고, 그 동일한 표현의 추가 사본을 포함합니다. 각 원의 표현 해상도를 따라서 더 많은 표현을 해결하기 위해, 각 작업의 양을 다루. 이 서비스 인스턴스 처리의 리소스를 소진하고, 같은 인스턴스에 할당된 다른 실행은 그 상태에 있었던 동안 진행할 수 없습니다. ## ** 중요 ** 사건 창 중 \(약 6 : 11 AM에서 11 : 23 AM PDT 8 월 6, 2026 \) : * Prod2의 일부 고객의 파이프 라인 실행 중-execution을 뚫고 더 발전하지 않았습니다. * 새로운 단계 출력 또는 상태 업데이트가 생성되지 않았고, 완화 후 aborted 및 재 실행해야했습니다. * Behavior는 영향을받는 서비스 인스턴스에 의해 처리되는 실행에 제한되었습니다. 다른 인스턴스에 의해 처리 된 파이프라인은 일반적으로 수행됩니다. ** 데이터 손실 없음 **. Pipeline 정의, 실행 역사, 그리고 저장된 상태는 불완전했다. Prod2의 대부분의 파이프라인은 사건을 성공적으로 수행하기 위해 계속되었습니다. 1 차적인 충격은 문제가 mitigated 한 번 다시 실행할 필요가 없다는 것입니다. ## ** 루트 원인 ** 하네스 파이프 라인은 runtime에서 해결되는 표현식을 지원한다. 예를 들어, 파이프라인을 트리거 한 Git webhook 페이로드의 내용을 삽입하는 표현. 이 경우, Git 커밋 메시지에는 payload expression 자체의 리터 텍스트, 두 번, 동일한 페이로드 표현을 참조 한 파이프라인이 포함되어 있습니다. 커밋 메시지는 webhook 페이로드의 일부이므로, 커밋 메시지에서 수행된 표현의 두 리터 사본을 포함하여 전체 페이로드를 삽입하는 표현을 해결합니다. 이러한 새로 삽입된 복사본은 수정된 표현으로 처리되었고, 각 패스는 페이로드의 두 개의 전체 사본을 삽입했습니다. 처리되는 가치의 크기와 프로세스에 필요한 작업, 따라서 모든 패스에 이중화하고 집중보다는 폭발적으로 성장. 하네스는 이 문제를 해결하기 위해 안전한 가드를 갖는다: 표현 해상도는 halts와 파이프라인이 명시된 오류로 실패하는 최대 배열 깊이에 의해 경계된다. 안전에 대한 결함은 한계가이 특정한 자력적인 경우에 적용되지 않았으므로 해결되지 않았습니다. Expression Resolution은 파이프라인 단계를 시작하는 스레드에 인라인을 실행합니다. 각 패스로 인해 진보적으로 더 많은 메모리와 CPU가 완료되지 않고, 서비스 인스턴스는 작업을 진행 중지하고, 그 인스턴스에 할당 된 모든 실행은보고 된 것. ##**심사** 하네스는 다음과 같은 즉각적인 완화 단계를 완료했습니다. * 런웨이 해상도의 파이프라인과 표현 패턴을 식별합니다. * 영향을받는 서비스 인스턴스를 중지하여 더 이상 작동하지 않을 것입니다. 나머지 건강한 인스턴스는 일반적으로 할당 및 처리한 실행을 선택합니다. * 관행은 정상에 돌려보내고 사건을 닫았습니다. 이 작업은 정상적인 파이프라인 실행 행동을 복원하고 고객 기반 영향을 해결했습니다. ##**Action 항목** 재발력의 위험을 줄이고 탐지를 개선하기 위해 다음과 같은 행동은 구현되는 다양한 단계에 있습니다. * 표현 깊이 및 루프 검출에 대한 결함을 수정하여 자기 공명 표현이 붙잡고 경계없이 소모 자원 대신 명확한 오류로 신속하게 실패합니다. * 트리거 페이로드 콘텐츠에서 해결되는 페이로드 표현을 방지하고, 자기 잔존 경로를 완전히 제거하십시오. * 최대 표현식 배열 깊이를 강화하고 기존의 깊이 한계 이외에 명시된 루프 감지를 평가합니다. * 자동적 표현 패턴을 재현한 사전 제작 환경에서 자동화된 테스트를 강화하고 Safeguard가 감지하고 중지하는 것을 확인합니다. * 파이프라인 실행에 있는 이 본을 위한 감시를 추가하십시오 그래서 proactively 검출됩니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 8월 4일 PM 12:07 UTCinvestigating

   We are currently investigating this issue.

2. 2026년 8월 4일 PM 12:17 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026년 8월 4일 PM 1:00 UTCinvestigating

   We have identified the issue and started to implement the fix , prod2 is restored.

4. 2026년 8월 4일 PM 1:09 UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.

5. 2026년 8월 4일 PM 1:16 UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.

6. 2026년 8월 4일 PM 3:28 UTCresolved

   This incident has been resolved.

7. 2026년 8월 6일 PM 5:02 UTCpostmortem

   # 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.

1. 2026년 8월 3일 AM 3:08 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 3일 AM 3:37 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

3. 2026년 8월 3일 AM 5:53 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 31일 PM 8:22 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 1일 AM 2:41 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 1일 AM 5:45 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 1일 AM 9:11 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 21일 AM 4:19 UTCpostmortem

   # ** 일정 ** 25 7 월과 4 8 월 2026 사이, 파이프 라인 실행 대쉬보드 및 하네스 Prod 2의 개요 페이지 및 Prod 3 클러스터는 실시간으로 사이에 표시되는 데이터를 표시합니다. Pipelines 자체가 지속적으로 구축, 배포 및 일반적으로 실행; 문제는 신속하게 실행 레코드가보고 및 대쉬보드보기를 제공하는 데이터베이스에 복사 된 방법에 대해 확신했다. ** 고객 데이터가 손실되지 않았습니다. ** 모든 영향을받는 기록은 두드러지게 보관되어 분석 데이터 저장소로 재생되었습니다. 하네스는 1 8월 2026일 복제 구성 요소의 queue-backed 버전의 수평으로 확장 가능한 클러스터에 영향을 미치며 모든 영향을받는 계정의 대상 데이터 백필을 완료했습니다. # ** 루트 원인 ** 하네스는 1차 운영 데이터스토어에서 파이프라인 실행 기록을 지속적으로 복제하는 변경 데이터 캡처 구성 요소를 유지하며 대시보드 및 보고 쿼리에 최적화된 별도의 시간 시리즈 데이터 저장소로 유지합니다. Dashboards는 분석 datastore에서 독점적으로 읽습니다. 복제가 뒤떨어질 때, 대쉬보드는 전 세계의 정확한 이전보기를 렌더링하고, 자체를 실행하는 것은 비범죄입니다. 이 날카롭게 발생, 데이터베이스에서 지속적인 증가는 다른 하네스 플랫폼 모듈에서 동일한 복제 경로를 공유하는 다른 볼륨을 쓰기, 그 구성 요소의 단일 인스턴스 버전은 여전히 Prod 2 및 Prod 3.에서 실행. backlog는 형성되고 성장합니다. # ** 사전 행동 ** 마구는 그런 문제를 방지하기 위하여 뒤에 오는 행동에 완료하거나 투입했습니다. |**액션** | 인포메이션 | 정의된 임계값을 초과하지 않는 지연을 경고하기 때문에 복제 지연을 수정합니다 | | 표준 플랫폼 모니터링 보드에 복제 지연 패널을 추가하여 파이프라인의 건강이 기본으로 호출됩니다 | | 복제 스트림에 대한 per-module rate limiting or entity filtering을 통해 co-tenant 모듈에서 증폭을 줄입니다 |

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 31일 PM 1:48 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 8월 1일 AM 2:34 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 8월 1일 AM 2:44 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 8월 1일 PM 11:49 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 13일 AM 12:50 UTCpostmortem

   # ** 일정 ** 7월 31일, 2026일, EU1 클러스터의 파이프라인을 통해 수행되는 예측 업로드는 인증 오류로 실패했습니다. 수동으로 시작된 업로드 \( 파이프라인의 외곽)은 영향을받지 않았으며, 기존의 artifacts \(downloads\)를 검색할 수 있는 능력도 비공개되었습니다. 이것은 하나의 클러스터의 특정 파이프라인 업로드 경로에 격리되었습니다. # ** 중요 ** * EU1 클러스터의 파이프라인을 통해 수행 된 Artifact 업로드는 약 4 시간 및 34 분 동안 인증 오류로 실패했습니다. * 기존의 artifacts \ (downloads\)를 검색하는 것은 영향을 미치지 않았습니다. * 파이프라인 외부의 수동으로 업로드는 영향을 미치지 않았습니다. * 다른 클러스터/지역은 이 문제점에 영향을 미치지 않았습니다. # ** 루트 원인 ** 파이프라인 기반 artifact uploads을 처리하는 구성 요소는 컨테이너 이미지로 배포됩니다. EU1 클러스터에서, 이 이미지는 공공 이미지 소스를 미러링 내부 레지스트리에서 재생됩니다. 다른 클러스터에서 동일한 이미지는 대중 소스에서 직접 검색됩니다. 우리의 릴리스 프로세스의 게시 오류는 이미 사용중인 버전 라벨을 사용하여이 구성 요소의 새로운 빌드를 발생, 오히려 새로운 할당 된 것보다, 독특한 버전. 결과적으로 두 개의 다른 이미지가 공개 소스에서 동일한 버전 라벨과 관련된 종료되었습니다. 우리의 내부 레지스트리 미러는 자동화 된 복제 프로세스를 통해 공공 소스의 이미지. 복제가 트리거 된 방법 때문에, 수정 된 것보다는 버전 라벨과 관련된 원래 \ (earlier\) 이미지를 복사했습니다. 이 의미는 EU1 클러스터 - 내부 미러에서 끌어 - 다른 클러스터보다 서로 다른, 결함 이미지를 실행 종료, 공공 소스에서 직접 잡아 따라서 올바른 이미지를 받았다. 불완전한 이미지는 파이프를 생성하는 인증 문제가 발생했습니다. # ** 소송 ** * 업로드 구성 요소의 마지막 알려진 좋은 버전에 영향을받는 계정을 되돌아, 즉시 파이프 라인 업로드를 복원. * 모든 클러스터를 통해 문제를 해결하기 위해 부품의 정정, 영구 버전. #**다음 단계** * 이 실패 형태를 가능한 한 완성 된 컨테이너 관련 결함을 제거하기 위해 업로드 단계를 수정합니다. * 이 구성 요소에 대한 우리의 릴리스 파이프라인을 업데이트하여 이미지를 게시 할 수 없습니다 기존 버전을 작성할 수 없습니다. 모든 게시는 새로운, 명백한 버전이 앞으로 이동해야합니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 30일 AM 5:59 UTCinvestigating

   요약 - 우리는 외부 리소스에 연결할 수없는 Build VM과 네트워크 연결 문제를 해결합니다. 우리는 현재 문제를 조사하고 있습니다.

2. 2026년 7월 30일 AM 8:07 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

3. 2026년 7월 30일 AM 8:07 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

4. 2026년 7월 31일 AM 3:22 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 7일 PM 7:32 UTCpostmortem

   ## 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..

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 27일 AM 9:09 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 7월 27일 AM 9:22 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

3. 2026년 7월 27일 PM 1:33 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 27일 AM 7:52 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 7월 27일 AM 8:13 UTCinvestigating

   이 문제를 조사하고 있습니다.

3. 2026년 7월 27일 AM 9:04 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

4. 2026년 7월 27일 AM 9:05 UTCidentified

   이 문제를 해결하기 위해 계속 노력하고 있습니다.

5. 2026년 7월 27일 AM 9:07 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

6. 2026년 7월 27일 AM 9:09 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

7. 2026년 7월 27일 PM 1:33 UTCresolved

   이 사건은 해결되었습니다.

8. 2026년 8월 7일 PM 6:15 UTCpostmortem

   # 요약 최근의 생산 배치 동안, 우리의 내부 배치 도구에 결함은 우리의 생산 환경에서 잘못된, 비 생산 구성 값을 실행하는 두 가지 중요한 서비스를 발생 이 4개의 명백한 증후의 관련 세트로 지도했습니다: 잘못된 윤곽 행동, 간헐적인 로그인/액세서리 실패, 1개의 고객 환경에 영향을 미치는 파일스토어 접근 문제점 및 UI에 있는 지연된 파이프라인 상태 갱신. 우리는 식별하고 기본 구성 결함에 대한 영구 수정을 구현하고 이미 UI 지연 증상을 해결하는 장소 자원 및 용량 변경에 넣어. 이 사건 중 아무 점도 파이프 라인 실행 자체 손실, 손상, 또는 갇힌 상태에서 왼쪽. 실행 행동이 영향을 받지 않은 상태 가시성에 지연을 제한했다. # Incident 세부사항 ## Incorrect 생산 구성 값 적용 우리의 엔지니어링 팀은 적절한 생산 구성보다는 다른 환경을위한 구성 값을 사용하여 특정 생산 서비스를 배치하는 서비스 관리자 배포 파이프라인의 결함을 확인했습니다. ** 루트 원인 ** 배치 동안 구성 overrides를 fetching에 책임있는 서비스는 요청 당 최대 1,000 결과를 반환하는 내부 API를 쿼리합니다. 환경의 총 수는 최근에 그 한계를 넘어 성장. 결과적으로, 첫 번째 1,000을 초과하는 모든 서비스는 응답에 포함되지 않았고, 배포 파이프라인은 침묵적으로 그 서비스에 대한 기본 설정 값으로 다시 떨어졌다. 이것은 배포 툴링에서 확인 된 pagination 결함이며 구성 값이 자체에 문제가 없습니다. ** 해결책 ** 엔지니어링은 메커니즘을 확인하고 배포 파이프라인의이 한계 관련 격차를 제거하는 영구적 인 수정을 구현합니다. ## Intermittent 로그인 / 액세스 실패 위에서 언급 한 Service Manager 배포 중 일부 사용자는 Intermittent 로그인 또는 액세스 실패를 경험했습니다. 정상적인 작동 하에서, 이전 실행 인스턴스는 계속 중단 없이 트래픽을 제공 해야 합니다 새로운 배포 진행 중. 이 사건에서, 그 fallback 행동은 예상대로 발생하지 않았다, 배포 창에서 액세스 실패에 기여. ## Filestore 액세스 문제 파일스토어 액세스 이슈는 Prod-3 환경과 단일 고객의 환경에 영향을 미쳤습니다. ** 루트 원인 ** 이것은 서비스 관리자의 IAM / Storage-bucket 권한 구성과 관련되며, 롤백 활동에 의해 잠재적으로 트리거됩니다. ## Delayed Pipeline 실행 상태 업데이트 UI 일부 사용자는 UI의 파이프라인 실행 그래프가 새로 고침하고 최신 상태를 신속하게 반영하지 못한다는 것을 관찰했다. 중요한 것은 가시적 지연 만이었다 : 실제 파이프라인 실행에 영향을 미치지 않았고, 이 문제의 결과로 실패하지 않았습니다. ** 루트 원인 ** 파이프라인 실행 그래프는 상태 업데이트를 수신하기 위해 메시지 스트림 \(성능 로그 \)에 의존합니다. 사건 창 도중, 이 스트림의 소비자 처리는 \(high Consumer lag\) 뒤에 떨어졌다, 이는 빠른 상태 업데이트가 UI에 도달하는 방법을 지연. 이 결과적으로 데이터베이스가 같은 시간에 계획 된 스케일링 작업의 중간에 있었다는 사실에 의해 발생, 그 창에서 트래픽 스파이크 더 지연을 배부. 사용자들은 일반적으로 실행되었더라도 파이프라인의 느리게 경험했습니다. ** 해결책 ** 우리는 영향을받는 구성 요소에 대한 리소스 용량을 증가하여 50 % 이상의 예비 헤드 룸이 앞으로 진행되고, 유사한 부하 스파이크에 대한 감도를 감소시킵니다. 이 변경은 구현되고 현재 플랫폼의이 부분에 대한 장기적인 경화의 일부로 검증됩니다. # 충격 요약 * Prod-1 및 Prod-3 환경에서 잘못된 구성 값으로 서비스 관리자 및 라이센스 관리자 ran. * 일부 사용자는 영향을받은 배포 창에서 간헐적인 로그인 또는 액세스 실패를 경험했습니다. * Prod-3에 있는 1개의 소비자 환경은 filestore 접근 문제점을 경험했습니다. * 영향을받는 환경의 사용자들은 UI에서 파이프라인 실행 상태 업데이트를 연기했습니다. 따라서 파이프라인 실행은 올바르게 실행되지 않았고, 갇힌, 또는 손상되지 않았습니다. # 예방 조치 다음과 같은 교정 및 예방 조치가 확인되었습니다. | **차례 / 예방 조치** | 인포메이션 | 구성-lookup 서비스에 pagination limit을 수정하여 모든 서비스가 반환되고 평가되어 총 수에 관계없이 평가됩니다. | | 구성을 검색할 수 없는 서비스가 안전하다는 것을 추가하십시오.(예: alerts and block the deploy\) 오히려 비생산적인 기본값으로 다시 떨어지는 것. · | 포스트그레와 메시징 파이프 자원 헤드룸 \(target: 50% 이상의 예비 용량 \)를 증가하여 동시 부하 및 스케일링 이벤트에 대한 감도를 줄일 수 있습니다. · 우리는이 사건에 영향을 미치는 영향을 인식 플랫폼의 여러 영역과 우리가 전체 해상도를 통해 작업으로 당신의 인내를 평가.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 22일 PM 2:55 UTCinvestigating

   AIDI 대시보드에 영향을 미치는 문제점을 조사하고 있습니다. 사용자는 대쉬보드에 접근할 때 부하 시간 또는 간헐적인 실패를 경험할 수 있습니다. 우리 팀은 뿌리 원인을 확인하고 정상 성능을 회복하기 위해 적극적으로 노력하고 있습니다. 우리는 더 많은 정보로 업데이트를 제공 할 것입니다.

2. 2026년 7월 22일 PM 2:58 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 7월 22일 PM 3:25 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 7월 22일 PM 11:16 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 10일 PM 6:17 UTCpostmortem

   ## 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.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 17일 PM 5:16 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 7월 17일 PM 5:34 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 7월 17일 PM 6:12 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 7월 17일 PM 9:56 UTCresolved

   이 사건은 해결되었습니다.

5. 2026년 8월 4일 AM 2:48 UTCpostmortem

   # 요약 지난 17 7월 2026일, 일상적인 코드 배포에 따라, 이전 delegate 버전의 고객 \(858xx 및 아래 \)는 글로벌 빌드 쿼리 기능을 사용하여 하네스 클라우드 호스팅 빌드에 지연된 CI 빌드를 시작했습니다. Affected builds는 예상된 하위 두 번째 시간 내에서 진행하는 것보다 계속하기 전에 "유니트에 대한"단계에서 약 8 분의 예상치 못한 일시 중지를 경험했습니다. 전체적인 구조 감속은 intermittent이었습니다. # 충격 * 모든 CI 빌드는 잠재적으로 지연 될 수 있습니다. 영향력은 글로벌 빌드 쿼리 기능을 사용하여 하네스 클라우드 호스팅 인프라에 구축하기 위해 가장 발음되었습니다. * 사전예약된 지폐 슬롯이 유효하지 않았기 때문에 느리게 "cold start"가 계속되기 전에 약 8 분의 불만을 경험했습니다. 이것은 사용자가 빌드 실패보다 느리게 빌드하는 것으로 나타났습니다. * 새로운 delegate 버전 \(858xx 이상)에서 실행되는 계정은 영향을받지 않았습니다. * 이 문제의 직접적인 결과로 실패하지 않고 데이터가 손실되지 않았습니다. # 뿌리 원인 루트 원인은 inadvertently broke how a specific build-queueing record was read back from our database once builds that had already was queued under the 이전 버전의 코드가 새로 배치 된 버전. 우리는 영향을받은 레코드를 청소하여 즉각적인 영향을 미칩니다. 그리고 아래의 코드 변경을 반전하고, 우리는 반복에서이 종류의 문제를 방지하기 위해 여러 가지 안전장치를 구현하고 있습니다. # 다음 단계 우리는 다음과 같은 행동으로 비슷한 반복의 위험을 평가합니다. 이 사건을 일으키는 특정 코드 경로는 이미 거꾸로 옮겼습니다, 그리고 우리는 구조상 safeguards를 실행하기 때문에 이러한 일반적인 문제의 클래스가 재발 할 수 없습니다, 코드베이스에서 어디에도 그렇지 않으면 발생할 수 있습니다. | **차례 / 예방 조치** | 인포메이션 | 데이터베이스에 저장된 모든 내부 데이터 클래스에 명시된, 안정적인 식별자 추가, 그래서 미래의 내부 코드 재구성 이전에 저장된 레코드를 읽을 수있는 시스템의 능력을 파괴 할 수 없습니다. · | 롤백 및 백워드 호환성 테스트에 대한 사전 제작 환경, 특히 생산에 도달하기 전에 문제의이 클래스를 잡기 위해 설계되었습니다. ·

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 17일 PM 1:10 UTCinvestigating

   우리는 현재이 문제를 조사하고 있습니다.

2. 2026년 7월 17일 PM 1:12 UTCidentified

   문제는 식별되고 수정이 구현됩니다.

3. 2026년 7월 17일 PM 1:19 UTCmonitoring

   수정이 구현되어 결과를 모니터링하고 있습니다.

4. 2026년 7월 17일 PM 1:19 UTCmonitoring

   우리는 더 많은 문제를 모니터링하고 있습니다.

5. 2026년 7월 17일 PM 2:16 UTCresolved

   이 사건은 해결되었습니다.

6. 2026년 7월 22일 PM 5:25 UTCpostmortem

   # 요약 6월 19일과 7월 17일 사이에, 내장된 Git Clone 단계 — 그리고 drone-git clone 플러그인을 사용하여 파이프라인 단계 — 오류 실행 /usr/local/bin/clone을 가진 ARM64 Kubernetes 빌드 인프라에 실패: 실행 형식 오류. AMD64 \ (Intel / AMD \) 빌드, Windows 빌드 및 VM 컨테이너 바이너리 경로가 영향을받지 않았습니다. 루트 원인은 실제로 AMD64 binaries를 포함하기 위해 ARM64 태그 드론 git 이미지를 일으키는 내부 이미지 출판 과정에서 결함이었다. 우리는 확인과 같은 날 문제를 mitigated 마지막 알려진 좋은 버전에 drone-git 이미지를 반전하여보고되었다. 고객 행동이나 구성 변경이 필요했습니다. # 뿌리 원인 6월 19, 2026일, 의 보안 구제는 무인기 이미지가 내장 된 방법을 재구성했습니다. AMD64 빌드는 제대로 업데이트되었지만 ARM64 빌드 파이프라인은 ARM64 파일을 직접 구축하지 않았습니다. 텍스트 대용을 통해 AMD64 빌드 파일을 적응시키고 ARM64 인프라에서 컴파일했습니다. 6 월 19 변경은 AMD64 파일을 변경하여 헌법이 실패하지 않는 대신, 그래서 파이프 라인은 Git Clone과 Git LFS binaries가 여전히 AMD64에 컴파일 된 ARM64를 태그했다. # 충격 * Affected : 내장 된 Git Clone 단계 및 ARM64 Kubernetes 빌드 인프라에서 실행되는 drone-git clone 플러그인을 사용하여 파이프라인 단계, 7 월 6 및 7 월 17, 2026 사이에 모든 계정에서. * Symptom: Git Clone 단계에서 실행 /usr/local/bin/clone: 형식 오류를 실행합니다. * 영향을 미치지 않음 : AMD64 \ (Intel / AMD \) 쿠버네티스 및 VM 빌드, Windows 빌드, VM 컨테이너리스 실행 경로 및 우리의 경화 이미지 변형. # 소송 우리는 마지막 알려진 좋은 릴리스에 모든 영향을받는 서비스 전반에 걸쳐 사용되는 드론-git 이미지 버전을 reverted. 이 완전히 ARM64 실행 실패를 해결; 고객 구성 변경이 필요하지 않습니다. # 다음 단계 그런 문제를 다시 일어나지 않도록하십시오. * AMD64 빌드 파일에 맞게 전용 ARM64 빌드 파일을 직접 구축하기 위해 ARM64 이미지 게시 파이프라인을 재건합니다. * 모든 이미지 릴리스에 자동화 된 포스트 게시 유효성 향상 : 이진 아키텍처는 이미지 태그에 일치하고 이미지가 재평가되기 전에 기능적인 연기 테스트를 실행합니다. * ARM64 Kubernetes 빌드 시나리오를 포함하는 자동화된 테스트 적용 확대. * 순환에서 영향을받는 중간 이미지 버전을 제거하면 올바른 릴리스가 검증됩니다.

공식 인시던트 업데이트를 자동 번역했습니다.