Na primeira parte, falamos sobre por que decidimos substituir o antigo sistema BMS em nossos data centers por um novo. E não apenas mude, mas desenvolva do zero para atender às suas necessidades. Na segunda parte contamos como fizemos.
Análise de mercado.
Tendo em conta os descritos em desejos e a decisão de recusar a atualização do sistema existente, escrevemos uma especificação técnica para encontrar uma solução 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 do mercado de sistemas de monitoramento continuam trabalhando principalmente em servidores de hardware, embora o processo de migração para nuvens neste segmento já tenha começado. Quanto à reserva de máquinas virtuais, ninguém apoiou esta opção. Além disso, havia a sensação de que nenhum dos desenvolvedores visíveis no mercado sequer demonstrava compreensão da necessidade de redundância: “a nuvem não está caindo” era a resposta mais comum. Na verdade, nos foi oferecido colocar o monitoramento do data center em uma nuvem localizada fisicamente no mesmo data center.
Aqui precisamos fazer uma pequena digressão sobre o processo de seleção de um empreiteiro. O preço, claro, importa, mas durante qualquer concurso para implementação de um projeto complexo, na fase de diálogo com os fornecedores, você começa a sentir qual dos candidatos está mais interessado e capaz de implementá-lo.
Isto é especialmente perceptível em projetos complexos.
Pela natureza do esclarecimento de dúvidas às especificações técnicas, os empreiteiros podem ser divididos entre os interessados em simplesmente vender (sente-se a pressão padrão de um gerente de vendas) e os interessados em desenvolver um produto, tendo ouvido e compreendido o cliente, fazendo comentários construtivos alterações nas especificações técnicas antes mesmo da escolha final (mesmo apesar do real risco de melhorar as especificações técnicas de outra pessoa e perder o concurso), no final estão simplesmente prontos para aceitar um desafio profissional e fazer um bom produto.
Tudo isto fez-nos prestar atenção a um promotor local relativamente pequeno - o grupo de empresas Sunline, que respondeu imediatamente à maioria das nossas necessidades e estava pronto para implementar todas as necessidades relativas ao novo BMS.
Riscos
Enquanto os grandes players tentavam entender o que queríamos e mantinham conosco uma correspondência tranquila envolvendo especialistas em nível de pré-venda, o desenvolvedor local marcou uma reunião em nosso escritório com a participação de sua equipe técnica. Nesta reunião, o empreiteiro demonstrou mais uma vez o seu desejo de participar no projeto e, o mais importante, explicou como seria implementado o sistema necessário.
Antes da reunião, vimos dois riscos de trabalhar com uma equipe que não conta com os recursos de uma grande empresa nacional ou internacional:
- Os especialistas poderão sobrestimar as suas capacidades e, como resultado, simplesmente não conseguirem lidar com a situação, por exemplo, utilizarão software complexo ou conceberão algoritmos de reserva inviáveis;
- Após a conclusão do projeto, a equipe do projeto poderá se desintegrar e, portanto, o suporte ao produto ficará em risco.
Para minimizar esses riscos, convidamos nossos próprios especialistas em desenvolvimento para a reunião. Os funcionários do potencial contratante foram exaustivamente entrevistados sobre em que se baseia o sistema, como a redundância está planejada para ser implementada e outras questões nas quais nós, como serviço de operação, não somos suficientemente competentes.
O veredicto foi positivo: a arquitectura da plataforma BMS existente é moderna, simples e fiável, pode ser melhorada, o esquema de redundância e sincronização proposto é lógico e viável.
O primeiro risco foi resolvido. O segundo foi excluído após receber a confirmação do contratante de que estava pronto para nos transferir o código-fonte do sistema e a documentação, e também pela escolha da linguagem de programação Python, que era bem conhecida de nossos especialistas. Isso nos garantiu a oportunidade de manter o sistema por conta própria, sem dificuldades e um longo período de treinamento dos funcionários caso a incorporadora saia do mercado.
Uma vantagem adicional da plataforma foi que ela foi implementada em contêineres Docker: o kernel, a interface web e o banco de dados do produto funcionam neste ambiente. Essa abordagem oferece muitas vantagens, incluindo configurações predefinidas para a maior velocidade de implantação da solução em comparação com a adição “clássica” e fácil de novos dispositivos ao sistema. O princípio “todos juntos” simplifica ao máximo a implementação do sistema: basta descompactar o sistema e você poderá utilizá-lo imediatamente.
Com esta solução fica mais fácil fazer cópias do sistema, podendo melhorá-lo e implementar upgrades em um ambiente separado, sem interromper o funcionamento da solução como um todo.
Uma vez minimizados ambos os riscos, o contratante forneceu o CP. Cobriu todos os parâmetros mais importantes do sistema BMS para nós.
Reserva
O novo sistema BMS tinha que estar localizado na nuvem, numa máquina virtual.
Sem hardware, sem servidores e com todos os inconvenientes e riscos associados a este modelo de implantação - a solução em nuvem permitiu-nos livrar-nos deles para sempre. Foi decidido que o sistema operaria em nossa nuvem em dois data centers em São Petersburgo e Moscou. São dois sistemas totalmente funcionais operando em modo de espera ativo com acesso a todos os especialistas autorizados.
Os dois sistemas asseguram-se mutuamente, fornecendo reserva total de poder de computação e canais de transmissão de dados. Também foram configuradas medidas adicionais de segurança, incluindo backup de dados e canais, sistemas, máquinas virtuais em geral, e backup de banco de dados separado uma vez por mês (recurso mais valioso em termos de gerenciamento e análise).
Observe que a redundância como opção na solução BMS foi desenvolvida especificamente para nossa solicitação. O esquema de reserva em si era assim:
apoio
O ponto mais importante para o funcionamento eficaz de uma solução BMS é o suporte técnico.
Tudo é simples aqui: um novo sistema nos custaria 35 rublos de acordo com este indicador. por mês para o SLA “resposta dentro de 000 horas”, ou seja, 8 x 35/000 = US$ 12 por ano. O primeiro ano é gratuito.
Para efeito de comparação, manter o BMS antigo do fornecedor custava US$ 18 por ano, com um aumento no valor para cada novo dispositivo adicionado! Ao mesmo tempo, a empresa não disponibilizou um gestor dedicado; toda a interação ocorreu através de um gestor de vendas que se interessa por nós como potencial comprador com a correspondente ênfase no processamento de pedidos.
Por menos dinheiro, recebíamos suporte completo ao produto, com um gerente de conta 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 imediatos em qualquer aspecto do sistema, integração via API, etc.
Atualizações
De acordo com o CP proposto no novo BMS, todas as atualizações estão incluídas no custo do suporte, ou seja, não exigem pagamento adicional. A exceção é o desenvolvimento de funcionalidades adicionais além do especificado nas especificações técnicas.
O sistema antigo exigia pagamento tanto para atualizações de firmware (como Java) quanto para correções de bugs. Era impossível recusar; na ausência de atualizações, o sistema como um todo “desacelerou” devido a versões antigas de componentes internos.
E, claro, era impossível atualizar o software sem adquirir um pacote de suporte.
Abordagem flexível
Outro requisito fundamental dizia respeito à interface. Queríamos acessá-lo através de um navegador web de qualquer lugar, sem a presença obrigatória de um engenheiro no território do data center. Além disso, buscou-se criar uma interface animada para que a dinâmica da infraestrutura ficasse mais clara para os engenheiros de plantão.
Também no novo sistema foi necessário fornecer suporte para fórmulas de cálculo de operação de sensores virtuais em sistemas de engenharia - por exemplo, para distribuição ideal de energia elétrica entre racks de equipamentos. Para fazer isso, você precisa ter à sua disposição todas as operações matemáticas usuais aplicáveis aos indicadores de sensores.
Em seguida, foi necessário o acesso a uma base de dados SQL com a possibilidade de retirar dela os dados necessários ao funcionamento dos equipamentos - nomeadamente, todos os registos de monitorização de dois mil dispositivos e dois mil sensores virtuais gerando cerca de 20 mil variáveis.
Também foi necessário um módulo de contabilização de equipamentos de rack, proporcionando uma representação gráfica da disposição dos dispositivos em cada unidade com cálculo do peso total do hardware, mantendo uma biblioteca de dispositivos e informações detalhadas sobre cada elemento.
Aprovação de especificações técnicas e assinatura de contrato
Na altura em que foi necessário iniciar os trabalhos no novo sistema, a correspondência com as “grandes” empresas ainda estava muito longe de discutir o custo das suas propostas, pelo que comparamos o CP recebido com os custos de atualização do antigo BMS (ver. ), e como resultado acabou sendo mais atraente no preço e atendendo às nossas necessidades.
A escolha foi feita.
Depois de selecionar um empreiteiro, os advogados começaram a elaborar um acordo e as equipes técnicas de ambos os lados começaram a aprimorar as especificações técnicas. Como sabem, especificações técnicas detalhadas e competentes são a base para o sucesso de qualquer obra. Quanto mais especificidades houver nas especificações técnicas, menos decepções do tipo “mas não era isso que queríamos”.
Darei dois exemplos do nível de detalhamento dos requisitos nas especificações técnicas:
- Os data centers de plantão têm autonomia para adicionar novos dispositivos ao BMS, na maioria das vezes são PDUs. No antigo BMS, este era o nível “administrador”, que também permitia alterar as configurações variáveis de todos os dispositivos, sendo impossível separar as funções. Isso não nos convinha. Na versão básica existente da nova plataforma, o esquema era semelhante. Indicamos imediatamente nos termos de referência que queríamos separar essas funções: apenas um funcionário autorizado deveria alterar as configurações, mas os de plantão deveriam continuar podendo adicionar dispositivos. Este esquema foi aceito para implementação.
- Em qualquer BMS padrão existem três categorias típicas de notificações: VERMELHA - devem ser respondidas imediatamente, AMARELO - podem ser observadas, AZUL - “Informativas”. Tradicionalmente usamos alertas azuis para monitorar quando os parâmetros de negócios foram excedidos, como o rack de um cliente excedendo seu limite de capacidade. Este tipo de notificação, no nosso caso, destinava-se aos gestores e não interessava ao serviço de operações, mas no antigo BMS obstruía regularmente a lista de incidentes activos e interferia no trabalho operacional. Consideramos bem-sucedida a própria lógica e diferenciação de cores das calças de notificação e a mantivemos, no entanto, as especificações técnicas indicavam especificamente que as notificações “azuis” deveriam, sem distrair os oficiais de plantão, “despejar” silenciosamente em uma seção separada, onde eles serão tratados por especialistas comerciais.
Com grau de detalhamento semelhante, foram prescritos os formatos para construção de gráficos e geração de relatórios, os contornos das interfaces, a lista de dispositivos que precisavam ser monitorados e muitas outras coisas.
Este foi um trabalho verdadeiramente criativo de três grupos de trabalho – o de atendimento ao cliente, que ditou os seus requisitos e condições; especialistas técnicos de ambos os lados, cuja tarefa era transformar essas condições em documentação técnica; equipes de programadores contratados que implementaram os requisitos do cliente de acordo com o desenvolvido documentação técnica... Como resultado, adaptamos alguns de nossos requisitos sem princípios à funcionalidade de uma plataforma existente, e o contratante se comprometeu a acrescentar algo para nós.
Operação paralela de dois sistemas
É hora de implementação. Na prática, isto significou que demos ao contratante a oportunidade de implementar um protótipo de BMS na nossa nuvem virtual e fornecer acesso de rede a todos os dispositivos que necessitam de monitorização.
No entanto, o novo sistema ainda não estava pronto para operação. Nesta fase era importante para nós manter a monitorização no sistema antigo e ao mesmo tempo dar acesso aos dispositivos do novo sistema. É impossível construir um sistema adequadamente sem ver os dispositivos nele, que por sua vez não podem ser desativados no monitoramento do sistema antigo.
Se os dispositivos poderiam suportar interrogatórios simultâneos por dois sistemas não era óbvio sem testes reais. Havia a possibilidade de que a sondagem dupla simultânea levasse a recusas frequentes de resposta dos dispositivos e receberíamos muitos erros relativos à indisponibilidade dos dispositivos, o que por sua vez bloquearia o funcionamento do antigo sistema de monitoramento.
O departamento de rede executou rotas virtuais de um protótipo do novo BMS implantado na nuvem até os dispositivos, e obtivemos os resultados:
- dispositivos conectados via protocolo SNMP praticamente nunca foram desconectados devido a solicitações simultâneas,
- dispositivos conectados por meio de gateways usando protocolos modbas-TCP tiveram problemas que foram resolvidos com a redução inteligente de sua frequência de polling.
E então começamos a observar como um novo sistema estava sendo construído diante de nossos olhos, nele surgiam dispositivos já familiares para nós, mas em uma interface diferente - conveniente, rápida, acessível até mesmo de um telefone.
Contaremos o que aconteceu no final, na terceira parte do nosso artigo.
Fonte: habr.com