Эксплуатация ИТ-инфраструктуры: в чём проблема №1?

55% DevOps и SRE, которых мы опросили на конференции HighLoad++, уверены, что часть знаний об «инфре» находится только внутри голов инженеров. Ещё по 44% считают, что инструменты врут, а документация устаревает уже в момент написания. В итоге актуальной и полной картины ИТ-инфраструктуры нет ни у кого.

Согласно опросу на HL++ и нашим CustDev-исследованиям, именно восстановление текущего состояния инфраструктуры — проблема №1.

Итого, знание об инфраструктуре разрознено между инженерами (обычно нигде нет даже их списка). Команда эксплуатации, часто недоукомплектованная, работает под большой нагрузкой. Вдобавок в индустрии случается текучка кадров, с которой «утекает» и экспертиза по «инфре». Как же быть?

Ксения Кузнецова, CPO компании «Прегель», отвечает: «Фрагментарные знания об инфраструктуре в разы замедляют исследование инцидента, а цифровая модель быстро даст реальную картину».

В следующем посте — о том, что делать с требованиями к «инфре».

Что делать с требованиями к «инфре»?

Бизнес ждёт от ИТ-инфраструктуры не только прозрачности, но и гибкости. На практике даже понять, что у нас есть и как оно настроено, проблематично. А команда эксплуатации должна ещё учитывать входящие требования и что-то менять. Желательно - быстро, чтобы успевать за рынком или даже опережать его. Но и на уровне требований есть проблемы:

📍У 44% DevOps и SRE, опрошенных нами на HighLoad++, требования из разных источников противоречат друг другу.
📍33% респондентов отмечают, что бизнес присылает неструктурированные требования, которым нужны расшифровка и уточнение.

Подготовка непротиворечивой конфигурации в таких условиях - сложная задача. Есть ли решение?

Ксения Кузнецова, CPO компании «Прегель», отмечает: «На обнаружение и устранение противоречивости или неполноты требований у эксплуатантов сейчас уходит много времени. Текущие способы решения этих проблем не работают, поэтому мы и думаем о новых подходах».

В новом посте - о нуждах заказчиков изменений в «инфре».

Что нужно заказчикам изменений в «инфре»?

Заказчиков изменений в инфраструктуре много. Разработчикам хочется благополучно передать сервис в эксплуатацию и не упираться в «инфру». Руководителям команд интересна прозрачность статуса задач. Бизнесу необходимо быстро внедрять изменения, гибко меняться под рынок и экономить без риска. Что же происходит на практике?

📍У 31% разработчиков «инфра» мешает созданию решений и функций, для 34% статус инфраструктурных задач не прозрачен.

📍 35% тимлидов не понимают, как оптимизировать инфраструктуру без риска, 28% отмечают, что инфраструктурные проблемы отъедают треть времени.

📍 У 50% продактов и бизнес-руководителей из-за медленной перестройки «инфры» страдает time to market продукта, 30% не могут посчитать стоимость инфраструктуры в юнит-экономике продукта.

Ксения Кузнецова, CPO компании «Прегель», комментирует: «Для заказчиков изменений ИТ-инфраструктура - «чёрный ящик».

Если у представителя команды эксплуатации есть хотя бы неточное и неполное представление о ней, то у заказчика изменений, который напрямую с ней не работает, оно часто отсутствует.

В результате, разработка создаёт новый сервис и не знает, как передать его в эксплуатацию, какими метриками его обвязать, т.к. представления об устройстве и принципах работы инфраструктуры нет. Эксплуатация не может добавить эти метрики самостоятельно из-за недостатка знаний о внутреннем устройстве сервиса.

Если вам знакомы эти или другие проблемы с инфраструктурой, и вы готовы к диалогу об их решении, мы открыты для всех мнений».

Следующий пост - о самых популярных метриках для «инфры».

ИТ-инфраструктура: ключевые метрики

Чего бизнес ждёт от ИТ-инфраструктуры? Прежде всего, он хочет обеспечить непрерывность основных процессов и избежать прямых убытков. Во вторую очередь бизнес ждёт гибких изменений, чтобы расти и развиваться. К таким выводам мы пришли, анализируя топ метрик от наших респондентов с HighLoad++.

