Первый пост, с почином меня, стало быть)
Решил ответить постом, т.к для комментария будет много текста.
Часть 1. Как устроена обычная техподдержка и как с ней работать. (здесь не пойдет речь про изначальный пост сисадмина, так что кому не интересно можете пропустить)
Я проработал в техподдержке 3 года и еще сколько то месяцев, прошел путь от первой до третьей линии поддержки иностранных клиентов, а затем до системного аналитика. Для тех кто не понял, что за линии - объясню кратко. В техподе есть обычно три линии:
1) первая линия - говорящие скрипты, т.е люди, которые не имеют технических, компьютерных и т.д навыков, разве что "уверенный пользователь ПК". Но они знают продукт, который выпускает компания, во всяком случае должны знать. Задача этих спецов - получить от клиента описание проблемы, предложить решение из списка возможных и составить заявку, чтобы ее, если что можно было передать на более опытных спецов.
И они могут помочь. Да, вы можете сколько угодно смеяться над "перезапустите компьютер", но это помогает в большинстве случаев. И это реально проще чем объяснять неопытному юзеру такую банальную вещь, как перезапустить службу, а при перезапуске компа - служба перезапустится (у служб наших ПО всегда стоял автозапуск если что)
2) вторая линия - это спецы, которые уже не только разбираются в продукте компании, но и обладают некоторыми общими знаниями в айти, своего рода эникейщики, т.е знают например, что такое API и как сделать JSON-запрос, простые SQL-запросы, журнал винды смогут просмотреть и найти там причину, некоторые нетрудные админские вопросы порешать, например сделать проброс портов, настроить RemoteApp для приложухи.
3) третья линия - уже опытные спецы, которые в свободное от техподдержки время, когда задач немного привлекаются для работы в других отделах, ну т.е каждый такой специалист имеет знания в определенной области хотя бы на уровне уверенного джуна. И соответственно привлекается для задач по тестированию или может привлекаться для внедрения, как аналитик и т.д. Т.е это по сути переходная стадия от техподдержки до более узкоспециализированного профессионала (тестировщика, разраба, сисадмина и т.д). Во всяком случае так у нас в компании.
Резюмируя сказанное:
1) Работая с техподдержкой описывайте инфу по возможности баг-репортом (описание, сценарий возникновения, фактический итог, желаемый итог, скрины, версия вашей программы (если знаете))
2) Работайте через эл.почту, я прекрасно понимаю, что "Эй, мы же в 21 веке живем", что мессенджеры или общение голосом удобнее, но по этой причине ваши заявки могут быть не созданы или не отслеживаться руководителем техпода.
Т.е например звонки записываются, но чтобы прослушать звонок, который может идти больше получаса руководителю поддержки придется потратить много времени, имейте в виду, что это и ваше время, т.к чем дольше в вашем вопросе будут разбираться, то тем дольше ваша проблема будет нерешенной. За день специалисту может поступать очень много звонков и он просто может не успеть/забыть создать заявку по звонку, таким образом ваше обращение будет сложнее найти и отдать более опытному специалисту.
С чатами такая же ситуация, их труднее отслеживать чем письма. А вот все письма отрабатываются через HelpDesk, не буду описывать что это, но короче говоря руководитель техпода или любой другой специалист всегда может увидеть заявку другого и самое главное при обращении через почту - заявка ВСЕГДА создается автоматически. А значит, если руководитель техпода/разрабов/фирмы увидит, что заявка не решается или требуется более высокий уровень компетенции, то просто передаст ее на другую линию или другой отдел. Такой вот парадокс, что позвонить или написать в мессенджер удобнее, но именно для решения вопроса удобнее электронная почта.
Извините, что загрузил вас этой информацией, но это необходимо, чтобы вы понимали как организована работа техподдержки и как с ней работать, чтобы всем было комфортно.
Часть 2. Разбор обращения сисадмина с точки зрения специалиста техподдержки.
Так вот теперь я хочу рассказать как со стороны техподдержки могло выглядеть обращение сисадмина, ведь с похожими ситуациями сталкивался и я не раз. Автор пишет, что было "подробное описание проблемы". Зачастую это подробное описание со стороны пользователей, а по факту данных необходимых для анализа проблемы там просто нет, короче для техподдержки подробное описание это баг-репорт.
Т.е не только описание проблемы, но и сценарий при котором она возникла/возникает, что именно происходит (тут как раз скрины будут к месту), что должно было быть вместо этого, версия продукта, а также по возможности логи, бэкапы, профилирование и т.д. Понятно, что от юзера нельзя это все требовать, но если этого не было, то считать это подробным описанием нельзя и техпод будет уточнять информацию. Я сейчас не говорю, что автор врет, когда говорит, что дал подробные данные (я этого не знаю, а раз он сисадмин, то скорее всего действительно дал максимально подробно инфу, вышеизложенное скорее для вас, для понимания, что такое подробное описание).
Техпод ответил, что у них все работает. Да в контексте проблемы это звучит смешно, но ситуации когда проблема на стороне юзера не редкость. Ситуация: есть интернет-магазин, он обновил логотип на сайте, но по факту логотип не обновился, конечно клиент звонит в техпод сайта и матерится, а дело оказывается в том, что он не почистил кэш. Или другой пример, звонит клиент и говорит, у меня сайт стал резко тормозить, че вы там натворили?! Техпод смотрит в мониторинг типа Grafana, но не видит там большой нагрузки, естественно он скажет, что проблема на стороне клиента, а там может быть что угодно, например куча вкладок, грузящих память и т.д.
Техпод отправляет инструкцию, что можно и нужно проверить. Тут автор говорит, что "инструкция = КГ/АМ", но не объясняет подробно почему. Якобы там только два пункта: "1. Обратитесь в техпод. 2. Обратитесь к разрабам". Честно говоря слабо верится. Нет, конечно бывают очень тупые инструкции, но в столь откровенный посыл нахуй мало верится. Да и вообще обычно техподдержка всегда сама контактирует с разрабами, иногда менеджер клиента, но я нигде не видел, чтобы клиент контактировал с разрабами, ну разве что в совсем маленьких фирмах и стартапах, где разрабы сами занимаются техподдержкой.
Затем автор собирает консилиум из админов и они решают вопрос и вот тут странность. Если они решили вопрос сами, то высока вероятность, что проблема была реально на их стороне. Объясню почему:
1) Фирмы зачастую берегут свой софт и полный доступ к исходникам программы не дают, т.е если проблема в коде, то поправить ее самостоятельно юзер, каким бы он продвинутым не был - поправить не сможет.
2) Большинство проблем на стороне поставщика продукта могут решить только сами разрабы/техпод и т.д. Например, если это сайт, то клиент имеет зачастую очень ограниченный доступ на сервер, где этот сайт крутится и единственное, что может - это загружать картинки/файлы в отдельную папку. Это сделано, чтобы юзер по незнанию или злому умыслу не загрузил какой-то зловред.
И еще много причин. Поэтому я склонен не доверять автору.
Ну и затем следует ситуация, когда техпод вымогает от автора отчет о том как он решил. Вот тут вообще подозрительно. Обычно техпод только рады сами закрыть заявку, чтобы она не висела мертвым грузом и не портила статистику, показатели. Требовать описать способ решения проблемы могут лишь в том если автор решил как то не очень законно или подозрительно, например каким-то образом получил доступ к исходному коду и т.д.
Короче, я тоже многое предполагаю и моя аргументация по сути ничего не стоит, т.к фактов я не знаю. Может там реально охреневший от наглости техпод, но я бы хотел, чтобы автор дал более детальное описание. Хотелось бы больше конкретики. Техподдержку часто ругают, и обычные юзеры и такие вот продвинутые, типа "Смотрите какая тупая техподдержка, а я вот админ/разраб с корешами собрался, да программу переписали по-быстренькому", а на самом деле ситуаций, когда пользователь не признает проблему на своей стороне тоже немало.
