Gestión de Incidentes para Operaciones

Capítulo 1. Evaluación del PROCESO de Respuesta a Incidentes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Definición de incidente:

Suceso, provocado por el hombre o por un fenómeno natural, que requiere la actuación o el apoyo del personal de los servicios de emergencia para evitar o minimizar la pérdida de vidas o los daños a la propiedad y/o a los recursos naturales. (Asociación Nacional de Protección contra Incendios)

Interrupción no planificada de un servicio informático o reducción de la calidad de un servicio informático. (ITIL)

Mientras lees esta frase, se están produciendo incidentes informáticos en todo el mundo. La respuesta a esos incidentes adopta muchas formas, desde una persona trabajando en un problema hasta un gran grupo de personas marcando en un puente de conferencia telefónica o tecleando en una plétora de aplicaciones de comunicación/flujo de trabajo/productividad desde cualquier parte del mundo. Esos respondedores pueden utilizar el proceso ITIL o los principios DevOps o un sistema creado internamente o algún otro método. La respuesta puede ser completamente organizada o totalmente caótica. Pero, de un modo u otro, los incidentes de TI se resuelven. La verdadera pregunta es: "¿Se están resolviendo tan rápidamente como podrían?".

Nota

A modo de ilustración a lo largo del libro, utilizaremos un puente de conferencia como ejemplo de las comunicaciones de los IRT. Hay muchos métodos utilizados para comunicarse durante un incidente, incluidas las comunicaciones verbales y escritas a través de muchas plataformas tecnológicas, y no todos los IRT utilizan puentes de conferencia para la respuesta a incidentes, pero la representación de la palabra hablada sirve como plataforma eficaz para ilustrar las comunicaciones interpersonales.

El primer paso en el camino hacia una respuesta a incidentes eficiente y bien organizada comienza con una evaluación honesta del status quo, incluido el Ciclo de Vida del Incidente (ver Figura 1-1). En muchos casos, los responsables de la respuesta a incidentes se encuentran con un patrón de respuesta (bueno o malo) y acaban aferrándose a él por inercia. Algunos intervinientes pueden haber sobrevivido a un incidente importante y decir "vaya, estuvo cerca, espero que no vuelva a ocurrir". Los patrones y los hábitos, por su propia naturaleza, son cómodos de mantener y difíciles de romper.

Figura 1-1. El ciclo de vida del incidente

Independientemente de si estás contento o descontento con la forma en que tu Equipo de Respuesta a Incidentes (ERI) responde a las emergencias informáticas, es conveniente investigar si se puede mejorar el rendimiento.

Nota

En aras de la coherencia, el resto de este libro utilizará el término Equipo de Respuesta a Incidentes (IRT) como término general para el grupo encargado de mitigar los incidentes dentro de una organización. Tu grupo particular puede tener un término o una estructura organizativa diferente para responder a los incidentes.

Al fin y al cabo, los incidentes suponen un riesgo para la empresa de muchas maneras, ninguna de ellas buena: reputación empañada; erosión de la confianza de los clientes; disminución de la marca; repercusiones financieras adversas y pérdida de confianza de los inversores. Los equipos de respuesta a incidentes eficaces y con éxito comparten características comunes, todas ellas fáciles de identificar una vez que sabes qué buscar. Aparte de la Revisión Posterior a la Acción (RPA) (véase el Capítulo 6), que tiene lugar después de la respuesta, puede ser útil que evalúes todo tu proceso de respuesta a incidentes tal como existe en la actualidad y veas si hay áreas que podrían mejorarse.

Para empezar, es útil elaborar una lista de preguntas generales que puedan plantearse y responderse tanto cuantitativa como cualitativamente. Disponer de buenos datos de referencia sobre estadísticas de respuesta anteriores y/o sobre cómo está configurado tu equipo de respuesta ayuda a sentar las bases de la evaluación.

Si eres una organización pequeña con pocas personas, puede parecer obvio quién responderá para resolver las incidencias. Una de las primeras preguntas que hacemos a las organizaciones es la siguiente: ¿Hay una persona que entienda toda la pila con gran detalle para solucionar cualquier problema que pueda surgir? La respuesta obvia es no, pero lo hemos validado con organizaciones de todo el mundo. Además, a medida que las empresas crecen y escalan, toda la pila seguirá complicándose, lo que requerirá solucionadores de problemas más especializados, lo que exigirá un proceso de gestión de incidencias más maduro. Si tu organización adquiere empresas para ampliar su negocio y su cartera de productos y servicios, los procesos de gestión de incidencias de las empresas adquiridas también deben identificarse, evaluarse y revisarse durante la fase de diligencia debida del acuerdo. Independientemente de cómo crezca tu organización, hazte preguntas como las siguientes para centrarte en cómo configurar mejor el Equipo de Respuesta a Incidentes.

