Operațiuni IT

Helpdesk & Task Manager

Toate cererile către IT intră într-o singură coadă, cu termene SLA măsurate și baza de cunoștințe la îndemână.

Versiune
2.2.0
Stadiu
Stabil
Capturi
4
Înlocuiește
Helpdesk plătit per agent (Freshservice, Jira Service Management)
Coada de lucru a helpdesk-ului. Cele 14 tichete active, ordonate după urgență: cele două peste SLA apar primele, marcate cu roșu, apoi P1 și P2. Fiecare card arată sursa (portal, e-mail sau alertă automată), responsabilul și timpul rămas până la termenul SLA.
Coada de lucru a helpdesk-ului. Cele 14 tichete active, ordonate după urgență: cele două peste SLA apar primele, marcate cu roșu, apoi P1 și P2. Fiecare card arată sursa (portal, e-mail sau alertă automată), responsabilul și timpul rămas până la termenul SLA.

Capturi din aplicație

Cum arată în lucru

Interfața reală Monolit, cu datele unei firme fictive într-o zi obișnuită. Apăsați pe o captură ca s-o vedeți la dimensiune completă.

Sarcinile zilei, generate din șabloane. Verificările de rutină (backup, UPS, alerte SOC, conturi blocate, patch-uri) apar automat în fiecare dimineață, cu listă de pași și ora-țintă. Deasupra stau tichetele asignate utilizatorului, cu termenul SLA.
Captura 2 din 4

Sarcinile zilei, generate din șabloane

Verificările de rutină (backup, UPS, alerte SOC, conturi blocate, patch-uri) apar automat în fiecare dimineață, cu listă de pași și ora-țintă. Deasupra stau tichetele asignate utilizatorului, cu termenul SLA.

Detaliul unui tichet. Tichetul P1 pentru stația izolată după o alertă antivirus: comentarii publice și note interne, fișiere atașate (inclusiv mesajul original primit pe e-mail) și istoricul complet al acțiunilor, cu autor și oră.
Captura 3 din 4

Detaliul unui tichet

Tichetul P1 pentru stația izolată după o alertă antivirus: comentarii publice și note interne, fișiere atașate (inclusiv mesajul original primit pe e-mail) și istoricul complet al acțiunilor, cu autor și oră.

Baza de cunoștințe. Articole interne pentru echipa IT și articole publice pentru portalul utilizatorilor, cu etichete, număr de vizualizări și stare (publicat sau ciornă). Tot aici se gestionează răspunsurile predefinite folosite în tichete.
Captura 4 din 4

Baza de cunoștințe

Articole interne pentru echipa IT și articole publice pentru portalul utilizatorilor, cu etichete, număr de vizualizări și stare (publicat sau ciornă). Tot aici se gestionează răspunsurile predefinite folosite în tichete.

1Nivelul 1

Pentru conducere

Ce problemă rezolvă, cum se lucrează cu modulul și ce se poate măsura.

Ce problemă rezolvă

Cererile către IT vin pe mai multe căi: telefon, e-mail, discuții pe hol, alerte automate. Fără un singur loc de evidență, unele se pierd, altele se rezolvă de două ori, iar conducerea nu știe cât durează o rezolvare sau cât de mulțumiți sunt colegii. Pe lângă cereri, echipa IT are verificări zilnice (backup, UPS, conturi, actualizări) care se fac din memorie sau nu se fac deloc.

Task Manager adună în același modul tichetele de helpdesk și sarcinile de rutină ale echipei IT, cu termene, responsabili și istoric.

