Избранные проекты

Сначала валидация: мультисайтовая резиденция по Hyper-V и SCVMM

Для конечного заказчика глобальной ИТ-сервисной компании — правительства одного из штатов США · по резиденс-контракту с Dell

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

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

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

Момент, ради которого мы рассказываем эту историю, наступил в середине проекта: инженерная команда заказчика провела ревью нашей целевой архитектуры и оспорила одно из её ключевых решений — где должна проходить граница ответственности между Network ATC и SCVMM в конфигурировании сети. Они были правы, что настояли. Мы переработали проект, и версия 1.1 несёт след их ревью: более чистое разделение того, кто чем управляет, согласованное строка за строкой с людьми, которые эксплуатируют платформу.

Иные консалтинговые компании назвали бы это трением по объёму работ. Мы называем это проектом, который работает ровно так, как задуман: мы занимаемся инженерией вместе с заказчиком, а не вопреки ему. Архитектура, выдержавшая проверку инженерами самого заказчика, стоит больше той, которую никто не оспаривал.

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

Методология миграции приложений, поставленная на промышленные рельсы

Действующий проект миграции приложений с Dell · поставка по модели B2B2B

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

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

Как работает фабрика:

• Фазовые гейты. Каждая фаза завершается гейтом с определёнными критериями входа и выхода. Ничто не движется дальше по инерции.
• Сгенерированные ранбуки — и сгенерированные планы отката. Для каждой move-группы фабрика производит путь вперёд и путь назад в единообразной, пригодной для ревью форме. План отката — не довесок задним числом; он генерируется вместе с ранбуком, каждый раз.
• Человеческое go/no-go. ИИ-агенты готовят доказательную базу: синтез обследования, карту зависимостей, проверки валидации, документацию. Каждое решение на гейте принимает человек. Ни один шаг миграции не выполняется со слов агента.
• Полная прослеживаемость. Каждое решение и каждое действие логируется и атрибутируемо: что сделано, когда, кем и с чьего одобрения.

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

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

Агентная модель работы под надзором инженеров

Наша модель выполнения проектов · так устроен каждый проект Gus IT

Первый вопрос, который серьёзный заказчик задаёт о выполнении проектов силами ИИ, — правильный вопрос: безопасно ли подпускать ИИ-агентов к продуктивной инфраструктуре?

Наш ответ — строгое разделение труда, применяемое в каждом проекте.

Что делают наши ИИ-агенты: повторяющуюся инженерную работу, которая съедает время senior-инженеров и провоцирует человеческие ошибки. Они проводят обследование целых инфраструктур, превращают конфигурации в документацию, генерируют ранбуки и планы отката, выполняют проверки валидации и поддерживают «бумажный след» в актуальном состоянии — единообразно, в любое время суток, без усталости.

Чего они не делают никогда: не утверждают архитектуру. Не прикасаются к продуктивной системе без надзора. Не принимают решение go/no-go.

В каждом проекте есть поименованный senior-инженер, который отвечает за утверждение архитектуры и за каждое действие, меняющее состояние систем. Наша автоматизация построена с безопасным dry-run: её можно отрепетировать, не касаясь живых систем, и каждая фаза несёт план отката прежде, чем несёт изменение. Каждое действие — человека или агента — логируется и атрибутируемо, поэтому вы всегда знаете, кто решил и кто действовал.

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

Это не лабораторная концепция. Именно так мы сегодня выполняем нашу контрактную работу, включая проекты по партнёрским и канальным контрактам.

Если вы взвешиваете, есть ли ИИ место в вашей цепочке выполнения проектов — или как им управлять, когда он там окажется, — приходите на оценочный разговор с самыми трудными вопросами. Эта модель построена так, чтобы выдерживать допрос.