Estamos viviendo tiempos en los que se escucha hablar de DevOps en todas partes, cómo se deben eliminar las barreras entre estos dos mundos como Desarrollo y Operaciones, pero todos estos discursos se basan en el punto de vista del desarrollador y del negocio, pero nunca desde el punto de vista del Administrador.
Venimos de una época en la que los equipos de operaciones estaban divididos en varios niveles de escalamiento donde cada nivel debía estar menos poblado y más capacitado que el anterior. Así que tenemos un primer nivel con personas con conocimientos básicos que trabajan 24×7 cubriendo cualquier tipo de incidente que pudiera ocurrir. En caso de que ocurra algo, intentan resolverlo con el conocimiento (generalmente más documento que conocimiento…) y en caso de que algo no funcione como se espera, lo derivan a un segundo nivel con más conocimiento sobre la plataforma donde probablemente sean un equipo de guardia para manejar eso y vamos a tener tantos niveles como se desee. ¿Cómo encaja todo esto con DevOps, CI & CD y demás…? Ok, bastante fácil…
El Nivel 1 hoy en día no existe: Las herramientas de monitoreo, CI & CD y demás, hacen innecesario este primer nivel, porque si puedes crear un documento con los pasos a seguir cuando algo sale mal, estás escribiendo código pero dentro de un Documento, así que nadie te detiene para entregar una herramienta automatizada para hacer eso. Entonces, en inglés sencillo, los operadores de primer nivel de ayer ahora son scripts. Pero todavía necesitamos nuestros equipos de operaciones, nuestro servicio 24×7 y demás… seguro, porque de vez en cuando (más a menudo de lo que nos gustaría) sucede algo fuera de lo normal y eso necesita ser gestionado.
Entonces, la automatización nunca va a reemplazar a L2 & L3, así que vas a necesitar personas capacitadas para manejar incidentes, tal vez podrías tener un equipo más pequeño a medida que automatizas más procesos, pero nunca puedes deshacerte de la parte del conocimiento, ese no es el punto. Aquí, podemos discutir si este equipo podría ser el equipo de desarrollo o un equipo mixto de ambos mundos, y eso podría ser correcto. Cualquier enfoque es válido con esto. Así que, hemos implementado todos nuestros nuevos y elegantes procesos de CI & CD, herramientas de monitoreo y las plataformas parecen estar funcionando sin ninguna ayuda y soporte hasta que algo realmente extraño sucede. Entonces, ¿qué hacer con esa gente? Por supuesto, enseñar las habilidades para ser valiosos como L2 & L3, así que tienen que ser mejores operadores / administradores de sistemas / cualquier palabra que más te guste. ¿Y cómo pueden hacer eso?
Como dije antes, estamos pasando de un mundo donde los equipos de Operaciones trabajan basados en procedimientos escritos y tienen su imaginación limitada para mirar más allá de su protocolo aprobado, pero eso ya no es la forma en que L2 & L3 trabaja. Cuando te enfrentas a un incidente, el procedimiento es bastante similar a cazar un error, o si escapamos del mundo de TI, es como resolver un crimen. ¿Cuáles son las similitudes entre resolver un crimen y gestionar una plataforma? Ok, enumerémoslas:
- – ¿Qué? — ¿Qué le pasó a mi sistema? Comienzas con las consecuencias del problema, probablemente un rastro de error en el registro, probablemente otro sistema llamándote porque tu sistema no está disponible… Ok, aquí lo tienes, este es tu cadáver.
- ¿Cuándo? — Cuando sabes que algo salió mal, comienzas a encontrar la causa raíz, y comienzas a buscar rastros de registros para encontrar el primero que generó el problema, incluso descartas los rastros de registros que son consecuencias del primero, y tratas de encontrar cuándo todo comenzó a fallar. Para hacer eso, necesitas buscar evidencias sobre el fallo y demás… Así que ahora, estás investigando, buscando evidencias, hablando con testigos (sí, tus rastros de registros son los testigos más confiables que vas a encontrar, rara vez mienten. Es como si estuvieran en el estrado frente a un juez)
- ….. ¿Y ahora? ¿Cómo & Por qué? — Y ese es el punto difícil, cómo & por qué, son los siguientes pasos como lo haces en una caza de errores, pero la principal diferencia aquí, es cuando el equipo de desarrollo está cazando un error, pueden correlacionar las evidencias que recopilan en el paso dos, con el código fuente que construyeron para saber cómo y por qué todo salió mal… Pero en tu caso, como administrador de sistemas probablemente te enfrentas a un sistema propietario o no tienes acceso al código o cómo enfrentarlo incluso si fuera de código abierto… y probablemente ni siquiera tienes acceso al código fuente del equipo de desarrollo… Entonces, ¿cómo resuelves esto?
- Ok, probablemente la mayoría de ustedes están pensando algo como: Conocer el producto y tu plataforma. Ser un operador certificado del producto que estás gestionando, conocer todo el manual del producto, y demás… Y eso podría ser útil, porque eso significa que sabes mejor cómo funcionan las cosas a un nivel alto… pero… seamos claros: ¿Alguna vez encontraste en un curso de certificación, o examen o documentación o lo que sea, información de tan bajo nivel que podría ayudarte en el caso específico que estás enfrentando…? En caso de que la respuesta a mi pregunta sea sí, tal vez no estás enfrentando un error difícil, sino un error de configuración principal…
- Entonces… ¿qué podemos hacer? Como dice el título: Aprende a programar. Pero probablemente estás pensando, ¿cómo puede estar relacionado saber programar con cazar un error cuando no tengo acceso al código ni siquiera para echar un vistazo? Y… ¿aprender a programar en qué lenguaje? ¿en los componentes que se gestionan en mi plataforma? ¿en java? ¿en Go? ¿En node.js? ¿En C++? ¿En x86? ¿Todos ellos? Ok… tienes razón, tal vez la pregunta no es simplemente aprender a programar, pero esa es la idea: Aprende a programar, aprende a diseñar, aprende a arquitectar soluciones… ¿Quieres saber por qué? Ok, veamos. En toda mi carrera he estado trabajando con muchos productos diferentes, diferentes enfoques, diferentes paradigmas, diferentes lenguajes base, todo diferente, pero todos comparten una cosa, que todos los sistemas hoy en día comparten: Están construidos por personas.
Sí, cada pieza de software, cada servidor, cada programa, cada página web, cada todo está construido por una persona, como tú y como yo…
Si piensas que todos los productos y piezas de software están hechos por genios, estás equivocado. ¿Eres consciente de cuántas piezas de software están disponibles? ¿Crees que existen tantos genios en todo el mundo? Por supuesto, son personas capacitadas y algunas de ellas son realmente brillantes, y es por eso que generalmente siguen el sentido común para arquitectar, diseñar y construir sus soluciones.
Y ese es el punto que podemos usar para resolver nuestro caso y resolver nuestro asesinato, porque con las evidencias que tenemos y las ideas de construir soluciones, tenemos que pensar: Ok, ¿cómo habría construido esto si yo fuera el encargado de esta pieza de software? Y vas a ver que tienes razón casi todo el tiempo…
Pero me falta otro punto importante que dejamos sin respuesta antes… ¿Aprender a programar en qué lenguaje? En el que tu plataforma está basada: Si estás gestionando una plataforma basada en OSGi, aprende mucho sobre desarrollo en java y desarrollo y arquitectura OSGI, vas a encontrar que todos los problemas son lo mismo… Una dependencia entre dos módulos OSGI, y una sentencia Import-package que debería estar allí… la otra en la que alguien carga los paquetes o alguna sentencia Export-Package que debería estar allí…
Lo mismo, si estás ejecutando una aplicación de escritorio .NET, aprende mucho sobre desarrollo .NET y serás lo suficientemente capacitado para no necesitar un documento para saber qué hacer, porque sabes cómo debería funcionar esto… y eso te llevará a por qué está sucediendo esto.
Y con todas esas preguntas respondidas, solo queda una cosa. Necesitas poner en marcha un plan para mitigar o resolver el problema, para que el problema nunca vuelva a suceder. Y con todo eso, presentamos nuestra orden de arresto al incidente.
Finalmente estás en la parte del juicio, cuando presentas tus evidencias, tu teoría sobre cómo y por qué sucedió esto (el motivo :P) y deberías poder convencer al jurado (el cliente) más allá de una duda razonable, y finalmente terminas con la sentencia que pediste para el error/fallo/incidente que es el plan de mitigación, y tu plataforma es un mundo mejor con un incidente menos caminando libre.
Lo que describimos aquí es cómo hacer un análisis post-mortem y probablemente para la mayoría de ustedes esto es algo diario que hacen, pero todo el tiempo en los clientes cuando trabajamos en colaboración con el equipo de operaciones, notamos que no siguen este enfoque, por lo que están atascados porque no tienen un documento que nos diga cómo hacer (paso a paso) en estas situaciones extrañas.
Así que, me gustaría terminar con un himno para resumir todo esto: Cuando te enfrentas a un incidente: “Mantén la calma, aplica el sentido común y comienza a leer los rastros de registros!!”
