Ferramentas para medição e monitoramento em DevOps

Ferramentas para medição e monitoramento em DevOps

Olá!

Espero que estejam bem, e saudáveis.

Sigo em minha jornada de tentar simplificar o DevOps, de forma que uma pessoa não especializada em tecnologia, como eu, possa entender dessa metodologia que gera tanto valor e impacto positivo nas organizações que a adotam.

O tema desse artigo é "Ferramentas para medição e monitoramento em DevOps", e você examinará a prática de melhoria contínua e como ela sustenta a evolução de todas as outras práticas para promover o sucesso do DevOps em sua organização.

Abraçando a melhoria contínua

Introdução

Uma das principais práticas da metodologia DevOps é o objetivo de melhoria contínua. Implementar DevOps não é um projeto com início, meio e fim definidos. É uma jornada contínua.

Alcançar a melhoria contínua requer reconhecer onde as eficiências podem ser obtidas, identificar quais melhorias podem ser feitas e aprender com o trabalho recém-realizado. Os passos necessários para atingir estes objectivos são identificados através da prática de monitorização contínua.


Monitoramento contínuo

O monitoramento contínuo refere-se às atividades necessárias para monitorar a integridade, o desempenho e a confiabilidade de seu aplicativo, infraestrutura e processos, à medida que o trabalho passa do desenvolvimento para a produção.

Ele procura aplicar o mesmo nível de rigor em todas as áreas de possível melhoria à medida que uma organização busca a melhoria contínua.

Algumas perguntas podem nos ajudar a refletir sobre nosso monitoramento contínuo, e se ele está sendo bem executado, como, por exemplo:

  • A aplicação está funcionando conforme o esperado?
  • Uma transferência poderia ter sido concluída mais rapidamente?
  • O trabalho resultou em um aumento mensurável na atividade do cliente?
  • O SLA (acordo de nível de serviço) de desempenho do ambiente está sendo cumprido?

Objetivos do monitoramento contínuo em DevOps

As organizações alcançam verdadeira eficiência e escalabilidade utilizando monitoramento contínuo para fornecer dados em tempo real para análise. A identificação imediata de incidentes por meio de sistemas de alerta automatizados encaminha o trabalho para as pessoas certas assim que um problema é encontrado, minimizando o impacto no tempo de atividade ou na receita.

Além disso, alguns benefícios do monitoramento contínuo são:

  • visibilidade e transparência da rede
  • resposta rápida a incidentes
  • minimização do tempo de inatividade do sistema
  • maior capacidade de tomada de decisão
  • melhor desempenho empresarial

E por que o monitoramento contínuo é necessário?

As práticas de integração contínua, entrega contínua e implantação contínua aumentam o ritmo da mudança organizacional. Pode haver muitas compilações em vários estágios de produção, executando milhares de cargas de trabalho, utilizando microsserviços e micro front-ends em centenas de ambientes de nuvem.

Os processos que produzem trabalho neste pipeline de desenvolvimento são complexos. É fundamental implementar mecanismos para ajudar a rastrear o impacto das atualizações, fornecer visibilidade e permitir que as equipes detectem e respondam a incidentes.

Monitoramento da aplicação

O monitoramento de aplicativos fornece informações sobre o desempenho de seus aplicativos e serviços da Web. Isso inclui transações ponta a ponta, conexões e a estabilidade geral do back-end e do front-end.

Os dados sobre o tempo de atividade, o tempo de transação, o volume de transações, as respostas do sistema e as respostas da API de um aplicativo permitem que o desempenho do aplicativo seja monitorado em busca de falhas ou identificação de áreas onde melhorias podem ser feitas.

Abaixo, listo alguns dos mais comuns tipos de monitoramento:

Availability: o monitoramento de disponibilidade (availability) verifica se o aplicativo, site ou sistema não está comprometido ou sofrendo uma interrupção e está disponível 24 horas por dia e 365 dias por ano

