O documento trata da Engenharia de Confiabilidade (SRE), explorando conceitos como métricas de desempenho (SLA, SLO, SLI) e a importância de abraçar incertezas e riscos em sistemas de software. Discute estratégias para garantir resiliência, como simuladores de desastres e políticas de fallback, e enfatiza a necessidade de um aprendizado contínuo e uma abordagem prática na implementação de melhorias. Por fim, aborda ferramentas e práticas recomendadas que podem ser adotadas para fortalecer a confiabilidade e a resiliência organizacional.

1. Engenharia de
Confiabilidade
Roadmap da
Resiliência

2. Matheus Fidelis
Site Reliability Engineer
@fidelissauro
linktr.ee/fidelissauro

3. O QUE É SRE?

4. LET’S GET STARTED
● Site Reliability Engineering
● Engenharia de Confiabilidade
● Ben Treynor Sloos, Vice
Presidente de Engenharia do Google
● Incorporar aspectos de
Engenharia em Operações
● Garantir a Confiabilidade de
Software e Produtos
O QUE É SRE?

5. TL;DR
MEDIR E GARANTIR
Sistemas e Produtos

6. NÃO É APENAS
SOBRE
INFRAESTRUTURA
É ORGANIZACIONAL

8. ACEITAR OS RISCOS
Não é "se", é "quando"...

9. LET’S GET STARTED
● Não é "se", é "quando"...
● As coisas vão quebrar
● Algo vai parar de funcionar
● Vai dar erro
● Alguém vai ficar triste
ACEITAR OS RISCOS

10. COMEÇANDO DE
ALGUM LUGAR

12. MÉTRICAS INICIAIS
(SLA, SLO, SLI)

13. Métricas de
Confiabilidade
Acordos
Service Level Agreement
O número previsto em contrato.
A obrigação.
Nunca pode ser 100%.
SLA
Service Level Indicator
O indicador de performance do
SLO e SLA.
O dedo duro.
SLI
Service Level Objective
O objetivo de melhora da
métrica.
Mais rigoroso que o SLA.
A estrela guia.
Nunca pode ser 100%.
SLO
O quanto falta pro SLO e SLA
serem quebrados?
A margem de erro.
Error Budget

14. LET’S GET STARTED
● Deve ser um indicador além
do time técnico
● É simples, objetivo, todos
entendem
● Sem glamour
● "Se alguém demora mais que
30 segundos pra entender, está
ruim"
Métricas de Confiabilidade

15. "Você vai ter muitos
alarmes, muitos
dashboards, muitas
métricas até melhores
e mais detalhados que
eles, mas isso não quer
dizer que você tem
SLO's… Eles não
servem"
— Crédito a alguém inteligente que eu inventei

16. QUAIS PODEM SER MEUS
SLA'S, SLO'S e SLI'S?
Métricas RED

17. Métricas RED
Número de Requests em um
determinado range de tempo
Rate
Duração média, maxima, p99,
p90, p50 dos requests dentro
de um determinado range de
tempo
Duration
Porcentagem de erros em um
determinado range de tempo
Error
● Métricas voltadas para serviços e
microsserviços
● Modelo baseado em uso de serviço

18. "SE O PRODUTO
NÃO COMPRAR,
NÃO FAZ SENTIDO"
Desculpa…

19. COMO GARANTIR MEU SLO
e SLA??
A jornada começa aqui…

20. IDENTIFICANDO &
MEDINDO &
TOMANDO AÇÕES

22. CHAOS
Abraçar a aleatoriedade e incertezas
(E se preparar pra isso)

23. ANTIFRAGILIDADE
Se beneficiar das aleatoriedades sistêmicas (ou não)

25. LET’S GET STARTED
● Nassin Taleb, Matemático
analista de riscos
● Definir o oposto de "Frágil"
● Se beneficiar com o caos
● Conflitos e adversidades
● Entender os "Cisnes Negros"
Antifragilidade

26. LET’S GET STARTED
● Eventos que não podem ser
previstos
● Eventos irregulares
● Alto impacto
● Óbvios depois que ocorrem
● Facilmente previsíveis depois
que ninguém previu
Antifragilidade

28. FRÁGIL

29. FRÁGIL ROBUSTO

30. FRÁGIL ROBUSTO ANTIFRÁGIL

31. LET’S GET STARTED
● Networking
● Containers Hell
● Business Errors
● Datacenter Outages
● System Outages
● Hardware Failures
● Compatibility Failures
● Components Failures
● Security Disasters
Cisnes Negros Origens

32. LET’S GET STARTED
● Conversando e Conhecendo
● Mapeamento visual
● Game Days
● Simulações de Desastres
● Perguntas Cretinas
● Assumindo Riscos como
Produto
● Post-Mortens
Lidando seus Cisnes

33. BLAST RADIUS
Estimar e diminuir os impactos

35. LET’S GET STARTED
● Termo Utilizado pelos times da AWS
● Zona de Impacto de um desastre
● Qual o dano?
● Quais os Workloads Afetados?
● Quais as dependências
● O que está em Outage
● O que será degradado parcialmente?
● O que ainda funciona?
Blast Radius

