«Вчера 1С работала нормально…» — и вот уже кипят телефоны, нервы, кофе

— СБиСик, спасай, у нас горит!
— Что случилось?
— Да ничего нового, просто вчера работало, а сегодня «1С ошибка», документы не проводят, отчётность висит.
— Хм, значит, где-то ночью тихонько щёлкнул тумблер. Давайте искать, что именно щёлкнуло.

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

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

Почему «вчера работало» ничего не объясняет

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

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

Поэтому первый закон нашего клуба: не ищем, кто виноват, ищем, что изменилось. И если клиент упирает: «Мы ничего не трогали», я мягко улыбаюсь: «Ок, тогда трогала Вселенная. Смотрим логи Windows».

Что может поменяться за одну ночь

Люблю рассказывать это как историю крестиков-ноликов. Берём три поля: клиент, сервер, база. В каждом поле ночью кто-то может поставить новый крестик.

1. Сторона клиента
— Автообновление Windows, поменялся драйвер сетевой карты — как результат, медленный пинг до сервера.
— Антивирус словил сигнатуру и отправил файл rphost в карантин, а пользователь клянётся, что «ничего не устанавливал».
— Закончилось место на диске, кэш базы перестал записываться, логин висит на «Подключение к инфобазе…».
— Вчера Вася сидел в офисе по гигабиту, сегодня дома по Wi-Fi через три стены.

2. Сервер и сеть
— Ночь — лучшее время для бэкапов. Дисков массиву стало тесно, и теперь каждый SELECT ждёт, когда RAID передумает греметь.
— Сисадмин поставил cumulative update на Windows Server, а вместе с ним — новую версию драйвера HASP. Утром лицензии «не видят ключ».
— Ротация логов SQL сервера не пролезла через лимит, и база теперь пишет в тот самый диск «C:» с 5% свободного места.

3. Сама база и конфа
— Ночью автообновление релиза: добавился новый индекс, но перед этим утилита сняла старый; итого — 2 часа без индекса, а утром отчёт «Продажи за год» бежит 25 минут.
— Внешняя обработка «Сравнить цены поставщиков» лежала в расширении. После релиза её параметры конфликтуют с новым модулем, и пользователь видит «Неизвестное имя параметра» — классика.
— Кончился номер в регистраторе событий. Звучит экзотично, но я ловил: платформа 8.3.10, событие 65 535, дальше — обрыв «формата потока».

Я могу продолжать, но уже слышу за кадром голос: «Эй, СБиСик, а как понять, это локально у Оли или у всей базы?» — хорошая подводка к следующему блоку.

Локальная боль или системная катастрофа

Проверка на месте всегда начинается с простого вопроса: «Кто именно страдает?»

1. Только один человек
В 70% случаев причина живёт на его компьютере. Кэш, профиль, антивирус, права NTFS, забитый диск. Я однажды диагностировал тормоза пятиминутным тестом: перекинул ярлык базы на чистый ноут, вошёл под тем же пользователем — шустро. Вернулся на старый — тормозит. Всё, идём чистить TEMP. У нас даже мем про «Священное удаление catched files».

2. Группа пользователей
Обычно это сеть: один VLAN легчает, другой — душится. Или терминальный сервер раздал 30 сессий после перезапуска и завис на свопе. Тогда у главбуха открывается, а у склада висит. Ключевой тест — смена сети: подключаешь одного из страдальцев к гостевому Wi-Fi и смотришь, ожило или нет.

3. Вся компания
Это уже красная лампа: лицензия, служба ragent, блокировки в СУБД, криво доехавший релиз. Здесь спасают логи и метрика «когда именно началось». В 04:15? Значит, рядом ночной скрипт.

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

Ошибки мышления, которые удлиняют аварию

Неделю назад звонок: «1С не запускается, ждём когда вы приедете». Я спрашиваю: «Компьютер перезагружали, ладно. Саму службу «1С:Предприятие» на сервере проверяли?» — «Нет, мы же не трогали сервер». Ну конечно, ведь он святой. А служба тем временем легла после очередного «Security Update», и каждая минута ожидания вычёркивала строки из журнала регистрации, усложняя поиск.

Вот список ловушек, которые я вижу чаще всего:

1. «Если у всех, значит база»
Иногда «у всех» — это просто один терминальный сервер. У нас был случай: RDS 2012 отключил лицензии RemoteApp, пол-офиса «без 1С», другой половине повезло, они входили через старый RDP-шлюз и продолжали работать. База здесь вообще ни при чём.

2. «Если после обновления, виноват релиз»
Правда бывает наоборот: релиз наконец научился валидировать некорректные данные, которые жили в регистре два года. Обновление не сломало, оно вскрыло. Долг болтается на поверхности, просто его теперь видно.

3. «Документ не проводится — значит баг в коде»
Иногда да, но чаще — нарушена взаимосвязь остатков или ролей доступа. У бухгалтера нет права на новый реквизит, а разработчик добавил его в «позавчерашней» доработке.

