O documento introduz o conceito de Site Reliability Engineering (SRE) e fornece diretrizes para equipes implementarem práticas SRE para melhorar a confiabilidade dos sistemas em produção, como definir orçamentos de erro e níveis de serviço.

1. Introdução à SRE
Um guia para melhorar a confiabilidade das aplicações em
produção
Igor Abade V. Leite | @igorabade
• Microsoft Regional Director
• CEO, CloudMotion (www.cloudmotion.com.br)

2. Ciclo de vida típico de um
software
Ideia Negócio Desenvolvimento Operações Clientes

3. Lembrando que…
... O objetivo não é apenas implantar o software, mas também garantir que
seja mantido adequadamente, uma vez em produção
Quanto tempo leva para um incidente chegar à equipe certa?
Dá para ser minutos, em vez de horas?
Com que frequência o mesmo incidente acontece de novo?
Dá para reduzir a nunca?

4. A confiabilidade é a capacidade
de um sistema ser capaz de
suportar alguns tipos de falha e
ainda permanecer funcional do
ponto de vista do usuário.

5. Site Reliability Engineering…
... é o que acontece quando um engenheiro de software é colocado para
resolver problemas de operações (infraestrutura)
50% de suas
contribuições em problemas de
Engenharia de Sistemas
–
infraestrutura, sistemas operacionais
& rede, bancos de dados
–
disponibilidade, observabilidade,
eficiência e confiabilidade dos serviços
50% de suas
contribuições em problemas de
Engenharia de Software
–
design da aplicação, estruturas de dados,
design de serviços e integrações
–
tarefas de desenvolvimento que contribuam
para a confiablilidade do sistema

6. Objetivos da equipe SRE
Suportar
sistemas em
produção
Contribuir
para trabalho
no projeto
• Abordagem SRE para Operações:
• Trate as operações como um problema de
engenharia de software
• Automatize tarefas normalmente feitas por
administrações de sistema (como implantações)
• Projete arquiteturas de serviço mais confiáveis e
operáveis desde o início; não deixe para depois
Os SREs gastam menos de 50% do seu tempo realizando trabalho operacional para permitir
que eles gastem mais tempo na melhoria da infra-estrutura e automação de tarefas

7. Por que outro papel?
• A evolução dos sistemas requer uma evolução dos
engenheiros de sistemas
• A confiabilidade é geralmente deixada para os arquitetos
projetarem, tipicamente no início de um projeto de produto
• Os requisitos não funcionais não são revisados com tanta
frequência
• A mudança de funcionalidade pode afetar os requisitos de
confiabilidade assumidos anteriormente
• A maioria das paralisações são tipicamente causadas por
mudanças, e uma mentalidade típica de Ops não
necessariamente se prepara para uma solução rápida
• Sistemas “definidos por software”

8. Muro da Confusão
Desenvolvimento
Evolução
Agilidade
Operações
Estabilidade
Controle

9. DevOps vs. SRE?
SRE implementa DevOps
Um conjunto de princípios e diretrizes culturais que ajuda
a quebrar os silos entre desenvolvimento e operações
(infra)
• Reduza silos
• Planeje para falhas
• Mudanças em pequenos lotes
• Ferramentas & automação
• Meça tudo
Um conjunto de práticas com ênfase em fortes
capacidades de engenharia que implementa as práticas de
DevOps e define um papel e uma equipe
• Reduza silos compartilhando a propriedade
• Planeje paras falha usando orçamentos de erro
• Mudanças em pequenos lotes com foco na estabilidade
• Ferramentas & automação de tarefas manuais
• Meça tudo monitorando as coisas certas
DevOps SRE

10. Como SRE e DevOps se relacionam
SREs conectam atividades de Operações
com Desenvolvimento
• SRE muitas vezes atuam como
“guardiões da produção”
• Software sem qualidade é rejeitado e
SREs ajudam a evitar potenciais
problemas operacionais

11. Responsabilidade Compartilhada
Equipes de desenvolvimento participam do
suporte a aplicações em produções
• O trabalho do SRE pode fluir para equipes
de desenvolvimento
• 5% do trabalho operacional fica com os
desenvolvedores
• Participa dos plantões (mais comum no
início)
• Coloque o desenvolvedor no plantão assim
que os objetivos de confiabilidade forem
atingidos

