Na primeira parte, falamos sobre por que decidimos substituir o antigo sistema BMS em nossos data centers por um novo. E não apenas trocar, mas desenvolver do zero de acordo com nossas necessidades. Na segunda parte, contamos como fizemos isso.
Análise de mercado
Levando em conta os pontos descritos em desejos e a decisão de não atualizar o sistema existente, escrevemos um documento de requisitos para buscar soluções no mercado e fizemos consultas a várias grandes empresas que se dedicam apenas à criação de sistemas SCADA industriais.
As primeiras respostas deles mostraram que os líderes de mercado em sistemas de monitoramento ainda operam predominantemente em servidores físicos, embora o processo de migração para a nuvem já tenha começado neste segmento. No que diz respeito à redundância de máquinas virtuais – essa opção não era suportada por ninguém. Além disso, tinha a impressão de que nenhum dos desenvolvedores notáveis no mercado demonstrou compreender a necessidade de redundância: "a nuvem não cai" era a resposta mais comum. Basicamente, nos era oferecido colocar o monitoramento do data center na nuvem, fisicamente localizado no mesmo data center.
Aqui é necessário fazer uma pequena digressão sobre o processo de seleção do contratante. O preço, claro, importa, mas durante qualquer licitação para a realização de um projeto complexo, na fase de diálogo com os fornecedores, você começa a sentir quem dos candidatos está mais interessado e é capaz de realizá-lo.
Isso é especialmente notável em projetos complexos.
Pelo tipo de perguntas de esclarecimento ao documento de requisitos, os contratantes podem ser divididos entre aqueles que estão interessados apenas em vender (sente-se a pressão padrão do gerente de vendas) e aqueles que estão interessados em desenvolver o produto, ouvindo e compreendendo o cliente, fazendo correções 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ção), e, a fim, simplesmente dispostos a aceitar o desafio profissional e criar um bom produto.
Tudo isso nos levou a prestar atenção em um desenvolvedor local relativamente pequeno - o grupo de empresas "Sanline", que atendeu à maioria das nossas demandas imediatamente e estava disposto a realizar todas as necessidades relacionadas ao novo BMS.
Riscos
Enquanto os grandes jogadores tentavam entender o que queríamos e conduziam uma conversa lenta conosco, envolvendo especialistas de nível pré-venda, um desenvolvedor local agendou uma reunião em nosso escritório com a participação de sua equipe técnica. Nesta reunião, o contratante demonstrou mais uma vez a vontade de participar do projeto e, o mais importante, explicou como o sistema requisitado será implementado.
Antes da reunião, identificamos dois riscos de trabalhar com uma equipe que não possui o respaldo de uma grande empresa nacional ou internacional:
- Os especialistas poderiam superestimar suas capacidades e, como resultado, simplesmente não conseguir dar conta do projeto, por exemplo, utilizando softwares complexos ou projetando algoritmos de reserva inviáveis.
- Após a implementação do projeto, a equipe do projeto pode se desintegrar e, consequentemente, 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 do potencial contratante foram minuciosamente questionados sobre como o sistema é construído, como o processo de reserva será implementado e outras questões nas quais não temos conhecimento suficiente como equipe de operações.
O veredicto foi positivo: a arquitetura da plataforma BMS existente é moderna, simples e confiável, podendo ser aprimorada; o esquema de reservas e sincronização proposto é lógico e funcional.
O primeiro risco foi mitigado. O segundo foi eliminado ao recebermos do contratante a confirmação da disposição de nos transferir os códigos fonte do sistema e a documentação, além de escolherem a linguagem de programação Python, bem conhecida por nossos especialistas. Isso nos garantiu a possibilidade de manter o sistema com nossos próprios recursos, sem quaisquer dificuldades e evitando um longo período de treinamento dos funcionários em caso de saída da empresa desenvolvedora do mercado.
Um dos principais benefícios da plataforma era que ela foi implementada em contêineres Docker: nesse ambiente, funcionam o núcleo, a interface web e o banco de dados do produto. Essa abordagem oferece diversas vantagens, incluindo a pré-configuração para uma velocidade de implantação superior em comparação com o modelo 'clássico' e a facilidade de adicionar novos dispositivos ao sistema. O princípio de 'tudo junto' simplifica ao máximo a implementação do sistema: basta descompactar e já podemos utilizá-lo.
Com essa solução, é mais fácil fazer cópias do sistema, e aprimorá-lo e realizar upgrades podem ser feitos em um ambiente separado, sem interromper o funcionamento da solução como um todo.
Após minimizar ambos os riscos, o contratado forneceu a proposta. Nela, foram trabalhados todos os parâmetros mais importantes para nós do sistema BMS.
Redundância
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 disso para sempre. Foi decidido que o sistema funcionaria em nossa nuvem em dois locais de data center em São Petersburgo e Moscovo. Estas são duas sistemas totalmente funcionais operando em modo active standby, com acesso para todos os profissionais autorizados.
Os dois sistemas garantem backup mútuo, assegurando total redundância tanto em poder computacional quanto em canais de transmissão de dados. Medidas de segurança adicionais também foram configuradas, incluindo backup de dados e canais, sistemas, máquinas virtuais de forma geral, e um backup separado do banco de dados mensalmente (o recurso mais valioso em termos de gestão e análise).
Cabe destacar que a opção de redundância no BMS foi desenvolvida especificamente para nossa solicitação. O esquema de redundância era assim:
Suporte
Um ponto crucial para a exploração eficaz da solução BMS é o suporte técnico.
Aqui é simples: o novo sistema custaria para nós, segundo esse indicador, 35.000 rublos por mês pelo SLA 'resposta em até 8 horas', ou seja, 35.000 x 12 / 80 = $5.250 por ano. O primeiro ano é gratuito.
Para comparação: o suporte da antiga BMS do fornecedor custava $18.000 dólares por ano, com aumento do valor para cada novo dispositivo adicionado! Além disso, a empresa não fornecia um gerente dedicado, toda a interação acontecia através do gerente de vendas, que se interessava por nós como potenciais compradores, com o respectivo foco no tratamento das solicitações.
Por menos dinheiro, recebemos suporte completo do produto, com um gerente de conta que participaria do desenvolvimento do produto, com um ponto único de entrada, etc. O suporte tornou-se significativamente mais flexível – graças ao acesso direto aos desenvolvedores para ajustes rápidos em qualquer aspecto do funcionamento do sistema, integração via API, etc.
Atualizações
No orçamento proposto para a nova BMS, todas as atualizações estão incluídas no custo do suporte, ou seja, não requerem pagamento adicional. A exceção é o desenvolvimento de funcionalidades adicionais, além daquelas indicadas no documento de requisitos.
O antigo sistema previa o pagamento tanto pela atualização do software embutido gratuito (como o Java), quanto pela correção de erros. Não era possível abrir mão disso, pois na ausência de atualizações o sistema em geral "tinha lentidão" devido às versões antigas dos componentes internos.
E, naturalmente, não era possível atualizar o software sem a compra do pacote de suporte.
Abordagem flexível
Outra exigência fundamental dizia respeito à interface. Queríamos garantir o acesso a ela através de um navegador da web de qualquer lugar, sem a necessidade da presença de um engenheiro no local do data center. Além disso, buscávamos criar uma interface animada, de modo que a dinâmica de funcionamento da infraestrutura fosse mais visual para os engenheiros de plantão.
Além disso, o novo sistema precisava garantir suporte para fórmulas para o cálculo do funcionamento de sensores virtuais em sistemas de engenharia – por exemplo, para a distribuição otimizada de potências elétricas nas estantes de equipamentos. Para isso, é necessário ter à disposição todas as operações matemáticas conhecidas, aplicáveis aos dados dos sensores.
Além disso, era necessário acesso ao banco de dados SQL com a capacidade de extrair os dados necessários sobre o funcionamento dos equipamentos – 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 era necessário um módulo de gerenciamento de equipamentos no rack, que fornecesse uma representação gráfica da localização dos dispositivos em cada unidade, com contagem do peso total do "hardware", manutenção de uma biblioteca de dispositivos e informações detalhadas sobre cada elemento.
Aprovação do escopo e assinatura do contrato
Na época em que era preciso começar o trabalho no novo sistema, a correspondência com as "grandes" empresas ainda estava muito longe de discutir os preços de suas propostas, portanto, comparámos a proposta recebida com os custos de atualização do antigo BMS (ver. ), e no resultado, a proposta se mostrou mais atraente em termos de preço e adequada às nossas necessidades.
A escolha foi feita.
Após a seleção do contratado, os advogados começaram a elaborar o contrato, enquanto as equipes técnicas de ambos os lados refinavam o escopo. Como é sabido, um escopo detalhado e bem elaborado é a base para o sucesso de qualquer trabalho. Quanto mais concretude houver no escopo, menos decepções do tipo "mas nós queríamos diferente".
Cito dois exemplos de nível de detalhamento das exigências no escopo:
- Os operadores do Data Center têm a autoridade de adicionar novos dispositivos ao BMS, geralmente PDU. No antigo BMS, isso era um nível de "administrador", que permitia, inclusive, mudar os limites das variáveis de todos os dispositivos, e dividir funções era impossível. Isso não nos agradava. Na versão básica existente da nova plataforma, o esquema era semelhante. Imediatamente indicamos no escopo que queríamos dividir esses papéis: apenas o funcionário autorizado deve alterar os limites, mas os operadores ainda devem ter a capacidade de adicionar dispositivos. Esse esquema foi aceito para implementação.
- Em qualquer BMS padrão, existem três categorias típicas de notificações: VERMELHA – ação imediata necessária, AMARELA – monitoramento possível, AZUL – ‘Informativa’. Tradicionalmente, utilizamos as notificações ‘azuis’ para monitorar extrapolações de parâmetros comerciais, como quando o limite de potência do rack de um cliente é ultrapassado. Este tipo de notificação, em nosso caso, era destinado a gerentes e não era interessante para o serviço de operação, mas na antiga BMS, isso frequentemente congestionava a lista de incidentes ativos e atrapalhava o trabalho operacional. Mantivemos a lógica e a diferenciação de cores das notificações, que consideramos eficaz, mas na especificação deixamos claro que as notificações ‘azuis’ devem, sem distrair os plantonistas, ser ‘despejadas’ silenciosamente em uma seção separada, onde especialistas comerciais iriam tratá-las.
Com um grau semelhante de detalhamento, foram definidos os formatos de construção de gráficos e relatórios, as interfaces, a lista de dispositivos a serem monitorados e muitas outras questões.
Foi um verdadeiro trabalho criativo de três grupos de trabalho – o serviço de cliente, que impôs suas exigências e condições; os especialistas técnicos de ambas as partes, que tinham a tarefa de transformar essas condições em documentação técnica; e a equipe de programadores do contratante, que implementou as exigências do cliente segundo a documentação técnica desenvolvida… No final, adaptamos algumas de nossas exigências não essenciais para a funcionalidade já existente da plataforma, enquanto o contratante se comprometeu a complementar outras para nós.
Funcionamento paralelo de dois sistemas
Chegou o momento de implementar. Na prática, isso significava que dávamos ao contratante a oportunidade de implantar um protótipo da BMS em nossa nuvem virtual e fornecíamos acesso de rede a todos os dispositivos que precisavam de monitoramento.
Neste meio tempo, o novo sistema ainda não estava pronto para operação. Nesta fase, era importante para nós manter o monitoramento no antigo sistema e, ao mesmo tempo, dar acesso aos dispositivos ao novo sistema. Não é possível construir um sistema corretamente sem ver os dispositivos nele, que por sua vez não podem ser desconectados do monitoramento do antigo sistema.
Se os dispositivos aguentariam a consulta simultânea de dois sistemas, não estava claro sem testes reais. Havia a possibilidade de que a consulta simultânea dupla levasse a falhas frequentes nas respostas dos dispositivos e que obtivéssemos muitos erros de indisponibilidade, o que, por sua vez, bloquearia o funcionamento do antigo sistema de monitoramento.
O departamento de redes implementou rotas virtuais do protótipo do novo BMS, implantado na nuvem, para os dispositivos, e obtivemos os resultados:
- os dispositivos conectados pelo protocolo SNMP praticamente não desconectavam devido às solicitações simultâneas,
- os dispositivos conectados através de gateways pelos protocolos modbus-TCP enfrentaram problemas que foram resolvidos com uma redução razoável na frequência de suas consultas.
E então começamos a observar como, diante de nossos olhos, um novo sistema estava se construindo, apresentando dispositivos já conhecidos, mas em uma nova interface – conveniente, rápida e acessível até mesmo pelo telefone.
Sobre o que conseguimos no final, contaremos na terceira parte do nosso artigo.
Fonte: habr.com