Desde luego, esta lista de preguntas no es exhaustiva y pretende simplemente estimular tu propia reflexión sobre cómo sentar las bases de una evaluación del Equipo de Respuesta a Incidentes:

• ¿Cuál es tu definición de incidente y de acontecimiento?

• ¿A cuántos incidentes respondes en un mes determinado?

• ¿Cuál es la proporción entre incidentes y sucesos y respondes de la misma manera a ambos?

• ¿Cuántos incidentes se produjeron al mes en los dos últimos años?

• ¿Cuántos acontecimientos se produjeron al mes en los dos últimos años?

• Identifica y describe los niveles actuales de gravedad/prioridad para la respuesta a incidentes.

• ¿Se utilizan los niveles de gravedad/prioridad de los incidentes y/o se aplican de forma coherente en toda la organización de respuesta a incidentes?

• ¿De qué informes/análisis de datos relativos a la respuesta a incidentes disponéis?

• En tu opinión, ¿se gestionan y dirigen los incidentes de forma coherente y eficaz? Si no es así, enumera los retos/obstáculos.

• Cuando se produce un incidente, ¿hay un plan definido de respuesta y escalada?

• ¿Hay un equipo central con responsabilidades de guardia 24x7 o el equipo está de guardia?

• Haz una lista de todos los posibles respondedores al incidente (Comandantes de Incidente y PYMES) por unidad de negocio y ubicación geográfica.

• Describe el horario de los turnos y la dotación de personal del Equipo principal de Respuesta a Incidentes, por ubicación y función.

• Enumera los proveedores externos que forman parte de la respuesta al incidente por función, ubicación e información de contacto.

• ¿Tienen los miembros del IRT normas de tiempo para la respuesta a incidentes? ¿Los equipos de respuesta siguen esas normas de tiempo y la dirección ejecutiva las hace cumplir?

• ¿Qué retos existen a la hora de integrar a las PYME en una respuesta?

• ¿Existe un organigrama para la respuesta a incidentes que enumere el Equipo de Respuesta a Incidentes principal y todos los demás participantes?

• ¿Cómo se producen las comunicaciones durante un incidente (por ejemplo, conferencia telefónica, herramientas basadas en la web, etc.)?

• ¿Se graban las comunicaciones de voz del incidente (por ejemplo, puentes de conferencia, WebEx, etc.)? ¿Se archivan? ¿Se revisan?

• ¿Hay alguien asignado para preparar y realizar el Análisis de Causas Raíz (ACR) y los AAR?

• ¿Existe un proceso para incorporar la información aprendida de las recomendaciones de los AAR al desarrollo/ingeniería en tiempos de paz?

• ¿Qué papel desempeñan los altos ejecutivos durante la respuesta a un incidente?

Ten en cuenta que una respuesta eficaz a los incidentes es cuestión de proceso, con diez pasos generales pero distintos en el Ciclo de Vida del Incidente:

1. Detecta el problema.

2. Determina si el asunto es un incidente o un suceso.

3. Envía al Equipo de Respuesta a Incidentes adecuado.

4. Reúne al equipo de respuesta tiempo medio de reunión (MTTA).

5. Establece el mando, organiza los recursos y fija los objetivos del incidente.

6. Dirige el esfuerzo de resolución utilizando IMS.

7. Notifícalo a las partes interesadas.

8. Resuelve el incidente y libera los recursos.

9. Realiza AAR.

10. Poner en práctica la mejora de la calidad (MC) y la garantía de calidad (GC) (tratadas con más detalle más adelante en el capítulo).

Evento: Un hecho puntual relevante para las operaciones de tu infraestructura o aplicación (por ejemplo, la CPU ha superado el umbral del 95% en host-abc o el Cambio nº 1234 se ha implementado correctamente en host-abc), pero que no se considera un incidente. Los eventos no requieren la implantación del Sistema de Gestión de Incidentes (SGI) ni un Comandante de Incidentes (CI). Los eventos pueden convertirse en incidentes.

Puede que te encuentres con una versión de esta lista en un orden distinto o quizá con un paso diferente aquí o allá, pero, en su mayor parte, así es como evoluciona un incidente informático. La Figura 1-1 representa el Ciclo de Vida de un Incidente. QA y QI forman parte del proceso AAR, y no se mencionan aquí como elementos separados.

