Nos últimos posts, venho compartilhando fundamentos essenciais de DevOps, tais como: O que é DevOps? Definição, visão e antipatterns | Timeline DevOps e Gartner Hype Cycle | Adotando o DevOps e CALMS | Os benefícios do DevOps | Aprendizagem contínua, cultura livre de culpa e Blameless Postmortems | CI / CD – Continuous integration, delivery and deployment. Vale a leitura destes artigos acima, antes de dar continuidade a leitura deste post.

Já familiarizado com os conceitos acima, outra recomendação que posso compartilhar é o entendimento detalhado de algumas práticas de sucesso em DevOps, das quais resumo abaixo:

  • Blameless postmortemsBlameless é não culpar as pessoas pessoas pelas falhas, sabendo das responsabilidades inerentes da função. Veja mais no artigo.
  • Developers on call: cria um mecanismo de alinhamento, decisão e feedback muito rápido com o time. O artigo de Organizações Exponenciais explora as tecnologias sociais e como escalar rapidamente informações nos times.
  • Andon Cords: conceito utilizado pela Toyota – corda física para parada de linha (empodera qualquer um na linha de produção a parar em caso de problema). Ajuda a formar o senso de qualidade no time.
  • Infra as code: ajuda muito no planejamento do deploy e disaster recovery. Também permite que outras mudanças em DevOps aconteçam em alta velocidade.
  • Blue/Green Deployment: a ideia é ter duas versões idênticas do ambiente de produção (Blue e Green) e assim mitigar o risco em publicações de releases. O resumo do livro Continuous Delivery traz mais detalhes.
  • Incident Command System: o artigo Incident Command for IT: What We Can Learn from the Fire Department aborda como os processos de emergência podem ser aplicáveis a TI – em pequenos e grandes incidentes, já que incidentes acontecem em nossos serviços.
  • Public status pages: serviços vão cair – isso acontece na vida real. A comunicação pode ajudar em melhorar a satisfação do cliente (e manter a confiança) durante as indisponibilidades. Pense nisso!
  • Embedded Teams: gestão do conflito de interesse entre Dev e Ops. Mantenha o time responsável por todo o seu trabalho, ao invés de jogar requisições por cima do muro. Isso permite disciplina e coordenação muito mais próxima para o sucesso do serviço.
  • Dependencie and injection: conexões com serviços externos (database, rest services, etc.) são a fonte da maioria dos problemas de runtime – o Design Pattern “Dependency Injection” foca em como remover estas dependências.
  • Chaos Monkey: oriunda do Simian Army (Netflix) – a autonomia para resolução de problemas dos times, desde o código até a operação de servidores, permite resolver constantemente os problemas com rapidez e precisão. O Simian Army é um software que gera falhas propositalmente (de forma aleatória), criando uma cultura de prontidão a resolução em qualquer questão. E assim, nenhum problema pode ser ignorado.