Как мы скриптами автоматизировали четыре рутинных процесса в облачной инфраструктуре
Повторяющиеся операции в облаке по отдельности не выглядят чем-то сложным: проверить доступные мощности, сверить параметры нового объекта, собрать данные об инциденте, прикинуть лимит по IOPS. Но когда растет количество кластеров, площадок, клиентов и запросов, а команда не раздувается пропорционально, "простые" действия превращаются в нескончаемую очередь однотипных задач.
Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. Ниже - мой практический опыт: как мы последовательно обвязали скриптами четыре процесса и получили предсказуемость, скорость и меньше ручных ошибок, не превращая автоматизацию в "черный ящик".
Что именно мы автоматизировали
1) учет и планирование вычислительных мощностей;
2) проверку конфигурации новых объектов;
3) подготовку данных при инфраструктурных инцидентах;
4) расчет лимитов IOPS для дисковых политик.
Принцип, с которого все началось
Я придерживаюсь простой логики: если задача разовая - ее можно сделать руками за пару часов и забыть. Если же она повторяется - лучше потратить пару дней на скрипт и действительно забыть, оставив человеку только принятие решения.
Перед тем как писать очередную автоматизацию, я отвечал себе на несколько вопросов:
- как часто повторяется операция;
- какие шаги идут по стабильным правилам и не требуют "творчества";
- откуда брать исходные данные;
- что делать, если источник данных временно недоступен;
- какое решение в итоге должен принять инженер;
- что допустимо выполнять автоматически, а что - только подсвечивать.
Во многих сценариях скрипт - не "замена инженера" и не робот, который сам меняет инфраструктуру. Его роль - собрать фактуру, сравнить с эталоном, найти отклонения и сократить время до решения. Именно это и дало максимальный эффект.
---
Задача 1. Учет и планирование мощностей
Что раньше делали вручную
Когда я пришел в OXYGEN, с историей потребления ресурсов было тяжело: можно было открыть текущую картину по конкретному кластеру, но вопрос "что было у этого клиента месяц или год назад?" оставался без ответа. Приходили менеджеры с запросами вроде: "Нужно 500 CPU и 10 ТБ дисков. Место есть?" - и начиналась ручная проверка, сверка, правка таблиц.
Особенно много времени уходило на ответы по крупным запросам: несколько сотен vCPU и терабайты дискового пространства требовали быстро понять:
- сколько ресурсов уже выделено;
- сколько реально используется;
- как менялась загрузка кластера;
- есть ли резерв для нового размещения;
- не является ли свободная мощность уже забронированной под чей-то будущий рост.
Как мы автоматизировали
Я собрал дашборд, который:
- каждый час обходит все кластеры OXYGEN и собирает метрики состояния (vCPU/vRAM/объемы дисков);
- хранит историю с 2022 года - можно выбрать любую дату и увидеть фактическую картину;
- показывает не только "выдано клиентам", но и реальное потребление;
- учитывает правило внутреннего резерва: свободных ресурсов должно оставаться не меньше 20% объема, и это видно в реальном времени - вплоть до количества свободных ядер.
Мы работаем в нескольких локациях: Москва, Санкт‑Петербург, Екатеринбург, Люксембург, Казахстан, Узбекистан. Для распределенной инфраструктуры такой "единый экран" - критичен: иначе планирование превращается в ручной квест.
В результате мы получили не просто красивые графики. Мы смотрим на запас по каждому кластеру и заранее создаем задачи в тикетной системе на установку дополнительных серверов, когда загрузка приближается к красной линии. Прозрачность дала возможность видеть паттерны и точнее планировать закупки и дооснащение, а значит - улучшать качество обслуживания клиентов без авралов.
Как обрабатываем ошибки и "пустые данные"
При сборе метрик важно отличать нулевое значение от отсутствия данных - особенно с учетом особенностей VMware Cloud Director и vCenter. Если площадка или API временно недоступны, нельзя трактовать это как "потребление упало до нуля".
Поэтому при ошибке сбора мы действуем так:
- фиксируем неуспешный цикл;
- сохраняем последнее корректное значение;
- помечаем данные как неактуальные;
- формируем техническое уведомление.
Это простое правило уберегло от ложных "радостных" отчетов и неверных решений по емкости.
---
Задача 2. Проверка конфигурации новых объектов
Почему это стало проблемой
Создание объектов в vCloud - операция типовая, но риск ошибок высокий: одна пропущенная настройка в моменте может "аукнуться" через недели. Когда поток заявок увеличивается, ручной чек‑лист начинает буксовать: инженеры отвлекаются, кто-то трактует требования по‑своему, кто-то просто устал. Итог - несоответствия стандарту, а дальше цепочка: нестабильная работа, лишние обращения, долгие разбирательства "почему так получилось".
Что именно проверяем
После создания объектов в vCloud нам требовалось сверять параметры с внутренним чек‑листом. Проверка распространяется на несколько типов объектов:
- Provider VDC;
- Organization;
- VDC;
- Edge Gateway;
- External Network.
Как выглядит автоматизация на практике
Мы вынесли стандарты в формализованный набор правил и сделали скрипт, который:
- получает параметры созданных объектов;
- сравнивает их с эталоном для нужного типа;
- подсвечивает расхождения (что не так и где именно);
- формирует понятный отчет для инженера.
Важно: скрипт не "чинит" автоматически. Он сокращает время на проверку и делает ее одинаковой для всех - без вариативности и человеческого фактора. Инженер принимает решение, что менять и когда, но в руках у него уже готовая диагностика.
---
Задача 3. Подготовка данных при инфраструктурных инцидентах
Инцидент - это всегда гонка со временем. И почти всегда в первые минуты не хватает не знаний, а данных: что именно деградировало, на какой площадке, какие компоненты затронуты, что происходило до события, каковы симптомы по метрикам и логам.
Раньше сбор "пакета для расследования" был разрозненным: часть информации доставалась из мониторинга, часть - из систем виртуализации, часть - из логов, и все это нужно было еще привести к общему виду. На инцидентах это ощущается особенно больно: разные инженеры могут собирать разный набор фактов, а значит - терять время на повторные запросы и уточнения.
Мы сделали сценарий, который по минимальному вводу (например, идентификатор клиента/организации, имя VDC или временной интервал) готовит "инцидентный набор":
- фиксирует временные рамки и ключевые события;
- собирает снимок основных метрик;
- подтягивает технические параметры затронутых объектов;
- формирует единый отчет, который можно приложить к тикету.
Эффект оказался заметным уже в первые недели: время до первичной диагностики сократилось, а качество разборов стало стабильнее - меньше "провалов" из-за того, что кто-то забыл собрать важную деталь.
---
Задача 4. Расчет лимитов IOPS для дисковых политик
Почему это стало проблемой
IOPS - тема, в которой легко ошибиться, если считать "на глазок". С одной стороны, хочется дать клиенту запас. С другой - бесконтрольные лимиты могут ухудшать ситуацию для соседей по кластеру и приводить к конфликту за ресурсы хранения.
Когда запросов на дисковые политики становится много, ручные расчеты начинают отличаться от инженера к инженеру: где-то перестраховались, где-то недодали, где-то забыли учесть профиль нагрузки. А еще всегда остается риск банальной арифметической ошибки.
Что мы автоматизировали
Мы описали правила расчета лимитов и сделали скрипт, который:
- принимает исходные вводные по диску/политике;
- рассчитывает целевые лимиты IOPS по заданной модели;
- выдает результат в стандартизированном виде, чтобы его было легко проверить и применить.
Здесь, как и в предыдущих задачах, ключевой выигрыш - единый подход и воспроизводимость. Решения становятся сравнимыми, а обсуждение - предметным: спорим не "кто как привык", а "какое правило применяем и почему".
---
Немного об архитектуре и философии: почему мы не делали "монолит-автоматизатор"
Мы старались не строить одну огромную систему, которая "умеет все", а развивали набор небольших инструментов под конкретные процессы. Такой подход легче сопровождать: если ломается сбор мощностей, это не парализует проверки конфигураций или инцидентные отчеты.
Еще один принцип - наблюдаемость самой автоматизации. Любой скрипт должен уметь честно сказать: "данные не получены", "источник недоступен", "результат неактуален". Это лучше, чем молча отдать нули или неполный набор фактов и тем самым подтолкнуть людей к неверному решению.
---
Дополнительные практики, которые усилили эффект (и сэкономили еще больше времени)
1) Единые форматы вывода. Мы договорились о стандарте отчета: одинаковые поля, одинаковые имена сущностей, одинаковая структура. Это резко уменьшает время на чтение и снижает риск неверной интерпретации.
2) "Сухой прогон" перед применением. Там, где возможны изменения, сначала формируется план: что будет затронуто и какие параметры изменятся. Это дисциплинирует и помогает избежать случайных действий в продакшене.
3) Разделение на "сбор" и "оценку". Сбор данных максимально механический, а оценка - набор правил. Такой разнос упрощает поддержку: источники меняются - правим сбор; меняются требования - правим правила.
4) Защита от частичных данных. Если один из источников не ответил, система не делает вид, что все хорошо. Она либо помечает результат как неполный, либо явно показывает, какие блоки отсутствуют.
5) Регулярный пересмотр чек‑листов. Автоматизация не отменяет актуализацию стандартов. Мы заложили регулярную ревизию правил: инфраструктура меняется, продукты развиваются - эталон должен поспевать.
6) Ориентация на решение, а не на "побольше метрик". Легко увлечься сбором всего подряд. Но реальную ценность дают те данные, которые ускоряют выбор действия: масштабировать, переносить, ограничивать, чинить, сообщать клиенту.
---
Итог
Автоматизация четырех рутинных процессов дала нам предсказуемость и единый стандарт работы: от планирования емкости до контроля конфигураций, от подготовки инцидентных данных до расчета IOPS. Главное - мы не пытались "убрать человека из процесса". Мы убрали ручную рутину, ускорили диагностику и сделали принятие решений более точным.
В облачной инфраструктуре побеждает не тот, кто умеет героически тушить пожары, а тот, кто системно снижает количество поводов для этих пожаров - и оставляет инженерам время на работу, где действительно нужна голова, а не бесконечные проверки по списку.
