No QCon de São Francisco, Michael Kehoe ministrou a palestra "Construindo aplicações prontas para a produção". Com base em sua experiência sobre a engenharia da confiabilidade dos sites (site reliability engineering - SRE), ele apresentou os princípios da preparação para a produção que todos os engenheiros das organizações devem focar, como: estabilidade e confiabilidade, escalabilidade e performance, tolerância a falhas e recuperação de desastres, monitoramento e documentação.
Kehoe, que é engenheiro de confiabilidade de site na equipe de produção da SRE no LinkedIn, iniciou a palestra referenciando o livro "Production Ready Microservices" de Susan Fowler e uma citação associada:
Um aplicativo ou serviço pronto para produção é aquele que pode ser confiável para atender ao tráfego de produção…
… Acreditamos que ele se comporta de maneira razoável, confiamos que ele funcione de forma confiável, confiamos nele para realizar o trabalho e para executar bem o trabalho com muito pouco tempo de inatividade.
As mudanças na arquitetura de software e no ciclo de vida de entrega de software na última década aumentaram os desafios de declarar a prontidão da produção e também forneceram novas oportunidades. Por exemplo, os aplicativos monolíticos foram decompostos em vários microsserviços, permitindo uma rápida iteração, rápida implantação e escalonamento individuais, mas também significa que mais serviços precisam ser verificados e operados. Novas técnicas, como integração contínua, combinadas com o surgimento de diferentes métodos de trabalho como o DevOps e o movimento SRE, significam que os engenheiros podem automatizar mais e seguir as melhores práticas estabelecidas para trabalhar em conjunto entre as disciplinas.
Para o princípio da estabilidade e confiabilidade, Kehoe começou defendendo a necessidade de ciclos estáveis de desenvolvimento e implantação. Neste contexto, a estabilidade é toda sobre "ter uma experiência de pré-produção consistente". No desenvolvimento, isso deve se concentrar em práticas de testes bem estabelecidas, revisões de código e integração contínua. Para a prática de implantação, os engenheiros devem garantir que as construções sejam repetíveis, que um ambiente de preparação (staging) esteja funcionando "igual à produção", e que um processo de lançamento canary[1] esteja disponível.
[1] O lançamento canary é uma técnica para reduzir o risco de lançar uma nova versão de software em produção, por meio do lançando gradual da alteração para um pequeno subconjunto de usuários, antes de distribuí-lo para todos os usuários.
O valor de um ambiente de preparação (staging) como um conceito pode ser discutível, mas se você tiver um, será necessário tratá-lo como produção, para obter plenamente seu valor.
A falta de confiabilidade nos sistemas baseados em microservices geralmente vem de alterações no tráfego de entrada ou de mudanças no comportamento de serviços de recebimento de dados. Os engenheiros devem entender o roteamento de tráfego de produção, balanceamento de carga, a descoberta de serviços e as suas verificações de integridade associadas. O gerenciamento de dependências é essencial (tanto do ponto de vista do serviço quanto do código), e a atenção deve ser focada no processo de integração do engenheiro e no compartilhamento das melhores práticas estabelecidas. Um tópico frequentemente negligenciado, mas muito importante, é o procedimento de descontinuação de serviços.
A discussão sobre o próximo princípio, escalabilidade e desempenho, começou com um enfoque na compreensão de "escalas de crescimento", ou seja, como cada serviço é dimensionado com metas de negócios e indicadores-chave de desempenho (KPIs). Os engenheiros devem estar cientes dos recursos, sabendo quais gargalos existem dentro do sistema e quais são as opções de escalonamento elástico. A avaliação de desempenho constante é necessária - idealmente, testar isso deve fazer parte do processo de integração contínua - e, portanto, entender o gerenciamento de tráfego de produção e o planejamento de capacidade que estão em vigor.
Em relação ao princípio de tolerância a falhas e a recuperação de desastres, os engenheiros devem estar cientes e evitar pontos únicos de falha no projeto e na operação. A compreensão de conceitos existentes nas disciplinas de engenharia de resiliência e nas disciplinas de engenharia do caos também são altamente benéficas no mundo dinâmico e efêmero da computação em nuvem. Garantir que uma equipe saiba como reagir a falhas e gerenciar incidentes - por exemplo, criando planos de desastre e executando dias de jogos - e, projetar e executar constantemente experimentos para testar suposições com modos de falha é algo vital.
O próximo princípio de prontidão discutido foi o monitoramento. Kehoe argumentou que painéis e alertas devem ser organizados ao nível de serviço, para alocação de recursos e infraestrutura. Todos os alertas devem exigir ação humana e, idealmente, apresentar procedimentos de correção pré-documentados e links para runbooks associados. O registro (log) também é um aspecto subestimado do desenvolvimento de software: engenheiros devem escrever instruções de log para auxiliar na depuração, e o valor dessas declarações deve ser verificado durante os experimentos de caos e dias em produção.
O último princípio a ser explorado foi a documentação. Deve haver uma página de aterrissagem (landing page) centralizada para documentação de cada serviço, e a documentação deve ser revisada regularmente (pelo menos a cada 3 a 6 meses) por engenheiros de serviço, SREs e partes interessadas relacionadas. A documentação do serviço deve incluir informações importantes, como portas e nomes de host, descrição, diagrama de arquitetura, descrição da API e informações de oncall e onboarding.
Resumindo a exploração dos princípios de prontidão, Kehoe discutiu como implementar diretrizes mensuráveis para ajudar na implementação e verificar as afirmações. O desafio é que, muitas vezes, os conceitos gerais de prontidão para a produção não são algo que pode ser diretamente traduzido em "algo que é verdadeiro ou falso" e, em vez disso, não pode ser pontuado ou medido diretamente. Uma alternativa é concentrar-se nos resultados de seguir diretrizes específicas de prontidão.
Existe valor na criação de listas de verificação manuais para medir diretrizes e resultados associados, especialmente quando uma equipe está apenas começando a explorar os princípios da prontidão, mas o valor real é fornecido por meio da geração automatizada de indicadores de prontidão. Kehoe demonstrou várias estruturas internas de verificação de serviço automatizado do LinkedIn e os painéis associados que são usados para orientar a implementação e a verificação de prontidão.
Os principais aprendizados da palestra foram resumidos como: criar um conjunto de diretrizes para o que significa que um serviço estar "pronto"; automatizar a verificação e pontuação dessas diretrizes, e; como definir as expectativas entre as equipes de produto, engenharia e SREs, de que essas diretrizes devem ser atendidas como parte de uma "definição de feito".
É possível baixar os slides da palestra de Kehoe, "Building Building-Ready Applications", no site do evento. A gravação completa da apresentação será disponibilizada no InfoQ.com nos próximos meses.