SRE: É a evolução do sysadmin?

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.

Transcript

1. Site Reliable Engineering Evolução de Sysadmin?
2. Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com
3. TEMOS VAGAS!! #VempraZup Tire foto do QR Code para ver as oportunidades. zup.com.br/vagas
4. 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”
5. 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.
6. 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.
7. Princípios Data Centric Assuma/Abrace os Riscos Automação Observability Release Engineering
8. 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
9. 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
10. 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
11. “DevOps métricas” Lead time for changes Deployment frequency Time to restore service Change failure rate
12. Abrace o Risco / Falhar e aprender
13. Abrace o Risco / Falhar e aprender Error Budget Blameless Postmortem Engenharia do Caos
14. 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
15. 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.
16. 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.
17. Automação
18. Jidoka Automação com um toque humano
19. 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
20. 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.
21. 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)
22. 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.
23. 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
24. Toil sempre existirá!!!
25. 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.
26. Métricas
27. 4 Golden Signals Latência Tráfego Erros Saturação
28. 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/
29. 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?
30. On-Call
31. 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?
32. Release Engineering
33. 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.
34. Release Engineering Trunk-Based Development Change-Advisory Board (Gerência de Mudança)
35. 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
36. O papel de SRE Perfis de pessoas: • Software Engineers • System Engineers Habilidades: • Saber/aprender programar • System Thinking
37. 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?