Nas partes anteriores, falamos sobre como criamos e implementamos um novo sistema de monitoramento de data center. Como resultado, temos um mecanismo poderoso para rastrear e manter estatísticas de todos os parâmetros do data center que afetam a disponibilidade de seus recursos e indicadores de operação ininterrupta.
A próxima tarefa no caminho do desenvolvimento do sistema foi a questão de seu ajuste: como torná-lo conveniente para trabalhar com o novo sistema, e ele mesmo seria o mais informativo possível?
O problema aqui é que a funcionalidade do sistema permite habilitar muitas notificações e sinais de emergência - com tais configurações, a equipe será forçada a responder constantemente a eles, elaborando os cenários apropriados.
Outra opção é definir um número insuficiente dessas notificações, criando riscos para os atendentes perderem um evento realmente importante.
Nesta parte, compartilharemos nossa experiência prática na configuração de nosso sistema de monitoramento de data center.
Um pouco de teoria
“As variáveis coletadas pelo sistema SCADA se dividem em tele-sinalização e telemetria” - me ensinaram uma vez no instituto. E, de fato, nada mudou: o telesignaling é um estadodispositivos, por exemplo, "nenhum alarme", "há um alarme", "aberto", "fechado", etc.
E a telemetria, como você pode imaginar, é o valor digital de algum parâmetro, por exemplo, "220 Volts" ou "10 Amperes".
O estado ou valor definido pelo usuário no qual uma mensagem (alarme) aparece na tela é chamado de “setpoint”. Você pode definir um atraso antes que a mensagem apareça, ou seja, o alarme só aparece na tela após X segundos (desde que a emergência não tenha parado antes) ou para "congelar" a mensagem na tela - neste caso, o alarme já desapareceu, mas a mensagem a respeito fica na tela armazenada por mais X segundos.
Os acidentes por prioridade são normalmente divididos em três tipos principais: "Vermelho", "Amarelo" e "Azul". Acidentes "vermelhos" exigem ação imediata dos funcionários, "Amarelo" os avisa sobre algo, "Azul" geralmente relata alguns eventos não críticos. Por exemplo, deduzimos acidentes "Azuis" do resumo que os atendentes veem e os utilizam para monitorar vários parâmetros comerciais (excedendo a capacidade solicitada). Esses acidentes são informados apenas aos gestores e não distraem os atendentes.
Para a comodidade de configurar o mesmo tipo de equipamento, as variáveis em dispositivos diferentes, mas com o mesmo nome (por exemplo, "OutputCurrent") têm as mesmas configurações em todos os dispositivos do sistema. Se mudarmos a configuração em um lugar, ela mudará em todos os lugares.
Quando um dispositivo requer configurações individuais para a variável necessária, aplicamos uma marca especial "Apenas para este dispositivo". Agora a variável tornou-se individual para um dispositivo específico, tem sua própria configuração e não afeta outras variáveis com o mesmo nome.
Além disso, os próprios dispositivos têm suas próprias configurações de fábrica. Por exemplo, a PDU é configurada de fábrica para reconhecer um alarme de sobrecorrente de 32A. Se for acionado, a PDU notificará sobre o tipo de alarme "Alarme de sobrecarga". E esta é uma variável completamente diferente, não relacionada à variável "OutputCurrent" configurada no BMS.
Exemplo de configurações padrão de fábrica dentro de uma PDU:
Assim, listamos as principais funcionalidades para configurar um sistema de monitoramento.
Como afinar esse "piano" corretamente? Vamos repassar as tarefas em ordem.
O que queremos alcançar
A tarefa mais importante: qualquer mensagem de alarme na
A segunda tarefa é minimizar mensagens falsas ou não informativas. Não importa o quão atencioso e responsável você possa ter, se algo está constantemente piscando, piscando e zumbindo na frente de seus olhos, então eles perderão um acidente real, se afogarão em um mar de alertas ou desligarão o som - e como resultado, eles também perderão o alerta de incidente.
Etapa 1. Determinação das variáveis necessárias e desnecessárias para cada dispositivo
Normalmente, cada dispositivo vem com um chamado "mapa de variáveis", com base no qual um "driver" é criado pelo engenheiro de comissionamento. Sua tarefa é "indicar" ao sistema de monitoramento em qual registro dos dados recebidos se encontra a variável solicitada. Por exemplo, o registro 1 do protocolo de pesquisa do dispositivo contém informações sobre o modo de operação do motor "System_on_fun" e o registro 2 - sobre o modo de operação do compressor "Compressor_1".
O número de variáveis para um dispositivo costuma ser superior a 100. O funcionário que configura inicialmente o sistema (geralmente um engenheiro de TI) não pode decidir por si mesmo o que é importante aqui e o que não é. Como regra, todas as variáveis são adicionadas ao monitoramento de acordo com o princípio “e se elas forem úteis”.
A princípio, isso é permitido - a equipe de operações pode olhar os valores reais de todas as variáveis disponíveis e entender o que eles realmente precisam. Mas se você deixar o sistema neste estado por muito tempo, teremos os seguintes efeitos negativos:
- Variáveis supérfluas carregam a tarefa operacional do sistema de monitoramento e aumentam o tamanho do arquivo, o sistema é forçado a processar e salvar dados desnecessários.
- Quanto mais variáveis forem pesquisadas, maior será a probabilidade de falha na pesquisa. Isso é especialmente verdadeiro para dispositivos conectados por meio de um loop (por exemplo, por meio de um gateway usando o protocolo MODBUS). Isso leva ao recebimento dos estados "sem dados (N / A)" ou "quebra de comunicação", ou seja, o dispositivo sai periodicamente da monitoração.
- Algumas variáveis são supérfluas "por padrão". Por exemplo, sua versão do equipamento não possui compressor ou sensor de pressão, mas eles são cadastrados no driver universal para toda a gama de modelos de equipamentos e são sondados, sendo adicionados ao arquivo, carregando a rede e processando.
As imagens mostram parte do código do driver. Os // símbolos indicam variáveis ocultas da votação. Também é visível uma lista de variáveis exibidas para o usuário ao definir os pontos de ajuste no próprio BMS.
De acordo com a nossa experiência, é melhor não mexer nas configurações de fábrica dentro dos dispositivos na fase inicial (claro, se eles já não informarem sobre o acidente). No entanto, a cada sessão de treinamento em um equipamento específico, os funcionários devem ser lembrados da presença de configurações no próprio dispositivo e no BMS. No futuro, isso ajudará os atendentes a entender exatamente o que exatamente é a causa da mensagem de alarme.
As variáveis supérfluas no driver devem ser gradualmente reveladas e ocultadas da votação, e as restantes devem ser divididas entre aquelas às quais as configurações devem ser atribuídas e as que são salvas sem configurações apenas para análises e estatísticas subsequentes.
Isso não deve ser feito pelo ajustador do sistema, mas por um funcionário que entende a operação do sistema controlado pelo sistema de monitoramento - de preferência o engenheiro-chefe ou o engenheiro-chefe de energia.
Estágio 2. Minimização de mensagens falsas e não informativas Os
falsos positivos costumam ocorrer devido a falhas na pesquisa do dispositivo. Se a placa de rede do dispositivo não for autoalimentada, uma falha no polling e uma queda real de energia serão exibidas como um tipo de falha - "falha de comunicação".
Neste caso, é necessário dividir o equipamento em crítico (por exemplo, PDU) e ordinário (por exemplo, painéis de ventilação "SHCHUV"). Para equipamentos convencionais, você pode definir um atraso para o sinal de "desconexão" (por exemplo, 300 segundos) - então a maioria das desconexões falsas será ignorada.
É claro que tal atraso não pode ser colocado em equipamentos críticos, portanto, se ele constantemente dá falsas falhas, então você deve lidar com a rede física, o número de variáveis pesquisadas. É bem possível que muitos dispositivos estejam "travados" em um gateway e seja necessário segmentar a rede adicionando novos gateways.
Os acidentes não informativos ocorrem com mais frequência durante processos transitórios. Eles não podem ser chamados de falsos - eles realmente existem, mas são "normais" para um modo de operação específico do equipamento. O exemplo mais óbvio é a transição para um grupo gerador a diesel.
Neste caso, uma parte do equipamento alimentado sem um no-break "normalmente" é desenergizado e dá um erro de "desconexão", e o próprio no-break emite um monte de mensagens - "sem energia na entrada", "sem energia em bypass "," fonte de alimentação da bateria "Etc. A equipe recebe imediatamente dezenas de mensagens.
Para otimizar o número de mensagens ao mudar para DGS, você deve:
- definido para alarmes que aparecem “normalmente” durante a transição, atrasos de tempo mais longos do que o tempo em que a fonte de alimentação do grupo gerador aparece. Por exemplo, defina o retardo do sinal de "desconexão" do painel de ventilação para 300 segundos quando o tempo padrão para comutação para o grupo gerador a diesel é de 200 segundos.
Então, a fonte de alimentação para o SCHU aparecerá antes do atraso do ponto de ajuste e a situação não será reconhecida como uma emergência. Ao mesmo tempo, existem dispositivos críticos que são alimentados pelo UPS e devem estar sempre conectados (por exemplo, PDU) - as mensagens sobre sua "desconexão" devem aparecer sem demora.
- analise as mensagens do UPS ao trocar para um grupo gerador a diesel e divida-as em "normais" atribuindo-lhes um tipo "amarelo" (por exemplo, uma declaração do fato "não há energia na entrada") e "anormal "(" desconexão do disjuntor da bateria ", que não deve ser nenhum modo de operação), com a atribuição dos mesmos ao tipo" vermelho ".
Ao mesmo tempo, escrevemos separadamente nas instruções aos oficiais de serviço que, no caso de uma transição para um grupo gerador a diesel, acidentes "amarelos" podem ser observados e não reconhecidos (eles desaparecerão após a conclusão de uma transição regular ), e os acidentes “vermelhos” podem ser eliminados imediatamente (não deveriam ser).
Baseando-se apenas na teoria, é muito difícil ajustar os pontos de ajuste para esse processo "transitório" de uma só vez. Para um ajuste bem-sucedido, é necessário observar as transições para o DGS várias vezes em tempo real.
Por exemplo, precisamos observar 4-5 transições para uma configuração aceitável de um novo BMS. Para analisar o processo de transição não programada, foi feito um registro da tela do sistema de monitoramento, pois é importante observar os alarmes não no arquivo de eventos, mas para analisar a ocorrência de alarmes na dinâmica do resumo operacional.
Passo 3. Dicas adicionais de nossa experiência
1. Nas telas do turno de serviço, não deve haver indicação desnecessária nas cores das mensagens de alarme.
Exemplo do mundo real. Um data center solicitou um mapa de fluxo de temperatura na sala do servidor. Este é um modelo 3D de fluxos de ar com muitos dados de temperatura dos sensores. O resultado foi uma visão do ar do norte com fluxos de ar - em algum lugar o ar estava destacado em verde, em algum lugar - amarelo e vermelho (do mais frio ao mais quente). Ao mesmo tempo, as temperaturas do ar estão em todos os lugares dentro dos limites normais e as cores são usadas apenas para maior clareza na exibição da diferença de temperatura em diferentes pontos.
Além disso, essa visão "heterogênea" foi exibida em um dos monitores na "sala de serviço". Como resultado, descobriu-se que a ferramenta, criada para análise de processos, apareceu diante dos olhos dos plantonistas, que foram "afiados" para correr para o equipamento quando virem vermelho e deformar quando virem amarelo.
Provavelmente, eles explicaram aos atendentes que na tela esquerda "vermelho / amarelo" é normal, e na tela direita as mesmas cores são um sinal de ação. No entanto, é claro que essa prática aumenta muito seriamente o risco de erro humano.
É lógico remover tais sistemas dos monitores da sala de serviço, eles devem ser observados pelo engenheiro-chefe para fins de análise de tendências - por exemplo, após algumas alterações nos parâmetros do ambiente de ar na sala dos servidores ou no comissionamento de novos equipamentos.
2. Use notificações por SMS com cuidado.
Vários anos atrás, ainda tínhamos medo de uma Internet móvel ruim e usávamos SMS em vez de mensageiros instantâneos. Depois de definir acidentalmente a configuração errada, ela foi aplicada a todos os dispositivos com o mesmo nome em 100 dispositivos, e meus colegas inscritos na lista de e-mails receberam 100 mensagens SMS cada. Desde então, não utilizamos o envio de SMS.
3. Configure a duplicação de mensagens sobre problemas por meio do mensageiro.
Isso pode ser feito, por exemplo, por meio do Microsoft Teams ou do Telegram. Tanto você quanto o plantonista receberão mensagens sobre acidentes, enquanto o telefone emite sons e vibra (o que não é o caso quando se trabalha com o sistema por meio de um navegador).
E não tenha medo de que haja muitas mensagens. Em nossa experiência, durante o dia normal de operação de um data center, apenas algumas dezenas de mensagens são recebidas, e elas não carregam os telefones dos funcionários. Ou seja, os equipamentos do data center e o sistema BMS podem ser configurados de forma a não receber centenas de notificações e ao mesmo tempo não perder nada importante.
Para reduzir o número de mensagens, inclua na lista de mala direta apenas notificações sobre a ocorrência de alarmes "vermelho" e "amarelo", ou seja, o mínimo necessário, permitindo que você mantenha o dedo no pulso dos eventos.
4. Agrupe mensagens em mensageiros.
Durante a transição para um grupo gerador a diesel ou devido a um acidente complexo, você terá dezenas de emergências ativas, o telefone vibrará constantemente com as mensagens que chegam ao mensageiro, evitando que você faça uma chamada importante ou abra a janela do sistema de monitoramento.
Você pode configurar a distribuição para que o mensageiro receba uma mensagem geral com uma lista geral dos acidentes ocorridos no último minuto. Esta configuração não afeta o aparecimento de alarmes no resumo do sistema BMS (os alarmes aparecem no resumo sem demora), e por 1 minuto de atraso no recebimento de uma mensagem em seu telefone, você não perderá nada, mas haverá muitas vezes menos mensagens em seu telefone.
5. Destaque a mensagem sobre a perda de conexão com o servidor na interface.
Por exemplo, a Internet foi perdida nas instalações dos atendentes. A interface do usuário não tem conexão com o servidor e, portanto, o alarme não aparece no resumo, a inscrição escura "servidor não está disponível" pode não ser percebida pelo pessoal, os funcionários podem olhar para o painel BMS "verde" com parâmetros numéricos por um longo tempo, sem saber que ele está localizado off-line.
A captura de tela mostra um exemplo de indicação de perda de comunicação com o servidor BMS, enquanto parâmetros irrelevantes do equipamento são exibidos.
6. Conecte o maior número possível de sistemas ao monitoramento.
Por exemplo, tradicionalmente, um sistema de alarme de incêndio funciona de forma autônoma e seu painel fica pendurado no posto de segurança.
Sim, no sinal de “FOGO” são acionados os algoritmos automáticos dos sistemas, o sistema de alerta é acionado, mas o segurança informa sobre o surgimento dos sinais de “Falha” ou “Atenção” em uma voz de plantão.
É muito difícil conectar totalmente esse sistema ao monitoramento, mas em tal sistema é fácil configurar três sinais de relé "falha", "atenção" e "incêndio" e, em seguida, conectá-los com "contatos secos" ao BMS módulo do sistema.
Isso reduz o risco do notório fator humano. Um exemplo de sinal de teste “FIRE” no sistema BMS do data center, conectado via “contatos secos”.
Resumindo nossa história da série 4
Um sistema de monitoramento de data center é mais do que apenas “olhos e ouvidos” para monitorar sistemas de engenharia de data center. O seu correto funcionamento permite atingir o mais alto nível de confiabilidade através da continuidade do site, e, portanto, proporciona à empresa uma vantagem competitiva adicional.
Tendo passado por um caminho bastante difícil e longo, nós obtivemos:
- um sistema de monitoramento rápido e estável que atualmente monitora mais de 2.500 dispositivos e calcula cerca de 10.000 sensores virtuais;
- reserva de sistema com base na plataforma de soluções em nuvem Lindatacenter em São Petersburgo e Moscou;
- -, , 1 ;
- , , ;
- , , – .