Unico 장애 기록

1. 2026년 8월 30일 AM 2:35 UTCinvestigating

   고객 여러분, 금요일 오후 11시 (BRT), 8월 29, 2026, 우리는 IDCloud에서 프로세스 생성에 영향을 미치는 불안정성을 확인했습니다. 이 기간 동안, 일부 요청은 일반 응답 시간보다 느리거나 경험할 수 있습니다. 우리는이 불편함을 인식하고 이해를 평가 할 수 있습니다. 새로운 업데이트는 곧 제공됩니다. Unico 팀

2. 2026년 8월 30일 AM 2:49 UTCidentified

   엔지니어링 팀은 IDCloud에서 프로세스 생성에 영향을 미치는 불안정성의 근원을 맵핑했습니다. 기술 팀은 이미 영향을받는 층의 스케일링 리소스를 포함하여 정확한 조치를 적용하고 지속적인 모니터링 키 지표를 가지고 있습니다. 서비스는 최고 우선 순위 및 전체 엔지니어링 동기로 처리됩니다. 더 많은 업데이트가 곧 발송될 것입니다. Unico 팀

3. 2026년 8월 30일 AM 2:57 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 IDCloud의 프로세스 생성에 영향을 미치는 불안정한 작업을 수행했습니다. 환경은 안정성으로 돌아 왔습니다. 가용성 및 응답 시간 지표가 11:48 PM (BRT)으로 정상 작동 수준으로 복원되었습니다. 서비스는 정상적인 사용을 위해 유효합니다. 이 시간에, 우리의 기술 팀은 원조한 감시의 밑에 남아 있고, 환경에 일관된 성과를 지키고 어떤 변동든지의 경우에는 즉각 행동하기 위하여 지킵니다. 더 많은 업데이트가 곧 발송될 것입니다. Unico 팀

4. 2026년 8월 30일 AM 3:15 UTCresolved

   고객 여러분, 경영진 및 영향 오후 11시와 오후 11시 48분 사이 (BRT) 8월 29, 2026일, IDCloud에서 영향을 받는 프로세스 생성. 이 창 도중, 이 교류를 사용하는 몇몇 고객은 입증, 문서 붙잡음 및 통보 납품을 포함하여 의존하는 여행에 전파와 더불어 실패 및 증가한 응답 시간을 경험했습니다. 처리 된 정보의 무결성 또는 보안에 대한 타협이 없으며 데이터가 손실되지 않았습니다. 지시자는 11:48 PM (BRT)에 정상적인 운영 수준에, 우리의 감시에서 둘 다 확인하고 고객 측, 덮는 과정 창조 및 완료를 확인한 상태에서 돌려보냅니다. 뿌리 원인 및 해결 이 기원은 우리의 데이터 층에서 확인되었다: 내부 유지 보수 routine가 붙어, 응용 작업은 사용 가능한 연결 제한이 배출 될 때까지 누락 시작, 처리 용량 감소. 우리의 엔지니어링 팀은 수술적으로 갇힌 일상을 종결, 즉시 큐를 해제. 연결 및 처리 용량은 완전히 복원되었으며 데이터 변경이 없습니다. 약속과 다음 단계 우리의 엔지니어링 팀은 세 개의 프론트에 초점을 맞출 것입니다 : 내부 유지 보수 루틴의 대기 시간을 제한하고 동일한 구조에 대한 실행에서 동시 루틴을 방지하고 데이터 층의 변동에 대한 서비스 탄력을 강화하십시오. 완전한 타임라인과 마감일을 포함한 상세한 postmortem는 곧 공유될 것입니다. 우리는 진심으로 당신의 작업에 미치는 영향을 사과하고 우리의 지원 채널을 통해 사용할 수 있습니다. Unico 팀

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

1. 2026년 8월 10일 PM 8:26 UTCidentified

   고객, 우리는 Behavior Alert (IDTrust) 기능 및 1 : N 흐름에 영향을 미치는 일부 IDCloud 요청에 미치는 영향을 감지했습니다. 이 instability는 또한 이 기능을 이용하는 멕시코에 있는 고객에 영향을 미칠지도 모릅니다. 엔지니어링 팀은 가능한 한 빨리 문제를 해결하기 위해 동기 부여됩니다. 우리는 곧 새로운 업데이트를 제공 할 것입니다.

2. 2026년 8월 10일 PM 8:29 UTCmonitoring

   우리의 엔지니어링 팀은 영향을받는 IDCloud 플로우 기능의 불안정성을 해결하기 위해 필요한 작업을 식별하고 구현했습니다. 이때 기술팀은 데이터 레이어의 상세한 분석을 수행하고 환경을 모니터링하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

3. 2026년 8월 10일 PM 9:01 UTCresolved

   경영진 및 영향 약 5:08 오후, 자동화 된 경고는 얼굴 인식 서비스 (1:N 흐름)의 가용성 드롭을 감지, 사건을 트리거. 문제는 신속하고 행동 경고 서비스에 영향을 미치기 시작하고, 그 후, 프로세스 생성 흐름, 이러한 서비스 사이에 일시 중단으로 인해. 영향은 이러한 기능을 사용하여 클라이언트의 하위 집합에 영향을 미쳤습니다. 상황은 정상적인 수준으로 돌아가는 미터와 더불어 5:22 PM에 안정된 것으로 보고되었습니다. 뿌리 원인 및 해결 루트 원인은 내부 워크로드에 의해 생성 된 트래픽 스파이크, 이는 정상적인 클라이언트 트래픽에 의해 사용되는 가장자리 층을 우회하여 생체 인식 요청의 높은 볼륨을 전송. 이 추가 볼륨은 얼굴 인식 서비스를 지원하는 데이터베이스의 용량을 포화. saturation는 그 서비스에서 timeouts를 발생, 바이오 메트릭 엔진 오케스트라 서비스로 변신, 그리고 마지막으로 이러한 기능을 사용하여 프로세스 생성 흐름에. 문제를 해결하기 위해, 팀은 스파이크에 책임있는 워크로드를 중단하고 영향을받는 데이터베이스의 용량을 증가. 이 작업은 문제를 mitigated, 오류 볼륨은 가까운 zero 수준에 반환. 약속과 다음 단계 후속 항목은 내부 작업 부하의 유형에 제한 비율을 구현하기 위해 열렸다. 스파이크 발생, 반복에 대한 예방 측정으로. 영향을받는 데이터베이스의 용량 증가는 이미 사건 자체에서 수행되었습니다.

4. 2026년 8월 25일 PM 1:05 UTCpostmortem

   ** 일정 ** 8 월 10, 2026, 사이 5:08 PM 및 5:27 PM \ (브라질 시간 \), 1 : N 얼굴 인식 흐름에 대한 가용성 지표는 95 % 이하로 떨어졌다, 약 19 분의 총 영향. 이 사건은 생체 인식 엔진에 의해 사용되는 벡터 검색 데이터베이스의 포화에 의해 발생, queue 소비 메커니즘의 예기치 않은 행동에서 발생, 이는 구성보다 2.36 배 더 높은 호출 볼륨을 생성. 과잉로드는 데이터베이스의 최대 스케일링 제한에 도달하여 여러 의존 서비스에서 캐스케이드 타임 아웃을 발생시키고 기간 동안 오류가있는 55 클라이언트 사용자에게 영향을 미칩니다. ** 중요 ** 얼굴 인식, 인증 및 프로세스 생성의 사용자는 기간 동안 여러 클라이언트 경험 오류 및 timeouts에서 흐름. 바이오미터 관현, 엔진, 프로세스 제작 서비스를 통해 데이터베이스 포화. Mitigation은 내부 서비스를 비활성화하여 데이터베이스의 최대 스케일링 제한을 늘리고, 오후 5시 27분에 서비스를 안정화시켰습니다. ** 루트 원인 ** 루트 원인은 서비스 행동과 관련된 요인의 조합이었다 인프라의 용량. 이 서비스는 두 번째 당 2 요청의 제한으로 구성되었지만, 큐 소비 메커니즘은 예기치 않게 행동했습니다. 처리는 acknowledgment 마감 기한을 초과하는 메시지는 원래 실행을 취소하지 않고 큐에 의해 재배되었습니다. 938 작업 항목 2,217 효과적인 통화 \ (~8.4 RPS \). 이 증폭 된 트래픽은 가장자리 보호 층을 통과하지 않고 데이터베이스에 도달하여 일반적으로 요청 볼륨을 제한합니다. 이 흐름에 사용되는 네트워크 경로는 그 제어를 통해 이동하지 않았습니다. 데이터베이스, 이미 최대 스케일링 제한에 가까운 작동, 추가 부하를 흡수 할 수 없었다 - 그것의 CPU는 80 %에 도달하면서 100 노드의 구성 된 천장까지 흩어져 - 및 쿼리 대기 시간은 ~3 초 ~ 18.75 초 p90, 독립 서비스의 전체 체인에 걸쳐 시간 아웃을 전파. ** 해결책 ** 팀은 몇 분 이내에로드의 소스로 질문을 확인했습니다. 프로세스가 비활성화되었으며 데이터베이스의 최대 스케일링 제한이 100에서 150 노드로 증가했습니다. 이 두 가지 행동으로, 서비스는 오후 5시 27분에 안정화되었습니다. **Lessons 학습 ** 이 사건은 소비자가 redelivery를 통해 볼륨을 증폭 할 수 있을 때 메시지 출판 측에서만 적용된 비율을 보여주었습니다. 비율과 concurrency 통제는 소비 측 뿐 아니라 존재할 필요가 있습니다. 또한, 내장된 보안을 우회하는 경로를 통해 중요한 구성 요소를 액세스하는 내부 서비스는 구조적 위험을 나타냅니다. 어떤 내부 클라이언트는 공유 인프라에서 제어되지 않은 부하를 생성 할 수 있습니다.

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

