Мониторинг инфраструктуры дата-центра — непростая задача. Часто для ее упрощения используется автоматизация. Ну а что — отлично же, получать себе на монитор все уведомления системы мониторинга. Как-то мы уже писали, что автоматизация всего и вся — это неплохо. Это достаточно сложная, но решаемая задача. Зачем ее вообще решать, автоматизируя обнаружение новых устройств, соединений, программного обеспечения, создавая сценарии ответных действий системы на появляющиеся триггеры?

Все потому, что человек — ленив, автоматика во многих случаях будет работать лучше. Но и здесь есть проблемы. Казалось бы, что может случиться после внедрения такой системы? Вроде бы основные проблемы решены, любая проблема не останется незамеченной. Но на самом деле некоторые важные вопросы остаются, зачастую, нерешенными. Более того, они встречаются очень часто. Речь идет о двух таких проблемах, и они мы поговорим в продолжении.

Проблема 1: уведомление об ошибке — это еще не все


Стратегией можно назвать поиск брокколи в магазинах и процесс покупки. Тактикой в данном случае можно назвать умение уговорить детей съесть приготовленное.
Томас ЛаРок, SolarWinds

Прежде, чем углубляться в автоматизацию, будь то автоматическое обнаружение проблемы, отправка отчета или сценарий действий на случай непредвиденной ситуации, необходимо принять меры в отношении одной критической вещи. Речь идет о так называемом DPR цикле, который расшифровывается, как Detection, Prevention, Response. Другими словами, речь идет о процедуре обнаружения проблемы, предотвращении ее появления и ответных действиях сотрудников ЦОД в случае появления проблемы.

Сейчас остановимся на ошибках и сообщениях об их появлениях. Скажем, саппорт получил такое сообщение автоматической системы предупреждения, отлично. Теперь нужно разобраться в том, почему эта ошибка возникла, а также найти способ, позволяющий предотвратить в будущем ее повторное появление.

В процессе создания службы автоматических уведомлений об ошибках нужно также предусмотреть и то, что это только начало. Ведь нужно проделать еще и тяжелую работу по анализу ситуации, для того, чтобы найти причину возникновения нежелательной ситуации. После этого нужно создать дополнительные проверочные модули, направленные на идентификацию уже случившейся ситуации. Может быть, мы и уверены в том, что она уже не появится, но всякое может быть.

Автоматическая реакция на уведомления системы предупреждения позволяет немного расслабиться, ведь за все отвечает автоматика. Но инженеры должны все равно разбираться в том, почему проблема возникла. Автоматика, зачастую, на это неспособна.



Проблема 2: разворачивание системы автоматизации мониторинга


Речь идет о том, что перед внедрением системы автоматизации необходимо иметь план того, что должна уметь такая система. Ее необходимо тщательно продумать, чтобы потом не было проблем. Ну а в плане нужно предусмотреть следующее:

  • Наличие выборки тестовых машин. Это могут быть чисто «лабораторные» сервера, на которых будет отрабатываться система автоматизации, или машины, которые используются в ходе работы, но являющиеся по той либо иной причине менее приоритетными, чем все другие;

  • Не стоит отрабатывать ситуации, доводя работу машины до критической. Скажем, для отработки системы уведомлений о критической нагрузке на сервера не стоит доводить загрузку ресурсов системы до 90%, хватит и меньшего уровня;

  • Если система поддерживает логирование, то стоит эту функцию включить. В итоге, если случается проблема, вы будете понимать, что именно произошло и почему. Журнал событий должен быть максимально подробным;

  • В некоторых случаях не стоит отправлять уведомления о проблемах по e-mail. Все это провоцирует дополнительные задержки в работе. Представьте себе, что в почту пришло 740 сообщений, и с ними необходимо теперь разгребаться, открывая каждое уведомление по очереди. Лучше всего сохранять уведомления локально, выводя одновременно на дисплей;

  • Результаты тестирования системы уведомлений стоит обсудить с саппортом, возможно, представители команды поддержки посоветуют дельные вещи;

  • После того, как система отработана в тестовом варианте, стоит ее потихоньку вводить в работу. Причем разворачивать систему нужно не сразу всю, а поэтапно. Сначала включить ее для 10-20 систем. Затем оценить результаты. Потом расширить систему еще на 50 машин, и снова проверить. Поэтапное включение системы автоматизации уведомлений позволит избежать масштабных ошибок при разворачивании такой системы сразу на 100% машин. В последнем случае, если возникнет проблема, это может аукнуться всему дата-центру.

Если воспользоваться этими советами, можно увидеть недостатки системы автоматизации, и понять, как их исправить еще до того, как случится масштабный сбой. Для того, чтобы при реализации системы автоматизации использовать действительно актуальные инструменты, стоит постоянно обсуждать с командой последующие этапы работы. На что специалисты жалуются больше всего? Это и нужно решать в первую очередь.

Если все получится, то вы сможете избавить себя и команду от постоянно возникающих и повторяющихся ситуаций, на которые приходится тратить свое время, которого, естественно, всегда не хватает. То, что указано в материале — лишь малая часть работы по внедрении системы автоматизации мониторинга ЦОД. Часть уже была показана ранее, остальное планируем опубликовать в ближайшее время.
Поделиться с друзьями
-->

Комментарии (1)


  1. bravo-ej
    15.12.2016 13:50

    Вы бы лучше про средства для мониторинга и как из всего этого выстроить цельное решение. А так же логику отработки событий. А то что то получилось пока не очень =/ Надеялся увидеть принципы выстраиваемая системы мониторинга и уведомлений, а оказалось, что (1) пришло событие — по нему надо отработать, а (2) выберите компьютер, не грузите ему CPU, но забейте логами харды, обсудите с коллегами… последний совет можно назвать полезным!

    Я всегда за такие статьи, отчасти потому, что негде почитать конкретно про это — нужна консолидация опыта очень разных специалистов. Но специалистов, а не менеджеров отдела продаж.