El legendario origen del movimiento DevOps

A pesar de que DevOps es una de las buzzwords que a día de hoy no puede
faltar en cualquier evento de IT que se precie, pocos conocen el origen de
su historia, que resulta muy ilustrativa como contexto para entender mejor
el significado del término.

Para los más curiosos (o los que queráis tener una historia interesante que
contar en el próximo BeerUp), cuenta la leyenda que fue en 2008 en una
convención informal de agilismo cuando un belga presentó y argumentó el
concepto por primera vez, aún sin bautizarlo.

El término «DevOps” como tal se popularizó en 2009, a partir de los

“DevOps Days” celebrados primero en Gante (Bélgica) y luego replicados en
varias ciudades del mundo (a Barcelona llegó en 2013). Damon Edwards,
apóstol del movimiento desde su propia empresa #SimplifyOps, relata en
un corto vídeo la génesis completa.

Así, resulta muy revelador comprobar cómo el movimiento DevOps está

fuertemente ligado desde su origen a las metodologías ágiles de desarrollo
software. Todo comenzó de hecho en la conferencia Agile’08 celebrada en
agosto de ese año en Toronto (Canadá).

Andrew Clay Shafer (creador de Puppet Labs y ahora en Pivotal, la spinoff

de MVware y EMC2 que liberó la base de datos NoSQL Redis), tenía un slot
asignado, pero a su charla sólo había acudido una persona, un belga
llamado Patrick Debois, así que decidió ahorrársela. Asaltado en los pasillos
por ese mismo joven, que había ido a contar su caso de no-éxito
(«Infraestructura Agile y operaciones: ¿cómo de infra-ágil eres?»), y ante su
insistencia, comenzaron a discutir cómo se podría llevar el agilismo al
mundo de la infraestructura y la administración de sistemas.

Patrick había vivido una experiencia muy frustrante en un proyecto para el

ministerio belga de finanzas que ni desarrolladores de software ni

1
administradores de sistemas habían logrado sacar adelante. Animados por
este intercambio de ideas, acordaron crear un grupo en Google para abrir
la discusión a la comunidad, el Agile System Administrators Group.

Un año después, O’Reilly organizaba en junio en San José (California) el

evento Velocity’09, transmitido en streaming. Tras la exposición de la ahora
muy citada “10+ Deploys a Day: Dev and Ops Cooperation at Flickr» por
John Allspaw y Paul Hammond, Patrick se lamentaba en Twitter de no haber
podido asistir en persona.

Entonces Paul Nasrat, responsable del CMS del periódico británico The
Guardian y desde 2010 en Google, respondió a su tuit proponiéndole que
organizara un evento similar en Europa.

Patrick recogió el guante y sólo cuatro meses después estaba convocado su

primer DevOps Day. La repercusión fue enorme, y el hashtag creado para la
ocasión, #DevOps, triunfó en las redes sociales de forma viral, dando
nombre a todo un movimiento.

En lo único que parece disentir Patrick Debois, que actualmente alterna sus
trabajo en la radiotelevisión flamenca con su labor de consultor de su
propia empresa Jedi BVBA, es en la forma de escribirlo: frente a la común
acepción de hacerlo con la doble mayúscula, DevOps, Patrick piensa que
sería más pertinente una sola palabra, Devops; la discusión sigue viva, y una
tercera facción aboga por eliminar las mayúsculas y escribirlo simple y
llanamente como devops.

Ya conoces cómo se fraguó el término y su intrínseca relación con el

agilismo. Pero si no sabes exactamente lo que es, o has leído definiciones
contradictorias que te hacen dudar, no te pierdas nuestro próximo post
sobre lo que es, y sobre todo lo que no es devops.

2
DevOps es uno de los términos más mencionados en el actual entorno de
IT. Normalmente se asocia a estrategias de transformación digital, y a
metodologías como Continuous Delivery o desarrollo ágil.

En un post anterior (El legendario origen del movimiento DevOps),

presentábamos la génesis del término, pero como ocurre con la mayoría de
las buzzwords tecnológicas, es complicado encontrar una definición
canónica, y es frecuente de hecho encontrar usos del término
contradictorios, o flagrantemente incorrectos.

Gran parte de la confusión viene de mezclar lo que es DevOps con los