Solemos encontrarnos con Equipos de Respuesta a Incidentes que se han visto desbordados por un incidente que se hizo más grande y/o más desagradable y/o avanzó más rápido de lo que estaban preparados. Quizá no pudieron reunir rápidamente los recursos técnicos adecuados o se vieron frustrados por el hecho de que sólo unos pocos miembros del equipo eran "capaces de dirigir un incidente". O puede que faltara un liderazgo claro y dirigido, lo que provocó el caos en el puente de conferencias telefónicas sobre incidentes o en algún otro canal de comunicación. Operar con éxito entornos de producción de alta fiabilidad depende de un liderazgo fuerte y de un equipo capaz de expertos técnicos en red, computación, almacenamiento y aplicaciones, tanto si se trata de un pequeño equipo DevOps como de un equipo empresarial global. En los flujos de trabajo diarios, por ejemplo, DevOps es un deporte de equipo con una metodología colaborativa que marcha según una cadencia determinada. La respuesta a incidentes también es un deporte de equipo que depende de un liderazgo fuerte y de un equipo capaz de expertos técnicos, pero el ritmo al que el equipo se reúne y comienza la resolución es diferente al de completar un sprint o alguna otra tarea no relacionada con incidentes.

Hemos desarrollado un acrónimo que representa los siete atributos clave de un programa eficaz de respuesta a incidentes. PROCESS significaPredecible,Repetible,Optimizado,Claro,Evaluado, Escalable ySostenible.

Para ello, cada letra de PROCESO es un eslabón interdependiente en la cadena de respuesta a incidentes. Utiliza esos eslabones como herramienta de análisis paso a paso para evaluar cómo está a la altura tu enfoque actual de respuesta informática. El Ciclo de Vida del Incidente es también una serie de pasos interrelacionados que se basan progresivamente en el paso anterior e influyen en todos los demás pasos posteriores. Por ejemplo, si reducir el tiempo medio de reparación (MTTR) de un incidente informático es importante para la empresa, debes examinar cada elemento del Ciclo de Vida del Incidente, desde la detección de la presencia de un problema hasta el envío del equipo y el tiempo que se tarda en reunir el equipo de personas adecuado, pasando por el esfuerzo de resolución y el AAR.

Muchas empresas pierden un tiempo valioso al principio del Ciclo de Vida del Incidente debido al envío ineficaz de los intervinientes. Además, descubrimos que muchas empresas no distinguen claramente entre una notificación y un envío. Es típico no encontrar una distinción clara entre los que están "al tanto" de la información relativa a un incidente y los que son llamados a responder.

Envío: Acción de ponerse en contacto con una persona concreta que representa una función laboral (base de datos, red, almacenamiento, seguridad, por ejemplo), un equipo u otro grupo con el fin de convocar una función necesaria para el incidente. El envío se diferencia de la notificación en que es una orden y no una solicitud. En el servicio de bomberos, ser enviado es una directiva que debe seguirse como cualquier otra directiva y no es una negociación ni se considera opcional.

Notificación: Mensaje (urgente o no) enviado a una persona (por ejemplo, SMS, teléfono, correo electrónico), normalmente relacionado con una alerta o incidente. Las notificaciones pretenden ser una información más que un envío. Las notificaciones no son una llamada a responder, aunque pueden utilizarse para informar a la gente de los acontecimientos.

A efectos de comparación y claridad, piénsalo así: se avisa a la gente y se envían las funciones de respuesta a incidentes.

Alerta: Representa el estado de una comprobación/condición de una herramienta de monitoreo iniciada/resuelta por un evento (por ejemplo, de Pingdom-tu sitio web está actualmente ABIERTO). Las alertas son generadas por herramientas de monitoreo de tecnología para identificar una anormalidad en el entorno. Las alertas pueden ser el primer momento en que se identifica un suceso. Una investigación posterior puede determinar si se trata de un suceso o un incidente.

Algunas empresas utilizan el enfoque de "rociar y rezar" o "pensar en grupo", consistente en enviar notificaciones a un montón de expertos técnicos, ejecutivos y otros, hacer que decenas de ellos lleguen a un puente de conferencia abierta (u otro método de comunicación) sin líder identificado, con la esperanza de que el grupo resuelva el problema en un tiempo razonable. En la práctica, estos grupos serpentean en su camino hacia la resolución. En otros casos, no hay una expectativa clara de que, una vez alertado, un interviniente en un incidente deba llegar a un puente de conferencia telefónica con algún sentido de urgencia. Muchas empresas son bastante laxas a la hora de definir y comunicar expectativas claras acerca de que esté "de guardia". Si estás de guardia, estás en el negocio de "ahora mismo", no en el de "ya me pondré a ello dentro de unos minutos", o en el de "estoy ocupado haciendo otras cosas". El tiempo es dinero y cuanto más se tarde en enviar y reunir al equipo adecuado, más se tardará en resolver el problema. Puedes conseguir más respondedores o escribir más código, pero no puedes ganar más tiempo. El tiempo sólo puede ahorrarse o malgastarse.

Consejo

