Замещение MS-стека в производстве. Методология по этапам

Как я подхожу к замещению MS-стека

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

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

Типичный стартовый ландшафт у такого заказчика. Обычный MS-зоопарк. Active Directory с групповыми политиками, Exchange, SharePoint, Microsoft Office, Visio и Project, Autodesk в конструкторском отделе. Поверх стоит клиент-серверная 1С на MS SQL Server и терминальный доступ через Windows RDS. Дальше я разбираю каждый слой и показываю, как его снимаю.

С чего начинаю. Инвентаризация и риски

Первые недели идут без замены. Только инвентарь. Что есть, кто чем пользуется, на каких системах висят бизнес-процессы, какие между системами связи. Я веду эту инвентаризацию по той же девятидоменной методологии аудита, что описывал в записи про карту ИТ-зрелости. По каждой системе держу в голове один вопрос. Что произойдёт с производством, если эта система не работает сутки.

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

На проектах такого масштаба годовые платежи за лицензии Microsoft и Autodesk обычно складываются в 10–15 млн ₽. Это порядок величин, а не точная цифра конкретного заказчика. Эта сумма становится базой, от которой я считаю окупаемость программы. Сразу делаю оговорку, к которой вернусь в экономике. Часть этой базы теоретическая. Autodesk запретил продление для российских компаний, Microsoft напрямую тоже фактически недоступен, и продолжать платить эти деньги по факту не получается. Поэтому baseline я считаю как «сколько стоило бы, будь продление доступно», и помечаю это явно.

Кроме лицензий выписываю риски от продления MS-стека. Внеплановый рост цен в рублях. Отзыв российских юрлиц как клиентов. Недоступность поддержки и обновлений безопасности. Невозможность подписать новые контракты. Трудность обосновать расходы перед советом. Это не про 187-ФЗ и не про принуждение регулятора. Это организационная стратегия независимости от санкционно-чувствительных вендоров. Про 187-ФЗ скажу отдельно ниже.

Граф зависимостей

В дополнение к инвентарю систем строю граф зависимостей. Это не карта сети, а функциональная модель «кто на кого опирается». Без каталога не работает почта. Без почты нет подписи на договорах через почтовый клиент. Без файлового хранилища конструкторы не находят чертежи. Размер графа зависит от ландшафта, но суть в другом. В нём всегда проступают несколько точек концентрации риска. Каталог как корень аутентификации. Файловое хранилище как точка обмена между конструкторами и закупками. 1С как сердце финансовых и складских процессов.

Держу этот граф живым документом в drawio с экспортом в общий файловый сервис, доступным всему ИТ-отделу. Каждый инцидент после программы повод сверить, не появилось ли в графе нового ребра. Граф зависимостей экономит больше всего боли именно на этапе файлов, и ниже я покажу почему.

Почему этапами, а не сразу всё

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

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

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

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

Почему первой ставлю почту

Почта идёт первым этапом почти всегда. Exchange меняю на связку Postfix, Dovecot, Roundcube и Rspamd. Это самая предсказуемая часть программы, потому что почтовый стек стоит на стандартизованных протоколах (SMTP, IMAP, LMTP, Sieve), которые меняются раз в десятилетие. На почте я проверяю, готова ли команда и инфраструктура к остальному.

Как строю архитектуру

Два узла в HA-связке через keepalived. Postfix принимает SMTP с подписями DKIM, прогоняет письмо через спам-фильтрацию в Rspamd, передаёт через LMTP в Dovecot. Dovecot держит ящики в Maildir на ZFS со снимками. Веб-доступ через Roundcube за обратным прокси с TLS. Аутентификацию на старте временно сажаю на отдельный бэкенд, а после этапа каталога перевожу на LDAP. Это порядок, который повторяю из проекта в проект.

Миграция ящиков

Перенос ящиков делаю через imapsync, классику миграций между IMAP-серверами. Скорость зависит от размера ящика, переносы гоню параллельно по несколько штук за раз. Окна выбираю ночные, на время переноса заворачиваю входящую почту на резервный MX, который буферизует письма. Простой для пользователей при таком подходе стремится к нулю. Почта не теряется, она ждёт в очереди.

