A talk that I gave at the Pricefy HQ as an introduction to Site Reliability Engineering and how it relates to DevOps. As the traditional SRE saying goes "hope is not a strategy". So you better be prepared when reallity knocks the door. Enjoy!

1. Leandro Silva
https://github.com/leandrosilva
TechTalk
Jul-2019

2. Esperança não é
uma estratégia
Site Reliability Engineering

3. Indústria de software
tradicional

4. Constrói o que
não participou da
especificação
Opera o que
não participou
da construção
Sofre no
relacionamento
com o cliente
Uns perseguem velocidade de mudança Outros estabilidade
Todos querem ver o cliente feliz e satisfeito
No final

5. “Desenvolvimento
de software com
qualidade”
Cena do clássico
True Story Pictures (2000)

7. Silos Blame Culture

8. Como garantir confiança no produto entregue
sem a toxicidade da cultura do dedinho?

10. Site Reliability Engineering
{ engenharia de confiabilidade }

11. “Fundamentalmente, é o que acontece quando você pede para um
engenheiro de software projetar uma função de operação.”
Ben Treynor Sloss, Vice Presidente, Google Engineering, Fundador do Google SRE

12. Nasceu no Google em 2003, antes do movimento DevOps.
A missão era garantir a disponibilidade do site dentro de certas
expectativas pré-definidas e que qualquer mudança que se
pretendesse fazer levasse em conta os seus benefícios vs. os
riscos oferecidos à estabilidade esperada.
A idéia foi reunir um time que criasse uma ponte entre a gestão
de produto, o desenvolvimento e a operação, aplicando a
mentalidade de engenharia de software à infraestrutura e
operação de sistemas, de forma a automatizar tantas tarefas
humanas quanto possível.
Mais confiabilidade, menor custo total.
The Holy Book
(2016)

13. class SRE : DevOps

14. Todo problema é um problema de software.

15. Não estamos
falando apenas de
programação de
funcionalidades
de negócio.

16. O
p
e
r
a
ç
ã
o
Disponibilidade (quando está disponível para uso)
Latência (quanto tempo demora para responder a uma ação)
Performance (quanto de trabalho correto consegue executar)
Capacidade (quanto requer de recursos para operar satisfatoriamente)
Eficiência (quão bem estão sendo usados os recursos)
Mudança (como alterar o serviço sem quebrá-lo)

17. 01001110 11000011 10100011 01101111 00100000 01100101 01101110 01110100
01110010 01100101 01100111 01100001 01101101 01101111 01110011 00100000
01100010 01101001 01101110 11000011 10100001 01110010 01101001 01101111
01110011 00101100 00100000 01100101 01101110 01110100 01110010 01100101
01100111 01100001 01101101 01101111 01110011 00100000 01110011 01100101
01110010 01110110 01101001 11000011 10100111 01101111 01110011 00101110

18. 01001110 11000011 10100011 01101111 00100000 01100101 01101110 01110100
01110010 01100101 01100111 01100001 01101101 01101111 01110011 00100000
01100010 01101001 01101110 11000011 10100001 01110010 01101001 01101111
01110011 00101100 00100000 01100101 01101110 01110100 01110010 01100101
01100111 01100001 01101101 01101111 01110011 00100000 01110011 01100101
01110010 01110110 01101001 11000011 10100111 01101111 01110011 00101110
Não entregamos binários, entregamos serviços.

19. Reliability é a primeira
feature desejada para um
sistema de software.

20. É o quanto pode-se confiar que
um sistema está constantemente
disponível por dado período.
( re·li·a·bil·i·ty )

21. disponibilidade =
atividade
(atividade + inatividade)

22. Perseguindo
constantemente a
disponibilidade

23. Indicadores,
Objetivos e
Acordos1º

24. Indicadores (SLI)
● Latência das requisições
● Falhas de requisições
● Throughput de processos batches
● Número de arquivos PDF gerados
Tudo que tenha valor em ser medido.

