Versão

Data

Resumo das alterações

Contexto do Problema

Explicação da situação garantindo a identificação de: o que, onde, quando e quanto do item monitorado bem como período de apuração; o que está envolvido (painel, endpoint, produto, canal, marca, ambiente, ticket, volume e nível de severidade do impacto); e se a desconformidade é pontual, recorrente ou estrutural.

Causas Identificadas

Detalhamento da(s) causa(s) raiz(es) em sua origem, indicando o motivo fundamental (técnico, processual, de governança, dados ou dependência externa), sem descrever apenas o contexto do problema. Indica o onde, o estado atual dos componentes que atendem o serviço (capacidade, configuração etc.) e a razão de como o estado contribuiu para o problema.

Soluções Aplicadas

Descrição das soluções aplicadas/em aplicação para correção das causas, detalhando a(s) ação(ões) adotada(s) e o resultado esperado, componentes corrigidos, datas marco de início e de conclusão.

Controles Mitigatórios

Informação sobre o que impedirá a recorrência, incluindo controles preventivos e detectivos, alertas, rotinas de monitoramento, esteiras de validação, aumento de capacidade e melhorias de governança interna.

Tempo de resposta das APIs (Desempenho)

Disponibilidade das APIs

Requisições com status code HTTP 529 (sobrecarga do servidor)

Versões iniciais e novas versões de APIs

Implementação de APIs e artefatos associados

Modalidades de participação

Retirada de versões antigas de APIs

Metas de prazo máximo para atendimento de tickets (SLA)

Reporte de informações (PCM e planilhas autorreportadas)

Qualidade de dados

Jornada do cliente

Taxa de conversão

Contexto do problema

Descrição objetiva do cenário em que a desconformidade ocorreu, incluindo, por exemplo: APIs afetadas, período de ocorrência, magnitude da degradação (ex.: percentis de latência acima do limite regulatório – quanto), componentes impactados, volume de chamadas (volume é contexto e não a causa) e impacto no negócio (ex.: indisponibilidade, lentidão para consumidores – especificar quais e quando).

Causas identificadas

Identificação clara da causa (e causas contribuintes), com nexo causal técnico com o contexto explicitamente declarado.

Deve conter: componente(s) ofensor(es), sua capacidade instalada, dependência da API para com o serviço ofertado pelo componente e demais contextos necessários à análise.

A causa deve ser demonstrável, se solicitado, evitando suposições (se baixa capacidade de processamento, por exemplo, deve-se possuir a possibilidade de demonstrar consumo de CPU próximo do limite provisionado, ou outro indicador em sistema corporativo que o prove).

Soluções aplicadas

Descrição das ações corretivas implementadas para eliminar cada causa, incluindo, por exemplo: ajustes de arquitetura (quais), otimização de código (onde, razão), escalabilidade de infraestrutura (onde, quanto), banco de dados (o quê), correções de integração ou filas (o quê).

As soluções devem ser específicas às causas relatadas, com indicação de quando serão aplicadas, em quais componentes e qual é o resultado esperado.

Controles mitigatórios

Medidas implementadas para prevenção de novas ocorrências, como por exemplo: implantação de monitoramento em tempo real para ação manual imediata (qual melhoria), definição de thresholds de latência para APIs, alertas automáticos antes da degradação crítica, dashboards operacionais visíveis para times técnicos e gestão. As medidas devem ser vinculadas ao indicador afetado. 

Foi detectado que durante o pico diário das H às H ocorre saturação do pool de conexões de integração provisionado na configuração do Nginx, hoje limitado a X, o que leva ao não atendimento imediato de requisições solicitadas pelo API gateway ao sistema de contas-correntes, deflagrando reconexões, com consequente lentidão para os consumidores do endpoint X do Open Finance.

Instabilidade pontual de performance.

Reconstrução durante o período sob análise, do índice de ID de recurso no banco de dados Oracle. Esse índice é necessário ao endpoint de recursos Z, ocasionando lentidão de resposta aos requests.

Lentidão momentânea no banco de dados.

Incapacidade de autoscaling da memória necessária ao cache durante o pico de X a Y, ocasionada por limitação Z.