1. 2026년 7월 31일 PM 12:42 UTCinvestigating

   Prezados 클라이언트, Identificamos uma instabilidade técnica pontual que afeta a atualização do painel de acompanhamento após o envio de documentos. Reforçamos que o fluxo de envio e assinatura está funcionando normalmente : os destinatários continuam recebendo e conseguindo assinar os arquivos. no entanto, o 레지소 do envio pode temporariamente não ser exibido na lista de acompanhamento 할 remetente. Nossa equipe de engenharia já está atuando para corrigir e restabelecer o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos informados sobre o progresso. Atenciosamente, 그리스,

2. 2026년 7월 31일 PM 1:08 UTCidentified

   Prezados 클라이언트, Gostaríamos de atualizar o 상태 sobre 시각적 ização de documentos no painel de acompanhamento. O problema foi identificado com sucesso por nossa는 técnica를 갖추고 있습니다. no momento, os engenheiros já estão subindos correção para restabelecer a exibição correta de todos os envios na 인터페이스는 remetente. Lembramos que o processamento, envio e assinatura dos documentos continuam operando normalmente. Volataremos com uma nova atualização assim que a correção 용 concluída e entrarmos na fase de monitoramento. Atenciosamente, 그리스,

3. 2026년 7월 31일 PM 1:20 UTCmonitoring

   Prezados 클라이언트, Informamos que a correção para a exibição no painel de acompanhamento foi aplicada com sucesso. a lista de documentos e históricos de envios já está retornando à 정상화. no 순간, nossa equipe de engenharia está monitorando o ambiente de perto para garantir a estabilidade 총 serviço. Agradecemos a paciência e traremos a Confirmação do encerramento em breve. Atenciosamente, 그리스,

4. 2026년 7월 31일 PM 2:06 UTCresolved

   Prezados 클라이언트, Informamos que o 사건 relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após aplicação da correção e o período de monitoramento, checkamos que a listagem e o histórico de documentos foram totalmente restabelecidos, e plataforma 오페라 em Completea estabilidade. Agradecemos pela compreensão 전자 paciência de todos durante o processo. Atenciosamente, 그리스,

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

1. 2026년 7월 29일 PM 2:04 UTCresolved

   경영진 및 영향 ID Cloud Webhook 알림 서비스는 해결되었습니다. 충격 기간: 08:32에서 10:05. Platform Impact: Instability는 Webhook 알림 전달에 엄격히 제한되어 있으며 메시지 배포 지연으로 인한. 주요 플랫폼의 degradation이 아니고, 생동감 엔진의 고장이 없으며 데이터 손실이 없습니다. 고객 영향: 문제점은 고객의 작은 부분을 영향을 미쳤습니다. Getting polling flow as a contingency (fallback)는 가동적인 충격을 경험했습니다. 뿌리 원인 & 해결책 뿌리 원인: 불안정성은 환경에 있는 특징 갱신에 의해 방아쇠를 당했습니다. 작업 큐와 목적지 경로 사이의 액세스 권한에 임시 mismatch는 알림의 임시 백로를 선도하는 데 거부되는 요청을 발생. Resolutive 활동: 기술 팀은 새로운 환경에 대한 트래픽 리디렉션을 완료, 구성 요소 간의 적절한 통신을 복원하고 Webhooks의 백 로그를 해제. 가공은 정상에 돌려주고, 파견 큐는 완전히 명확했습니다. 약속 & 다음 단계 우리의 서비스의 안정성은 우리의 최우선권입니다. 총 투명도를 보장하고 재발을 방지하기 위해, 우리의 기술설계 팀은 뒤에 오는 정면에 집중할 것입니다: 상세한 Postmortem : 심층적 인 뿌리 원인 분석과 예방 조치 계획을 갖춘 포괄적 인 보고서가 준비됩니다. 관측성 개선: 우리는 전환 시나리오에서 상호 서비스 통신 오류로 더 큰 가시성을 보장하기 위해 지표를 모니터링합니다. 우리는 진심으로 불편을 끼쳐 드려서 더 명확하게 사용할 수 있습니다. Unico 팀

2. 2026년 8월 7일 PM 1:08 UTCpostmortem

   ** 일정 ** 7 월 29, 2026, 8 : 32 AM 및 10 : 05 AM \ (브라질 시간 \) 사이에 웹 후크 배달 서비스는 약 1 시간 및 33 분 동안 분해되었습니다. 웹훅 서비스는 새 클러스터에서 인증 토큰을 생성하기 시작했으나, 여전히 오래된 클러스터로 전달되었지만, 이는 저자의 오류로 토큰을 거부했다. 분실된 사건은 수요에 재처리되었습니다. ** 중요 ** 다중 제품은 동시에 영향을 미쳤습니다. 인증, 지불 및 온보딩 흐름. 웹훅 알림에 독점적으로 의존하는 클라이언트의 사용자는 기간 동안 자신의 비즈니스 흐름 경험있는 운영 중단을 계속합니다. 낙하 메커니즘으로 활성 오염을 구현 한 클라이언트는 영향을 줄였습니다. ** 루트 원인 ** 루트 원인은 마이그레이션 계획에서 확인되었다: 절차는 webhook 흐름의 chained 의존도를 맵하지 않았다 — 내부 경로가 비동기 작업을 생성, 차례로, 배송을위한 공공 경로 호출. 내부 경로와 별도의 단계의 공공 경로에 마이그레이션함으로써, 호환성 창은 새로운 클러스터에 의해 생성 된 토큰이 이전 서비스 계정 식별자에 특히 검증 된 오래된 클러스터의 허가 정책에 의해 거부되었는지를 창조했다. 이 시나리오는 변화의 위험 평가 중 확인되지 않았으며, 기존의 서비스 품질 지표는 실패가 재료화 된 비동기 배달 층을 덮었습니다. ** 해결책 ** 팀은 실패의 소스로 토큰 호환성을 확인하고 새로운 클러스터에 공공 경로의 마이그레이션을 완료, 의향을 제거. 그 시점에서, queue의 보류 배달은 일반적으로 처리 시작. 영향은 오전 10시 5분에서 중단되며, 이전 클러스터의 트래픽은 오전 10시 32분에서 0에 도달했습니다. **Lessons 학습 ** 이 사건은 Chained 비동시적 인 배달 흐름을 포함하는 마이그레이션이 클러스터 사이의 호환성 창없이 조정 된 방식으로 마이그레이션하기 위해 체인에 참여하는 모든 경로가 필요합니다. 가장 마이그레이션에 적합하면서 점차적인 접근 방식은 원자 전환 또는 훨씬 짧은 전환 창으로 피할 수 있는 오류 기간을 만들었습니다. 또한 비동기 납기 층의 관측 가능성의 부족은 사건이 내부적으로 검출되지 않은 이유였습니다. 기존 지표는 실제 배달이 아닌 이벤트 수용 만 측정했습니다. 이 층의 실패 및 backlog에 대한 전용 경고 생성은 가장 긴급한 모니터링 개선 확인.

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