requisitos necesarios o los beneficios obtenidos al implementar DevOps. Sin
querer ser excesivamente dogmáticos acerca de un término cuyas líneas de
contorno aún no han acabado de asentarse del todo, vamos a intentar al
menos arrojar algo de luz sobre el concepto.

DevOps según WikiPedia

Comenzamos con lo más próximo que hoy en día podemos tener a una
definición canónica. ¿Qué dice Wikipedia de DevOps?:

«DevOps es un acrónimo inglés de development (desarrollo) y operations

(operaciones), que se refiere a una metodología de desarrollo de software
que se centra en la comunicación, colaboración e integración entre
desarrolladores de software y los profesionales de sistemas en las
tecnologías de la información (IT)».DevOps es una respuesta a la
interdependencia del desarrollo de software y las operaciones IT. Su
objetivo es ayudar a una organización a producir productos y servicios
software más rápidamente, de mejor calidad y a un coste menor.

Las empresas con entregas (releases) muy frecuentes podrían requerir

conocimientos de DevOps. Flickr desarrolló un sistema DevOps para
cumplir un requisito de negocio de diez despliegues diarios. A este tipo de
sistemas se les conoce como despliegue continuo (continuous deployment)

3
o entrega continua (continuous delivery), y suelen estar asociados a
metodologías lean startup. Grupos de trabajo, asociaciones profesionales y
blogs usan el término desde 2009«.
Todo claro, ¿verdad? ¿O pensáis como yo que hay overflow de conceptos?
Rescatemos de momento tres ideas clave:

DevOps es una metodología para creación de software.

DevOps se basa en la integración entre desarrolladores software y
administradores de sistemas.
DevOps permite fabricar software más rápidamente, con mayor calidad,
menor coste y una altísima frecuencia de releases.
Con estos conceptos en mente, repasemos algunas corrientes de opinión
en torno a DevOps.

¿Es DevOps una cultura?

No, DevOps no es en sí una cultura, pero sí requiere de un fuerte cambio
cultural y organizativo para su implementación. Un cambio cultural hacia la
colaboración, la comunicación, y en último término la completa integración
entre las antiguas áreas (en lo habitual rabiosamente estancas) de
desarrollo y sistemas.

Este cambio cultural es tan complicado de conseguir en algunas

organizaciones, que son muchos los que lo identifican directamente con
DevOps, pero recordemos: DevOps es una metodología de desarrollo
software, y un cambio de cultura no es en sí mismo una forma de desarrollar
software.

¿Es DevOps una nueva raza de hombres orquesta?

Otro error común es confundir DevOps con modelos que algunas startups
se ven abocadas a adoptar en sus inicios, en los que todos los miembros del
equipo técnico saben de desarrollo, de sistemas, de tuning de rendimiento,

4
de bases de datos… y hasta de cablear la oficina, comprar portátiles y hasta
configurar el móvil de la gente de negocio. ¿Os suena ;-)?
Ese modelo puede funcionar durante un tiempo, pero no escala. DevOps no
consiste en aumentar la responsabilidad de los desarrolladores haciendo
que lleven varias gorras (en particular dos, la de desarrollo y la de sistemas),
sino en sustituir esas dos gorras por una sola: una nueva gorra DevOps.

¿Es DevOps una profesión?

Según Rob Steward, vicepresidente de desarrollo de producto de Progress
Software, “una buena práctica de DevOps liberará a los desarrolladores
para que se centren en hacer lo que mejor saben hacer: escribir software.
DevOps elimina el trabajo y las preocupaciones de la puesta en producción
del software una vez que está escrito”.

Si esto es así, ¿qué es un ingeniero DevOps? ¿No hemos quedado en que

DevOps permite que un desarrollador sólo desarrolle? ¿Entonces por qué
se buscan en el mercado –y cada vez con mayor demanda- perfiles con
habilidades específicas para montar equipos DevOps?

La respuesta es sencilla: para un desarrollador pasar a un modelo DevOps

resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas
habilidades. Estas habilidades, según una investigación de Puppet Labs, son,
por este orden: scripting, don de gentes, reingeniería de procesos, y en
último lugar experiencia con herramientas específicas. Un perfil que no es
fácil de encontrar.

Así que no, DevOps no es una profesión, y estrictamente no existen ni

perfiles DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con
capacidades específicas para integrarse en equipos DevOps”.

DevOps: un modelo de desarrollo de productos digitales

