К статье
Практический материал

Администрирование · 10 мин

Как провести КТС в 1С: комплексное техническое сопровождение базы

Как организовать комплексное техническое сопровождение (КТС) базы 1С: обновление конфигурации, резервное копирование, тестирование и исправление, регламентные операции.

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

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

Ниже — практический порядок проведения КТС для типовых конфигураций (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом и др.) в файловом и клиент-серверном варианте. Часть операций требует прав администратора и доступа к конфигуратору.

Что входит в КТС и как подготовиться

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

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

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

Резервное копирование перед работами

Для файловой базы самый надёжный способ — выгрузка в файл .dt через конфигуратор: меню «Администрирование — Выгрузить информационную базу». Файл .dt содержит и данные, и конфигурацию, его можно загрузить в пустую базу и получить полную рабочую копию. Дополнительно можно скопировать сам файл 1Cv8.1CD — но только при полностью завершённых сеансах, иначе копия может оказаться повреждённой.

Для клиент-серверной базы основной метод — штатный backup средствами СУБД (MS SQL, PostgreSQL). Выгрузка .dt тоже допустима, но на больших базах она занимает много времени и не заменяет плановое копирование средствами СУБД.

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

Обновление конфигурации

Типовую конфигурацию на поддержке обновляют через конфигуратор: «Конфигурация — Поддержка — Обновить конфигурацию». Если обновления установлены в каталог шаблонов, выберите поиск обновлений в каталоге; если скачан файл поставки (.cfu) — укажите его вручную. В пользовательском режиме многие типовые конфигурации поддерживают обновление через интернет из раздела «Администрирование — Обновление версии программы».

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

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

Порядок обновления типовой конфигурации
  1. 1
    Создайте и проверьте резервную копию базы
  2. 2
    Завершите все сеансы и установите блокировку соединений
  3. 3
    В конфигураторе выполните «Поддержка — Обновить конфигурацию» и выберите источник обновления
  4. 4
    Примите изменения и обновите конфигурацию базы данных (F7)
  5. 5
    Запустите базу в режиме предприятия и дождитесь завершения обработчиков обновления
  6. 6
    Проверьте версию конфигурации и работу ключевых операций

Тестирование и исправление базы

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

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

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

Контрольные точки

Как проверить результат КТС

Версия конфигурации после обновления
Норма

Соответствует целевому релизу, первый запуск завершился без ошибок

Тревожный признак

Версия не изменилась, обработчики обновления завершились с ошибками

Резервная копия
Норма

Файл создан, загружается в тестовую базу

Тревожный признак

Файл отсутствует, нулевого размера или не загружается

Регламентные задания
Норма

Выполняются по расписанию, в журнале нет ошибок

Тревожный признак

Задания заблокированы или завершаются с ошибками

Ключевые операции
Норма

Проведение документов, отчёты и обмены работают как раньше

Тревожный признак

Ошибки при проведении, пустые или искажённые отчёты

Регламентные задания и обслуживающие обработки

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

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

Отдельно проверьте обработки удаления помеченных объектов и свёртки/архивации старых периодов, если они используются. Регулярное удаление помеченных объектов контролирует рост базы, но выполнять его стоит тоже после резервной копии — удаление необратимо.

Типичные ошибки при проведении КТС

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

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

Типичные ошибки
01
Обновление без проверенной резервной копии — при сбое данные теряются безвозвратно
02
Прерывание обработчиков обновления при первом запуске — часть данных остаётся в старом формате
03
Исправление ссылочной целостности без предварительного анализа — объекты удаляются безвозвратно
04
Пропуск промежуточных релизов — обновление завершается ошибкой или база не открывается
05
Работа пользователей во время обслуживания — конфликты и незавершённые транзакции

Как выстроить регулярный регламент

Разовое обслуживание не заменяет регламента. Практичная схема: резервное копирование — ежедневно автоматически (средствами СУБД или скриптами), проверка восстановления копии — периодически на тестовом сервере, обновление конфигурации — по мере выхода значимых релизов, обязательно перед сдачей регламентированной отчётности, тестирование и реиндексация — по расписанию в нерабочее время.

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

Итог

Что важно запомнить

КТС в 1С — это регулярный цикл: копия, обновление, тестирование, контроль заданий. Порядок этапов и проверка результата важнее скорости. Любое действие, затрагивающее структуру или данные базы, выполняется только после создания и проверки резервной копии.

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

Можно ли обновлять конфигурацию, пока пользователи работают?

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

Чем выгрузка .dt отличается от копирования файла 1Cv8.1CD?

Выгрузка .dt — штатный механизм: файл содержит данные и конфигурацию и гарантированно загружается обратно. Копирование файла 1Cv8.1CD допустимо только при полностью завершённых сеансах, иначе копия может оказаться повреждённой. Для надёжности используют выгрузку .dt, а копирование файла — как дополнительную меру.

Как часто нужно обновлять конфигурацию?

Жёсткого правила нет, но пропускать релизы надолго не стоит: устаревают формы отчётности, курсы, классификаторы и механизмы обмена с государственными сервисами. Практичный ориентир — обновляться перед сдачей отчётности и при выходе релизов с критичными исправлениями, не допуская отставания на много версий.

Что делать, если обновление завершилось ошибкой?

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

Нужно ли тестирование и исправление, если база работает без ошибок?

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

Можно ли автоматизировать КТС?

Частично. Резервное копирование автоматизируется средствами СУБД или скриптами, реиндексация и обновление статистики — планами обслуживания СУБД, контроль заданий — мониторингом журнала регистрации. Обновление конфигурации полностью автоматизировать сложнее: оно требует контроля цепочки релизов и проверки результата, поэтому обычно остаётся ручной операцией под наблюдением администратора.