Clasificación de criticidad de los sistemas de información

"¡Alfa-bank es tan confiable como un tanque

y Gamma-bank es tan confiable como un banco!"



Victor Pelevin, "Números"

Cuando la frase "sistema bancario" aparece en las conversaciones, la imaginación dibuja un sistema súper confiable construido con los equipos más costosos, agrupado en todos los niveles posibles y aislado del mundo exterior por medios de protección accesibles e inaccesibles. De hecho, existen tales sistemas. Pero ...







si nos fijamos en las vacantes de desarrolladores en el banco, entonces es muy posible ver entre los requisitos de conocimiento de Cassandra, MongoDB y otras plataformas, que de ninguna manera inspiran pensamientos sobre la disponibilidad del 100%. Y DBMS como Oracle o Microsoft SQL Server se instalan en algún lugar de un grupo de servidores costosos conectados a las matrices más confiables y de alto rendimiento, y en algún lugar de una máquina virtual normal en una granja desde el mismo producto básico.



Las razones son obvias: las soluciones redundantes son caras. Pero, ¿cómo encontrar un compromiso entre el costo de la plataforma y su confiabilidad?



Érase una vez, cuando había pocos sistemas de información en la empresa, la infraestructura de cada sistema era una obra de arte. Con el tiempo, hubo más sistemas, se volvió costoso admitir varios cientos de configuraciones diferentes de hardware y software, y los departamentos de infraestructura llegaron a la estandarización. Por ejemplo, un conjunto de soluciones de infraestructura RDBMS que las aplicaciones pueden usar podría tener este aspecto:

• servidores de clase alta con matrices de discos de clase alta más replicación síncrona;
• servidores de gama media con matrices de discos de gama media más replicación sincrónica;
• servidores de clase media con matrices de discos de gama media más replicación asincrónica;
• servidores básicos con matrices de discos de gama media sin replicación.

Ahora bien, ¿cómo se elige una configuración para una base de datos específica que pertenece a una aplicación específica?



Puede hacer una lista de "las aplicaciones más importantes que deben funcionar a toda costa". Esto plantea dos problemas:



La configuración del hardware para las aplicaciones restantes depende del "peso" del propietario del sistema. Como resultado, algunos servicios de licencia electrónica por enfermedad funcionan en los equipos más costosos, porque esta es la creación favorita del jefe de contabilidad, con quien nadie quiere pelear. Esto es una pérdida de dinero irrazonable.



Es posible que algunas aplicaciones no estén incluidas en la lista "más importante" porque no se han pensado en ellas. Por ejemplo, todo el mundo recuerda sobre el procesamiento de tarjetas bancarias, pero nadie recuerda la comprobación de clientes en "listas negras", que deberían funcionar con cada operación. Como resultado, la falla de dicho sistema se convierte en una sorpresa desagradable y conduce a serios problemas.



Existe una metodología formal que le permite tomar la decisión correcta y proteger lo que necesita protección sin pagar de más por lo que no puede pagar de más.



Para empezar, se introduce una clasificación de aplicaciones según el nivel de criticidad. Por regla general, hay cuatro de estos niveles. Se pueden llamar, por ejemplo, así:

• Platino;
• Oro;
• Plata;
• Bronce.

O así:

• Misión crítica;
• Crítico para el negocio;
• Negocio operativo;
• Productividad de oficina.

Estos cuatro niveles encajan perfectamente en 4 configuraciones de infraestructura diferentes. Lo único que queda por hacer es clasificar cada aplicación según sea necesario.



Al evaluar, es importante observar dos reglas:



el sistema lo evalúa la empresa, no el departamento de TI que lo atiende. La criticidad no debe estar determinada por el tiempo o el trabajo intensivo que deba mantener el sistema. El único criterio son las pérdidas en las que incurrirá la empresa por el tiempo de inactividad del sistema.



La redacción de las preguntas que forman la evaluación debe permitir la posibilidad de verificar las respuestas. Por supuesto, los criterios todavía se basan en el juicio de expertos, pero el experto, al menos, puede explicar por qué dio tal evaluación.



¿Qué determina el nivel de criticidad?

• . , , , .
• SLA (service level agreement). , – , .
• . , , .

En la práctica mundial, se ha desarrollado algo como esto:







Esto no significa que en su empresa la distribución de sistemas por clases deba ser exactamente la misma. Pero en cualquier caso, si más del 15% de los sistemas operativos entraron en la clase de misión crítica, esta es una razón para pensar seriamente.



A la pregunta "cuánto se necesita este o aquel sistema", cualquier propietario responderá "muy". Por lo tanto, se debe hacer otra pregunta: ¿qué sucede si el sistema se detiene? La clase de criticidad del sistema depende de la severidad de las consecuencias del apagado del sistema y la velocidad de su ocurrencia.



