Добавить в корзинуПозвонить
Найти в Дзене
АйТи на практике

Мы думали, что это просто медленная 1С. Через месяц клиент подал в суд

Все началось максимально безобидно. Позвонил руководитель компании. Спокойный голос, без паники: 1С стала медленнее работать. Документы открываются дольше, отчеты подвисают. Ничего критичного, но мешает. Такие обращения – рутина. Обычно там что-то из разряда «сервер подзабился», «база разрослась», «нужно чуть оптимизировать». Мы договорились посмотреть. На первой встрече картина выглядела именно так. Сотрудники жалуются, но работают.
Система не падает.
Ошибок нет. Просто медленно. И в голове автоматически включается режим: окей, не пожар. Можно разобраться планово. Сам руководитель тоже не форсировал. Сказал прямо: главное, чтобы совсем не встало. И это ключевой момент. Потому что когда нет боли, нет и ощущения риска. Когда начали разбираться, выяснилось, что тормозит не все подряд. Медленно открывались определенные документы.
Некоторые операции выполнялись с задержкой.
А часть процессов шла нормально. Это уже выглядело подозрительно. Потому что если проблема в сервере – тормозит все.
Оглавление

Все началось максимально безобидно.

Позвонил руководитель компании. Спокойный голос, без паники: 1С стала медленнее работать. Документы открываются дольше, отчеты подвисают. Ничего критичного, но мешает.

Такие обращения – рутина. Обычно там что-то из разряда «сервер подзабился», «база разрослась», «нужно чуть оптимизировать».

Мы договорились посмотреть.

«Да это не срочно»

На первой встрече картина выглядела именно так.

Сотрудники жалуются, но работают.
Система не падает.
Ошибок нет.

Просто медленно.

И в голове автоматически включается режим: окей, не пожар. Можно разобраться планово.

Сам руководитель тоже не форсировал. Сказал прямо: главное, чтобы совсем не встало.

И это ключевой момент.

Потому что когда нет боли, нет и ощущения риска.

Первые странности

Когда начали разбираться, выяснилось, что тормозит не все подряд.

Медленно открывались определенные документы.
Некоторые операции выполнялись с задержкой.
А часть процессов шла нормально.

Это уже выглядело подозрительно.

Потому что если проблема в сервере – тормозит все. Если в сети – тоже.

А здесь было избирательно.

Начали копать глубже.

Где спряталась проблема

Оказалось, что дело не в железе.

И не в классической «перегруженной базе».

Проблема была в одном из бизнес-процессов, завязанном на обмен данными.

Часть информации подтягивалась из внешней системы.
С задержкой.
Иногда – с ошибкой.

И самое неприятное – это не ломало процесс полностью.

Он продолжал работать.

Просто данные в моменте могли быть неактуальными.

Почему это не заметили сразу

Потому что система не кричала об ошибке.

Она делала вид, что все ок.

Документ создается.
Проводится.
Уходит дальше по цепочке.

Только данные внутри него могли отличаться от реальности.

И это не бросается в глаза.

Сотрудник видит цифры – значит, работает.

Где начинается цепная реакция

Дальше включается бизнес.

На основе этих данных формируются документы.
Они уходят клиентам.
По ним принимаются решения.

И если в начале цепочки есть небольшая неточность, к концу она превращается в проблему.

Но не сразу.

Сначала это «погрешность».
Потом «странность».
Потом «разберемся позже».

А потом уже поздно.

Момент, когда стало не до шуток

Через пару недель клиент компании начал задавать вопросы.

Почему цифры в документах не сходятся.
Почему условия отличаются от согласованных.
Почему данные «прыгают».

Сначала пытались объяснить. Где-то поправить вручную.

Но когда расхождения начали повторяться, ситуация вышла из-под контроля.

И в какой-то момент пришло уведомление.

Претензия.

А затем – суд.

Что оказалось причиной

Когда уже начали разбирать ситуацию под давлением, картина сложилась полностью.

Тот самый «незначительный» дефект в обмене данными.

Он давал небольшую задержку и иногда подтягивал устаревшую информацию.

Не всегда. Не критично на первый взгляд.

Но этого хватило.

Чтобы в документах появлялись расхождения.
Чтобы клиент принимал решения на неверных данных.
Чтобы накопился конфликт.

И в итоге – финансовые требования.

Самое неприятное

Не сам дефект.

А то, что его можно было поймать раньше.

Еще на этапе «просто медленно работает».

Потому что это уже был сигнал.

Не про скорость. Про нестабильность.

Но его восприняли как нечто второстепенное.

Не срочно. Не критично.

Разберемся потом.

Почему такие истории повторяются

Потому что бизнес делит проблемы на «важные» и «не очень».

Упало – важно.
Не работает – важно.
Тормозит – переживем.

И вот в этой категории «переживем» часто и сидят самые опасные вещи.

Те, которые не ломают систему сразу.

Но тихо влияют на данные.

А данные – это уже деньги.

Где здесь ИТ

ИТ в таких историях – это не только про «починить».

Это про вовремя увидеть, что за симптомом стоит нечто большее.

Не просто ускорить.
А понять, почему стало медленнее.

Потому что иногда скорость – это единственный сигнал, что система работает неправильно.

Чем все закончилось

Систему в итоге привели в порядок.

Нашли узкое место.
Исправили обмен.
Проверили цепочку данных.

Но это уже была работа с последствиями.

Потому что параллельно шли разбирательства.

И цена вопроса выросла в разы по сравнению с тем, что можно было сделать в начале.

Вопрос, который стоит задать себе заранее

Если у вас сейчас что-то «просто работает медленнее» – вы уверены, что это только про скорость?

Или за этим уже может скрываться проблема, которая пока просто не успела выстрелить?