Ce face, concret

  • Tichete cu prioritate și termen SLA. Fiecare tichet are o prioritate de la P1 (critic) la P4 (minor), un termen de răspuns și un termen de rezolvare. Interfața arată cât timp a mai rămas și marchează cu roșu tichetele care au depășit termenul.
  • Mai multe surse de intrare. Tichetele se creează din interfață, din portalul utilizatorilor (și fără cont), din e-mailurile trimise la căsuța de helpdesk și automat, de alte module Monolit (de exemplu RMM).
  • Cozi de lucru pe echipe. Tichetele intră automat în coada potrivită, după categorie. Fiecare coadă are membri și numărul de tichete deschise.
  • Coada IT. O listă unică a tichetelor active, cu cele urgente primele, filtre („ale mele”, „neasignate”, pe coadă) și acțiuni în masă.
  • Comunicare cu solicitantul. Comentarii publice și note interne, răspuns pe e-mail direct din tichet, răspunsuri predefinite completate automat cu numele solicitantului și numărul tichetului.
  • Pauză de SLA. Când se așteaptă un răspuns de la utilizator, ceasul SLA se oprește; la reluare, termenele se decalează cu durata pauzei.
  • Evaluarea satisfacției. După rezolvare, solicitantul poate da o notă de la 1 la 5 și un comentariu. Media pe 30 de zile apare în indicatori.
  • Sarcini recurente din șabloane. Verificările de rutină (zilnice, săptămânale, lunare, trimestriale, anuale sau o singură dată) apar automat în lista zilei, cu ora-țintă și listă de pași; pașii obligatorii sunt marcați.
  • Bază de cunoștințe. Articole interne pentru IT și articole publice pentru portal, cu etichete și căutare.
  • Calendar. Ședințe, ferestre de mentenanță, ferestre de schimbare și termene.

Fluxuri de lucru

1. O cerere venită de la un coleg

  1. Colegul trimite cererea din portal sau pe e-mail, la căsuța de helpdesk.
  2. Tichetul primește categorie și prioritate și intră în coada implicită a categoriei.
  3. Un membru al echipei îl preia („Preia tu”) sau managerul IT îl asignează.
  4. Tehnicianul răspunde pe e-mail din tichet, eventual pornind de la un răspuns predefinit. Dacă așteaptă informații, pune SLA-ul pe pauză.
  5. Tichetul se închide cu o categorie de rezoluție (remediat, instrucțiuni oferite, duplicat, fals pozitiv, nicio acțiune necesară, altele) și note.
  6. Solicitantul evaluează rezolvarea (1–5).

2. O alertă tehnică devenită tichet

  1. Un modul de monitorizare (de exemplu RMM) creează tichetul prin API, fără intervenție umană.
  2. Tichetul apare în Coada IT, cu termen SLA calculat din prioritate.
  3. Dacă termenul trece, tichetul este marcat „SLA depășit”, iar modulul publică un eveniment pe care îl preia SOC.

3. Ziua de lucru a echipei IT

  1. Dimineața, lista „Azi” conține sarcinile generate din șabloanele active, plus tichetele asignate utilizatorului.
  2. Tehnicianul bifează pașii fiecărei sarcini; sarcinile neterminate din zilele trecute apar ca depășite.
  3. La angajări, modulul HR creează sarcini IT (cont, stație, VPN) direct în Task Manager.

Indicatori pe care îi măsoară

  • sarcinile zilei: finalizate din total;
  • sarcinile depășite;
  • tichetele deschise și cele în lucru;
  • tichetele peste termenul SLA;
  • rata de finalizare a sarcinilor pe ultimele 7 zile;
  • timpul mediu de rezolvare;
  • satisfacția solicitanților pe 30 de zile (media notelor, procentul de mulțumiți, numărul de evaluări).

Numărul de tichete deschise și sarcinile întârziate apar și pe pagina principală Monolit.

2Nivelul 2

Pentru echipa IT

Arhitectură, integrări, API, roluri și limitările cunoscute.

Arhitectură

  • Serviciul task_manager, versiunea 2.2.0, rulează ca serviciu systemd monolit-task-manager pe portul 8002, în spatele Nginx, cu prefixul /api/tasks.
  • Backend FastAPI + SQLAlchemy, date în MS SQL Server 2022, schema tasks. Comunicarea cu alte module se face prin evenimente Redis.
  • Instalarea inițială încarcă 38 de șabloane de sarcini, 8 categorii și 35 de subcategorii de tichete.
  • Variabile de mediu obligatorii: DB_HOST, DB_USER, DB_PASSWORD, SECRET_KEY. Depinde de core_service ≥ 2.0.0 (autentificare).