5
Como conclusión, quedémonos con una definición simple de DevOps con la
que todos podamos estar de acuerdo: DevOps es una metodología de
desarrollo software basada en la integración entre desarrolladores y
administradores de sistemas, que permite que los desarrolladores puedan
enfocarse sólo en desarrollar y puedan desplegar su código en segundos.

DevOps es especialmente útil en el nuevo entorno de la transformación

digital y el desarrollo de productos digitales, para los que el usuario final y/o
el cliente interno de negocio demanda TTM (time-to-market), más
flexibilidad, más calidad, menos coste y una altísima frecuencia de releases.

El Circulo de oro
Qué hace que personas sean seguidas por otras y sus seguidores quieran
ser los primeros en probar lo que hacen? ¿Por qué las personas hacen largas
colas para comprar un producto Apple? La razón es simple; Circulo de Oro.
Porque han encontrado en qué creer, porque han encontrado una causa
justa para seguir, porque simplemente se identifican con lo que un Líder
profesa y comparte.

El Circulo de Oro de Simon Sinek es una maravillosa forma de entender del

porqué grandes personajes han tenido éxito por encima de otros que
también lo han intentado y el porqué las grandes empresas de éxito están
en la cima. Nadie puede negar que Steve Jobs era un maestro para explicar
el porqué de sus productos innovadores y quién no se ha emocionado con
el discurso de Martin Luther King; «Tengo un Sueño».

Qué es el Circulo de oro?

Es la manera de entender qué motiva a las personas a seguir, a comprar o
simplemente a creer en otro o en otros. Explicada mágicamente en lo
siguiente:

6
¿Cómo se relaciona la teoría de los tres Cerebros con el Circulo de oro?
Porqué? Lo inspira el cerebro Reptil y Límbico, controla los instintos y
creencias

Cómo? Lo inspira el cerebro Límbico, controla los sentimientos, la confianza

y la lealtad

Qué? Lo inspira el cerebro Neocortes, controla el pensamiento racional.

Simon Sinek explica, que los líderes o empresas exitosas son los que saben
comunicar muy bien «el porqué» hacen las cosas, Sinek expone que «hay
que hablar de adentro hacia afuera, donde se maneja el comportamiento
humano, sin palabras, sólo con emociones”. Sinek explica que si usted
puede conectar bien con el porqué tendrá gran terreno ganado para
conseguir seguidores y obviamente clientes.

“La gente no compra lo que uno hace, compra el Porqué uno lo hace” Simon
Sinek

Puedes leer también: 7 Formas de Liderar una Tribu según Seth Godin

¿Cómo funciona el Circulo de Oro?

El orden correcto de hacer los negocios es primero dar a a conocer el
Porqué?, segundo dar a entender el Cómo y por ultimo mostrar el qué.
Ponemos como ejemplo a Apple, esta empresa liderada por un visionario
como Steve Jobs, siempre ha promulgado muy bien sus creencias y valores:
El porqué de sus productos? «Por que nosotros desafiamos el status quo y
pensamos diferente». El Cómo; «con productos bien diseñados, sencillos y

7
fáciles de usar» y el qué; «sencillamente ofrecemos Computadores geniales
para las personas» .

“Si uno habla de corazón de sus creencias, atraerá a los que creen lo mismo”
Simon Sinek

De esta manera se entiende muy bien porque se debe transmitir a las

personas primero que todo el Porqué de las cosas. Otro ejemplo de la
aplicación del Circulo de Oro es como los hermanos Wright (quienes
inventaron el avión) los guiaba una creencia, una causa; creyeron que si
eran capaces de inventar el avión, eso cambiaría el curso del mundo, por
eso lo lograron.

Martin Luther King creía en dos leyes; «la ley divina y la ley de los hombres,
sólo cuando la ley de los hombres este acorde con la ley divina habrá paz e
igualdad» con esta premisa y la manera de profesar su credo el Dr. King
movió muchas personas en pro de los derechos civiles y se convirtió más
que en un líder en alguien que lideraba una causa que muchos también
sentían y creían. Es el vivo ejemplo de la aplicación del Circulo de Oro.

«Existen Líderes y personas que lideran. Los líderes tienen poder o

autoridad pero los que lideran nos inspiran» Simon Sinek

Puedes leer también: «El Reto de encantar a los Clientes» de Guy Kawasaki

Conclusión del Circulo de Oro