Si respondes a incidentes informáticos, EL TIEMPO es el bien más importante que existe.

Muchos equipos (y directivos de empresa) se centran en preguntar por el Análisis de la Causa Raíz (ACR) de un problema en los primeros minutos de un incidente. Ésta es la pregunta equivocada. Preguntarse "por qué se ha roto" (causa raíz) es mucho menos importante que "cómo lo arreglamos" (resolución del incidente). En nuestra opinión, lo primero en lo que hay que centrarse es en el tiempo medio para reunir (MTTA) al equipo adecuado. ¡No tendrás buenos MTTR con MTTA lentos! En las primeras fases de un incidente, los hechos se van descubriendo a medida que se desarrolla la situación. Los mejores descubridores de hechos son los expertos en la materia técnica (PYMES) que responden al incidente, porque pueden mirar los registros, realizar consultas y ejecutar análisis. Estos PYMES se convierten en los ojos y oídos del Equipo de Respuesta a Incidentes. Sin MTTA urgente de los PYMES, no hay datos. Sin datos, el Equipo de Respuesta a Incidentes vuela a ciegas y no se pueden tomar medidas correctivas. ¡Céntrate primero en solucionar el problema y restablecer el servicio! Como decimos en el cuerpo de bomberos, "cuando apagas el fuego, las condiciones mejoran".

Para ello, sé duro contigo mismo y con tus expectativas, y sé realista a la hora de evaluar tu actual proceso de respuesta a incidentes. En la mayoría de las empresas es fácil mejorar la MTTA si la empresa está dispuesta a establecer expectativas claras. Piensa en esto: la parte MTTA del Ciclo de Vida del Incidente contiene todas las actividades previas a la respuesta. ¡La MTTA es la única actividad controlada por el Equipo de Respuesta a Incidentes! La resolución de incidentes es un comodín, ya que tu entorno operativo es complejo y las condiciones del incidente pueden cambiar en cualquier momento. Lo diremos de nuevo para enfatizarlo, ¡la MTTA es la única actividad que controla el Equipo de Respuesta a Incidentes!

Las respuestas que encuentres utilizando PROCESS como plantilla de evaluación diferirán de una empresa a otra, porque no existe un enfoque de libro de cocina. Se trata más bien de un ejercicio de reflexión que puedes utilizar para explorar y mapear los distintos aspectos de un Equipo de Respuesta a Incidentes basado en PROCESS, y para descubrir y corregir cualquier punto débil de tu sistema por el camino.

Previsible

La base de unos Equipos de Respuesta a Incidentes excelentes es la previsibilidad. Los clientes compran y esperan disponibilidad 7×24×365 de sus proveedores de servicios. Sabemos que una disponibilidad del 100% es una métrica casi imposible, por lo que las empresas aspiran a un 99,99% o más. De hecho, se hacen enormes inversiones con cada 9 incremental a la derecha del punto decimal de disponibilidad, mejorando del 99,99% al 99,999%. Así que, si la disponibilidad definitiva es esquiva en los entornos de producción, la previsibilidad en la respuesta a incidentes es absolutamente esencial.

La previsibilidad en la respuesta a incidentes tiene que ver con la claridad de funciones y responsabilidades y con el comportamiento esperado de cada persona antes y después de reunirse para un incidente. Se trata de eliminar la incertidumbre en la fase de montaje de la respuesta. ¿Existen expectativas claras sobre qué PYMES pueden ser necesarias para un determinado tipo de incidente, y quién asumirá el papel de liderazgo del Comandante del Incidente? Los Equipos de Respuesta a Incidentes eficaces, por grandes o pequeños que sean, tienen procedimientos de guardia claros y bien definidos, ¡y hacen que la gente rinda cuentas!

¿Tus expertos técnicos están de guardia en zonas horarias diferentes? ¿Hay refuerzos para el personal de guardia principal? ¿Tienen claro que "de guardia" significa estar preparado para responder a una llamada, texto u otra notificación en un plazo de tiempo especificado por la empresa?

Hacer que los intervinientes comprendan su papel es fundamental para el éxito. La respuesta a incidentes no consiste en llegar para ayudar a resolver el problema cuando sea conveniente. Si te identifican como disponible de guardia, no es opcional. Tal vez tu trabajo habitual te tenga muy ocupado todos los días. Si estás de servicio o de guardia como interviniente identificado en un incidente, asegúrate de que estás preparado para responder rápidamente. Estate preparado, dispuesto y capacitado para responder a la llamada y proteger el negocio.

