SRE - Resumo
Estruturação da palestra SRE - Site Reliability Engineering
1. Conceitos
1.1. Modelo Atual
1.1.1. Usa administradores de Sistemas para:
1.1.1.1. Operar o serviço
1.1.1.2. Responder a eventos e atualizações
1.1.2. Trabalha com a divisão da equipe de administração e da equipe de desenvolvimento.
1.1.3. Vantagens
1.1.3.1. Fácil de implementar
1.1.3.2. Amplamente utilizado
1.1.3.3. Ferramentas já consolidadas no mercado
1.1.3.4. Facilidade em contratar pessoal
1.1.4. Desvantagens
1.1.4.1. Custos diretos
1.1.4.1.1. O aumento da complexidade ou tráfego do serviço gera um aumento proporcional:
1.1.4.2. Custos Indiretos
1.1.4.2.1. Equipe DEV e OPS
1.1.4.2.2. Resultado
1.2. O que é SRE?
1.2.1. Objetivo
1.2.1.1. Encontrar formas para aprimorar o design e a operação dos sistemas para fazê-los mais escaláveis, confiáveis e mais eficientes
1.2.2. É o que acontece quando você pede para um engenheiro de software projetar uma equipe de operações.
1.2.2.1. Engenheiros de Software fazem o papel de administrador do sistema
1.2.2.2. Com habilidades e pré disposição para desenvolver sistemas para automatizar os processos
1.3. SRE X DevOps
1.3.1. DEVOPS
1.3.1.1. Características
1.3.1.1.1. Envolvimento da TI em todas as fases do projeto e desenvolvimento de um sistema
1.3.1.1.2. Alta dependência de automação em comparação a esforços humanos
1.3.1.1.3. Aplicação de técnicas e ferramentas de engenharia nas tarefas de produção
1.3.1.2. Todas estas características são consistentes com o SRE.
1.3.1.3. O DEVOPS é uma generalização, um modelo...
1.3.1.3.1. Para ser aplicado em uma gama mais ampla de organizações, estruturas gerenciais e recursos.
1.3.2. SRE
1.3.2.1. É uma implementação do DEVOPS em um contexto especifico e com objetivos mais específicos
1.3.2.1.1. Serviços grandes e complicados
1.3.2.1.2. Voltado para serviços On Line - Sites
1.3.2.1.3. Objetivando principalmente disponibilidade e confiabilidade dos serviços
1.3.2.1.4. Em uma grande estrutura distribuída
2. Equipe SRE
2.1. A equipe SRE é composta por engenheiros de software que sustentam os produtos e criam sistemas para realizar o trabalho que, de outra forma, seria feito manualmente pelo Sysadmin
2.2. Perfil profissional
2.2.1. 50 a 60% Engenheiros de Software
2.2.1.1. Perfil 100% DEV
2.2.2. 40 a 50% quase engenheiros de Software
2.2.2.1. Perfil 85% DEV
2.2.2.2. 25%
2.2.2.2.1. Unix
2.2.2.2.2. Redes(Camada 1-3)
2.2.3. 100% da equipe tem que ter:
2.2.3.1. Aptidão para desenvolver sistemas complexos
2.2.3.2. Não gostar de tarefas enfadonhas e manuais
2.2.3.2.1. Tendem a automação dos processos
2.2.3.3. Focada em engenharia
2.2.3.3.1. Automatizar para evitar sobrecarga e aumento da equipe relacionado ao aumento da escala do sistema
2.2.3.4. Ter em mente a importância da documentação e da preparação
2.2.3.5. Ter consciência do que pode dar errado juntamente com um forte desejo de evitá-lo
2.2.3.6. Aprimoramento continuo
2.2.3.6.1. Aprender
2.2.3.6.2. Ensinar
2.3. Carga de Trabalho
2.3.1. 50% OPS
2.3.1.1. O objetivo é deixar o serviço estável e operacional
2.3.1.2. Este tempo tende a diminuir com a automação dos processos
2.3.2. 50% DEV
2.3.2.1. Automatizando processos para garantir que o sistema automaticamente se reparem e se mantenham funcionando, sem iteração humana.
2.4. Características
2.4.1. Inovação Rapida
2.4.2. Aceitação a mudanças
2.4.3. Custo relativamente baixo
2.4.3.1. A abordagem tradicional exigiria um número maior de pessoas na equipe
2.4.4. Relacionamento com outras equipes
2.5. Desafios
2.5.1. Contratação de profissionais
2.5.2. Falta de informações consolidadas
2.5.2.1. Como montar a equipe?
2.5.2.2. Como administrar a equipe?
2.5.3. Abordagem não Ortodoxa
2.5.3.1. Exige forte apoio da gerência
2.5.3.2. Exemplo
2.5.3.2.1. O SRE pode decidir interromper os lançamentos de novas versões em prol da estabilidade do ambiente
2.6. Responsabilidades da equipe
2.6.1. Disponibilidade
2.6.2. Latência
2.6.3. Desempenho
2.6.4. Eficiência
2.6.5. Gerenciamento de Mudanças
2.6.6. Monitoração
2.6.7. Respostas a emergências
2.6.8. Planejamento de capacidade
3. Princípios Fundamentais
3.1. Foco na engenharia
3.1.1. 50% OPS
3.1.1.1. Tarefas
3.1.1.1.1. Tickets
3.1.1.1.2. Plantão
3.1.1.1.3. Tarefas manuais, etc
3.1.1.1.4. 2 eventos em um turno de 8 a 12 horas
3.1.2. 50% DEV
3.1.2.1. Automatizando processos
3.1.2.1.1. Sistemas automatizados continuam dependendo de iterações humanas em certos momentos.
3.1.2.1.2. Sistemas automáticos são capazes de se reparar e escalar automaticamente, sem auxílio humano.
3.1.2.2. Quando a equipe gasta menos de 50% em DEV é necessário intervenção
3.1.2.2.1. Atribuindo bugs e tickets de volta para a equipe de desenvolvimento
3.1.2.2.2. Integrando os desenvolvedores na escala de plantão
3.1.2.2.3. Isso resulta em
3.2. Buscar a máxima rapidez nas mudanças sem perder estabilidade do serviço
3.2.1. Ritmo de Inovação X Estabilidade do produto
3.2.1.1. O SRE deve tratar este conflito em primeiro plano
3.2.2. Proposta SRE - Provisão para Erros - Error Budget
3.2.2.1. O que é?
3.2.2.1.1. Usado para resolver o problema entre DEV e OPS.
3.2.2.1.2. 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.2.2.2. Definindo metas
3.2.2.2.1. "100% é a meta de confiabilidade incorreta para basicamente tudo"
3.2.2.2.2. A definição da meta correta de disponibilidade é baseda nas regras do negócio
3.2.2.3. Definindo a provisão para erros
3.2.2.3.1. A provisão para erros será 1 - a meta de disponibilidade definida
3.2.2.3.2. A meta do SRE deixa de ser "Nenhuma interrupção no serviço"
3.2.2.4. Como "Gastar" a provisão para erros?
3.2.2.4.1. Gastar a provisão para riscos para obter o máximo de rapidez no lançamento de funcionalidades
3.2.2.4.2. Uma interrupção de serviço deixa de ser algo "Ruim"
3.3. Monitoração
3.3.1. Controle da disponibilidade e saúde de um sistema
3.3.2. Forma tradicional de monitoração
3.3.2.1. Observar um valor ou condição específica
3.3.2.2. Valores fora da faixa predefinida disparam alertas
3.3.2.3. Problema
3.3.2.3.1. Depende de uma pessoa para ver o alerta e tomar decisões
3.3.3. Proposta SRE
3.3.3.1. Seres humanos somente devem ser notificados quando houver necessidade de tomar uma atitude.
3.3.3.2. Alertas
3.3.3.2.1. Exige ação humana imediata
3.3.3.2.2. Em reposta a algo que está ocorrendo, ou que vai ocorrer
3.3.3.3. Tickets
3.3.3.3.1. Exige ação humana, mas com planejamento.
3.3.3.3.2. Esta ação evita que haja dano
3.3.3.4. Logging
3.3.3.4.1. Problema resolvido automaticamente
3.3.3.4.2. Registro de informação para disgnóstico
3.3.4. Os quatro sinais de ouro do Google
3.3.4.1. Latência
3.3.4.2. Tráfego
3.3.4.3. Erros
3.3.4.4. Saturação
3.3.5. As informações do monitoramento só são úteis se soubermos o que fazer com elas...
3.4. Resposta a Emergências
3.4.1. A confiabilidade de um sistema é medida em função de:
3.4.1.1. MTTF - Mean TIme To Failure
3.4.1.1.1. Tempo médio para falhas
3.4.1.2. MTTR - Mean Time To Repair
3.4.1.2.1. Tempo médio para correção
3.4.1.2.2. Métrica mais importante da eficiência da resposta
3.4.2. Intervenções humanas acrescentam latência
3.4.2.1. Mesmo com mais falhas, um sistema capaz de evitar emergências sem intervenção humana tende a ter uma disponibilidade melhor
3.4.3. Mas quando forem necessárias...
3.4.3.1. Criar um manual de melhores práticas resulta em uma melhoria de 3X no MTTR
3.4.3.1.1. Playbook
3.4.3.2. Exercícios de resposta a emergências também melhoram o MTTR
3.4.3.2.1. Wheel of Misfortune
3.5. Gerenciamento de mudanças
3.5.1. 70% das interrupções de serviço se devem a mudanças em um sistema ativo
3.5.2. Proposta SRE
3.5.2.1. Automação para:
3.5.2.1.1. Implementar rollouts (lançamentos) progressivos
3.5.2.1.2. Detectar problemas de forma rápida e precisa
3.5.2.1.3. Fazer rollback das mudanças de modo seguro quando surgirem problemas
3.5.2.1.4. Integração e entrega continua?
3.6. Previsão de demanda e planejamento de capacidade
3.6.1. Meio para garantir que haja capacidade suficiente e redundância para servir a uma demanda futura, com a disponibilidade necessária.
3.6.2. Levar em consideração
3.6.2.1. Crescimento Orgânico
3.6.2.1.1. Adoção natural do produto e do uso pelos clientes
3.6.2.2. Crescimento Inorgânico
3.6.2.2.1. Lançamento de novas funcionalidades
3.6.2.2.2. Eventos de marketing
3.6.2.2.3. Mudanças orientadas ao negócio
3.6.3. Como fazer?
3.6.3.1. Previsão exata da demanda orgânica
3.6.3.1.1. Com tempo de antecedência para aquisição de capacidade
3.6.3.2. Incorporação das fontes de demanda inorgânica na previsão da demanda
3.6.3.3. Testes regulares de carga
3.6.3.3.1. Capacidade bruta X capacidade do serviço
3.7. Provisionamento
3.7.1. Combina Gerenciamento de mudanças com planejamento de capacidade
3.7.1.1. Deve ser conduzido de forma rápida e somente quando necessário.
3.7.1.2. Deve ser conduzido de forma correta sob risco de a capacidade operacional não estar disponível quando necessária.
3.7.2. Envolve:
3.7.2.1. Ativar uma nova instância ou localização
3.7.2.2. Fazer modificação nos sistemas existentes
3.7.2.2.1. Arquivos de configuração
3.7.2.2.2. Distribuidores de carga
3.7.2.2.3. Redes
3.7.2.3. Validar a nova capacidade operacional
3.8. Eficiência e desempenho
3.8.1. O uso eficiente de recursos representa dinheiro.
3.8.2. Utilização eficiente de Recursos
3.8.2.1. Demanda(carga)
3.8.2.1.1. O SRE que prevê a demanda
3.8.2.1.2. Os sistemas se tornam mais lentos a medida que sua carga aumenta
3.8.2.2. Capacidade
3.8.2.2.1. Um serviço mais lento é equivalente a uma perda de capacidade.
3.8.2.2.2. O SRE faz um provisionamento para atender a uma meta de capacidade a uma velocidade específica de resposta.
3.8.2.3. Eficiência
3.8.2.3.1. O SRE pode modificar softwares
3.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.
3.8.2.3.3. Isso aumenta a capacidade e a eficiência do sistema
4. Princípios de funcionamento
4.1. Aceitando Riscos
4.1.1. Objetivo
4.1.1.1. O SRE trabalha essencialmente com a avaliação, gerenciamento e o uso de provisões para erros(error budget) para oferecer abordagens neutras e uteis ao gerenciamento de serviços.
4.1.1.2. Confiabilidade Máxima
4.1.1.2.1. Depois de certo ponto, aumentar a confiabilidade é pior para um serviço.
4.1.1.3. O SRE tem que equilibrar o risco da falta de disponibilidade com:
4.1.1.3.1. Metas de inovação
4.1.1.3.2. Operação eficiente
4.1.1.3.3. Satisfação dos usuários
4.1.2. Administrando Riscos
4.1.2.1. Sistemas não confiáveis podem minar a confiança do usuário
4.1.2.2. O custo não aumenta de forma linear com relação a confiabilidade
4.1.2.2.1. Uma melhoria na confiabilidade pode custar 100 vezes mais que o incremento anterior.
4.1.2.2.2. Custos
4.1.2.3. O SRE administra a confiabilidade de sistemas administrando riscos.
4.1.2.3.1. Alinhar o risco assumido por um serviço com o risco que o negócio está disposto a suportar
4.1.2.3.2. O serviço deve estar confiável o suficiente, mas não mais confiável do que o necessário.
4.1.2.3.3. Assumir riscos de forma explicita e bem planejada
4.1.3. Mensurando Riscos
4.1.3.1. Definir uma métrica objetiva para representar a propriedade que queremos otimizar no sistema
4.1.3.1.1. Permite avaliar o desempenho atual e monitorar melhorias ou degradações ao longo do tempo.
4.1.3.2. Dificuldade
4.1.3.2.1. Como reduzir todos os fatores a uma única métrica.
4.1.3.2.2. Falhas de serviço
4.1.3.3. Exemplos de mensuração de riscos
4.1.3.3.1. A forma mais simples de representar a tolerância a riscos de um sistema é em termos do nível aceitável de down time não planejado
4.1.3.3.2. Em sistemas distribuídos globalmente é melhor usar uma abordagem baseada em Taxa de requisições bem-sucedidas.
4.1.3.4. Periodicidade
4.1.3.4.1. Metas trimestrais
4.1.3.4.2. Monitoradas semanalmente ou até diariamente.
4.1.4. Tolerância dos serviços aos riscos
4.1.4.1. O SRE tem que trabalhar com o dono do produto
4.1.4.1.1. Transformar objetivos de negocio em objetivos explícitos.
4.1.4.2. Serviços voltados para consumidores finais
4.1.4.2.1. Normalmente tem proprietários explícitos
4.1.4.2.2. Qual o nível de disponibilidade exigido?
4.1.4.2.3. Tipos diferentes de falhas tem efeitos diferentes no serviço?
4.1.4.2.4. Usar o custo do serviço para dimensionar os riscos.
4.1.4.2.5. Que outras métricas podem ser importantes?
4.1.4.3. Serviços de Infraestrutura
4.1.4.3.1. Requisitos diferem dos requisitos de sistemas voltados para os consumidores
4.1.4.3.2. Meta de nível de disponibilidade
4.1.4.3.3. Tipos de Falhas
4.1.4.3.4. Proposta SRE