Спам-фильтрация на Rspamd

Замена облачной защиты Exchange на собственный Rspamd идёт отдельной под-задачей внутри почтового этапа. Включаю модули SPF, DKIM, DMARC, списки RBL, статистический байесовский классификатор. Для обучения выгружаю из старого Exchange архив писем с пометками «спам» и «не спам» и переобучаю классификатор на этой выборке. Точность на первых днях обычно держится в районе 95–96% по случайной выборке, за пару недель дотягивается ближе к 98%. Это типичная динамика, а не результат одного замера.

На стороне веба собираю в Roundcube интерфейс карантина на плагине Managesieve. Пользователи сами размораживают ложноположительные письма и помечают пропущенный спам, эти пометки идут обратно в Rspamd для дообучения. Раз в неделю администратор смотрит статистику и подстраивает пороги.

Файлы, где обычно бьёт откат

SharePoint меняю на Nextcloud на собственной СХД. Это этап, на котором откат случается чаще всего. И почти всегда по одной и той же причине.

Как планирую

Nextcloud на паре узлов с PostgreSQL и кешем сессий. Хранилище лежит на СХД заказчика через выделенный том. Данные переношу через rsync с сохранением структуры папок. Права доступа переношу миграцией групп SharePoint в одноимённые группы Nextcloud. На бумаге всё просто. Засада прячется в правах.

Классическая ошибка с правами

SharePoint держит не плоскую иерархию папок, а наследование прав через site collections с многоуровневыми группами, в которые напрямую вложены группы каталога. Классическая ошибка, это мигрировать эти права плоским скриптом «группа → папка», игнорируя вложенность. Так наследование через site collections не переносится. Часть людей теряет доступ к подпапкам, к которым он у них был только через цепочку групп. И почти всегда среди пострадавших окажется кто-то со срочной отчётностью именно в этих папках. Поэтому проверяю это до окна, а не во время.

Если откат всё же объявлен, алгоритм один. Поднять SharePoint из последнего снимка, заморозить миграцию, переписать перенос прав. Простоя при этом нет, потому что Nextcloud я запускаю параллельно, не выключая SharePoint. Возврат означает просто отложить переключение. Дорого здесь не время отката, а потерянное окно и доверие пользователей.

Как делаю перенос прав правильно

Вместо плоского скрипта делаю перенос в три прохода. Первый. Выгружаю дерево наследования прав из SharePoint в структурированный вид с пометками «прямые права», «через группу», «через site collection». Второй. Строю в Nextcloud эквивалентную структуру (там это решается тегами, архитектура проще). Третий. Валидация. Для каждой пары «пользователь и документ» проверяю, что доступ совпадает с эталоном из SharePoint. Только после прохода валидации ставлю окно переключения.

Поиск и совместная работа

Две вещи, которые на SharePoint были из коробки, в Nextcloud требуют отдельного внимания. Полнотекстовый поиск по содержимому документов подключаю внешним движком (приложение Full Text Search с поисковым бэкендом на отдельном узле). Базовый поиск Nextcloud ищет по именам и тегам, этого мало. Индексация большого архива занимает время, считаю её в плане отдельной строкой. Совместное редактирование документов в браузере закрываю интеграцией с OnlyOffice. По опыту это удобнее, чем было на SharePoint, особенно для распределённых команд, где один документ правят из нескольких локаций одновременно.

Каталог. FreeIPA, Samba AD, ALD Pro

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

Развилка по архитектуре

FreeIPA отлично закрывает Linux-серверы и сервисы. Единый каталог, Kerberos, единый вход для инфраструктуры. Но сам по себе FreeIPA не работает контроллером домена Active Directory, в который можно ввести Windows-машины командой join. У него собственная LDAP-схема и MIT Kerberos, и на тех же узлах он не может одновременно работать ещё и как Samba AD DC. У Samba AD DC несовместимая схема и свой Kerberos. Поэтому здравые сценарии такие.