Garantizar que las expectativas de respuesta están claras es la fruta más fácil de conseguir, porque puede hacerse antes de que se produzca el incidente. Identificar a los actores, o al menos el tipo de actores que podrías necesitar, es un ejercicio de planificación previa y puede ser en gran medida guionizado en un plan de respuesta definido y evaluado/afinado como parte del AAR. Piensa en tus últimos 10 incidentes y evalúa la MTTA en términos de hacer llegar a las personas adecuadas a la respuesta. ¿Conseguiste que las personas adecuadas respondieran rápidamente y con sentido de la urgencia? ¿Actuaron y participaron de forma positiva? Si no, ¿por qué no? Piensa en la previsibilidad como la parte "quién" de la respuesta.

Repetible

Si hay incertidumbre sobre quién responderá a un incidente y quién estará al mando, y sobre cómo reunirlos para una respuesta, entonces tu respuesta a incidentes puede mejorar.

La repetibilidad es la parte del "cómo" de la respuesta, con el objetivo de enviar de forma coherente y eficiente a las personas identificadas en la sección de previsibilidad. Los Equipos de Respuesta a Incidentes altamente eficientes han revisado una lista de tipos de incidentes comunes o probables, han asignado a cada uno un nivel de gravedad (SEV), han identificado a las PYMES por función para responder y han hecho coincidir el envío de respondedores PYMES con esos niveles de gravedad. Por ejemplo, un nivel SEV 1 puede tener una lista predeterminada de expertos técnicos (red, informática, almacenamiento, aplicaciones) que serían apropiados para un tipo de incidente concreto. Cada organización es diferente, así que no vamos a dar ejemplos concretos. Baste decir que la identificación oportuna de un incidente informático, que impulsa un procedimiento de envío rápido y específico con expectativas claras sobre cuándo y cómo se reunirá el personal de respuesta al incidente (cuanto más rápido, mejor) es la piedra angular de la previsibilidad. La repetibilidad demuestra que toda respuesta a cualquier tipo de incidente debe esforzarse por ser la misma, independientemente de la hora del día, el día de la semana o la época del año en que se produzca. Por ejemplo, las respuestas previsibles y repetibles deben producirse de la misma manera a las 2 de la mañana de Navidad o a las 2 de la tarde de cualquier día laborable normal. ¡La previsibilidad y la repetibilidad son el enemigo natural del rociar y rezar!

Esto no quiere decir que una organización deba tener operaciones 24x7 para poder tener una respuesta demostrablemente repetible. Se trata más bien de que el personal de respuesta a incidentes esté realmente disponible cuando se le designe para estar de guardia y responda siempre de la misma manera.

Optimizado

La optimización se basa en un mecanismo de respuesta a incidentes predecible y repetible, garantizando que los intervinientes identificados comprenden las reglas de actuación durante los incidentes y están formados, equipados y claramente preparados para hacer lo que se les pide. ¿Tienes un programa de formación formal para los intervinientes (¡y esperamos que esté basado en IMS!)? ¿Se imparte de forma coherente en todo tu equipo, especialmente si el equipo es global? ¿Comprende todo el mundo cómo encaja en la respuesta a incidentes? ¿Existen políticas claras de escalado? ¿Qué condiciones deben darse para desencadenar una escalada? ¿A quién corresponde la escalada?

Escalada: La adición de más o diferentes recursos (PYMES, equipos, proveedores externos, etc.), más allá de un envío inicial, necesarios para resolver un incidente. Por ejemplo, el CI puede necesitar más o diferentes administradores de bases de datos (DBA) en un incidente, por lo que el CI debe escalar a esos recursos adicionales. Escalar también puede significar notificar o ponerse en contacto de otro modo con las partes interesadas internas de la empresa a un nivel superior al del CI. Esto podría incluir escalar un incidente a los ejecutivos de la empresa.

Si interactúas con proveedores u otros terceros, ¿saben cómo responder y participar? ¿Comparten tu mismo sentido de la urgencia? ¿Se entiende y aplica universalmente el concepto de mando en caso de incidente?

Es fácil detectar a las personas que simplemente "no lo entienden" en cuanto a tener el sentido de urgencia y la concentración necesarios para resolver un incidente, o que se sienten molestas por estar de guardia en primer lugar. Sin embargo, ¿se les explicó la importancia del plan de respuesta a incidentes? ¿Recibieron formación sobre sus funciones individuales y de equipo en la respuesta a incidentes? La respuesta a incidentes es un deporte de equipo, y no deja lugar a egos, actitudes o falta de confianza dentro del equipo. Es importante responsabilizar a las personas, pero es injusto si se les responsabiliza sin haber recibido nunca formación o información sobre las expectativas de la empresa. En nuestra práctica de consultoría, hacemos hincapié en la necesidad de identificar a todos los posibles Comandantes de Incidentes, expertos técnicos de PYMES, ejecutivos, proveedores y cualquier otra persona que pueda ser llamada a responder. Esto nos permite asegurarnos de que todos ellos tienen formación específica en respuesta a incidentes y una comprensión clara de las expectativas, de modo que, como mínimo, cada interviniente en un incidente sepa lo que se espera de él y esté preparado para contribuir adecuadamente. La previsibilidad es el quién y la repetibilidad es el cómo de la respuesta a incidentes. La optimización es la parte del PROCESO en la que debes asegurarte de que todo el mundo está formado y equipado para hacer el trabajo.

