Вендоры и импортозамещение: выбор, SLA, зависимость и переезд

← назад к разделу

Пока руководитель отвечает за одну команду, вендоры для него это чужая проблема: базу купили до него, облако выбрали архитекторы, договор подписал закупщик. С ростом зоны ответственности выясняется, что половина рисков сидит именно там: поддержка, которая отвечает через три дня, лицензия, которую нельзя продлить, подрядчик, у которого в голове вся интеграция. А в России к этому добавляется импортозамещение, где сроки и требования задаёт не бизнес, а нормативные акты.

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

Выбор вендора: RFI, RFP и пилотспросят на собеседовании

Выбор идёт воронкой, и на каждом шаге кандидатов становится меньше, а проверка дороже.

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

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

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

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

SLA в договоре: что проверятьспросят на собеседовании

Цифра 99,9% на первой странице ничего не значит, пока не прочитаны определения. Что смотреть в договоре или приложении об уровне обслуживания:

• Как считают доступность. За месяц или за год, исключены ли плановые работы и сколько их может быть, кто фиксирует простой: ваш мониторинг или их. 99,9% в месяц это около 43 минут простоя, 99,5% уже около 3,6 часа.
• Время реакции и время решения раздельно. «Реакция 1 час» означает, что за час вам ответят «приняли». Нужен срок восстановления работы или обходного решения для критичного приоритета.
• Определение приоритетов. Кто присваивает критичность: если вендор, то ваш «всё лежит» станет «средним».
• Часы поддержки. 24×7 или рабочие дни по московскому времени; для продукта, который падает ночью, это разные договоры.
• Последствия нарушения. Скидка на следующий период в размере 5-10% от месячного платежа не компенсирует ущерб и мало мотивирует. Ищите право расторгнуть договор после повторных нарушений, это сильнее любой скидки.
• Эскалация. Имена и роли на втором и третьем уровне, а не общий адрес поддержки.
• Отчётность. Ежемесячный отчёт о выполнении SLA, который вендор присылает сам.

Свой SLA перед бизнесом нельзя обещать выше, чем у самого слабого вендора в цепочке, если нет резерва. Как связать это с целевыми уровнями сервиса, разобрано в метриках команды.

Зависимость от вендора и как её ограничитьспросят на собеседовании

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

Что ограничивает зависимость:

• Данные выгружаются в открытом формате и это проверено руками, а не прочитано в документации. Раз в квартал полная выгрузка и восстановление на чистом стенде.
• Открытые протоколы и стандарты на границах. SQL без расширений вендора в приложении, S3-совместимое хранилище, OpenID Connect для входа, OpenTelemetry для наблюдаемости. Внутри можно пользоваться чем угодно, граница должна быть заменяемой.
• Слой между вашим кодом и вендором. Свой интерфейс к платёжному шлюзу или очереди позволяет сменить реализацию за недели, а не месяцы.
• Условия выхода в договоре. Срок, в течение которого вендор отдаёт данные после расторжения, формат, помощь в переезде, фиксированная цена продления на 2-3 года вперёд.
• Права на код при заказной разработке. Исключительные права на результат и передача исходников с документацией на каждой приёмке, а не «в конце проекта».
• Решение записано. Почему выбрали этого вендора и какую зависимость приняли, фиксируют в ADR: через три года это единственный способ понять, какие допущения поменялись.

Расходы на облака и лицензии разбираются отдельно в статье о деньгах в облаке.

Подрядчики и аутстаффспросят на собеседовании

Две модели, которые часто путают, и от этого ломается управление.

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

Что работает в обеих моделях:

• Свой человек на каждом контракте. У каждого подрядчика есть внутренний владелец, который понимает, что тот делает, и может принять работу. Без него вы покупаете чёрный ящик.
• Приёмка не по актам, а по артефактам. Код в вашем репозитории с первого дня, тесты, документация, прошедшее ревью. Акт подписывают после этого.
• Знания не уходят с подрядчиком. Ключевые решения описаны, на критичные компоненты есть хотя бы один свой инженер, который их знает. Правило: доля подрядчиков в команде, которая владеет критичной системой, не больше половины.
• Доступы. Отдельные учётные записи, минимальные права, отзыв в день окончания договора. Как устроить это с секретами и персональными данными, описано в статье о PII и секретах.
• Аутстафф встраивают как своих. Те же ритуалы, то же ревью, тот же вход в команду. Отношение «это же подрядчик» даёт текучесть и потерю знаний через полгода.

