1. 1 - Objetivo
1.1. Como o SRE trabalha?
1.1.1. Avaliação, gerenciamento dos riscos
1.1.2. Error Budget
1.1.3. Oferecem abordagens neutras e uteis
1.2. Problema da confiabilidade máxima
1.2.1. Depois de certo ponto, aumentar a confiabilidade é pior para um serviço.
1.2.2. Maximizar a confiabilidade limita a velocidade de inovação.
1.2.3. Aumenta drasticamente os custos
1.2.4. É imperceptível para os usuários
1.3. O SRE tem que equilibrar o risco da falta de disponibilidade com:
1.3.1. Metas de inovação
1.3.2. Operação eficiente
1.3.3. Satisfação dos usuários
2. 2 - Administrando Riscos
2.1. Porque administrar riscos é importante?
2.1.1. Sistemas não confiáveis podem minar a confiança do usuário
2.2. O custo não aumenta de forma linear com relação a confiabilidade
2.2.1. Uma melhoria na confiabilidade pode custar 100 vezes mais que o incremento anterior.
2.2.2. Custos
2.2.2.1. Redundância
2.2.2.1.1. Equipamentos
2.2.2.2. Oportunidade
2.2.2.2.1. Trabalho interno X Novas funcionalidades
2.3. O SRE administra a confiabilidade de sistemas administrando riscos.
2.3.1. Alinhar o risco assumido por um serviço com o risco que o negócio está disposto a suportar
2.3.2. O serviço deve estar confiável o suficiente, mas não mais confiável do que o necessário.
2.3.2.1. Isso seria perder uma oportunidade de acrescentar novas funcionalidades.
2.3.3. Assumir riscos de forma explicita e bem planejada
2.3.3.1. Error Budget
3. 3 - Mensurando Riscos
3.1. Definir uma métrica objetiva para representar a propriedade que queremos otimizar no sistema
3.1.1. Permite avaliar o desempenho atual e monitorar melhorias ou degradações ao longo do tempo.
3.2. Como medir o contentamento do cliente através de uma métrica?
3.2.1. Como medir?
3.2.1.1. Falta de satisfação
3.2.1.2. Danos ou perda de confiança
3.2.1.3. Perda direta ou indireta de receita
3.2.1.4. Impactos na marca
3.2.1.5. Todos fatores difíceis de mensurar...
3.3. Exemplos de mensuração de riscos
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 downtime não planejado
3.3.1.1. Nível desejado de disponibilidade do serviço
3.3.1.1.1. Relação entre o tempo online com o tempo total
3.3.1.1.2. Em uma janela de tempo
3.3.1.2. Em geral é expresso em números de "Noves"
3.3.1.2.1. 99,9%
3.3.1.2.2. 99,99%
3.3.1.2.3. 99,999%
3.3.1.2.4. Cada "nove" adicional representa uma melhoria em direção ao 100%
3.3.1.3. Calculado com base na proporção de Up Time do sistema.
3.3.1.3.1. Um sistema com meta de 99,99% pode estar inativo por até 52,56 minutos em um ano, e manter a sua meta de disponibilidade..
3.3.1.3.2. Isso dá 4 minutos de inatividade em um mês.
3.3.2. Sistemas distribuídos apresentam dificuldades para determinar o Uptime e o Downtime.
3.3.2.1. É melhor usar uma abordagem baseada em taxa de requisições bem-sucedidas.
3.3.2.1.1. Relação entre as requisições executadas com sucesso e o total de requisições validas.
3.3.2.1.2. Pode ainda incluir diferenças entre os tipos de requisição
3.3.2.1.3. Pode ser usada tanto em sistemas que servem diretamente ao usuário final, como em sistemas de infraestrutura.
3.3.2.2. Exemplo
3.3.2.2.1. Um sistema que atenda 2,5 milhões de requisições por dia com uma meta de disponibilidade de 99,99% pode apresentar até 250 erros e, ainda assim atingir sua meta para este dia.
3.3.2.2.2. A fórmula e uma tabela com valores pode ser encontrada na bibliografia.
3.4. Periodicidade
3.4.1. Metas trimestrais
3.4.2. Monitoradas semanalmente ou até diariamente.
4. 4 - Tolerância dos serviços aos riscos
4.1. O SRE tem que trabalhar com o dono do produto
4.1.1. Transformar objetivos de negócio em objetivos explícitos.
4.1.2. Serviços diferentes, objetivos diferentes
4.2. Serviços voltados para consumidores finais
4.2.1. Normalmente tem proprietários explícitos
4.2.1.1. Caso não tenha, falar com os desenvolvedores.
4.2.2. Qual o nível de disponibilidade exigido?
4.2.2.1. Levar em consideração:
4.2.2.1.1. Funcionalidade que o serviço oferece
4.2.2.1.2. Posicionamento de mercado
4.2.2.2. Perguntas
4.2.2.2.1. Qual o nível de serviço esperado pelos usuários?
4.2.2.2.2. Serviço diretamente ligado a geração de receita?
4.2.2.2.3. Serviço gratuito ou pago?
4.2.2.2.4. Tem concorrentes no mercado?
4.2.2.2.5. Qual o nível de serviço que os concorrentes oferecem?
4.2.2.2.6. Serviço voltado para consumidores ou empresas?
4.2.2.3. Exemplos contrastantes
4.2.2.3.1. Google apps for Works
4.2.2.3.2. Youtube
4.2.3. Tipos diferentes de falhas tem efeitos diferentes no serviço?
4.2.3.1. O que é pior para ao serviço?
4.2.3.1.1. Uma taxa constante de falhas ou interrupções?
4.2.3.1.2. Interrupção ocasional do site todo?
4.2.3.2. Exemplo
4.2.3.2.1. Aplicativo de contatos
4.2.3.2.2. Google Ads
4.2.4. Usar o custo do serviço para dimensionar os riscos.
4.2.4.1. O custo é um fator essencial para determinar a meta de disponibilidade.
4.2.4.1.1. Mas é necessário saber quantificar...
4.2.4.1.2. O quanto os sucessos ou falhas podem ser diretamente traduzidos em ganhos ou perdas de receita?
4.2.4.2. Perguntas
4.2.4.2.1. Se fossemos operar este sistema com um nove a mais de disponibilidade, qual seria o aumento de receita?
4.2.4.2.2. Esta receita adicional supera o custo para elevar a meta de disponibilidade?
4.2.5. Que outras métricas podem ser importantes?
4.2.5.1. Usar metas corretas
4.2.5.1.1. Proporciona alguns graus de liberdade para assumir riscos planejados.
4.2.5.1.2. Quais não são importantes?
4.2.5.1.3. Quais são importantes?
4.2.5.2. Exemplos
4.2.5.2.1. AdWords
4.2.5.2.2. AdSense
4.3. Serviços de Infraestrutura
4.3.1. Requisitos diferem dos requisitos de sistemas voltados para os consumidores
4.3.1.1. Tem vários clientes com necessidades variadas
4.3.1.1.1. Baixa latência e alta confiabilidade
4.3.1.1.2. Throughput
4.3.1.2. Meta de nível de disponibilidade
4.3.1.2.1. Latência X throughput
4.3.2. Como resolver?
4.3.2.1. Conceber os serviços de infraestrutura como superconfiáveis...
4.3.2.2. Muito caro
4.3.3. Proposta SRE
4.3.3.1. Oferecer serviços com níveis explicitamente definidos.
4.3.3.1.1. Permitindo assim que os clientes façam negociações.
4.3.3.1.2. Motiva o cliente a escolher o nível de serviço com menor custo que atenda as suas necessidades.
4.3.3.2. Particionar a infraestrutura e oferecer níveis de serviço independentes
4.3.3.2.1. Clusters de baixa latência e alta confiabilidade
4.3.3.2.2. Clusters para throughput
4.3.3.3. Oferecer garantias de serviço diferentes ajustando diversas características.
4.3.3.3.1. Quantidade de recursos
4.3.3.3.2. Grau de redundância
4.3.3.3.3. Restrições de provisionamento geográfico