Kyiv IT Outsourcing Forum 2017 — встигни купити Early Bird квитки до 1 травня!

Карьера в IT: должность Support Engineer

Представляем новую статью из серии «Карьера в IT». Она посвящена должности Support Engineer — этот специалист занимается техподдержкой уже выпущенных продуктов компании.


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

По данным ДОУ, среднему украинскому инженеру техподдержки 26 лет, он имеет зарплату $300-700 и опыт работы 2 года.

Задачи и обязанности

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

Профессия Support Engineer разбита на 5 уровней (Levels), по номеру которого можно сразу с большой точностью определить, что из себя представляет конкретная позиция. Эта структура не имеет ничего общего с карьерной лестницей, а только с расположением работника поддержки на линии «Клиент — ядро продукта». Чем ниже уровень, тем ближе к клиенту и тем дальше от ядра. Поэтому из первого уровня практически невозможно дорасти до третьего-четвертого из-за разницы в специфике задач и требований к кандидатам, так как каждый уровень — это совершенно другая сфера деятельности.

Level 0 (Колл-центр). Основная задача — первичная обработка запроса пользователя: уточнение учетной информации пользователя, краткое описание проблемы. Иногда — выдача пользователю заранее согласованной информации (ответов на часто задаваемые вопросы). В особо сложных случаях — вызов дежурного инженера.

Технические знания там не требуются, только грамотная речь и отсутствие боязни телефона. Большой плюс — знание иностранных языков. Карьерно продвинуться из колл-центра особенно никуда нельзя, разве что внутри непосредственно колл-центра.

Level 1. Сотрудники первого уровня поддержки сортируют запросы, поступающие в почту, отделяют явный мусор (в корзину) от простых вопросов (отвечают сами) и профильных вопросов (отправляют коллегам уровнем выше или в соответствующий отдел), отвечают на телефонные звонки.

Требования к сотрудникам обычно такие же, как и для колл-центра, но крайне желательна общая компьютерная грамотность (например, пользователь MS Excel). Поскольку для поддержки продукта нужно главным образом знать продукт компании, то все равно кандидата придется обучать с нуля.

Карьерно продвинуться можно отсюда либо во второй уровень (техническая экспертиза), либо в менеджмент поддержки (управление), либо в отдел продаж.

Level 2. Это последний уровень техподдержки, который имеет дело непосредственно с конечным пользователям. Здесь же сотрудники имеют наиболее полную картину о продукте в целом, как с точки зрения пользователя, так и с точки зрения внутренних особенностей. Сюда перенаправляются запросы, с которыми не справился первый уровень, здесь заказываются тренинги для клиентов о продукте фирмы. У сотрудников второго уровня есть доступы и к клиентским системам, и к внутренним баг-трекерам и бэклогам.

«Мне всегда нравилось помогать людям, я с детства помогал своим друзьям решить проблемы с установкой разных игр и настройкой ПК. Мне это приносило удовольствие. Кроме этого, я имею неплохие софтскиллы и достаточно стрессоустойчив. Привлекала меня загруженность на 100%. Из-за большой загруженности я всегда был в тонусе и быстро впитывал информацию, мне кажется на начальном этапе это то, что нужно, для молодого специалиста».

Текучка здесь ниже, чем в в первом уровне, но требования к кандидату выше: дополнительно нужны как минимум базовые навыки программирования, базовые знания баз данных, умение быстро сопоставлять факты, навыки trouble shooting. Для тренингов нужны навыки презентаций. В зависимости от компании, второй уровень может также выполнять функции первого, что может несколько снизить технические требования к кандидату.

«Я работаю в техподдержке хостинг-компании.Мой круг обязанностей — решение вопросов клиентов компании через чат и систему тикетов, в большей степени это администрирование виртуальных и выделенных серверов, помощь со скриптами и CMS, мониторинг сервисов инфраструктуры, консультирование клиентов по предпродажным вопросам, по вопросам безопасности, восстановление работоспособности серверов в случае каких-либо ошибок».

