Составление руководства администратора для 1С-Битрикс
Руководство администратора для Битрикс-проекта — это не пересказ официальной документации «1С-Битрикс». Это описание конкретной инсталляции: какие инфоблоки есть и что в них можно редактировать, как работает цепочка публикации, какие настройки трогать нельзя и почему. Без такого документа каждый новый администратор тратит недели на освоение, а половина вопросов решается звонком разработчику. Наш опыт показывает: грамотное руководство сокращает время онбординга в 3-5 раз и исключает типовые ошибки при администрировании.
Как составить руководство, которое не устареет за месяц?
Главная проблема — документ устаревает с каждым обновлением. Решение: процесс, при котором разработчик при сдаче задачи обновляет соответствующий раздел руководства. Для хранения используйте систему с историей версий — Confluence, Notion или Google Docs. Файл Word на сервере — антипаттерн, так как версионирование невозможно. В Git-репозиторий руководство не кладите: оно содержит операционную информацию, не относящуюся к коду. На практике, облачные системы типа Confluence справляются с актуальностью значительно лучше.
Мы гарантируем, что разработанное нами руководство остаётся актуальным благодаря чек-листу сопровождения. Сертификаты и лицензии нашей команды подтверждают компетенции в области Битрикс.
Что должно быть в разделах для администратора?
Типовой состав руководства:
| Раздел | Содержание |
|---|---|
| Доступы и окружение | Адреса панелей, ссылка на менеджер паролей, описание ролей и групп прав |
| Управление контентом | Инфоблоки, поля, скриншоты, ограничения |
| Управление каталогом (e-commerce) | Товары, цены, склады (catalog), скидки (sale) |
| Заказы и покупатели | Статусы заказов, жизненный цикл |
| Технические процедуры | Резервное копирование, обновление ядра, очистка кеша |
Описание инфоблоков: шаблон для каждого
Для каждого инфоблока делайте карточку по шаблону:
Инфоблок: Новости Тип: news | ID: 3 | Символьный код: news Расположение в меню: Контент → Новости URL административного списка: /bitrix/admin/iblock_list_admin.php?IBLOCK_ID=3&type=news Поля элемента: - Название (NAME) — обязательное. Заголовок новости - Символьный код (CODE) — генерируется автоматически, не редактировать - Дата публикации (ACTIVE_FROM) — если не указана, новость публикуется немедленно - Анонс (PREVIEW_TEXT) — краткое описание для списка, до 300 символов - Анонс-картинка (PREVIEW_PICTURE) — 800×600 px, JPG/PNG, максимум 500 КБ - Детальный текст (DETAIL_TEXT) — редактор TinyMCE, полный текст новости - Теги (TAGS) — через запятую, используются для фильтрации Что нельзя делать: - Изменять символьный код опубликованной новости (сломает URL и потеряет позиции в поиске) - Удалять разделы с активными элементами без перепривязки Такой формат понятен людям без технического бэкграунда и не требует пояснений при каждом обращении. На практике, администраторам часто нужна информация о том, какие ограничения существуют при редактировании, чтобы не сломать сайт случайным действием.
Описание технических процедур
Очистка кеша — самое частое действие администратора. В /bitrix/admin/cache.php два варианта: очистить весь кеш или только кеш компонента. Опишите, что чистить при разных ситуациях. Если сайт использует HTML-кеш (/bitrix/html_pages/), его нужно чистить отдельно. Рекомендуем документировать, что кеширование может скрывать новые данные до 24 часов, если TTL высокий, поэтому при критичных ошибках кеш нужно чистить немедленно.
Резервное копирование — встроенный модуль (/bitrix/admin/backup.php). Опишите, как создать копию вручную, где она хранится, как восстановить сайт. Именно этот шаг спасает в критический момент. На практике, регулярные бэкапы предотвращают потерю данных при сбое железа, взломах или случайном удалении важной информации администратором.
Обновление модулей — через «Marketplace» или /bitrix/admin/update_system.php. Совет: не обновляйте сразу после выхода — дайте время на выявление багов. После обновления проверьте работоспособность по списку страниц. Документируйте процедуру отката в случае критичных проблем после обновления.
Специфика для мультисайтовых инсталляций
Если на одном ядре Битрикс работает несколько сайтов, руководство должно чётко разграничивать: какие инфоблоки общие, какие — сайт-специфичные. Таблица b_iblock содержит поле SITE_ID. Администратор должен понимать, что изменение «общего» инфоблока затронет все сайты. Ошибка здесь стоит дорого: изменение в одном инфоблоке может незаметно сломать логику на других сайтах. Рекомендуем маркировать общие инфоблоки в руководстве желтым, сайт-специфичные — зеленым, чтобы визуально выделять критичные точки.
Что входит в работу?
Мы подготавливаем полное руководство администратора:
- Структурированная документация по всем разделам
- Скриншоты и шаблоны карточек инфоблоков
- Инструкции по техническим процедурам (кеш, бэкап, обновления)
- Чек-лист поддержки актуальности
- Обучение администратора работе с документом
- Консультационная поддержка в течение месяца после сдачи
Процесс разработки и передачи
Работа начинается с детального собеседования с текущей администраторской и технической командой. Мы определяем регламент обслуживания сайта, частоту обновлений контента и типичные ошибки администраторов. На основе этого создаём руководство, адаптированное именно под вашу инсталляцию. Затем проводим обучающую сессию с администраторами и оставляем контакт для вопросов в течение месяца. Документация хранится на защищённом облачном сервисе с версионированием и истории изменений.
Более 5 лет на рынке, 50+ реализованных проектов на Битрикс. Закажите руководство — получите документ, который сэкономит время вашей команде.