81% опрошенных следят за показателями надёжности и доступности (SLO / SLA / SLI). Эта метрика является самой популярной среди разработчиков и архитекторов, руководителей команд, продактов и руководителей бизнес-блока. Все участвовавшие в опросе CTO также подтвердили её важность.

У DevOps и SRE в приоритете были метрики нагрузки CPU, RAM и т.п, а также среднее время восстановления MTTR (Mean Time To Recovery) и среднее время между сбоями MTBF (Mean Time Between Failures). Для решения прикладных задач, характерных для этих ролей, они оказались важнее.

32% всех респондентов пользуются картами инфраструктуры, отражающими различные срезы её состояния (стойки, сетевая связанность, серверы и т.п.). Эти инструменты облегчают, в частности, отслеживание нагрузки, функционирования оборудования и размещения компонентов.

Комментарий Ксении Кузнецовой, CPO компании «Прегель»: «В ходе собственных исследований мы выяснили, что под «картами инфраструктуры» обычно понимается сумма объектов из разрозненных источников, отражающая их состояние и взаимосвязи. Часто они существуют автономно и никак не проинтегрированы друг с другом.

Эксплуатанты стараются установить связи между ними, чтобы решить инцидент или принять решение об управляющем воздействии. Людям важно где-то хранить сведения о взаимосвязи компонентов ИТ-инфраструктуры и визуализировать эти связи - для нашей компании и продукта это ценный сигнал о востребованности».

До встречи в следующем году!

С наступающими праздниками, дорогие заказчики, партнёры и коллеги!

Искренне благодарим вас за вашу поддержку. Обратная связь от вас помогает нам становиться лучше. Развитие нашей компании - ваша заслуга.

Желаем вам стабильности, успехов, роста и процветания в новом году!

Новости об open source проекте Foliage

Foliage - открытая технология для создания цифровых двойников ИТ-инфраструктуры. Она лежит в основе продуктовой линейки компании «Прегель», поэтому мы активно следим за её развитием. Уже через 2 недели в Генте (Бельгия) состоится международная конференция Config Management Camp, в программу которой включен доклад о Foliage.

2 февраля в 18:00 по Москве запланирован доклад “On the Path to Digital Twins: Loosely Coupled Infrastructure Models”, тезисы которого уже доступны на сайте конференции. Онлайн-трансляцию мероприятия ожидаем на YouTube-канале CitytvNl.

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

– сбор фактов об ИТ-инфраструктуре из облачных и локальных источников;
– построение распределённых графовых моделей поверх конфигурационных и runtime-данных;
– создание специфичного для данного домена или задачи «среза» модели в целях поддержки повседневных операций и автоматизации;
– обмен знаниями, практиками и политиками с помощью переиспользуемых фрагментов графа знаний.

Признание Foliage международным open-source сообществом - важный знак для нас: через несколько лет цифровое моделирование ИТ-инфраструктуры может стать мировым трендом.

Присоединяйтесь к трансляции CfgMgmtCamp 2 февраля!

«Инфра» и жизненный цикл цифрового продукта

ИТ-инфраструктура - это не только эксплуатационная среда цифрового продукта. Еcли у вас есть код, значит, есть и место, где он крутится, - и это необязательно прод. Потребность в стартовой «инфре» возникает задолго до запуска продукта:

📍 Стенды разработки нужны уже на этапе проектирования и проверки гипотез.

📍 Стенды тестирования, нагрузки и песочниц планируются ещё до появления первой сборки.

📍 Среда эксплуатации должна быть готова до непосредственной поставки продукта.

(Более подробно это иллюстрирует схема выше.)

Сохранять, поддерживать и обслуживать ИТ-инфраструктуру придётся вплоть до даты EOL (End-of-Life). Цикл проверки гипотез, разработки и выкатки изменений у успешных продуктов повторяется в течение нескольких лет.

Как это отражается на «инфре»? Она постепенно прирастает новыми сущностями, и чем старше продукт, тем дальше он от своих двух первых стендов для MVP. На этом этапе крайне важно научиться отчуждать знания - они не должны оставаться только в головах тех, кто проектировал самый первый вариант «инфры» (иначе неизбежен «фактор автобуса»).

