Привет, Хабр! Меня зовут Денис, я руковожу технической поддержкой в одной из крупнейших компаний России. Более 16 лет я работаю в IT, а последние годы занимаюсь управлением поддержки и автоматизацией процессов.
Хочу поделиться нашим опытом перехода на новый ИТ-стек, построенный на полностью российских решениях (Astra Linux, R7 Office, TrueConf и другие), и преодоления всех сложностей. Возможно, кого-то из вас это оградит от пары седых волос и сэкономит сотни часов работы поддержки.
Это мой первый подход в написании статьи, прошу не закидывать тапками. Статья вводная, но, если вам будет интересно, я готов рассказать про каждый инструмент подробнее.
До перехода: жизнь в зоне комфорта
До перехода мы жили спокойно: поддержка обслуживала дочерние общества и площадки (а это несколько десятков тысяч пользователей), у каждого подразделения была своя локальная база знаний «в удобном формате» (читай: у кого Word, у кого Excel, а кто-то вёл в блокноте).
Все поступающие обращения были уже «обкатаны», технари хорошо знали инструменты, с которыми работали каждый день, вопросов в сторону сервис-менеджеров или от клиент-менеджеров почти не поступало.
Этакий «чил» в знакомой среде Microsoft, пользователи знали свои привычные инструменты, серьёзных обращений было мало. Техническая поддержка чувствовала себя уверенно и комфортно.
Переход и страх нового
В компании давно появилось понимание, что многое офисное ПО устарело (что, например, подтвердил Microsoft, закрыв Skype). Наш ИТ-кластер заранее готовился к масштабному переходу, и мы понимали, что впереди — новый этап.
Ожидания были примерно такие:
Во время перехода на отечественный стек чем больше нового ПО появлялось в периметре компании, тем большее количество вызовов нам пришлось принимать. Мы столкнулись с новой реальностью.
Во-первых, вырос поток обращений. Пользователи, которые годами работали в привычной среде, внезапно потеряли кнопку «Пуск» там, где она была всегда. Outlook стал R7 Office, Skype — TrueConf, Windows превратился в Astra Linux.
Большинство инцидентов возникало не из-за отсутствия функционала, а из-за того, что привычные элементы интерфейса переехали. В результате:
лавина инцидентов;
перегруз первой и второй линии;
поиски решений в интернете «на коленке»;
дублирование и противоречивые знания.
В пике среднее время решения (AHT) увеличилось в два раза. Пользователи были недовольны, поддержка — на грани выгорания.
AHT (Average Handle Time, среднее время обработки обращений) — ключевой показатель эффективности технической поддержки.
Нужно было срочно что-то менять внедрять.
Единая база знаний
Первое, что мы сделали — создали единую базу знаний. В ней появились роли:
пользователь (ищет, предлагает новые статьи);
модератор (фильтрует и проверяет);
эксперт (подтверждает правильность решения).
Так мы ввели цикл жизни знаний: от предложения до публикации и обновления. Постепенно база разрослась с Astra Linux на все продукты — R7 Office, TrueConf и другие. Это стало нашим «единым окном истины».
Про то, как внедряли и использовали единую базу знаний, могу подробнее рассказать в отдельном посте – оставьте комментарий, если это будет вам интересно.
Обходные решения и третья линия
Повторяющиеся инциденты мы фиксировали и снабжали обходными решениями. Если вендор ещё не выпустил патч, мы публиковали временный «костыль» (да, мы их не любим, но иногда без них никак).
Чтобы систематизировать этот процесс, мы выделили третью линию поддержки, которая занимается нестандартными кейсами, общается с вендорами и центрами компетенций. Произошел так называемый «сдвиг влево» – загрузка линий поддержки начала выравниваться.
Интеграция с ITSM
Вроде очевидная история, но все же расскажу: мы связали базу знаний с ITSM. Теперь обходные решения автоматически подтягиваются в карточки инцидентов, а сами инциденты и проблемы связаны с расчётно-технологическими картами. Такой подход дал нам возможность:
оценивать стоимость работ и трудозатраты;
ранжировать важность проблем и решений;
правильно расставлять приоритеты для автоматизации.
Отдельный бонус: стало ясно, где проблемы возникают из-за самой системы, а где — из-за нашей очень строгой информационной безопасности (иногда складывалось впечатление, что ИБ — это «наш главный вендор багов»).
На сегодняшний день мы прораннжировали все новые (Linux) операции технической поддержки и создали несколько инструментов (Astra Fix, Astra Pulse и другие), которые позволили сократить суммарно трудозатраты на одно обращение на 84,5%.
Мы разработали Astra Fix и Astra Pulse самостоятельно, как внутренние решения для автоматизации. Это не официальные продукты ГК «Астра», а наши собственные технологии для повышения эффективности. Об этом также могу рассказать в отдельных статьях, если будет интересно.
Эффект
В конце 2023 года стало ясно, что поддержка работает на пределе: среднее время решения выросло на 7%. В большой компании изменения не происходят мгновенно — но процесс был запущен. К середине 2025 года среднее время снизилось на 23% по сравнению с концом 2024-го. Это подтверждает, что направление мы выбрали правильно – положительная динамика продолжается и сейчас.
Для поддержки:
AHT начал приходить в норму;
нагрузка между линиями распределилась;
эксперты перестали тушить «точечные пожары» и занялись устранением корневых причин.
Для бизнеса:
стабилизировали ситуацию с обращениями;
сократили трудозатраты, оптимизировали расходы;
высвободили время высококвалифицированных специалистов.
Для пользователей:
метрики удовлетворённости в третьем квартале 2025 начали расти после резкого падения;
обращения стали решаться быстрее;
постепенно ушёл негатив и страх перед отечественными продуктами.
Советы тем, кто только готовится к переходу
Если бы я мог дать три совета коллегам из других компаний, они были бы такими.
Сразу стройте единую базу знаний. Это должна быть точка истины, иначе потонете в разрозненных решениях.
Закладывайте приоритизацию автоматизации. Считайте трудозатраты, ведите статистику и автоматизируйте то, что «жжёт» чаще всего.
Инвестируйте в обучение пользователей. Сценарии «до → после» работают лучше всего. Люди не любят новое, и это нормально — задача поддержки сделать переход максимально безболезненным.
Вместо заключения
«Two men looked out from prison bars, One saw the mud, the other saw stars» («Двое смотрели из тюремной решетки, Один видел грязь, другой видел звезды»), – Дейл Карнеги, «Как перестать беспокоиться и начать жить».
Переход на новые технологии и ПО — это всегда вызов. Но еще это возможность перестроить процессы поддержки так, чтобы они стали эффективнее.
Мы прошли через период адаптации, создали единую базу знаний, наладили интеграцию с ITSM, выстроили приоритеты и распределили нагрузку. В итоге поддержка стала работать быстре�� и дешевле, а пользователи стали довольнее.
Если вы только планируете переход — помните: начальный этап будет непростым. Но новые технологии, несмотря на свою непривычность и необходимость доработки, открывают реальные преимущества. Главное — вовлекать пользователей, учитывать их обратную связь и постепенно адаптировать решения под реальные потребности. Это путь, который того стоит.
Пишите в комментариях, как у вас проходили подобные переходы и какие уроки вы вынесли из них. Буду рад обменяться опытом.