Pico de acesso não previsto.

Contexto do problema

Detalhamento do incidente (data, duração, APIs afetadas), impacto no serviço/cliente, nível de indisponibilidade (total ou parcial) e indicadores de disponibilidade antes/durante o evento.

Causas identificadas

Descrição da causa raiz (ex.: falha de infraestrutura, indisponibilidade de fornecedor, erro de deploy, falha de rede), com explicação técnica clara e validação pela equipe responsável.

Soluções aplicadas

Medidas adotadas para normalização (rollback, correção técnica, ajuste de configuração, acionamento de contingência), com registro da execução e validação da restauração do serviço.

Controles mitigatórios

Implementação de monitoramento de disponibilidade, definição de SLA, planos de contingência e redundância, gestão de mudanças, testes de resiliência e processos formais de gestão de incidentes.

Indisponibilidade causada por falha no cluster de banco de dados primário, devido ao esgotamento de conexões simultâneas, sem acionamento automático do failover configurado.

Falha de infraestrutura.

Interrupção da API ocasionada por erro em deploy de versão (v2.3.1), que introduziu loop de requisições e sobrecarga no serviço.

Problema de deploy.

Queda devido à indisponibilidade do provedor externo de autenticação utilizado na API x (timeout superior a 30s), sem mecanismo de fallback implementado. 

Falha no provedor de terceiro.

Contexto do problema

Descrição detalhada do evento: quando ocorreu (datas/horários), duração e sistemas afetados; identificação das APIs, serviços ou canais impactados;
volume de requisições e comportamento observado (picos, anomalias de tráfego); impacto ao cliente e ao negócio (ex.: indisponibilidade de serviços críticos, falha em transações); classificação do incidente conforme (ex.: severidade, criticidade).

Causas identificadas

Análise de causa raiz (RCA), com evidências técnicas e indicação se o problema decorreu de: capacidade insuficiente (infraestrutura), falha em balanceamento de carga, ataque ou comportamento anômalo (ex.: DDoS), erro de configuração ou deploy, dependência de terceiro (cloud, API externa).
Registros de logs, métricas e traces que comprovem a origem do problema.
Avaliação de falha de controles preventivos existentes.

Soluções aplicadas

