Кар'єра в 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/L4Support Engineers.

Робочий день інженера техпідтримки — це обробка інцидентів, яких, залежно від якості софта, буває більше або менше. Як правило, день починається з перевірки всіх тікет-трекерів, системи моніторингу, а також, можливо, критично важливих середовищ.

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

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

Переваги і недоліки

У своїй посади інженерів техпідтримки приваблює різноманітність завдань, насичений ритм роботи:

«Подобається спілкування з людьми з різних країн і культурою, рішення технічних завдань різної складності. То почуття, коли вирішив якусь складну, на перший погляд не вирішувану задачу, непередавано :)»

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

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

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

Також відзначають, що ця посада — один з варіантів відносно легкого входу в галузь:

«Для мене Support Engineering — це перехідний етап від роботи системним адміністратором до розробки ПЗ. Втім, робота досить різнопланова, ненудна, завдання можуть бути досить складними і цікавими. Є можливість проявити себе».

«Мені здається люди приходять в техпідтримку тоді, коли в них не вистачає глибоких технічних знань, але при цьому хочеться бути в ІТ і отримувати айтишную зарплату без особливих напрягів, адже спілкування по телефону, email і sql запити — це простіше , ніж розробка такої ж системи. Єдине сильне вимога — хороша розмовна англійська».

З недоліків — велика кількість стресових ситуацій, складності безпосереднього кар'єрного росту:

«Приходить новий інцидент — ставиш його собі в графік. Приходить критичний інцидент — кидаєш все, розбираєшся з ним. Буває, по кілька разів на день міняєш пріоритети завдань. Виходить рванная робота, ти повинен вміти швидко перемикатися між тасками. З часом від початку цього боліти голова, був виснажений».

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

«Є проблема професійного росту. Коли ти - людина-оркестр, ти знаєш щось про все, але нічого глибинно про щось одне. Та це тобі не додає ціни на ринку, ціни як фахівця. Або ж навпаки, якщо у тебе дуже вузька спеціалізація по конкретній технології/продукту, то теж можуть бути труднощі з пошуком наступної роботи».

Згадують і проблеми у стосунках з колегами з інших відділів:

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

«Велика кількість девелоперів, QA і т. п. не є людьми високої культури спілкування, що нерідко буває серйозною перешкодою при обговоренні/ескалації інцидентів або спроби виманити в них інформацію, яка саппорт вкрай необхідна для аналізу риквеста. Девелопери «завжди дуже зайняті». Нерідко люди в інших відділах вважають саппорт найнижчою сходинкою в компанії з випливають ставленням. Якщо пояснити більш детально, люди не завжди розуміють важливість саппорта і не надають треюбущейся саппорт підтримки. Наприклад, додаток може бути описано досить слабо технічним редактором (і це не рідкість), і інформацію можна отримати тільки у тих, хто має безпосереднє відношення до створення архітектури або визначення функціоналу. Завдання для саппорта часто буває складною, і ти відчуваєш себе в якості «жебраки».

Як стати і куди рухатися далі

Для L2Support Engineers потрібні базові знання Windows/Linux OS, баз даних, загальні знання в галузі системного адміністрування мереж, архітектури системи. Для L3— більш глибокі знання з вищезазначених тем, а також хороші знання Unix-Based OS, навички скриптования, знання моніторингових систем.

Для роботи в компаніях, спрямованих на іноземні ринки, обов'язковий англійської не нижче середнього рівня.

«Робота в супорті, на мій погляд, чимось схожа на „передову“ на війні. Тут потрібна стійкість, швидка реакція, звичайно ж знання своєї справи і стресостійкість».

З особистих якостей:

стресостійкість;
посидючість;
гарна пам'ять;
навченість, вміння швидко знаходити інформацію для вирішення проблем.

«Саппорт повинен бути гнучким, уміти швидко реагувати і адаптуватися під ситуацію. Важливі комунікаційні навички — не боятися говорити щось, ініціативність — не боятися дзвонити і повідомляти бізнес і менеджерів вищої ланки».

Можливі кар'єрні шляхи інженера техпідтримки:

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

P. S. Дякую за допомогу в написанні статті 30 українських інженерів техпідтримки, які розповіли DOU про свою професію. Наведені в статті цитати взяті з їх розповідей.

См. також:

Статті про інших спеціальностях в IT

Опубліковано: 11/01/17 @ 08:00
Розділ Різне

SEO Блог