Из инженеров поддержки второго уровня получаются отличные Technical Pre-Sales Engineers и Product Trainers (если есть хорошие социальные навыки), SLA-менеджеры (если есть склонность к формализации процессов) и изредка — инженеры поддержки третьего уровня (если склонность к поддержке инфраструктуры больше, чем к поддержке непосредственно продукта).

Level 3. Инженеры техподдержки третьего уровня имеют гораздо больше общего с сисадминами/devops, чем с коллегами из второго уровня. С клиентами они уже не общаются, поэтому социальные навыки и знания языков уходят на второй план. Поддержка третьего уровня поддерживает не столько сам продукт, сколько инфраструктуру продукта, поэтому продукт в целом они, как правило, не знают. В их задачи входит конфигурация, починка, поддержка и развитие продуктовой среды, а также разруливание проблем в нерабочее время.

Рабочий процесс третьей линии техподдержки начинается с того, что поступает заявка от второй линии. Типичный вид одного такого кейса — это описание проблемы, в который входит текстовое описание, скриншоты, информация об аппаратной среде, файл с логами работы продукта.

Инженер техподдержки изучает присланную информацию и, как правило, реагирует по одному из трех сценариев:

  • Дает рекомендации по решению проблемы, если проблема известна и уже есть готовое решение или продукт работает должным образом, просто необходимо разъяснение, или нужны изменения в конфигурации аппаратного среды, где установлен продукт;
  • Запрашивает дополнительные данные (диагностические приложения, новые логи продукта с заданными параметрами, дополнительные снимки экрана), если информации недостаточно, после чего дает рекомендации по решению проблемы;
  • Идентифицирует, что проблема в недостатке продукта, и переводит заявку на команду разработчиков, после чего они изготавливают патч, который тестирует инженер техподдержки и передает пользователю.
«Приходит новая заявка — ставишь ее себе в график. Приходит критический инцидент — приостанавливаешь все, разбираешься с ним. Бывает по несколько раз в день приходится менять приоритеты задач. Так что нужно уметь быстро переключаться между задачами и правильно расставлять приоритеты».

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

Текучка на этой позиции средняя, требования к кандидатам отражают инфраструктурные особенности компании. Как правило, нужны хорошие знания Unix Based OS, навыки скриптования, знание баз данных, знание мониторинговых систем.

«Куда они растут карьерно — доподлинно неизвестно. По-моему, они просто приходят из таких же позиций и уходят на такие же позиции, наращивая технические знания и гонорары».

Level 4. Встречается гораздо реже первых трех. Фактически, это девелоперы, которые в компании давно и досконально знают внутренности продукта или его части, потому что сами его программировали. С клиентами они не контактируют, инциденты не разруливают. В их задачи входит быстро починить критическую проблему в системе, которая уже ушла к пользователям. Их основные источники задач — багтрекеры.

Со стороны их не берут, а взращивают в компании. Карьерно развиваются они так же, как и программисты: могут стать, например, архитектором проекта или вроде того.

Дальше речь пойдет непосредственно о L2/L3/L4 Support Engineers.

Рабочий день инженера техподдержки — это обработка инцидентов, которых, в зависимости от качества софта, бывает больше или меньше. Как правило, день начинается с проверки всех тикет-трекеров, системы мониторинга, а также, возможно, критически важных сред.

«Работа состоит из разгребания тонн логов разных приложений, копание в базах данных, настройках приложений, аналитика найденного, поиск решения, имплементация, всё это сопровождается контролем признаков активности из мониторинг систем (чтобы ничего не пропустить) и перепиской с коллегами из разных локаций для консультаций по какому-либо вопросу».

От других членов команды разработки ПО Support Engineers отличаются тем, что они как никто другой знают о проблемах юзабилити, а также понимают всю картину воркфлоу от начала до конца.

