Обробка звернень

Звернення поділяються на декілька типів:

Запит – стандартне звернення надання доступу, активації закладів, декларацій, технічних питань та підпис договорів;

Інцидент – масова проблема в роботі ЦК;

Проблема – запит на присутність помилок валідацій, тощо;

У випадках, якщо певна проблема масова та розповсюджена в усіх МІС, до задачі, у полі Organizations ставиться значення All MISes (співробітниками служби підтримки):

Правила проставлення пріоритетів:

Urgent - невідкладний пріоритет (задачі беруться в роботу терміново і позачергово); Такий пріоритет присвоюється задачам, що описують проблему, яка впливає на працездатність системи (сповільнення роботи або недоступність) в цілому.

High - високий пріоритет (задачі є першочерговими до виконання); Такий пріоритет присвоюється задачам, які унеможливлюють роботу компоненту або декількох та впливають на систему в цілому.

Normal - середній пріоритет (задачі виконуються планово і виконуються після виконання всіх задач зі статусом High). Такий пріоритет присвоюється задачам, які описують помилки в одному з компонентів, що унеможливлюють роботу саме цього компоненту, але не впливають на роботу системи в цілому;

Low - низький пріоритет (задачі є не пріоритетними і виконуються після виконання всіх задач зі статусом High та Normal). Такий пріоритет присвоюється задачам з середовища PreProd та рішення яких не будуть впливати на роботу системи.

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

Перевіряється відповідність достатнього опису до заголовку звернення та наявність логів чи інших матеріалів. При відсутності достатнього опису, інженер просить доповнити, при відсутності логів – додати їх.

Для кожного звернення, інженер SD має

вказати відповідні мітки, для полегшення пошуку звернень та статистичних обробок.
додати учасників з команди підтримки, щоб вони могли відслідковувати зміни у зверненні. А саме: спостерігачами додаються інші інженери техпідтримки, а учасниками додаються (request participants) tech Lead, ВА від ДП та BA НСЗУ(за потреби)

Логи з Prod середовища, обов’язково мають бути у кодуванні UTF-8 та повинні бути заархівовані і захищені паролем, який узгоджено з службою підтримки ДП.

При взятті в роботу звернення інженер техпідтримки має змінити статус задачі на “В роботі/ вивчається фахівцями”, далі ознайомлюється з описом проблеми та наданими логами.

В звернення, в якому розглядається помилка роботи системи Ehealth чи інші, має бути доданий відповідальних бізнес аналітик, в результаті розгляду і дослідження конкретного випадку бізнес аналітиком питання може бути передане на виправлення команді техпідтримки другої лінії, вендору задача передається лише самим бізнес аналітиком. В такому випадку задачі призначається статус “Передано розробникам” та додатково зв’язуються з задачами, що передаються на розробників.

Через деякий час, коли розробники зробили виправлення та надали фідбек, інженер технічної підтримки опрацьовує повідомлення від розробника та надає додаткову консультацію по вирішенні проблеми. У випадку потреби вендору або L2, L3 інших логів, додаткової інформації про систему тощо, інженер виконує запити до відповідальних осіб або МІС на отримання потрібної інформації.

Деякі типи звернень можуть стосуватися юридичних питань, бізнес процесів, або питань що не пов’язані з компетенціями технічних спеціалістів,де долучаються команди PM/BA та НСЗУ, де вони дають зворотній зв’язок на питання у зверненні.

Спеціаліст надає відповідь автору запиту та переводить тікет в статус “Очікує реакції автора” для отримання підтвердження від МІС, а якщо відповіді немає - повідомляє МІС про факт прийняття в роботу запиту, звертається за консультацією та переводить тікет в статус “В очікуванні”.

Перед закриттям звернення, вказується затрачений час інженером на вирішення проблеми.

Звернення закривається та переводиться у статус “Вирішено/Оброблено” після підтвердження з боку МІС або у випадку відсутності зворотнього зв’язку з боку автора протягом 5 робочих днів.