Инфраструктура электронного архива: сроки, доступ и сканирование

С чего начинаются проблемы с электронным архивом

Проблемы почти всегда начинаются не с поломок, а с ожиданий. Электронный архив запускают как «папку для сканов», а через полгода он внезапно становится медленным, дорогим и нервным: поиск открывает документ по 10-20 секунд, места не хватает, резервные копии не укладываются в ночь, а пользователи спорят, кто что имеет право видеть.

Обычно забывают про рост. Архив растет не линейно: подразделения подключаются волнами, качество сканов повышают (и файлы тяжелеют), появляются версии документов, а затем добавляется требование хранить дольше. Параллельно растет и «невидимый» объем: резервные копии, репликации, тестовые среды, временные файлы обработки.

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

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

Чтобы выбрать серверы и хранилище без переплаты, нужны простые вводные:

• сроки хранения по типам документов и ожидаемый рост фонда;
• сколько пользователей работает одновременно и что они делают (поиск, просмотр, выгрузки);
• модель ролей доступа и требования к аудиту;
• объемы сканирования в день и средний размер файла;
• требования к резервному копированию и времени восстановления.

Если эти цифры собрать заранее, системный интегратор сможет подобрать конфигурацию без лишних «запасов».

Определяем задачи архива простыми словами

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

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

Дальше определитесь с форматом файла. PDF или PDF/A обычно удобнее для чтения и обмена, TIFF часто выбирают для качества и долгого хранения, JPEG встречается в фото и быстрых сканах. Сразу решите, будет ли у документов OCR-слой. Без распознавания текста вы почти всегда ограничены поиском по карточке и метаданным.

Полезно коротко описать, как люди будут находить документы. Чаще всего это комбинация:

• поиск по атрибутам (номер, ИИН, контрагент, дата);
• поиск по тексту внутри документа (требует OCR);
• поиск по штрихкоду или QR на скане (ускоряет разбор пачек);
• просмотр, скачивание и печать (важны требования к скорости).

И последнее - доступность. Архив «по будням с 9 до 18» и архив, который нужен круглосуточно, требуют разного уровня резервирования и поддержки. Двухчасовой простой для бухгалтерии в конце квартала может быть критичнее, чем простой на складе в спокойный сезон.

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

Сроки хранения: что они реально меняют в инфраструктуре

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

Практично делить сроки на три группы: короткие (1-3 года), средние (5-10 лет) и длительные (15+ лет, иногда постоянно). Для инфраструктуры важно не только «сколько хранить», но и сколько времени документ остается активным. Пока его часто ищут и открывают, нужен быстрый слой хранения и хорошая производительность.

Рабочая логика проектирования обычно такая:

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

Отдельный вопрос - политика удаления. Удаление в архиве не должно быть «кто-то стер папку». Заранее определите, кто утверждает уничтожение, как фиксируется основание, кто выполняет операцию и как записывается факт уничтожения. Это влияет на хранение журналов аудита и на права администраторов.

Проверьте влияние сроков на емкость простым тестом: если архив растет на 2 ТБ в месяц, то «длительная» категория на 5 лет - это уже 120 ТБ без учета резервных копий. А копии часто добавляют от 1x до 3x к емкости, в зависимости от политики.

Роли доступа и аудит: влияние на серверы и производительность

Когда продумывают инфраструктуру электронного архива, роли доступа часто воспринимают как «настройку в системе». На деле это прямой фактор нагрузки: кто и как часто открывает документы, кто загружает новые, кто согласует, кто администрирует, кто проверяет.

Роли и принцип наименьших прав

Обычно в архиве есть несколько типов действий: загрузка (включая сканирование), просмотр, согласование, администрирование и аудит. Если всем выдать широкий доступ «на всякий случай», растет риск ошибок и утечек, а расследования и проверки становятся тяжелее.

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

Журналы действий и ресурсы сервера

Аудит почти всегда требует подробных журналов. Для проверок обычно фиксируют:

• вход в систему и неудачные попытки;
• просмотр и скачивание документа;
• изменение метаданных и статусов;
• создание, замена, удаление файлов;
• админские изменения прав и политик.

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

Рост числа пользователей влияет не только на «сколько лицензий». Он увеличивает одновременные сессии, количество запросов к поисковому индексу и базе, а также объем операций чтения. Сканы нагружают запись и обработку (OCR, индексация), просмотр нагружает чтение и сеть, аудит добавляет постоянную «мелкую» запись в журнал. Если ожидается резкий рост пользователей, нужен запас по CPU, памяти и IOPS, иначе система начинает тормозить именно в часы пик.

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

Почти все просчеты в электронном архиве начинаются с фразы: «Сканируем немного». На практике важно знать не только среднее число страниц в день, но и пики (конец месяца, закрытие дел, массовая оцифровка фонда), а также сколько сканеров работают одновременно и с какой скоростью.

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

Грубые ориентиры (сильно зависят от компрессии и типа PDF): черно-белая 300 dpi часто укладывается в сотни килобайт на страницу, серый цвет - ближе к 1-2 МБ, цвет - от нескольких мегабайт и выше. При двустороннем сканировании объем почти удваивается.

