Поддержка пользователей 01. Как устроена поддержка: уровни, заявки, приоритеты

В 9:05 в чат пишет petrova из бухгалтерии: «У меня всё сломалось!!! Срочно!!!». Через минуту звонит ivanov: «Не печатает принтер отдела, сделайте что-нибудь». Руководитель заглядывает в кабинет и просит «глянуть почту директора вне очереди». Если отвечать тому, кто громче, к обеду вы забудете, кто о чём просил, потеряете половину подробностей и испортите отношения со всеми сразу.

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

• понимать, что делает первая линия и когда передавать задачу;
• вести заявку так, чтобы её мог продолжить любой коллега;
• назначать приоритет и объяснять его пользователю;
• разговаривать так, чтобы человек помогал, а не защищался;
• не создавать риски безопасности себе и пользователям.

Если нужно сразу к проблеме, начните с таблицы.

Что нужно знать заранее

Достаточно уверенно пользоваться Windows. ITIL (популярный набор практик управления ИТ-услугами) знать не нужно, и статья не про него: мы берём только то, что помогает в первый рабочий месяц.

Важно различать, на чём основан каждый совет:

Среда в примерах — домен lab.example: сотрудники ivanov и petrova, компьютеры PC1 и PC2, сервер DC1 (контроллер домена) и сервер FS1 (файлы и печать), принтер бухгалтерии PRN-ACC1 (путь \\FS1.lab.example\PRN-ACC1). Читатель серии — один специалист с двумя учётными записями: helpdesk1 (группа GG-HelpDesk, по умолчанию) и admin-lab (вторая линия); в большой фирме это разные люди. Как создать группу и выдать ей право сбрасывать пароли в одном OU (organizational unit, подразделение каталога), показано в Windows Server с нуля 05: там тестовый помощник называется helper1, а здесь мы используем имя helpdesk1. Создайте его так же и добавьте в GG-HelpDesk.

Уровни поддержки

Поддержку принято делить на линии (уровни; их же обозначают L1, L2, L3 или Tier 1–3). Это договорённость, а не стандарт: названия и границы у каждой организации свои. Смысл один: каждая линия решает то, что ей по силам и по правам, а остальное передаёт вместе с контекстом.

В небольшой фирме все три линии могут быть одним человеком. Роли от этого не пропадают: вы по-прежнему ведёте заявку и каждый раз решаете, можно ли сделать шаг безопасно и в рамках своих прав. Что именно доступно первой линии в нашей лаборатории (практика автора, опирающаяся на делегирование из Windows Server с нуля 05):

В остальных статьях серии шаги с пометкой «(вторая линия)» требуют прав администратора: первая линия передаёт их вместе с результатами проверок.

Минимальные права первой линии — не бюрократия. Принцип наименьших привилегий в документации Microsoft сформулирован так: входить нужно с учётной записью, у которой ровно столько прав, сколько нужно для текущей задачи. Как пример широких прав там названы права сотрудников helpdesk на сброс паролей у многих учётных записей; поэтому в лаборатории сброс делегирован на одно подразделение (OU), а не на весь домен (практика автора).

Чего первая линия не делает без отдельного согласования (практика автора): не меняет групповые политики и права на общие папки, не правит реестр и системные файлы «по совету из интернета», не отключает защиту (брандмауэр, антивирус, контроль учётных записей, обновления) «чтобы заработало» и не удаляет данные без копии.

Когда передавать задачу на следующую линию (практика автора):

1. Не хватает прав или доступа. Не просите «одолжить» пароль администратора.
2. Типовые проверки пройдены, причина не ясна. Разумный предел — 15–30 минут; число выберите сами.
3. Затронуты несколько пользователей или сервис. Если FS1 недоступен для всех, это одна проблема, а не десять заявок.
4. Есть признаки инцидента безопасности (см. ниже).
5. Нужно изменение, которое нельзя откатить, или массовое изменение.

Заявка — единица работы

Заявка (тикет) — запись об обращении, у которой есть номер, автор, история и исполнитель. Без неё теряется память («мы же это уже чинили»), невозможно передать работу коллеге и некому увидеть, что три обращения за день — одна поломка. Система заявок может быть любой: от общего почтового ящика с таблицей до специализированной программы. Выбирайте по возможностям: номер, поля, история изменений, назначение исполнителя, вложения, поиск, уведомления.

