Circle Ci 장애 기록

1. 2026년 10월 21일 오후 7:31 UTCidentified

   일부 사용자는 용량 문제로 인해 gen2 Docker 작업에 대한 대기 시간이 증가 할 수 있습니다.

2. 2026년 10월 21일 오후 8:03 UTCidentified

   우리는 더 많은 용량을 추가하여 문제를 완화합니다. 참고 : 우리는 여전히 2xlarge에서 20 분까지 지연을 볼 수 있습니다.

3. 2026년 10월 21일 오후 8:22 UTCidentified

   2xlarge docker 작업의 대기 시간은 복구됩니다. 우리는 용량으로 업데이트 계속 온라인 온다.

4. 2026년 10월 21일 오후 8:35 UTCidentified

   2xlarge docker 작업의 시간이 60 초 미만입니다. 다른 자원 크기에 대한 대기 시간은이 사건에 의해 영향을받지 않았고 10 초 미만 남아있었습니다.

5. 2026년 10월 21일 오후 8:40 UTCmonitoring

   우리는 도커 작업을위한 대기 시간의 전체 복구를 보았다.

6. 2026년 10월 21일 오후 8:54 UTCresolved

   Gen2 Docker 작업의 대기 시간은 복구 및 작업은 정상 대기 시간 내에 실행됩니다.

7. 2026년 10월 22일 오후 11:29 UTCpostmortem

   ## 요약 에서 15:44 에 20:55 UTC 에 10월 21, 고객 실행 Gen 2 도커 작업은 그들의 작업을 위해 대기 시간을 증가 보았다. 지연은 2xlarge 리소스 클래스에서 가장 긴, 작업은 20 분까지 기다립니다. 사건은 클라우드 인스턴스의 제한된 가용성에 의해 발생했습니다. 특히 2xlarge 일자리를 위해 수요를 충족하도록 구성되었습니다. 응답에서, 우리의 엔지니어링 팀은 추가 인스턴스 유형을 구성, 추가 구성 2 도커 클러스터. 20:55 UTC에 의해, 대기 시간은 정상으로 돌아와 사고가 해결되었습니다. 사건이 해결 된 후, 우리는 추가 클라우드 영역으로 Gen 2 Docker 함대를 확장했으며 앞으로 유사한 사건을 방지하기 위해 추가 클라우드 지역을 적극적으로 서 있습니다. 원래 상태 페이지는 여기에 찾을 수 있습니다: [10월 21 - 증가 도커 gen2 대기 시간](https://status.circleci.com/incidents/5jb50gh55gtj). ## 배경 CircleCI가 Docker 작업을 실행할 때, 우리는 클라우드 인스턴스의 여러 클러스터 중 하나에 일정하고, 각 인스턴스는 여러 고립 된 작업을 수행 할 수 있습니다. 클라우드 인스턴스에서 작업 스케줄링은 고전적인 [“빈 포장 문제”](https://en.wikipedia.org/wiki/Bin packing problem): 요청된 리소스 클래스의 CPU, 메모리 및 저장에 적합한 사용 가능한 용량을 찾는다. 2xlarge와 같은 더 큰 자원 종류는 더 단단하게 포장하는 더 작은 것 보다는 적합하기 어렵습니다. 인스턴스의 순위표를 사용하여 클라우드 인스턴스를 제공합니다. 클라우드 공급자가 우리의 첫 번째 선택을 제공 할 수없는 경우, 우리는 목록에 다음 유형으로 돌아갑니다. 우리는 최소한의 함대 크기를 유지 : 최소의 인스턴스 유지 실행, 그래서 우리는 수요가 낮을 때 용량을 포기하지 않는다. 최소 함대 크기 이상, 수요 상승으로 인스턴스를 추가합니다. 작업량을 실행할 수 있는 충분한 용량이 있을 때, 용량이 가능할 때까지 작업할 수 있습니다. ## 어떤 Happened \(모든 시간 UTC\) 시작 15:44 10 월 21, Gen 2xlarge 리소스 클래스에 대한 수요가 급격히 상승, 우리는 유지에 충분한 추가 용량을 제공하지 않았다. 우리의 엔지니어링 팀은 투자를 시작했습니다. 19:25, Gen 2xlarge 리소스 클래스의 대기 시간은 20 분에 도달했으며 다른 리소스 클래스의 대기 시간은 증가했다. 19:56에 의해, 우리의 엔지니어링 팀은 더 많은 용량을 온라인으로 얻기 위해 Gen 2 함대에 추가 인스턴스 유형을 구성했다, 그리고 19:59에 의해, 우리는 그 인스턴스 유형을 제공했다. 20:11, 우리는 여러 추가 Gen 2 클러스터를 추가, 그리고 그 클러스터에 최소 함대 크기를 증가. 로 20:35, 정상적인 수준에 반환된 누적 작업의 수, 그리고 20:41, 2xlarge 작업의 95 %는 4 초 이내에 시작되었다. 우리는 20:55에 사건을 해결했습니다. 이 사건을 해결 한 후, Docker 작업에 추가 클라우드 영역을 추가하여 더 많은 용량을 사용할 수 있습니다. ## 미래 예방 및 공정 개선 우리는 이미 많은 장소에서 sourcing 수용량을 포함하여 일 시작 시간을 개량하는 뒤에 오는 단계를 가지고 있고, 큰 자원 종류를 위한 수용량을 더 보존하고, 더 급속한 준비를 실행합니다. ** Docker 작업에 대한 추가 영역을 추가했습니다. ** 우리는 최근 기계 작업에 대한 추가 클라우드 영역을 추가, 그리고 우리는 지금 Docker 작업에 동일하게 수행. ** Docker 및 Machine 작업 모두에 대한 추가 클라우드 영역을 지속적으로 추가합니다 **. ** 추가 Gen 2 클러스터 **. 우리는 몇 가지 추가 Gen 2 클러스터를 구성하여 작업을 더 빨리 계획하고, 더 많은 용량을 사용할 수 있습니다. **우리는 우리가 사용하는 클라우드 인스턴스 유형의 집합을 확장하고 최소한의 함대 크기를 올리고 있습니다. ** 추가 인스턴스 유형을 구성했습니다. 우리는 또한 Gen 2의 최소 함대 크기를 증가하여 현재의 기본 요구 사항을 충족합니다. **우리는 더 큰 자원 클래스의 스케줄링을 우선적으로 하기 위해 우리의 작업 스케줄러를 수정했습니다.** 우리는 우리가 작업이 리소스 클래스를 통해 더 공정하게 균형을 잡는 방법을 변경하고, bin-pack 작업에 더 효율적으로 사용할 수 있습니다. ## 결론 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이이 이 사건을 해결하기 위해 일하면서 그들의 인내에 고객을 감사합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 20일 오후 3:58 UTCinvestigating

   M4pro.large 리소스 클래스를 사용하여 일부 macOS 작업에 대한 대기 시간이 증가했습니다. 우리는 투자하고 곧 또 다른 업데이트를 제공 할 것입니다. 감사합니다.

2. 2026년 10월 20일 오후 4:32 UTCmonitoring

   M4pro.large 리소스 클래스에서 macOS 작업을 실행하는 고객은 여전히 대기 시간이 증가했으며, 일부 작업이 시작되기까지 30 분이 소요됩니다. 우리는 이것을 감시하고 다른 갱신을 곧 공유할 것입니다.

3. 2026년 10월 20일 오후 5:02 UTCmonitoring

   M4pro.large를 위한 대기 시간은 아직도 무거운 큰 수요 때문에 상승됩니다. 모든 m4pro.medium은 정상적입니다. 우리는 적극적으로 감시하고, 우리는 patience를 평가합니다.

4. 2026년 10월 20일 오후 5:31 UTCmonitoring

   M4pro.large 리소스 클래스에서 macOS 작업에 대한 대기 시간이 복구됩니다. Xcode 27.0을 사용하는 작업은 이제 평균적으로 약 ~3.5 분, 피크에서 약 ~40 분. Xcode 26.6 및 26.4.1을 사용하는 작업은 여전히 backlog를 통해 작업하고, 이는 명확하게. m4pro.medium의 대기 시간은 정상입니다. 우리는 우리가 감시자를 계속하기 때문에 또 다른 갱신을 공유할 것입니다.

5. 2026년 10월 20일 오후 6:14 UTCresolved

   M4pro.large 리소스 클래스의 macOS 작업에 대한 대기 시간은 정상으로 돌아 왔습니다. 우리는 backlogs가 정리 한 동안 당신의 인내에 감사드립니다.

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

1. 2026년 10월 14일 오후 2:47 UTCinvestigating

   대략 14:00 UTC부터, M4 Pro 대용량 자원 클래스의 Xcode 26.6.0을 사용하는 macOS 작업을 실행하는 고객은 작업 시작 지연을 경험하고 있습니다. 대기 시간은 30 분 이상에 도달했습니다. 우리의 엔지니어가 조사하는 동안 당신의 patience를 당신을 감사하십시오. 우리는 15:30 UTC로 다른 업데이트를 제공 할 것입니다.

2. 2026년 10월 14일 오후 3:17 UTCidentified

   Xcode 26.6.0을 사용하는 macOS 작업을 시작합니다. 대략 15:11 UTC부터, Xcode 26.4를 사용하는 macOS 작업은 약 30 분의 대기 시간과 함께 지연됩니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 우리는 15:45 UTC로 다른 업데이트를 제공 할 것입니다.

3. 2026년 10월 14일 오후 4:01 UTCresolved

   10월 14일 UTC와 15:51 UTC 사이, Xcode 26.6.0 또는 Xcode 26.4 작업이 시작된 경험 지연을 사용하는 macOS 작업을 실행하는 고객. 대략 14:00 UTC에서, M4 Pro 대용량 자원 클래스에서 Xcode 26.6.0을 사용하는 작업은 30 분 이상 기다리며, 이러한 지연은 약 15:12 UTC로 회복됩니다. 대략 15:11 UTC에서, Xcode 26.4를 사용하는 작업은 대략 30 분을 시작합니다. 문제는 해결되고 모든 영향을받는 기능은 정상으로 돌아 왔습니다. 우리는 당신의 인내심을 주셔서 감사합니다. 우리 팀은 수정을 구현하기 위해 일했습니다.

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

1. 2026년 10월 9일 오전 11:33 UTCidentified

   Data를 구축하기 전에 지연되는 데이터 인프라의 지연이 발생하고 일부 알림이 눈에 보입니다. 우리는 소송에서 일하고 있습니다.

2. 2026년 10월 9일 오후 1:00 UTCidentified

   영향을받는 것은: 고객은 파이프라인을 트리밍하고, 고객은 아웃바운드 웹훅 및 이메일 및 슬랙 알림에 의존합니다. 당신이 기대할 수 있는 것 이후 11:15 UTC: - 파이프 라인은 계속하지만 아직 처리되지 않은 동안 여전히 생성되고, 그래서 리 트리거는 중복 파이프에서 발생할 수 있습니다. - 아웃바운드 웹훅 및 거래 알림(Slack 및 Email)은 전송되지 않습니다. - 파이프 상태는 볼 수 없습니다. - Project Usage 페이지의 사용료 데이터는 stale입니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트: 우리는 13:30 UTC로 다른 업데이트를 제공 할 것입니다.

3. 2026년 10월 9일 오후 1:30 UTCidentified

   11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 영향을받는 것은: 고객은 파이프라인을 트리밍하고, 고객은 아웃바운드 웹훅 및 이메일 및 슬랙 알림에 의존합니다. 당신은 무엇을 기대할 수 있습니다: - 약 13시 UTC 이후, 파이프라인은 다시 처리되고 작업이 시작된다. - 대부분의 작업은 현재 약 4 분 이내에 시작되며, 일부는 약 10 분 동안 기다리는 것입니다. 관대는 여전히 처리되고 더 길게 시작할 수 있습니다. - 아웃바운드 webhooks 및 알림이 재개되었습니다. - 파이프 라인은 여전히 backlog에서 처리되고, 그래서 retriggering는 중복 파이프라인에서 발생할 수 있습니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트: 우리는 14:00 UTC로 다른 업데이트를 제공 할 것입니다.

4. 2026년 10월 9일 오후 2:00 UTCidentified

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 어떤 영향 워크플로우 및 작업 실행, 고객들은 프로젝트 사용 페이지에서 사용 데이터를 볼 수 있습니다. 당신이 기대할 수 있는 것 - 파이프 라인은 다시 처리되고, 그 공격을 포함. - 약 13:25 UTC, 작업 흐름 및 작업은 backlog를 통해 작업으로 지연을 늘리고 있습니다. 대부분의 일자리는 현재 약 10 분 이내에 시작되며 25 분 정도 기다리는 것입니다. - 우리는 대략 14:35 UTC에 의하여 이 backlog를 통해 일할 것으로 예상합니다. - 사고 중에 방아쇠 파이프의 작업 흐름은 여전히 시작을 기다리고 있습니다. 그래서 방아쇠는 중복 작업 흐름에 발생할 수 있습니다. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트 우리는 14:30 UTC로 다른 업데이트를 제공 할 것입니다.

5. 2026년 10월 9일 오후 2:29 UTCidentified

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 어떤 영향 워크플로우 및 작업 실행, 고객들은 프로젝트 사용 페이지에서 사용 데이터를 볼 수 있습니다. 당신이 기대할 수 있는 것 - 워크플로우 및 작업이 개선되는 지연. 대부분의 일자리는 현재 약 3 분 이내에 시작되며, 13:50 UTC에서 약 10 분이 소요됩니다. - 사고 중에 방아쇠 파이프 라인의 일부 워크플로우는 여전히 40 분 정도의 시작을 기다리고 있습니다. - backlog를 통한 작업은 예상보다 약간 더 길어집니다. 우리는 지금 대략 14:45 UTC에 의해 그것을 명확하게 기대합니다. - 사고 중에 방아쇠 파이프의 작업 흐름은 여전히 시작을 기다리고 있습니다. 그래서 방아쇠는 중복 작업 흐름에 발생할 수 있습니다. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트 우리는 15:00 UTC로 다른 업데이트를 제공 할 것입니다.

6. 2026년 10월 9일 오후 2:43 UTCidentified

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 어떤 영향 워크플로우 및 작업 실행, 고객들은 프로젝트 사용 페이지에서 사용 데이터를 볼 수 있습니다. 당신이 기대할 수 있는 것 - 약 14시 40분의 UTC로 인해 발생하는 파이프라인에서 워크플로우의 backlog. - 대부분의 작업은 약 30 초 이내에 시작되며 약 3 분 동안 기다리는 것입니다. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 underlying 문제점에 일을 계속하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트 우리는 15:10 UTC로 다른 업데이트를 제공 할 것입니다.

7. 2026년 10월 9일 오후 2:54 UTCmonitoring

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 어떤 영향 워크플로우 및 작업 실행, 고객들은 프로젝트 사용 페이지에서 사용 데이터를 볼 수 있습니다. 당신이 기대할 수 있는 것 - 사고의 파이프라인 및 워크플로우의 백로그가 명확하게 되었습니다. - 약 14:45 UTC, 대부분의 작업 흐름 및 작업은 약 15 초 이내에 시작되며, 시작 시간은 정상으로 계속됩니다. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 복구를 모니터링하는 동안 당신의 인내력을 주셔서 감사합니다. 다음 업데이트 우리는 15:20 UTC로 다른 업데이트를 제공 할 것입니다.

8. 2026년 10월 9일 오후 3:32 UTCmonitoring

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 어떤 영향 고객 조회 파이프라인, 작업 흐름 및 작업 CircleCI UI, 및 고객 보기 사용 데이터 프로젝트 사용 페이지. 당신이 기대할 수 있는 것 - 작업 흐름 및 작업은 시간에 실행됩니다. - The CircleCI UI는 30분 뒤에 있습니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - 우리의 엔지니어는 UI가 붙잡을 수 있도록 처리하는 속도에 적극적으로 일하고 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가이 지연을 줄이기 위해 노력하는 동안 당신의 patience에 당신을 감사하십시오. 다음 업데이트 우리는 16:00 UTC로 다른 업데이트를 제공 할 것입니다.

9. 2026년 10월 9일 오후 4:02 UTCmonitoring

   11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 어떤 영향 고객 작업 흐름 및 작업, 고객 조회 파이프라인, 작업 흐름 및 작업 CircleCI UI, 및 고객 보기 사용 데이터 프로젝트 사용 페이지. 당신이 기대할 수 있는 것 - 약 15:15 UTC, 작업 흐름 및 작업이 지연으로 시작되었습니다. 대부분의 작업은 현재 약 4 분 이내에 시작되며 일부는 20 분 정도 기다리는 것입니다. - The CircleCI UI는 평균 30분 뒤에 남아 있으며, 일부 업데이트는 더 오래 걸립니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이러한 지연을 줄이기 위해 노력하는 동안 당신의 인내심을 주셔서 감사합니다. 다음 업데이트 우리는 16:30 UTC로 다른 업데이트를 제공 할 것입니다.

10. 2026년 10월 9일 오후 4:32 UTCmonitoring

    11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 대략 15:15 UTC, 작업 흐름 및 작업은 다시 지연으로 시작되었습니다. 어떤 영향 고객 작업 흐름 및 작업, 고객 조회 파이프라인, 작업 흐름 및 작업 CircleCI UI, 및 고객 보기 사용 데이터 프로젝트 사용 페이지. 당신이 기대할 수 있는 것 - 워크플로우 및 작업 시작 지연이 증가하고 쉽게 시작되었습니다. 대부분의 작업은 약 4 분 이내에 시작되며 25 분 정도 기다리는 것입니다. - The CircleCI UI는 지금 약 20 분, 약 30 분입니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이러한 지연을 줄이기 위해 노력하는 동안 당신의 인내심을 주셔서 감사합니다. 다음 업데이트 우리는 17 : 00 UTC로 다른 업데이트를 제공 할 것입니다.