Claro

La claridad garantiza que las metas y objetivos programáticos generales y de respuesta a incidentes se transmitan a todos los miembros del IRT y a todos los demás que puedan participar en una respuesta. Es fácil suponer que todos los que puedan unirse a una respuesta a incidentes en cualquier capacidad tienen claras las metas y objetivos del esfuerzo de resolución de incidentes. Por desgracia, no siempre es así. A menudo, descubrimos que los responsables de TI no tienen claro por qué se les pone de guardia o se les pide que se unan a un puente de conferencias telefónicas sobre incidentes. Oímos esto con frecuencia cuando escuchamos puentes grabados para nuestros clientes. Un experto técnico se une y pregunta: "¿por qué estoy aquí?" o "¿para qué me necesitáis?". Se produce alguna discusión para que el experto se oriente sobre el hecho de que se le ha llamado para ayudar a resolver un incidente informático. Se pierde un tiempo valioso que nunca puede recuperarse. Para ello, es fundamental asegurarse de que cualquiera que pueda ser llamado a responder sepa exactamente por qué se le convoca, cuál será su papel y cuándo será liberado del incidente por el CI.

Este establecimiento de expectativas comienza en la cúspide del organigrama de la empresa. Es fundamental que los ejecutivos marquen la pauta para crear y apoyar la respuesta a incidentes, valorando el esfuerzo, tanto dentro del IRT como en toda la empresa. Los ejecutivos deben esforzarse por crear una cultura de respuesta a incidentes, garantizando la previsibilidad, la repetibilidad y la optimización del equipo. De nuevo, parece sencillo, pero es vital que todos los intervinientes sepan y comprendan lo que se espera de ellos cuando se les pide que respondan, y que se garantice la coherencia del incidente con la que responde el equipo. Para que la respuesta a incidentes tenga éxito, este proceso de reflexión y apoyo debe estar imbricado en la cultura de la empresa. La naturaleza del incidente informático puede variar y variará, pero el planteamiento de respuesta al incidente debe ser claro y coherente.

¿Comprenden realmente todos los intervinientes que, en esencia, funcionan como el cuerpo de bomberos de la empresa? Oímos muchas referencias relacionadas con el cuerpo de bomberos por parte de ingenieros de fiabilidad, PYMES y ejecutivos. Como ejemplo, el uso de la palabra triaje es habitual en TI. Su origen es un término médico común de urgencias, que significa clasificar y asignar prioridades durante un incidente con muchas víctimas. La primera persona que responde a un problema de TI es, literalmente, un primer interviniente. Como el problema puede convertirse en un incidente, la respuesta también debe escalar, como un incendio que escala a una segunda, tercera o cuarta alarma. Lo extraño es que muchos intervinientes no ven la conexión entre el interviniente de seguridad pública y el interviniente de TI, ni sienten la responsabilidad que ello conlleva. "Estamos tan ocupados apagando incendios", dijo un ingeniero, "que no encuentro tiempo para hacer mi trabajo diario". Dicho de otro modo, mientras el resto de la empresa construye el negocio, los intervinientes deben defenderlo de cualquier daño.

Piensa en el punto de la claridad de este modo: no es necesario que todos pensemos del mismo modo durante una respuesta, pero debemos pensar en la misma dirección con el mismo punto de vista, unidad de propósito, metodología y enfoque.

Evaluado

Hasta este punto, el énfasis se ha puesto en poner las piezas en su sitio para crear un excelente programa de respuesta a incidentes. Hablaremos del proceso AAR en el Capítulo 6, pero por ahora comprende que cada respuesta a un incidente crea una oportunidad para aprender a responder mejor al siguiente. Como hemos oído en la gestión de incidentes a lo largo de los años, "¡no dejes que una buena crisis se desperdicie!". Dedicar tiempo y esfuerzo a examinar objetiva y específicamente cada parte del Ciclo de Vida del Incidente, desde la detección de un problema, el envío de los intervinientes y la reunión del Equipo de Respuesta a Incidentes, hasta cómo se resolvió finalmente el incidente, ofrecerá con toda seguridad lecciones aprendidas o áreas que podrían mejorarse. La parte de la evaluación es donde los esfuerzos de garantía de calidad (GC) y mejora de la calidad (MC) se vinculan al PROCESO.

Garantía de calidad (GC)

