De “Oops” a “Ops”

“Oops”: la expresión que viene a tu mente cuando recibes la noticia de que ninguno de los usuarios en el país pueden ingresar a la aplicación luego del cambio que realizaste días atrás.

Si tienes suerte, la noticia llega durante el día en la semana laboral. Pero, que pasa cuando: ¿recibes llamadas similares a las 3:26 am por caídas en Producción?¿Cuando debes interrumpir tu festejo de año nuevo para resolver dicha situación?¿Cuando pierdes la fiesta de cumpleaños de tu hij@ por ese tipo de problemas en los sistemas?

Siendo un apasionado por la tecnología, siempre me gustó jugar con ésta a través de las herramientas que tenía a mi alcanze. Pero, ¿qué pasa cuando las herramientas empiezan a jugar con nuestras vidas?

“Somos nosotros quienes moldean a nuestras herramientas. Luego, nuestras herramientas son quienes nos moldean.” — J. Culkin (1967).

Para comprobar este aforismo, basta con bajar el smartphone y observar alrededor.

(Interludio para permitir que guardes el smartphone📱 y observes alrededor 👁.

…Fin del interludio)

Bueno, basta de hechar lleña a la fuego. Es momento de retomar el control de la situación, de re-humanizar la labor tecnológica y empezar a realizar “Ops” (Operaciones) en los ambientes de Producción con astucia y proactividad. El objetivo es el de mejorar la calidad de vida de los humanos que mantienen estos ambientes para así mejorar los sistemas mismos en consecuencia.

Revisemos dos tácticas para alcanzar este objetivo:

Visualiza el Trabajo

A diferencia de la Era Industrial donde los procesos y productos eran tangibles, actualmente trabajamos con los intangibles ceros y unos. Visualizarlos de alguna manera es obligatorio tanto si tu equipo esta compuesto por un@ o por varias personas.

En “The Phoenix Project”, los autores clasifican el trabajo en cuatro tipos:

1. Proyectos de Negocio. Proyectos planificados y ejecutados que impactarán (espero positivamente) al negocio. Ej: deployment de un nuevo website en Producción, utilización de Inteligencia Artificial para el Soporte a Clientes o aprovisionamiento de infraestructura para nuevos usuarios.
2. Proyectos de IT (Information Technology). Cualquier implementación inicial para promover la productividad/remover obstáculos de los miembros de la empresa. Por ejemplo: creación de ambientes de desarrollo, implementación de tuberías de CI\CD y creación de monitores de performance.
3. Cambios. Siempre existen requerimientos para modificaciones a cualquiera de las implementaciones de los anteriores dos tipos de trabajo. A estos los llamamos Cambios. Por ejemplo: habilitar puertos diferentes al nuevo website que fue desplegado en Producción, añadir un nuevo paso las tuberías de CI\CD o agregar nuevas métrica a los monitores de performance.
4. Trabajo No Planeado. Cualquier tipo de emergencia, imprevisto o solicitud que no pueda ser colocada en la cola de tareas (Backlog) a realizarse en un futuro cercano (si practicas Metodologías Ágiles, nos referimos al siguiente Sprint). En este tipo hablamos de la situación conocida como “¡deja lo que estés haciendo y ponte a solucionar el problema!”🔥⚠🔥️️.

Bueno, ya los conoces y de seguro tienes una idea de la proporción que realizas de ellos en el día a día.

Ahora, para visualizarlos utilizaremos un Kanban Board. Al colocar todas las tareas que realizas en este tablero, empezarás a descubrir patrones. Precaución: cuando dije todas las tareas, me refería a T-O-D-A-S. La disciplina inicial es extremandamente importante para adquirir el hábito de registrar las tareas que tu equipo desempeña.

Kanban Board — Identificando “Trabajo No Planeado”

Por experiencia puedo predecir que encontrarás Trabajo No Planeado que se repite a lo largo de varias semanas y en muchos casos corresponde a la clase de situaciones que te despiertan a media noche. Cuando hayas identificado dichas situaciones, es tiempo de crear un Proyecto de IT para liquidarlas. #hastaLaVista#unplannedWork

Pruebas de Antifragilidad

Tal vez estés en desacuerdo pero, considero que la Gestión de Incidentes es para aquellos que llegan a la fiesta cuando esta ya terminó. En otras palabras, la Gestión de Incidentes trata de lidiar con un imprevisto, no con la forma de prevenirlo.

Recuerda: la mala fortuna te golpeará tarde o temprano. Sé inteligente y golpéate primero. Sí...dije “golpéate” primero. Las Pruebas de Antifragilidad, también conocidas como Ingeniería del Caos, son la forma proactiva de minimizar el impacto de los imprevistos. De esta manera eres tú quien prueba cuan fuerte eres en lugar de esperar que la Diosa de la Mala Fortuna (o La Ley de Murphy) te ponga a prueba.

De manera similar a los científicos quienes conducen experimentos para aprender sobre fenómenos físicos y sociales , la Ingeniería del Caos utiliza experimentos para aprender acerca de un sistema en particular. — (Basiri, Jones, Blohowiak, Hochstein and Rosenthal (2017). Chaos Engineering. Chapter 2).

En pocas palabras hablamos de validar empíricamente la resiliencia de tus sistemas en Producción. Para esto, es necesario definir inicialmente lo que significa un ”Estado Estable”. Tras lo cual, correremos los experimentos controlados con el objetivo de recolectar información acerca de las causas que producen que el sistema se desvíe de dicho estado. Algunos ejemplos de esta clase de experimentos son:

• Dado el escenario donde tienes cinco servidores para balancear la carga de peticiones de los usuarios, simula el escenario donde hubo malfuncionamiento en uno de ellos y apágalo por una hora. (Chaos Monkey es una herramienta open source utilizada en Netflix para realizar esta simulación).
• En una temporada baja de utilización del sistema, recurre a automatización para simular la carga e incrementarla paulatinamente para así aprender cual es el límite que es posible soportar sin dejar el Estado Estable. Este experimento es básicamente un Test de Performance, sin embargo, el obtener la información y actuar proactivamente (por ejemplo implementando Grupos de Auto-escalamiento) lo convierte en una estrategia de resiliencia.

Si estas seguro que el ejecutar alguno de estos experimentos llevará al sistema a un problema obvio, entonces no vale la pena ejecutarlo. Primero implementa la mitigación y luego ejecuta el experimento.

Después de una más de una acelerada década trabajando en tecnología aprendí que:

• Tener que resolver los mismos problemas a diario no es “trabajo”, es falta de sentido común.
• Vivir en constante estrés no es heroico, es suicida.
• No existe dinero suficiente o posiciones de estatus corporativo elevadas que pueda retornar momentos perdidos.

Trabajar inteligentemente significa retomar el mando de nuestros juguetes tecnológicos para así retomar el control de nuestras vidas.

Keep on learning and doing great Ops!

Como siempre, por favor déjame tu feedback en un comentario en este artículo. ¿Te fue útil?¿Qué aumentarías o quitarías?¿Otras sugerencias? También puedes enviarme un tweet a @jjruescas1 y colocar #DevOps al final para poder encontrarlo.🙂

¿Deseas conocer más sobre DevOps? No olvides revisar el curso “DevOps — Las Artes Marciales del Software” en Udemy.com.