INSTRUÇÃO NORMATIVA BCB Nº 574, DE 20 DE DEZEMBRO DE 2024 (parte 3 de 3)

5.3.1 Cálculo do desempenho
Para fins do cálculo do desempenho, deve-se considerar o valor do percentil
95 e as requisições para medir o desempenho, que pretende minimizar impacto do
aparecimento de valores extremos (outliers). O valor do percentil 95 pode ser obtido da
seguinte maneira:
I - coleta dos dados: Seja R o conjunto de todos os tempos de resposta de um
dia, onde ri é o tempo de resposta da i-ésima requisição. Ou seja, R={r1, r2, ..., rn};
II - cálculo do índice do percentil 95: o índice para o percentil 95, denotado
por i95, é calculado pela fórmula i95 = 0.95 * n, arredondado para o número inteiro mais
próximo, e onde n representa número de requisições;
III - ordenação dos dados: Ordene o conjunto R em ordem crescente para
obter o conjunto ordenado Rord={r(1), r(2), ..., r(n)}, onde r(1) é o menor tempo de
resposta e r(n) é o maior; e
IV - obtenção do valor do percentil 95: o valor do percentil 95, denotado por
P95, é o valor no índice i95 no conjunto ordenado Rord. Ou seja, P95 = r(i95).
Considerando um exemplo em que um endpoint recebe 10.555 requisições em
um dia (ou seja, n = 10.555). Nesse caso, o índice para o percentil 95 será 10.027 (i95
= [0.95 * n] = [10.027,25] = 10.027). Após ordenarmos as medições do tempo de resposta
em ordem crescente (formando o conjunto Rord), o valor do percentil 95 (P95) para esse
dia será igual ao tempo de resposta na posição 10.027 no conjunto ordenado Rord.
5.3.2 Service Level Agreement (SLA) do desempenho
Neste contexto, os endpoints das APIs deverão manter, diariamente, o
percentil 95 do tempo de resposta em no máximo:
I - 1.500ms, em endpoints classificados como de alta e média-alta
frequências;
II - 2.000ms, em endpoints classificados como de média frequência; e
III - 4.000ms, em endpoints classificados como de baixa frequência.
Por exemplo, em um dia que um endpoint de alta frequência receba 10.000
requisições, o tempo de resposta de pelo menos 9.500 requisições deve ser inferior a
1.500ms.
Informações adicionais:
I - as medições de tempo de resposta devem ser realizadas de maneira
independente para cada versão "major" dos endpoints em produção;
II - devem ser consideradas as requisições com todos os códigos de retorno
possíveis, com exceção dos associados a limites de tráfego e limites operacionais;
III - esta subseção não se aplica às APIs de "Webhook";
IV - as instituições provedoras devem gerar e acompanhar seus indicadores de
desempenho, de maneira independente da Plataforma de Coleta de Métricas (PCM)
provida pela Estrutura de Governança do Open Finance;
V - as instituições consumidoras das APIs devem registrar os tempos de
resposta das APIs que consomem para envio à PCM. Nelas, a medição do tempo de
resposta de cada requisição deve iniciar no momento antes da requisição ser feita e deve
terminar após o último byte ser recebido, antes de qualquer processamento;
VI - o valor do tempo de resposta a ser considerado para uma requisição é
o valor reportado pelo consumidor da API;
VII - na falta de informações dos consumidores, serão utilizadas as
informações dos provedores para o cálculo do SLA de desempenho; e
VIII - a Estrutura de Governança do Open Finance deverá disponibilizar
indicadores adicionais para monitoramento e aprimoramento do ecossistema, que não
terão, nesse momento, um SLA mínimo, tais como:
a) percentil 95 do tempo de resposta somente de requisições com status code 2XX;
b) percentil 95 do tempo de resposta - provedor - deve considerar todas as
requisições fornecidas pelo provedor das APIs, mesmo quando houver diferença entre as
informações entre provedor e consumidor;
c) percentil 95 do tempo de resposta - consumidor - deve considerar todas as
requisições fornecidas pelos consumidores das APIs, mesmo quando houver diferença
entre as informações entre provedor e consumidor;
d) índice de paridade - percentual do número de requisições no status
"PAIRED" em relação ao total; e
e) média do tempo de resposta até P95 - média do tempo de resposta de
todas as requisições com tempo de resposta menores que o valor do P95.
5.3.3 Aferição do desempenho para fins do processo de monitoramento
Considerando que o Manual de Monitoramento do Open Finance estabelece
que o período de apuração do desempenho é mensal, assim que o mês de referência se
encerrar, a Estrutura de Governança do Open Finance deve verificar se os endpoints das
APIs das instituições participantes atenderam aos SLAs do desempenho definidos na
seção anterior deste manual.
Para fins do processo de monitoramento, considera-se que um endpoint está
em conformidade caso tenha respeitado o SLA do desempenho em pelo menos 90% dos
dias do mês de referência, arredondando-se para o número inteiro mais próximo, desde
que o valor do P95 dos demais dias não tenha sido superior ao SLA do desempenho
aumentado em 20%.
Por exemplo:
I - em um mês de 30 dias, em que um endpoint de alta frequência tenha
apresentado valor de P95 inferior a 1.500ms em 27 dias e, nos demais dias, tenha
apresentado valor de P95 entre 1.500ms e 1.800ms (1.500ms * 1,2 = 1.800ms), o endpoint
está em conformidade para fins do processo de monitoramento naquele mês; e
II - em um mês de 31 dias, em que um endpoint de alta frequência tenha
apresentado valor de P95 inferior a 1.500ms em 28 dias e, nos demais dias, tenha
apresentado, em pelo menos um dos dias, valor de P95 superior a 1.800ms (1.500ms *
1,2 = 1.800ms), o endpoint não está em conformidade para fins do processo de
monitoramento naquele mês.
5.4 Disponibilidade
5.4.1 Cálculo da disponibilidade
A disponibilidade dos endpoints das APIs do Open Finance será calculada
empiricamente, baseada na monitoração de requisições válidas. Serão consideradas
"requisições válidas" as requisições que retornam status code da faixa 2XX, 5XX, igual a
408 ou igual a 422. As requisições válidas podem ser divididas em "requisições válidas
com sucesso" - com status code na faixa 2XX ou igual a 422 - e "requisições válidas com
erro" - com status code na faixa 5XX ou igual a 408.
A disponibilidade pontual (t) será calculada como a fração do total de
requisições válidas que cada endpoint recebe e as que ele processa com sucesso a cada
intervalo de 1 minuto. Os intervalos de minuto deverão ser calculados do segundo zero
(0s:000ms) até o segundo 59 (59s:999ms). 1_BCB_30_001
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: 1_BCB_30_002
Dessa forma, obtém-se o indicador percentual para cada janela de tempo de
1 minuto. Cada período de 1 minuto será classificado como "disponível" ou
"indisponível". Se a "disponibilidade pontual" da janela de tempo ficar abaixo de 95%
isso indicará que ela será considerada como "indisponível", caso contrário será
"disponível".
Períodos que não tenham requisições válidas são considerados "indefinidos"
e são desconsiderados para cálculo da disponibilidade. 1_BCB_30_003
A disponibilidade diária será calculada baseada nas informações das
disponibilidades pontuais.
1_BCB_30_004
Por exemplo, considerando um dia em que houve requisições válidas em
1.390 das 1.440 faixas de 1 minuto possíveis (1 dia = 24h * 60min= 1.440 faixas de
horário) para um endpoint específico "x" de versão 1, e dos quais 30 períodos tiveram
a disponibilidade menor que o limite de disponibilidade definido (95%), a
Disponibilidade Diária de "x" v1 será igual a: 1_BCB_30_005
A disponibilidade longa deverá ser calculada diariamente como média móvel
das disponibilidades dos últimos noventa dias corridos, considerando somente os dias
em que a disponibilidade diária pode ser calculada (teve pelo menos uma
disponibilidade pontual diferente de "indefinido"). Ou seja, caso nos últimos noventa
dias tenhamos dois dias calculados como indefinidos, a média deve ser calculada
considerando somente as 88 disponibilidades válidas.
A aferição mensal deve considerar a disponibilidade longa do último dia do
mês de referência.
5.4.2 SLA da disponibilidade
Cada um dos endpoints das APIs categorizadas como "Dados Abertos",
"Dados Cadastrais e Transacionais", "Relatórios e Métricas", por versão, e os endpoints
das APIs de "Segurança" "/register" e "/token", deverão satisfazer os requisitos
mínimos de disponibilidade abaixo:
I - disponibilidade diária (calendário): 95%; e
II - disponibilidade longa (média móvel de 90 dias), medida diariamente:
99,5%.
As APIs classificadas como "Serviços de Iniciação de Pagamentos" seguem o
definido na regulamentação do Pix.
Informações adicionais:
I - as medições devem ser feitas todos os dias, em todas as faixas de 1
minuto disponíveis, iniciando na primeira faixa (00:00:00-00:00:59) e terminando na
última faixa (23:59:00-23:59:59), considerando o horário de Brasília;
II - as medições de disponibilidade devem ser feitas para cada versão major
dos endpoints em produção. Por exemplo, em períodos de convivência o endpoint de
v1/resources poderia estar disponível no mesmo período em que o endpoint de
v2/resources estaria também disponível. É importante que suas disponibilidades sejam
calculadas de maneira independente;
III - as instituições provedoras devem gerar e acompanhar seus indicadores
de disponibilidade, de maneira independente da Plataforma de Coleta de Métricas
(PCM) provida pela Estrutura de Governança do Open Finance;
IV - o status code a ser considerado para uma requisição é o valor
reportado pelo consumidor da API;
V - na falta de informações dos consumidores, serão utilizadas as
informações dos provedores para o cálculo do SLA de disponibilidade;
VI - a indisponibilidade programada não exime o cálculo da disponibilidade
no período apurado;
VII esta subseção não se aplica às APIs de "Webhook";
VIII - a disponibilidade de endpoints que não tenham requisições válidas no
período apurado será considerada "indefinida", não estando sujeita a um SLA; e
IX - a Estrutura de Governança do Open Finance deverá disponibilizar
indicadores adicionais para monitoramento e aprimoramento do ecossistema que não
terão, nesse momento, um SLA mínimo, tais como:
a) disponibilidade calculada do ponto de vista do provedor da API - deve
considerar as informações fornecidas pelo provedor das APIs; e
b) disponibilidade calculada do ponto de vista do consumidor da API - deve
considerar as informações fornecidas somente pelos consumidores das APIs,
classificadas no PCM como "PAIRED" ou "SINGLE".
5.5 Timeout
Padronização do timeout de tempo de resposta do provedor e do tempo de
resposta do consumidor em quinze segundos.
As requisições que excederem o limite de timeout do provedor deverão ser
respondidas com o status code HTTP 504 (Gateway Timeout).
Brasília, 20 de dezembro de 2024.