En conclusión seguimos a los que nos lideran, no por ellos sino por nosotros
mismos. Esos que lideran son los que comienzan por el Porqué, tienen la
habilidad de inspirar a quienes los rodean o de encontrar a otros que los

8
inspire, encontraron una causa, un para qué en la vida; motivados por la
pasión y al amor hacia sus semejantes.

“Lo que uno hace simplemente demuestra lo que uno cree” Simon Sinek

¿Porqué vendemos soluciones y servicios IT?

Porque sentimos pasión por la tecnología, porque encontramos nuestra
misión en la vida que es tocar mentes y corazones de las personas para que
tengan una plataforma tecnológica que les permita ser exitosos y tener una
mejor rentabilidad. También porque nos emocionamos con cada proyecto
que emprendemos, porque queremos compartir todo lo que sabemos,
queremos generar conocimiento e información útil para las personas y ésta
genere Valor para sus negocios y sus vidas.

DevOps Conceptos Básicos

DevOps Introducción, Principios, Roles y Ciclo de vida

¿Qué es DevOps?
El término "DevOps" generalmente se refiere a un movimiento profesional
que aboga por una relación de trabajo colaborativo entre el Desarrollo y las
Operaciones de TI, lo que resulta en un rápido flujo de trabajo planificado
(es decir, altas tasas de despliegue), al tiempo que aumenta la confiabilidad,
la estabilidad, la resistencia y seguridad del entorno de producción.

Diferencia con Agile

Uno de los principios del proceso de desarrollo de Agile es proporcionar

software de trabajo en incrementos más pequeños y más frecuentes, en
oposición al enfoque de "big bang" del método de cascada.

9
Esto es más evidente en el objetivo Agile de tener características
potencialmente vendibles al final de cada sprint. Donde, como DevOps, se
extiende y completa el proceso de integración y lanzamiento continuo
asegurando que el código esté listo para la producción y proporcionando
valor al cliente.

Aunque muchas personas ven DevOps como una reacción a ITIL (IT
Infrastructure Library) o ITSM (IT Service Management).

DevOps informa cuál -ITIL e ITSM son las mejores metodologías de los
procesos de negocio que sustentan las operaciones de TI y describen
muchas de las capacidades necesarias para que las operaciones de TI
admitan un flujo de trabajo al estilo de DevOps.

El objetivo de DevOps no es solo aumentar la tasa de cambio, sino desplegar

funciones exitosamente en la producción sin causar caos e interrumpir
otros servicios, a la vez que detecta y corrige incidentes rápidamente
cuando ocurren.

Esto incluye las disciplinas de ITIL sobre diseño de servicios, incidentes y

gestión de problemas.

¿Por qué se necesita DevOps?

Antes de DevOps, el equipo de desarrollo y operación trabajaba en
completo aislamiento. Las pruebas y la implementación fueron actividades
aisladas realizadas después de la creación del diseño. Por lo tanto,
consumieron más tiempo que los ciclos reales de construcción.

Sin usar DevOps, los miembros del equipo dedican una gran parte de su
tiempo a probar, desplegar y diseñar en lugar de construir el proyecto.

10
La implementación manual del código provoca errores humanos en la
producción.

Los equipos de codificación y operación tienen sus cronogramas separados

y no están sincronizados, causando más retrasos.

¿Por qué se usa DevOps?

DevOps permite a los equipos de desarrollo ágiles implementar la
integración continua y la entrega continua. Esto les ayuda a lanzar
productos más rápidamente en el mercado.

Otras razones importantes son:

Es Predecible: DevOps ofrece una tasa de fallas significativamente menor

de las nuevas versiones.
Reproducibilidad: Permite que la versión anterior pueda restaurarse en
cualquier momento.
Mantenimiento: Proceso de recuperación sin esfuerzo en caso de que una
nueva versión falle o deshabilite el sistema actual.
Tiempo de comercialización: DevOps reduce el tiempo de comercialización
hasta un 50% mediante la entrega de software simplificada. Este es
particularmente el caso de las aplicaciones digitales y móviles.
Mayor calidad: DevOps ayuda al equipo a mejorar la calidad del desarrollo
de aplicaciones ya que incorpora problemas de infraestructura.
Riesgo reducido: DevOps incorpora aspectos de seguridad en el ciclo de
vida de la entrega del software. Ayuda en la reducción de defectos en todo
el ciclo de vida.
Resistente: el estado operativo del sistema de software es más estable,
seguro y los cambios son consultables.

