{"id":80952,"date":"2020-05-10T01:42:22","date_gmt":"2020-05-09T23:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2"},"modified":"2020-05-10T01:42:22","modified_gmt":"2020-05-09T23:42:22","slug":"monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"Monitoramento em Data Center: como trocamos o antigo BMS pelo novo. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Monitoramento<\/p>\n

Na primeira parte, falamos sobre por que decidimos substituir o antigo sistema BMS em nossos data centers por um novo. E n\u00e3o apenas trocar, mas desenvolver do zero de acordo com nossas necessidades. Na segunda parte, contamos como fizemos isso.
\n<\/a><\/noindex><\/p>\n

An\u00e1lise de mercado<\/h2>\n

\nLevando em conta os pontos descritos em primeira parte<\/a><\/noindex> desejos e a decis\u00e3o de n\u00e3o atualizar o sistema existente, escrevemos um documento de requisitos para buscar solu\u00e7\u00f5es no mercado e fizemos consultas a v\u00e1rias grandes empresas que se dedicam apenas \u00e0 cria\u00e7\u00e3o de sistemas SCADA industriais.\u00a0<\/p>\n

As primeiras respostas deles mostraram que os l\u00edderes de mercado em sistemas de monitoramento ainda operam predominantemente em servidores f\u00edsicos, embora o processo de migra\u00e7\u00e3o para a nuvem j\u00e1 tenha come\u00e7ado neste segmento. No que diz respeito \u00e0 redund\u00e2ncia de m\u00e1quinas virtuais \u2013 essa op\u00e7\u00e3o n\u00e3o era suportada por ningu\u00e9m. Al\u00e9m disso, tinha a impress\u00e3o de que nenhum dos desenvolvedores not\u00e1veis no mercado demonstrou compreender a necessidade de redund\u00e2ncia: \"a nuvem n\u00e3o cai\" era a resposta mais comum. Basicamente, nos era oferecido colocar o monitoramento do data center na nuvem, fisicamente localizado no mesmo data center.<\/p>\n

Aqui \u00e9 necess\u00e1rio fazer uma pequena digress\u00e3o sobre o processo de sele\u00e7\u00e3o do contratante. O pre\u00e7o, claro, importa, mas durante qualquer licita\u00e7\u00e3o para a realiza\u00e7\u00e3o de um projeto complexo, na fase de di\u00e1logo com os fornecedores, voc\u00ea come\u00e7a a sentir quem dos candidatos est\u00e1 mais interessado e \u00e9 capaz de realiz\u00e1-lo.\u00a0<\/p>\n

Isso \u00e9 especialmente not\u00e1vel em projetos complexos.\u00a0<\/p>\n

Pelo tipo de perguntas de esclarecimento ao documento de requisitos, os contratantes podem ser divididos entre aqueles que est\u00e3o interessados apenas em vender (sente-se a press\u00e3o padr\u00e3o do gerente de vendas) e aqueles que est\u00e3o interessados em desenvolver o produto, ouvindo e compreendendo o cliente, fazendo corre\u00e7\u00f5es construtivas ao documento de requisitos mesmo antes da escolha final (mesmo correndo o risco real de melhorar o documento de requisitos de outro e perder a licita\u00e7\u00e3o), e, a fim, simplesmente dispostos a aceitar o desafio profissional e criar um bom produto.<\/p>\n

Tudo isso nos levou a prestar aten\u00e7\u00e3o em um desenvolvedor local relativamente pequeno - o grupo de empresas \"Sanline\", que atendeu \u00e0 maioria das nossas demandas imediatamente e estava disposto a realizar todas as necessidades relacionadas ao novo BMS.\u00a0<\/p>\n

Riscos<\/h2>\n

