Medindo a satisfação dos consumidores de suas APIs

Olá, pessoal! Eu sou o Marcelo Dias, sou arquiteto de soluções aqui na Sensedia. Eu estou aqui com o Vinícius hoje, que é um desenvolvedor aqui da área de soluções da Sensedia também. E hoje a gente vai trazer aqui para vocês um conteúdo sobre como medir a satisfação dos consumidores das suas APIs, através da prática de implementação de objetivos de níveis de serviço, os SLOs.

Eu gosto sempre de iniciar minhas apresentações com uma frase que consiga transmitir o objetivo que eu estou tentando passar nesse conteúdo. E para essa de hoje eu escolhi essa do Peter Drucker, que é considerado o pai da administração moderna, onde ele diz que o que pode ser medido pode ser melhorado. E esse é o objetivo desse conteúdo que a gente está trazendo aqui para vocês: como que eu posso aqui definir e implementar alguns indicadores com base em métricas das suas APIs? Que você possa definir objetivos que representem os diferentes níveis de satisfação dos clientes, dos consumidores dessas APIs.

Antes de eu começar aqui propriamente dito, falar dos conceitos de indicadores e objetivos de níveis de serviço, eu vou comentar rapidamente aqui sobre o papel das APIs nas nossas aplicações, na exposição de capacidades de negócio. Então as APIs, inclusive depois eu até vou deixar aqui disponível na descrição do vídeo um link para um outro conteúdo que a gente gerou sobre modernização de aplicações, onde eu explico um pouco mais esse e outros conceitos. Mas só comentando aqui rapidamente, as APIs exercem um papel fundamental na exposição das capacidades de negócio de uma empresa, de como eu exponho as minhas funcionalidades para permitir diferentes níveis de integração, seja numa estratégia de integração mais interna, para melhorar a agilidade na integração das minhas aplicações, do RP com o meu CRM, seja através de uma integração mais restrita, onde eu tenho contratos mais formais estabelecidos para integrar com os meus parceiros, ou até mesmo uma estratégia mais pública, onde eu estou expondo as minhas capacidades de negócio através de APIs para que outros parceiros de negócio, outros desenvolvedores, possam construir soluções usando as minhas capacidades de negócio.

Aqui é um conceito bem bacana, introduzido pelo Gartner, sobre composable enterprise, ou também conhecido como composable business, onde ele diz que é uma organização que entrega resultados de negócio e se adapta ao ritmo de mudanças do mercado. E como essas organizações fazem isso? Através da combinação de capacidades de negócio, que o Gartner chama de PBC, package of business capabilities. O que são esses PBCs? É uma coleção de serviços e esquemas de dados que suportam uma determinada capacidade de negócio, bem reconhecida pelos usuários de negócio. E a exposição dessa capacidade para consumo por outras aplicações, por parceiros, por outros consumidores, é feita através de APIs e também através de canais de eventos. Então aí a gente consegue ver a importância das APIs na integração dos nossos sistemas em diferentes estratégias, em diferentes estilos de plataformas.

Bom, agora que eu comentei aqui rapidamente sobre esse papel das APIs, vamos falar aqui um pouco sobre alguns conceitos relacionados a indicadores e objetivos de níveis de serviço. Quando a gente fala em objetivos de níveis de serviço, os SLOs, a gente também tem aqui esses outros dois termos que estão relacionados:

SLA: que é o acordo de nível de serviço, que é o acordo que você faz com seus clientes, usuários dos seus serviços, os consumidores no contexto das suas APIs.

SLOs: que são os objetivos propriamente ditos, que é um objetivo interno que a sua equipe deve buscar para não impactar o acordo que foi feito com seus clientes, com os consumidores das suas APIs.

SLIs: que são os indicadores de níveis de serviço, que é a medida real do comportamento do seu serviço, geralmente feita através

Aqui nesse slide a gente tem uma apresentação, um diagrama bem bacana, que mostra muito bem esse cenário. Como que eu uso essa técnica, que é essa prática, para medir a

satisfação dos consumidores das minhas APIs? Aqui eu estou falando bastante no contexto de APIs, mas isso aqui também se aplica para outras camadas aqui da sua aplicação.

Então aqui nesse exemplo a gente tem um indicador, um SLI, que é o tempo médio de resposta para submeter um pedido de compra em milissegundos. Eu tenho uma representação ali, numa linha ali na horizontal que representa esse meu indicador. Eu tenho um objetivo estabelecido e mais à frente aqui eu vou explicar algumas técnicas, alguns passos que a gente pode seguir para ajudar a encontrar um objetivo ideal para o seu serviço. Aqui nesse exemplo a gente já tem um valor determinado aqui. Eu tenho um objetivo que esse meu serviço tenha um tempo médio de resposta de até 700 milissegundos. E o acordo, geralmente eu tenho ali um espaço, um valor um pouco maior do que o meu objetivo. O acordo real que eu vou fazer com o meu usuário final, com o consumidor da minha API.