1. 2026년 7월 24일 PM 9:47 UTCinvestigating

   고객 여러분, 우리는 현재 데이터 배달의 지연에 영향을 미치는 우리의 Webhooks의 불안정성을 조사하고 있습니다. 엔지니어링 팀은 신속하게 문제를 해결하기 위해 적극적으로 노력하고 있습니다. 우리는 곧 더 많은 업데이트를 제공 할 것입니다.

2. 2026년 7월 24일 PM 9:53 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 데이터 배달 지연에 영향을 미치는 Webhook 불안정성을 해결하기 위해 필요한 작업을 식별하고 구현했습니다. 이때 기술팀은 데이터 레이어의 상세한 분석을 수행하고 환경을 모니터링하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

3. 2026년 7월 24일 PM 10:18 UTCresolved

   경영진 및 영향 시작 6:05 PM (Brasília time), 불안정은 웹훅 서비스에서 발생, 이 기간 동안 영향을받는 작업에 대한 이벤트 처리 및 알림 전달에 실패를 선도. 뿌리 원인 및 해결 이 사건은 여러 서비스에서 사용되는 공유 서비스 계정으로 문제가 발생했습니다. 인증 실패로 인한. 뿌리 원인을 식별하면 엔지니어링 팀은 필요한 자격 증명과 구성을 복원했습니다. 정상 작동은 오후 6시 29분(BRT)에 완전히 재구성되었습니다. 약속과 다음 단계 지속적인 개선과 위험 완화의 일환으로 엔지니어링 팀은 서비스 전반에 걸쳐 리소스 의존성 및 액세스 관리를 검토 할 것입니다. 미래의 인프라 조정에 유사한 구성 문제를 방지합니다.

4. 2026년 8월 3일 PM 8:00 UTCpostmortem

   ** 일정 ** 7 월 24, 2026, 사이 6:05 오후 및 6:29 오후 \ (브라질 시간 \), 웹 후크 생성 및 배달 서비스는 약 24 분 동안 사용할 수 없습니다. 이 사건은 이전의 클러스터 마이그레이션에 연결된 리소스 거부 프로세스 중 인프라 서비스 계정에 액세스하는 손실에 의해 발생했습니다. 영향을받는 계정은 문서화되지 않고 여러 서비스에 의해 공유되었으며 웹훅 서비스가 인증 기능을 잃고 이벤트를 전달합니다. ** 중요 ** Webhook 이벤트 생성 및 배송은 기간 동안 중단되었으며, 1,550 이상의 오류가 기록 된 18 개 이상의 클라이언트 사용자에게 영향을 미쳤습니다. 동일한 인증 흐름에 따라 다른 서비스에 영향을 미치는 영향은 다른 플랫폼 기능에 걸쳐 동시 분해를 유발합니다. ** 루트 원인 ** 루트 원인은 서비스 의존성 구성에서 확인되었습니다. 이 크로스 서비스 의존도는 문서화되지 않았거나 의존성 맵핑에 표시되지 않았습니다. 퇴직 프로세스가 원래의 서비스 리소스 정리의 일부로 계정을 제거 할 때, 다른 활성 서비스에 의해 여전히 사용되었는지 확인하는 자동화 된 검증이 없었다. 이 safeguard의 부재는 제거가 폭 넓은 인증 실패를 초래할 때까지 숨겨지은 신뢰성을 유지합니다. ** 해결책 ** 팀은 인증 실패의 원천으로 불안정한 서비스 계정을 신속하게 식별했습니다. 계정을 수동으로 조정하고 클러스터에 적용, 6 : 29 PM에서 서비스를 복원. 총 충격 기간은 약 24 분이었습니다. **Lessons 학습 ** 이 사건은 서비스의 숨겨지은 의존성을 창출하는 유산 구성의 위험을 노출 : 계획 된 유지 보수 중 단일 리소스 변경은 동시에 여러 서비스를 중단하는 것이 충분했습니다. 인프라 리소스는 모든 변경 전에 자동화된 의존성 검증을 포함합니다.

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

1. 2026년 7월 21일 PM 4:39 UTCidentified

   고객, Web Journey (이전 ByUnico)에 영향을 미치는 프로세스 여정에서 인증 흐름에 영향을 미치는 IDCloud 기능의 불안정성을 조사하고 있습니다. 엔지니어링 팀은 가능한 한 빨리 문제를 해결하기 위해 동기 부여됩니다. 우리는 곧 더 많은 업데이트를 제공 할 것입니다.

2. 2026년 7월 21일 PM 4:49 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 영향을받는 IDCloud 플로우 기능의 불안정성을 해결하기 위해 필요한 작업을 식별하고 구현했습니다. 이때 기술팀은 데이터 레이어의 상세한 분석을 수행하고 환경을 모니터링하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

3. 2026년 7월 21일 PM 6:02 UTCresolved

   경영진 및 영향 7월 21, 2026일 오후 12:44 (브라질 시간)에 약 12:44에서 시작, 흐름에 초기 화면의 느린 로딩 경험의 감소 된 여정에서 사용자의 부분. 이 여행이 사용되는 모든 환경에서의 영향은 인식 속도에 영향을 미치며, 더 적은 범위로, 이 기간 동안 프로세스를 완료하는 사용자의 능력. 뿌리 원인 및 해결 조사는 사건의 definitive 뿌리 원인을 확인하기 위해 진행됩니다. 서버, 네트워크 또는 인프라에 대한 영향이 없습니다. 문제는 사용자의 장치에서 온 스크린 경험에 격리 된 문제입니다. 포함 측정으로, 책임있는 팀은 1:39 PM (BRT)에 예방 조정을 적용하고, 몇 분 안에 정상으로 돌려보냅니다. 검증 및 확인하는 분석은 여전히 기술 팀에 의해 수행됩니다. 약속과 다음 단계 사건 응답 과정의 지속적인 개선의 일환으로, 팀은 책임있는 팀을 위한 자동적인 에스컬레이션 교류를 강화하기 위하여 투입하고, 활성화를 순간에서 더 직접적이고 효과적이기 때문에 사건이 열립니다. 또한, 로딩 속도 모니터링은 이 여행에 새로운 변화의 롤아웃 동안 강화되며, 잠재적 인 회귀를 식별하고 정확하고, 유사한 상황에서 사용자에게 영향을 최소화합니다.

4. 2026년 8월 3일 PM 2:01 UTCpostmortem

   ** 일정 ** 7 월 21, 2026, 사이 12:44 오후와 1:43 PM \(브라질 시간 \), 감소 된 여행에 대한 페이지로드 성능 지표는 심각하게, ~4.8s ~ 8.9s에서 평균로드 시간 점프와 P95 도달 31.5 초. 이 사건은 공급자로부터 시작된 연결에 클라우드 인프라에 의해 적용된 비율로 인해 로드에서 프론트엔드 자산을 방지했습니다. ** 중요 ** 32명의 클라이언트에게서 사용자는 대략 94의 여행 과실이 기록된 상태에서 극단적으로 느린 페이지 짐 또는 완전한 선적 실패를 경험했습니다. "Initialization Timeout" 오류 - 응용 프로그램이 30 초 이내에 마운트 할 때 트리거 - 기간 동안 약 23 천 발생에 도달. ** 루트 원인 ** 루트 원인은 인프라의 네트워크 계층에 식별되었다: CDN 공급자는 아웃바운드 IP 주소의 제한된 세트를 통해 트래픽을 통합. 새로운 TCP 연결 및 TLS Handhakes의 스파이크는 이러한 IPs에서 시작된 클라우드 인프라의 자동 네트워크 레이어 방어 메커니즘을 트리거했습니다. 이는 HTTP 처리 전에도 속도 제한 연결을 시작했습니다. 이러한 실패가 네트워크 층에서 발생하기 때문에 - HTTP 처리 전에 - 그들은 표준 요청 로그에 나타나지 않았다, 기존의 모니터링과 크게 비교 진단에 보이지 않는 문제를. ** 해결책 ** 클라우드 인프라에 적용된 비율 제한의 자연 회복에 대한 영향. 구성 요소의 deactivation, 처음 가능한 원인으로 떨어졌다, 회복과 함께 태운 temporally하지만 나중에 사건과 관련이 없다는 것을 확인했다. 구성 수정 - 확장 된 타임 아웃으로 HTTP Keep-Alive를 활성화하고 가장자리 보호 층에서 CDN IP에 대한 규칙을 추가 - 관련 공급자의 지원 팀에 의해 후속 항목으로 식별되었다. **Lessons 학습 ** 이 사건은 CDN과 클라우드 인프라 사이의 네트워크 층에서 실패가 표준 애플리케이션 모니터링에 보이지 않는 것을 강조하여 중요한 블라인드 스팟을 만듭니다. 후속 항목으로, 팀은 공급자에 의해 추천된 구성 수정을 구현하고 자산 전달 층에서 적합성을 확장하기 위해이 유형의 분해를 감지해야합니다.

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

