Cinco formas de enfrentar una crisis en el área de Operaciones de TI

Cinco formas de enfrentar una crisis en el área de Operaciones de TI

Los profesionales de Operaciones de TI (IT Ops) desempeñan tres roles críticos en una organización. Son arquitectos, constructores y héroes que salvan el día cuando las cosas van mal. Visualizan y ayudan a planificar entornos digitales, construir la infraestructura en la que se ejecutan esos entornos y corregir las aberraciones antes y después de que los problemas se conviertan en crisis.

Hoy, me gustaría centrarme en la naturaleza de ruptura / corrección de un trabajo de operaciones de TI, específicamente en el caótico negocio de prevenir las crisis de las redes de TI y lidiar con ellas cuando ocurren. Sobre la base de lidiar con los cambios de operaciones de TI en los últimos 15 años, aquí están (IMHO) algunas de las cosas más importantes que los profesionales de TI pueden hacer para resolver el impacto de las crisis cuando se producen y evitarlas antes de que sucedan.

1. ¿Qué cambió?

Muchas (¿la mayoría?) de las crisis ocurren debido a un cambio en el medio ambiente. Al diagnosticar un problema, es útil conocer otros cambios recientes en el entorno. Si no es posible encontrar una causa directa obvia para un problema, tómate un minuto y reflexiona: ¿qué cambió recientemente que podría haber causado este problema? Esto es particularmente útil cuando se resuelve un problema que ocurre en una ubicación remota donde es posible que no se tenga visibilidad de todo lo que sucede.

Si un servidor deja de comunicarse, por ejemplo, los primeros pasos siempre serán verificar el servidor para asegurarse de que no esté colapsado, que los discos duros no estén llenos, que esté conectado a la red, etc. Si no se encuentra la solución en el servidor es hora de ampliar la búsqueda y ver otras cosas que se han cambiado recientemente.

Las conexiones se revelan durante una falla. Verifica el sistema de gestión de proyectos o cambia los registros para ver qué cambios se han producido recientemente en la red. Podría ser que no pueda acceder al servidor porque está detrás de un enrutador, un conmutador o un firewall que se ha configurado incorrectamente. Alguien puede haber borrado accidentalmente el registro DNS del servidor o cambiado una vía del enrutamiento. El problema puede haber ocurrido en otro lugar y estás viendo los síntomas, no la causa.

2. Evita los daños colaterales a partir de la falta de planificación

No hay nada como la sensación de hundimiento provocada por un problema inesperado que ocurre mientras realiza un cambio en otra área. Un ejemplo de daño colateral podría ser cambiar un servidor solo para descubrir que noquea una transferencia nocturna, porque la seguridad de la transferencia está codificada en la identidad del hardware de la máquina y el cambio del hardware cambió la clave de hardware. La clave para luchar contra el daño colateral es identificar todas las funciones relacionadas antes de que ocurra el cambio. Analiza e identifica todas las funciones relacionadas y agrega los pasos de ajuste necesarios al plan de cambio.

3. Usa una lista de verificación para los cambios

En su libro The Checklist Manifesto: How to Get Things Done Right, Atul Gawande habla sobre cómo usar listas de verificación para aumentar la capacidad de entregar información de manera correcta, segura y confiable. Con demasiada frecuencia, los profesionales de Operaciones de IT entran en una situación y realizan un trabajo crítico usando solo memoria, entrenamiento e instinto. Los problemas ocurren cuando realizan pasos fuera de secuencia o saltan pasos. Soy un gran defensor del uso de listas de verificación durante los cambios de la red como una ayuda para asegurar el éxito y evitar las crisis. Una buena lista de verificación lo ayuda a planificar e implementar correctamente estos pasos en el proceso de cambio.

Pasos preparatorios
¿qué debe hacerse antes del cambio? ¿Qué servidores o equipos deben ser derribados o ajustados? ¿Quién necesita ser notificado?

Pasos en el proceso
¿qué pasos se deben realizar durante el cambio? ¿Qué configuraciones necesitan ser modificadas?