Então através dessa estrutura, dessas definições, eu consigo ter todo um mecanismo aqui para medir a satisfação de quem vai consumir as minhas APIs. Tem um indicador claro, tenho um objetivo definido que eu devo buscar. Então eu consigo entender que enquanto eu estou dentro do meu objetivo, eu posso considerar que o meu usuário está satisfeito. Eu estou até excedendo a expectativa daquilo que foi combinado. Eu tenho o meu acordo, eventualmente mesmo se eu violar meu objetivo, mas estiver dentro do meu acordo, eu posso ter que tomar alguma ação para melhorar a qualidade do meu serviço. Mas eu estou dentro do que foi combinado, então ainda estou em uma situação favorável. E se eu estiver acima desse parâmetro que eu defini do meu acordo, aí eu estou em uma situação onde eu posso entender que o meu usuário está insatisfeito. E eu preciso ter uma certa prioridade para agir e melhorar o comportamento do meu serviço. Ou até mesmo, dependendo do caso, eu posso ter até mesmo uma penalidade contratual. Quando eu exceder, violar o acordo que foi feito.

Ao longo aqui da apresentação eu vou mostrar algumas sugestões de passos de como definir e implementar esses indicadores e os objetivos. Aqui só complementando um pouco, a prática de SLO, de Objetivo de Nível de Serviço, é um dos princípios que compõe o SRE, o Site Reliability Engineering. Que é um conjunto de princípios e práticas que visa melhorar a confiabilidade do seu software, da sua aplicação, dos seus serviços. Essa frase aqui é um exemplo bem bacana que eu gosto de usar do fundador do SRE do Google, do Benjamin Loss, onde ele diz que o SRE é o que acontece quando você pede a um engenheiro de software que desenhe um time de operações. O que ele quer dizer com isso? Quando você pede para um engenheiro, um desenvolvedor, para ele se preocupar com essas práticas de confiabilidade, a tendência é que você tente automatizar a aplicação dessas práticas, tornar isso parte do seu software. Você passa a tratar aspectos de confiabilidade como features da sua aplicação. Você vai inclusive até incorporar tarefas no seu backlog, priorizar isso no seu processo de desenvolvimento.

Bom, agora que eu introduzi aqui rapidamente sobre alguns conceitos desses termos de SLI, de SLO, SLA também, eu vou mostrar aqui agora alguns passos, algumas recomendações, algumas sugestões de passos aqui que você pode seguir para conseguir especificar e implementar os seus indicadores. Quais seriam esses passos?

Um primeiro passo seria você obter uma visão geral da sua arquitetura. Você conseguir entender quais são os componentes que compõem a minha arquitetura, quais são as camadas, principais ferramentas e plataformas, tecnologias. Tudo aquilo que compõe o meu ecossistema relacionado àquela aplicação, aquela capacidade de negócio ou conjunto de capacidades de negócio.

Aqui está um exemplo bem simples, que está ilustrado aqui para essa apresentação. A gente vai usar aqui como um exemplo até para as próximas etapas. Mas você pode usar outros padrões que você geralmente utiliza, como por exemplo uma anotação ML, um modelo C4 ou até mesmo um diagrama de forma livre mesmo para mapear a sua arquitetura. Mas é importante ter esse conhecimento, essa informação. Quais são os componentes, quais são as camadas, quais são as dependências, para eu conseguir entender quais partes da minha arquitetura eu preciso definir os indicadores, a forma como eu vou coletar essas informações. Então, conseguir ter essa clareza para depois conseguir direcionar as demais etapas do

Como uma próxima etapa, qual seria aqui uma sugestão? Você identificar quais são as capacidades de negócio suportadas por aquela aplicação. Isso é extremamente importante porque a partir dessas capacidades de meu processo.

negócio que a gente vai seguir com as próximas etapas de entender quais são os indicadores que fazem sentido, começar a monitorar isso e definir os meus objetivos. Aqui é um exemplo bem simples, dentro desse contexto que a gente está usando como um exemplo. Uma capacidade de negócio de submeter um pedido de compra. Eu posso ter outras capacidades ali, eu preciso entender quais são as funções de negócio que eu estou suportando para aquela aplicação, que é isso que vai direcionar ali a melhor forma de medir a satisfação de quem consome essas capacidades de negócio.

