Lista de verificação de prontidão de produção

A tradução do artigo foi elaborada especificamente para os alunos do curso "Práticas e ferramentas DevOps", que começa hoje!

Você já lançou um novo serviço em produção? Ou talvez você estivesse envolvido no apoio a esses serviços? Se sim, o que motivou você? O que é bom para a produção e o que é ruim? Como você treina novos membros da equipe em lançamentos ou manutenção de serviços existentes.

A maioria das empresas acaba adotando abordagens do “Velho Oeste” quando se trata de práticas de operação industrial. Cada equipe decide suas próprias ferramentas e práticas recomendadas por tentativa e erro. Mas isso muitas vezes afeta não apenas o sucesso dos projetos, mas também dos engenheiros.

Tentativa e erro criam um ambiente onde acusações e transferência de culpa são comuns. Com esse comportamento, fica cada vez mais difícil aprender com os erros e não repeti-los novamente.

Organizações de sucesso:

• perceber a necessidade de diretrizes para a produção,
• estudar as melhores práticas,
• iniciar discussões sobre questões de prontidão para produção ao desenvolver novos sistemas ou componentes,
• garantir o cumprimento das regras de preparação para produção.

A preparação para produção inclui um processo de “revisão”. A revisão pode ser na forma de uma lista de verificação ou de um conjunto de perguntas. As revisões podem ser feitas manualmente, automaticamente ou ambas. Em vez de listas estáticas de requisitos, você pode criar modelos de listas de verificação que podem ser adaptados a necessidades específicas. Dessa forma, os engenheiros podem herdar conhecimento e flexibilidade suficiente quando necessário.

Quando verificar se um serviço está pronto para produção?

É útil realizar uma verificação de prontidão de produção não apenas imediatamente antes da liberação, mas também ao transferi-la para outra equipe de operações ou para um novo funcionário.

Verifique quando:

• Você está lançando um novo serviço em produção.
• Você transfere a operação do serviço de produção para outra equipe, como o SRE.
• Você transfere a operação do serviço de produção para novos empregados.
• Organizar suporte técnico.

Lista de verificação de prontidão de produção

Há algum tempo, por exemplo, eu publicado lista de verificação para testar a prontidão para produção. Embora esta lista tenha sido originada de clientes do Google Cloud, ela será útil e aplicável fora do Google Cloud.

Design e Desenvolvimento

• Desenvolva um processo de construção repetível que não exija acesso a serviços externos e não dependa da falha de sistemas externos.
• Durante o período de design e desenvolvimento, defina e defina SLOs para seus serviços.
• Documente as expectativas quanto à disponibilidade de serviços externos dos quais você depende.
• Evite um único ponto de falha removendo dependências de um único recurso global. Replique o recurso ou use um substituto quando o recurso estiver indisponível (por exemplo, um valor codificado).

Gerenciamento de configurações

• Configurações estáticas, pequenas e não secretas podem ser passadas por meio de parâmetros de linha de comando. Para todo o resto, use serviços de armazenamento de configuração.
• Uma configuração dinâmica deve ter configurações de fallback caso o serviço de configuração esteja indisponível.
• A configuração do ambiente de desenvolvimento não deve estar relacionada à configuração de produção. Caso contrário, isto pode levar ao acesso do ambiente de desenvolvimento aos serviços de produção, o que pode causar problemas de privacidade e fuga de dados.
• Documente o que pode ser configurado dinamicamente e descreva o comportamento de fallback se o sistema de entrega de configuração estiver indisponível.

Gerenciamento de liberação

• Documente o processo de liberação em detalhes. Descreva como as versões afetam os SLOs (por exemplo, aumentos temporários na latência devido a falhas de cache).
• Documente lançamentos canário.
• Desenvolva um plano de revisão de lançamento canário e, se possível, mecanismos de reversão automática.
• Certifique-se de que as reversões possam usar os mesmos processos das implantações.

Observabilidade

• Certifique-se de que o conjunto de métricas necessárias para o SLO seja coletado.
• Certifique-se de diferenciar entre dados do cliente e do servidor. Isto é importante para encontrar as causas do mau funcionamento.
• Configure alertas para reduzir custos trabalhistas. Por exemplo, remova alertas causados ​​por operações de rotina.
• Se você usa o Stackdriver, inclua métricas da plataforma GCP em seus painéis. Configure alertas para dependências do GCP.
• Sempre propague rastreamentos recebidos. Mesmo que você não esteja envolvido no rastreamento, isso permitirá que serviços de nível inferior depurem problemas na produção.

Proteção e segurança

• Certifique-se de que todas as conexões externas estejam criptografadas.
• Certifique-se de que seus projetos de produção tenham a configuração correta do IAM.
• Use redes para isolar grupos de instâncias de máquinas virtuais.
• Use uma VPN para conectar-se com segurança a redes remotas.
• Documente e monitore o acesso do usuário aos dados. Certifique-se de que todo o acesso do usuário aos dados seja auditado e registrado.
• Certifique-se de que os endpoints de depuração sejam restritos por ACLs.
• Limpe a entrada do usuário. Configure limites de tamanho de carga útil para entrada do usuário.
• Certifique-se de que seu serviço possa bloquear seletivamente o tráfego de entrada para usuários individuais. Isso bloqueará as violações sem afetar outros usuários.
• Evite endpoints externos que iniciam muitas operações internas.

Planejamento de capacidade

• Documente como seu serviço é dimensionado. Por exemplo: número de usuários, tamanho da carga recebida, número de mensagens recebidas.
• Documente os requisitos de recursos para o seu serviço. Por exemplo: número de instâncias de máquinas virtuais dedicadas, número de instâncias do Spanner, hardware especializado como GPU ou TPU.
• Limitações de recursos do documento: tipo de recurso, região, etc.
• Documente as restrições de cota para a criação de novos recursos. Por exemplo, limitar o número de solicitações da API GCE se você usar a API para criar novas instâncias.
• Considere executar testes de carga para analisar a degradação do desempenho.

Isso é tudo. Vejo você na aula!

Fonte: habr.com