Verificación del cambio
¿cómo se determina si el cambio funcionó? ¿Qué artículos debe verificar? ¿Qué datos deberían usarse para la verificación?

Procedimientos de emergencia
¿qué estrategias de mitigación debe usar si las cosas van mal? ¿Cuál es el plan de acción para una crisis?

Pasos de restauración
¿cómo revierte los pasos preparatorios que realizó para implementar el cambio? Prestar atención a este paso puede evitar desencadenar una crisis en otra área.

Las listas de verificación no tienen que ser largas. Simplemente deben ser exhaustivas, precisas y usables. En mi humilde opinión, usar una lista de verificación es crucial para un cambio de red exitoso.

4. Regla “Una cosa a la vez”

Mi regla personal es: solo realizar un cambio importante de red a la vez. Una cosa es que un solo cambio vaya mal y provoque una crisis. Otra cosa es que dos o más cambios fallen al mismo tiempo, creando múltiples crisis. Es tentador realizar múltiples cambios siempre que tenga una parte de la red inactiva pero no lo haga. No vale la pena el riesgo.

5. Saber dónde se encuentra

Con el conocimiento de la ubicación, las heridas autoinflingidas más horribles ocurren cuando un profesional de TI elimina un sistema de producción cuando cree que está trabajando en un sistema de prueba. El ejemplo perfecto es el administrador de TI que, al actualizar una base de datos de control de calidad, borra accidentalmente la base de datos de producción porque está en la máquina equivocada. Estos errores a menudo ocurren cuando se usan programas de Escritorio remoto, donde accidentalmente se conecta a la máquina equivocada. Asegúrate de poner los pasos para asegurarte de que estás en la máquina correcta antes de comenzar a trabajar, incluso si es algo tan simple como realizar un comando de nombre de host. Te agradecerás la primera vez que esto te impida realizar un trabajo en la máquina incorrecta.

Estos consejos son pasos prácticos que no están cubiertos o solo se abordan en las guías de gestión de cambios. Realizar pasos simples como estos puede ayudarte a lidiar con una inesperada crisis de operaciones de TI o prevenir que ocurra una crisis.

Consulta la información original en inglés

Tipos de plataformas low-code

En el siguiente blog analizamos diferentes desafíos que atraviesan las empresas y los tipos de herramientas low-code que pueden ayudarte.

Transformación digital con ayuda de Low-Code

La transformación digital implica muchos desafíos, pero con ayuda de Low-code podemos superar estos problemas y abrir el camino para el cambio

5 consejos para elegir la suite de Gestión de Procesos de Negocio (BPM)

El enfoque de suite de gestión de procesos empresariales ayuda en el ciclo de vida de mejora de procesos como analizamos en este blog.

Plataforma de código abierto low-code, qué es y cuáles son sus ventajas

En el siguiente blog exploramos la definición de las plataformas de código abierto low-code, sus ventajas y desventajas

Plataformas no-code frente a los problemas de TI

Ingresa en nuestro blog para aprender cómo las plataformas no-code ayudan a resolver los problemas en los departamentos de TI

Características de los sistemas de low-code qué los hace mejores

En el siguiente blog hablamos sobre el impacto de los sistemas low-code en el desarrollo de aplicaciones y sus ventajas en los negocios

6 puntos clave para elegir la plataforma RAD adecuada

El siguiente blog analizamos el desarrollo de aplicaciones RAD y las características que debe tener para tu negocio.

No-code: qué es y cómo aplicarlo en el desarrollo sin código

Con la llegada de la programación no-code, diseñar las soluciones que tu empresa necesita es más fácil, descubre cómo lograrlo en este post

Los 6 principales desafíos en adquisiciones que enfrentan las empresas

En este blog analizamos los principales problemas en el área de adquisiciones que enfrentan las empresas de todos los tamaños

7 beneficios de implementar el desarrollo ciudadano

Con el desarrollo ciudadano tu empresa puede eliminar los cuellos de botella y reducir la carga de trabajo de TI. Descubre más en este blog