Browser-speed: a velocidade de navegação (browser speed) monitora a capacidade de um site de responder aos usuários de ponta a ponta. O monitoramento de desempenho mais avançado levará em consideração variáveis como tamanho do arquivo, número de arquivos, arquitetura do sistema, localização geográfica do usuário, tipo de dispositivo e velocidade de conexão

End user transactions: o monitoramento de transações (end-user transactions) mede as taxas de conversão e rejeição, desde o clique, toque ou deslize inicial do navegador até o aplicativo de back-end

Error rate: o monitoramento da taxa de erros (error rate) rastreia a porcentagem de códigos de resposta HTTP ou outros erros que são acionados ao usar seu aplicativo, site ou aplicativo

SLA Status: O monitoramento de SLA fornece evidências documentais para apoiar que os SLAs estão sendo cumpridos e permite que a empresa garanta que níveis e qualidade de serviço adequados estejam sendo entregues

Third-party resource usage: monitorar recursos de terceiros garante que, caso haja uma interrupção, você saiba antes de seus clientes. Isso garante que você possa cumprir seus compromissos com seus clientes.

Throughput: a taxa de transferência (throughput) é uma medida das solicitações por minuto por meio de um aplicativo. Ele permite que você veja rapidamente as tendências de desempenho

Response time: monitorar os tempos de resposta (response time) pode ajudá-lo a identificar quais componentes, consultas ou solicitações podem estar causando atrasos que o usuário está enfrentando.

Monitoramento do pipeline de entrega

O monitoramento do pipeline de entrega permite a visibilidade de todo o pipeline de entrega de ponta a ponta. Ele fornece insights sobre como as equipes de DevOps estão trabalhando, expõe gargalos e fornece informações sobre a velocidade e a qualidade dos produtos entregues.

As atividades de monitoramento do pipeline de entrega incluem o monitoramento de compilações, confirmações, implantações, marcos de desenvolvimento e qualidade.

Monitoramento de Infraestrutura

O monitoramento da infraestrutura fornece observabilidade total em toda a pilha de tecnologia, proporcionando insights contínuos sobre sua integridade, desempenho e disponibilidade. O monitoramento de sua infraestrutura de TI é necessário para qualquer organização que dependa dela para entregar seus produtos e serviços.

A infraestrutura de TI abrange centenas de dispositivos conectados, contêineres, hardware, servidores, software, armazenamento, máquinas virtuais e muito mais. O monitoramento desses ambientes grandes e complexos não pode ser alcançado sem ferramentas de monitoramento de infraestrutura que permitam configurar respostas automatizadas.

Monitoramento de rede

O monitoramento de rede monitora e rastreia atividades nas redes nas quais sua infraestrutura está operando. Isso inclui o status e a atividade de componentes como firewalls, roteadores, servidores, switches e máquinas virtuais.

O objetivo principal do monitoramento de rede é evitar tempo de inatividade, falhas e travamentos.

Ferramentas de monitoramento

Ferramentas populares de monitoramento de infraestrutura incluem Nagios, ManageEngine OpManager, Prometheus, Paessler PRTG Network Monitor, Sematext, Solarwinds e Zabbix.

Se você estiver acessando infraestrutura como serviço (IaaS), é provável que o fornecedor disponibilize suas próprias ferramentas, por exemplo, a Amazon usa AWS CloudWatch.

As ferramentas de monitoramento de rede incluem Cacti, ntop, nmap, Spiceworks, Traceroute e Wireshark.

Muitas ferramentas de monitoramento combinam monitoramento de aplicativos e servidores, fornecendo informações sobre o desempenho dos aplicativos e dos serviços que os suportam.

Ferramentas empresariais de ponta, como BMC Helix Operations Management, BigPanda e PagerDuty, analisam eventos e alertas de monitores existentes para determinar qualquer correlação entre eles e fornecem aos usuários de DevOps uma lista consolidada de problemas.

Abraçando a melhoria contínua - resumo

Até esse ponto do artigo, demonstrei os objetivos do monitoramento contínuo, a necessidade de monitorar toda a pilha de aplicativos e o que isso abrange.