E numa próxima etapa, é uma etapa relativamente simples, mas extremamente importante e às vezes até difícil de se definir. Ela é simples, mas existe uma complexidade de se chegar nessa definição. É você definir o conceito de disponibilidade das capacidades de serviço. Vou pegar aqui aquele exemplo da submissão do pedido de compra. O que significa, na perspectiva dessa capacidade de negócio, estar disponível? Basta que o processo ali no sistema operacional esteja no ar? Basta que o servidor esteja ligado? Basta que a minha API responda ali um status 200? Às vezes isso não é muito claro. Se você questionar para diferentes perfis envolvidos na sua aplicação, um analista de negócio, um engenheiro de software, um analista de suporte de operações, se você não tiver essa definição clara, cada um pode ter um entendimento diferente do que significa estar disponível. Então a ideia aqui dessa etapa é você ter um texto claro. Não precisa ser muito técnico nesse nível. Depois a gente vai especificar no SLI a forma técnica de como atingir esse conceito. Mas o que significa estar disponível? Aqui é um exemplo de como a gente pode fazer isso. Os pedidos de compra são recebidos e processados com sucesso em 99% do tempo, desde que existam fundos e não existam restrições financeiras ou de negócio. É um texto simples, mas que vai direcionar todas as demais etapas. Então eu já vou ter que me atentar. Tem uma questão relacionada a restrições financeiras ou de negócio. Então eu preciso ver nos meus indicadores como eu atinjo essa condição. Quais subsídios eu tenho para extrair métricas que me representam essa informação. Então é extremamente importante a gente ter essa visão aqui clara, um texto simples, em português claro e compartilhado e entendido por todos os diferentes perfis envolvidos no desenvolvimento e suporte daquela aplicação, daquele serviço.

E como uma próxima etapa, uma vez que eu já entendi a minha arquitetura, identifiquei minhas capacidades de negócio, defini um conceito de disponibilidade para cada uma dessas capacidades de negócio, eu vou começar a definir os indicadores que fazem sentido para começar a medir a satisfação dos meus consumidores. Então aqui alguns exemplos:

Um indicador de disponibilidade, onde eu olho para a proporção de pedidos de compra válidos.

Depois eu preciso especificar, implementar o que significa para a gente um pedido de compra válido.

Latência, o tempo médio de resposta de pedidos de compra válidos.

E um indicador aqui, um exemplo de qualidade: uma proporção de pedidos de compra finalizados com sucesso.

Então aqui alguns exemplos simples para a gente explorar aqui na nossa apresentação. É importante ressaltar aqui também, no contexto de APIs, eu citei alguns exemplos de indicadores de qualidade, de disponibilidade, de latência, que são alguns tipos de SLI bem comuns quando se fala no contexto de APIs, que são indicadores de requisição e resposta. Mas existem outros tipos de indicadores, de SLIs, que também podem ser implementados, como de processamento de dados, para verificar a cobertura do dado, o quão atualizado o dado está, no caso de rotinas de replicação de dados, por exemplo. E até mesmo indicadores de armazenamento, que focam mais na durabilidade daquele dado. E é também importante ressaltar aqui que a gente tem diferentes formas de coletar esse dado. Então eu posso coletar esse dado do meu indicador a partir de métricas a nível da aplicação. Eu posso ter testes sintéticos, eu tenho algumas transações específicas para realizar testes no meu ambiente produtivo, identificar esse comportamento da minha API, mas sem afetar o dado real de produção. São testes específicos para você coletar esse tipo de métricas. Posso analisar logs do servidor, seja um servidor de aplicação ou servidor, por exemplo,de uma plataforma de APIs que suporta a camada de APIs da sua aplicação. Pipelines de processamento de dados, métricas de infraestrutura de front-end. Métricas de processamento de dados, métricas de infraestrutura de front-end, como por exemplo, métricas de um load balancer, que pode também ser utilizada para implementar alguns dos seus indicadores, dos seus SREs e até mesmo a instrumentação do lado do cliente. Então, por exemplo, uma aplicação móvel, onde você pode implementar uma lógica que vai calcular algumas métricas quando ele consumir alguns serviços. Dessa forma, você vai estar o mais próximo possível do usuário final, aquela métrica que você está coletando.

Mas o importante é entender que vão ter diferentes camadas para se coletar essa informação e diferentes estratégias, seja como log, como métricas, instrumentando ou testes pontuais.