Дальше посчитайте поток:

• страниц в день (и отдельно в пиковый день) = сканеров × страниц в минуту × минут работы;
• объем в день = страниц в день × средний размер страницы;
• объем в год = объем в день × рабочих дней (или календарных);
• рост за срок хранения = объем в год × лет хранения;
• запас = +20-50% на перескан, вложения, служебные файлы.

Помните, что OCR и индексация часто нагружают сервер сильнее, чем само хранение. Распознавание любит CPU и память, а массовая обработка создает очередь задач. Если вы одновременно сканируете, делаете OCR, загружаете в систему и проводите контроль качества, это параллельные потоки. Им нужна стабильная скорость записи, достаточная производительность серверов и пропускная способность сети.

Простой пример: в обычный день 20 000 страниц, в пик - 60 000. Если в пик запускать OCR сразу, система должна выдержать тройную нагрузку без остановки приема документов. Здесь помогает разделение ресурсов: отдельный узел (или выделенные мощности) под OCR, отдельный контур под хранение и понятные очереди обработки.

Пошаговый расчет: от требований к конфигурации

Чтобы инфраструктура электронного архива не оказалась «на глазок», удобнее идти от требований к цифрам, а уже потом к серверам и дискам.

1. Соберите вводные: сроки хранения по видам, роли доступа (кто что видит), ожидаемое число пользователей, а также SLA (сколько простоя допустимо и за сколько нужно восстановиться). Отдельно фиксируйте пики: когда идет массовая загрузка сканов и когда чаще всего ищут документы.

2. Посчитайте данные: переведите объемы сканирования в гигабайты, оцените прирост в месяц и общий объем на 3-5 лет с запасом. Учитывайте индексы, версии, служебные файлы и рост.

3. Разложите хранение по уровням: быстрый слой для свежих и часто запрашиваемых документов и емкий слой для долгого хранения. Это снижает стоимость и помогает удержать скорость поиска.

4. Продумайте резервное копирование и восстановление: заранее решите, что защищаете в первую очередь - базу данных, файловое хранилище, поисковые индексы, журналы аудита.

5. Подберите серверы под нагрузку приложения и БД: CPU и RAM под одновременную работу и индексацию, быстрые диски под БД и индексы, отдельный ресурс под OCR (если он тяжелый), сеть под загрузку и выдачу файлов, мониторинг и запас по росту.

Пример: если архив ежедневно принимает сканы от канцелярии, а основные запросы идут от юристов и аудиторов, узкое место часто не в «общих терабайтах», а в скорости БД, индекса и журналирования.

Выбор серверов: на что реально смотрят в архиве

При выборе серверов важно не «взять побольше всего», а понять, где система упрется первой: база данных, поиск, OCR, загрузка сканов или раздача документов пользователям.

Сервер приложения и сервер БД: вместе или раздельно

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

Чаще всего разносить стоит, если база быстро растет и «съедает» диск и память, поиск и OCR идут параллельно с работой пользователей, нужны обновления без простоя всего архива, важна предсказуемая скорость в часы пик.

CPU и RAM: что важнее для поиска и OCR

Для базы данных и поисковых индексов чаще важнее RAM: чем больше данных и индексов помещается в память, тем меньше обращений к диску и тем быстрее отклик. CPU становится критичным, когда много параллельных запросов, сложные фильтры, отчеты и OCR.

Если OCR выполняется на тех же серверах, планируйте запас по CPU и выделяйте «окна» для массовой обработки. Иначе в рабочее время пользователи увидят тормоза при открытии карточек и поиске.

Диски: IOPS для активных операций и емкость для архива

Архивные данные занимают много места, но читаются неравномерно. Поэтому обычно разделяют быстрый слой для активных операций (БД, индексы, очередь загрузки) и емкий слой для долгого хранения.

Быстрые диски и высокий IOPS нужны для БД, индексов и массовой загрузки. Большая емкость важна для файлового хранилища сканов и версий.

Сеть: узкие места при массовой загрузке и раздаче

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

Хранилище и резервное копирование без самообмана

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

Резервное копирование проще понимать через три слова: RPO, RTO и окно бэкапа.

• RPO - сколько данных вы готовы потерять по времени.
• RTO - через сколько архив должен снова заработать после сбоя.
• Окно бэкапа - когда система может «проседать» из-за копирования и сколько времени на это реально есть.

Копии лучше не держать «в том же шкафу». Практичнее думать так: первая копия на основной площадке, вторая - на отдельном устройстве в другой зоне, третья - вне площадки. Для многих организаций работает правило 3-2-1: три копии, на двух разных носителях, одна - отдельно.

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

• где лежат 2-я и 3-я копии и кто имеет к ним доступ;
• как часто делаются полные и инкрементальные копии;
• как проверяется целостность (хэши, периодическая верификация);
• как часто выполняется тестовое восстановление и сколько оно занимает.