Импортозамещение: что требуют актыспросят на собеседовании

Здесь нельзя пересказывать по памяти и по чужим статьям: акты меняются несколько раз в год. Ниже то, что написано в первоисточниках на дату подготовки статьи.

Реестр российского ПО. Постановление Правительства № 1236 от 16.11.2015 в действующей редакции утверждает правила формирования и ведения единого реестра российских программ для ЭВМ и баз данных и реестра евразийского ПО. Уполномоченный орган по реестру Минцифры (п. 6 постановления), реестр работает в ФГИС «Реестры программ для электронных вычислительных машин и баз данных» (п. 6.1); с изменениями 2025 года сами записи вносит оператор реестра, которого определяет Правительство (п. 6 Правил). Важная деталь: изначально это же постановление устанавливало запрет на допуск иностранного ПО в госзакупках, но постановлением № 1875 от 23.12.2024 эти пункты признаны утратившими силу, и теперь 1236 это только правила реестра.

Закупки по 44-ФЗ и 223-ФЗ. Запрет переехал в постановление Правительства № 1875 от 23.12.2024 «О мерах по предоставлению национального режима...». Пункт 1 устанавливает для закупок по обоим законам запрет на товары иностранного происхождения по перечню приложения № 1, ограничение по приложению № 2 и преимущество российских товаров. В приложении № 1 позиция 146 это «Программа для электронной вычислительной машины и (или) базы данных». Российское происхождение подтверждается номером реестровой записи из реестра российского ПО (п. 3, подп. «г»). Купить иностранное ПО можно, если в реестрах российского и евразийского ПО нет программы того же класса или если ни одна из них не соответствует требованиям заказчика; тогда в описание объекта закупки включают обоснование неприменения запрета с классом ПО и характеристиками, по которым российские программы не подходят.

КИИ. Указ Президента № 166 от 30.03.2022 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» устанавливает две вещи (п. 1):

• с 31 марта 2022 года заказчики по 223-ФЗ, кроме организаций с муниципальным участием, не могут закупать иностранное ПО, в том числе в составе программно-аппаратных комплексов, и услуги для его использования на принадлежащих им значимых объектах КИИ без согласования с уполномоченным федеральным органом;
• с 1 января 2025 года органам государственной власти и этим заказчикам запрещается использовать иностранное ПО на принадлежащих им значимых объектах КИИ.

Порядок согласования, требования к ПО и правила перехода на российское ПО по указу утверждены постановлением Правительства № 1478 от 22.08.2022.

Указ касается только заказчиков по 223-ФЗ и органов власти, но с 1 сентября 2025 года действует Федеральный закон № 58-ФЗ от 07.04.2025, который дополнил 187-ФЗ «О безопасности КИИ». Теперь любой субъект КИИ обязан использовать на значимых объектах ПО из реестра российского ПО либо ПО, которое применяется в защищённых государственных информационных системах (п. 5 ч. 3 ст. 9) и соблюдать требования к программно-аппаратным средствам (п. 6 ч. 3 ст. 9), а порядок и сроки перехода устанавливает Правительство (п. 7 ч. 2 ст. 6). Граница при этом прежняя: речь о значимых объектах КИИ, а не обо всей ИТ-инфраструктуре компании.

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

Дорожная карта миграцииспросят на собеседовании

Карта строится от инвентаризации, а не от списка российских продуктов.

1. Инвентаризация. Все зарубежные продукты: что, где стоит, сколько лицензий, когда истекает поддержка, какие системы зависят. Отдельной колонкой: работает ли на значимом объекте КИИ.
2. Классификация по риску. Что перестанет работать без поддержки (СУБД, ОС, виртуализация, средства защиты), что просто устареет (офисные пакеты, IDE). Первые идут раньше.
3. Выбор замены по воронке из первого раздела, с пилотом. Проверка записи в реестре по номеру, а не по словам вендора.
4. Волны. Сначала небольшая некритичная система, на которой команда учится; потом основные; критичные последними, когда процесс отлажен.
5. Параллельная работа и откат. Старая система живёт, пока новая не прошла неделю без расхождений.
6. Вывод старого из эксплуатации с датой. Без неё две системы живут годами и стоят вдвое.

Пример волны: переезд с Oracle на PostgreSQL или его российскую сборку. Схему и типы ora2pg переносит почти механически, основная работа в хранимом коде и SQL приложения, проверка идёт сверкой контрольных сумм и теневым прогоном. По шагам это разобрано в статье Oracle или PostgreSQL: отличия и миграция. Для дорожной карты из неё важно одно: срок определяет объём PL/SQL, а не размер базы, поэтому оценку делают после анализа кода, а не по числу таблиц.

