Menta

Blog

Seguridad de la información: 9 mitos de respuesta a incidentes: ¡desmentidos!

La respuesta a incidentes se refiere a los procesos colectivos que ayudan a detectar, identificar, solucionar problemas y resolver dichos incidentes.

Un incidente ocurre cada vez que un servicio no está disponible o no funciona de la forma en que se ha definido, generalmente a través de un acuerdo de nivel de servicio (Service Level Agreement, SLA) formal. Los incidentes pueden ser causados por ​​diversos factores: cortes de red, errores de aplicaciones, fallas de hardware o errores de configuración.

La respuesta a incidentes se refiere a los procesos colectivos que ayudan a detectar, identificar, solucionar problemas y resolver dichos incidentes. Ha evolucionado a lo largo de los años para incluir muchos marcos y enfoques. Sin embargo, todos comparten un objetivo común: brindar a las partes interesadas las herramientas que necesitan para que los sistemas que se comportan mal vuelvan a funcionar lo antes posible, al tiempo que hacen que esos sistemas sean más robustos y confiables.

Sin embargo, a pesar de su larga historia, la respuesta a incidentes todavía está envuelta en mitos y obstaculizada por percepciones erróneas que impiden que las empresas resuelvan los incidentes de la manera más rápida y eficaz posible, y quizás lo más importante, que aprendan cómo reducir la ocurrencia de incidentes.

Mito 1: La velocidad lo es todo

También conocido como el mito de "cualquier solución es una buena solución". Obviamente, la resolución rápida de problemas es importante, especialmente para los sistemas que afectan directamente a los clientes. Pero no es lo único de lo que preocuparse. Una solución incorrecta o incompleta, o una solución temporal, o una solución que rompe algo más en el futuro, puede ser peligrosa de implementar en nombre de la velocidad.

Las empresas deben centrarse en la eficacia del resultado final y en la velocidad. 

Mito 2: Una vez que apagues el fuego, habrás terminado

Este mito, afortunadamente, se está erradicado lentamente. En estos días, es bastante estándar tener algún tipo de autopsia o retrospectiva interna después de resolver un incidente. El punto es aprender proactivamente del incidente para hacer que sus sistemas sean más robustos y estables, y evitar incidentes similares en el futuro. La frase relevante aquí es "aprender de forma proactiva".

Es importante pensar en la respuesta a incidentes como un proceso de extremo a extremo en el que la respuesta es medida, iterativa, repetible y escalable. Por ello, es fundamental incentivar las medidas de prevención en lugar de simplemente resolver incidentes en modo reactivo.

Mito 3: informar sólo de los problemas importantes de los que se quejan los clientes para evitar que  TI se vea mal

Otro mito prevaleciente sostiene que no debes ser demasiado comunicativo acerca de tus incidentes. Si informas todos los incidentes, según el razonamiento, puede parecer que TI está fallando, por lo que es mejor reconocer y comunicar sólo los incidentes graves que los clientes han notado y reportado.

Esa es la teoría, pero es una muy mala idea. Los clientes y las partes interesadas internas prefieren la honestidad y la transparencia. Necesitan saber que pueden confiar en el equipo para detectar y reconocer los incidentes que podrían afectarles. Ocultar incidentes, incluso los menores, puede destruir esa confianza.

Tener incidentes es sólo parte del juego y todos deben saberlo. La clave es lo que se hace con esos incidentes. Lo mejor es ser proactivo en la comunicación.

Mito 4: sólo importan los incidentes que afectan al cliente

Este mito se ha extendido tanto que incluso algunas organizaciones definen los incidentes únicamente como "interrupciones que afectan al cliente". Pero creer en ese mito reduce la efectividad general de la respuesta a incidentes. Nuevamente, la idea es que la respuesta a incidentes debe ser una experiencia de aprendizaje y que debe tomar acciones proactivas basadas en ese aprendizaje.

Mito 5: los sistemas siempre alertarán cuando sea necesario

La gente de operaciones tiende a monitorear lo que cree que es importante. Pero no siempre tiene razón. Esto se reduce a la diferencia entre monitorización macro y micro. En la micro monitorización, se están mirando componentes individuales como CPU, memoria y disco. Con la supervisión de macros, se está observando el panorama general, que es cómo afecta a los usuarios de los sistemas.

Aquí es donde entran en juego los objetivos de nivel de servicio (SLO) y los indicadores de nivel de servicio (SLI). Se busca observar la experiencia del usuario. Por ejemplo, si de repente tus solicitudes web por segundo caen a cero, sabes que tienes un problema. Si simplemente hicieras un micro monitoreo, como controlar la utilización de la memoria, podría perderse la falla. Al observar la métrica que importaba: si los usuarios están interactuando con el sistema, es posible captar algo que de otro modo no habrías notado.

