Нет, гигагерцы!
«Несколько лет назад, кажется в 2014 году, пришел как-то к нам на поддержку новый клиент.
У клиента много баз, много интеграций между ними. База, где ведется основной учет, за несколько лет переписана до неузнаваемости. Причем в разные моменты ее дорабатывали разработчики очень разной квалификации. Никакой документации нет, технических заданий нет, спросить в случае чего не у кого. Плюс ко всему, совместно с переходом к нам на поддержку происходил также и переезд с собственных серверов в забугорский дата-центр (в компании была реструктуризация), что также добавляло изрядное количество проблем. Все это добро свалилось к нам одномоментно, практически без каких-либо нормальных процессов приемки-передачи. В общем, никогда такого не было, и вот опять!
Клиент большой, важный и требовательный (а есть другие?). Начинаем в ускоренном порядке въезжать в его бизнес-процессы, знакомиться с IT-службой, настраивать сервера, обрабатывать заявки. Вдруг, в какой-то момент встает обмен между двумя самыми главными, самыми важными информационными базами. Обмен полностью самописный. Никаких вам универсальных механизмов, правил обмена, EnterpriceData или чего-то подобного. Из одной базы COM-ом цепляемся в другую базу, собираем данные и погнали. Только код, только Hardcore!
Итак, обмен не работает. Ошибка абсолютно невразумительная и непонятная: «в данной транзакции уже происходили ошибки». ОК, уже происходили, понятно, вернее — не понятно, дальше что?
Ладно, открываю конфигуратор в боевой базе (нет времени собирать какие-то тестовые стенды), ставлю точки останова, запускаю обмен. Выявил процедуру, где возникает ошибка. Уже хорошо. В этой процедуре также ставлю точку останова и иду построчно по F10. Пытаюсь уже здесь выловить злосчастную строчку, где все падает, и… обмен проходит без ошибок. Что за чертовщина? Но времени разбираться нет. Отписываемся клиенту, что обмен прогрузили, и едем дальше разруливать заявки.
Но на следующий день (обмен ходил раз в сутки ночью) все опять повторяется. Регламентное задание не отработало. Та же ошибка. Снова конфигуратор, снова точки останова, F10, и снова обмен проходит без ошибок.
Ближе к вечеру разворачиваю тестовые базы на нужную дату. Запускаю обмен – ошибка! Ставлю в конфигураторе режим «Остановка по ошибке». Ошибка есть, остановки нет! Иду отладчиком построчно – нет ошибок! Начинаю верить в магию и параллельные миры. Еду домой, много думаю.
Следующий день уже знакомо начинается с того, что ночью обмен не прошел. Надо понимать, что все это происходило в режиме аврала. Сидеть несколько часов с задачей нет никакой возможности. В результате составили расписание: каждое утро дежурный разработчик открывал рабочий конфигуратор и прогонял обмен руками в режиме отладки. Это продолжалось пару недель, пока не разгребли более срочные задачи и не смогли заняться этой проблемой детально.
Причина же оказалась в следующем: в процессе обмена шла запись некоторых служебных данных в некоторый служебный регистр, причем регистр был периодический с периодом в 1 секунду. Когда обмен запускался регламентным заданием, происходила запись в этот регистр одинаковых данных, соответственно обмен падал с ошибкой «запись не уникальна». Когда шли отладкой, между итерациями проходило больше одной секунды и все служебные данные записывались в регистр без ошибок. Остановка по ошибке не срабатывала, т.к. как весь обмен был написан «в попытке», а до этого момента в вышестоящей процедуре также была исключительная ситуация, которая на результат обмена не влияла, но не давала отловить ошибку записи в регистр (привет разработчику, который это написал).
Возникает вопрос, почему же раньше все работало? А помните про переезд в дата-центр? Раньше сервера были старые, медленные и ситуаций записи в регистр в рамках одной секунды не возникало. А новые сервера работали так быстро, что между итерациями цикла (где и была запись) проходило меньше секунды.
Via Виталий Онянов
Присоединяйтесь к ОК, чтобы подписаться на группу и комментировать публикации.
Нет комментариев