Преимущества и недостатки

В своей должности инженеров техподдержки привлекает разнообразие задач, насыщенный ритм работы:

«Нравится общение с людьми из различных стран и культурой, решение технических задач различной сложности. То чувство, когда решил какую-то сложную, на первый взгляд не решаемую задачу, непередаваемо :)»

«Знания ценятся не столько глубокие, сколько разнообразные, и очень важны определенные личностные качества — дружелюбие, выдержка, настойчивость».

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

«Позиция Support Engineer довольна интересна, так как необходимо много коммуницировать не только с клиентами но и с инженерами своей компании — разработчиками, тестировщиками, техрайтерами, менеджментом. Так ты можешь развиваться в любом направлении, да и друзей много можно завести».

Также отмечают, что эта должность — один из вариантов относительно легкого входа в отрасль:

«Для меня Support Engineering — это переходной этап от работы системным администратором до разработки ПО. Впрочем, работа достаточно разноплановая, нескучная, задачи могут быть достаточно сложными и интересными. Есть возможность проявить себя».

«Мне кажется люди приходят в техподдержку тогда, когда у них не хватает глубоких технических знаний, но при этом хочется быть в ИТ и получать айтишную зарплату без особых напрягов, ведь общение по телефону, email и sql запросы — это проще , чем разработка такой же системы. Единственное сильное требование — хороший разговорный английский».

Из недостатков — обилие стрессовых ситуаций, сложности непосредственного карьерного роста:

«Приходит новый инцидент — ставишь его себе в график. Приходит критический инцидент — бросаешь всё, разбираешься с ним. Бывает, по несколько раз в день меняешь приоритеты задач. Получается рванная работа, ты должен уметь быстро переключаться между тасками. Со временем начала от этого болеть голова, был вымотан».

«У других команд есть цель, которую они видят, к которой движутся. У нас же — такой себе День сурка, ведь письма будут всегда и пользователи будут всегда, и вот когда мы поможем вот этой 1000-ой, за ней придет другая».

«Есть проблема профессионального роста. Когда ты- человек-оркестр, ты знаешь что-то обо всем, но ничего глубинно о чем-то одном. И это тебе не прибавляет цены на рынке, цены как специалисту. Или же наоборот, если у тебя очень узкая специализация по конкретной технологии/продукту, то тоже могут быть сложности с поиском следующей работы».

Упоминают и проблемы в отношениях с коллегами из других отделов:

«Самое очевидное — у саппорта зарплаты меньше, чем у девелоперов ;) В остальном все недостатки — мелкие, больше связанные с рабочим процессом. Например, часто нужно обосновать вышестоящим, зачем тебе необходим доступ на этот сервер или зачем админскими роль в этой базе данных, ты ведь не девелопер — обходись тем, что есть».

«Большое кол-во девелоперов, QA и т.п. не являются людьми высокой культуры общения, что нередко бывает серьезным препятствием при обсуждении/эскалации инцидентов или попытках выудить у них информацию, которая саппорту крайне необходима для анализа риквеста. Девелоперы «всегда очень заняты». Нередко люди в других отделах считают саппорт самой низкой ступенью в компании с вытекающим отношением. Если объяснить более детально, люди не всегда понимают важность саппорта и не оказывают треюбущейся саппорту поддержки. Например, приложение может быть описано довольно слабо техническим писателем (и это не редкость), и информацию можно получить только у тех, кто имеет непосредственное отношение к созданию архитектуры или определению функционала. Задача для саппорта часто бывает сложной, и ты чувствуешь себя в качестве «попрошайки».

Как стать и куда двигаться дальше

Для L2 Support Engineers нужны базовые знания Windows/Linux OS, баз данных, общие знания в области системного администрирования, сетей, архитектуры системы. Для L3 — более глубокие знания по вышеупомянутым темам, а также хорошие знания Unix Based OS, навыки скриптования, знание мониторинговых систем.