Историю изменений инфраструктуры может хранить цифровая модель - с ней команды получают шанс при необходимости разобраться, по каким принципам «инфра» строилась в самом начале. Без понятного источника, к которому можно обратиться, эксплуатанты получают legacy хаос.

Мы ищем пути его преодоления вместе с вами - напишите нам на info@pregel.pro. Мы расскажем и покажем, какие шаги к цифровому моделированию инфраструктуры можно сделать уже сейчас.

Скоро - о том, как и почему рост бизнеса увеличивает хаос в «инфре».

Новости и демо Foliage - сегодня!

Напоминаем: в 18:00 на YouTube-стриме международной конференции Config Management Camp можно будет посмотреть доклад "On the Path to Digital Twins: Loosely Coupled Infrastructure Models" об открытой технологии Foliage.

Этот open source проект - основа наших решений, и мы стремимся использовать все его преимущества.

Создатели технологии обещают провести демонстрацию текущих возможностей Foliage, код демо также находится в открытом доступе.

DMTF RedFish: подводные камни

В феврале в блоге «Онтико» выйдет статья по мотивам выступления Никиты Австрийского на HighLoad++ 2025. Никита - технический руководитель разработки в нашей компании и эксперт по управлению крупными серверными парками. Его статья посвящена сравнению протоколов IPMI и DMTF RedFish - преимущественно в пользу последнего.

Как это часто бывает, в материал вошло далеко не всё, что стоило бы сказать.

Вот 4 казуса работы с RedFish, с которыми вы точно столкнётесь:

1) Redfish один, но у каждого вендора своя реализация. Стандарт рекомендательный, и производители оборудования трактуют его по-разному. Одна и та же сущность может находиться по разным путям, предписанные стандартом поля могут отсутствовать. Иногда важная информация находится в поле OEM, где никак не ожидаешь найти самое основное.

Что делать: принять разницу трактовок как данность и адаптироваться к ней. Выполнив discovery на старте, фиксировать, что где находится и как поддерживается. Не «затачивать» парсеры под одного вендора, допускать отсутствие полей. Писать адаптеры под каждого производителя (Dell/HPE/Lenovo/OpenBMC) вместо унифицированного решения «под всех».

2) Аутентификация сегодня работает так, а завтра иначе. У серверов от разных вендоров разные механизмы входа и сессий с разными требованиями. Обновление прошивки иногда ломает интеграцию. Для доступа к удалённой консоли могут внезапно потребоваться дополнительные действия (одноразовый URL через OEM-action), или вдруг нужны дополнительные заголовки/CSRF.

Что делать: не хранить «вечные» учётные данные в каждом сервисе, а сделать централизованный брокер доступа. Использовать сессии и токены с ограниченным сроком действия. Сразу учитывать работу с корпоративными сертификатами безопасности.

3) Нажали кнопку - результата ждать 20 минут. Часть серверных операций мгновенная (reset или power), но есть и долгие операции. Например, обновление прошивок, настройка RAID и подключение виртуальных носителей выполняются асинхронно. Для незавершающихся операций приходится отслеживать статус, ошибки и таймауты. Контроллеры (BMC) легко «ложатся», если их нагружать параллельными запросами.

Что делать: ввести единый механизм управления заданиями со стадиями запуска, контроля, повтора и получения финального результата. Операции нужно делать устойчивыми к повтору. Число запросов к «железу» нужно ограничивать, устанавливая лимиты.

4) По спецификации фича есть, а по факту недоступна. Востребованная функциональность типа KVM, Virtual Media или RAID на части серверов может не поддерживаться в прошивке или оставаться недоступной из-за ограничений лицензии и выключенных настроек.

Что делать: всегда проверять фактическую доступность, не ограничиваясь документацией. Иногда целесообразно проработать и держать наготове альтернативные и упрощенные способы доступа (через тот же протокол IPMI). Во избежание проблем при проектировании автоматизаций и интерфейсов брать в расчёт и отображать стоит только реально доступную функциональность.

Зная эти нюансы, вы серьёзно облегчите себе работу с RedFish (мы к нему ещё вернёмся).