11
Eficiencia de costes: DevOps ofrece rentabilidad en el proceso de desarrollo
de software, que siempre es una aspiración de la gestión de las empresas
de TI.
Rompe una base de código más grande en pequeños trozos: DevOps se basa
en el método de programación ágil. Por lo tanto, permite dividir las bases
de códigos más grandes en trozos más pequeños y manejables.

¿Cuándo no adoptar DevOps?

No debe usarse en una aplicación de misión crítica como bancos, energía y
otros sitios de datos confidenciales.

Dichas aplicaciones necesitan estrictos controles de acceso en el entorno

de producción, una política detallada de gestión de cambios, política de
control de acceso a los centros de datos.

Principios de DevOps
Aquí, hay seis principios que son esenciales al adoptar DevOps:

Acción centrada en el cliente: el equipo de DevOps debe tomar medidas

centradas en el cliente para que constantemente inviertan en productos y
servicios.
Responsabilidad de extremo a extremo: el equipo de DevOps debe
proporcionar soporte de rendimiento hasta que se ocurra el fin de vida.
Esto mejora el nivel de responsabilidad y la calidad de los productos
diseñados.
Mejora Continua: la cultura DevOps se centra en la mejora continua para
minimizar el desperdicio. Continuamente acelera la mejora del producto o
los servicios ofrecidos.
Automatiza todo: la automatización es un principio vital del proceso
DevOps. Esto no es solo para el desarrollo de software, sino también para
todo el panorama de la infraestructura.

12
Trabajar como un solo equipo: en el rol de DevOps, el del diseñador,
desarrollador y evaluador ya están definidos. Todo lo que tenían que hacer
es trabajar como un equipo con total colaboración.
Monitorea y pruebe todo: es muy importante que el equipo de DevOps
tenga un sólido monitoreo y procedimientos de prueba.

El enfoque de DevOps necesita cambios frecuentes e incrementales en las

versiones de código, lo que significa frecuentes despliegues y pruebas.

Aunque los ingenieros de DevOps necesitan codificar de vez en cuando

desde cero, es importante que tengan las bases de los lenguajes de
desarrollo de software.

Un ingeniero de DevOps trabajará con el personal del equipo de desarrollo

para abordar la codificación y secuencias de comandos necesarias para
conectar elementos de código, como bibliotecas o kits de desarrollo de
software.

Roles, responsabilidades y habilidades de un ingeniero DevOps

Los ingenieros de DevOps trabajan a tiempo completo. Ellos son
responsables de la producción y el mantenimiento continuo de la
plataforma de una aplicación de software.

Los siguientes son algunos de los roles, responsabilidades y habilidades que

se esperan del ingeniero DevOps:

Capaz de realizar la solución de problemas del sistema y la solución de

problemas en los dominios de plataforma y aplicaciones.
Gestione el proyecto de manera efectiva a través de plataformas abiertas y
basadas en estándares.
Aumentar la visibilidad del proyecto, la trazabilidad.

13
Mejore la calidad y reduzca los costos de desarrollo con la colaboración.
Analizar, diseñar y evaluar scripts y sistemas de automatización.
Garantizar la resolución crítica de los problemas del sistema mediante el
uso de los mejores servicios de soluciones de seguridad en la nube.
El ingeniero de DevOps debe tener la habilidad suave de resolver problemas
y aprender rápidamente.

Ciclo de vida DevOps

DevOps es una profunda integración entre desarrollo y operaciones.
Comprender DevOps no es posible sin conocer el ciclo de vida de DevOps.

Aquí hay una breve información sobre el ciclo de vida de DevOps continuo:

1. Desarrollo
En esta etapa DevOps, el desarrollo del software se lleva a cabo
constantemente. En esta fase, todo el proceso de desarrollo se divide en
pequeños ciclos de desarrollo. Esto beneficia al equipo DevOps para
acelerar el desarrollo de software y el proceso de entrega.

2. Prueba
El equipo de QA usa herramientas como Selenium para identificar y corregir
errores en la nueva pieza de código.

3. Integración
En esta etapa, la nueva funcionalidad se integra con el código vigente y las
pruebas se llevan a cabo. El desarrollo continuo solo es posible debido a la
integración y pruebas continuas.

4. Despliegue

