46 Sirv incidents · 2014년 11월 — official updates, affected components, duration and resolution details.
일부 Sirv 계정으로 업로드하면 서버 문제로 인해 실패합니다. 이것은 때때로 표시에서 이미지를 방지 할 수 있습니다. 가능한 한 빨리 문제를 해결하기 위해 노력하고 있습니다.
문제의 원인은 이제 완전히 해결되었습니다. 기간 동안 Sirv 계정의 약 25 %는 파일 업로드 실패의 비율을 경험할 수 있습니다. 나중에 짧은 업로드는 작은 요청에 영향을 미치는 것이기 때문에 성공할 수 있습니다. 리뷰는 현재 진행 중이며, 추가 정보는 나중에 제공됩니다.
공식 인시던트 업데이트를 자동 번역했습니다.
작은 수의 업로드 및 요청은 Sirv의 기본 데이터 센터의 여러 네트워크 스위치 실패로 인해 오류를 반환합니다. CDN 요청은 정상으로 작동합니다. 우리는 상황을 감시하고 더 많은 정보로 업데이트를 제공할 것입니다.
모든 서비스는 정상 및 요청에 다시 완료됩니다.
이 문제는 Sirv의 기본 데이터 센터에 영향을 미치는 핵심 라우터 오류에 의해 발생했습니다. 이는 파일 저장 및 업로드에 대한 간헐적 인 정전, 모든 전송 유형 : API, S3 및 FTP. Sirv는 자동적으로 그것의 실패 서비스로 전환했습니다, 그래서 가공하고 납품은 정상으로 계속했습니다. CDN 요청은 정상으로 계속됩니다. 모든 서비스는 일단 datacentre가 핵심 라우터 아웃리지를 해결 한 번 복원되었습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
독일의 일부 요청에 대한 응답 시간은 정상보다 느리며 작은 수는 타이밍됩니다. 문제는 조사됩니다.
문제는 해결되었습니다. 독일의 서버 중 하나가 과부하되었고 평소보다 느리게 반응했습니다. 서버는 이제 다시 건강합니다. 우리는이 일이 다시 일어나는 기회를 줄일 수있는 작업을 검토하고 있습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
캘리포니아의 일부 요청은 느리고 작은 번호 (2 % 미만)은 실패합니다. 오늘 로스 앤젤레스에서 배포 된 새로운 CDN 서버와 관련이 있습니다.
문제는 해결되었습니다. 문제는 새로운 로스 앤젤레스 데이터 센터에 영향을 미치는 패킷 손실에 의해 발생했습니다. Datacenter는 네트워크 불안정성을 경험한 Arelion의 업스트림 공급자에게 문제를 추적했습니다. Arelion이 일시적으로 상류 공급자로 비활성화되었을 때 문제가 해결되었습니다. 트래픽은 다른 공급자를 통해 다시 시작되었습니다. 데이터 센터는 데이터 센터를 식별하고 다시 루트 트래픽을 자동으로 식별하고 이러한 시나리오에서 신속하게 식별해야합니다. 그러나이 문제의 해결은 충분히 빠르지 않았고이 새로운 데이터 센터를 채택 한 후 곧 발생했습니다. 우리는 그것을 사용하여 중단하기로 결정했습니다. 모든 트래픽은 이제 우리 고유의 로스 앤젤레스 데이터 센터 (As of 7 April 2025)에서 노선되고 있습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
일부 파일 업로드는 서버 클러스터 문제로 인해 완료되지 않습니다. 원인은 조사됩니다. 문제는 계정의 작은 숫자에 영향을 미칩니다. 파일 업로드가 실패하면, 이 문제가 해결 될 때까지 기다립니다.
이 문제는 진행 중입니다. 문제의 원인은 확인되었으며 가능한 한 빨리 해결하기 위해 노력하고 있습니다.
문제는 해결되었습니다. 문제는 한 클러스터에 두 개의 서버가 동시에 실패했습니다. 이것은 Sirv 계정의 약 20 %에 새 파일의 업로드에 영향을 미쳤습니다. 업로드는 한 서버가 다운되면 정상으로 계속 설계되었지만 두 서버가 다운되면 일부 업로드가 실패 할 수 있습니다. 그들은 한 서버에서 실행 중지 된 수출 서비스로 인해 실패, 그 다음 다른 서버. 오류는 재시작에서 서비스를 방지했습니다. 그런 다음 두 번째 문제는 서버가 재부팅 할 수 없기 때문에 예상보다 훨씬 더 오래 걸릴 것입니다. 이것은 outdated BIOS 때문에. BIOS가 업데이트 된 후에는 서버가 재부팅되어 소멸 문제의 원인이 해결되었습니다. 이 작업을 다시 방지하려면 데이터 센터와 새로운 BIOS 관리 프로세스를 구현했습니다. 우리는 또한 우리의 하드웨어 새로 고침 주기를 단축하고, 더 빈번한 기계설비 향상을 위해. Recurring에서 수출 서비스 실패의 가능성을 줄이기 위해, 우리는 프로세스를 비활성화하고 서버 미터를 모니터링하고 있습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
09:29 및 09:32 UTC 사이 3 분 동안 일부 요청이 반환되지 않았습니다. 이 문제는 특정 요청과 특정 계정 만 영향을받습니다. 대부분의 계정은 비공개되었습니다.
문제는 3 분 안에 해결되었습니다. 원인은 동시에 여러 서버의 재부팅, 1 서버만 재부팅해야 한다. 이것은 우리의 표준 운영 절차에 있는 oversight이었습니다. 우리는 자동적으로 보호하고 recurring에서 이것을 방지하는 방법을 조사하고 있습니다.
공식 인시던트 업데이트를 자동 번역했습니다.
서버 오류는 제한된 계정의 수에 실패하는 일부 파일 업로드를 발생시킵니다. 문제는 해결됩니다. 실패한 경우, 일시 중지하고 나중에 시도하십시오.
문제는 해결되었습니다. 서버의 거의 많은 수가 동시에 실패했습니다. Sirv는 서버 정전 도중 정상적인 가동을 계속하기 위하여 디자인되고 모든 체계는 정상으로, 그러나 몇몇 파일 업로드 실패했습니다. 우리는 가능한 변화가 미래에 이러한 상황에서 도움이 될 수 있는지 고려하고있다.
공식 인시던트 업데이트를 자동 번역했습니다.
504 타임아웃의 높은 수는 API 파일 업로드 요청에 대해 반환됩니다.
업로드 요청에서 API에 무거운 부하가 계속 있습니다. contributing 인자는 처리하기 위하여 평소보다 길게 가지고 가는 많은 AI 이미지 확장 요구에 입니다. 요청의 큐에 의한 지연은 504 응답으로 실패하는 일부 API 파일 업로드 요청을 유발합니다.
변경은 거의 해결되었습니다. 업로드 요청의 대다수가 성공합니다.
API 업로드 하중은 거의 완전히 해결됩니다.
문제는 완전히 해결되었습니다. 이 문제는 대용량 이미지 확장 API 요청이 업로드 API를로드하면 API 요청이 504 오류를 반환합니다. 이것은 해결되었지만, API 요청의 약 5 %가 502 응답으로 실패했습니다. 이 문제를 다시 일어나서 방지하기 위해 개선은 이미지 확장 및 더 나은 부하를 줄이기 위해 만들어졌습니다. 변화는 또한 로깅 및 경고, 같은 시나리오의 빠른 식별. 이 문제의 가장 큰 영향은 Sirv WordPress 플러그인에있었습니다. 플러그인은 응답이 수신 될 때까지로드에서 페이지를 차단 모든 관리자 페이지에 API 요청을 전송했다 - 일반적으로 미만 300ms 그러나 최대 20 초 API 요청이 중단되면. 이러한 API 요청이 요구되지 않았으므로 새로운 WordPress 플러그인 버전 v7.3.3이 1805 UTC (14 11 월)에 릴리스되어 이러한 요청을 제거하고 반복에서이 문제를 방지합니다. https://wordpress.org/plugins/sirv/ ------ Sirv API를 사용하면 스크립트가 502 응답을 수신하는 리트리 요청으로 작성된다는 것을 권장합니다. 502 및 기타 오류 응답 처리에 대한 권고는 여기에 제공됩니다. https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide
공식 인시던트 업데이트를 자동 번역했습니다.
몇몇 파일은 계정의 작은 수에 반환되지 않습니다. 이 문제는 긴급하게 해결됩니다.
문제는 해결되었습니다. 1052 UTC에서 작은 계정 (12 계정, 50,000 +에서)의 요청에 대한 약 11%는 200 응답 (OK)을 반환해야 할 때 404 응답 (파일이 발견되지 않음)을 반환했습니다. Sirv 팀은 문제를 확인했을 때, 그들은 신속하게 그것을 해결하고 1206 UTC에 의해 이러한 요청은 정상 200 응답을 반환했다. 이 문제는 Sirv 엔지니어가 새 저장 클러스터 shard를 구성 한 동안의 구성으로 인해 발생했습니다. 일부 요청은 새로운 shard로 이동하여 수신 할 준비가되었습니다. severity 수준 3로 분류하는: Minor 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
Sirv의 25 CDN 위치에 대한 높은 요청은 오류를 반환합니다. 우리의 엔지니어는 문제를 확인하고 해결하기 위해 신속하게 일하고 있습니다.
문제는 해결되었습니다. 여러 서버에 동시에 소프트웨어 daemon의 실패에 의해 발생했습니다. 과거에 실패하지 않은 경량적이고 효율적인 서비스 관리자입니다. 기간 동안, 3%와 58% 사이에 HTTPS 요청은 오류를 반환, 이는에 따라 25 CDN 위치 요청을 받았다. 우리는이 일어난 이유를 조사하고 미래의 서비스 가용성에 영향을 미치는 행동을 방지하기 위해 조치를 취할 것입니다. severity Level 2로 분류됩니다.
공식 인시던트 업데이트를 자동 번역했습니다.
415 오류의 높은 수준은 CDN에 발생합니다. 우리의 엔지니어는 원인을 조사하고 있습니다.
이 문제의 원인을 조사하기 위해 계속됩니다. 그것은 단지의 본질. 그것은 0 바이트의 파일에서 415 오류로 자신을 나타냅니다. 또한 500 오류의 낮은 비율이 높다. 대부분의 요청은 200 응답을 성공합니다. 우리의 엔지니어는 이것을 이해하고 해결하기 위해 열심히 일하고 있습니다.
415 오류 문제는 일부 파일에 의해 발생, 그들은 그들의 내용의 일부를 잃는 의미. 이 파일은 0 바이트를 가지고있는 my.sirv.com에서 제어판에서 보여줍니다. 오늘 업로드 된 파일이 더 truncated 가능성이 더 큽니다. truncation이 오랜 시간 동안 파일로 일한 것처럼 보입니다. 이것은 일반적으로 수행하기 때문에 식별되지 않았기 때문에 비강화 된 버전의 캐싱. truncated file issue는 오늘, 인프라 업그레이드 후만 알려지지 않았습니다. 서버 캐시가 명확하고 truncated 버전이 분명했다. truncation의 원인은 이제 해결 된 소프트웨어 버그였습니다. 우리는 현재 truncated 파일을 복원하기 위해 노력하고 있습니다 - 시간이 지남에 따라 걸릴 수있는 프로세스. 현재 로딩되지 않은 모든 파일을 다시로드 할 수 있다면 지금 당장하십시오. 문제는 파일의 ~0.2 %에 영향을 미칠 것으로 추정됩니다.
Truncated 파일의 약 80 %가 복구되었습니다. 415 오류의 수는 크게 떨어졌지만, 그들은 상승했습니다. 문제를 완전히 해결하려면, 나머지 truncated 파일은 원래 파일로 대체해야합니다. 우리는 나머지 파일을 복구하는 방법에 대해 일하고 있습니다, 그들은 열심히 얻을 수 있지만, 그것은 시간이 걸릴 수 있습니다 또는 일. 가장 빠른 가능한 해상도의 경우 파일을 다시로드하는 것이 좋습니다. 그런 파일은 계정에서 0 바이트를 가지고 표시됩니다. 다음 URL에서 시작, 마지막 30 일에서 업로드 모든 파일 목록을 볼 수: https://my.sirv.com/#/search/?created=30d Size, Ascending의 결과를 분류하여 0 바이트 파일을 찾습니다. 또 다른 업데이트는 여기에 게시됩니다. 우리는 나머지 파일에 뉴스가 있습니다.
우리는 남아있는 truncated 파일의 작은 수를 복구하는 것을 계속하고 있습니다. 이 12-24 시간 이상 요구 될 것으로 추정됩니다. 제공되지 않은 모든 파일이있는 경우, 당신은이 곧 다시로드하여 해결할 수 있습니다. 0 바이트 파일의 목록을 생성하는 도구입니다. 계정의 0 바이트 파일 목록과 같은 경우 https://sirv.com/help/support/#support에서 요청을 제출하고 도구가 준비되면 목록을 준비합니다. 에 관계없이, 우리는 모든 파일을 복구하는 작업을 계속합니다. Sirv의 Autofetch 기능을 사용하여 파일을 업로드하면 Zero byte 파일을 간단하게 삭제할 수 있으며 다음 요청에 따라 원격 위치에서 다시 검색 할 수 있습니다.
더 많은 파일이 복원되었습니다. 415 오류의 비율은 계속 하락합니다. 계정의이 페이지에서 415 오류 목록을 볼 수 있습니다. https://my.sirv.com/#/analytics/errors/415?from=20231206&to=20231206 파일에서 415 오류를 해결하려면 파일을 업로드 할 수 있습니다. 필요한 경우 0 바이트 파일의 목록을 제공 할 수 있습니다 -이 양식을 통해 Sirv 지원 팀을 요청하십시오. https://sirv.com/help/support/#support 우리는 가능한 한 많은 파일로 복원하고 있습니다.
415 오류의 상승률이 해결 된 문제. truncated 파일은 0 바이트로 일부 파일을 썼는 소프트웨어 문제로 발생했습니다. 소프트웨어로, 이것은 마스터 파일의 모든 버전에서 복제 할 수있는 truncated 파일이 발생했습니다. Sirv는 하드웨어 문제 (서버 또는 하드 드라이브 실패)에 대해 보호 할 수있는 모든 파일을 triplicates, 그러나 업데이트 된 파일은 모든 검사를 통과하고 조심스럽게 파일을 여행. 파일의 캐시된 버전이 처리 및 납품에 사용되었기 때문에 탐지 없이 존재했습니다. 모든 시스템은 파일이 삭제되었을 때 어제의 인프라 업그레이드까지 완벽하게 작동했습니다. 루트 원인은 truncation 발생 소프트웨어 문제점을 식별하고 수정하여 해결되었습니다. 12월 5일에 1500 UTC에 의해 완료되었습니다. 그런 다음 작업은 truncated 된 그 파일을 복원 할 수 있었다. 플랫폼 건너, 약 0.2 %의 파일이 영향을 받았다. 그 파일 중, 우리는 계정에 따라 95 %와 100 % 사이에 복원 할 수있었습니다. 100 % 미만의 복원이있는 모든 계정은 다시 파일을 업로드함으로써 복원해야하는 0 바이트 파일의 목록을 보내집니다. 파일 목록으로 이메일을 보내 주십시오. 도움이 필요한 경우 다음 URL을 통해 메시지를 보내주십시오. https://sirv.com/help/support/#support 문제의 철저한 조사는 이메일에 의해 세부 사항으로보고됩니다. 보고서 내에서 이미 설계 된 개선 및 새로운 기능과 함께이 문제의 가능한 반복을 방지하기 위해 수행되는 작업 목록이 될 것입니다. 우리는이 문제에 의해 영향을받은 모든 고객에게 사과합니다. 첫 번째 마스터 데이터가 손실되었습니다. 우리는 그것을 통해 모든 가능한 수업을 배우고 전보다 강력하고 신뢰할 수 있습니다.
나머지 truncated 파일의 99 % 이상이 복원되었습니다. 어떤 영향 받은 사용자는 영향을 받은 파일의 정확한 목록으로 제공됩니다. 이 문제에서 남아있는 잔여 충격이 없습니다. severity Level 1: 긴요한 충격으로 분류됨.
공식 인시던트 업데이트를 자동 번역했습니다.
0419 UTC에서 시드니 CDN 위치에서 429 오류가 상승했습니다.
문제는 1031 UTC에서 해결되었습니다. 원인은 시드니 CDN 위치가 같은 IP 주소에서 오는 모든 요청을 볼 수있는 서버 구성이었다, 진정한 클라이언트 IP 주소 대신. 이 트리거 된 DDOS 보호, 같은 IP에서 요청의 과도한 수를 제한. 429 응답은 많은 요청에 대해 반환되었습니다. 이 문제는 시드니 datacentre 네트워크가 사용할 수 없을 때 매우 짧은 문제였습니다. 그 문제는 약 1 분 만 지속됩니다. 그러나, 실제 사건은 우리 팀이 시드니 CDN 위치를 복원 한 후 즉시 시작되었습니다. 서버 구성이 적용될 때입니다. 문제가 해결되었습니다 일단 우리가 misconfiguration을 발견하고 수정했습니다. 다중 작업은 반복에서이 문제를 방지하고 미래의 유사한 문제의 영향을 줄이기 위해 촬영됩니다 : - 추가 모니터링 및 경고 - 새 문제 제출 양식 - Context에 민감한 해결책 통보 - Wider 내부 경고 시드니 CDN 위치 만 영향을 받았다. severity 수준 3로 분류하는: Minor 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
약 1830 UTC 에 22 11 월, 우리는 새로운, 더 강력한 클러스터에 기본 파일 데이터베이스에 업그레이드를 시작했다. 업그레이드가 일어났지만, API 검색 쿼리가 실패했습니다.
11월 23일에 1035 UTC에서 업그레이드가 완료되었으며, 정상 작동을 재개했습니다. API 검색 요청이 오류 응답을 반환하지 않는 경우, 해당 API 검색 요청을 제외하고, 해당 시스템의 다운타임과 모든 시스템이 작동하지 않았습니다. 이 문제는 다른 API 요청이 정상으로 반환되었기 때문에 확인되지 않았으므로 총 API 오류 응답은 약간 높고 경고가 유발되지 않았습니다. 이 문제는 사용자가 조사를 초래 한 후 이벤트가 확인되었습니다. 자동적으로 미래에 이러한 문제를 식별하기 위해 검색 API를 특별히 모니터링하는 방법을 평가하고 있습니다. 우리는 또한 Sirv WordPress 플러그인을 업데이트하여 실패한 검색의 경우 명확하게 구독 된 메시지를 표시합니다. severity 수준 4로 분류하는: 최소 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
My.sirv.com의 파일 관리 도구는 실패 서버로 인해 천천히로드됩니다. 파일 목록 및 파일 검색은 일반적으로 1 ~ 4 초 정도 걸리는 2 ~ 20 초입니다. 실패한 서버는 대체되고 우리는 72 시간 안에 정상에 돌려보내는 속도를 예상합니다. 다음 3 개월 동안 전체 제어 패널 서버 클러스터의 주요 업그레이드에 의해 수행됩니다.
클러스터에 추가하기 위해 새로운 서버의 제공을 기다리고 있습니다. UI 탐색 속도가 훨씬 빠릅니다.
새로운 서버는 11 월 14 일 저녁에 배포되었으며 점차 캐시를 채웠습니다. 컨트롤 패널은 원래의 빠른 성능으로 돌아 왔습니다. 추가 서버는 이제 업그레이드되어 있으므로 컨트롤 패널이 앞으로 2 주 동안 빠르게로드됩니다. severity 수준 4로 분류하는: 최소 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
워싱턴 D.C. CDN 위치에 대한 요청의 극적 인 증가는 10 월 14 : 10 UTC에서 발생했으며, 2 초 미만의 요청의 작은 비율을 감안했습니다. 이 문제는 평균 응답 시간이 상승하더라도 다음 3 시간 이상으로 변합니다. 문제는 10 월 24에서 다음 날을 반환 : 32 UTC, 요청의 17%가 천천히로드하기 전에보다 심각하게 - 2 초보다 큰 30 초. 이 문제는 Sirv의 25 CDN 위치의 두에 영향을 미쳤습니다.
문제는 10 월 25 일 UTC 06:48에 의해 해결되었습니다. 두 가지 원인에 대한 조사 포인트 - 스파이크는 Sirv의 DNS 공급자로 인해 로스 앤젤레스 POP는 대신 워싱턴 D.C. POP에 요청. 이것은 고립에서 벌금이 되었지만 datacentre는 느린 응답을 일으키는 수신 서버의 대역폭을 훔치는 것으로 나타납니다. 조사는 진행 중이며, 정의 결론에 도달하지 않고 DNS 및 datacentre 제공 업체와 협력해야합니다. 이 문제의 가능한 반복을 방지하기 위해 이미 수행됩니다. 더 자세한 보고서는 나중에 제공됩니다.
이 문제에 대한 상세한 조사는 두 개의 기여 요인을 발견했습니다. 첫 번째는 AWS Route53에 업데이트되었으며, 이는 10월 17일 AWS에서 구현되었습니다. 이 변경은 Sirv가 Route53 규칙에 의해 만들어지지 않았지만 Route53 서비스 자체 내에서 변경되었습니다. 로스 앤젤레스 POP는 다른 POP에 약간 다른 여정 논리를 가지고 있었고 AWS 업데이트는 워싱턴 DC 가을에 통과 된 트래픽과 다르게 행동하기 위해 라우팅을 발생했습니다. 이 더 높은 부하로 unnoticed 갔다 아직도 그것의 수용량 및 요구가 성공적으로 반환되었다, 그래서 이것은 워싱턴 DC로 unnoticed 추가 부하를 처리 할 수 있었다. 두 번째 기여 요인은 23 및 24 10 월 피크 미국 거래 시간 동안 정상 교통보다 높았습니다. 결합 된 두 가지 요소는 워싱턴 DC 하드 디스크가 정상보다 훨씬 느리게 요청을 반환합니다. 문제가 발생했기 때문에 반복을 방지하기 위해 여러 조치를 취했습니다. 비슷한 사건에 대해 mitigate에; 그리고 사건에서 해결 시간을 가속화합니다. Actions include: - 새로운 라우팅 논리가 적용되었습니다. - 워싱턴 DC 용량이 증가했습니다. - 다른 모든 CDN 위치에서 용량이 증가했습니다. - routing에서 제거 할 CDN 위치에 도입 된 새로운 공차. - 추가 디스크 모니터링, 용량 업그레이드의 초기 준비를 돕기 위해. - HDD는 SSD로 대체됩니다. - SOP for our support team to 조사 및 유사한 문제 해결. severity 수준 3로 분류하는: Minor 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
API 업로드 실패의 작은 숫자와 함께, 높은 업로드 사용의 초기 문제.
문제는 정상화 된 9 분 이내에 자체를 해결했습니다. 기간 동안, 대략 98%의 업로드 성공과 2% 실패. REST API 업로드는 시브 계정의 사용 페이지에서 지정된 금액에 시간 당 제한됩니다 https://my.sirv.com/#/account/usage. 업로드 이미지에 대한 REST API를 사용하는 경우, 최고의 전술은 각 업로드 요청에 대한 응답을 확인하고 오류 응답을받을 경우 (400, 401, 429 등) 다음 일시 정지 업로드 및 다시 시도합니다. 여기에 문서를 참조하십시오 : https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide severity 수준 4로 분류하는: 최소 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
REST API 업로드 요청의 작은 수는 매우 높은 부하로 인해 실패합니다.
이 문제는 업로드 API에서 로드 한 번 해결했습니다. 기간 중 약 97%의 업로드가 성공했고 3%가 실패했습니다. REST API 업로드는 시브 계정의 사용 페이지에서 지정된 금액에 시간 당 제한됩니다 https://my.sirv.com/#/account/usage. 업로드 이미지에 대한 REST API를 사용하는 경우, 최고의 전술은 각 업로드 요청에 대한 응답을 확인하고 오류 응답을받을 경우 (400, 401, 429 등) 다음 일시 정지 업로드 및 다시 시도합니다. 여기에 문서를 참조하십시오 : https://sirv.com/help/articles/sirv-rest-api/#error-handling-guide severity 수준 4로 분류하는: 최소 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
로스 앤젤레스 CDN 서버 중 하나는 건강하고 0000 UTC에서 4xx 오류를 반환하기 시작했습니다. 그것은 90 초 후에 여정에서 제거되고 더 60 초 안에, 모든 교통은 건강한 서버에 경로를 갖게 되었습니다.
문제는 3 분 안에 자동으로 해결되었습니다. severity 수준 4로 분류하는: 최소 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
Sirv CDN의 London POP에 대한 일부 요청은 높은 부하로 인해 오류를 반환합니다. 이 POP는 영국과 아일랜드를 제공합니다. 우리는 해결책에 일하고 있습니다.
문제는 해결되고 현재 모니터링됩니다.
일부 요청은 런던 CDN 서버 중 하나가 로컬 DNS 해상도와 네트워크 타임 아웃의 조합으로 인해 실패했습니다. 문제는 1215 UTC에서 시작되었으며 1332 UTC에서 해결되었습니다. 이 기간 동안, 영국과 아일랜드의 요청의 25 %는 404 또는 500 오류를 반환합니다. 문제는 빨리 해결되었지만 관련 SSL 인증서 유효성 검사 실패는 몇 시간 전에 차단 된 경고를 모니터링 시스템에 의해 받았습니다. 변경은 이미 반복에서이 문제를 방지하기 위해 배포되었습니다. SSL 인증서 문제는 해결되었습니다. 독립적 인 모니터링의 두 번째 수준은 구성되었습니다. 추가 건강 자동화는 이러한 문제를 자동으로 해결하기 위해 잠재적 인 것으로 평가됩니다. severity 수준 3로 분류하는: Minor 충격.
공식 인시던트 업데이트를 자동 번역했습니다.
문제는 0755 UTC에서 해결되었습니다. 0625 UTC에서 인도를 제공하는 Indore CDN POP에 대한 일부 요청은 200 응답 대신 404 응답 (파일이 발견되지 않음)을 반환하기 시작했습니다. 문제는 전 세계 모든 CDN 서버에 업데이트 후 14 시간 발생했습니다. 모든 POP는 인도 POP를 포함하여 건강하게 행동했지만 Indore POP는 성공적으로 업데이트되지 않았으며 결국 오류를 반환하기 시작했습니다. 문제가 확인되면, 인도 POP에 업데이트를 다시 배포하여 해결되었습니다. 사건 중 94%의 요청이 오류를 반환했습니다. 다른 모든 국가에 요청은 정상으로 반환되었습니다. 이 문제를 방지하기 위해, 새로운 자동화 된 배포 규칙은 인간의 검사만 한 배포 프로세스의 일부에 대 한 만들어집니다. 추가 alerting metric도 생성되고, 배포가 실패한 상황에서 상황을 식별합니다. 우리는이 사건에 영향을 미치는 모든 고객에게 사과하고, 우리는 문제의 가능한 반복을 방지하는 데 도움이 될 수있는 다른 변경을 평가하고 있습니다. CDN 문제가 발생하면 통제 내의 즉각적인 솔루션은 여기서 Sirv 설정에서 CDN을 일시적으로 비활성화하는 것입니다. https://my.sirv.com/#/account/settings/domains severity Level 2로 분류됩니다.
공식 인시던트 업데이트를 자동 번역했습니다.
