Mayan EDMS: сервер стоит копейки, дорого обходится всё вокруг него

MAATRIX

«Поставим Mayan EDMS на недорогой VPS — и документооборот компании закрыт бесплатно» — фраза логичная на этапе, когда в системе ещё нет ни одного реального документа. Mayan EDMS действительно open-source и не требует мощного железа под саму платформу. Но система документооборота — не файл на диске, а процесс: сканы, распознавание текста, согласования, права доступа и живые люди, которые вчера носили бумаги на подпись лично, а сегодня должны нажимать кнопки в незнакомом интерфейсе. Разберём честно, во что реально обходится Mayan EDMS, если считать не только счёт за сервер.

Что такое Mayan EDMS и почему сервер — не всё

Mayan EDMS — открытая система управления документами на Django: хранение файлов с версионированием, метаданные, теги, «шкафы» (cabinets) как ручные папки, автоматические индексы, которые строят виртуальные деревья каталогов по значениям метаданных, workflow-движок для согласования и подробная система прав доступа (ACL) на уровне отдельного документа. Официально рекомендованный способ развёртывания — Docker: комплект контейнеров поднимает сам Mayan, PostgreSQL как основную базу и Redis, который здесь играет двойную роль — кеш и брокер очереди задач для Celery.

Именно Celery — деталь, которую расчёт «сервер за пару долларов» обычно не учитывает. OCR, генерация превью страниц, построение индексов, уведомления, автоматические переходы workflow — всё это не происходит синхронно с загрузкой файла, а уходит в очередь и обрабатывается фоновыми воркерами: пользователь, загрузивший скан, не ждёт, пока сервер распознает текст. Но это значит, что «сервер под Mayan EDMS» — это минимум четыре взаимодействующих сервиса (веб-приложение, PostgreSQL, Redis, воркеры Celery), и то, насколько бодро система работает под нагрузкой, определяется ресурсами воркеров, а не веб-интерфейса.

Цена самого VPS в этой конструкции правда невысока — небольшой офис с умеренным потоком документов не грузит CPU и память так, как видеоконференция или ML-модель. Но это единственная строка расхода, которую честно отражает счёт за аренду. Дальше — то, что в него не входит.

OCR: распознавание текста — процесс, а не галочка

Типичный сценарий — сканирование бумажного документа, загрузка (или сканирование сразу в источник, из которого Mayan его подхватывает) и распознавание текста, чтобы документ впоследствии находился полнотекстовым поиском, а не только по вручную проставленным тегам. Технически OCR подключается через Tesseract с языковыми пакетами, которые ставятся в окружение отдельно от самого Mayan:

apt-get install tesseract-ocr-rus tesseract-ocr-eng

На бумаге — одна команда. На практике здесь начинается реальная работа:

• качество скана определяет качество OCR больше, чем настройки Tesseract. Скан под углом, с тенью от переплёта, ниже разумного DPI — распознавание либо не сработает, либо даст текст с таким числом ошибок, что поиск по нему бесполезен. Стандарт сканирования стоит навести до включения OCR, а не после;
• многоязычные архивы требуют явного выбора языка на документ или тип документа, а не одного глобального языка на всю систему — иначе документы на неуказанном языке распознаются мусором;
• OCR грузит CPU воркера, а не веб-сервер. При заливке архива из тысяч страниц одномоментно очередь Celery выстраивается в цепочку, и «документ загружен, а текст не находится ещё полчаса» — не баг, а следствие того, сколько воркеров реально выделено под обработку;
• не всё одинаково хорошо распознаётся. У родного PDF с текстовым слоем OCR фактически не нужен. А вот фото документа с телефона и сканы низкого качества стоит заранее проверить на выборке ваших же документов, а не полагаться на общие ожидания от Tesseract;
• повторный OCR документов, загруженных до исправления настроек сканирования или до включения нужного языка, — отдельная ручная задача по всему архиву, если решение о конфигурации принято после массовой загрузки, а не до.

OCR в Mayan EDMS не включается один раз кнопкой — это процесс, который стоит спроектировать заранее: стандарт сканирования, языковые пакеты, ресурсы под воркеров. Переделка после того, как в системе тысяча плохо распознанных документов, стоит заметно дороже.

Workflow согласования: сложность не в коде, а в процессе

Workflow-движок технически прост: описываете состояния документа («Черновик» → «На согласовании» → «Утверждено» / «Отклонено») и переходы между ними, каждый переход ограничивается правами — кто может перевести документ дальше — и привязывается к действию: уведомление, смена метаданных, запуск другого процесса. Нарисовать схему в интерфейсе — час работы.

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

• нужен ли параллельный этап согласования (юрист и финансист смотрят документ одновременно) или только последовательный — движок Mayan EDMS моделирует линейные переходы, и разветвлённую логику приходится собирать через дополнительные состояния, а не получать из коробки;
• что происходит, если согласующий в отпуске — есть ли делегирование прав на переход, или документ «зависает» до его возвращения;
• нужен ли разный workflow для разных типов документов — каждому типу можно назначить свой процесс, но это значит, что перед настройкой нужно явно перечислить типы и процесс для каждого;
• как обрабатывать отклонение — возврат в «Черновик» с комментарием или отдельная ветка без возможности повторной отправки без новой версии документа.

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

Интеграция с тем, что уже есть в компании

