Devops

Me encontré un post de Stephen Nelson-Smith en el blog de Patrick Debois acerca del concepto devops (Development+Operations) que postula que en el software empresarial se ha borrado la línea que dividía el desarrollo de las operaciones. Incluso las metodologías ágiles con sprints quincenales se han demostrado insuficientemente rápidas, en mi experiencia, para seguir el ritmo de cambios que demandan las compañías que hacen un uso intensivo de tecnología informática.
Hacer un pase a producción todos los días suena a locura, pero no está muy alejajdo de lo que sucede en la práctica muchas veces. Y ya sé que saldrá el purista de turno a contar que en su consultora han educado al cliente a tal y cual y que ellos lo hacen todo de forma eficiente ordenada y militar y que son muy buenos con tal metodología ¡ra, ra, rá! Y a lo mejor a ellos que son consultores externos hasta es verdad que las operaciones diarias les afectan menos, pero la cruda realidad diaria de un departamente de informática es que se trata de la puta jungla.
Algunas claves que da Nelson-Smith acerca de cómo gestionar las devops son realmente dignas de tener en cuenta.
1) Hay que difuminar la distinción en programadores y administradores de sistemas.
No es para nada ninguna novedad que la calidad final de un software depende casi exclusivamente de la calidad de la mano de obra empleada para escribirlo. El gran experto en Scrum Ángel Medinilla escribía hace poco afirmando que la consultoría se cultiva como un producto gourmet. Las devops requieren de mano de obra que, además de poseer profundos conocimientos de programación dominen igualmente la gestión de bases de datos y la administración de sistemas. Si el programador no tiene experiencia en administración de sistemas se produce el clásico efecto “en mi PC funciona” derivado de que el que escribió el software no cayó en la cuenta de que el formato de fechas por defecto MM/DD/YYYY en el servidor cuyo sistemo operativo está en inglés es diferente del de su Windows 7 en español DD/MM/AAAA.
2) El procedimiento de paso a producción debe ser plenamente seguro.
Debe existir un procedimiento operativo para pasar cosas de desarrollo a produccion que esté automatizado y sea 100% seguro frente a cosas como librerías que existen en la máquina del desarrollador pero no en la de producción, etc.
3) El código se debe escribir en “modo bug free”.
Microsoft lleva muchos años premiando a programadores que son capaces de escribir código que según sale del horno está libre de defectos software. Se sabe que el coste económico de arreglar un bug crece de forma descomunal a medida que el programa avanza en la cadena de producción desde el laboratorio de I+D hasta el usuario final. Lo mismo que el programador debe ser sysdamin debe ser también su propio tester riguroso, principalmente porque haciendo devops no da tiempo de pasar cada pequeño cambio por todo el ciclo de pruebas antes de pasarlo a producción.
4) Hay que empezar por el mínimo producto viable
En su libro magistral The design and evolution of C++ Bjarne Stroustrup afirma que «un sistema grande y complejo que no ha evolucionado a partir de otro más pequeño no funciona y, además, es imposible arreglarlo para que funcione«.
5) El diseño debe estar pensado para poder crecer en pequeños trozos
Como el producto empieza siendo muy pequeño, habrá que ampliarlo muchas veces. Es preciso que el crecimiento esté muy bien planificado para evitar que el código se convierta rápidamente en spaghetti. Si bien la codificación inicial debe ser la mínima posible el diseño debe ser muy ambicioso y, en particular, debe ser lo menos acoplado posible de manera que se puedan introducir cambios en un subsistema sin afectar a otros. Esto implica tomar una gran cantidad de decisiones de diseño estratégicas a priori eligiendo entre simplicidad vs. potencia. Muchos arquitectos de software tienen tendencia a diseñar aplicaciones que son como un arco romano donde cada pieza sujeta a las demás, el arco romano fue un gran invento para la construcción, pero aplicado al software es nefasto porque si quitas cualquiera de las piedras se te cae todo el tinglado.
6) El sistema debe ser muy fácilmente auditable y depurable
Dado que habrá cambios continuamente, es preciso poder trazas en cada momento lo que ha pasado o lo que está haciendo el programa en cada instante. Aquí el Software Libre es la clave, ya que tener los fuentes es lo único que garantiza que se puede depurar el sistema de verdad.
7) El sistema debe tener resiliencia
Es decir debe poder funcionar aunque se degraden las condiciones del entorno. El último fallo de servicio importante en Facebook se produjo por un error en un parámetro de un fichero de configuración que se propagó. El software reaccionaba al error intentando recargar el fichero y entró en un bucle que produjo una sobrecarga. Moraleja: las piezas pequeñas más aparentemente inocentes como un fichero de propiedades externas son igual de peligrosas que un serpiente venenosa, y el software, además de funcionar bien, deber contener cierto porcentaje de programación defensiva para protegerse frente a ofidios.
8) Debe existir una política de contención de daños
No todos los subsistemas se pueden cambiar todos los dias. Es por eso que el kernel de Linux no lo toca ni Dios, pero los módulos externos se desarrollan en Comunidad. Antes de pasar cualquier cosa a producción hay que intentar determinar qué es lo peor que podría pasar si el nuevo cambio rompe la build. ¿Dejará todo de funcionar? ¿Se borrará la base de datos de clientes? ¿O simplemente los botones que deberían ser grises saldrán en negro?
9) La organización debe aceptar que el software es algo vivo
Como tal crece y evoluciona. Cada día aparecen nuevas funcionalidades, y, por contra, alguna que otra desaparece o deja de funcionar temporalmente. De igual forma los plazos se vuelven algo deslizante, el software no se desarrolla, evoluciona y, como todas las evoluciones su velocidad de cambio y la dirección que tomen pueden ser muy variables en función del entorno.
10) Debe existir un sistema de documentación continua
Si al software se le añaden cosas todos los días, llega un punto en el que evoluciona hasta un punto en el cual nadie sabe realmente cómo se comporta o qué es lo que puede hacer en respuesta a determinados «estímulos». Para aliviar este problema con la «personalidad» del programa, en paralelo al desarrollo hay que crear un sistema de documentación continua «tipo wiki» en el cual se pueda contar rápidamente la historia de los cambios. Tener un estándar de reporting diario puede ser útil, que explique quién hizo qué cambio, cómo y porqué. La documentación debe ser fácil de redactar y fácil de explotar, de nada sirve escribir cosas que nadie sabe dónde están, o que nadie lee, o que aunque las lean no las entienden.

Post relacionado:
Llevando la agilidad y el lean al departamento de sistemas (Javier Garzás)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.