11. 2026년 10월 9일 오후 5:06 UTCmonitoring

    11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 대략 15:15 UTC, 작업 흐름 및 작업은 다시 지연으로 시작되었습니다. 어떤 영향 고객 작업 흐름 및 작업, 고객 조회 파이프라인, 작업 흐름 및 작업 CircleCI UI, 및 고객 보기 사용 데이터 프로젝트 사용 페이지. 당신이 기대할 수 있는 것 - 워크플로우 및 작업 시작 지연은 꾸준히 유지됩니다. 대부분의 작업은 약 4 분 이내에 시작되며 약 8 분 동안 기다리는 것이 약 25 분입니다. - The CircleCI UI는 평균 20분 뒤에 남아 있으며, 일부 업데이트는 더 오래 걸립니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이러한 지연을 줄이기 위해 노력하는 동안 당신의 인내심을 주셔서 감사합니다. 다음 업데이트 우리는 17 : 30 UTC로 다른 업데이트를 제공 할 것입니다.

12. 2026년 10월 9일 오후 5:34 UTCidentified

    11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 대략 15:15 UTC, 작업 흐름 및 작업은 다시 지연으로 시작되었습니다. 어떤 영향 고객은 파이프라인 및 워크플로우 및 작업, 고객 조회 파이프라인, 워크플로우 및 작업 서클CI UI 및 프로젝트 사용 페이지의 사용 데이터를 볼 수 있습니다. 당신이 기대할 수 있는 것 - 약 17:00 UTC 이후 지연이 크게 증가했습니다. 대부분의 직업은 지금 대략 12 분을 시작하고, 몇몇은 대략 30 분을 기다리고 있습니다. - 약 17:15 UTC 이후, 일부 작업이 시작되지 않습니다. - 파이프 라인은 더 천천히 처리되고, 그래서 일부는 더 오래 걸릴 수 있습니다. - The CircleCI UI는 1시간 이상입니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어가 이것을 해결하는 동안 당신의 patience를 당신을 감사하십시오. 다음 업데이트 우리는 18:00 UTC로 다른 업데이트를 제공 할 것입니다.

13. 2026년 10월 9일 오후 6:08 UTCidentified

    11:15 UTC 이후 고객은 파이프라인 및 알림에 대한 혼란을 경험했습니다. 11:15 UTC 및 약 13 : 00 UTC 사이, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅 및 거래 알림 (Slack 및 이메일)이 전송되지 않았습니다. 약 13 : 00 UTC 및 14 : 40 UTC, 워크 플로우 및 작업이 백 로그를 통해 일하면서 지연으로 시작되었습니다. 대략 15:15 UTC, 작업 흐름 및 작업은 다시 지연으로 시작되었습니다. 어떤 영향 고객은 파이프라인 및 워크플로우 및 작업, 고객 조회 파이프라인, 워크플로우 및 작업 서클CI UI 및 프로젝트 사용 페이지의 사용 데이터를 볼 수 있습니다. 견적 요청 - 약 17시 UTC 이후 지연이 증가합니다. 대부분의 직업은 지금 대략 25 분을 시작하고, 몇몇은 대략 시간 기다리고 있습니다. - 약 17:15 UTC 이후, 일부 수신 작업 흐름이 실패하고 작은 작업의 수는 시작 실패. - 새로운 파이프라인은 더 이상 시작을 복용하고 있습니다. - The CircleCI UI는 1시간 이상입니다. 새로운 워크플로우와 상태 변경은 긴 일이 될 수 있습니다. - UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. - Project Usage 페이지의 사용료 데이터는 현재 stale입니다. 우리의 엔지니어는 손에 문제점을 해결하기 위하여 계속합니다. 다음 업데이트 우리는 18:30 UTC로 다른 업데이트를 제공 할 것입니다.

14. 2026년 10월 9일 오후 6:32 UTCidentified

    우리의 마지막 업데이트 이후 변경 사항 * The CircleCI UI는 대략 시간 뒤에, 그리고 몇몇 갱신을 위한 대략 90 분입니다. Workflows and jobs may already have run, or may be running, even if UI shows them as not started or does not show them at all. * 실행중인 작업은 빠른 시작. 대부분이 약 15 분 이내에 시작되어 약 28 분, 일부는 여전히 시간 동안 기다리고 있습니다. * 새로운 파이프라인은 점점 지연됩니다. * 일부 작업 흐름은 여전히 실패합니다. 처리 할 수없는 작업 흐름은 실패로 표시됩니다. * UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. 아직도 진행: Project Usage 페이지의 사용료 데이터는 stale입니다. 다음 업데이트 우리는 19:00 UTC에 의해 다른 업데이트를 제공 할 것입니다.

15. 2026년 10월 9일 오후 6:57 UTCidentified

    우리의 마지막 업데이트 이후 변경 사항 * 직업은 빨리 시작합니다. 대부분의 시간은 약 8 분 이내에 시작되며 약 15 분에서 가장 긴 대기 시간은 약 45 분에 떨어졌습니다. * The CircleCI UI는 잡기 시작이지만 여전히 뒤에 있습니다. Workflows and jobs may already have run, or may be running, even if UI shows them as not started or does not show them at all. * Pipelines는 더 빨리 가공되고, 그러나 새로운 파이프라인은 아직도 지연됩니다. 아직도 진행 * 일부 작업 흐름과 작업은 여전히 실패합니다. * UI에 아직 나타나지 않는 재조절 작업 흐름을 피하십시오. * 프로젝트 사용법 페이지에 사용법 책임 자료는 stale입니다. 다음 업데이트 우리는 19:30 UTC로 다른 업데이트를 제공 할 것입니다.

16. 2026년 10월 9일 오후 7:29 UTCidentified

    우리의 마지막 업데이트 이후, 작업은 빠른 시작: 대부분 약 6 분, 약 8 분. The CircleCI UI는 여전히 1 시간 뒤에 잡기입니다. 새로운 파이프라인은 도착으로 처리됩니다. 작업은 이미 UI가 아직 표시되지 않는 경우에도 실행할 수 있으므로 UI에 나타나지 않는 워크플로우를 피하십시오. 우리는 20:00 UTC로 다른 업데이트를 제공 할 것입니다.

17. 2026년 10월 9일 오후 8:06 UTCidentified

    직업은 빨리 시작하고 몇몇은 실패합니다: 최대 일은 대략 4 분 안에, 대략 6 분에서 아래로 시작되고, 가장 긴 대기는 대략 30 분에서 대략 20 분에 떨어졌습니다. 이전의 파이프 라인은 이제까지 일하고 있습니다. CircleCI UI는 여전히 뒤에 있으며, 이전 업데이트는 더 이상 나타납니다. 작업은 이미 UI가 아직 표시되지 않는 경우에도 실행할 수 있으므로 UI에 나타나지 않는 워크플로우를 피하십시오. 우리는 20:30 UTC로 다른 업데이트를 제공 할 것입니다.

18. 2026년 10월 9일 오후 9:22 UTCidentified

    20:48 UTC, 새로운 작업 흐름 및 작업이 시작되지 않기 때문에. 우리는 일시적으로 새로운 작업을 시작 했으므로 우리의 시스템은 이미 진행중인 작업을 잡을 수 있으므로 CircleCI UI 및 API로 업데이트 지연. 이전 업데이트는 이제 UI 및 API에서 이 백 로그 클리어로 나타납니다. 새로운 파이프라인은 아직도 받아들여지고 queued 이때 파이프 라인 또는 워크플로우를 피하십시오. 한 번의 작업 이력서를 복제 할 수 있습니다. 우리는 22:00 UTC로 다른 업데이트를 제공 할 것입니다.

19. 2026년 10월 9일 오후 10:09 UTCidentified

    우리의 마지막 업데이트 이후, 대부분의 파이프 라인의 이전 지연 된 사고가 지금 처리되었습니다, 그들의 작업 흐름은 시작에 할당됩니다. 새로운 워크플로우와 작업은 일시적으로 일시적으로 일시적으로 중단됩니다. 지연된 업데이트는 CircleCI UI 및 API에서 계속 나타납니다. 파이프라인 또는 워크플로우를 피하기 위해 계속하십시오. 이를 통해 한 번의 작업을 재개할 수 있습니다. 우리는 22:30 UTC로 다른 업데이트를 제공 할 것입니다.

20. 2026년 10월 9일 오후 10:28 UTCidentified

    우리의 마지막 업데이트 이후, 우리는 점차적으로 일하고, 몇 가지 할당 된 워크플로우 및 작업이 다시 시작되었습니다. 대부분의 누적 작업은 여전히 대기하고 있으며, 시작해야 할 작업은 1 시간 이상 대기 할 수 있습니다. 시스템의 과부하를 피하기 위해 신중하게 비율을 늘리고 있습니다. 지연된 업데이트는 CircleCI UI 및 API에서 계속 나타납니다. 파이프라인 또는 워크플로우를 피하기 위해 계속하십시오. 이 작업은 재조절된 작업으로 복제를 만들 수 있습니다. 우리는 23:00 UTC에 의해 다른 업데이트를 제공 할 것입니다.

21. 2026년 10월 9일 오후 11:00 UTCidentified

    많은 작업 흐름과 작업이 시작되고, CircleCI UI와 API가 작동하고 몇 가지 지연으로 업데이트됩니다. 우리는 나머지 queued 일을 통해 계속됩니다. queue의 작업은 약 1 시간 이상 기다리며 일부 Linux 작업은 용량에 대해 10 분 정도 기다리는 것입니다. 작업이 계속 진행되는 동안 재조절을 방지하기 위해 계속하십시오. 우리는 23:30 UTC로 다른 업데이트를 제공 할 것입니다.

22. 2026년 10월 9일 오후 11:38 UTCidentified

    우리는 여전히 쿼츠 워크 및 작업의 중요한 백로를 통해 일하고 있습니다. 시간이 개선되었지만 그들은 정상보다 오래 유지되고 일부 작업은 1 시간 이상 기다립니다. CircleCI UI와 API는 최신 상태로 유지됩니다. 재조절 파이프 또는 워크플로를 방지하기 위해 backlog 클리어를 사용하면 중복을 만들 수 있습니다. 우리는 00:00 UTC에 의해 다른 업데이트를 제공 할 것입니다.

23. 2026년 10월 9일 오후 11:59 UTCidentified

    마지막 업데이트 이후, 누적된 작업 흐름과 작업의 backlog는 약 23:47 UTC로 명확했습니다. 작업 흐름과 작업은 이제 몇 초 내에 시작되며, CircleCI UI와 API는 최신 버전입니다. 우리는 우리가 안정적으로 유지되도록 시스템을 밀접하게 모니터링하고 있습니다. 우리는 00:30 UTC에 의해 다른 업데이트를 제공 할 것입니다.

24. 2026년 10월 10일 오전 12:45 UTCidentified

    작업 흐름과 작업은 일반적으로 시작해야, 몇 초 안에, 그리고 CircleCI UI와 API는 현재까지 남아. Slack과 이메일 알림은 여전히 전달됩니다. Project Usage 페이지의 사용료 데이터는 stale입니다. 우리는 우리의 시스템을 밀접하게 모니터링하고 01:15 UTC에 의해 다른 업데이트를 제공 할 것입니다.

25. 2026년 10월 10일 오전 1:23 UTCmonitoring

    작업 흐름과 작업은 일반적으로 시작되고 실행되며, CircleCI UI와 API는 최신입니다. 우리는 그들이 안정적으로 남아 있는지 확인하기 위해 긴밀한 시스템을 모니터링하고 있습니다. 우리는 02:00 UTC에 의해 다른 업데이트를 제공 할 것입니다.

26. 2026년 10월 10일 오전 2:08 UTCresolved

    10월 9일 UTC 및 23:47 UTC 사이, 고객은 파이프라인, 워크플로우 및 작업 전반에 걸쳐 지연 및 실패를 경험했습니다. CircleCI UI, API 및 알림의 지연과 함께. 11:15 에 대해 13:00 UTC, 파이프라인은 생성되었지만 처리되지 않았고, 아웃바운드 웹훅과 슬랙 및 이메일 알림이 전송되지 않았습니다. 대략 13:00에서 14:40 UTC의 워크플로우 및 작업은 backlog를 통해 일하면서 지연으로 시작되었습니다. 약 15:15에서 20:48 UTC, 워크 플로우 및 작업이 지연으로 시작, 최대 약 1 시간의, 그리고 CircleCI UI와 API는 약 2 시간의 뒤떨어졌다. 이 시간 동안 일부 작업이 시작되지 않았으며 일부 작업이 실패했습니다. 20:48에서 약 22:10 UTC에 이르기까지, 우리는 일시적으로 새로운 워크플로우 및 작업 시작 그래서 우리의 시스템은 복구 할 수 있습니다. 새로운 파이프라인은 받아들여지고 이 시간 도중 queued. 약 22:10에서 23:47 UTC, 할당 된 작업 흐름 및 작업 이력서 처리. 그들 중 일부는 약 2 시간 동안 기다렸다. 문제는 해결되고 모든 영향을받는 기능은 정상으로 돌아 왔습니다. 프로젝트 사용법 페이지에 사용법 책임 자료는 아직 날짜까지이고 우리의 자료 backfills가 완료되면 새롭게 할 것입니다. 이 창에서 실패한 작업은 영향을 미칠 수 있습니다. 우리는 우리의 엔지니어가 해결을 구현하는 데 일하면서 당신의 인내에 감사드립니다.

