Наша компания занимается обслуживанием серверов. Мониторинг для нас — сверхкритическая система, его отказ может привести к большим финансовым потерям. Отслеживать физическую доступность мониторинга может другая система мониторинга, а вот логические ошибки…

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


Вводные данные: есть несколько сотен клиентов. Есть система мониторинга zabbix. Для каждого клиента заведена отдельная группа, в которой располагаются все сервера клиента. Новые хосты добавляются автоматически. Клиент имеет доступ к метрикам по хостам в своей группе. Есть один специальный хост, который проверяет доступность сайтов всех клиентов. Все срабатывания приводят к созданию задачи в redmine. Так выглядел наш мониторинг пару лет назад.

Все началось с простого запроса от клиента о предоставления доступа к мониторингу доступности сайта. Как вы помните, у нас он один для всех клиентов и дать доступ мы не смогли. И заверте…

Часть первая: эпик фейл, мы нашли тебя

Мы сели, поразмыслили и решили, что давно пора сделать каждому клиенту такой спец-хост и дать доступ к метрикам. Админы — народ ленивый, руками копировать не хотелось. Написали скрипт, который разберет все проекты, создаст и перенесет все нужные метрики и триггеры. Скрипт, протестированный «на кошках», работал как швейцарские часы.

Запускаем скрипт в продакшн, и к нашему изумлению он вываливает мешок и маленькую тележку ошибок. Беглый анализ показывает, что метрики собираются, а триггеров-то для них и нет! Проблемных проверок набралось порядка 10%. Вроде не так и много, но сама ситуация крайне печальная. Позвонит клиент: «У нас сайт упал!» И что мы ответим? «Спасибо, что сообщили, сами мы не в курсе...»? А если сайт пролежал 10 часов? Нам повезло, мы нашли проблему до того, как она выстрелила.

Часть вторая: кто виноват и что делать

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

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

Мы провели анализ и выделили задачи, которые можно полностью или частично автоматизировать.

Мы автоматизировали все работы, связанные с добавлением шаблонов. Написали скрипты, которые создают проверки, админу остается только задать входные данные.Надо добавить проверку доступности сайта? Просто запусти script --url site.com. Надо добавить хост в maintenance? Запусти скрипт… Ну вы поняли. Мы даже добавили функционал проверки на наличие обновления в git, чтобы все гарантированно пользовались последней версией скриптов. Еще мы написали скрипт, который делает все возможные проверки на наличие ошибок, отключенные хосты, хосты, оставленные в maintenance, и т.д. и т.п. И жить нам стало радостно и весело. Happy end.

Часть третья: новая волна проблем

Казалось бы, наступило счастье. Но рано мы обрадовались. В один прекрасный пятничный вечер, как обычно и бывает, коллега написал: «У меня на десяток хостов не подцепились шаблоны». Напомню, процесс автоматизирован, скрипт смотрит роли в системе конфигурирования и цепляет нужные шаблоны. В пятницу вечером браться за такое дело никто не хочет. Просим коллегу подождать полчасика, вдруг само наладится. Прошел час, второй, третий… Шаблоны так и не подцепились. Деваться некуда, полезли смотреть. Оказалось, после очередного обновления часть скриптов перестала работать. При этом, внося изменения, мы сделали выборочное тестирование, но именно сбойные скрипты не попали в выборку.

Поскольку мониторингом занимается один человек, виновник был очевиден. Наказывать не стали, но спросили: «Что делать, чтобы такого не повторилось?».

Что делать? Конечно же, писать автотесты. Теперь у нас все скрипты до деплоя на сервере проходят автотесты.

Эпилог

Прочитав эту статью, кто-то скажет: «Позор, как так можно работать?» Но разве вы сами никогда не удаляли прод базу данных?? Даже в Gitlab такое случалось… Мы не боимся ошибок, каждый фейл дает нам возможность сделать компанию лучше. Главное — найти и устранить причины, а не заниматься лечением симптомов.

А вы уверены что ваша система мониторинга здорова на 100%?

PS: Работая над статьей, я поймал себя на мысли, что в devops работа ops все больше походит на dev. Значит, не надо изобретать велосипед, будем брать практики и инструменты из dev и применять в ops.

PSS: Мы не показываем примеры кода, потому что код заточен под наши нужды и нашу архитектуру. Но если вам интересно, напишите в комментариях, и мы зальем код на github.