Uno de los temas más prevalentes durante el último año ha sido la resiliencia. A medida que una pandemia mundial desestabilizaba las suposiciones subyacentes sobre las que se basaban muchas empresas, subrayaba la importancia de ser resilientes frente a desastres y cambios drásticos. Esta lógica también debería aplicarse a las infraestructuras de TI.
Las organizaciones deben aceptar que los desastres de infraestructura no son solo una posibilidad, son inevitables (ya sea una interrupción, una brecha, un incendio, una tormenta, una inundación o, al menos en un caso, ratones). Sin embargo, un desastre en un centro de datos no tiene por qué dañar la experiencia de los clientes. Para ganar en 2021 y más allá, las empresas deben dejar de lado la noción de recuperación ante desastres y, en cambio, crear y planificar una verdadera resiliencia de TI.
Miremos hacia atrás al 25 de noviembre de 2020. En el fin de semana de compras en línea más grande del año, AWS experimentó una interrupción importante. Se cayeron miles de servicios en Internet. Las aplicaciones y servicios como Roku y Adobe se desconectaron. Los sistemas de seguridad para el hogar dejaron de funcionar. Detrás de escena, los equipos de TI de AWS y las empresas afectadas se apresuraron a restaurar las operaciones con cada momento adicional fuera de línea que degradaba la lealtad de los clientes que tanto les costó ganar. Los equipos de TI no pueden permitirse el lujo de ser tomados por sorpresa por interrupciones como esta.
Sin embargo, a pesar del amplio alcance de la interrupción, no todos los clientes de AWS se vieron afectados. ¿Por qué?
¿Cómo sobrevivieron empresas como Netflix y Apple?
En lugar de centrarse en la recuperación ante desastres, las organizaciones de TI con visión de futuro trabajaron al revés, desde la experiencia del cliente. Durante la interrupción, los principales clientes de AWS, Apple y Netflix, continuaron con sus servicios sin interrupciones. Practicaron la resiliencia de TI y se aseguraron de que sus clientes no experimentaran tiempo de inactividad debido al caos en sus centros de datos.
A medida que se lleva a cabo más actividad económica digitalmente y las expectativas de los clientes sobre las experiencias de los usuarios continúan aumentando, el costo del tiempo de inactividad continúa aumentando. Para prosperar en este nuevo entorno, las empresas deben dejar atrás la “recuperación ante desastres” y adoptar una postura de resiliencia de TI. A continuación se muestran tres formas de cambiar el paradigma, con un enfoque en la columna vertebral de la mayoría de las pilas de TI empresariales: la base de datos relacional.
Los desastres no pueden ser excepciones, por lo que deben convertirse en no eventos.
Para 2022, el 75 por ciento de las bases de datos relacionales migrarán a un entorno de nube, según Gartner. Esta migración es, en parte, impulsada por el deseo de confiar en los expertos cuando se trata de ejecutar la infraestructura. Pero incluso en las nubes dirigidas por expertos, los desastres siguen ocurriendo. Además de AWS, durante los últimos ocho meses IBM, Facebook y Google, por nombrar algunos, han experimentado interrupciones que dieron como resultado un tiempo de inactividad de cara al cliente. Necesitamos esperar fracasos como regla, no como excepción. El hardware fallará aleatoriamente, pero la experiencia de sus clientes debe permanecer constante.
Los planes de recuperación ante desastres (los runbooks que acumulan polvo virtual por falta de uso) están desactualizados. Es hora de evolucionar hacia la resiliencia en lugar de la recuperación. Un patrón emergente popular para hacer esto son las bases de datos de escalamiento horizontal de múltiples regiones en lugar de las bases de datos de escalamiento vertical. Esto le permite distribuir el riesgo (y la potencia informática) entre varias máquinas, mientras que todo el clúster se comporta como una única base de datos lógica. Si una máquina, centro de datos o región falla, ahora puede preservar la experiencia del cliente.
Se deben eliminar el tiempo de inactividad planificado y el "mantenimiento programado".
El tiempo de inactividad relacionado con el caos puede resultar en largas noches para los equipos de TI, pero ¿cómo pensamos sobre el tiempo de inactividad programado para el mantenimiento de rutina de los sistemas? Desde el punto de vista de los usuarios finales, esto también puede ser desastroso si un servicio de misión crítica no está disponible cuando un usuario más lo necesita.
Las fuentes del tiempo de inactividad planificado incluyen la ampliación de las bases de datos relacionales monolíticas, el cambio de la estructura de esas bases de datos para admitir nuevas funciones, actualizaciones de bases de datos y actualizaciones de seguridad del sistema operativo.
Necesitamos eliminar el "tiempo de inactividad planificado" de nuestro vocabulario.
Con una base de clientes global, no hay un buen momento para desconectar su aplicación; será perjudicial para alguien en algún lugar. En cambio, las empresas deben ser proactivas mediante la creación de arquitecturas que permitan el mantenimiento en línea, en producción. Los sistemas modernos deben admitir actualizaciones continuas sin tiempo de inactividad para trabajos de mantenimiento y deben permitir algunas actualizaciones de aplicaciones sobre la marcha sin afectar a los usuarios finales.
Deje de informar sobre RPO y RTO. Solo cuentan la mitad de la historia.
Este cambio de paradigma de recuperación de desastres hacia la resiliencia de TI requerirá que las organizaciones y los profesionales de TI reconsideren las métricas que lo acompañan para la supervivencia. Dos métricas comunes en el espacio de recuperación ante desastres son el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO): cuántos datos se perderán en una interrupción o falla y cuánto tiempo se tarda en recuperarse. Estas métricas son un buen punto de partida, pero solo cuentan la mitad de la historia. Se quedan cortos cuando se trata de comparar arquitecturas que permiten la resiliencia de TI.
El componente que falta es que, dependiendo de la arquitectura, las probabilidades de que un RPO / RTO desencadene un desastre pueden ser muy diferentes. Los equipos de TI deben comprender las posibilidades de que ocurra un evento de RPO / RTO, el costo de cada segundo de tiempo de inactividad y pérdida de datos, y lo que eso significa para el costo esperado de desastres a largo plazo. Si las empresas optimizan el costo esperado del tiempo de inactividad en lugar de simplemente RPO / RTO, encontrarán que las arquitecturas modernas pueden brindarles resultados dramáticamente mejores al reducir la posibilidad de una interrupción, incluso con características de RPO / RTO aparentemente similares.
El camino a seguir
Ha llegado el momento de que las empresas reconsideren sus arquitecturas para trabajar al revés desde su experiencia de cliente ideal. El hardware fallará, se realizarán actualizaciones de software. La clave está en limitar, o incluso eliminar, el impacto en el cliente. Eso es lo que significa priorizar la resiliencia de TI.