Aprovechando que me he leído el libro What is DevOps? (un e-book que, por cierto, es gratuito), voy a explicaros un poco de qué va el tema.
La idea principal del DevOps es la fusión del departamento de sistemas con el departamento de desarrollo. ¿Por qué? Pues porque la división de estos dos departamentos hace que sus miembros se vean como “enemigos”. Digamos que el objetivo del trabajo del departamento de sistemas es el mantener la aplicación funcionando, mientras que el objetivo del trabajo del departamento de desarrollo es (simplificando) añadir nuevas funcionalidades a la aplicación. El problema es que esas nuevas funcionalidades suelen ser vistas por el departamento de sistemas como potenciales desestabilizadores de la aplicación, es decir como más trabajo, por lo que sistemas intentará retrasar al máximo el despliegue en producción de esas nuevas funcionalidades (ha de pasar un tiempo en el entorno de test), lo que será percibido por desarrollo como un menosprecio o amenaza a su trabajo y ya tenemos montado el mal rollo dentro de la empresa.
Lo que propone DevOps es que uniendo ambos departamentos no sólo consigues una mayor harmonía dentro del departamento de IT, si no que consigues una mayor eficiencia a la hora de resolver incidencias. Por ejemplo, desarrollando la parte de logs ¿Cuántos de nosotros ha tenido un problema con una aplicación, ha ido a echarle un ojo al log y ver un galimatías que es incapaz de entender (no entremos cuando vemos el chorro de excepciones no capturadas tan típicas de una aplicación Java)? ¿Por qué? Pues por que el que ha programado la aplicación no sabe que información necesita sistemas, el es de desarrollo y pondrá la información que le resultaría útil a él o ella. Y no por ánimo de joder al pobre sysadmin a media hora de acabar su turno, si no simplemente porque no es consciente de lo que necesita el sysadmin.
Otra de las cosas interesantes que comentan, es hacer que la aplicación se “autoadministre”. Dado que sistemas ahora participa en el desarrollo, se puede añadir código que gestione las típicas incidencias que se resuelven reiniciando un demonio (¿a que jode una alerta a las tres de la mañana para, simplemente, reiniciar un Apache y que ya no te vuelva el sueño?). Hacer la aplicación más resiliente se le llama a esto. Si a esto le sumamos la aparición del IaaS (AWS, Rackspace, CloudBuilder, etc.) podemos hacer que la propia aplicación levante más frontales web cuando lo necesite, o pare un esclavo de base de datos y levante otro porque había fallos con la replicación de forma totalmente automática. Obviamente esto haría mucho más agradable el trabajo del sysadmin de guardia, que sólo sería despertado para incidencias gordas e interesantes, no para chorradas.
La verdad que es una idea que me parece interesante y creo que el futuro de sistemas a por ese camino, al menos en entornos web.
PD: Ya sabéis empresas web que estéis interesadas en un sysadmin molón y que sepa de qué va el rollo DevOps os invito a visitar mi perfil de LinkedIn. 
).
