🖕🏽 📥 😡 Monitoramento no data center: como alteramos o antigo BMS para um novo. Parte 2 ✊ 👧🏻 ⛅️

Na primeira parte, falamos sobre por que decidimos mudar o antigo sistema BMS em nossos data centers para um novo. E não apenas mudar, mas desenvolver a partir do zero para atender às suas necessidades. Na segunda parte, mostramos como fizemos.

Análise de mercado

Com base nos desejos e decisões descritos na primeira parte , para recusar a atualização do sistema existente, escrevemos uma declaração de trabalho para encontrar uma solução no mercado e fizemos consultas a várias grandes empresas envolvidas apenas na criação de sistemas SCADA industriais.

As primeiras respostas deles mostraram que os líderes do mercado de sistemas de monitoramento continuam trabalhando principalmente em servidores de ferro, embora o processo de migração para as nuvens nesse segmento já tenha começado. Quanto às máquinas virtuais de backup - ninguém suportou esta opção. Além disso, havia um sentimento de que nenhum dos desenvolvedores visíveis no mercado sequer mostrava um entendimento da necessidade de redundância: "a nuvem não cai", foi a resposta mais comum. De fato, nos foi oferecido colocar o monitoramento do data center em uma nuvem localizada fisicamente no mesmo data center.

Aqui é necessário fazer uma pequena digressão sobre o processo de seleção de um contratado. O preço, é claro, é importante, mas durante qualquer licitação para a implementação de um projeto complexo, no estágio do diálogo com os fornecedores, você começa a sentir qual dos candidatos está mais interessado e capaz de implementá-lo.

Isso é especialmente visível em projetos complexos.

Pela natureza das perguntas de esclarecimento da TK, é possível dividir os contratados entre os interessados simplesmente para vender (a pressão padrão do gerente de vendas é sentida) e os interessados em desenvolver o produto, depois de ouvir e entender o cliente, para fazer alterações construtivas nas especificações técnicas antes mesmo da escolha final (mesmo apesar da real risco de melhorar a TK de outra pessoa e perder a licitação), no final, apenas pronto para aceitar o desafio profissional e criar um bom produto.

Tudo isso nos fez prestar atenção a um desenvolvedor local relativamente pequeno - o grupo de empresas Sunline, que respondeu à maioria de nossos requisitos imediatamente e estava pronto para atender a todas as necessidades relacionadas ao novo BMS.

Os riscos

Enquanto os grandes jogadores estavam tentando entender o que queremos, e estávamos em uma agradável correspondência com a ajuda de especialistas em pré-venda, um desenvolvedor local marcou uma consulta em nosso escritório com a participação de sua equipe técnica. Nesta reunião, o contratado demonstrou novamente o desejo de participar do projeto e, o mais importante, explicou como o sistema necessário será implementado.

Antes da reunião, vimos dois riscos de trabalhar com uma equipe que não possui os recursos de uma grande empresa nacional ou internacional:

Os especialistas podem superestimar suas capacidades e, como resultado, simplesmente não conseguem lidar, por exemplo, usam software sofisticado ou projetam algoritmos de backup impraticáveis.
Após a implementação do projeto, a equipe do projeto pode terminar e, portanto, o suporte ao produto estará em risco.

Para minimizar esses riscos, convidamos nossos próprios especialistas em desenvolvimento para a reunião. Os funcionários de um contratado em potencial foram cuidadosamente entrevistados sobre em que o sistema se baseia, como ele planeja implementar reservas e sobre outros assuntos em que nós, como serviço de operação, não somos competentes o suficiente.

O veredicto foi positivo: a arquitetura da plataforma BMS existente é moderna, simples e confiável, pode ser finalizada, o esquema de backup e sincronização proposto é lógico e eficiente.

Eles lidaram com o primeiro risco. Eles excluíram o segundo, tendo recebido confirmação do contratado de que estavam prontos para fornecer o código-fonte do sistema e da documentação, além de escolher a linguagem de programação Python, que é bem conhecida por nossos especialistas. Isso nos garantiu a oportunidade de manter o sistema por conta própria, sem dificuldades e um longo período de treinamento para os funcionários, caso a empresa desenvolvedora saia do mercado.