E aqui um exemplo de como seria uma especificação do meu indicador, do meu SLI. Pegando esse mesmo exemplo que a gente estava trabalhando aqui do pedido de compra, eu tenho a minha capacidade de negócio, que é submeter um pedido de compra, um tipo de SLI que eu estou verificando, que é de requisição e resposta, mais focado em disponibilidade. A minha estratégia de medição, eu vou coletar esse dado nessa métrica a partir de logs do servidor, no caso ali o meu servidor de APIs, minha plataforma de APIs que está suportando uma camada específica da minha arquitetura.

A especificação do meu SLI, que é o mesmo exemplo lá anterior, que é a proporção de pedidos de compra válidos e a implementação, como que eu implemento esse SLI. Aqui é importante, essa parte de implementação, lembrar do conceito de disponibilidade, principalmente para esse tipo de SLI. Então eu preciso me atentar a todos aqueles detalhes que foram ditos lá na instrução, que descrevia o conceito de disponibilidade, que citava ali os pedidos de compra com sucesso, mas também ali a questão de restrições financeiras ou restrições de negócio que envolvia ali o conceito de disponibilidade.

E como que eu especifico, implemento esse tipo de SLI? Nesse nosso exemplo aqui, até reforça que é a importância de você manter uma estratégia adequada de APIs, uma API bem estruturada, com os recursos e as operações bem definidos, explorar corretamente ali, aplicar as melhores práticas de uma API REST, explorar corretamente os métodos HTTP, os códigos de resposta HTTP, tentando procurar sempre definir uma estratégia adequada que vai representar corretamente ali as suas capacidades de negócio.

E com isso a gente consegue extrair mais facilmente os indicadores. Então, nesse meu exemplo aqui, o que nós temos? Como que eu implemento esse indicador? Eu tenho ali a proporção de requisições de pedido de compra, que é o método POST da minha API de orders, no path ali o orders, concluído com sucesso, HTTP status 201. Esse é o status que a minha API, na estrutura que ela foi desenvolvida, que ela foi pensada, que ela está documentada, que ele retorna para mim quando eu submeto um pedido com sucesso. Ela vai me retornar um código 201. Ou com alguma exceção de negócio. Lembrando ali, aquele link com o conceito de disponibilidade. Que é o status code aqui 422. Que na documentação da minha API, na forma como ela foi desenvolvida, isso representa para mim uma exceção de negócio, onde pode representar um saldo insuficiente, uma restrição financeira, ou até mesmo ali um indício de fraude. Então é um outro tipo de código que eu preciso olhar para o meu conceito de disponibilidade. Além de recusas relacionadas à segurança, que eu olho ali para códigos 401 e 403.

Esse ponto aqui é importante, por quê? Eu preciso olhar para todos esses tipos de códigos, aqui entendendo a arquitetura da minha aplicação, a estrutura da minha API. Eu vou olhar para todos esses tipos de códigos para dizer que a minha API, esse meu serviço que eu estou provendo, ele está disponível. Então, se ele respondeu 201, o pedido foi submetido com sucesso, está disponível. Se ele respondeu com uma exceção, 422, é uma exceção de negócio, está prevista. Eu recebi a requisição, eu entendi ela, eu processei, mas ele caiu em alguma restrição de negócio. Então eu respondi, o serviço está disponível, mas ele caiu em uma restrição de negócio. Ou por questões de segurança, o meu serviço está disponível. O consumidor da API que não me passou as credenciais corretas, ou elas não estão válidas, ou expirou algum token de acesso. Então o serviço está disponível.

Então eu preciso olhar para todos esses detalhes para conseguir definir corretamente cada um dos meus indicadores. Os demais outros códigos, eu posso entender que se ela retornar algum código diferente desses que eu mencionei aqui, eu vou considerar o serviço como não disponível. Então vai entrar no meu cálculo de disponibilidade. Uma vez que eu identifiquei,mapeei minha arquitetura, identifiquei minhas capacidades de negócio, defini um conceito de disponibilidade e defini e especifiquei os meus indicadores. Disponibilidade e definir e especifiquei os meus indicadores, meus séries. O próximo passo agora seria eu definir, iniciar minha edição e definir os objetivos e começar a alertar esses objetivos. Como que eu faço isso? A primeira etapa para isso seria você estabelecer uma baseline. Então, a partir do momento que eu já defini e implementei os meus requisitos, eu vou começar a coletar dados em cima disso. Vou iniciar minha medição e vou analisar isso. Vou começar a ver na linha do tempo, durante alguns dias, durante algumas semanas ou meses, o que fizer mais sentido para você conseguir analisar. Eu vou entender todo o comportamento do meu serviço com base nos indicadores que eu implementei. Então, vou ter ferramentas adequadas ali, métricas, dashboards, onde eu vou conseguir analisar e estudar o comportamento da minha API.

