2 - Princípios Fundamentais

1. 7 - Provisionamento

1.1. Combina Gerenciamento de mudanças com planejamento de capacidade

1.1.1. Deve ser conduzido de forma rápida e somente quando necessário.

1.1.2. Deve ser conduzido de forma correta sob risco de a capacidade operacional não estar disponível quando necessária.

1.2. Envolve:

1.2.1. Ativar uma nova instância ou localização

1.2.1.1. Deixar o recurso pronto para utilização

1.2.2. Fazer modificação nos sistemas existentes

1.2.2.1. Arquivos de configuração

1.2.2.2. Distribuidores de carga

1.2.2.3. Redes

1.2.3. Validar a nova capacidade operacional

2. 1 - Foco na engenharia

2.1. 50% DEV e 50% OPS

2.2. 50% OPS

2.2.1. Tarefas

2.2.1.1. Tickets

2.2.1.2. Tarefas manuais, etc

2.2.1.3. Plantão

2.2.2. 2 eventos em um turno de 8 a 12 horas

2.2.2.1. Respeitar esta regra é importante

2.2.2.1.1. Mais do que isso impossibilita ao engenheiro aprender com o evento

2.2.2.1.2. Menos do que isso será desperdício de tempo.

2.2.3. O SRE tem que ter tempo suficiente para:

2.2.3.1. Tratar o evento

2.2.3.1.1. Restaurar o serviço

2.2.3.2. Postmortem

2.2.3.2.1. Geram memória de um incidente

2.2.3.2.2. Sem acusações

2.2.3.2.3. Conteúdo

2.3. 50% DEV

2.3.1. Automatizando processos

2.3.1.1. Sistemas automatizados continuam dependendo de interações humanas em certos momentos.

2.3.1.2. Sistemas autônomos são capazes de se reparar e escalar automaticamente, sem auxílio humano.

2.3.2. Ajustando os sistemas

2.3.2.1. Aumentar a eficiência

2.3.2.2. Aumentar a confiabilidade

2.3.3. Quando a equipe gasta menos de 50% em DEV é necessário intervenção

2.3.3.1. Atribuindo bugs de volta para a equipe de desenvolvimento - Postmortem

2.3.3.2. Integrando os desenvolvedores na escala de plantão

3. 2 - Buscar a máxima rapidez nas mudanças sem perder estabilidade do serviço

3.1. Proposta SRE - Provisão para Erros - Error Budget

3.1.1. Para que serve?

3.1.1.1. A provisão de erros oferece uma métrica clara e objetiva que determina até que ponto um serviço pode deixar de ser confiável.

3.1.1.2. Inovação X Estabilidade

3.1.1.2.1. Quando implementar novas funcionalidades?

3.1.1.2.2. Quanto focar em estabilizar as funcionalidades implementadas?

3.1.1.3. Qual o nível de tolerância a falhas de um novo software?

3.1.1.3.1. Uma tolerância alta pode gerar um produto frágil e não utilizável

3.1.1.3.2. Pouca tolerância gera um produto estável mas que ninguém vai querer usar.

3.1.1.4. Quantidade de testes para novas funcionalidades?

3.1.1.4.1. Poucos testes podem gerar interrupções no serviço, ou vazamento de dados.

3.1.1.4.2. Testes demais, poderá ocasionar a perda da oportunidade do mercado.

3.1.1.5. Frequência de implantação de versões

3.1.1.6. Estas decisões não podem ser determinadas por política, medo ou esperança

3.1.1.7. Esperança não é uma estratégia

3.1.1.7.1. A provisão de erros é uma métrica confiável que pode ser usada para orientar estas negociações.

3.1.2. Como fazer? - Definindo metas

3.1.2.1. "100% é a meta de confiabilidade incorreta para basicamente tudo"

3.1.2.1.1. Normalmente o usuário não poderá dizer qual é a diferença entre 100% e 99,999% de disponibilidade

