Ping проходит, но пользователи снова не могут войти в 1С. Вы перезапускаете службу, работа возвращается, а через неделю ситуация повторяется.
Ping подтверждает доступность узла по сети. Он ничего не говорит о состоянии кластера 1С, СУБД, ОС и внешних сервисов. На это ограничение указывает разбор инцидентов 1С от Infostart.
В принятой от другого администратора инфраструктуре перезапуск особенно мешает расследованию. Симптом исчезает, а события остаются в разных журналах без общей временной линии.
Ваша задача — не вернуть систему в строй ещё один раз. Нужно понять, где начался сбой, доказать причину владельцу системы и изменить условие его повторения.
Чем расследование отличается от устранения симптома
Перезапуск rphost восстанавливает работу процесса. Но сам по себе он не объясняет, почему процесс завершился и повторится ли авария.
Root Cause Analysis, или RCA, ищет условие, без которого происшествие не случилось бы. В методическом руководстве OneUptime готовое расследование отвечает на три вопроса:
- что произошло;
- почему это произошло;
- как предотвратить повторение.
Последний вопрос отделяет расследование от обычной диагностики. Если итог сводится к «перезапустили службу», причина осталась в системе.
Не смешивайте корневую причину с сопутствующим фактором. OneUptime называет сопутствующим условие, которое усилило происшествие или повысило его вероятность, но не запустило основную цепочку.
Например, высокая нагрузка могла приблизить исчерпание файловых дескрипторов. Но если аварию запустил оставленный лимит ОС, исправлять нужно именно лимит.
Сначала сохраните хронологию
До изменения настроек зафиксируйте состояние системы. Иначе вы сами измените часть свидетельств, по которым предстоит восстановить ход происшествия.
Запишите время первого обращения пользователя и время восстановления. Уточните, какие сеансы, базы и операции пострадали. Отдельно отметьте действия администратора после обращения.
Затем соберите события компонентов в одну временную линию. SimpleOne относит логи, метрики и хронологию к данным, на которых должны строиться выводы RCA.
Для 1С понадобятся сведения из нескольких мест. Стороннее руководство 1C Expert описывает их так:
- журнал кластера хранит события управления сессиями, подключений и работы диспетчера;
- журнал информационной базы фиксирует действия пользователей, ошибки и изменения данных;
- журнал событий Windows содержит запись об аварийном завершении
rphost.exe; - вывод
rac cluster dumpinfoпоказывает текущие сессии и процессы кластера.
Снимайте показания с часов каждого узла. Если время сервера СУБД отстаёт от сервера 1С, события могут поменяться местами и дать ложную причинную цепочку.
| Наблюдение | Где подтвердить | Что оно доказывает | Чего пока не доказывает |
|---|---|---|---|
| Закрылся один клиент | Журнал ОС клиента, журнал базы, время обращения | Сбой затронул конкретный сеанс или рабочее место | Что сервер 1С работал без ошибок |
| Оборвались несколько сеансов | Журнал кластера, обращения пользователей, состояние процессов | Граница сбоя шире одного клиента | Что причиной стал кластер |
Завершился rphost.exe | Журнал событий Windows и журнал кластера | Рабочий процесс завершился аварийно | Почему он завершился |
| Операция ждала блокировку | Журнал базы, пользователь и сеанс блокировки | Ожидание связано с конкретной транзакцией | Что блокировка стала корневой причиной всего инцидента |
| Остановился внешний обмен | Журналы интеграции, ОС и сетевого узла | Нарушился определённый участок обмена | Что ошибка находится внутри 1С |
Один сигнал задаёт направление проверки. Корневую причину он ещё не доказывает.
Если клиенты закрылись без сообщения, сначала отделите одиночный вылет от общего отказа. Масштаб происшествия сократит число рабочих гипотез.
Не включайте подробную регистрацию всех событий бессрочно. Руководство 1C Expert предупреждает о нагрузке на сервер и быстром росте занятого места при таком режиме.
Проведите границу сбоя
Начните не с привычного подозреваемого, а с масштаба. Сбой мог затронуть одного пользователя, одну операцию, одну базу или весь сервер.
После этого пройдите путь запроса: клиент, кластер 1С, СУБД, ОС, сеть, внешний сервис. Разбор Infostart подчёркивает, что причина может находиться на любом связанном слое.
Граница нужна, чтобы отсеять версии, которые не объясняют все наблюдения. Если одновременно оборвались сеансы с разных рабочих мест, переустановка одного клиента не отвечает масштабу происшествия.
Если не открывается только одна база, общий отказ сети тоже выглядит слабой версией. Ищите отличие этой базы: СУБД, фоновые задания, расширения или интеграции.
| Граница сбоя | Рабочая гипотеза | Проверяемое свидетельство | Следующий шаг |
|---|---|---|---|
| Один клиент | Ошибка клиентского процесса или рабочего места | Событие ОС совпало со временем вылета, остальные сеансы продолжили работу | Проверить клиент и повторить ту же операцию с другого места |
| Несколько сеансов одного процесса | Авария rphost | В Windows записано завершение процесса, журнал кластера показывает потерянные сеансы | Сопоставить событие с ресурсами ОС и действиями пользователей |
| Одна база | Блокировка, регламентное задание или ошибка на стороне СУБД | События относятся к одной информационной базе | Проверить транзакции, обслуживание СУБД и задания этой базы |
| Все базы сервера | Сбой кластера, ОС или общего ресурса | Одновременно пострадали независимые базы | Проверить процессы сервера, память, диск и общие службы |
| Только внешний обмен | Ошибка связности или стороннего сервиса | Пользователи работают, но API, HTTP-сервис или очередь недоступны | Проверить маршрут, порт, протокол и журнал второй стороны |
| Виртуальные серверы на одном хосте | Нехватка ресурса за пределами гостевой ОС | Проблемы совпали по времени у нескольких виртуальных машин | Сопоставить события гостевых ОС с показателями гипервизора |
Граница сбоя показывает, где проверять следующую версию. Она не назначает виновный компонент заранее.
При общей медленной работе используйте разделение задержки по сеансу, базе и серверу. Для виртуальной среды продолжите проверку за пределами гостевой ОС.
Записывайте гипотезы так, чтобы их можно было опровергнуть
Фраза «наверное, кончилась память» плохо подходит для расследования. Она не задаёт признак, который подтвердит или отвергнет версию.
Рабочая гипотеза выглядит иначе: «rphost завершился из-за ограничения ресурса ОС; перед аварией ресурс достиг предела». Теперь понятно, какие данные искать и с чем сопоставлять время события.
Для каждой версии нужны три совпадения:
- Она объясняет наблюдаемый симптом и его масштаб.
- Временная линия подтверждает нужную последовательность событий.
- После целевого исправления проверяемый признак исчезает.
Первые два совпадения доказывают связь с происшествием. Третье проверяет, что вы изменили причину, а не замаскировали её.
Не останавливайтесь на первой правдоподобной версии. SimpleOne относит поспешный вывод без достаточных доказательств к типовым ошибкам RCA.
Не заканчивайте расследование формулировкой «ошибся оператор». Она называет участника, но не объясняет, почему система приняла опасное действие и не остановила его.
Ищите недостающий контроль, неясный порядок или техническое ограничение. SimpleOne рекомендует исследовать систему и процессы, а не искать виновного сотрудника.
Пример: Too many open files
Сообщение Too many open files означает, что процесс исчерпал доступные файловые дескрипторы. Такой пример приводит Infostart в разборе инцидентов 1С на Linux.
Сообщение подтверждает механизм отказа, но ещё не завершает расследование. Нужно выяснить, почему рабочий сервис достиг предела именно при штатной нагрузке.
В статье Infostart корневое условие связано с настройками Linux по умолчанию. Под промышленной нагрузкой сервер 1С может упереться в лимит открытых файлов.
Цепочка расследования может выглядеть так:
- пользователи потеряли соединение с 1С;
- журнал зафиксировал
Too many open files; - процесс достиг ограничения ОС;
- для службы сохранился лимит, рассчитанный не под рабочую нагрузку;
- контроль настройки перед вводом сервера не проводился.
Частые обращения к файлам или рост нагрузки здесь могут быть сопутствующими условиями. Корневая причина — лимит службы, оставленный без проверки под фактическую эксплуатацию.
Лимит меняют через ulimit либо конфигурацию systemd. Способ зависит от того, как запускается служба, поэтому проверяйте итоговое значение у работающего процесса.
Перезапуск после изменения ещё не доказывает результат. Нужно подтвердить, что служба получила новый лимит и снова не достигает его при рабочей нагрузке.
«Пять почему» не требует ровно пяти ответов
Метод «пять почему» помогает пройти от события к условию, которое его породило. OneUptime уточняет: итераций может потребоваться меньше или больше пяти.
Не задавайте вопрос механически. Каждый следующий ответ должен опираться на факт и углублять ту же причинную цепочку.
Для Too many open files цепочка может закончиться на отсутствии проверки лимитов при вводе сервера. Дополнительные вопросы после этого уже уйдут в общие рассуждения.
Если версии расходятся, линейной цепочки мало. Диаграмма Исикавы группирует параллельные факторы, а дерево отказов связывает события операторами «И» и «ИЛИ».
Эти методы полезны при сложном отказе нескольких компонентов. Для одного подтверждённого ограничения ОС схема на полстраницы только затруднит отчёт.
Отделите причину от условий, которые усилили сбой
У одного происшествия может быть несколько заметных факторов. Они не получают одинаковый статус только потому, что встретились в одной временной линии.
Предположим, процесс завершился при вечернем обмене. Одновременно выросла нагрузка, накопилась устаревшая статистика СУБД и сработало ограничение ОС.
Корневой причиной станет условие, устранение которого предотвратило бы происшествие. Так определяет её руководство OneUptime.
Остальные условия запишите отдельно. Они могут требовать своих мер, но не должны подменять доказанный механизм отказа.
Разделение влияет и на приоритет работ. Сначала устраните условие повторения, затем снижайте тяжесть и вероятность сопутствующих сценариев.
Исправление должно менять условие повторения
Мера следует из доказанного факта. При лимите файлов меняют лимит службы; при устаревшей статистике восстанавливают обслуживание СУБД.
Для ошибки связности исправляют маршрут, порт или протокол на найденном участке. При конфликте расширения меняют порядок эксплуатации копии либо само расширение.
Формулировка «усилить мониторинг» слишком широкая. Запишите конкретный признак, порог реакции, канал уведомления и владельца.
OneUptime предлагает расставлять меры по четырём критериям: вероятность повторения, тяжесть последствий, стоимость исправления и охват систем. Пункт без ответственного остаётся намерением.
| Мера | Какой факт её обосновывает | Как проверить результат | Кто отвечает | Срок контроля |
|---|---|---|---|---|
| Изменить лимит открытых файлов службы | Процесс достиг действующего ограничения перед аварией | Проверить лимит работающего процесса и его запас под нагрузкой | Администратор Linux | После перезапуска и в следующий рабочий пик |
| Восстановить обслуживание статистики СУБД | Ожидания запросов совпали с устаревшей статистикой | Сопоставить обслуживание, планы запросов и повтор проблемной операции | Администратор СУБД | После обслуживания и по расписанию |
| Исправить сетевую связность | Ошибка обмена совпала с недоступностью нужного порта | Повторить обмен и проверить журнал обеих сторон | Сетевой администратор | Сразу после изменения и после плановой смены правил |
| Изменить эксплуатацию расширения | Сбой воспроизводится только при подключении копии или сложном отчёте | Повторить сценарий без конфликта | Администратор 1С | До следующего запуска операции |
| Добавить наблюдение за доказанным признаком | До аварии ресурс достиг предела без уведомления | Вызвать тестовое событие и проверить доставку сигнала | Владелец мониторинга | При настройке и по регламенту |
Расследование заканчивается проверяемым изменением. Сам отчёт не уменьшает вероятность нового сбоя.
Для задержек свяжите пользовательскую операцию с серверными событиями через сопоставление APDEX, техжурнала и показателей инфраструктуры. Это помогает отличить совпадение по времени от причинной связи.
Как оформить результат для следующего администратора
Отчёт должен пережить передачу системы. Через полгода его прочитает человек, который не участвовал в созвонах и не знает ваших сокращений.
Уложите вывод на один экран:
Что произошло → где началось → чем доказано → почему защита не сработала → что меняем → как проверим.
Для случая с файловыми дескрипторами запись получится конкретной. Процесс исчерпал лимит, событие подтверждено журналом, служба получила новое значение через systemd, результат проверен у работающего процесса.
Приложите временную линию и ссылки на сохранённые журналы. Отдельно перечислите отброшенные версии и факты, которые им противоречат.
Так следующий специалист не начнёт расследование с нуля. Он увидит, что уже проверили, какое условие изменили и когда нужно оценить результат.
Когда инцидент можно закрыть
Работающая после перезапуска 1С ещё не означает, что расследование закончено. Перед закрытием проверьте пять условий:
- хронология сохранена и сведена по времени;
- граница сбоя обозначена;
- причина подтверждена журналами, метриками или воспроизведением;
- сопутствующие факторы записаны отдельно;
- профилактическая мера получила владельца и способ проверки.
Если один пункт отсутствует, оставьте расследование открытым. Иначе следующий сбой снова начнётся с ping и перезапуска.