Минимальный набор полей (практика автора):

Плохая заявка: «Не работает принтер. Петрова». Хорошая: «petrova, PC1, каб. 12: печать на PRN-ACC1 из Word даёт «Принтер недоступен» с 9:10; вчера работало; пароль меняла в пятницу; задание висит в очереди; затронута только она, отчёт нужен к 15:00; перезагрузка не помогла».

Часть данных проще узнать, чем спрашивать. Имя устройства и версию Windows показывает раздел «Параметры → Система → О программе» (так назван он в ru-ru справке; в вашей сборке может называться «О системе»), а кто вошёл в систему — команда whoami:

whoami

Пример вывода:

lab\petrova

Скриншот ошибки пользователь сделает сочетанием Win+Shift+S (приложение «Ножницы»); клавиша PrtSc кладёт снимок всего экрана в буфер обмена.

Статусы заявки (практика автора): «Новая» → «В работе» → «Ждём пользователя» → «Передана» → «Решена» → «Закрыта». «Решена» и «закрыта» — разные вещи: закрывайте после того, как пользователь подтвердил результат, или после срока ожидания, который принят у вас в организации.

Приоритет: влияние и срочность

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

Ориентиры реакции можно задать условно: P1 — немедленно, P2 — в течение часа, P3 — в течение рабочего дня, P4 — по мере возможности. Это иллюстрация, реальные цели определяет договорённость с руководством.

Правила приоритета (практика автора):

• Приоритет определяют последствия для работы, а не громкость голоса и не должность. Исключения (например, день важной презентации) лучше записать в правила заранее, чем решать «по ситуации».
• Приоритет пересматривают. Пока вы диагностировали, выяснилось, что та же ошибка у соседнего отдела, — повышайте.
• Однотипные заявки связывают с одной основной: так видно масштаб.
• Объясняйте решение человеку: «Я поставил обычный приоритет: затронут только ваш компьютер, а отчёт можно напечатать на принтере отдела. Если срок горит, скажите: пересмотрим».

Близкая идея есть в руководстве NIST SP 800-61 Rev. 3 по реагированию на инциденты безопасности: из-за ограниченных ресурсов обращения не обрабатывают в порядке поступления, а оценивают по набору факторов риска, например критичности актива и влияния на работу. Матрицы «влияние × срочность» там нет, и для обычных заявок это лишь аналогия.

Общение с пользователем

Всё в этом разделе — практика автора. Человек приходит к вам не в лучший момент: работа встала, он чувствует себя виноватым или раздражён. Ваша задача — быстро собрать факты и не добавить стресса.

• Выслушайте до конца и перескажите своими словами: «Правильно ли я понимаю, что принтер недоступен только у вас?»
• Задавайте один вопрос за раз. Сначала открытые («Что вы делали перед тем, как появилась ошибка?»), потом закрытые («Вчера печатало?»).
• Просите точный текст ошибки или скриншот: пересказ теряет детали.
• Давайте инструкции по одному действию и ждите ответа «готово».
• Говорите без жаргона: не «сбросьте кэш DNS», а «давайте обновим сетевые настройки».
• Не обещайте срок исправления, обещайте срок следующего сообщения: срок починки вам не принадлежит, а написать «пока новостей нет, проверю в 15:00» вы можете всегда.
• Не обвиняйте, даже если причина в пользователе. Говорите о событии, а не о человеке.
• Не бойтесь сказать «не знаю». «Не знаю, но выясню и напишу вам до 15:00» лучше уверенной догадки, которая окажется неверной.
• Результат подтверждайте вместе: пусть пользователь сам напечатает страницу.

Пример короткого диалога:

Пользователь: Принтер не печатает, сделайте что-нибудь!
Поддержка:    Понимаю, неприятно. Давайте разберёмся. Что вы видите
              на экране при печати?
Пользователь: «Принтер недоступен».
Поддержка:    Спасибо. Это принтер бухгалтерии? Вчера он печатал?
Пользователь: Да, вчера всё было нормально.
Поддержка:    Хорошо. Запишу в заявку. Сделайте, пожалуйста,
              скриншот этого окна: Win+Shift+S.

