3 - Aceitando Riscos

SRE - Aceitando Riscos

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
3 - Aceitando Riscos por Mind Map: 3 - Aceitando Riscos

1. 1 - Objetivo

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.

1.2. 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. 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 reduzir todos os fatores a uma única métrica?

3.2.1. Falhas de serviço

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 down time não planejado

3.3.1.1. Nível desejado de disponibilidade do serviço

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. A fórmula e uma tabela com valores pode ser encontrada na bibliografia.

3.3.2. Em sistemas distribuídos globalmente é melhor usar uma abordagem baseada em Taxa de requisições bem-sucedidas.

3.3.2.1. Sistemas distribuídos globalmente apresentam dificuldades para determinar o Up time e o Down time.

3.3.2.1.1. Pode ainda incluir diferenças entre os tipos de requisição

3.3.2.1.2. Pode ser usada tanto em sistemas que servem diretamente ao usuário final, como em sistemas internos.

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 ma 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 negocio em objetivos explícitos.

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. Quão resiliente é o o nosso negócio em relação ao down time do serviço?

4.2.3.2. O que é pior para ao serviço?

4.2.3.2.1. Uma taxa constante de falhas ou interrupções?

4.2.3.2.2. Interrupção ocasional do site todo?

4.2.3.3. Exemplo

4.2.3.3.1. Aplicativo de contatos

4.2.3.3.2. Google Ads

4.2.4. Usar o custo do serviço para dimensionar os riscos.

4.2.4.1. Fator essencial para determinar a meta de disponibilidade.

4.2.4.1.1. 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. Entender quais métricas são importantes, e quais não são importantes, proporciona alguns graus de liberdade para assumir riscos planejados.

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. Meta de nível de disponibilidade

4.3.1.1.1. Tem vários clientes com necessidades variadas

4.3.1.2. Tipos de Falhas

4.3.1.2.1. Latência X throughput - Sucesso e falha são opostos para estes 2 tipos de usuários.

4.3.2. Como resolver?

4.3.2.1. Conceber os serviços de infraestrutura como super confiáveis...

4.3.2.2. Muito caro

4.3.3. Proposta SRE

4.3.3.1. Oferecer serviços com níveis explicitamente definidos permitindo assim que os clientes façam negociações.

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

5. 5 - Quiz Time