Por que os engenheiros não se preocupam com o monitoramento de aplicativos?

Tudo com sexta-feira! Amigos, hoje continuamos uma série de publicações dedicadas ao curso DevOps Practices and Tools , porque as aulas no novo grupo do curso começarão no final da próxima semana. Então, vamos começar!



O monitoramento é fácil . Este é um fato conhecido. Levante o Nagios, execute o NRPE no sistema remoto, configure o Nagios na porta TCP do NRPE 5666 e você terá monitoramento.

É tão fácil que não é interessante. Agora você tem as métricas básicas para o tempo do processador, subsistema de disco, RAM, que vêm por padrão no Nagios e no NRPE. Mas, na realidade, isso não é "monitoramento" como tal. Este é apenas o começo.

(Geralmente eles instalam PNP4Nagios, RRDtool e Thruk, configuram notificações no Slack e vão diretamente para o nagiosexchange, mas por enquanto o deixam).

Um bom monitoramento é realmente bastante complicado, você realmente precisa conhecer os elementos internos do aplicativo que está assistindo.

O monitoramento é difícil?

Qualquer servidor, seja Linux ou Windows, por definição, servirá a algum propósito. Apache, Samba, Tomcat, armazenamento de arquivos, LDAP - todos esses serviços são mais ou menos exclusivos em um ou mais aspectos. Cada um tem sua própria função, suas próprias características. Existem diferentes maneiras de obter métricas, KPI (principais indicadores de desempenho), interessantes para você quando o servidor está sob carga.


Foto de Luke Chesser em Unsplash


(Gostaria que meus painéis fossem pintados em cores azul neon - suspirando sonhadoramente - ... hmm ...)

Qualquer software que fornece serviços deve ter um mecanismo para coletar métricas. O Apache possui um módulo mod-status que exibe a página de mod-status do servidor. O Nginx possui stub_status . O Tomcat possui JMX ou aplicativos da web especiais que mostram as principais métricas. O MySQL tem o comando "show global status", etc.
Então, por que os desenvolvedores não incorporam esses mecanismos nos aplicativos que eles criam?

Os desenvolvedores fazem apenas isso?

Um certo nível de indiferença à incorporação de métricas não se limita aos desenvolvedores. Trabalhei em empresas nas quais desenvolvi aplicativos usando o Tomcat e não produzi nenhuma das minhas métricas, nenhum registro de atividades de serviço, exceto os registros gerais de erros do Tomcat. Alguns desenvolvedores geram uma abundância de logs que não significam nada para o administrador do sistema, que teve azar de lê-los às 3:15 da manhã.


Postado por Tim Gouw em Unsplash

Os engenheiros de sistema que permitem o lançamento de tais produtos também devem ter alguma responsabilidade pela situação. Poucos engenheiros de sistema têm tempo e cuidado para tentar obter métricas significativas dos logs, sem o contexto dessas métricas e a capacidade de interpretá-las à luz da atividade do aplicativo. Alguns não entendem que benefício podem obter disso, exceto indicadores como "algo está atualmente (ou será em breve) errado".

Uma mudança de pensamento sobre a necessidade de métricas deve ocorrer não apenas entre os desenvolvedores, mas também entre os engenheiros de sistema.

Para qualquer engenheiro de sistema que precise não apenas responder a eventos críticos, mas também garantir sua ausência, a ausência de métricas geralmente é um obstáculo para isso.

No entanto, os engenheiros de sistema geralmente não buscam o código, ganhando dinheiro com a empresa. Eles precisam de desenvolvedores líderes que entendam a importância da responsabilidade de um engenheiro de sistemas na detecção de problemas, na conscientização de problemas de desempenho e similares.

Essa coisa de devops

A mentalidade devops descreve a sinergia do pensamento do desenvolvedor (devs) e da exploração (ops). Qualquer empresa que afirme estar fazendo devops deve:

1. para dizer o que eles provavelmente não fazem (uma dica do meme do filme "Princess Bride" - "Eu não acho que isso significa o que você pensa que significa!")
2. promover uma posição de melhoria contínua do produto.