Документы редко появляются из ниоткуда прямо в веб-интерфейсе. У компании уже есть источники: почта, куда приходят счета от поставщиков, сетевая папка, куда бухгалтерия годами складывала сканы, учётная система, формирующая часть документов сама. Mayan EDMS умеет подключать несколько типов источников загрузки — вручную через веб-форму, через «стейджинговую» папку на диске, через сканирование напрямую в систему и через опрос почтового ящика (IMAP/POP3), когда вложения из писем автоматически становятся документами нужного типа. Это снимает часть ручной работы, но требует настройки:

• для источника-почты нужен отдельный технический ящик, доступ по IMAP или POP3, и правило, что считать документом — не любое письмо с вложением автоматически превращается в нужный тип документа с нужными метаданными;
• прямого готового коннектора к учётной системе (1С, CRM, биллинг) у Mayan EDMS нет — есть REST API для программной загрузки документов и метаданных, но модуль, вызывающий этот API из вашей учётной системы, придётся писать самостоятельно или заказывать отдельно;
• метаданные — это то, на чём строятся автоматические индексы (виртуальные папки по значению поля, например «Год / Контрагент / Тип документа»), и структуру стоит спроектировать до массовой заливки архива — переделка после загрузки тысяч документов требует либо массового скрипта через API, либо ручной правки;
• перенос уже существующего архива — не drag-and-drop операция на тысячах файлов, а отдельный проект: нужно решить, какие метаданные проставить каждому старому документу и можно ли это вывести автоматически из структуры папок и имён файлов, или часть архива придётся разбирать вручную.

Если в компании уже отлажен обмен документами с контрагентами через оператора ЭДО, это отдельная задача, не пересекающаяся напрямую с Mayan EDMS: там — маршрутизация между организациями и проверка подписи оператором, здесь — внутреннее хранение, версионирование и согласование. Подробнее об инфраструктуре такой интеграции — в статье «Электронный документооборот через оператора: серверная сторона вопроса». Оба процесса нередко сосуществуют: документы приходят через оператора ЭДО, а затем архивируются и согласовываются уже в Mayan EDMS.

Обучение сотрудников: самая недооценённая статья расходов

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

• обучение базовым операциям — загрузка документа, простановка метаданных, поиск, работа с версиями — короткое, но обязательное для каждого пользователя, а не только для «ответственного за систему»;
• обучение workflow отдельно от интерфейса — сотрудник должен понимать не только «как нажать кнопку перехода», но и что происходит после, кто увидит документ следующим и что будет, если он не сделает это вовремя;
• период параллельной работы старого и нового процесса. Компании редко отключают бумажный или почтовый процесс в день запуска — какое-то время документы идут и туда, и туда, пока не появится уверенность, что электронный процесс их не теряет, а это двойная нагрузка на сотрудников в переходный период;
• сопротивление изменениям — реальный фактор. Сотрудник, годами работавший определённым образом, не обязательно радуется новой системе, даже объективно более удобной. Часть времени внедрения уходит на то, чтобы объяснить, зачем это нужно, и разобрать неудобства на реальных сценариях;
• выделенный «ответственный за систему» внутри компании, не обязательно айтишник — человек, к которому идут с вопросом «как теперь сделать вот это», прежде чем эскалировать проблему до администратора.

Обучение — не разовое мероприятие в день запуска, а процесс, повторяющийся при каждом расширении workflow, при найме сотрудника, при изменении бизнес-процесса. Компании, закладывающие это время заранее, проходят внедрение заметно спокойнее тех, кто считает, что «система интуитивная, разберутся сами».

Администрирование, обновления и бэкапы на дистанции

После первого месяца эксплуатации нагрузка на систему не заканчивается, она меняется по характеру — с проектных задач на регулярную эксплуатацию:

• обновления — между релизами Django-приложения возможны миграции базы и изменения в хранении файлов, так что обновление требует бэкапа перед апдейтом и проверки на копии данных, а не «в лоб»;
• бэкап — это две сущности, а не одна. База PostgreSQL с метаданными и правами — одна часть, файловое хранилище с телами документов — вторая, и растёт она обычно быстрее базы. Нужна согласованная копия обеих частей на один момент времени — рассинхронизация может дать запись о документе без файла или наоборот;
• рост хранилища планируется заранее — архив практически никогда не уменьшается, особенно быстро растёт в первые месяцы после заливки накопленного бумажного архива;
• мониторинг очереди Celery — если воркеры встали, новые документы загружаются, но не проходят OCR, не строятся индексы, не срабатывают переходы workflow. Система выглядит рабочей, а часть функциональности молча не выполняется;
• права доступа требуют периодического аудита — гранулярные ACL можно выставить один раз и забыть, а через год выяснить, что уволенный сотрудник технически всё ещё имеет доступ.

Для базового ориентира по установке PostgreSQL как основной базы Mayan EDMS пригодится общая инструкция по установке и настройке PostgreSQL на VPS — специфика Mayan EDMS добавляется поверх этой базовой конфигурации, а не заменяет её.

Честная таблица: во что реально обходится Mayan EDMS

Как и в случае с TCO выделенного сервера в целом, точные цифры в каждой строке зависят от объёма архива, числа согласующих сотрудников и того, есть ли в компании человек, для которого администрирование Mayan EDMS — часть должностных обязанностей, а не разовая задача «между делом». Похожая по логике, но другая по предметной области статья — TCO самостоятельного хостинга Akaunting: там основная статья расходов — платные модули и требования к сохранности финансовых данных, здесь — распознавание текста, моделирование workflow и обучение людей работе с новым процессом.

Частые вопросы