Привет, Хабр! Уверен, у вас тоже такое бывало: сидишь в проде, сервис падает, а нужного ответа нет ни в Confluence, ни в старых чатах. В итоге бесконечный скролл в Telegram, повторы вопросов в почте и потерянные часы на поиски того, что кто-то уже когда-то решал. Мы уперлись в эту проблему лбом и поняли, что нужен инструмент, который аккумулирует знания и делает их доступными.
Меня зовут Денис Селюков, я техлид разработки внутреннего Q&A‑портала МТС DevTools Stack. С помощью этого продукта мы упорядочили накопление знаний, и я покажу, что дает такая относительно простая механика и как ее можно прокачать с помощью ИИ-инструментов.
Как в МТС появилась идея создать внутренний Stack Overflow
Повседневная работа команд показала системную проблему: внутри компании используется множество собственных решений и найти по ним информацию в открытых источниках невозможно. В итоге одни и те же вопросы кочевали из чатов в Telegram и рассылки на почту: как подключить API, почему упал сервис в проде, какой способ миграции данных выбрать. Ответы терялись, обсуждения дублировались, а время специалистов расходовалось впустую.
Ситуация обострилась к концу 2024 года, когда в МТС появилось несколько новых внутренних платформ. Знания перестали накапливаться централизованно и оставались в головах отдельных экспертов.
Центр компетенций разработки зафиксировал проблему и предложил очевидное решение — создать внутренний аналог Stack Overflow. Публичный опыт этой платформы показал эффективность Q&A-формата, а опрос среди 500+ сотрудников подтвердил потребность: 80% поддержали идею. Так стартовал проект под кодовым названием DevTools Stack, призванный превратить разрозненные знания в живую базу коллективного опыта.
Почему выбрали именно Q&A
Когда мы обсуждали формат будущего инструмента, у нас было несколько вариантов: Confluence как wiki, база знаний на SharePoint, чат-бот в Telegram. Но все они быстро отвалились по ряду причин.
Wiki и базы знаний
Да, Confluence и SharePoint привычны, но у них есть фундаментальный минус. Они статичны. Кто-то написал статью, через месяц она устарела, а через полгода уже вводит в заблуждение. Обновлять такие материалы некому, и в итоге база превращается в кладбище артефактов. Поиск в wiki тоже слабый: приходится копаться в иерархии страниц, а релевантность результатов оставляет желать лучшего.
Чат-боты
Мы рассматривали вариант с ботами, но поняли, что для нас это скорее костыль. Бот может помочь найти ссылку или подсказать FAQ, но полноценного обсуждения и накопления знаний там не получится. История теряется, вопросы дублируются, а структурировать все это невозможно.
Q&A-портал
Формат вопросов и ответов оказался для нас оптимальным:
Интерактивность. Можно задать вопрос, получить несколько вариантов ответа, проголосовать за лучший и закрыть тему как решенную. Это живой процесс, а не статичная документация.
Поиск и релевантность. Теги, рейтинги и связанные вопросы делают поиск быстрым и точным. Не нужно копаться в древе страниц — достаточно ввести ключевые слова.
Геймификация. Репутация, бейджи, лидерборды. Эти механики реально работают: инженеры охотнее делятся знаниями, когда видят, что их вклад ценится.
Масштабируемость. В компании с тысячами сотрудников wiki быстро превращается в хаос. Q&A же самоорганизуется за счет модерации и голосования сообщества.
В итоге мы остановились именно на этом варианте.
Архитектура: что под капотом и почему так
Когда мы оценивали варианты, нам стало ясно, что писать собственный движок с нуля дорого и долго. Вместо этого выбрали Discourse — популярное open‑source-решение, которое изначально поддерживает Q&A‑формат: категории, теги, голосование, модерацию. Это позволило быстро запуститься, а усилия направить не на базовую разработку, а на кастомизацию под корпоративные задачи. Плюс у Discourse активное сообщество и экосистема плагинов, что дает гибкость и экономит месяцы работы.
Основные компоненты:
Backend. Ruby on Rails как основа Discourse. Мы не переписывали бизнес‑логику, а расширяли ее через плагины и хуки.
Базы данных. PostgreSQL — основная реляционная БД (посты, пользователи, метаданные). Redis — кеш, сессии, очереди задач. Асинхронка — Sidekiq для jobs.
Frontend. Ember.js (нативный для Discourse) + HTML/CSS/JS. Мы добавили кастомные темы и компоненты для корпоративного брендинга МТС.
Развертывание и инфраструктура. Docker для контейнеризации, Kubernetes для оркестрации и autoscaling. Все развернуто во внутренней облачной платформе МТС с CI/CD через GitLab.
UI и функциональность:
Главная страница. Содержит категории и топики, поиск, фильтры по новизне/популярности, иконки уведомлений / профиля / поиска в шапке. Можно настроить категории как карточки или списки. Подкатегории и описания управляются через админку.
Топики и посты. Цепочки с поддержкой markdown — текст, изображения, код, эмодзи. Действия: ответы, лайки, закладки, редактирование, цитирование. Плагины: Spoiler Alert (спойлеры), Footnote (сноски), AI Bot (ИИ-ответы).
Профиль пользователя. Аватар, био, статистика (посты, лайки), нотификации. SSO: OIDC с интеграцией в Active Directory.
Админ-панель. Отдельный дашборд для модераторов — аналитика, настройки плагинов, автоматизация через Discourse Automation.
Брендинг и перформанс. Цвета/логотипы/темы под МТС, быстрая отдача за счет Redis-кеша и кластера Kubernetes.
Если коротко: берем зрелый движок, адаптируем под наши процессы, добавляем нужные для корпоративного использования плагины, упираемся в стабильность и скорость. Дальше — интеграции и ИИ-часть.
Технологии и фреймворки
Чтобы портал работал надежно и масштабируемо, мы собрали архитектуру из проверенных компонентов и расширили ее плагинами — как для базовой функциональности, так и для интеграции ИИ.
Аутентификация
Для безопасного доступа только сотрудников МТС подключили плагин OpenID Connect. Он обеспечивает бесшовную авторизацию через корпоративный Active Directory (SSO), без лишних логинов и паролей.
ИИ-компонент
Плагин AI for Discourse — ключевой элемент, который делает форум «умным». Мы кастомизировали его под внутренние задачи:
бот предлагает ответы на вопросы;
проверяет их релевантность;
генерирует черновики. Плагин интегрирован с внутренними моделями MWS GPT, которые общаются через API, совместимые с OpenAI. Вся логика построена на вебхуках Discourse, что позволяет гибко управлять обработкой вопросов.
Дополнительные плагины:
Discourse Footnote — для сносок и технических пояснений в постах;
Discourse Automation — автоматизация задач: уведомления, модерация, правила;
Discourse Spoiler Alert — скрытие деталей в ответах, удобно для длинных логов и конфигураций.
Инфраструктурные технологии:
Kibana — логирование;
Prometheus + Grafana — мониторинг метрик;
OpenSearch — продвинутый полнотекстовый поиск с поддержкой синонимов и автодополнения;
HTTPS — с корпоративными сертификатами и встроенной защитой от спама.
Такой стек дал нам гибкость и скорость. Достаточно быстро мы получили готовую платформу, адаптированную под внутренние процессы. Сейчас система стабильно обрабатывает тысячи запросов в день без простоев и перегрузок.
Интеграции с внутренними системами
Интеграция с корпоративным таск-менеджером пока на этапе анализа. Эта одна из ключевых систем в компании: у нее высокая нагрузка и критичность для процессов, поэтому любые связки с ней требуют особой осторожности. Мы рассматриваем сценарии, где вопрос из Stack может автоматически превращаться в задачу, и наоборот.
А вот Telegram-бот уже работает в проде. Он подключен к корпоративным чатам и анализирует сообщения в реальном времени. Если в чате появляется технический вопрос, то бот пытается найти на него ответ сначала в МТС Stack, затем в оригинальном Stack Overflow и, при необходимости, через внутренние LLM-модели.
Если ответ найден, то бот просто кидает ссылку в чат. Если нет — он создает вопрос в МТС Stack через API. Как только кто-то из сообщества отвечает, бот дублирует ответ обратно в Telegram.
Благодаря плагину AI for Discourse в работу включаются и внутренние модели платформы MWS GPT. Они занимаются вопросами без ответа и генерируют варианты решений. Качество таких ответов мы продолжаем улучшать, но даже текущий уровень сотрудники оценивают как полезный.
В результате бот закрывает около 20% типовых вопросов. Это освобождает экспертов и ускоряет коммуникацию.
Как мы решаем проблему качества и релевантности ответов
Чтобы избежать мусорных вопросов и неразборчивых ответов, мы выстроили несколько уровней контроля.
Модерация
Пользователи голосуют за ответы, а участники с высокой репутацией могут редактировать чужие посты. Это помогает быстро поднимать качественные решения наверх. Плюс работает автоматическая модерация: ML-модели отслеживают спам, дубликаты и токсичные формулировки.
ИИ-помощь
Перед публикацией ИИ предлагает улучшения. Например, добавить код-сниппет или уточнить формулировку. Он же проверяет релевантность вопроса, чтобы избежать повторов и нецелевых тем.
Рейтинг и теги
Каждый вопрос получает теги (например, #java, #devops), а поиск ранжирует результаты по релевантности. Закрытые вопросы архивируются, но остаются доступными. Это важно для повторного использования решений.
Поиск на OpenSearch
Мы развернули собственный кластер OpenSearch, форк Elasticsearch, и интегрировали его с МТС Stack. Это дало продвинутый полнотекстовый поиск с поддержкой синонимов, автодополнения и ранжирования по контексту. По сравнению с базовым поиском на PostgreSQL это другой уровень.
Как изменились процессы: что с метриками и мотивацией
80% вопросов получают релевантные ответы в первые 24 часа. Причем сюда входят не только новые вопросы, но и те, что были найдены через поиск, — без необходимости задавать их заново.
После запуска внутреннего Stack и Telegram-бота процессы внутри МТС заметно ускорились. Новички стали находить ответы в два раза быстрее, так что онбординг сократился до пары дней. Команды начали делиться лучшими практиками, и это снизило время разрешения инцидентов на 40%. Вместо «спроси у Петрова» — поиск по Q&A. Это разгрузило экспертов и усилило культуру обмена знаниями.
Чтобы понимать, как портал работает, мы отслеживаем базовые метрики:
скорость ответа (цель — <4 часа до первого, <24 до принятого);
количество закрытых вопросов (~500 в месяц, 85% с решением);
вовлеченность (DAU/MAU, активность, проникновение по командам).
В планах — перейти к более продвинутым метрикам вроде Lead Time Development, чтобы связать знания с реальной скоростью изменений.
Мотивация сотрудников строится на трех уровнях:
геймификация (бейджи, лидерборды, достижения, мерч);
интеграция в перформанс-ревью;
обучение и промо (от вебинаров до конкурсов «Вопрос недели»).
Регулярный фидбэк помогает нам адаптировать портал под реальные сценарии и это работает: вовлеченность растет, а знания становятся доступнее.
Как Front Platform использует МТС Stack
Одними из первых, кто начал активно использовать внутренний Q&A-портал, стали команды Front Platform. У них был корпоративный продукт, с которым работали разные подразделения, и при интеграции возникало множество вопросов: как подключиться, где взять логи, что делать при ошибке.
Сначала все обсуждали в Telegram-чате, но быстро стало понятно, что это неудобно. Ветка обсуждений терялась среди сообщений, не было структуры, невозможно было понять, решен ли вопрос. История исчезала, а повторные вопросы множились.
Решение пришло от одного из разработчиков — перенести коммуникацию в МТС Stack. И это сработало:
каждый вопрос стал отдельной веткой с полной историей;
можно закрыть тикет и отправить его в архив;
шаблоны помогают структурировать запросы (например, стенд, версия, логи);
поиск по всем тикетам позволяет быстро находить уже решенные кейсы;
корпоративная авторизация сохраняет конфиденциальность;
подкатегории баги, идеи, вопросы упрощают навигацию.
В итоге Front Platform построили удобную точку входа для всех, кто работает с их продуктом.
Что дальше: развитие МТС Stack
Расширение — ключевая задача. Мы активно привлекаем новые команды, особенно те, кто разрабатывает внутренние продукты, не описанные в открытых источниках. Часто даже закрытая документация не актуализируется — и Stack становится единственным живым пространством, где можно быстро получить ответ.
Важно не только охватить больше команд, но и вовлечь разные инженерные роли: от разработчиков, для которых Stack уже стал основным инструментом, до владельцев продуктов, которые могут использовать портал как площадку для поддержки и обратной связи.
В ближайших планах — несколько крупных улучшений:
Интеграция с внутренней продуктовой платформой, чтобы автоматически создавать пространства для каждого продукта и упростить коммуникацию между техлидами, владельцами и пользователями.
SLA и дайджесты. Появится система SLA для вопросов и настраиваемый дайджест незакрытых тем. Это поможет модераторам быстрее реагировать и закрывать «висящие» вопросы.
Кастомный RAG-сервис. Мы разрабатываем компонент, который объединяет генеративные модели (MWS GPT) с поиском по базе знаний. Прежде чем сгенерировать ответ, ИИ извлекает релевантные данные из Jira и Confluence, чтобы дать точный и контекстный результат.
Автоматическая архивация. Сейчас вопросы архивируются вручную. Мы хотим автоматизировать этот процесс, учитывая структуру категорий, чтобы закрытые темы не терялись, а оставались доступны через поиск.