Если человек грубит, не спорьте и сведите разговор к фактам: «Что сейчас важнее всего — получить принтер или распечатать документ?» При угрозах и оскорблениях остановите разговор и обратитесь к руководителю.

Безопасность при работе с пользователем

Пароль не спрашивают и не принимают

NCSC в рекомендациях для пользователей прямо говорит: пароль нельзя сообщать никому, включая сотрудников ИТ-поддержки, ни лично, ни по телефону, ни письмом или сообщением. Если пароль забыт, ИТ-служба сначала подтверждает личность, а затем сбрасывает пароль. Почему это правило нужно, показывает NIST SP 800-63B-4 («Digital Identity Guidelines», июль 2025): среди примеров социальной инженерии указано, что пароль выдают по телефонному звонку от злоумышленника, который представился системным администратором.

Если пользователь начал диктовать пароль, остановите его: «Не говорите пароль. Я сброшу его, вы зададите новый сами». Как сбросить пароль и заставить сменить его при входе, объясняет Поддержка пользователей 05. Свой пароль тоже никому не называйте, а пароль администратора вводите только по правилу из Поддержка пользователей 02.

Личность проверяют до сброса

Сброс пароля или перенос многофакторной аутентификации (MFA, подтверждение входа вторым способом) — желанная цель для злоумышленника. В совместном предупреждении CISA, ФБР и их партнёров о группе Scattered Spider описано, как преступники представляются сотрудниками и убеждают helpdesk сбросить пароль и перенести MFA на их устройство. В блоге 2025 года NCSC советует пересмотреть, как служба поддержки проверяет сотрудника перед сбросом, особенно у привилегированных учётных записей, а NIST отмечает, что восстановление доступа с участием человека подвержено социальной инженерии.

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

Своя учётная запись, а не чужая

Принцип «у каждого свои средства входа» — давняя рекомендация (NIST SP 800-63B-4, приложение B.4). Не входите под учётной записью пользователя, «чтобы посмотреть, как у него»: попросите показать экран или используйте удалённую помощь (Поддержка пользователей 02). Повседневную работу ведите под helpdesk1, а admin-lab используйте только тогда, когда без прав администратора не обойтись, и не читайте под ним почту и не открывайте сайты.

Данные пользователя и журнал действий

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

Если это похоже на инцидент безопасности

Признаки: файлы внезапно не открываются или переименованы, на экране требование выкупа, пользователь открыл подозрительное вложение или ввёл пароль на сомнительной странице, пришли неожиданные запросы на подтверждение входа. Это уже не обычная заявка. Практика автора: не продолжайте «чинить как обычно», не удаляйте следы и передайте дело ответственному за безопасность по принятой процедуре. Расследует не первая линия; NIST описывает для группы реагирования первый шаг так: проверить, что инцидент действительно произошёл, затем оценить его серьёзность и срочность. Ваша задача — быстро и без потерь передать факты. Что делать дальше, разбирает Поддержка пользователей 10.

База знаний

База знаний — набор коротких статей «симптом → причина → решение». Она экономит время: второй раз та же проблема решается за минуту. Записывайте решение сразу после заявки, пока помните детали (шаблон, практика автора):

Название:    Принтер PRN-ACC1: «Принтер недоступен» после смены пароля
Симптом:     как говорит пользователь, текст ошибки
Условия:     Windows 11, подключение к \\FS1.lab.example\PRN-ACC1
Причина:     что оказалось источником
Решение:     шаги, по одному действию в строке
Проверка:    как убедиться, что исправлено
Откат:       как вернуть, если стало хуже
Источник:    ссылка на заявку, дата проверки, автор

Не храните в базе пароли, ключи и данные пользователей. Указывайте дату проверки: интерфейс и поведение Windows меняются, и инструкция месячной давности может устареть.

Эскалация и дежурство

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

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

Дежурство — договорённость, кто на связи в нерабочее время или в отпуск коллег. Минимум: график с именами, список контактов, доступ дежурного к инструкциям и понятное правило, что считается срочным.

Метрики: измеряйте осторожно

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