Проверка целостности важна не меньше, чем само копирование. Архив может выглядеть «живым» годами, пока не понадобится восстановить документ и не выяснится, что копия битая. План восстановления (что, откуда и за сколько) должен быть таким же реальным, как и план закупки серверов и дисков.

Типичные ошибки при проектировании электронного архива

Причина перерасхода чаще не в цене железа, а в неверных допущениях. Проект выглядит «достаточным» на бумаге, но через полгода заканчивается место, интерфейс тормозит, а доступ к документам становится спорным.

Чаще всего встречаются такие ошибки:

• Считают только «чистый» объем сканов. На практике место съедают резервные копии, версии файлов, индексы, служебные базы, журналы аудита.
• Делают сканы слишком тяжелыми. 600 dpi и цвет для всего выглядят безопасно, но часто не дают пользы, а в 2-4 раза увеличивают объем и нагрузку на OCR. Для большинства задач хватает 300 dpi и серого, а цвет оставляют для исключений.
• Складывают все в одно хранилище. Активные документы и «долгий» архив имеют разный профиль нагрузки. Если не разделить уровни, страдает скорость и растет цена.
• Настраивают доступ «примерно». Размытые роли приводят к конфликтам, лишним проверкам и сложному расследованию инцидентов.
• Недооценивают индексацию и OCR. Сканирование дает поток файлов, а поиск по содержимому - поток вычислений. Если это не заложить, архив начинает тормозить в часы пик.

Пример: отдел переводит в архив договоры «на всякий случай» в максимальном качестве. Через год выясняется, что часть документов нужно хранить 5 лет, часть - 10, а к старым обращаются редко. Если бы это разделили по уровням хранения и качеству сканов, можно было бы взять меньший массив быстрых дисков и больше емкости под холодный слой.

Пример сценария: как увязать сроки, доступ и сканирование

Представим организацию с головным офисом и 8 филиалами. Всего 200 пользователей, из них 40 активно работают с архивом каждый день. Сканирование идет постоянно: в сумме 6 000 страниц в день, в пиковые дни (конец месяца) - до 12 000.

1) Разложение по срокам хранения и доступу

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

• кадровые: 75 лет, доступ HR + аудит;
• договоры: 5-10 лет, доступ юристы + финансы;
• первичка и счета: 5 лет, доступ бухгалтерия;
• внутренние заявки: 1-3 года, доступ подразделения;
• справочные: до замены, доступ широкий.

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

2) Оценка роста на 3 года и пики нагрузки

Для грубой оценки достаточно перевода «страницы в гигабайты». Если одна страница после сжатия в PDF/A занимает в среднем 250 КБ (с OCR может быть больше), то 6 000 страниц в день - это около 1,5 ГБ.

Даже если считать 22 рабочих дня, получится примерно 33 ГБ в месяц, около 400 ГБ в год и около 1,2 ТБ за 3 года. Добавьте запас 30-50% на индексы, версии, вложения, служебные файлы и рост качества сканов - и вы уже ближе к 2 ТБ.

Пики нагрузки чаще всего возникают не по объему, а по одновременному доступу: конец месяца, проверки, массовые выгрузки, пакетное распознавание.

Какой подход к серверу, хранилищу и бэкапу подходит

Для такого сценария обычно работает схема:

• разделить роли: отдельный сервер под приложение и отдельный под базу данных, чтобы пики пользователей не «душили» БД;
• хранилище в 2 слоя: быстрый слой для последних 3-6 месяцев и «холодный» слой для длительного хранения;
• отдельные политики для классов документов: долгий срок + строгий доступ = отдельный раздел и усиленный аудит;
• резервное копирование по правилу 3-2-1 и отдельные сроки хранения для бэкапов.

Короткий чеклист и следующие шаги

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

Быстрый чеклист:

• уточните вводные: сроки хранения по типам, число активных пользователей, реальные пики сканирования;
• перепроверьте расчеты объема: годовой рост, запас на 2-3 года, отдельное место под версии и служебные файлы, плюс место под резервные копии;
• согласуйте окна обслуживания: когда можно делать бэкап, проверку целостности, обновления, миграции;
• проверьте безопасность: роли доступа, аудит действий, разделение рабочих и административных учетных записей, раздельные среды (тест и продуктив);
• зафиксируйте целевые показатели: сколько секунд можно ждать поиск и сколько времени допустимо на восстановление.

Следующий практический шаг - запросить предварительную спецификацию у интегратора и дать ему одинаковые вводные. Чтобы расчет был точным, подготовьте:

• таблицу типов документов со сроками хранения и примерным количеством;
• оценку сканирования по дням и по пикам (страницы или файлы);
• модель ролей и требований к аудиту;
• целевые показатели по поиску и восстановлению.

Если вам нужно быстро сверить варианты по серверной части и поддержке в Казахстане, можно обсудить вводные с GSE.kz (gse.kz) как с производителем серверов и системным интегратором. Главное - чтобы спецификация опиралась на ваши реальные сроки хранения, модель доступа и пики сканирования, а не на усредненные «запасы».