Недоступность 1С — понятие настолько широкое, что само по себе почти ничего не означает. Пользователь описывает не причину, а собственное ощущение: работа встала.
За одной и той же фразой скрываются принципиально разные события — от выдернутого сетевого кабеля на рабочем месте до заблокированной администратором базы, остановленной службы или переполненного диска на сервере СУБД.
Более того, пользователи регулярно называют недоступностью то, что формально ею не является. Система отвечает, сеанс жив, база работает, но документ проводится сорок секунд, форма списка открывается с задержкой, а отчёт «висит».
С точки зрения пользователя это неотличимо от отказа: работать нельзя. С точки зрения администратора это деградация производительности — другой класс проблемы, с другими методами диагностики и устранения.
Отдельная сложность в том, что самое ценное свидетельство обычно теряется. Лучшее описание проблемы — снимок экрана с текстом сообщения, которое выдала система.
Но у пользователя выработан рефлекс — закрыть непонятное окно и только потом обратиться в поддержку. В результате специалист получает не факт, а пересказ.
Поэтому первая задача при обращении — не устранение, а локализация. Пока неизвестно, в каком слое инфраструктуры находится причина, любые действия будут перебором вариантов.
Локализация проблемы
Проблема у одного пользователя или у всех? Это главный вопрос отсечения. Единичный случай уводит на рабочее место, канал связи или лицензию. Массовый — на сервер, базу или инфраструктуру в целом.
Что именно происходит? Приложение не запускается, не находит сервер, разрывает сеанс, выдаёт сообщение о блокировке или просто работает недопустимо медленно — это четыре разных сценария.
Что менялось за последние сутки? Обновление платформы или конфигурации, установка расширения, обновления операционной системы, изменения на сетевом оборудовании, регламентные работы. Подавляющее большинство внезапных отказов имеет вполне конкретную причину в недавних изменениях.
Ответы на эти три вопроса, как правило, сокращают область поиска. Дальше имеет смысл разбирать проблемы уже предметно.
Четыре области возникновения проблем
Инфраструктуру учетной системы удобно рассматривать как последовательность слоев:
- рабочее место пользователя;
- сеть и каналы связи;
- сервер с ресурсами и службами;
- сама база с платформой и конфигурацией.
Отказ в любом из них выглядит для пользователя одинаково, но устраняется по-разному.
Рисунок 1 — Четыре области: признак → типичные причины → первое действие
Лицензирование
Сквозной темой, проходящей через все слои, стоит лицензирование — оно способно остановить работу и на клиенте, и на сервере.
Лицензирование при этом не образует собственного слоя: отказать может и локальный ключ на рабочем месте, и сервер лицензирования, и сетевой доступ к нему. При этом программная лицензия чувствительна к изменению конфигурации оборудования.
Два правила снимают большую часть проблем четвёртой области ещё до их возникновения.
- Первое: резервная копия делается до начала любых работ с учётной системой, а не после.
- Второе: наличие тестового контура, на котором обновление проверяется заранее, кратно сокращает вероятность отказа в продуктивной среде.
Быстрая диагностика проблемы
Пользователь обращается в поддержку — она позволяет отнести обращение к области, даже если человек не смог описать симптом точно.
| Обращение пользователя | Вероятная область | Первое действие |
|---|---|---|
| Не работает только у меня, у коллег всё нормально | Рабочее место или канал связи | Проверить доступность других внутренних ресурсов и состояние VPN |
| Не работает у всех одновременно | Сервер, база, лицензирование | Проверить службы 1С и СУБД, свободное место, журнал регистрации |
| Сервер 1С не обнаружен, соединение не установлено | Службы на сервере или сетевой доступ к порту | Проверить состояние агента сервера, доступность портов кластера |
| Сообщение о блокировке или регламентных работах | Администрирование базы | Уточнить у администратора статус и срок работ |
| Не найдена лицензия, превышено число сеансов | Лицензирование | Проверить сервер лицензирования, ключ, зависшие сеансы |
| Всё открывается, но невыносимо медленно | Ресурсы сервера, блокировки, тяжёлые запросы | Снять метрики CPU, памяти, дисков, посмотреть фоновые задания |
| Перестало работать сразу после обновления | Платформа, конфигурация, расширения | Сверить версии клиента и сервера, отключить расширения |
| Выкидывает из базы через некоторое время | Сеть, тайм-ауты, ресурсы, лицензии | Проверить стабильность канала и загрузку сервера |
Таблица 1 — Реакция на обращение пользователей
Вывод
Недоступность 1С — это собирательное название для целого набора не связанных между собой отказов. Поэтому работа по обращению всегда состоит из двух последовательных этапов, и порядок здесь принципиален.
Сначала — локализация. Определить, единичная проблема или массовая, зафиксировать точную формулировку сообщения об ошибке, выяснить, что менялось в системе, и на основании этого отнести отказ к конкретной области: рабочее место, сеть, сервер, база и конфигурация или лицензирование.
Только после этого — принятие мер по устранению, уже адресных, в рамках выявленной области. Попытка устранять до локализации превращается в перебор гипотез, а перебор в проде — это дополнительный простой и риск усугубить ситуацию.
Полезно закреплять две вещи в регламенте, а не в устной договорённости.
- Первое: пользователь по возможности присылает снимок экрана с текстом сообщения — это единственный способ не потерять самую информативную часть диагностики.
- Второе: любым работам с учётной системой предшествует резервная копия, а сами работы по возможности обкатываются на тестовом контуре.
Наконец, главное. Все перечисленные отказы решаются достаточно оперативно, но сам факт того, что потенциальная проблема была доведена до сбоя, нарушает основной принцип службы поддержки — проактивность и исключение простоя.
Заканчивающееся место на диске, растущая очередь к дисковой подсистеме, увеличивающееся время отклика, приближение к лимиту лицензий, остановившаяся служба — всё это контролируется, и сбой исключается при своевременной реакции на алерты от мониторинга.
От реакции на жалобы — к предупреждению инцидентов
Настроенная система мониторинга переводит работу из режима реагирования на жалобы в режим предупреждения инцидентов: проблема фиксируется на этапе потенциального сбоя, а не на этапе остановки бизнеса. Это и есть разница между поддержкой, которая чинит недоступность, и поддержкой, при которой недоступность не наступает.
