Добрый день!

Прошу помощи в непростой для меня ситуации. Я работаю системным администратором в компании, которая наняла разработчиков для написания информационной системой с бэкендом на 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]Ошибку сети выдаёт, зараза..


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

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

iscrafmРеалистпропущено...
Если разработчик знает о таком поведении, то он просто обязан предусмотреть обработку возникновения подобных ситуаций.
Ты просто не сталкивался похоже. Программа не получает никаких сигналов о том, что сети уже нет.Ок, ну не получает она ответа от сети. Или сервер сдох. Или FB вылетел с ошибкой. В моём понимании может быть тысяча и одна причина, почему данные, которые запросил клиент не могут быть пересланы - и во всех этих причинах пользователь должен видеть белое окно зависшего софта?

Всесто того, чтоб заниматься этой идиотией - просто повыключай в сетевых адаптерах везде такую хрень, как tcp/udp offloading, и checksum до кучи.
Может ещё DEP, антивирус и брандмауер отключать, от греха подальше? Используется отнюдь не самосборное оборудование, официально сертифицированное и совместимое с Windows Server, и что-то мне подсказывает, что проблема в другом месте.


Проблема эта не нова, и проявляется на hp procurve довольно стабильно
В статье по ссылке объясняются особености обработки сетевых подключений и софтовые же методы борьбы с этим. Никакой связи с оборудованием и коммутаторами НР я тут не вижу. Гугл найти связь тоже не помог. Ну и доверия к НР у меня больше, чем к этим конкретным разработчикам.

iscrafmSchastlivyМожет ещё DEP, антивирус и брандмауер отключать, от греха подальше?
Вы такие вопросы про сервер задаете?
Это сарказм на рекомендацию отключения tcp offloading на брендовом сертифицированном MS сервере =)

iscrafmSchastlivyпропущено...

Это сарказм на рекомендацию отключения tcp offloading на брендовом сертифицированном MS сервере =)
не понял сарказма. Про брендовый какой-то сервер тоже сарказм?

Человек с именем "Но грекс знает верный ответ" рекомендует мне отключать tcp offloading на серверах. Для брендовых и сертифицированных MS серверов, я приравниваю этот совет к рекомендации отключить DEP, антивирус или брандмауер. К снижению безопасности, этот пункт не приводит, но вот к возрастанию нагрузки на CPU - вполне. Я не прав?

P.S. Мне кажется, что тема начинается скатываться во флуд и холивар. Для себя я вопрос прояснил, план действий составил (и диагности сети там тоже есть). Спасибо всем за советы, дальше можно продолжить холивар )

Опять грекаА с кривыми файрволлами, которые дропают dnat соединения по таймауту, и про tcp keepalive ты тоже видать не в курсе.Сталкивался я с разными глюками, но их количество на нормальном железе и софте как правило стремиться к нулю.

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

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

Да что-ж вы так прицепились-то к моей любви к брендовому железу - любовь и уважение не означают ярый фанатизм и выдавание желаемого за действительное. То, что глюки у них есть - я и не отрицал никогда. А вот ваше выгораживание разработчиков, чей продукт вы даже в глаза не видели - глупость полнейшая. Я намеренно не называю разработчиков и их продукт (продукт не индивидуальный, но и на массовость он точно не тянет) - ибо с более глючной и настолько кривой внешне системой я ещё не сталкивался. Частично вас понять можно - солидарность к колегам и прочее, но если бы вы видели эту систему живьём - поверьте, на фонее неё используемое оборудование выглядит верхом надёжности. И именно поэтому, при невозможности диагностики, я скорее сделаю ставку на то, что глюк исходит от этого продукта, а не от сети и прочих компонентов - теорию вероятности и статистику отказов никто не отменял. Теперь моя логика вам понятна?
Касательности бОльшей надёжности и совместимости китайского оборудования - посмеялся =). Зайдите на форум нага, почитайте, какие весёлые глюки там народ с китайцами имеет. Багтрек у НР большой, да? Есть такое, но почему? А это потому, что этим оборудованием пользуется куча компаний по всему миру, гоняет его в хвост и в гриву и юзает весь заложенный в него функционал. И глюки эти признаются и оперативно фиксятся. И идут, как правило, по достаточно специфичным функциям. А вот у китайцев - шаг влево, шаг вправо - и не работает ничего. Да, фиксят, когда баг найдут и отправят им. Вот только из-за того, что пользует их много меньше народа и на менее ответственных местах - нарваться на глюки в них - раз плюнуть. А некоторые проблемы не исправляются впринципе (поищите на счёт совпадения хешей маков на длинковских свитчах DES-3028 - проблеме уже не первый год, а производитель по прожнему её игнорирует).
Стаж не буду называть принципиально - вы же не хотите передить на личности, потому что аргументы закончились?

miwaonline,

Ну так решение мне уже подсказали: сейчас деньги платятся на основании договора, в котором есть пункт о доработках в системе, устраняющих неудобства пользователей. Соответственно под этот пункт и попадает выдача предупреждений и предложений перезапустить запрос к БД при обработке этого запроса дольше 10-30 секунд =) Как бы всё очень логично и правильно оказывается, и с точки зрения ТЗ, и с точки зрения здравого смысла.