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
+
5.
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
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?
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
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