1. 2026년 7월 21일 PM 2:39 UTCidentified

   고객, 우리는 프로세스 생성 및 프로세스 세부 흐름에 영향을 미치는 우리의 IDCloud 기능에 대한 불안정성을 조사하고 있습니다. 엔지니어링 팀은 가능한 한 빨리 문제를 해결하기 위해 동기 부여됩니다. 더 많은 업데이트를 제공합니다.

2. 2026년 7월 21일 PM 2:46 UTCidentified

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

3. 2026년 7월 21일 PM 2:50 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 영향을받는 IDCloud 플로우 기능의 불안정성을 해결하기 위해 필요한 작업을 식별하고 구현했습니다. 이때 기술팀은 데이터 레이어의 상세한 분석을 수행하고 환경을 모니터링하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

4. 2026년 7월 21일 PM 4:00 UTCresolved

   경영진 및 영향 7 월 21, 2026, 약 11 : 17 AM BRT에서 사용 가능한 드롭은 IDCloud 생성 프로세스 및 프로세스 query 유량에서 감지되었습니다. 충격 창 도중, 고객의 부분은 의존하는 서비스의 사슬을 통해 전파되는 이 가동에 있는 상승 지연 및 실패 (시간)를 경험했습니다. 효과적인 영향은 약 23 분의 창에 집중되었습니다. 피크, 오류 및 대기 상태 지표는 정상 작동 수준 이상이었습니다. 뿌리 원인 및 해결 조사는 읽힌 데이터베이스 (replica)의 degradation에 해당 기능을 기원으로 지원합니다. 이 데이터베이스는 증가된 부하 및 쿼리 실행 시간을 보여주기 시작, 내부 콘텐츠 처리 및 백업 읽기 요청. 그 결과로, 그것의 위 서비스는 timeouts를 축적하고 보호 기계장치 (회로 차단기)를 방아쇠로 묶는 효력을 고객에 의해 경험해 일으키기 시작했습니다. 약속과 다음 단계 Unico는 상세한 postmortem로이 사건을 처리하고 이미 초안되고, 예방 조치를 통합하기 위해 Post-incident review (PiR) 회의를 개최합니다. 응답 중에 이미 제기 된 후속 조치 중에는 진단 루틴 및 쿼리의 준비는이 데이터베이스 레이어의 콘텐츠 식별을 가속화하고 데이터베이스에 대한 관찰성을 개선합니다. 상세한 예방 조치는 postmortem에서 공유됩니다. 우리는 플랫폼의 안정성과 신뢰성에 대한 우리의 약속을 reaffirm하고 instability의 기간 동안 발생하는 불편에 대해 사과합니다. Unico 팀.

5. 2026년 7월 28일 PM 12:10 UTCpostmortem

   ** 일정 ** 7 월 21, 2026, 11 : 41 및 11 : 43 AM \ (Brasília time\) 사이에, 프로세스 생성 흐름은 사용할 수 없습니다, 주요 서비스 오류율은 42% 및 15.75 초에 p99 대기 시간. 이 사건은 생물 측정 데이터베이스에 포화에 기인했습니다 복제를 읽었습니다: 데이타베이스 메모리 풀은 가장 자주 접근한 dataset를 봉사할 수 없었습니다, 디스크 읽기로 돌아가기 위하여 일반적으로 빠른 쿼리를 일으키는 원인이 되고, 축적된 세션의 각자 강화 나선을 창조하고 대기시간을 증가시키. ** 중요 ** 프로세스 생성, 인증 및 결제의 사용자는 여러 클라이언트에서 오류 및 타임아웃을 받았습니다. 주요 데이터베이스는 사건을 통해 intact에 남아있다. 실패는 읽기 복제에 격리되었다. ** 루트 원인 ** 루트 원인은 포화이었다 : 인증 흐름에 사용되는 쿼리는 누락 된 인덱스로 인해 중요한 테이블에 광범위한 검사를 수행했다. 정상적인 조건에서, 이 행동은 데이터베이스 인프라에 의해 허용되었다. 메모리 용량이 한계에 도달하면 더 이상 캐시에서 가장 액세스 된 데이터를 유지 할 수 없습니다. 각 읽기는 디스크에서 데이터를 태칭하여 각 쿼리의 비용을 크게 높일 수 있습니다. 이 abrupt 붕괴 효과 - gradual degradation는 광범위한 실패로 방법을 제공합니다 - 응답 및 내부 데이터베이스 리소스 콘텐츠에 대한 축적 된 대기 세션으로 자기 강화되었습니다. 또한, 중요한 흐름에 대한 모든 읽기 트래픽은 배포 또는 대체 경로가없는 단일 복제에 집중되었습니다. 이 유형의 degradation. ** 해결책 ** 데이터베이스는 축적 된 세션으로 자연스럽게 회복되어 수동 개입이 필요없습니다. 데이터베이스 팀에 escalated 및 모니터링 서비스 안정화. 사건은 정상적인 가동이 복원된 확인 후에 닫혔습니다. **Lessons 학습 ** 이 사건은 데이터베이스 층의 구조적 격차를 공개했다 : 대체 경로없이 단일 복제에 대한 모든 읽기 트래픽의 중요한 쿼리 및 농도에 누락 된 인덱스. 후속으로, 팀은 누락된 색인을 만들고, 복제를 통해 읽힌 트래픽을 배포하고, 비슷한 성격의 미래 사건에 대한 응답을 가속화하기 위해 진단 런 책을 구축.

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

1. 2026년 7월 20일 PM 12:33 UTCidentified

   고객 여러분, 우리는 GetSelfie, 프로세스 생성에 영향을 미치는 우리의 IDCloud 기능의 일부에 대한 불안정성을 확인하고 웹 여행 (이전 ByUnico)에 대한 세부 흐름을 처리했습니다. API Journey (ByClient)는 영향을받지 않았습니다. 엔지니어링 팀은 가능한 한 빨리 문제를 해결하기 위해 동기 부여됩니다. 우리는 더 많은 업데이트와 함께 곧 따를 것입니다.

2. 2026년 7월 20일 PM 12:35 UTCidentified

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

3. 2026년 7월 20일 PM 12:39 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 영향을받는 IDCloud 플로우 기능의 불안정성을 해결하기 위해 필요한 작업을 식별하고 구현했습니다. 이때 기술팀은 데이터 레이어의 상세한 분석을 수행하고 환경을 모니터링하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

4. 2026년 7월 20일 PM 1:22 UTCresolved

   경영진 및 영향 우리는 프로세스 캡처 및 시각화 흐름에 영향을 미치는 불안정성을 확인, 뿐만 아니라 인증, 웹 여행에 대한, 사이 충격 09:07 그리고 09:21 (BRT). 영향은이 흐름을 사용하여 클라이언트의 일부에 도달; API 여행 영향을받지 않았다. 뿌리 원인 및 해결 루트 원인은 생산에 적용되는 구성 변경에 연결되며 내부 데이터베이스 구성 요소에 부하가 증가합니다. 이 증가된 부하 상승 지연 및 통합 층의 오류, 이는 보호 메커니즘을 트리거하고 일시적으로 웹 여행 흐름을 중단. 엔지니어링 팀은 문제를 완화하기 위해 구성 변경을 압연하고, 상황을 정상화 한 후. 약속과 다음 단계 엔지니어링 팀은 지속적으로 변화의 롤백을 따라 환경을 모니터링합니다. 상세한 postmortem는 다가오는 일에 있는 우리의 팀에 의해 공유될 것입니다. 우리는 불편을 끼쳐 드려요. 유니코 팀!

