SRE: É a evolução do sysadmin?

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.

168c322e7157a4cfffdeb88ab2309e02?s=128

Fernando ike

October 14, 2020
Tweet

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?