Perspective asupra Known Error Database (KEDB)!

Acest articol a fost publicat in categoria Tehnologii in .

Cu ajutorul catorva exemple din IT va prezentam mai multe informatii despre KEDB (Baza de date cu erori cunoscute) . Cel mai frecvent, secretul succesului este reprezentat de rezolvarea micilor probleme una cate una, astfel timpul de raspuns este mult imbunatatit. Fiecare pas trebuie facut metodic, unul dupa altul, astfel unul din instrumentele principale prin care organizatiile isi aproprie succesul este KEDB.

Ce este Known Error Database?

Pentru a intelege KEDB (Baza de date cu erori cunoscute) mai intai trebuie stiut faptul ca sunt 3 termeni ITIL ce trebiesc cunoscuti: incident, problema si eroare cunoscuta. Ce ar putea fi inteles ca incident? Daca serviciul tau de email pica fara nici o notificare prealabila atunci acest aspect poate fi reprezentat ca si incident. In acest exemplu, motivul din spatele intreruperii functionalitatii emailului este problema, deci problema este cauza care sta la baza incidentului. Cu alte cuvinte, acesta este lucrul care a cauzat situatia respectiva de la bun inceput.

De ce KEDB este necesar?

Intorcandu-ne la problema cu serviciul de email, putem spune ca serviciile sale au fost pe modul inchis dupa rularea catorva diagnostice si efectuarea anumitor teste. Dupa constatarea problemei, solutia ar fi putut fi mai rapida daca serviciul ar fi fost oprit si restartat. Serviciul de email a fost picat in timp ce diagnosticarea si solutionarea erau in curs de desfasurare, lucru ce ar putea conduce la sanctiuni aplicate de catre clienti. In cazul in care serviciul de email pica din nou, echipa tehnica va face referire la intreruperea precedenta din KEDB astfel diagnosticarea incepe cu serviciul care a cauzat problema ultima data. Oricum aceasta problema particulara a fost inregistrata de catre compania care ofera serviciile de e-mail in KEDB. In cazul in care problema se repeta, echipa de suport tehnic poate face referire la ultima intrerupere in KEDB si sa execute un diagnostic cu serviciul care a cauzat problema ultima data.

In acest moment solutionarea poate dura cateva secunde daca avem de a face cu acelasi serviciu care provoaca problema.

Solutie permanenta si solutie alternativa

Exista cateva modalitati de a repara serviciile cazute. Cea mai buna solutie, este cea permanenta, care presupune un remediu care sa garanteze zero intreruperi. Cel mai comun tip este cel prin care se cauta o solutie alternativa. Aceasta modalitate este cel mai frecvent urmata de implementarea unei solutii la o data ulterioara. Repornirea serviciului este o solutie alternativa la intreruperea serviciului de email. Dar acest lucru este probabil sa se intample si in viitor, iar echipa de suport tehnic stie ca acest lucru va rezolva doar problema pentru moment.

Acum sa vedem cateva aspecte ale KEDB in actiune.

Vazand semnificatia KEDB, acum sa intelegm cum si cand se inregistreaza, utilizeaza si intretin acele informatii.

  1. Daca un incident este rezolvat folosind mijloace temporare, o eroare cunoscuta este creata cu sumarul incidentului, descriere, simptome si toti pasii implicati in rezolvarea lor.
  2. Daca un incident apare, atunci echipa tehnica de suport acceseaza KEDB pentru a verifica daca o solutie alternativa exista in baza de date.
  3. Exista si o a treia posbilitate, unde o solutie permanenta la o eroare cunoscuta este identificata si implementata si astfel incidentul nu ar trebuie sa se mai intample niciodata.

Pentru servicii de intretinere si suport apeleaza la specialistii nostri pentru dezvoltari dedicate.


Exemple de proiecte


Spotlight

Magento / CSS3 / HTML5 / Ajax / Webservices


Mr Crispy

Magento / CSS3 / HTML5 / Ajax / Webservices