Procese automate

  • Sarcinile zilei se generează din șabloanele active (GET /api/tasks/today).
  • Căsuța de helpdesk se citește prin IMAP; configurația păstrează ora ultimei citiri, ultimul succes și eșecurile consecutive. Citirea se poate porni și manual. Răspunsurile pleacă prin SMTP.
  • La depășirea unui termen SLA, backend-ul publică evenimentul tasks.sla_breach.

Integrări și protocoale

Direcție Mecanism Detalii
publică eveniment tasks.sla_breach task_id, title, priority, overdue_hours; consumat de SOC
publică eveniment tasks.ticket_created ticket_id, title, priority, created_by, is_portal
consumă eveniment rmm.alert_created alertele RMM
primește POST /api/tasks/tickets apelat de RMM pentru tichete automate
primește POST /api/tasks/ apelat de HR la onboarding (cont AD, stație, VPN)
e-mail IMAP și SMTP, cu SSL/TLS configurabil configurare din Setări; parolele se salvează criptat și se afișează mascat
citit de GET /api/tasks/kpi pagina principală Monolit

Endpoint-uri notabile

Contractul declară 76 de endpoint-uri (plus /health). Cele mai importante:

  • GET /api/tasks/kpi — indicatorii din antet și de pe pagina principală;
  • GET /api/tasks/tickets/queue — Coada IT, cu filtre queue_id, mine, unassigned;
  • POST /api/tasks/tickets/bulk — acțiuni în masă (rezolvare, schimbare de prioritate, mutare în altă coadă, închidere);
  • POST /api/tasks/tickets/{id}/pause-sla și /resume-sla — ceasul SLA;
  • GET /api/tasks/tickets/{id}/history — istoricul modificărilor;
  • POST /api/tasks/tickets/{id}/attachments — atașamente (multipart, plafon și tipuri validate);
  • POST /api/tasks/tickets/{id}/reply — răspuns către solicitant pe e-mail;
  • GET /api/tasks/tickets/{id}/canned/{cid} — răspuns predefinit cu variabilele {{nume}}, {{prenume}}, {{ticket}}, {{titlu}}, {{agent}} completate;
  • GET /api/tasks/queues, GET /api/tasks/kb, GET /api/tasks/canned — cozi, bază de cunoștințe, răspunsuri predefinite;
  • rutele /api/tasks/portal/... — portalul: tichete proprii, tichete fără cont (plafon per IP, identificare prin sesiune), articole publice, evaluare CSAT prin jeton.

Roluri și audit

  • Aproape toate rutele cer autentificare. Crearea și modificarea categoriilor, administrarea cozilor, răspunsurile predefinite, ștergerea articolelor și configurarea căsuței de e-mail cer rolul it_manager.
  • Conținutul paginii „Configurare” (cozi, membri, rutare pe categorii) este disponibil doar pentru admin și it_manager; ceilalți văd mesajul „Acces restricționat”.
  • Rutele de portal marcate public (formular, articole publice, evaluare) nu cer cont; portalul fără cont nu vede notele interne și nici atașamentele interne.
  • Fiecare tichet are istoric: creare, schimbări de câmp (stare, prioritate, responsabil, ceas SLA), comentarii, fișiere atașate sau șterse, e-mailuri trimise, depășiri de SLA — cu autor și oră.
  • Atașamentele au amprentă SHA-256, sursă (intern, portal, e-mail) și pot fi marcate „doar pentru IT”. Interfața limitează fișierele la 25 MB.

Cerințe

  • MS SQL Server 2022 cu ODBC Driver 18, Redis 7, Python 3.12;
  • core_service pornit (autentificare JWT);
  • pentru e-mail: o căsuță dedicată, accesibilă prin IMAP și SMTP.

Limitări și ce e încă în plan

  • Șabloanele de sarcini au rute de creare, modificare și ștergere, dar interfața nu are încă un editor de șabloane.
  • Regulile SLA pe priorități se pot citi prin API (GET /api/tasks/sla-rules); contractul nu are rută pentru modificarea lor.
  • Responsabilul unei categorii se setează prin API; pagina „Rutare pe categorii” îl afișează, dar schimbă din interfață doar coada implicită.
  • Butonul „Eveniment nou” din Calendar nu este încă legat la crearea de evenimente; ruta de API există.
  • Lista „Toate” încarcă ultimele 200 de sarcini, fără paginare.