Comparação de Páginas

Controle de versão

Introdução e Objetivos

Esta métrica visa monitorar e assegurar que as se os endpoints das 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 Financeestão cumprindo os SLAs de disponibilidade, estabelecidos no Manual de APIs do Open Finance.

Considerando que a disponibilidade dos endpoints das APIs do Open Finance será calculada empiricamente, baseada na monitoração de requisições válidas.

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 seguintede Disponibilidade das APIs mede a capacidade de uma API estar acessível e funcionando corretamente para os desenvolvedores e usuários finais.

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.

As medições devem ser realizadas de maneira independente para cada versão "major" dos endpoints em produção.

O status code a ser considerado para uma requisição é o valor reportado pelo consumidor da API, ou seja, o valor reportado pela instituição iniciadora de pagamentos nas APIs de “Serviços de Iniciação de Pagamentos” e o valor reportado pela receptora de dados no caso de APIs de "Dados Cadastrais e Transacionais".  

Na falta de informações dos consumidores, serão utilizadas as informações dos provedores para o cálculo do SLA de disponibilidade, ou seja,  o valor reportado pela instituição detentora de contas nas APIs de "Serviços de Iniciação de Pagamentos", e o valor reportado pela instituição transmissora de dados no caso de APIs de "Dados Cadastrais e Transacionais".

A indisponibilidade programada não exime o cálculo da disponibilidade no período apurado.

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.

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, ou seja, ou seja os participantes têm metas de índice de disponibilidade diferentes, de acordo com as suas categorias de participação no arranjo:

A conformidade é avaliada mensalmente, verificando se os endpoints das APIs das instituições participantes atenderam aos SLAs de disponibilidade. A aferição mensal deve considerar a disponibilidade longa do último dia do mês de referência.

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á:

Para as APIs de “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":

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

• Disponibilidade longa: Cálculo monitoramento da 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.

Para as APIs de “Serviços de Iniciação de Transação de Pagamentos” monitoramento mensal de acordo com a regulamentação do Pix, .

Aspectos Técnicos

O monitoramento inclui várias etapas:

• Agrupar por minuto e contar as requisições com sucesso e erro

Filtragem

• organisationid = r.clientorgid OU (organisationid = serverorgid E status = 'UNPAIRED')

• statuscode = 2xx, 5xx, 408 ou 422

• status ≠ “PAIRED_INCONSISTENT”

Agrupamento

• serverorgid

• endpoint

• dia

• minuto

Contar as requisições por tipo

total_validas → total de chamadas

success → total chamadas com statuscode  2xx ou 422

error → total chamadas com statuscode 5xx OU 408

• Calcular a disponibilidade do minuto

Para cada minuto, realiza o calculo do percentual de disponibilidade

 disponibilidade_no_minuto = (success / (sucess + errors)) * 100

• Agrupar por dia e calcular o total de minutos disponíveis

Agrupamento

• serverorgid

• endpoint

• dia

Cálculo

total_validas_dia → total de chamadas no dia

total_minutos_disponiveis → total disponibilidade_no_minuto ≥ 95%

total_minutos → total de minutos do dia

• Calcular disponibilidade e conformidade diária, mensal e longa

 Disponibilidade diária

percent_disp_dia = total_minutos_disponiveis / total_minutos

Conformidade diária

percent_disp_dia ≥ 0.95 ?

então “CONFORME” se não “NÃO CONFORME”

Disponibilidade mensal (Iniciação de pagamentos)

percent_disp_mensal = média mensal de percent_disp_dia

Conformidade mensal (Iniciação de pagamentos)

percent_disp_mensal ≥ Categoria de disponibilidade PIX da instituição ?

então “CONFORME” se não “NÃO CONFORME”

Disponibilidade longa

percent_disp_u90d = média dos últimos 90 dias de percent_disp_dia

Conformidade longa

percent_disp_u90d ≥ 0.995 ?

então “CONFORME” se não “NÃO CONFORME”

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:

...

• 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%.

A conformidade para a disponibilidade das APIs depende da conformidade em todos os dias da disponibilidade diária das APIs e da sua disponibilidade longa, considerando o último dia do mês de apuração. As APIs de “Serviços de Iniciação de Pagamentos” seguem as metas do índice de disponibilidade do arranjo Pix.

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).

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.

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:

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.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:

...

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.

...