Инженер технической поддержки: обязанности и инструкция
Кратко
Инженер технической поддержки — должность на стыке первой и второй линии: он не только отвечает на обращения, но и разбирается в причине неполадки, а не просто передаёт её дальше. Разница с должностью «специалист технической поддержки» — в требуемой технической глубине: сети, серверы, интеграции, логи (инструкция для этой смежной должности собрана отдельно — должностные обязанности специалиста поддержки). Ниже — готовая должностная инструкция с этой разницей внутри, а не выдуманная заново.
Актуально на 23 сентября 2026 года.
Чем инженер отличается от специалиста и оператора
Три соседние должности часто путают, потому что обязанности пересекаются. Разница — в глубине разбора и в том, кого зовут, когда типовой ответ не решает вопрос.
| Должность | Что делает | Когда нужна |
|---|---|---|
| Оператор / специалист поддержки | Отвечает по инструкции и базе знаний, эскалирует непонятное | Поток типовых обращений, чат и почта |
| Инженер технической поддержки | Разбирает причину: смотрит логи, конфигурацию, интеграции; может воспроизвести неполадку | Вторая линия, технически сложный продукт |
| Системный / DevOps-инженер | Меняет инфраструктуру и код, а не только диагностирует | Когда причина — не в настройках клиента, а в самой системе |
Ещё одна смежная роль — тот, кто отвечает за пользователей конкретного продукта компании, а не за внешних клиентов; её обязанности расписаны в статье функции специалиста поддержки пользователей.
Если в одной вакансии написано и «отвечать на обращения в чате», и «дорабатывать интеграции с 1С», это на самом деле две должности под одним названием — именно так должностные инструкции превращаются в список обид на испытательном сроке.
Готовый образец
ДОЛЖНОСТНАЯ ИНСТРУКЦИЯ
инженера технической поддержки
Утверждаю: <должность, подпись, ФИО>
Дата: <ДД.ММ.ГГГГ>
С инструкцией ознакомлен: <подпись, ФИО, дата>
1. Общие положения
1.1. Инженер технической поддержки (далее — Инженер) относится к категории специалистов и подчиняется непосредственно <руководителю службы технической поддержки>.
1.2. На должность назначается лицо со средним профессиональным или высшим техническим образованием и опытом работы с <перечень систем: сети, СУБД, API, конкретный стек продукта> не менее <1 года>.
1.3. Инженер обязан знать устройство поддерживаемого продукта на уровне, достаточном для чтения логов и воспроизведения неполадки, порядок эскалации к разработке и границы своих полномочий на изменение конфигурации.
1.4. В организациях с регулируемой деятельностью (банк, финансовая организация, госсектор) в раздел 1 добавляется пункт о допуске к сведениям ограниченного доступа и обязательном прохождении проверки безопасности.
2. Должностные обязанности
| № | Обязанность | Проверяемый результат |
|---|---|---|
| 2.1 | Принимать обращения, эскалированные с первой линии, с уже собранным первичным описанием | Обращение принято с указанием шагов воспроизведения |
| 2.2 | Воспроизводить неполадку или устанавливать, что она не воспроизводится в текущих условиях | В карточке зафиксирован результат попытки воспроизведения |
| 2.3 | Анализировать логи, конфигурацию и историю изменений для установления причины | Причина указана словами, а не «не работает» |
| 2.4 | Устранять неполадку в пределах своих полномочий либо готовить точную постановку для разработки | Постановка содержит шаги воспроизведения, ожидаемый и фактический результат |
| 2.5 | Проверять исправление перед закрытием обращения, а не со слов клиента | Отметка о проверке в карточке обращения |
| 2.6 | Вести и пополнять базу знаний по решённым техническим случаям | Не менее <2> статей в месяц по новым причинам |
| 2.7 | Соблюдать требования по обработке персональных данных и конфиденциальных сведений заказчика | Передачи сведений вне рабочей системы нет |
3. Права
3.1. Запрашивать у клиента доступ к среде, логам или воспроизведению для диагностики.
3.2. Эскалировать к разработке без ожидания порога SLA при признаках системной, а не единичной неполадки.
3.3. Отказывать в изменениях вне зоны ответственности с указанием, кто отвечает за них.
3.4. Вносить руководителю предложения по устранению повторяющихся технических причин обращений.
4. Ответственность
4.1. За неисполнение обязанностей раздела 2 — в пределах трудового законодательства <страна>.
4.2. За закрытие обращения без фактической проверки решения.
4.3. За разглашение сведений, ставших известными при диагностике.
5. Показатели оценки
| Показатель | Норма | Период |
|---|---|---|
| Доля обращений с установленной причиной (не «не воспроизвелось») | не ниже <80 %> | месяц |
| Доля повторных обращений по той же причине в течение 30 дней | не выше <10 %> | месяц |
| Среднее время диагностики от приёма до постановки причины | не выше <норматив SLA второй линии> | месяц |
| Число статей базы знаний по новым причинам | не менее <2> | месяц |
Как заполнять
Пункт 1.2 (требования к опыту). Указывайте конкретный стек, а не общее «технический бэкграунд» — так отсеиваются кандидаты без нужного опыта ещё на этапе резюме, а не на испытательном сроке.
Пункт 1.4 (финансовая организация). Если вакансия открыта в банке или другой регулируемой организации, требование о допуске и проверке безопасности обязано попасть в инструкцию до выхода сотрудника, а не после первого инцидента с доступом к данным клиентов.
Показатель 2.4 против 2.2. Норма «доля с установленной причиной» работает только вместе с честным правом написать «не воспроизвелось» (пункт 2.2) — иначе инженер начнёт придумывать правдоподобную причину, чтобы не портить показатель.
Частые ошибки
Инженеру дают обязанности первой линии целиком. Если инженер отвечает на весь входящий поток, а не только на эскалированные случаи, показатель «время диагностики» станет бессмысленным — он смешается со временем ожидания в очереди.
Нет права отказать в изменении вне зоны ответственности (3.3). Без этого пункта инженер поддержки постепенно превращается в бесплатного разработчика по любому запросу клиента.
Показатели скопированы у специалиста первой линии. Медиана первого ответа — метрика первой линии; для инженера важнее время до установленной причины и доля решений с первого раза.
Частые вопросы
Чем должностная инструкция инженера отличается от инструкции специалиста поддержки?
Разделом обязанностей и показателями: у специалиста — приём и типовой ответ, у инженера — диагностика причины и решение того, что типовым ответом не закрывается. Общие разделы (права, ответственность) можно взять из инструкции специалиста и заменить раздел 2.
Нужен ли инженеру технической поддержки доступ к инфраструктуре?
Ровно тот, что нужен для диагностики: логи, конфигурация, тестовая среда. Доступ на изменение продакшена — отдельное право, которое стоит выдавать не по должности, а по конкретной задаче.
Как оформить должность инженера поддержки пользователей, если он один на компанию?
Убрать из раздела 2 пункты про эскалацию к разработке, если разработки в компании нет, и добавить обязанность вести список известных ограничений системы — она заменяет функцию отдельной базы знаний второй линии.
Как это устроено в TehProf.kz Support
Инженер второй линии в TehProf.kz Support обычно получает роль «Оператор» с расширенными правами: видимость всех заявок компании (а не только своих), право объединять и разъединять заявки при повторных обращениях по одной причине, и доступ к внутренним заметкам с историей переписки по заявке — состав прав настраивается на экране Роли и права. Если инженеру нужно видеть нагрузку и время диагностики по своим заявкам, доступ к вкладке «Операторы» аналитики выдаётся отдельным правом «Аналитика».
Связанные статьи
- Должностная инструкция специалиста технической поддержки: образец
- Оператор техподдержки: обязанности и инструкция
- Специалист поддержки клиентов: обязанности
- Что такое эскалация обращения и когда её запускать
- Схема эскалации обращений: образец правил и уровней
Нужна поддержка, которая так и работает?
TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.