Mito 6: puedes saber qué tan bien están funcionando tus procesos de mensajería instantánea con el tiempo medio de resolución

El MTTR es exactamente lo que dice: el tiempo promedio que se tarda en resolver un incidente. Pero abundan los problemas al depender de esta métrica como indicador para el éxito de la respuesta a incidentes. Para empezar, no todos los incidentes son iguales. Los incidentes simples y fáciles de resolver no deben juzgarse con la misma métrica que los más complicados.

¿Cómo se compara un servicio de correo electrónico empresarial que no funciona con una aplicación que sólo tiene un puñado de usuarios, que tal vez sufre un incidente fácilmente resuelto cada dos meses? Los incidentes son tan variados que no es un buen indicador de lo bien que lo está haciendo.

Además, medir el MTTR es en sí mismo un arte, no una ciencia. Por ejemplo, ¿cuándo empieza a correr el reloj? ¿Es cuando una aplicación comienza a ralentizarse? ¿Cuándo recibe su primera alerta? ¿Cuando un cliente se da cuenta? Los límites de los sistemas complejos son tan fluidos que ésta es una métrica difícil de capturar de manera consistente. El MTTR puede resultar útil si el tiempo de respuesta a incidentes es tan bajo que está tratando de reducirlo a un número aceptable; de lo contrario, puede resultar muy engañoso.

Mito 7: estamos mejorando en mensajería instantánea porque detectamos problemas antes y más rápido

Gracias a la mayor eficacia y granularidad de las herramientas automatizadas de monitoreo y alerta como New Relic, las empresas están mejorando mucho en la detección de incidentes de lo que antes era posible. Pero eso no significa que estemos mejorando en la respuesta a incidentes. Detectar un incidente es sólo la mitad de la ecuación. Resolverlo es la otra mitad.

¿El remedio? La inteligencia artificial y el aprendizaje automático pueden ayudar evaluando datos históricos relacionados con incidentes y sugiriendo posibles respuestas en función de incidentes anteriores. Sin embargo, en la mayoría de los incidentes se requiere un mínimo de cinco personas para resolver. Además, cuanto mayor sea el número de aplicaciones de misión crítica, cuanto más grande y distribuida sea la organización, más tiempo llevará.

Mito 8: una "cultura impecable" significa que no hay responsabilidad por los incidentes

Éste es un mito importante que hay que disipar, dado el movimiento (positivo) en la industria de TI hacia una cultura libre de culpa.

En el lado positivo, una cultura libre de culpa elimina el miedo de la ecuación de respuesta a incidentes: es mucho más probable que las personas sean sinceras y transparentes cuando saben que no van a ser despedidas por cometer un error. Pero eso no implica que no haya responsabilidad. Aún debes identificar qué errores se cometieron y quién los cometió para aprender de ellos.

Existe una gran diferencia entre la responsabilidad y la culpa. La culpa generalmente malinterpreta la naturaleza de los sistemas complejos, en los que es probable que un error particular sea más un evento desencadenante que vuelca las fichas de dominó de las fallas latentes. Una cultura libre de culpa realmente permite una verdadera responsabilidad, porque las personas y los equipos se sienten lo suficientemente seguros como para ser transparentes sobre los pasos en falso, de modo que la organización pueda mejorar el sistema en general.

Mito 9: se necesita un equipo dedicado a mensajería instantánea

Si bien algunas empresas optan por tener un equipo dedicado a la respuesta a incidentes independiente, otras prefieren rotar a las personas a través de trabajos regulares de ingeniería de TI. 

En el enfoque de DevOps, cualquier ingeniero debería poder responder a cualquier incidente en cualquier función. Las respuestas a los incidentes del día a día deben distribuirse en toda la organización. Es crucial capacitar a cualquier ingeniero que tenga la información necesaria para realizar llamadas difíciles durante un incidente. Capacita a quien esté respondiendo para que pueda tomar decisiones difíciles y sepa que puede hacer todo lo posible y tomar decisiones.

Por supuesto, todo esto requiere una formación intensa, profunda y continua, así como procesos repetibles e iterativos. Cada ingeniero de guardia debe tener la capacitación y la  experiencia suficientes para realizar buenas llamadas, y también debe contar con soporte en caso de que una llamada se desvíe.

¿Sabe cómo determinar las transacciones problemáticas en su aplicación web? Nuestros expertos pueden apoyarlo.

Contáctanos