Há muito tempo, em uma galáxia muito distante, havia uma empresa que cresceu de uma startup para algo muito maior, mas por um tempo o departamento de TI ainda era compacto e muito eficiente. Essa empresa hospedou centenas de servidores Windows virtuais e, é claro, esses servidores foram monitorados. Mesmo antes de ingressar na empresa, o NetIQ havia sido escolhido como uma solução de monitoramento.
Uma das minhas novas tarefas era oferecer suporte ao NetIQ. A pessoa que trabalhou com o NetIQ antes, falou muito sobre sua experiência com o NetIQ, infelizmente, se eu tentar colocá-lo aqui, seria apenas uma longa fila de caracteres '****'. Logo eu percebi o porquê. Steve Jobs provavelmente está girando em seu túmulo olhando para a interface assim:
Na primeira linha, a lógica da caixa de seleção é positiva (
evento de aumento ); na próxima, negativa (
evento de não elevação ). Então, como '
Aumentar evento somente i f' funciona? Eu não tenho ideia.
No entanto, havia algo muito pior no NetIQ: seu agente de monitoramento era muito frágil. Muito mais vulnerável que o próprio Windows. Pouca memória? O agente está inoperante. CPU é 100%? O agente não responde. 0 bytes livres restantes em uma unidade de disco? Bem, para enviar uma mensagem de alerta, um agente deve primeiro salvá-lo em um arquivo em um disco ... Então, sim, você não recebe nenhum alerta nesse caso.
No entanto, “não conserte o que não está quebrado” e, de alguma forma, vivemos com ele até que nossa empresa foi comprada por uma muito maior. Quando uma grande empresa compra uma pequena, a pequena se dissipa como uma gota de água no mar. No entanto, no nosso caso, nós (da perspectiva da TI) não éramos muito menores que a TI de uma empresa maior, e era óbvio desde o início que a fusão seria muito complicada. Tão complicado que, por um tempo, fomos deixados sozinhos como um departamento independente e todos os processos de negócios e de TI permaneceram os mesmos - apenas sob o guarda-chuva do novo nome. Isso me lembra o momento em que
O ANEL estava deitado na lava, mas ainda não começou a derreter.
Enquanto isso, eu atualizei o NetIQ da versão 7 para 8 e posterior para a versão 9. Foi quando todos os nossos problemas começaram. Estávamos usando o NetIQ para monitorar apenas algumas coisas básicas: disponibilidade de um servidor, memória, CPU, espaço em disco e o mais importante para nós - status dos serviços domésticos. Quando qualquer tipo de inicialização de serviço desenvolvido em casa foi definido como "Automático", ele deve estar sempre em execução (caso contrário, consideramos travado). Não deve haver casos como este:
Portanto, o NetIQ parou de monitorar o status dos serviços. Após uma semana de experimentação e outra semana de chamadas com o suporte do NetIQ, tínhamos aprendido que “
não era um bug, era um recurso ” e o alerta era acionado apenas quando um processo saía com um código de saída específico. E nossos serviços falharam com QUALQUER código.
Nesse ponto, era tarde demais para reverter. Como você entende, assim que descobrimos que nossa infraestrutura crítica não foi monitorada, imediatamente ... eh ... não fizemos nada. Porque naquela época o processo de “fusão” da nossa empresa em uma maior atingiu uma fase ativa, e era assim:
Ouvi sons de trovão muito acima, e parecia que os deuses no Olimpo estavam decidindo o destino do mundo, enquanto eu tentava distraí-los com meu minúsculo problema técnico. Ao mesmo tempo, não conseguia dormir sabendo que nosso sistema de monitoramento estava meio cego.
Depois de perceber que não havia mais o que esperar, decidi criar uma solução rápida e suja - um minúsculo scanner de serviço que deveria passar por todos os servidores para verificar os serviços e enviar e-mails para os serviços que estavam inativos, exatamente como na versão antiga do NetIQ fez. Você pode pensar que o script do PowerShell é a melhor maneira de fazê-lo, mas ... Se tudo o que você tem é um martelo, tudo parece um prego. Se você é um DBA que trabalhou com SQL desde a versão 6.0, então ... Aqui está um pequeno extrato do código, para que você possa entender do que estou falando:
Levei apenas algumas horas para escrever a primeira solução. Durante os próximos dias, adicionei uma auditoria, parâmetros e outras coisas sofisticadas. Depois de examinar o que o comando WMIC poderia fazer, não consegui parar. Não me lembro exatamente do que aconteceu nas próximas duas semanas - tudo estava meio embaçado, mas quando acordei, todos os recursos do NetIQ foram implementados usando SQL puro.
Eu não apenas copiei a funcionalidade NetIQ "como está", eu havia implementado tudo o que sempre sonhei. No alerta de e-mail do LOWDISK, você também anexa um PDF com um gráfico de crescimento do uso do disco para entender instantaneamente se o crescimento foi genuíno ou se algo deu errado. Pouca memória - e você obtém não apenas o gráfico, mas também uma distribuição de memória por processo. Além disso, para w3wp.exe, você recebe um nome de pool anexado. Eu também havia implementado lembretes inteligentes com proteção contra inundações e muitas outras coisas sofisticadas. BTW, a lista de servidores virtuais foi extraída automaticamente dos repositórios VMware. Ao olhar para os assuntos de alerta em um cliente móvel, você pode dizer instantaneamente o que estava acontecendo - mesmo sem abrir os emails:
Os desenvolvedores modernos se acostumaram a criar níveis de abstração a ponto de prejudicar sua capacidade de escrever um código simples e direto. Eles não podem criar um sistema de monitoramento sem dizer: “Ok, para qualquer servidor, podemos executar qualquer conjunto de scripts com regras de um repositório ... Quão flexível ...”. Mas o monitoramento de algumas coisas fundamentais, como status de memória, CPU, disco, serviços, é único. Ao implementar a verificação dessas condições básicas com um nível de abstração, elas terminam com um código que funciona igualmente ruim para todos os casos. Este é um exemplo do sistema SCOM. Tenho certeza de que foi implementado exatamente pelas especificações:
Mas a grande vantagem do novo sistema era que não havia nenhum agente. Sem agentes - nada para instalar, nada para quebrar. O sistema era simples e confiável como um hummer.
Poucos meses depois, cheguei ao trabalho e passei uma ou duas horas trabalhando em minha nova criação - lentamente, sem prazos e ETAs, deixando quase nenhuma dívida técnica. Depois de um tempo eu me forcei a parar.
O NetIQ ainda estava em produção, mas as pessoas definitivamente preferiram alertas do novo sistema, mais confiáveis e informativos. Gradualmente, mudei todos os "assinantes" de alerta para o novo sistema, mantendo, no entanto, o antigo sistema ativo. Enquanto isso, o processo de "fusão" de nossa antiga empresa em uma maior chegara à sua fase final:
Bem, tudo tem um fim. Fiquei até surpreso por ter tido a chance de brincar com essas coisas em uma grande empresa burocrática. Após um mês de preparação, disseram-me que “
ok, em uma semana, encerramos o NetIQ e passamos para o SCOM como padrão corporativo ”. Desliguei o NetIQ (tenho que admitir, odiei tanto que foi um dos momentos mais felizes da minha carreira) e comecei a esperar o SCOM chegar. Mas não havia. Nada desde uma semana, mês e até um quarto.
Obtivemos o SCOM somente após 6 meses completos - alguém tinha esquecido o custo das licenças para o grande número de servidores que tínhamos. Nesses 6 meses, muitos departamentos tornaram-se tão dependentes do novo sistema, que mantinha não apenas os alertas, mas também as métricas e inventários de desempenho, que estava fora de questão desativá-lo. Tornou-se um segundo sistema de backup. Para os auditores, existe o SCOM, para as coisas realmente úteis - existe a minha criação.
De tempos em tempos, os gerentes de diferentes níveis hierárquicos passavam por cima dos alertas desse sistema e perguntavam - o que é? Recentemente, eu expliquei toda a história por trás deste produto. Eles riram e deixaram esse sistema funcionar, e para mim foi uma chance de escrever um código como quando eu era estudante - guiado não por especificações, mas baseado no meu próprio entendimento, como um hobby. Foi muito divertido.
Artigo em russo