Сам был во второй линии поддержки. Есть некоторое представление, какой должна быть первая линия:
* Ни при каких обстоятельствах не связывать багрепортера с инженером по первому требованию
* Писать баг в виде WID, WIS, WIE
* Описать окружение бага
* Взять координаты обратной связи
Из личного опыта: более 50% пропущенных первой линией проблем решались без участия инженера (просто суппорт не понял, о чем клиент говорит), или клиент не мог описать, что он хочет/в чем проблема.
Техподдержке 2-й линии сложно с неопытными пользователями
Опытным пользователям сложно с техподдержкой 1-й линии.
Иногда бывает сложно девочке объяснить, что:
* если физический канал пропал «внезапно» — то пинга быть не может, и перезагрузка в [другую] ось ничего не даст
* если tracert/phing работает, но только внутри сети — то dhcp не при чем
* если pptp рассказывает о том, что сервер не доступен, то дело не в деньгах на счете
* если у меня iPhone — то он умеет ходить по gprs, дайте мне только настройки
Впрочем, попадался суппорт, который по 2-3 ключевым словам сразу понимал, что тут нужен инженер. И спасибо инженерам, которые не только чинят, но и перезванивают, отчитываются и требуют подтверждение починки.
Естественно, что не только этим человек провинился. Кстати, объяснить прочему таки kill или почему не kill, и чем еще можно останавливать процессы, человек, насколько я помню, объяснить не мог
Я тоже люблю предполагать лучшее, но в данном случае, коль уж мы опустились на личности, не тот случай. Этот же человек, получив комманду: «готовсь к остановке СУБД продакшина и быстрого создания резервной копии», а еще через 30 минут «делай» только открывал терминал. Естественно, то, что mysqldump нет в путях он узнал именно сейчас, когда лежал продакшн и 15000 пользователей пили кофе, долбясь об сорри сервер. Еще через 5 минут, порыскав во все ему известные bin он выдал бессвязное: «я не знаю где/что/как». Ну и классическое, на набранные мной в терминале locate и find — o0.
Начнем с конца
3. kill — не linux way — вывод, человек плохо разбирается в SysV-init
1-2. Следует, человек скорее всего, понятия не имеет, что там может происходить в SysV-init
* Ни при каких обстоятельствах не связывать багрепортера с инженером по первому требованию
* Писать баг в виде WID, WIS, WIE
* Описать окружение бага
* Взять координаты обратной связи
Из личного опыта: более 50% пропущенных первой линией проблем решались без участия инженера (просто суппорт не понял, о чем клиент говорит), или клиент не мог описать, что он хочет/в чем проблема.
Опытным пользователям сложно с техподдержкой 1-й линии.
Иногда бывает сложно девочке объяснить, что:
* если физический канал пропал «внезапно» — то пинга быть не может, и перезагрузка в [другую] ось ничего не даст
* если tracert/phing работает, но только внутри сети — то dhcp не при чем
* если pptp рассказывает о том, что сервер не доступен, то дело не в деньгах на счете
* если у меня iPhone — то он умеет ходить по gprs, дайте мне только настройки
Впрочем, попадался суппорт, который по 2-3 ключевым словам сразу понимал, что тут нужен инженер. И спасибо инженерам, которые не только чинят, но и перезванивают, отчитываются и требуют подтверждение починки.
3. kill — не linux way — вывод, человек плохо разбирается в SysV-init
1-2. Следует, человек скорее всего, понятия не имеет, что там может происходить в SysV-init
2. Таки пид
3. Логгирование на экран результата работы
Где-то еще #ps ax|grep cron; kill… видел
* Один соискатель не знал, что такое TCP и чем он отличается от UDP
* Другой работник при просьбе остановить cron выполнял #killall cron