27. 2026년 10월 12일 오후 10:32 UTCpostmortem

    ## 요약 10월 9일 UTC와 23:47 UTC 사이, CircleCI 고객은 파이프라인, 워크플로우 및 작업 전반에 걸쳐 시간과 실패를 경험했습니다. CircleCI UI, API 및 알림의 지연과 함께. * 11:15에서 13:00 UTC, 파이프라인은 생성되었지만 처리되지 않았으며 아웃바운드 웹훅과 슬랙 및 이메일 알림이 전송되지 않았습니다. * 13:00에서 14:40 UTC, 워크플로우 및 작업은 backlog를 통해 일하면서 지연으로 시작되었습니다. * 15:15에서 20:48 UTC, 워크 플로우 및 작업은 지연을 늘리고 시작하며, 1 시간 정도까지, CircleCI UI와 API는 약 2 시간 동안 떨어졌습니다. 이 시간 동안 일부 작업이 시작되지 않았으며 일부 작업이 실패했습니다. * 20:48에서 22:10 UTC, 우리는 일시적으로 새로운 작업 흐름을 시작 일시적으로 일시적으로 사용 하 여 우리의 시스템은 복구 할 수 있습니다. 새로운 파이프라인은 받아들여지고 이 시간 도중 queued. * 22:10에서 23:47 UTC, 할당 된 작업 흐름 및 작업은 성공적으로 처리되었습니다. 그들 중 일부는 약 2 시간 동안 기다렸다. * 로 23:47, 사건은 mitigated. 이 사건에 대한 상태 페이지는 [10월 9일 - UI 및 API에서 표시된 데이터 지연](https://status.circleci.com/incidents/6cfhhlr4rmm0)에서 확인할 수 있습니다. 고객은 10 월 6 일 이전에 비슷한 사건을 경험했습니다 - 파이프라인, 워크플로우, UI 데이터 및 알림의 지연] (https://status.circleci.com/incidents/z4hbq8h49j8c). Multiple CircleCI 서비스 사용 Temporal backed by Postgres as a Reliable queueing mechanism, 그리고 둘 다 사건은 동일한 원인을 가지고: Temporal의 Postgres 인스턴스에 쓰기의 비율은 Postgres의 거래 로그보다 더 빠졌다 그 쓰기. 두 경우, 이 두 개의 파이프 라인과 상태 알림을 처리하는 데 발생하는 다중 시간 지연. 우리는 몇몇 완화를 평가했습니다, 그 후에 새 워크플로우는 이렇게 체계가 안전하게 회복할 수 있고, 점차적으로 뒤로 덮는 것을 시작합니다. 우리는 그 때 우리의 체계가 정상에 돌려보낼 때까지 throttled 일 백업. 영구적으로 Bottleneck을 해결하기 위해, 우리는 여러 Temporal 인스턴스를 통해 작업을 분할하고, 각각의 독립적 인 데이터베이스와 worker 클러스터와 함께, 우리는 그들을 통해 균형. 우리는 이미 10 월 12의 주를 시작하는 인프라 작업을 예정했으며이 정확한 병목을 제거하고이 사건을 방지했습니다. 그래서 시작 19:11 10월 9 우리의 엔지니어링 팀 구현, 테스트, 그리고 몇 시간 이내에 이러한 변경의 간단한 버전을 압연. 우리는 더 새로운 경고를 추가하고 높은 부하의 밑에 더 나은 성과를 위한 underlying 데이타베이스를 조정했습니다. 이 창에서 실패한 작업이 실패한 고객은 그들을 다시 실행할 수 있습니다. ## 배경 고객 작업을 실행하려면 CircleCI는 일련의 단계를 수행합니다. 우리는 고객 파이프라인을 받아들입니다. 우리는 그 파이프라인을 노동자에게 할당합니다. 우리는 그 파이프라인과 일자리에 대한 상태 업데이트를 제공합니다. 그리고 우리는 그 작업이 소비하는 크레딧을 담당합니다. 이 단계의 각은 독립적 인 서비스로 구현되며 신뢰할 수있는 큐와 함께합니다. 역사적으로 우리는 신뢰성을 위해 Exponential backoff 및 dead Letter queues와 더불어 튼튼한 저장의 정상에 RabbitMQ를 가진 이 믿을 수 있는 큐를 실행했습니다. 작년에, 우리는 점점 더 단순하고 강력한 프로그래밍 모델에 대한 더 나은 내구성과 신뢰성을 제공하는 [Temporal] (https://temporal.io/)에 우리의 신뢰할 수있는 큐를 단순화했습니다. 우리의 빌드 서비스 \ (통합 가능한 계획으로 파이프라인 구성을 회전), 우리의 워크플로우 오케스트라 서비스 \ (작업을 근로자에 배포하는 경우), 우리의 알림 서비스 \ (상태 업데이트 제공), 우리의 충전 서비스 \ (클래스 \에 대한 고객 충전) 이제 Temporal을 사용합니다. Temporal은 작업 흐름 및 활동에 대한 국가를 저장합니다. \ ("history"\) 데이터베이스에서, 이것은 비동기 및 stateful 인 Temporal 인스턴스의 유일한 구성 요소입니다. 결과적으로, Temporal 인스턴스의 허용 능력과 실행 워크플로우는 백킹 데이터베이스의 쓰기 속도에 의존합니다. 우리는 또한 완료된 워크플로우 및 활동을 삭제하기 위해 Temporal을 구성했습니다. 3 일 후에 완료되었습니다. 이 사건의 시간에, 우리는 이 믿을 수 있는 큐 전부를 위한 Multi-AZ Postgres RDS 인스턴스에 의해 역행된 단 하나에 의하여 클러스터를 박았습니다. Multi-AZ RDS 인스턴스가 영역 실패에 탄력있는 동안 단일 쓰기 ahead-log \(WAL\)를 통해 데이터베이스 일관성을 유지합니다. Postgres 인스턴스를 구성했을 때 Dedicated Log Volume \(DLV\)에 WAL을 저장하기 위해 로그 쓰기를 작성하지 않았습니다. 데이터베이스는 백업 저장에 지속적으로 로그를 보관하고 로그가 보관 된 후 볼륨에 재사용 공간을 재사용 할 수 있습니다. 데이터베이스가 아카이브보다 더 빨리 로그를 작성하면 볼륨 채우기 및 Postgres는 WAL 로그를 작성하는 공간이 없습니다. 그런 다음 데이터베이스는 들어오는 글을 수락하고 완전히 읽기 전용으로 간다. RDS DLV는 스토리지 1TB 및 3000 IOPS에 제한되어 있으며 AWS 당 이러한 제한은 하드 코딩 및 증가 할 수 없습니다. ## 어떤 Happened \(모든 시간 UTC\) 10 월 6 사건에 기여 요인 중 하나는 우리가 다가오는 작업과 같은 시간에 Temporal 역사 토론의 높은 비율을 처리하고 있었다, 이는 백 데이터베이스에 압력을 넣어. 10월 6일 사건을 해결하기 위해, 우리는 Temporal의 가장 큰 테이블에 정리 설정을 변경하고 전용 볼륨으로 거래 로그를 이동. 이 변경은 트랜잭션 로그의 주요 소스를 삭제, 하지만 추가 로그는 예정된 삭제에서 쓰기를 고려하지 않았다. 우리는 Temporal을 구성하기 때문에 완료된 워크플로우와 활동을 삭제하기 위해 3 일 후에 완료, 10 월 6 역사는 10 월 9 일에 삭제 될 예정 10 월 9 일 08:00부터, Temporal은 예정된 토론을 처리하기 시작했으며 Postgres DLV의 무료 결과 공간으로, 0.8TB에서 08:00에서 0.1TB로 10:10로 떨어지기 시작했습니다. 우리의 모니터링 경고 10:28 그리고 우리는 10:31에 사건을 선언. 우리의 인프라 팀은 투자되었지만, 11:15에서 DLV는 공간과 Postgres 인스턴스가 읽기 전용으로 갔다. 이것은 그것의 궤도에 있는 모든 Temporal 처리를 멈추었습니다. 11:42에서, 우리는 데이터 볼륨에 DLV에서 WAL 로그를 이동하고 여분의 디스크 공간과 IOPS를 사용합니다. 이 maneuver는 10 월 6 일에 사건을 mitigated했으며 약 60 분이 걸립니다. 데이터베이스가 재시작하는 동안, 우리는 Temporal의 여러 로드 헛간 기술 업스트림을 구현하기 시작했습니다. * 우리는 우리가 들어오는 workloads altogether가 나머지 이동을 유지하는지 여부를 조사하기 시작했지만 궁극적으로이 값을 제공하지 않을 것이라고 결정했습니다. * 12:29, 우리는 임시 활동의 12%를 나타내는 신용 위탁 갱신을 떨어뜨립니다. 이것은 우리가 그것을 backfill 할 때까지 stale 위탁 자료를 가진 파이프라인 사용법 페이지를 떠납니다, 그러나 자료를 잃거나 달리기에서 파이프라인을 방지하지 않을 것입니다. 12:59, 데이터베이스가 백업 및 11:15 이후 누락 된 처리 작업을 시작 했다 및 14:40, 이 backlog는 명확 하 고 작업을 시작 했다. 그러나, 15:15에 의해, 데이터베이스의 라우팅 정리로 반환된 지연은 테이블 Temporal 용도에 떨어졌고 일정한 작업을 추적합니다. 그 테이블은 일반적으로 청소를 기다리고 삭제 된 행의 수천을 보유하지만, 늦은 오후에, 그들은 열의 수백만을 개최. 모든 임시 가동은 그 줄을 과거에 읽었습니다, 그래서 데이타베이스는 각 하나와 임시 ran 더 느린에 다량 처리 시간을 보냈습니다. 이 결과 고객이 계속하여 파이프라인 및 상태 업데이트에서 시간 긴 지연을 볼 수 있습니다. 다음 몇 시간 동안 우리는 다음과 같은 다양한 완화 시도 : * 데이터베이스 압력을 줄이기 위해 Temporal 구성 값을 조작. 이것은 최소한 효력이 있었습니다. * Postgres에서 죽은 행을 청소하기 위해 수동 진공 작업을 실행하십시오. CPU에 대 한 경쟁을 완료 하 고 궁극적으로 위조 되었다. 우리는 17:45에 그들을 취소하여 데이터베이스 부하에 압력을 구합니다. * 우리는 별도의 Temporal 인스턴스에 알림 usecases의 모든 이동하려고 시작했다. 이것은 임시 활동의 18%를 대표했습니다. 우리는 성공적으로 17:07에 의해 이동 통보를 완료했습니다. * 17:16, 우리는 성공적으로 5%에 의해 감소된 파이프라인 국가의 우리의 표현에 있는 최적화를 실행합니다. 즉, 턴은 데이터베이스의 크기를 작성하고 따라서 Postgres WAL 로그의 데이터 압력. 이 완전히 문제가되지 않았습니다. 20:48에 의해, 우리는 Postgres가 이제 데이터베이스 CPU에 thrashing하고 로그 쓰기에 더 이상 병목이 없었다는 것을 깨달았습니다. 우리는 우리의 업스트림 시스템이 새로운 작품을 제출하고 이전 제출하고 실패 한 작업을 재개하는 것을 더 실현합니다. 우리는 클래식 리트리 폭풍에 있었다는 것을 인식, 우리는 모든 들어오고 복원 작업을 일시 중지하고 데이터베이스를 완전히 완료 할 수 있도록하기 위해, 그것을 수 있도록. 우리는 천천히 22:07에서 퀴즈 작업을 중단하여 지속 가능한 부하에서 데이터베이스를 유지합니다. 이 완전히 23:47에 의해 성공할 때 모든 퀴즈 작업을 시작했고, 우리는 10 월 10 일 02:08에 사건을 닫습니다. ## 미래 예방 및 공정 개선 ## 다수 임시 Instances 10월 9일 19:11부터 시작된 사건 완화 및 해결과 병렬에서는, 우리는 또한 다수 sharded Temporal 인스턴스를 서 있고 그 사이에 균형 들어오는 일을 적재하는 기능을 실행하기 시작했습니다. 여러 Temporal 인스턴스의 각각은 자체 독립적 인 데이터베이스와 worker 클러스터를 유지하므로 다른 곳에서 격리됩니다. 10 월 6 사건에서 postmortem 작업 항목으로, 우리는 이미 예정된 인프라 작업을 수행 한 단일 Temporal 인스턴스와 Postgres 데이터베이스의 병목을 제거, 10 월 12 시작 및 2 주 걸릴 것으로 예상. 10 월 9 일, 우리는이 작업을 단순히 기다릴 수 없다는 것을 깨달았습니다, 그래서 우리의 엔지니어링 팀은 구현, 테스트, 몇 시간 내에 계획 된 변경의 간단한 버전을 압연. 이 변경은 10월 10일 01:45에 성공적으로 완료되었습니다. **또한, 우리는 우리가 거래 로그를 저장하고 모니터링하는 방법을 변경하고 있습니다. ** 우리의 Temporal 데이터베이스는 더 이상 고정 크기 로그 볼륨을 사용합니다. 우리는 얼마나 멀리 로그 아카이브 가을에 경고를 추가하고 데이터베이스가 로그를 얼마나 빠른지, 그래서 우리는 우리가 10 월 9에했던 것보다 시간을 일찍 행동 할 수 있습니다. ** 우리는 또한 Temporal의 삭제 일정을 수정하고 있습니다. ** Temporal deletes는 실행 후 며칠을 완료했습니다. 그래서 바쁜 하루는 데이터베이스로드로 돌아갑니다. 우리는 언제 변화하고 얼마나 빨리 그 deletions는 달립니다. ** 우리는 Temporal이 느리 때 우리의 시스템 복원 방법을 변경하고 있습니다. ** 10 월 9 일, 우리의 시스템은 Temporal에 대한 실패한 작업을 회복하고 부하에 추가했습니다. 우리는 10 월 6 사건 후 최선을 다하고 있으므로, 우리는 임시 직원을 위해 대기 할 시스템을 변경하여 작업이 떨어지지 않습니다. ## 결론 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 8일 오후 1:00 UTCidentified

   고객은 기계 작업에 대한 높은 대기 시간을 경험할 수 있습니다. 우리는 이것을 해결하기 위해 일하고 있습니다.

2. 2026년 10월 8일 오후 1:34 UTCidentified

   Linux 기계 작업을 사용하는 고객은 대기 시간을 높였습니다. 약 11 분 동안 평균 대기 시간은 중간, arm.medium 및 arm.large 리소스 클래스에서 30 분을 초과합니다. 우리의 엔지니어는 문제점을 확인하고 고침에 일하고 있습니다. 우리는 14:00 UTC로 다른 업데이트를 제공 할 것입니다.

3. 2026년 10월 8일 오후 2:04 UTCidentified

   Linux 기계 작업을 사용하는 고객은 대기 시간이 높고 약 40 분 동안 평균 대기 시간이 50 분 초과됩니다. 대부분의 Linux 기계 리소스 클래스는 중간, 큰, xlarge, 2xlarge 및 팔과 같은 영향을받습니다. 우리의 엔지니어는 문제점을 확인하고 고침에 일하고 있습니다. 우리는 14:30 UTC로 다른 업데이트를 제공 할 것입니다.

4. 2026년 10월 8일 오후 2:37 UTCidentified

   Linux 기계 작업 및 원격 도커를 사용하는 고객은 대기 시간을 높였습니다. 몇 가지 리소스 클래스에서 40 분을 초과하는 가장 긴 대기 시간이 감소하고 지금 평균 약 20 분 동안 시작되었습니다. 우리의 엔지니어는 문제점을 확인하고 고침에 일하고 있습니다. 우리는 15:00 UTC로 다른 업데이트를 제공 할 것입니다.

5. 2026년 10월 8일 오후 3:01 UTCidentified

   수정이 배포되고 대기 시간은 감소하지만, Linux 기계 작업 및 원격 도커를 사용하는 고객은 여전히 지연을 경험하고있다. 현재 평균 대기 시간 약 11 분, 가장 긴 대기 35 몇 가지 리소스 클래스에서 분. 가능한 한 빨리 용량을 추가하기 위해 노력하고 있습니다. 우리는 15:30 UTC로 다른 업데이트를 제공 할 것입니다.

6. 2026년 10월 8일 오후 3:31 UTCidentified

   시간이 계속 감소하지만, Linux 기계 작업 및 원격 도커를 사용하는 고객은 여전히 지연을 경험하고있다. 현재 평균 약 6 분. 가장 긴 대기, 약 20 분, 2xlarge, arm.2xlarge 및 gpu.nvidia에 있습니다. 작은 자원 클래스. 가능한 한 빨리 용량을 추가하기 위해 노력하고 있습니다. 우리는 16:00 UTC로 다른 업데이트를 제공 할 것입니다.

7. 2026년 10월 8일 오후 3:59 UTCidentified

   시간이 계속 감소하지만, Linux 기계 작업 및 원격 도커를 사용하는 고객은 여전히 지연을 경험하고있다. 현재 평균 약 90 초, 가장 긴 대기 시간 약 6 분 일부 자원 수업. 가능한 한 빨리 용량을 추가하기 위해 노력하고 있습니다. 우리는 16:30 UTC로 다른 업데이트를 제공 할 것입니다.

8. 2026년 10월 8일 오후 4:09 UTCmonitoring

   Linux 기계 작업 및 원격 도커를 사용하여 고객을위한 대기 시간은 정상으로 돌아 왔습니다. 우리는 우리가 수용량을 추가하는 것을 계속하는 동안 대기 시간을 안정되어 있는 지키는 감시입니다. 우리는 16:30 UTC로 다른 업데이트를 제공 할 것입니다.

9. 2026년 10월 8일 오후 4:35 UTCresolved

   10월 8일 오후 12시 40분 UTC와 16:00 UTC 사이, Linux 기계 작업 및 원격 도커를 사용하여 고객은 대기 시간을 경험했습니다. 문제는 해결되고 대기 시간이 정상으로 돌아 왔습니다. 우리는 당신의 인내심을 주셔서 감사합니다. 우리 팀은 수정을 구현하기 위해 일했습니다.