Состояние на ноябрь 2026 года (проверьте актуальность). NIST SP 800-61 Rev. 3 (апрель 2025) заменил редакцию 2012 года, а SP 800-63B-4 (июль 2025) заменил SP 800-63B. Прежняя модель из четырёх фаз реагирования относится к редакции 2012 года: в Rev. 3 жизненный цикл выстроен по функциям NIST Cybersecurity Framework 2.0. Рекомендации NCSC для пользователей опубликованы в 2016 году, блог NCSC о проверке службой поддержки — в мае 2025 года: сверяйте их с внутренними правилами вашей организации.

Типичные ошибки и недоразумения

• Заявки нет. «Я быстро посмотрю» заканчивается тем, что через неделю никто не помнит, что делалось.
• Приоритет по громкости. Громкий пользователь с одним принтером обгоняет тихий отдел без доступа к FS1.
• Пароль «для удобства». Пользователь сообщил пароль, вы им воспользовались, и теперь невозможно доказать, кто что делал.
• Сброс по звонку без проверки. Так проходят социальные атаки на службу поддержки.
• Обещан срок исправления. Срока вы не контролируете; пообещайте время следующего сообщения.
• «Решено» без проверки пользователем. Заявка возвращается завтра.
• Передача «без контекста». «Не работает, посмотрите» заставляет следующую линию начинать с нуля.

Проверьте себя

1. Почему приоритет заявки определяют по влиянию и срочности, а не по очереди поступления? Очерёдность по времени не учитывает последствия: один пользователь с неудобством не должен обгонять отдел, который не может работать. Близкая идея есть и в NIST для инцидентов безопасности: оценка по факторам риска, а не «в порядке поступления».
2. Пользователь предлагает продиктовать пароль, чтобы вы «зашли и посмотрели». Что вы ответите и сделаете? Остановить: пароль никому не сообщают, включая ИТ-поддержку; сбросить пароль по процедуре, чтобы пользователь сам задал новый, и записать в заявку.
3. Какие поля обязательны в заявке? Кто, где, что (дословно), когда началось, что менялось, влияние и срочность, что уже пробовали (практика автора).
4. Когда первая линия передаёт заявку дальше? Нет прав, причина не ясна после типовых проверок, затронуты многие, есть признаки инцидента безопасности или нужно необратимое изменение; передавать нужно с полным контекстом.
5. Вам позвонили «от имени» сотрудника и просят сбросить пароль директора. Как поступить? Не сбрасывать по одному звонку: проверить личность, перезвонив по номеру из справочника или получив подтверждение руководителя, и записать способ проверки в заявку.

Что дальше

• Поддержка пользователей 02. Удалённая помощь — как подключаться к пользователю быстро и безопасно.
• Поддержка пользователей 03. Диагностика ПК с Windows — журналы и проверки, которые нужны для заявки.
• Поддержка пользователей 05. Учётные записи и пароли — безопасный сброс пароля и блокировки.
• Поддержка пользователей 10. Потеря данных и фишинг — что делать при признаках инцидента.

Источники

• NIST SP 800-61 Rev. 3. Incident Response Recommendations and Considerations for Cybersecurity Risk Management — замена редакции 2012 года; приоритизация, триаж, проверка сообщений об инциденте
• NIST SP 800-63B-4. Digital Identity Guidelines: Authentication and Authenticator Management — пример социальной инженерии (раздел 6.1), риски восстановления с участием человека (6.3), совместное использование аутентификаторов (приложение B.4)
• NCSC: Advice for End Users — пароль нельзя сообщать даже сотрудникам ИТ-поддержки; личность подтверждают перед сбросом (страница 2016 года)
• NCSC: Incidents impacting retailers (блог NCSC, 4 мая 2025) — рекомендация пересмотреть проверку сотрудников службой поддержки перед сбросом пароля
• CISA: Scattered Spider (AA23-320A) — социальная инженерия в отношении helpdesk, перенос MFA, имитация службы поддержки
• Implementing Least-Privilege Administrative Models — принцип наименьших привилегий, риск широких прав helpdesk
• whoami — вывод текущего домена и имени пользователя
• Find information about your Windows device — имя устройства и версия Windows в «Параметры → Система → О программе» (название по ru-ru странице)
• Use Snipping Tool to capture screenshots — сочетание Win+Shift+S и клавиша PrtSc; русское название приложения «Ножницы» — по ru-ru странице