En el mundo de un ingeniero de confiabilidad del sitio (SRE),la falla no solo es una opción, sino que también se espera. Los sistemas, aplicaciones web, servidores, dispositivos, etc., son propensos a problemas de rendimiento e interrupciones inesperadas en algún momento. Es un hecho inevitable. Estas fallas inesperadas pueden conducir a enormes pérdidas de ingresos, confianza del cliente y, dependiendo de la industria, tal vez multas. Afortunadamente, la gestión de incidentes de SRE es una de las prácticas básicas utilizadas para limitar la interrupción causada por problemas inesperados. En un artículo diferente, hablamos sobre la ingeniería del caos y cómo los equipos de SRE buscan y prueban proactivamente las fallas para evitar que suceda lo peor. Sin embargo, como todos sabemos, los problemas pueden pasar desapercibidos. El objetivo es evitar que estos incidentes se conviertan en fallas en cascada a gran escala. Los equipos de SRES y DevOps pueden usar estos incidentes para reconstruir mejor y mejorar sus sistemas y servicios.
¿Qué es un incidente?
Antes de profundizar más en este tema, primero debemos discutir qué es un incidente. ¿Dónde está la línea trazada entre algo que requiere una acción inmediata versus algo que puede ser investigado más tarde? Si cada problema se clasificara como urgente, nadie obtendría ninguna resolución. En el contexto de TI (Tecnología de la Información), un incidente es simplemente un evento o problema que interrumpe la operación normal o la calidad del servicio. No ha resultado en una falla, pero si no se controla, tiene la posibilidad de causar un mayor impacto en sus servicios y operaciones. Y generalmente ocurren a las 2:00 a.m. mientras estás felizmente dormido y te despierta el sonido de tu teléfono que se apaga. Estamos bromeando, por supuesto, pero sabes que algo es malo si sucede tan temprano en la mañana. Nada bueno sucede a las 2:00 a.m., especialmente cuando estamos hablando de la industria de TI.
¿Qué es la gestión de incidentes?
Ahora que hemos hablado de lo que es un incidente, la gestión de incidentes es el proceso mediante el cual los equipos resuelven estos eventos y devuelven los sistemas y servicios a la operación normal. También debemos tener en cuenta que la gestión de incidentes es solo un elemento de un concepto más amplio conocido como gestión de servicios de TI o ITSM. ITSM define cómo los equipos diseñan, crean y prestan sus servicios. Es mucho más que solo soporte de TI. ITSM son las políticas, los procesos y la estructura detrás del ciclo de vida de los servicios de TI. ITSM es una de las prácticas de la Biblioteca de Infraestructura de Tecnología de la Información, o ITIL.
ITIL proporciona el marco y las directrices para desarrollar soluciones ITSM. Es posible que ya esté familiarizado con otros marcos, como Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO/IEC 20000 y Microsoft Operations Framework (MOF).
El marco de gestión de servicios de TI (ITSM)
Si damos un paso atrás y solo nos centramos en los elementos dentro del marco de ITSM por un tiempo, hay otros seis componentes que componen la “rueda” de ITSM junto con la gestión de incidentes. Si bien no entraremos en detalles sobre estos, pero es importante comprender cómo encajan todas estas piezas junto con la gestión de incidentes.
Catálogo de servicios
El catálogo de servicios de TI suele ser una base de datos o recurso que una organización crea para proporcionar a los usuarios información sobre sus servicios operativos y ofertas. Estos catálogos de servicios proporcionan información útil sobre los servicios actuales y planificados, así como los precios, el proceso de compra, los puntos de contacto y otros entregables.
Mesa de Servicio
La mesa de servicio se puede considerar como el punto de contacto entre el proveedor de servicios y los usuarios, como los empleados internos, las partes interesadas o los clientes. Es el “hub” central donde los usuarios van a obtener asistencia y servicio. Según la definición de ITIL, la mesa de servicio puede tomar la forma de resolución de incidentes o solicitudes de servicio, pero cualquiera que sea el caso, el objetivo principal de la mesa de servicio es proporcionar un servicio rápido y eficiente.
Gestión de problemas
Cuando hablamos de gestión de incidentes, un equipo de SRE puede ser capaz de resolver rápidamente un incidente, pero el problema subyacente aún puede existir y persistir por un tiempo más. La gestión de problemas es el proceso mediante el cual se corrigen permanentemente las causas raíz de los incidentes, lo que mejora el rendimiento a largo plazo y las futuras implementaciones de servicios.
Gestión del cambio
Cualquier tipo de cambio, ya sea que estemos hablando de nuevos despliegues de servicios o cambios personales, siempre hay un elemento de riesgo. La gestión de cambios es el proceso de determinar cómo los cambios afectarán a la implementación del servicio y/o considerar los efectos en el propio negocio. La gestión del cambio también se agrupa a veces con la gestión de versiones.
Gestión de activos
No se puede virtualizar todo… todavía. Los servicios de software todavía requieren dispositivos físicos y hardware para que funcionen. Y las organizaciones necesitan rastrear, administrar y actualizar continuamente estos dispositivos para garantizar que sus servicios puedan funcionar sin problemas. La gestión de activos también se conoce como gestión de activos de TI, o ITAM.
Gestión de conocimientos, políticas y procedimientos
El objetivo de la gestión del conocimiento es reducir la redundancia en términos de recopilación, revisión y uso compartido de información dentro de una organización. Esto ayuda a mejorar la eficiencia y garantiza que la información sea consistente, actualizada y disponible.
Lifecyle de gestión de incidentes: proceso y pasos
La respuesta de una organización a un incidente, ya sea que estemos hablando de tiempo de inactividad, violaciones de seguridad o ataques cibernéticos, o incluso latencia prolongada y errores repetidos, es fundamental para el éxito continuo del negocio y la confianza del cliente o usuario final. Los SSE deben gestionar sistemas distribuidos complejos. Si bien los beneficios de estos sistemas son que son más confiables, escalables y tolerantes a fallas, esto también los hace extremadamente complejos, lo que puede resultar en tiempos de remediación más largos ya que los problemas son más difíciles de detectar e identificar. Los mejores equipos de gestión de incidentes de SRE se adhieren a un estricto proceso de gestión y remediación de incidentes. Si bien los pasos y procesos reales pueden variar entre las organizaciones, la mayoría sigue el mismo camino básico. Veamos el proceso y los pasos de la gestión de incidentes de SRE.
1. Identificación de incidentes
No puede solucionar problemas que no conoce. La identificación de incidentes comienza con algún tipo de mecanismo de monitoreo o alerta. Hablamos sobre el monitoreo de sistemas distribuidos en un artículo diferente y cómo eso se relaciona con los equipos de SRE. Saber cuándo y dónde se produce un error, tiempo de inactividad o latencia de la aplicación es un factor crítico para limitar el impacto en los usuarios y clientes. Sin embargo, en algunos casos, un incidente se conocerá a través de un ticket de soporte, una llamada telefónica o incluso las redes sociales, lo que nunca es una buena noticia cuando los problemas se publican públicamente para que todos los vean.
2. Registro de incidentes
Cualquiera que sea el método de detección, una vez que se ha identificado un incidente, debe registrarse. El registro de incidentes sirve para múltiples propósitos. Asegura que haya un registro formal que se haya presentado y que se revisen las tendencias de incidentes más adelante. Si el mismo incidente, o similar, aparece repetidamente, podría ser una indicación de un problema más complejo que debe abordarse. Al registrar un incidente, también se incluye información relevante, como la marca de tiempo, la descripción del incidente y quién descubrió el problema. Cuanto más detallada sea la información, mejor.
3. Categorización de incidentes
Luego viene la categorización del incidente en función de factores como la gravedad, la urgencia o el área funcional afectada. Al igual que el registro del incidente, cuanta más información se proporcione puede ayudar más adelante a la hora de determinar el equipo o la persona adecuada para asignar a la respuesta al incidente.
4. Priorización de incidentes
Según cómo se clasificó el incidente, el siguiente paso es establecer el nivel de prioridad. Una vez más, algunos de estos pasos ocurren al mismo tiempo, por lo que en algunos casos, pueden llevarse a cabo al mismo tiempo. Las organizaciones suelen utilizar una escala simple de baja, media o alta, sin embargo, algunos incidentes pueden caer automáticamente en categorías específicas dependiendo de lo que se vea afectado. Por ejemplo, si el incidente está relacionado con una interrupción, eso caería automáticamente en alta prioridad.
5. Respuesta, resolución y cierre de incidentes
El último paso es finalmente responder y resolver el incidente para cerrar. Este último paso es más una forma de arte que una ciencia. No hay un botón fácil aquí. Puede tomar varios ciclos e intenta confirmar que el incidente finalmente se resuelve. Cada intento puede traer más información y teorías adicionales sobre por qué puede estar sucediendo el incidente. Esto también puede conducir a la identificación de nuevas oportunidades donde las debilidades pueden estar presentes. Una vez que se ha tratado el incidente, es hora de cerrar la solicitud y responder al usuario original que informó del incidente.
Autopsias
Después de una respuesta a un incidente, generalmente es una buena idea revisar los detalles del incidente en su totalidad. Esto se llama un incidente post mortem. Determinar qué incidentes requieren una autopsia generalmente lo decide el equipo u organización, sin embargo, las razones siguen siendo las mismas. Las autopsias ayudan a identificar áreas que se pueden mejorar, identificar puntos ciegos de rendimiento y refinar su proceso de respuesta a incidentes. Una autopsia debe resumir todos los aspectos del incidente e incluir los siguientes elementos:
- Resumen de alto nivel y cronograma del incidente.
- Análisis de causa raíz y fuente del incidente.
- Acciones tomadas para resolver el incidente y cuáles fueron efectivas o no efectivas.
- Prevención de incidentes futuros junto con información adicional que se descubrió.
Las autopsias son una de las reglas centrales de la cultura SRE. De hecho, lo llaman post mortem sin culpa. La idea detrás de este concepto es que todos en el equipo actuaron con las mejores intenciones y nadie tiene la culpa del incidente. La atención se centra en identificar por qué sucedió y cómo mejorar el rendimiento del sistema en el futuro. Los errores son una parte natural de la industria, por lo que en lugar de culpar a las personas, el enfoque está en crear un sistema más robusto y resistente para que los problemas nunca vuelvan a suceder.
Conclusión: SRE Incident Management – Visión general, técnicas y herramientas
La gestión de incidentes de SRE es fundamental para mantener los sistemas, aplicaciones, sitios y servicios en funcionamiento. Los segundos importan, especialmente cuando se trata de la experiencia del usuario. En sistemas distribuidos grandes, el problema más pequeño podría causar problemas en cascada. La configuración proactiva de las alertas y notificaciones correctas puede ser la diferencia cuando ocurren problemas y garantizar que el impacto para los usuarios sea limitado. Para obtener más información sobre cómo la plataforma Dotcom-Monitor se integra con estas herramientas de gestión de incidentes, visite nuestra Base de conocimientos.
Pruebe Dotcom-Monitor de forma gratuita y obtenga acceso a todas las soluciones, integraciones y funciones de la plataforma.