Echemos un vistazo a varios sistemas bancarios.



El sistema de liquidación proporciona (¡sorpresa!) Liquidaciones entre clientes - entidades legales. Si de repente un gran cliente corporativo no puede realizar un pago a una contraparte, el banco perderá una cantidad muy significativa, por lo que el sistema de liquidación, sin duda, entrará en la clase más alta de criticidad.



Tomemos el procesamiento de tarjetas. Si cien o dos clientes no pueden pagar con una tarjeta, las pérdidas del banco serán pequeñas, pero una denegación de servicio tan masiva es inaceptable en sí misma.



Ahora tomemos un sistema que mantiene los depósitos. Si este sistema se detiene, las pérdidas del banco volverán a ser pequeñas y la denegación de servicio no será tan masiva como en el caso del procesamiento. Pero, ¿necesitamos un editorial de periódico con el titular "El banco se niega a emitir depósitos"? La pregunta es retórica.



Finalmente, tomemos el libro mayor. Si de repente le sucede algo, los clientes no notarán nada, ya que este sistema no participa en absoluto en el servicio al cliente. Pero vale la pena retrasar la entrega del balance, ya que las sanciones del Banco Central no tardarán en llegar.



Entonces, las consecuencias negativas del tiempo de inactividad del sistema se pueden dividir en 4 clases:

• Económico (pérdidas directas);
• Cliente (denegación de servicio);
• Reputacional (reacciones negativas en los medios);
• Legal (desde advertencias y multas hasta juicios y revocación de licencias).

Para cada clase de consecuencias, se deben formular criterios de gravedad y asignarles puntuaciones de 0 a 4. Por ejemplo, una tabla podría verse así:





Por supuesto, todos los números son arbitrarios, todos los métodos de cálculo se basan únicamente en el juicio de expertos, y el margen de debate sobre qué considerar como "medios regionales" y cómo tratar los artículos negativos en blogs populares es realmente ilimitado. Pero en una gran corporación seguramente habrá tanto un departamento legal como un servicio de relaciones públicas que expresarán rápidamente una opinión competente.



El siguiente paso es elegir los intervalos de tiempo en los que estimaremos las pérdidas. Por ejemplo, hora, 4 horas, 8 horas, 24 horas. Estos intervalos son arbitrarios y no tienen nada que ver con los SLA de los sistemas que se evalúan. Aunque en el futuro sería correcto vincular SLA estándar a estos intervalos.



Ahora, el propietario de cada sistema completa una matriz de 16 celdas. Los números de la tabla siguiente se dan como ejemplos. Lo único que es fundamentalmente importante es que la estimación de las consecuencias para un intervalo más largo no puede ser menor que la estimación para un intervalo más corto.





Quedan tres pasos para obtener la puntuación final de esta matriz.

Paso uno: para cada intervalo de tiempo, seleccione la estimación máxima:





Paso dos: traducimos las estimaciones obtenidas a las clases de criticidad utilizando la matriz:





Para este sistema, obtenemos las siguientes estimaciones:





Y, finalmente, de todas las estimaciones obtenidas, elegimos la máxima; en este caso, el sistema que se evalúa debe clasificarse como crítico para el negocio.



Habiendo recibido estas estimaciones, podemos elegir razonablemente una u otra solución de infraestructura para cada sistema.



Quedan varios matices, sin los cuales la metodología descrita estaría incompleta.



Si el sistema asegura la operatividad de otro sistema, entonces su clase de criticidad no puede ser menor que la clase del sistema dependiente. Por ejemplo, Active Directory no tiene nada que ver con los negocios. Pero si de repente aumenta, las consecuencias para muchas aplicaciones comerciales serán las más graves y, por lo tanto, AD definitivamente pertenece a la clase de misión crítica.



Las pérdidas incurridas como resultado del tiempo de inactividad del sistema no pueden ser menores que las pérdidas incurridas al interrumpir el proceso comercial que proporciona este sistema. A la luz de esta regla, es muy interesante evaluar el sistema de correo electrónico corporativo, porque de repente resulta que el intercambio de información crítica está ligado a él.



Si una empresa usa varios bloques en el mismo sistema y las estimaciones de estos bloques para el sistema difieren, entonces se debe usar la estimación máxima. Además, incluso los criterios de evaluación pueden ser diferentes. Entonces, por ejemplo, la evaluación de la imposibilidad de atender a un cliente puede diferir mucho según el tipo de cliente que sea: un "físico" común, un VIP o un gran cliente corporativo.



Etiquete sus sistemas, y que su infraestructura sea tan confiable como debe ser, ¡pero no más costosa de lo que puede ser!