5. 2026년 8월 4일 PM 2:14 UTCpostmortem

   **Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

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

1. 2026년 7월 16일 PM 2:02 UTCinvestigating

   고객 여러분, 우리는 Unico People Portals에 대한 인증 시스템에 대한 통찰력을 조사하고 IDCloud 고객에 영향을 미치는 우리의 메시징 서비스에서 문제를 평가하고 있습니다. 엔지니어링 팀은 가능한 한 빨리 문제를 해결하기 위해 동기 부여됩니다. 우리는 곧 업데이트를 제공 할 것입니다.

2. 2026년 7월 16일 PM 2:08 UTCmonitoring

   고객 여러분, 우리의 팀은 문제를 확인하고 사건을 해결하기 위해 조치를 취했습니다. 우리는 Unico People Portals에 대한 인증 시스템의 불안정성뿐만 아니라 SMS 및 이메일 배송에 대한 IDCloud 플로우에 영향을 미치는 우리의 메시징 서비스 문제에 대해 경험이 있습니다. 우리의 기술설계 팀은 mobilized, 그것을 지키는 환경을 감시하는 것은 제대로 작용하는 것을 계속합니다.

3. 2026년 7월 16일 PM 3:28 UTCresolved

   경영진 및 영향 에 10:51 에 07/16/2026, 문제는 Unico 사람들 입장 포털 및 메시징에 인증 서비스에서 확인되었다, 이는 SMS의 전달에 영향을 미치는 및 Unico 사람들 및 IDCloud 클라이언트에 이메일 링크, 그리고 Unico 사람들 입장 포털에 B2C 클라이언트 인증. 충격은 이 2개의 교류에 제한되고 제품의 핵심 긴요한 여행에 영향을 미치지 않았습니다. 사건은 풀 해상도까지 약 30 분 지속됩니다. 뿌리 원인 및 해결 루트 원인은 메시징 클러스터의 한 노드에 저장 압력으로 식별되었습니다. 중요한 디스크 임계 값에 도달하면 메시지 전달 및 인증에 책임있는 큐의 처리가 향상됩니다. 엔지니어링 팀은 약 10:59 AM에서 클러스터의 저장 용량을 증가 시켰습니다. 즉, 몇 분 안에 정상적인 지표를 모니터링 할 수 있습니다. 환경은 가득 차있는 회복이 확인될 때까지 감시되고, 사건은 오전 11:20에 닫혔습니다. 약속과 다음 단계 엔지니어링팀은 이 유형의 탈선에 대한 경고 에스컬레이션 및 우선 순위를 검토합니다. 경고가 제대로 문제점을 확인했지만 책임있는 팀에 자동 에스컬레이션 흐름이 개선 될 수 있습니다. 상세한 postmortem은 준비되고 오는 날에 공유됩니다.

4. 2026년 8월 3일 PM 12:14 UTCpostmortem

   ** 일정 ** 7월 16일, 2026일, 오전 10시 12분과 오전 11시 10분부터 오전 11시 10분까지, 메시징 및 인증 서비스는 약 58분 동안 평가되었습니다. 원인은 메시지 큐 클러스터의 노드 중 하나에 디스크 포화, 즉, 구성 제한에 도달하면, 모든 게시자를 차단, 큐에 최대 33 천 메시지의 백 로그를 발생. 충격은 SMS 및 이메일을 통해 인증 링크의 배달뿐만 아니라 Unico People Admission 포털의 최종 사용자 인증 흐름에 영향을 미쳤습니다. ** 중요 ** SMS 또는 이메일을 통해 인증 링크를 기다리는 사용자는 기간 동안 수신하지 않았다. 입학 포털에 인증하는 사람들 관리 제품의 최종 사용자도 서비스에 액세스 할 수 없습니다. 클러스터의 디스크가 확장 된 후의 영향이 포함되었습니다. ** 루트 원인 ** 루트 원인은 메시지 처리 흐름에서 확인되었다: 과도하게 큰 페이로드 — 불필요한 데이터를 포함하는 감사 구성 요소에 의해 생성 — 메시지 큐 클러스터에 의해 허용되는 크기 제한을 초과. 그들은 deterministically 모든 시도에 거부 된 이후,이 메시지는 모든 retries를 배출 한 후 죽은 letter queues에 경로를했다. 이 큐는 만료 또는 자동 세척 정책이 없었다, 메시지가 무한하게 축적되고 진보적으로 클러스터의 디스크 공간을 소비. ** 해결책 ** 클러스터의 디스크는 노드당 500GB로 확장되어 즉시 큐와 클러스터 메트릭을 정상화했습니다. 오전 11시 10분에서 정상으로 돌아오는 서비스. 구조적 인 루트 원인 - dead-letter queues의 무한한 축적 - 주소가 될 후속 항목으로 남아. **Lessons 학습 ** symptom \ (disk saturation\)만 주소하는 사건은 축적의 뿌리 원인을 조사하지 않고 문제의 회복을 보장합니다. Lifecycle Policy \(TTL/expiration\) for dead-letter queues and the 부족 of payload size validation before to publishing is a two centralstructure gaps to be corrected. 또한, 문제가 낮은 우선 순위로 분류 된 경고는 경고가 트리거되고 사건의 형식적인 오프닝 사이에 약 38 분의 지연이 발생했습니다. 중요한 서비스 평가를위한 불허한 간격.

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

1. 2026년 7월 13일 PM 12:51 UTCidentified

   고객 여러분, IDCloud 요청의 작은 부분에서 오류를 생성하는 정체성 검증 기능에 대한 불안정성을 확인했습니다. 우리의 기술설계 팀은 진단을 위해 이미 동기를 부여하고 가능한 빨리 서비스를 정상화하기 위하여 뿌리 원인을 확인하기 위하여 일합니다. 이 시간에, 기술 팀은 우리의 자료 층에 있는 상세한 분석을 충격을 완화하기 위하여 지휘하고 있습니다. 더 많은 업데이트가 곧 발송될 것입니다.

2. 2026년 7월 13일 PM 1:06 UTCmonitoring

   고객 여러분, 우리의 엔지니어링 팀은 IDCloud 요청의 작은 부분에서 오류를 생성하는 정체성 검증 기능의 불안정성을 해결하기 위해 작업을 식별하고 구현했습니다. 이 시간에, 기술 팀은 우리의 자료 층에 있는 상세한 분석을 지휘하고 환경을 감시하는 것을 계속합니다. 더 많은 업데이트가 곧 발송될 것입니다.

3. 2026년 7월 13일 PM 1:47 UTCresolved

   경영진 및 영향 7월 13, 2026일, 우리는 IDCloud 요청의 최소 부분에 오류 생성, 여러 인증 흐름에 영향을 미치는 우리의 정체성 검증 기능에 대한 불안정성을 확인했습니다. 이 문제는 9:27 AM BRT의 자동화 된 가용성 경고를 통해 감지, 오류의 약간 증가와 함께 이미 약 8 AM BRT에서 눈에 띄는 및 9:07 AM BRT 주위의 상당한 악화, 9:49 AM BRT의 피크 충격에 도달. 뿌리 원인 및 해결 루트 원인은 내부 인증 구성 요소에 적용 된 gradual 변화로 식별되어 세션 토큰 서명 유효성에 대한 실패가 발생했습니다. 뿌리 원인이 확인되면 엔지니어링 팀은 변경 및 서비스 가용성이 정상으로 반환됩니다. 충격의 가장 중요한 단계는 대략 44 분 지속했습니다. 약속과 다음 단계 엔지니어링은 롤아웃의 이 유형 중 오류 스파이크의 경우 자동 롤백 메커니즘을 포함하여 중요한 인증 구성 요소에 영향을 미치는 점차적인 롤아웃의 변화 유효성 과정에 대한 개선을 평가하고 있습니다. 상세한 postmortem는 다음 단계로 내부로 공유될 것으로 예상됩니다.