14
En esta fase, el proceso de implementación se lleva a cabo de manera
continua. Se realiza de tal manera que cualquier cambio realizado en
cualquier momento en el código, no debe afectar el funcionamiento del
sitio web de alto tráfico.

5. Monitoreo
En esta fase, el equipo de operación se encargará del comportamiento
inadecuado del sistema o errores que se encuentran en la producción.

Flujo de trabajo de DevOps

Los flujos de trabajo proporcionan una visión general de la secuencia en la
que se proporciona la entrada. También le informa sobre las acciones que
se realizan y el resultado se genera para un proceso de operaciones.

El flujo de trabajo permite separar y organizar los trabajos que son

solicitados por los usuarios. También brinda la posibilidad de reflejar su
proceso ideal en los trabajos de configuración.

Marco CALMS para DevOps

Cultura
Si la cultura de DevOps se pudiera resumir en una palabra, esta sería
“colaboración” y, mejor aún, “colaboración transversal”. (Vale, eso son más
bien dos.)

Todas las herramientas y automatizaciones del mundo no sirven para nada

si no van acompañadas de una voluntad real de trabajar juntos por parte
de los profesionales de Desarrollo y TI/Operaciones, porque DevOps no
soluciona los problemas relacionados con herramientas, sino los problemas
humanos. Por lo tanto, sería raro que un día te asomaras desde el cubículo,
miraras alrededor y descubrieras que los equipos de tu empresa reflejan la

15
cultura de DevOps. Pero sí hay algunas cosas sencillas que puedes hacer
para cultivarla.

Piensa en DevOps como una metodología ágil, pero con las operaciones
incluidas. Formar equipos con una orientación hacia los proyectos o los
productos que sustituyan equipos basados en funciones es dar un paso en
la dirección correcta. Incluye desarrollo, control de calidad, gestión de
productos, diseño, operaciones, gestión de proyectos y cualquier otro
conjunto de aptitudes que requiera el proyecto. En Atlassian, incluso
integramos el marketing en nuestros equipos de producto.

Pocas cosas fomentan tanto la colaboración como compartir un objetivo

común y tener un plan para alcanzarlo juntos. En algunas compañías,
cambiar de repente a equipos basados en proyectos resulta algo excesivo y
precipitado. Así que mejor ir a paso lento. Los equipos de desarrollo pueden
(y deben) invitar a los miembros adecuados del equipo de operaciones a
unirse a las sesiones de planificación de sprints, las reuniones rápidas
diarias y las demostraciones de sprints. Los equipos de operaciones pueden
invitar a desarrolladores clave. Es una forma ágil y orgánica de estar al tanto
de los proyectos, las ideas y las dificultades de los demás. El tiempo
invertido en escuchar y enriquecer conocimientos de esferas temáticas se
amortiza consiguiendo una gestión de publicaciones y una resolución de
urgencias mucho más eficientes.

Y, hablando de urgencias, constituyen una prueba efectiva de la cultura de

DevOps. ¿Se vuelcan Desarrollo, Operaciones y Atención al cliente en el
problema y lo resuelven como equipo? ¿Empiezan todos dando por hecho
que sus compañeros de equipo tomaron las mejores decisiones posibles
con la información y los recursos con que contaban entonces? ¿La
incidencia se trata a toro pasado corrigiendo procesos en lugar de
señalando a alguien con el dedo? Si la respuesta es afirmativa, es una buena
señal de que tu equipo trabaja con la cultura de DevOps en esencia.

16
Ten en cuenta que las empresas de mayor éxito aprueban la cultura de
DevOps en todos los departamentos y a todos los niveles del organigrama.
Cuentan con canales abiertos de comunicación y los emplean
habitualmente. Se aseguran de que los objetivos de todos vayan a la par, y
los ajustan según sea necesario. Asumen que mantener al cliente satisfecho
es tanto responsabilidad de la gestión de productos como del equipo de
desarrollo. Entienden que DevOps no es el trabajo de un solo equipo. Es el
trabajo de todos.

Los equipos que practican DevOps despliegan 30 veces más

frecuentemente, fallan 60 veces menos y se recuperan 160
veces más rápido.

— Informe del estado de DevOps en 2016 de Puppet Labs

Automatización
Invertir en automatización suprime el trabajo manual repetitivo, genera
procesos reproducibles y crea sistemas fiables.

Compilar, probar, desplegar y automatizar son los puntos de partida típicos