Observar objetivamente un comportamiento, una decisión o una circunstancia y evaluarla con respecto a la norma establecida, asegurándose de que se está produciendo el comportamiento esperado.

Mejora de la calidad (MC)

Encontrar oportunidades, puntos débiles o piezas que faltan en el mecanismo de respuesta a incidentes y tomar medidas para corregir/mejorar la deficiencia.

La GC y la IC son inversiones que producen dividendos a largo plazo. Ajustar el proceso de respuesta a incidentes, la forma en que los expertos técnicos resolvieron el incidente y/o la capacidad de liderazgo del Comandante de Incidentes puede descubrir puntos débiles que están obstaculizando tu búsqueda de un rendimiento excelente. Se está trabajando mucho en el ámbito de las "autopsias sin culpa" y aplaudimos esos esfuerzos. Los entornos informáticos actuales son grandes y complejos. No es posible prever todos los casos de uso ni probar la configuración para un funcionamiento impecable con todos los demás elementos de la pila. Los incidentes también presentan la oportunidad de encontrar y corregir defectos. Creemos una cultura de aprendizaje en la que la información sobre incidentes se utilice para mejorar las operaciones. Se trata de mejorar, ¡no de encontrar defectos ni de culpar a nadie!

Cuando descubras "minas terrestres" de actuación deficiente o incoherente, debes identificarlas, reconocerlas y hacer lo necesario para mejorar la deficiencia. En ausencia de una forma meditada de evaluar objetivamente el proceso de respuesta a incidentes, una actuación deficiente puede convertirse en la norma establecida y, culturalmente, será más difícil cambiarla en el futuro.

Escalable

Una característica poderosa del SGI es que funciona tanto para la más pequeña empresa de nueva creación con unos pocos empleados, como para las mayores empresas con operaciones en todo el mundo. La parte escalable del proceso está relacionada con la previsibilidad y la repetibilidad, en el sentido de que un proceso sólido de respuesta a incidentes puede crecer o reducirse rápidamente en función de las necesidades del incidente o del crecimiento de la organización. Esto último se refiere a la escalabilidad a nivel de programa más que a nivel de incidente, pero a medida que crece la organización, crece también la necesidad de un conjunto de recursos más amplio y profundo. Nos referimos a esto como fuerza de banquillo. La fuerza del banquillo es muy parecida a la forma en que los equipos deportivos ven la escalabilidad: tener acceso a una amplia variedad de talentos igualmente buenos para llenar los huecos de rotación, descanso o sustitución de los jugadores mientras dure el partido. Por ejemplo, a medida que una empresa crece, es probable que también crezca el número de incidencias, y la empresa necesitará más personas cualificadas para dirigir las operaciones de producción y las incidencias. La fuerza del banquillo contribuye a la naturaleza escalable y sostenible de PROCESS.

Para TI, es importante tener en cuenta las vacaciones, las bajas por enfermedad, los desplazamientos, la cobertura de turnos, etc., para mantener un alto nivel de competencia y disponibilidad del personal de respuesta a incidentes en todo momento. Puesto que no se sabe cuándo puede producirse el siguiente incidente grave, el proceso de respuesta a incidentes informáticos debe estar siempre preparado, como un cuerpo de bomberos. Un equipo con un buen banquillo no sólo tiene un puñado de jugadores estrella. Está formado por un cuadro de talentos que pueden intercambiarse, añadirse o ampliarse para satisfacer cualquier necesidad que surja. Hemos visto cómo los entornos de nuestros clientes se hacían más grandes y complejos, combinando el escalado de la planificación de la capacidad para la demanda futura con programas de actualización tecnológica, todo ello a la velocidad de los lanzamientos continuos de código. En consecuencia, estos entornos fallan más y requerirán esfuerzos de gestión de incidencias más centrados a medida que pase el tiempo.

Lo ideal es que el Equipo de Respuesta a Incidentes establezca su identidad y los recursos disponibles por función, de modo que no dependa sólo de un puñado de personas para responder con regularidad. Muchos entornos informáticos son ya tan complejos que se necesita una constelación de conocimientos técnicos específicos para comprender todos los diversos detalles operativos. Es bastante habitual que se necesiten equipos enteros de desarrollo, equipos de aplicaciones y expertos en bases de datos/almacenamiento/redes para resolver un solo incidente informático. Con la escala y la complejidad vienen aún más especialización y la necesidad de gestionar un mayor volumen y complejidad de incidentes informáticos, que posiblemente se produzcan simultáneamente. Por tanto, ser capaz de enviar y obtener rápidamente un mayor número de expertos técnicos variados y altamente cualificados, posiblemente de todo el mundo, ayudará a crear una cultura de respuesta eficaz en la organización.

Sostenible

