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!
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
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)
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)
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.
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
35.
36. Por volta de 5% positivo
no final. Ainda dá para
assumir o risco de fazer
mais o que?
37.
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
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
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
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)
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.