{"id":22473,"date":"2021-12-08T16:18:10","date_gmt":"2021-12-08T16:18:10","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/?p=22473"},"modified":"2026-06-15T15:43:58","modified_gmt":"2026-06-15T15:43:58","slug":"gestion-de-incidentes-sre-vision-general-tecnicas-y-herramientas","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/gestion-de-incidentes-sre-vision-general-tecnicas-y-herramientas\/","title":{"rendered":"Gesti\u00f3n de incidentes SRE: visi\u00f3n general, t\u00e9cnicas y herramientas"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

En el mundo de un ingeniero de confiabilidad del sitio (SRE),<\/a>la falla no solo es una opci\u00f3n, sino que tambi\u00e9n se espera. Los sistemas, aplicaciones web, servidores, dispositivos, etc., son propensos a problemas de rendimiento e interrupciones inesperadas en alg\u00fan momento. Es un hecho inevitable. Estas fallas inesperadas pueden conducir a enormes p\u00e9rdidas de ingresos, confianza del cliente y, dependiendo de la industria, tal vez multas. Afortunadamente, la gesti\u00f3n de incidentes de SRE es una de las pr\u00e1cticas b\u00e1sicas utilizadas para limitar la interrupci\u00f3n causada por problemas inesperados. En un art\u00edculo diferente, hablamos sobre la ingenier\u00eda del caos<\/a> y c\u00f3mo 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.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 es un incidente?<\/h2>\n

Antes de profundizar m\u00e1s en este tema, primero debemos discutir qu\u00e9 es un incidente. \u00bfD\u00f3nde est\u00e1 la l\u00ednea trazada entre algo que requiere una acci\u00f3n inmediata versus algo que puede ser investigado m\u00e1s tarde? Si cada problema se clasificara como urgente, nadie obtendr\u00eda ninguna resoluci\u00f3n. En el contexto de TI (Tecnolog\u00eda de la Informaci\u00f3n), un incidente es simplemente un evento o problema que interrumpe la operaci\u00f3n 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\u00e1s felizmente dormido y te despierta el sonido de tu tel\u00e9fono que se apaga. Estamos bromeando, por supuesto, pero sabes que algo es malo si sucede tan temprano en la ma\u00f1ana. Nada bueno sucede a las 2:00 a.m., especialmente cuando estamos hablando de la industria de TI.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 es la gesti\u00f3n de incidentes?<\/h2>\n

Ahora que hemos hablado de lo que es un incidente, la gesti\u00f3n de incidentes es el proceso mediante el cual los equipos resuelven estos eventos y devuelven los sistemas y servicios a la operaci\u00f3n normal. Tambi\u00e9n debemos tener en cuenta que la gesti\u00f3n de incidentes es solo un elemento de un concepto m\u00e1s amplio conocido como gesti\u00f3n de servicios de TI o ITSM. ITSM define c\u00f3mo los equipos dise\u00f1an, crean y prestan sus servicios. Es mucho m\u00e1s que solo soporte de TI. ITSM son las pol\u00edticas, los procesos y la estructura detr\u00e1s del ciclo de vida de los servicios de TI. ITSM es una de las pr\u00e1cticas de la Biblioteca de Infraestructura de Tecnolog\u00eda de la Informaci\u00f3n, o ITIL.<\/p>\n

ITIL proporciona el marco y las directrices para desarrollar soluciones ITSM. Es posible que ya est\u00e9 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).<\/p>\n

<\/p>\n

El marco de gesti\u00f3n de servicios de TI (ITSM)<\/h3>\n

Si damos un paso atr\u00e1s 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\u00f3n de incidentes. Si bien no entraremos en detalles sobre estos, pero es importante comprender c\u00f3mo encajan todas estas piezas junto con la gesti\u00f3n de incidentes.<\/p>\n

<\/p>\n

Cat\u00e1logo de servicios<\/h4>\n

El cat\u00e1logo de servicios de TI suele ser una base de datos o recurso que una organizaci\u00f3n crea para proporcionar a los usuarios informaci\u00f3n sobre sus servicios operativos y ofertas. Estos cat\u00e1logos de servicios proporcionan informaci\u00f3n \u00fatil sobre los servicios actuales y planificados, as\u00ed como los precios, el proceso de compra, los puntos de contacto y otros entregables.<\/p>\n

<\/p>\n

Mesa de Servicio<\/h4>\n

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\u00fan la definici\u00f3n de ITIL, la mesa de servicio puede tomar la forma de resoluci\u00f3n 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\u00e1pido y eficiente.<\/p>\n

<\/p>\n

Gesti\u00f3n de problemas<\/h4>\n

Cuando hablamos de gesti\u00f3n de incidentes, un equipo de SRE puede ser capaz de resolver r\u00e1pidamente un incidente, pero el problema subyacente a\u00fan puede existir y persistir por un tiempo m\u00e1s. La gesti\u00f3n de problemas es el proceso mediante el cual se corrigen permanentemente las causas ra\u00edz de los incidentes, lo que mejora el rendimiento a largo plazo y las futuras implementaciones de servicios.<\/p>\n

<\/p>\n

Gesti\u00f3n del cambio<\/h4>\n

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\u00f3n de cambios es el proceso de determinar c\u00f3mo los cambios afectar\u00e1n a la implementaci\u00f3n del servicio y\/o considerar los efectos en el propio negocio. La gesti\u00f3n del cambio tambi\u00e9n se agrupa a veces con la gesti\u00f3n de versiones.<\/p>\n

<\/p>\n

Gesti\u00f3n de activos<\/h4>\n

