Повторяющиеся операции в облачной инфраструктуре — по отдельности совсем не сложные. Проверить доступные мощности, сверить параметры нового объекта, собрать данные об инциденте или рассчитать лимит IOPS — все это можно сделать вручную. Но когда количество кластеров, площадок, клиентов и запросов растет, а количество рук — не увеличивается, это становится проблемой.
Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. В этой статье я рассказываю про личный опыт автоматизации мониторинга облака. Ниже разберу четыре задачи, которые мы последовательно автоматизировали.
Что именно автоматизировали
Общий принцип автоматизации
Моя система мониторинга данных появилась благодаря следующему принципу: если задача разовая – ее можно сделать руками за 2 часа и забыть навсегда. А если она повторяется периодически — лучше потратить 2 дня на скрипт и… да, забыть о ней навсегда.
Перед разработкой каждого скрипта я отвечал сам себе на такие вопросы:
-
насколько часто повторяется операция;
-
какие действия выполняются по стабильным правилам;
-
откуда можно получить исходные данные;
-
что произойдет, если источник данных недоступен;
-
какое решение должен принять человек;
-
какие действия допустимо выполнять автоматически.
Во многих сценариях автоматизация не заменяет инженера и не меняет инфраструктуру самостоятельно. Она подготавливает данные, обнаруживает отклонения и сокращает время до принятия решения.
Именно это мне и нужно! Поехали к конкретике.
Задача 1. Учет и планирование мощностей
Что выполнялось вручную
Когда я только пришел в OXYGEN, в компании было затруднительно посмотреть историю использования ресурсов. Можно было зайти и увидеть, что сейчас выдано клиентам на конкретном кластере, но вопрос «А что было у этого клиента месяц или год назад?» оставался без ответа. Менеджеры приходили с запросами вроде: «Мне нужно 500 CPU и 10 ТБ дисков. Место есть?». Приходилось идти, смотреть вручную, обновлять таблицы.
Например, при запросе на несколько сотен виртуальных CPU и несколько терабайт дискового пространства требовалось выяснить:
-
сколько ресурсов уже выделено;
-
сколько фактически используется;
-
как менялась загрузка кластера;
-
есть ли резерв для нового размещения;
-
не относится ли свободная мощность к уже забронированным ресурсам.
Как автоматизировали
Я сделал дашборд, который:
-
Ежечасно ходит по всем кластерам OXYGEN (а это Москва, Питер, Екатеринбург, Люксембург, Казахстан, Узбекистан) и собирает метрики состояния инфраструктуры (vCPU/vRAM/объемы дисков).
-
Хранит историю с 2022 года. Можно выбрать любую дату и посмотреть, как были использованы ресурсы.
-
Считает не только выданные ресурсы, но и реальное потребление.
-
Показывает, есть ли еще место, учитывая, что запас свободных ресурсов по правилам нашей компании должен быть не меньше 20% объема. Сколько ядер свободны, мы видим в реальном времени.
Визуально это графики по каждому кластеру. Мы смотрим на наши запасы ресурсов и формируем задачи в тикетной системе на установку дополнительных серверов, если загрузка приближается к красной линии. Прозрачность загрузки позволяет анализировать паттерны и предсказывать, как увеличивать наши кластеры, как мы можем строить стратегию по закупке и дооснащению и улучшать качество обслуживания для наших клиентов.
Как обрабатываются ошибки
При сборе данных важно отличать нулевое значение от отсутствия данных. Есть особенности работы VMware Cloud Director и vCenter. Если площадка или API временно недоступны, система не должна трактовать это как падение потребления до нуля.
Поэтому при ошибке:
-
фиксируется неуспешный цикл сбора;
-
сохраняется последнее корректное значение;
-
данные помечаются как неактуальные;
-
формируется техническое уведомление.
Задача 2. Проверка конфигурации новых объектов
Что выполнялось вручную
После создания объектов в vCloud требовалось сверять их параметры с внутренним чек-листом. Проверка распространяется на несколько типов объектов:
-
Provider VDC;
-
Organization;
-
VDC;
-
Edge Gateway;
-
External Network.
Нужно было убедиться, что параметры соответствуют заявке, а в описании указан её номер.
Почему это стало проблемой
Создание объектов состоит из нескольких шагов. Даже при корректном регламенте отдельное поле можно пропустить или заполнить неверно — особенно при высокой загрузке и большом количестве однотипных операций.
Ручная повторная проверка также занимает время и плохо масштабируется. Поэтому нужен стандартизированный процесс, который освобождает время руководителя.
Как автоматизировали
Я сделал скрипт, который обнаруживает новые объекты, сопоставляет их параметры с чек-листом и отправляет результат проверки в отдельный Telegram-чат.
А что у нас в чек-листе? А вот что:
-
правильно ли выставлены параметры?
-
добавлен ли комментарий с номером заявки в описание?
Если какой-то из параметров не соответствует заданному – в наш отдельный Telegram-чат летит сообщение формата: «Ребята, по заявке №XXX выставлены неверные параметры, нужно исправить». Или наоборот, если всё хорошо, бот просто пишет: «Клиенту IT выдали 100 ГБ SSD».
Как обрабатываются ошибки
Ошибки разделены на две категории:
-
ошибка конфигурации — данные получены, но параметр не соответствует правилу;
-
ошибка проверки — данные получить или интерпретировать не удалось.
Во втором случае система не должна сообщать, что объект корректен. Результат помечается как неопределенный и требует повторной проверки.
Также необходимо учитывать изменения стандартов. Правила проверки должны быть версионируемыми, иначе новый допустимый параметр может быть ошибочно принят за нарушение.
Теперь команда быстрее узнает об отклонениях, а проверка выполняется единообразно. Конечно, формальная проверка подтверждает только соответствие заданным правилам. Она не гарантирует, что сама заявка составлена правильно или что выбранная конфигурация оптимальна. Кроме того, чек-лист необходимо поддерживать в актуальном состоянии при изменении внутренних стандартов и API платформы. Но это уже другой вопрос.
Задача 3. Подготовка данных при инфраструктурных инцидентах
Что выполнялось вручную
При недоступности хоста Zabbix формировал событие, но кто конкретно пострадал — понять сразу было сложно. Приходилось дополнительно выяснять:
-
какие виртуальные машины находились на хосте;
-
каким клиентам они принадлежали;
-
является ли событие частью плановых работ;
-
кому необходимо отправить уведомление.
После этого список вручную передавался первой линии поддержки для регистрации обращения и подготовки рассылки. А это драгоценные минуты, которые не хочется тратить каждый раз на одно и то же.
Как автоматизировали
Теперь схема иная:
-
Скрипт с заданной периодичностью выгружает информацию о состоянии хостов и о ВМ находящихся на них.
-
Если скрипт видит, что хост «упал» и это не запланированные технические работы, то он берет список ВМ с этого хоста, который у него уже есть, и вкладывает его в сообщение.
-
В наш общий чат техподдержки летит пост с тегом первой линии:
«Хост такой-то упал. Просьба завести обращение по инциденту и выполнить рассылку клиентам согласно вложенного файла. Список приложен».
Вот и все. Теперь в течение 5 минут мы уже знаем, кому писать. А главное – клиенты не приходят к нам с вопросами: «А почему у нас все перезагрузилось, а вы молчите?».
Задача 4. Расчет лимитов IOPS
Что выполнялось вручную
Для разных политик (SATA, SSD и так далее) и разных размеров дисков лимиты IOPS рассчитываются по-разному. Это зависит от типа политики; размера диска; минимального значения; максимального значения; шага изменения; границ диапазонов.
У нас на СХД (системах хранения данных) есть правило: до 100 ГБ — один лимит, от 100 до 200 ГБ — другой. Вручную считать и выставлять для каждого нового диска — это неделя ручной работы.
Почему это стало проблемой
Даже простая формула становится источником ошибок, если ее многократно применяют вручную. Дополнительные риски создают граничные значения: например, диск размером ровно 100 ГБ может относиться к одному или другому диапазону в зависимости от принятого правила.
Как автоматизировали
Не зря у меня в дипломе написано «математик». В итоге раздумий родилась функция строк на 20 (в коде — и того меньше, всего 4 значимые строки). На входе — размер диска, минимальное и максимальное значение IOPS для этой политики, шаг. На выходе — точная цифра, которая должна быть выставлена на диск.
Расчет стал воспроизводимым: одинаковые входные данные дают одинаковый результат независимо от того, кто запускает операцию.
Это сократило объем ручной работы и упростило массовую проверку существующих дисков.
Немного об архитектуре и философии
Описанные решения работают с разными источниками данных и имеют разные требования к периодичности и реакции на ошибки.
Портал мощностей ориентирован на историю и аналитику. Проверка объектов запускается после изменения конфигурации. Сервис инцидентов должен быстро сопоставлять событие с последним корректным снимком. Калькулятор IOPS представляет собой детерминированную функцию.
Часть вспомогательных заданий также работает по расписанию: сбор биллинговых данных, проверка сертификатов, контроль SLA и проверка парольных политик. Они построены по той же схеме, но в эту статью не включены, как-нибудь расскажу отдельно, если интересно.
В заключение
Вот так, по кусочкам, и собирается автоматизация в облаке. Это не какой-то единый монструозный продукт, а экосистема скриптов, ботов и порталов, которая позволяет нам быстро реагировать на инциденты, планировать закупку оборудования и не сойти с ума от рутины.
Главное — не бояться пробовать. Я, например, того же Telegram-бота учился писать по статье на Хабре. Там было 90% нужной информации, остальное дописывал уже сам.
Спасибо вам за время, уделенное моему рассказу! Я старался сделать этот текст максимально простым и полезным, без пространных рассуждений. Если у вас появились вопросы о то, как работает моя система и что у нее под капотом – пишите в комментариях под статьей, постараюсь всем ответить. А если вы уже работаете с чем-то подобным – тем более пишите и делитесь опытом!
Кстати, чтобы понять масштабы, с которыми работает моя система мониторинга и алертов – загляните на сайт OXYGEN, там подробно и про наши мощности и про кластеры, в которых они сосредоточены. И в TG-канал наш заходите, там коллеги публикуют новости про дата-центры и облака.
ссылка на оригинал статьи https://habr.com/ru/articles/1068812/