\nEnquanto os grandes jogadores tentavam entender o que quer\u00edamos e conduziam uma conversa lenta conosco, envolvendo especialistas de n\u00edvel pr\u00e9-venda, um desenvolvedor local agendou uma reuni\u00e3o em nosso escrit\u00f3rio com a participa\u00e7\u00e3o de sua equipe t\u00e9cnica. Nesta reuni\u00e3o, o contratante demonstrou mais uma vez a vontade de participar do projeto e, o mais importante, explicou como o sistema requisitado ser\u00e1 implementado.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Antes da reuni\u00e3o, identificamos dois riscos de trabalhar com uma equipe que n\u00e3o possui o respaldo de uma grande empresa nacional ou internacional:<\/p>\n

    \n
  1. Os especialistas poderiam superestimar suas capacidades e, como resultado, simplesmente n\u00e3o conseguir dar conta do projeto, por exemplo, utilizando softwares complexos ou projetando algoritmos de reserva invi\u00e1veis.<\/li>\n
  2. Ap\u00f3s a implementa\u00e7\u00e3o do projeto, a equipe do projeto pode se desintegrar e, consequentemente, o suporte ao produto estar\u00e1 em risco.<\/li>\n<\/ol>\n

    \nPara minimizar esses riscos, convidamos nossos pr\u00f3prios especialistas em desenvolvimento para a reuni\u00e3o. Os funcion\u00e1rios do potencial contratante foram minuciosamente questionados sobre como o sistema \u00e9 constru\u00eddo, como o processo de reserva ser\u00e1 implementado e outras quest\u00f5es nas quais n\u00e3o temos conhecimento suficiente como equipe de opera\u00e7\u00f5es.<\/p>\n

    O veredicto foi positivo: a arquitetura da plataforma BMS existente \u00e9 moderna, simples e confi\u00e1vel, podendo ser aprimorada; o esquema de reservas e sincroniza\u00e7\u00e3o proposto \u00e9 l\u00f3gico e funcional.\u00a0<\/p>\n

    O primeiro risco foi mitigado. O segundo foi eliminado ao recebermos do contratante a confirma\u00e7\u00e3o da disposi\u00e7\u00e3o de nos transferir os c\u00f3digos fonte do sistema e a documenta\u00e7\u00e3o, al\u00e9m de escolherem a linguagem de programa\u00e7\u00e3o Python, bem conhecida por nossos especialistas. Isso nos garantiu a possibilidade de manter o sistema com nossos pr\u00f3prios recursos, sem quaisquer dificuldades e evitando um longo per\u00edodo de treinamento dos funcion\u00e1rios em caso de sa\u00edda da empresa desenvolvedora do mercado.<\/p>\n

    Um dos principais benef\u00edcios da plataforma era que ela foi implementada em cont\u00eaineres Docker: nesse ambiente, funcionam o n\u00facleo, a interface web e o banco de dados do produto. Essa abordagem oferece diversas vantagens, incluindo a pr\u00e9-configura\u00e7\u00e3o para uma velocidade de implanta\u00e7\u00e3o superior em compara\u00e7\u00e3o com o modelo 'cl\u00e1ssico' e a facilidade de adicionar novos dispositivos ao sistema. O princ\u00edpio de 'tudo junto' simplifica ao m\u00e1ximo a implementa\u00e7\u00e3o do sistema: basta descompactar e j\u00e1 podemos utiliz\u00e1-lo.\u00a0<\/p>\n

    Com essa solu\u00e7\u00e3o, \u00e9 mais f\u00e1cil fazer c\u00f3pias do sistema, e aprimor\u00e1-lo e realizar upgrades podem ser feitos em um ambiente separado, sem interromper o funcionamento da solu\u00e7\u00e3o como um todo.\u00a0\u00a0<\/p>\n

    Ap\u00f3s minimizar ambos os riscos, o contratado forneceu a proposta. Nela, foram trabalhados todos os par\u00e2metros mais importantes para n\u00f3s do sistema BMS.<\/p>\n

    Redund\u00e2ncia<\/h2>\n

    \nO novo sistema BMS deveria estar na nuvem, em uma m\u00e1quina virtual.\u00a0<\/p>\n

    Sem hardware, sem servidores e todos os inconvenientes e riscos associados a esse modelo de implanta\u00e7\u00e3o \u2013 a solu\u00e7\u00e3o em nuvem nos permitiu nos livrar disso para sempre. Foi decidido que o sistema funcionaria em nossa nuvem em dois locais de data center em S\u00e3o Petersburgo e Moscovo. Estas s\u00e3o duas sistemas totalmente funcionais operando em modo active standby, com acesso para todos os profissionais autorizados.\u00a0<\/p>\n

    Os dois sistemas garantem backup m\u00fatuo, assegurando total redund\u00e2ncia tanto em poder computacional quanto em canais de transmiss\u00e3o de dados. Medidas de seguran\u00e7a adicionais tamb\u00e9m foram configuradas, incluindo backup de dados e canais, sistemas, m\u00e1quinas virtuais de forma geral, e um backup separado do banco de dados mensalmente (o recurso mais valioso em termos de gest\u00e3o e an\u00e1lise).\u00a0<\/p>\n

    Cabe destacar que a op\u00e7\u00e3o de redund\u00e2ncia no BMS foi desenvolvida especificamente para nossa solicita\u00e7\u00e3o. O esquema de redund\u00e2ncia era assim:<\/p>\n

    \"Monitoramento<\/p>\n

    Suporte<\/h2>\n

    Um ponto crucial para a explora\u00e7\u00e3o eficaz da solu\u00e7\u00e3o BMS \u00e9 o suporte t\u00e9cnico.\u00a0<\/p>\n

    Aqui \u00e9 simples: o novo sistema custaria para n\u00f3s, segundo esse indicador, 35.000 rublos por m\u00eas pelo SLA 'resposta em at\u00e9 8 horas', ou seja, 35.000 x 12 \/ 80 = $5.250 por ano. O primeiro ano \u00e9 gratuito.\u00a0<\/p>\n

    Para compara\u00e7\u00e3o: o suporte da antiga BMS do fornecedor custava $18.000 d\u00f3lares por ano, com aumento do valor para cada novo dispositivo adicionado! Al\u00e9m disso, a empresa n\u00e3o fornecia um gerente dedicado, toda a intera\u00e7\u00e3o acontecia atrav\u00e9s do gerente de vendas, que se interessava por n\u00f3s como potenciais compradores, com o respectivo foco no tratamento das solicita\u00e7\u00f5es.\u00a0<\/p>\n

    Por menos dinheiro, recebemos suporte completo do produto, com um gerente de conta que participaria do desenvolvimento do produto, com um ponto \u00fanico de entrada, etc. O suporte tornou-se significativamente mais flex\u00edvel \u2013 gra\u00e7as ao acesso direto aos desenvolvedores para ajustes r\u00e1pidos em qualquer aspecto do funcionamento do sistema, integra\u00e7\u00e3o via API, etc.<\/p>\n

    Atualiza\u00e7\u00f5es<\/h2>\n

    \nNo or\u00e7amento proposto para a nova BMS, todas as atualiza\u00e7\u00f5es est\u00e3o inclu\u00eddas no custo do suporte, ou seja, n\u00e3o requerem pagamento adicional. A exce\u00e7\u00e3o \u00e9 o desenvolvimento de funcionalidades adicionais, al\u00e9m daquelas indicadas no documento de requisitos.\u00a0<\/p>\n

    O antigo sistema previa o pagamento tanto pela atualiza\u00e7\u00e3o do software embutido gratuito (como o Java), quanto pela corre\u00e7\u00e3o de erros. N\u00e3o era poss\u00edvel abrir m\u00e3o disso, pois na aus\u00eancia de atualiza\u00e7\u00f5es o sistema em geral \"tinha lentid\u00e3o\" devido \u00e0s vers\u00f5es antigas dos componentes internos.<\/p>\n

    E, naturalmente, n\u00e3o era poss\u00edvel atualizar o software sem a compra do pacote de suporte.<\/p>\n

    Abordagem flex\u00edvel<\/h2>\n

    \nOutra exig\u00eancia fundamental dizia respeito \u00e0 interface. Quer\u00edamos garantir o acesso a ela atrav\u00e9s de um navegador da web de qualquer lugar, sem a necessidade da presen\u00e7a de um engenheiro no local do data center. Al\u00e9m disso, busc\u00e1vamos criar uma interface animada, de modo que a din\u00e2mica de funcionamento da infraestrutura fosse mais visual para os engenheiros de plant\u00e3o.\u00a0<\/p>\n

    Al\u00e9m disso, o novo sistema precisava garantir suporte para f\u00f3rmulas para o c\u00e1lculo do funcionamento de sensores virtuais em sistemas de engenharia \u2013 por exemplo, para a distribui\u00e7\u00e3o otimizada de pot\u00eancias el\u00e9tricas nas estantes de equipamentos. Para isso, \u00e9 necess\u00e1rio ter \u00e0 disposi\u00e7\u00e3o todas as opera\u00e7\u00f5es matem\u00e1ticas conhecidas, aplic\u00e1veis aos dados dos sensores.\u00a0<\/p>\n

    Al\u00e9m disso, era necess\u00e1rio acesso ao banco de dados SQL com a capacidade de extrair os dados necess\u00e1rios sobre o funcionamento dos equipamentos \u2013 ou seja, todos os registros de monitoramento de dois mil dispositivos e dois mil sensores virtuais, gerando cerca de 20 mil vari\u00e1veis.\u00a0<\/p>\n

    Tamb\u00e9m era necess\u00e1rio um m\u00f3dulo de gerenciamento de equipamentos no rack, que fornecesse uma representa\u00e7\u00e3o gr\u00e1fica da localiza\u00e7\u00e3o dos dispositivos em cada unidade, com contagem do peso total do \"hardware\", manuten\u00e7\u00e3o de uma biblioteca de dispositivos e informa\u00e7\u00f5es detalhadas sobre cada elemento.\u00a0<\/p>\n

    Aprova\u00e7\u00e3o do escopo e assinatura do contrato<\/h2>\n

    \nNa \u00e9poca em que era preciso come\u00e7ar o trabalho no novo sistema, a correspond\u00eancia com as \"grandes\" empresas ainda estava muito longe de discutir os pre\u00e7os de suas propostas, portanto, compar\u00e1mos a proposta recebida com os custos de atualiza\u00e7\u00e3o do antigo BMS (ver. a primeira parte<\/a><\/noindex>), e no resultado, a proposta se mostrou mais atraente em termos de pre\u00e7o e adequada \u00e0s nossas necessidades.<\/p>\n

    A escolha foi feita.<\/p>\n

    Ap\u00f3s a sele\u00e7\u00e3o do contratado, os advogados come\u00e7aram a elaborar o contrato, enquanto as equipes t\u00e9cnicas de ambos os lados refinavam o escopo. Como \u00e9 sabido, um escopo detalhado e bem elaborado \u00e9 a base para o sucesso de qualquer trabalho. Quanto mais concretude houver no escopo, menos decep\u00e7\u00f5es do tipo \"mas n\u00f3s quer\u00edamos diferente\".<\/p>\n

    Cito dois exemplos de n\u00edvel de detalhamento das exig\u00eancias no escopo:<\/p>\n

      \n
    1. Os operadores do Data Center t\u00eam a autoridade de adicionar novos dispositivos ao BMS, geralmente PDU. No antigo BMS, isso era um n\u00edvel de \"administrador\", que permitia, inclusive, mudar os limites das vari\u00e1veis de todos os dispositivos, e dividir fun\u00e7\u00f5es era imposs\u00edvel. Isso n\u00e3o nos agradava. Na vers\u00e3o b\u00e1sica existente da nova plataforma, o esquema era semelhante. Imediatamente indicamos no escopo que quer\u00edamos dividir esses pap\u00e9is: apenas o funcion\u00e1rio autorizado deve alterar os limites, mas os operadores ainda devem ter a capacidade de adicionar dispositivos. Esse esquema foi aceito para implementa\u00e7\u00e3o.<\/li>\n
    2. \u00a0Em qualquer BMS padr\u00e3o, existem tr\u00eas categorias t\u00edpicas de notifica\u00e7\u00f5es: VERMELHA \u2013 a\u00e7\u00e3o imediata necess\u00e1ria, AMARELA \u2013 monitoramento poss\u00edvel, AZUL \u2013 \u2018Informativa\u2019. Tradicionalmente, utilizamos as notifica\u00e7\u00f5es \u2018azuis\u2019 para monitorar extrapola\u00e7\u00f5es de par\u00e2metros comerciais, como quando o limite de pot\u00eancia do rack de um cliente \u00e9 ultrapassado. Este tipo de notifica\u00e7\u00e3o, em nosso caso, era destinado a gerentes e n\u00e3o era interessante para o servi\u00e7o de opera\u00e7\u00e3o, mas na antiga BMS, isso frequentemente congestionava a lista de incidentes ativos e atrapalhava o trabalho operacional. Mantivemos a l\u00f3gica e a diferencia\u00e7\u00e3o de cores das notifica\u00e7\u00f5es, que consideramos eficaz, mas na especifica\u00e7\u00e3o deixamos claro que as notifica\u00e7\u00f5es \u2018azuis\u2019 devem, sem distrair os plantonistas, ser \u2018despejadas\u2019 silenciosamente em uma se\u00e7\u00e3o separada, onde especialistas comerciais iriam trat\u00e1-las.<\/li>\n<\/ol>\n

      \nCom um grau semelhante de detalhamento, foram definidos os formatos de constru\u00e7\u00e3o de gr\u00e1ficos e relat\u00f3rios, as interfaces, a lista de dispositivos a serem monitorados e muitas outras quest\u00f5es.\u00a0<\/p>\n

      Foi um verdadeiro trabalho criativo de tr\u00eas grupos de trabalho \u2013 o servi\u00e7o de cliente, que imp\u00f4s suas exig\u00eancias e condi\u00e7\u00f5es; os especialistas t\u00e9cnicos de ambas as partes, que tinham a tarefa de transformar essas condi\u00e7\u00f5es em documenta\u00e7\u00e3o t\u00e9cnica; e a equipe de programadores do contratante, que implementou as exig\u00eancias do cliente segundo a documenta\u00e7\u00e3o t\u00e9cnica desenvolvida\u2026 No final, adaptamos algumas de nossas exig\u00eancias n\u00e3o essenciais para a funcionalidade j\u00e1 existente da plataforma, enquanto o contratante se comprometeu a complementar outras para n\u00f3s.\u00a0<\/p>\n

      Funcionamento paralelo de dois sistemas<\/h2>\n

      \n\"Monitoramento
      \nChegou o momento de implementar. Na pr\u00e1tica, isso significava que d\u00e1vamos ao contratante a oportunidade de implantar um prot\u00f3tipo da BMS em nossa nuvem virtual e fornec\u00edamos acesso de rede a todos os dispositivos que precisavam de monitoramento.<\/p>\n

      Neste meio tempo, o novo sistema ainda n\u00e3o estava pronto para opera\u00e7\u00e3o. Nesta fase, era importante para n\u00f3s manter o monitoramento no antigo sistema e, ao mesmo tempo, dar acesso aos dispositivos ao novo sistema. N\u00e3o \u00e9 poss\u00edvel construir um sistema corretamente sem ver os dispositivos nele, que por sua vez n\u00e3o podem ser desconectados do monitoramento do antigo sistema.\u00a0<\/p>\n

      Se os dispositivos aguentariam a consulta simult\u00e2nea de dois sistemas, n\u00e3o estava claro sem testes reais. Havia a possibilidade de que a consulta simult\u00e2nea dupla levasse a falhas frequentes nas respostas dos dispositivos e que obtiv\u00e9ssemos muitos erros de indisponibilidade, o que, por sua vez, bloquearia o funcionamento do antigo sistema de monitoramento.<\/p>\n

      O departamento de redes implementou rotas virtuais do prot\u00f3tipo do novo BMS, implantado na nuvem, para os dispositivos, e obtivemos os resultados:\u00a0<\/p>\n