Feliz sexta-feira para todos! Amigos, hoje continuamos a série de publicações dedicadas ao curso , pois as aulas da nova turma do curso terão início no final da próxima semana. Então, vamos começar!
O monitoramento é justo. Este é um fato conhecido. Abra o Nagios, execute o NRPE no sistema remoto, configure o Nagios na porta TCP NRPE 5666 e você terá monitoramento.
É tão fácil que não é interessante. Agora você tem métricas básicas de tempo de CPU, subsistema de disco, RAM, fornecidas por padrão para Nagios e NRPE. Mas isto não é realmente “monitoramento” como tal. Isto é apenas o começo.
(Normalmente eles instalam PNP4Nagios, RRDtool e Thruk, configuram notificações no Slack e vão direto para o nagiosexchange, mas vamos deixar isso de lado por enquanto).
Bom monitoramento é realmente bastante complexo, você realmente precisa conhecer os detalhes internos do aplicativo que está monitorando.
O monitoramento é difícil?
Qualquer servidor, seja Linux ou Windows, servirá, por definição, 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 função, suas características próprias. Existem diferentes maneiras de obter métricas, KPIs (indicadores-chave de desempenho), que são interessantes para você quando o servidor está sobrecarregado.
foto por em
(Eu queria que meus painéis fossem azul neon – suspirando sonhadoramente –... hmm...)
Qualquer software que forneça serviços deve ter um mecanismo para coletar métricas. Apache tem um módulo mod-status, exibindo a página de status do servidor. Nginx tem - stub_status. O Tomcat possui JMX ou aplicativos da web personalizados que mostram as principais métricas. MySQL tem um comando "mostrar status global" etc.
Então, por que os desenvolvedores não incorporam mecanismos semelhantes nos aplicativos que criam?
Somente os desenvolvedores estão fazendo isso?
Um certo nível de indiferença à incorporação de métricas não se limita aos desenvolvedores. Trabalhei em empresas onde eles desenvolviam aplicativos usando o Tomcat e não forneciam nenhuma métrica própria, nenhum log de atividade de serviço, exceto logs de erros gerais do Tomcat. Alguns desenvolvedores geram muitos logs que não significam nada para o administrador do sistema, que tem o azar de lê-los às 3h15 da manhã.
foto por em
Os engenheiros de sistemas que permitem o lançamento de tais produtos também devem assumir alguma responsabilidade pela situação. Poucos engenheiros de sistemas têm tempo ou cuidado para tentar extrair 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 como podem se beneficiar disso, além dos indicadores de que “algo está atualmente (ou estará em breve) errado”.
Uma mudança de pensamento quanto à necessidade de métricas deve ocorrer não apenas entre os desenvolvedores, mas também entre os engenheiros de sistemas.
Para qualquer engenheiro de sistemas que precise não apenas responder a eventos críticos, mas também garantir que eles não ocorram, a falta de métricas costuma ser uma barreira para isso.
No entanto, os engenheiros de sistemas normalmente não mexem no código para ganhar dinheiro para sua empresa. Eles precisam de desenvolvedores líderes que entendam a importância da responsabilidade do engenheiro de sistemas na identificação de problemas, na conscientização sobre questões de desempenho e assim por diante.
Essa coisa de devops
A mentalidade devops descreve a sinergia entre o pensamento de desenvolvimento (dev) e operações (ops). Qualquer empresa que afirme “fazer devops” deve:
- dizendo coisas que provavelmente não dizem (referindo-se ao meme da Princesa Noiva - "Não acho que isso signifique o que você acha que significa!")
- Incentivar uma atitude de melhoria contínua do produto.
Você não pode melhorar um produto e saber que ele foi melhorado se não souber como funciona atualmente. Você não pode saber como um produto funciona se não entender como funcionam seus componentes, os serviços dos quais ele depende, seus principais pontos fracos e gargalos.
Se você não observar possíveis gargalos, não será capaz de seguir a técnica dos Cinco Porquês ao escrever uma Postmortem. Você não conseguirá colocar tudo em uma tela para ver como um produto funciona ou saber como ele parece “normal e feliz”.
Mude para a esquerda, ESQUERDA, EU DISSE LEEEE—
Para mim, um dos princípios-chave do Devops é “deslocar para a esquerda”. Deslocar para a esquerda neste contexto significa mudar a possibilidade (sem responsabilidade, mas apenas recursos) para fazer coisas que normalmente interessam aos engenheiros de sistemas, como criar métricas de desempenho, usar logs com mais eficiência, etc., à esquerda do Ciclo de Vida de Entrega de Software.
foto por em
Os desenvolvedores de software devem ser capazes de utilizar e conhecer as ferramentas de monitoramento que a empresa utiliza para realizar o monitoramento em todas as suas formas, métricas, logging, interfaces de monitoramento e, o mais importante, observe como o produto deles funciona na produção. Você não pode fazer com que os desenvolvedores invistam esforço e tempo no monitoramento até que possam ver as métricas e influenciar sua aparência, como o proprietário do produto as apresenta ao CTO no próximo briefing, etc.
Em suma
- Leve seu cavalo até a água. Mostre aos desenvolvedores quantos problemas eles podem evitar para 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 que está sendo criticado pelo CTO. Traga-os para a luz, com cuidado e calma. Se isso não funcionar, suborne, ameace e convença eles ou o proprietário do produto a implementar a obtenção dessas métricas dos aplicativos o mais rápido possível e, em seguida, desenhe os diagramas. Isto será difícil porque não será visto como uma prioridade e o roteiro do produto terá muitos projectos geradores de receitas pendentes. Portanto, você precisará de um business case para justificar o tempo e os gastos gastos na implementação do monitoramento no produto.
- Ajude os engenheiros de sistema a terem uma boa noite de sono. Mostre a eles que usar uma lista de verificação “vamos lançar” para qualquer produto que está sendo lançado é uma coisa boa. E garantir que todos os aplicativos em produção sejam cobertos por métricas ajudará você a dormir melhor à noite, permitindo que os desenvolvedores vejam o que está errado e onde. No entanto, a maneira certa de irritar e frustrar qualquer desenvolvedor, proprietário de produto ou CTO é persistir e resistir. Esse comportamento afetará a data de lançamento de qualquer produto se você esperar até o último minuto novamente, então mude para a esquerda novamente e inclua esses problemas em seu plano de projeto o mais rápido possível. Se necessário, vá para reuniões de produto. Use um bigode falso e feltro ou algo assim, nunca irá falhar. Comunique suas preocupações, demonstre benefícios claros e evangelize.
- Certifique-se de que tanto o desenvolvimento (desenvolvimento) quanto as operações (ops) entendam o significado e as consequências da movimentação das métricas do produto para a zona vermelha. Não deixe o Ops como o único guardião da saúde do produto, certifique-se de que os desenvolvedores também estejam envolvidos (#productsquads).
- Os registros são ótimos, mas as métricas também. Combine-os e não deixe que suas toras se transformem em lixo em uma enorme bola flamejante de inutilidade. Explique e mostre aos desenvolvedores por que ninguém mais entenderá seus logs, mostre a eles como é olhar logs inúteis às 3h15 da manhã.
foto por em
Isso é tudo. Novo material será lançado na próxima semana. Se você quiser saber mais sobre o curso, convidamos você a , que acontecerá na segunda-feira. E agora estamos tradicionalmente aguardando seus comentários.
Fonte: habr.com