«Я тут запустил TCP/IP, пытаюсь соединиться
с Windows-машиной, а оно не работает.
В чем дело?!?»
Первый ответ службы технической поддержки будет выглядеть примерно так (бьюсь об заклад, у них даже есть специальный шаблон для этого):
Что значит «не работает»? Вы имеете в виду TCP/IP на
стороне QNX или на стороне Windows? Какой модуль TCP/IP
не работает? Что вы пытаетесь сделать? Какие у вас
версии QNX и TCP/IP? Какая у вас версия Windows и какой
там TCP/IP?
Мораль сей басни такова: если у вас проблема, то вам, вероятно, надо ее решить быстро. Если вам нужен ответ на вопрос быстро, постарайтесь привести максимум информации о возникшей у вас проблеме в первом же запросе, чтобы специалисты технической поддержки QSSL сразу же смогли попробовать воспроизвести вашу проблемную ситуацию.
Существует ряд вещей, которые служба технической поддержки спрашивает всегда. К ним относятся:
• точное описание сбоя;
• версии программных продуктов;
• конфигурация системы;
• аппаратная платформа (x86, РРС, и т.д.)
Чтобы предоставить эту информацию, опишите, что вы ожидали, и что произошло на самом деле. Вышеприведенный пример выглядел бы гораздо лучше в таком варианте:
Я пытаюсь подсоединиться по telnet из QNX/Neutrino 2.00A к Windows-машине и сразу же после приглашения login получаю сообщение «Connection closed by foreign host».
Следующее, что следует указать, — это информация о версиях различных модулей, которые вы используете. Ее можно взять от команд ls
и cksum
. В случае с нашим примером хорошо было бы бы сообщить службе техподдержки, какая у вас версия команды telnet
, стека TCP/IP, и т.д.
# cd /usr/nto/x86
# ls -l bin/telnet dll/devn-ne2000.so dll/npi-ttcpip.so
-rwxr-xr-x 1 root root 71588 May 19 11:45 bin/telnet*
-rwxr-xr-x 1 root root 680928 May 19 11:05 dll/devn-no2000.so*
-rwxr-xr-x 1 root root 83765 Jun 02 06:39 dll/npi-ttcpip.so*
# cksum bin/telnet dll/devn-ne2000.so dll/npi-ttcpip.so
1574162245 71588 bin/telnet
3564123752 680928 dll/devn-ne2000.so
2582029317 83765 dll/npi-ttcpip.so
Это даст сотрудникам техотдела примерную картину дат, размеров и контрольных сумм ряда объектов, которые, возможно, связаны с проблемой. Отметьте строку «cd /usr/nto/x86
» — она говорит, что я использую средства разработки в версии для x86.
Если у вас есть подозрение, что проблема может быть связана с особенностями платформы, вам, безусловно, следует указать ее название, торговую марку (brand) и соответствующие применяемые в ней чипсеты.
Также служба технической поддержки, как правило, требует описания конфигурации вашей системы — особенно когда есть подозрение, что проблема связана с недостатком памяти, лицензированием, и т.п. Вы должны попытаться дать полную информацию относительно объема установленной памяти, количестве выполняющихся процессов, приблизительной степени загрузки, и т.д:
Чем более подробную информацию вы предоставите, тем быстрее вам смогут помочь.
Если вы используете бета-версию программного обеспечения (то есть вы подписаны на бета-программу QSSL), вся вышеперечисленная информация критична, потому ваши версии программного обеспечения, скорее всего, будут отличаться от официально выпущенных. Однако, имейте в виду, что в общем случае поддержка бета-версий по телефону в QSSL не предусмотрена, так что здесь единственный способ получить информацию — написать в телеконференцию или, если разработчик запрашивает прямой контакт с вами, поговорить с разработчиком напрямую.
В любом случае одним из лучших решений являются телеконференции, потому что они дают возможность и другим участникам видеть, какие есть проблемы, и как с ними быть (то есть если найдена ошибка, то какие есть обходные пути). Как бы там ни было, вышеупомянутая информация критична для определения того, какие именно программные продукты из бета-релиза вы применяете.
Также, если вы обмениваетесь информацией с разработчиком, то имейте в виду, что у него, как правило, есть еще тысяча дел, и он вряд ли сможет ответить на ваш запрос сразу. Дружеский «ping» спустя несколько дней молчания делу не повредит, а вот повторное требование ответа через 15 минут после запроса определенно не прибавит вам новых друзей.
Что часто проявляется при работе с бета-версиями, так это то, что люди забывают ставить обновления. Механизм же бета-тестирования работает так, что пропуск обновления запросто может заставить вашу систему вести себя странновато. Некоторые новые драйверы или администраторы ресурсов могут вести себя со своими клиентами совершенно иначе, чем в предыдущих версиях.
В этом случае вы должны быть уверены (потому что вас обязательно спросят!), что все обновления установлены, и в нужном порядке.
Один из первых вопросов персонала технической поддержки обычно звучит так: «А оно происходит исключительно с бухты-барахты, или вы можете это повторить намеренно?»
Это не праздное любопытство. Если проблема проявляется редко, она столь же серьезна, как и проблема, которая проявляется регулярно. Главное — понять, с какой стороны подойти.
Обычно в случае редко проявляющейся проблемы персонал технической поддержки рекомендует сконфигурировать операционную систему и другие компоненты так, чтобы когда проблема проявится вновь, остался какой-нибудь отчет о состоянии системы или был вызван отладчик — чтобы можно было потом разобраться, что произошло.
Если проблемная ситуация легко воспроизводится, то технический персонал захочет воспроизвести ее на месте, чтобы продемонстрировать разработчику на «живой» системе. «Смотри-ка! Все умирает, стоит мне сде…»
Даже если проблема воспроизводима, персонал технической поддержки, скорее всего, не будет в восторге от перспективы переворошить 6000 строк вашей Си-кода в поисках затаившейся в его недрах ошибки.
В большинстве случаев, которые мне доводилось видеть, местоположение ошибки можно было сузить примерно до 20–30 строк максимум. Большие файлы могут быть действительно полезны для анализа в тех случаях, когда вы подозреваете, что ошибка связана с размерами объектов, а не с библиотеками или ядром. Например, у некоторых утилит может быть задан размер массива по умолчанию, и попытка увеличить его размер ведет к проблеме. В этом случае персонал технической поддержки может запросить у вас tar
-архив, в котором содержится все. К счастью, создавать tar-архивы несложно. Например, если каталог вашего проекта называется /src/projects/xyzzy
, и техперсонал хочет посмотреть все, что там находится, вы можете сделать следующее:
# cd /src/projects
# tar cvf xyzzy.tar xyzzy
Это «высосет» все содержимое каталога xyzzy
(включая все подкаталоги!) в файл с именем xyzzy.tar
. Если результирующий tar
-файл получится большим, вы сможете сэкономить время на его загрузку и место на диске, если сожмете его с помощью утилиты gzip
:
# gzip -9v xyzzy.tar
xyzzy.tar: 60.2% — replaced with xyzzy.tar.gz