13/02/2020 | Autor: Claudio Romão | Categoria: Técnico | Comentários

Recebendo notificações do seu processo de DevOps

Nos últimos posts (Como pegar feedback no processo de DevOps - parte 1 e parte 2 ) falamos sobre o feedback que podemos coletar no nosso ciclo de desenvolvimento. Falamos de coletar os dados desde os primeiros ciclos como por exemplo, uma análise de pull request até o monitoramento da aplicação no ambiente produtivo.

Mas o que adianta saber o que coletar se essa informação não chegar para a pessoa certa no momento certo?

Imagina que conseguimos coletar todas as informações que conversamos anteriormente. E aí, como disponibilizar?

Não adianta coletar as métricas e logs no meu processo senão fizer nada com ele. Essas métricas serão apenas dados simples que ficarão armazenados em algum canto. Nós precisamos transformar esses dados em informação, que é o dado trabalhado. Isso que vai nos ajudar a saber onde precisamos melhorar e onde podemos economizar.

Como vimos, temos uma quantidade bem grande de dados coletados. Então disponibilizar eles da melhor forma e para quem precisa, acaba sendo crucial para o processo de melhoria contínua.

Se simplesmente para qualquer ação nós dispararmos um e-mail, o que vai acabar acontecendo é que receberemos uma quantidade bem grande de e-mails e vamos acabar não dando importância. Provavelmente você vai criar aquela regra no seu leitor de e-mail para quando chegar uma mensagem do remetente X jogar na pasta Y.

Então como fazer para não perder o dado importante e notificar da melhor forma e quem realmente precisa?

Nós precisamos usar a melhor ferramenta de entrega para cada caso. A seguir vou listar algumas opções que podem ser usadas, porém a recomendação é entender no nosso processo quem precisa saber do que e quando.

E-mail

Esse modelo de notificação não tem como ser ignorado. Ele é importante e o mais utilizado. Mas imagina o seguinte cenário: Eu subo uma alteração para uma feature branch e ela inicializa automaticamente todo o processo de validação de build, testes de unidade e análise estática de código e o processo dá erro. Quem deveria receber essa informação? O time todo? Não. Essa informação só é relevante para quem trabalha na feature. Como estão em uma feature branch devemos notificar a pessoa do time que fez a subida. Ela é a maior interessada.

O e-mail é essencial, porém devemos escolher exatamente o que mandar e para quem, caso contrário vamos gerar “spam” nas caixas de todos as pessoas do time.

Chat

O chat é uma outra ferramenta bem interessante. Nós podemos por exemplo, criar um canal no Microsoft Teams que receberá algumas notificações. Essas notificações são entregues para todas as pessoas do canal. Outra vantagem de utilização dessa ferramenta de chat é a possibilidade de fazer pesquisas no histórico das conversas e resgatar alguma informação do passado.

Quando usaríamos o chat? Imagina a seguinte situação, acabei de fazer minha feature e agora quero subir para Dev. Idealmente faria a integração da minha feature com dev através de um pull request. Podemos enviar a notificação no canal do time, assim qualquer integrante do time vai receber a notificação e pode atuar no pull request.

Geralmente essas aplicações ainda oferecem integrações que nos permitem interagir com bots para já tomar algumas ações na própria tela do chat, agilizando ainda mais o nosso processo.

Relatórios

Esse modelo de comunicação é bastante para repotar informações para alta gestão e também utilizado nos processos de build e release. Cada vez que o processo é finalizado, devemos conseguir olhar e analisar tudo o que foi feito. Plataformas como o Azure DevOps Service, oferecem relatórios integrados nas funcionalidades de build e release onde conseguimos analisar os logs de execução e resultados das validações que estamos fazendo.

Dashboard

O Dashboard é uma excelente ferramenta para termos uma visão completa da saúde da nossa aplicação. Nele podemos colocar várias informações para entender como está o desenvolvimento da aplicação e como ela está se comportando em produção.

Vários times usando TV´s para ficar apresentando dashboards com informações específicas e com isso dar uma visibilidade constante de como está o projeto.

Uma vantagem do Dashboard é que podemos ter vários tipos de dashboards, um para cada tipo de informação necessária para o time atuar. Por exemplo, podemos ter um dashboard com informações de novas subidas e métricas de negócio da aplicação em produção para a equipe de negócio. Podemos ter um dashboard com informações mais específicas da equipe de infraestrutura que a aplicação utiliza para a equipe de infraestrutura.

Podemos identificar o que é importante para cada pessoa envolvida com o sistema e montar um dashboard que concentre as principais informações, possibilitando que ela possa olhar e tomar a decisão mais correta.

Notificações e Alertas

As ferramentas de monitoramento novas como o Application Insights, nos ajudam a receber notificações importantes do estado da nossa aplicação tanto no nível técnico como no nível de negócios. Um ponto muito importante que podemos usar é a configuração de alertas específicos, para quando um problema for identificado na aplicação a ação correta seja tomada.

Com o Application Insights por exemplo, conseguimos criar alertas baseados em métricas da nossa aplicação que podem desde simplesmente enviar um e-mail para um grupo específico, enviar um SMS para uma pessoa específica ou até mesmo já executar uma rotina automatizada para resolver o problema.

Um exemplo seria monitorar a capacidade de recursos da máquina. Quando ela atingir um limite específico, identificando que estamos tendo mais utilização do que o normal, ele dispara uma ação que automaticamente vai provisionar uma nova instância da nossa aplicação.

Ferramentas de análise de dados

Uma outra ferramenta bem legal de usarmos é uma de análise de dados. Por exemplo, podemos enviar todos os logs da nossa aplicação para o Azure Monitor e depois utilizar o modelo de query para ter a informação correta e com isso entender o que aconteceu com a nossa aplicação.

Podemos também jogar as informações de negócio para uma outra base e usar ferramentas como o Power BI para fazer consultas e criar dashboards que ajudarão as áreas a tomar decisões para o futuro do sistema.

Como vimos, temos várias ferramentas que podemos utilizar para receber os dados coletados no nosso processo. Cada uma tem suas vantagens e desvantagens. Cabe o time entender como gostaria de receber cada tipo de feedback que nosso processo está nos dando.

Espero que tenha gostado e se tiver alguma dúvida específica me manda um e-mail ou deixe nos comentários.

Até a próxima, Claudio Romão