Останній рубіж як працює друга лінія техпідтримки у рітейлі
У сфері рітейлу будь-який технічний збій – це великий стрес для співробітників магазину та прямі втрати бізнесу через перервані бізнес-процеси. В одному з попередніх матеріалів ми з'ясували, як виникають проблеми вирішують фахівці першої лінії підтримки сервісних компаній, які займаються супроводом торгової інфраструктури.
Цього разу В'ячеслав Шамбазов, керівник служби технічної підтримки «Пілота» розповів про другу лінію підтримки, інженери якої розбираються із найскладнішими та найкритичнішими технічними інцидентами.
Чим друга лінія підтримки відрізняється від першої
Перша лінія підтримки проводить класифікацію звернень замовників та намагається вирішити проблему самотужки. Якщо зробити це в короткий термін (5-15 хвилин) не вдається або потрібні додаткові компетенції, інцидент передається на другу лінію підтримки. Її співробітники мають глибші технічні навички, що дозволяє їм швидше розбиратися з проблемами, що виникають.
Обов'язково виконується повторна перевірка інформації, яку інженерові другої лінії передають співробітники першої. Це не означає, що користувачу, який зіткнувся з проблемою і перебуває в стані стресу, повторно ставлять ті самі питання. У нього з'ясовують додаткові деталі, які допоможуть якнайшвидше з'ясувати суть несправності.
Приклад: при помилках у базі даних у співробітників першої лінії підтримки може бути компетенцій адміністраторів баз даних (DBA), тому під час діалогу з користувачем можуть не поставити важливі питання, специфічні для конкретної БД. Вони просто з'ясовують деталі інциденту, а співробітники другої лінії вже ставлять глибші питання щодо інстанцій та запущених нанеобхідної машині послуг і кодів помилок.
Якою б налагодженою була робота першої лінії підтримки, завжди трапляються інциденти, які вона вирішити не зможе. Як наслідок вони потрапляють до інженерів другої лінії. Після часу завжди виконується ретроспективний аналіз заявок, що надійшли — це робиться з метою написання інструкцій або скриптів автоматизації, які в майбутньому дозволять співробітникам хелпдеску на першій лінії вирішувати подібні завдання самостійно.
Ретроспективний аналіз не можна робити надто часто (наприклад, щодня) через специфіку взаємодії різних служб у межах одного сервісного департаменту. Такі комунікації завжди регламентовані, тому інженери другої лінії підтримки не можуть змусити співробітників першої лінії щодня знайомитися з новими інструкціями та розумітися на роботі скриптів. Ця робота має свої цикли — у нас це місяць. Такий підхід дозволяє виділяти ресурси на виправлення проблем, створення описів і впровадження документів, що вийшли, та інструментів у роботу першої лінії підтримки.
Як це працює на практиці
Оскільки інженерів другої лінії підтримки завжди менше, ніж співробітників хелпдеску на першій, то заявки, що до них надходять, не виконуються в онлайн-режимі. При передачі на другу лінію заявка ставиться в чергу на обробку - зазвичай на це йде 30-45 хвилин.
При постановці в чергу аналізується терміновість та критичність заявки — якщо магазин зіткнувся із серйозною проблемою, то змушувати покупців та персонал чекати на рішення 40 хвилин ніхто не буде, і робота над інцидентом розпочнеться негайно. У договорах між рітейлерами та сервісними компаніями завжди прописується певний рівень SLA для термінових завдань. Таким чином, якщо компанія окремо вказала,що проблеми певного типу завдадуть серйозної шкоди бізнесу, такі заявки будуть оброблятися інженерами поза загальною чергою.
Розглянемо кілька реальних прикладів роботи другої лінії підтримки. До сервісної компанії надійшов дзвінок від касира магазину, на касі якого принтер перестав друкувати чеки. У такому разі перша лінія підтримки повинна виконати стандартні процедури з перевірки елементів касового блоку — наприклад, уточнити, чи не закінчився в принтері папір, чи не зажувала чекову стрічку, чи горять на пристрої всі необхідні індикатори — раптом, скажімо, хтось ногою випадково висмикнув провід із розетки.
Після цього користувача просять виконати тестові операції - наприклад, відправити на друк касовий звіт, щоб перевірити працездатність обладнання без пробиття нових товарів. Якщо проблема не вирішується, співробітник служби підтримки може спробувати підключитися до каси віддалено та провести додаткову діагностику щодо працездатності важливих служб та драйверів операційної системи.
Якщо інцидент так і не вдалося вирішити, створюється заявка для другої лінії підтримки. У цей тикет заноситься вся інформація про неполадки, а також описуються вжиті першою лінією дії для виправлення проблеми.
Інженери другої лінії, приступаючи до вирішення проблеми, перевіряють усі раніше зібрані в рамках роботи з інциденту дані та можуть вивчити базу знань із описами схожих збоїв. На відміну від співробітників першої лінії підтримки, ці фахівці мають доступ до статистики інцидентів за всіма замовниками та мають більш глибокі знання в технічних областях. При надходженні інциденту вони можуть за регламентний час підібрати варіант його вирішення, навіть якщо подібні ситуації раніше незустрічалися та не документовані.
У нашому прикладі з печаткою чеків інженер може виявити, що на операційну систему були встановлені оновлення, що викликають конфлікти зі службами друку, або відбулися зміни в доменних політиках, що призвели до зміни прав доступу користувачів операційної системи. Або, наприклад, у принтері, через стрибок напруги, зіпсувався мікрокод керуючої програми і тепер потрібно його «прошивати» заново.
Після виявлення проблеми найпростіший спосіб її вирішення – відновлення образу системи з зразка. Якщо з якоїсь причини еталонних зразків немає — таке можливо на етапі пілотного впровадження технологій — доводиться займатися внесенням потрібних налаштувань вручну.
У нашій практиці такі ситуації є досить рідкісними, оскільки один із пріоритетів роботи сервісної служби в рітейлі — це швидкість відновлення працездатності. А найшвидше вирішити проблеми можна за допомогою відновлення системи з еталона.
Друга лінія, отримавши подібну заявку, може, не відволікаючись на прості питання про об'єкт, розпочати вирішення безпосередньо самої заявки, тобто в нашому прикладі це усунення виявлених розбіжностей у звітах. Ця операція може займати досить тривалий час і може бути наслідком багатьох різних факторів, з якими інженери другої лінії добре знайомі і мають необхідні компетенції.
Ще одним прикладом підключення інженерів другої лінії до вирішення заявок, які не можуть бути вирішені на рівні першої лінії підтримки, часто є збої серверного обладнання. Воно вимагає значної компетенцій обслуговування, а збої у його роботі який завжди виражаються у явному виході з ладу апаратних компонент сервера. Тому заявка передається на другу лініютехнічної підтримки та її фахівці намагаються усунути інцидент. Він може виражатися в порушенні теплового режиму експлуатації сервера, виході з ладу окремих елементів (збої в роботі пам'яті, збійні сектори на жорстких дисках, виході з ладу елементів живлення кеш пам'яті), порушенні роботи серверного ПЗ (СУБД, ERP, BI) або помилках взаємодії коїться з іншими, зовнішніми стосовно цього серверу, системами.
Висновок: чому рітейлери не обслуговують інфраструктуру самі
У сервісних компаній великий досвід роботи з технологіями, що використовуються у сфері рітейлу (наприклад, нашій компанії 25 років — і знань накопичилося порядно). Наші інженери стикалися зі значною кількістю інцидентів, що сталися в різних розмірах і типах інфраструктур. Все це сприяє набуттю різнобічного досвіду вирішення реальних проблем.
Ніщо не заважає рітейлерам займатися розвитком власних ІТ-департаментів, проте робота з технологіями — це не бізнес таких компаній, їхнє завдання продавати товари.
Крім того, технологічні аутсорсери мають можливості підлаштовуватися під піки активності бізнесу, коли може виникати найбільше проблем — якщо рітейлер продає гаджети Apple, то восени і навесні після виходу нових пристроїв у його магазинах завжди буде наплив покупців і, як наслідок, виникне більше збоїв торгової інфраструктури. Сил власних ІТ-фахівців для вирішення всіх проблем може вистачити, а наймати більше людей не вигідно для бізнесу.
А ми, наприклад, як сервісна компанія, можемо виділяти додаткових співробітників для роботи під час таких піків і навіть формувати спеціальні команди інженерів, які працюють над завданнями конкретного замовника. Це набагато вигідніше для бізнесу, ніж витрачати сили та ресурси нарозвиток непрофільних ІТ-компетенцій.