2 - Princípios Fundamentais

Princípios fundamentais do SRE

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
2 - Princípios Fundamentais por Mind Map: 2 - Princípios Fundamentais

1. 1 - Foco na engenharia

1.1. 50% OPS

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

1.1.1.1. Tempo suficiente para

1.1.1.1.1. Tratar o evento

1.1.1.1.2. Postmortem

1.1.1.1.3. O tempo é importante

1.1.2. Tarefas

1.1.2.1. Tickets

1.1.2.2. Plantão

1.1.2.3. Tarefas manuais, etc

1.2. 50% DEV

1.2.1. Automatizando processos

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

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

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

1.2.2.1. Atribuindo bugs e tickets de volta para a equipe de desenvolvimento

1.2.2.2. Integrando os desenvolvedores na escala de plantão

1.2.2.3. Isso resulta em

1.2.2.3.1. Feedback para os desenvolvedores

1.2.2.3.2. Criação de sistemas mais eficientes

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

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

2.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.

2.1.1.1. Inovação X Estabilidade

2.1.1.1.1. Quando implementar novas funcionalidades?

2.1.1.1.2. Quanto focar em estabilizar as funcionalidades implementadas?

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

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

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

2.1.1.3. Quantidade de testes para novas funcionalidades?

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

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

2.1.1.4. Tempo de uso de versões beta

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

2.1.1.5.1. Esperança não é um estratégia

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

2.1.2. Definindo metas

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

2.1.2.1.1. Marca passos e freios ABS são exceções relevantes...

2.1.2.1.2. Nenhum usuário poderá dizer qual é a diferença entre 100% e 99,999% de disponibilidade

2.1.2.1.3. Existem muitos outros sistemas entre o usuário e o serviço

2.1.2.1.4. O esforço para conseguir 100% de disponibilidade não vai gerar vantagem para o usuário

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

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

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

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

2.1.3. Definindo a provisão para erros

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

2.1.3.1.1. Meta Definida = 99,99%

2.1.3.1.2. Erro Budget = 0,01%

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

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

2.1.4.1. Gastar a provisão para riscos para obter o máximo de rapidez no lançamento de funcionalidades

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

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

2.1.4.2. Uma interrupção de serviço deixa de ser algo "Ruim"

2.1.4.2.1. Passa a ser uma parte esperada do processo

3. 3 - Monitoração

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

3.2. Forma tradicional de monitoração

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

3.2.2. Valores fora da faixa predefinida disparam alertas

3.2.3. Problema

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

3.3. Proposta SRE

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

3.3.2. Alertas

3.3.2.1. Exige ação humana imediata

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

3.3.3. Tickets

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

3.3.3.2. Esta ação evita que haja dano

3.3.4. Logging

3.3.4.1. Problema resolvido automaticamente

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

3.4. Os quatro sinais de ouro do Google

3.4.1. Latência

3.4.2. Tráfego

3.4.3. Erros

3.4.4. Saturação

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

4. 4 - Resposta a Emergências

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

4.1.1. MTTF - Mean Time To Failure

4.1.1.1. Tempo médio para falhas

4.1.2. MTTR - Mean Time To Repair

4.1.2.1. Tempo médio para correção

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

4.2. Intervenções humanas acrescentam latência

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

4.3. Mas quando forem necessárias...

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

4.3.1.1. Playbook

4.3.1.1.1. Procedimentos a serem executados

4.3.1.1.2. Fluxo do processo

4.3.1.1.3. Escalonamento de pessoas

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

4.3.2.1. Wheel of Misfortune

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

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

5. 6 - Gerenciamento de mudanças

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

5.2. Proposta SRE

5.2.1. Automação para:

5.2.1.1. Implementar rollouts (lançamentos) progressivos

5.2.1.2. Detectar problemas de forma rápida e precisa

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

5.2.1.4. Integração e entrega continua?

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

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

6.2. Levar em consideração

6.2.1. Crescimento Orgânico

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

6.2.2. Crescimento Inorgânico

6.2.2.1. Lançamento de novas funcionalidades

6.2.2.2. Eventos de marketing

6.2.2.3. Mudanças orientadas ao negócio

6.3. Como fazer?

6.3.1. Previsão exata da demanda orgânica

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

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

6.3.3. Testes regulares de carga

6.3.3.1. Capacidade bruta X capacidade do serviço

7. 5 - Provisionamento

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

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

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

7.2. Envolve:

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

7.2.2. Fazer modificação nos sistemas existentes

7.2.2.1. Arquivos de configuração

7.2.2.2. Distribuidores de carga

7.2.2.3. Redes

7.2.3. Validar a nova capacidade operacional

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.2.3. Eficiência do Software

8.2.3.1. O SRE pode modificar softwares

8.2.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.2.3.3. Isso aumenta a capacidade e a eficiência do sistema

9. Quiz Time