12. Implantando SRE nas empresas
Site Reliability Engineering

13. Implantação de SRE em uma empresa
• Equipes SRE bem-sucedidas
dependem do compromisso de
toda a empresa
• Os valores da empresa devem estar
alinhados com a forma como a SRE
opera
Mandato
organizacional
“Buy-in” da gestão
Responsabilidades
Compartilhadas

14. Modelos de equipes SRE
Equipes Centralizadas de SRE
• Backlog comum com as melhorias de
confiabilidade de toda a organização
• Implementado uniformemente
• SREs são trazidos como parte dos
processos de design, revisão, validação,
go-lives
• Nível limitado de influência dentro da
equipe Exemplo:
Facebook (via Engenharia de Produção)

15. Modelos de equipes SRE
SREs dentro das equipes
• SREs incorporados como membros
das equipes em tempo integral como
parte das equipes de produtos:
• Tratado como um membro da equipe de
produtos
• Contribuição constante com desenho da
confiabilidade e implementação do produto Exemplo:
Google, Bloomberg, Uber

16. Métricas-chave
Tempo médio
para restaurar
o serviço
(MTTR)
Lead time para
implantação /
rollback
Monitoramento
aprimorado
(detectar
problemas mais
cedo)
Estabelecer
orçamentos de
erro (gestão de
risco baseada
em orçamento)

17. Contratação e Onboarding
Competências
• Curiosidade natural por sistemas; foco em automação
• Idealmente, indivíduos multi-qualificados que tenham
experiência em escrever e manter software
• Familiaridade e/ou interesse em arquitetura de sistemas
Perfil
• Sys Admins que estejam dispostos a aprender scripting /
programação; ou
• Desenvolvedores que estejam dispostos a assumir funções
de infraestrutura
• SRE Bootcamps: sessões com insights
sobre a arquitetura do sistema, processo
de entrega de software e operações
• Plantão com membros seniores da SRE
• Participação nas chamadas de resposta a
incidentes
Contratação Onboarding

18. Orçamento de Erros
Site Reliability Engineering

19. Medindo a confiabilidade
• Fácil de medir através de meios automáticos (por
exemplo, tempo de atividade do servidor)
• Difícil julgar o sucesso para sistemas distribuídos
• Não diz muito sobre a experiência experiência do
usuário
• Mede o valor para usuários reais para os quais o
serviço está funcionando
• Melhor para medir sistemas distribuídos
Disponibilidade =
Uptime real
Uptime previsto
Disponibilidade =
Boas interações
Total interações

20. Orçamento de erro
100% - <meta de disponibilidade> =
Orçamento de “inconfiabilidade”
• Ou o “Orçamento de Erro”
• SRE e Gestão de Produtos definem
conjuntamente uma meta de disponibilidade
• Depois disso, um orçamento de erro é
estabelecido
• O monitoramento (via tempo de atividade) é
definido no local para medir o desempenho +
métricas em relação ao objetivo
• Um loop de feedback é criado para manter /
utilizar o orçamento

21. Benefícios de ter Orçamentos de Erro
• Os orçamentos de erro tornam-se
uma métrica rastreável explícita
que conecta o planejamento de
novas funcionalidades do produto
à confiabilidade do serviço
• Responsabilidade compartilhada pelo uptime
• Falhas de funcionalidade, bem como problemas de
infraestrutura, caem no mesmo orçamento de erro
• Incentivo comum para equipes de produtos e SREs
• Cria um equilíbrio entre confiabilidade e inovação
• As equipes de produtos podem priorizar recursos
• A equipe agora pode decidir onde e como gastar o
orçamento de erro
• Metas de confiabilidade tornam-se críveis e
alcançáveis
• Fornece uma abordagem mais pragmática para definir uma
disponibilidade realista

22. Janela de indisponibilidade
Meta Janela de indisponibilidade permitida
Por ano Por 30 dias
95 % 18.25 dias 1.5 dias
99 % 3.65 dias 7.2 horas
99.9 % 8.76 horas 43.2 minutos
99.99 % 52.6 minutos 4.32 minutos
99.999 % 5.26 minutos 25.9 segundos
A criação de uma meta de confiabilidade depende da natureza
do negócio
Pergunta: Por que 100% de confiabilidade não é uma boa ideia?