10. 2026년 10월 8일 오후 5:54 UTCpostmortem

    ## **Summary ** 10월 1일부터 10월 8일까지, 2026년, CircleCI 고객은 5개의 별도의 사건을 경험해 정상적인 시작보다 더 이상 기다리거나 시작하지 못했습니다. 사건의 세는 우리의 클라우드 공급자로부터 제한된 인스턴스 가용성에 의해 구동되었다. 1은 우리의 스케줄링 인프라의 구성 문제로 발생했고, 내부 서비스에 메모리 제한으로 하나씩 발생했습니다. * **10월 1, 07:57 에 10:24 UTC:** Docker Gen 2 작업은 시작 30 분까지 기다립니다. 구성 문제는 고성능 로컬 디스크를 사용하여 Gen 2 스케줄링 서버를 방지했습니다. 트래픽의 파열 중, 가을 디스크 포화 및 작업 배치가 느립니다. * **10월 7, 13:27에서 14:06 UTC:** 기계 작업은 우리가 우리의 클라우드 공급자에서 충분한 가상 기계를 취득할 수 없기 때문에 정상적인 보다는 더 오래 대기했습니다. * **10월 7, 14:24 에 15:21 UTC:** 일부 작업은 인프라 오류로 실패하고 워크플로우가 지연되었습니다. 각 작업을 제공 하는 서비스 시작에서 구성 메모리와 재시작. * **10월 7, 18:49에서 20:05 UTC:** Docker Gen 2 작업은 클라우드 공급자로부터 충분한 인스턴스를 취득할 수 없기 때문에 정상보다 더 오래 기다리게되었습니다. * **10월 8, 12:48에서 16:00 UTC:** Linux 기계 작업 및 원격 도커 작업은 시작 50 분까지 기다립니다. 우리의 클라우드 공급자는 우리가 요청하는 인스턴스 유형의 충분하지 않았다, 그리고 다른 인스턴스 유형을 선택 논리의 결함은 대안을 사용하여 우리를 유지. 이 사건에 기다린 작업은 지연되지 않았습니다. 작업이 10 월 7 사건 중 인프라 오류로 실패 한 고객은 14 : 24에서 15 : 21 UTC가 중단 될 수 있습니다. 원래 상태 페이지는 아래에 찾을 수 있습니다: * [10 월 1 - Gen 2 Docker Jobs 시작 지연] (https://status.circleci.com/incidents/22mrv46g6n7g) * [10 월 7 - 기계 작업 작업 작업 시작 지연](https://status.circleci.com/incidents/tj6wdnfjwr64) * [10 월 7 - 적외선의 수준은 고객 일에 실패] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [10 월 7 - 도커 Gen2에 대한 작업 대기 시간 증가] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [10 월 8 - 기계 작업을위한 상승 대기 시간] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** 배경 ** CircleCI에서 실행되는 모든 작업은 따릅니다. 그 compute는 executor에 달려 있습니다. Docker 작업은 인스턴스의 함대에 작업을 일정하는 서버 클러스터에서 실행됩니다. Scheduler는 인스턴스가 각 작업을 실행하는 것을 결정하는 그 서버에 소프트웨어입니다. Gen 2 Docker 작업은 10 월 1 사건의 시간에 그런 클러스터에 ran. Gen 1 Docker 작업은 여러 클러스터를 통해 확산됩니다. 원격 도커 작업을 포함한 기계 작업, 전용 가상 기계를 얻을. 원격 도커 작업은 제공을 통해 제출에서 Linux 기계 작업으로 처리됩니다. 우리의 기계 프로비저닝 서비스 요청 우리의 클라우드 제공 업체의 각 기계 중 하나에서 우리는 일반적으로 기계 작업에 사용됩니다. 공급자가 요청한 인스턴스 유형을 공급할 수 없는 경우, 서비스가 다시 떨어질 것입니다: 그것은 다른 인스턴스 유형, 또는 우리가 유지한 리스트에서 다른 지역을 요청합니다. 작업은 기계가 사용할 때까지 기다립니다. 어떤 직업이 시작될 때, 그것은 그것의 윤곽을 위한 일 윤곽 서비스를 요구합니다. 이 서비스는 같은 프로그램의 작은 사본 인 파드 세트로 실행됩니다. 너무 많은 파드가 중지되면 나머지 파드는 더 많은로드를 수행하고, 작업은 서비스 복구까지 시작할 수 없습니다. 이 경로는 3 종류의 용량에 따라 다릅니다. 우리의 스케줄링 시스템의 처리량, 우리의 클라우드 공급자의 인스턴스의 공급 및 작업 시작 서비스의 메모리 및 번호. 그들 중의 부족은 직장 대기 또는 실패합니다. ## **Happened ** \(모든 시간 UTC\) # # # ** 10 월 1 : Docker Gen 2 작업은 30 분까지 지연 ** 07:44, Gen 2 Docker 일자리를 일정하는 서버의 디스크 활동은 용량의 90 %로 상승하고 거기 유지. 에 07:57, 도커 작업의 수는 시작 하기 시작 하기 시작, 및 대기 시간 장미 그것. 자동화된 alert는 08:08의 on-call 엔지니어를 찾습니다. 우리는 08:42에 사건을 선언했다. 08:43에서 엔지니어는 스케줄링 서버에서 높은 디스크 대기 시간을 확인했습니다. 그들은 먼저 디스크가 너무 느리기 때문에 더 빠른 디스크 유형으로 변경을 준비했습니다. 09:01에서 팀은 두 개의 워크스트림에 동의했습니다. 서버가 더 빠른 디스크로 이동하고 두 번째 Gen 2 클러스터를 추가하여 작업이 두 클러스터를 가로 질러 버릴 것입니다. 09:41에서 엔지니어는 뿌리 원인을 발견했습니다. 각 스케줄링 서버는 빠른 디스크가 직접 부착되어 있으며, 스케줄러는 작업 데이터를 유지하는 것이 바람직합니다. 이 서버는 보안 강화 운영 체제 이미지에서 실행되며 빠른 디스크가 사용되지 않았습니다. Scheduler는 대신 느린 네트워크 배치 디스크에 데이터를 썼습니다. 빠른 디스크를 설정하는 스크립트는 오류없이 실패, 이 서버에 로그인의 간격은 실패를 숨깁니다. Gen 2 트래픽은 점점 파열되었습니다. 그 파열 중에 더 느린 디스크 포화, 스케줄러가 뒤에 떨어졌다. 대기 시간 09:54, 에서 작업 할 때 Gen 2 중간 자원 클래스 대기 30 분. 09:55에서 엔지니어는 빠른 디스크를 올바르게 설정하는 수정을 적용했습니다. 10:11에서, 스케줄러는 더 빠른 작업을 시작, 이는 서버가 새로운 작업을 계속할 수 있었다. Gen 2 매체의 대기 시간은 10 : 14에서 13 분, 10 : 17에서 7 분, 10 : 20에서 1 분 30 초. 우리는 10시 24분에서 모니터링하는 상태 페이지를 이동하고 10시 45분에서 사건을 해결했습니다. 11:20에서, 두 번째 Gen 2 클러스터는 작업을 실행 시작. # # # ** 10 월 7, 13 : 27에서 14 : : 기계 작업을위한 상승 대기 시간 ** 우리는 13:27에서 사건을 선언 한 후 높은 큐 팅 및 대기 시간. 우리는 13:31의 상태 페이지에 게시. 13:31, 엔지니어는 우리가 기계 작업을위한 가상 기계를 취득하기 위해 노력하고 있었다, 그리고 시작 작업의 수는 기계 작업에 대한 높은 주로이었다. 13:34, 대기 시간은 executors에 걸쳐 상승했다. 13:48에서, 대기 시간은 더 많은 기계가 사용되기 시작, 우리는 14:06에 사건을 해결. ###**10월 7, 14:24 에 15:21: 작업 실패 및 워크플로우 지연** 이전 사건이 해결 된 후 곧, 우리는 우리의 실행 시스템에 제출 된 작업의 수에 날카로운 하락 때문에 14 : 24의 새로운 사건을 선언했습니다. 14:26에서 엔지니어는 작업 구성 서비스의 파드는 재시작했다. 파드는 요청을 응답하기 위해 서비스의 몇 가지 사본을 떠나고, 반복 된 시도가 인프라 오류로 실패한 후 구성을 검색 할 수 없었던 작업. 이미 실행중인 작업 흐름은 시작되지 않은 작업에서 업데이트를 기다리고 있습니다. 14:35, 엔지니어는 pods에 사용할 수있는 메모리의 양을 증가하고 pods의 수를 증가, 이는 서비스를 더 많은 사본을 공유하기 위해. 우리는 또한 사용할 수있는 메모리의 양을 증가 작업 제출은 복구 시작, 우리의 워크 플로우 시스템을 통해 흐르는 메시지의 수 정상 수준으로 돌아. 14:44, 우리는 모니터링 상태 페이지를 이동. 작업 설정 서비스에서 파드는 메모리 제한 및 재시작에 도달했습니다. 우리는 메모리 할당과 팟 수를 증가, 및 서비스 복구. 15:13, 우리는 Gen 2 Docker 클러스터의 인스턴스 수를 증가 시켰습니다 그래서 우리는 빠른 대기 작업의 백 로그를 통해 작동 할 수 있습니다. 우리는 15:21에 사건을 해결했습니다. ##**10월 7, 18:49 에 20:05: 도커 Gen 2 일자리를 위한 상승 대기 시간** 우리는 Docker Gen 2 대기 시간 장미 후 18:49에서 새로운 사건을 선언했습니다. 18:51, 엔지니어는 가능한 인스턴스의 부족이 대기 시간을 올리는 그들의 충분한 취득에서 우리를 유지 확인. 리소스 클래스 크기에 따라 시간이 다릅니다. 19:52, 평균 대기 시간은 더 많은 용량이 사용되기 때문에, 짧은 스파이크가 계속되고, 우리는 모니터링 상태 페이지를 이동. 우리는 20:05에 사건을 해결했습니다. # # # ** 10 월 8 : Linux 기계 및 원격 도커 작업이 50 분까지 기다립니다 ** 우리는 12:48에 사건을 선언 한 후 기계 및 원격 도커 작업을위한 많은 일자리를보고합니다. 12:49에서 엔지니어는 우리의 클라우드 공급자가 충분한 인스턴스를 공급할 수 없다는 것을 보았습니다. 우리가 조사 한대로 계속되는 지연. 13:13에서, 우리는 우리의 첫번째 선택이 사용할 수 없을 때 다른 인스턴스 유형 또는 지역을 선택할 논리를 시험하기 시작했습니다. 13:24에서, 우리는 그 논리에 결함이 우리의 주요 지역에서 다른 인스턴스 유형 사용에서 우리를 중지했다고 의심, 그래서 우리는 우리의 fallback 지역을 비활성화하고 결함의 원인을 확인. 엔지니어는 수정 작업을 시작하고 14:49에 배포했습니다. 이 서비스는 다른 인스턴스 유형을 요청하고 큰 숫자에서 기계를 시작했습니다. 14:58, 기계에 대 한 기다리는 작업의 큐는 꾸준히 떨어졌다. 리소스 클래스의 평균 대기 시간은 다음 시간 동안 계속됩니다. 우리는 대기 작업의 backlog를 통해 일했습니다. 16:00에, 기계가 명확하고 대기 작업의 수가 정상으로 돌아갑니다. 우리는 16:09에서 모니터링 상태 페이지를 이동하고 16:35에서 사건을 해결. ## **Future 예방 및 공정 개선 ** 우리는 공급 다변화, fallback 논리, 그리고 더 이른 탐지를 포함하여 일 시작 시간의 탄력을 강화하기 위하여 뒤에 오는 단계를 가지고 있습니다. ** 우리는 우리의 compute 지구를 확장하고 있습니다. ** 10월 7일과 10월 8일 사건에서, 우리의 클라우드 공급자는 우리가 사용한 지구에 충분한 예를 공급할 수 없었습니다. 우리는 우리의 선호한 지구를 outpace에 있는 수요를 위한 순서 손잡이 스파이크에 있는 우리의 fallback 논리에 새로운 지구를 추가하고 있습니다. **다른 인스턴스 유형을 선택한 논리를 수정하고 있습니다.** 10월 8일, 결함은 같은 지역에 다른 인스턴스 유형을 사용하여 기계 제공 서비스를 유지. 우리는 사건에 대한 수정을 배포하고 이제이 논리를 전체로 검토하고 다시 작성, 테스트와 함께, 그래서 하나의 인스턴스 유형의 부족은 다른 작업을 이동합니다. ** 우리는 추가 용량을 제공하는 인스턴스 유형을 확장하고 있습니다. ** 우리는 우리의 클라우드 공급자와 협력하여 기존 지역의 추가 용량을 예약하고 작업이 실행될 수있는 인스턴스 유형을 추가하고 있습니다. 고성능 구획을 위한 기업 수요는 성장합니다. 우리는 어디를 다각화하고 우리가 소스 수용량 그래서 우리의 고객은 공급 변이에서 격리됩니다. ** 우리는 두 번째 Gen 2 Docker 클러스터를 추가하므로 트래픽 파열은 두 개의 클러스터에서 배포됩니다. ** 서버 디스크 포화에 대한 경고도 추가하고 스케줄러의 작업이 얼마나 빠른지, 서버가 사용중인 빠른 디스크 없이 시작될 때 화재가 경고합니다. 우리는 디스크 설정 스크립트 오류로 실패했다, 우리는이 서버에서 로그 배송을 복원 그래서 비슷한 문제는 더 빨리 볼 수. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 7일 오후 6:54 UTCidentified

   Docker Gen2의 작업에 대한 증가 된 대기 시간이 있습니다.

2. 2026년 10월 7일 오후 7:00 UTCidentified

   참고 : 지연은 Docker `xlarge` 이상에서 실행하는 사람들을 위해 더 많은 통지가 될 것입니다.

3. 2026년 10월 7일 오후 7:52 UTCmonitoring

   우리는 여전히 작업 대기 시간 동안 스파이크를보고 있지만 평균 대기 시간은 모든 Docker Gen2에 더 잘 찾고 있습니다.

4. 2026년 10월 7일 오후 8:05 UTCresolved

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

5. 2026년 10월 8일 오후 5:54 UTCpostmortem

   ## **Summary ** 10월 1일부터 10월 8일까지, 2026년, CircleCI 고객은 5개의 별도의 사건을 경험해 정상적인 시작보다 더 이상 기다리거나 시작하지 못했습니다. 사건의 세는 우리의 클라우드 공급자로부터 제한된 인스턴스 가용성에 의해 구동되었다. 1은 우리의 스케줄링 인프라의 구성 문제로 발생했고, 내부 서비스에 메모리 제한으로 하나씩 발생했습니다. * **10월 1, 07:57 에 10:24 UTC:** Docker Gen 2 작업은 시작 30 분까지 기다립니다. 구성 문제는 고성능 로컬 디스크를 사용하여 Gen 2 스케줄링 서버를 방지했습니다. 트래픽의 파열 중, 가을 디스크 포화 및 작업 배치가 느립니다. * **10월 7, 13:27에서 14:06 UTC:** 기계 작업은 우리가 우리의 클라우드 공급자에서 충분한 가상 기계를 취득할 수 없기 때문에 정상적인 보다는 더 오래 대기했습니다. * **10월 7, 14:24 에 15:21 UTC:** 일부 작업은 인프라 오류로 실패하고 워크플로우가 지연되었습니다. 각 작업을 제공 하는 서비스 시작에서 구성 메모리와 재시작. * **10월 7, 18:49에서 20:05 UTC:** Docker Gen 2 작업은 클라우드 공급자로부터 충분한 인스턴스를 취득할 수 없기 때문에 정상보다 더 오래 기다리게되었습니다. * **10월 8, 12:48에서 16:00 UTC:** Linux 기계 작업 및 원격 도커 작업은 시작 50 분까지 기다립니다. 우리의 클라우드 공급자는 우리가 요청하는 인스턴스 유형의 충분하지 않았다, 그리고 다른 인스턴스 유형을 선택 논리의 결함은 대안을 사용하여 우리를 유지. 이 사건에 기다린 작업은 지연되지 않았습니다. 작업이 10 월 7 사건 중 인프라 오류로 실패 한 고객은 14 : 24에서 15 : 21 UTC가 중단 될 수 있습니다. 원래 상태 페이지는 아래에 찾을 수 있습니다: * [10 월 1 - Gen 2 Docker Jobs 시작 지연] (https://status.circleci.com/incidents/22mrv46g6n7g) * [10 월 7 - 기계 작업 작업 작업 시작 지연](https://status.circleci.com/incidents/tj6wdnfjwr64) * [10 월 7 - 적외선의 수준은 고객 일에 실패] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [10 월 7 - 도커 Gen2에 대한 작업 대기 시간 증가] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [10 월 8 - 기계 작업을위한 상승 대기 시간] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** 배경 ** CircleCI에서 실행되는 모든 작업은 따릅니다. 그 compute는 executor에 달려 있습니다. Docker 작업은 인스턴스의 함대에 작업을 일정하는 서버 클러스터에서 실행됩니다. Scheduler는 인스턴스가 각 작업을 실행하는 것을 결정하는 그 서버에 소프트웨어입니다. Gen 2 Docker 작업은 10 월 1 사건의 시간에 그런 클러스터에 ran. Gen 1 Docker 작업은 여러 클러스터를 통해 확산됩니다. 원격 도커 작업을 포함한 기계 작업, 전용 가상 기계를 얻을. 원격 도커 작업은 제공을 통해 제출에서 Linux 기계 작업으로 처리됩니다. 우리의 기계 프로비저닝 서비스 요청 우리의 클라우드 제공 업체의 각 기계 중 하나에서 우리는 일반적으로 기계 작업에 사용됩니다. 공급자가 요청한 인스턴스 유형을 공급할 수 없는 경우, 서비스가 다시 떨어질 것입니다: 그것은 다른 인스턴스 유형, 또는 우리가 유지한 리스트에서 다른 지역을 요청합니다. 작업은 기계가 사용할 때까지 기다립니다. 어떤 직업이 시작될 때, 그것은 그것의 윤곽을 위한 일 윤곽 서비스를 요구합니다. 이 서비스는 같은 프로그램의 작은 사본 인 파드 세트로 실행됩니다. 너무 많은 파드가 중지되면 나머지 파드는 더 많은로드를 수행하고, 작업은 서비스 복구까지 시작할 수 없습니다. 이 경로는 3 종류의 용량에 따라 다릅니다. 우리의 스케줄링 시스템의 처리량, 우리의 클라우드 공급자의 인스턴스의 공급 및 작업 시작 서비스의 메모리 및 번호. 그들 중의 부족은 직장 대기 또는 실패합니다. ## **Happened ** \(모든 시간 UTC\) # # # ** 10 월 1 : Docker Gen 2 작업은 30 분까지 지연 ** 07:44, Gen 2 Docker 일자리를 일정하는 서버의 디스크 활동은 용량의 90 %로 상승하고 거기 유지. 에 07:57, 도커 작업의 수는 시작 하기 시작 하기 시작, 및 대기 시간 장미 그것. 자동화된 alert는 08:08의 on-call 엔지니어를 찾습니다. 우리는 08:42에 사건을 선언했다. 08:43에서 엔지니어는 스케줄링 서버에서 높은 디스크 대기 시간을 확인했습니다. 그들은 먼저 디스크가 너무 느리기 때문에 더 빠른 디스크 유형으로 변경을 준비했습니다. 09:01에서 팀은 두 개의 워크스트림에 동의했습니다. 서버가 더 빠른 디스크로 이동하고 두 번째 Gen 2 클러스터를 추가하여 작업이 두 클러스터를 가로 질러 버릴 것입니다. 09:41에서 엔지니어는 뿌리 원인을 발견했습니다. 각 스케줄링 서버는 빠른 디스크가 직접 부착되어 있으며, 스케줄러는 작업 데이터를 유지하는 것이 바람직합니다. 이 서버는 보안 강화 운영 체제 이미지에서 실행되며 빠른 디스크가 사용되지 않았습니다. Scheduler는 대신 느린 네트워크 배치 디스크에 데이터를 썼습니다. 빠른 디스크를 설정하는 스크립트는 오류없이 실패, 이 서버에 로그인의 간격은 실패를 숨깁니다. Gen 2 트래픽은 점점 파열되었습니다. 그 파열 중에 더 느린 디스크 포화, 스케줄러가 뒤에 떨어졌다. 대기 시간 09:54, 에서 작업 할 때 Gen 2 중간 자원 클래스 대기 30 분. 09:55에서 엔지니어는 빠른 디스크를 올바르게 설정하는 수정을 적용했습니다. 10:11에서, 스케줄러는 더 빠른 작업을 시작, 이는 서버가 새로운 작업을 계속할 수 있었다. Gen 2 매체의 대기 시간은 10 : 14에서 13 분, 10 : 17에서 7 분, 10 : 20에서 1 분 30 초. 우리는 10시 24분에서 모니터링하는 상태 페이지를 이동하고 10시 45분에서 사건을 해결했습니다. 11:20에서, 두 번째 Gen 2 클러스터는 작업을 실행 시작. # # # ** 10 월 7, 13 : 27에서 14 : : 기계 작업을위한 상승 대기 시간 ** 우리는 13:27에서 사건을 선언 한 후 높은 큐 팅 및 대기 시간. 우리는 13:31의 상태 페이지에 게시. 13:31, 엔지니어는 우리가 기계 작업을위한 가상 기계를 취득하기 위해 노력하고 있었다, 그리고 시작 작업의 수는 기계 작업에 대한 높은 주로이었다. 13:34, 대기 시간은 executors에 걸쳐 상승했다. 13:48에서, 대기 시간은 더 많은 기계가 사용되기 시작, 우리는 14:06에 사건을 해결. ###**10월 7, 14:24 에 15:21: 작업 실패 및 워크플로우 지연** 이전 사건이 해결 된 후 곧, 우리는 우리의 실행 시스템에 제출 된 작업의 수에 날카로운 하락 때문에 14 : 24의 새로운 사건을 선언했습니다. 14:26에서 엔지니어는 작업 구성 서비스의 파드는 재시작했다. 파드는 요청을 응답하기 위해 서비스의 몇 가지 사본을 떠나고, 반복 된 시도가 인프라 오류로 실패한 후 구성을 검색 할 수 없었던 작업. 이미 실행중인 작업 흐름은 시작되지 않은 작업에서 업데이트를 기다리고 있습니다. 14:35, 엔지니어는 pods에 사용할 수있는 메모리의 양을 증가하고 pods의 수를 증가, 이는 서비스를 더 많은 사본을 공유하기 위해. 우리는 또한 사용할 수있는 메모리의 양을 증가 작업 제출은 복구 시작, 우리의 워크 플로우 시스템을 통해 흐르는 메시지의 수 정상 수준으로 돌아. 14:44, 우리는 모니터링 상태 페이지를 이동. 작업 설정 서비스에서 파드는 메모리 제한 및 재시작에 도달했습니다. 우리는 메모리 할당과 팟 수를 증가, 및 서비스 복구. 15:13, 우리는 Gen 2 Docker 클러스터의 인스턴스 수를 증가 시켰습니다 그래서 우리는 빠른 대기 작업의 백 로그를 통해 작동 할 수 있습니다. 우리는 15:21에 사건을 해결했습니다. ##**10월 7, 18:49 에 20:05: 도커 Gen 2 일자리를 위한 상승 대기 시간** 우리는 Docker Gen 2 대기 시간 장미 후 18:49에서 새로운 사건을 선언했습니다. 18:51, 엔지니어는 가능한 인스턴스의 부족이 대기 시간을 올리는 그들의 충분한 취득에서 우리를 유지 확인. 리소스 클래스 크기에 따라 시간이 다릅니다. 19:52, 평균 대기 시간은 더 많은 용량이 사용되기 때문에, 짧은 스파이크가 계속되고, 우리는 모니터링 상태 페이지를 이동. 우리는 20:05에 사건을 해결했습니다. # # # ** 10 월 8 : Linux 기계 및 원격 도커 작업이 50 분까지 기다립니다 ** 우리는 12:48에 사건을 선언 한 후 기계 및 원격 도커 작업을위한 많은 일자리를보고합니다. 12:49에서 엔지니어는 우리의 클라우드 공급자가 충분한 인스턴스를 공급할 수 없다는 것을 보았습니다. 우리가 조사 한대로 계속되는 지연. 13:13에서, 우리는 우리의 첫번째 선택이 사용할 수 없을 때 다른 인스턴스 유형 또는 지역을 선택할 논리를 시험하기 시작했습니다. 13:24에서, 우리는 그 논리에 결함이 우리의 주요 지역에서 다른 인스턴스 유형 사용에서 우리를 중지했다고 의심, 그래서 우리는 우리의 fallback 지역을 비활성화하고 결함의 원인을 확인. 엔지니어는 수정 작업을 시작하고 14:49에 배포했습니다. 이 서비스는 다른 인스턴스 유형을 요청하고 큰 숫자에서 기계를 시작했습니다. 14:58, 기계에 대 한 기다리는 작업의 큐는 꾸준히 떨어졌다. 리소스 클래스의 평균 대기 시간은 다음 시간 동안 계속됩니다. 우리는 대기 작업의 backlog를 통해 일했습니다. 16:00에, 기계가 명확하고 대기 작업의 수가 정상으로 돌아갑니다. 우리는 16:09에서 모니터링 상태 페이지를 이동하고 16:35에서 사건을 해결. ## **Future 예방 및 공정 개선 ** 우리는 공급 다변화, fallback 논리, 그리고 더 이른 탐지를 포함하여 일 시작 시간의 탄력을 강화하기 위하여 뒤에 오는 단계를 가지고 있습니다. ** 우리는 우리의 compute 지구를 확장하고 있습니다. ** 10월 7일과 10월 8일 사건에서, 우리의 클라우드 공급자는 우리가 사용한 지구에 충분한 예를 공급할 수 없었습니다. 우리는 우리의 선호한 지구를 outpace에 있는 수요를 위한 순서 손잡이 스파이크에 있는 우리의 fallback 논리에 새로운 지구를 추가하고 있습니다. **다른 인스턴스 유형을 선택한 논리를 수정하고 있습니다.** 10월 8일, 결함은 같은 지역에 다른 인스턴스 유형을 사용하여 기계 제공 서비스를 유지. 우리는 사건에 대한 수정을 배포하고 이제이 논리를 전체로 검토하고 다시 작성, 테스트와 함께, 그래서 하나의 인스턴스 유형의 부족은 다른 작업을 이동합니다. ** 우리는 추가 용량을 제공하는 인스턴스 유형을 확장하고 있습니다. ** 우리는 우리의 클라우드 공급자와 협력하여 기존 지역의 추가 용량을 예약하고 작업이 실행될 수있는 인스턴스 유형을 추가하고 있습니다. 고성능 구획을 위한 기업 수요는 성장합니다. 우리는 어디를 다각화하고 우리가 소스 수용량 그래서 우리의 고객은 공급 변이에서 격리됩니다. ** 우리는 두 번째 Gen 2 Docker 클러스터를 추가하므로 트래픽 파열은 두 개의 클러스터에서 배포됩니다. ** 서버 디스크 포화에 대한 경고도 추가하고 스케줄러의 작업이 얼마나 빠른지, 서버가 사용중인 빠른 디스크 없이 시작될 때 화재가 경고합니다. 우리는 디스크 설정 스크립트 오류로 실패했다, 우리는이 서버에서 로그 배송을 복원 그래서 비슷한 문제는 더 빨리 볼 수. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 7일 오후 2:27 UTCinvestigating

   우리는 infra에서 상승을 투자하고 있습니다.

