Com hem comentat en un post anterior la part més important sobre la seguretat i control de riscos per a una empresa és la recuperació de l’operativitat en un temps determinat, en cas d’incidència greu.
Quan parlem de pla de recuperació de desastres, podem pensar en un gran projecte, amb una inversió de molts diners, etc. Però no es l’objectiu d’aquest post, En aquest post explicarem quins són els punts bàsics d’aquest procediment i com s’ha d’implementar, per tal de tenir un pla de recuperació mínim i que no representi un elevat cost per a l'empresa, però que ens proporcioni seguretat.
El primer que cal tenir en compte és l’abast d’aquest pla. Cal ser conscient que no estem fent un sistema que no caurà mai, el nostre objectiu és tenir un sistema que en un temps determinat pugui tornar a ser operatiu per a l'empresa. Per tant el que intentarem és tenir el mínim indispensable per poder tornar a facturar, no perdre reputació o el que es determini que és primordial per al funcionament de l’empresa.
Tampoc contemplem grans desastres naturals, terratrèmols, tsunamis, impactes d’avions, etc. En una startup, i fins i tot en la majoria de les petites empreses, en cas que passes això el que menys preocuparia segurament seria l’operativitat de l’empresa.
Només contemplarem dos escenaris, problemes amb un o diversos servidors de la plataforma i problemes amb el proveïdor de serveis de la infraestructura.
Comencem doncs amb la definició del pla:
Definició del pla de recuperació
El primer que cal deixar clar per gestionar les expectatives són les limitacions d’aquest pla. És a dir quin és el seu abast:
- Quins serveis i riscos cobreix.
- Quina ha de ser la capacitat mínima de la infraestructura d’emergència.
- Quin és el temps previst de recuperació dels serveis bàsics.
- Quin és el temps previst de la totalitat de la funcionalitat.
- Quina quantitat de dades es perdran en el pitjor del casos.
Aquesta informació és important doncs les respostes a aquestes preguntes determinaran el cost d’implementació d’aquest pla. Aquestes limitacions hauran de ser acordades per la direcció de l'empresa, doncs és una decisió de negoci i no tecnològica.
Un cop tenim definits els límits del pla, passem descriure els components del pla.
Llistat dels sistemes de component la plataforma i el seu nivell de criticitat.
Necessitarem un llistat de tots els sistemes que component la plataforma. Això és, una llista de totes les eines ( i teconologies ) que s’estan fent servir per al funcionament complet de l’empresa, amb els sistemes implicats per tal que aquests funcionin correctament. També necessitarem que s’assigni un nivell de criticitat pel negoci de cadascuna de les funcionalitats, per part de la direcció. El nivell de criticitat assignat a cadascuna de les funcionalitats determinarà el seu ordre de recuperació.
Funcionalitat
|
Criticitat
|
Serveis implicats
|
Botiga online, e-commerce
|
1
|
Web
Base de dades
Servidors
...
|
Enviament comandes
|
2
|
Servei correu electrònic.
Servidor
|
Comptabilitat de l'empresa
|
4
|
Software comptabilitat.
Connexió Internet.
|
...
|
...
|
...
|
Aquest llistat ens ha d’indicar l’ordre de recuperació dels sistemes segons la seva prioritat. També ens servirà per tal d’identificar els serveis implicats en cadascuna de les funcionalitats per tal de fer els procediments de recuperació de cadascun d’aquests serveis.
Determinació de les necessitats per la recuperació
Basant-nos en la llista anterior hem de determinar:
- Quines són les necessitats mínimes d’infraestructura.
- Quina informació necessitem per fer la recuperació.
En el primer punt haurem de definir quina es la infraestructura mínima, necessària per cobrir els serveis i capacitats definits a l’abast del procediment.
Habitualment quan es parla d’infraestructura mínima en aquest escenari estem parlant de mínims extrems, és a dir és prioritza el temps de recuperació ( i en conseqüència també els costos ) per davant de tenir una capacitat elevada.
Donat que un dels escenaris que estem contemplant és que el proveïdor de la infraestructura desaparegui, caldrà preveure també on s’ubicarien els servidors de la plataforma d’emergència.
El segon punt, és un llistat de la informació necessària per a realitzar la recuperació de cadascun dels serveis, bases de dades, configuració de serveis, etc.
Cal tenir presents sempre tots els proveïdors i tecnologies que estem fent servir per al procés de recuperació. Hem de tenir clar quins serveis està oferint el proveïdor de la infraestructura en aquest aspecte, així com els diferents proveïdors de serveis que tenim. Com accedir a aquests serveis, que cobreixen, etc.
Amb tota aquesta informació recollida haurem de fer una llistat, amb cadascun dels elements necessaris per a la recuperació i la seva ubicació. Un altre cop cal destacar que aquesta informació ha d’estar disponible en un lloc que no estigui afectat pel problema que està tenint la infraestructura, per tal de poder realitzar el procés de recuperació.
Definició de l’equip de recuperació,
En el procés de recuperació no només ha d’estar involucrada la gent que executa el procediment, hi ha d’haver involucrada gent de tota l’empresa. Normalment, en una startup això ja es dona de manera natural, però és més adequat de definir qui i quines tasques tindrà cadascun durant el procés.
Caldrà realitzar comunicacions, tant cap l’interior de l’empresa com amb l’exterior i caldrà prendre decisions. Com a mínim, doncs a més a més de l’equip tècnic hi hauria d’haver algú de direcció i algú d’atenció al client.
Durant el procés de recuperació s’aniran passant per diferents fases, i es possible que sigui necessari que en algunes fases s’involucri altre personal de l'empresa. Si aquest és el cas caldrà també que formin part de l’equip de recuperació. No cal que s’incorporin en un primer moment, si no que estiguin disponibles per tal de començar a treballar en quan sigui possible. Un cas d’aquest perfil, podria ser per exemple el gestor de catàlegs, que haurà de carregar els catàlegs un cop el sistema estigui disponible.
Haurem de fer doncs la llista de persones involucrades, quina serà la seva funció en el procés, la manera de contactar amb elles i en quina fase de la recuperació seran necessàries.
Pla de comunicació.
Un cop de tenim l’equip de comunicació definit, hem de definir el pla de comunicació. Aquest ha d’indicar principalment:
- Com s’inicia el procediment.
- Què és comunicarà.
- Qui comunicarà
- A qui es comunicarà.
- Com es comunicarà.
- Quina freqüència de comunicació hi haurà?
- Quins activadors hi haurà per enviar les comunicacions?
Pla de recuperació.
Finalment arribem al pla de recuperació pròpiament dit. En aquest punt, haurem de descriure les passes necessàries per tal de poder restaurar cadascuna de les funcionalitats.
En aquest punt cal fer un petit incís, l’ideal seria que absolutament tots els processos de recuperació de totes les funcionalitats estiguessin completament definits. A la pràctica, en una startup ( i en una petita empresa ) això no és factible. No hi haurà temps de fer tota aquesta documentació, els canvis en tota la plataforma són ràpids, la documentació queda obsoleta al cap d’una setmana, etc.
Aquest nivell de documentació al detall hauria d’existir per als serveis indicats com a crítics, i mantenir aquesta documentació. El procediment ha de ser tant explícit que s’hauria de poder fer un copia&enganya del document. Això tot i que sembla una tonteria no ho és.
Imaginem la següent situació:
Són les 12 del migdia d’un dia qualsevol la botiga online treu fum, google analytics no sap no posar les xifres de visites!!!!
De cop, tot es para!! La web no funciona!! Què passa????.
Després d’una breu i ràpida investigació, es determina que la base de dades s’ha corromput, cal restaurar-la.
Iniciem el procés de recuperació, tothom a lloc?, som-hi!
- Ostres ara no recordo si la comanda de recuperació portava majúscules o no?
- Al manual de recuperació diu: Restaurar la base de dades. Però les taules de la base de dades estaven definides com a tipus A o tipus B? S’han de restaurar totes les bases de dades o només la que es diu BOTIGA?
Totes aquestes preguntes no poden aparèixer durant el procés de restauració, cal minimitzar el temps i els riscos del procediment. Es necessari doncs, tenir el procediment, com a mínim, de les funcionalitats crítiques documentats al detall. Pensem que en aquests moments estem perdent diners!!!
Revisió del pla de recuperació
Un cop tenim el pla fet, cal provar-lo. Hem d’assegurar-nos que funciona, que tot el que hem pensat, escrit i decidit realment funcionarà el dia que passi alguna cosa. En cas que les coses no siguin com hem descrit, doncs caldrà modificar el pla.
Aquest pla no serveix si no és funcional, per tant, de manera periòdica caldrà executar-lo per comprovar que continua sent vàlid i en cas que no ho sigui modificar-lo per tal que torni a ser-ho.
Links interessant sobre el tema
Llibres per aprofundir més en el tema.
 * |
IT Disaster Recovery Planning For Dummies
Peter H. Gregory,
December 2007
|
 * |
The Disaster Recovery Handbook: A Step-by-step Plan to Ensure Business Continuity and Protect Vital Operations, Facilities, and Assets
Michael Wallace, Lawrence Webber, Larry Webber
AMACOM Div American Mgmt Assn, 2011 - 440 pàgines
|
 * |
Business Continuity and Disaster Recovery Planning for IT Professionals
Susan Snedaker
Butterworth-Heinemann, 18/04/2011 - 456 pàgines
|
Comentaris
Publica un comentari a l'entrada