Apresentação no Meetup do IFood Engineering sobre Site Reliability Engineering, termo criado originalmente pelo Google para abordagem de Engenharia de Software para Operações de TI.
Origens ● SRE é criado em 2003 ● DevOps é “criado” em 2008/2009 ● “Público” em 2016 com o livro “Site Reliability Engineering - How Google Runs Production Systems”
O que é SRE? é uma abordagem de Engenharia de Software para Operação de TI (Infraestrutura), ajudando as equipes encontrar o equilíbrio de lançar novas funcionalidades e garantir a confiabilidade delas para os usuários.
SRE vs DevOps DevOps é um conjunto de práticas, diretrizes e cultura projetada para quebrar silos em desenvolvimento, operações, arquitetura, rede e segurança. Site Reliability Engineering é uma maneira de implementar DevOps baseado na aplicação de Engenharia de Software em Operações de TI.
Service Level Indicator SLI -> “Uma métrica quantitativa de algum aspecto do nível de serviço” https://www.blameless.com/blog/sli-slo-sla Exemplos: ● Latência ou Disponibilidade em Tempo de resposta em milissegundos ● Taxa de erro por requests/sec ● Taxa de requisições por segundo ● Recurso ou sistema utilizado
Service Level Objectives SLO -> Um valor objetivo ou conjunto de valores para um nível de serviço mensurado por um mais indicadores de SLI ● SLI <= Objetivo ● Limite menor ou maior que o SLI https://www.blameless.com/blog/sli-slo-sla
Service Level Agreements Acordo de nível de serviço do produto ou serviço estabelecido com cliente e/ou usuário baseado no SLO https://www.blameless.com/blog/sli-slo-sla
Error Budget Error Budget é o acordo entre equipe(s) de tecnologia e negócio (ou outras áreas) a quantidade de erro tolerado para implementar novas funcionalidades
Blameless Postmortem Postmortem são a oportunidade de analisar profundamente um incidente para encontrar o entendimento da cadeia de eventos e as causa(s)-raíz(es) geradoras. Um incidente nunca ocorre somente por uma falha humana, ele é uma relação de diversas interações entre pessoas, sistemas (software) e processos.
Engenharia do Caos Engenharia do Caos é a experimentação recorrente para melhorar a confiabilidade e resiliência de sistemas (softwares + pessoas) em condições adversas em produção.
Princípios base do Jidoka ● Descobrir uma anomalia ● Para o processo ● Corrigir o problema imediatamente ● Investigar e resolver a causa raiz https://kanbanize.com/continuous-flow/jidoka
O que é Toil Toil é o tipo de tarefa relacionada de um serviço em produção que tende ser manual, repetitivo, automatizável, tático, sem valor duradouro e que escala linearmente quando um serviço cresce.
Por que lidar com o Toil Pessoas: ● Descontentamento e não satisfação de realização ● Burnout ● Maior incidência de erros, resultando em maior quantidade de retrabalho ● Sem tempo para aprender novas habilidades ● Estagnação na carreira (falta de oportunidade de participar de projetos que agreguem valor)
Por que lidar com o Toil Organizações: ● Escassez constante de capacidade da equipe ● Custo excessivo do suporte operacional (Ops) ● Inabilidade de conduzir iniciativas estratégicas. ● Inabilidade para reter talentos ou adquirir talentos.
Diminuição do Toil ● Identificar o tempo usado em atividades manuais e repetitivas ● Estabelecer uma meta de redução do tempo em Toils: 70% para 50% ● Automatizar com inteligência ● Reduzir o MTTR
Advocate - Reliability and Resilience Developer Experience Disponibilização de meios e formas das equipes “clientes” (devs, cientistas de dados, etc) tenham autonomia no Ciclo de Desenvolvimento de Software (SLDC) Confiabilidade e Resiliência Incentiva a adoção de arquiteturas e soluções pelo olhar de confiabilidade e resiliência de modo que não impacte profundamente o Lead Time.
O que é Observabilidade Um sistema é "observável" de forma que você pode explicar o que está acontecendo por dentro apenas observando do lado de fora. https://www.honeycomb.io/blog/best-practices-for-observability/
O que tornar obrigatoriamente observável? Há rastreabilidade de uma requisição fim a fim? Há rastreabilidade de cada agente, etapa, recurso do processo que seja possível correlacionar?
On-Calls / Plantões ● As equipes de produto/aplicação estão nos plantões? ● O fluxo de escalonamento de um incidente é claro? Ex: Quando acionar N2, N3 de um produto/aplicação ● Há base de conhecimento facilmente acessível para os plantonistas? ● A rotação dos plantonistas está organizada equilibrada para os plantonistas o descansarem o suficiente? ● A política de remuneração do plantão e sobreaviso é clara?
Release Engineering Suporta ou é guardião das melhores práticas e ferramentas para permitir equipes de desenvolvimento para controlar e executar por eles o processo de release.
DevOps e SRE Redução dos silos: Compartilhar responsabilidade Aceitar as falhas como algo normal: Error budgets e blameless postmortems Implement mudanças graduais (small batches): Reduz o custo de falha Leverage tooling and automation: Automatizar os casos comuns Métrica de tudo: Métrica para toil e confiabilidade
Referências Liz Fong Jones - Intro to SRE Google - SRE Book Google - The Site Reliable Workbook Blameless - The Essential Guide DevOps Key Metrics - Accelerate Book Honeycomb - Achieving Observability Fernando Ike - Site Reliability Engineering Fernando Ike - Blameless Postmortem 10Deploys - Episódio 019 Kanbanize - What is Jidoka?
fernandoike
akiroom
loglass2019
shunsukeono_am
orgachem
nikkei_engineer_recruiting
biwashi
ryomaru0825
kosui
cmusudakeisuke
mosa_siru
knsg16
peisuke
trallard
quramy
rocio
wjessup
zakiwarfel
akmur
denniskardys
maggiecrowley
mongodb
philhawksworth
3n
samlambert