Тихая замена: как бизнесу перейти на новый софт без сбоев и остановок

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

Меня зовут Олег Жигалов, я технический директор Р7. Мы разрабатываем редакторы документов, таблиц, презентаций, почтовые решения, BI‑инструменты и другие корпоративные продукты.

В большинстве проектов мы как вендор остаемся «за кадром». Наши решения поставляют и внедряют партнеры‑интеграторы. Именно они помогают заказчикам подобрать архитектуру, установить продукты и встроить их в существующую инфраструктуру.

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

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

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

С чем обычно приходят

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

Когда к проекту подключается вендор

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

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

Как проверить, что ваша инфраструктура готова к переходу

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

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

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

Три реальных кейса

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

Сложная архитектура. Один крупный промышленный заказчик переходил на российский софт в рамках импортозамещения. В инфраструктуре использовались Kerberos и LDAP. После первых попыток внедрения начали возникать ошибки интеграции, что уже стало рискованным для важных процессов. Стало ясно, что типовые схемы тут не работают. Дальше двигаться не рискнули, пришли к нам.

Мы спроектировали кастомную отказоустойчивую архитектуру, полностью интегрированную в контур заказчика. Базу данных разместили в существующем кластере PostgreSQL. Внутренние службы (процессинг, API, registry) вынесли на выделенный кластер серверов. Поиск выделили на отдельный сервер. Перед связкой RabbitMQ и Redis развернули кластер HAProxy для балансировки нагрузки. Для хранения файлов установили два сервера документов и S3‑совместимое хранилище. Настройку Kerberos и LDAP провели совместно с IT‑службой клиента.

Удаленный поселок. Другой кейс у нас был с промышленной компанией и работой в удаленном поселке. Связь с центральным офисом шла по спутниковому каналу меньше 10 Мбит/с при этом устойчивое соединение было доступно лишь несколько часов в сутки. Даже письма между сотрудниками внутри поселка сначала уходили в крупный город на другом конце страны, а затем возвращались обратно. В результате локальная переписка занимала и без того узкий канал связи.

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

Автоматизация на Linux. Государственное учреждение переводило сотни сотрудников на российскую ОС. Основная проблема была даже не в самой установке системы, а в рутинном развертывании офисных редакторов и управлении лицензиями. Администраторы тратили часы на ручной обход и установку софта каждому сотруднику.

Мы разработали схему автоматизации, которая сняла необходимость делать все вручную. Теперь редакторы устанавливаются автоматически, лицензии выдаются без обращения в техподдержку. Время подготовки одного рабочего места сократилось с нескольких часов до 10‑15 минут.

Пять принципов для тех, кто готовится к переходу

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

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

Не ломайте существующие процессы. Лучший переход — тот, который пользователи не замечают. Интерфейсы должны оставаться привычными, как и сценарии работы. Чем меньше изменений видит сотрудник, тем быстрее он адаптируется.

Доверьте настройку безопасности своей ИТ‑службе, но привлекайте вендора для экспертизы. Компания должна сохранить контроль над данными, а вендор — помочь сделать так, чтобы этот контроль работал с новым софтом.

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

Почему масштабирование нужно закладывать сразу

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

Пример из практики. Одна из крупных авиакомпаний заключила с нами трехлетний договор с возможностью расширения. Они заложили рост в архитектуру с самого начала. Через два года, когда их бизнес вырос на 30%, им не пришлось ничего перестраивать. Просто добавили новые мощности, и система продолжила работать.

В итоге

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

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

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