de los equipos que aún no la han puesto en práctica. Oye, ¿y qué mejor
motivo para que Desarrollo, Pruebas y Operaciones trabajen juntos que
construir sistemas que los beneficien a todos?

Los equipos que son nuevos en la automatización suelen empezar con la

entrega continua: la práctica de ejecutar cada cambio en el código
mediante un puñado de pruebas automatizadas, a menudo facilitadas por
una infraestructura basada en la nube, a continuación empaquetar
compilaciones satisfactorias y promoverlas hasta producción con
despliegues automatizados. Como puedes imaginar, la entrega continua no
es una tarea fácil y rápida de preparar, pero la rentabilidad de la inversión
bien merece la pena.

17
¿Por qué? Los ordenadores ejecutan las pruebas con mayor rigor y
exactitud que los seres humanos. Estas pruebas detectan antes los errores
y los fallos de seguridad, por lo que los desarrolladores los pueden corregir
más fácilmente. Y los despliegues automatizados alertan a TI y Operaciones
de los “desajustes” del servidor entre entornos, lo cual reduce o acaba con
las sorpresas cuando ha llegado la hora de publicar.

Otra de las contribuciones principales de DevOps es la idea de

“configuración como código”. Los desarrolladores procuran crear
aplicaciones modulares que admiten composición porque son más fiables y
fáciles de mantener. La misma filosofía se puede aplicar a la infraestructura
que las aloja, ya esté en la nube o en la red de la propia compañía.

Es verdad, los sistemas siempre están cambiando, pero podemos crear una
facha de inmutabilidad utilizando código en el aprovisionamiento de modo
que reaprovisionar un servidor dañado sea más rápido que repararlo, y no
digamos más fiable. Además, reduce riesgos. Tanto Desarrollo como
Operaciones pueden incorporar nuevos lenguajes o tecnologías mediante
el código de aprovisionamiento y compartir las actualizaciones entre ellos.
Las incidencias de compatibilidad resultan evidentes de forma inmediata,
en lugar de manifestarse a media publicación.

La “configuración como código” y la “entrega continua” no son los únicos

tipos de procesos automatizados que se observan en el mundo de DevOps,
pero merecen una mención especial porque ayudan a derribar la barrera
que hay entre el desarrollo y las operaciones. Y cuando DevOps utiliza
despliegues automatizados para enviar código probado a conciencia a
entornos de idéntica provisión, el “¡A mí me funciona!” deja de funcionar.

Infalible
Cuando nos dicen “infalible” en un contexto de software, solemos pensar
en suprimir actividades de escaso valor y avanzar rápido: ser enérgico, ser
ágil. Más oportunos aún para DevOps son los conceptos de mejora continua
y aceptación de los errores.

18
Una mentalidad de DevOps ve oportunidades de mejora continua en todas
partes. Algunas resultan obvias, como mantener retrospectivas periódicas
para mejorar los procesos del equipo. Otras son más sutiles, como las
pruebas A/B en distintos métodos de incorporación para nuevos usuarios
del producto.

Al desarrollo ágil le agradecemos el haber convertido la mejora continua en

una idea corriente. Los primeros en adoptar la metodología ágil
demostraron que un producto sencillo en manos de los clientes hoy tiene
más valor que un producto perfecto en manos de los clientes dentro de seis
meses. Si el producto se mejora continuamente, los clientes no se
marcharán.

¿Y sabes qué? Cometer errores es inevitable. Así que es como si prepararas

al equipo para asumirlos, recuperarse y aprender de ellos (algunos lo llaman
“ser antifrágil”). En Atlassian pensamos que, si no te equivocas de vez en
cuando, es que no te estás esforzando lo suficiente.

Desafiamos a nuestros equipos con objetivos osados y peliagudos y nos

aseguramos de que dispongan de la autonomía y los recursos necesarios
para alcanzarlos. Contratamos a personas inteligentes y ambiciosas, y no
esperamos que sean siempre infalibles.

En el contexto de DevOps, equivocarse no es un delito punible. Los equipos

tienen asumido que las cosas están destinadas a torcerse en algún
momento, así que trabajan para conseguir detecciones y recuperaciones
rápidas. (Lee acerca del Chaos Monkey de Netflix para ver un buen ejemplo
de ello.) Los análisis a toro pasado se centran en qué fallaron los procesos
y cómo reforzarlos, no en qué miembro del equipo se cargó el código. ¿Por
qué? Porque la mejora continua y el fracaso van de la mano.

