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:

1. – ¿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.
2. ¿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)
3. ….. ¿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!!»

We are living times where you hear about DevOps everywhere, how the walls should be removed between these two worlds like Development and Operations, but all these speeches are based on the point of view from the developer and the business, but never from the point to view of the Administrator.

We are coming from a time where the operation teams where split on several levels of escalation where each level should be less populated and more skilled than the previous one. So we have a first level with people with basic knowledge that are working 24×7 covering any kind of incident that could happen. In case anything happen they try to solve it with the knowledge (usually more document than knowledge…) and in case something is not working as expected they forward it to a second level with more knowledge about the platform where they are probably an on-call team to handle that and we’re going to have so many levels as wanted. How all of this fit with Devops, CI & CD and so on…? Ok, pretty easy..

Level 1 today doesn’t exists: Monitoring tools, CI & CD and so on, make no needed this first level, because if you could create a document with the steps to do when something wrong happen you are writing code but inside a Document so nobody stops you to deliver an automated tool to do that. So, in plain english, yesterday first level operators are now scripts. But we still need our operation teams, our 24×7 seven service and so on.. for sure, because from time to time (more usually that we’d liked it) something out of the normal happens and that’s need to be managed.

So, automation is never going to replace L2 & L3, so you’re going to need skill people to handle incidents, maybe you could have a smaller team as you automate more process but never you can get rid of the knowledge part, that’s not the point. Here, we can discuss if this team could be the development team or a mix team from both worlds, and that could be right. Any approach is valid with this. So, we’ve implemented all our new fancy CI & CD process, monitoring tools and the platforms seems to be running without any help and support until somethings really strange happen. So, what to do with that people? Of course, teach the skills to be valuable as L2 & L3, so they have to be better operator / system administrator /whatever word you like the most. And how they can do that?

As I said before we are moving from a world where the Operation teams works based on written procedures and they have their imagination limited to look far from its approved protocol, but that’s not anymore the way L2 & L3 works. When you are facing an incident, the procedure is pretty much the same as hunting a bug, or if we escape from the IT world, it’s like to solving a crime. What are the similarities between solving a crime and managing a platform? Ok, let’s enumerate them:

1. – What? — What happened to my system? You start with the consequences of the issue, probably a error log trace, probably another system calling you because you system is unavailable.. Ok, here you have, this is your dead body.
2. When? — When you know something wrong happen, you start to find the root cause, and you start search logs traces to find the first one that generate the problem, even you discard the log traces that are consequences from the first one, and you try to find when everything starting to fail. To do that, you need to seek evidences about the crash and so on.. So now, you are investigating, searching for evidences, talking to witnesses (yeah, your log traces are the most trustworthy witnesses you are going to find, rarely they lied. It’s like they are on the stand in fron the of a judge)
3. ….. And now? How & Why? — And that’s the difficult point, how & why, are the next steps as you do in a bug hunting, but the main difference here, is when the dev team is hunting a bug, they can correlate the evidences they gather on the step two, with the source code they built to know how and why everything goes wrong.. But in you case, as a system administrator you are facing probably a proprietary system or you don’t have access to the code or how to fight it even if it was open source.. and probably you don’t have even access to the source code from the dev team.. So, how do you solve this?

• Ok, probably most of you are thinking something like: Knowing the product and your platform. Being a certificated operator of the product you are managing, know the whole manual from the product, and so on.. And that could be helpful, because that means you know better about how things works at a high level… but.. let’s be clear: Do you ever find in a certification course, or exam or documentation or whatever, so low-level info that could help you to the specific case you are facing.. ? In case the answer to my question is yes, maybe you’re not facing a difficult bug, but a main configuration error..
• So.. what we can do? As the title said: Learn to code. But you are probably thinking, how can be related know to code with hunting a bug when I don’t have access to the code even to take a look? And.. learn to code in what language? on the components that are managed in my platform? in java? in Go? In node.js? In C++? In x86? All of them? Ok… you’re right, maybe the question is not simply learn to code but that’s the idea: Learn to code, learn to design, learn to architect solutions…. Do you want to know why? Ok, let’s see. In my whole career I’ve been working with a lot of different products, different approaches, different paradigms, different base languages, different everything, but all of them share one thing, that all the systems nowadays shared: They are built by people.

Yes, each piece of software, each server, each program, each web page, each everything is built by a person, like you and like me..

If you think that all the products and piece of software are done by genius you are wrong. Are you aware how many software pieces are available? Do you think that exists so many genius all over the world? Of course, they are skilled people and some of them are truly brilliant, and that’s why they usually follow the common sense to architect, design and build their solutions.

And that’s the point we can use to go crack down our case and solve our murder, because with the evidences we have and the ideas of building solution we have to think: Ok, how had I built this if I was the one in charge of this piece of software? And you are going to see that you are right almost every time…

But I’m missing another important point that we leave unanswered before.. Learn to code in which language? In the one you platform are based: If you are managing a OSGi based platform, learn a lot of java development and OSGI development and architecture, you are going to find that all the issues are the same thing.. A dependency between two OSGI modules, and Import-package sentence that should be there.. the other in which someone load the packages or some Export-Package sentence that should be there…

Same thing, if you are running a .NET Desktop application, learn a lot of .NET development and you’ll be skilled enough to don’t need a document to know what to do, because you know how this should be work.. and that is going to lead you to why this is happening.

And with all that questions answered, just only thing is left. You need to put in motion a plan to mitigate or solve the issue, so the issue is never happened again. And with all of than, we filed our arrest order to the incident.

That finally you are at the court part, when you present you’re evidence, your theory about how and why this happened (the motive 😛 ) and you should be able to convince the jury (the customer) beyond a reasonable doubt, and finally you finish with the sentence that you asked for the bug/crash/incident that are the mitigation plan, and you platform is a better world with one less incident walking free.

What we describe here is how to do a post-morten analysis and probably for most of you this is daily stuff you do, but all the times in customers when we work in collaboration with operation team, we notice that they don’t follow this approach, so they are stuck because they don’t have a document which tell us how to do (step by step) in this strange situations.

So, I’d like to finish with a anthem to summarize all of this: When you are facing an incident: “Keep calm, Apply common sense and start reading the log traces!!