4. 2026년 7월 20일 PM 10:47 UTCpostmortem

   # Postmortem : 인증 흐름 불안정성 **주의 날짜:** 7월 13, 2026 ** 정확한 기간: ** ~44 분 ## 요약 7월 13, 2026일, 플랫폼의 인증 흐름에 대한 가용성 향상을 확인했습니다. 이 사건은 보안 토큰을 검증하는 내부 구성 요소의 롤링 배포 중에 도입 된 호환성에 의해 발생했습니다. 원인은 우리의 가동 팀에 의해 진단되고, 분 안에 갱신에 의하여 회복된 체계 안정성을 돌려보냅니다. ## 충격 degradation는 대략 44 분을 지속하고 동시에 플랫폼에 다수 입증 교류를, 고객 직면 서비스에서 대략 0.9%의 과실 비율 결과로. 이 기간 동안, 일부 최종 사용자는 불안정성을 경험하고 일반 오류 메시지 \ (HTTP 500 \)를 보았습니다. 이 이벤트는 44 분 지속되었지만, 증가 된 대기 시간과 비할 수 없습니다. ## 뿌리 원인 실패는 보안 토큰 검증 구성 요소에 업데이트 된 소프트웨어 결함에 의해 발생, 다른 버전을 실행하는 인스턴스 간의 호환성에 결과. 이 호환성은 다른 버전의 동시, 평행한 실행을 요구했기 때문에 시험 환경에서 검출되지 않았습니다. 또한, 내부 엔드포인트는 검증이 실패할 때도 HTTP 성공 응답을 반환, 이는 자동 배포 모니터링 시스템을 방지하고 자동으로 롤아웃을 halting. ## 해결책 원인이 확인되면, On-call 팀은 영향을받는 구성 요소의 롤백을 실행, 즉시 인증 흐름의 가용성을 복원. 이 사건은 자동화된 SLO 경고에 의해 몰입 시작의 분 안에 검출되고, escalation는 사건의 가득 차있는 진단 및 완화를 가능하게 합니다. ## 레슨 우리는 롤링 배포에서 버전 호환성 검증을 개선하고 내부 엔드 포인트의 HTTP 응답 동작을 조정하여 오류 처리가 실패한 배포의 자동 롤백을 트리거하고 고객에게 도달하기 전에 마스크를 방지하기 위해 오류를 표준화합니다. ## 지속적인 개선에 대한 약속 이 것 같은 Incidents는 플랫폼 신뢰성을 지속적으로 개선하는 우리의 약속을 강화합니다. 우리는 학습 기회로 각 사건을 대우하고, 우리의 과정을 검토하고, 탐지와 예방 기계장치를 강화하고, 더 튼튼한 기술설계 연습에 지속적으로 투자합니다. 우리의 목표는 모든 고객에게 가용성 및 투명성에 바를 올리는 것입니다. Unico 팀.

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

1. 2026년 7월 10일 PM 4:43 UTCinvestigating

   현재 IDCLOUD 기능에 대한 불안정성을 경험하고 있습니다. 우리의 기술 팀은 이미 뿌리 원인을 조사하고있다. 더 많은 정보가 가능한 한 빨리 업데이트 할 것입니다.

2. 2026년 7월 10일 PM 5:12 UTCidentified

   우리는 우리의 핵심 검증 및 위험 분석 API의 일부에서 일시 중단 또는 지연을 일으킬 수있는 불안정성을 확인했습니다. 관련 서비스: - Identity & Validation: 식별, 1:1 검증, Serpro 유사성 반환 - 위험 및 사기 : 위험 점수, 사기 위험 분류 - Documentation & Liveness: 문서 재사용 및 캡처, 수명 현재 상태 및 다음 단계 : 우리의 엔지니어링 팀은 이미 완전히 관여하고 뿌리 원인을 조사하고 있습니다. 우리는 행동을 격리하고 가능한 한 빨리 정상적인 가동을 복원하기 위해 적극적으로 노력하고 있습니다.

3. 2026년 7월 10일 PM 5:25 UTCmonitoring

   현재 상태 및 다음 단계 소송 작업은 성공적으로 적용되었으며 시스템은 이제 안정적입니다. 이 시간에, 우리의 기술설계 팀은 지속적으로 안정성과 정상적인 가동을 지키는 플랫폼의 성과를 적극적으로 감시합니다. 이 사건에 대한 귀하의 책임과 이해에 감사드립니다. 귀하의 서비스는 정상적으로 작동해야 합니다.

4. 2026년 7월 10일 PM 5:57 UTCresolved

   경영진 및 영향 사이 1:21 오후와 2:16 오후 (브라질 시간) 7 월 10, 2026, 우리는 프로세스 생성 흐름 및 관련 여행의 가용성에 대한 변동을 확인, 우리의 주요 API의 오류율에 임시 스파이크에 결과. - 충격의 범위: 독점적인 사건은 이 간격 도중 특정 여행의 가용성에 영향을 미쳤습니다. 이 기간 동안 오류율 증가를 경험하지 않은 고객은 영향을받지 않았습니다. - Data Integrity : 처리 된 정보의 무결성 또는 보안에 대한 타협이 없습니다. - Mitigation : 초기 작업은 몇 분 안에 적용되었으며 오류의 볼륨을 단축했습니다. 서비스는 오후 2시 16분에 완전히 정상화되어 엔지니어링 및 모니터링 팀의 안정성 확인을 따르고 있습니다. 뿌리 원인 이 사건은 인프라 서비스에 대한 불안정성에 의해 방아쇠, 관련 내부 구성 요소의 초기화에 급격한 분해에 따라. 약속과 다음 단계 우리는 우리의 플랫폼의 탄력에 깊이 투입됩니다. 사건 중 발생한 정확한 예방 조치는 이미이 자연의 미래 발생 위험을 완화하기 위해 모니터링되고 있습니다. - Postmortem : 상세한 기술 보고서 (Postmortem)는 완전한 타임라인, 건축 분석 및 정의된 마감일을 가진 장기적인 행동 계획을 포함하는 곧 공유될 것입니다. 우리는 진심으로 충격과 불안정성을 위해 사과합니다. 우리의 고객의 신뢰는 우리의 최우선권이고, 우리는 우리의 서비스의 우수성을 지키기 위하여 지속적으로 일합니다. Unico 팀

5. 2026년 7월 14일 PM 2:08 UTCpostmortem

   ** 일정 ** 7 월 10, 2026, 사이 1:21 오후와 2:09 오후 \(브라질 시간 \), 프로세스 생성의 오류율은 약 11% 약 9 분 동안, 지속적인 가용성 분해와 함께 2:09 오후. 이 사건은 인프라 구성 관리 구성 요소의 불안정성에 기인하여 올바르게 초기화하여 바이오미터 서비스 팟을 방지했습니다. 영향은 사전 노출 메모리 소비 행동 \ (팟 재시작의 빈도를 증가) 및 새로운 인스턴스의 생성을 유발하는 트래픽 스파이크에 의해 증폭되었다 - 구성 구성 요소의 불안정성 창에서 초기화 할 수없는 모든. ** 중요 ** 다중 흐름은 프로세스 생성, 인증, 생체 인식, 지불 및 내부 운영을 포함하여 동시에 영향을 미쳤습니다. 바이오 미터 엔진에 의존하는 모든 서비스 전반에 걸쳐 오류가 발생했습니다. 그것의 최고봉에, 과실 비율은 11%를 도달했습니다. 사용 가능한 생물 측정 서비스 pods의 수는 사건의 가장 중요한 창 도중 생산 클러스터 둘 다에서 0에 떨어졌습니다. ** 루트 원인 ** 루트 원인은 생물 측정 서비스의 시작 논리에 최적화 기회와 관련이 있었다 : 인프라 구성 관리 구성 구성 요소가 부팅 중에 실패를 반환하는 경우 응용 프로그램은, 캐시 된 데이터가 가을으로 사용할 수있을 때. 이 논리는 일시적인 커뮤니케이션을 영구적인 윤곽 과실로 동일한 방법을 대우하고, 정확하게 순간에 떨어지는 캐시를 가장 필요로 했습니다. 구성 구성 구성 요소가 불안정한 경우, 모든 팟이 다시 시작하려고 시도 - 메모리 압력 또는 자동 스케일링 때문에 - 실패 루프에 갇혀있어 초기화 과정을 완료 할 수 없습니다. ** 해결책 ** 이 팀은 영향을받는 구성 요소 중 하나에서 트래픽을 격리하여 처음 영향을 미칩니다. 이는 약 9 분 이내에 오류 스파이크를 중단했습니다. 구성 관리 구성 요소의 안정화는 pods가 정상적으로 다시 올 수 있도록합니다. 긴급 수정은 준비하고 같은 날 배포, 시작을 차단하는 제한적 검증을 제거 - 낙하 캐시를 보장은 비슷한 상황에서 투명하게 사용됩니다. **Lessons 학습 ** 이 사건은 서비스의 탄력 메커니즘 인 가을 백 캐시가 아키텍처에 존재했지만 환경 가용성에 대한 엄격한 데이터 검증을 우선 순위화 한 시작 논리에 의해 중립화되었다고 밝혔다. 중요한 서비스를 위한 시작 경로는 인프라 구성 요소가 불안정하지 않을 때 우아하게 향상하도록 설계되어야 합니다. ** 안정성 및 지속적인 개선에 대한 약속 ** 우리는 우리의 인프라의 견고함에 크게 투자하고 지속적으로 효율성, 보안 및 신뢰성의 최고 수준에서 운영되도록합니다. Unico 팀.

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

