Indisponibilidade Programada

Notificação de Indisponibilidade Programada 

Finalidade 

Esta página estabelece a regra de antecedência e o conteúdo mínimo para uma manutenção ser tratada como indisponibilidade programada no Open Finance. Vale para os dois canais formais de reporte: o endpoint /outages da API Comum (Discovery), documentado na Área do Desenvolvedor, e o Portal do Service Desk (interface web), operado pela Estrutura de Governança nos termos do Manual de Serviços Prestados pela Estrutura de Governança do Open Finance. 

A política abrange manutenções programadas de qualquer natureza: sem impacto, com impacto parcial ou com impacto total sobre as APIs do ecossistema. 

Esta página trata apenas da classificação operacional das janelas e da forma como elas aparecem em relatórios, painéis e registros da Estrutura de Governança. Não altera o cálculo do SLA de disponibilidade, pois o Manual de APIs já estabelece, no item VI, que toda indisponibilidade conta no SLA, programada ou não. 

Princípio 

Uma manutenção só é tratada como “programada” se a instituição avisou com antecedência real, em tempo suficiente para que iniciadores e receptores possam redirecionar tráfego, comunicar clientes e postergar jornadas. Notificação publicada em cima da hora, no mesmo horário do início da janela ou após o início não confere à janela o caráter de programação, independentemente do canal usado. 

O objetivo da regra é instrumental à evolução das jornadas de consentimento: evitar que o usuário final do Ecossistema seja direcionado a um serviço sabidamente indisponível. 

Antecedência mínima 

A notificação, seja no endpoint /outages, seja no Portal do Service Desk, deve ser publicada com pelo menos 12 (doze) horas de antecedência em relação ao início da janela de manutenção. 

Regra especial para finais de semana e feriados: manutenções programadas para sábado, domingo ou feriado devem ser comunicadas até as 12h00 (meio-dia) do último dia útil anterior ao início da janela. Esta regra prevalece sobre o prazo geral de 12 horas sempre que resultar em antecedência maior. 

Conteúdo mínimo da notificação 

A notificação deve conter, no mínimo: 

1. Data e hora de início 

2. Duração prevista 

3. Classificação de impacto: sem impacto, impacto parcial ou impacto total 

4. Escopo: APIs e endpoints afetados (obrigatório nos casos de impacto parcial) 

5. Motivo 

No /outages, esses elementos correspondem aos campos outageTime, duration, isPartial e explanation. No Portal do Service Desk, devem constar do corpo da comunicação. 

Notificação incompleta é tratada como notificação ausente. 

Regra de reclassificação 

Se a notificação não atender à antecedência mínima (12 horas, ou 12h00 do dia útil anterior em caso de fins de semana/feriados) ou ao conteúdo mínimo, a janela é classificada como indisponibilidade não programada nos registros e relatórios da Estrutura de Governança, no monitoramento operacional e nos painéis públicos (quando disponibilizados). Vale para qualquer canal de notificação e independe do status retornado em /status (ex.: SCHEDULED_OUTAGE) ou da existência de comunicação correlata no Service Desk. 

Esta reclassificação é estritamente operacional. Não altera o cálculo do SLA de disponibilidade, que segue o item VI da seção de Disponibilidade do Manual de APIs: toda indisponibilidade conta no cálculo do período apurado, programada ou não. 

Exceção para Manutenção emergencial 

Incidente ativo de segurança ou de estabilidade que demande ação imediata pode ser notificado com menos de 12 horas (ou fora da janela de 12h00 do dia útil anterior, quando aplicável). Nesse caso, a janela é classificada como indisponibilidade não programada com comunicação tempestiva, categoria que reconhece o esforço da instituição em avisar, mas não confere à janela o tratamento operacional de “programada”. 

A comunicação tempestiva deve sair nos canais usualmente utilizados pela instituição (/outages e/ou Service Desk) assim que viável. Como em qualquer indisponibilidade, a janela conta no cálculo do SLA conforme o Manual de APIs. 

Atualização e cancelamento de notificações 

• Antecipação do início: se o horário de início foi adiantado depois da publicação, a antecedência é recontada a partir do novo horário. Se ficar abaixo de 12 horas (ou descumprir a regra de 12h00 do dia útil anterior para fins de semana/feriados), a janela vira não programada. 

• Expansão do escopo: incluir novas APIs ou endpoints na janela exige nova notificação, com as 12 horas aplicando-se apenas aos itens adicionados. 

• Cancelamento: se a janela for cancelada, a desativação deve ser publicada no mesmo canal usado na notificação original, assim que conhecida. Cancelamento não exige antecedência. 

Consolidação de janelas 

Várias janelas seguidas, ou múltiplas janelas no mesmo dia afetando o mesmo conjunto de APIs/endpoints, são tratadas como uma janela única para efeito desta regra. Isso evita fragmentar a indisponibilidade em pedaços pequenos para tentar contornar a exigência de antecedência. 

Referências 

Manual de Serviços Prestados pela Estrutura de Governança do Open Finance: 
https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=588 

Manual de APIs do Open Finance: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=615