Для работы в компаниях, направленных на иностранные рынки, обязателен английский не ниже среднего уровня.

«Работа в саппорте, на мой взгляд, чем-то похожа на „передовую“ на войне. Здесь нужна стойкость, быстрая реакция, конечно же знание своего дела и стрессоустойчивость».

Из личных качеств:

  • стрессоустойчивость;
  • усидчивость;
  • хорошая память;
  • обучаемость, умение быстро находить информацию для решения проблем.
«Саппорт должен быть гибким, уметь быстро реагировать и адаптироваться под ситуацию. Важны коммуникационные навыки — не бояться говорить что-то, инициативность — не бояться звонить и уведомлять бизнес и менеджеров высшего звена».

Возможные карьерные пути инженера техподдержки:

  • Дорасти до Support Lead — заниматься более сложными задачами, расширять или же, наоборот, углублять свой опыт, координировать работу отдела;
  • Стать проектным менеджером, если хочется развиваться не по техническому, а по управленческому пути. Этому поможет баланс софтскиллов и технического бэкграунда, умение решать конфликты. Если же интересно работать с клиентами, можно рассмотреть позицию Technical Account Manager или бизнес-аналитика;
  • Стать системным администратором, если нравится работать с инфраструктурой, занимается настройкой и обеспечением стабильной работы техники;
  • Стать DevOps, если интересно писать сценарии и хочется самостоятельно создавать инфраструктуру, поднимать проекты, автоматизировать развертывание;
  • Стать DBA, если нравится администрировать и проектировать базы данных, писать SQL запросы;
  • Стать QA или разработчиком.

P. S. Благодарю за помощь в написании статьи Елену Логодскую и еще 28 украинских инженеров техподдержки, которые рассказали DOU о своей профессии. Приведенные в статье цитаты взяты из их рассказов.

См. также:

29 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

По поводу «попрошайки» в точку! Именно так я себя всегда чувствовала в качестве специалиста техподдержки на протяжении 7 лет. Ушла. Ты знаешь все по чуть-чуть и не чувствуешь себя конкурентным специалистом. Ты знаешь продукт больше, чем общепризнанные вещи, и куда после этого? В новой компании новый продукт.
В общем сейчас я отработала первую неделю как web верстальщик. Сложно, много нового, надо много учиться, но зато это будут знания, которые я смогу применять дальше. В общем есть чем поделиться...

А что, правда в саппорте максимум 700 баксов зп ?

Нет, $300-700 — это I и III квартили, а медиана — $500 (данные отсюда). Но есть и $1500-1700, просто таких анкет не так много.

сапорт занадто розтягнуте питання, для тих хто в кол центрі, може і так, для 3-ї і 4-ї лінії дуже сумніваюсь... До речі, цікаво було б в ЗП опитуваннях розділити лінії(рівні) для більш чіткої картини.

Интресно как всегда. Напишите еще про загадошного Programm Manager

Стрессоустойчивость — главное качество саппорта :)

Суппорт — вот кто это придумал?[sə’pɔːt]
Ну и по поводу "

Нередко люди в других отделах считают саппорт самой низкой ступенью в компании с вытекающим отношением.
"

Чисто украинское отношение. В Европе, Америке и полагаю других странах нет такого. Обычная работа и все

В більшості європейських компаній нажаль це теж ключова фраза

В Европе та же фигня, точно говорю.

Значит мне повезло с компанией.

На самом деле все зависит от двух факторов — типа компании и культуры компании.
Саппорт СааС или продуктовой компании это первейшая линия обороны и хорошо выстроенный саппорт позволяет компенисровать недостатки и баги продукта. С другой стороны конечно девелоперам не нравится когда им постят баги :). А шо делать то... Но менеджмент должен строить правильную культуру компании иначе кина не будет. И как раз DevOps он про это, а не про дженкинс с амазоном...

