ЖУРНАЛ СТА 1/2013

90 СТА 1/2013 www.cta.ru В ЗАПИСНУЮ КНИЖКУ ИНЖЕНЕРА Как «выжать» максимум из технической поддержки производителя Николай Горбунов М Ы НЕ ПИШЕМ В ТЕХПОДДЕРЖКУ В инженерном деле чудес не бывает – говорят, даже для ис- тории с магическим переключателем [1] в конце концов на- шлось логичное объяснение. Любая инженерная задача со- стоит из деталей, и любая проблема заключается в том, что ка- кие-то конкретные детали работают и/или взаимодействуют не так, вне зависимости от того, знаем мы про них что-либо или нет. При этом опытный инженер всегда знает, что в зада- чах диагностики неисправностей додумывать или подразуме- вать что-либо очень вредно: как известно, допущение – пра- матерь всех провалов, и чем больше фактов, тем ближе исти- на, а по ложному пути можно блуждать сколь угодно долго. Количество деталей, влияющих на работу технической си- стемы, может быть невообразимо велико. О каких-то из них мы не знаем, потому что они выпадают из нашего кругозора, другие лежат на поверхности, но мы их даже не рассматрива- ем, наивно полагая, что уж они-то здесь совершенно ни при чём. Это абсолютно нормально: мировая инженерная практи- ка изобилует весёлыми историями про курьёзы отладки напо- добие электронной почты, которая не доставляется дальше, чем на 500 миль [2], сторожевой собаки, которая скулит перед тем, как зазвонит телефон [3], постороннего стука в кузове «Га- зели» [4] и т.п. Я однажды чуть ли не два месяца пытался по- нять причину стука во входную дверь своей квартиры между восемью и десятью вечера (два или три раза – «тук-тук-тук», подбегаешь, смотришь в глазок – никого), пока однажды, воз- вращаясь вечером домой, случайно не наткнулся на спускаю- щегося навстречу соседа, который шёл выгуливать своего сет- тера. Сеттер был ужасно рад, что его ведут гулять, и ошалело вилял хвостом, проходя мимо моей двери, он как раз успевал ударить по ней хвостом два-три раза. Как сделать время диаг- ностики таких проблем предсказуемым? Однажды, когда я был молодым специалистом и работал в техподдержке, меня вызвали прочитать мастер-класс на тех- ническом семинаре в Запорожье. Когда семинар закончился, ко мне подошел представитель одного из заказчиков и спро- сил, известно ли мне что-нибудь про проблему с драйвером некой сетевой карты для операционной системы QNX4. Про- блема была знакомой: производитель оборудования заменил микросхему на одной из своих плат, изменил номер версии платы (вытравленный в уголке мелким шрифтом), но номер для заказа оставил неизменным. Разница, как в анекдоте, ока- залась потрясающей: со старой версией платы драйвер рабо- тал корректно, а с новой «валил» при запуске весь сетевой стек. По закону подлости проявилась эта ситуация в самый непод- ходящий момент: наш заказчик сделал и отладил прототип си- стемы на плате старой версии, а когда пришло время ставить систему на объект, закупил оборудование по тем же самым но- мерам для заказа, и система внезапно отказалась работать. Мы подняли по тревоге техподдержку производителя, те признали проблему и через три дня предоставили исправленную версию драйвера; система была успешно развёрнута, а задача со спо- койной совестью сдана в архив. С этого момента до семинара в Запорожье прошло больше года. Когда я спросил представи- теля запорожского заказчика: «У нас уже год как есть реше- ние – почему же вы сразу не написали к нам в техподдерж- ку?» – он ответил: «Мы не пишем в техподдержку. Если мы сталкиваемся с проблемой, которую не можем решить прямо сейчас, мы просто ищем другой подход». Этот ответ меня тогда сильно озадачил – я не мог понять, по- чему проще перепроектировать систему, чем написать не- сколько строк по электронной почте и с некоторой веро- ятностью получить решение мгновенно. Работая впоследствии в должности менеджера проектов, я нашел ответ на этот во- прос: лучше плохо ехать, чем хорошо стоять. Руководство на- чинает паниковать, когда работа приостанавливается на не- определённый срок и её возобновление зависит от обстоя- тельств, которые не выглядят контролируемыми, например от работы инженеров техподдержки сторонней организации. Го- раздо спокойнее загрузить своих людей другой работой и на- деяться, что пока шар на их стороне, ситуация находится под контролем. Созданию этой иллюзии во многом способствует реальный отрицательный опыт работы с техподдержкой – многие из вас наверняка сталкивались с ситуацией, когда техническая под- держка производителя либо вообще молчит, либо слишком медленно реагирует, либо реагирует быстро, но обсуждение проблемы затягивается на неопределённый срок и в конечном итоге не приводит ни к чему. Иногда обращаться в техпод- держку мешает инженерная гордость (да я сам справлюсь, что я, не инженер?), иногда – интерес к проблеме (когда ещё зале- зешь в исходный код планировщика?), но результат всегда один: обращение в техподдержку часто используется как по- следний шанс, когда других вариантов не осталось, а время уже упущено. Между тем, если возникают проблемы, их надо ре- шать быстро, ну или хотя бы предсказуемо. В настоящей статье описывается, как устроена техническая поддержка, почему она работает так, как она работает, и как взаимодействовать с ней, чтобы получить от этого максималь- ный эффект. Приведённые рекомендации в большей степени относятся к работе с производителями программного обес- печения, хотя большинство из них будут полезны в любой практике диагностики и решения технических проблем. К АК РАБОТАЕТ ТЕХПОДДЕРЖКА Мухи и котлеты Прежде всего, следует понимать, что в общем случае (наиболее часто это справедливо для больших компаний)