2. 2026년 10월 7일 오후 2:44 UTCmonitoring

   우리는 회복의 징후를 본다. Docker Gen2 대기 시간은 약간 높고 모니터링합니다.

3. 2026년 10월 7일 오후 3:21 UTCresolved

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

4. 2026년 10월 8일 오후 5:55 UTCpostmortem

   ## **Summary ** 10월 1일부터 10월 8일까지, 2026년, CircleCI 고객은 5개의 별도의 사건을 경험해 정상적인 시작보다 더 이상 기다리거나 시작하지 못했습니다. 사건의 세는 우리의 클라우드 공급자로부터 제한된 인스턴스 가용성에 의해 구동되었다. 1은 우리의 스케줄링 인프라의 구성 문제로 발생했고, 내부 서비스에 메모리 제한으로 하나씩 발생했습니다. * **10월 1, 07:57 에 10:24 UTC:** Docker Gen 2 작업은 시작 30 분까지 기다립니다. 구성 문제는 고성능 로컬 디스크를 사용하여 Gen 2 스케줄링 서버를 방지했습니다. 트래픽의 파열 중, 가을 디스크 포화 및 작업 배치가 느립니다. * **10월 7, 13:27에서 14:06 UTC:** 기계 작업은 우리가 우리의 클라우드 공급자에서 충분한 가상 기계를 취득할 수 없기 때문에 정상적인 보다는 더 오래 대기했습니다. * **10월 7, 14:24 에 15:21 UTC:** 일부 작업은 인프라 오류로 실패하고 워크플로우가 지연되었습니다. 각 작업을 제공 하는 서비스 시작에서 구성 메모리와 재시작. * **10월 7, 18:49에서 20:05 UTC:** Docker Gen 2 작업은 클라우드 공급자로부터 충분한 인스턴스를 취득할 수 없기 때문에 정상보다 더 오래 기다리게되었습니다. * **10월 8, 12:48에서 16:00 UTC:** Linux 기계 작업 및 원격 도커 작업은 시작 50 분까지 기다립니다. 우리의 클라우드 공급자는 우리가 요청하는 인스턴스 유형의 충분하지 않았다, 그리고 다른 인스턴스 유형을 선택 논리의 결함은 대안을 사용하여 우리를 유지. 이 사건에 기다린 작업은 지연되지 않았습니다. 작업이 10 월 7 사건 중 인프라 오류로 실패 한 고객은 14 : 24에서 15 : 21 UTC가 중단 될 수 있습니다. 원래 상태 페이지는 아래에 찾을 수 있습니다: * [10 월 1 - Gen 2 Docker Jobs 시작 지연] (https://status.circleci.com/incidents/22mrv46g6n7g) * [10 월 7 - 기계 작업 작업 작업 시작 지연](https://status.circleci.com/incidents/tj6wdnfjwr64) * [10 월 7 - 적외선의 수준은 고객 일에 실패] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [10 월 7 - 도커 Gen2에 대한 작업 대기 시간 증가] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [10 월 8 - 기계 작업을위한 상승 대기 시간] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** 배경 ** CircleCI에서 실행되는 모든 작업은 따릅니다. 그 compute는 executor에 달려 있습니다. Docker 작업은 인스턴스의 함대에 작업을 일정하는 서버 클러스터에서 실행됩니다. Scheduler는 인스턴스가 각 작업을 실행하는 것을 결정하는 그 서버에 소프트웨어입니다. Gen 2 Docker 작업은 10 월 1 사건의 시간에 그런 클러스터에 ran. Gen 1 Docker 작업은 여러 클러스터를 통해 확산됩니다. 원격 도커 작업을 포함한 기계 작업, 전용 가상 기계를 얻을. 원격 도커 작업은 제공을 통해 제출에서 Linux 기계 작업으로 처리됩니다. 우리의 기계 프로비저닝 서비스 요청 우리의 클라우드 제공 업체의 각 기계 중 하나에서 우리는 일반적으로 기계 작업에 사용됩니다. 공급자가 요청한 인스턴스 유형을 공급할 수 없는 경우, 서비스가 다시 떨어질 것입니다: 그것은 다른 인스턴스 유형, 또는 우리가 유지한 리스트에서 다른 지역을 요청합니다. 작업은 기계가 사용할 때까지 기다립니다. 어떤 직업이 시작될 때, 그것은 그것의 윤곽을 위한 일 윤곽 서비스를 요구합니다. 이 서비스는 같은 프로그램의 작은 사본 인 파드 세트로 실행됩니다. 너무 많은 파드가 중지되면 나머지 파드는 더 많은로드를 수행하고, 작업은 서비스 복구까지 시작할 수 없습니다. 이 경로는 3 종류의 용량에 따라 다릅니다. 우리의 스케줄링 시스템의 처리량, 우리의 클라우드 공급자의 인스턴스의 공급 및 작업 시작 서비스의 메모리 및 번호. 그들 중의 부족은 직장 대기 또는 실패합니다. ## **Happened ** \(모든 시간 UTC\) # # # ** 10 월 1 : Docker Gen 2 작업은 30 분까지 지연 ** 07:44, Gen 2 Docker 일자리를 일정하는 서버의 디스크 활동은 용량의 90 %로 상승하고 거기 유지. 에 07:57, 도커 작업의 수는 시작 하기 시작 하기 시작, 및 대기 시간 장미 그것. 자동화된 alert는 08:08의 on-call 엔지니어를 찾습니다. 우리는 08:42에 사건을 선언했다. 08:43에서 엔지니어는 스케줄링 서버에서 높은 디스크 대기 시간을 확인했습니다. 그들은 먼저 디스크가 너무 느리기 때문에 더 빠른 디스크 유형으로 변경을 준비했습니다. 09:01에서 팀은 두 개의 워크스트림에 동의했습니다. 서버가 더 빠른 디스크로 이동하고 두 번째 Gen 2 클러스터를 추가하여 작업이 두 클러스터를 가로 질러 버릴 것입니다. 09:41에서 엔지니어는 뿌리 원인을 발견했습니다. 각 스케줄링 서버는 빠른 디스크가 직접 부착되어 있으며, 스케줄러는 작업 데이터를 유지하는 것이 바람직합니다. 이 서버는 보안 강화 운영 체제 이미지에서 실행되며 빠른 디스크가 사용되지 않았습니다. Scheduler는 대신 느린 네트워크 배치 디스크에 데이터를 썼습니다. 빠른 디스크를 설정하는 스크립트는 오류없이 실패, 이 서버에 로그인의 간격은 실패를 숨깁니다. Gen 2 트래픽은 점점 파열되었습니다. 그 파열 중에 더 느린 디스크 포화, 스케줄러가 뒤에 떨어졌다. 대기 시간 09:54, 에서 작업 할 때 Gen 2 중간 자원 클래스 대기 30 분. 09:55에서 엔지니어는 빠른 디스크를 올바르게 설정하는 수정을 적용했습니다. 10:11에서, 스케줄러는 더 빠른 작업을 시작, 이는 서버가 새로운 작업을 계속할 수 있었다. Gen 2 매체의 대기 시간은 10 : 14에서 13 분, 10 : 17에서 7 분, 10 : 20에서 1 분 30 초. 우리는 10시 24분에서 모니터링하는 상태 페이지를 이동하고 10시 45분에서 사건을 해결했습니다. 11:20에서, 두 번째 Gen 2 클러스터는 작업을 실행 시작. # # # ** 10 월 7, 13 : 27에서 14 : : 기계 작업을위한 상승 대기 시간 ** 우리는 13:27에서 사건을 선언 한 후 높은 큐 팅 및 대기 시간. 우리는 13:31의 상태 페이지에 게시. 13:31, 엔지니어는 우리가 기계 작업을위한 가상 기계를 취득하기 위해 노력하고 있었다, 그리고 시작 작업의 수는 기계 작업에 대한 높은 주로이었다. 13:34, 대기 시간은 executors에 걸쳐 상승했다. 13:48에서, 대기 시간은 더 많은 기계가 사용되기 시작, 우리는 14:06에 사건을 해결. ###**10월 7, 14:24 에 15:21: 작업 실패 및 워크플로우 지연** 이전 사건이 해결 된 후 곧, 우리는 우리의 실행 시스템에 제출 된 작업의 수에 날카로운 하락 때문에 14 : 24의 새로운 사건을 선언했습니다. 14:26에서 엔지니어는 작업 구성 서비스의 파드는 재시작했다. 파드는 요청을 응답하기 위해 서비스의 몇 가지 사본을 떠나고, 반복 된 시도가 인프라 오류로 실패한 후 구성을 검색 할 수 없었던 작업. 이미 실행중인 작업 흐름은 시작되지 않은 작업에서 업데이트를 기다리고 있습니다. 14:35, 엔지니어는 pods에 사용할 수있는 메모리의 양을 증가하고 pods의 수를 증가, 이는 서비스를 더 많은 사본을 공유하기 위해. 우리는 또한 사용할 수있는 메모리의 양을 증가 작업 제출은 복구 시작, 우리의 워크 플로우 시스템을 통해 흐르는 메시지의 수 정상 수준으로 돌아. 14:44, 우리는 모니터링 상태 페이지를 이동. 작업 설정 서비스에서 파드는 메모리 제한 및 재시작에 도달했습니다. 우리는 메모리 할당과 팟 수를 증가, 및 서비스 복구. 15:13, 우리는 Gen 2 Docker 클러스터의 인스턴스 수를 증가 시켰습니다 그래서 우리는 빠른 대기 작업의 백 로그를 통해 작동 할 수 있습니다. 우리는 15:21에 사건을 해결했습니다. ##**10월 7, 18:49 에 20:05: 도커 Gen 2 일자리를 위한 상승 대기 시간** 우리는 Docker Gen 2 대기 시간 장미 후 18:49에서 새로운 사건을 선언했습니다. 18:51, 엔지니어는 가능한 인스턴스의 부족이 대기 시간을 올리는 그들의 충분한 취득에서 우리를 유지 확인. 리소스 클래스 크기에 따라 시간이 다릅니다. 19:52, 평균 대기 시간은 더 많은 용량이 사용되기 때문에, 짧은 스파이크가 계속되고, 우리는 모니터링 상태 페이지를 이동. 우리는 20:05에 사건을 해결했습니다. # # # ** 10 월 8 : Linux 기계 및 원격 도커 작업이 50 분까지 기다립니다 ** 우리는 12:48에 사건을 선언 한 후 기계 및 원격 도커 작업을위한 많은 일자리를보고합니다. 12:49에서 엔지니어는 우리의 클라우드 공급자가 충분한 인스턴스를 공급할 수 없다는 것을 보았습니다. 우리가 조사 한대로 계속되는 지연. 13:13에서, 우리는 우리의 첫번째 선택이 사용할 수 없을 때 다른 인스턴스 유형 또는 지역을 선택할 논리를 시험하기 시작했습니다. 13:24에서, 우리는 그 논리에 결함이 우리의 주요 지역에서 다른 인스턴스 유형 사용에서 우리를 중지했다고 의심, 그래서 우리는 우리의 fallback 지역을 비활성화하고 결함의 원인을 확인. 엔지니어는 수정 작업을 시작하고 14:49에 배포했습니다. 이 서비스는 다른 인스턴스 유형을 요청하고 큰 숫자에서 기계를 시작했습니다. 14:58, 기계에 대 한 기다리는 작업의 큐는 꾸준히 떨어졌다. 리소스 클래스의 평균 대기 시간은 다음 시간 동안 계속됩니다. 우리는 대기 작업의 backlog를 통해 일했습니다. 16:00에, 기계가 명확하고 대기 작업의 수가 정상으로 돌아갑니다. 우리는 16:09에서 모니터링 상태 페이지를 이동하고 16:35에서 사건을 해결. ## **Future 예방 및 공정 개선 ** 우리는 공급 다변화, fallback 논리, 그리고 더 이른 탐지를 포함하여 일 시작 시간의 탄력을 강화하기 위하여 뒤에 오는 단계를 가지고 있습니다. ** 우리는 우리의 compute 지구를 확장하고 있습니다. ** 10월 7일과 10월 8일 사건에서, 우리의 클라우드 공급자는 우리가 사용한 지구에 충분한 예를 공급할 수 없었습니다. 우리는 우리의 선호한 지구를 outpace에 있는 수요를 위한 순서 손잡이 스파이크에 있는 우리의 fallback 논리에 새로운 지구를 추가하고 있습니다. **다른 인스턴스 유형을 선택한 논리를 수정하고 있습니다.** 10월 8일, 결함은 같은 지역에 다른 인스턴스 유형을 사용하여 기계 제공 서비스를 유지. 우리는 사건에 대한 수정을 배포하고 이제이 논리를 전체로 검토하고 다시 작성, 테스트와 함께, 그래서 하나의 인스턴스 유형의 부족은 다른 작업을 이동합니다. ** 우리는 추가 용량을 제공하는 인스턴스 유형을 확장하고 있습니다. ** 우리는 우리의 클라우드 공급자와 협력하여 기존 지역의 추가 용량을 예약하고 작업이 실행될 수있는 인스턴스 유형을 추가하고 있습니다. 고성능 구획을 위한 기업 수요는 성장합니다. 우리는 어디를 다각화하고 우리가 소스 수용량 그래서 우리의 고객은 공급 변이에서 격리됩니다. ** 우리는 두 번째 Gen 2 Docker 클러스터를 추가하므로 트래픽 파열은 두 개의 클러스터에서 배포됩니다. ** 서버 디스크 포화에 대한 경고도 추가하고 스케줄러의 작업이 얼마나 빠른지, 서버가 사용중인 빠른 디스크 없이 시작될 때 화재가 경고합니다. 우리는 디스크 설정 스크립트 오류로 실패했다, 우리는이 서버에서 로그 배송을 복원 그래서 비슷한 문제는 더 빨리 볼 수. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 7일 오후 1:40 UTCinvestigating

   고객은 기계 작업 작업 작업 작업에 대 한 높은 대기 시간을 경험할 수 있습니다, 우리는 루트 원인을 조사 하 고 우리가 더 알고 있을 때 업데이트 됩니다.

