Nessa palestra falamos sobre a cultura devops e como desenvolvimento e operações evoluíram para um modelo mais moderno e equilibrado.

1. Site Reliability Engineering
Como desenvolvimento e operações evoluíram para um
modelo mais moderno e equilibrado

2. - Desenvolvimento: Toda atividade relacionada a desenvolver novas features,
corrigir bugs e reduzir o débito técnico
- Operações: Atividades voltadas à manutenção e configuração de servidores e
infraestrutura
- Deploy: Ação de publicar novas versões de um determinado software
Glossário

3. Devs
Objetivos: Desenvolver e publicar software, com
alterações e novas features
Antes de tudo, como era antes?
Sysadmins:
Objetivos: Manter os sistemas estáveis e
funcionais

4. Surgem os conflitos de interesse
Times disfuncionais e custos
diretos e indiretos
Toda nova publicação
pode potencialmente
quebrar os sistemas
rodando
Demoras e restrições
para publicar novas
features e correções de
bug geram o custo de
oportunidade
+

6. Cultura
Devops
Uma combinação de práticas unindo dev e operações, visando diminuir o tempo do
ciclo de desenvolvimento e promover entrega contínua

7. Desenvolvimento
Integração contínua (CI)
Testes automatizados
Entrega Contínua (CD)
Configuração
Monitoramento
Práticas DevOps

8. SRE
Conceito introduzido pelo Google com diversas práticas e conceitos visando a
confiabilidade de sistemas.

9. Sistemas instáveis degradam a
confiança do usuário e trazem
diversos prejuízos.
Gerenciando o
risco e
melhorando a
estabilidade

10. Nem sempre um sistema estável ao
extremo é a melhor solução
Custos e riscos de
uma alta
disponibilidade

11. Custo de recursos redundantes
Para termos uma disponibilidade alta, uma das estratégias mais comuns é a
redundância de recursos, onde disponibilizamos a mesma aplicação em vários
servidores diferentes

12. Custo de oportunidade
Ao escolher aumentar a estabilidade, estamos abrindo mão de desenvolver novas
features e produtos

13. SLIs, SLOs e SLAs
SLI (Service level indicator): qualquer tipo de
métrica relacionada com a disponibilidade, como
latência, throughput e quantidade de erros.
SLO (Service level objective): é o alvo desejado
para os SLIs definidos, geralmente usado
internamente.
SLA (Service level agreement): Um acordo,
geralmente formalizado por contratos e com
obrigações legais vinculadas.
Exemplo:
SLI: Latência dos requests
SLO: Deve ser menor que 300 milissegundos, para
uso interno do time
SLA: Deve ser menor que 500 milissegundos, com
consequências atreladas (multas ou outras
implicações legais)

14. O que é uma disponibilidade desejável?
Existem vários fatores a se considerar, como:
- Criticidade do serviço
- Riscos envolvidos nas falhas sistêmicas
- Esse serviço é ligado diretamente à receita da empresa?
- Existem competidores no mercado? Qual a disponibilidade que eles oferecem?

15. O que é uma disponibilidade desejável?

16. O que é uma disponibilidade desejável?

17. Um exemplo real: app engine do google cloud

18. Error budgets
Após definir a disponibilidade desejada, podemos definir nossos error budgets (algo
como orçamento para falhas) e com isso podemos ter decisões mais embasadas. Ex:
- Com 99.9% de SLA, podemos ter 8h de downtime por ano ou 2h por trimestre.
- Se no meio do ano já tivemos 7h de downtime, quer dizer que estamos quase
passando os objetivos, então devemos trabalhar mais em estabilidade
Novas features Estabilidade

19. Metrificando quantidade de erros por semana

20. Metrificando tempos de resposta

21. Mas e o cargo de SRE/Devops?
- Geralmente as pessoas nesse papel irão
cuidar da estrutura e auxiliar diversos times
com automações, ferramentas de
observabilidade e entrega contínua por conta
do background mais especializado
- Importante lembrar que gerir a
confiabilidade dos sistemas é dever de todos.
Isso evita aquela separação entre
desenvolvimento e operações mencionada
anteriormente.

22. “Hope is not a
strategy.”
- Traditional SRE saying

23. Obrigado!
Dúvidas, sugestões?
Referências e livros completos:
https://sre.google/books/