Ações corretivas imediatas adotadas (ex.: aumento de capacidade, rollback de versão, bloqueio de tráfego, ajuste de rate limit); correções estruturais implementadas (ex.: auto scaling, melhoria de arquitetura (qual), otimização de código – onde e por qual razão; ajustes em monitoramento e alertas; implementação de planos de continuidade ou contingência.

Controles mitigatórios

Controles preventivos implementados ou reforçados, como por exemplo: mecanismos de auto scaling, rate limiting e throttling, balanceamento e distribuição de carga, e redundância e alta disponibilidade; monitoramento contínuo (APM, observabilidade, alertas proativos); planos de resposta a incidentes (runbooks, playbooks); governança e revisão periódica de capacidade; treinamento de equipes e revisão de processos de change management; indicadores (KPIs/KRIs) definidos para evitar recorrência.

Durante o pico identificou-se saturação do cluster de APIs devido à ausência de auto scaling, resultando em rejeição de requisições com status HTTP 529. 

Ocorreu instabilidade no sistema durante o período.

Verificou-se falha no balanceador de carga, que direcionou volume excessivo de requisições para um único nó degradado, ocasionando sobrecarga e respostas HTTP 529. 

Houve indisponibilidade momentânea do serviço.

Não houve redirecionamento do tráfego ao provedor anti-DDOS devido a falha humana, levando à exaustão de recursos e geração de respostas HTTP 529.

Ataque impactou a aplicação. 

Contexto do problema

Descrição detalhada do evento relacionado à publicação inicial ou à alteração de versão da API, incluindo datas, ambientes, e identificação das APIs impactadas.

Causas identificadas

Apresentação da análise de causa raiz indicando falhas no processo de gestão de mudanças, versionamento ou governança de APIs. Isso pode incluir ausência de controle sobre versionamento, mudanças não documentadas ou falhas em pipelines de deploy. 

Soluções aplicadas

Descrição das ações corretivas adotadas, melhorias implementadas no processo, como reforço em testes automatizados, ajustes em pipelines de CI/CD, revisão de procedimentos.

Controles mitigatórios

Demonstrar os controles implementados ou aprimorados para evitar recorrência, incluindo mudanças nos processos formais de versionamento, processos estruturados de gestão de mudanças e releases, e obrigatoriedade de testes abrangentes antes da publicação. Também são esperados monitoramento contínuo, indicadores de qualidade de APIs e revisão periódica dos processos de desenvolvimento e publicação. 

Apesar de ter sido registrado erro no provisionamento da nova API no GW, o processo automatizado prosseguiu com sua publicação no balanceador de carga, colocando em produção uma atualização parcial e mantendo simultaneamente o serviço antigo em produção.

Houve problema na atualização da API.

O processo de gestão de mudanças não previa o redirecionamento da ação em caso de restruturação organizacional, o que deixou o pedido de mudanças atribuído a uma equipe inexistente.. 

A API não foi publicada em produção na data prevista por erro humano.

Contexto do problema

Descrição clara da desconformidade identificada, indicando, por exemplo, se há API não aderente ao padrão do Open Finance ou divergente das especificações técnicas, além das APIs afetadas, incluindo nome, versão e endpoints impactados.

Causas identificadas

Apresentação de causa raiz detalhada, apontando se o problema decorre de erro de implementação, falha em deploy ou divergência entre documentação e código. Identificar se a causa está relacionada a especificações técnicas incorretas, erro de versionamento, falhas em artefatos (como Swagger/OpenAPI, certificados ou metadados) ou problemas de segurança/autenticação. 

Soluções aplicadas

Descrição das correções, incluindo ajustes em endpoints e APIs, serviços de negócio (backend), correção de certificados ou configurações de segurança. Devem ser informadas as datas da implementação das correções e caso aplicável, também deve ser indicada a atualização no Diretório de Participantes.

Controles mitigatórios

Descrição das ações adotadas para prevenção de novas ocorrências, monitoramento contínuo de APIs (incluindo health checks e métricas de erro) e revisão dos processos de governança de APIs, incluindo deploy, versionamento e publicação. 

Detalhamento dos controles preventivos, como validações antes da publicação e revisão de artefatos, e os controles detectivos, como alertas, logs e monitoramento contínuo.

A falha foi causada por divergência entre o contrato publicado na especificação e a implementação em produção, devido à ausência de validação automatizada no pipeline de deploy.

Erro sistêmico e de publicação de API.

O problema ocorreu por configuração incorreta do certificado de segurança (mTLS), incompatível com os requisitos definidos, após atualização de infraestrutura sem testes de regressão completos. 

Falha de configuração do certificado de segurança.

A desconformidade foi originada por versionamento inadequado da API, em que a versão “deprecated” foi removida antes do prazo de convivência, devido à ausência de controle formal de ciclo de vida de APIs. 

Problema técnico de versionamento.

Contexto do problema

Detalhamento da natureza da inconsistência, como classificação incorreta, ausência de documentação comprobatória ou enquadramento inadequado. Deve incluir o período de ocorrência, as áreas ou processos impactados.

Causas identificadas

Descrição da causa raiz do problema, indicando se a origem decorre de falhas sistêmicas, erros operacionais, interpretação inadequada da norma ou ausência de atualização de sistemas e procedimentos, bem como indicar se a causa é pontual ou estrutural.

Soluções aplicadas

Apresentação das ações corretivas adotadas para sanar o problema, como reclassificação de participações, ajustes em bases de dados e revisão de critérios. Descrever as melhorias em processos, incluindo atualização de políticas, normas e fluxos, bem como eventuais ajustes sistêmicos ou automações, além de informar os treinamentos realizados e os prazos e status das ações (concluídas ou em andamento).

Controles mitigatórios

Detalhamento dos controles implementados para prevenção de nova ocorrência, incluindo validações automáticas, conciliações periódicas e revisões independentes.

A classificação incorreta das modalidades de participação ocorreu devido à ausência de parametrização adequada no Diretório após atualização da normativa regulatória, resultando em enquadramento indevido.

A inconsistência foi causada por um erro sistêmico não especificado.

O apontamento foi causado pela inexistência de controle de validação independente no processo de cadastro, permitindo divergências entre a documentação suporte e o registro da modalidade de participação.

Houve um problema manual no processo de provisionamento.

A inconsistência identificada decorreu da interpretação inadequada do item pela equipe operacional, em razão de falta de treinamento específico e ausência de orientação formal atualizada.

O problema ocorreu devido a falha humana.

Contexto do problema

Descrição clara do cenário, evidenciando que versões antigas de APIs permaneceram ativas além do período permitido pelas normas, informando qual API e qual versão estavam em desacordo, detalhando a data prevista para descontinuação em comparação com a data real de retirada, bem como descrever os impactos no ecossistema, como a eventual utilização continuada por consumidores.

Causas identificadas

Demonstração da análise de causa raiz, descrevendo de forma detalhada os fatores que levaram ao descumprimento, que pode incluir falhas no processo de governança de APIs, como ausência de demanda interna de descontinuação, problemas técnicos que impediram a remoção da versão antiga, dependência de terceiros que não migraram no prazo.

Soluções aplicadas

Descrição das ações corretivas adotadas para sanar o problema, incluindo a desativação das versões antigas fora de conformidade, a implementação ou melhoria do processo de gestão do ciclo de vida das APIs.

Controles mitigatórios

Apresentação das medidas preventivas implementadas para prevenção de nova ocorrência, como a formalização de uma política de versionamento e descontinuação alinhada às normas, a implantação de monitoramento contínuo do uso das APIs por meio de telemetria, a configuração de alertas automáticos para versões próximas do vencimento, e o estabelecimento de processos de governança com pontos de controle obrigatórios.

A descontinuação da versão da API não ocorreu no prazo devido à ausência de um processo formalizado de gestão de ciclo de vida, o que resultou na falta de acompanhamento estruturado das datas de sunset previamente definidas.

Falha operacional no processo de APIs.

O atraso na retirada da versão foi causado por dependência de participantes externos que não concluíram a migração no prazo, somado à ausência de um plano de contingência para encerramento forçado conforme exigido.

Houve um desalinhamento interno.

Contexto do problema

Descrição objetiva do cenário identificado, com apresentação dos dados quantitativos (percentuais de SLA não atendido, volume de tickets impactados, períodos afetados).

Causas identificadas

Análise detalhada da causa raiz, demonstrando que houve investigação estruturada. As causas podem incluir fatores como inadequação no dimensionamento da equipe, falhas em processos de priorização, ineficiências nos fluxos operacionais, indisponibilidade ou limitação de sistemas, ausência de automação ou falhas na capacitação dos colaboradores.

Soluções aplicadas

Descrição das ações corretivas implementadas para tratar o problema, incluindo ajustes de capacidade operacional (contratação ou realocação de equipe), revisão de SLAs e critérios de priorização, otimização dos fluxos de atendimento, melhorias sistêmicas (automação, ferramentas de monitoramento) e ações de capacitação. Deve-se demonstrar que as soluções estão alinhadas à eliminação das causas.

Controles mitigatórios

Apresentação dos mecanismos implementados para prevenção de nova ocorrência, como monitoramento contínuo dos indicadores de SLA, definição de alertas preventivos para tickets próximos do vencimento, rotinas de acompanhamento gerencial, indicadores de desempenho acompanhados pela governança, auditorias internas periódicas e planos de contingência para picos de demanda.

Cronograma de regularização dos tickets em aberto

Apresentação de cronograma detalhado para solução de cada ticket atrasado em aberto na data de apuração, com identificação do ticket, situação atual e data prevista de conclusão, permitindo o acompanhamento objetivo do cumprimento dos prazos assumidos.

O volume de tickets aumentou 35% no período analisado sem ajuste proporcional no dimensionamento da equipe, gerando fila superior à capacidade de atendimento e impactando diretamente o cumprimento dos SLAs.

Alto volume de demandas.

A ausência de critérios automatizados de priorização resultou no tratamento inadequado de tickets críticos, causando atrasos no atendimento de solicitações com maior urgência.

Problemas no processo de atendimento.