Com aplicativos e ambientes de implantação cada vez mais complexos, o monitoramento sofisticado é vital e complexo para a organização moderna. Também citei algumas das ferramentas que podem ser utilizadas para auxiliar as actividades de monitoramento.

Monitoramento na prática - Introdução

O monitoramento contínuo identifica onde as eficiências podem ser obtidas, as melhorias feitas ou os erros corrigidos. Nesta segunda parte do artigo, você verá as métricas que o monitoramento contínuo produz para iniciar o ciclo de vida de desenvolvimento novamente.

Métricas, telemetria e coleta de dados

O principal resultado das atividades de monitoramento contínuo são os dados.

Combinar o retorno dos dados das atividades de monitoramento contínuo e apresentá-los de maneira significativa permite que uma organização obtenha insights sobre seu verdadeiro desempenho, meça a qualidade e preveja a capacidade de seus processos. Um pipeline de desenvolvimento bem monitorado permitirá que quaisquer anomalias sejam detectadas imediatamente.

Alguns exemplos:

Monitoramento sintético: o monitoramento sintético utiliza um conjunto consistente de transações para avaliar o desempenho e a disponibilidade. Os dados quantitativos capturados em tempo real ou quase em tempo real permitem que mudanças ao longo do tempo sejam identificadas

Monitoramento do usuário: o monitoramento do usuário mede a experiência do usuário em seu laptop, desktop ou dispositivo móvel. Condições como redes móveis, roteamento de internet e cache afetarão as métricas retornadas.

Logs: logs são registros de eventos que descrevem mudanças que ocorrem e atividades que ocorrem dentro ou em um sistema

Traces: traces são registros que descrevem cada etapa ou operação executada por um componente do sistema. Os rastreamentos podem ser habilitados sob demanda ou inserindo código no componente para gerá-los. Devido à alta sobrecarga computacional, eles geralmente são usados apenas para tarefas específicas durante curtos períodos de tempo.

Alertas: alertas são emitidos por ferramentas ou sistemas se um problema subjacente for identificado ou um limite de alerta for acionado. Eles solicitam ação manual ou alertam o operador de que uma resposta automática ao alerta está ocorrendo.

Notificações: as notificações informam o operador sobre eventos padrão ou esperados que ocorreram ou foram realizados. Por exemplo, quando uma compilação passa no teste ou uma senha é redefinida.

Unindo métricas de DevOps

Os dashboards agrupam o resultado das atividades de monitoramento contínuo de uma organização em um local centralizado que permite que as equipes de DevOps acessem a mesma telemetria e ferramentas. Todos têm visibilidade do pipeline de desenvolvimento de software e podem ter acesso a painéis adicionais adaptados à sua função.

Lead time for change e cycle time

O lead time for change e o cycle time são duas métricas importantes e relacionadas.

O lead time for change é o tempo que leva desde o momento em que uma confirmação do código é feita até quando ele está em um estado implantável. Esta é uma medida do tempo necessário para o código passar em todos os testes de pré-lançamento.

O cycle time é o tempo que leva desde o início do trabalho até a entrega. O objetivo é tornar o ciclo de desenvolvimento, teste e feedback o mais curto possível para que as melhorias possam ser implementadas rapidamente sem sacrificar a qualidade.

Change Failure Rate

A change failure rate é a porcentagem de alterações que falham na produção. É uma medida de estabilidade e avalia a eficiência dos processos de implantação.

Como você viu em um dos meus artigos, um processo ideal de implantação contínua será automatizado, resultando em maiores medidas de consistência e confiabilidade. As implantações manuais podem apresentar uma change failure rate mais alta, pois exigem muitas alterações pequenas e repetitivas em cada implantação que carregam o potencial adicional de erro humano.

Mean Time to Recovery (MTTR)

O mean time to recovery (MTTR) é uma medida do tempo que leva para implementar uma solução para um problema. Este pode ser o tempo de recuperação de uma interrupção de serviço ou da falha de uma implantação.