Si el equipo de ventas necesita crecer, pierde talento o necesita ajustar la estrategia en función de un cambio en la dirección o la filosofía del negocio, la empresa aborda esas cuestiones rápidamente contratando a más gente o reorganizándose para evitar el riesgo de pérdidas financieras. Cuando la respuesta a incidentes supera el punto de la formación inicial y se convierte en una actividad formal dentro de una organización, ésta debe ver, cuidar y valorar al Equipo de Respuesta a Incidentes como a cualquier otra unidad empresarial.

Sostenibilidad significa que la respuesta a incidentes es, de hecho, tan valiosa como cualquier otra unidad de negocio, y merece la misma cantidad de compromiso financiero, liderazgo ejecutivo y desarrollo organizativo. La respuesta a incidentes en el ámbito de las TI no debe considerarse un mal necesario, como hemos visto en muchas organizaciones. Estar de guardia para responder debe ser respetado dentro de la organización, con la intención de atraer talento impresionante y cualificado. El deber de respuesta a incidentes es doloroso a veces -a nadie le gusta levantarse en mitad de la noche de forma habitual-, pero este inconveniente es fundamental para la salud financiera y el bienestar de la empresa.

Decimos todo esto para subrayar este punto de sostenibilidad. Pocos en el negocio de la respuesta a incidentes informáticos recibieron formación formal para convertirse en respondedores a incidentes. Más bien, la habilidad técnica individual o el conocimiento único de un entorno operativo les lleva inadvertidamente a la "punta de la lanza" en la respuesta a incidentes. Como una persona puede ser un gran ingeniero, puede ser asignada al Equipo de Respuesta a Incidentes. Operaciones, y en concreto la respuesta a incidentes como parte de las operaciones, es el lugar donde se cruzan la tecnología y los fallos, y el proceso de resolución de incidentes debe ser eficaz para que la empresa siga funcionando. Para ello, es habitual coger grandes talentos técnicos y atornillarlos a la formación en respuesta a incidentes, ungiendo así a la persona como respondedor a incidentes, esté o no capacitada para la tarea. Muchas veces, este enfoque funciona bien y las personas pasan sin problemas de experto técnico a experto técnico en respuesta a incidentes, que no son necesariamente lo mismo. Pero muchas veces, simplemente no funciona.

Una vez más, establecer la cultura de respuesta formalizada a los incidentes y cuidar del equipo con apoyo, liderazgo y compromiso financiero hará que atraer y mantener a grandes talentos sea una tarea mucho más fácil.

Resumen

El objetivo de toda empresa es crecer y crear valor. Cada empleado tiene una función y la mayoría dedica su tiempo a construir el negocio. Los responsables de la respuesta a incidentes protegen a la empresa de los riesgos asociados a las interrupciones y cortes del servicio. La respuesta a incidentes informáticos es un campo especializado por derecho propio y debe valorarse por su contribución al bienestar financiero a largo plazo de la empresa. El primer paso para crear un equipo de gestión de incidentes con éxito es realizar una evaluación honesta del status quo. La siguiente lista de puntos y conceptos clave es una destilación del PROCESO en un formato fácil de digerir:

• PROCESO es un acrónimo que puedes utilizar como herramienta de evaluación programática. Utilizar cada punto para guiar un debate sobre los diversos aspectos de tu proceso de respuesta a incidentes puede proporcionarte ideas sobre áreas que puedes mejorar.

• No debería haber ninguna duda sobre quién está disponible para responder y quién está disponible en la reserva de talento de respuesta a incidentes.

• Deberías poder responder de la misma manera, cada minuto de cada hora laborable.

• Los miembros del equipo deben estar formados, equipados y preparados para hacer el trabajo que la empresa les pide que hagan.

• Todos los miembros del Equipo de Respuesta a Incidentes deben saber exactamente qué se espera de ellos, cuál es su papel, qué margen tienen para tomar decisiones sobre un incidente, y saber que cuentan con el apoyo de la dirección ejecutiva para resolver los incidentes con el fin de proteger la empresa.

• Un buen proceso de respuesta a incidentes puede ampliarse y reducirse rápidamente para adaptarse a las necesidades del incidente.

• Los programas de respuesta a incidentes de éxito se construyen para ser sostenibles en términos de contratación y retención de los mejores talentos.

• Una organización debe crear y mantener una cultura de respuesta a incidentes y considerarla tan importante como cualquier otra unidad empresarial.

• Hay una diferencia entre suceso, alerta, incidente, envío y notificación. Si tu empresa no ha dejado esto muy claro a todos los intervinientes y a toda la empresa, te sugerimos que lo hagas. Nos encontramos con muchas empresas que no lo han hecho y eso crea confusión durante el proceso de reunir al equipo adecuado en el momento adecuado para hacer las cosas adecuadas.