25. Objetivos (SLO)
● Número absoluto ou intervalo para um
indicador que esteja sendo medido.
● PM e SRE definem juntos.
● Sua performance é comunicada pela
monitoração de seus indicadores.
● Novas funcionalidades são publicadas
somente se a estabilidade do serviço
estiver dentro dos objetivos.
● Quando atingidos, incentivos são
muito bem-vindos.

26. Acordos (SLA)
● São acordos legais firmados entre os
clientes e os provedores dos serviços.
● Tipicamente são baseados em SLO,
acrescidos de uma margem de
segurança para recuperação.
● Tem alguma repercussão quando são
quebrados.
● 100% é caro e inviável. (diminishing return)

27. exempli gratia (1)
SLI
Percentil 95 da latência da geração de PDF < 2 min por página nos
últimos 15 minutos.
SLO
Percentil 95 da geração de PDF terá sucesso 99,9% ao longo do ano.
SLA
Haverá crédito ao cliente se o percentil 95 da geração de PDF tiver
menos que 99,5% de sucesso ao longo do ano.

28. SLI
● Disponibilidade
● Latência
SLO
● Disponibilidade 97%
● Latência 90% para PDF < 1,5 min
● Latência 99% para PDF < 2 min
exempli gratia (2)

29. O que causa problemas em sistemas?

30. or change something

31. Error Budget

32. $
$
$
$
$
$
$
$
$
$

33. O objetivo de se estabelecer Error Budget é não
incluir mais variáveis em um sistema instável ou
com disponibilidade a quem dos objetivos.
(não)

34. Error Budget = 100% - SLO
100% - 99,9% = 0,1%
SLO = 99,9% disponibilidade/mês = 0,1% indisponibilidade/mês
Error Budget = 0,001 x 30 dias x 24 horas x 60 min = 43,2 min/mês

36. Por volta de 5% positivo
no final. Ainda dá para
assumir o risco de fazer
mais o que?

38. Você pode ter uma infraestrutura decente e software bem feito, e então,
gastar seu budget com mudanças que entreguem novas features para o
usuário e inovações para o negócio.
(ou)
Você pode desperdiçar seu orçamento de erros com uma infraestrutura
porcaria e correção de bugs em software mal feito.

39. Volte ao trabalho até que o serviço apresente a
disponibilidade esperada.
Error Budget insuficiente

40. Outages

42. Minimize os impactos rapidamente.
Faça uma post-mortem.
Aprenda com os erros.
Não deixe acontecer novamente.
Seja mais pessimista com seu código,
arquitetura, infraestrutura e usuário.
Log tudo.
Monitore preventivamente.
Automatize tarefas manuais.
Reduza ao máximo o “Toil” diário.

43. ● Não existe a pergunta: quem é o culpado? (blameless)
● Assume que as pessoas são inteligentes e bem intencionadas
● Mantém o foco no processo e na tecnologia
● Cria uma linha do tempo para entender onde aconteceu o que
● Obtém todos os fatos
● Cria bug para cada trabalho que precisa de follow-up
Filosofia da post-mortem

44. Recomendações

45. 1. Arquitetura de sistemas
2. Boas práticas de programação
3. Sistemas operacionais
4. Redes
Habilidades fundamentais:
Uma empresa pequena não precisa ter um time de SRE, mas pode aplicar os princípios de SRE.

46. Mikey Dickerson's Hierarchy of Reliability
Por onde começar?
Pode-se priorizar a saúde de um
serviço de modo semelhante a
como Abraham Maslow categorizou
as necessidades humanas.

47. ● The 12 Factor;
● Fonte única e versionada de configuração
do serviço;
● Forma rápida de fazer rollback;
● Monitoração (fique atento aos golden
signals: tráfego > erros > latência >
saturação);
● Log agregado para ter um único lugar
onde monitorar e usar na hora do
troubleshooting;
Must have nas aplicações:
● Métricas em um lugar único de onde tirar
dados estatísticos do serviço;
● Traceabilidade para saber onde passou
cada request (o problema pode ocorrer
em uma única máquina);
● Não seja ingênuo, seja pessimista, teste
tudo e ofereça um fallback amigável para
falhas;
● Feature flags;
● Canary releases.