4. «Перезапустим всё, авось починится»
Перезапуск — как лось в хрустальной лавке. Может помочь, но уничтожит ценные следы: номера блокировок, тайм-стампы, состояния служб. Я обычно сначала сохраняю скрины диспетчера блокировок, копирую последние 200 строк lgs-файла, только потом предлагаю рестарт.

Кейс из склада: всё летало, пока не сменили компьютер

Реальная история трёхдневной давности. На складе УТ 11, новый ПК на Windows 11, всё актуально. Девушка-кладовщик жалуется: «Тормозит подбор, картинка номенклатуры встаёт на паузу». У остальных — норм. Проверяю: пинг 1 мс, сигнал Wi-Fi отличный, база на SQL 2019, нагрузка смешная. Но! В логах 1С только на её клиенте — пачки «Warning: cpu time 3000 ms, wait io 0 ms». Греется проц. Лезу в диспетчер задач: Intel Graphics Control ловит 40% CPU, пока 1С отрисовывает превью. Ставим свежий драйвер видеокарты — и чудо, документ собирается за 1,5 секунды. А ведь если бы я поверил «вчера работало», пошёл бы шерстить базу, индексы, журнал регистрации, потратил бы полдня зря.

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

Отчего же «нормально» вчера могло быть иллюзией

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

Ещё один пласт — «спящие» ошибки в данных. В базе ЗУП мы как-то нашли три документа «Отражение зарплаты в регл. учёте» с одинаковым номером. Год стояли, никому не мешали, пока не пришло обновление, которое внезапно стало проверять уникальность номера. Бухгалтер: «Никто ничего не менял, после обновления всё упало». А база шепчет: «Эй, я болела давно».

Получается, «работает» — это не факт, а состояние «не протестировали на этот сценарий». Нужен другой взгляд: фиксировать метрики каждый день. Если вчера отчёт шёл 15 секунд, а сегодня 25 — это уже звоночек, ещё до паники «сломалось!». Но статистику обычно не ведут, поэтому наблюдают только контраст.

Три быстрых вопроса для старта расследования

1. Когда точно заметили? Чем точнее время, тем легче найти соседнее событие в журналах SQL, Windows, «1С:Предприятие».

2. Кого зацепило? Один ПК, терминальный сервер, все пользователи. Без ответа на этот вопрос бесполезно бросаться вглубь.

3. Что могли менять ночью или ранним утром? Бэкапы, планировщик, агент SQL, расценки, крон на Linux-сервере с хранилищем, правки конфы — выписываем всё. Даже если думаете, что «не касается», запишите, потом пригодится.

В половине случаев уже на этом этапе вылезает подсказка: «О, да, запускали утилиту проверки диска, и после неё сервер не перезагружали». Или «SQL переиндексировал регистры, но не перестроил статистику».

Идём глубже: что происходит внутри платформы

Здесь важно принять простую идею: платформа 1С — это не монолит, а куча служб и процессов. rphost, ragent, ras, сервер лицензирования, хранилище кэша, COM-соединения. Один пошёл в стопор — начинается каскадная деградация. Я обычно открываю диспетчер служб и смотрю, не застрял ли ragent в «Stopping». Если «просит» больше 30 секунд — уже плохо. Команда tasklist /svc быстро расскажет, кто съел память. А ещё лучше — вынести на графики: как только ram_usage rphost прыгает до 1,5 Гб, знаем, что где-то зациклилась тяжёлая форма.

Важно и то, что интерфейс может открываться, а процессы уже дерутся за блокировки. Пользователь кликает по кнопке «Провести и закрыть», видит крутящийся кружок и думает, что «1С зависла». На самом деле регламентный отчёт открыл транзакцию и жмёт ту же таблицу. Журнал блокировок покажет — да, там separate session 25 минут держит эксклюзив. Тут либо убить процесс, либо дождаться. Но без журнала не догадуваться.

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

Чего боится «ночное обновление»

Самый частый триггер фразы «вчера работало» — автоматический апдейт, который выкатывают, пока люди спят. Кажется, логично: никто не нажмёт лишнюю кнопку. На деле же ночь — это лаборатория Штейнмана: мало памяти, включён бэкап, на диске мелькают десятки temp-файлов, а в это же время платформа перекраивает таблицы. Один сбой на RAID — и утренний «формат потока» превращается в глобальную 1с ошибку.

Что делать? Главный принцип — «развязываем узел по нитке». Увидели, что апдейт шёл с 02:00 до 02:19 — идём в логи SQL именно за этот интервал. Если там чисто, проверяем, не закончился ли place on disk во время восстановления индексов. Отдельный пункт — расширения: платформа сначала отключает их, потом грузит заново. Если файл .cfe лежит на сетевом шаре, а шаре подвисла сетевая карта, — расширение не подхватится и половина обработок исчезнет из меню. Пользователь восклицает «пропали кнопки», а причина — просто пустой reconnect.

Разбор четырёх горячих кейсов

1. Лицензия погасла, но база открывается
Клиенты коннектятся по толстому клиенту, ключи USB вставлены, всё чинно. Но каждые три минуты сессия отваливается с ошибкой 1114. Почему? Ночью обновили драйвер HASP, он перезапустил службу, а прав в системе мало — служба встала в «Starting». Диагностика простая: net start hasplms → зависание. Исправили права, перезапустили — всё, «вчера работало» снова сегодня. Кстати, это отличный пример того, как исправить 1С за пять минут, если знать, где щёлкнуть.

