Pronto pra produção?

Como desenvolvedores, escrevemos código na firma para resolver algum problema de negócio para que ela consiga se manter atendendo clientes/usuários, idealmente entregando algum valor pra sociedade e ganhando dinheiro com isso. Manter aplicações em produção, que precisam constantemente mudar para acompanhar as necessidades de negócio, ser confiáveis, disponíveis e previsíveis ao longo do tempo de vida é algo que exige esforço e planejamento constantes.

Para um negócio que depende diretamente de Engenharia de Software para crescer, existem vários indicadores de performance que estão diretamente ligados ao nosso trabalho, mas vou citar só alguns convenientes pro ponto que quero abordar. 😝

• Lucratividade: Custo de operação é um vetor muito importante para definição do lucro ao longo do tempo. Dinheiro não é infinito e a maioria dos negócios digitais apostam em crescimento da base de usuários e na Economia de escala. Com o advento das clouds, nunca foi tão fácil gastar mais dinheiro do que o necessário para resolver determinado problema. Além disso, se iterações no software exigem uma fricção maior do que a necessária, por falta de conhecimento dos responsáveis e/ou qualidade da base de código, o desenvolvimento se torna mais demorado e mais caro.

• Disponibilidade: Estamos acostumados a sempre ter acesso a uma tela pronta para ser operada, seja um notebook, celular, TV, … Quando a bateria acaba, ficamos sem sinal ou esgotamos nosso plano de dados, a experiência não é a mesma, né? Se o produto existe, mas não pode ser utilizado, não há entrega de valor. Na era do imediatismo, problemas crônicos de disponibilidade tendem a gerar estresse e abalo de confiança podendo representar um risco para sobrevivência e sucesso de um produto.
• Nível de qualidade de serviço: Lá pra 2018, morando no centro do Rio de Janeiro, eu tinha uma TV 4K e uma internet nada estável de 2Mb da Oi. Consegue imaginar como era tentar ver algum video em 4K no YouTube? Só fui de fato usufruir da imagem da TV mais de 1 ano depois, após um upgrade no plano de internet. O Software desenvolvido precisa atender e acompanhar as expectativas dos clientes.

• Ticket médio: Já pagou por algo que depois se arrependeu ou a conta de um restaurante que foi mal atendido? Você provavelmente não voltou mais no restaurente. Assim como o desenvolvimento de novas features em um software pode levar o seu produto a ter um valor de mercado maior ou a expandir o público alvo, uma experiência ruim ou incompleta pode levar a perda de clientes, valor de mercado mais baixo ou até mesmo cenários mais graves, como perda de dinheiro em ações judiciais.
• Índice de Turnover: O mercado de engenharia de software está extremamente aquecido no mundo todo. Isso significa que o tempo de vida do software tende a ser maior do que a permanência dos desenvolvedores. Se um software depende de um humano específico para ser desenvolvido e operado com eficiência, dá pra imaginar o que acontece quando esse desenvolvedor não estiver mais presente, né?

Ao longo do tempo, fui criando opinião sobre o conjunto de boas práticas que julgo necessárias para garantir um impacto positivo nesses indicadores. Quando entro em contato com um novo software que eu tenha que interagir ou criar, tento responder algumas perguntas:

👩🏻‍💻 Ciclo de desenvolvimento

• Existem testes adequados do tipo lint (análise estática de código)? Quais os cenários não cobertos?
• Existem testes fim-a-fim adequados?
• Existem testes adequados para validar os pontos de integração com outros serviços?
• O código-fonte é versionado?
• Existe um guia de contribuição para que novos desenvolvedores saibam como abordar a base de código?
• Existe uma política de code review para garantir que mais de um desenvolvedor seja responsável pela validação de qualidade das mudanças?
• O processo de build e teste é automatizado? Rodam a cada commit na ferramenta de CI?
• Existe uma política de cobertura de testes? O nível de cobertura é conhecido?
• Códigos que reduzem a cobertura de testes podem ser mergeados na branch principal?

🔧 Gerenciamento de Configuração

• É possível alterar a configuração da aplicação sem uma nova build?
• É possível alterar a configuração da aplicação sem um novo deploy?
• Existe versionamento de configuração?
• É possível indentificar qual era a configuração da aplicação em determinado momento?
• Configurações contendo dados sensíveis são tratadas de forma adequada?

🚀 Pipeline de Deploy

• Existe um pipeline de deploy automatizado?
• Existe uma fase de homologação em um ambiente replicado?
• Todo o ambiente está replicado ou só parte dele?
• Testes em ambiente de homologação são realizados antes de liberados para produção? (end-to-end, carga, etc.)
• O ambiente de homologação tem algum acesso ao ambiente de produção ou são ambientes totalmente isolados?
• Existe deploy canário na pipeline? Quando uma nova versão da aplicação vai para o ambiente de produção, ela substitui gradualmente a versão anterior ou é liberada para toda a base de clientes?
• Existe um procedimento rápido para pular etapas de qualidade em caso de emergência?
• Existe uma forma fácil de fazer rollback de uma versão defeituosa caso necessário?

🏎 Escalabilidade e desempenho

