Site Reliable Engineering Evolução de Sysadmin?

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

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

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.

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

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

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

Abrace o Risco / Falhar e aprender

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

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.

Automação

Jidoka Automação com um toque humano

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

Toil sempre existirá!!!

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.

Métricas

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

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-Call

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

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.

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

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

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

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?