Planejamento de Nuvem e Observabilidade

O que é: o plano do que o negócio executa, o que ele monitora, o que acorda alguém, e quanto isso custa - escrito antes que qualquer coisa seja comprada.

Visão Geral

Calcula o menor plano de monitoramento que realmente detectaria a pior falha deste negócio, e então o constrói apenas quando solicitado. A saída padrão é uma recomendação curta, não um registro de serviço. O registro - CSV, SQL DDL, JSON Schema, mapeamento Notion - é produzido mediante solicitação, a partir de uma lista de campos para que os quatro não se afastem.

Camada: Camada 8: Operar. Adequado para: Estágio de Crescimento. Código da tabela: n/a.

A regra que esta tabela existe para impor: um alerta é um custo humano, então Alert Channel e Severity decidem se uma pessoa será acordada às 3 da manhã. Tudo mais nesta tabela existe para tornar essa decisão possível: o que o serviço faz (SLI Definition), como é um bom funcionamento (SLO Target), o que é medido (Dashboard URL), quanto custa (Monthly Cost Estimate), e - o campo que a maioria das tabelas omite - o que acontece quando o alerta dispara (Runbook URL). Um alerta sem runbook transforma um problema técnico em um problema de pânico.

A segunda regra: Phase é o campo que mantém isso acessível. Uma pilha de dez serviços com quatro sinais cada, em um plano de nível, ordenados pelo que mais prejudicaria o negócio. Um negócio sem desenvolvedor deve estar executando uma plataforma gerenciada e três alertas, não uma pilha de coletores.

Quando Usar Esta Habilidade

• monitoramento, observabilidade, alertas, tempo de atividade, "descobrimos com um cliente"
• SLI, SLO, taxa de erro, latência, p95, p99
• "o que devemos monitorar", "como sabemos que o site está fora do ar"
• resposta a incidentes, plantão, runbook, postmortem
• custo de nuvem, quanto está custando, o que devemos desligar
• "qual serviço devemos usar", VPS, contêineres, serverless, hospedagem gerenciada
• prontidão para incidentes, página de status, prevenção de tempo de inatividade

Não use para: código de aplicação, infraestrutura como código, ou um pipeline de implantação (devops-pipeline-designer, ci-cd-pipeline-builder no pacote de engenharia); uma revisão de arquitetura de segurança (security-and-privacy); ou um incidente real, que é uma situação ao vivo, não um plano.

Como Funciona

Siga o contrato de execução compartilhado. As regras específicas do módulo abaixo definem apenas campos de domínio, decisões, cálculos e restrições de segurança.

Etapa 1 - Identificar a intenção

Leia a solicitação e escolha a intenção antes de perguntar qualquer coisa.

• "planejar" / "configurar" / "precisamos" -> artefatos desejados; vá para a Etapa 2.
• "o site está fora do ar" / "está fora do ar" / "estamos fora do ar" -> um incidente, agora mesmo. Confirme a falha voltada para o usuário primeiro e aponte para o runbook; não construa nada.
• "quanto isso custa" / "revisar" / "auditar" -> uma revisão, não uma construção.
• "devemos usar" -> uma pergunta de decisão; responda com prós e contras, depois ofereça o registro.

Pergunte apenas se este é o fato ausente de maior valor; caso contrário, prossiga sem uma abertura:

P: O que quebra para o negócio se o site ou aplicativo ficar fora do ar por uma hora, e quem notaria primeiro - um cliente, um membro da equipe ou um sistema automatizado?

Etapa 2 - Pergunte apenas o que está faltando

Trate respostas ambíguas como não respondidas e pergunte qual opção explícita o usuário deseja. Registre valores desconhecidos como Unknown; Unknown não é zero. Um registro não deve ser Done quando uma verificação obrigatória falha.

Pule qualquer coisa já respondida. Pergunte o restante um de cada vez e pare assim que as respostas restantes não alterarem o plano.

• Falha - Qual é a coisa crítica para o negócio - o site, o formulário de reserva, o caixa, e-mail, uploads de arquivos? / Qual é a pior falha realista - fora do ar, lento, dados incorretos ou um e-mail que para de chegar silenciosamente? / Quanto tempo um cliente está disposto a esperar antes de reclamar, e quanto tempo antes de ir embora?
• Pilha - O que está realmente em execução hoje - hospedagem compartilhada, um VPS, uma plataforma gerenciada, uma ferramenta SaaS, contêineres? / Quem configurou, e essa pessoa ainda está disponível? / Existe um repositório, e quem pode implantar?
• Tráfego - Aproximadamente quantos visitantes, pedidos ou trabalhos por dia? / Existem picos sazonais ou de campanha que o alteram em uma ordem de magnitude? / Existem períodos de pico em que ser lento é pior do que estar fora do ar?
• Pessoas - Existe alguém que possa estar de plantão, e em quais horários? / Alguém já usa uma ferramenta pela qual o negócio paga? / Quem tem permissão para reiniciar algo às 3 da manhã?
• Dados e dinheiro - O que não pode ser perdido, e qual é o ponto de recuperação aceitável? / …