IT Support Done Right: A Practical Field Guide

Більшість роботи в IT support оцінюється за швидкістю, але швидкість без методу просто переносить ту саму проблему далі по коридору. Квиток закритий за п'ять хвилин, який відкриється знову через три дні, коштує дорожче, ніж той, що займе двадцять хвилин, але насправді буде вирішений. Цей посібник охоплює звички, які відрізняють того, хто закриває квитки, від того, хто вирішує проблеми.

Почніть з реального збору інформації, а не припущення

Перед тим як торкатися машини, попросіть користувача описати проблему його власними словами, потім поставте три уточнюючих питання: коли це почалося, що змінилося недавно, і це відбувається щоразу чи час від часу. "Мій інтернет повільний" може означати DNS розв'язання, насичений Wi-Fi канал, несправний NIC або браузер з сорока вкладками. Запишіть точний текст помилки, якщо він є. Скріншоти краще описів — попросіть один перед тим, як просити користувача що-небудь спробувати.

Стримуйтеся від спокуси одразу перейти до "ви пробували перезавантажити". Це працює часто достатньо, щоб люди за умовчанням це робили, але якщо ви пропустите збір інформації, ви пропустите закономірності. Якщо три людини на одному комутаторі повідомлять про ту саму повільність в одну годину, це інший квиток, ніж один ноутбук з поганим драйвером.

Відтворіть перед тим, як виправляти

Якщо ви не можете відтворити проблему, ви не можете підтвердити, що ви її виправили. Попросіть користувача пройти крізь точні кроки на спільному екрані або зробіть це самі на його машині, якщо дозволяють віддалені інструменти. Перевірте ipconfig /all на Windows або ip a на Linux для базової мережевої перевірки, дивіться Event Viewer (eventvwr.msc) на помилки додатків і системи близько повідомленого часу, і перевірте journalctl -xe --since "1 hour ago" на Linux машинах для того ж вікна.

Для збоїв додатків отримайте точний номер білда і версію ОС. "Воно впало" вам нічого не говорить; "Outlook 16.0.17726 падає при відкритті запрошення календаря з вкладенням .ics" говорить вам, де шукати. Перехрестьте посилання зі відомими проблемами у примітках до версій постачальника перед тим, як припускати, що це локально.

Розподіліть за впливом, а не за тим, хто найголосніше кричить

Один користувач, заблокований у доступі до електронної пошти, — незручно. Спільний файловий сервер недоступний для сорока людей — це відключення. Побудуйте просту шкалу важкості — щось на кшталт P1 для відключень, що впливають на кількох користувачів або критичні системи, P2 для одиничних блокувань, P3 для зниженої але робочої функціональності, P4 для косметичних або зручних запитів — і застосовуйте її послідовно, навіть під тиском від менеджера, який хоче своє першим.

Задокументуйте рішення про важкість в самому квитку. Це захищає вас пізніше, коли хто-небудь запитує, чому їх P3 лежав два дні, поки ви обробляли три P1.

Виправте кореневу причину, а не симптом

Перезавантаження сервісу, який постійно падає, виграє час, а не рішення. Якщо spooler друку щодня помирає, перевірте Get-WinEvent -LogName Application -MaxEvents 50 на реальну помилку перед тим, як перезавантажити його знову. Якщо пароль користувача постійно несподівано закінчується, перевірте групову політику, застосовану до їх OU, замість простого скидання й переходу далі.

Ведіть особистий журнал повторюваних виправлень. Якщо ви знайдете себе, набираючи ту саму команду PowerShell або той самий реєстровий fix три рази, це знак, що це належить до скрипту або документованого runbook, а не до вашої голови.

Документуйте так, щоб хто-небудь інший це читав

Кожна розробка квитка повинна відповісти: яка була справжня причина, що було виправлено, і що ви перевірили б першим, якщо це трапиться знову. "Виправлено" як примітка розробки нікчемна для наступного техніка, включаючи вас через шість місяців без пам'яті про цей квиток.

Добра примітка розробки виглядає так: "Коренева причина: DHCP scope на VLAN 20 вичерпаний, нові пристрої отримали APIPA адреси. Виправлення: розширено scope від /24 до /23, резервування для принтера додане. Перевірка: перевірте кількість DHCP оренди щомісячно, порівняльний поріг встановлено на 90%." Те третє речення — це те, яке більшість техніків пропускає, і це те, яке запобігає повторному квитку.

Перенесіть з контекстом, а не просто переслав

Коли квиток переходить до tier 2 або постачальнику, включіть те, що ви вже виключили. "Перевірено кабелі, поміняно порт, підтвердженої конфігурації VLAN, ще ж немає link light" економить наступній людині від переробки ваших перших двадцяти хвилин. Розпливчасті escalations на кшталт "користувач каже, що це зламане, будь ласка радьте" просто переносять затримку замість того, щоб її видалити.

Закрийте цикл з користувачем

Розкажіть користувачу, що було неправильно простою мовою, а не просто "виправлено". Люди більше довіряють support, коли розуміють, що сталося, і це скорочує кількість разів, коли та сама людина подає той самий квиток в наступному місяці, тому що не зрозуміла, що це пов'язано.

Якщо ви хочете глибше заглибнутися в технічну сторону будь-чого з цього — основи мереж, журнали подій Windows або написання власних діагностичних інструментів — Korra Studio має segmenty на Networking, Systems та Scripting, які варто пройти далі.