1. 2026년 7월 7일 PM 9:22 UTCidentified

   Prezado Cliente, Identificamos uma latência seguida de indisponibilidade na criação de processos de algumas capacidades da Unico. Devido a isso, uma parcela de nossos clientes pode perceber lentidão ou aumento de erros em operações que envolvem o ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Nossa equipe de engenharia já foi acionada e está trabalhando no diagnóstico da causa raiz para normalizar o serviço o quanto antes. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar os impactos. Comprometemo-nos a enviar novas atualizações em breve assim que tivermos novidades. Equipe Unico.

2. 2026년 7월 7일 PM 9:32 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno das capacidades de ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026년 7월 7일 PM 10:14 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026년 7월 13일 PM 9:18 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2026년 7월 6일 PM 4:29 UTCidentified

   Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com IDScore, que está apresentando lentidão no retorno do Score de autenticação de determinados processos. Clientes que utilizam orquestração com o Trust podem enfrentar também cenários de erros em determinados processos devido a lentidão identificada. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

2. 2026년 7월 6일 PM 4:51 UTCmonitoring

   Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno do Score de autenticação. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026년 7월 6일 PM 5:25 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026년 7월 13일 PM 9:17 UTCpostmortem

   **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

1. 2026년 7월 2일 PM 10:04 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br Em breve retornaremos com novas atualizações.

2. 2026년 7월 2일 PM 10:05 UTCidentified

   We are continuing to work on a fix for this issue.

3. 2026년 7월 3일 AM 12:04 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimento foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Estamos em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

4. 2026년 7월 3일 AM 1:14 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

5. 2026년 7월 13일 PM 8:36 UTCpostmortem

   ### **Postmortem: WhatsApp Support Channel Instability** #### **Summary** On July 2, 2026, an instability affected our WhatsApp customer support channel. During this period, automated messages from our virtual assistant \(bot\) were not being delivered to end-users. Service was fully restored after the identification and rollback of a system change within our technology partner’s environment. #### **Impact** This incident exclusively impacted customers attempting to reach support through our WhatsApp channel. While automated messages managed by the bot failed to deliver, manual messages sent by human agents continued to operate normally. Our alternative support channels, such as email and webchat, remained fully operational and were communicated as active alternatives during the instability. #### **Root Cause** The root cause was an update deployed in the messaging service managed by our technology partner. This update introduced an incompatibility within the partner's own production environment configurations. This supplier-side infrastructure failure disrupted the automated communication flow, preventing the bot from delivering messages. #### **Resolution** Our partner's technical team investigated the issue within their environment and traced the failure back to the recently deployed update. The resolution applied by the vendor consisted of performing an immediate rollback to the previous stable version of their messaging service. Once the partner completed this rollback, message delivery was successfully restored, and our support channel returned to normal operations. #### **Lessons Learned** This incident reinforced the importance of maintaining an agile contingency and communication strategy to quickly redirect our customers to alternative channels \(such as webchat and forms\) during third-party service outages. Additionally, it highlighted the need to continuously align with our key vendors regarding the requirement for more rigorous validation and testing protocols in their own environments before promoting updates that can impact our operations.

1. 2026년 6월 26일 PM 2:10 UTCresolved

   Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade que causou falhas de acesso na plataforma SafeDoc (através do endereço seu.acesso.io) para um grupo específico de clientes. Durante esse período, alguns usuários enfrentaram dificuldades no fluxo de login, processamento e visualização de imagens e arquivos. A origem do comportamento esteve relacionada a uma atualização programada de manutenção executada na noite de 25/06, que gerou incompatibilidade na parametrização de algumas instâncias do sistema. Nossos times de Engenharia e SRE identificaram o cenário e aplicaram as correções e ajustes de configuração necessários nas instâncias afetadas. O serviço foi restabelecido e está operando normalmente. Lamentamos o ocorrido e seguimos monitorando o comportamento da plataforma para garantir a estabilidade das operações. Em caso de dúvidas, nossa equipe de CX está à disposição. Equipe Unico.

2. 2026년 7월 3일 PM 6:22 UTCpostmortem

   **Resumo** No dia 26 de junho de 2026, entre 00:17 e 10:40 \(horário de Brasília\), um grupo de clientes enfrentou instabilidade que afetou o acesso a alguns de nossos serviços. A falha se manifestou em erros de login, processamento e acesso a arquivos. Nossa equipe de engenharia identificou a causa e restaurou o serviço para todos os clientes afetados. **Impacto** Durante o incidente, que durou aproximadamente 10 horas e 23 minutos, 24 clientes ficaram impossibilitados de utilizar funcionalidades essenciais de nossos serviços, impactando suas operações. O acesso foi completamente restabelecido às 10:40 do dia 26 de junho de 2026. **Causa Raiz** A causa raiz do incidente foi uma falha durante um processo de atualização programada de sistema, que ocorreu na noite do dia 25 de junho. A atualização de configuração não foi aplicada corretamente em um subconjunto de servidores, fazendo com que o sistema fizesse referência a dependências de software desatualizadas e incompatíveis. Essa falha impediu a comunicação correta com serviços de armazenamento em nuvem e de autenticação, resultando nos erros observados pelos clientes. A ausência de validação automatizada pós-implantação e de alertas centralizados para este tipo de erro de configuração impediu a detecção proativa do problema. **Resolução** Assim que o incidente foi reportado na manhã do dia 26 de junho, nossa equipe de prontidão foi acionada. Foi identificado que a falha estava relacionada a uma implantação incorreta de arquivos de configuração. As equipes de engenharia aplicaram as correções necessárias em todas as instâncias afetadas, restaurando a funcionalidade completa dos serviços. Após a aplicação da correção, foi realizada uma verificação completa para garantir que todos os sistemas estivessem operando normalmente. **Lições Aprendidas** * Automação na validação: Implementações em larga escala exigem verificações automatizadas pós-implantação para garantir que todas as instâncias tenham sido atualizadas corretamente e de forma consistente. * Observabilidade centralizada: É fundamental garantir que os registros de erros de todas as aplicações sejam transmitidos para uma plataforma centralizada, permitindo a detecção rápida de anomalias, mesmo que a falha afete a própria capacidade de comunicação da aplicação. Estamos comprometidos com a confiabilidade de nossos serviços e continuaremos trabalhando para fortalecer nossos sistemas e processos.

1. 2026년 6월 24일 PM 6:20 UTCidentified

   Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes Mexico que utilizam essa capacidade. A nossa equipe de tecnologia está analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. 2026년 6월 24일 PM 6:31 UTCmonitoring

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. 2026년 6월 24일 PM 6:53 UTCresolved

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. 2026년 7월 13일 PM 7:27 UTCpostmortem

   **Summary** On June 24, 2026, between 2:55 PM and 3:26 PM \(Brasília time\), the availability indicator for the process creation flow dropped below 95%, with a total duration of approximately 31 minutes. The incident was caused by an instability in an infrastructure provider used in the risk assessment flow, which began returning errors and latency above expected levels. The impact was concentrated on users from Mexican market clients. **Impact** Users of the process creation and authentication flows that relied on the risk assessment step received timeout errors during the period. The impact was more severe for Mexican market clients but also affected authentication flows for other clients. **Root Cause** The root cause was an instability in the infrastructure provider responsible for the risk assessment step. The provider began operating with latency well above normal and returning errors, causing requests that depended on this step to become blocked and propagate failures to the process creation and authentication flows. Internal services were unable to isolate the impact of the provider's degradation, resulting in widespread unavailability for all users passing through this step. **Resolution** The infrastructure provider stabilized on its own at 3:16 PM. The team identified a timeout configuration need during the incident and opened a correction with explicit values. The incident was closed at 3:50 PM after stability was confirmed. **Lessons Learned** The incident highlighted the need to strengthen isolation mechanisms between internal services and infrastructure providers, so that isolated instabilities do not propagate to end users. As follow-ups, the team identified improvements in the resilience of the affected flows and in the documentation of critical dependencies, aiming to reduce response time and impact in future occurrences of a similar nature.

