Wednesday, November 11, 2009

Simularea unui DRP

DRP - Disaster Recovery Plan
RTO - Recovery Time Objective (în cât timp restaurezi serviciul)
RPO - Recovery Point Objective (care este pierderea de date acceptată)

O să mă opresc pentru câteva momente asupra unui aspect pe care îl consider delicat şi care generează de multe ori discuţii aprinse. Mai jos pun o informaţie extrasă din Cobit 4.1 , mai exact din capitolul DS4 - Ensure Continous Service.

DS4.5 Testing of the IT Continuity Plan
Test the IT continuity plan on a regular basis to ensure that IT systems can be effectively recovered, shortcomings are addressed and the plan remains relevant. This requires careful preparation, documentation, reporting of test results and, according to the results, implementation of an action plan. Consider the extent of testing recovery of single applications to integrated testing scenarios to end-to-end testing and integrated vendor testing.

Subliniez câteva aspecte legate de acest test şi unele erori întâlnite de-a lungul vremii :
- testul trebuie să fie periodic. Dacă astăzi rezultatul a fost pozitiv, nu înseamnă că şi următorul o să fie la fel.
- după orice modificare majoră de arhitectură sau orice schimbare semnificativă asupra componentelor implicate într-o astfel de soluţie un nou test trebuie executat.
- rezultatul testului este pozitiv sau negativ. Am întâlnit foarte multă lume care consideră un test cu rezultat negativ un dezastru. Greşit ! Important este să inveţi din acest test, să documentezi ceea ce a mers rău şi să eviti la următorul test aceleaşi greşeli. Dacă rezultatul este negativ de mai multe ori consecutiv, planul trebuie revizuit complet.
- revizuirea rezultatelor în urma testelor, îmbunătăţirea documentaţiei şi informarea echipei sunt elemente esenţiale care vor creşte şansele de reuşită într-o situaţie reală.
- resurse (oameni) - am avut multe discuţii legate de acest topic. Îmi menţin părerea : pentru primul test (sau testul următor unui rezultat negativ), nivelul de cunoştinţe şi experienţa oamenilor trebuie sa fie mai mare decât media echipei. Acesta este momentul în care se stabilesc paşii ce trebuie urmăriţi, se scrie/corectează documentaţia. Dar, pentru testele recurente eu recomand alocarea unor persoane cu conştinţe medii şi rotirea acestor persoane. De ce ? Pentru că în momentul în care o să ai o situaţie reală ai nevoie de ajutorul echipei şi nu doar a celor mai experimentaţi.
- aveţi mare grijă ca în timpul testului să nu afectaţi mediul de producţie. Având în vedere că se incearcă o simulare cât mai reală, şansele de a afecta mediul de producţie sunt destul de ridicate.
- de cele mai multe ori testul este anunţat şi nu sunt întâmpinate probleme în a respecta RTO/RPO. O situaţie extremă puţin probabil că o să fie planificată. Încercaţi să luaţi prin surprindere echipa şi cereţi o simulare care nu este prevăzută. De obicei există o înţelegere scrisă legată de timpii de reactivitate pentru a activa o astfel de soluţie.

Spre final, un motto : "Pregătiţi-vă pentru ce e mai rău, aşteptaţi-vă la ce e mai bun !"

No comments:

Post a Comment