Uma vantagem adicional da plataforma foi que ela foi implementada em contêineres do Docker: nesse ambiente, o kernel, a interface da web e a função de banco de dados do produto. Essa abordagem oferece muitas vantagens, incluindo configurações predefinidas para a maior velocidade de implantação da solução em comparação com os "clássicos" e a simples adição de novos dispositivos ao sistema. O princípio de “tudo junto” simplifica a implementação do sistema o máximo possível: é suficiente descompactar o sistema e você pode operá-lo imediatamente.

Com essa solução, é mais fácil fazer cópias do sistema e é possível melhorá-lo e implementar atualizações em um ambiente separado, sem interromper a solução como um todo.

Depois que os dois riscos foram minimizados, o contratado forneceu a KP. Ele elaborou todos os parâmetros mais importantes do sistema BMS para nós.

Reserva

O novo sistema BMS deveria estar na nuvem em uma máquina virtual.

Sem hardware, sem servidores e todos os inconvenientes e riscos associados a esse modelo de implantação - a solução em nuvem nos permitiu nos livrar deles para sempre. Foi decidido que o sistema funcionaria em nossa nuvem em dois locais de data center em São Petersburgo e Moscou. Estes são dois sistemas totalmente funcionais que operam no modo de espera ativa com acesso a todos os especialistas autorizados.

Os dois sistemas garantem um ao outro, fornecendo uma reserva completa para os canais de transmissão de dados e energia de computação. Medidas de segurança adicionais também são configuradas, incluindo backup de dados e canais, sistemas, máquinas virtuais em geral e um backup separado do banco de dados uma vez por mês (o recurso mais valioso na perspectiva de gerenciamento e análise).

Observe que a redundância como opção da solução BMS foi desenvolvida especificamente para nossa solicitação. O próprio esquema de backup ficou assim:

Apoio, suporte

O ponto mais importante para a operação eficaz de uma solução BMS é o suporte técnico.

Tudo é simples aqui: um novo sistema nos custaria 35.000 rublos neste indicador. por mês para o SLA "resposta em 8 horas", ou seja, 35.000 x 12/80 = US $ 5.250 por ano. O primeiro ano é grátis.

Para comparação: o suporte do antigo BMS do fornecedor custa US $ 18.000 por ano, com um aumento no valor de cada novo dispositivo adicionado! Ao mesmo tempo, a empresa não forneceu um gerente dedicado, toda a interação ocorreu por meio de um gerente de vendas que está interessado em nós como potencial comprador, com ênfase correspondente no processamento de solicitações.

Por menos dinheiro, recebemos suporte completo para o produto, com um gerente de contas que participaria do desenvolvimento do produto, com um único ponto de entrada etc. O suporte tornou-se muito mais flexível - graças ao acesso direto aos desenvolvedores para ajustes operacionais em qualquer aspecto do sistema, integração via API etc.

Atualizações

De acordo com o KP proposto no novo BMS, todas as atualizações estão incluídas no custo do suporte, ou seja, não exige pagamento adicional. Uma exceção é o desenvolvimento de funcionalidades adicionais além das especificadas no ToR.

O sistema antigo assumia o pagamento pela atualização do firmware do software livre (como Java) e pela correção de bugs. Era impossível recusar isso, na ausência de atualizações, o sistema como um todo "diminuiu a velocidade" devido a versões antigas de componentes internos.

E, é claro, era impossível atualizar o software sem comprar um pacote de suporte.

Abordagem flexível

Outro requisito fundamental dizia respeito à interface. Queríamos fornecer acesso a ele por meio de um navegador da Web de qualquer lugar, sem a presença de um engenheiro no data center. Além disso, nos esforçamos para criar uma interface animada, para que a dinâmica do funcionamento da infraestrutura fosse mais visível para os engenheiros de serviço.

Também no novo sistema, foi necessário fornecer suporte para fórmulas para o cálculo da operação de sensores virtuais em sistemas de engenharia - por exemplo, para a distribuição ideal de energia elétrica entre racks com equipamentos. Para isso, você deve ter à sua disposição todas as operações matemáticas usuais aplicáveis aos indicadores de sensores.