Os sistemas antifrágeis aceitam a ocorrência de incidentes e concentram-se em como otimizar os processos para restaurar o serviço. Identificar e remover gargalos no fluxo de trabalho de resolução pode reduzir o tempo médio de recuperação e ajudar a equipe de DevOps a minimizar o impacto dos incidentes.

Deployment frequency

O deployment frequency é uma medida do número de vezes que um novo código é implantado na produção.

Equipes de DevOps bem-sucedidas e de alto desempenho implantam componentes menores e mais semelhantes com mais frequência. Mudanças menores são mais fáceis de testar, implantar e reverter em caso de falha. Cada implantação também oferece a oportunidade de receber feedback antecipado do cliente, para que o esforço de trabalho possa se concentrar nos itens que o cliente realmente deseja.

Eficácia do resultado

Outra métrica importante a monitorar é a eficácia dos resultados. O trabalho pode ser validado rastreando o uso e comparando versões de produtos para medir o impacto da mudança. Se a implantação de uma alteração de código for apoiada pelo aumento esperado na atividade do usuário, a equipe de DevOps poderá continuar seu trabalho.

Se o uso não refletir o comportamento esperado e o sentimento do usuário indicar uma resposta negativa à mudança, a equipe poderá precisar dinamizar suas atividades de trabalho.

A equipe pode utilizar informações de uso para medir o impacto de suas mudanças e tomar decisões de negócios baseadas em dados.

Resposta a Incidentes

São esperados incidentes no ciclo de vida de desenvolvimento de software, desde falhas de hardware e rede até configurações incorretas, esgotamento de recursos, inconsistências de dados e bugs de software.

A forma como você responde a incidentes e reage a eventos em grande escala antes que eles afetem os usuários determina a capacidade de uma organização de fornecer produtos estáveis e confiáveis.

As organizações empregam várias ferramentas para ajudar a gerenciar esse processo. Embora você possa não estar envolvido na definição do que constitui um incidente, nas equipes DevOps todos estão envolvidos na resposta a incidentes.

Incidentes de segurança

Outro tipo de incidente ao qual a equipe DevOps pode precisar responder são os incidentes de segurança. A segurança do DevOps é um empreendimento contínuo que exige a participação de todos. Assim como os outros tipos de incidentes examinados na página anterior, cada equipe deve ter um plano de resposta sobre como lidar com incidentes de segurança.

Muitas organizações usam simulações para que as equipes possam praticar a detecção e o tempo médio de recuperação. Caso ocorra uma violação, o tempo de exposição e recuperação é minimizado devido ao preparo prévio da equipe.

Monitoramento na prática - Resumo

As métricas de DevOps ajudam a determinar se o feedback e as ações tomadas estão economizando tempo e aumentando a produtividade. Nesta segunda e última parte do artigo, você viu como capturar e responder continuamente ao feedback é fundamental para fornecer software resiliente, confiável e de qualidade aos usuários finais.

As mesmas métricas também fornecem os dados necessários para estruturas como o Plan-Do-Study-Act (PDSA) de Deming – introduzido num artigo anterior – que permite às organizações avaliar o impacto global do DevOps e identificar onde podem ser feitas melhorias adicionais.

Obrigado por ter chegado até aqui. Agora, você já conhece a minha opinião, e eu quero saber a sua! Deixe seus pensamentos nos comentários e vamos transformar essa discussão em algo incrível. Compartilhe suas ideias, desafios e histórias - a nossa conversa está apenas começando. Vamos nessa juntos!

________________________________________________________________

Eu sou o Daniel Roberto dos Santos, tenho 21 anos de experiência em Supply Chain, Operações, Gestão de Projetos e metodologias ágeis. Também sou palestrante , consultor e professor. Minha atual experiência, é como Gerente de Projetos Ágeis em CIO na IBM. me graduei em Administração pela Pontifícia Universidade Católica de São Paulo, com pós-graduação em Marketing pela ESPM Escola Superior de Propaganda e Marketing. Sou Professional Scrum Master® Certified Scrum.org e Project Management Professional Project Management Institute


Entre para ver ou adicionar um comentário

Outras pessoas também visualizaram

Conferir tópicos