E o próximo passo após isso seria definir o objetivo propriamente dito. Vamos supor aqui nesse exemplo que eu implementei meu indicador, comecei a minha medição e entendi que aquele comportamento está adequado. Vamos partir do suposto aqui que o meu comportamento está adequado. Eu considero que com o meu comportamento atual, o meu consumidor está satisfeito. Se ele não estiver, vou ter que tomar algumas ações para melhorar o comportamento do meu serviço antes mesmo de se definir um objetivo. Mas vamos pegar nesse exemplo aqui que identifiquei com base em dados históricos que o comportamento está adequado. O que eu posso concluir em cima disso? O tempo médio aqui de resposta, pegando o exemplo aqui de um indicador de latência, o tempo médio de resposta do meu serviço de pedidos, quando ele conclui com sucesso ou com alguma exceção de negócio, que são aqueles códigos que eu mencionei, o 201 e o 422, ele sempre está ali acima de 600 milissegundos, mas sempre está abaixo de 700 milissegundos. Eu consigo concluir que é algo que eu consigo cumprir ao longo do tempo. Eu tenho ali os outros códigos também, a parte de recusa, de segurança, que estão com um tempo mais baixo ali, mas vamos nos atentar mais àqueles dois primeiros ali por enquanto. Então eu posso concluir que, para mim aqui, para o meu cenário, um objetivo aqui que faça sentido, seria de repente ali 700 milissegundos. Então se eu colocar um objetivo ali de 650 milissegundos, eventualmente eu vou violar esse objetivo. Então vou colocar ali um objetivo, supondo aqui novamente, supondo que esse comportamento é aceitável para o seu usuário, então vamos trabalhar com esse objetivo e tentar buscar que sempre o meu serviço fique dentro dessa faixa, desse threshold ali.

E depois, como ficaria aqui o nosso indicador, a especificação desse L.I. complementando com o objetivo? Então eu tenho aqui um exemplo onde eu coloco um objetivo, que 90% das requisições, esse tempo pode variar, a ideia é que você discuta com a sua equipe de desenvolvimento, de operações e até mesmo com a equipe de negócio, para chegar aqui nesse objetivo, analisando os dados, as métricas do comportamento do seu serviço. E você diga ali que 90% das requisições de pedido de compra válidos, respondidas em até 700 milissegundos, com base nos dados históricos, dados reais, nos últimos 28 dias, ou algum outro período que faça sentido para você.

E após isso, uma vez que eu defini o meu objetivo com base em dados, em métricas, indicadores bem implementados, agora eu posso configurar alertas em cima disso. Como que eu vou fazer isso? Aqui eu voltei de novo aquela imagem, que representa bem nesse contexto de medir a satisfação dos consumidores, onde eu tenho aqui novamente o meu SLI, que é o tempo médio de resposta para submeter um pedido, em milissegundos. O meu objetivo de 700 milissegundos, onde eu vou entender que o meu usuário está satisfeito, ou eventualmente estou até superando a expectativa se eu estiver abaixo desse objetivo. E lembrando que eu defini esse objetivo com base em dados reais, em métricas reais, e eventualmente definindo um acordo. O acordo geralmente eu tenho ali um parâmetro um pouco maior que eu vou definir com o meu usuário final. Nesse exemplo aqui estou com 1 segundo, mas poderia ser ali 900 milissegundos, 800 milissegundos. Aqui é só um exemplo para ilustrar essa situação. O objetivo é algo que eu vou buscar internamente para não afetar o meu acordo. Eventualmente se eu violar o meu objetivo, mas ainda estiver dentro do meu acordo, ainda estou em uma situação favorável, como eu mencionei lá anteriormente. E acima disso eu já considero que o meu cliente está insatisfeito, ou posso até mesmo estar sofrendo alguma penalidade. Eu tendo esses parâmetros bem definidos, o meu indicador está implementado com base no meu conceito de disponibilidade, com base nas minhas capacidades denegócio, defini um objetivo com base em métricas reais, defini um acordo com base nessas métricas, eu começo a configurar os alertas em cima desses parâmetros. Aqui nesse exemplo, estou mostrando uma configuração de alerta em cima do meu objetivo. Dependendo do cenário, eu posso ter outros níveis de alerta. Posso ter um alerta para um parâmetro ali um pouco antes do objetivo para me sinalizar antes mesmo de violar o objetivo, mas a ideia é que não seja também tão agressivo, senão você vai ficar gerando muitos alertas, muitas notificações de forma desnecessária. A tendência é acabar ignorando ali essas notificações em função do excesso de notificações. Então a gente precisa ser mais preciso nesse trabalho. Ou até mesmo aqui definir outros alertas com diferentes níveis de criticidade. Vou ter um alerta que violou o objetivo, vou ter um alerta quando eu estiver próximo de violar o meu acordo, um alerta com nível mais crítico, um alerta ali extremamente crítico quando eu violar o meu acordo. Então posso configurar aqui diferentes níveis de alerta de acordo com a criticidade. Mas tudo isso estruturado ali por indicadores bem definidos, conceitos de disponibilidade, olhando para as capacidades de negócio da sua aplicação e principalmente ali coletando métricas e analisando essas métricas ao longo do tempo.