19
 DevOps ha evolucionado de modo que Desarrollo posee
más operaciones, y así es como funciona Chef. No podemos
seguir pasándonos la pelota. Nuestros ingenieros se
encargan del control de calidad, la escritura de código y la
ejecución de sus propias pruebas para sacar el software
para los clientes.

— Julian Dunn, gestor de productos de Chef

Medición
Sin datos, es difícil demostrar que su esfuerzo continuo por mejorar esté
mejorando algo en efecto. Por suerte, hay un montón de herramientas y
tecnologías para medir el rendimiento: cuánto tiempo pasan los usuarios
con su producto, si esa entrada del blog ha generado alguna venta o con
cuánta frecuencia aparecen alertas críticas en los registros.

Aunque se puede medir casi todo, eso no quiere decir que lo tengas que
medir todo. Sigue el ejemplo del desarrollo ágil y empieza por lo básico:

 ¿Cuánto tiempo llevó pasar del desarrollo al despliegue?

 ¿Con qué frecuencia tienen lugar errores o fallos?
 ¿Cuánto se tarda en recuperarse tras un fallo del sistema?
 ¿Cuántas personas utilizan su producto en este momento?
 ¿Cuántos usuarios has ganado o perdido esta semana?
Sobre una base sólida implantada, cuesta menos detectar métricas más
sofisticadas del uso de las funcionalidades, el recorrido de los clientes, y los
SLA (acuerdos de nivel de servicio). La información que se obtiene viene
muy bien a la hora de confeccionar hojas de ruta y especificar el siguiente
gran paso.

Con todos estos datos jugosos, tu equipo puede tomar decisiones, pero
resultan aún más útiles cuando se comparten con otros equipos, sobre todo
si son de otros departamentos. Por ejemplo, el equipo de marketing quiere

20
tener funcionalidades nuevecitas que vender. Mientras tanto, observas una
alta rotación de clientes, porque el producto está plagado de deuda técnica.
Al aportar datos de los usuarios útiles para la hoja de ruta, aunque no
profundicen en funcionalidades y sí en correcciones, es más fácil lograr
consenso y obtener adquisiciones de las partes interesadas.

DevOps no es el trabajo de una persona sola. Es el trabajo

de todos.

— Christophe Capel, gestor de productos principal, Jira

Service Desk
Compartir
La antigua fricción entre los equipos de desarrollo y operaciones se debe en
gran medida a una falta de puntos en común. Creemos que compartir
responsabilidades y logros representará un importante avance para zanjar
esa división. Los desarrolladores pueden aumentar su buena voluntad de
manera instantánea ayudando a soportar una de las cargas más pesadas de
Operaciones: el localizador. En DevOps gusta la idea de que las personas
que compilan una aplicación se involucren también en su lanzamiento y
ejecución.

Esto no quiere decir que contrates desarrolladores esperando directamente

que también dominen las operaciones. Lo que significa es que Desarrollo y
Operaciones se unan en todas las fases del ciclo de vida de la aplicación.

Los equipos que adoptan DevOps suelen tener una función rotativa en la
que los desarrolladores tratan las incidencias detectadas por los usuarios
finales, mientras que solucionan problemas de producción al mismo
tiempo. Esta persona da respuesta a las incidencias urgentes que los
clientes han notificado, creando parches cuando haga falta, y trabaja con el
backlog de los defectos notificados por clientes. El “desarrollador de apoyo”
aprende mucho sobre el uso que se le da a la aplicación en la vida real. Y
gracias a su gran disponibilidad para con el equipo de operaciones, los
equipos de desarrollo fomentan la confianza y el respeto mutuo.

21
Dejarse la piel juntos en los momentos difíciles hace disfrutar mucho más
de los logros. Sabrás que la cultura de DevOps ha calado en tu empresa
cuando veas que el equipo de desarrollo le lleva dónuts al de operaciones
el día de publicación.

El feedback positivo de los compañeros nos motiva tanto como nuestras

ambiciones profesionales o la nómina. Reconocer públicamente a un
compañero de equipo que ha detectado un molesto error antes de que
salga a la calle es muy importante. Si tu departamento tiene un presupuesto
ilimitado para gratificar a los empleados, ¡no lo desaproveches!

22