3 Maneiras DevOps – 2º Feedback

Esse é o segundo artigo da série sobre DevOps, no qual você irá conhecer o conjunto de princípios, práticas e ideias essenciais para o bom funcionamento de uma esteira de fabricação de software que são apresentados nas 3 maneiras do DevOps. Para conferir o primeiro artigo desta série, clique aqui.

A segunda maneira oferece o feedback rápido e constante habilitando a identificação e resolução de problemas em sua origem e na identificação de falhas antes que elas aconteçam. E, para obter máximo aproveitamento do feedback é necessário trabalhar com segurança em sistemas complexos, saber dos problemas quando eles ocorrem e construir novos conhecimentos juntos para assim criar um ambiente seguro e confiável para o cliente.

2ª maneira (fonte: Gene Kim, “The three Ways: The Principles Underpinning Devops”)

Com o entendimento desta prática é possível evitar problemas através dos seguintes pontos do feedback:

Trabalhar com segurança em sistemas complexos

Um dos grandes desafios de trabalhar com sistemas complexos é que eles normalmente possuem diversas dependências entre si, o que torna o entendimento do comportamento de cada componente desafiador e complexo.

Por isso são recomendadas arquitetura de aplicação desacopladas para tornar possível não só o desenvolvimento e melhoria da aplicação, mas também a facilidade e maior controle sobre o que está ocorrendo durante a aplicação.  Esse tema está totalmente alinhado com a 1ª maneira que é o fluxo que é sugerido o trabalho com micro serviços para a redução dos lotes. 

Saber dos problemas quando eles ocorrem

Dentro deste tópico existe a telemetria e monitoramento como principais itens, pois eles fornecerão a coleta automática dos dados sobre a saúde dos ambientes e aplicações, gerando insumos importantes para a tomada de decisão sobre determinado evento.

Dentro do ciclo de vida de desenvolvimento de software diversas métricas são geradas, como: funcionalidades testadas, erros de implantação e após implantação, as funcionalidades mais usadas pelo cliente, tempo de resposta, entre outros. Todos os dados devem ser coletados, armazenados e exibidos ao time para a criação de autonomia dos times e geração de valor ao produto e cliente.

Fluxo de Monitoramento

Você sabia?

O DORA – DevOps Research and Assessment possuí classificações para o aspecto da performance de entrega de software, no qual é avaliado a maturidade DevOps dentro da organização através das seguintes informações:

  • Frequência de implantações;
  • Tempo das mudanças;
  • Tempo para restauração de serviços;
  • Taxa de mudanças com falhas.

Saiba mais sobre o DORA no artigo desenvolvido por Heider Hengstmann clicando aqui.

Construir novos conhecimentos juntos

O cenário ideal é mobilizar quem seja necessário para a resolução dos problemas quando eles ocorrem. Essa prática constrói um conhecimento mais profundo e compartilhado sobre o produto ou sistema utilizado, pois todos podem sugerir análises e testes em diferentes partes do sistema baseado em cada experiência particular e ao final do incidente a equipe pode criar uma base de conhecimento melhor e mais profunda sobre o ambiente.

Outro tipo de feedback que deve ser levado em consideração é o do cliente que utiliza o serviço. Pode parecer óbvio, porém muitas empresas não colocam na equação para a tomada de decisão a opinião dos consumidores do produto que podem gerar informações essenciais sobre a interface, lentidão ou falta de resposta de determinado serviço, etc.

Essa simples iniciativa, além de gerar feedbacks importantes dos clientes sobre o produto, também gera empatia, uma vez que transforma uma insatisfação do cliente ao entendimento que o produto ou serviço está em busca de evolução baseada em suas experiências.

Resposta a incidentes

Mesmo em ambientes construídos de formas idênticas através de infraestrutura como código ou self-service, códigos implantados por esteiras com execução de testes são suscetíveis a geração de falhas durante sua implantação. Para esses casos é necessário criar um plano de resposta para incidentes bem estabelecido.

Neste plano deve-se conter estratégias, ações e pessoas responsáveis para cada tipo de indisponibilidade e/ou problema, como por exemplo:

Também podem ser utilizadas como estratégias a utilização de backup e restore ou uma movimentação da infraestrutura para outras regiões dentro de um cloud provider ou até mesmo a mudança dele.

Conclusão

As 3 maneiras do DevOps apresentam conceitos e frameworks difundidos no mercado, porém em cada maneira são estabelecidos preceitos para a organização e potencialização das ações e práticas que suportam os processos DevOps. A segunda maneira intitulada de “Feedback” reativa a real necessidade de entendimento do produto e como ele se comporta no dia a dia e da demanda de antecipação a problemas para que tenhamos produtos confiáveis e disponíveis quando o cliente precisar.

Referências

Manual do Devops, um livro de Gene Kim, Jez Humble, Patrick Debois e John Willis