E como uma última etapa aqui desse processo, é importante ressaltar que é sempre um processo de melhoria contínua. Eventualmente eu vou ter ali novas features na minha aplicação, vou expor ali novas capacidades de negócio, então preciso rever o desenho da minha arquitetura, identificar ali uma nova capacidade. Posso refinar ali e rever o meu conceito de disponibilidade para ver se eu preciso fazer algum tipo de ajuste. Refinar os meus SLIs para ver se eu estou cobrindo todas as condições necessárias, ou até mesmo implementar novos SLIs, fazer uma monitoração contínua das métricas, desses indicadores, que inclusive o comportamento da minha API pode se alterar ao longo do tempo, eu precisar rever isso e também rever os objetivos. O meu objetivo não pode ser tão agressivo, mas também não pode ser tão flexível. Então a ideia é que eu passe a revisar esses itens aqui ao longo do tempo. E da mesma forma que os alertas, eu vou configurando novos alertas, refinando ali os alertas de acordo com a mudança da nossa arquitetura, das condições e novos requisitos que eu venha a implementar.

Bom, a ideia agora é a gente mostrar um exemplo prático de como implementar isso. Esse exemplo vai estar focado aqui na camada de APIs da nossa solução, vou usar esse mesmo exemplo aqui de API de pedidos, de pedidos de compra, onde a gente vai demonstrar aqui usando as ferramentas da Sensedia, o API Management, o Analytics e o Flexible Actions, como opções para você criar essa estrutura de indicadores, gerar uma baseline, configurar os seus objetivos e os seus alertas de uma forma mais ágil, de uma forma mais prática e dinâmica. Que também não é interessante você seguir todo esse processo de uma forma burocrática, gerando documentações que vão ser mais estáticas e eventualmente não vão ser atualizadas e vão acabar gerando ali um overhead no seu processo de desenvolvimento. Então aqui a gente vai mostrar um exemplo prático, focando aqui na camada de APIs, de como um ferramental adequado pode agilizar a adoção desse tipo de prática e te auxiliar na medição da satisfação dos consumidores das suas APIs.

Para esse exemplo aqui, como eu comentei, a gente está usando uma API de pedidos, e só reforçando aqui a importância de ter uma estratégia adequada de APIs, explorando todas as melhores práticas de uma API, uma API REST, definindo corretamente ali a estrutura de recursos e operações dessas APIs, explorando ali o uso dos métodos HTTP, definindo corretamente os códigos de resposta que ela pode retornar, seja para sucesso, alguma condição de negócio, os esquemas de dados bem definidos. Então é importante ter uma estratégia adequada, que isso vai facilitar muito a adoção dessa prática e a definição dos diferentes indicadores para você medir o comportamento real da sua API.

Bom, agora eu vou passar aqui a palavra para o Vinícius, que ele vai fazer aqui uma apresentação para vocês aqui na prática, usando aqui as ferramentas da Sensedia, de como a gente pode implementar aqui, usar a ferramenta para identificar esses indicadores e configurar ali os seus objetivos e os seus alertas. Olá pessoal, meu nome é Vinícius, eu sou desenvolvedor do time aqui de soluções, e hoje agora eu vou estar mostrando aqui brevemente um pouco da nossa plataforma para vocês, um pouco do nosso analytics e do nosso Flexible Actions também. Então, nesse primeiro momento a gente estáaqui na parte do manager, na parte de disposição e gerenciamento da nossa API. Então aqui a gente tem a nossa API de pedidos, que a gente fez o uso dele e também um pouco de teste de carga para demonstrar para vocês. gente tem basicamente esses recursos e operações dentro dela. Então é basicamente um post, um get aqui bem simples mesmo.