2. 2026년 10월 7일 오후 1:52 UTCmonitoring

   우리는 복구의 징후를보고 상황을 모니터링합니다.

3. 2026년 10월 7일 오후 2:06 UTCresolved

   사건이 해결되었습니다. 감사합니다

4. 2026년 10월 8일 오후 5:55 UTCpostmortem

   ## **Summary ** 10월 1일부터 10월 8일까지, 2026년, CircleCI 고객은 5개의 별도의 사건을 경험해 정상적인 시작보다 더 이상 기다리거나 시작하지 못했습니다. 사건의 세는 우리의 클라우드 공급자로부터 제한된 인스턴스 가용성에 의해 구동되었다. 1은 우리의 스케줄링 인프라의 구성 문제로 발생했고, 내부 서비스에 메모리 제한으로 하나씩 발생했습니다. * **10월 1, 07:57 에 10:24 UTC:** Docker Gen 2 작업은 시작 30 분까지 기다립니다. 구성 문제는 고성능 로컬 디스크를 사용하여 Gen 2 스케줄링 서버를 방지했습니다. 트래픽의 파열 중, 가을 디스크 포화 및 작업 배치가 느립니다. * **10월 7, 13:27에서 14:06 UTC:** 기계 작업은 우리가 우리의 클라우드 공급자에서 충분한 가상 기계를 취득할 수 없기 때문에 정상적인 보다는 더 오래 대기했습니다. * **10월 7, 14:24 에 15:21 UTC:** 일부 작업은 인프라 오류로 실패하고 워크플로우가 지연되었습니다. 각 작업을 제공 하는 서비스 시작에서 구성 메모리와 재시작. * **10월 7, 18:49에서 20:05 UTC:** Docker Gen 2 작업은 클라우드 공급자로부터 충분한 인스턴스를 취득할 수 없기 때문에 정상보다 더 오래 기다리게되었습니다. * **10월 8, 12:48에서 16:00 UTC:** Linux 기계 작업 및 원격 도커 작업은 시작 50 분까지 기다립니다. 우리의 클라우드 공급자는 우리가 요청하는 인스턴스 유형의 충분하지 않았다, 그리고 다른 인스턴스 유형을 선택 논리의 결함은 대안을 사용하여 우리를 유지. 이 사건에 기다린 작업은 지연되지 않았습니다. 작업이 10 월 7 사건 중 인프라 오류로 실패 한 고객은 14 : 24에서 15 : 21 UTC가 중단 될 수 있습니다. 원래 상태 페이지는 아래에 찾을 수 있습니다: * [10 월 1 - Gen 2 Docker Jobs 시작 지연] (https://status.circleci.com/incidents/22mrv46g6n7g) * [10 월 7 - 기계 작업 작업 작업 시작 지연](https://status.circleci.com/incidents/tj6wdnfjwr64) * [10 월 7 - 적외선의 수준은 고객 일에 실패] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [10 월 7 - 도커 Gen2에 대한 작업 대기 시간 증가] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [10 월 8 - 기계 작업을위한 상승 대기 시간] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** 배경 ** CircleCI에서 실행되는 모든 작업은 따릅니다. 그 compute는 executor에 달려 있습니다. Docker 작업은 인스턴스의 함대에 작업을 일정하는 서버 클러스터에서 실행됩니다. Scheduler는 인스턴스가 각 작업을 실행하는 것을 결정하는 그 서버에 소프트웨어입니다. Gen 2 Docker 작업은 10 월 1 사건의 시간에 그런 클러스터에 ran. Gen 1 Docker 작업은 여러 클러스터를 통해 확산됩니다. 원격 도커 작업을 포함한 기계 작업, 전용 가상 기계를 얻을. 원격 도커 작업은 제공을 통해 제출에서 Linux 기계 작업으로 처리됩니다. 우리의 기계 프로비저닝 서비스 요청 우리의 클라우드 제공 업체의 각 기계 중 하나에서 우리는 일반적으로 기계 작업에 사용됩니다. 공급자가 요청한 인스턴스 유형을 공급할 수 없는 경우, 서비스가 다시 떨어질 것입니다: 그것은 다른 인스턴스 유형, 또는 우리가 유지한 리스트에서 다른 지역을 요청합니다. 작업은 기계가 사용할 때까지 기다립니다. 어떤 직업이 시작될 때, 그것은 그것의 윤곽을 위한 일 윤곽 서비스를 요구합니다. 이 서비스는 같은 프로그램의 작은 사본 인 파드 세트로 실행됩니다. 너무 많은 파드가 중지되면 나머지 파드는 더 많은로드를 수행하고, 작업은 서비스 복구까지 시작할 수 없습니다. 이 경로는 3 종류의 용량에 따라 다릅니다. 우리의 스케줄링 시스템의 처리량, 우리의 클라우드 공급자의 인스턴스의 공급 및 작업 시작 서비스의 메모리 및 번호. 그들 중의 부족은 직장 대기 또는 실패합니다. ## **Happened ** \(모든 시간 UTC\) # # # ** 10 월 1 : Docker Gen 2 작업은 30 분까지 지연 ** 07:44, Gen 2 Docker 일자리를 일정하는 서버의 디스크 활동은 용량의 90 %로 상승하고 거기 유지. 에 07:57, 도커 작업의 수는 시작 하기 시작 하기 시작, 및 대기 시간 장미 그것. 자동화된 alert는 08:08의 on-call 엔지니어를 찾습니다. 우리는 08:42에 사건을 선언했다. 08:43에서 엔지니어는 스케줄링 서버에서 높은 디스크 대기 시간을 확인했습니다. 그들은 먼저 디스크가 너무 느리기 때문에 더 빠른 디스크 유형으로 변경을 준비했습니다. 09:01에서 팀은 두 개의 워크스트림에 동의했습니다. 서버가 더 빠른 디스크로 이동하고 두 번째 Gen 2 클러스터를 추가하여 작업이 두 클러스터를 가로 질러 버릴 것입니다. 09:41에서 엔지니어는 뿌리 원인을 발견했습니다. 각 스케줄링 서버는 빠른 디스크가 직접 부착되어 있으며, 스케줄러는 작업 데이터를 유지하는 것이 바람직합니다. 이 서버는 보안 강화 운영 체제 이미지에서 실행되며 빠른 디스크가 사용되지 않았습니다. Scheduler는 대신 느린 네트워크 배치 디스크에 데이터를 썼습니다. 빠른 디스크를 설정하는 스크립트는 오류없이 실패, 이 서버에 로그인의 간격은 실패를 숨깁니다. Gen 2 트래픽은 점점 파열되었습니다. 그 파열 중에 더 느린 디스크 포화, 스케줄러가 뒤에 떨어졌다. 대기 시간 09:54, 에서 작업 할 때 Gen 2 중간 자원 클래스 대기 30 분. 09:55에서 엔지니어는 빠른 디스크를 올바르게 설정하는 수정을 적용했습니다. 10:11에서, 스케줄러는 더 빠른 작업을 시작, 이는 서버가 새로운 작업을 계속할 수 있었다. Gen 2 매체의 대기 시간은 10 : 14에서 13 분, 10 : 17에서 7 분, 10 : 20에서 1 분 30 초. 우리는 10시 24분에서 모니터링하는 상태 페이지를 이동하고 10시 45분에서 사건을 해결했습니다. 11:20에서, 두 번째 Gen 2 클러스터는 작업을 실행 시작. # # # ** 10 월 7, 13 : 27에서 14 : : 기계 작업을위한 상승 대기 시간 ** 우리는 13:27에서 사건을 선언 한 후 높은 큐 팅 및 대기 시간. 우리는 13:31의 상태 페이지에 게시. 13:31, 엔지니어는 우리가 기계 작업을위한 가상 기계를 취득하기 위해 노력하고 있었다, 그리고 시작 작업의 수는 기계 작업에 대한 높은 주로이었다. 13:34, 대기 시간은 executors에 걸쳐 상승했다. 13:48에서, 대기 시간은 더 많은 기계가 사용되기 시작, 우리는 14:06에 사건을 해결. ###**10월 7, 14:24 에 15:21: 작업 실패 및 워크플로우 지연** 이전 사건이 해결 된 후 곧, 우리는 우리의 실행 시스템에 제출 된 작업의 수에 날카로운 하락 때문에 14 : 24의 새로운 사건을 선언했습니다. 14:26에서 엔지니어는 작업 구성 서비스의 파드는 재시작했다. 파드는 요청을 응답하기 위해 서비스의 몇 가지 사본을 떠나고, 반복 된 시도가 인프라 오류로 실패한 후 구성을 검색 할 수 없었던 작업. 이미 실행중인 작업 흐름은 시작되지 않은 작업에서 업데이트를 기다리고 있습니다. 14:35, 엔지니어는 pods에 사용할 수있는 메모리의 양을 증가하고 pods의 수를 증가, 이는 서비스를 더 많은 사본을 공유하기 위해. 우리는 또한 사용할 수있는 메모리의 양을 증가 작업 제출은 복구 시작, 우리의 워크 플로우 시스템을 통해 흐르는 메시지의 수 정상 수준으로 돌아. 14:44, 우리는 모니터링 상태 페이지를 이동. 작업 설정 서비스에서 파드는 메모리 제한 및 재시작에 도달했습니다. 우리는 메모리 할당과 팟 수를 증가, 및 서비스 복구. 15:13, 우리는 Gen 2 Docker 클러스터의 인스턴스 수를 증가 시켰습니다 그래서 우리는 빠른 대기 작업의 백 로그를 통해 작동 할 수 있습니다. 우리는 15:21에 사건을 해결했습니다. ##**10월 7, 18:49 에 20:05: 도커 Gen 2 일자리를 위한 상승 대기 시간** 우리는 Docker Gen 2 대기 시간 장미 후 18:49에서 새로운 사건을 선언했습니다. 18:51, 엔지니어는 가능한 인스턴스의 부족이 대기 시간을 올리는 그들의 충분한 취득에서 우리를 유지 확인. 리소스 클래스 크기에 따라 시간이 다릅니다. 19:52, 평균 대기 시간은 더 많은 용량이 사용되기 때문에, 짧은 스파이크가 계속되고, 우리는 모니터링 상태 페이지를 이동. 우리는 20:05에 사건을 해결했습니다. # # # ** 10 월 8 : Linux 기계 및 원격 도커 작업이 50 분까지 기다립니다 ** 우리는 12:48에 사건을 선언 한 후 기계 및 원격 도커 작업을위한 많은 일자리를보고합니다. 12:49에서 엔지니어는 우리의 클라우드 공급자가 충분한 인스턴스를 공급할 수 없다는 것을 보았습니다. 우리가 조사 한대로 계속되는 지연. 13:13에서, 우리는 우리의 첫번째 선택이 사용할 수 없을 때 다른 인스턴스 유형 또는 지역을 선택할 논리를 시험하기 시작했습니다. 13:24에서, 우리는 그 논리에 결함이 우리의 주요 지역에서 다른 인스턴스 유형 사용에서 우리를 중지했다고 의심, 그래서 우리는 우리의 fallback 지역을 비활성화하고 결함의 원인을 확인. 엔지니어는 수정 작업을 시작하고 14:49에 배포했습니다. 이 서비스는 다른 인스턴스 유형을 요청하고 큰 숫자에서 기계를 시작했습니다. 14:58, 기계에 대 한 기다리는 작업의 큐는 꾸준히 떨어졌다. 리소스 클래스의 평균 대기 시간은 다음 시간 동안 계속됩니다. 우리는 대기 작업의 backlog를 통해 일했습니다. 16:00에, 기계가 명확하고 대기 작업의 수가 정상으로 돌아갑니다. 우리는 16:09에서 모니터링 상태 페이지를 이동하고 16:35에서 사건을 해결. ## **Future 예방 및 공정 개선 ** 우리는 공급 다변화, fallback 논리, 그리고 더 이른 탐지를 포함하여 일 시작 시간의 탄력을 강화하기 위하여 뒤에 오는 단계를 가지고 있습니다. ** 우리는 우리의 compute 지구를 확장하고 있습니다. ** 10월 7일과 10월 8일 사건에서, 우리의 클라우드 공급자는 우리가 사용한 지구에 충분한 예를 공급할 수 없었습니다. 우리는 우리의 선호한 지구를 outpace에 있는 수요를 위한 순서 손잡이 스파이크에 있는 우리의 fallback 논리에 새로운 지구를 추가하고 있습니다. **다른 인스턴스 유형을 선택한 논리를 수정하고 있습니다.** 10월 8일, 결함은 같은 지역에 다른 인스턴스 유형을 사용하여 기계 제공 서비스를 유지. 우리는 사건에 대한 수정을 배포하고 이제이 논리를 전체로 검토하고 다시 작성, 테스트와 함께, 그래서 하나의 인스턴스 유형의 부족은 다른 작업을 이동합니다. ** 우리는 추가 용량을 제공하는 인스턴스 유형을 확장하고 있습니다. ** 우리는 우리의 클라우드 공급자와 협력하여 기존 지역의 추가 용량을 예약하고 작업이 실행될 수있는 인스턴스 유형을 추가하고 있습니다. 고성능 구획을 위한 기업 수요는 성장합니다. 우리는 어디를 다각화하고 우리가 소스 수용량 그래서 우리의 고객은 공급 변이에서 격리됩니다. ** 우리는 두 번째 Gen 2 Docker 클러스터를 추가하므로 트래픽 파열은 두 개의 클러스터에서 배포됩니다. ** 서버 디스크 포화에 대한 경고도 추가하고 스케줄러의 작업이 얼마나 빠른지, 서버가 사용중인 빠른 디스크 없이 시작될 때 화재가 경고합니다. 우리는 디스크 설정 스크립트 오류로 실패했다, 우리는이 서버에서 로그 배송을 복원 그래서 비슷한 문제는 더 빨리 볼 수. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 6일 오후 4:00 UTCinvestigating

   어떤 영향 CircleCI 파이프라인 및 워크플로우를 사용하여 UI 데이터 디스플레이, 아웃바운드 알림 및 아웃바운드 웹훅을 포함한 고객. 당신이 기대할 수 있는 것 생성된 파이프라인의 지연 및 워크플로우 및 작업 시작. 작업, 워크플로우 및 파이프라인 데이터는 UI에 나타나는 15 분까지 걸릴 수 있습니다. 아웃바운드 알림 및 웹훅은 최대 1 분까지 지연됩니다. 다음 업데이트 우리는 30 분 안에 또 다른 갱신을 제공할 것입니다 또는 우리가 공유하는 정보 더가 있기 때문에.

2. 2026년 10월 6일 오후 4:10 UTCinvestigating

   이후 15:47 UTC, 고객은 실패한 작업을 볼 수 있습니다, 이전에보고 된 지연 이외에. 우리의 엔지니어는 조사를 계속하고 문제점을 완화합니다.

3. 2026년 10월 6일 오후 4:31 UTCidentified

   16:02 UTC로, 파이프라인은 완전히 실패하므로 새로운 작업 흐름이나 작업이 이 시점에서 실행되지 않습니다. 이것은 지연과 실패한 작업이 더 일찍보고되었습니다. 우리의 엔지니어는 문제점을 mitigating에 일하고, 우리는 우리가 그것을 가지고 있는 빨리 정보를 공유할 것입니다.

4. 2026년 10월 6일 오후 4:42 UTCidentified

   16:39 UTC로, 우리는 새 파이프라인 및 워크플로우에 대한 복구를보고 시작하며, 작업은 다시 실행하기 시작합니다. 우리의 엔지니어는 회복에 일하고 우리가 그것을 가지고 있기 때문에 더 많은 정보를 공유할 것입니다.

5. 2026년 10월 6일 오후 5:21 UTCidentified

   Pipelines, 워크플로우 및 작업이 다시 실행되는 동안, 고객은 워크플로우의 작업과 아웃바운드 알림이 약 1 분으로 지연됩니다. 버전 제어 시스템에 알림 및 상태 업데이트는 다시 시작. 우리의 엔지니어는 가득 차있는 회복을 향해 일하고 있습니다.

6. 2026년 10월 6일 오후 6:04 UTCidentified

   고객은 작업 흐름의 작업과 아웃바운드 알림의 지연과 같은 일반적인 지연을 계속 경험할 수 있습니다. 우리는 우리의 엔지니어가 조사를 계속하고 문제점을 완화하는 동안 당신의 patience를 당신을 감사합니다. 우리는 다음 30 분 이내에 또 다른 업데이트를 공유 할 것입니다, 또는 더 많은 정보를 사용할 수 있다면 더 빨리.

7. 2026년 10월 6일 오후 6:55 UTCidentified

   고객은 작업 흐름 및 작업 시작 전에 평소 지연보다 오래 지속됩니다. 일부 경우 최대 30 분. 이 사건에서 일찍 개선되었지만 지연이 남아 있습니다. 아웃바운드 알림의 지연이 개선되었습니다. 우리는 우리의 엔지니어가 정상적인 일 시작 시간을 회복하는 것을 계속하는 동안 당신의 patience를 당신을 감사합니다. 우리는 다음 30 분 이내에 또 다른 업데이트를 공유 할 것입니다, 또는 더 많은 정보를 사용할 수 있다면 더 빨리.

8. 2026년 10월 6일 오후 7:16 UTCidentified

   고객은 계속 노력합니다. 대부분이 약 20 분 이내에 시작되어 약 40 분 전에 발생합니다. 작업 흐름의 매우 작은 수는 1 시간 이상 대기 할 수 있습니다. 우리의 엔지니어는 개선된 서비스 안정성이 있는 변화가 있고, 나머지 지연은 사건 도중 건설한 일의 backlog로 인해 입니다. backlog는 감소하고, 우리는 그것을 빨리 지우기에 집중됩니다. 더 많은 정보를 계속 공유합니다. 우리는 우리의 엔지니어가 backlog를 통해 일하는 동안 당신의 patience를 당신을 감사합니다. 우리는 다음 30 분 이내에 또 다른 업데이트를 공유 할 것입니다, 또는 더 많은 정보를 사용할 수 있다면 더 빨리.

