Третья серия. Примеры плохой и хорошей практик мониторинга Scada-систем WinCC
В прошлой части статьи мы разобрались с тем, как настраивать Zabbix и WinCC, чтобы построить эффективный комплекс мониторинга. Я, Арсений Тиунов, менеджер по визуализации, продолжаю рассказывать о мониторинге SCADA-систем WinCC на производствах «Северстали». И сегодня речь пойдет о том, какие минусы есть у существовавших до этого методиках диагностики, ну и конечно же, о плюсах нового способа в Zabbix.
Целью этих работ были не только настроенные триггеры для реагирования персонала, но и возможность увидеть полную картину работы WinCC по всему ландшафту. Например, виджет дашборда может подсветить нам ландшафт — на каком из производств есть критические сообщения (аварии) и предупреждения и как часто они возникают. Посмотрим на примерах, как это работает c Zabbix и как это было без него.
Кейс 1, где мог бы пригодиться мониторинг WinCC, но его там не было
Пример взят на основе реально произошедшего простоя технологического агрегата по причине сбоя на сервере WinCC. Диагностики этого сервера в Zabbix на тот момент еще не было. Сервер WinCC перешел в состояние сбоя, а резервирующий его сервер не был в состоянии готовности (Standby), поэтому клиенты не переключились на второй сервер. Оператор вызвал специалиста для выяснения проблемы, видимой как сбой АРМ-клиента. Посмотрим, что произошло и как этого можно было бы избежать.
Предупредительные сообщения о проблеме начались за 2 дня до сбоя. Метрики производительности системы сообщений и системы архивирования WinCC показывали предаварийную ситуацию. Системные алармы в ОС Windows сервера WinCC генерировались, но не были замечены. Сервер не был подключен к мониторингу Zabbix – информации об этих сигналах у персонала не было. Это привело к увеличению времени реакции на определение неисправного узла в связке клиент-сервер.
Система мониторинга WinCC предиктивна. Здесь появлявшиеся предупреждения по предаварийному состоянию системы сообщений и системы архивирования WinCC можно было бы выявить до наступления сбоя.
Мониторинга утилизации ресурсов не было. В течении длительного периода времени нагрузка процессора увеличивалась и достигла 100%. Информации об этом у персонала не было. Оператор сообщил о проблеме уже по факту сбоя.
Информация об утилизации ресурсов. В системе мониторинга Zabbix контролируются такие параметры хоста:
состояние процессора
состояние ОЗУ
состояние диска
состояние адаптера информационной сети
С Zabbix было бы известно, что сервер работает на предельном режиме.
Не было информации о состоянии резервирования серверов. В момент сбоя клиенты не переключились на резервирующий сервер. Персоналу было неизвестно состояние резервирования на серверах. Количество переключений клиентов между серверами отследить было сложно.
Информация о состоянии резервирования. В системе мониторинга WinCC в Zabbix контролируются такие параметры резервирования:
состояние резервирования
количество переключений серверов за период времени
Если бы в этом кейсе был настроен мониторинг через Zabbix, то было бы заранее известно, что предусмотренное проектом резервирование не работает.
Кейс 2, в котором мы покажем, как среди тысячи серверов WinCC определить проблемный сервер и предотвратить его сбой
Просматривая дашборд с ландшафтом всех WinCC, мы видим периодические критичные проблемы с одним из производств:
Выбираем производство с проблемами, переходим в его дашборд и видим проблемный узел:
Еще мы видим, что именно он формирует критичное системное сообщение, которое указывает на большую «Очередь скриптов» на сервере:
Эта информация есть в «проблемах» и в графиках метрики:
Мы видим, что «Очередь скриптов» достигла значения 10000, что привело к возникновению системного сообщения. Оператор еще не вызывал специалиста по проблеме, но триггер о превышении «Очереди скриптов» уже отработал. А в случае резервированных серверов оператор и не увидит проблемы, так как его клиентский АРМ переключится с одного сервера на другой. Он может переключаться несколько раз, и это никому не будет видно. Поэтому все эти триггеры введены на переключение состояния резервирования. Ведь частые переключения также будут сигнализировать о проблемах на этой паре серверов.
Вернемся к нашему серверу с проблемой в «Очереди скриптов». В запланированное время специалист произвел восстановление нормальной работы системы (не дожидаясь аварийной ситуации, чтобы избежать простоя технологического агрегата). Если говорить именно об «Очереди скриптов», то нахождение источника ее роста — нетривиальный процесс, связанный с обследованием как ресурсов сервера, так и непосредственно исполняемого проекта WinCC. Тем не менее, поиск причин становится проще, если у тебя есть исходные данные для диагностики в Zabbix.
Восстановление нормальной работы сервера «глазами Zabbix»:
Как видим, индикация проблемы по этому серверу ушла. Остался сигнал по другому серверу, говорящий нам о произошедшем недавно изменении состояния резервирования (что также полезно проанализировать).
Вывод: Zabbix не может сделать за пользователя всю работу по диагностике и предотвращению сбоев WinCC, но облегчить жизнь специалисту с десятками, а то и сотнями серверов SCADA-систем — точно сможет. Нужно лишь немного помочь Zabbix с настройками логики обнаружения проблем.
Резюме: что мы сделали и каких результатов достигли с помощью Zabbix
Мы разработали архитектуру решения по охвату мониторингом ландшафта Scada-систем WinCC в Zabbix. Подготовили и расширяем подгруппы для добавления узлов.
Расширили количество полезных метрик, получаемых в Zabbix. Помимо существующих метрик, предоставили возможность пользователям формировать собственные метрики и передавать их в Zabbix через zabbix_sender.exe (например, сигнал о начале ремонта технологического агрегата). Также возможно их включение в общие для всех скрипты и шаблоны.
Сформировали единый подход к оценке метрик Scada-систем. Постепенно переработали и перешли от избыточного количества метрик к проверенному минимально необходимому набору. Появилась возможность охвата по этим метрикам всего ландшафта. Остается возможность детальной аналитики всех метрик на уровне узла.
Выработали необходимый минимальный набор триггеров событий на основе метрик WinCC. Набор триггеров для всех узлов ландшафта можно легко расширить, используя шаблоны Zabbix.
Создали дашборды для улучшения эргономики пользователя в Zabbix. Такой дашборд точно описывает состояние SCADA-систем с различным уровнем масштаба и глубины аналитики.
Иерархия ландшафта строится согласно архитектуре решения. Каждый узел точно соответствует положению в ландшафте, охвачен ролевой моделью пользователей, агрегируется в разрезе метрик по своей подгруппе.
И наконец, самое главное: реализовали возможность предотвращения сбоев WinCC, а выяснять причины аварийных ситуаций стало легче.
Что предстоит сделать
Управление ландшафтом АСУТП – это непрерывный процесс, в котором всегда есть что улучшить. В ближайшее время мы планируем:
Продолжать работу над настройкой триггеров и дашбордов под возникающие сбойные ситуации SCADA-систем и систематизировать кейсы и методологию по мониторингу WinCC в Zabbix.
Реализовать опрос логов WinCC в Zabbix с дальнейшим созданием триггеров событий. Это даст возможность добавить события в сфере безопасности КИИ (например, «логирование пользователя», «неверное имя пользователя/пароль», «ошибка сертификата», «не удалось верифицировать подключение к ПЛК. Неверный пароль»).
Автоматизировать формирование своеобразной базы знаний по случившимся инцидентам в Zabbix. В случае нового вида ошибки можно задать поиск по сработавшему триггеру для всего ландшафта и проанализировать соответствующие ему данные в Zabbix (метрики и логи событий WinCC).
Реализовать получение данных OPC-серверов средствами Zabbix.
Дополнить данные WinCC в Zabbix данными OPC-серверов (PLC, Scada, Digital) и реализовать более сложную аналитику в рамках всего ландшафта АСУТП. Эту возможность нам дает успешно протестированное решение по получению данных.
Продолжить процесс охвата ландшафта АСУТП с взаимным увязыванием данных в единую систему мониторинга в Zabbix.
С Наступающим и прекрасного года!