2. «Длинный» отчёт стал вечным
ERP, отчёт «АВС-анализ за год». Вчера 7 секунд, сегодня 4 минуты. В журнале регистрации видно: планировщик в 03:00 пересобрал статистику, но в 03:01 начался бэкап, забрав I/O. В результате оптимизатор выбрал Nested Loops вместо Hash Join. Решили перекроем — перестроили статистику ещё раз вручную, скорость вернулась. Пользователь удивился, насколько тонко балансируют «нормально» и «катастрофа».

3. «Не могу провести документ, прав хватает»
ЗУП, начисление премии. После релиза добавили реквизит «КатегорияЗП», а в роли «Кадровик» забыли выдать права на запрос к новому регистру. Базывая роль «Бухгалтер» документ проводит, кадровики — нет. Ошибка «Недостаточно прав» не появляется, вместо неё тихое «Объект не найден». Обычная ловушка: платформа прячет причину за generic-сообщением. Лекарство: включить профилировщик прав — сразу видно, на какой таблице Access Denied.

4. «Файл обмена с маркетплейсом падает на 32-й строке»
УТ 11, внешняя обработка писалась год назад. Вчера маркетплейс расширил формат JSON — добавил поле «parentSku». Код на стороне 1С не знает такого параметра и валится. Пользователь орёт: «Мы же не трогали код!» — и формально прав. Трогал внешнее API. Мораль простая: если обмен зависит от чужого сервиса, «вчера работало» ни о чём не говорит — смотрим changelog поставщика.

Быстрый чек-лист: 15-минутная разведка

1. Что именно не так? Ошибка, зависание, пропажа элементов? Записываем точный текст, делаем скрин, фиксируем время.

2. Кого задело? Один ПК → копаем клиент, много ПК → сеть, все → сервер/база.

3. Что меняли с вечера? Апдейт Windows, антивирус, релиз конфигурации, драйвер принтера, плановые работы дата-центра. Отмечаем даже то, что «не должно влиять» — обычно влияет именно оно.

4. Есть ли логи? Журнал регистрации 1С, eventlog Windows, error-лог SQL, отчёт мониторинга сети. Нет логов — делаем их, дальше бессмысленно гадать.

5. Можно ли воспроизвести на тестовой базе? Если да — спасены: меняем параметры, смотрим, на каком шаге рвётся. Если нет — значит сбой окружения, а не данных.

6. Точка отката? Всегда держите под рукой прошлый релиз платформы и конфигурации. Не для немедленного даунгрейда, а чтобы проверить гипотезу: ставим старую платформу рядом, подключаемся — проблема остаётся? Значит, ищем глубже.

Ошибка выжившего: «ну перезапустили, и всё прошло»

Это ловушка номер один. Быстрое «исправили» без анализа кормит будущую аварию. Перезагрузка сервера смыла блокировки, и база ожила — круто. Но через неделю та же транзакция опять встанет колом, только ближе к концу квартала, когда вокруг будет в десять раз больше сессий. Протоколируйте причину, даже если кажется мелочью. Иначе каждый раз будете слышать то же «вчера работало» всё более нервным тоном.

Чего стоит избегать администратору

1. Игнорировать мелкие жалобы
Если сегодня отчёт вместо 10 секунд идёт 18, это не «нормально». Это ранний сигнал. Завтра будет 180. Ведите простую табличку метрик, чтобы цифры были, а не ощущения.

2. Зачищать журнал регистрации раньше времени
Часто вижу cron, который стирает всё старше суток. До обеда пол-дня логов уже потерян. Дайте себе хотя бы трёхдневное окно.

3. Делать релиз без бэкапа
Звучит банально, но админы иногда верят, что «git всё хранит». Да, хранит код, но не данные. Один неожиданный DROP INDEX — и вот вы уже ищете, как вчера работало, хоть чем-то помочь.

Наблюдения из практики

• Чем моложе база, тем громче падение: нет статистики, нет индексов, нет кеша, зато пользователь сразу замечает лаг.
• Терминальные фермы RDS любят валиться после Update KB5005568 — служба лицензий RDS не стартует, 1С падает без окна и кажется, что «не запускается совсем».
• Внешние отчёты на COM-объектах Office ломаются не при апдейте 1С, а при обновлении Excel. Но звонок всё равно идёт нам, потому что «1С не печатает Эксель».

• 70 % запросов «как исправить 1С» решаются удалением кеша в %APPDATA%\1C — грустная, но честная статистика. Пользователь видит магию, мы — закономерность.

Финал

«Вчера работало» — это не упрёк и не оправдание. Это просто отметка на тайм-лайне, от которой начинает плясать поиск. Держите логи длиннее, метрики — под рукой, а голову — холодной. Вопрос «что изменилось?» по-прежнему самый дешёвый и самый ценный инструмент диагностики. Кстати, а какие изменения за последнюю неделю ловили вы? Напишите, обсудим — вдруг спасём чью-то нервную среду.