9. 2026년 10월 6일 오후 7:51 UTCidentified

   작업 흐름과 작업의 지연은 계속 감소합니다. 대부분이 약 10 분 이내에 시작되어 약 40 분 전에 발생합니다. 작업 흐름의 매우 작은 수는 1 시간 이상 대기 할 수 있습니다. 작업이 시작되지 않은 경우, 작업을 다시 실행하십시오. 아웃바운드 알림의 지연이 개선되었습니다. 나머지 지연은 사건 중에 건설 된 작업의 백로로로 인해 백로가 절반 이상 감소했습니다. 우리는 대략 15 분에서 명확하게 된 백로를 기대합니다. 우리는 한 번 또 다른 업데이트를 공유 할 것입니다, 또는 다음 30 분 이내에 최신.

10. 2026년 10월 6일 오후 8:13 UTCidentified

    지연된 작업의 backlog는 명확하고 워크플로우는 알림에서 지연 없이 다시 시작됩니다. 그러나 Docker 및 Linux 작업을 사용하여 고객은 중간, 큰, 2xlarge gen2을 포함하여 여러 리소스 클래스를 통해 작업을 대기 할 수 있습니다. 우리의 엔지니어는 이 문제점을 mitigating에 계속합니다. 작업이 시작되지 않은 경우, 작업을 다시 실행하십시오. 우리는 우리의 엔지니어가 이것을 일하는 동안 당신의 patience를 당신을 감사합니다. 우리는 다음 30 분 이내에 또 다른 업데이트를 공유 할 것입니다, 또는 더 많은 정보를 사용할 수 있다면 더 빨리.

11. 2026년 10월 6일 오후 8:31 UTCmonitoring

    작업 흐름 및 작업은 일반적으로 시작되며 Docker 및 Linux 작업의 대기 시간은 정상으로 반환됩니다. 우리의 엔지니어는 이 문제점을 감시하기 위하여 계속됩니다. 작업이 시작되지 않은 경우, 작업을 다시 실행하십시오. 우리는 우리의 엔지니어가 이것을 일하는 동안 당신의 patience를 당신을 감사합니다. 우리는 다음 30 분 이내에 또 다른 업데이트를 공유 할 것입니다, 또는 더 많은 정보를 사용할 수 있다면 더 빨리.

12. 2026년 10월 6일 오후 9:18 UTCresolved

    약 15:30 UTC 및 20:30 UTC의 10월 6, 2026, 고객은 파이프라인, 워크플로우 및 작업에 영향을 미치는 지연 및 실패를 경험했습니다. 약 16:02 UTC에서 16:39 UTC까지, 파이프라인은 실패하고 새로운 작업 흐름이나 작업을 시작할 수 없습니다. 서비스 이력서, 워크플로우 및 작업은 약 20:00 UTC까지 지연으로 계속됩니다. 피크에서 약 40 분까지 평균 시간을 시작하고, 작업 흐름의 매우 작은 수는 1 시간 이상 기다립니다. 아웃바운드 알림 및 webhooks는 일반적으로 약 19:00 UTC까지 지연되었습니다. 지연된 작업의 backlog로, 우리의 실행 능력에 대한 수요의 결과 증가, Docker 및 Linux 작업에 대한 더 지연을 발생. 약 19:45 UTC에서 20:30 UTC까지, 이 작업은 시작하기 전에 평소보다 더 이상 대기. 20:05 UTC 주변의 피크에서 대기는 2xlarge gen2, 6 분 xlarge gen2에 대한 약 8 분, 몇 가지 다른 리소스 클래스에 대해 5 분 미만에 도달했습니다. 문제는 해결되고, 모든 영향을받는 기능은 정상으로 돌아 왔습니다. 이 창에서 실패한 작업은 영향을 미칠 수 있습니다. 우리는 당신의 인내심을 주셔서 감사합니다. 우리 팀은 수정을 구현하기 위해 일했습니다.

13. 2026년 10월 7일 오후 10:08 UTCpostmortem

    ## 요약 10월 6일, 2026일, 15:30에서 20:30 UTC까지, CircleCI 고객은 파이프라인 및 워크플로우 및 작업 시작 지연을 경험했습니다. 15:48에서 16:38 UTC, 워크플로우 또는 작업이 시작되지 않았으며, 16:02 UTC가 실패했습니다. 단축, 간헐적 지연은 13:30 UTC에서 이전 시작되었습니다. CircleCI UI의 데이터, 알림 및 버전 관리 제공업체의 상태 업데이트도 지연되었습니다. 이 사건은 CircleCI의 모든 파이프라인, 워크플로우 및 작업에 대응하는 워크플로우 오케스트라션 서비스 뒤에 데이터베이스에서 시작되었습니다. 데이터베이스의 가장 큰 테이블에 대한 Routine 유지 보수는 데이터베이스보다 빠른 트랜잭션 로그를 기록 할 수 있으며 로그는 저장 볼륨을 설정 한 다음을 채웠습니다. 읽기 전용으로 데이터베이스를 유지하려면, 우리의 엔지니어는 데이터베이스의 주요 저장 볼륨에 로그를 이동. 이동은 50 분 동안 데이터베이스를 오프라인으로했다. 데이터베이스가 다시 왔을 때, 그것은 우리의 엔지니어가 18:19 UTC에서 데이터베이스 설정을 변경할 때까지 약 절반의 정상적인 속도로 작업을 처리했습니다. 우리는 backlog를 통해 일하고, 작업 시작 시간은 20:30 UTC에 의해 정상으로 돌려. 이 창에서 실패한 작업이 실패한 고객은 그들을 다시 실행할 수 있습니다. 원래 상태 페이지는 찾을 수 있습니다 [here](https://status.circleci.com/incidents/z4hbq8h49j8c). ## 배경 파이프라인을 트리거 할 때, CircleCI는 워크플로우 오케스트라 서비스로 손. 이 서비스는 모든 작업 흐름과 작업의 상태를 추적하고 각 작업이 실행될 준비가 될 때 결정하고 실행 함대에 준비 작업을 전달합니다. 또한 UI와 알림을 볼 수 있는 작업 데이터를 구동하고, 작업을 완료할 때 전송된 상태입니다. 관현악 서비스는 데이터베이스의 상태를 저장합니다. 데이터베이스는 트랜잭션 로그에 모든 변경을 적용하기 전에 작성하고 전용 저장 볼륨에 해당 로그를 유지합니다. 그것은 지속적으로 로그를 보관하므로 그 공간을 재사용 할 수 있습니다. 뒤에 떨어질 경우 볼륨 채우기, 데이터베이스는 쓰기를 받아 들이고, 새로운 일이 앞으로 이동할 수 없습니다. 데이터베이스는 각 테이블에 정기적인 유지 보수 프로세스 \(autovacuums\)을 실행하여 내부 레코드를 즉시 유지합니다. 매우 큰 테이블에,이 과정은 테이블의 모든 페이지를 읽고 큰 볼륨의 트랜잭션 로그를 작성합니다. ## 어떤 Happened \(모든 시간 UTC\) 10:02 년 10 월 6 일, 우리의 모니터링은 관현 서비스의 오류에 대한 짧은 라이브 경고를 제기. 각 경고는 약 15 분 안에 자체에 명확했습니다. 우리의 엔지니어는 이전의 유사한 간략한 경고를 보았고, 체계는 긴장의 다른 표시를 보여주었습니다, 그래서 그들은 runbook를 각 시간, 그리고 각 경고는 그것의 자신의 partway에 맑게 하고 또한 경고를 더 과민하게 하기 위하여 일을 시작했습니다. 약 12:40, 자신의 거래 로그를 생성하는 정기적 인 워크로드와 함께, 데이터베이스의 가장 큰 테이블의 여러 유지 보수 프로세스는 데이터베이스보다 더 빠른 추가 트랜잭션 로그를 작성하기 시작, 그리고 로그 볼륨은 작성 시작. 13:30에서 관현악 서비스는 느리게 시작되었습니다. 15:30을 통해 일부 파이프 라인과 작업이 더 오래 시작되었습니다. 짧은 파열. 13:35, 우리의 모니터링은 다시 경고, 여러 다른 서비스에서 관련 경고와 함께이 시간. Infrastructure Engineers는 alert runbooks를 따르고 경고 중 일부를 정리합니다. 경고는 14:30 주위에 다시 돌아와 더 조사 후, 우리는 14:54에 사건을 선언. 우리는 경고의 조합을 인식해야한다, 그리고 우리는 우리가 아래의 수정 방법을 덮었다. 사건을 선언 한 후, 우리의 엔지니어는 유지 보수 프로세스에 느려지게 추적 \ (anti-wraparound autovacuum\). 데이터베이스가 취소되면이 프로세스를 자동으로 다시 시작합니다. 그래서 우리의 엔지니어는 신속하게 완료하는 데 도움이 설정을 변경했습니다. 15:30까지 지연이 지속되고 일부 작업이 실패하기 시작했습니다. 15:43에서 거래 로그 볼륨이 전체로 닫혔습니다. 채워진 경우 데이터베이스는 쓰기를 중지하고 작동하지 않을 수 있습니다. 우리의 엔지니어는 데이터베이스의 주요 스토리지 볼륨에 대한 트랜잭션 로그를 이동하기로 결정했습니다. 이동은 데이터베이스가 오프라인으로 이동해야하며, 앞으로 몇 가지 일이 소요되는지 예측할 수 없습니다. 이동 시작 15:47. 15:48에서 16:38, 관현악 서비스는 어떤 일을 처리 할 수 없습니다. 고객은 여전히 파이프라인을 트리거 할 수 있지만 워크 플로우 또는 작업이 시작되지 않으며 16 : 02의 새로 방아쇠가 발생했습니다. 우리는 15:58에 우리의 상태 페이지에 게시하고 16:20의 주요 정전에 제기. 데이터베이스가 오프라인이었지만, 우리의 엔지니어는 대체 데이터베이스를 fallback으로 준비했습니다. 원래 데이터베이스는 먼저 다시 와서, 그래서 우리는 서비스에 보관. 에 16:38, 데이터베이스는 다시 온라인 와서 다시 시작. Transaction logs and regular data now sharing the same storage, 데이터베이스는 이전보다 천천히. 16:38에서 18:19, 관현 서비스 처리 작업 약 반 그것의 정상적인 속도, 작업은 가장 긴에서 약 50 분, 시작 하는 분의 10을 기다립니다. 그 시간 동안 데이터베이스는 우리가 전용 볼륨으로 돌아갈 수 있기 전에 트랜잭션 로그를 아카이브 완료했다. 우리는 또한 여러 데이터베이스 매개 변수 변경을 조사하여 더 유지 보수가 시작되고 서비스 도달을 줄이기 위해 준비 된 방법을 중지합니다. 교체 데이터베이스와 함께, 우리는 또한 그 시간 동안 서비스의 전체 스택을 준비 그래서 우리는 데이터 손실의 위험에 이동하고 그 움직임에 대해 선택 할 수 있도록. 18:19, 우리의 엔지니어는 각 쓰기가 저장에 대기 시간을 잘라 데이터베이스 설정을 변경. 처리 속도 복구, 및 backlog는 명확하게 시작. 더 빨리 삭제하려면 데이터베이스와 서버 용량을 시스템에 추가하여 실행 함대에 작업합니다. 에 대해 19:55, 새로운 작업은 다시 시작 시간. 백로그는 우리의 실행 함대에 도달했습니다. 에서 19:49 받는 사람 20:30, 더 큰 자원 클래스에 일부 도커 작업은 약 10 분 동안 용량을 확장하는 동안 시작. 20:30, 작업 시작 시간은 정상으로 돌아 왔습니다. 우리는 20:32에서 감시하는 상태 페이지를 이동하고 21:19에 사건을 해결했습니다. 약 3,500 건의 일자리가 사건 중에 시작되지 않았습니다. 고객은이 작업을 다시 실행할 수 있습니다. 우리는 원시 CI가 한 번 이상 일하는 증거를 발견했습니다. 원래 실행이 지연된 동안 작업 흐름을 다시 한 고객은 모두 실행 완료 될 수 있습니다. 연례 계획 고객은 그들의 계정 팀과 협력하여 사용법을 검토 할 수 있습니다. ## 미래 예방 및 공정 개선 우리는 recurrence를 방지하고 우리의 응답 시간을 개량하기 위하여 뒤에 오는 단계를 가지고 있습니다: **이 사건을 발생시키는 조건에 경고를 추가합니다. ** 우리의 모니터링은 느리게 잡았지만, 우리는 전체 거래 로그 볼륨이 얼마나 충분히 빠졌는지 경고하지 않았다. 우리는 모두에 경고를 추가하고, 데이터베이스 유지 보수에 경고와 함께, 그래서 우리는 이전 행동 할 수 있습니다. 우리는 또한 noisy 또는 민감한 경고를 보장하기 위해 우리의 경고를 수정하고 실제 문제를 숨길 수 없습니다. **우리는 유지 보수 프로세스를 어떻게 조정하고 있습니다 \ (autovacuum \) 우리의 데이터베이스에 실행. ** 우리는 우리의 데이터베이스에서 실행되는 autovacuums를 가진 빈도 그리고 공격성에서 찾고 있습니다. 우리는 또한 시간이 지남에 따라이 테이블의 크기를 추적하고 안전 한도 내에서 머물 수 있습니다. ** 단일 거래 로그 병목을 제거하고 있습니다. ** 관현악 서비스의 모든 것은 현재 하나의 데이터베이스와 하나의 트랜잭션 로그를 통해 이동하고, 그 로그가 뒤에 떨어질 때, 모든 파이프라인, 워크플로우 및 작업이 느립니다. 우리는 두 가지 접근 방식을 평가하고 있습니다. 여러 데이터베이스 인스턴스를 통해 서비스를 분할하고, 각각의 트랜잭션 로그로 이동하여 많은 노드를 통해 쓰기를 확산하기 위해 내장 된 분산 된 데이터베이스로 이동합니다. 어떤 접근법은 작업 부하의 일부에 backlog의 효과를 제한 할 것입니다. **우리는 관현악 서비스를 위해 대기하고 있습니다. ** 사건 도중, 몇몇 일은 우리의 체계가 retrying 후에 포기한 때문에 실패했습니다. 우리는 그 행동을 변화시키기 위해 노력하고 있습니다. ** 긴 사건 중의 상태 페이지 업데이트를 개선하고 있습니다. ** 고객은 우리의 초기 업데이트가 충분한 세부 사항을 제공하지 않았습니다. 우리는 우리의 지도를 새롭게 하기 때문에 갱신은 특정한 충격 및 타이밍 더 빨리 포함합니다. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이이 이 사건을 해결하기 위해 일하면서 그들의 인내에 고객을 감사합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 10월 1일 오전 9:06 UTCinvestigating

   고객은 Docker Gen 2 Jobs를 시작하는 지연을 경험할 수 있습니다. 시스템의 처리량을 증가시키기 위해 노력하고 있습니다.

2. 2026년 10월 1일 오전 9:47 UTCidentified

   우리는 뿌리 원인을 확인하고 우리는 해결에 적극적으로 노력하고 있습니다. 감사합니다.

3. 2026년 10월 1일 오전 10:13 UTCidentified

   수정이 시작되었습니다. 복구를 관찰하기 시작합니다.

4. 2026년 10월 1일 오전 10:24 UTCmonitoring

   우리는 정상적인 수준에 queue 시간 반환을 보고, 감시자를 계속합니다.

5. 2026년 10월 1일 오전 10:45 UTCresolved

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