No se puede virtualizar todo… todav\u00eda. Los servicios de software todav\u00eda requieren dispositivos f\u00edsicos 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\u00f3n de activos tambi\u00e9n se conoce como gesti\u00f3n de activos de TI, o ITAM.<\/p>\n

<\/p>\n

Gesti\u00f3n de conocimientos, pol\u00edticas y procedimientos<\/h4>\n

El objetivo de la gesti\u00f3n del conocimiento es reducir la redundancia en t\u00e9rminos de recopilaci\u00f3n, revisi\u00f3n y uso compartido de informaci\u00f3n dentro de una organizaci\u00f3n. Esto ayuda a mejorar la eficiencia y garantiza que la informaci\u00f3n sea consistente, actualizada y disponible.<\/p>\n

<\/p>\n

Lifecyle de gesti\u00f3n de incidentes: proceso y pasos<\/h2>\n

La respuesta de una organizaci\u00f3n a un incidente, ya sea que estemos hablando de tiempo de inactividad, violaciones de seguridad o ataques cibern\u00e9ticos, o incluso latencia prolongada y errores repetidos, es fundamental para el \u00e9xito 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\u00e1s confiables, escalables y tolerantes a fallas, esto tambi\u00e9n los hace extremadamente complejos, lo que puede resultar en tiempos de remediaci\u00f3n m\u00e1s largos ya que los problemas son m\u00e1s dif\u00edciles de detectar e identificar. Los mejores equipos de gesti\u00f3n de incidentes de SRE se adhieren a un estricto proceso de gesti\u00f3n y remediaci\u00f3n de incidentes. Si bien los pasos y procesos reales pueden variar entre las organizaciones, la mayor\u00eda sigue el mismo camino b\u00e1sico. Veamos el proceso y los pasos de la gesti\u00f3n de incidentes de SRE.<\/p>\n

<\/p>\n

1. Identificaci\u00f3n de incidentes<\/h3>\n

No puede solucionar problemas que no conoce. La identificaci\u00f3n de incidentes comienza con alg\u00fan tipo de mecanismo de monitoreo o alerta. Hablamos sobre el monitoreo de sistemas distribuidos<\/a> en un art\u00edculo diferente y c\u00f3mo eso se relaciona con los equipos de SRE. Saber cu\u00e1ndo y d\u00f3nde se produce un error, tiempo de inactividad o latencia de la aplicaci\u00f3n es un factor cr\u00edtico para limitar el impacto en los usuarios y clientes. Sin embargo, en algunos casos, un incidente se conocer\u00e1 a trav\u00e9s de un ticket de soporte, una llamada telef\u00f3nica o incluso las redes sociales, lo que nunca es una buena noticia cuando los problemas se publican p\u00fablicamente para que todos los vean.<\/p>\n

<\/p>\n

2. Registro de incidentes<\/h3>\n

Cualquiera que sea el m\u00e9todo de detecci\u00f3n, una vez que se ha identificado un incidente, debe registrarse. El registro de incidentes sirve para m\u00faltiples prop\u00f3sitos. Asegura que haya un registro formal que se haya presentado y que se revisen las tendencias de incidentes m\u00e1s adelante. Si el mismo incidente, o similar, aparece repetidamente, podr\u00eda ser una indicaci\u00f3n de un problema m\u00e1s complejo que debe abordarse. Al registrar un incidente, tambi\u00e9n se incluye informaci\u00f3n relevante, como la marca de tiempo, la descripci\u00f3n del incidente y qui\u00e9n descubri\u00f3 el problema. Cuanto m\u00e1s detallada sea la informaci\u00f3n, mejor.<\/p>\n

<\/p>\n

3. Categorizaci\u00f3n de incidentes<\/h3>\n

Luego viene la categorizaci\u00f3n del incidente en funci\u00f3n de factores como la gravedad, la urgencia o el \u00e1rea funcional afectada. Al igual que el registro del incidente, cuanta m\u00e1s informaci\u00f3n se proporcione puede ayudar m\u00e1s adelante a la hora de determinar el equipo o la persona adecuada para asignar a la respuesta al incidente.<\/p>\n

<\/p>\n

4. Priorizaci\u00f3n de incidentes<\/h3>\n

Seg\u00fan c\u00f3mo se clasific\u00f3 el incidente, el siguiente paso es establecer el nivel de prioridad. Una vez m\u00e1s, 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\u00e1ticamente en categor\u00edas espec\u00edficas dependiendo de lo que se vea afectado. Por ejemplo, si el incidente est\u00e1 relacionado con una interrupci\u00f3n, eso caer\u00eda autom\u00e1ticamente en alta prioridad.<\/p>\n

<\/p>\n

5. Respuesta, resoluci\u00f3n y cierre de incidentes<\/h3>\n

El \u00faltimo paso es finalmente responder y resolver el incidente para cerrar. Este \u00faltimo paso es m\u00e1s una forma de arte que una ciencia. No hay un bot\u00f3n f\u00e1cil aqu\u00ed. Puede tomar varios ciclos e intenta confirmar que el incidente finalmente se resuelve. Cada intento puede traer m\u00e1s informaci\u00f3n y teor\u00edas adicionales sobre por qu\u00e9 puede estar sucediendo el incidente. Esto tambi\u00e9n puede conducir a la identificaci\u00f3n 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\u00f3 del incidente.<\/p>\n

<\/p>\n

Autopsias<\/h2>\n

Despu\u00e9s 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\u00e9 incidentes requieren una autopsia generalmente lo decide el equipo u organizaci\u00f3n, sin embargo, las razones siguen siendo las mismas. Las autopsias ayudan a identificar \u00e1reas 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:<\/p>\n