23. Níveis de Serviço
• A Gestão dos Produtos, em conjunto com
os SREs, define níveis de serviço para os
sistemas como parte do design do
produto
• Os níveis de serviço nos permitem:
• Equilibrar recursos que estão sendo construídos
com confiabilidade operacional
• Qualificar e quantificar a experiência do usuário
• Definir as expectativas dos usuários para
disponibilidade e desempenho

24. Níveis de serviço
Service Level Agreement
(SLA)
• Um contrato comercial
do prestador de
serviços + o cliente
• Perda de serviço pode
estar relacionada à
perda de negócios
• Normalmente, uma
violação de SLA
significaria alguma
forma de compensação
ao cliente
Service Level Objective
(SLO)
•Um limiar além do
qual uma melhoria do
serviço é necessária
•O ponto em que os
usuários podem
considerar a abertura
de chamado de
suporte, o "limiar da
dor“ - por exemplo, o
buffer do YouTube
•Impulsionado pelas
necessidades dos
negócios, não apenas
pelo desempenho
atual
Service Level Indicator
(SLI)
•Medida quantitativa
de um atributo do
serviço, como
throughput, latência
•Diretamente
mensurável e
observável pelos
usuários – não uma
métrica interna
(tempo de resposta
versus utilização da
CPU)
•Pode ser uma forma
de representar a
experiência do
usuário

25. Exemplo de Nível de Serviço
Service Level Indicator (SLI)
Latência de respostas HTTP bem-sucedidas (HTTP
200)
Service Level Objective (SLO)
Latência de 95% das respostas deve ser inferior a
200ms
Service Level Agreement (SLA)
Cliente compensado se a latência do percentil 95
exceder 300ms

26. Esgotando um orçamento de erro
Pergunta: o que você pode fazer se
esgotar o orçamento de erro?
• Nenhum novo recurso é lançado (por
um período de tempo)
• Muda a velocidade das atualizações
• Prioriza-se os esforços de engenharia
para aumentar a confiabilidade
Enquanto houver orçamento de
erro restante (em uma janela de
tempo), novos recursos podem
ser implantados

27. SRE “Golden Signals"
• Focado mais no tempo de atividade
para deduzir disponibilidade versus
experiência do usuário
• Monitorar métricas do sistema (como
CPU, memória, armazenamento) é
importante, mas pode não significar
nada para a experiência do cliente
• "Sobrecarga de ruído"
Saturação Erros
Tráfego Latência
É melhor definir SLIs & SLOs usando
esses “sinais dourados”, pois eles leva
em conta a percepção do usuário
sobre o sistema

28. Próximos passos
Site Reliability Engineering

29. Comece sua própria jornada SRE!
Reconheça
Falhas são inevitáveis, é
melhor planejar para isso
Buy-in
Liderança & alta gestão
Cultura
Crie uma cultura de auto-
aperfeiçoamento
Competências
Procure por indivíduos
multiqualificados que
foquem na colaboração

30. O que fazer
• Selecione um sistema “piloto”
• Identifique seus SLI/SLO
• Crie uma baseline para o estado
atual
• Atualize gradualmente os sistemas
e processos para atender ao SLO
• Enxágüe e repita ☺

31. O que NÃO fazer
• Renomear sua equipe de infraestrutura para SER
• Isso não é SRE!
• Tratar os SREs como equipes de infraestrutura
• E não como desenvolvedores de software
• SLO de 100%
• É melhor planejar para as falhas
• Muitas interações estão fora de seu controle
• Transformação em silos
• Acredite que as equipes estão dispostas a mudar
• Melhor envolvê-los como parte da jornada de transformação
• Ex.: Gestão de Mudanças, Gerenciamento de Incidentes,
Segurança

32. Para saber mais

33. Obrigado!
Um guia para melhorar a confiabilidade das aplicações em
produção
Igor Abade V. Leite | @igorabade
• Microsoft Regional Director
• CEO, CloudMotion (www.cloudmotion.com.br)