No es ningún secreto que en entornos comerciales altamente competitivos, la demanda de las organizaciones para crecer y aumentar los ingresos y las ganancias sigue aumentando. Mientras satisfacen la demanda y se mantienen actualizadas a través de la digitalización, las organizaciones deben ser conscientes de ser eficientes, mantener o reducir los costos y mantener los gastos de los empleados en línea.
Avanzar en esas dos áreas ya es bastante difícil, pero moverse en esas direcciones agrega estrés a los sistemas tecnológicos corporativos en toda la pila de tecnología, desde datos hasta aplicaciones e infraestructura de red. Las restricciones tecnológicas incluyen limitaciones de capacidad, tiempo de actividad del sistema, calidad de los datos y la capacidad de recuperarse de un evento tecnológico, físico o cibernético catastrófico.
La tecnología resistente es fundamental para mantener servicios ininterrumpidos para los clientes y atenderlos durante las horas pico. Esto requiere una infraestructura resistente con mayor visibilidad y transparencia en toda la pila de tecnología para mantener una organización en funcionamiento en caso de un ataque cibernético, corrupción de datos, falla catastrófica del sistema u otros tipos de incidentes.
La tecnología resistente debe ser ágil, escalable, flexible, recuperable e interoperable. Además, la resiliencia debe existir no solo en la arquitectura y el diseño, sino también a través de la implementación y el monitoreo continuo.
Comprender la criticidad
Para lograr la resiliencia, una organización necesita comprender la criticidad de un proceso determinado, evaluar la tecnología subyacente, reconocer el impacto comercial correspondiente y conocer la tolerancia al riesgo de la organización y las partes interesadas externas. Para llegar allí, una organización necesita comprender dónde y cuál es su resiliencia hoy y ser capaz de responder a la pregunta: ¿podríamos recuperarnos y reconstruirnos después de un evento catastrófico?
En una encuesta de McKinsey de 2022 sobre resiliencia tecnológica que evaluó el nivel de madurez de ciberseguridad de más de 50 organizaciones líderes en América del Norte, Europa y otros mercados desarrollados, el 10 por ciento de los encuestados indicó que se vieron obligados a reconstruir desde cero (por ejemplo, debido a a un evento catastrófico), con el 2 por ciento afirmando que ya han intentado recuperarse desde cero pero no tuvieron éxito (por ejemplo, pruebas deliberadas).
Además, el 20% de los encuestados indicó que ya había intentado recuperarse desde cero y tuvo éxito, el 8% intentó recuperarse desde cero, el 18% señaló que tenía planes para intentar recuperarse desde cero, mientras que el 36% afirmó que no había planes para recuperarse de metal desnudo.
La resiliencia tecnológica es la suma de prácticas y fundamentos necesarios para diseñar e implementar la tecnología de manera segura en toda la pila de tecnología. La resiliencia tecnológica prepara a las organizaciones para superar los desafíos cuando su pila de tecnología se ve comprometida, reduciendo la frecuencia de eventos catastróficos y permitiéndoles recuperarse más rápido en caso de un evento.
En la encuesta de McKinsey, cuando se preguntó cuál era el objetivo de tiempo de recuperación para sus aplicaciones más críticas, el 28% de los encuestados dijo que era inmediato, mientras que el 34% dijo que era menos de una hora, el 14% dijo menos de dos horas y el 20% dijo menos de cuatro horas. Uno de los encuestados en la encuesta declaró: «Los sistemas y aplicaciones críticos inactivos durante un período de tiempo significativo pueden costar a las instituciones financieras miles de millones de dólares».
Las capacidades de resiliencia caen en un espectro de madurez que va desde la redundancia simple a servidores duplicados hasta capacidades avanzadas con resiliencia integrada en la arquitectura por diseño.
- Arquitectura y diseño: las organizaciones maduras incorporan la resiliencia tecnológica en el diseño y la arquitectura empresarial. Los diseños resilientes incorporan elementos de las lecciones aprendidas de las operaciones, los incidentes y las tendencias de la industria para realizar inversiones en tecnología informadas sobre el riesgo.
- Implementación y operaciones: las operaciones resilientes deben considerar no solo las contingencias operativas, como la recuperación ante desastres o las demandas de rendimiento que aumentan exponencialmente, sino también la causa raíz de los incidentes que surgen durante el funcionamiento habitual para mejorar los procedimientos, la capacitación y las soluciones tecnológicas.
- Monitoreo y validación: esto consiste en métricas reactivas o retrospectivas en niveles de madurez más bajos. En niveles de madurez más altos, las organizaciones cambian a medidas más proactivas (y, en última instancia, predictivas) para hacer pruebas de estrés de las soluciones antes de implementarlas o perforar respuestas planificadas previamente y planes de contingencia para las eventualidades más probables.
- Respuesta y recuperación: las organizaciones con resiliencia de alta tecnología no solo responden a medida que ocurren los incidentes, sino que también alimentan continuamente las lecciones de sus propias operaciones, las tendencias de la industria y los eventos catastróficos en el diseño, la operación, el monitoreo y la planificación de sus empresas.
Espectro de resiliencia
En el nivel más básico, la resiliencia se deja a los propietarios y usuarios individuales del sistema. El administrador de la base de datos es responsable de las copias de seguridad de los datos de la organización y los empleados individuales deben hacer una copia de seguridad de sus propios datos. Avanzando a lo largo de la escala de madurez, las organizaciones confían en capacidades de resiliencia centralizadas administradas por TI o una función de resiliencia. Dicha organización proporciona soluciones de copia de seguridad centralizadas, mantiene sistemas centrales redundantes y supervisa las interrupciones del sistema y las fallas de las aplicaciones.
La resiliencia se puede lograr de forma pasiva mediante la realización de copias de seguridad manuales diarias. Cambiar a un enfoque activo implica monitorear los primeros indicadores de corrupción de datos o comportamiento anómalo del sistema y tomar medidas preventivas. Esos indicadores incluyen un volumen cada vez mayor de datos corruptos, una cantidad inusualmente alta de interrupciones breves de la red y una cantidad mayor de lo habitual de servidores que requieren reinicios. La resiliencia activa se produce además a través de la sincronización continua de aplicaciones, sistemas y bases de datos, de modo que siempre se mantenga la redundancia. También se realizan pruebas periódicas de conmutación por error para validar la resiliencia.
El nivel más avanzado de resiliencia consiste en la resiliencia inherente. El principal diferenciador es que la resiliencia está integrada en la pila de tecnología por diseño. La resiliencia inherente incluye capacidades como el procesamiento duplicado entre sistemas, la redundancia modular y la tolerancia automática a fallas dentro de los sistemas. La verdadera redundancia inherente permite la capacidad de realizar pruebas aleatorias de conmutación por error en producción para validar la resiliencia. Solo la tecnología que permite los procesos comerciales más críticos de una organización debe ser inherentemente resistente por diseño. La mayoría de las organizaciones se encuentran dentro del espectro de capacidad de resiliencia pasiva a activa mientras realizan un cambio continuo hacia la resiliencia activa.
Cómo volverse resiliente
Una cosa es sentar las bases y señalar los problemas detrás de la resiliencia, pero ¿cómo se llega allí? Hay tres claves para establecer y hacer crecer un entorno tecnológico más resistente:
- Cultura sin culpa: cuando surgen problemas, los equipos y los gerentes no buscan a quién culpar. Se enfocan en solucionar el problema y prevenir recurrencias. Los equipos celebran a los miembros que exponen vulnerabilidades y debilidades según sea necesario para construir una tecnología más resistente.
- Enfoque basado en métricas: los equipos miden incansablemente su propio rendimiento y se centran en los incidentes que crearon (por ejemplo, a partir de versiones o parches) o repiten incidentes que tienen la misma causa raíz.
- Ensayar la interrupción: los equipos se anticipan a los problemas y se desarrollan y capacitan iterativamente para responder a interrupciones completas del sistema. Construyen desde aplicaciones individuales a sistemas a productos (sistemas de sistemas) a servicios completos.
Cuando se les preguntó en la encuesta de McKinsey con qué frecuencia prueban las aplicaciones críticas, un poco más del 60 por ciento de los encuestados dijeron que lo hacían al menos trimestralmente. De ellos, el 14 por ciento dijo que se hacía la prueba semanalmente, el 26 por ciento la prueba mensualmente y el 26 por ciento la prueba trimestralmente. En general, el 28 por ciento dijo que se hace la prueba cada seis meses, mientras que el 6 por ciento indicó que se hace la prueba anualmente. Un encuestado dijo: “Hay pruebas trimestrales. Los sistemas más críticos se probarán cada vez, los sistemas menos críticos se distribuirán en ciclos de prueba alternos o anuales como mínimo”.
Resiliencia basada en el riesgo
Las empresas se están moviendo hacia la resiliencia tecnológica basada en el riesgo. El enfoque reconoce que no todos los activos se crean de la misma manera, ni se pueden proteger por igual en el entorno digital actual que lo abarca todo.
Algunas capacidades y activos subyacentes son más críticos para una empresa y su negocio que otros. En el caso de una gran empresa de servicios eléctricos, por ejemplo, estos incluyen los sistemas de tecnología que permiten la entrega de electricidad y gas natural a los clientes. En el caso de una institución global de servicios financieros, las plataformas comerciales y aquellas que respaldan las transacciones de los clientes son las más críticas. El modelo de negocio digital, de hecho, depende completamente de la confianza y la capacidad de proporcionar continuamente servicios orientados al cliente. Garantizar la resiliencia de esos activos está en el centro de una estrategia eficaz para protegerse contra eventos catastróficos.
Tres palancas para desarrollar la resiliencia tecnológica
Alcanzar altos niveles de madurez de resiliencia tecnológica requiere construir las capacidades y procesos necesarios, utilizando tres palancas como guía.
1.Priorizar los servicios: no todos los servicios y sistemas comerciales deben recibir el mismo trato al implementar capacidades de resiliencia tecnológica. Más bien, las organizaciones deberían definir sus servicios más críticos. Estos comprenden los servicios cruciales necesarios para cumplir con las obligaciones con los clientes, socios comerciales, reguladores y la sociedad.
Después de identificar y obtener un acuerdo entre negocios sobre estos servicios, es esencial comprender el panorama tecnológico subyacente, incluidas las aplicaciones y los sistemas que permiten los servicios comerciales más críticos, sus dependencias y cómo están interconectados.
Tener visibilidad y transparencia de los servicios más críticos y las aplicaciones, sistemas y dependencias subyacentes permite evaluar el nivel de resiliencia actual y priorizar la resiliencia objetivo aplicación por aplicación y sistema por sistema.
En el estudio de McKinsey sobre resiliencia, se preguntó a los encuestados: «¿Cuánto tiempo les tomó lograr que todas sus aplicaciones más críticas estuvieran en línea con los objetivos de tiempo de recuperación?». Aquí, el 26 por ciento de los encuestados dijo menos de un año, mientras que el 28 por ciento dijo menos de dos años y el 26 por ciento dijo menos de tres años.
Un encuestado dijo: «Ser claro sobre qué sistemas son los más críticos es un desafío continuo». Mientras que otro dijo: «Fue durante la supertormenta Sandy que el banco se preocupó mucho por su solidez, o la falta de ella, y esto se convirtió en el centro de atención inmediatamente después».
2.Evaluar el nivel actual de resiliencia y revisar crisis pasadas: el siguiente paso consiste en evaluar la resiliencia de la tecnología existente. Las organizaciones deben evaluar su madurez a lo largo de la misma curva S de resiliencia tecnológica, ya sea que tengan arquitectura y capacidades resilientes, capacidades de resiliencia pasiva, resiliencia activa con capacidades de conmutación por error, o sean inherentemente resilientes por diseño.
Por lo general, las organizaciones deben evaluar las capacidades actuales en las cuatro dimensiones del ciclo de vida de la resiliencia tecnológica. Las organizaciones más maduras incorporan resiliencia tecnológica en la arquitectura de aplicaciones y sistemas por diseño. En la implementación y las operaciones, las operaciones resilientes deben considerar no solo las contingencias operativas, sino también la causa raíz de los incidentes que surgen durante el funcionamiento habitual para mejorar los procedimientos, la capacitación y las soluciones tecnológicas. El monitoreo y la validación involucran métricas reactivas o retrospectivas en niveles de madurez más bajos. En niveles de madurez más altos, las organizaciones cambian a medidas proactivas para buscar indicadores tempranos de problemas de resiliencia y probar respuestas y planes de contingencia para las eventualidades más probables. En respuesta y recuperación, las organizaciones con alta resiliencia tecnológica no solo responden a medida que ocurren los incidentes, sino que también aprenden continuamente de sus propias operaciones, tendencias de la industria y eventos catastróficos y luego retroalimentan el diseño, la operación, el monitoreo y la planificación de la tecnología.
Las organizaciones también deben evaluar los incidentes pasados relacionados con la tecnología para identificar y descubrir los factores contribuyentes comunes que se pueden abordar para aumentar la resiliencia de la tecnología. Por lo general, esto consiste en seleccionar un amplio conjunto de incidentes recientes de diversa duración e impacto en las funciones comerciales para evaluar. También puede incluir la revisión de registros de respuesta a incidentes anteriores, informes de incidentes y otros documentos para identificar factores contribuyentes, patrones y conocimientos que pueden arrojar luz sobre las causas detrás de los incidentes. Reunirse con ingenieros, propietarios de productos o sistemas, gerentes de versiones y otras personas involucradas en el incidente y la respuesta puede revelar lo que sucedió, lo que se podría haber hecho para prevenir el incidente y las iniciativas que ya están en marcha.
Una vez completado, es posible identificar y, en última instancia, remediar los factores comunes que condujeron a estos incidentes, que pueden incluir el propio entorno tecnológico, la arquitectura de las aplicaciones, las interfaces entre sistemas y terceros, y la forma en que se incorporó la resiliencia en aplicaciones y sistemas individuales.
3.Remediar las brechas a través de un enfoque multifuncional: lograr la resiliencia tecnológica requiere remediar las brechas identificadas a partir de la evaluación de la tecnología de la organización y el diagnóstico de incidentes pasados. Además de remediar directamente las brechas identificadas, las organizaciones deben tomar los siguientes pasos específicos:
Determinar la propiedad y la responsabilidad de las actividades de resiliencia tecnológica. Los sistemas distribuidos pueden tener varios propietarios, y los desarrolladores no siempre tienen incentivos para diseñar y diseñar para la resiliencia. Las aplicaciones y los sistemas deben tener una propiedad clara, los desarrolladores necesitan incentivos con objetivos de rendimiento vinculados a la resiliencia de las aplicaciones que construyen, y los contratos de terceros deben incluir cláusulas y requisitos de resiliencia. La ausencia de una propiedad y responsabilidad clara del sistema para remediar las brechas afectará negativamente la resiliencia de los sistemas y procesos comerciales.
Mejorar la gobernanza hacia niveles de resiliencia. La supervisión de la resiliencia debe implementarse desde el nivel ejecutivo hacia abajo. El C-suite necesita comunicar su intención y priorización de la resiliencia a todos los niveles de la organización con mensajes continuos y consistentes. Los ayuntamientos, los boletines trimestrales y los seminarios web son posibles vías. Asimismo, podrán considerarse premios y otras formas de incentivos monetarios y no monetarios.
Aumentar la resiliencia de aplicaciones individuales y grupos de aplicaciones. La resiliencia de aplicaciones y sistemas individuales también debe abordarse y remediarse. Aquellos que tienen la mayor cantidad de incidentes y respaldan los procesos comerciales más críticos deben priorizarse para la remediación.
Fortalecer la configuración del alojamiento, ya sea en las instalaciones o en la nube. Las plataformas subyacentes en las que residen las aplicaciones también deben diseñarse y diseñarse para la resiliencia. Las organizaciones deben trabajar para aumentar la resiliencia de sus plataformas locales y en la nube a través de la reparación de brechas conocidas y abordando los factores contribuyentes de incidentes pasados.
Trabajar con terceros para aumentar la resiliencia de las plataformas de terceros de las que dependen los procesos y servicios comerciales críticos. Podría haber incentivos para que terceros construyan resiliencia en sus sistemas, y los contratos deben tener un lenguaje claro sobre los requisitos de desempeño para la resiliencia.
Implementar pruebas regulares, con un enfoque en las capacidades de conmutación por error automática para entornos a gran escala y ejercicios selectivos para probar la recuperación de las copias de seguridad. La resiliencia es un viaje continuo, y los sistemas deben probarse y validarse regularmente para garantizar que cumplan con los requisitos de resiliencia. Las pruebas mensuales de conmutación por error de las aplicaciones críticas para el negocio son esenciales tanto a nivel de aplicación como de plataforma. Las pruebas de conmutación por error deben diseñarse para probar no solo lo esperado sino también lo inesperado, como a través de apagados bruscos o la introducción de aumentos repentinos de capacidad que reflejen escenarios reales. Cuando la resiliencia está integrada por diseño, las aplicaciones deben apagarse aleatoriamente en producción para probar si la resiliencia inherente está realmente diseñada e integrada en la aplicación o el sistema.
En la encuesta de McKinsey, cuando se preguntó qué escenarios de conmutación por error planearon o probaron los encuestados, el 92 por ciento dijo que probaron para una falla del centro de datos único y para el impacto no físico, mientras que el 52 por ciento dijo una falla del centro de datos doble y el 83 por ciento dijo impacto físico.
Cuando se preguntó: «¿Ejecuta pruebas de conmutación por error no planificadas?» (es decir, apaga los sistemas aleatoriamente y prueba la capacidad de respuesta/recuperación de la organización), el 54 por ciento dijo que no, mientras que el 26 por ciento dijo que solo las aplicaciones más críticas y el 20 por ciento dijo que prueba para todas las aplicaciones.
El camino hacia la resiliencia tecnológica en tres pasos
Con una comprensión de las tres palancas de la resiliencia tecnológica, una organización puede embarcarse en su viaje tecnológico en tres pasos:
Diagnóstico de resiliencia tecnológica
Identificar dos o tres procesos comerciales críticos y mapear los conjuntos de datos, las aplicaciones y los sistemas tecnológicos subyacentes que habilitan los procesos. Evaluar la resiliencia de cada componente del flujo de valor. Esto conducirá a descubrir la resiliencia tecnológica de los datos, las aplicaciones y los sistemas que sustentan los procesos comerciales críticos junto con las acciones de mitigación de riesgos.
Llevar a cabo una retrospectiva de incidentes
Llevar a cabo una retrospectiva de los incidentes recientes relacionados con la tecnología para identificar los factores contribuyentes comunes y desarrollar acciones de remediación para disminuir la tasa de incidentes y aumentar la resiliencia del entorno tecnológico. Entreviste a los desarrolladores, ingenieros de versiones y otras personas involucradas en los incidentes para descubrir los factores contribuyentes y lo que podría haberse hecho para prevenirlos. El resultado proporcionará una perspectiva más sólida sobre los factores que contribuyeron a los incidentes y las acciones que se pueden tomar para disminuir la tasa de incidentes y aumentar la resiliencia de la tecnología.
Desarrollar una capacidad de tecnología redundante
Diseñar una arquitectura resistente para uno o más componentes de la pila de tecnología y una arquitectura de tecnología de estado futuro para abordar el diagnóstico anterior y la retrospectiva de incidentes. Estas capacidades deben incluir un plan de transición e implementación y requisitos para el monitoreo, mantenimiento y validación continuos. El resultado debe ser una arquitectura de tecnología resiliente, un plan de transición y de implementación junto con requisitos de monitoreo y validación.
Alcanzar la resiliencia no es una actividad de una sola vez; más bien, es un proceso continuo y una capacidad que llevará tiempo para convertirse en un mecanismo de defensa sólido.
Al igual que con todos los tipos de protección, no es «obtienes lo que pagas», sino «obtienes por lo que te preparas». Sería fácil gastar dinero en todas las formas de resiliencia, pero comprender lo que uno posee y luego tener visibilidad y transparencia sobre lo que uno tiene le brindará enfoque, lo que permitirá que cualquier organización siga siendo resiliente y siga funcionando o vuelva a un estado estable lo antes posible.