• Windows-десктопы остаются. Поднимаю отдельный контроллер домена для Windows. Это либо Samba 4 в роли AD DC, либо реестровое решение из перечня Минцифры. ALD Pro (Группа Астра) или РЕД АДМ (РЕД СОФТ). Для Linux-инфраструктуры рядом ставлю FreeIPA и устанавливаю между ними доверие (cross-forest trust через ipa-adtrust-install). Windows ходит в свой AD DC, Linux во FreeIPA, доверие связывает оба мира.
• Windows-десктопы уходят. Тогда отдельный AD DC не нужен. Весь парк переезжает на Linux-АРМ и сажается на FreeIPA или на отечественную доменную службу по Kerberos и LDAP. Это чище, но требует одновременной замены десктопов, а это отдельный большой кусок программы.

Для импортозамещения логичнее смотреть в сторону реестровых ALD Pro и РЕД АДМ как замены AD. Они спроектированы под привычную доменную модель и снимают вопрос о том, кто будет вводить Windows-машины в домен. FreeIPA в этой схеме остаётся каталогом для Linux, а не «заменой AD на всё».

Миграция учёток, групп и политик

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

Болезненнее идут групповые политики. В AD их обычно набирается несколько десятков. Пароли, заставки, отключение USB, настройки браузера, сетевые диски. В мире FreeIPA или Linux-АРМ привычных GPO в том же виде нет, и я переписываю политики как набор конфигурационных ролей (ansible), которые применяются при загрузке станции и при входе пользователя. Полезный побочный эффект в том, что по ходу разбора обычно выясняется, что заметная часть политик это легаси многолетней давности, которое давно не актуально. В новую систему оно просто не переезжает.

Единый вход для веб-приложений

Сквозной вход (SSO) к веб-приложениям (Nextcloud, корпоративный портал, веб-интерфейсы учётных систем) я делаю не средствами каталога, а отдельным сервисом. Разворачиваю Keycloak отдельно и федерирую его с каталогом (FreeIPA или AD) по LDAP и Kerberos. Приложения подключаю уже к Keycloak по SAML или OIDC. Важная поправка к частому заблуждению. Keycloak не входит во FreeIPA и не поднимается «из коробки» вместе с ним, это самостоятельный продукт. FreeIPA умеет работать с внешним поставщиком идентификации начиная с версии 4.10, но сам ролью SAML-IdP для произвольных веб-приложений не выступает.

Результат для пользователя простой. Один вход утром на рабочей станции, и дальше веб-приложения открываются без повторного ввода пароля. На старом MS-стеке такого сквозного входа обычно не было. Частичный через Outlook и SharePoint, а остальные системы требовали отдельных логинов. Это то улучшение, которое программа замещения даёт бонусом.

Офисный пакет и макросы VBA

Microsoft Office меняю на отечественный офисный пакет. Главная боль здесь предсказуема. Макросы VBA в финансовых таблицах.

Выбор офисного пакета

Реальный выбор для российской компании сегодня идёт между Р7-Офис и OnlyOffice. Оба построены на одном ядре document server, поэтому сравниваю их по нюансам, а не по принципиальной разнице. На десктопную массу обычно ставлю Р7-Офис (правообладатель АО «Р7»). OnlyOffice в варианте DocSpace беру там, где во главе угла совместная работа над одним документом с расширенными правами, например для проектного офиса. Выбор подтверждаю на тестовой выборке реальных файлов заказчика. Открываю десятки типовых таблиц с условным форматированием и смотрю, где меньше расхождений в отображении.

Макросы VBA

Здесь обычно и прячется главный сюрприз этапа. У финансового отдела всегда находится 10–15рабочих таблиц с макросами (порядок величин). Это автозаполнение, агрегация данных из 1С, выгрузка в нужные форматы. Часть написана много лет назад уволившимся сотрудником и нигде не задокументирована.

Отечественные офисные пакеты макросы поддерживают, но в собственной модели. Не VBA, а совместимый движок с похожим API. Автоматического переноса нет. Каждый макрос, это ручной разбор и переписывание под новый интерфейс.