Você não pode melhorar um produto e sabe que ele foi aprimorado se não souber como ele funciona atualmente. Você não poderá descobrir como um produto funciona se não entender como seus componentes funcionam, os serviços dos quais depende, seus principais pontos problemáticos e gargalos.
A menos que esteja observando possíveis gargalos, não é possível seguir a técnica Cinco Por que ao escrever Post-mortem. Você não pode coletar tudo em uma tela para ver como o produto funciona ou para descobrir como ele parece "normal e feliz".

Esquerda, esquerda, eu disse, NOOOOOOOO -

Para mim, um dos princípios fundamentais do Devops é o "turn left". Uma mudança para a esquerda nesse contexto significa uma mudança na capacidade ( não responsabilidade , mas apenas na capacidade) de fazer o que os engenheiros de sistema geralmente se preocupam, por exemplo, criar métricas de desempenho, usar logs com mais eficiência etc., para a esquerda no ciclo de vida de entrega do software ( Ciclo de vida da entrega de software).


Foto de NESA de Makers em Unsplash

Os desenvolvedores de software devem poder usar e conhecer as ferramentas de monitoramento que a empresa usa para monitorar em todas as suas formas, métricas, registros, interfaces de monitoramento e, o mais importante, observar como o produto funciona na produção . Você não pode forçar os desenvolvedores a investir tempo e esforço no monitoramento até que possam ver as métricas e influenciar sua aparência, como o proprietário do produto apresentará seus CTOs no próximo briefing etc.

Em suma

1. Traga o cavalo para a água. Mostre aos desenvolvedores quantos problemas eles podem evitar por si mesmos, ajude-os a identificar os KPIs e métricas corretos para seus aplicativos, para que haja menos gritos do proprietário do produto nos quais o CTO está gritando. Traga-os para a luz, suave e calmamente. Se isso não der certo, suborne, ameace e convença eles ou o proprietário do produto para obter rapidamente essas métricas dos aplicativos e, em seguida, desenhe diagramas. Isso será difícil, pois não será considerado uma prioridade e haverá muitos projetos de geração de renda aguardando implementação no roteiro do produto. Portanto, você precisará de um caso de negócios para justificar o tempo e o dinheiro gastos na implementação do monitoramento no produto.
2. Ajude os engenheiros do sistema a dormir o suficiente. Mostre a eles que usar uma lista de verificação de liberação de versão para qualquer produto é bom. E verificar se todos os aplicativos em produção estão cobertos com métricas ajudará você a ter uma boa noite de sono, permitindo que os desenvolvedores vejam o que funciona e onde não funciona. No entanto, a maneira certa de irritar e chatear qualquer desenvolvedor, proprietário do produto e CTO é empurrar paus nas rodas e resistir. Esse comportamento afetará a data de lançamento de qualquer produto se você esperar novamente até o último minuto; então, mude novamente para a esquerda e inclua esses problemas o mais rápido possível no plano do projeto. Se necessário, vá para reuniões de produtos. Use um bigode falso e feltro ou algo assim, nunca falha. Relate suas preocupações, mostre benefícios óbvios e evangelize.
3. Certifique-se de que os desenvolvedores (dev) e a operação (ops) entendam o significado e as consequências de mover as métricas do produto para a zona vermelha. Não deixe a operação como a única proteção ao desempenho do produto; verifique se os desenvolvedores também participam (#productsquads).
4. Logs são ótimos, mas métricas também. Combine-os e não deixe seus toros se tornarem lixo em uma enorme bola flamejante de futilidade. Explique e mostre aos desenvolvedores por que ninguém, exceto eles, entenderá seus logs, mostre a eles como é assistir logs inúteis às 3:15 da manhã.

Foto de Marko Horvat em Unsplash

Só isso. Novo material será lançado na próxima semana. Se você quiser saber mais sobre o curso, convidamos você para um dia aberto , que será realizado na segunda-feira. E agora estamos tradicionalmente aguardando seus comentários.