E aqui embaixo a gente tem a parte do fluxo da nossa API, onde a gente implementou algumas políticas para ter uma definição melhor. Então a gente tem algumas políticas de segurança, de tráfego e também de logs. Então essa é a parte de gerenciamento e exposição das APIs dentro do manager.

E agora a gente vai para uma parte de analytics, para a gente conseguir ter uma visão melhor dessa API, conseguir ver ali qual é o objetivo que a gente tem que definir e também ver como é simples ter essa definição feita pelo analytics da Sensedia. Então nesse primeiro momento aqui a gente tem um gráfico aqui bem racional, então representando aqui a quantidade de chamadas por sucesso e erro da nossa API de pedidos. A gente tem aqui a parte também de um racional pela latência de todas as chamadas dessa API de pedidos. Então não tem a granularidade de get ou post ou até mesmo de status code. Então é um gráfico aqui para a gente medir um racional da nossa API.

Além disso a gente também montou aqui um gráfico para ter essa granularidade, que é possível também aqui no analytics a gente ter gráficos totalmente configuráveis dentro da solução. E expandindo aqui esse gráfico de latência que a gente criou, ele está separado pelos status codes definidos na nossa API. Então também tendo esses status codes aqui definidos bem na nossa estratégia de API, a gente também consegue ter uma utilização de forma bem fácil e prática aqui dentro do analytics.

Então aqui a gente tem a parte dos status codes:

201 - sucesso

422 - referente à nossa regra de negócio

E se a gente observar por aqui, ele não está ultrapassando a faixa de 700 milissegundos. Beleza? E também tem aqui a parte do gráfico separado aqui o total de chamadas por esses mesmos status codes que eu mostrei anteriormente:

201

401

403

422

429

mas só que separado aqui de uma forma bem mais granular. Então essa parte da analytics aqui é uma parte que pode agregar bastante valor na parte de definir esses objetivos e também de definir alguma estratégia para a sua API. Então essa parte está aí para ajudar a definir essas métricas.

Além disso a gente também tem o flexible actions, que seria a parte de alertar caso a gente tenha algum objetivo quebrado. Então é a parte que a gente consegue fazer o monitoramento das nossas APIs dentro do manager e gerar alertas a partir de alguma regra que a gente imponha dentro da nossa estratégia.

Então aqui a gente tem a parte de criação desse alerta. Então eu vou demonstrar aqui como é fácil a criação desse alerta e quais são as possibilidades de criação também. Então o nome aqui é bem simples, o nome é mais para catalogação desse alerta dentro da plataforma. Então eu vou botar um nome referente a como eu vou monitorar, que é pela latência. Vou usar uma tag para fazer a organização melhor desse alerta. Aqui uma classificação que a gente pode ter para esse alerta:

Neutra

Com sucesso

Warning

Crítico

Então eu vou botar aqui que vai ser um alerta de warning. Aqui a gente vai selecionar a nossa API exposta dentro do manager. Então aqui eu vou selecionar a nossa API de pedidos. Também conseguimos separar ali qual ambiente que a gente quer monitorar essa API. Então aqui eu vou selecionar o ambiente de desenvolvimento. Também é possível selecionar o recurso e operação dessa API que a gente quer monitorar. Então feito isso a gente já selecionou a nossa API, já selecionou o recurso também e a operação que a gente quer monitorar.

E agora a gente vai selecionar o tipo de alerta e de evento que a gente quer disparar ali e como a gente vai disparar. Então aqui eu vou selecionar que a gente vai disparar um alerta quando eu tiver de acordo com alguma latência que eu definir aqui embaixo. Entãotambém tem a parte de disponibilidade, total de chamadas e o status code da nossa chamada. Como a gente definiu que seria a latência aqui, a gente vai definir aqui embaixo também qual será o mínimo ali de latência que a gente tem que atingir para que esse alerta seja gerado. Aqui também tem um período que a gente vai olhar para a nossa API, para o período do dado que a gente vai olhar para que o nosso alerta seja gerado ou não. Então aqui eu vou botar um período de 30 minutos.

Então aqui eu vou definir o nosso comparador, então aqui a gente tem a possibilidade de selecionar o maior que e o menor que. Aqui eu vou botar o maior que e aqui é basicamente o total da nossa latência que a gente quer monitorar. A fim de teste para a gente disparar esse alerta mais facilmente, eu vou definir aqui a quantidade em 300 milissegundos e aqui o total de chamadas que o alerta vai ter que ver para ele fazer o disparo do alerta. Então a gente vai ter que ter 5 chamadas com a quantidade maior de 300 milissegundos, então a latência maior que 300 milissegundos para esse alerta ser disparado.