По опыту итог разбора раскладывается примерно так. Большую часть макросов удаётся переписать один в один. Несколько переписываю с сознательной потерей функциональности, отказавшись от выгрузок в форматы, которые и так перестали быть нужны. И почти всегда остаётся один-два самых упрямых макроса, завязанных на специфичную COM-функцию Excel. Их держу на одном изолированном рабочем месте с Windows и Excel как переходное решение, пока задачу не удаётся разобрать иначе. Это нормальный хвост, а не провал.

Обучение пользователей

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

CAD, самый болезненный этап

Autodesk меняю на nanoCAD и Компас. Это самый болезненный этап из всех. Инженеры держатся за привычный инструмент до последнего, и это не каприз, а реальная стоимость переучивания.

Контекст

Конструкторский отдел, это десятки рабочих мест и архив документации за много лет. Тысячи активных чертежей в форматах dwg, ipt, iam, idw, плюс система версионирования (Vault). Архив, это главный груз этапа. Его нельзя потерять и нельзя «слегка переколбасить» при переносе.

Что выбираю и почему

nanoCAD беру как замену AutoCAD. Он читает dwg в нативе и держит базовый набор команд. Компас-График и Компас-3D как замену Inventor. Это полноценная отечественная САПР с модулем сборок и встроенным PDM вместо Vault. Альтернативы вроде T-FLEX тоже смотрю на пилоте, но решение принимаю по двум критериям. Качество чтения dwg-архива и то, насколько быстро адаптируются сами инженеры. Голос инженеров здесь весит больше моего.

Сопротивление и пилот

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

Рабочий подход, это пилот с одним инженером. Беру того, у кого ещё нет многолетнего рефлекса на горячие клавиши AutoCAD, даю ему освоиться без давления по срокам и дожидаюсь честного «нормально, можно работать». Дальше делаю его наставником для следующих, и обучение идёт каскадом. Это медленнее по графику, чем групповой пилот, но именно это доводит отдел до результата без бунта.

Перенос архива

Подавляющее большинство чертежей открывается в nanoCAD без потери информации. Проблемными оказываются сборки со специфичными блоками от плагинов AutoCAD. Их переразбираю в новых форматах вручную, и это отдельная строка в плане по времени. Ключевые сборки пересобираю в Компасе, остальной архив держу в режиме чтения dwg и ipt для справки. Полную конвертацию всего архива в новый формат не делаю. Это лишняя работа, читать старое можно и так.

1С. Меняем окружение, не саму 1С

1С обычно уже стоит. Управление торговлей, Бухгалтерия, ЗУП на платформе 8.3. Сама 1С по определению отечественная, менять её не нужно. Замещение касается окружения. Это MS SQL Server под ней и Windows-терминальный доступ.

MS SQL → Postgres Pro

Платформа 1С 8.3 официально поддерживает Postgres Pro Enterprise для 1С. Это сертифицированная сборка PostgreSQL от компании «Постгрес Профессиональный». Миграцию базы делаю штатной выгрузкой и загрузкой на новую СУБД. Основной риск тут не в самом переносе, а в производительности тяжёлых отчётов. Часть отчётов, годами оттюнингованных под MS SQL, после переноса работает заметно медленнее. Лечится индексами и материализованными представлениями на стороне PostgreSQL плюс оптимизацией нескольких запросов на стороне 1С. На эту доработку закладываю время после основного окна. Не считаю миграцию законченной в момент переключения.

Windows RDS → терминальный доступ на Linux

Здесь скажу честно. Одобренного решения «из коробки» уровня Windows RDS в отечественном ландшафте нет, и это болевая точка. Варианты, которые рассматриваю, это терминальный доступ через x2go на Linux-сервере либо проприетарные VDI-решения из реестра (например, Termidesk). Выбор зависит от каналов связи и бюджета.

Главный нюанс, это поведение на узких каналах. В локальной сети производительность близка к MS RDS. На удалённых офисах с узкими каналами графическая отзывчивость заметно проседает. Для работы с 1С это терпимо, там не нужна высокая частота кадров. Поэтому сценарии разделяю. 1С идёт через терминальный сервер, а видеоконференции и графику отдаю на локальные клиенты с прямым доступом, не через ту же терминальную сессию.