48. 1. Reduza o tempo de detecção de falha
(↓time-to-detect / TTD)
2. Reduza o tempo de reparação de falha
(↓time-to-resolution / TTR)
3. Reduza o impacto % das falhas
(↓usuários / funcionalidades)
4. Reduza a frequência das falhas
(↓time-to-failure / TTF)
Invista tempo em melhorar a disponibilidade:

49. Quanto mais você avança no nível de disponibilidade,
mais você reduz a velocidade de mudanças, a.k.a.
publicação de novas funcionalidades e inovação.
Tem que ter essa consciência e buscar somente o
nível de disponibilidade suficiente para deixar o
cliente feliz.
Lembre-se do princípio de diminishing return.
Mais disponibilidade do que o necessário não é bom.
99%
99,9%
99,99%
10x esforço
10x esforço
Custo da disponibilidade:
não se esqueça...

50. Invista algum tempo sério em educar o seu cliente sobre a cultura
de confiabilidade de sistemas, porque se as integrações dos
sistemas dele com os serviços que você oferece estiverem
fragilizadas, ele terá uma impressão errada da disponibilidade dos
seus serviços e ficará infeliz com isso.
Customer Reliability Engineering

51. DevOps

52. Conjunto de práticas e cultura que promovem a quebra da barreira entre
desenvolvimento e operação com objetivo de fazer entregas melhores em um
espaço de tempo menor.
O que é?

53. O Zen de John Willis, Damon Edwards e Jez Humble:
CALMS

54. Redução dos silos organizacionais (“dev + ops” e não um time de
devops separado dos times de dev e de ops)
Aceitar que falhas acontecem (shit happens)
Implementar mudanças gradualmente (pacotes menores
diminuem o risco das implantações)
Potencializar ferramental e automação de tarefas (seja
preguiçoso e se livre do trabalho automatizando)
Medir tudo (como saber se um serviço está bom sem mensurar?
Qual a
estratégia?

55. class SRE : DevOps
lembra?
Essa é uma maneira prescritiva
de implementar concretamente
um conjunto de motivações e
expectativas.

56. DevOps SRE
Redução dos silos organizacionais
Compartilhar o “ownership” do
serviço entre PM, Dev e Ops
Aceitar que falhas acontecem
SLOs e Post-Mortems que não
apontam culpados
Implementar mudanças
gradualmente
Reduzir do custo de falhas, fazendo
implantações pequenas, canary
releases e feature flags
Potencializar ferramental e
automação de tarefas
Automatizar o trabalho do ano todo
Medir tudo
SLIs e medição do quanto de
trabalho manual precisa ser feito
diariamente (toil)

57. Não é um ou outro.

58. Não é um ou outro. É uma forma concreta de.

59. Conclusão

60. SRE nasceu no Google, uma empresa gigantesca, para eliminar os silos
que haviam entre PM, Dev e Ops e promover evolução sustentável do site
com máxima disponibilidade, sem desperdiçar recursos.
De lá para cá, muitas empresas implantaram SRE.
Empresas pequenas, startups, não precisam ter equipes dedicadas de
SRE, nem devem tentar copiar Google, Twitter, LinkedIn, New Relic, etc.
O que precisam, sim, é desenvolver a mentalidade de SRE desde cedo e
aplicar os princípios que levam progressivamente à confiabilidade dos
serviços.
Em um startup, todo desenvolvedor tem o boné de SRE na sua mesa.
Todo problema pode ser resolvido com código ⎼ tanto quanto possível.

61. Esperança não é uma
estratégia.
Trabalhe pela disponibilidade consistente do seu serviço.