6. 2026년 10월 9일 오후 10:36 UTCpostmortem

   ## **Summary ** 10월 1일부터 10월 8일까지, 2026년, CircleCI 고객은 5개의 별도의 사건을 경험해 정상적인 시작보다 더 이상 기다리거나 시작하지 못했습니다. 사건의 세는 우리의 클라우드 공급자로부터 제한된 인스턴스 가용성에 의해 구동되었다. 1은 우리의 스케줄링 인프라의 구성 문제로 발생했고, 내부 서비스에 메모리 제한으로 하나씩 발생했습니다. * **10월 1, 07:57 에 10:24 UTC:** Docker Gen 2 작업은 시작 30 분까지 기다립니다. 구성 문제는 고성능 로컬 디스크를 사용하여 Gen 2 스케줄링 서버를 방지했습니다. 트래픽의 파열 중, 가을 디스크 포화 및 작업 배치가 느립니다. * **10월 7, 13:27에서 14:06 UTC:** 기계 작업은 우리가 우리의 클라우드 공급자에서 충분한 가상 기계를 취득할 수 없기 때문에 정상적인 보다는 더 오래 대기했습니다. * **10월 7, 14:24 에 15:21 UTC:** 일부 작업은 인프라 오류로 실패하고 워크플로우가 지연되었습니다. 각 작업을 제공 하는 서비스 시작에서 구성 메모리와 재시작. * **10월 7, 18:49에서 20:05 UTC:** Docker Gen 2 작업은 클라우드 공급자로부터 충분한 인스턴스를 취득할 수 없기 때문에 정상보다 더 오래 기다리게되었습니다. * **10월 8, 12:48에서 16:00 UTC:** Linux 기계 작업 및 원격 도커 작업은 시작 50 분까지 기다립니다. 우리의 클라우드 공급자는 우리가 요청하는 인스턴스 유형의 충분하지 않았다, 그리고 다른 인스턴스 유형을 선택 논리의 결함은 대안을 사용하여 우리를 유지. 이 사건에 기다린 작업은 지연되지 않았습니다. 작업이 10 월 7 사건 중 인프라 오류로 실패 한 고객은 14 : 24에서 15 : 21 UTC가 중단 될 수 있습니다. 원래 상태 페이지는 아래에 찾을 수 있습니다: * [10 월 1 - Gen 2 Docker Jobs 시작 지연] (https://status.circleci.com/incidents/22mrv46g6n7g) * [10 월 7 - 기계 작업 작업 작업 시작 지연](https://status.circleci.com/incidents/tj6wdnfjwr64) * [10 월 7 - 적외선의 수준은 고객 일에 실패] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [10 월 7 - 도커 Gen2에 대한 작업 대기 시간 증가] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [10 월 8 - 기계 작업을위한 상승 대기 시간] (https://status.circleci.com/incidents/jn756xtsy4xg) ## ** 배경 ** CircleCI에서 실행되는 모든 작업은 따릅니다. 그 compute는 executor에 달려 있습니다. Docker 작업은 인스턴스의 함대에 작업을 일정하는 서버 클러스터에서 실행됩니다. Scheduler는 인스턴스가 각 작업을 실행하는 것을 결정하는 그 서버에 소프트웨어입니다. Gen 2 Docker 작업은 10 월 1 사건의 시간에 그런 클러스터에 ran. Gen 1 Docker 작업은 여러 클러스터를 통해 확산됩니다. 원격 도커 작업을 포함한 기계 작업, 전용 가상 기계를 얻을. 원격 도커 작업은 제공을 통해 제출에서 Linux 기계 작업으로 처리됩니다. 우리의 기계 프로비저닝 서비스 요청 우리의 클라우드 제공 업체의 각 기계 중 하나에서 우리는 일반적으로 기계 작업에 사용됩니다. 공급자가 요청한 인스턴스 유형을 공급할 수 없는 경우, 서비스가 다시 떨어질 것입니다: 그것은 다른 인스턴스 유형, 또는 우리가 유지한 리스트에서 다른 지역을 요청합니다. 작업은 기계가 사용할 때까지 기다립니다. 어떤 직업이 시작될 때, 그것은 그것의 윤곽을 위한 일 윤곽 서비스를 요구합니다. 이 서비스는 같은 프로그램의 작은 사본 인 파드 세트로 실행됩니다. 너무 많은 파드가 중지되면 나머지 파드는 더 많은로드를 수행하고, 작업은 서비스 복구까지 시작할 수 없습니다. 이 경로는 3 종류의 용량에 따라 다릅니다. 우리의 스케줄링 시스템의 처리량, 우리의 클라우드 공급자의 인스턴스의 공급 및 작업 시작 서비스의 메모리 및 번호. 그들 중의 부족은 직장 대기 또는 실패합니다. ## **Happened ** \(모든 시간 UTC\) # # # ** 10 월 1 : Docker Gen 2 작업은 30 분까지 지연 ** 07:44, Gen 2 Docker 일자리를 일정하는 서버의 디스크 활동은 용량의 90 %로 상승하고 거기 유지. 에 07:57, 도커 작업의 수는 시작 하기 시작 하기 시작, 및 대기 시간 장미 그것. 자동화된 alert는 08:08의 on-call 엔지니어를 찾습니다. 우리는 08:42에 사건을 선언했다. 08:43에서 엔지니어는 스케줄링 서버에서 높은 디스크 대기 시간을 확인했습니다. 그들은 먼저 디스크가 너무 느리기 때문에 더 빠른 디스크 유형으로 변경을 준비했습니다. 09:01에서 팀은 두 개의 워크스트림에 동의했습니다. 서버가 더 빠른 디스크로 이동하고 두 번째 Gen 2 클러스터를 추가하여 작업이 두 클러스터를 가로 질러 버릴 것입니다. 09:41에서 엔지니어는 뿌리 원인을 발견했습니다. 각 스케줄링 서버는 빠른 디스크가 직접 부착되어 있으며, 스케줄러는 작업 데이터를 유지하는 것이 바람직합니다. 이 서버는 보안 강화 운영 체제 이미지에서 실행되며 빠른 디스크가 사용되지 않았습니다. Scheduler는 대신 느린 네트워크 배치 디스크에 데이터를 썼습니다. 빠른 디스크를 설정하는 스크립트는 오류없이 실패, 이 서버에 로그인의 간격은 실패를 숨깁니다. Gen 2 트래픽은 점점 파열되었습니다. 그 파열 중에 더 느린 디스크 포화, 스케줄러가 뒤에 떨어졌다. 대기 시간 09:54, 에서 작업 할 때 Gen 2 중간 자원 클래스 대기 30 분. 09:55에서 엔지니어는 빠른 디스크를 올바르게 설정하는 수정을 적용했습니다. 10:11에서, 스케줄러는 더 빠른 작업을 시작, 이는 서버가 새로운 작업을 계속할 수 있었다. Gen 2 매체의 대기 시간은 10 : 14에서 13 분, 10 : 17에서 7 분, 10 : 20에서 1 분 30 초. 우리는 10시 24분에서 모니터링하는 상태 페이지를 이동하고 10시 45분에서 사건을 해결했습니다. 11:20에서, 두 번째 Gen 2 클러스터는 작업을 실행 시작. # # # ** 10 월 7, 13 : 27에서 14 : : 기계 작업을위한 상승 대기 시간 ** 우리는 13:27에서 사건을 선언 한 후 높은 큐 팅 및 대기 시간. 우리는 13:31의 상태 페이지에 게시. 13:31, 엔지니어는 우리가 기계 작업을위한 가상 기계를 취득하기 위해 노력하고 있었다, 그리고 시작 작업의 수는 기계 작업에 대한 높은 주로이었다. 13:34, 대기 시간은 executors에 걸쳐 상승했다. 13:48에서, 대기 시간은 더 많은 기계가 사용되기 시작, 우리는 14:06에 사건을 해결. ###**10월 7, 14:24 에 15:21: 작업 실패 및 워크플로우 지연** 이전 사건이 해결 된 후 곧, 우리는 우리의 실행 시스템에 제출 된 작업의 수에 날카로운 하락 때문에 14 : 24의 새로운 사건을 선언했습니다. 14:26에서 엔지니어는 작업 구성 서비스의 파드는 재시작했다. 파드는 요청을 응답하기 위해 서비스의 몇 가지 사본을 떠나고, 반복 된 시도가 인프라 오류로 실패한 후 구성을 검색 할 수 없었던 작업. 이미 실행중인 작업 흐름은 시작되지 않은 작업에서 업데이트를 기다리고 있습니다. 14:35, 엔지니어는 pods에 사용할 수있는 메모리의 양을 증가하고 pods의 수를 증가, 이는 서비스를 더 많은 사본을 공유하기 위해. 우리는 또한 사용할 수있는 메모리의 양을 증가 작업 제출은 복구 시작, 우리의 워크 플로우 시스템을 통해 흐르는 메시지의 수 정상 수준으로 돌아. 14:44, 우리는 모니터링 상태 페이지를 이동. 작업 설정 서비스에서 파드는 메모리 제한 및 재시작에 도달했습니다. 우리는 메모리 할당과 팟 수를 증가, 및 서비스 복구. 15:13, 우리는 Gen 2 Docker 클러스터의 인스턴스 수를 증가 시켰습니다 그래서 우리는 빠른 대기 작업의 백 로그를 통해 작동 할 수 있습니다. 우리는 15:21에 사건을 해결했습니다. ##**10월 7, 18:49 에 20:05: 도커 Gen 2 일자리를 위한 상승 대기 시간** 우리는 Docker Gen 2 대기 시간 장미 후 18:49에서 새로운 사건을 선언했습니다. 18:51, 엔지니어는 가능한 인스턴스의 부족이 대기 시간을 올리는 그들의 충분한 취득에서 우리를 유지 확인. 리소스 클래스 크기에 따라 시간이 다릅니다. 19:52, 평균 대기 시간은 더 많은 용량이 사용되기 때문에, 짧은 스파이크가 계속되고, 우리는 모니터링 상태 페이지를 이동. 우리는 20:05에 사건을 해결했습니다. # # # ** 10 월 8 : Linux 기계 및 원격 도커 작업이 50 분까지 기다립니다 ** 우리는 12:48에 사건을 선언 한 후 기계 및 원격 도커 작업을위한 많은 일자리를보고합니다. 12:49에서 엔지니어는 우리의 클라우드 공급자가 충분한 인스턴스를 공급할 수 없다는 것을 보았습니다. 우리가 조사 한대로 계속되는 지연. 13:13에서, 우리는 우리의 첫번째 선택이 사용할 수 없을 때 다른 인스턴스 유형 또는 지역을 선택할 논리를 시험하기 시작했습니다. 13:24에서, 우리는 그 논리에 결함이 우리의 주요 지역에서 다른 인스턴스 유형 사용에서 우리를 중지했다고 의심, 그래서 우리는 우리의 fallback 지역을 비활성화하고 결함의 원인을 확인. 엔지니어는 수정 작업을 시작하고 14:49에 배포했습니다. 이 서비스는 다른 인스턴스 유형을 요청하고 큰 숫자에서 기계를 시작했습니다. 14:58, 기계에 대 한 기다리는 작업의 큐는 꾸준히 떨어졌다. 리소스 클래스의 평균 대기 시간은 다음 시간 동안 계속됩니다. 우리는 대기 작업의 backlog를 통해 일했습니다. 16:00에, 기계가 명확하고 대기 작업의 수가 정상으로 돌아갑니다. 우리는 16:09에서 모니터링 상태 페이지를 이동하고 16:35에서 사건을 해결. ## **Future 예방 및 공정 개선 ** 우리는 공급 다변화, fallback 논리, 그리고 더 이른 탐지를 포함하여 일 시작 시간의 탄력을 강화하기 위하여 뒤에 오는 단계를 가지고 있습니다. ** 우리는 우리의 compute 지구를 확장하고 있습니다. ** 10월 7일과 10월 8일 사건에서, 우리의 클라우드 공급자는 우리가 사용한 지구에 충분한 예를 공급할 수 없었습니다. 우리는 우리의 선호한 지구를 outpace에 있는 수요를 위한 순서 손잡이 스파이크에 있는 우리의 fallback 논리에 새로운 지구를 추가하고 있습니다. **다른 인스턴스 유형을 선택한 논리를 수정하고 있습니다.** 10월 8일, 결함은 같은 지역에 다른 인스턴스 유형을 사용하여 기계 제공 서비스를 유지. 우리는 사건에 대한 수정을 배포하고 이제이 논리를 전체로 검토하고 다시 작성, 테스트와 함께, 그래서 하나의 인스턴스 유형의 부족은 다른 작업을 이동합니다. ** 우리는 추가 용량을 제공하는 인스턴스 유형을 확장하고 있습니다. ** 우리는 우리의 클라우드 공급자와 협력하여 기존 지역의 추가 용량을 예약하고 작업이 실행될 수있는 인스턴스 유형을 추가하고 있습니다. 고성능 구획을 위한 기업 수요는 성장합니다. 우리는 어디를 다각화하고 우리가 소스 수용량 그래서 우리의 고객은 공급 변이에서 격리됩니다. ** 우리는 두 번째 Gen 2 Docker 클러스터를 추가하므로 트래픽 파열은 두 개의 클러스터에서 배포됩니다. ** 서버 디스크 포화에 대한 경고도 추가하고 스케줄러의 작업이 얼마나 빠른지, 서버가 사용중인 빠른 디스크 없이 시작될 때 화재가 경고합니다. 우리는 디스크 설정 스크립트 오류로 실패했다, 우리는이 서버에서 로그 배송을 복원 그래서 비슷한 문제는 더 빨리 볼 수. 고객 경험은 우리의 최고 우선권이고, 우리는 우리의 고객가 우리에 있는 신뢰와 일치하기 위하여 우리의 체계의 신뢰성을 지속적으로 개량하기 위하여 투입합니다. 우리는 우리의 팀이 이러한 사건을 해결하기 위해 일하면서 그들의 인내심을 위해 우리의 고객을 감사 합니다. 질문이나 우려가 있는 지원팀에 연락해 주십시오.

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

1. 2026년 9월 23일 오후 6:13 UTCidentified

   고객은 새로운 가입 및 계획 변경에 지연을 경험할 수 있습니다.

2. 2026년 9월 23일 오후 8:06 UTCresolved

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

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

1. 2026년 9월 21일 오후 4:22 UTCinvestigating

   고객은 Linux Machine에서 작업 지연을 경험할 수 있습니다. 우리는 투자입니다.

2. 2026년 9월 21일 오후 4:48 UTCmonitoring

   Linux 머신의 작업 대기 시간은 정상으로 돌아갑니다.

3. 2026년 9월 21일 오후 5:09 UTCresolved

   This incident has been resolved.

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

1. 2026년 9월 16일 오후 2:55 UTCinvestigating

   우리는 파이프라인 데이터에 대한 지연을 조사하고 있습니다. 파이프 라인은 여전히 실행되지만 데이터는 UI 또는 API에서 지연 될 수 있습니다.

2. 2026년 9월 16일 오후 3:29 UTCidentified

   우리는 문제점을 확인하고 치료에 일하고 있습니다. 감사합니다.

3. 2026년 9월 16일 오후 5:34 UTCidentified

   Pipeline 데이터는 여전히 지연 될 수있는 테스트 결과의 예외와 함께 정상으로 사용할 수 있습니다. 우리는이 작업을 계속하고, 당신의 인내에 감사드립니다.

4. 2026년 9월 16일 오후 6:22 UTCmonitoring

   모든 파이프라인 자료는 지금 정상으로 유효합니다. 우리는 회복을 계속할 것입니다.

5. 2026년 9월 16일 오후 7:30 UTCresolved

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

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

1. 2026년 9월 15일 오후 2:42 UTCinvestigating

   우리는 현재 UI에서 파이프라인 데이터 서핑에 지연이 있습니다.

2. 2026년 9월 15일 오후 3:14 UTCidentified

   우리는 일부 복구를 볼 시작.

3. 2026년 9월 15일 오후 5:02 UTCresolved

   UI의 파이프라인 데이터에 미치는 영향은 이제 해결되었습니다. 우리는 우리의 엔지니어가 지연을 줄이기 위해 일한 동안 당신의 patience를 당신을 감사합니다.

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

1. 2026년 9월 14일 오전 11:59 UTCinvestigating

   증가된 네트워크 오류 및 latencies로 인해 macOS 작업의 대기 시간이 증가합니다. macOS 호스팅 제공업체와 함께 투자하고 있습니다.

2. 2026년 9월 14일 오후 12:36 UTCinvestigating

   MacOS 작업의 시간을 단축하고 조사를 계속합니다.

3. 2026년 9월 14일 오후 12:48 UTCmonitoring

   우리의 macOS 호스팅 제공 업체는 완화를 구현했으며 우리는 latencies를 개선했습니다. 우리는 감시자를 계속할 것입니다.

4. 2026년 9월 14일 오후 12:59 UTCresolved

   MacOS 작업의 시간은 정상으로 돌아갑니다.

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

1. 2026년 9월 10일 오후 8:25 UTCidentified

   고객의 작은 수는 오류를 볼 수 있거나 고전적인 파이프 라인보기를 사용할 때 deprecated-config 경고와 프로젝트 용 파이프라인 페이지를로드 할 수 없습니다. 새로운 파이프라인 전망에 고객은 영향을 미치지 않습니다. 우리는 원인을 확인하고 수정을 배포했습니다.

2. 2026년 9월 10일 오후 8:25 UTCmonitoring

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

3. 2026년 9월 10일 오후 8:26 UTCresolved

   이 사건은 해결되었습니다. 18:53 UTC와 19:24 UTC 사이에 파이프라인을 생성 한 작은 수의 고객 deprecated config syntax를 사용하여 구성을 포함 하 여 그들의 빌드 유형 작업을 시작 실패. 업무 또는 파이프라인이 실패한 고객은 그들을 다시 실행할 수 있습니다.

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

1. 2026년 9월 4일 오후 3:16 UTCinvestigating

   우리는 Mac 인프라에 영향을 미치는 네트워크 문제를 감지했습니다. 우리는 투자하고 곧 업데이트를 제공 할 것입니다. 고객은 이 시간에 queuing 경험할지도 모릅니다.

2. 2026년 9월 4일 오후 3:43 UTCidentified

   우리는 Mac 인프라 제공 업체와 네트워킹 문제를 식별하고, 문제를 해결하기 위해 노력합니다. 우리는 일부 복구를보고 시작하지만, 우리는 고객이 여전히 일부 쿼리를 볼 수 있다고 기대합니다. 우리는 곧 새롭게 할 것입니다.

3. 2026년 9월 4일 오후 4:19 UTCmonitoring

   우리의 Mac 인프라 제공 업체는이 네트워킹 문제에 대한 수정을 적용하고 우리는 정상에 큐 타임 반환을보고있다. 우리는 더 긴 동안 약간의 일을 계속하는 것입니다. 우리는 곧 새롭게 할 것입니다.

4. 2026년 9월 4일 오후 4:55 UTCresolved

   우리는 더 이상 queue 시간에 충격을 보았고 모든 것이 정상으로 돌아 왔습니다. 우리는 이 문제를 해결하고 감시하는 동안 당신의 patience를 평가합니다.

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

1. 2026년 8월 26일 오후 3:43 UTCidentified

   고객은 플랜 사용 UI 또는 플랜 사용 API를 호출 할 때 간헐적인 오류를 경험할 수 있습니다. 우리는 문제를 확인하고 우리는이 오류를 완화하기 위해 적극적으로 노력하고 있습니다.

2. 2026년 8월 26일 오후 4:04 UTCmonitoring

   우리는 계획 사용 API 및 UI의 관련 페이지가 올바르게 로드되어 문제가 발생합니다.

3. 2026년 8월 26일 오후 4:10 UTCresolved

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

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

1. 2026년 8월 25일 오후 11:20 UTCresolved

   사이 19:49 UTC 과 21:07 UTC 에 8월 25, 2026, 고객에 로그인하려고 서클CI 를 사용하여 GitHub에 로그인 할 수 없습니다, 의 오류를 수신 GitHub에서 콜백 URL이 유효했다. 이미 로그인 한 고객은 영향을받지 않았습니다. 문제는 해결되고 GitHub 로그인은 일반적으로 작용합니다. 우리는 당신의 인내심을 주셔서 감사합니다. 우리 팀은 수정을 구현하기 위해 일했습니다.

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

1. 2026년 8월 17일 오후 9:06 UTCidentified

   문제의 원인은 확인되었습니다. 우리는 작업이 수정되었습니다.

2. 2026년 8월 17일 오후 9:36 UTCmonitoring

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

3. 2026년 8월 17일 오후 9:37 UTCresolved

   Insights 데이터는 한 번 더 좋습니다. 감사합니다.

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