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

1. Как мы жили в Docs-аду

Когда-то вся наша внутренняя документация находилась в Google Docs. Там было всё: от регламентов разработки и гайдов по DevOps до шаблонов КП и инструкций для новых сотрудников.

Первое время это казалось нормальным — быстро, удобно, привычно. Но чем больше становилась команда, тем сильнее Docs превращался в болото. Появились десятки дублей, кто-то случайно перезаписывал чужие файлы, версии терялись, ссылки переставали работать. Даже поиск не спасал — выдавал километровые списки похожих документов, и каждый раз приходилось гадать, где «та самая финальная версия».

Однажды на планёрке мы посчитали, что за неделю каждый тратит по часу-два просто на поиск нужных инструкций. И тогда стало ясно: если мы сами, будучи digital-агентством, живём на костылях из папок и чатов, — пора что-то менять. Нам нужна была реальная корпоративная база знаний, а не склад случайных файлов.

2. Попытки приручить хаос

Первый шаг был очевиден — попробовать навести порядок в самом Google Docs. Мы разбили пространство на папки по отделам, придумали цветовую маркировку, завели шаблоны для регламентов и инструкций. Казалось, теперь всё под контролем.

Но через пару месяцев стало ясно: структура есть, а порядка нет.

Например, регламент DevOps лежал в трёх местах — в общей папке «Процессы», у Dev-отдела и у конкретного инженера, который когда-то сделал «улучшенную» версию.

В PM-папке лежало два почти одинаковых чек-листа менеджера, отличавшихся на один пункт.

А гайд по Event Storming существовал в трёх форматах: часть в Word, часть в Notion, часть в голове у тимлида.

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

3. Поиск нормального решения

Мы начали искать альтернативу. Хотелось чего-то лёгкого, быстрого и self-hosted. Мы протестировали всё, что было под рукой: Notion, Confluence, GitBook, Wiki.js, DokuWiki. Каждый вариант платформы для базы знаний компании давал что-то полезное, но ни один не складывался в цельную картину.

• Notion был красивым, но облачным.

• Confluence — функциональным, но громоздким и медленным.

• GitBook отлично подходил для публичных мануалов, но не для внутренней кухни.

• DokuWiki напоминал 2007 год и пугал интерфейсом

Мы сформулировали критерии, без которых смысла нет продолжать:

1. Self-hosted: всё должно жить у нас на серверах.

2. Markdown, потому что он лёгкий, дружит с Git и не превращает текст в визуальный кошмар.

3. Поддержка тегов, шаблонов и дерева разделов.

4. Интеграция с нашим self-hosted GitLab для авторизации.

5. Нормальный поиск и API, чтобы можно было дружить с Bitrix и CI/CD.

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

4. Почему победил Outline

Когда мы дошли до Outline, всё стало на свои места. Это оказался тот редкий случай, когда продукт не кричит «я умный», а просто работает. Интерфейс минималистичный, Markdown-редактор удобный, структура коллекций и документов продумана, поиск быстрый, OAuth с GitLab подключается без боли.

Outline не пытался быть всем сразу, как Confluence, но и не упирался в простоту, как Wiki.js. Он был именно тем, что нужно digital-команде: быстрым, предсказуемым, понятным. Нам понравилось, что можно гибко разграничивать доступы между отделами, а главное — авторизация через GitLab позволяла не плодить новых логинов. Так Outline стал нашим фаворитом: «Notion для DevOps-ов», как мы его шутливо назвали.

5. Как мы его развернули

Развёртывание заняло пару часов. Мы выбрали стек Ubuntu + PostgreSQL + Redis + Docker Compose. Всё поставили через docker-сервисы, подняли Nginx-прокси с SSL, и Outline завёлся с первого раза.

Самое важное — авторизация через наш self-hosted GitLab. В GitLab мы зарегистрировали новое приложение, указали redirect-URI https://wiki.company.ru/auth/gitlab.callback, забрали Application ID и Secret, и добавили их в .env Outline. После перезапуска контейнеров на главной странице появилась кнопка “Sign in with GitLab”. Один клик — и пользователь автоматически создаётся, без регистрации и ручного администрирования.

Всё просто: если человека нет в GitLab — его нет и в базе знаний. Так мы получили единую точку управления пользователями и избавились от лишних зависимостей. Настроили бэкапы PostgreSQL через cron, вывели логи в общий стек мониторинга, и через пару дней Outline переехал из тестового стенда в прод.

6. Как мы разложили знания по полочкам

Самое сложное — не поднять сервис, а придумать структуру, в которую удобно писать. Мы решили не усложнять и пошли от логики отделов. Появились коллекции: «Общие документы», «Разработка», «QA», «PM & Account», «Маркетинг» и «Инфраструктура». В каждой — своя структура. У каждой коллекции — свой куратор, который следит за актуальностью документов.

Например, в разделе «Разработка» лежат регламенты Bitrix-проектов, DevOps и CI/CD, архитектурные стандарты и шаблоны C4-диаграмм.

QA собрал свои чек-листы, тест-кейсы и шаблоны баг-репортов.

PM и маркетинг получили собственные гайды и шаблоны КП.

Мы внедрили единый шаблон Markdown-документа: цель, область применения, процесс, инструменты, контроль и обновление. Это помогло команде писать в едином формате — не придумывая каждый раз с нуля.

7. Что мы поняли на практике

Поначалу все относились к Outline как к «ещё одному инструменту». Но постепенно стало ясно, что он реально экономит время. Мы закрепили правило: если вопрос повторяется дважды — ответ оформляется в Outline. Нашли новую инструкцию? Не кидаем в чат, а создаём страницу и кидаем ссылку.

Раз в месяц кураторы разделов проводят «док-ревью»: проверяют, что актуально, а что пора обновить. Через вебхуки Outline шлёт уведомления в Telegram, и все видят, что изменилось. Это создало прозрачность и привело к тому, что сотрудники начали доверять документации.

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

8. Что изменилось и что дальше

Через три месяца после запуска стало видно, что система работает. Количество вопросов в чатах сократилось почти вдвое. Время на онбординг новых сотрудников уменьшилось на 30–40%. Регламенты перестали теряться, а внутренние процессы стали понятнее.

Outline стал нашим вторым мозгом: лёгким, техничным и дружелюбным. Мы планируем связать его с Bitrix, чтобы автоматически подтягивать документацию к задачам, и сделать бота в Telegram, который будет искать ответы в базе знаний.

И да, теперь фраза «финальная версия_v7.docx» у нас считается плохим тоном. Потому что однажды мы выбрались из Docs-ада — и обратно уже не хочется.