Puncte:0

Ce instrumente folosiți pentru a vă măsura MTTR-ul ca echipă de operațiuni?

drapel cn

si il masori deloc?

Problema mea este că atunci când o întrerupere este alertată, se simte o pierdere de timp pentru a crea mai întâi un bilet JIRA, așa că încep să o rezolv imediat. În plus, unele întreruperi sunt rezolvate mai întâi prin soluții alternative și apoi revizuite pentru a le rezolva corect.

Puncte:1
drapel us
Rob

„Problema mea este că atunci când o întrerupere este alertată, se simte o pierdere de timp pentru a crea mai întâi un bilet JIRA”

Acest lucru este desigur ușor de rezolvat, majoritatea sistemelor de alertă pot genera mai multe alerte în același timp și una dintre acele alerte poate fi crearea automată a unui bilet Jira.

O parte a închiderii biletului Jira poate fi apoi sarcina administrativă de înregistrare (în orice mod/sistem este potrivit pentru dvs.) ceea ce ați convenit ca timp de reparație.

(Deja subînțeles, dar permiteți-mi să spun asta în mod explicit: timpul de rezoluție a biletelor urmărit de sistemul dvs. de ticketing nu este același cu timpul de reparare.)

Când timpii de rezoluție a biletelor sunt importanți și o măsurătoare de performanță în sine, este posibil să doriți să închideți biletul generat automat pentru întrerupere imediat după ce întreruperea a fost rezolvată.
Când începeți o investigație de analiză a cauzei rădăcină (RCA), utilizați un bilet de investigare a problemei înrudit, dar nou, #XYZ (care are criterii de performanță diferite și este raportat diferit de biletele privind întreruperile).

În funcție de rezultatele RCA, puteți începe să lucrați la o remediere permanentă / măsuri de atenuare pe care le urmăriți într-un mod diferit din nou, în funcție de ceea ce trebuie făcut.

drapel cn
Teoretic, aș putea crea bilete JIRA, dar primesc destul de multe rezultate false pozitive, așa că ar trebui să merg la JIRA tot timpul și să le marchez ca WontFix. De asemenea, chiar folosiți JIRA pentru raportul dvs. MTTR? Sunt de acord că aș putea face acest lucru teoretic, dar nu sunt sigur cât de bine ar funcționa în practică.
drapel us
Rob
Falsele pozitive din alertele dvs. sunt o problemă separată, dar generăm incidente pentru fiecare alertă (într-un sistem de ticketing altul decât Jira). Timpul de reparare înseamnă lucruri diferite pentru diferiți oameni și companii, rezolvarea întreruperii se face adesea printr-o repornire, reluare la un sistem din spate etc. Pentru unii aceasta este reparația, dar pentru alții reparația efectivă include efectuarea RCA, urmărirea elimină eroarea, reparând-o în cod, întregul ciclu QA până când în cele din urmă o versiune este implementată în producție.
drapel us
Rob
Raportăm automat timpii de rezolvare a biletelor și, de asemenea, disponibilitatea și durata întreruperilor, dar nu și pe MTTR. Multe lucruri sunt soluții ușoare, dar altele pur și simplu durează mult timp (și au puțină prioritate)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.