Então seguindo aqui, a gente vem para uma parte de definição de quanto esse alerta irá rodar. Então a gente tem a possibilidade aqui de botar um alerta pré-definido, um horário pré-definido, então a cada um minuto esse alerta vai rodar e vai olhar há 30 minutos atrás dos dados da API para fazer o disparo do alerta. Então aqui a gente vai botar a cada 5 minutos. Também é possível a gente definir uma expressão crawl para ter o disparo de alerta ali em algum momento definido de acordo com a estratégia de negócio de vocês.

Aqui nós temos então onde o alerta chegará, então a gente tem algumas opções aqui:

Chegar por e-mail

Por Slack

Por Teams

Por disparo de webhook

Pelo WhatsApp

Então se a gente quiser integrar o alerta ali com a criação de um ticket automático também é possível e também pelo WhatsApp. Aqui a gente vai selecionar o Slack. Vou selecionar aqui o meu workspace, o meu canal que eu quero receber essa mensagem também. Também é possível aqui adicionar uma mensagem customizada para esse alerta. Feito isso, nosso canal de recebimento desse alerta já está configurado. Então caso a nossa API passe ali os 300 milissegundos em 5 chamadas, o disparo do alerta vai ser efetuado para esse tipo de canal.

Então configurado isso, eu dou um save aqui. Ele já vem para uma parte de um overview do que foi criado. Então aqui todas as informações que a gente preencheu anteriormente e o canal que a gente selecionou para chegar o alerta. Então aqui a gente já tem o nosso catálogo dos alertas já criados. Então a gente tem aqui o alerta criado e aqui uma parte do overview e também aqui a gente também tem como mandar uma mensagem de teste para esse canal para ver se a gente está conectado, se está funcionando tudo certinho a comunicação.

Então aqui a gente tem a parte de recebimento desses alertas. Então a gente tem aqui a descrição de qual API que a gente estava monitorando anteriormente com o alerta. Então a gente tem API orders de pedido, no ambiente que a gente deu deploy nela, em qual recurso e qual operação que retornou acima dos 300 milissegundos. Então aqui a gente também tem umas mensagens que a operação retornou maior que 300 milissegundos nos últimos 5 minutos e também aqui uma média da latência que retornou. Aqui embaixo a gente também tem outro alerta da mesma API, só que aqui a gente vê que também retornou acima dos 300 milissegundos e também aqui tem uma margem menor da latência média que foi retornada.

Então pessoal, é basicamente isso essa demonstração, é uma breve demonstração aqui dos nossos produtos. Espero que vocês tenham gostado aí e eu passo a bola novamente para o Marcelo. Muito obrigado.

Bom pessoal, agora só para concluir, vou comentar rapidamente aqui sobre a Sensedia e como a gente pode ajudar nesse processo. A Sensedia é uma empresa, uma referência nacional em estratégias de APIs e microserviços, tanto com a nossa plataforma de integração moderna, onde o Vinícius apresentou um pouco para vocês de como a gente consegue usar alguns dos produtos para suportar aqui nessa estratégia de indicadores, objetivos, de níveis de serviço, e tambémcom todos os nossos serviços profissionais, a nossa consultoria extremamente especializada em todo esse contexto de APIs e microserviços. Extremamente especializada em todo esse contexto de APIs e microserviços. Dentro dos nossos serviços, a plataforma, o Vinícius já teve a oportunidade de apresentar um pouco para vocês. Dentro dos nossos serviços, queria destacar um serviço chamado API Care, onde a Sensedia conta com profissionais extremamente especializados para atuar com uma parceria na operação do dia a dia das suas APIs, ajudando inclusive na definição desses principais indicadores e definindo esses thresholds que representam esses objetivos para monitorar e alertar a sua operação em cima do comportamento das suas APIs, visando uma melhor confiabilidade dos seus serviços prestados.

Essa nossa oferta, a API Care, cobre ali algumas atividades como:

Uma atuação 24x7.

Planos de atendimento e acionamento totalmente personalizados.

Envio de relatórios, repórter de tanto a nível executivo quanto operacional.

Monitoramento completo do ambiente que suporta as suas APIs mais críticas de negócio.

Um apoio especial em eventos e também em war rooms.

Além de um apoio consultivo ali na governança das suas APIs.

Bom, pessoal, era isso que a gente tinha aqui para trazer para vocês hoje, tá? Espero que vocês tenham gostado e contem aí com a Sensedia para ajudar vocês em toda a sua estratégia de APIs e microserviços e também a medir o comportamento das suas APIs e entender e monitorar como está a satisfação de quem está consumindo as suas APIs. Até breve!

‍