Dia Oficial

Diário Oficial da União · 01/03/2024 · pág. 106

DOU 01/03/2024 - Diário Oficial da União - Brasil

Baixar página em PDF · Criar alerta deste tema

O visualizador interativo precisa de JavaScript — baixe a página original em PDF.

TEXTO OFICIAL · ÍNTEGRA

Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001, que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil. Este documento pode ser verificado no endereço eletrônico http://www.in.gov.br/autenticidade.html, pelo código 05152024030100106 106 Nº 42, sexta-feira, 1 de março de 2024 ISSN 1677-7042 Seção 1 headers da resposta. Essa definição objetiva permitir um adequado rastreamento de divergências que podem ocorrer entre instituições transmissoras e receptoras de dados associadas ao limite operacional. 5.3 Desempenho Deverá ser medido o tempo de resposta de cada requisição, ou seja, o tempo transcorrido entre o recebimento de uma requisição que não ultrapassa os limites de tráfego e o momento em que a requisição é completamente respondida. Adicionalmente, esta medição deverá ser feita de maneira que os tempos medidos sejam os mais próximos possíveis dos tempos de resposta experimentados por quem fez a requisição. A medição na instituição provedora da API deve iniciar quando a requisição é recebida pelo gateway e deve terminar após o último byte da resposta desta requisição ser enviado. 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 Responsável pela 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 Responsável pela 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 Responsável pela 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): Disponibilidade pontual (t) = (Total de requisições válidas com sucesso)/(Total de requisições válidas com sucesso + Total de requisições válidas com erro). 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: Disponibilidade pontual (t = 11:34:00 - 11:34:59) = 255/(255 + 4) = 98,45%. 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. Assim, considera-se, em relação à disponibilidade, que: I - disponível, se disponibilidade pontual (t) ³ 95%; II - indisponível, se disponibilidade pontual (t) < 95% III - indefinido, se disponibilidade pontual (t) = div/0. A disponibilidade diária será calculada baseada nas informações das disponibilidades pontuais: Disponibilidade diária = (Número de períodos disponíveis)/(Número de períodos disponíveis + Número de períodos indisponíveis). 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: Disponibilidade diária (2023-10-16) = 1360 / (1360 + 30) = 97,84%. 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 Responsável pela 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 Responsável pela 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 código de status HTTP 504 (Gateway Timeout). Brasília, 29 de fevereiro de 2024. Ministério Público da União MINISTÉRIO PÚBLICO DO DISTRITO FEDERAL E TERRITÓRIOS PROCURADORIA-GERAL DE JUSTIÇA COORDENADORIAS DAS PROMOTORIAS DE JUSTIÇA PORTARIA Nº 11-6ª PROREG, DE 7 DE MARÇO DE 2023 O MINISTÉRIO PÚBLICO DO DISTRITO FEDERAL E TERRITÓRIOS, pela 6ª Promotoria de Justiça Regional de Defesa dos Direitos Difusos, com fundamento no artigo 129, inciso I, da Constituição Federal, artigo 80, §10, da Lei 7.347/1985 e artigo 70, inciso I, da Lei Complementar no 75/1993 e artigos 10 e 20, ambos da Resolução no 78/2007 do CSMPDFT; Considerando a atribuição das Promotorias Regionais de Defesa dos Direitos Difusos - PROREG, no âmbito da região administrativa em que estiver sediada, nos termos do artigo 11, inciso X, da Resolução n: 90/2009 - CSMPDFT, no sentido de instaurar inquéritos civis e procedimentos de investigação preliminar destinados à propositura de ações de responsabilidade por atos de improbidade administrativa de suas respectivas atribuições, bem como promover as ações e medidas cabíveis; e Considerando as diligências a serem realizadas, notadamente a análise de vínculos entre os servidores nomeados para cargos comissionados e agentes políticos; resolve: Converter o presente Procedimento Preparatório em INQUÉRITO CIVIL PÚBLICO, para apurar supostos atos de nepotismo realizados pelos gestores da Administração Regional de Ceilândia e da Administração Regional de Sol Nascente no ano de 2021 e 2022. Registre-se no NEOGAB e anote-se como interessados a Administração Regional de Ceilândia e a Administração Regional de Sol Nascente. Após a devida autuação desta Portaria, promovidas as comunicações, publicações e anotações de estilo (art. 20 da Resolução no 66/2005), aguarde-se a elaboração de pesquisa completa pelo CI/MPDFT, ainda em confecção (ID: 9222208). LÍVIA CRUZ RABELO Promotora de Justiça