Vendor lock-in: как уйти от нас и ничего не потерять

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

Коротко: vendor lock-in в нашем случае не работает как рычаг удержания. Не потому что мы альтруисты, а потому что наша модель построена иначе.

Где живёт ваша инфраструктура

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

Всё, что мы делаем с вашей инфраструктурой, живёт в вашем репозитории. Terraform-конфиги, описывающие облачные ресурсы, сети, балансировщики. Роли и плейбуки Ansible, отвечающие за состояние серверов и приложений. CI/CD-пайплайны в вашем GitLab. Документация и runbook-и в вашей Wiki.

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

Это не декларация. Это архитектурное решение, принятое ещё тогда, когда мы формализовали разделение ролей между Terraform и Ansible — об этом мы писали в 2017 году, когда стандарт только устоялся. Граница проходит по первому SSH-соединению: всё, что создаётся через API провайдера — Terraform; всё, что происходит внутри ОС — Ansible. Такая структура читаема любым инженером, знакомым с этими инструментами, и не требует «посвящения» от нас.

Принципиально важно, что речь не о формальной галочке. Мы видели проекты, где «IaC» существовал в виде нескольких Terraform-файлов с захардкоженными IP и комментарием «не трогать», пока остальная конфигурация жила в пяти Ansible-плейбуках, написанных тремя разными людьми без единого стиля. Такой код теоретически хранится в репозитории, но практически непередаваем — его нельзя понять без того инженера, который его писал. Наш стандарт описывает не факт хранения кода, а качество, при котором код реально читаем и воспроизводим.

Что происходит при завершении контракта

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

Код в актуальном состоянии. За время работы мы следим за тем, чтобы инфраструктурный код отражал реальное состояние контура. Никаких «временных правок руками, которые потом занесём» — если изменение не попало в Terraform или Ansible, оно не считается сделанным. Это дисциплина, а не благое пожелание.

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

База знаний в актуальном виде. За время работы мы ведём Wiki с архитектурными решениями, описанием нетривиальных кейсов, runbook-ами на типичные инциденты. При завершении контракта эта документация передаётся вместе с кодом — не как набросок, а как документ, которым реально можно пользоваться.

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

Почему мы так делаем

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

Искусственный vendor lock-in работает как инструмент удержания ровно до того момента, когда клиент накапливает достаточно раздражения и решает разобраться с проблемой радикально. После этого расставание происходит болезненно для обеих сторон: у клиента — месяцы хаоса при передаче, у нас — испорченная репутация. Мы видели такие истории на рынке и сознательно не хотим быть их участником.

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

Честный trade-off

Полная передаваемость требует дисциплины, которая иногда замедляет работу на старте.

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

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

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

Что проверить заранее

Если вы сейчас выбираете DevOps-партнёра и хотите убедиться, что не попадёте в зависимость — вот конкретные вопросы, которые стоит задать на переговорах:

• Где хранится инфраструктурный код и кто имеет к нему доступ?
• Используется ли IaC (Terraform, Ansible) или настройки живут на серверах руками?
• Что именно передаётся при завершении контракта — код, документация, сессии с командой?
• Зафиксирован ли порядок передачи в договоре?

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

У нас ответы на эти вопросы зафиксированы в договоре. Передача контура — стандартная процедура, а не переговоры с нуля при расставании.

Если хотите разобраться, как выглядит наш подход к конкретно вашему контуру — начните с обследования. Мы проводим его за 3–5 рабочих дней и даём план: что есть сейчас, как это описывается в коде и что нужно для воспроизводимой эксплуатации. Подробнее — на странице DevOps-аутсорсинга.