1. 2026년 6월 23일 AM 1:24 UTCinvestigating

   Prezado 클라이언트, Nossa monitoração proativa detectou um comportamento 불규칙한 ID 지불 e no fluxo de onboarding do ByUnico. Embora a causa exata ainda esteja sob investigação, isso pode se appearar como lentidão ou intermitência no serviço. 장비 de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. 에 breve retornamos com atualizações.

2. 2026년 6월 23일 AM 1:39 UTCidentified

   Prezado 클라이언트, Nossa equipe ainda está investigando a causa raiz 할 problema. 에 breve traremos mais atualizações. Agradecemos는 compreensão입니다.

3. 2026년 6월 23일 AM 1:53 UTCidentified

   Prezado 클라이언트, Informamos que nossa equipe identificou a causa da instabilidade e está ativamente trabalhando 나 aplicação da solução. Seguimos empenhados em restabelecer o serviço o mais rapidamente possível e manteremos você informado sobre a evolução. Novas atualizações serão enviadas 에 breve.

4. 2026년 6월 23일 AM 2:18 UTCmonitoring

   Prezado 클라이언트, Nossa equipe identificou as causas do problema e realizou as ações para que este 부패 fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através do nosos canais de atendimento. Atenciosamente, Equipe 유니코!

5. 2026년 6월 23일 AM 2:41 UTCresolved

   Prezado 클라이언트, Nossa equipe identificou as causas do problema e realizou as ações para que este 부패 fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através do nosos canais de atendimento. Atenciosamente, Equipe 유니코!

6. 2026년 7월 14일 PM 1:58 UTCpostmortem

   ** 일정 ** 6월 22, 2026일, 오후 9시 52분 \(Brasília time\)에서 문서 저장 흐름은 데이터베이스의 순차 식별자 제한의 배출로 사용할 수 없습니다. 그 순간부터, 모든 문서 삽입 작업은 실패하기 시작, 여러 의존하는 서비스에 대한 계산 오류. 이 사건은 약 86 분 지속되었습니다. ** 중요 ** 여러 중요한 서비스는 동시에 영향을 미쳤습니다. 내장 흐름, 프로세스 생성, 인증 및 지불. 일부 흐름에서, 가용성은 3% 이하로 떨어졌다. 클라이언트는 문서 저장에 의존하는 작업을 시도 할 때 실패 또는 지연에 영향을 미쳤습니다. ** 루트 원인 ** 루트 원인은 약 2.1 억 값을 지원하는 문서 테이블에 사용되는 32 비트 식별자 유형과 관련되었습니다. 시간이 지남에 기록 된 볼륨의 자연 성장과 함께, 이 한계는 도달, 데이터베이스를 더 이상 새로운 식별자를 생성 할 수 없습니다, 그래서 모든 삽입 작업이 실패하기 시작했다. 이 제한에 대한 근접을 추적하기 위해 구성 된 모니터링이 없기 때문에 소진은 이전 경고없이 abruptly 발생했습니다. ** 해결책 ** 팀은 약 20 분에 뿌리 원인을 확인했습니다. 즉각적인 완화로, 순차적 식별자는 데이터베이스에 구조적 변화를 필요로하지 않고 약 2.1 억 값을 해방하는 동일한 데이터 유형의 부정적인 범위를 사용하기 위해 재구성되었습니다. 이 솔루션은 생산에 적용되기 전에 낮은 환경에서 검증되었습니다. 이 서비스는 해결이 적용 된 후 곧 안정적으로 안정화 시작하고 전체 복구가 확인 될 때까지 모니터링되었습니다. **Lessons 학습 ** 이 사건은 계획된 정비로 처리될 수 있도록 배출을 허용하는 이른 경고와 더불어 높은 볼륨 테이블에 있는 순차적인 식별자 사용법을 위한 감시의 중요성을 강조합니다; 스코마 검토 과정에 있는 이 체크를 포함하여 높은 쓰기 양을 가진 테이블을 위한 8 바이트 식별자 유형의 채택하고, 핵심 persistence 서비스의 긴요한 의존성을 문서화하고, 영향 받은 사용자를 가진 커뮤니케이션을 더 빨리 이전하기 위하여.

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

1. 2026년 6월 19일 PM 1:08 UTCinvestigating

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 2026년 6월 19일 PM 6:34 UTCmonitoring

   Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimentos foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Neste momento, nosso time de engenharia e operações segue em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

3. 2026년 6월 19일 PM 7:42 UTCresolved

   Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

4. 2026년 7월 3일 PM 8:36 UTCpostmortem

   **Sumário** No dia 19 de junho de 2026, identificamos uma instabilidade que afetou nosso canal de atendimento via WhatsApp. O incidente, que teve início aproximadamente às 09:00 e foi resolvido às 15:45 \(horário de Brasília\), impediu que nossos agentes acessassem as conversas dos clientes nessa plataforma. A causa raiz foi um problema técnico originado em um de nossos parceiros de tecnologia, que já foi corrigido. **Impacto** Durante o período do incidente, o atendimento aos clientes finais através do canal de WhatsApp foi impactado. Como alternativa, os clientes foram orientados a utilizar nossos outros canais de contato, como formulário, e-mail e webchat. As operações foram normalizadas no mesmo dia. **Causa Raiz** A investigação, conduzida em conjunto com nosso parceiro tecnológico responsável pela plataforma de gestão de conversas, revelou que a causa do incidente foi uma alteração de certificados de segurança em um sistema terceiro com o qual a plataforma se integra. Essa alteração invalidou o mecanismo de autenticação utilizado pelo serviço, impedindo a comunicação entre a plataforma de atendimento e o canal do WhatsApp. A detecção do problema foi reativa, pois a falha de autenticação não gerava alertas proativos e o ambiente de testes não utiliza os mesmos certificados do ambiente de produção, o que impediu a reprodução do erro em testes preliminares. **Resolução** Após a identificação do problema, a equipe de engenharia do nosso parceiro tecnológico atualizou os certificados de autenticação em seus sistemas para restabelecer a compatibilidade com a plataforma terceira. A correção foi aplicada e validada, normalizando o acesso dos nossos agentes às conversas e restaurando completamente o serviço de atendimento via WhatsApp às 15:45. **Lições Aprendidas** * É crucial manter uma comunicação ativa e monitorar os canais de parceiros tecnológicos para se antecipar a mudanças que possam impactar os serviços integrados. * Falhas de autenticação com serviços externos são um ponto crítico e devem possuir mecanismos de alerta específicos para permitir uma detecção e resposta mais rápidas, reduzindo o tempo de indisponibilidade. Estamos empenhados em garantir a estabilidade e a qualidade de nossos canais de atendimento e continuaremos a trabalhar em estreita colaboração com nossos parceiros para fortalecer a resiliência de nossos serviços.

1. 2026년 6월 12일 PM 3:29 UTCidentified

   Prezado Cliente, Estamos acompanhando uma instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações.

2. 2026년 6월 12일 PM 5:03 UTCidentified

   Prezado Cliente, Seguimos acompanhando a instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações

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

   Prezado Cliente, As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

4. 2026년 6월 12일 PM 6:31 UTCresolved

   Prezado Cliente, Incidente resolvido. As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

1. 2026년 6월 12일 PM 2:58 UTCidentified

   Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via e-mail ou nos contatarem pelo nosso webchat como alternativa de contato sincrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

2. 2026년 6월 12일 PM 5:31 UTCmonitoring

   Prezado Cliente, As ações corretivas para o incidente foram executadas pelo nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido Atenciosamente, Equipe Unico

3. 2026년 6월 12일 PM 6:00 UTCresolved

   Prezado Cliente, Incidente resolvido. as ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico