ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações

Desempenho e Disponibilidade das APIs

ITEM 2.1

Controle de versão

Versão

Data

Resumo das alterações

1

May 27, 2024

Versão inicial

Introdução e Objetivos

Esta métrica visa monitorar e assegurar que as APIs das instituições participantes do Open Finance estejam aderentes aos padrões de desempenho e disponibilidade estabelecidos. A Estrutura Responsável pela Governança do Open Finance monitora essas questões para garantir a integridade, eficiência e eficácia do ecossistema do Open Finance.

Sobre a Métrica

A métrica se baseia em dois aspectos principais para determinar a conformidade das APIs das instituições participantes: a disponibilidade das APIs e o tempo de resposta das APIs.

Disponibilidade das APIs

  • Disponibilidade Diária: Monitoramento diário da disponibilidade das APIs, calculada como a fração do total de requisições válidas processadas com sucesso a cada intervalo de 1 minuto.

  • Disponibilidade Longa: Média móvel das disponibilidades dos últimos 90 dias corridos, considerando apenas os dias em que a disponibilidade diária pode ser calculada.

Tempo de Resposta das APIs

  • Desempenho: Medição do tempo de resposta de cada requisição, desde o recebimento da requisição pelo gateway até o envio do último byte da resposta. O valor do percentil 95 (P95) do tempo de resposta é utilizado para minimizar o impacto de valores extremos (outliers).

Critérios de Conformidade:

Disponibilidade das APIs

  • Disponibilidade diária mínima de 95%.

  • Disponibilidade longa (média móvel de 90 dias) mínima de 99.5%.

Tempo de Resposta das APIs

  • Percentil 95 do tempo de resposta:

    • 1.500ms para endpoints de alta e média-alta frequências.

    • 2.000ms para endpoints de média frequência.

    • 4.000ms para endpoints de baixa frequência.

Informações Adicionais

  • As medições devem ser feitas para cada versão major dos endpoints em produção.

  • As requisições com todos os códigos de retorno possíveis devem ser consideradas, exceto aquelas associadas a limites de tráfego e operacionais.

  • As medições de tempo de resposta e disponibilidade devem ser realizadas de maneira independente pela instituição provedora da API, além da Plataforma de Coleta de Métricas (PCM).

  • A Estrutura Responsável pela Governança do Open Finance deve disponibilizar indicadores adicionais para monitoramento e aprimoramento do ecossistema.

APIs de Iniciação de Pagamentos (Pix)

De acordo com o arranjo do Pix, o período de apuração do índice de disponibilidade é mensal. Todos os participantes do Pix devem apurar seu próprio índice de disponibilidade, podendo o BCB solicitar, a qualquer tempo, informações adicionais dos participantes para validação do índice informado, bem como utilizar mecanismos de validação dessa informação por meio de informações disponíveis na infraestrutura operada pelo BCB.

A meta mensal de índice de disponibilidade de cada categoria de participante é a seguinte:

Categoria

Disponibilidade

Categoria

Disponibilidade

A

99,5%

B

99,0%

C

98,5%

D

95,0%

Metodologia Simplificada

Para fins de monitoramento deste item, o período de apuração será mensal, conforme orientado pelo Manual de Monitoramento do Open Finance Brasil. A avaliação envolverá:

  • Disponibilidade diária: Monitoramento da disponibilidade diária de todos os dias do mês de referência.

  • Disponibilidade longa: Cálculo da disponibilidade longa como média móvel dos últimos 90 dias.

  • Tempo de Resposta: Medição do tempo de resposta de cada requisição e cálculo do percentil 95 (P95) do tempo de resposta.

Interpretação dos Resultados

Os resultados da métrica serão interpretados para verificar se as instituições estão cumprindo os critérios de conformidade para desempenho e disponibilidade das APIs. A análise incluirá:

Disponibilidade das APIs

Disponibilidade Diária

  • A disponibilidade pontual (t) é calculada como a fração do total de requisições válidas processadas com sucesso a cada intervalo de 1 minuto. Por exemplo, a disponibilidade pontual de um endpoint referente ao minuto 11:34, de um determinado dia, no qual houve um total de requisições válidas com sucesso de 255 e um total de requisições válidas com erro de 4, é calculada da seguinte forma:

image-20240527-165154.png

A disponibilidade diária é calculada baseada nas informações das disponibilidades pontuais.

Disponibilidade Longa

  • A disponibilidade longa é calculada diariamente como média móvel das disponibilidades dos últimos 90 dias corridos. Por exemplo, a disponibilidade longa do último dia de março é a média das disponibilidades diárias dos últimos 90 dias.

Tempo de Resposta das APIs

Cálculo do Desempenho

  • Para fins do cálculo do desempenho, deve-se considerar o valor do percentil 95 (P95) dos tempos de resposta diários.

  • Exemplo: Se um endpoint recebe 10.555 requisições em um dia (n = 10.555), o índice para o percentil 95 (i95) será 10.027 (i95 = [0.95 * n] = [10.027,25] = 10.027). Ordenando os tempos de resposta em ordem crescente (Rord), o valor do percentil 95 (P95) será o tempo de resposta na posição 10.027 no conjunto ordenado Rord

Service Level Agreement (SLA)

  • Endpoints de alta e média-alta frequências: P95 do tempo de resposta em no máximo 1.500ms.

  • Endpoints de média frequência: P95 do tempo de resposta em no máximo 2.000ms.

  • Endpoints de baixa frequência: P95 do tempo de resposta em no máximo 4.000ms.

Aferição do Desempenho

  • Um endpoint estará em conformidade se respeitar o SLA do desempenho em pelo menos 90% dos dias do mês de referência, com o valor do P95 dos demais dias não superior ao SLA do desempenho aumentado em 20%.

 

Exemplo Ilustrativo

Para ilustrar as condições de conformidade e desconformidade, considere os seguintes exemplos:

Conformidade

Em um mês de 30 dias, um endpoint de alta frequência deve apresentar um valor de P95 inferior a 1500ms em pelo menos 90% dos dias (27 dias). Nos demais dias, o valor de P95 pode ser até 20% superior ao SLA (1500ms * 1,2 = 1800ms).

Dia

P95 (ms)

Conformidade

Dia

P95 (ms)

Conformidade

1

1400

Sim

2

1450

Sim

3

1600

Sim

27

1500

Sim

28

1750

Sim

29

1780

Sim

30

1790

Sim

Neste exemplo, o endpoint está em conformidade para fins do processo de monitoramento naquele mês, pois em 27 dias o P95 foi inferior a 1500ms e, nos demais dias, o P95 não ultrapassou 1800ms.

Desconformidade

Em um mês de 31 dias, um endpoint de alta frequência deve apresentar um valor de P95 inferior a 1500ms em pelo menos 90% dos dias (28 dias). Nos demais dias, o valor de P95 pode ser até 20% superior ao SLA (1500ms * 1,2 = 1800ms). Se em qualquer um desses dias o P95 for superior a 1800ms, o endpoint estará em desconformidade.

Dia

P95 (ms)

Conformidade

Dia

P95 (ms)

Conformidade

1

1400

Sim

2

1450

Sim

3

1600

Sim

28

1500

Sim

29

1820

Não

30

1750

Sim

31

1790

Sim

Neste exemplo, o endpoint não está em conformidade para fins do processo de monitoramento naquele mês, pois em pelo menos um dos dias (dia 29), o P95 foi superior a 1.800ms.

Para maior clareza, veja a representação visual dos exemplos:

Mês

Dias do mês

Dias com P95 < 1500ms

Dias com P95 entre 1500ms e 1800ms

Dias com P95 > 1800ms

Conformidade

Mês

Dias do mês

Dias com P95 < 1500ms

Dias com P95 entre 1500ms e 1800ms

Dias com P95 > 1800ms

Conformidade

Março

30

27

3

0

Sim

Abril

31

28

2

1

Não

Aspectos Técnicos

Sob a perspectiva da Plataforma de Coleta de Métricas (PCM), os dados são predominantemente observados do lado do servidor. Na terminologia da PCM, o servidor é a instituição que fornece os dados em resposta a uma solicitação, enquanto o cliente é a instituição que faz a solicitação de dados. A avaliação da métrica é feita com base nos reportes enviados tanto pelo servidor quanto pelos seus respectivos reportadores (clientes). Quando não há reporte do cliente, é considerado o reporte do próprio servidor.

O status UNPAIRED é utilizado para indicar que o cliente ainda não reportou para a PCM. Além disso, são considerados os status codes 408, 5XX (família 500), 2XX (família 200) e 422 para todos os endpoints obrigatórios da instituição participante em análise, desde que o status não seja PAIRED_INCONSISTENT (pareados e inconsistentes).

Registros com os status UNPAIRED e PAIRED_INCONSISTENT são considerados divergentes e devem passar pelo processo de resolução. Esses registros indicam que houve uma discrepância entre os reportes enviados pelo cliente e pelo servidor ou que o reporte do cliente ainda não foi recebido, respectivamente. A conciliação dessas divergências é essencial para manter a integridade e a precisão dos dados coletados pela PCM.

Dados e Fontes

Para o cálculo da métrica, utiliza-se um conjunto diversificado de dados provenientes de diferentes fontes. A principal fonte informacional é a Plataforma de Coleta de Métricas (PCM), que consolida os dados a partir dos reportes enviados pelas instituições participantes. Além disso, as planilhas auto reportadas pelas instituições são integradas e consolidadas na Plataforma Analítica de Dados (PAD), um repositório centralizado que serve como base para a análise e avaliação da métrica. Essa combinação de dados provenientes da PCM e das planilhas auto reportadas permite uma avaliação precisa da métrica e um monitoramento efetivo do desempenho e disponibilidade das APIs no contexto do Open Finance.

Limitações e Considerações

Atualmente, não há visibilidade ou conhecimento de limitações ou considerações adicionais para esta métrica. A análise será continuamente revisada e aprimorada conforme novos dados e informações se tornem disponíveis.

ESTE É UM CONTEÚDO EM DESENVOLVIMENTO E NÃO DEVE SER CONSIDERADO COMO VERSÃO FINAL!
Clique aqui para maiores informações