Дело не в компании, а в людях. Точнее, есть ли у людей опыт работы с саппортом.
Обычно те, кто в компании давно, и опыт есть, нормально и с уважением относятся к саппорту и прочим техникам. А новички, особенно молодые, не представляют себе наш круг задач (и, тем более — квалификацию), и думают, что мы такие «принеси-подай». Потом отношение выравнивается, но если в компании большая текучка или компания стремительно растет (как наша, например), и новичков постоянно много, то неадекватное отношение встречается чаще.

Хто має справу саме з продуктом, той 100% має розуміти що суппорт це одна з найважливіших ланок в життєвому циклі проекта. Ось ті ключові моменти які я сміг виділи для себе за рік:
1. Банальщина. Щось упало/щось відвалилось/виліз баг — в цьому випадку суппорт стримує партнерів/клієнтів і дає команді розробки можливість підняти все що б там не працювало.
2. Девелоперів немає. Проспали/заболіли і т.д — в цьому випадку Вони уже прикривають всю команду, поки розробник доберається до роботи — конфлікт з партнером/юзером може бути повністю згладженний
3. Рекомендації. Суппорт як ніхто краще знає що саме потрібно нашим юзерам і що не працює так як треба.
4. Тестування. Чи Ви робите автотести чи у Вас все мануально, суппорт все одно перший знайде саме важливе і повідомить команду про можливий баг.
5. Відповідальність. Це просто круті люди в яких (виключно на моїй практиці) скіл відповідальності завжди на висоті, щоб Вони не робили!

Взагалі робота як робота, у всіх так, але благо є такі люди і я вдячний їм за роботу!

Как это нет? Т.е шутки про индусов в техподдержке просто так появляются?

Можливості є завжди і у всіх, тому, намою думку, писати що «неможливо переходити на вищі рівні підтримки», чи «переходити на інші посади в компанії» — не зовсім коректно, що підтверджується розділом «можливі кар’єрні шляхи».
І, насправді, не все Support в що «легко увійти», так як у багатьох компаніях один інженер — це відразу 2-3 рівні, а ті компанії в яких чітке розмежування 1-шу та 2-гу лінію тримають в Індії чи Китаї.
Загальний опис — ок, хоч є багато неточностей. Тепер нарешті можу зрозуміти наскільки релевентні описи інших посад...

Прошла все круги от кастомер саппорта до 3-ей линии и до ПМ .
Так что ,если кому-то инетересно -милости прошу с вопросами))

Статья очень хорошая , приятно читать)

Супорт это важно, особенно для маленьких компаний и стартапов. Для супорт есть 2 крайне важные метрики:

Time to Response — сколько времени прошло до ответа (меньше — лучше). Идеальное время до 20 минут

Time to Resolve — сколько заняло решение проблемы (меньше — лучше), Идеал — менее 24 часов до недели

LOL... Target Recovery Time — 10 minutes. Availability Target — 99.998%
Какие 20 минут :).

Вы путаете Resolve и Recovery. Recovery — это довольно скромное подмножество Resolve, которое касается только service availability.

К счастью, из запросов в саппорт связана с availability issues или там service outage только крохотная часть.

Нет, не путаю ;).

Ну ОК, а если серьезно то писать

Идеальное время до 20 минут
или
Идеал — менее 24 часов до недели
не правильно, потому что все зависит от Severity/Priority описанных в SLA. P1 надо резолвить в пределах Target Recovery Time, а Р4 можно и месяц, если SLA позволяет.
К счастью, из запросов в саппорт связана с availability issues или там service outage только крохотная часть.
Ну и это как в том анекдоте — Вам повезло...

Просто УМВР :-)

ану бігом усі KPI-ми мірятись :)

Не КРІ, а SLO (і не SLA).

дяйсно, тим не менше нагадує прикладну фалометрію :)

Подписаться на комментарии