Добрый день!

Прошу помощи в непростой для меня ситуации. Я работаю системным администратором в компании, которая наняла разработчиков для написания информационной системой с бэкендом на FireBird 2.5. Сейчас, когда проект уже почти сдан, начала появляться проблема в виде зависания их программы - интерфейс зависает наглухо, висит пока не скинешь через таск-менеджер. В процессе совместной с разработчиками отладки, в логе FireBird были найдены сообщения об ошибке "INET/inet_error: read errno = 10054". Гугление привело к информации о том, что проблема связана с обрывом TCP соединения. Со стороны разрабатываемого ПО при этом не выдаётся никаких ошибок, программа также не пытается повторно установить соединение. Разработчики отказываются от любых доработок продукта, ссылаясь на то, что эти зависания являются следствием плохой настройки серверов и глючностью сети. Однако, в моём понимании, их ПО должно либо самостоятельно переоткрывать соединение, либо хотя бы выдавать сообщение об ошибке - ведь в текущей ситуации пользователи и начальство уверены, что эта проблема связана с производительностью серверов (дескать, раз программа зависла, значит всё медленно работает), но у меня есть логи, которые показывают, что серверы практически ненагружены.
Прошу совета, как правильно составить претензию, на какие нормативы можно ссылаться? Нутром понимаю, что есть общепринятые или даже задокументированные требования к такого рода приложениям, но куда копать - совершенно не понимаю. Сначала хотел сослаться на то, что сеть Ethernet - изначально ненадёжная среда, допускающая потери пакетов, но ведь TCP учитывает этот момент и TCP-сессия уже является достаточно надёжной и в теории не долна рваться просто так. В общем, дайте совет, на что акцентировать внимание.

Всем большое спасибо за ответы!

Кто принимал решение об использовании FireBird и языка разработки самого приложения? Был ли этот выбор сделан самими разработчиками или это было требование указано в самом ТЗ на разработку ПО?
БД выбирал разработчик, но на всякий случай проверю этот пункт в тз. Язык разработки точно не задавался жёстко.

для начало было бы неплохо найти дефектное сетевое оборудование по маршруту, такие ошибки на ровном месте не появляются. А потом, посмотреть, есть ли в договоре пункт о том, что заказчик обязан предоставить рабочее железо для программы и использование им кривого оборудования = проблемы заказчика.Заниматься детальной диагностикой сети, сейчас, к сожалению, возможности нет (сильно занят другой задачей), в голову приходит только посмотреть статистику потерь по SNMP. Глюк появляется всего несколько раз в день, уже в продакшен среде с ~100 клиентами. Сама сеть - коммутаторы HP, сервера Intel, с кабелями вроде проблем нет (до этого работало год без подобных проблем). Между серверами всего один свич. Есть ещё, правда, пару дешёвых пятипортовых свичей на перифии, но они уже в коммутаторы уровня доступа втыкаются. Но тем не менее: как же так?? Ну, глюкнула сеть, оборвалась сессия - почему ошибку или предупреждение не выкинуть??

Не факт. Очень многое зависит от глючности сети (глючный свич, плохой обжим, некачественный кабель), настроек ОС (таймаут для TCP, например) и других факторов, которые зависят от системного/сетевого администратора больше, чем от программиста
Ну так я на данном этапе не ставлю цель разработчикам устранить этот глюк - для этого действительно нужна нормальная диагностика, но она может очень сильно затянуться (сейчас параллельно другие задачи выполнять), и скорее всего действительно проблема окажется на моей стороне, вопрос об адекватной обработке такой ошибки со стороны разрабатываемого ПО.

[quot]
Я бы советовал копать в сторону полюбовного решения проблемы./Само собой до суда и финансовых претензий доводить не хотелось бы.

Касаемо претензий - копать в сторону договора, который вы подписали, и тех.задания, которое является неотъемлимой частью договора.
Для общего развития - в сторону фразы "гост на разработку программного обеспечения", забитой в поисковик.Сейчас пойду гуглить и изучать договор, буду искать, за что можно зацепиться.

Договор смотрите. Мы в своем, например, указываем, что без нормально настроенной рабочей среды все претензии отсылаются на йух.Что есть нормально настроенная рабочая среда? С юридической точки зрения?

Повторяется ли ошибка при каком-то конкретном режиме, тяжелом запросе? Или случайным образом в разных режимах, то проходит все нормально, то ошибка?Ошибка носит случайный характер, закономерностей в последовательности действий/используемом функционале/объёме выборки не замечено.

Воспроизводится ли ошибка на тех же данных, но на другом оборудовании (например, локально)? На том же оборудовании, но на других данных (на меньшем количестве данных)? На другой версии FireBird?Добиться стабильного воспроизведения даже в имеющейся среде не получается, пускать же пользователей не на терминальный сервер, а на сервер БД считаю достаточно странным методом диагностики (для тестирования локального запуска). Остальные пути диагностики пока откладываются, т.к. нет возможности детально ими заниматься.

После чего конкретно начала появляться ошибка? (обновление версии программы, наполнение БД реальными данными, обновление антивируса на серверах и т.п.)? Возможно ли восстановить прежнюю ситуацию, чтобы ошибка исчезла?Трудно сказать точно, было 2 события: переезд БД на новый сервер, и постоянные смены версий ПО разработчиками (об изменениях они нас частенько забывают уведомить)

[qout]
Сделайте для приёмки тестовую сеть\раб.место\стенд.
В ТЗ должны быть записаны правила приёмки ПО и параметры окружения.
ЗЫ. Самостоятельно переоткрывать не должна, если это не указано в ТЗ.
[/qout]Если в продакшене на 100 клиентов глюк появляется всего несколько раз в день у разных клиентов (каждый из них цепляется к базе напрямую), то, думаю, на тестовом стенде вопроизвести проблему просто не получиться. По поводу переоткрытия сессии - а это мысль! Мы можем внести этот пункт в тз на доработку в ближайшее время =)

[qout]
протестируйте наконец - выдерните сетевой кабель и посмотрите реакцию проги :))[/qout]Ошибку сети выдаёт, зараза..


В общем пойду пока с договором ознакомлюсь, диагностику будет возможно не раньше, чем через месяц выполнить

Оу, прошу прощения за сбитое цитирование, но кнопку редактирования не вижу совсем