3.1.2.2. A definição da meta correta de disponibilidade é baseada nas regras do negócio

3.1.2.2.1. Qual o nível de disponibilidade que deixará os usuários satisfeitos?

3.1.2.2.2. Qual as alternativas disponíveis para os usuários não satisfeitos?

3.1.2.2.3. O que acontece com a utilização do produto pelos usuários em diferentes níveis de disponibilidade?

3.1.3. Calculo da provisão de erros

3.1.3.1. A provisão para erros será 1 - a meta de disponibilidade definida

3.1.3.1.1. Meta Definida = 99,99%

3.1.3.1.2. Erro Budget = 0,01%

3.1.3.2. A meta do SRE deixa de ser "Nenhuma interrupção no serviço"

3.1.3.2.1. Passa a ser "Manter a confiabilidade dentro dos limites"

3.1.4. Como "Gastar" a provisão para erros?

3.1.4.1. O Ideal é gastar a provisão para riscos para obter o máximo de rapidez no lançamento de funcionalidades

3.1.4.1.1. Enquanto não gastou toda a sua provisão para erros, ainda tem espaço para inovação.

3.1.4.1.2. Quando a provisão para erros acaba, vamos dedicar tempo para estabilizar o sistema.

3.1.4.2. Uma interrupção de serviço deixa de ser o vilão

3.1.4.2.1. Passa a ser uma parte esperada do processo

3.1.5. Vantagens

3.1.5.1. Equilíbrio entre inovação e estabilidade

3.1.5.2. Orienta decisões no processo de DEV e OPS

3.1.5.3. Define regras claras

3.1.5.3.1. Metas rigorosas - Menos Inovação

3.1.5.3.2. Metas menos Rigorosas - Mais inovação

3.1.5.4. Responsabilidade em conjunto do SRE e DEV

3.1.5.4.1. Melhora a comunicação entre as equipes

3.1.5.4.2. Cria uma métrica em comum

3.1.6. Exceções - Bala de Prata

3.1.6.1. Pequeno numero de tokens

3.1.6.1.1. Stakeholders experientes

3.1.6.2. Usada em casos importantes

3.1.6.3. Não acumula

3.1.6.4. Considerado uma falha

3.1.6.4.1. Gera um Postmortem

4. 3 - Monitoração

4.1. Controle da disponibilidade e saúde de um sistema

4.2. Forma tradicional de monitoração

4.2.1. Observar um valor ou condição específica

4.2.2. Valores fora da faixa predefinida disparam alertas

4.2.3. Problema

4.2.3.1. Depende de uma pessoa para ver o alerta e tomar decisões

4.3. Proposta SRE

4.3.1. Seres humanos somente devem ser notificados quando houver necessidade de tomar uma atitude.

4.3.2. Alertas

4.3.2.1. Exige ação humana imediata

4.3.2.2. Em reposta a algo que está ocorrendo, ou que vai ocorrer

4.3.3. Tickets

4.3.3.1. Exige ação humana, mas com planejamento.

4.3.3.2. Esta ação evita que haja dano

4.3.4. Logging

4.3.4.1. Problema resolvido automaticamente

4.3.4.2. Registro de informação para diagnóstico

4.4. Os quatro sinais de ouro do Google

4.4.1. Latência

4.4.2. Tráfego

4.4.3. Erros

4.4.4. Saturação

4.5. As informações do monitoramento só são úteis se soubermos o que fazer com elas...

5. 4 - Resposta a Emergências

5.1. A confiabilidade de um sistema é medida em função de:

5.1.1. MTTD Meam Time To Detect

5.1.1.1. Tempo médio para detecção da falha

5.1.2. MTTR - Mean Time To Repair

5.1.2.1. Tempo médio para correção

5.1.2.2. Métrica mais importante da eficiência da resposta

5.1.3. MTTF - Mean Time To Failure