36. LET’S GET STARTED
● Matriz de Resiliência
● Healthmaps
● Game Days
● Simulações de Desastre
● "Perguntas Cretinas"
Blast Radius - Como Medir?

37. LET’S GET STARTED
"O que acontece quando isso aqui
cair?" - Pergunta Cretina

38. LET’S GET STARTED
"Se eu desligar isso aqui, esse outro
ainda funciona?" - Pergunta Cretina

39. LET’S GET STARTED
"O que podemos fazer pra isso aí não
cair junto? Ou quem sabe minimizar o
impacto da queda?" - Pergunta Cretina

40. DISASTER RECOVERY &
GAME DAYS

42. LET’S GET STARTED
● Um desastre, é um desastre por definição
● Quem define o que é um desastre?
● Capacidade de escolher entre
○ Tomar uma voadora
○ Tomar um soco
○ Tomar um tapa
● Minimizar e contornar os impactos
● Simular é melhor que o acaso
● Medir o Blast Radius
● Gerar Backlog
Disaster Recovery

43. LET’S GET STARTED
● Backlog das Perguntas Cretinas
● Simular o impacto real delas
● Diminuir as Dependências
● Criar fluxos alternativos
● TradeOffs
● Testar ativamente os fluxos alternativos
● Desligar dependências, simular falhas e
manter os SLO's
Disaster Recovery & Game Days
Objetivos

44. SRE pode
ser um
time.
Resiliência
não.

45. Resiliência de
Infraestrutura
● Redundancia de Networking
● Multi-AZ & Multi Region
● Backups, Snapshots, Restore
● Recursos Redundantes
● Camadas de Dados
● Região e Plano de DR?
● Capacity Planning
● Plataforma
● SLA dos fornecedores

46. Resiliência de
Sistêmica
● Programação Defensiva
● Healthchecks
● Sync e Async
● Retry Policies
● Circuit Breakers
● Fault Injection
● Fallbacks
● Desacoplamento e Isolamento
● Camadas de Dados

47. Retry Policies
● Primeiro Passo
● Integrações Pragmáticas
● Retentativa de Comunicação Sync
● Priorizar comunicação Async
● Sempre pensar num fallback
● Mensageria e Filas Async
● Plataforma Inbound & Outbound
● Timeout nas Integrações

48. Fallbacks ● Sempre pensar em fluxos alternativos
● Duvida entre duas ou mais soluções?
○ Use várias
● Duvida entre dois ou mais parceiros?
○ Tenha vários
● Fluxo reserva
● Mensageria, Reservas, Fluxo
● Represagem
● Processamento tardio

49. Circuit
Breakers
● Dar erro mais rápido?
● Uso inteligente dos Fallbacks
● Trabalhar com as falhas de forma
prevista
● Thresholds 5xx, conn, business
● Fallback acionado de forma
inteligente
● Quebra tornar o fallback prioritário
● Checagem inteligente
● Monitoramento

50. Fault
Injection
● Injetar erros primários internacionais
● Testar ativamente os fallbacks
● Problemas de monitoramento
● Porcentagens aceitáveis do fluxo
principal
● Chaos Engineering - Assaults
○ Latency Injection
○ Error Injection
○ App Killer
○ Memory & CPU
○ Container exit

51. Resiliência em
QA / DevOps
● Testes
● Linters
● Business Tests
● Contratos
● Feature Toggles
● Canary
● Blue / Green
● Rollback rápido?

52. Resiliência em
Segurança
● Monitoramento
● Perimetro
● DMZ
● DDoS
● WAF
● Scans na Pipeline
● SAST & DAST Continuos
● Thread Inteligence

53. Chaos
Intencional
● Testar a resiliência dos clientes e
Serviços
● Plataforma / Cloud
○ Chaos Monkey
● Kubernetes
○ Chaos Mesh
○ Gremlin
○ LitmusChaos
● Development
○ Hystrix*
○ Resilience4j
○ GoBreaker
○ Chaos Monkey Libs

54. PRR Review
Production
Checklist
● Healthcheck dos produtos e
dependências
● Garantir de verdade
● MVP não é desculpa
● Deu certo, e agora???
● Revisitar periodicamente
● Score de confiança interno
● Até quando é do controle do
SRE?

55. A JORNADA É A
PARTE MAIS
IMPORTANTE
DO PROCESSO

56. Impossível ter
tudo pra
ontem.
Trabalhe com
pequenos
escopos

57. LET’S GET STARTED
● Começar do zero com tudo
que tem de melhor
● Aprendizado continuo
● Reaproveitamento
● Ganho de tempo
● Templates
● Tudo "By Default"
Templates & Golden Path

58. LET’S GET STARTED
● Como manter tudo isso sem
inibir inovação?
● Quais as melhores ferramentas?
● Quais as melhores práticas?
● Quais as melhores
recomendações?
● Tudo isso já vem por default?
● Como garantir isso rápido?
● Como evoluir isso?
Templates & Golden Path

59. @fidelissauro
linktr.ee/fidelissauro
Obrigado!