Шаблон строки в карте: система; что заменяем; на что; основание (КИИ, 44-ФЗ, риск поддержки); волна и квартал; владелец; критерий завершения; дата вывода старого.

Типичные ошибки

• Выбор по презентации. Демонстрация на сценариях вендора, а не на ваших данных. Лечится пилотом с заранее записанными критериями.
• SLA без определений. Высокий процент доступности, а реакция в рабочие часы и приоритет присваивает вендор.
• Импортозамещение как замена «один к одному». Ищут точную копию зарубежного продукта и не находят. Иногда дешевле поменять процесс, чем искать продукт с той же кнопкой.
• Все системы одной волной. Команда учится на критичной системе, и первые ошибки стоят дорого.
• Пересказ требований по слухам. «Нам запрещено всё иностранное» там, где акты требуют меньшего, или наоборот. Решения принимают по тексту актов и с юристами.
• Подрядчик без внутреннего владельца. Через год никто внутри не может принять работу или продолжить её.
• Нет даты вывода старого. Две системы, две поддержки, два набора навыков.

Глубже: совокупная стоимость за три годарасширенное

Сравнивать вендоров по цене лицензии это сравнивать машины по цене колёс. Совокупная стоимость владения считается на горизонт 3 года и включает: лицензии или подписку; техническую поддержку, обычно 20-25% от стоимости лицензий в год у коробочных продуктов (уточняйте у вендора); железо или облако; людей на эксплуатацию, включая обучение; разовую стоимость внедрения и переезда; стоимость будущего выхода. Последняя строка самая честная: продукт дешевле на 30%, из которого невозможно уйти, через пять лет оказывается самым дорогим. Сводную таблицу приносят финансовому директору в формате, который разобран в статье о портфеле и ROI.

Глубже: когда вендор ведёт себя плохорасширенное

Признаки: SLA нарушается третий месяц подряд, обещанные исправления уезжают из версии в версию, ключевой инженер вендора ушёл и на его место никого. Порядок действий: собрать факты (заявки, сроки, отчёты SLA), провести разговор на уровне руководителей с конкретным планом исправления и датами, параллельно оценить стоимость выхода и начать RFI на замену. Последний шаг не угроза, а страховка: переговоры идут иначе, когда у вас есть альтернатива, и вендор это чувствует. Разрыв без плана выхода хуже плохого вендора.

Коротко

• Вендора выбирают воронкой RFI, RFP, пилот; критерии с весами фиксируют до ответов, пилот с критериями успеха до старта.
• В SLA читают определения: как считают доступность, время решения отдельно от реакции, кто присваивает приоритет, право расторжения при повторных нарушениях.
• Зависимость от вендора мерят стоимостью ухода и ограничивают открытыми форматами, заменяемыми границами, условиями выхода в договоре и правами на код.
• Аутсорсинг это покупка результата, аутстафф аренда людей; в обоих случаях нужен внутренний владелец и код в вашем репозитории с первого дня.
• Постановление № 1236 теперь это правила реестра российского ПО у Минцифры; запрет на иностранное ПО в закупках по 44-ФЗ и 223-ФЗ сейчас в постановлении № 1875, позиция 146 приложения № 1.
• Указ № 166: с 31.03.2022 закупка иностранного ПО для значимых объектов КИИ заказчиками по 223-ФЗ только с согласованием, с 01.01.2025 его использование на таких объектах запрещено. С 01.09.2025 по 187-ФЗ (ред. 58-ФЗ) ПО из реестра на значимых объектах обязаны использовать все субъекты КИИ, в порядке и сроки от Правительства.
• Дорожная карта: инвентаризация, риск, выбор с пилотом, волны от некритичного к критичному, параллельная работа, дата вывода старого.

Что почитать дальше

• Oracle или PostgreSQL: отличия и миграция - пример одной волны импортозамещения по шагам.
• ADR: как фиксировать архитектурные решения - где фиксировать выбор вендора и принятую зависимость.
• Портфель проектов: приоритизация и ROI - как принести совокупную стоимость финансовому директору.
• Деньги в облаке - из чего складываются расходы на облачного вендора.
• Технический долг - устаревший продукт без поддержки это тоже долг с процентами.
• Стейкхолдеры и ожидания - как объяснять бизнесу сроки переезда.