Почему рост бизнеса ведёт к хаосу в ИТ-инфраструктуре?

Масштабирование редко бывает безболезненным. Для «инфры» взрывной рост почти всегда означает стремительную потерю управляемости. Не в последнюю очередь поэтому мы слышим о сбоях в работе именно в фазе роста, когда терять стабильность и деньги особенно обидно.

В чём причины сбоев?

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

Внедряются микросервисы. Несмотря на то, что они хороши с точки зрения непрерывности бизнеса, с позиции отслеживания инцидентов это труднопроходимые дебри. Как разобраться в 700-2000 микросервисах, у каждого из которых своя конфигурация? Это долго и больно. Шанс ошибиться и задеть соседние сервисы при изменениях тоже велик.

Становится больше серверов. Если под управлением их сотни и тысячи, конфигурирование вручную уже невозможно - берём Ansible или его аналог. Но инструменты автоматизации не предотвращают ошибок, зато они их тиражируют. А ещё всегда можно внести emergency-правку или забыть о каком-то сервере - и тогда config drift неизбежен.

Переезжаем в 2 и более ДЦ. Хотим подстраховаться от проблем поставщиков «инфры», но на выходе получаем более сложную топологию сети, разнокалиберное «железо», асимметричные отказы и необходимость мириться с географией дата-центров и сетевыми эффектами при каждом релизе. Также становится сложнее добиться согласованности данных и избежать split brain.

Рост бизнеса сопровождается множественными изменениями со стороны людей и инструментов. (С недавних пор к ним присоединились ИИ-агенты.) В фазе роста инфраструктура особенно хрупка и непрозрачна - её непрерывно подтюнивают, и отследить это без единого источника правды никак невозможно.

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

Скоро - о том, почему ИИ-инструменты не спасают, а подливают масла в огонь.

Как построить адаптивную систему управления ЦОДом на DMTF Redfish

Сегодня в блоге «Онтико» вышла статья о DMTF Redfish и IPMI. Автор - технический руководитель разработки «Прегеля» Никита Австрийский. Redfish - современный протокол управления сервером, на основе которого наша компания построила адаптивную систему для крупного заказчика.

Делимся советами, которые помогли нам создать решение для управления парком из более чем 1000 серверов на базе Redfish.

1) Фундамент: discovery всего, что есть

Как уже отмечалось в прошлом посте и статье, реализации Redfish разнятся от вендора к вендору. Поэтому сначала надо обнаружить всё, что реально доступно для каждого устройства - от консолей и сенсоров до действий и обновлений.

Хорошая практика - создать и хранить профиль всего, что доступно для сервера, включая модель и версию прошивки. Это позволит системе принимать решения автоматически с учётом этих данных.

2) Архитектура: нормализованное ядро + адаптеры «под вендора»

Часто код системы управления «железом» от разных производителей превращается в бесконечные «простыни» циклов с if vendor == ..., что неудобно и непонятно.

Хорошая практика - архитектура с ядром, в котором предусмотрена единая модель («сервер», «питание», «сенсоры», «консоль», «обновления») и адаптерами для разных вендоров оборудования - Dell, HPE, Lenovo, OpenBMC. Такой подход позволяет избежать переписывания ядра при появлении «железа» от нового производителя - достаточно добавить адаптер.

3) Надёжность и наблюдаемость: бережём BMC-контроллеры

BMC позволяют удалённо осуществлять мониторинг состояния (температура, питание, вентиляторы) и диагностику сервера. Они довольно медленные и капризные, не созданы для параллельных запросов и быстро выходят из строя. Если не подумать о них, «панель управления ЦОДом» превращается в «панель случайных таймаутов».

Хорошая практика - учесть особенности BMC уже на стадии проектирования. Стоит предусмотреть ограничение скорости запросов, очереди, кэширование и грамотно настроить повторение операций (retry), таймауты, а также метрики/трейсы по операциям и времени ответа. Спасение BMC от перегруза - отдельная тема, возможно, мы однажды к ней вернёмся.

Если вам интересно выжать максимум плюсов из RedFish, приходите в комментарии.

Эксплуатация ИТ-инфраструктуры в эпоху ИИ

