$30 off During Our Annual Pro Sale. View Details »

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.

Fernando ike

October 14, 2020
Tweet

More Decks by Fernando ike

Other Decks in Technology

Transcript

  1. Site Reliable Engineering
    Evolução de Sysadmin?

    View Slide

  2. Fernando Ike
    // linkedin.com/in/fernandoike
    // twitter.com/fernandoike
    // pontocafe.fernandoike.com

    View Slide

  3. TEMOS VAGAS!! #VempraZup
    Tire foto do QR Code para
    ver as oportunidades.
    zup.com.br/vagas

    View Slide

  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”

    View Slide

  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.

    View Slide

  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.

    View Slide

  7. Princípios
    Data Centric
    Assuma/Abrace os Riscos
    Automação
    Observability
    Release Engineering

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  11. “DevOps métricas”
    Lead time for changes
    Deployment frequency
    Time to restore service
    Change failure rate

    View Slide

  12. Abrace o Risco / Falhar e aprender

    View Slide

  13. Abrace o Risco / Falhar e aprender
    Error Budget
    Blameless Postmortem
    Engenharia do Caos

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  17. Automação

    View Slide

  18. Jidoka
    Automação com um toque humano

    View Slide

  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

    View Slide

  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.

    View Slide

  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)

    View Slide

  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.

    View Slide

  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

    View Slide

  24. Toil sempre existirá!!!

    View Slide

  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.

    View Slide

  26. Métricas

    View Slide

  27. 4 Golden Signals
    Latência
    Tráfego
    Erros
    Saturação

    View Slide

  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/

    View Slide

  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?

    View Slide

  30. On-Call

    View Slide

  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?

    View Slide

  32. Release Engineering

    View Slide

  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.

    View Slide

  34. Release Engineering
    Trunk-Based Development
    Change-Advisory Board (Gerência de Mudança)

    View Slide

  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

    View Slide

  36. O papel de SRE
    Perfis de pessoas:
    ● Software Engineers
    ● System Engineers
    Habilidades:
    ● Saber/aprender programar
    ● System Thinking

    View Slide

  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?

    View Slide