Ola a todos, chámome Igor Tyukachev e son consultor de continuidade empresarial. No post de hoxe teremos un longo e tedioso debate sobre verdades comúns, quero compartir a miña experiencia e falar dos principais erros que cometen as empresas á hora de elaborar un plan de continuidade do negocio.
1. RTO e RPO ao chou
O erro máis importante que vin é que o tempo de recuperación (RTO) é eliminado da nada. Ben, da nada - por exemplo, hai algúns números de hai dous anos do SLA que alguén trouxo do seu lugar de traballo anterior. Por que fan isto? Despois de todo, segundo todos os métodos, primeiro debes analizar as consecuencias dos procesos comerciais e, en función desta análise, calcular o tempo de recuperación obxectivo e a perda de datos aceptable. Pero facer unha análise deste tipo ás veces leva moito tempo, ás veces é caro, ás veces non está moi claro como, fai fincapé no que hai que facer. E o primeiro que se lles ocorre a moitos é: “Todos somos adultos e entendemos como funcionan os negocios. Non perdamos tempo e cartos! Tomemos máis ou menos como debe ser. Fóra da túa cabeza, usando o enxeño proletario! Que o RTO sexa dúas horas".
A que leva isto? Cando se chega á xestión por diñeiro para actividades para garantir o RTO/RPO requirido con certos números, sempre esixe xustificación. Se non hai xustificación, xorde a pregunta: de onde o sacaches? E non hai nada que responder. Como resultado, pérdese a confianza no teu traballo.
Ademais, ás veces esas dúas horas de recuperación custaban un millón de dólares. E xustificar a duración da RTO é unha cuestión de diñeiro, e moito máis.
E, finalmente, cando lle traes o teu plan BCP e/ou DR aos intérpretes (que en realidade estarán correndo e axitando os brazos no momento do accidente), farán unha pregunta semellante: de onde veñen estas dúas horas? E se non podes explicar isto claramente, non terán confianza nin en ti nin no teu documento.
Resulta ser un anaco de papel por un anaco de papel, unha baixa. Por certo, algúns fan isto deliberadamente, simplemente para satisfacer os requisitos do regulador.
Ben, entendes
2. A cura para todo
Algunhas persoas cren que se desenvolve un plan BCP para protexer todos os procesos comerciais de calquera ameaza. Recentemente, a pregunta "De que queremos protexernos?" Escoitei a resposta: "Todo e máis".
Pero o feito é que o plan só pretende protexer específico procesos de negocio clave da empresa desde específico ameazas. Por iso, antes de elaborar un plan, é necesario avaliar a aparición de riscos e analizar as súas consecuencias para o negocio. É necesaria unha avaliación de riscos para comprender que ameazas ten medo a empresa. En caso de destrución de edificios haberá un plan de continuidade, en caso de presión sancionadora -outro, en caso de inundación- un terceiro. Mesmo dous sitios idénticos en diferentes cidades poden ter plans significativamente diferentes.
É imposible protexer unha empresa enteira cun só BCP, especialmente un grande. Por exemplo, o enorme X5 Retail Group comezou a garantir a continuidade con dous procesos comerciais clave (escribimos sobre isto ). E simplemente non é realista encerrar a toda a empresa cun único plan; este é da categoría de "responsabilidade colectiva", cando todos son responsables e ninguén é responsable.
A norma ISO 22301 contén o concepto de política, co que, de feito, comeza o proceso de continuidade na empresa. Describe o que protexeremos e de que. Se a xente vén correndo e pide engadir isto e aquilo, por exemplo:
— ¿Engadimos ao BCP o risco de que nos pirateen?
Ou
— Recentemente, durante a choiva, o noso piso superior inundouse. Engademos un escenario de que facer en caso de inundación?
A continuación, remíteos inmediatamente a esta política e digamos que protexemos os activos específicos da empresa e só de ameazas específicas e acordadas previamente, porque agora son a prioridade.
E aínda que as propostas de cambios sexan realmente apropiadas, ofrécese a telas en conta na seguinte versión da política. Porque protexer unha empresa custa moito diñeiro. Polo tanto, todos os cambios no plan BCP deben pasar pola comisión orzamentaria e a planificación. Recomendamos revisar a política de continuidade do negocio da empresa unha vez ao ano ou inmediatamente despois de cambios significativos na estrutura da empresa ou nas condicións externas (que os lectores me perdoen por dicilo).
3. Fantasías e realidade
A miúdo ocorre que ao elaborar un plan BCP, os autores describen algunha imaxe ideal do mundo. Por exemplo, "non temos un segundo centro de datos, pero escribiremos un plan como se o fixeramos". Ou o negocio aínda non ten algunha parte da infraestrutura, pero os empregados aínda a engadirán ao plan coa esperanza de que apareza no futuro. E entón a empresa estenderá a realidade ao plan: construír un segundo centro de datos, describir outros cambios.
Á esquerda está a infraestrutura correspondente a BCP, á dereita a infraestrutura real
Todo isto é un erro. Escribir un plan BCP significa gastar diñeiro. Se escribes un plan que non funciona agora mesmo, estarás pagando un papel moi caro. É imposible recuperarse del, é imposible probalo. Resulta que é traballo polo traballo.
Podes escribir un plan con bastante rapidez, pero construír unha infraestrutura de copia de seguridade e gastar diñeiro en todas as solucións de protección é longo e caro. Isto pode levar máis dun ano. E pode resultar que xa tes un plan, e a infraestrutura para el aparecerá en dous anos. Por que é necesario un plan así? De que te protexerá?
Tamén é unha fantasía cando o equipo de desenvolvemento do BCP comeza a descubrir para os expertos o que deben facer e en que tempo. Procede da categoría: “Cando ves un oso na taiga, cómpre virar en sentido contrario ao oso e correr a unha velocidade que supera a velocidade do oso. Durante os meses de inverno, tes que cubrir as túas pistas".
4. Cumes e raíces
O cuarto erro máis importante é facer que o plan sexa demasiado superficial ou demasiado detallado. Necesitamos un medio de ouro. O plan non debe ser demasiado detallado para idiotas, pero non debe ser demasiado xeral para que algo así acabe:
O fácil en xeral
5. Ao César - o que é do César, ao mecánico - o que é do mecánico.
O seguinte erro deriva do anterior: un plan non pode acomodar todas as accións para todos os niveis de xestión. Os plans BCP adoitan desenvolverse para grandes empresas con grandes fluxos financeiros (por certo, segundo o noso , de media, o 48% das grandes empresas rusas atopáronse con situacións de emerxencia que supuxeron importantes perdas financeiras) e un sistema de xestión multinivel. Para tales empresas, non paga a pena tentar encaixar todo nun só documento. Se a empresa é grande e estruturada, entón o plan debería ter tres niveis separados:
- nivel estratéxico - para alta dirección;
- nivel táctico - para xestores intermedios;
- e o nivel operativo - para os implicados directamente no campo.
Por exemplo, se estamos a falar de restaurar unha infraestrutura fallida, entón a nivel estratéxico tómase a decisión de activar o plan de recuperación, a nivel táctico pódense describir os procedementos do proceso e a nivel operativo hai instrucións para a posta en marcha específicas. pezas de equipamento.
BCP sen orzamento
Todo o mundo ve a súa área de responsabilidade e as conexións con outros empregados. No momento dun accidente, cada un abre un plan, atopa rapidamente a súa parte e ségueo. O ideal é lembrar de memoria que páxinas abrir, porque ás veces os minutos contan.
6. Xogo de roles
Outro erro ao elaborar un plan BCP: non é necesario incluír nomes específicos, enderezos de correo electrónico e outra información de contacto no plan. No propio texto do documento só se deben indicar os roles impersoais, debendo asignarse a estes os nomes dos responsables de tarefas concretas e os seus contactos figuran no anexo do plan.
Por que?
Hoxe, a maioría da xente cambia de traballo cada dous ou tres anos. E se anotas todos os responsables e os seus contactos no texto do plan, terá que cambiarse constantemente. E nas grandes empresas, e especialmente nas gobernamentais, cada cambio a calquera documento require unha tonelada de aprobacións.
Sen esquecer que se se produce unha emerxencia e tes que follar frenéticamente o plan e buscar o contacto axeitado, perderás un tempo precioso.
Truco de vida: cando cambias unha aplicación, moitas veces nin sequera necesitas aprobala. Outro consello: pode utilizar sistemas de automatización de actualización do plan.
7. Falta de versionado
Normalmente crean un plan versión 1.0, e despois fan todos os cambios sen o modo de edición e sen cambiar o nome do ficheiro. Ao mesmo tempo, moitas veces non está claro o que cambiou en comparación coa versión anterior. A falta de versións, o plan vive a súa propia vida, que non se fai un seguimento de ningún xeito. A segunda páxina de calquera plan BCP debe indicar a versión, o autor dos cambios e unha lista dos propios cambios.
Xa ninguén o pode entender
8. A quen lle debo preguntar?
Moitas veces, as empresas non teñen unha persoa responsable do plan BCP e non hai un departamento separado que se encargue da continuidade do negocio. Esta honrosa responsabilidade atribúeselle ao CIO, ao seu adxunto, ou segundo o principio "ti ocupas da seguridade da información, así que aquí está BCP ademais". Como resultado, o plan desenvólvese, acórdase e apróbase, de arriba abaixo.
Quen é o responsable de almacenar o plan, actualizar e revisar a información nel? Isto pode non ser prescrito. Contratar a un empregado separado para iso é un despilfarro, pero cargar a un dos existentes con tarefas adicionais é posible, por suposto, porque agora todos se esforzan pola eficiencia: "Colgámoslle unha lanterna para que poida segar pola noite", pero é necesario?
Buscamos responsables de BCP dous anos despois da súa creación
Polo tanto, adoita suceder así: elaborouse un plan que se meteu nunha caixa longa para cubrirse de po. Ninguén a proba nin mantén a súa relevancia. A frase máis común que escoito cando chego a un cliente é: "Hai un plan, pero foi desenvolvido hai moito tempo, descoñécese se foi probado, hai a sospeita de que non funciona".
9. Demasiada auga
Existen plans nos que a introdución ten cinco páxinas, incluíndo unha descrición dos requisitos previos e agradecementos a todos os participantes no proxecto, con información sobre o que fai a empresa. Cando desprácese ata a décima páxina, onde hai información útil, o seu centro de datos xa está inundado.
Cando intentas ler ata o momento, que debes facer se o teu centro de datos está inundado?
Coloque toda a "auga" corporativa nun documento separado. O plan en si debe ser extremadamente específico: o responsable desta tarefa fai isto, etc.
10. A custa custa é o banquete?
Moitas veces, os creadores do plan non teñen apoio da alta dirección da empresa. Pero hai apoio de mandos intermedios que non xestionan ou non teñen o orzamento e os recursos necesarios para xestionar a continuidade do negocio. Por exemplo, o departamento de TI crea o seu plan BCP dentro do seu orzamento, pero o CIO non ve toda a imaxe da empresa. O meu exemplo favorito é a videoconferencia. Cando a videoconferencia do CEO non funcione, a quen eviscerará? O CIO que "non proporcionou". Polo tanto, dende o punto de vista do CIO, que é o máis importante na empresa? Polo que a xente sempre o "ama": a videoconferencia, que se converte inmediatamente nun sistema crítico para a empresa. E desde o punto de vista empresarial: ben, non VKS, só pensa, falaremos por teléfono, como baixo Brezhnev...
Ademais, o departamento informático adoita pensar que a súa principal tarefa en caso de desastre é restaurar o funcionamento dos sistemas informáticos corporativos. Pero ás veces non necesitas facelo! Se hai un proceso comercial en forma de impresión de anacos de papel nunha impresora moi cara, non debes mercar unha segunda impresora deste tipo como recambio e colocala xunto a ela en caso de avaría. Pode ser suficiente para colorear temporalmente os anacos de papel a man.
Se estamos construíndo protección continua dentro das TI, debemos contar co apoio da alta dirección e representantes empresariais. Se non, tendo pupado dentro do departamento de TI, podes resolver unha serie de problemas, pero non todos os necesarios.
Así se ve a situación cando só o departamento de TI ten plans de DR
10. Sen probas
Se hai un plan, hai que probalo. Para aqueles que non están familiarizados coas normas, isto non é nada obvio. Por exemplo, tes sinais de "saída de emerxencia" colgados por todas partes. Pero dime, onde está o teu cubo, gancho e pa? Onde está a boca de incendios? Onde debe situarse o extintor? Pero todo o mundo debería saber isto. Non nos parece nada lóxico atopar un extintor ao entrar nunha oficina.
Quizais a necesidade de probar o plan debería mencionarse no propio plan, pero esta é unha decisión controvertida. En calquera caso, un plan pode considerarse que funciona só se foi probado polo menos unha vez. Como dixen anteriormente, escoito moi a miúdo: “Hai un plan, toda a infraestrutura está preparada, pero non é un feito que todo saia como está escrito no plan. Porque non o probaron. Nunca".
En conclusión
Algunhas empresas poden analizar o seu historial para comprender que tipo de problemas son susceptibles de ocorrer e que probabilidade son. A investigación e a experiencia suxiren que non podemos protexernos de todo. A merda, tarde ou cedo, pásalle a calquera empresa. Outra cousa é como estarás preparado para esta ou unha situación similar e se poderás restaurar o teu negocio a tempo.
Hai quen pensa que a continuidade é como eliminar todo tipo de riscos para que non se materialicen. Non, a cuestión é que os riscos se materializarán, e estaremos preparados para iso. Os soldados están adestrados para non pensar na batalla, senón para actuar. O mesmo pasa cun plan BCP: permitirache restaurar o teu negocio o máis rápido posible.
O único equipo que non precisa BCP
Igor Tyukachev,
Consultor de Continuidade de Negocio
Centro de Deseño de Sistemas Informáticos
"Jet Infosystems"
Fonte: www.habr.com