Короткий ответ. После запуска 1С систему нужно довести до нормальной эксплуатации: проверить резервные копии, права пользователей, сервер, обновления, обмены и порядок действий при сбое. Первые 90 дней – удобный рабочий горизонт, чтобы закрыть эти задачи по очереди и увидеть систему уже под реальной нагрузкой. Критичные вещи вроде резервного копирования, административных доступов и ответственных лучше проверить сразу. Остальные вопросы можно уточнять по мере того, как появляются реальные данные по нагрузке и работе пользователей. Сам срок в 90 дней условный и нормативом не является.
Проверьте, не закончился ли проект слишком рано
1С уже запущена. Сотрудники работают, документы проводятся, бухгалтерия закрывает свои задачи.
Формально внедрение состоялось. Но именно после запуска начинают проявляться эксплуатационные вопросы, которые во время проекта могли выглядеть второстепенными.
Проверьте, знакомы ли вам такие ситуации:
- резервная копия создаётся, но восстановление ещё никто не проверял;
- нового сотрудника добавили по образцу коллеги, и вместе с нужными правами он получил доступ к данным, которые ему для работы вообще не требуются;
- обновления устанавливаются тогда, когда появляется конкретная необходимость;
- никто сразу не скажет, кто отвечает за сервер, а кто за конфигурацию 1С;
- обмен с сайтом или другой системой работает, но об ошибке узнают от пользователя;
- административные пароли остались у специалиста, который участвовал во внедрении;
- база работает нормально сейчас, а как она поведёт себя в конце месяца под полной нагрузкой, ещё никто не видел.
Каждый пункт сам по себе решаем. Сложности появляются, когда несколько таких вопросов обнаруживаются одновременно во время первого серьёзного сбоя.
Почему после внедрения остаются незакрытые задачи
Во время проекта внимание сосредоточено на запуске. Нужно настроить конфигурацию, перенести данные, проверить ключевые операции и дать пользователям возможность работать.
После запуска начинается эксплуатация. Число пользователей меняется, база растёт, появляются новые обмены, устанавливаются обновления, сотрудники получают и теряют доступы. Сервер продолжает работать каждый день, а резервные копии должны выполняться по расписанию.
Есть и организационная часть. Конфигурацию мог внедрять франчайзи 1С, сервер готовил системный администратор, виртуальную машину предоставляет хостер. Через несколько недель после запуска особенно хорошо видно, где заканчивается работа одного исполнителя и начинается зона другого.
Мы отдельно разбирали, кто должен обслуживать сервер 1С и как распределить зоны между подрядчиками.
Первые 90 дней: что проверить и когда
90 дней – рабочий ориентир. Критичные вещи лучше закрывать сразу, а часть проверок имеет смысл проводить после того, как система успела поработать под реальной нагрузкой.
| Период | Что проверить | Что должно быть понятно после проверки |
|---|---|---|
| Первая неделя | Ответственные, административные доступы, резервное копирование, место хранения копий, критичные обмены | Кому звонить, где лежат доступы и что произойдёт с данными при серьёзном сбое |
| Первые 30 дней | Тестовое восстановление, права пользователей, фактическая работа сервера, выполнение заданий и обменов | Восстанавливается ли база, соответствуют ли права реальным ролям и есть ли признаки проблем под рабочей нагрузкой |
| 30–60 дней | Обновления, рост базы, периоды высокой активности, взаимодействие подрядчиков | Как система ведёт себя под реальной нагрузкой и как должны проходить изменения |
| 60–90 дней | Повторная проверка прав, сценарий восстановления, административные доступы, список регулярных работ | Система переходит в понятную и управляемую эксплуатацию |
Если часть этих задач была закрыта ещё до запуска, достаточно проверить, что настройки действительно работают в текущей инфраструктуре.
1. Сначала определите, кто теперь отвечает за работающую 1С
После проекта остаются две большие части: сама 1С и инфраструктура, на которой она работает.
В зависимости от компании в этой схеме участвуют франчайзи, системный администратор, ИТ-подрядчик, хостер и разработчик интеграций.
У сотрудников должен быть простой ответ на вопрос: кому сообщить, если завтра утром 1С перестанет открываться?
Дальше технические специалисты уже определяют источник проблемы.
Зафиксируйте хотя бы:
- кто обновляет конфигурацию;
- кто обслуживает сервер;
- кто ведёт СУБД, если она используется;
- кто контролирует резервные копии;
- кто отвечает за сеть и удалённый доступ;
- кто разбирает ошибки обменов.
Такой список занимает меньше страницы, а во время сбоя экономит время на выяснение ролей.
2. Проверьте резервную копию восстановлением
Фраза «бэкап настроен» закрывает только часть вопроса.
Нужно знать: сможем ли мы получить из этой копии рабочую базу?
После внедрения могли измениться пути хранения, сервер, объём базы, расписание заданий или сама схема резервирования.
Полезно зафиксировать:
- что копируется;
- как часто;
- где хранится;
- сколько версий сохраняется;
- кто получает сообщение об ошибке;
- кто выполняет восстановление;
- сколько фактически занимает возврат базы к работе.
Последний пункт невозможно надёжно определить по настройкам программы резервного копирования. Его показывает тест.
Про саму процедуру у нас есть отдельный материал – как проверить бэкап 1С тестовым восстановлением.
3. Пересмотрите права после первых недель работы
На запуске права часто выдаются с запасом. Команде нужно начать работу, роли ещё уточняются, часть обязанностей распределяется уже после старта.
Через несколько недель становится видно, какие доступы действительно нужны.
Например, новому сотруднику могут выдать права копированием с коллеги. В результате вместе с нужными разделами он получает доступ к закупочным ценам, зарплатной информации или другим данным, которые не относятся к его работе.
Проверять стоит и временные доступы специалистов, участвовавших во внедрении.
Практический вопрос: если сотрудник завтра сменит должность или уволится, кто и где отключит его доступ?
Если для ответа нужно искать человека, который «это когда-то настраивал», процесс стоит оформить.
4. Посмотрите, как 1С ведёт себя под реальной нагрузкой
Первые недели после запуска дают то, чего нельзя получить на тестовом стенде: обычную рабочую нагрузку.
Сотрудники одновременно входят в систему, формируют отчёты, проводят документы, запускают обмены. К концу месяца нагрузка может заметно отличаться от первых дней после внедрения.
Самый полезный источник информации здесь – поведение системы и пользователей.
Если сотрудники уже знают, что тяжёлый отчёт лучше запускать вечером, а в конце месяца база становится заметно медленнее, это повод отдельно проверить инфраструктуру и режим работы 1С.
Какие именно показатели стоит контролировать на сервере, зависит от архитектуры. Этот список лучше определить с инженером после анализа конкретной системы.
Мы подробно разбирали такую ситуацию в статье о том, когда файловая 1С перестаёт соответствовать текущей нагрузке.
5. Зафиксируйте порядок обновлений
После запуска начинается обычная жизнь системы.
Появляются обновления конфигурации и платформы, меняются обработки и интеграции. К этому могут добавляться обновления операционной системы, СУБД и других компонентов.
Полезно заранее определить порядок:
- Кто принимает решение об обновлении.
- Кто проверяет совместимость.
- Когда выполняются работы.
- Какая резервная копия создаётся перед изменением.
- Кто проверяет ключевые операции после установки.
- Как действуем, если после обновления появились ошибки.
Для небольшой компании этот регламент может занимать несколько строк. Его ценность в том, что изменения перестают зависеть только от памяти конкретного специалиста.
6. Проверьте обмены как отдельные системы
После внедрения 1С часто связывают с сайтом, банком, складской системой, CRM, ЭДО и другими сервисами.
Сам факт успешного обмена сегодня ещё не показывает, как компания узнает о проблеме завтра.
Стоит определить:
- кто получает сообщение об ошибке;
- где видно последнюю успешную передачу;
- что произойдёт с накопившимися данными после восстановления;
- кто начинает диагностику;
- кто отвечает за сторону 1С и кто за вторую систему.
Это особенно важно для автоматических процессов. Пользователь может обнаружить ошибку уже после того, как накопилась очередь непереданных данных.
Быстрый чек-лист после внедрения 1С
К концу первых 90 дней у компании должны быть зафиксированы ответственные, административные доступы, резервное копирование, порядок обновлений, критичные обмены и сценарий восстановления.
Пройдите этот чек-лист по своей системе.
1. Назначьте ответственных
Запишите, кто ведёт 1С, сервер, сеть, СУБД, резервное копирование и интеграции.
2. Соберите административные доступы
У компании должен быть контролируемый способ получить критичные учётные данные без зависимости от одного внешнего специалиста.
3. Восстановите базу из копии
Проверьте результат и зафиксируйте фактическое время восстановления.
4. Пересмотрите права
Уберите временные и избыточные доступы, которые появились во время внедрения.
5. Посмотрите на реальную нагрузку
Проверьте, как система ведёт себя в обычный день и в периоды максимальной активности.
6. Опишите обновления
Определите, кто согласует изменения, создаёт копию, выполняет обновление и проверяет систему после него.
7. Проверьте интеграции
Для каждого критичного обмена должен быть ответственный и понятный способ заметить ошибку.
8. Пройдите один сценарий сбоя
Например: «Утром вся бухгалтерия потеряла доступ к 1С».
Кто принимает обращение? Кто проверяет сервер? У кого есть административный доступ? Когда подключается франчайзи? Кто восстанавливает базу?
Если порядок приходится придумывать во время обсуждения, его лучше оформить заранее.
Когда звать подрядчика
Аудит после внедрения особенно полезен, когда 1С уже работает, а эксплуатационные задачи распределены между несколькими людьми или компаниями. Например, франчайзи ведёт конфигурацию, сервер обслуживает другой специалист, а резервное копирование и мониторинг существуют отдельными процессами.
В «Доктор Сервер» при таком аудите смотрим инфраструктуру вокруг 1С: сервер, сеть, резервное копирование, административные доступы и распределение технических задач. Если система клиент-серверная, отдельно уточняем, кто занимается СУБД и где проходит граница с франчайзи.
В результате компания получает список конкретных участков, которые стоит закрыть в первую очередь. Стоимость рассчитывается после аудита, по запросу.