SLI's, SLA's e SLO's :: Não sabe por onde começar com suas métricas? Comece por aqui! - Nanoshots | Cloud & DevOps & Security
QueroSer.Tech
Medium
Contato
Home SRE SLI's, SLA's e SLO's :: Não sabe por onde começar com suas métricas? Comece por aqui!
SLI's, SLA's e SLO's :: Não sabe por onde começar com suas métricas? Comece por aqui!
Matheus Fidelis 05:40 9 comentários
Share:
Facebook
Twitter
Google+
Pinterest
Whatsapp
TL; DR; Um guia pra te levar do 0 ao 1
Se SRE é hype, então vamos hypar do jeito certo! Esse é um guia pra quem está começando uma jornada de SRE e tem dificuldades pra entender os fundamentos básicos ou com dificuldade de começar de algum lugar. Elaborei esse artigo pra ser simples, acessível e assertivo pra quem quer entender as principais métricas e descobrir por onde começar a medir e garantir a confiabilidade de seus produtos.
O que faz um SRE?
O papel do SRE, de uma forma bem alto nível são somente dois: Medir e Garantir.
Medir indicadores de performance, risco, custo, entrega, qualidade e disponibilidade de uma aplicação e/ou produto.
Como garantir tudo isso? Avaliando arquitetura de infraestrutura, plataforma, qualidade de código, segurança, fluxos de entrega, implementando monitoramento, alertas que fazem sentido e encontrando pontos de melhoria de disponibilidade dos serviços.
Mas isso ainda é muito complicado, e você não precisa colocar tudo isso num checklist pra poder começar. Esse artigo serve pra isso, pra te fazer dar o primeiro passo e sair do 0 pro 1.
E vamos começar pelo coração do que se considera Engenharia de Confiabilidade, os SLO`s, SLI`s e SLA`s e Error Budgets.
O que são essas siglas?
Parece complexo, muita gente vai escrever artigos com muito tecniquês pra explicar, mas é bem simples, vamos lá. Sem enrolar:
SLA (Service Level Agreement): É o nível contratual que um provedor, de qualquer coisa, IaaS, PaaS, SaaS estabelece com seu cliente referente a disponibilidade. Esse contrato nunca pode ser 100%. Se existe uma certeza nessa vida é que aplicações e serviços vão cair. Independente de tempo, criticidade e etc. O que podemos fazer é sempre adicionar 9`s nos nossos SLA`s, ao 99,999999 e além.
SLO (Service Level Objective): É o contrato interno, entre os times e produto. Normalmente ele é muito mais apertado e rígido que o SLA. Pois o mesmo é focado em melhorias, e adicionar mais 9`s aos nossos serviços. Caso o SLA seja de 99,9% de disponibilidade, seu SLO deve sempre mirar um 99,99 pra mais. Quando se atinge o SLO com segurança, aumente seu SLA público, e assim vai...
SLI (Service Level Indicators): São as métricas que você vai utilizar pra acompanhar como sua situação atual está em relação aos SLO's. Isso independe de ferramentas, pois são cálculos simples.
Error Budget: É a margem de erro que você tem pra trabalhar nos seus serviços. Normalmente calculado como (100 - SLO) = Error Budget. Como 100 - 99,9 = 00,1% de erros são aceitáveis.
Resumindo...
No fim das contas, o SLA é o mínimo disposto em contrato, os SLO`s são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos. Fácil né?
E o Error Budget é simplesmente o quanto você pode ter de falhas dentro desse contrato, e como você está posicionado em relação a isso. Se você quer ter 99% de disponibilidade, seu error budget é de 1%, mega simples né? E você quebra esse 1% em 100% e analisa quanto falta pra atingir esse budget, ou o quanto você passou dele. Não entendeu? Segura ai que a gente já vai te ajudar mais.
E pra que serve tudo isso? Qual a vantagem?
Simples, pra encontrar uma Estrela Guia.
O que seria uma Estrela Guia pro time? Uma, ou algumas poucas métricas, simples e objetivas que são fáceis de acompanhar e entender. E principalmente que façam sentido pra um escopo maior que o seu time.
E por incrível que pareça isso é MUITO difícil. Trabalhar com métricas em times de tecnologia de uma forma enxuta é muito complicado, principalmente entre vários times. Ou porque ninguém sabe o que medir, ou porque tem muita coisa sendo medida e fica difícil pra todo mundo acompanhar, ou porque métricas fornecidas e seguidas pelo time de infraestrutura não fazem sentido pros times de desenvolvimento, redes, produto e vice-versa (várias vezes).
Pra isso foram criados esses conceitos de SLO's, SLI's, Error Budgets e SLA's.
SLO's então. Qual meu objetivo? O quanto eu preciso entregar?
Vamos definir isso em 3 passos, mantendo um mindset de configuração e adaptação. A ideia desse artigo é te fazer começar de algum lugar. Então não se prenda em levantar tantas informações nesses primeiros passos. Vamos lá:
1) Sente, respire e formule duas frases:
Eu preciso responder todas as requisições em menos de 200 milisegundos (coloque aqui a métrica que o seu coração mandar)
Eu preciso ter 99% de disponibilidade pra minha aplicação, e vou medir isso semanalmente (coloque aqui a porcentagem e o período que vier na sua cabeça)
2) Leve isso para o seu time:
Pegue essas duas métricas, converse com pessoas próximas do seu time, de outros times, com alguns desenvolvedores, sysadmins, testers, engenheiros de rede, sei lá.
Pegue feedback e lapide mais ainda para o que faz sentido pra realidade da aplicação.
3) Leve isso pra sua gestão, junto com seu time
Defina esses acordos com bastante gente, seu time, seu gestor, líder técnico, ou alguém com papel de tomada de decisão, para que o ciclo de feedback seja o mais proveitoso possível.
Lembrando que essas métricas fazem pouco sentido se não forem adotadas em conjunto.
O que medir? O que definir como meus SLI`s?
Existem muitas coisas que podem ser medidas e se tornar estrelas guias do time. Mas vamos começar do feijão com arroz e nos limitar a duas métricas simples que fazem sentido na maioria dos casos. Disponibilidade e Tempo de resposta da aplicação. Então vamos começar com o básico e recomendado. O padrão RED, Rate, Errors e Duration. E como eu começo?
Disponibilidade:
Medir disponibilidade é simples, No caso de um sistema web podemos seguir com o calculo básico de (Quantidade de requisições realizadas com sucesso / Quantidade total de requisições) * 100
Em outros casos quando você não está tentando medir um sistema web, o calculo seria: (Quantidade de tempo em uptime / Quantidade de horas acordadas) * 100 .
Response Time:
Response time é mais baba ainda, dependendo da ferramenta que você estiver utilizando pra olhar isso. Mas pode se tornar complexo dependendo do seu cenário. Mas basicamente é o tempo de resposta que o servidor leva pra responder um cliente.
Basicamente o cálculo é a média de http dispatch de todas as requisições. Algo como average('duration').
Exemplo de Dashboard de SLO's e SLI's
Medir response time de um microserviço é simples, mas de uma malha não.
Na minha humilde opinião, o principal ponto a ser medido é sempre a sensação do cliente final, que está "consultando o histórico de vacinas do cachorrinho dele", ou "cadastrando um novo gatinho no cadastro de pets". O cliente final não liga pra quantos microserviços estão por trás daquela solicitação enviada. Por isso, considero o tempo de resposta do cliente final como um todo, por exemplo "o tempo que levou pra tirar tirar o relatório de vacinas" uma métrica mais importante do que medir o tempo em que microserviço de cadastro de pets leva pra consultar o microserviço de vacinas.
É importante também, mas comece pelo simples e importante. O que for mais fácil e fizer sentido pra você.
Com o tempo isso pode e deve evoluir. Como por exemplo, começar a tirar métricas da comunicação entre os serviços da malha e atingir objetivos de negócio. Assim como um SLO no futuro pode vir a se tornar algo do tipo: Com meu microserviço de análise de antifraude no ar, quero reduzir o número de chargebacks para menos de 0.05%. E assim vai...
Ainda não sabe por onde começar a medir? Comece com 10.
O número 10 é um número mágico que veio na minha cabeça agora. Simplesmente porque é ridículo e absurdo.
10% de erro é aceitável, e quero responder abaixo de 10s.
Soa ridículo, né? Eu sei. Mas pelo menos vai te ajudar a encontrar onde você está. Essa primeira métrica sendo fácil de bater, vai te ajudar a encontrar a saúde e estado atual da sua aplicação.
Depois que começar a medir e entender o seu cenário, logo após o primeiro ciclo de métricas, abaixe a régua pra onde faz sentido real pra você.
E depois do feijão com arroz...
O que podemos monitorar depois que fizemos o básico? Como podemos evoluir nossas métricas?
Monitoramento de disponibilidade e error rate por endpoints chaves;
Quantidade de requisições que passaram do response time acordado, além da média;
Custo por aplicação;
Disponibilidade por feature, como por exemplo, feature de emissão de boleto, cartão, emissão de notas fiscais, envio de email e etc
Error rate / Response time / Throughput baseado em padrões em dias do mês ou períodos do ano
Agradeço imensamente a todos que doaram uns 5 minutinhos do seu tempo pra revisar esse texto antes de ser publicado, foi de grande ajuda pra mim e eu agradeço de coração.
Espero que ele te ajude de alguma forma. Se te ajudou, conta pra mim!
Grande abraço!
Marcadores:
DevOps monitoramento post SRE
Share:
Facebook
Twitter
Google+
Pinterest
Whatsapp
9 comentários:
Felipe Hitomi 12 de agosto de 2020 14:30
Muito interessante a postagem, foi simples mas com conceitos.
ResponderExcluir
Respostas
Responder
Victor Paulo 13 de agosto de 2020 23:42
Parabéns ! Comecei a entender aqui sobre o assunto !
ResponderExcluir
Respostas
Responder
Fabio Costa 15 de fevereiro de 2021 15:46
O mais simples e objetivo que eu encontrei até o momento. Parabéns!
ResponderExcluir
Respostas
Responder
Mauricio Marques 4 de março de 2021 05:30
Muito bom, parabéns!
ResponderExcluir
Respostas
Responder
Rui 4 de março de 2021 09:10
Ajudou a enteder o conceito. Obrigado
ResponderExcluir
Respostas
Responder
Bruno Santos 8 de março de 2021 04:45
Fantástico, simples e objetivo, suficiente para entender o assunto, parabéns
ResponderExcluir
Respostas
Responder
Giovanni Lima 9 de abril de 2021 13:53
Muito bom!
ResponderExcluir
Respostas
Responder
mordp 25 de maio de 2021 14:21
Muito Bom! Sinto falto as vezes de post objetivos e simples! Tem muitos tecniqueis que parece as vezes outro mundo...
ResponderExcluir
Respostas
Responder
apolzek 1 de junho de 2021 11:28
Bem escrito, esclareceu bastante os termos !! ;)
ResponderExcluir
Respostas
Responder
Adicionar comentário
Carregar mais...
Assinar: Postar comentários ( Atom )
Social
Facebook
Twitter
LinkedIn
Github
Facebook
Popular
Zabbix - Monitorando Disponibilidade de Internet
Entendendo o Google Hacking na Pratica e Otimizando suas Buscas com Dorks
Realizando ataque Man in the Middle com SSLStrip e Ettercap
Configurando Proxy Transparente com Squid Proxy e PfSense
Resetando a senha do usuário root do MySQL e MariaDB
Encontrando e Acessando Câmeras e Roteadores abertos a Internet
Realizando ataques e varreduras anonimamente com Tor e Proxychains
Capturando senhas com Social Engineering Toolkit e Ettercap
Instalação e Configuração do Firewall pfSense 2.2.4
Adicionando repositórios PPA no Debian 8 Jessie
Labels
Ambientes (13) Android (2) App (1) ArchLinux (1) artigos (1) AWS (10) campanhas (2) CentOS (10) cloud (12) criptografia (7) cyberbullying (1) Desenvolvimento (32) DevOps (20) Docker (18) documentario (4) Dorks (1) Drops (2) ecs (1) eks (4) eks-playlist (4) envoy (3) fargate (1) Fedora (2) ferramentas (1) Fingerprint (2) Firewall (5) Forense (7) git (4) Google (1) Hacking (48) IOT (2) Java (2) Jekins (1) jenkins (1) Kubernetes (3) lambda (1) lifehacking (6) Linux (130) Metasploit (7) monitoramento (1) MyTools (7) Nginx (3) NodeJS (3) NoSQL (2) Notíciais (1) OpenSUSE (1) Palestra (2) PHP (3) pirataria (1) post (207) privacidade (5) Provisionamento (2) Proxy (6) pwgen (1) Python (10) Raspberry (2) Red Hat (7) Redes (49) Samba (6) segurança (95) serverless (1) Servidores (82) Shellscript (5) Spam (1) SQL (8) SRE (1) swarm (1) SystemDaily (22) Talk (3) Terraform (5) tips (37) Tor (3) torrents (2) troubleshooting (2) Tutoriais (93) video (4) VIM (2) Virtualbox (2) Virtualização (5) wargames (1) We (1) Web (43) Windows (3) Wireless (2) youtube (2) Zabbix (5)