5.1.3.1. Tempo médio entre as falhas

5.1.3.2. Frequência esperada

5.2. Calculando o impacto

5.2.1. Impacto=(MTTD+MTTR)*MTTF

5.2.2. Diminuir o Impacto

5.2.2.1. Versões "Canário"

5.2.2.2. Planejar sistemas com modo degradado

5.3. Outras formas de diminuir o impacto

5.3.1. Melhorar MTTD

5.3.1.1. Monitoramento

5.3.1.2. Alertas

5.3.1.3. Monitorar cumprimento do SLO

5.3.2. Melhorar MTTR

5.3.2.1. Manuais

5.3.2.2. Automatização de tarefas

5.3.3. Melhorar MTTF

5.3.3.1. Execução do sistema em vários domínios de falhas

5.3.3.2. Redirecionamento de trafego

5.4. Intervenções humanas acrescentam latência

5.4.1. Mesmo com mais falhas, um sistema capaz de evitar emergências sem intervenção humana tende a ter uma disponibilidade melhor

5.5. Mas quando forem necessárias...

5.5.1. Playbook - Criar um manual de melhores práticas resulta em uma melhoria de 3X no MTTR

5.5.1.1. Procedimentos a serem executados

5.5.1.2. Fluxo do processo

5.5.1.3. Escalonamento de pessoas

5.5.2. Wheel of Misfortune

5.5.2.1. Exercícios de resposta a emergências também melhoram o MTTR

5.5.2.2. Simulações de problemas que já ocorreram no passado

5.5.2.3. Semanalmente um membro do SRE é escolhido para fazer a simulação

6. 5 - Gerenciamento de mudanças

6.1. 70% das interrupções de serviço se devem a mudanças em um sistema ativo

6.2. Proposta SRE

6.2.1. Versões canário

6.2.2. Automação para:

6.2.2.1. Implementar rollouts (lançamentos) progressivos

6.2.2.2. Detectar problemas de forma rápida e precisa

6.2.2.3. Fazer rollback das mudanças de modo seguro quando surgirem problemas

6.2.2.4. Integração e entrega continua?

7. 6 - Previsão de demanda e planejamento de capacidade

7.1. Meio para garantir que haja capacidade suficiente e redundância para servir a uma demanda futura, com a disponibilidade necessária.

7.2. Levar em consideração

7.2.1. Crescimento Orgânico

7.2.1.1. Adoção natural do produto e do uso pelos clientes

7.2.2. Crescimento Inorgânico

7.2.2.1. Lançamento de novas funcionalidades

7.2.2.2. Eventos de marketing

7.2.2.3. Mudanças orientadas ao negócio

7.3. Como fazer?

7.3.1. Previsão exata da demanda orgânica

7.3.1.1. Com tempo de antecedência para aquisição de capacidade

7.3.2. Incorporação das fontes de demanda inorgânica na previsão da demanda

7.3.3. Testes regulares de carga

7.3.3.1. Capacidade bruta X capacidade do serviço

8. 8 - Eficiência e desempenho de software.

8.1. O uso eficiente de recursos representa dinheiro.

8.2. Utilização eficiente de Recursos pelos sistemas

8.2.1. Demanda(carga)

8.2.1.1. Os sistemas se tornam mais lentos a medida que sua carga aumenta

8.2.1.2. O SRE que prevê a demanda

8.2.2. Capacidade

8.2.2.1. Um serviço mais lento é equivalente a uma perda de capacidade.

8.2.2.2. O SRE faz um provisionamento para atender a uma meta de capacidade a uma velocidade específica de resposta.

8.3. Eficiência do Software

8.3.1. O SRE pode modificar softwares

8.3.2. O SRE e o time de DEV devem monitorar, e se necessário modificar um serviço a fim de melhorar o seu desempenho.

8.3.3. Isso aumenta a capacidade e a eficiência do sistema

9. Quiz Time