Além disso, era necessário o acesso ao banco de dados SQL, com a capacidade de extrair dele os dados necessários sobre a operação do equipamento - ou seja, todos os registros de monitoramento de dois mil dispositivos e dois mil sensores virtuais, gerando cerca de 20 mil variáveis.

Também precisávamos de um módulo para equipamentos de contabilidade no rack, fornecendo uma representação gráfica da localização dos dispositivos em cada unidade com o cálculo do peso total do hardware, mantendo uma biblioteca de dispositivos e informações detalhadas sobre cada elemento.

Harmonização da TK e assinatura de um acordo

Naquela época, quando era necessário iniciar o trabalho no novo sistema, a correspondência com empresas "grandes" ainda estava muito longe de discutir o custo de suas propostas, por isso comparamos o KP recebido com os custos de atualização do antigo BMS (consulte a primeira parte ) e Como resultado, mostrou-se mais atraente em termos de preço e correspondendo às nossas necessidades.

A escolha foi feita.

Depois de escolher um contratado, os advogados começaram a elaborar um contrato e as equipes técnicas de ambos os lados aprimoraram as especificações técnicas. Como você sabe, um TK detalhado e competente é a base para o sucesso de qualquer trabalho. Quanto mais detalhes em TK, menos decepções, como "mas não gostamos disso".

Vou dar dois exemplos do nível de detalhe dos requisitos no TK:

BMS , PDU. BMS «», , . . . , : , . .
BMS : – , – , – «». «» , , . , BMS . , , «» , , «» , .

Com um grau de detalhe semelhante, formatos de gráficos e relatórios, esboços de interface, uma lista de dispositivos que precisavam ser monitorados e muitas outras coisas foram prescritas.

Foi um trabalho verdadeiramente criativo de três grupos de trabalho - atendimento ao cliente, que ditou seus requisitos e condições; especialistas técnicos de ambos os lados, cuja tarefa era converter essas condições em documentação técnica; equipes de programadores contratados que implementaram os requisitos do cliente para a documentação técnica desenvolvida ... Como resultado, adaptamos alguns de nossos requisitos sem princípios à funcionalidade de uma plataforma existente, algo que o contratante se comprometeu a adicionar para nós.

Operação paralela de dois sistemas

Está na hora da implementação. Na prática, isso significava que estávamos dando ao contratado a oportunidade de implantar um protótipo BMS em nossa nuvem virtual e fornecer acesso à rede a todos os dispositivos que requerem monitoramento.

Além disso, o novo sistema ainda não estava pronto para operação. Nesse estágio, era importante manter o monitoramento no sistema antigo e, ao mesmo tempo, dar acesso aos dispositivos do novo sistema. É impossível construir um sistema normalmente sem ver dispositivos nele, que por sua vez não podem ser desconectados do monitoramento pelo sistema antigo.

Se os dispositivos podem suportar pesquisas simultâneas por dois sistemas não era óbvio sem testes reais. Era possível que uma pesquisa simultânea dupla levasse à negação frequente de respostas dos dispositivos e receberíamos muitos erros devido à indisponibilidade de dispositivos, o que, por sua vez, impediria a operação do antigo sistema de monitoramento.

O departamento de rede lançou rotas virtuais do protótipo do novo BMS implantado na nuvem para os dispositivos, e obtivemos os resultados:

os dispositivos conectados via protocolo SNMP praticamente não se desconectaram devido a chamadas simultâneas,
os dispositivos conectados via gateways usando os protocolos modbas-TCP tiveram problemas resolvidos por uma redução razoável na frequência de suas pesquisas.

E então começamos a observar como um novo sistema estava sendo construído diante de nossos olhos, já familiares para nós, os dispositivos apareciam nele, mas em uma interface diferente - conveniente, rápida, acessível, mesmo pelo telefone.

Falaremos sobre o que aconteceu como resultado na terceira parte do nosso artigo.

Monitoramento no data center: como alteramos o antigo BMS para um novo. Parte 2