Как сказалось на эксплуатации внедрение ИИ-помощников разработчика? Негативно - фактически конфигурация «инфры» стала новым узким местом. «Потолок» производства кода снят, скорость поставки кратно возросла. Но ускорился только один элемент системы (разработка) - эксплуатация работает в прежнем темпе, которого уже не хватает.

Новый код нужно где-то разворачивать и исполнять - и желательно сразу, чтобы новые фичи и сервисы быстрее начинали приносить деньги. На практике «сразу» никак не получается.

Что же не даёт эксплуатации успевать за прогрессом?

Ручное управление. ИТ-инфраструктура сильно завязана на человеческий фактор. Пароли, доступы и сетевые настройки (секреты) контролируются людьми. CI/CD пайплайны в большинстве команд сложные и медленные, с ручными шагами. Даже если ИИ-агент предлагает варианты конфигурации, финальное решение всё равно остаётся за человеком и может запаздывать.

Сложность автоматизации. Управление «инфрой» подразумевает множество нетривиальных и разнородных задач, трудно поддающихся даже упорядочению, не говоря уже об автоматизации. Для отдельных процессов автоматизации предусмотрены, но они рассчитаны на редкие изменения, а не на постоянный входящий поток апдейтов, который принёс с собой ИИ.

Высокая цена ошибки. Эксплуатация сразу имеет дело с «боевой» системой, а не с кодом, который ещё предстоит тестировать. Одна неверная настройка может мгновенно привести к сбою и убыткам. Процесс выкатки нового кода в продакшн, как правило, идёт медленно, чтобы можно было в любой момент «откатить» изменения обратно.

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

Зависимость от контекста. Решения в «инфре» всегда принимаются с учётом нескольких факторов - и часто «лучшие практики», заложенные в ИИ, не могут учесть ограничений и legacy конкретного проекта, а также взаимозависимость разных его частей. Часто знания об этом остаются негласными, нигде и никак не формализуются, оставаясь достоянием SRE, Platform и DevOps инженеров.

Код дешевеет, а инфраструктура становится всё дороже и приносит всё больше боли.

Чтобы выровнять баланс, потребуется создать цифровую модель инфраструктуры. В «Прегеле» мы занимаемся построением такой модели на основании технологии Knowledge Graph и ИИ-инструментов. Если вам интересно поучаствовать в трансформации отрасли, свяжитесь с нами.

Первый шаг к омоделиванию «инфры» - её интерактивная карта. Об этом - в следующий раз.

Что общего у болида «Формулы 1» и ИТ-инфраструктуры?

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

В бизнесе скорость успешной выкатки обновлений даёт конкурентное преимущество. Мы уверены, что тестирование конфигураций и проверка гипотез на цифровом двойнике «инфры» позволит избежать большинства ситуаций вида «деплоили, но откатили обратно». Сейчас каждая новая конфигурация несёт с собой риски. Большинство организаций до сих пор пытаются прогнозировать последствия изменений, используя статичные схемы в Confluence, Visio и Miro, и деплоят сразу в прод. Возможен ли постепенный переход к цифровым двойникам для уже существующих систем?

4 шага к цифровому двойнику ИТ-инфраструктуры

Цифровой двойник позволит добиться непротиворечивости изменений, выявить скрытые зависимости и моделировать поведение систем при изменениях. Мы выделяем 4 стадии перехода к такой системе.

Формализовать текущее состояние (as-is). Актуальная картина складывается из метрик, логов и топологий сервисов. Компоненты и их взаимосвязи объединяются в самообновляющуюся карту инфраструктуры.

Зафиксировать целевую архитектуру и стандарты (to-be). На этом шаге разные команды получают возможность договариваться о том, какой инфра должна стать в будущем, вносить свои пожелания в цифровой двойник и проверять их непротиворечивость.

Обнаружить отклонения, риски и технический долг. На этой стадии цифровой двойник помогает командам находить различие (diff) между актуальным и желаемым состояниями. Также команды получают от цифрового двойника информацию о том, что и где нужно изменить, чтобы прийти к желаемому состоянию.

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

Мы понимаем, что отрасль нуждается в таких системах, и верим, что цифровые двойники ИТ-инфраструктуры - наше будущее.