• Qual a escala de crescimento quantitativo/qualitativo do serviço? Qual foi o crescimento de uso nos últimos meses?
• Tecnologias de abstração e alocação de recursos fazem parte da solução?
• Quais são os requisitos de recursos do serviço (CPU, RAM, etc….)?
• Quanta CPU uma instância precisa? Lida bem com múltiplos núcleos?
• Quanta RAM uma instância precisa?
• Qual o tráfego que 1 instância consegue lidar? Quantos clientes é possível atender?
• Existem requisitos de recursos específicos como acesso a disco, rede de alto desempenho, acesso a GPU, …?
• Quais os gargalos de recurso da aplicação?
• A aplicação precisa ser escalada verticalmente, horizontalmente ou ambos?
• Existe política que garanta escalabilidade automática de recursos?
• Qual o percentual ideal de uso de cada recurso? (Usado / Disponível)
• Quanto custa manter uma instância em produção?

🏗 Dependências

• Quais as dependências dessa aplicação?
• Existe verificação automática de atualização de dependências de pacotes?
• As dependências estão listadas de forma a gerar builds determinísticas?
• São implementados mecanismos de quebra de circuito para as dependências?
• As dependências são escaláveis e de desempenho equivalente ao necessário pelo aplicação?
• Se são escaláveis, elas vão escalar automaticamente quando a aplicação demandar por mais recursos?

📈 Tráfego

• Os padrões de tráfego são previsíveis?
• Os padrões de tráfego são bem entendidos pelo time?
• As mudanças no serviço são programadas de acordo com o tráfego?
• O aumento abrupto de tráfego é tratado de forma adequada?
• O tráfego pode ser redirecionado para outros ambientes em caso de problemas físicos em um Datacenter?

📝 Logging

• O log reflete o estado do serviço em qualquer momento?
• O log é financeiramente escalável?
• Os logs são corretamente separados em níveis adequados?
• O serviço grava todas as informações relevantes para depuração de problemas?
• Por quanto tempo logs são retidos?
• Os logs são facilmente indexáveis, buscáveis e agrupáveis (log estruturado, em json…)?
• É possível rastrear os eventos em todo o sistema a partir de um log específico de alguma aplicação?
• Os nossos logs salvam informações sensíveis? Se sim, é possível controlar o acesso a essas informações?

📊 Métricas

• Quais são as principais métricas de saúde? Consigo saber através de dados e com facilidade se a aplicação está fazendo o que deveria ou se tem algo de errado?
• Quais são as métricas de servidor e infra?
• As métricas existentes são confiáveis e refletem a realidade do serviço em qualquer momento?
• As métricas possuem visualizações para serem monitoradas e possuem alertas?

⚠️ Alertas

• Existem alertas para todas as métricas principais?
• Todos os alertas definidos estão configurados com níveis adequados?
• Os alertas são configurados de forma em que o time seja notificado antes que haja uma interrupção de serviço?
• Existem instruções para triagem e atuação nos alertas?
• Os responsáveis por atuarem em um determinado evento são capacitados e alinhados com a forma de agir sobre o incidente?

🔨 Processamento de Tarefas

• A aplicação está escrita em linguagem de programação compatível com as necessidades de escala e desempenho?
• Os desenvolvedores responsáveis entendem os fluxos de processamento de tarefas da aplicação?
• Existem limitações de escalabilidade conhecidas na forma como a aplicação processa as tarefas?

📂 Armazenamento

• Que tipos de dados a aplicação precisa armazenar?
• Qual o schema dos tipos de dados armazenados?
• A aplicação faz mais operações de escrita, leitura ou ambos?
• O armazenamento é escalado horizontalmente ou verticalmente?
• O armazenamento é compartilhado com outras aplicações?
• O armazenamento é replicado?
• O que acontece em caso de falha em uma instância de armazenamento?
• Há armazenamento de informações sensíveis? Há controle de acesso para essas informações?
• Quantas transações são feitas por minuto ou segundo?
• Qual a taxa de crescimento dos dados a serem armazenados?
• Existe uma política de expurgo de dados?

🔄 Ciclo de Vida

• A aplicação passa por um período de warmup durante a inicialização?
• Tráfego é direcionado para a instância durante o warmup?
• A aplicação responde adequadamente a sinais de interrupção do SO?
• Existe graceful shutdown?
• O graceful shutdown pode ser realizado dentro do tempo de tolerância?

🤯 Caos, catástrofes e falhas

• Existem falhas conhecidas? Quais as falhas são comuns no ecossistema da aplicação?
• Como as falhas e interrupções impactam o negócio?
• Quais falhas internas podem derrubar a aplicação?
• Quais falhas de dependência podem afetar a aplicação?
• Existe um ponto único de falha? Ele pode ser eliminado ou contornado?
• São realizados testes de carga regulares?
• Os teste de carga incluem teste de caos?

Só porque eu gosto da cara desse moleque

⚠️ Essa é uma lista viva e contribuições nos comentários são bem vindas!
Nem todas as perguntas se aplicam a todos os casos e é importante sempre se questionar o que faz sentido para cada caso.