Резерв и мониторинг под новый стек

Резервное копирование

Отдельно про бэкап, потому что здесь легко оставить мину. На старом ландшафте резервное копирование часто ведёт Veeam. Veeam ушёл из РФ в 2022 году, поддержки и обновлений нет, лицензии под риском отзыва. Оставлять санкционно-зависимый продукт в основе бэкапа в программе, вся цель которой есть независимость от таких вендоров, это прямое самопротиворечие. Поэтому бэкап включаю в периметр замещения и перевожу на отечественные решения из реестра. Кибер Бэкап (Киберпротект) или RuBackup. Если по срокам Veeam какое-то время доживает по инерции, держу его в плане как осознанный временный компромисс с явной датой замены, а не как постоянное решение.

Содержимое бэкапов после программы меняется. Вместо образов Windows-серверов и дампов MS SQL приходят образы Linux-серверов, дампы PostgreSQL и снимки ZFS-разделов с почтой и файлами. Схему 3-2-1 сохраняю. Основная копия на отдельной СХД на площадке, вторая в удалённом офисе, третья в облаке российского провайдера с шифрованием на стороне клиента. Тестовое восстановление раз в квартал на отдельный узел. Это та часть программы, которую совет не видит, но без которой я не считаю программу завершённой.

Мониторинг и алертинг

Смешанный мониторинг старого ландшафта (часть на средствах Microsoft, часть на Zabbix) после замены свожу к единому открытому стеку. Prometheus для метрик, Loki для логов, Grafana для дашбордов, Alertmanager для оповещений. Алерты направляю в корпоративный мессенджер (его обычно внедряю заодно как замену Teams) и на дежурный канал. Покрываю метриками все этапы. Почту (очередь Postfix, доля спама), файлы (сессии, состояние хранилища), каталог (аутентификации, репликация), PostgreSQL (подключения, задержки, размер базы), терминальный доступ (сессии, загрузка). На дашборде держу одну страницу «общее состояние», по которой утром за полминуты видно, всё ли в порядке.

Экономика. Куда уходят деньги

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

Лицензионная часть после замещения резко падает. Почтовый стек, это open source, по сути бесплатен в лицензиях. Платными остаются подписки на поддержку Nextcloud, отечественный офисный пакет (Р7-Офис или OnlyOffice), отечественная САПР (nanoCAD и Компас) и сертифицированная Postgres Pro под 1С. В сумме это в разы меньше, чем платежи Microsoft и Autodesk до программы.

Поэтому окупаемость даю не одной цифрой, а вилкой. На проектах подобного масштаба разовые затраты на программу (команда внедрения, внешние консультанты по специфичным компонентам, новое серверное железо, обучение, резерв на откаты) окупаются экономией на лицензиях за 18–30 месяцев. Где в этой вилке окажется конкретный проект, решает в первую очередь то, насколько вырастет нагрузка на эксплуатацию. Чем больше открытых компонентов и чем слабее исходный ИТ-штат, тем ближе к верхней границе.

Ещё одна оговорка, без которой расчёт нечестен. Baseline лицензий частично теоретический. Autodesk и Microsoft напрямую в РФ продлевать нельзя, поэтому «экономия» считается от суммы, которую заказчик платил бы, будь продление доступно. Это корректная управленческая логика (мы снимаем будущий риск и будущие платежи), но подавать её как «сэкономили живые деньги в этом году» уже передёргивание. В разговоре с советом я разделяю эти две вещи явно.

Резерв в бюджете

Резерв на откаты и удлинения закладываю не 10%, а 15–20%. Десяти процентов на программе такого масштаба обычно не хватает. Типовой перерасход съедают как раз файловый этап (перенос прав) и CAD (сопротивление и сроки). Запас в 15–20% даёт подушку под эти предсказуемые риски и снимает лишние разговоры с советом про дополнительный CAPEX по ходу.

Где программа обычно спотыкается

Идеальных программ замещения не бывает. Помимо двух главных мест (перенос прав на файловом этапе и сопротивление на CAD), есть типовые хвосты, которые честнее признавать заранее.

Один-два макроса, которые не переехали

Почти всегда остаётся пара VBA-макросов, завязанных на специфичные COM-функции Excel, которые не переносятся в отечественный пакет. Они доживают на изолированном Windows-месте до момента, когда задачу удаётся решить иначе. По деньгам это копейки (одна оставшаяся лицензия), по принципу это недопереход, который держу на контроле, а не списываю.

Терминальный доступ на узких каналах

На удалённых офисах с узкими каналами пользователи дольше всего жалуются на медленность 1С через терминал по сравнению с прежним Windows RDS. Это особенность терминальных протоколов на узкой полосе, и универсального решения у меня нет. Лечу разделением сценариев и точечной настройкой под конкретный канал. Честно держу это в списке открытых задач.

Когнитивный переход дольше технического

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

Про 187-ФЗ КИИ, почему программа шла отдельно

Меня регулярно спрашивают, делаю ли я замещение по требованию 187-ФЗ. Чаще всего нет. Рыночно-мотивированное замещение и замещение по требованию закона о критической информационной инфраструктуре, это две разные программы, и я их не смешиваю.

187-ФЗ касается организаций, признанных субъектами КИИ. Если компания попадает под закон, у неё категорированы объекты КИИ, есть взаимодействие с ФСТЭК и план перехода на доверенные решения. Это отдельный регуляторный путь со специальными требованиями к сертификации каждого компонента.

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

Если компания под 187-ФЗ всё-таки подпадает, программа строится иначе. Сертификация каждой замены через реестры, длинные согласования, участие профильного аудитора. По опыту это удлиняет сроки и добавляет к бюджету заметную долю на работы по сертификации. Порядок прибавки на таких программах исчисляется десятками процентов. Поэтому регуляторное замещение я веду отдельной программой, а не в одном плане с рыночным.

Принципы, которые держу всегда

Пилот по CAD запускаю рано

CAD, это самый длинный этап, и его нельзя оставлять на середину программы. Пилот с одним молодым инженером на nanoCAD я запускаю в первые же недели, параллельно с действующей AutoCAD-лицензией. К моменту реальной миграции через много месяцев у меня уже есть готовый внутренний наставник и обкатанная процедура переноса архива. Это срезает недели с самого нервного этапа.

Пилоты только один-к-одному

Для любой потенциально болезненной замены сначала беру один пилотный пользователь до состояния «работает без потери производительности», и только потом масштабирование с этим пользователем как наставником. Групповой пилот по определению порождает коллективное сопротивление. Это правило применяю на любом болезненном этапе, а не приберегаю для CAD.

Граф зависимостей в первые недели

Полный граф «кто на что опирается» строю на этапе планирования, а не по ходу. Именно он показывает заранее, что права SharePoint завязаны на site collections, а не на плоских группах. Это предотвращает откат на файловом этапе. Инвентарь систем без графа зависимостей неполон.

Резерв 15–20%, а не 10%

На программах подобного масштаба десяти процентов резерва обычно не хватает. Закладываю 15–20%. Это подушка под предсказуемые риски (перенос прав, сопротивление по CAD), которая не приводит к разговорам про дополнительный CAPEX посреди программы.

Для кого эта запись

Если у вас впереди или уже идёт программа замещения MS-стека, приходите на первый разговор через форму контакта с любым артефактом. Инвентаризация систем, список хотелок, предварительный бюджет. Я разберу слабые места и покажу, где у вас будет откат через полгода, если не учесть граф зависимостей.

Если вы CIO и думаете, с какой системы начинать, начинайте с почты. Это самый дешёвый по людскому ресурсу этап с самым предсказуемым результатом. Прошла почта, пройдёт и программа. Встряли на почте, пересматривайте подход целиком.

Подробнее про методологию аудита, с которого я начинаю такие программы, читайте в записи про карту ИТ-зрелости за 4 недели. Про выбор серверной платформы под такую инфраструктуру есть запись про сравнение HPE, Dell и Lenovo в РФ 2024.