Página 1

Página 3
2

IT Revolution Press, LLC

25 NW 23rd Pl, Suite 6314

Portland, OR 97210

Copyright © 2016 por Gene Kim, Jez Humble, Patrick Debois y John
Willis

Todos los derechos reservados, para obtener información sobre el permiso para reproducir
selecciones de este libro, escriba a Permissions, IT Revolution Press, LLC,
25 NW 23rd Pl, Suite 6314, Portland, OR 97210

Primera edición

Impreso en los Estados Unidos de América

10 9 8 7 6 5 4 3 2 1

Diseño de portada por Strauber Design Studio

Ilustración de portada por eboy

Diseño de libro por Mammoth Collective

Diseño de libro electrónico por Carpeta digital

ISBN de impresión: 978-1942788003

Ebook – ISBN ISBN: 978-1-942788-07-2

Ebook – ISBN ISBN: 978-1-942788-08-9

Número de control de la Biblioteca del Congreso: 2016951904

Nota del editor a los lectores: muchas de las ideas, citas y paráfrasis
atribuido a diferentes pensadores y líderes de la industria aquí se extraen
de conversaciones informales, correspondencia, entrevistas, conferencias
mesas redondas y otras formas de comunicación oral que tuvieron lugar durante
los últimos seis años durante el desarrollo y la escritura de este libro. A pesar de que
los autores y el editor han hecho todo lo posible para garantizar que
la información en este libro era correcta al momento de la publicación, los autores y
el editor no asume y por la presente renuncia a cualquier responsabilidad ante cualquier parte por
cualquier pérdida, daño o interrupción causada por errores u omisiones, ya sea

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 1 de 485
 Los errores u omisiones resultan de negligencia, accidente o cualquier otra causa.
El autor del estudio de caso 18F en la página 325 ha dedicado el trabajo a
dominio público renunciando a todos sus derechos sobre el trabajo en todo el mundo
de acuerdo con la ley de derechos de autor, incluidos todos los derechos relacionados y relacionados,
medida permitida por la ley. Puede copiar, modificar, distribuir y realizar casos
estudie 18F, incluso con fines comerciales, todo sin pedir permiso.

Para obtener información sobre descuentos especiales para compras a granel o para
Para obtener información sobre los autores de reserva para un evento, visite ITRevolution.com.

Página 4

EL MANUAL DEVOPS

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 2 de 485
Página 6
5

Prefacio
¡Ajá!

El viaje para completar el Manual de DevOps tiene

ha sido largo, comenzó con Skype trabajando semanalmente
convocatorias entre los coautores en febrero de 2011, con
La visión de crear una guía prescriptiva que
servir como compañero del libro aún no terminado The
Proyecto Phoenix: una novela sobre TI, DevOps y
Ayudando a su empresa a ganar .

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 3 de 485
 Más de cinco años después, con más de dos mil horas.
de trabajo, el manual DevOps finalmente está aquí.
Completar este libro ha sido extremadamente largo
proceso, aunque uno que ha sido altamente gratificante
y lleno de aprendizaje increíble, con un alcance que es mucho
más amplio de lo que imaginamos originalmente. Durante el
proyecto, todos los coautores compartieron la creencia de que DevOps es
genuinamente importante, formado en un "ajá" personal
momento mucho antes en cada una de nuestras carreras profesionales,
con lo cual sospecho que muchos de nuestros lectores resonarán.

Gene Kim
He tenido el privilegio de estudiar de alto rendimiento
organizaciones tecnológicas desde 1999, y una de las
Los primeros hallazgos fueron que abarcan los límites.

Página 7

entre los diferentes grupos funcionales de TI

Operaciones, seguridad de la información y desarrollo
Fue crítico para el éxito. Pero aún recuerdo el primero
vez que vi la magnitud de la espiral descendente que
resultaría cuando estas funciones trabajaran hacia
objetivos opuestos

Era 2006, y tuve la oportunidad de pasar un

semana con el grupo que manejó la TI tercerizada
Operaciones de un gran servicio de reserva de aerolíneas. Ellos
describió las consecuencias aguas abajo de su
grandes versiones anuales de software: cada versión sería

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 4 de 485
 causar inmenso caos e interrupción para el
outsourcer, así como clientes; habría SLA
(acuerdo de nivel de servicio) sanciones, debido a la
interrupciones que afectan al cliente; habría despidos
del personal más talentoso y experimentado, debido a
el déficit de ganancias resultante; habría mucho
trabajo no planificado y lucha contra incendios para que el
el personal restante no podía trabajar en el creciente
pedidos atrasados ​de solicitudes de servicio procedentes de clientes; el
contrato se mantendría unido por la heroicidad de
gerencia intermedia; y todos sintieron que el
el contrato estaría condenado a ser presentado para volver a ofertar en
tres años.

La sensación de desesperanza y futilidad que resultó

creó para mí los inicios de una cruzada moral.
El desarrollo parecía ser visto siempre como
estratégico, pero las operaciones de TI fueron vistas como tácticas,
a menudo delegado o subcontratado por completo, solo para

Página 8

volver en cinco años en peor estado de lo que era primero

entregado.

Durante muchos años, muchos de nosotros supimos que debe haber

una mejor manera. Recuerdo haber visto las conversaciones saliendo
de la Conferencia Velocity 2009, que describe increíbles
resultados habilitados por arquitectura, técnica
prácticas y normas culturales que ahora conocemos como

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 5 de 485
 DevOps. Estaba tan emocionado, porque claramente apuntaba a
la mejor manera que todos habíamos estado buscando. Y
ayudar a difundir esa palabra fue uno de mis personales
Motivaciones para el coautor del Proyecto Phoenix . Tú
puedo imaginar lo increíblemente gratificante que era ver
la comunidad en general reacciona a ese libro, describiendo
cómo les ayudó a lograr su propio "ajá"
momentos

Jez Humble
Mi momento "ajá" de DevOps fue en un arranque en 2000
—Mi primer trabajo después de graduarme. Por un tiempo estuve
Uno de los dos técnicos. Yo hice todo:
redes, programación, soporte, sistemas
administración. Implementamos software para producción
por FTP directamente desde nuestras estaciones de trabajo.

Luego, en 2004, conseguí un trabajo en ThoughtWorks, un

consultoría donde mi primer concierto estaba trabajando en un
proyecto que involucra a unas setenta personas. Estaba en un
equipo de ocho ingenieros cuyo trabajo a tiempo completo era
desplegar nuestro software en una producción
ambiente. Al principio, fue realmente estresante.
Pero en unos meses pasamos del manual

Página 9

implementaciones que tardaron dos semanas en automatizarse

despliegue que tomó una hora, donde pudimos rodar
hacia adelante y hacia atrás en milisegundos usando el azul

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 6 de 485
 patrón de implementación verde durante el negocio normal
horas

Ese proyecto inspiró muchas de las ideas tanto en el

Libro de entrega continua (Addison-Wesley, 2000)
y éste. Mucho de lo que me impulsa a mí y a los demás
trabajar en este espacio es saber que, sea lo que sea
sus limitaciones, siempre podemos hacerlo mejor, y el
deseo de ayudar a las personas en su viaje.

Patrick Debois
Para mí, fue una colección de momentos. En 2007 estaba
trabajando en un proyecto de migración del centro de datos con algunos
Equipos ágiles. Estaba celoso de que tuvieran tanto
productividad: capaz de hacer tanto en tan poco
hora.

Para mi próxima tarea, comencé a experimentar con

Kanban en operaciones y vio cómo la dinámica de
El equipo cambió. Más tarde, en el Agile Toronto 2008
conferencia presenté mi documento IEEE sobre esto, pero yo
sentía que no resonó ampliamente en la comunidad ágil.
Comenzamos un grupo de administración del sistema ágil, pero
Pasé por alto el lado humano de las cosas.

Después de ver la Conferencia Velocity 2009

presentación "10 implementaciones por día" por John Allspaw
y Paul Hammond, estaba convencido de que otros estaban
pensando de manera similar. Entonces decidí organizar el

Página 10

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 7 de 485
 primeros DevOpsDays, acuñando accidentalmente el término
DevOps.

La energía en el evento fue única y contagiosa.

Cuando la gente comenzó a agradecerme porque cambió
su vida para mejor, entendí el impacto. yo
No he dejado de promocionar DevOps desde entonces.

John Willis
En 2008, acababa de vender un negocio de consultoría que
enfocado en prácticas de operaciones de TI heredadas a gran escala
alrededor de la gestión de configuración y monitoreo
(Tivoli) cuando conocí a Luke Kanies (el fundador de
Laboratorios de marionetas). Luke estaba haciendo una presentación sobre
Marioneta en una conferencia de código abierto de O'Reilly sobre
gestión de configuración (CM).

Al principio estaba pasando el rato en la parte de atrás de la habitación

matando el tiempo y pensando: "¿Qué podría este veinte-
de un año me cuenta sobre la gestión de la configuración?
Después de todo, literalmente había estado trabajando toda mi vida en
Algunas de las empresas más grandes del mundo, ayudando
ellos arquitecto CM y otra gestión de operaciones
soluciones Sin embargo, unos cinco minutos en su
sesión, pasé a la primera fila y me di cuenta
todo lo que había estado haciendo durante los últimos veinte años
estaba mal. Luke estaba describiendo lo que ahora llamo
segunda generación CM.

Después de su sesión tuve la oportunidad de sentarme y

tomar un café con él Estaba totalmente vendido por lo que
ahora llame a infraestructura como código. Sin embargo, mientras nosotros
se reunió para tomar un café, Luke comenzó a ir aún más lejos

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 8 de 485
Página 11

explicando sus ideas. Comenzó a decirme que creía

que las operaciones iban a tener que comenzar a comportarse
como los desarrolladores de software. Iban a tener que
mantener sus configuraciones en control de fuente y adoptar
Patrones de entrega de CI / CD para su flujo de trabajo. Siendo el
antigua persona de operaciones de TI en ese momento, creo que respondí
para él con algo como: "Esa idea se va a hundir
como Led Zeppelin con la gente de Ops ". (Estaba claramente
incorrecto.)

Luego, aproximadamente un año después en 2009 en otro O'Reilly

conferencia, Velocity, vi a Andrew Clay Shafer dar un
Presentación sobre Infraestructura Ágil. En su
presentación, Andrew mostró esta imagen icónica de un
muro entre desarrolladores y operaciones con una
representación metafórica del trabajo arrojado sobre el
pared. Él acuñó este "muro de confusión". Las ideas
expresó en esa presentación codificó lo que Lucas
Estaba tratando de decirme un año antes. Esa era la luz
bombilla para mi. Más tarde ese año, fui el único estadounidense
Invitado a los DevOpsDays originales en Gante. Por el
cuando ese evento terminó, a esto lo llamamos DevOps
Estaba claramente en mi sangre.

Claramente, los coautores de este libro llegaron a una situación similar.

epifanía, incluso si vinieron desde muy diferentes
direcciones. Pero ahora hay un peso abrumador de
evidencia de que los problemas descritos anteriormente suceden

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 9 de 485
 casi en todas partes, y que las soluciones asociadas
con DevOps son casi universalmente aplicables.

El objetivo de escribir este libro es describir cómo

replicar las transformaciones DevOps de las que hemos sido parte

Pagina 12

de o han observado, así como disipar muchos de los mitos

de por qué DevOps no funcionará en ciertas situaciones. Abajo
son algunos de los mitos más comunes que escuchamos
DevOps.

Mito : DevOps es solo para startups: mientras que DevOps

las prácticas han sido pioneras en la escala web, Internet
Empresas "unicornio" como Google, Amazon, Netflix,
y Etsy, cada una de estas organizaciones tiene, en algún momento
en su historia, corrían el riesgo de salir del negocio debido a
los problemas asociados con el "caballo" más tradicional
organizaciones: lanzamientos de códigos altamente peligrosos que fueron
propenso a fallas catastróficas, incapacidad para liberar funciones
lo suficientemente rápido como para vencer a la competencia, cumplimiento
preocupaciones, incapacidad para escalar, altos niveles de desconfianza
entre Desarrollo y Operaciones, y así sucesivamente.

Sin embargo, cada una de estas organizaciones pudo

transformar su arquitectura, prácticas técnicas y
cultura para crear los sorprendentes resultados que asociamos
con DevOps Como el Dr. Branden Williams, una información
ejecutivo de seguridad, bromeó: "Que no se hable más de
DevOps unicornios o caballos pero solo purasangres y
caballos que se dirigen a la fábrica de pegamento.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 10 de 485
 Mito : DevOps reemplaza a Agile: principios de DevOps y
las prácticas son compatibles con Agile, con muchas observaciones
que DevOps es una continuación lógica del viaje ágil
que comenzó en 2001. Ágil a menudo sirve como un efectivo
habilitador de DevOps, debido a su enfoque en equipos pequeños
entregando continuamente código de alta calidad a los clientes.

Página 13

Muchas prácticas de DevOps surgen si continuamos administrando

nuestro trabajo más allá del objetivo de "código potencialmente enviable"
al final de cada iteración, extendiéndola a tener nuestro
código siempre en estado desplegable, con desarrolladores
registrarse en el baúl todos los días, y que demostramos nuestra
características en entornos de producción.

Mito : DevOps es incompatible con ITIL: muchas vistas

DevOps como reacción a ITIL o ITSM (Servicio de TI
Gestión), que se publicó originalmente en 1989.
ITIL ha influido ampliamente en múltiples generaciones de operaciones
profesionales, incluido uno de los coautores, y es un
biblioteca de prácticas en constante evolución destinada a codificar el
procesos y prácticas que sustentan TI de clase mundial
Operaciones, abarcando estrategia de servicio, diseño y
apoyo.

Las prácticas de DevOps pueden hacerse compatibles con ITIL

proceso. Sin embargo, para soportar los plazos de entrega más cortos y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 11 de 485
 frecuencias de implementación más altas asociadas con DevOps,
muchas áreas de los procesos ITIL se vuelven completamente
automatizado, resolviendo muchos problemas asociados con el
procesos de configuración y gestión de versiones (por ejemplo,
mantener la base de datos de gestión de configuración y
bibliotecas de software definitivas actualizadas). Y porqué
DevOps requiere una detección y recuperación rápidas cuando
ocurren incidentes de servicio, las disciplinas de servicio de ITIL
el diseño, el incidente y la gestión de problemas permanecen como
relevante como siempre.

Mito : DevOps es incompatible con la información

Seguridad y cumplimiento: la ausencia de tradicional
controles (por ejemplo, segregación de funciones, aprobación de cambios

Página 14

procesos, revisiones manuales de seguridad al final del

proyecto) puede consternar la seguridad de la información y
profesionales de cumplimiento.

Sin embargo, eso no significa que las organizaciones DevOps

No tiene controles efectivos. En lugar de seguridad y
las actividades de cumplimiento solo se realizan al final de
En el proyecto, los controles están integrados en cada etapa de
trabajo diario en el ciclo de vida del desarrollo de software,
resultando en una mejor calidad, seguridad y cumplimiento
resultados.

Mito : DevOps significa eliminar las operaciones de TI, o

"NoOps": muchos malinterpretan DevOps como el completo
eliminación de la función de operaciones de TI. Sin embargo, esto

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 12 de 485
 Raramente es el caso. Si bien la naturaleza de las operaciones de TI funciona
puede cambiar, sigue siendo tan importante como siempre. ESO
Operaciones colabora mucho antes en la vida del software
ciclo con Desarrollo, que continúa trabajando con TI
Operaciones mucho después de que el código se haya implementado en
producción.

En lugar de que las operaciones de TI hagan el trabajo manual que viene

desde tickets de trabajo, permite la productividad del desarrollador
a través de API y plataformas de autoservicio que crean
entornos, probar e implementar código, monitorear y mostrar
telemetría de producción, etc. Al hacer esto, TI
Las operaciones se vuelven más como Desarrollo (al igual que QA
e Infosec), dedicados al desarrollo de productos, donde
el producto es la plataforma que los desarrolladores usan de manera segura,
pruebe, implemente y ejecute su TI de forma rápida y segura
servicios en produccion.

Página 15

Mito : DevOps es solo "Infraestructura como código" o

Automatización: mientras se muestran muchos de los patrones de DevOps
en este libro requieren automatización, DevOps también requiere
normas culturales y una arquitectura que permita la
objetivos compartidos que se alcanzarán en todo el valor de TI
corriente. Esto va mucho más allá de la automatización. Como
Christopher Little, un ejecutivo de tecnología y uno de los
los primeros cronistas de DevOps escribieron: "DevOps no es
sobre automatización, así como la astronomía no se trata

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 13 de 485
 telescopios ".
Mito : DevOps es solo para software de código abierto:
Aunque muchas historias de éxito de DevOps tienen lugar en
organizaciones que usan software como la pila LAMP
(Linux, Apache, MySQL, PHP), logrando DevOps
Los resultados son independientes de la tecnología utilizada.
Se han logrado éxitos con aplicaciones escritas
en Microsoft.NET, COBOL y ensamblaje de mainframe
código, así como con SAP e incluso sistemas integrados
(por ejemplo, firmware HP LaserJet).

¡SEPARA EL AHA! MOMENTO

Cada uno de los autores se ha inspirado en la increíble

innovaciones que suceden en la comunidad DevOps y
los resultados que están creando: están creando seguros
sistemas de trabajo, y permitiendo que pequeños equipos rápidamente
y desarrollar y validar independientemente el código que puede ser
desplegado de forma segura a los clientes. Dada nuestra creencia de que
DevOps es una manifestación de crear aprendizaje dinámico
organizaciones que refuerzan continuamente la alta confianza

Página 16

normas culturales, es inevitable que estas organizaciones

continuará innovando y ganando en el mercado.

Es nuestra sincera esperanza de que el Manual DevOps voluntad

servir como un recurso valioso para muchas personas en diferentes
maneras: una guía para planificar y ejecutar DevOps

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 14 de 485
 transformaciones, un conjunto de estudios de caso para investigar y
aprender de, una crónica de la historia de DevOps, un medio
para crear una coalición que abarque propietarios de productos,
Arquitectura, desarrollo, control de calidad, operaciones de TI y
Seguridad de la información para lograr objetivos comunes, una forma de
Obtenga los niveles más altos de apoyo de liderazgo para DevOps
iniciativas, así como un imperativo moral para cambiar el
forma en que gestionamos las organizaciones tecnológicas para permitir
mejor efectividad y eficiencia, así como permitir un
ambiente de trabajo más feliz y más humano, ayudando
todos se convierten en aprendices de por vida, esto no solo ayuda
todos alcanzan sus metas más altas como seres humanos,
pero también ayuda a sus organizaciones a ganar.

Página 17

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 15 de 485
 Prefacio
En el pasado, muchos campos de la ingeniería han experimentado
una especie de evolución notable, continuamente "nivelando" su
comprensión de su propio trabajo. Mientras hay
currículos universitarios y apoyo profesional
organizaciones situadas dentro de disciplinas específicas de
ingeniería (civil, mecánica, eléctrica, nuclear, etc.),
El hecho es que la sociedad moderna necesita todas las formas de ingeniería
reconocer los beneficios y trabajar en un
forma multidisciplinaria

Piense en el diseño de un vehículo de alto rendimiento.

¿Dónde termina el trabajo de un ingeniero mecánico y
comienza el trabajo de un ingeniero eléctrico? Dónde y
cómo y cuándo) debería alguien con dominio
conocimiento de la aerodinámica (quien ciertamente tendría
opiniones bien formadas sobre la forma, el tamaño y la ubicación
de windows) colabora con un experto en pasajero
¿ergonomía? ¿Qué pasa con las influencias químicas del combustible?
mezcla y aceite sobre los materiales del motor y
transmisión durante la vida útil del vehículo? Existen
otras preguntas que podemos hacer sobre el diseño de un
automóvil, pero el resultado final es el mismo: éxito en
los esfuerzos técnicos modernos requieren absolutamente múltiples
perspectivas y experiencia para colaborar.

Para que un campo o disciplina progrese y madure,

necesita llegar a un punto donde pueda reflexionar cuidadosamente

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 16 de 485
Página 18

en sus orígenes, busque un conjunto diverso de perspectivas sobre

esas reflexiones y ubican esa síntesis en un contexto
eso es útil para cómo la comunidad imagina el futuro.

Este libro representa tal síntesis y debería ser visto

como una colección seminal de perspectivas sobre el (lo haré
discutir, aún emergente y evolucionando rápidamente) campo de
ingeniería de software y operaciones.

No importa en qué industria se encuentre, o en qué producto o

servicio que brinda su organización, esta forma de pensar
es primordial y necesario para la supervivencia de cada
Líder empresarial y tecnológico.

—John Allspaw, CTO, Etsy

Brooklyn, NY, agosto de 2016

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 17 de 485
Página 19

Imagina un mundo donde Dev y Ops

Conviértete en DevOps

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 18 de 485
Página 20

Una introducción al manual de DevOps

Imagine un mundo donde los propietarios de productos, desarrollo, control de calidad, operaciones de TI e Infosec
trabajar juntos, no solo para ayudarse mutuamente, sino también para garantizar que la organización en general
tiene éxito Al trabajar hacia un objetivo común, permiten el flujo rápido de trabajo planificado
en producción (por ejemplo, realizar decenas, cientos o incluso miles de implementaciones de código por
día), mientras se logra estabilidad, confiabilidad, disponibilidad y seguridad de clase mundial.

En este mundo, los equipos interfuncionales prueban rigurosamente sus hipótesis sobre qué características
La mayoría deleita a los usuarios y promueve los objetivos de la organización. No solo les importa
implementando funciones de usuario, pero también asegurando activamente que su trabajo fluya sin problemas y
frecuentemente a través de todo el flujo de valor sin causar caos e interrupción a TI
Operaciones o cualquier otro cliente interno o externo.

Simultáneamente, QA, IT Operations e Infosec siempre están trabajando en formas de reducir

fricción para el equipo, creando los sistemas de trabajo que permiten a los desarrolladores ser más
productivo y obtener mejores resultados. Al agregar la experiencia de control de calidad, operaciones de TI y
Infosec en equipos de entrega y herramientas y plataformas automáticas de autoservicio, los equipos pueden
usar esa experiencia en su trabajo diario sin depender de otros equipos.

Esto permite a las organizaciones crear un sistema de trabajo seguro, donde pequeños equipos pueden
Desarrolle, pruebe e implemente de forma rápida e independiente el código y el valor de forma rápida, segura,
de forma segura y confiable para los clientes. Esto permite a las organizaciones maximizar el desarrollador
productividad, permitir el aprendizaje organizacional, crear una alta satisfacción de los empleados y ganar
el mercado.

Estos son los resultados que resultan de DevOps. Para la mayoría de nosotros, este no es el mundo que
vivir. Más a menudo que no, el sistema en el que trabajamos está roto, lo que resulta en extremadamente pobre
resultados que están muy por debajo de nuestro verdadero potencial. En nuestro mundo, desarrollo y TI
Las operaciones son adversarias; las pruebas y las actividades de Infosec ocurren solo al final de un
proyecto, demasiado tarde para corregir cualquier problema encontrado; y casi cualquier actividad crítica también requiere
mucho esfuerzo manual y demasiadas transferencias, dejándonos siempre esperando. No solo

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 19 de 485
 esto contribuye a tiempos de entrega extremadamente largos para hacer cualquier cosa, pero la calidad de nuestro
El trabajo, especialmente los despliegues de producción, también es problemático y caótico, lo que resulta en
Impactos negativos para nuestros clientes y nuestro negocio.

Como resultado, no cumplimos con nuestros objetivos, y toda la organización está insatisfecha con el
rendimiento de TI, lo que resulta en reducciones de presupuesto y empleados frustrados e infelices que
sentirse impotente para cambiar el proceso y sus resultados. † ¿ La solución? Necesitamos cambiar
cómo trabajamos; DevOps nos muestra el mejor camino a seguir.

Para comprender mejor el potencial de la revolución DevOps, veamos el

Revolución de fabricación de la década de 1980. Al adoptar los principios y prácticas Lean,
Las organizaciones de fabricación mejoraron drásticamente la productividad de la planta, el liderazgo del cliente
tiempos, calidad del producto y satisfacción del cliente, lo que les permite ganar en el mercado.

Antes de la revolución, los plazos de entrega promedio de pedidos de plantas de fabricación eran de seis semanas, con
Menos del 70% de los pedidos se envían a tiempo. Para 2005, con el generalizado

Página 21

implementación de prácticas Lean, los plazos de entrega promedio del producto se redujeron a menos de
tres semanas, y más del 95% de los pedidos se enviaron a tiempo. Organizaciones que
no implementó las prácticas Lean, perdió participación de mercado y muchos cerraron
enteramente.

Del mismo modo, se ha elevado el listón para ofrecer productos y servicios tecnológicos: qué
fue lo suficientemente bueno en décadas anteriores no es lo suficientemente bueno ahora. Para cada uno de los últimos cuatro
décadas, el costo y el tiempo requeridos para desarrollar e implementar capacidades comerciales estratégicas
y las características se han reducido en órdenes de magnitud. Durante las décadas de 1970 y 1980, la mayoría de los nuevos
Las características requieren de uno a cinco años para desarrollarse y desplegarse, a menudo cuestan decenas de millones de
dolares

En la década de 2000, debido a los avances tecnológicos y la adopción de principios ágiles y

prácticas, el tiempo requerido para desarrollar una nueva funcionalidad se había reducido a semanas o meses,
pero desplegarse en producción todavía requeriría semanas o meses, a menudo con catástrofes
resultados.

Y para 2010, con la introducción de DevOps y la mercantilización interminable de

hardware, software y ahora la nube, características (e incluso compañías de inicio completas) podrían
crearse en semanas, desplegarse rápidamente en producción en solo horas o minutos, por
En estas organizaciones, la implementación finalmente se convirtió en rutina y bajo riesgo. Estas organizaciones
son capaces de realizar experimentos para probar ideas de negocios, descubriendo qué ideas crean el
mayor valor para los clientes y la organización en su conjunto, que luego son más
desarrollado en funciones que se pueden implementar de forma rápida y segura en la producción.
Tabla 1. La tendencia cada vez más acelerada hacia una entrega de software más rápida, más barata y de bajo riesgo

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 20 de 485
 (Fuente: Adrian Cockcroft, "Velocity and Volume (or Speed ​Wins)", presentación en FlowCon,
San Francisco, CA, noviembre de 2013.)

Hoy, las organizaciones que adoptan los principios y prácticas de DevOps a menudo implementan cambios
cientos o incluso miles de veces por día. En una época donde la ventaja competitiva
requiere un tiempo de comercialización rápido y una experimentación incesante, organizaciones que no pueden
para replicar estos resultados están destinados a perder en el mercado a más ágil
competidores y potencialmente podrían cerrar completamente, como la fabricación
organizaciones que no adoptaron los principios Lean.

Página 22

En estos días, independientemente de en qué industria estamos compitiendo, la forma en que adquirimos clientes
y entregarles valor depende de la corriente de valor de la tecnología. Pon aún más
sucintamente, como declaró Jeffrey Immelt, CEO de General Electric, "Todas las industrias y
la empresa que no está llevando el software al núcleo de su negocio se verá afectada ". O como
Jeffrey Snover, miembro técnico de Microsoft, dijo: "En épocas económicas anteriores, las empresas
valor creado moviendo átomos. Ahora crean valor moviendo bits ".

Es difícil exagerar la magnitud de este problema: afecta a todas las organizaciones,

independientemente de la industria en la que operamos, el tamaño de nuestra organización, ya sea que seamos
con o sin fines de lucro. Ahora más que nunca, cómo se gestiona y realiza el trabajo tecnológico
predice si nuestras organizaciones ganarán en el mercado o incluso sobrevivirán. En muchos
casos, tendremos que adoptar principios y prácticas que se vean muy diferentes de aquellos
que nos han guiado con éxito en las últimas décadas. VerApéndice 1 .

Ahora que hemos establecido la urgencia del problema que resuelve DevOps, tomemos
tiempo para explorar con más detalle la sintomatología del problema, por qué ocurre y
por qué, sin una intervención dramática, el problema empeora con el tiempo.

EL PROBLEMA: ALGO EN TU ORGANIZACIÓN

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 21 de 485
 DEBE NECESITAR MEJORAMIENTO (O NO SERÍA
LEER ESTE LIBRO)

En su lugar, la mayoría de las organizaciones no pueden implementar cambios de producción en minutos u horas.
requiriendo semanas o meses. Tampoco pueden implementar cientos o miles de cambios
en producción por día; en cambio, luchan por desplegarse mensualmente o incluso trimestralmente. Ni
son rutinas de despliegues de producción, en lugar de interrupciones y extinción de incendios crónicos y
heroica

En una era donde la ventaja competitiva requiere un tiempo de comercialización rápido, altos niveles de servicio,
e incesante experimentación, estas organizaciones se encuentran en una competencia significativa
desventaja. Esto se debe en gran parte a su incapacidad para resolver un conflicto central crónico
dentro de su organización tecnológica.

EL NÚCLEO, CONFLICTO CRÓNICO

En casi todas las organizaciones de TI, existe un conflicto inherente entre Desarrollo y TI
Operaciones que crean una espiral descendente, lo que resulta en un tiempo cada vez más lento para comercializar
nuevos productos y características, menor calidad, mayores interrupciones y, lo peor de todo, una
creciente cantidad de deuda técnica.

El término "deuda técnica" fue acuñado por primera vez por Ward Cunningham. Análogo a financiero
deuda, la deuda técnica describe cómo las decisiones que tomamos conducen a problemas que
cada vez más difícil de solucionar con el tiempo, reduciendo continuamente nuestras opciones disponibles en
el futuro, incluso cuando se toma con prudencia, seguimos generando intereses.

Un factor que contribuye a esto son los objetivos a menudo competitivos del Desarrollo y TI
Operaciones Las organizaciones de TI son responsables de muchas cosas. Entre ellos están los dos
siguientes objetivos, que deben perseguirse simultáneamente:

Responda al panorama competitivo que cambia rápidamente

Página 23

Proporcionar un servicio estable, confiable y seguro al cliente.

Con frecuencia, el desarrollo se responsabilizará de responder a los cambios en el mercado,

desplegar características y cambios en producción lo más rápido posible. Las operaciones de TI
Asumir la responsabilidad de proporcionar a los clientes un servicio de TI estable, confiable y
seguro, lo que hace que sea difícil o incluso imposible para cualquiera introducir cambios en la producción
eso podría poner en peligro la producción. Configurado de esta manera, Desarrollo y Operaciones de TI
tener objetivos e incentivos diametralmente opuestos.

Dr. Eliyahu M. Goldratt, uno de los fundadores de la gestión de fabricación.

movimiento, llamado este tipo de configuración "el núcleo, conflicto crónico", cuando
Las medidas e incentivos organizacionales en diferentes silos impiden el logro
de objetivos globales y organizacionales. ‡

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 22 de 485
 Este conflicto crea una espiral descendente tan poderosa que impide el logro de lo deseado
resultados comerciales, tanto dentro como fuera de la organización de TI. Estos conflictos crónicos
a menudo ponen a los trabajadores tecnológicos en situaciones que conducen a una mala calidad de software y servicio,
y malos resultados para el cliente, así como una necesidad diaria de soluciones, extinción de incendios y
heroicidad, ya sea en gestión de productos, desarrollo, control de calidad, operaciones de TI o
Seguridad de información. VerApéndice 2 .

ESPIRAL HACIA ABAJO EN TRES ACTOS

La espiral descendente en TI tiene tres actos que probablemente sean familiares para la mayoría de los profesionales de TI.

El primer acto comienza en las operaciones de TI, donde nuestro objetivo es mantener las aplicaciones y
infraestructura en funcionamiento para que nuestra organización pueda ofrecer valor a los clientes. En nuestro diario
trabajo, muchos de nuestros problemas se deben a aplicaciones e infraestructura que son complejas,
mal documentado e increíblemente frágil. Esta es la deuda técnica y diaria
soluciones con las que vivimos constantemente, siempre prometiendo que arreglaremos el desastre cuando
Ten un poco más de tiempo. Pero ese momento nunca llega.

Es alarmante que nuestros artefactos más frágiles respalden nuestros ingresos más importantes.
sistemas generadores o nuestros proyectos más críticos. En otras palabras, los sistemas más propensos a
El fracaso también es nuestro más importante y está en el epicentro de nuestros cambios más urgentes.
Cuando estos cambios fallan, ponen en peligro nuestras promesas organizacionales más importantes, como
como disponibilidad para los clientes, objetivos de ingresos, seguridad de los datos del cliente, información financiera precisa
informes, y así sucesivamente.

El segundo acto comienza cuando alguien tiene que compensar la última promesa rota:
podría ser un gerente de producto que promete una característica más grande y audaz para deslumbrar a los clientes con o
un ejecutivo de negocios que establece un objetivo de ingresos aún mayor. Entonces, ajeno a lo que
la tecnología puede o no puede hacer, o qué factores llevaron a perder nuestro compromiso anterior, ellos
comprometer a la organización tecnológica a cumplir esta nueva promesa.

Como resultado, el desarrollo tiene la tarea de otro proyecto urgente que inevitablemente requiere
resolviendo nuevos desafíos técnicos y atajos para cumplir con la fecha de lanzamiento prometida,
agregando aún más a nuestra deuda técnica, hecha, por supuesto, con la promesa de que arreglaremos cualquier
problemas resultantes cuando tenemos un poco más de tiempo.

Esto prepara el escenario para el tercer y último acto, donde todo se vuelve un poco más
difícil, poco a poco: todos se ponen un poco más ocupados, el trabajo lleva un poco más de tiempo,

Página 24

las comunicaciones se vuelven un poco más lentas y las colas de trabajo se alargan un poco más. Nuestro trabajo
se vuelve más estrechamente acoplado, acciones más pequeñas causan fallas más grandes, y nos volvemos más
temeroso y menos tolerante de hacer cambios. El trabajo requiere más comunicación,
coordinación y aprobaciones; los equipos deben esperar un poco más por su trabajo dependiente
para terminar y nuestra calidad sigue empeorando. Las ruedas comienzan a moler más lentamente y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 23 de 485
 requieren más esfuerzo para seguir girando. VerApéndice 3.
Aunque es difícil de ver en el momento, la espiral descendente es obvia cuando uno toma
Un paso atrás. Notamos que las implementaciones de código de producción tardan cada vez más en
completa, pasando de minutos a horas a días a semanas. Y peor, el despliegue
los resultados se han vuelto aún más problemáticos, lo que resulta en un aumento constante
Número de interrupciones que afectan al cliente que requieren más heroicidad y extinción de incendios en
Operaciones, privándolos aún más de su capacidad de pagar deudas técnicas.

Como resultado, nuestros ciclos de entrega de productos continúan avanzando más y más lentamente, menos proyectos
se emprenden, y los que son, son menos ambiciosos. Además, los comentarios sobre
El trabajo de todos se vuelve más lento y más débil, especialmente las señales de retroalimentación de nuestro
clientes. Y, independientemente de lo que intentemos, las cosas parecen empeorar: ya no podemos
para responder rápidamente a nuestro cambiante panorama competitivo, ni podemos proporcionar
Servicio estable y confiable a nuestros clientes. Como resultado, finalmente perdemos en el mercado.

Una y otra vez, aprendemos que cuando falla la TI, toda la organización falla. Como Steven J.
Spear señaló en su libro The High-Velocity Edge , si los daños "se desarrollan lentamente como
una enfermedad debilitante "o rápidamente" como un choque de fuego ... la destrucción puede ser igual de completa ".

¿POR QUÉ ESTE ESPIRAL HACIA ABAJO SUCEDE EN TODAS PARTES?

Durante más de una década, los autores de este libro han observado que esta espiral destructiva ocurre en
innumerables organizaciones de todos los tipos y tamaños. Entendemos mejor que nunca por qué esto
se produce una espiral descendente y por qué requiere mitigar los principios de DevOps. Primero como
descrito anteriormente, cada organización de TI tiene dos objetivos opuestos, y segundo, cada
La compañía es una compañía de tecnología, lo sepan o no.

Como Christopher Little, un ejecutivo de software y uno de los primeros cronistas de DevOps,
dijo: "Cada empresa es una empresa de tecnología, independientemente de qué negocio piensan
están dentro. Un banco es solo una compañía de TI con una licencia bancaria ". §

Para convencernos de que este es el caso, tenga en cuenta que la gran mayoría del capital
los proyectos tienen cierta dependencia de TI. Como dice el dicho: "Es prácticamente imposible hacer
cualquier decisión comercial que no resulte en al menos un cambio de TI ".

En el contexto empresarial y financiero, los proyectos son críticos porque sirven como el principal
mecanismo de cambio dentro de las organizaciones. Los proyectos son típicamente lo que la gerencia necesita
aprobar, presupuestar y rendir cuentas; por lo tanto, son el mecanismo que
lograr los objetivos y aspiraciones de la organización, ya sea para crecer o incluso reducirse.¶

Los proyectos generalmente se financian a través de gastos de capital (es decir, fábricas, equipos y
proyectos importantes, y los gastos se capitalizan cuando se espera que la recuperación de la inversión demore años),
de los cuales el 50% ahora está relacionado con la tecnología. Esto es incluso cierto en verticales de la industria de "baja tecnología"
con el gasto histórico más bajo en tecnología, como energía, metal, recursos
extracción, automotriz y construcción. En otras palabras, los líderes empresariales son mucho más

Página 25

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 24 de 485
 depender de la gestión efectiva de TI para lograr sus objetivos de lo que ellos
pensar.** **

LOS COSTOS: HUMANOS Y ECONOMICOS

Cuando las personas están atrapadas en esta espiral descendente durante años, especialmente aquellas que están
aguas abajo del desarrollo, a menudo se sienten atrapados en un sistema que ordena fallos y
los deja impotentes para cambiar los resultados. Esta impotencia a menudo es seguida por
agotamiento, con los sentimientos asociados de fatiga, cinismo e incluso desesperanza y
desesperación.

Muchos psicólogos afirman que crear sistemas que causan sentimientos de impotencia es uno
de las cosas más perjudiciales que podemos hacer a otros seres humanos: privamos a otras personas de
su capacidad para controlar sus propios resultados e incluso crear una cultura donde las personas están
miedo de hacer lo correcto por temor a castigo, fracaso o poner en peligro su
sustento. Esto puede crear las condiciones de impotencia aprendida , donde las personas se vuelven
reacio o incapaz de actuar de una manera que evite el mismo problema en el futuro.

Para nuestros empleados, significa largas horas, trabajar los fines de semana y una disminución de la calidad de
vida, no solo para el empleado, sino para todos los que dependen de ellos, incluidos familiares y
amigos. No es sorprendente que cuando esto ocurre, perdemos a nuestra mejor gente (excepto aquellos
que sienten que no pueden irse, debido a un sentido del deber u obligación).

Además del sufrimiento humano que viene con la forma actual de trabajar, el
El costo de oportunidad del valor que podríamos estar creando es asombroso: los autores creen
que estamos perdiendo aproximadamente $ 2.6 billones de creación de valor por año, que es,
Al momento de escribir este artículo, equivalente a la producción económica anual de Francia, el sexto
La economía más grande del mundo.

Considere el siguiente cálculo: tanto IDC como Gartner estimaron que en 2011,
aproximadamente el 5% del producto interno bruto mundial ($ 3,1 billones) se gastó en TI
(hardware, servicios y telecomunicaciones). Si estimamos que el 50% de esos $ 3.1 billones se gastó en
costos de operación y mantenimiento de los sistemas existentes, y que un tercio de ese 50% se gastó
en trabajos o reprocesos urgentes y no planificados, se desperdiciaron aproximadamente $ 520 mil millones.

Si la adopción de DevOps nos podría permitir, a través de una mejor gestión y un aumento
excelencia operativa, reducir a la mitad ese desperdicio y volver a desplegar ese potencial humano en
algo que es cinco veces el valor (una propuesta modesta), podríamos crear $ 2.6 billones de
valor por año.

LA ÉTICA DE LOS DEVOPS: HAY UNA MEJOR MANERA

En las secciones anteriores, describimos los problemas y las consecuencias negativas de

status quo debido al conflicto central, crónico, de la incapacidad para lograr la organización
objetivos, por el daño que infligimos a otros seres humanos. Al resolver estos problemas, DevOps
asombrosamente nos permite mejorar simultáneamente el desempeño organizacional, lograr
Los objetivos de todos los diversos roles de tecnología funcional (por ejemplo, desarrollo, control de calidad, TI
Operaciones, Infosec), y mejorar la condición humana.

Esta combinación emocionante y rara puede explicar por qué DevOps ha generado tanto
entusiasmo y entusiasmo en tantos en tan poco tiempo, incluidos los líderes tecnológicos,

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 25 de 485
Page 26

ingenieros y gran parte del ecosistema de software en el que residimos.

ROMPIENDO LA ESPIRAL HACIA ABAJO CON DEVOPS

Idealmente, pequeños equipos de desarrolladores implementan independientemente sus características, validan sus
corrección en entornos similares a la producción, y tener su código implementado en producción
de forma rápida y segura. Las implementaciones de código son rutinarias y predecibles. En lugar de
comenzando implementaciones a la medianoche del viernes y pasando todo el fin de semana trabajando para completar
ellos, las implementaciones ocurren durante el día hábil cuando todos ya están en el
oficina y sin que nuestros clientes se den cuenta, excepto cuando ven nuevas funciones y
correcciones de errores que los deleitan. Y, mediante la implementación de código en medio de la jornada laboral, para el
primera vez en décadas, Operaciones de TI está trabajando durante el horario comercial normal como todos
más.

Al crear ciclos de retroalimentación rápidos en cada paso del proceso, todos pueden ver de inmediato
Los efectos de sus acciones. Cada vez que se comprometan cambios en el control de versiones, rápido
Las pruebas automatizadas se ejecutan en entornos similares a la producción, lo que garantiza continuamente que
el código y los entornos funcionan según lo diseñado y siempre están en un lugar seguro y desplegable
estado.

Las pruebas automatizadas ayudan a los desarrolladores a descubrir sus errores rápidamente (generalmente dentro de
minutos), que permite soluciones más rápidas, así como un aprendizaje genuino, aprendizaje que es
imposible cuando se descubren errores seis meses después durante las pruebas de integración, cuando
Los recuerdos y el vínculo entre causa y efecto se han desvanecido por mucho tiempo. En lugar de acumularse
deuda técnica, los problemas se resuelven a medida que se encuentran, movilizando a toda la organización si
necesario, porque los objetivos globales superan los objetivos locales.

La telemetría de producción generalizada en nuestros entornos de código y producción garantiza que

Los problemas se detectan y corrigen rápidamente, lo que confirma que todo funciona como
previsto y los clientes obtienen valor del software que creamos.

En este escenario, todos se sienten productivos: la arquitectura permite que pequeños equipos trabajen
Desacoplado de forma segura y arquitectónica del trabajo de otros equipos que utilizan el autoservicio
plataformas que aprovechan la experiencia colectiva de Operaciones y Seguridad de la Información.
En lugar de que todos esperen todo el tiempo, con grandes cantidades de retrabajo, trabajo urgente, equipos
trabaje de manera independiente y productiva en pequeños lotes, entregando rápida y frecuentemente
Nuevo valor para los clientes.

Incluso los lanzamientos de productos y funciones de alto perfil se vuelven rutinarios mediante el lanzamiento oscuro
técnicas Mucho antes de la fecha de lanzamiento, colocamos todo el código requerido para la función en
producción, invisible para todos, excepto para empleados internos y pequeños grupos de usuarios reales,
lo que nos permite probar y desarrollar la función hasta que alcance el objetivo comercial deseado.

Y, en lugar de combatir incendios durante días o semanas para que la nueva funcionalidad funcione, nosotros
simplemente cambie una función de alternancia o configuración. Este pequeño cambio hace que el nuevo
característica visible para segmentos cada vez más grandes de clientes, retrocediendo automáticamente si
Algo va mal. Como resultado, nuestros lanzamientos son controlados, predecibles, reversibles y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 26 de 485
 Estrés bajo.

No solo las versiones están más tranquilas: se están encontrando todo tipo de problemas y
arreglado temprano, cuando son más pequeños, más baratos y más fáciles de corregir. Con cada solución, también

Página 27

generar aprendizajes organizacionales, lo que nos permite evitar que el problema se repita y
permitiéndonos detectar y corregir problemas similares más rápido en el futuro.

Además, todos están aprendiendo constantemente, fomentando una cultura basada en hipótesis donde
El método científico se utiliza para garantizar que nada se dé por sentado: no hacemos nada sin
medir y tratar el desarrollo de productos y la mejora de procesos como experimentos.

Debido a que valoramos el tiempo de todos, no pasamos años creando características que nuestro
los clientes no quieren, implementando código que no funciona o arreglando algo que no funciona
En realidad la causa de nuestro problema.

Debido a que nos preocupamos por lograr los objetivos, creamos equipos a largo plazo que son responsables de
reuniéndolos En lugar de equipos de proyecto donde los desarrolladores son reasignados y barajados
después de cada lanzamiento, sin recibir comentarios sobre su trabajo, mantenemos los equipos intactos
pueden seguir iterando y mejorando, utilizando esos aprendizajes para lograr mejor sus objetivos.
Esto es igualmente cierto para los equipos de productos que están resolviendo problemas para nuestros
clientes, así como nuestros equipos de plataforma interna que ayudan a otros equipos a ser más
productivo, seguro y seguro.

En lugar de una cultura del miedo, tenemos una cultura colaborativa de alta confianza, donde las personas están
recompensado por tomar riesgos. Son capaces de hablar sin temor sobre problemas en lugar de
ocultándolos o poniéndolos en segundo plano, después de todo, debemos ver los problemas en orden
para resolverlos

Y, debido a que todos poseen la calidad de su trabajo, todos construyen de manera automatizada
prueba en su trabajo diario y utiliza revisiones por pares para ganar confianza en que los problemas son
abordado mucho antes de que puedan afectar a un cliente. Estos procesos mitigan el riesgo, como
en oposición a las aprobaciones de autoridades distantes, lo que nos permite entregar valor de manera rápida y confiable,
y de forma segura, incluso demostrando a auditores escépticos que tenemos un sistema efectivo de
controles internos.

Y cuando algo sale mal, llevamos a cabo autopsias sin culpa , para no castigar
cualquiera, pero para comprender mejor qué causó el accidente y cómo prevenirlo. Esta
El ritual refuerza nuestra cultura de aprendizaje. También realizamos conferencias tecnológicas internas para
elevar nuestras habilidades y garantizar que todos estén siempre enseñando y aprendiendo.

Debido a que nos importa la calidad, incluso inyectamos fallas en nuestro entorno de producción, por lo que
puede aprender cómo falla nuestro sistema de manera planificada. Realizamos ejercicios planificados para
practicar fallas a gran escala, matar procesos al azar y calcular servidores en producción,
e inyectar latencias de red y otros actos nefastos para garantizar que crezcamos cada vez más

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 27 de 485
 elástico. Al hacer esto, permitimos una mejor capacidad de recuperación, así como el aprendizaje organizacional y
mejora.

En este mundo, todos son dueños de su trabajo, independientemente de su papel en el

organización tecnológica Confían en que su trabajo es importante y es significativo
contribuyendo a los objetivos organizacionales, probados por su ambiente de trabajo de bajo estrés y
El éxito de su organización en el mercado. Su prueba es que la organización es
de hecho ganando en el mercado.

EL VALOR EMPRESARIAL DE LOS DEVOPS

Página 28

Tenemos evidencia decisiva del valor comercial de DevOps. Desde 2013 hasta 2016, como
parte del informe State Of DevOps de Puppet Labs , al que los autores Jez Humble y Gene Kim
contribuido, recopilamos datos de más de veinticinco mil profesionales de la tecnología,
con el objetivo de comprender mejor la salud y los hábitos de las organizaciones en todas las etapas de
Adopción de DevOps.

La primera sorpresa que revelaron estos datos fue la cantidad de organizaciones de alto rendimiento que utilizan
Las prácticas de DevOps superaron a sus pares de bajo rendimiento en lo siguiente
áreas:

Métricas de rendimiento

Implementaciones de código y cambio (treinta veces más frecuentes)

Codifique y cambie el tiempo de implementación (doscientas veces más rápido)

Métricas de confiabilidad

Implementaciones de producción (tasa de éxito de cambio sesenta veces mayor)

Tiempo medio para restaurar el servicio (168 veces más rápido)

Métricas de desempeño organizacional

Objetivos de productividad, participación de mercado y rentabilidad (dos veces más probabilidades de exceder)

Crecimiento de la capitalización de mercado (50% más en tres años)

En otras palabras, los de alto rendimiento fueron más ágiles y más confiables, proporcionando
La evidencia empírica de que DevOps nos permite romper el conflicto central y crónico. Alto
los artistas implementaron el código treinta veces más frecuentemente y el tiempo requerido para pasar de
El "código comprometido" para "ejecutarse con éxito en la producción" fue doscientas veces más rápido:
los de alto rendimiento tenían tiempos de entrega medidos en minutos u horas, mientras que los de bajo rendimiento tenían

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 28 de 485
 plazos de entrega medidos en semanas, meses o incluso trimestres.

Además, los de alto rendimiento tenían el doble de probabilidades de superar la rentabilidad, la cuota de mercado,
y objetivos de productividad. Y, para aquellas organizaciones que proporcionaron un símbolo de cotización bursátil, nosotros
descubrió que los de alto rendimiento tuvieron un crecimiento de capitalización de mercado un 50% mayor en tres años.
También tuvieron una mayor satisfacción laboral de los empleados, menores tasas de agotamiento de los empleados y su
los empleados tenían 2,2 veces más probabilidades de recomendar su organización a sus amigos como un gran
lugar para trabajar.†† Los de alto rendimiento también tuvieron mejores resultados de seguridad de la información. Por
integrando objetivos de seguridad en todas las etapas de los procesos de desarrollo y operaciones,
dedicaron un 50% menos de tiempo a solucionar problemas de seguridad.

DEVOPS AYUDA A LA PRODUCTIVIDAD DEL DESARROLLADOR DE ESCALA

Cuando aumentamos el número de desarrolladores, la productividad individual del desarrollador a menudo
disminuye significativamente debido a la comunicación, integración y sobrecarga de pruebas. Esto es
destacado en el famoso libro de Frederick Brook , The Mythical Man-Month , donde
explica que cuando los proyectos llegan tarde, agregar más desarrolladores no solo disminuye individualmente
productividad del desarrollador pero también disminuye la productividad general.

Página 29

Por otro lado, DevOps nos muestra que cuando tenemos la arquitectura correcta, la correcta
prácticas técnicas y las normas culturales correctas, pequeños equipos de desarrolladores pueden
Desarrolle, integre, pruebe e implemente cambios de forma rápida, segura e independiente en
producción. Como observó Randy Shoup, anteriormente director de ingeniería de Google,
Las organizaciones que utilizan DevOps "tienen miles de desarrolladores, pero su arquitectura y
las prácticas permiten que los equipos pequeños sigan siendo increíblemente productivos, como si fueran una startup ".

El Informe del estado de DevOps de 2015 examinó no solo "implementaciones por día" sino también "implementaciones
por día por desarrollador ". Presumimos que los de alto rendimiento podrían escalar sus
número de implementaciones a medida que creció el tamaño del equipo.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 29 de 485
 Figura 1. Implementaciones / día vs. número de desarrolladores (Fuente:‡‡
Puppet Labs, 2015 State Of
Informe DevOps .)

De hecho, esto es lo que encontramos. La Figura 1 muestra que en los de bajo rendimiento, las implementaciones por día por
el desarrollador baja a medida que aumenta el tamaño del equipo, se mantiene constante para los de mediano rendimiento y
aumenta linealmente para artistas de alto rendimiento.

En otras palabras, las organizaciones que adoptan DevOps pueden aumentar linealmente el número de
se implementa por día a medida que aumentan su número de desarrolladores, al igual que Google, Amazon y
Netflix lo ha hecho.§§

LA UNIVERSALIDAD DE LA SOLUCIÓN
Uno de los libros más influyentes en el movimiento de manufactura esbelta es The Goal: A
Proceso de mejora continua escrito por el Dr. Eliyahu M. Goldratt en 1984. Influyó
Una generación entera de gerentes de planta profesionales en todo el mundo. Era una novela sobre
un gerente de planta que tuvo que arreglar sus problemas de costos y fecha de vencimiento del producto en noventa días,
de lo contrario su planta se cerraría.

Más adelante en su carrera, el Dr. Goldratt describió las cartas que recibió en respuesta a The Goal.
Estas cartas normalmente decían: "Obviamente te has estado escondiendo en nuestra fábrica, porque
has descrito mi vida [como gerente de planta] exactamente ... "Lo más importante, estas cartas
mostró que las personas pudieron replicar los avances en el rendimiento que fueron
descrito en el libro en sus propios entornos de trabajo.

El Proyecto Phoenix: una novela sobre TI, DevOps y cómo ayudar a su empresa a ganar , escrito
por Gene Kim, Kevin Behr y George Spafford en 2013, se inspiró en el modelo The
Objetivo . Es una novela que sigue a un líder de TI que enfrenta todos los problemas típicos

Página 30

endémico en las organizaciones de TI: un proyecto con exceso de presupuesto y retraso que debe llegar a
mercado para que la empresa pueda sobrevivir. Experimenta despliegues catastróficos;
problemas de disponibilidad, seguridad y cumplimiento; Etcétera. En definitiva, él y su
el equipo usa los principios y prácticas de DevOps para superar esos desafíos, ayudando a sus
organización gana en el mercado. Además, la novela muestra cómo practican DevOps
mejoró el entorno laboral para el equipo, creando menos estrés y más
satisfacción debido a una mayor participación del profesional en todo el proceso.

Al igual que con The Goal , existe una tremenda evidencia de la universalidad de los problemas y
soluciones descritas en The Phoenix Project. Considere algunas de las declaraciones que se encuentran en el
Amazon comenta: "Me encuentro relacionado con los personajes de The Phoenix Project ... he
probablemente conocí a la mayoría de ellos en el transcurso de mi carrera "" Si alguna vez has trabajado en alguna
aspecto de TI, DevOps o Infosec definitivamente podrá relacionarse con este libro "o
"No hay un personaje en The Phoenix Project que no identifique conmigo mismo o
alguien que conozco en la vida real ... sin mencionar los problemas que enfrentan y superan aquellos
caracteres."

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 30 de 485
 En el resto de este libro, describiremos cómo replicar la transformación.
descrito en The Phoenix Project , también proporciona muchos estudios de casos de cómo otros
Las organizaciones han utilizado los principios y prácticas de DevOps para replicar esos resultados.

EL MANUAL DEVOPS: UNA GUÍA ESENCIAL

El propósito del Manual de DevOps es brindarle la teoría, los principios y las prácticas.
necesita iniciar con éxito su iniciativa DevOps y lograr los resultados deseados.
Esta guía se basa en décadas de teoría de gestión sólida, estudio de alto rendimiento.
organizaciones tecnológicas, trabajo que hemos realizado para ayudar a las organizaciones a transformarse, y
investigación que valida la efectividad de las prácticas DevOps prescritas. Tanto como
entrevistas con expertos en la materia relevantes y análisis de casi cien casos
estudios presentados en la Cumbre de DevOps Enterprise.

Dividido en seis partes, este libro cubre las teorías y principios de DevOps utilizando los Tres
Ways, una visión específica de la teoría subyacente introducida originalmente en The Phoenix
Proyecto . El manual de DevOps es para todos los que realizan o influyen en el trabajo en el
flujo de valor tecnológico (que generalmente incluye gestión de productos, desarrollo,
Control de calidad, operaciones de TI y seguridad de la información), así como para negocios y marketing
liderazgo, donde se originan la mayoría de las iniciativas tecnológicas.

No se espera que el lector tenga un amplio conocimiento de ninguno de estos dominios, o de

DevOps, Agile, ITIL, Lean o mejora de procesos. Cada uno de estos temas se presenta y
explicado en el libro cuando se hace necesario.

Nuestra intención es crear un conocimiento práctico de los conceptos críticos en cada uno de estos
dominios, tanto para servir como una cartilla e introducir el lenguaje necesario para ayudar
los profesionales trabajan con todos sus pares en todo el flujo de valor de TI y enmarcan
objetivos compartidos.

Este libro será de valor para los líderes empresariales y las partes interesadas que son cada vez más dependientes
sobre la organización tecnológica para el logro de sus objetivos.

Page 31

Además, este libro está destinado a lectores cuyas organizaciones podrían no ser
experimentando todos los problemas descritos en el libro (por ejemplo, largos plazos de implementación o
despliegues dolorosos). Incluso los lectores en esta posición afortunada se beneficiarán de
comprender los principios de DevOps, especialmente aquellos relacionados con objetivos compartidos, comentarios y
aprendizaje continuo

En la Parte I, presentamos una breve historia de DevOps e introducimos la teoría subyacente y

temas clave de cuerpos de conocimiento relevantes que abarcan décadas. Luego presentamos el
principios de alto nivel de las tres formas: flujo, retroalimentación y aprendizaje continuo y
Experimentación

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 31 de 485
 La Parte II describe cómo y dónde comenzar, y presenta conceptos tales como flujos de valor,
principios y patrones de diseño organizacional, patrones de adopción organizacional y caso
estudios.

La Parte III describe cómo acelerar Flow al construir los cimientos de nuestro despliegue
pipeline: permitiendo pruebas automatizadas rápidas y efectivas, integración continua, continua
entrega y arquitectura para lanzamientos de bajo riesgo.

La Parte IV discute cómo acelerar y amplificar la retroalimentación creando una producción efectiva
telemetría para ver y resolver problemas, anticipar mejor los problemas y alcanzar objetivos, permitir
retroalimentación para que Dev y Ops puedan implementar cambios de manera segura, integrar pruebas A / B en nuestro
trabajo diario, y crear procesos de revisión y coordinación para aumentar la calidad de nuestro
trabajo.

La Parte V describe cómo aceleramos el aprendizaje continuo al establecer una cultura justa,
convirtiendo descubrimientos locales en mejoras globales, y reservando adecuadamente el tiempo para
Crear aprendizaje organizacional y mejoras.

Finalmente, en la Parte VI describimos cómo integrar adecuadamente la seguridad y el cumplimiento en nuestro

trabajo diario, integrando controles de seguridad preventivos en código fuente compartido
repositorios y servicios, integrando la seguridad en nuestro canal de implementación, mejorando
telemetría para permitir una mejor detección y recuperación, proteger la canalización de implementación, y
logrando objetivos de gestión del cambio.

Al codificar estas prácticas, esperamos acelerar la adopción de prácticas DevOps,

aumentar el éxito de las iniciativas DevOps y reducir la energía de activación requerida para
Transformaciones de DevOps.

† Esta es solo una pequeña muestra de los problemas encontrados en las organizaciones de TI típicas.

‡ En el ámbito de la fabricación, existía un conflicto crónico similar: la necesidad de garantizar simultáneamente los envíos a tiempo a los clientes y controlar los costos.
En el Apéndice 2 se describe cómo se rompió este conflicto crónico central.

§ En 2013, el banco europeo HSBC empleó más desarrolladores de software que Google.

¶ Por ahora, suspendamos la discusión sobre si el software debe ser financiado como un "proyecto" o un "producto". Esto se discute más adelante en el libro.

** Por ejemplo, el Dr. Vernon Richardson y sus colegas publicaron este sorprendente hallazgo. Estudiaron las presentaciones de 10-K SEC de 184 corporaciones públicas
y los dividió en tres grupos: A) empresas con debilidades materiales con deficiencias relacionadas con TI, B) empresas con debilidades materiales sin problemas relacionados con TI
deficiencias, y C) "empresas limpias" sin debilidades materiales. Las empresas del Grupo A registraron una rotación del CEO ocho veces mayor que el Grupo C, y hubo cuatro
veces mayor rotación de CFO en el Grupo A que en el Grupo C. Claramente, TI puede importar mucho más de lo que normalmente pensamos.

†† Medido por la puntuación neta del promotor del empleado (eNPS). Este es un hallazgo significativo, ya que la investigación ha demostrado que "las empresas con trabajadores altamente comprometidos
Los ingresos crecieron dos veces y media más que aquellos con bajos niveles de participación. Y acciones [cotizadas en bolsa] de compañías con un trabajo de alta confianza
el medio ambiente superó los índices del mercado en un factor de tres desde 1997 hasta 2011 ".

‡‡ Solo se muestran las organizaciones que se implementan al menos una vez al día.

§§ Otro ejemplo más extremo es Amazon. En 2011, Amazon realizaba aproximadamente siete mil implementaciones por día. Para 2015, estaban
realizando 130,000 implementaciones por día.

Página
Page 3332

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 32 de 485
 Parte
Introducción

En la Parte I del Manual de DevOps , exploraremos cómo

la convergencia de varios movimientos importantes en
gestión y tecnología prepararon el escenario para el
Movimiento DevOps. Describimos flujos de valor, cómo
DevOps es el resultado de aplicar los principios Lean a
flujo de valor tecnológico y las tres formas: flujo,
Retroalimentación, y aprendizaje y experimentación continua.

Los enfoques principales dentro de estos capítulos incluyen:

Los principios de Flow, que aceleran la entrega.

de trabajo desde Desarrollo a Operaciones a nuestro
clientes

Los principios de Feedback, que nos permiten crear

sistemas de trabajo cada vez más seguros

Los principios del aprendizaje continuo y

La experimentación fomenta una cultura de alta confianza y un
enfoque científico para la mejora organizacional
asumir riesgos como parte de nuestro trabajo diario

UNA BREVE HISTORIA

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 33 de 485
34

DevOps y sus resultados técnicos, arquitectónicos y

las prácticas culturales representan una convergencia de muchos
Movimientos filosóficos y de gestión. Mientras que muchos
las organizaciones han desarrollado estos principios
independientemente, entendiendo que DevOps resultó
de un amplio golpe de movimientos, un fenómeno
descrito por John Willis (uno de los coautores de este
libro) como la "convergencia de DevOps", muestra un
Increíble progresión de pensamiento e improbable
conexiones Hay décadas de lecciones aprendidas de
fabricación, organización de alta confiabilidad, alta confianza
modelos de gestión y otros que nos han traído a
las prácticas de DevOps que conocemos hoy.

DevOps es el resultado de aplicar el más confiable

principios del dominio de la fabricación física
y liderazgo en el flujo de valor de TI. DevOps confía en
cuerpos de conocimiento de Lean, Theory of Restraints,
el sistema de producción de Toyota, ingeniería de resiliencia,
organizaciones de aprendizaje, cultura de seguridad, factores humanos,
y muchos otros. Otros contextos valiosos que DevOps
se basa en incluir culturas de gestión de alta confianza,
liderazgo de servicio y cambio organizacional
administración. El resultado es una calidad de clase mundial,
fiabilidad, estabilidad y seguridad a un costo cada vez menor y
esfuerzo; y flujo acelerado y fiabilidad en todo
el flujo de valor tecnológico, incluido el producto
Gestión, desarrollo, control de calidad, operaciones de TI y
Infosec.

Si bien la base de DevOps puede verse como

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 34 de 485
 derivado de Lean, la teoría de las restricciones y el

Página 35

Movimiento Toyota Kata, muchos también ven a DevOps como el

continuación lógica del viaje de software ágil que
comenzó en 2001.

EL MOVIMIENTO LEAN
Técnicas como la asignación de flujo de valor, Kanban
Se codificaron tableros y mantenimiento productivo total
para el sistema de producción de Toyota en la década de 1980. En 1997,
el Lean Enterprise Institute comenzó a investigar
aplicaciones de Lean a otras corrientes de valor, como el
industria de servicios y asistencia sanitaria.

Dos de los principios fundamentales de Lean incluyen la creencia profundamente arraigada

ese tiempo de fabricación requerido para convertir crudo
materiales en productos terminados fue el mejor predictor de
calidad, satisfacción del cliente y felicidad de los empleados,
y que uno de los mejores predictores de plazos de entrega cortos
Fueron pequeños lotes de trabajo.

Los principios Lean se centran en cómo crear valor para el

cliente a través del pensamiento de sistemas creando
constancia de propósito, abrazando el pensamiento científico,
creando flujo y atracción (versus empuje), asegurando calidad en
la fuente, liderando con humildad y respetando cada
individual.

El manifiesto ágil

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 35 de 485
 El Manifiesto Ágil fue creado en 2001 por diecisiete de
Los pensadores líderes en desarrollo de software. Ellos
quería crear un conjunto ligero de valores y
principios contra el desarrollo de software pesado

Page 36

procesos como el desarrollo en cascada, y

metodologías como el proceso racional unificado.

Un principio clave era "entregar software de trabajo

con frecuencia, de un par de semanas a un par de meses,
con preferencia a la escala de tiempo más corta ", enfatizando
El deseo de lotes pequeños, lanzamientos incrementales
en lugar de grandes lanzamientos en cascada. Otros principios
hizo hincapié en la necesidad de equipos pequeños y motivados,
trabajando en un modelo de gestión de alta confianza.

Agile es acreditado por aumentar dramáticamente el

productividad de muchas organizaciones de desarrollo. Y
Curiosamente, muchos de los momentos clave en DevOps
la historia también ocurrió dentro de la comunidad ágil o en
Conferencias ágiles, como se describe a continuación.

INFRAESTRUCTURA ÁGIL Y VELOCIDAD

MOVIMIENTO
En la conferencia Agile 2008 en Toronto, Canadá,
Patrick Debois y Andrew Schafer sostuvieron un "pájaros de un
sesión "pluma" sobre la aplicación de principios ágiles a
infraestructura en lugar de código de aplicación. A pesar de que

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 36 de 485
 fueron las únicas personas que aparecieron, rápidamente
ganó seguidores de pensadores de ideas afines, incluyendo
autor John Willis.

Más tarde, en la conferencia Velocity 2009, John Allspaw y

Paul Hammond dio el seminal "10 despliegues por día:
Dev y Ops Cooperación en la presentación de Flickr ”, donde
describieron cómo crearon objetivos compartidos entre
Dev y Ops y prácticas de integración continua utilizadas
hacer que la implementación sea parte del trabajo diario de todos.

Page 37

Según las cuentas de primera mano, todos los asistentes al

presentación de inmediato supo que estaban en el
presencia de algo profundo e histórico
significado.

Patrick Debois no estaba allí, pero estaba muy emocionado por

La idea de Allspaw y Hammond de que él creó el primer
DevOpsDays en Gante, Bélgica, (donde vivía) en
2009. Allí se acuñó el término "DevOps".

EL MOVIMIENTO CONTINUO DE ENTREGA

Sobre la base de la disciplina de desarrollo continuo
construcción, prueba e integración, Jez Humble y David
Farley extendió el concepto a la entrega continua ,
que definió el papel de una "tubería de implementación" para
asegúrese de que el código y la infraestructura estén siempre en un
estado desplegable, y que todo el código registrado en el tronco
puede desplegarse de manera segura en producción. Esta idea fue

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 37 de 485
 presentado por primera vez en la conferencia Agile 2006, y fue
También desarrollado independientemente en 2009 por Tim Fitz en un
publicación de blog en su sitio web titulada "Continuo
Despliegue."¶¶

TOYOTA KATA
En 2009, Mike Rother escribió Toyota Kata: Gestión
Personas para Mejora, Adaptabilidad y Superior
Resultados , que enmarcaron su viaje de veinte años a
Comprender y codificar el Sistema de Producción Toyota.
Había sido uno de los estudiantes de posgrado que voló con
Los ejecutivos de GM visitarán las plantas de Toyota y ayudaron a desarrollar
el kit de herramientas Lean, pero estaba perplejo cuando ninguno de los

38

Las empresas que adoptaron estas prácticas replicaron el nivel

de rendimiento observado en las plantas de Toyota.

Llegó a la conclusión de que la comunidad Lean era la que más extrañaba

importante práctica de todas, a la que llamó
mejora kata . Él explica que cada organización
tiene rutinas de trabajo, y la mejora que requiere kata
creando estructura para la práctica diaria y habitual de
trabajo de mejora, porque la práctica diaria es lo que
Mejora los resultados. El ciclo constante de establecimiento
estados futuros deseados, estableciendo resultados objetivo semanales,
y la mejora continua del trabajo diario es lo que
mejora guiada en Toyota.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 38 de 485
 Lo anterior describe la historia de DevOps y relevante
movimientos sobre los que se basa. En todo el resto de
Parte I, observamos los flujos de valor, cómo los principios Lean pueden
ser aplicado a la corriente de valor de la tecnología, y los Tres
Formas de flujo, retroalimentación y aprendizaje continuo y
Experimentación.

¶¶ DevOps también extiende y desarrolla las prácticas de infraestructura como código , que fue
promovido por el Dr. Mark Burgess, Luke Kanies y Adam Jacob. En infraestructura como código, el
El trabajo de Operaciones es automatizado y tratado como un código de aplicación, de modo que
Las prácticas de desarrollo se pueden aplicar a todo el flujo de desarrollo. Esto además permitió
flujo de implementación rápido, incluida la integración continua (iniciada por Grady Booch y
integrado como una de las 12 prácticas clave de programación extrema), entrega continua
(promovido por Jez Humble y David Farley), y despliegue continuo (promovido por Etsy,
Wealthfront y el trabajo de Eric Ries en IMVU).

Página 39

1 Entrega y el
ágil,
Tres continuo
maneras

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 39 de 485
 En este capítulo, una introducción a la base
Se presenta la teoría de Lean Manufacturing, así como la
Tres formas, los principios a partir de los cuales
se pueden derivar comportamientos observados de DevOps.

Nuestro enfoque aquí es principalmente en teoría y principios,

describiendo muchas décadas de lecciones aprendidas de
fabricación, organizaciones de alta confiabilidad, alta confianza
modelos de gestión y otros, desde los cuales DevOps
Se han derivado prácticas. El concreto resultante
principios y patrones, y su aplicación práctica a
el flujo de valor tecnológico, se presentan en el
capítulos restantes del libro.

EL VALOR DE FABRICACIÓN
CORRIENTE

Uno de los conceptos fundamentales en Lean es el valor.

transmitir . Lo definiremos primero en el contexto de
fabricación y luego extrapolar cómo se aplica a
DevOps y el flujo de valor tecnológico.

Page 40

Karen Martin y Mike Osterling definen flujo de valor en

su libro Value Stream Mapping: Cómo visualizar
Trabajar y alinear el liderazgo para la organización
Transformación como "la secuencia de actividades y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 40 de 485
 la organización se compromete a entregar a un cliente
solicitud "o" la secuencia de actividades necesarias para
diseñar, producir y entregar un bien o servicio a un
cliente, incluidos los flujos duales de información y
material."

En las operaciones de fabricación, el flujo de valor es a menudo

fácil de ver y observar: comienza cuando un pedido del cliente
se recibe y las materias primas se liberan en el
piso de planta. Para permitir tiempos de entrega rápidos y predecibles en
cualquier flujo de valor, generalmente hay un enfoque implacable en
creando un flujo de trabajo uniforme y uniforme, utilizando
técnicas como lotes pequeños, que reducen el trabajo en
proceso (WIP), evitando el reprocesamiento para garantizar que no
pasar defectos a los centros de trabajo aguas abajo, y constantemente
optimizando nuestro sistema hacia nuestros objetivos globales.

La corriente de valor tecnológico

Los mismos principios y patrones que permiten el rápido

el flujo de trabajo en procesos físicos es igualmente aplicable
al trabajo tecnológico (y, para el caso, para todos
el trabajo del conocimiento). En DevOps, generalmente definimos nuestro
flujo de valor tecnológico como el proceso requerido para
convertir una hipótesis de negocio en una tecnología habilitada
servicio que entrega valor al cliente.

Page 41

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 41 de 485
 La entrada a nuestro proceso es la formulación de un negocio.
objetivo, concepto, idea o hipótesis, y comienza cuando
aceptamos el trabajo en Desarrollo, agregándolo a nuestro
compromiso de trabajo atrasado.

A partir de ahí, los equipos de desarrollo que siguen un típico

El proceso ágil o iterativo probablemente transformará esa idea
en historias de usuarios y algún tipo de especificación de características,
que luego se implementa en código en la aplicación
o servicio en construcción. El código se registra en el
repositorio de control de versiones, donde cada cambio es
integrado y probado con el resto del software
sistema.

Porque el valor se crea solo cuando nuestros servicios son

funcionando en producción, debemos asegurarnos de que no estamos
solo entregando un flujo rápido, pero que nuestras implementaciones pueden
También se realiza sin causar caos e interrupciones
como interrupciones del servicio, impedimentos del servicio o seguridad
o fallas de cumplimiento.

ENFOQUE EN EL DESPLIEGUE TIEMPO PLAZO

Para el resto de este libro, nuestra atención estará en
tiempo de implementación, un subconjunto del flujo de valor
descrito arriba. Este flujo de valor comienza cuando cualquiera
ingeniero *** en nuestro flujo de valor (que incluye
Desarrollo, control de calidad, operaciones de TI e Infosec) verifica
cambia al control de versiones y termina cuando ese cambio es
ejecutando con éxito en producción, proporcionando valor a
el cliente y generar comentarios útiles y
telemetría

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 42 de 485
Page 42

La primera fase del trabajo que incluye Diseño y

El desarrollo es similar al desarrollo de productos Lean y
es muy variable y altamente incierto, a menudo requiere
altos niveles de creatividad y trabajo que tal vez nunca
realizado nuevamente, lo que resulta en una alta variabilidad del proceso
veces. En contraste, la segunda fase del trabajo, que
incluye pruebas y operaciones, es similar a Lean
Fabricación. Requiere creatividad y experiencia, y
se esfuerza por ser predecible y mecanicista, con el objetivo
de lograr resultados de trabajo con variabilidad minimizada
(p. ej., plazos de entrega cortos y predecibles, casi cero defectos).

En lugar de procesar grandes lotes de trabajo

secuencialmente a través del valor de diseño / desarrollo
transmitir y luego a través del valor de prueba / operaciones
corriente (como cuando tenemos una gran cascada de lotes
proceso o ramas de características de larga duración), nuestro objetivo es
tener pruebas y operaciones sucediendo simultáneamente
con diseño / desarrollo, permitiendo un flujo rápido y alto
calidad. Este método tiene éxito cuando trabajamos en pequeños
lotes y calidad de construcción en cada parte de nuestro valor
corriente.†††

Definición del tiempo de entrega frente al tiempo de procesamiento

En la comunidad Lean, el tiempo de entrega es una de dos medidas
comúnmente utilizado para medir el rendimiento en valor
flujos, con el otro tiempo de procesamiento
(a veces conocido como tiempo de contacto o tiempo de tarea).‡‡‡

Mientras que el reloj de tiempo de entrega comienza cuando la solicitud es

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 43 de 485
 hecho y finaliza cuando se cumple, el reloj de tiempo de proceso
comienza solo cuando comenzamos a trabajar en la solicitud del cliente

Page 43

—Específicamente, omite el tiempo que el trabajo está en la cola,

esperando ser procesado (figura 2).

Figura 2. Tiempo de entrega frente al tiempo de proceso de una implementación

operación

Porque el tiempo de entrega es lo que experimenta el cliente, nosotros

típicamente enfocamos nuestra atención de mejora de procesos allí
en lugar de en tiempo de proceso. Sin embargo, la proporción de
El tiempo de proceso hasta el tiempo de entrega sirve como una medida importante
de eficiencia: lograr un flujo rápido y tiempos de entrega cortos
casi siempre requiere reducir el tiempo que nuestro trabajo es
esperando en las colas

El escenario común: tiempos de entrega de implementación

Meses que requieren
En los negocios como siempre, a menudo nos encontramos en situaciones
donde nuestros plazos de implementación requieren meses. Esto es
especialmente común en organizaciones grandes y complejas que
están trabajando con estrechamente acoplados, monolíticos

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 44 de 485
 aplicaciones, a menudo con escasa prueba de integración
entornos, prueba larga y entorno de producción
plazos de entrega, alta dependencia en pruebas manuales y múltiples
procesos de aprobación requeridos. Cuando esto ocurre, nuestro valor
la transmisión puede verse como la figura 3:

Page 44

Figura 3: Un flujo de valor tecnológico con una implementación

plazo de entrega de tres meses (Fuente: Damon Edwards,
"DevOps Kaizen", 2015.)

Cuando tenemos largos plazos de implementación, los heroicos son

requerido en casi todas las etapas del flujo de valor. Nosotros
puede descubrir que nada funciona al final del proyecto
cuando fusionamos todos los cambios del equipo de desarrollo
juntos, dando como resultado un código que ya no se construye correctamente
o pasa cualquiera de nuestras pruebas. Arreglar cada problema requiere
días o semanas de investigación para determinar quién rompió
el código y cómo se puede arreglar, y aún así da como resultado
resultados del cliente.

Nuestro ideal de DevOps: plazos de implementación de

Minutos
En el ideal de DevOps, los desarrolladores reciben rápido, constante
retroalimentación sobre su trabajo, lo que les permite rápidamente
e implementar, integrar y validar de forma independiente

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 45 de 485
 su código, y tener el código implementado en el
entorno de producción (ya sea mediante la implementación del código
ellos mismos o por otros).

Logramos esto al verificar continuamente el código pequeño

cambios en nuestro repositorio de control de versiones, realizando
pruebas automatizadas y exploratorias en su contra, y
desplegándolo en producción. Esto nos permite tener un
alto grado de confianza en que nuestros cambios funcionarán
según lo diseñado en producción y que cualquier problema puede ser
detectado y corregido rápidamente.

Página 45

Esto se logra más fácilmente cuando tenemos arquitectura

que es modular, bien encapsulado y poco acoplado
para que los equipos pequeños puedan trabajar con altos grados de
autonomía, con fallas pequeñas y contenidas, y
sin causar interrupciones globales.

En este escenario, se mide nuestro tiempo de implementación

en minutos o, en el peor de los casos, horas. Nuestro resultante
el mapa de flujo de valor debería parecerse a la figura 4:

Figura 4: Un flujo de valor tecnológico con un tiempo de espera de

minutos

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 46 de 485
 OBSERVANDO "% C / A" COMO MEDIDA DE
REHACER
Además de los plazos de entrega y los tiempos de proceso, la tercera clave
métrica en el flujo de valor de la tecnología es por ciento
completa y precisa ( % C / A ). Esta métrica refleja el
calidad de la salida de cada paso en nuestro flujo de valor.
Karen Martin y Mike Osterling afirman que "el% C / A
se puede obtener preguntando a los clientes intermedios qué
porcentaje del tiempo que reciben trabajo que es 'utilizable
como es ", lo que significa que pueden hacer su trabajo sin
tener que corregir la información que se proporcionó, agregar
información faltante que debería haberse proporcionado, o
aclarar información que debería haber y podría haber sido
más claro ".

Página 46

LOS TRES CAMINOS: LOS PRINCIPIOS

DEVOPS BASES

The Phoenix Project presenta las tres formas como el set

de principios subyacentes a partir de los cuales todos los observados
Los comportamientos y patrones de DevOps se derivan (Figura 5)

The First Way permite un flujo rápido de trabajo de izquierda a derecha desde
Desarrollo a Operaciones al cliente. A fin de que
maximizar el flujo, necesitamos hacer visible el trabajo, reducir nuestro
tamaños de lotes e intervalos de trabajo, calidad de construcción por

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 47 de 485
 evitar que los defectos pasen a aguas abajo
centros de trabajo, y optimizar constantemente para el mundo
metas.

Figura 5: Las tres formas (Fuente: Gene Kim, “Las tres

Formas: Los principios que sustentan DevOps, "Revolución de TI
Press blog, accedido el 9 de agosto de 2016,
http://itrevolution.com/the-three-ways-principles-
apuntalar-devops / .)

Page 47

Al acelerar el flujo a través del valor de la tecnología

flujo, reducimos el tiempo de entrega requerido para cumplir
solicitudes internas o de clientes, especialmente el tiempo
requerido para implementar código en la producción
ambiente. Al hacer esto, aumentamos la calidad de
trabajar tan bien como nuestro rendimiento y aumentar nuestra capacidad para
Superar a la competencia.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 48 de 485
 Las prácticas resultantes incluyen construcción continua,
procesos de integración, prueba e implementación; creando
ambientes bajo demanda; Limitando el trabajo en proceso
(WIP); y construir sistemas y organizaciones que son
seguro para cambiar.

The Second Way permite el flujo rápido y constante de

retroalimentación de derecha a izquierda en todas las etapas de nuestro valor
corriente. Requiere que amplifiquemos los comentarios para evitar
los problemas vuelven a suceder o habilita más rápido
Detección y recuperación. Al hacer esto, creamos calidad
en la fuente y generar o incorporar conocimiento donde
es necesario, esto nos permite crear sistemas cada vez más seguros de
trabajar donde se encuentran y solucionan problemas mucho antes de un
Se produce una falla catastrófica.

Al ver los problemas a medida que ocurren y enjambrarlos

hasta que las contramedidas efectivas estén en su lugar, nosotros
acortar y amplificar continuamente nuestros circuitos de retroalimentación, un
principio básico de prácticamente todas las mejoras de procesos modernos
metodologías Esto maximiza las oportunidades para nuestro
organización para aprender y mejorar.

La Tercera Vía permite la creación de una generación generosa

confiar en una cultura que apoya una dinámica, disciplinada y

48

enfoque científico para la experimentación y la toma de riesgos,

facilitando la creación de aprendizaje organizacional, tanto

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 49 de 485
 de nuestros éxitos y fracasos. Además, por
acortando y amplificando continuamente nuestros comentarios
bucles, creamos sistemas de trabajo cada vez más seguros y somos
más capaz de correr riesgos y realizar experimentos que
ayúdanos a aprender más rápido que nuestra competencia y ganar en el
mercado.

Como parte de la Tercera Vía, también diseñamos nuestro sistema de

trabajar para que podamos multiplicar los efectos de nuevos
conocimiento, transformando los descubrimientos locales en globales
mejoras Independientemente de donde alguien realice
trabajo, lo hacen con el acumulado y colectivo
experiencia de todos en la organización.

CONCLUSIÓN

En este capítulo, describimos los conceptos de valor

corrientes, el tiempo de entrega como una de las medidas clave de la
efectividad tanto para la fabricación como para la tecnología
flujos de valor y los conceptos de alto nivel detrás de cada
de las Tres Vías, los principios que sustentan DevOps.

En los siguientes capítulos, los principios para cada una de las

Tres formas se describen con mayor detalle. El primero de
estos principios son Flow, que se centra en cómo
cree el flujo rápido de trabajo en cualquier flujo de valor, ya sea
está en fabricación o trabajo tecnológico. Las practicas
que permiten un flujo rápido se describen en la Parte III.

*** En adelante, el ingeniero se refiere a cualquier persona que trabaje en nuestro flujo de valor, no solo a los desarrolladores.

Página 49

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 50 de 485
 ††† De hecho, con técnicas como el desarrollo basado en pruebas, las pruebas se realizan incluso antes de la primera
Se escribe una línea de código.

‡‡‡ En este libro, el término tiempo de proceso se verá favorecido por la misma razón Karen Martin y Mike
Cita de Osterling: “Para minimizar la confusión, evitamos usar el término tiempo de ciclo ya que tiene varios
definiciones sinónimo de tiempo de procesamiento y ritmo o frecuencia de salida, por nombrar algunos ".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 51 de 485
Página 50
51

2 Laprincipios
Los
Fluir
primera forma:
de

En el flujo de valor de la tecnología, el trabajo generalmente fluye de

Desarrollo a Operaciones, las áreas funcionales entre nuestros
negocios y nuestros clientes. La primera forma requiere el rápido y
flujo de trabajo fluido desde el desarrollo hasta las operaciones, para entregar
valor a los clientes rápidamente. Optimizamos para este objetivo global
en lugar de objetivos locales, como la finalización de la función de desarrollo
tasas, prueba de encontrar / corregir relaciones, o medidas de disponibilidad de operaciones.

Aumentamos el flujo al hacer visible el trabajo, al reducir el tamaño de los lotes

e intervalos de trabajo, y construyendo calidad en, previniendo
defectos por pasar a centros de trabajo aguas abajo. Por
acelerando el flujo a través del flujo de valor de la tecnología, nosotros
reducir el tiempo de entrega requerido para cumplir con los requisitos internos y externos
solicitudes de clientes, aumentando aún más la calidad de nuestro trabajo
mientras nos hace más ágiles y capaces de experimentar mejor
competencia.

Nuestro objetivo es disminuir la cantidad de tiempo requerido para los cambios en

desplegarse en producción y aumentar la fiabilidad y
calidad de esos servicios. Pistas sobre cómo hacemos esto en el
El flujo de valor de la tecnología se puede deducir de cómo el Lean

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 52 de 485
 Los principios se aplicaron al flujo de valor de fabricación.

HAGA VISIBLE NUESTRO TRABAJO

Page 52

Una diferencia significativa entre tecnología y fabricación.

El flujo de valor es que nuestro trabajo es invisible. A diferencia de lo físico
procesos, en el flujo de valor de la tecnología no podemos ver fácilmente
donde se impide el flujo o cuando el trabajo se acumula delante de
centros de trabajo restringidos Transferencia de trabajo entre trabajo
los centros suelen ser muy visibles y lentos porque el inventario debe
ser movido físicamente

Sin embargo, en el trabajo tecnológico, el movimiento se puede hacer con un clic de

un botón, como reasignar un ticket de trabajo a otro equipo.
Porque es tan fácil, el trabajo puede rebotar interminablemente entre equipos
debido a información incompleta, o el trabajo puede pasarse a
centros de trabajo aguas abajo con problemas que permanecen completamente
invisible hasta que lleguemos tarde entregando lo que prometimos a la
cliente o nuestra aplicación falla en el entorno de producción.

Para ayudarnos a ver dónde fluye bien el trabajo y dónde está el trabajo
en cola o estancado, necesitamos hacer nuestro trabajo lo más visible posible.
Uno de los mejores métodos para hacerlo es usar tableros de trabajo visuales,
como tableros kanban o tableros de planificación de sprint, donde podemos
representar el trabajo en tarjetas físicas o electrónicas. El trabajo se origina en
la izquierda (a menudo extraída de una cartera de pedidos), se extrae del trabajo
centro a centro de trabajo (representado en columnas) y termina cuando
llega al lado derecho del tablero, generalmente en una columna etiquetada
"Hecho" o "en producción".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 53 de 485
Page 53

Figura 6: Un ejemplo de tablero kanban, que abarca los requisitos, Dev,

Prueba, puesta en escena y en producción (Fuente: David J. Andersen y
Dominica DeGrandis, Kanban para ITOps , materiales de capacitación para
taller, 2012.)

Nuestro trabajo no solo se hace visible, también podemos gestionar nuestro

trabaje para que fluya de izquierda a derecha lo más rápido posible.
Además, podemos medir el tiempo de espera de cuando una tarjeta es
colocado en el tablero para cuando se mueve a la columna "Listo".

Idealmente, nuestro tablero kanban abarcará todo el flujo de valor,

definir el trabajo como completado solo cuando llega al lado derecho de

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 54 de 485
 el tablero (figura 6). El trabajo no se realiza cuando el desarrollo
completa la implementación de una característica; más bien, solo se hace
cuando nuestra aplicación se ejecuta con éxito en producción,
entregando valor al cliente.

Al poner todo el trabajo para cada centro de trabajo en colas y hacerlo

visible, todos los interesados ​pueden priorizar más fácilmente el trabajo en el
contexto de objetivos globales. Hacer esto permite que cada centro de trabajo
tarea única en el trabajo de mayor prioridad hasta que se complete,
Aumento del rendimiento.

LÍMITE DE TRABAJO EN PROCESO (WIP)

En la manufactura, el trabajo diario generalmente es dictado por una producción.

horario que se genera regularmente (por ejemplo, diariamente, semanalmente),

Page 54

establecer qué trabajos deben ejecutarse en función de los pedidos de los clientes,
fechas de vencimiento del pedido, piezas disponibles, etc.

En tecnología, nuestro trabajo suele ser mucho más dinámico, esto es

especialmente el caso en servicios compartidos, donde los equipos deben satisfacer
Las demandas de muchas partes interesadas diferentes. Como resultado, diariamente
el trabajo se vuelve dominado por la prioridad del día , a menudo con
solicitudes de trabajo urgente que llegan a través de cada comunicación
posible mecanismo, incluidos sistemas de tickets, llamadas de interrupción,
correos electrónicos, llamadas telefónicas, salas de chat y escaladas de administración.

Las interrupciones en la fabricación también son muy visibles y costosas,

a menudo requiere romper el trabajo actual y eliminar cualquier
trabajo incompleto en proceso para comenzar el nuevo trabajo. Este alto nivel de
El esfuerzo desalienta las interrupciones frecuentes.

Sin embargo, interrumpir a los trabajadores de la tecnología es fácil, porque el

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 55 de 485
 las consecuencias son invisibles para casi todos, a pesar de que
El impacto negativo en la productividad puede ser mucho mayor que en
fabricación. Por ejemplo, un ingeniero asignado a múltiples
los proyectos deben cambiar entre tareas, incurriendo en todos los costos de
tener que restablecer el contexto, así como las reglas y objetivos cognitivos.

Los estudios han demostrado que el tiempo para completar incluso tareas simples,
como ordenar formas geométricas, se degrada significativamente cuando
multitarea Por supuesto, porque nuestro trabajo en el valor tecnológico
la secuencia es mucho más compleja cognitivamente que la clasificación geométrica
formas, los efectos de la multitarea en el tiempo de proceso son mucho peores.

Podemos limitar la multitarea cuando usamos un tablero kanban para administrar

nuestro trabajo, como codificar y aplicar WIP (trabajo en
progreso) límites para cada columna o centro de trabajo que pone un límite
limitar el número de tarjetas que pueden estar en una columna.

Por ejemplo, podemos establecer un límite de WIP de tres tarjetas para la prueba.
Cuando ya hay tres cartas en la línea de prueba, no hay cartas nuevas
se puede agregar al carril a menos que se complete o retire una tarjeta
de la columna "en el trabajo" y volver a poner en la cola (es decir, poner
la tarjeta de regreso a la columna a la izquierda). Nada puede ser

Página 55

trabajado hasta que se represente primero en una tarjeta de trabajo, reforzando

que todo el trabajo debe hacerse visible.

Dominica DeGrandis, uno de los principales expertos en el uso de kanbans

en las secuencias de valor de DevOps, señala que "controlar el tamaño de la cola [WIP]
es una herramienta de administración extremadamente poderosa, ya que es una de las pocas
Indicadores principales del tiempo de entrega: con la mayoría de los elementos de trabajo, no
sepa cuánto tiempo tomará hasta que se complete realmente ".

Limitar WIP también facilita ver problemas que impiden

finalización del trabajo.† Por ejemplo, cuando limitamos WIP, encontramos
para que no tengamos nada que hacer porque estamos esperando

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 56 de 485
 alguien más. Aunque puede ser tentador comenzar un nuevo trabajo (es decir,
"Es mejor estar haciendo algo que nada"), mucho mejor
la acción sería averiguar qué está causando el retraso y ayudar a solucionar
ese problema. La multitarea mala a menudo ocurre cuando las personas son
asignado a múltiples proyectos, lo que resulta en muchas prioridades
problemas.

En otras palabras, como David J. Andersen, autor de Kanban:

Cambio evolutivo exitoso para su negocio de tecnología ,
bromeó: “Deja de comenzar. Comienza a terminar.

REDUCIR TAMAÑOS DE LOTE

Otro componente clave para crear un flujo suave y rápido es

realizar trabajos en lotes pequeños. Antes de la inclinación
revolución de fabricación, era una práctica común fabricar
en lotes grandes (o lotes), especialmente para operaciones donde
La configuración del trabajo o el cambio entre trabajos era lento o costoso.
Por ejemplo, la producción de paneles de carrocería grandes requiere configuración
troqueles grandes y pesados ​en máquinas de estampado de metal, un proceso que
Podría tomar días. Cuando el costo de cambio es tan caro, lo haríamos
a menudo estampan tantos paneles a la vez como sea posible, creando grandes
lotes para reducir el número de cambios.

Page 56

Sin embargo, los tamaños de lotes grandes dan como resultado niveles vertiginosos de WIP
y altos niveles de variabilidad en el flujo que caen en cascada a través del
planta de fabricación completa. El resultado es largos plazos de entrega y pobre
calidad: si se encuentra un problema en un panel de cuerpo, todo el lote
tiene que ser desechado

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 57 de 485
 Una de las lecciones clave en Lean es que para reducir los tiempos de entrega
y aumentar la calidad, debemos esforzarnos por reducir continuamente el lote
Tamaños. El límite inferior teórico para el tamaño del lote es de una sola pieza.
flujo , donde cada operación se realiza una unidad a la vez. ‡

Las diferencias dramáticas entre los lotes grandes y pequeños pueden

ser visto en la simple simulación de envío de boletines descritos en
Lean Thinking: desterre el desperdicio y cree riqueza en su
Corporación de James P. Womack y Daniel T. Jones.

Supongamos que en nuestro propio ejemplo tenemos diez folletos para enviar y
enviar cada folleto por correo requiere cuatro pasos: doblar el papel, insertar
el papel en el sobre, selle el sobre y selle el
sobre.

La estrategia de lote grande (es decir, "producción en masa") sería

realice secuencialmente una operación en cada uno de los diez folletos.
En otras palabras, primero doblaríamos las diez hojas de papel, luego
inserte cada uno de ellos en sobres, luego selle los diez sobres, y
luego sellarlos.

Por otro lado, en la estrategia de lotes pequeños (es decir, "pieza única
flujo "), todos los pasos necesarios para completar cada folleto son
realizado secuencialmente antes de comenzar en el próximo folleto. En
En otras palabras, doblamos una hoja de papel, la insertamos en el sobre,
sellarlo y sellarlo; solo entonces comenzamos el proceso de nuevo con
La siguiente hoja de papel.

La diferencia entre usar lotes grandes y pequeños es

dramático (ver figura 7) Supongamos que cada una de las cuatro operaciones toma
diez segundos para cada uno de los diez sobres. Con el gran tamaño de lote
estrategia, se produce el primer sobre completado y sellado
solo después de 310 segundos.

57

Peor aún, supongamos que descubrimos durante la operación de sellado de sobres

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 58 de 485
 que cometimos un error en el primer paso de plegado, en este caso, el
lo primero que descubriríamos es que el error es a los doscientos segundos,
y tenemos que replegar y reinsertar los diez folletos en nuestro lote
de nuevo.

Figura 7: Simulación del "juego de sobres" (doblar, insertar, sellar y

sellar el sobre)

(Fuente: Stefan Luyten, "Flujo de una sola pieza: por qué la producción en masa
no es la forma más eficiente de hacer 'cosas' ”, Medium.com, 8 de agosto,
2014, https://medium.com/@stefanluyten/single-piece-flow-
5d2c2bec845b # .9o7sn74ns .)

En contraste, en la estrategia de lotes pequeños se completó la primera

el sobre estampado se produce en solo cuarenta segundos, ocho veces
más rápido que la estrategia de lotes grandes. Y, si cometimos un error en
El primer paso, solo tenemos que rehacer un folleto en nuestro lote.
Los tamaños de lote pequeños resultan en menos WIP, tiempos de entrega más rápidos, más rápido
detección de errores y menos retrabajo.

Los resultados negativos asociados con grandes tamaños de lote son tan
relevante para el flujo de valor de la tecnología como en la fabricación.
Considere cuándo tenemos un cronograma anual para lanzamientos de software,
donde el código de todo un año que tiene el desarrollo
Trabajado en se lanza a la implementación de producción.

Al igual que en la fabricación, este lanzamiento de lotes grandes crea repentinamente,

altos niveles de WIP e interrupciones masivas en todos los niveles posteriores
centros de trabajo, lo que resulta en un flujo deficiente y resultados de baja calidad.
Esto valida nuestra experiencia común de que cuanto mayor sea el cambio
entrando en producción, cuanto más difíciles son los errores de producción
para diagnosticar y reparar, y cuanto más tardan en remediar.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 59 de 485
58

En una publicación sobre Lecciones aprendidas de inicio , Eric Ries afirma: "El lote
el tamaño es la unidad en la que los productos de trabajo se mueven entre etapas en un
proceso de desarrollo [o DevOps]. Para el software, el lote más fácil
para ver es el código. Cada vez que un ingeniero registra el código, son
agrupando una cierta cantidad de trabajo. Hay muchas tecnicas
para controlar estos lotes, que van desde los pequeños lotes
necesario para el despliegue continuo en sucursales más tradicionales
desarrollo basado, donde todo el código de múltiples
los desarrolladores que trabajan durante semanas o meses se agrupan y
integrados juntos ".

El equivalente al flujo de una sola pieza en el flujo de valor de la tecnología.

se realiza con despliegue continuo, donde cada cambio
comprometido con el control de versiones se integra, se prueba y se implementa
en producción Las prácticas que permiten esto se describen en
Parte IV

REDUCIR EL NÚMERO DE ESPOSAS

En el flujo de valor de la tecnología, siempre que tengamos mucho

plazos de implementación medidos en meses, a menudo es porque
hay cientos (o incluso miles) de operaciones requeridas para
mover nuestro código del control de versiones a la producción
ambiente. Para transmitir código a través del flujo de valor se requiere
múltiples departamentos para trabajar en una variedad de tareas, que incluyen
pruebas funcionales, pruebas de integración, creación de entornos,
administración del servidor, administración de almacenamiento, redes, carga
equilibrio y seguridad de la información.

Cada vez que el trabajo pasa de un equipo a otro, requerimos todo tipo
de comunicación: solicitud, especificación, señalización, coordinación,
y a menudo priorizando, programando, desconfiando, probando y
verificar Esto puede requerir el uso de diferentes tickets o proyectos
sistemas de gestión; redacción de documentos de especificaciones técnicas;

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 60 de 485
 comunicarse a través de reuniones, correos electrónicos o llamadas telefónicas; y usando el archivo
recursos compartidos del sistema, servidores FTP y páginas Wiki.

Page 59

Cada uno de estos pasos es una cola potencial donde el trabajo esperará cuando
confiamos en recursos que se comparten entre diferentes valores
flujos (por ejemplo, operaciones centralizadas). Los plazos de entrega de estos
las solicitudes son a menudo tan largas que hay una escalada constante para tener
trabajo realizado dentro de los plazos necesarios.

Incluso en las mejores circunstancias, algo de conocimiento es inevitable

perdido con cada traspaso. Con suficientes traspasos, el trabajo puede
perder completamente el contexto del problema que se está resolviendo o el
objetivo organizativo que se apoya. Por ejemplo, un servidor
el administrador puede ver un ticket recién creado solicitando a ese usuario
crear cuentas sin saber qué aplicación o servicio
es por qué necesita ser creado, cuáles son todas las dependencias,
o si es realmente un trabajo recurrente.

Para mitigar este tipo de problemas, nos esforzamos por reducir el

cantidad de traspasos, ya sea automatizando porciones significativas de
el trabajo o reorganizando equipos para que puedan entregar valor al
cliente, en lugar de tener que estar constantemente
Depende de los demás. Como resultado, aumentamos el flujo al reducir el
cantidad de tiempo que nuestro trabajo pasa esperando en la cola, así como
la cantidad de tiempo sin valor agregado. Ver Apéndice 4 .

IDENTIFICAR Y ELEVAR CONTINUAMENTE

NUESTRAS RESTRICCIONES

Para reducir los tiempos de entrega y aumentar el rendimiento, necesitamos

Identificar continuamente las limitaciones de nuestro sistema y mejorar su trabajo.
capacidad. En Beyond the Goal , el Dr. Goldratt afirma: "En cualquier valor

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 61 de 485
 corriente, siempre hay una dirección de flujo, y siempre hay una
y solo restricción; cualquier mejora no realizada en esa restricción
es una ilusión ". Si mejoramos un centro de trabajo que se posiciona
antes de la restricción, el trabajo simplemente se acumulará en el cuello de botella
aún más rápido, esperando que el cuello de botella realice el trabajo
centro de trabajo.

60

Por otro lado, si mejoramos un centro de trabajo posicionado después

el cuello de botella, sigue hambriento, esperando que el trabajo despeje el
embotellamiento. Como solución, el Dr. Goldratt definió los "cinco enfoques
pasos":

Identificar la restricción del sistema.

Decide cómo explotar la restricción del sistema.

Subordinar todo lo demás a las decisiones anteriores.

Eleve la restricción del sistema.

Si en los pasos anteriores se ha roto una restricción, regrese

al primer paso, pero no permita que la inercia provoque un sistema
restricción.

En las transformaciones típicas de DevOps, a medida que avanzamos desde

plazos de implementación medidos en meses o trimestres para liderar
veces medidas en minutos, la restricción generalmente sigue esto
progresión:

Creación del entorno: no podemos lograr implementaciones en

exigir si siempre tenemos que esperar semanas o meses para
entornos de producción o prueba. La contramedida es
crear entornos que sean a la demanda y completamente autónomos

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 62 de 485
 servicio, para que siempre estén disponibles cuando los necesitemos.

Implementación de código: no podemos lograr implementaciones en

exigir si cada una de nuestras implementaciones de código de producción toma
semanas o meses para realizar (es decir, cada implementación requiere
1.300 pasos manuales propensos a errores, que involucran hasta tres
cien ingenieros). La contramedida es automatizar nuestro
despliegues tanto como sea posible, con el objetivo de ser
completamente automatizado para que pueda ser autoservicio por cualquier
desarrollador.

Página 61

Configuración y ejecución de prueba: no podemos lograr implementaciones en

exigir si cada implementación de código requiere dos semanas para configurar
nuestros entornos de prueba y conjuntos de datos, y otras cuatro semanas para
ejecutar manualmente todas nuestras pruebas de regresión. La contramedida
es automatizar nuestras pruebas para que podamos ejecutar implementaciones de manera segura
y para paralelizarlos para que la tasa de prueba pueda mantenerse al día con nuestra
tasa de desarrollo del código.

Arquitectura demasiado ajustada: no podemos lograr implementaciones

bajo demanda si la arquitectura demasiado ajustada significa que cada vez
queremos hacer un cambio de código tenemos que enviar a nuestros ingenieros
a decenas de reuniones del comité para obtener permiso para
Haz nuestros cambios. Nuestra contramedida es crear más
arquitectura débilmente acoplada para que se puedan hacer cambios
de forma segura y con más autonomía, aumentando el desarrollador
productividad.

Después de que se hayan roto todas estas restricciones, nuestra restricción

probablemente sea el desarrollo o los propietarios del producto. Porque nuestro objetivo es

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 63 de 485
 para permitir que pequeños equipos de desarrolladores se desarrollen independientemente,
prueba y despliegue valor a los clientes de forma rápida y confiable, esto es
donde queremos que esté nuestra restricción. Alto rendimiento, independientemente
de si un ingeniero está en Desarrollo, QA, Ops o Infosec,
declare que su objetivo es ayudar a maximizar la productividad del desarrollador.

Cuando la restricción está aquí, solo estamos limitados por el número de

buenas hipótesis de negocio que creamos y nuestra capacidad para desarrollar el
código necesario para probar estas hipótesis con clientes reales.

La progresión de las restricciones enumeradas anteriormente son generalizaciones de

transformaciones típicas: técnicas para identificar la restricción en
flujos de valor reales, como a través del mapeo de flujo de valor y
medidas, se describen más adelante en este libro.

ELIMINAR DIFICULTADES Y RESIDUOS EN

LA CORRIENTE DE VALOR

Page 62

Shigeo Shingo, uno de los pioneros de la producción de Toyota

Sistema, cree que los residuos constituyen la mayor amenaza para
viabilidad comercial: la definición comúnmente utilizada en Lean es "la
uso de cualquier material o recurso más allá de lo que el cliente
requiere y está dispuesto a pagar ". Definió siete tipos principales de
Residuos de fabricación: inventario, sobreproducción, extra
procesamiento, transporte, espera, movimiento y defectos.

Las interpretaciones más modernas de Lean han señalado que "eliminar

desperdicio ”puede tener un contexto degradante y deshumanizante; en lugar,
El objetivo se reformula para reducir las dificultades y el trabajo pesado en nuestro diario
trabajar a través del aprendizaje continuo para lograr el
objetivos de la organización. Para el resto de este libro, el término
desperdicio implicará esta definición más moderna, ya que

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 64 de 485
 coincide con los ideales de DevOps y los resultados deseados.
En el libro Implementing Lean Software Development: From
Concept to Cash , Mary y Tom Poppendieck describen el desperdicio y
dificultades en el flujo de desarrollo de software como cualquier cosa que
causa demoras para el cliente, como actividades que pueden ser
anulado sin afectar el resultado.

Las siguientes categorías de desechos y dificultades provienen de

Implementación de desarrollo de software Lean a menos que se indique lo contrario
célebre:

Trabajo realizado parcialmente: esto incluye cualquier trabajo en el valor

transmisión que no se ha completado (por ejemplo, requisito
documentos u órdenes de cambio aún no revisados) y trabajo que es
sentado en la cola (por ejemplo, esperando la revisión de control de calidad o el administrador del servidor
boleto). El trabajo parcialmente realizado se vuelve obsoleto y pierde valor
a medida que pasa el tiempo

Procesos adicionales: cualquier trabajo adicional que se esté realizando

realizado en un proceso que no agrega valor al
cliente. Esto puede incluir documentación no utilizada en un
centro de trabajo aguas abajo, o revisiones o aprobaciones que no

Page 63

agregar valor a la salida. Los procesos adicionales agregan esfuerzo y

aumentar los plazos de entrega

Características adicionales: características integradas en el servicio que no son

que necesita la organización o el cliente (por ejemplo, "oro
enchapado"). Las características adicionales agregan complejidad y esfuerzo a las pruebas
y gestión de funcionalidad.

Cambio de tareas: cuando las personas se asignan a múltiples

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 65 de 485
 proyectos y flujos de valor, que requieren que cambien de contexto
y administrar dependencias entre el trabajo, agregando adicional
esfuerzo y tiempo en el flujo de valor.

En espera: cualquier retraso entre trabajos que requiera recursos para esperar
hasta que puedan completar el trabajo actual. Los retrasos aumentan el ciclo
tiempo y evitar que el cliente obtenga valor.

Movimiento: la cantidad de esfuerzo para mover información o

materiales de un centro de trabajo a otro. Lata de residuos de movimiento
ser creado cuando las personas que necesitan comunicarse con frecuencia
No están colocados. Las transferencias también crean desperdicio de movimiento y, a menudo
requieren comunicación adicional para resolver ambigüedades.

Defectos: información, materiales incorrectos, faltantes o poco claros,

o los productos generan desperdicio, ya que se necesita un esfuerzo para resolverlos
cuestiones. Cuanto mayor sea el tiempo entre la creación del defecto y el defecto
detección, cuanto más difícil es resolver el defecto.

Trabajo no estándar o manual: dependencia de no estándar

o trabajo manual de otros, como el uso de no reconstrucción
servidores, entornos de prueba y configuraciones. Idealmente, cualquier
Las dependencias de las operaciones deben ser automáticas,
con servicio y disponible bajo demanda.

Heroica: para que una organización logre objetivos,

los individuos y los equipos se colocan en una posición donde deben
realizar actos irracionales, que incluso pueden formar parte de

Página 64

su trabajo diario (p. ej., problemas nocturnos a las 2:00 a. m. en

producción, creando cientos de tickets de trabajo como parte de cada
lanzamiento de software). §

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 66 de 485
 Nuestro objetivo es generar estos desechos y dificultades en cualquier lugar
la heroicidad se hace necesaria, visible y hacer sistemáticamente lo que
es necesario para aliviar o eliminar estas cargas y dificultades para
Alcanzar nuestro objetivo de flujo rápido.

CONCLUSIÓN

Mejorar el flujo a través del flujo de valor de la tecnología es esencial

para lograr los resultados de DevOps. Hacemos esto haciendo trabajo
visible, limitando WIP, reduciendo los tamaños de lote y la cantidad de
transferencias, identificando y evaluando continuamente nuestras limitaciones,
y eliminando dificultades en nuestro trabajo diario.

Las prácticas específicas que permiten un flujo rápido en el valor DevOps

flujo se presentan en la Parte IV. En el próximo capítulo, presentamos
La segunda vía: los principios de la retroalimentación.

† Taiichi Ohno comparó el cumplimiento de los límites de WIP con el drenaje de agua del río de inventario para revelar todo
Los problemas que obstruyen el flujo rápido.

‡ También conocido como "tamaño de lote de uno" o "flujo 1x1", términos que se refieren al tamaño de lote y un límite WIP de uno.

§ Aunque la heroicidad no se incluye en las categorías de desechos de Poppendieck, se incluye aquí debido a la frecuencia
ocurre, especialmente en la operación de servicios compartidos.

Página 66
65

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 67 de 485
 3 Laprincipios
Los segunda forma:
Realimentación
de

Mientras que First Way describe los principios que permiten el flujo rápido de
trabajar de izquierda a derecha, la Segunda Vía describe los principios que
permitir la retroalimentación recíproca rápida y constante de derecha a izquierda
etapas del flujo de valor. Nuestro objetivo es crear un lugar cada vez más seguro y más
sistema de trabajo resistente.

Esto es especialmente importante cuando se trabaja en sistemas complejos, cuando

La primera oportunidad para detectar y corregir errores es típicamente cuando un
evento catastrófico está en marcha, como un trabajador de fabricación
herido en el trabajo o la fusión de un reactor nuclear en progreso.

En tecnología, nuestro trabajo ocurre casi por completo dentro de complejos

sistemas con alto riesgo de consecuencias catastróficas. Como en
fabricación, a menudo descubrimos problemas solo cuando hay grandes fallas
en curso, como un corte de producción masivo o una violación de seguridad
resultando en el robo de datos del cliente.

Hacemos que nuestro sistema de trabajo sea más seguro mediante la creación rápida, frecuente y alta
flujo de información de calidad a lo largo de nuestro flujo de valor y nuestro
organización, que incluye retroalimentación y bucles de retroalimentación. Esta
nos permite detectar y remediar problemas mientras son más pequeños,
más barato y más fácil de arreglar; evitar problemas antes de que causen
catástrofe; y crear aprendizaje organizacional que integramos en
trabajo futuro. Cuando ocurren fallas y accidentes, los tratamos como
oportunidades de aprendizaje, en oposición a una causa de castigo y
culpa. Para lograr todo lo anterior, primero exploremos la naturaleza de
sistemas complejos y cómo pueden hacerse más seguros.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 68 de 485
Page 67

TRABAJAR CON SEGURIDAD DENTRO DEL COMPLEJO

SISTEMAS

Una de las características definitorias de un sistema complejo es que desafía

la capacidad de cualquier persona para ver el sistema como un todo y comprender
cómo encajan todas las piezas Los sistemas complejos suelen tener un alto
grado de interconexión de componentes estrechamente acoplados, y
el comportamiento a nivel del sistema no puede explicarse simplemente en términos de
comportamiento de los componentes del sistema.

El Dr. Charles Perrow estudió la crisis de Three Mile Island y observó

que era imposible que alguien entendiera cómo funcionaría el reactor
comportarse en todas las circunstancias y cómo podría fallar. Cuando un problema era
en marcha en un componente, era difícil aislarlo del otro
componentes, que fluyen rápidamente a través de los caminos de menor resistencia en
formas impredecibles

Dr. Sidney Dekker, quien también codificó algunos de los elementos clave de seguridad.
cultura, observó otra característica de los sistemas complejos: hacer el
Lo mismo dos veces no conducirá previsiblemente o necesariamente a lo mismo
resultado. Es esta característica que hace listas de verificación estáticas y mejor
prácticas, aunque valiosas, insuficientes para evitar catástrofes
ocurriendo VerApéndice 5.

Por lo tanto, porque el fracaso es inherente e inevitable en complejos

sistemas, debemos diseñar un sistema de trabajo seguro, ya sea en
fabricación o tecnología, donde podemos realizar trabajos sin miedo,
confía en que cualquier error se detectará rápidamente, mucho antes de que
causar resultados catastróficos, como lesiones laborales, defectos del producto o
Impacto negativo en el cliente.

Después de descifrar el mecanismo causal detrás del Producto Toyota

Sistema como parte de su tesis doctoral en la Harvard Business School, Dr.
Steven Spear declaró que el diseño de sistemas perfectamente seguros es probable
más allá de nuestras capacidades, pero podemos hacer que sea más seguro trabajar en complejos
sistemas cuando se cumplen las cuatro condiciones siguientes:†

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 69 de 485
 El trabajo complejo se gestiona de modo que los problemas de diseño y
las operaciones se revelan

Página 68

Los problemas se enjambran y se resuelven, lo que resulta en una construcción rápida de

nuevos conocimientos

El nuevo conocimiento local se explota a nivel mundial en todo el

organización

Los líderes crean otros líderes que continuamente hacen crecer este tipo de
capacidades

Se requiere que cada una de estas capacidades trabaje de manera segura en un complejo
sistema. En las siguientes secciones, las dos primeras capacidades y sus
importancia se describen, así como cómo se han creado en
otros dominios y qué prácticas les permiten en el valor tecnológico
corriente. (Las capacidades tercera y cuarta se describen en el capítulo 4).

VEA LOS PROBLEMAS A medida que OCURREN

En un sistema de trabajo seguro, debemos probar constantemente nuestro diseño y

supuestos de funcionamiento. Nuestro objetivo es aumentar el flujo de información en nuestro
sistema de tantas áreas como sea posible, antes, más rápido, más barato y
con tanta claridad entre causa y efecto como sea posible. Mas
supuestos que podemos invalidar, cuanto más rápido podamos encontrar y solucionar problemas,
aumentando nuestra capacidad de recuperación, agilidad y capacidad de aprender e innovar.

Hacemos esto creando retroalimentación y bucles de retroalimentación en nuestro sistema

de trabajo. Dr. Peter Senge en su libro La Quinta Disciplina: El Arte y
La práctica de la Organización de Aprendizaje describió los circuitos de retroalimentación como
Parte crítica del aprendizaje de las organizaciones y el pensamiento sistémico. Realimentación
y los bucles de avance hacen que los componentes dentro de un sistema se refuercen

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 70 de 485
 o contrarrestarse unos a otros.
En la fabricación, la ausencia de retroalimentación efectiva a menudo contribuye a
Principales problemas de calidad y seguridad. En un caso bien documentado en el
Planta de fabricación de General Motors Fremont, no hubo efectivo
procedimientos establecidos para detectar problemas durante el proceso de ensamblaje,
ni hubo procedimientos explícitos sobre qué hacer cuando los problemas eran
encontró. Como resultado, hubo instancias de motores en funcionamiento.
hacia atrás, a los autos les faltan volantes o llantas, y los autos incluso tienen que
ser remolcado fuera de la línea de montaje porque no comenzarían.

Página 69

Por el contrario, en las operaciones de fabricación de alto rendimiento hay un rápido,

flujo de información frecuente y de alta calidad en todo el valor
flujo: cada operación de trabajo se mide y supervisa, y cualquier
Los defectos o desviaciones significativas se encuentran rápidamente y se actúa sobre ellos.
Estos son los cimientos de lo que permite la calidad, la seguridad y la continuidad.
aprendizaje y mejora.

En el flujo de valor de la tecnología, a menudo obtenemos malos resultados debido a

La ausencia de retroalimentación rápida. Por ejemplo, en un software de cascada
proyecto, podemos desarrollar código para todo un año y no recibir comentarios sobre
calidad hasta que comenzamos la fase de prueba, o peor, cuando lanzamos nuestro
software para clientes. Cuando la retroalimentación es tan tardía e infrecuente,
es demasiado lento para permitirnos prevenir resultados no deseados.

Por el contrario, nuestro objetivo es crear retroalimentación rápida y bucles de avance rápido
dondequiera que se realice el trabajo, en todas las etapas del valor de la tecnología
flujo, que abarca la gestión de productos, desarrollo, control de calidad,
Infosec, y Operaciones. Esto incluye la creación de compilación automatizada,
integración y procesos de prueba, para que podamos detectar inmediatamente cuándo
Se ha introducido un cambio que nos saca de un correcto
estado funcional y desplegable.

También creamos telemetría generalizada para que podamos ver cómo todo nuestro sistema
los componentes operan en el entorno de producción, por lo que
puede detectar rápidamente cuando no están funcionando como se esperaba. Telemetría

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 71 de 485
 también nos permite medir si estamos logrando nuestros objetivos previstos
e, idealmente, se irradia a todo el flujo de valor para que podamos ver cómo
Nuestras acciones afectan a otras partes del sistema como un todo.

Los bucles de retroalimentación no solo permiten la detección y recuperación rápidas de

problemas, pero también nos informan sobre cómo prevenir estos problemas
de ocurrir nuevamente en el futuro. Hacer esto aumenta la calidad y
seguridad de nuestro sistema de trabajo, y crea aprendizaje organizacional.

Como Elisabeth Hendrickson, vicepresidenta de ingeniería de Pivotal Software, Inc.

y autor de Explore It !: Reduce el riesgo y aumenta la confianza con
Pruebas exploratorias , dijo: "Cuando dirigí la ingeniería de calidad, yo
describió mi trabajo como "crear ciclos de retroalimentación". La retroalimentación es crítica
porque es lo que nos permite dirigirnos. Debemos validar constantemente

Page 70

entre las necesidades del cliente, nuestras intenciones y nuestras implementaciones.

Las pruebas son simplemente un tipo de retroalimentación ”.

ENJUAGUE Y RESUELVE PROBLEMAS PARA CONSTRUIR

NUEVOS CONOCIMIENTOS

Obviamente, no es suficiente detectar simplemente cuando lo inesperado

ocurre. Cuando ocurren problemas, debemos enjambrarlos, movilizar
quien sea requerido para resolver el problema.

Según el Dr. Spear, el objetivo del enjambre es contener problemas

antes de que tengan la oportunidad de propagarse y diagnosticar y tratar el
problema para que no pueda repetirse. "Al hacerlo", dice, "construyen siempre-
conocimiento más profundo sobre cómo administrar los sistemas para hacer nuestro
trabajo, convirtiendo la inevitable ignorancia inicial en conocimiento ".

El modelo de este principio es el cable Toyota Andon . En da Toyota

planta de fabricación, encima de cada centro de trabajo hay un cable que cada

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 72 de 485
 el trabajador y el gerente están capacitados para tirar cuando algo sale mal; para
ejemplo, cuando una parte es defectuosa, cuando una parte requerida no está disponible,
o incluso cuando el trabajo lleva más tiempo de lo documentado. ‡

Cuando se tira del cordón de Andon, se alerta al líder del equipo y

inmediatamente trabaja para resolver el problema. Si el problema no puede ser
resuelto dentro de un tiempo especificado (por ejemplo, cincuenta y cinco segundos), la producción
la línea se detiene para que toda la organización pueda movilizarse para ayudar
con resolución de problemas hasta que se haya tomado una contramedida exitosa
desarrollado.

En lugar de solucionar el problema o programar una solución "cuando

tener más tiempo ", pululamos para arreglarlo de inmediato, esto es casi el
opuesto al comportamiento en la planta de GM Fremont descrito anteriormente.
El enjambre es necesario por las siguientes razones:

Impide que el problema progrese aguas abajo, donde el

el costo y el esfuerzo para repararlo aumentan exponencialmente y la deuda técnica
se permite acumular

Impide que el centro de trabajo comience un nuevo trabajo, lo que probablemente

Introducir nuevos errores en el sistema.

Page 71

Si no se soluciona el problema, el centro de trabajo podría potencialmente

tiene el mismo problema en la próxima operación (por ejemplo, cincuenta y cinco segundos
más tarde), que requieren más arreglos y trabajo. VerApéndice 6.

Esta práctica de enjambre parece contraria a la gestión común

práctica, ya que deliberadamente permitimos que un problema local interrumpa
operaciones a nivel mundial. Sin embargo, el enjambre permite el aprendizaje. Previene
la pérdida de información crítica debido a recuerdos que se desvanecen o cambian
circunstancias. Esto es especialmente crítico en sistemas complejos, donde
muchos problemas ocurren debido a algunos inesperados, idiosincrásicos
interacción de personas, procesos, productos, lugares y circunstancias:
A medida que pasa el tiempo, se hace imposible reconstruir exactamente lo que fue

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 73 de 485
 sucediendo cuando ocurrió el problema.
Como señala el Dr. Spear, el enjambre es parte del "ciclo disciplinado de
reconocimiento de problemas de tiempo, diagnóstico, ... y tratamiento (contramedidas
o medidas correctivas en la fabricación vernácula). Es el
disciplina del ciclo de Shewhart: planificar, hacer, verificar, actuar, popularizado por
W. Edwards Deming, pero aceleró a la velocidad de deformación ".

Es solo a través del enjambre de problemas cada vez más pequeños descubiertos
cada vez más temprano en el ciclo de vida que podemos desviar problemas antes de un
Se produce una catástrofe. En otras palabras, cuando el reactor nuclear se derrite
abajo, ya es demasiado tarde para evitar los peores resultados.

Para permitir una retroalimentación rápida en el flujo de valor de la tecnología, debemos crear
el equivalente de un cable Andon y la respuesta de enjambre relacionada.
Esto requiere que también creamos la cultura que lo haga seguro, y
incluso alentado, a tirar del cordón de Andon cuando algo sale mal,
si es cuando ocurre un incidente de producción o cuando ocurren errores
anteriormente en la secuencia de valor, como cuando alguien introduce un cambio
eso rompe nuestros procesos continuos de construcción o prueba.

Cuando las condiciones desencadenan un tirón del cable Andon, enjambramos para resolver el
problema y evitar la introducción de nuevos trabajos hasta que el problema haya
resuelto§ Esto proporciona retroalimentación rápida para todos en el valor
stream (especialmente la persona que causó la falla del sistema), nos permite
para aislar y diagnosticar rápidamente el problema, y ​evita más
factores complicados que pueden ocultar la causa y el efecto.

Page 72

Prevenir la introducción de nuevos trabajos permite la continua

integración y despliegue, que es flujo de una sola pieza en el
flujo de valor tecnológico. Todos los cambios que pasan nuestra construcción continua
y las pruebas de integración se implementan en producción, y cualquier cambio
que hacen que las pruebas fallen, activan nuestro cable de Andon y se enjambran
hasta que se resuelva.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 74 de 485
 MANTENGA LA CALIDAD DE EMPUJE MÁS CERCA DE LA
FUENTE

Inadvertidamente podemos perpetuar sistemas de trabajo inseguros debido a la

forma en que respondemos a accidentes e incidentes. En sistemas complejos, agregar
más pasos de inspección y procesos de aprobación en realidad aumentan el
probabilidad de fallas futuras. La efectividad de los procesos de aprobación.
disminuye a medida que empujamos la toma de decisiones más lejos de donde el
Se realiza el trabajo. Hacerlo no solo disminuye la calidad de las decisiones sino que
también aumenta nuestro tiempo de ciclo, disminuyendo así la fuerza del
retroalimentación entre causa y efecto, y reducir nuestra capacidad de aprender
de éxitos y fracasos. ¶

Esto se puede ver incluso en sistemas más pequeños y menos complejos. Cuando arriba
abajo, los sistemas burocráticos de mando y control se vuelven ineficaces,
generalmente se debe a la diferencia entre "quién debería hacer algo"
y "quién realmente está haciendo algo" es demasiado grande, debido a insuficiente
claridad y actualidad.

Los ejemplos de controles de calidad ineficaces incluyen:

Requerir que otro equipo complete tedioso, propenso a errores y

tareas manuales que podrían automatizarse fácilmente y ejecutarse según sea necesario
el equipo que necesita el trabajo realizado

Requerir aprobaciones de personas ocupadas que están distantes del

trabajar, obligándolos a tomar decisiones sin una adecuada
conocimiento del trabajo o las posibles implicaciones, o simplemente
sello de goma sus aprobaciones

Crear grandes volúmenes de documentación de detalles cuestionables.

que se vuelven obsoletas poco después de que se escriben

Page 73

Empujar grandes lotes de trabajo a equipos y comités especiales para

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 75 de 485
 aprobación y procesamiento y luego esperando respuestas
En cambio, necesitamos que todos en nuestro flujo de valor encuentren y solucionen problemas
en su área de control como parte de nuestro trabajo diario. Al hacer esto, empujamos
responsabilidades de calidad y seguridad y toma de decisiones donde
el trabajo se realiza, en lugar de depender de aprobaciones de distancia
ejecutivos

Utilizamos revisiones por pares de nuestros cambios propuestos para obtener lo que sea
Se necesita garantía de que nuestros cambios funcionarán según lo diseñado. Nosotros
Automatizar la mayor parte del control de calidad que generalmente realiza un control de calidad
o departamento de seguridad de la información como sea posible. En lugar de desarrolladores
necesitando solicitar o programar una prueba para que se ejecute, estas pruebas pueden ser
realizado bajo demanda, permitiendo a los desarrolladores probar rápidamente sus propios
codificar e incluso implementar esos cambios en la producción ellos mismos.

Al hacer esto, realmente hacemos de la calidad la responsabilidad de todos como

opuesto a que sea responsabilidad exclusiva de un departamento separado.
La seguridad de la información no es solo el trabajo de la Seguridad de la Información, sino también
la disponibilidad no es simplemente el trabajo de Operaciones.

Hacer que los desarrolladores compartan la responsabilidad de la calidad de los sistemas.

construyen no solo mejoran los resultados sino que también aceleran el aprendizaje.
Esto es especialmente importante para los desarrolladores, ya que generalmente son
equipo que está más alejado del cliente. Gary Gruver
observa: "Es imposible que un desarrollador aprenda algo cuando
alguien les grita por algo que rompieron hace seis meses, eso es
¿Por qué necesitamos proporcionar comentarios a todos lo más rápido posible, en
minutos, no meses ".

HABILITAR OPTIMIZAR PARA BAJAR

CENTROS DE TRABAJO

En la década de 1980, los principios de Diseño para la Manufacturabilidad buscaban

diseñar piezas y procesos para que los productos terminados puedan crearse con
El costo más bajo, la más alta calidad y el flujo más rápido. Ejemplos incluyen
diseñando partes que son muy asimétricas para evitar que

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 76 de 485
Page 74

colocarse al revés, y diseñar sujetadores de tornillo para que estén

imposible de apretar demasiado.

Esto fue una desviación de cómo se hacía típicamente el diseño, que

centrado en los clientes externos pero pasado por alto internos
partes interesadas, como las personas que realizan la fabricación.

Lean define dos tipos de clientes para los que debemos diseñar:
cliente externo (que probablemente paga por el servicio que somos
entrega) y el cliente interno (que recibe y procesa el
trabajar inmediatamente después de nosotros). Según Lean, nuestro más importante
El cliente es nuestro siguiente paso aguas abajo. Optimizando nuestro trabajo para ellos
requiere que tengamos empatía por sus problemas para mejorar
Identificar los problemas de diseño que impiden un flujo rápido y suave.

En el flujo de valor tecnológico, optimizamos para el trabajo posterior

centros diseñando para operaciones, donde operacional no funcional
requisitos (por ejemplo, arquitectura, rendimiento, estabilidad, capacidad de prueba,
configurabilidad y seguridad) tienen una prioridad tan alta como las características del usuario.

Al hacer esto, creamos calidad en la fuente, lo que probablemente resulte en un conjunto de

requisitos no funcionales codificados que podemos integrar de forma proactiva
en cada servicio que construimos.

CONCLUSIÓN

Crear comentarios rápidos es fundamental para lograr calidad, confiabilidad y

seguridad en el flujo de valor tecnológico. Hacemos esto al ver los problemas como
ocurren, pululando y resolviendo problemas para construir nuevos conocimientos,
acercando la calidad a la fuente y optimizando continuamente para
Centros de trabajo aguas abajo.

Las prácticas específicas que permiten un flujo rápido en la secuencia de valor de DevOps
se presentan en la Parte IV. En el próximo capítulo, presentamos la Tercera Vía:
Los principios de retroalimentación

† El Dr. Spear extendió su trabajo para explicar los éxitos duraderos de otras organizaciones, como el proveedor de Toyota
network, Alcoa, y el Programa de Propulsión de Energía Nuclear de la Marina de los EE. UU.

‡ En algunas de sus plantas, Toyota ha pasado a usar un botón Andon.

§ Sorprendentemente, cuando el número de tirones del cable Andon disminuye, los gerentes de planta disminuirán las tolerancias para obtener un
aumento en el número de tirones de cable Andon para continuar permitiendo más aprendizajes y mejoras y para
detectar señales de falla cada vez más débiles.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 77 de 485
 ¶ En la década de 1700, el gobierno británico participó en un espectacular ejemplo de mando y control burocrático de arriba hacia abajo,
que resultó notablemente ineficaz. En ese momento, Georgia todavía era una colonia, y a pesar del hecho de que los británicos

Página 75

el gobierno estaba a tres mil millas de distancia y carecía de conocimiento de primera mano sobre la química local de la tierra, la rocosa
topografía, accesibilidad al agua y otras condiciones, trató de planificar toda la economía agrícola de Georgia. los
Los resultados del intento fueron pésimos y dejaron a Georgia con los niveles más bajos de prosperidad y población en los trece
colonias

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 78 de 485
Page 77
76

4 Los
Laprincipios de
tercera vía:
Aprendizaje continuo
y experimentación

Mientras que First Way aborda el flujo de trabajo de izquierda a derecha y el

Second Way aborda la retroalimentación recíproca rápida y constante de
de derecha a izquierda, la Tercera Vía se enfoca en crear una cultura de continuo
aprendizaje y experimentación. Estos son los principios que permiten
creación constante de conocimiento individual, que luego se convierte en
equipo y conocimiento organizacional.

En operaciones de fabricación con calidad y seguridad sistémicas.

problemas, el trabajo suele estar rígidamente definido y aplicado. Por ejemplo,
en la planta de GM Fremont descrita en el capítulo anterior, los trabajadores
tenía poca capacidad para integrar mejoras y aprendizajes en sus
trabajo diario, con sugerencias de mejora "apto para enfrentarse a una pared de ladrillos
de indiferencia ".

En estos entornos, a menudo también existe una cultura de miedo y baja

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 79 de 485
 confianza, donde los trabajadores que cometen errores son castigados, y aquellos que
hacer sugerencias o señalar problemas son vistos como denunciantes
y alborotadores. Cuando esto ocurre, el liderazgo es activamente
suprimir, incluso castigar, aprender y mejorar, perpetuar
problemas de calidad y seguridad.

Por el contrario, las operaciones de fabricación de alto rendimiento requieren y

Promover activamente el aprendizaje: en lugar de definir rígidamente el trabajo, el
el sistema de trabajo es dinámico, con trabajadores de línea que realizan experimentos
en su trabajo diario para generar nuevas mejoras, habilitadas por rigurosos
estandarización de los procedimientos de trabajo y documentación de los resultados.

78 de 1189.

En el flujo de valor de la tecnología, nuestro objetivo es crear una alta confianza

cultura, reforzando que todos somos aprendices de por vida que debemos tomar riesgos
en nuestro trabajo diario Aplicando un enfoque científico a ambos procesos
mejora y desarrollo de productos, aprendemos de nuestros éxitos
y fracasos, identificando qué ideas no funcionan y reforzando esas
Esto hace. Además, cualquier aprendizaje local se convierte rápidamente en global.
mejoras, para que las nuevas técnicas y prácticas puedan ser utilizadas por el
organización entera.

Reservamos tiempo para la mejora del trabajo diario y para avanzar

acelerar y asegurar el aprendizaje Constantemente introducimos el estrés en
nuestros sistemas para forzar la mejora continua. Incluso simulamos y
inyectar fallas en nuestros servicios de producción bajo condiciones controladas para
Aumentar nuestra resistencia.

Al crear este sistema continuo y dinámico de aprendizaje, permitimos

equipos para adaptarse rápida y automáticamente a un cambio constante
entorno, que en última instancia nos ayuda a ganar en el mercado.

HABILITAR EL APRENDIZAJE ORGANIZACIONAL Y

UNA CULTURA DE SEGURIDAD

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 80 de 485
 Cuando trabajamos dentro de un sistema complejo, por definición es imposible
para que podamos predecir perfectamente todos los resultados de cualquier acción que tomemos. Esta
es lo que contribuye a resultados inesperados, o incluso catastróficos, y
accidentes en nuestro trabajo diario, incluso cuando tomamos precauciones y trabajamos
cuidadosamente.

Cuando estos accidentes afectan a nuestros clientes, buscamos entender por qué
sucedió. La causa raíz a menudo se considera un error humano, y el
Una respuesta administrativa muy común es "nombre, culpa y vergüenza"
La persona que causó el problema. † Y, ya sea sutil o explícitamente,
la gerencia insinúa que la persona culpable de cometer el error
ser castigado. Luego crean más procesos y aprobaciones para evitar
el error vuelve a suceder.

Dr. Sidney Dekker, quien codificó algunos de los elementos clave de seguridad.
cultura y acuñó el término cultura justa , escribió: "Respuestas a incidentes
y los accidentes que se consideran injustos pueden impedir las investigaciones de seguridad,

Página 79

Promover el miedo en lugar de la atención plena en las personas que son críticas para la seguridad.
trabajar, hacer que las organizaciones sean más burocráticas en lugar de tener más cuidado,
y cultivar el secreto profesional, la evasión y la autoprotección ".

Estos problemas son especialmente problemáticos en el flujo de valor de la tecnología.

—Nuestro trabajo casi siempre se realiza dentro de un sistema complejo, y
cómo la gerencia elige reaccionar ante fallas y accidentes conduce a una
cultura del miedo, lo que hace improbable que los problemas y el fracaso
las señales son reportadas alguna vez. El resultado es que los problemas permanecen ocultos.
hasta que ocurra una catástrofe.

El Dr. Ron Westrum fue uno de los primeros en observar la importancia de

cultura organizacional en seguridad y desempeño. Observó que en
organizaciones de salud, la presencia de culturas "generativas" fue uno
de los principales predictores de seguridad del paciente. El Dr. Westrum definió tres tipos
de Cultura:

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 81 de 485
 Las organizaciones patológicas se caracterizan por grandes cantidades de
Miedo y amenaza. La gente suele acumular información, retenerla por
razones políticas, o distorsionarlo para que se vean mejor.
El fracaso a menudo está oculto.

Las organizaciones burocráticas se caracterizan por reglas y procesos,

a menudo para ayudar a departamentos individuales a mantener su "territorio". El fracaso es
procesado a través de un sistema de juicio, lo que resulta en
castigo o justicia y misericordia.

Las organizaciones generativas se caracterizan por buscar activamente y

compartir información para permitir mejor a la organización lograr su
misión. Las responsabilidades se comparten en todo el flujo de valor,
y el fracaso da como resultado una reflexión y una investigación genuina .

80

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 82 de 485
 Figura 8: El modelo de tipología organizacional de Westrum: cómo
organizaciones procesan información (Fuente: Ron Westrum, "Una tipología de
cultura organizacional ”, BMJ Quality & Safety 13, no. 2 (2004),
doi: 10.1136 / qshc.2003.009522.)

Tal como el Dr. Westrum encontró en las organizaciones de atención médica, un grupo de alta confianza,
la cultura generativa también predijo el desempeño de TI y organizacional en
flujos de valor tecnológico.

En el flujo de valor tecnológico, establecemos las bases de un

cultura generativa esforzándose por crear un sistema de trabajo seguro. Cuando
ocurren accidentes y fallas, en lugar de buscar errores humanos, nosotros
Busque cómo podemos rediseñar el sistema para evitar el accidente.
sucediendo de nuevo

Por ejemplo, podemos realizar una autopsia sin culpa después de cada
incidente para obtener la mejor comprensión de cómo ocurrió el accidente
y acordar cuáles son las mejores contramedidas para mejorar el
sistema, idealmente evitando que el problema vuelva a ocurrir y
permitiendo una detección y recuperación más rápidas.

Al hacer esto, creamos aprendizaje organizacional. Como Bethany Macri, un

ingeniero en Etsy que dirigió la creación de la herramienta Morgue para ayudar con
grabación de autopsias, declaró: "Al eliminar la culpa, eliminas
temor; al eliminar el miedo, habilitas la honestidad; y la honestidad permite
prevención."

El Dr. Spear observa que el resultado de eliminar la culpa y poner

El aprendizaje organizacional en su lugar es que "las organizaciones se vuelven siempre
más autodiagnóstico y superación personal, experto en detectar problemas
[y] resolviéndolos ".

Página 81

Muchos de estos atributos también fueron descritos por el Dr. Senge como atributos
de organizaciones de aprendizaje. En La quinta disciplina, escribió que estos
características ayudan a los clientes, aseguran la calidad, crean competitividad
ventaja y una fuerza laboral activa y comprometida, y descubrir el
verdad.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 83 de 485
 INSTITUCIONALIZAR LA MEJORA DE
TRABAJO DIARIO

Los equipos a menudo no pueden o no quieren mejorar los procesos que

operar dentro de El resultado no es solo que continúen sufriendo de
sus problemas actuales, pero su sufrimiento también empeora con el tiempo.
Mike Rother observó en Toyota Kata que en ausencia de
mejoras, los procesos no permanecen igual, debido al caos y
Entropía, los procesos en realidad se degradan con el tiempo.

En el flujo de valor de la tecnología, cuando evitamos solucionar nuestros problemas,

confiando en soluciones diarias, nuestros problemas y deudas técnicas
se acumula hasta que todo lo que estamos haciendo es realizar soluciones alternativas, tratando de
evitar desastres, sin ciclos sobrantes para realizar un trabajo productivo. Esto es
por qué Mike Orzen, autor de Lean IT , observó: "Aún más importante
que el trabajo diario es la mejora del trabajo diario ".

Mejoramos el trabajo diario reservando explícitamente el tiempo para pagar

deuda técnica, corregir defectos y refactorizar y mejorar áreas problemáticas
de nuestro código y entornos: lo hacemos reservando ciclos en cada
intervalo de desarrollo, o programando bombardeos kaizen , que son
períodos en que los ingenieros se autoorganizan en equipos para trabajar en la fijación de cualquier
problema que quieren

El resultado de estas prácticas es que todos encuentran y solucionan problemas

en su área de control, todo el tiempo, como parte de su trabajo diario. Cuando
finalmente solucionamos los problemas diarios que hemos trabajado durante meses
(o años), podemos erradicar de nuestro sistema los problemas menos obvios.
Al detectar y responder a estas señales de falla cada vez más débiles, solucionamos
problemas cuando no solo es más fácil y económico sino también cuando
Las consecuencias son menores.

82

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 84 de 485
 Considere el siguiente ejemplo que mejoró la seguridad laboral en
Alcoa, un fabricante de aluminio con ingresos de $ 7.8 mil millones en 1987.
La fabricación de aluminio requiere calor extremadamente alto, presiones altas,
y productos químicos corrosivos. En 1987, Alcoa tenía un historial de seguridad aterrador,
con un 2% de los noventa mil empleados empleados heridos cada uno
año: son siete lesiones por día. Cuando Paul O'Neill comenzó como CEO,
su primer objetivo era tener cero lesiones para empleados, contratistas y
visitantes

O'Neill quería ser notificado dentro de las veinticuatro horas de que alguien
heridos en el trabajo, no para castigar, sino para asegurar y promover eso
se estaban generando e incorporando aprendizajes para crear un lugar más seguro
lugar de trabajo. En el transcurso de diez años, Alcoa redujo su tasa de lesiones
en un 95%.

La reducción en las tasas de lesiones permitió a Alcoa centrarse en los más pequeños
problemas y señales de falla más débiles, en lugar de notificar solo a O'Neill
cuando ocurrieron lesiones, comenzaron a informar también de cualquier llamada cercana. ‡
Al hacer esto, mejoraron la seguridad en el lugar de trabajo sobre el posterior
veinte años y tener uno de los registros de seguridad más envidiable en el
industria.

Como escribe el Dr. Spear, “los alcoanos gradualmente dejaron de trabajar alrededor del
dificultades, inconvenientes e impedimentos que experimentaron.
Afrontamiento, lucha contra incendios y recuperación se fueron reemplazando gradualmente.
en toda la organización mediante una dinámica de identificación de oportunidades
para la mejora de procesos y productos. Como esas oportunidades eran
identificado y los problemas fueron investigados, los focos de ignorancia
que reflejaron se convirtieron en pepitas de conocimiento ". Esta
ayudó a dar a la compañía una mayor ventaja competitiva en el
mercado.

Del mismo modo, en el flujo de valor de la tecnología, a medida que hacemos nuestro sistema de
trabajamos de manera más segura, encontramos y solucionamos problemas de señales de falla cada vez más débiles
Por ejemplo, inicialmente podemos realizar autopsias sin culpa solo para
incidentes que impactan al cliente. Con el tiempo, podemos realizarlos para
incidentes de menor impacto en el equipo y casi accidentes también.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 85 de 485
Page 83

TRANSFORME LOS DESCUBRIMIENTOS LOCALES EN

MEJORAS GLOBALES

Cuando se descubren nuevos aprendizajes localmente, también debe haber algunos

mecanismo para permitir que el resto de la organización use y se beneficie
de ese conocimiento En otras palabras, cuando los equipos o individuos tienen
experiencias que crean experiencia, nuestro objetivo es convertir ese tácito
conocimiento (es decir, conocimiento que es difícil de transferir a otra persona)
por escrito o verbalizando) en explícito, codificado
conocimiento, que se convierte en la experiencia de otra persona a través de la práctica.

Esto asegura que cuando alguien más haga un trabajo similar, lo haga con
la experiencia acumulativa y colectiva de todos en el
organización que alguna vez ha hecho el mismo trabajo. Un ejemplo notable
de convertir el conocimiento local en conocimiento global es la Marina de los EE. UU.
Programa de propulsión de energía nuclear (también conocido como "NR" para "Naval
Reactores "), que tiene más de 5,700 años de operación sin un
Víctima relacionada con un solo reactor o escape de radiación.

El NR es conocido por su intenso compromiso con los procedimientos programados.

y trabajo estandarizado, y la necesidad de informes de incidentes para cualquier
desviación del procedimiento u operaciones normales para acumular
aprendizajes, no importa cuán pequeña sea la señal de falla: constantemente
actualizar procedimientos y diseños de sistemas basados ​en estos aprendizajes.

El resultado es que cuando una nueva tripulación se embarca en su primera

despliegue, ellos y sus oficiales se benefician del colectivo
conocimiento de 5.700 años de reactores sin accidentes. Igualmente impresionante es
que sus propias experiencias en el mar se agregarán a este colectivo
conocimiento, ayudando a futuras tripulaciones a cumplir con seguridad sus propias misiones.

En el flujo de valor de la tecnología, debemos crear mecanismos similares para

crear conocimiento global, como hacer todos nuestros post-mortem irreprochables
informes que pueden buscar los equipos que intentan resolver problemas similares y
crear repositorios de código fuente compartido que abarcan todo
organización, donde el código compartido, las bibliotecas y las configuraciones que
encarnar el mejor conocimiento colectivo de toda la organización puede ser

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 86 de 485
 Utilizado fácilmente. Todos estos mecanismos ayudan a convertir la experiencia individual
en artefactos que el resto de la organización puede usar.

84

PATRONES DE RESILIENCIA INYECTOS EN NUESTROS

TRABAJO DIARIO

Las organizaciones de fabricación de bajo rendimiento se amortiguan

de las interrupciones de muchas maneras; en otras palabras, se acumulan o agregan
flacidez Por ejemplo, para reducir el riesgo de que un centro de trabajo esté inactivo (debido a
inventario que llega tarde, inventario que tuvo que desecharse, etc.),
los gerentes pueden optar por almacenar más inventario en cada centro de trabajo.
Sin embargo, ese búfer de inventario también aumenta WIP, que tiene todo tipo
de resultados no deseados, como se discutió anteriormente.

Del mismo modo, para reducir el riesgo de que un centro de trabajo caiga debido a
falla de maquinaria, los gerentes pueden aumentar la capacidad comprando más
equipo de capital, contratando a más personas o incluso aumentando el espacio de piso.
Todas estas opciones aumentan los costos.

En contraste, los de alto rendimiento logran los mismos resultados (o mejores) al

Mejorando las operaciones diarias, introduciendo continuamente tensión para elevar
rendimiento, así como la ingeniería de mayor resistencia en su sistema.

Considere un experimento típico en uno de los colchones de Aisin Seiki Global

fábricas, uno de los principales proveedores de Toyota. Supongamos que tuvieran dos
líneas de producción, cada una capaz de producir cien unidades por día.
En días lentos, enviarían toda la producción a una línea,
experimentar con formas de aumentar la capacidad e identificar
vulnerabilidades en su proceso, sabiendo que si sobrecarga la línea
Si fallaba, podían enviar toda la producción a la segunda línea.

Por la experimentación incesante y constante en su trabajo diario, ellos

fueron capaces de aumentar continuamente la capacidad, a menudo sin agregar
equipo nuevo o contratar más personas. El patrón emergente que

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 87 de 485
 Los resultados de este tipo de rituales de mejora no solo mejoran
rendimiento pero también mejora la capacidad de recuperación, porque la organización es
siempre en estado de tensión y cambio. Este proceso de aplicar estrés
para aumentar la resiliencia fue nombrado antifragilidad por autor y riesgo
analista Nassim Nicholas Taleb.

En el flujo de valor de la tecnología, podemos introducir el mismo tipo de

tensión en nuestros sistemas buscando reducir siempre el liderazgo de implementación
veces, aumentar la cobertura de prueba, disminuir los tiempos de ejecución de prueba e incluso

Page 85

rediseñando si es necesario para aumentar la productividad del desarrollador o

Aumentar la fiabilidad.

También podemos realizar ejercicios de Game Day , donde ensayamos grandes

fallas de escala, como apagar centros de datos completos. O podemos inyectar
fallas cada vez mayores en el entorno de producción (como el
famoso "Chaos Monkey" de Netflix, que mata aleatoriamente procesos y
calcular servidores en producción) para garantizar que somos tan resistentes como nosotros
quiero ser.

LÍDERES REFORZAN UNA CULTURA DE APRENDIZAJE

Tradicionalmente, se esperaba que los líderes fueran responsables de establecer

objetivos, asignando recursos para lograr esos objetivos, y
establecer la combinación correcta de incentivos. Los líderes también establecen
El tono emocional para las organizaciones que dirigen. En otras palabras,
líderes liderados por "tomar todas las decisiones correctas".

Sin embargo, existe evidencia significativa que muestra que la grandeza no es

logrado por los líderes que toman todas las decisiones correctas; en cambio,
El papel es crear las condiciones para que su equipo pueda descubrir la grandeza en
su trabajo diario En otras palabras, crear grandeza requiere tanto
líderes y trabajadores, cada uno de los cuales depende mutuamente de cada uno
otro.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 88 de 485
 Jim Womack, autor de Gemba Walks, describió el complemento
relación de trabajo y respeto mutuo que debe ocurrir entre
líderes y trabajadores de primera línea. Según Womack, esta relación
es necesario porque ninguno de los dos puede resolver problemas solos: los líderes no
lo suficientemente cerca del trabajo, que se requiere para resolver cualquier problema, y
los trabajadores de primera línea no tienen el contexto organizacional más amplio o
autoridad para realizar cambios fuera de su área de trabajo. §

Los líderes deben elevar el valor del aprendizaje y el problema disciplinado

resolviendo Mike Rother formalizó estos métodos en lo que él llama
entrenando kata. El resultado es uno que refleja el método científico,
donde declaramos explícitamente nuestros objetivos del Norte verdadero, como "sostener cero
accidentes "en el caso de Alcoa, o" doble rendimiento en un año "en
El caso de Aisin.

86

Estos objetivos estratégicos luego informan la creación de iterativos, a corto plazo

objetivos, que se conectan en cascada y luego se ejecutan estableciendo el objetivo
condiciones en el flujo de valor o en el nivel del centro de trabajo (p. ej., “reducir plomo
tiempo en un 10% dentro de las próximas dos semanas ").

Estas condiciones objetivo enmarcan el experimento científico: explícitamente

Indicar el problema que buscamos resolver, nuestra hipótesis de cómo
la contramedida propuesta lo resolverá, nuestros métodos para probar eso
hipótesis, nuestra interpretación de los resultados y nuestro uso de los aprendizajes para
informar la próxima iteración.

El líder ayuda a entrenar a la persona que realiza el experimento con

preguntas que pueden incluir:

¿Cuál fue tu último paso y qué pasó?

¿Qué aprendiste?

¿Cuál es tu condición ahora?

¿Cuál es su próxima condición objetivo?

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 89 de 485
 ¿En qué obstáculo estás trabajando ahora?

cual es tu siguiente paso?

¿Cuál es su resultado esperado?

¿Cuándo podemos verificar?

Este enfoque de resolución de problemas en el que los líderes ayudan a los trabajadores a ver y
Resolver problemas en su trabajo diario es el núcleo del Toyota
Sistema de producción, de organizaciones de aprendizaje, el Kata de mejora,
y organizaciones de alta confiabilidad. Mike Rother observa que él ve
Toyota "como una organización definida principalmente por el comportamiento único
rutinas que enseña continuamente a todos sus miembros ".

En el flujo de valor tecnológico, este enfoque científico e iterativo

El método guía todos nuestros procesos de mejora interna, pero también cómo
Realizamos experimentos para asegurar que los productos que construimos realmente
Ayudar a nuestros clientes internos y externos a alcanzar sus objetivos.

Page 87

CONCLUSIÓN

Los principios de la Tercera Vía abordan la necesidad de valorar

Aprendizaje organizacional, que permite una alta confianza y un alcance de límites
entre funciones, aceptando que las fallas siempre ocurrirán en complejos
sistemas, y hacer aceptable hablar sobre problemas para que podamos
Crear un sistema de trabajo seguro. También requiere institucionalizar el
mejora del trabajo diario, convirtiendo los aprendizajes locales en globales
aprendizajes que pueden ser utilizados por toda la organización, así como
inyectando tensión continuamente en nuestro trabajo diario.

Aunque fomentando una cultura de aprendizaje y experimentación continua

es el principio de la Tercera Vía, también está entretejido en la Primera y
Segundas maneras. En otras palabras, mejorar el flujo y la retroalimentación requiere un

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 90 de 485
 enfoque iterativo y científico que incluye el encuadre de un objetivo
condición, estableciendo una hipótesis de lo que nos ayudará a llegar allí, diseñando
y realizando experimentos y evaluando los resultados.

Los resultados no solo son un mejor rendimiento, sino también un aumento

resiliencia, mayor satisfacción laboral y mejor organización
adaptabilidad.

Page 88

PARTE I CONCLUSIÓN

En la Parte I del Manual de DevOps, analizamos varios

movimientos en la historia que ayudaron a conducir al desarrollo de DevOps.
También observamos los tres principios principales que forman la base
para organizaciones exitosas de DevOps: los principios de Flow, Feedback,

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 91 de 485
 y aprendizaje continuo y experimentación. En la Parte II, comenzaremos
para ver cómo iniciar un movimiento DevOps en su organización.

† El patrón de "nombre, culpa y vergüenza" es parte de la teoría de la mala manzana criticada por el Dr. Sydney Dekker y ampliamente
discutido en su libro The Field Guide to Understanding Human Error.

‡ Es sorprendente, instructivo y realmente conmovedor ver el nivel de convicción y pasión que Paul O'Neill tiene sobre el
Los líderes de responsabilidad moral deben crear seguridad en el lugar de trabajo.

§ Los líderes son responsables del diseño y la operación de procesos en un nivel superior de agregación donde otros tienen menos
perspectiva y autoridad.

Page 8990
Página

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 92 de 485
 Parte
Introducción

¿Cómo decidimos dónde comenzar un DevOps?

transformación en nuestra organización? Quien necesita ser
¿involucrado? ¿Cómo debemos organizar nuestros equipos, proteger
su capacidad de trabajo y maximizar sus posibilidades de
tener éxito? Estas son las preguntas que pretendemos responder en
Parte II del Manual de DevOps .

En los siguientes capítulos, veremos los

proceso de iniciar una transformación DevOps. Empezamos
evaluando los flujos de valor en nuestra organización,
localizar un buen lugar para comenzar y formar una estrategia para
crear un equipo de transformación dedicado con específico
objetivos de mejora y eventual expansión. Para cada
transformando el flujo de valor, identificamos el trabajo
se realiza y luego mira el diseño organizacional
estrategias y arquetipos organizacionales que mejor
Apoyar los objetivos de transformación.

Los enfoques principales en estos capítulos incluyen:

Seleccionar con qué flujos de valor comenzar

Comprender el trabajo que se realiza en nuestro candidato

flujos de valor

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 93 de 485
Page 91

Diseñando nuestra organización y arquitectura con

Ley de Conway en mente

Permitir resultados orientados al mercado a través de más

colaboración efectiva entre funciones en todo
el flujo de valor

Proteger y habilitar a nuestros equipos.

Comenzar cualquier transformación está llena de incertidumbre: nosotros

están trazando un viaje hacia un estado final ideal, pero donde
Prácticamente todos los pasos intermedios son desconocidos. Estas
los siguientes capítulos tienen la intención de proporcionar un proceso de pensamiento
para guiar nuestras decisiones, proporcionar pasos procesables que podamos
tomar e ilustrar casos de estudio como ejemplos.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 94 de 485
Página 93
92

'

55 Seleccionar cuál
Flujo de valor para
Empezar con

Elegir un flujo de valor para la transformación de DevOps merece cuidado

consideración. El flujo de valor que elegimos no solo dicta la dificultad de
nuestra transformación, pero también dicta quién estará involucrado en la transformación.
Afectará cómo debemos organizarnos en equipos y cómo podemos habilitar mejor la
equipos e individuos en ellos.

Michael Rembetsy notó otro desafío, quien ayudó a dirigir DevOps

transformación como Director de Operaciones en Etsy en 2009. Observó: "Nosotros
debemos elegir nuestros proyectos de transformación con cuidado, cuando estamos en problemas, no
conseguir muchas fotos Por lo tanto, debemos elegir cuidadosamente y luego proteger esos
proyectos de mejora que mejorarán más el estado de nuestra organización ".

Examinemos cómo el equipo de Nordstrom comenzó su transformación DevOps

iniciativa en 2013, que Courtney Kissler, su vicepresidenta de comercio electrónico y tienda
Tecnologías, descritas en la Cumbre empresarial de DevOps en 2014 y 2015.

Fundada en 1901, Nordstrom es un minorista de moda líder que se centra en

entregando la mejor experiencia de compra posible a sus clientes. En 2015,
Nordstrom tuvo ingresos anuales de $ 13.5 mil millones.

El escenario para el viaje DevOps de Nordstrom probablemente se estableció en 2011 durante uno de
sus reuniones anuales de la junta directiva. Ese año, uno de los temas estratégicos.
se discutió la necesidad de aumentar los ingresos en línea. Estudiaron la difícil situación de
Blockbusters, Borders y Barnes & Nobles, que demostraron la extrema
consecuencias cuando los minoristas tradicionales llegaron tarde creando e- competitividad
capacidades comerciales: estas organizaciones estaban claramente en riesgo de perder sus
posicionarse en el mercado o incluso cerrar completamente el negocio. †

En ese momento, Courtney Kissler era el director senior de Systems Delivery y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 95 de 485
 Tecnología de venta, responsable de una parte importante de la tecnología.
organización, incluidos sus sistemas en la tienda y el sitio de comercio electrónico en línea. Como
Kissler describió: “En 2011, la organización tecnológica de Nordstrom fue muy
mucho optimizado para el costo: habíamos subcontratado muchas de nuestras funciones tecnológicas,
tuvimos un ciclo de planificación anual con grandes lotes, lanzamientos de software 'en cascada'.
A pesar de que tuvimos una tasa de éxito del 97% de alcanzar nuestro cronograma, presupuesto y alcance

Page 94

objetivos, estábamos mal equipados para lograr lo que la estrategia comercial de cinco años
requerido por nosotros, ya que Nordstrom comenzó a optimizar la velocidad en lugar de simplemente
optimizando el costo ".

Kissler y el equipo de gestión de tecnología de Nordstrom tuvieron que decidir dónde

comenzar sus esfuerzos iniciales de transformación. No querían causar agitación en el
todo el sistema En cambio, querían centrarse en áreas muy específicas del negocio.
para que puedan experimentar y aprender. Su objetivo era demostrar temprano
gana, lo que daría a todos la confianza de que estas mejoras podrían ser
replicado en otras áreas de la organización. Cómo exactamente eso se lograría
Aún era desconocido.

Se centraron en tres áreas: la aplicación móvil del cliente, su tienda

sistemas de restaurantes y sus propiedades digitales. Cada una de estas áreas tenía negocios
objetivos que no se estaban cumpliendo; por lo tanto, fueron más receptivos a considerar un
diferente forma de trabajar Las historias de los dos primeros se describen a continuación.

La aplicación móvil Nordstrom había experimentado un inicio desfavorable. Como

Kissler dijo: "Nuestros clientes estaban extremadamente frustrados con el producto, y nosotros
tenía críticas negativas uniformes cuando lo lanzamos en la App Store. Peor aún, el
la estructura y los procesos existentes (también conocidos como "el sistema") habían diseñado sus procesos
para que solo puedan lanzar actualizaciones dos veces al año ". En otras palabras, cualquier solución
a la aplicación tendría que esperar meses para llegar al cliente.

Su primer objetivo era habilitar lanzamientos más rápidos o bajo demanda, proporcionando más rápido
iteración y la capacidad de responder a los comentarios de los clientes. Crearon un
equipo de producto dedicado que se dedicó exclusivamente a brindar soporte para dispositivos móviles
aplicación, con el objetivo de permitir que ese equipo pueda
implementar, probar y entregar valor al cliente. Al hacer esto, no
ya no tiene que depender y coordinarse con los puntajes de otros equipos dentro
Nordstrom Además, pasaron de la planificación una vez al año a un
Proceso de planificación continua. El resultado fue una única acumulación de trabajo priorizada
para la aplicación móvil basada en la necesidad del cliente, ya no existían conflictos

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 96 de 485
 prioridades cuando el equipo tuvo que soportar múltiples productos.

Durante el año siguiente, eliminaron las pruebas como una fase separada del trabajo,
en cambio, integrándolo en el trabajo diario de todos. ‡ Duplicaron las características siendo
entregado por mes y redujo a la mitad el número de defectos, creando un éxito
Salir.

Su segunda área de enfoque fueron los sistemas que respaldan su Café Bistro en la tienda.
restaurantes. A diferencia del flujo de valor de la aplicación móvil donde la necesidad comercial era
Reduzca el tiempo de comercialización y aumente el rendimiento de las funciones, la empresa necesita aquí
fue para disminuir el costo y aumentar la calidad. En 2013, Nordstrom había completado
once "re-conceptos de restaurante" que requirieron cambios en la tienda
aplicaciones, causando una serie de incidentes que impactan al cliente. Inquietantemente

Page 95

habían planeado cuarenta y cuatro más de estos re-conceptos para 2014, cuatro veces más
tantos como en el año anterior.

Como Kissler declaró: “Uno de nuestros líderes empresariales sugirió que tripliquemos nuestro equipo
tamaño para manejar estas nuevas demandas, pero propuse que tuviéramos que dejar de tirar
más cuerpos ante el problema y, en cambio, mejorar la forma en que trabajamos ".

Pudieron identificar áreas problemáticas, como en su ingesta de trabajo y

procesos de implementación, que es donde enfocaron sus esfuerzos de mejora.
Pudieron reducir los tiempos de entrega de implementación de código en un 60% y reducir el
Número de incidentes de producción 60% a 90%.

Estos éxitos dieron a los equipos la confianza de que los principios y prácticas de DevOps
eran aplicables a una amplia variedad de flujos de valor. Kissler fue ascendido a vicepresidente de
Comercio electrónico y tecnologías de tienda en 2014.

En 2015, Kissler dijo que para la venta o la tecnología orientada al cliente

organización para permitir que la empresa cumpla con sus objetivos, "... necesitábamos aumentar
productividad en todos nuestros flujos de valor de tecnología, no solo en unos pocos. En el
nivel de gestión, creamos un mandato general para reducir los tiempos de ciclo
en un 20% para todos los servicios orientados al cliente ".

Ella continuó: “Este es un desafío audaz. Tenemos muchos problemas en nuestro

estado actual: los tiempos de proceso y ciclo no se miden de manera consistente
equipos, ni son visibles. Nuestra primera condición objetivo requiere que ayudemos a todos nuestros
los equipos miden, lo hacen visible y realizan experimentos para comenzar a reducir su
tiempos de proceso, iteración por iteración ".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 97 de 485
 Kissler concluyó: "Desde una perspectiva de alto nivel, creemos que las técnicas tales
como mapeo de flujo de valor, reduciendo nuestros tamaños de lote hacia el flujo de una sola pieza, como
así como el uso de la entrega continua y microservicios nos llevará a nuestro deseado
estado. Sin embargo, mientras todavía estamos aprendiendo, estamos seguros de que nos dirigimos
la dirección correcta, y todos saben que este esfuerzo cuenta con el apoyo de
los más altos niveles de gestión ".

En este capítulo, se presentan varios modelos que nos permitirán replicar el

procesos de pensamiento que el equipo de Nordstrom utilizó para decidir qué flujos de valor
Empezar con. Evaluaremos nuestros flujos de valor candidatos de muchas maneras, incluyendo
ya sea un servicio greenfield o brownfield , un sistema de compromiso o un
sistema de registro . También calcularemos el balance riesgo / recompensa de la transformación
y evaluar el nivel probable de resistencia que podemos obtener de los equipos en los que trabajaríamos
con.

GREENFIELD VS. SERVICIOS BROWNFIELD

Page 96

A menudo categorizamos nuestros servicios o productos de software como greenfield o

brownfield Estos términos se usaron originalmente para la planificación urbana y la construcción.
proyectos El desarrollo greenfield es cuando construimos en tierras subdesarrolladas.
El desarrollo de Brownfield es cuando construimos en terrenos que anteriormente se usaban para
fines industriales, potencialmente contaminados con residuos peligrosos o contaminación.
En el desarrollo urbano, muchos factores pueden hacer que los proyectos greenfield sean más simples que
proyectos brownfield: no hay estructuras existentes que necesiten ser demolidas
tampoco hay materiales tóxicos que deban eliminarse.

En tecnología, un proyecto greenfield es un nuevo proyecto o iniciativa de software, probablemente en

las primeras etapas de planificación o implementación, donde construimos nuestras aplicaciones
e infraestructura de nuevo, con pocas limitaciones. Comenzando con un software greenfield
el proyecto puede ser más fácil, especialmente si el proyecto ya está financiado y un equipo está
ya sea creado o ya está en su lugar. Además, porque estamos empezando
Desde cero, podemos preocuparnos menos por las bases de código existentes, los procesos y los equipos.

Los proyectos Greenfield DevOps a menudo son pilotos para demostrar la viabilidad del público o
nubes privadas, automatización de despliegue piloto y herramientas similares. Un ejemplo de
un proyecto DevOps greenfield es el producto Hosted LabVIEW en 2009 en National

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 98 de 485
 Instruments, una organización de treinta años con cinco mil empleados y $ 1
mil millones en ingresos anuales. Para llevar este producto al mercado rápidamente, un nuevo equipo
fue creado y se le permitió operar fuera de los procesos de TI existentes y
explorar el uso de nubes públicas. El equipo inicial incluyó una aplicación
arquitecto, arquitecto de sistemas, dos desarrolladores, un desarrollador de sistemas de automatización, un
jefe de operaciones y dos empleados de operaciones en alta mar. Mediante el uso de prácticas DevOps,
pudieron entregar LabVIEW Hospedado al mercado en la mitad del tiempo de su
introducciones normales de productos.

En el otro extremo del espectro están los proyectos Brownfield DevOps, estos son
Productos o servicios existentes que ya están sirviendo a clientes y tienen
potencialmente ha estado en funcionamiento durante años o incluso décadas. Brownfield proyecta a menudo
vienen con cantidades significativas de deuda técnica, como no tener prueba
automatización o ejecución en plataformas no compatibles. En el ejemplo de Nordstrom
presentado anteriormente en este capítulo, tanto los sistemas de restaurante en la tienda como e-
Los sistemas de comercio eran proyectos brownfield.

Aunque muchos creen que DevOps es principalmente para proyectos nuevos, DevOps
se ha utilizado para transformar con éxito proyectos brownfield de todo tipo. De hecho,
Más del 60% de las historias de transformación compartidas en la Cumbre de DevOps Enterprise
en 2014 fueron para proyectos brownfield. En estos casos, hubo una gran
brecha de rendimiento entre lo que el cliente necesitaba y lo que la organización
actualmente estaba entregando, y las transformaciones de DevOps crearon tremendas
beneficio comercial

Page 97

De hecho, uno de los hallazgos en el Informe sobre el estado de DevOps de 2015 confirmó que
la edad de la aplicación no fue un predictor significativo del rendimiento; en lugar,
lo que predijo el rendimiento fue si la aplicación fue diseñada (o
podría ser rediseñado) para la comprobabilidad y la capacidad de implementación.

Los equipos que apoyan proyectos brownfield pueden ser muy receptivos a experimentar
con DevOps, particularmente cuando existe una creencia generalizada de que
los métodos son insuficientes para lograr sus objetivos, y especialmente si hay un fuerte
sentido de urgencia en torno a la necesidad de mejora. §

Al transformar proyectos brownfield, podemos enfrentar impedimentos significativos y

problemas, especialmente cuando no existen pruebas automatizadas o cuando hay una
arquitectura acoplada que evita que pequeños equipos desarrollen, prueben y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 99 de 485
 desplegar código de forma independiente. Se discute cómo superamos estos problemas
a lo largo de este libro.

Los ejemplos de transformaciones brownfield exitosas incluyen:

CSG (2013): en 2013, CSG International tuvo $ 747 millones en ingresos y

más de 3,500 empleados, lo que permite más de noventa mil agentes de servicio al cliente
para proporcionar operaciones de facturación y atención al cliente a más de cincuenta millones de videos,
clientes de voz y datos, ejecutando más de seis mil millones de transacciones e imprimiendo
y el envío de más de setenta millones de estados de cuenta en papel cada mes. Su
El alcance inicial de la mejora fue la impresión de facturas, uno de sus principales negocios,
e involucró una aplicación COBOL mainframe y los veinte
plataformas tecnológicas. Como parte de su transformación, comenzaron a actuar
implementaciones diarias en un entorno similar a la producción, y duplicó el
frecuencia de lanzamientos de clientes de dos veces al año a cuatro veces al año. Como
Como resultado, aumentaron significativamente la confiabilidad de la aplicación y
Reducción de los tiempos de implementación del código de dos semanas a menos de un día.

Etsy (2009): en 2009, Etsy tenía treinta y cinco empleados y generaba $ 87

millones en ingresos, pero después de que "apenas sobrevivieron a la temporada de compras navideñas"
comenzaron a transformar prácticamente todos los aspectos de cómo la organización
trabajó, eventualmente convirtiendo a la compañía en uno de los DevOps más admirados
organizaciones y preparan el escenario para una exitosa OPI 2015.

CONSIDERE AMBOS SISTEMAS DE REGISTRO Y

SISTEMAS DE COMPROMISO

La firma de investigación Gartner ha popularizado recientemente la noción de TI bimodal ,

refiriéndose al amplio espectro de servicios que soportan las empresas típicas. Dentro
TI bimodal hay sistemas de registro , los sistemas tipo ERP que ejecutan nuestro
negocios (p. ej., MRP, RRHH, sistemas de información financiera), donde la corrección de

98

las transacciones y los datos son primordiales; y sistemas de compromiso , que son
sistemas orientados al cliente o empleados, como los sistemas de comercio electrónico y
aplicaciones de productividad.

Los sistemas de registro suelen tener un ritmo de cambio más lento y a menudo tienen regulaciones
y requisitos de cumplimiento (por ejemplo, SOX). Gartner llama a este tipo de sistemas
"Tipo 1", donde la organización se centra en "hacerlo bien".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 100 de 485
 Los sistemas de compromiso generalmente tienen un ritmo de cambio mucho más alto para respaldar
bucles de retroalimentación rápida que les permiten realizar experimentos para descubrir
cómo satisfacer mejor las necesidades del cliente. Gartner llama a este tipo de sistemas "Tipo 2"
donde la organización se enfoca en "hacerlo rápido".

Puede ser conveniente dividir nuestros sistemas en estas categorías; Sin embargo, nos
saber que el conflicto central y crónico entre "hacerlo bien" y "hacerlo rápido"
se puede romper con DevOps. Los datos de los informes del estado de DevOps de Puppet Labs
—Siguiendo las lecciones de Lean Manufacturing — muestra que el alto rendimiento
Las organizaciones pueden ofrecer simultáneamente mayores niveles de rendimiento y
fiabilidad.

Además, debido a lo interdependientes que son nuestros sistemas, nuestra capacidad de hacer
los cambios en cualquiera de estos sistemas están limitados por el sistema que es más difícil de
cambiar con seguridad, que casi siempre es un sistema de registro.

Scott Prugh, vicepresidente de desarrollo de productos en CSG, observó: “Hemos adoptado un

filosofía que rechaza la TI bimodal, porque cada uno de nuestros clientes merece
Velocidad y calidad. Esto significa que necesitamos excelencia técnica, ya sea
el equipo está apoyando una aplicación mainframe de 30 años, una aplicación Java o un
aplicación movil."

En consecuencia, cuando mejoramos los sistemas brownfield, no solo debemos esforzarnos por
reducir su complejidad y mejorar su fiabilidad y estabilidad, también debemos
hacerlos más rápidos, seguros y fáciles de cambiar. Incluso cuando la nueva funcionalidad es
agregados solo a los sistemas de interacción nuevos, a menudo causan confiabilidad
problemas en los sistemas de registro brownfield en los que confían. Al hacer estos
sistemas posteriores más seguros para cambiar, ayudamos a toda la organización más
Alcanzar sus objetivos de forma rápida y segura.

COMIENCE CON EL MÁS SIMPÁTICO Y

GRUPOS INNOVADORES

Dentro de cada organización, habrá equipos e individuos con una amplia gama.
de actitudes hacia la adopción de nuevas ideas. Geoffrey A. Moore primero representado
este espectro en forma del ciclo de vida de adopción de tecnología en Crossing The

Page 99

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 101 de 485
 Abismo , donde el abismo representa la dificultad clásica de alcanzar grupos
más allá de los innovadores y los primeros en adoptar (verFigura 9 ).

En otras palabras, las nuevas ideas a menudo son rápidamente aceptadas por los innovadores y los primeros
adoptantes, mientras que otros con actitudes más conservadoras se resisten a ellos (los primeros
mayoría , mayoría tardía y rezagados ). Nuestro objetivo es encontrar aquellos equipos que
ya cree en la necesidad de los principios y prácticas de DevOps, y quién posee un
deseo y capacidad demostrada para innovar y mejorar sus propios procesos.
Idealmente, estos grupos serán entusiastas partidarios del viaje de DevOps.

Figura 9: La curva de adopción de tecnología (Fuente: Moore y McKenna, Crossing

El abismo , 15.)

Especialmente en las primeras etapas, no pasaremos mucho tiempo tratando de convertir el

grupos más conservadores. En cambio, enfocaremos nuestra energía en crear éxitos
con menos grupos de aversión al riesgo y construir nuestra base desde allí (un proceso que es
discutido más adelante en la siguiente sección). Incluso si tenemos los niveles más altos de
patrocinio ejecutivo, evitaremos el enfoque del big bang (es decir, comenzar
en todas partes a la vez), eligiendo en cambio enfocar nuestros esfuerzos en algunas áreas de la
organización, asegurando que esas iniciativas sean exitosas, y expandiéndose desde
allí.¶

DEVOPS AMPLIADOS A TRAVÉS DE NUESTRA ORGANIZACIÓN

Independientemente de cómo alcancemos nuestro esfuerzo inicial, debemos demostrar las primeras victorias y
Transmitir nuestros éxitos. Hacemos esto rompiendo nuestros objetivos de mejora más grandes
en pequeños pasos incrementales. Esto no solo crea nuestras mejoras más rápido, sino que también
también nos permite descubrir cuándo tomamos la decisión equivocada de flujo de valor:
Al detectar nuestros errores temprano, podemos retroceder rápidamente e intentarlo nuevamente, haciendo
diferentes decisiones armadas con nuestros nuevos aprendizajes.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 102 de 485
Página 100

A medida que generamos éxitos, nos ganamos el derecho de ampliar el alcance de nuestros DevOps
iniciativa. Queremos seguir una secuencia segura que aumente metódicamente nuestros niveles de
credibilidad, influencia y apoyo. La siguiente lista, adaptada de un curso.
impartido por el Dr. Roberto Fernández, profesor de administración William F. Pounds
en MIT, describe las fases ideales utilizadas por los agentes de cambio para construir y expandir
su coalición y base de apoyo:

1. Encuentra innovadores y primeros adoptantes: al principio, enfocamos nuestro

esfuerzos en equipos que realmente quieren ayudar: estos son nuestros espíritus afines y
compañeros de viaje que son los primeros en ofrecerse como voluntarios para comenzar el viaje DevOps. En
lo ideal, también son personas respetadas y con un alto grado de
influencia sobre el resto de la organización, dando a nuestra iniciativa más
credibilidad.

2. Construir una masa crítica y una mayoría silenciosa: en la siguiente fase, buscamos
expandir las prácticas de DevOps a más equipos y flujos de valor con el objetivo de
creando una base estable de apoyo. Al trabajar con equipos que son receptivos a
nuestras ideas, incluso si no son los grupos más visibles o influyentes, ampliamos
nuestra coalición que está generando más éxitos, creando un "carro"
efecto "que aumenta aún más nuestra influencia. Específicamente evitamos el peligro
batallas políticas que podrían poner en peligro nuestra iniciativa.

3. Identificar los holdouts: los "holdouts" son de alto perfil, influyentes

detractores que tienen más probabilidades de resistir (y tal vez incluso sabotear) nuestros esfuerzos.
En general, abordamos este grupo solo después de haber logrado una mayoría silenciosa,
cuando hemos establecido suficientes éxitos para proteger con éxito nuestra
iniciativa.

Expandir DevOps en una organización no es una tarea pequeña. Puede crear riesgos para
individuos, departamentos y la organización en su conjunto. Pero como Ron van
Kemenade, CIO de ING, quien ayudó a transformar la organización en uno de los
La mayoría de las organizaciones tecnológicas admiradas dijo: "El cambio principal requiere coraje,
especialmente en entornos corporativos donde la gente tiene miedo y pelea contigo. Pero si
comienzas pequeño, realmente no tienes nada que temer. Cualquier líder necesita ser valiente
lo suficiente como para asignar equipos para hacer una toma de riesgos calculada ".

CONCLUSIÓN

Peter Drucker, líder en el desarrollo de la educación gerencial, observó

que "los peces pequeños aprenden a ser peces grandes en pequeños estanques". Al elegir cuidadosamente dónde y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 103 de 485
 cómo comenzar, podemos experimentar y aprender en áreas de nuestra organización que
crear valor sin poner en peligro al resto de la organización. Al hacer esto, nosotros
construya nuestra base de soporte, gane el derecho de expandir el uso de DevOps en nuestro

Page 101

organización, y ganar el reconocimiento y la gratitud de un cada vez más grande

distrito electoral.

† Estas organizaciones a veces se conocían como los "Asesinos B que están muriendo".

‡ La práctica de confiar en una fase de estabilización o en una fase de endurecimiento al final de un proyecto a menudo tiene resultados muy pobres, porque significa
Los problemas no se encuentran ni se solucionan como parte del trabajo diario y no se abordan, lo que puede convertirse en problemas más grandes.

§ Que los servicios que tienen el mayor beneficio comercial potencial son sistemas brownfield no debería sorprender. Después de todo, estos son los
sistemas en los que se confía más y tienen el mayor número de clientes existentes o la mayor cantidad de ingresos dependiendo de ellos.

¶ Big Bang, son posibles las transformaciones de arriba hacia abajo, como la transformación Agile en PayPal en 2012 que fue dirigida por su vicepresidente de
tecnología, Kirsten Wolberg. Sin embargo, como con cualquier transformación sostenible y exitosa, esto requirió el más alto nivel de
apoyo administrativo y un enfoque incesante y sostenido para impulsar los resultados necesarios.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 104 de 485
Page 103
102

6 Trabaja en nuestro valor

Stream, haciéndolo
Entendiendo
Visible y el
Expandiéndolo a través de
la organización

Una vez que hemos identificado un flujo de valor al que queremos aplicar los principios de DevOps y
patrones, nuestro siguiente paso es obtener una comprensión suficiente de cómo se entrega el valor a
el cliente: qué trabajo se realiza y por quién, y qué pasos podemos tomar para
mejorar el flujo

En el capítulo anterior, aprendimos sobre la transformación DevOps dirigida por Courtney

Kissler y el equipo de Nordstrom. Con los años, han aprendido que uno de los
La forma más eficiente de comenzar a mejorar cualquier flujo de valor es realizar un taller con todos
las principales partes interesadas y realizan un ejercicio de mapeo de flujo de valor: un proceso
(descrito más adelante en este capítulo) diseñado para ayudar a capturar todos los pasos necesarios para crear
valor.

El ejemplo favorito de Kissler de las ideas valiosas e inesperadas que pueden provenir de
el mapeo de flujo de valor es cuando intentaron mejorar los largos tiempos de espera asociados con
solicita pasar por la aplicación Cosmetics Business Office, un mainframe COBOL
aplicación que respaldaba a todos los gerentes de piso y departamento de su tienda
departamentos de belleza y cosmética.

Esta aplicación permitió a los gerentes de departamento registrar nuevos vendedores para varios

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 105 de 485
 líneas de productos transportadas en sus tiendas, para que puedan rastrear las comisiones de ventas, habilitar
reembolsos de proveedores, y así sucesivamente.

Kissler explicó:

Conocía bien esta aplicación particular de mainframe; anteriormente en mi carrera, apoyé

este equipo de tecnología, así que sé de primera mano que durante casi una década, durante cada
ciclo de planificación anual, debatiríamos sobre cómo necesitábamos obtener esta aplicación
fuera de la unidad central. Por supuesto, como en la mayoría de las organizaciones, incluso cuando estaba lleno
soporte de gestión, nunca parecíamos llegar a migrarlo.

Mi equipo quería realizar un ejercicio de mapeo de flujo de valor para determinar si

la aplicación COBOL realmente fue el problema, o tal vez hubo un problema mayor
que necesitábamos abordar Realizaron un taller que reunió a todos con
cualquier responsabilidad por entregar valor a nuestros clientes internos, incluido nuestro
socios comerciales, el equipo de mainframe, los equipos de servicios compartidos, etc.

Página 104

Lo que descubrieron fue que cuando los gerentes de departamento presentaban

formulario de solicitud de 'asignación de línea de producto', les pedíamos un empleado
número, que no tenían, por lo que lo dejarían en blanco o lo pondrían
algo como 'No lo sé' Peor aún, para completar el formulario, departamento
los gerentes tendrían que abandonar la tienda de manera inconveniente para usar una PC
El back office. El resultado final fue todo este tiempo perdido, con el trabajo recuperado y
adelante en el proceso.

Durante el taller, los participantes realizaron varios experimentos, incluidos

eliminar el campo de número de empleado en el formulario y dejar que otro departamento obtenga eso
información en un paso descendente. Estos experimentos, realizados con la ayuda de
Los gerentes de departamento mostraron una reducción de cuatro días en el tiempo de procesamiento. El equipo después
reemplazó la aplicación de PC con una aplicación de iPad, lo que permitió a los gerentes enviar
la información necesaria sin salir de la tienda, y el tiempo de procesamiento fue
reducido aún más a segundos.

Ella dijo con orgullo: "Con esas mejoras increíbles, todas las demandas para conseguir esto
aplicación fuera de la unidad central desapareció. Además, otros líderes empresariales tomaron
cuenta y comenzó a llegar a nosotros con una lista completa de más experimentos que querían
Conducir con nosotros en sus propias organizaciones. Todos en el negocio y la tecnología.
los equipos estaban entusiasmados con el resultado porque resolvieron un problema comercial real y,
lo más importante, aprendieron algo en el proceso ".

En el resto de este capítulo, veremos los siguientes pasos: identificar todos

los equipos requeridos para crear valor para el cliente, creando un mapa de flujo de valor para hacer visible

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 106 de 485
 todo el trabajo requerido y su uso para guiar a los equipos sobre cómo mejorar y más rápidamente
crear valor. Al hacer esto, podemos replicar los sorprendentes resultados descritos en este
Ejemplo de Nordstrom.

IDENTIFICANDO LOS EQUIPOS QUE APOYAN NUESTRO VALOR

CORRIENTE

Como demuestra este ejemplo de Nordstrom, en flujos de valor de cualquier complejidad, nadie
la persona conoce todo el trabajo que debe realizarse para crear valor para el
cliente, especialmente porque el trabajo requerido debe ser realizado por muchas personas diferentes
equipos, a menudo muy alejados entre sí en los organigramas, geográficamente o
por incentivos.

Como resultado, después de seleccionar una aplicación o servicio candidato para nuestra iniciativa DevOps,
debemos identificar a todos los miembros de la cadena de valor responsables de trabajar
juntos para crear valor para los clientes que se atienden. En general, esto incluye:

Propietario del producto: la voz interna de la empresa que define el siguiente conjunto de
funcionalidad en el servicio

Desarrollo: el equipo responsable de desarrollar la funcionalidad de la aplicación en el

Servicio

Page 105

QA: el equipo responsable de garantizar que existan bucles de retroalimentación para garantizar el servicio
funciona como se desee

Operaciones: el equipo a menudo responsable de mantener la producción.

entorno y ayudar a garantizar que se cumplan los niveles de servicio requeridos

Infosec: el equipo responsable de asegurar sistemas y datos

Release managers: las personas responsables de gestionar y coordinar el

implementación de producción y procesos de lanzamiento

Ejecutivos de tecnología o gerente de flujo de valor: en la literatura Lean, alguien

quién es responsable de "garantizar que el flujo de valor cumpla o supere al cliente
requisitos [y organizacionales] para el flujo de valor general, de principio a fin "

CREAR UN MAPA DE STREAM DE VALOR PARA VER EL TRABAJO

Después de identificar nuestros miembros de flujo de valor, nuestro siguiente paso es obtener un

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 107 de 485
 comprensión de cómo se realiza el trabajo, documentado en forma de flujo de valor
mapa. En nuestro flujo de valor, el trabajo probablemente comienza con el propietario del producto, en forma de
solicitud del cliente o la formulación de una hipótesis comercial. Algún tiempo después, este trabajo
es aceptado por Desarrollo, donde las características se implementan en código y se registran para
nuestro repositorio de control de versiones. Las compilaciones se integran, se prueban en una producción
entorno, y finalmente desplegados en producción, donde (idealmente) crean valor para
nuestro cliente.

En muchas organizaciones tradicionales, este flujo de valor consistirá en cientos, si no

miles, de pasos, que requieren trabajo de cientos de personas. Porque documentar cualquier
El mapa de flujo de valor de este complejo probablemente requiera varios días, podemos realizar una
taller de un día, donde ensamblamos todos los componentes clave y los retiramos del
distracciones de su trabajo diario.

Nuestro objetivo no es documentar cada paso y las minucias asociadas, sino lo suficiente
Comprender las áreas de nuestro flujo de valor que ponen en peligro nuestros objetivos de flujo rápido,
cortos plazos de entrega y resultados confiables para el cliente. Idealmente, hemos reunido esos
personas con autoridad para cambiar su parte de la corriente de valor.†

Damon Edwards, coanfitrión del podcast DevOps Café , observó: “En mi experiencia, estos
Los tipos de ejercicios de mapeo de flujo de valor son siempre reveladores. A menudo es el primero
momento en que la gente ve cuánto trabajo y heroicidad se requieren para entregar valor al
cliente. Para Operaciones, puede ser la primera vez que ven las consecuencias que
se produce cuando los desarrolladores no tienen acceso a entornos configurados correctamente, que
contribuye a un trabajo aún más loco durante las implementaciones de código. Para el desarrollo, puede
ser la primera vez que ven todos los heroicos requeridos por Test and Operations para
para implementar su código en producción, mucho después de que marquen una característica como 'completada' ".

Utilizando toda la amplitud de conocimiento aportada por los equipos involucrados en la cadena de valor,
debemos centrar nuestra investigación y escrutinio en las siguientes áreas:

Page 106

Lugares donde el trabajo debe esperar semanas o incluso meses, como ser productivo
entornos, procesos de aprobación de cambios o procesos de revisión de seguridad

Lugares donde se genera o recibe un trabajo significativo

Nuestro primer paso para documentar nuestro flujo de valor solo debe consistir en un proceso de alto nivel
bloques Por lo general, incluso para flujos de valor complejos, los grupos pueden crear un diagrama con cinco
a quince bloques de proceso en pocas horas. Cada bloque de proceso debe incluir el plomo
tiempo y tiempo de proceso para procesar un elemento de trabajo, así como el% C / A medido
por los consumidores intermedios de la producción. ‡

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 108 de 485
 Figura 10: Un ejemplo de un mapa de flujo de valor
(Fuente: Humble, Molesky y O'Reilly, Lean Enterprise , 139.)

Utilizamos las métricas de nuestro mapa de flujo de valor para guiar nuestros esfuerzos de mejora. En el
Ejemplo de Nordstrom, se centraron en las bajas tasas de% C / A en el formulario de solicitud enviado
por gerentes de departamento debido a la ausencia de números de empleados. En otros casos, puede
ser largos tiempos de entrega o bajas tasas de% C / A al entregar una prueba configurada correctamente
entornos para equipos de desarrollo, o podrían ser los largos plazos de entrega necesarios para
ejecutar y pasar pruebas de regresión antes de cada lanzamiento de software.

Una vez que identificamos la métrica que queremos mejorar, debemos realizar el siguiente nivel de
observaciones y mediciones para comprender mejor el problema y luego construir un
Mapa de flujo de valor futuro idealizado, que sirve como una condición objetivo para lograr por algunos
fecha (por ejemplo, generalmente de tres a doce meses).

El liderazgo ayuda a definir este estado futuro y luego guía y permite al equipo
lluvia de ideas hipótesis y contramedidas para lograr la mejora deseada a ese
declarar, realizar experimentos para probar esas hipótesis e interpretar los resultados para
determinar si las hipótesis fueron correctas. Los equipos siguen repitiendo e iterando,
usando cualquier nuevo aprendizaje para informar los próximos experimentos.

CREANDO UN EQUIPO DE TRANSFORMACIÓN DEDICADO

Page 107

Uno de los desafíos inherentes a iniciativas como las transformaciones de DevOps es que
inevitablemente están en conflicto con las operaciones comerciales en curso. Parte de esto es natural
resultado de cómo evolucionan las empresas exitosas. Una organización que ha tenido éxito.
por cualquier período extendido de tiempo (años, décadas o incluso siglos) ha creado

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 109 de 485
 mecanismos para perpetuar las prácticas que los hicieron exitosos, como el producto
desarrollo, administración de pedidos y operaciones de la cadena de suministro.

Se utilizan muchas técnicas para perpetuar y proteger el funcionamiento de los procesos actuales, como
como especialización, enfoque en eficiencia y repetibilidad, burocracias que imponen
procesos de aprobación y controles para proteger contra la variación. En particular, las burocracias.
son increíblemente resistentes y están diseñados para sobrevivir a condiciones adversas: se puede eliminar
la mitad de los burócratas, y el proceso aún sobrevivirá.

Si bien esto es bueno para preservar el status quo, a menudo necesitamos cambiar la forma en que trabajamos para
adaptarse a las condiciones cambiantes en el mercado. Hacer esto requiere interrupción y
innovación, lo que nos pone en desacuerdo con los grupos que actualmente son responsables diariamente
operaciones y las burocracias internas, y quién casi siempre ganará.

En su libro The Other Side of Innovation: Solving the Execution Challenge, Dr. Vijay
Govindarajan y el Dr. Chris Trimble, ambos miembros de la facultad de Tuck de Dartmouth College
School of Business, describió sus estudios sobre cómo se logra la innovación disruptiva
a pesar de estas poderosas fuerzas de las operaciones diarias. Documentaron cómo el cliente
los productos de seguros de automóviles impulsados ​se desarrollaron y comercializaron con éxito en Allstate,
cómo se creó el rentable negocio de publicación digital en el Wall Street Journal ,
el desarrollo de la innovadora zapatilla de trail running en Timberland, y el
desarrollo del primer coche eléctrico en BMW.

Con base en su investigación, el Dr. Govindarajan y el Dr. Trimble afirman que las organizaciones
necesita crear un equipo de transformación dedicado que pueda operar fuera del resto
de la organización responsable de las operaciones diarias (que llaman
"Equipo dedicado" y "motor de rendimiento" respectivamente).

En primer lugar, responsabilizaremos a este equipo dedicado por lograr un claro

resultado definido, medible, a nivel del sistema (por ejemplo, reducir el tiempo de implementación desde
"Código comprometido en el control de versiones para ejecutarse con éxito en producción" en un 50%). En
Para ejecutar dicha iniciativa, hacemos lo siguiente:

Asigne miembros del equipo dedicado para que se asignen únicamente a DevOps
esfuerzos de transformación (en lugar de "mantener todas sus responsabilidades actuales, pero
dedica el 20% de tu tiempo a esta nueva cosa de DevOps ").

Seleccione miembros del equipo que sean generalistas, que tengan habilidades en una amplia variedad de
dominios

Seleccionar miembros del equipo que tengan relaciones duraderas y de respeto mutuo.
con el resto de la organización.

Cree un espacio físico separado para el equipo dedicado, si es posible, para maximizar
flujo de comunicación dentro del equipo, y creando cierto aislamiento del resto del
organización.

108

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 110 de 485
 Si es posible, liberaremos al equipo de transformación de muchas de las reglas y políticas que
restringir al resto de la organización, como lo hizo National Instruments, descrito en el
capítulo previo. Después de todo, los procesos establecidos son una forma de memoria institucional: nosotros
necesita el equipo dedicado para crear los nuevos procesos y aprendizajes necesarios para generar
nuestros resultados deseados, creando nueva memoria institucional.

Crear un equipo dedicado no solo es bueno para el equipo, sino también bueno para el
motor de rendimiento. Al crear un equipo separado, creamos el espacio para que ellos puedan
experimentar con nuevas prácticas, protegiendo al resto de la organización del potencial
interrupciones y distracciones asociadas con él.

ACUERDAN UN OBJETIVO COMPARTIDO

Una de las partes más importantes de cualquier iniciativa de mejora es definir una medida mensurable
objetivo con un plazo claramente definido, entre seis meses y dos años en el futuro. Eso
debería requerir un esfuerzo considerable pero aún ser alcanzable. Y el logro de la meta
debería crear un valor obvio para la organización en general y para nuestros clientes.

Estos objetivos y el plazo deben ser acordados por los ejecutivos y conocidos por
todos en la organización. También queremos limitar el número de estos tipos de
iniciativas que se llevan a cabo simultáneamente para evitar que gravemos demasiado la organización
cambiar la capacidad de gestión de los líderes y la organización. Ejemplos de mejora
los objetivos pueden incluir:

Reduzca el porcentaje del presupuesto gastado en soporte de productos y trabajo no planificado

en un 50%.

Asegúrese de que el tiempo de espera desde el registro del código hasta el lanzamiento de producción sea de una semana o menos para el 95%
de cambios

Asegúrese de que los lanzamientos siempre se puedan realizar durante el horario comercial normal con cero
falta del tiempo.

Integre todos los controles de seguridad de la información necesarios en la tubería de implementación

para pasar todos los requisitos de cumplimiento requeridos.

Una vez que se aclara el objetivo de alto nivel, los equipos deben decidir una cadencia regular para conducir
El trabajo de mejora. Al igual que el trabajo de desarrollo de productos, queremos trabajo de transformación
para hacerse de manera iterativa e incremental. Una iteración típica estará en el rango de
De dos a cuatro semanas. Para cada iteración, los equipos deben acordar un pequeño conjunto de objetivos que
genera valor y progresa hacia la meta a largo plazo. Al final de cada
iteración, los equipos deben revisar su progreso y establecer nuevas metas para la próxima iteración.

MANTENGA NUESTROS HORIZONTES DE PLANIFICACIÓN DE MEJORA CORTO

En cualquier proyecto de transformación de DevOps, debemos mantener nuestros horizontes de planificación cortos, solo
como si estuviéramos en una startup haciendo desarrollo de productos o clientes. Nuestra iniciativa debe
esforzarse por generar mejoras medibles o datos procesables en semanas (o, en el
peor caso, meses).

Al mantener cortos nuestros horizontes de planificación e intervalos de iteración, logramos lo siguiente:

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 111 de 485
Page 109

Flexibilidad y la capacidad de priorizar y volver a planificar rápidamente

Disminuya el retraso entre el trabajo gastado y la mejora realizada, que

fortalece nuestro ciclo de retroalimentación, lo que aumenta la probabilidad de reforzar los comportamientos deseados:
cuando las iniciativas de mejora son exitosas, fomenta más inversión

Aprendizaje más rápido generado desde la primera iteración, lo que significa una integración más rápida de nuestro
aprendizajes en la próxima iteración

Reducción de la energía de activación para obtener mejoras.

Realización más rápida de mejoras que marcan diferencias significativas en nuestro diario
trabajo

Menos riesgo de que nuestro proyecto sea eliminado antes de que podamos generar resultados demostrables

RESERVE EL 20% DE LOS CICLOS PARA REQUISITOS NO FUNCIONALES

Y REDUCIR LA DEUDA TÉCNICA
Un problema común a cualquier esfuerzo de mejora de procesos es cómo priorizarlo adecuadamente:
después de todo, las organizaciones que más lo necesitan son aquellas que tienen la menor cantidad de tiempo para
gastar en mejoras. Esto es especialmente cierto en las organizaciones tecnológicas debido a
deuda técnica.

Las organizaciones que luchan con la deuda financiera solo hacen pagos de intereses y nunca
reducir el capital del préstamo, y eventualmente pueden encontrarse en situaciones donde
ya no puede atender los pagos de intereses. Del mismo modo, las organizaciones que no pagan
la deuda técnica puede verse tan cargada de soluciones diarias para los problemas restantes
sin reparar que ya no pueden completar ningún trabajo nuevo. En otras palabras, ahora son
solo haciendo el pago de intereses sobre su deuda técnica.

Gestionaremos activamente esta deuda técnica asegurándonos de invertir al menos el 20% de todos
Ciclos de desarrollo y operaciones de refactorización, inversión en trabajos de automatización y
arquitectura y requisitos no funcionales (NFR, a veces referidos como
"Ilities"), como mantenibilidad, manejabilidad, escalabilidad, confiabilidad, comprobabilidad,
implementabilidad y seguridad.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 112 de 485
Page 110

Figura 11: Invierta el 20% de los ciclos en aquellos que crean un valor positivo, invisible para el usuario
(Fuente: "Aprendizaje automático y deuda técnica con D. Sculley", Software Engineering Daily
podcast, 17 de noviembre de 2015, http://softwareengineeringdaily.com/2015/11/17/machine-
aprendizaje-y-técnico-deuda-con-d-sculley / .)

Después de la experiencia cercana a la muerte de eBay a fines de la década de 1990, Marty Cagan, autor de
Inspirado: Cómo crear productos que los clientes adoren, el libro seminal sobre diseño de productos
y gestión, codificó la siguiente lección:

El trato [entre los propietarios del producto y] la ingeniería es así: Producto

la administración toma el 20% de la capacidad del equipo desde el principio y le da esto a
ingeniería para gastar como mejor les parezca. Pueden usarlo para reescribir, rediseñar o volver a diseñar
factorizar partes problemáticas de la base del código ... lo que crean que es necesario evitar
alguna vez tener que venir al equipo y decir: 'tenemos que parar y reescribir [todo nuestro código]'.
Si hoy estás en muy mal estado, es posible que necesites hacer este 30% o incluso más de
Los recursos. Sin embargo, me pongo nervioso cuando encuentro equipos que piensan que pueden escapar
con mucho menos del 20%.

Cagan señala que cuando las organizaciones no pagan su "impuesto del 20%", la deuda técnica lo hará
aumentar hasta el punto en que una organización gasta inevitablemente todos sus ciclos pagando
abajo de la deuda técnica. En algún momento, los servicios se vuelven tan frágiles que la entrega de funciones
se detiene porque todos los ingenieros están trabajando en problemas de confiabilidad o trabajando
alrededor de los problemas

Al dedicar el 20% de nuestros ciclos para que Dev y Ops puedan crear contramedidas duraderas
A los problemas que encontramos en nuestro trabajo diario, nos aseguramos de que la deuda técnica no
impedir nuestra capacidad de desarrollar y operar nuestros servicios en producción de manera rápida y segura.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 113 de 485
 Elevar la presión adicional de la deuda técnica de los trabajadores también puede reducir los niveles de
agotamiento

Caso de estudio
Operation InVersion en LinkedIn (2011)
Operation InVersion de LinkedIn presenta un interesante caso de estudio que ilustra
La necesidad de pagar la deuda técnica como parte del trabajo diario. Seis meses después de su
IPO exitosa en 2011, LinkedIn continuó luchando con problemas
implementaciones que se volvieron tan dolorosas que lanzaron Operation InVersion,
donde detuvieron todo el desarrollo de características durante dos meses para revisar
sus entornos informáticos, implementaciones y arquitectura.

Página 111

LinkedIn fue creado en 2003 para ayudar a los usuarios a "conectarse a su red para un mejor trabajo
oportunidades ". Al final de su primera semana de operaciones, tenían 2.700 miembros.
Un año después, tenían más de un millón de miembros y crecieron exponencialmente.
desde entonces. Para noviembre de 2015, LinkedIn tenía más de 350 millones de miembros, que
generar decenas de miles de solicitudes por segundo, lo que resulta en millones de consultas
por segundo en los sistemas de back-end de LinkedIn.

Desde el principio, LinkedIn se ejecutó principalmente en su aplicación Leo local, un

Aplicación Java monolítica que sirvió a cada página a través de servlets y gestionó
Conexiones JDBC a varias bases de datos Oracle de back-end. Sin embargo, para mantenerse al día
Con el creciente tráfico en sus primeros años, dos servicios críticos fueron desconectados de
Leo: las primeras consultas manejadas alrededor del gráfico de conexión de miembros enteramente
memoria, y el segundo fue la búsqueda de miembros, que superó al primero.

Para 2010, la mayoría de los nuevos desarrollos ocurrían en nuevos servicios, con casi uno
Cien servicios que se ejecutan fuera de Leo. El problema era que Leo solo era
desplegarse una vez cada dos semanas.

Josh Clemm, gerente senior de ingeniería en LinkedIn, explicó que para 2010,
La empresa tenía problemas importantes con Leo. A pesar de escalar verticalmente
Leo al agregar memoria y CPU, "Leo a menudo bajaba en producción, era
difícil de solucionar y recuperar, y difícil de liberar nuevo código ... Estaba claro
necesitábamos 'matar a Leo' y dividirlo en muchos pequeños funcionales y apátridas
servicios."

En 2013, la periodista Ashlee Vance de Bloomberg describió cómo "cuando LinkedIn

intentaría agregar un montón de cosas nuevas a la vez, el sitio se desmoronaría
desorden roto, que requiere que los ingenieros trabajen hasta bien entrada la noche y solucionen los problemas ".
Para el otoño de 2011, las noches ya no eran un rito de iniciación o una actividad de unión,
porque los problemas se habían vuelto intolerables. Algunos de los mejores ingenieros de LinkedIn,

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 114 de 485
 incluido Kevin Scott, que se había unido como vicepresidente de ingeniería de LinkedIn tres
meses antes de su oferta pública inicial, decidió dejar por completo de ingeniería
trabajar en nuevas funciones y dedicar todo el departamento a arreglar el núcleo del sitio
infraestructura. Llamaron al esfuerzo Operación Inversión.

Scott lanzó Operation InVersion como una forma de "inyectar los inicios de una cultura
manifiesto en la cultura de ingeniería de su equipo. No habría una nueva característica
desarrollo hasta que se modernizó la arquitectura informática de LinkedIn, eso es lo que
los negocios y su equipo lo necesitaban ".

Scott describió una desventaja: "Haz público, tienes todo el mundo mirándote,
y luego le decimos a la gerencia que no vamos a entregar nada nuevo mientras todos
de trabajos de ingeniería en este proyecto [InVersion] para los próximos dos meses. Era un
cosa aterradora ".

Sin embargo, Vance describió los resultados masivamente positivos de Operation InVersion.
"LinkedIn creó un conjunto completo de software y herramientas para ayudarlo a desarrollar código para
el sitio. En lugar de esperar semanas para que sus nuevas funciones lleguen a
El sitio principal de LinkedIn, los ingenieros podrían desarrollar un nuevo servicio, tener una serie de
los sistemas automatizados examinan el código en busca de errores y problemas que el servicio pueda

112

interactuar con las funciones existentes y lanzarlo directamente al sitio de LinkedIn en vivo ...
El cuerpo de ingeniería de LinkedIn [ahora] realiza importantes actualizaciones al sitio tres veces
un día." Al crear un sistema de trabajo más seguro, el valor que crearon incluyó menos
sesiones nocturnas de hacinamiento, con más tiempo para desarrollar características nuevas e innovadoras.

Como Josh Clemm describió en su artículo sobre el escalado en LinkedIn, "el escalado puede ser
medido en muchas dimensiones, incluida la organización ... [Operación
InVersion] permitió a toda la organización de ingeniería centrarse en mejorar
herramientas e implementación, infraestructura y productividad del desarrollador. Era
exitosos en permitir la agilidad de ingeniería, necesitamos construir el nuevo escalable
productos que tenemos hoy ... [En] 2010, ya teníamos más de 150 servicios separados.
Hoy tenemos más de 750 servicios ".

Kevin Scott declaró: “Tu trabajo como ingeniero y tu propósito como tecnología
El equipo es ayudar a su empresa a ganar. Si lideras un equipo de ingenieros, es mejor
tomar la perspectiva de un CEO. Su trabajo es descubrir qué es lo que su empresa,
necesita su negocio, su mercado, su entorno competitivo. Aplicar eso
a su equipo de ingeniería para que su empresa gane ".

Al permitir que LinkedIn pague casi una década de deuda técnica, Project
InVersion permitió estabilidad y seguridad, al tiempo que estableció la siguiente etapa de crecimiento para el
empresa. Sin embargo, requirió dos meses de enfoque total en no funcional
requisitos, a expensas de todas las funciones prometidas hechas al público

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 115 de 485
 mercados durante una salida a bolsa. Al encontrar y solucionar problemas como parte de nuestro trabajo diario, nosotros
administrar nuestra deuda técnica para evitar estas experiencias de "casi muerte".

AUMENTAR LA VISIBILIDAD DEL TRABAJO

Para poder saber si estamos progresando hacia nuestra meta, es esencial que
Todos en la organización conocen el estado actual del trabajo. Hay muchas maneras de
hacer visible el estado actual, pero lo más importante es que la información que
la pantalla está actualizada y revisamos constantemente lo que medimos para asegurarnos de que
ayudándonos a comprender el progreso hacia nuestras condiciones objetivo actuales.

La siguiente sección discute patrones que pueden ayudar a crear visibilidad y alineación
entre equipos y funciones.

UTILICE HERRAMIENTAS PARA REFORZAR EL COMPORTAMIENTO DESEADO

Como Christopher Little, un ejecutivo de software y uno de los primeros cronistas de DevOps,
observó: “Los antropólogos describen las herramientas como un artefacto cultural. Cualquier discusión sobre cultura
después de la invención del fuego también debe tratarse de herramientas ". Del mismo modo, en el valor DevOps
Stream, utilizamos herramientas para reforzar nuestra cultura y acelerar los cambios de comportamiento deseados.

Un objetivo es que nuestras herramientas refuercen que Desarrollo y Operaciones no solo tienen
objetivos compartidos, pero tienen un trabajo atrasado común, idealmente almacenado en un trabajo común
sistema y usando un vocabulario compartido, para que el trabajo pueda ser priorizado globalmente.

Al hacer esto, Desarrollo y Operaciones pueden terminar creando una cola de trabajo compartida,
en lugar de que cada silo use uno diferente (por ejemplo, Desarrollo usa JIRA mientras que Operaciones

113

usa ServiceNow). Un beneficio significativo de esto es que cuando los incidentes de producción son
mostrado en los mismos sistemas de trabajo que el trabajo de desarrollo, será obvio cuando esté en curso
los incidentes deberían detener otro trabajo, especialmente cuando tenemos una junta kanban.

Otro beneficio de tener Desarrollo y Operaciones usando una herramienta compartida es un

trabajo atrasado, donde todos priorizan proyectos de mejora desde una perspectiva global,
Seleccionar el trabajo que tiene el mayor valor para la organización o que más reduce
deuda. A medida que identificamos la deuda técnica, la agregamos a nuestra reserva prioritaria si no podemos
abordarlo de inmediato. Para problemas que no se han resuelto, podemos usar nuestro "20% de tiempo
para requisitos no funcionales "para corregir los elementos principales de nuestra cartera de pedidos.

Otras tecnologías que refuerzan los objetivos compartidos son las salas de chat, como los canales IRC,
HipChat, Campfire, Slack, Flowdock y OpenFire. Las salas de chat permiten compartir rápidamente
información (en lugar de completar formularios que se procesan a través de predefinidos
flujos de trabajo), la capacidad de invitar a otras personas según sea necesario y registros de historial que son

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 116 de 485
 se registra automáticamente para la posteridad y se puede analizar durante las sesiones post-mortem.
Se crea una dinámica sorprendente cuando tenemos un mecanismo que permite a cualquier equipo
miembro para ayudar rápidamente a otros miembros del equipo, o incluso a personas ajenas a su equipo:
El tiempo requerido para obtener información o el trabajo necesario puede ir de días a minutos. En
Además, debido a que todo se está grabando, es posible que no necesitemos pedirle a otra persona
ayuda en el futuro, simplemente la buscamos.

Sin embargo, el entorno de comunicación rápida facilitado por las salas de chat también puede ser un
retirarse. Como Ryan Martens, el fundador y CTO de Rally Software, observa: "En un chat
habitación, si alguien no recibe una respuesta en un par de minutos, es totalmente aceptado y
esperaba que puedas volver a molestarlos hasta que obtengan lo que necesitan ".

Las expectativas de respuesta inmediata pueden, por supuesto, conducir a resultados no deseados. UN
El aluvión constante de interrupciones y preguntas puede evitar que las personas
trabajo necesario hecho. Como resultado, los equipos pueden decidir que ciertos tipos de solicitudes deberían
pasar por herramientas más estructuradas y asincrónicas.

CONCLUSIÓN

En este capítulo, identificamos a todos los equipos que respaldan nuestro flujo de valor y los capturamos en
un mapa de flujo de valor qué trabajo se requiere para entregar valor al cliente. los
El mapa de flujo de valor proporciona la base para comprender nuestro estado actual, incluido nuestro
tiempo de entrega y métricas de% C / A para áreas problemáticas, e informa cómo establecemos un futuro
estado.

Esto permite a los equipos de transformación dedicados iterar y experimentar rápidamente para
mejorar el rendimiento. También nos aseguramos de asignar una cantidad de tiempo suficiente para
mejora, solucionando problemas conocidos y problemas arquitectónicos, incluyendo nuestros
requerimientos funcionales. Los estudios de caso de Nordstrom y LinkedIn demuestran
cómo se pueden hacer mejoras dramáticas en los plazos y la calidad cuando encontramos
problemas en nuestro flujo de valor y pagar deuda técnica.

† Lo que hace que sea aún más importante que limitemos el nivel de detalle que se recopila: el tiempo de todos es valioso y escaso.

114

• Por el contrario, hay muchos ejemplos de uso de herramientas de una manera que garantiza que no ocurran cambios de comportamiento. Por ejemplo, una organización se compromete a un

herramienta de planificación ágil, pero luego la configura para un proceso en cascada, que simplemente mantiene el status quo.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 117 de 485
115 de 1189.
116

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 118 de 485
 7
Mente
Organización y
Arquitectura con
Cómo diseñar nuestro
Ley de Conway en

En los capítulos anteriores, identificamos un flujo de valor para comenzar nuestra transformación DevOps
y estableció objetivos y prácticas compartidas para permitir que un equipo de transformación dedicado a
Mejorar la forma en que entregamos valor al cliente.

En este capítulo, comenzaremos a pensar en cómo organizarnos para lograr mejor nuestro
objetivos de flujo de valor. Después de todo, cómo organizamos nuestros equipos afecta cómo realizamos nuestro trabajo.
El Dr. Melvin Conway realizó un famoso experimento en 1968 con una investigación por contrato.
organización que tenía ocho personas encargadas de producir un COBOL y un
Compilador ALGOL. Observó: "Después de algunas estimaciones iniciales de dificultad y tiempo, cinco
las personas fueron asignadas al trabajo de COBOL y tres al trabajo de ALGOL. El COBOL resultante
el compilador se ejecutó en cinco fases, el compilador ALGOL se ejecutó en tres ".

Estas observaciones condujeron a lo que ahora se conoce como la Ley de Conway, que establece que
"Las organizaciones que diseñan sistemas ... están obligadas a producir diseños que son copias
de las estructuras de comunicación de estas organizaciones ... Cuanto más grande es una organización, más
menos flexibilidad tiene y más pronunciado es el fenómeno ". Eric S. Raymond, autor
del libro La catedral y el bazar: reflexiones sobre Linux y código abierto por un
Accidental Revolutionary , creó una versión simplificada (y ahora más famosa) de
Ley de Conway en su archivo de jerga: "La organización del software y la organización de
el equipo de software será congruente; comúnmente indicado como 'si tienes cuatro grupos trabajando
en un compilador, obtendrás un compilador de 4 pasadas ".

En otras palabras, cómo organizamos nuestros equipos tiene un poderoso efecto en el software que
producir, así como nuestros resultados arquitectónicos y de producción resultantes. Para obtener
Flujo rápido de trabajo desde el desarrollo hasta las operaciones, con alta calidad y excelente cliente
resultados, debemos organizar nuestros equipos y nuestro trabajo para que la Ley de Conway funcione para nuestros
ventaja. Si se hace mal, la Ley de Conway evitará que los equipos trabajen de manera segura y
independientemente; en cambio, estarán estrechamente unidos, todos esperándose el uno al otro
trabajo por hacer, incluso con pequeños cambios que crean catástrofes potencialmente globales
Consecuencias.

Un ejemplo de cómo la Ley de Conway puede impedir o reforzar nuestros objetivos se puede ver en un
tecnología desarrollada en Etsy llamada Sprouter. El viaje de DevOps de Etsy comenzó en
2009, y es una de las organizaciones DevOps más admiradas, con ingresos en 2014 de casi
$ 200 millones y una OPV exitosa en 2015.

Desarrollado originalmente en 2007, Sprouter conectó personas, procesos y tecnología en

formas que crearon muchos resultados no deseados. Sprouter, abreviatura de "procedimiento almacenado

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 119 de 485
Página 117

enrutador ", fue diseñado originalmente para ayudar a facilitar la vida de los desarrolladores y la base de datos
equipos Como dijo Ross Snyder, ingeniero senior en Etsy, durante su presentación en Surge
2011, "Sprouter fue diseñado para permitir que los equipos de desarrollo escriban código PHP en la aplicación,
los DBA para escribir SQL dentro de Postgres, con Sprouter ayudándolos a encontrarse en el medio ".

Sprouter residía entre su aplicación PHP front-end y la base de datos Postgres,

centralizando el acceso a la base de datos y ocultando la implementación de la base de datos
capa de aplicación. El problema era que agregar cualquier cambio en la lógica de negocios resultó en
fricción significativa entre los desarrolladores y los equipos de bases de datos. Como observó Snyder, "para
casi cualquier nueva funcionalidad del sitio, Sprouter requería que los DBA escribieran un nuevo archivo almacenado
procedimiento. Como resultado, cada vez que los desarrolladores quisieran agregar una nueva funcionalidad, lo harían
necesitan algo de los DBA, que a menudo les obligaba a atravesar un montón de
burocracia." En otras palabras, los desarrolladores que crean nuevas funcionalidades dependen de
el equipo de DBA, que necesitaba ser priorizado, comunicado y coordinado, resultando
en el trabajo sentado en colas, reuniones, plazos de entrega más largos, etc. Esto es porque
Sprouter creó un fuerte acoplamiento entre los equipos de desarrollo y de bases de datos,
evitar que los desarrolladores puedan desarrollar, probar e implementar de forma independiente sus
código en producción.

Además, los procedimientos almacenados de la base de datos estaban estrechamente acoplados a Sprouter, en cualquier momento
se cambió el procedimiento, también requirió cambios en Sprouter. El resultado fue que Sprouter
se convirtió en un único punto de falla cada vez más grande. Snyder explicó que todo era tan
estrechamente acoplado y requirió un nivel tan alto de sincronización como resultado, que casi
cada despliegue causó una mini interrupción.

Se pueden explicar tanto los problemas asociados con Sprouter como su eventual solución.
por la ley de Conway. Etsy inicialmente tenía dos equipos, los desarrolladores y los DBA, que eran
cada uno responsable de dos capas del servicio, la capa lógica de la aplicación y almacenada
capa de procedimiento Dos equipos trabajando en dos capas, como predice la Ley de Conway. Sprouter fue
pretendía facilitar la vida de ambos equipos, pero no funcionó como se esperaba, cuando los negocios
las reglas cambiaron, en lugar de cambiar solo dos capas, ahora necesitaban hacer cambios en
tres capas (en la aplicación, en los procedimientos almacenados y ahora en Sprouter). los
Los desafíos resultantes de coordinar y priorizar el trabajo en tres equipos significativamente
aumentaron los tiempos de entrega y causaron problemas de confiabilidad.

En la primavera de 2009, como parte de lo que Snyder llamó "el gran cultural de Etsy
transformación ", se unió Chad Dickerson como su nuevo CTO. Dickerson se puso en movimiento
muchas cosas, incluida una inversión masiva en la estabilidad del sitio, hacer que los desarrolladores realicen
sus propios despliegues en producción, así como comenzar un viaje de dos años para
Eliminar Sprouter.

Para hacer esto, el equipo decidió mover toda la lógica empresarial de la capa de base de datos al
capa de aplicación, eliminando la necesidad de Sprouter. Crearon un pequeño equipo que escribió un
Capa de mapeo relacional de objetos PHP (ORM),† permitiendo a los desarrolladores front-end hacer
llama directamente a la base de datos y reduce la cantidad de equipos necesarios para cambiar
lógica de negocios desde tres equipos hasta un equipo.

Como describió Snyder, “Comenzamos a usar el ORM para cualquier área nueva del sitio y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 120 de 485
 migró pequeñas partes de nuestro sitio desde Sprouter a ORM con el tiempo. Nos tomó dos años

118

para migrar todo el sitio fuera de Sprouter. Y a pesar de que todos nos quejamos de Sprouter
todo el tiempo, se mantuvo en producción en todo momento ".

Al eliminar Sprouter, también eliminaron los problemas asociados con múltiples equipos
necesidad de coordinar cambios de lógica de negocios, disminución del número de traspasos y
aumentó significativamente la velocidad y el éxito de las implementaciones de producción, mejorando el sitio
estabilidad. Además, debido a que los equipos pequeños podrían desarrollar e implementar independientemente
código sin requerir que otro equipo realice cambios en otras áreas del sistema,
La productividad del desarrollador aumentó.

Sprouter finalmente se eliminó de la producción y los repositorios de control de versiones de Etsy en

principios de 2001. Como dijo Snyder, "Wow, se sintió bien". ‡

Como Snyder y Etsy experimentaron, cómo diseñamos nuestra organización dicta cómo es el trabajo
realizado, y, por lo tanto, los resultados que logramos. Durante el resto de este capítulo, nosotros
explorará cómo la Ley de Conway puede afectar negativamente el rendimiento de nuestro flujo de valor,
y, lo que es más importante, cómo organizamos nuestros equipos para utilizar la Ley de Conway en nuestro beneficio.

ARQUETÍAS ORGANIZACIONALES

En el campo de las ciencias de decisión, existen tres tipos principales de estructuras organizativas.
que informan cómo diseñamos nuestros flujos de valor DevOps teniendo en cuenta la Ley de Conway:
funcional , matriz y mercado . Los define el Dr. Roberto Fernández de la siguiente manera:

Las organizaciones orientadas a la funcionalidad optimizan la experiencia, la división del trabajo o la reducción
costo. Estas organizaciones centralizan la experiencia, lo que ayuda a permitir el crecimiento profesional y
desarrollo de habilidades, y a menudo tienen estructuras organizativas jerárquicas altas. Esto tiene
ha sido el método predominante de organización para Operaciones (es decir, administradores de servidores, redes
administradores, administradores de bases de datos, etc., están organizados en grupos separados).

Las organizaciones orientadas a matrices intentan combinar la orientación funcional y de mercado.

Sin embargo, como muchos de los que trabajan o administran organizaciones matriciales observan, la matriz
Las organizaciones a menudo resultan en estructuras organizacionales complicadas, como
contribuyentes que reportan a dos gerentes o más, y algunas veces no logran ninguno de
Los objetivos de orientación funcional o de mercado.

Las organizaciones orientadas al mercado optimizan para responder rápidamente a las necesidades del cliente.
Estas organizaciones tienden a ser planas, compuestas de múltiples disciplinas multifuncionales
(por ejemplo, marketing, ingeniería, etc.), que a menudo conducen a posibles redundancias en
la organización. Así es como operan muchas organizaciones prominentes que adoptan DevOps

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 121 de 485
 —En ejemplos extremos, como en Amazon o Netflix, cada equipo de servicio es
simultáneamente responsable de la entrega de funciones y el soporte del servicio.§

Con estas tres categorías de organizaciones en mente, exploremos más a fondo cómo
La orientación funcional, especialmente en las operaciones, puede causar resultados no deseados en el
flujo de valor tecnológico, como predeciría la Ley de Conway.

Page 119

PROBLEMAS A MENUDO CAUSADOS POR FUNCIONAMIENTO EXCESIVO

ORIENTACIÓN ("OPTIMIZAR POR EL COSTO")

En las organizaciones tradicionales de operaciones de TI, a menudo utilizamos orientación funcional para organizar
nuestros equipos por sus especialidades. Ponemos a los administradores de la base de datos en un grupo, el
administradores de red en otro, los administradores del servidor en un tercero, y así sucesivamente. Uno
Una de las consecuencias más visibles de esto son los largos plazos de entrega, especialmente para actividades complejas.
como implementaciones grandes donde debemos abrir tickets con múltiples grupos y coordinar
transferencias de trabajo, lo que resulta en nuestro trabajo esperando en largas colas en cada paso.

Para agravar el problema, la persona que realiza el trabajo a menudo tiene poca visibilidad o
comprensión de cómo su trabajo se relaciona con cualquier objetivo de flujo de valor (por ejemplo, "Solo soy
configurando servidores porque alguien me lo dijo "). Esto coloca a los trabajadores en una creatividad y
vacío de motivación

El problema se exacerba cuando cada área funcional de Operaciones tiene que servir a múltiples
flujos de valor (es decir, múltiples equipos de desarrollo) que compiten por sus escasos ciclos. En
Para que los equipos de desarrollo realicen su trabajo de manera oportuna, a menudo tenemos que
escalar problemas a un gerente o director, y eventualmente a alguien (generalmente un ejecutivo)
quien finalmente puede priorizar el trabajo contra los objetivos organizacionales globales en lugar de
objetivos funcionales del silo. Esta decisión debe luego caer en cascada en cada una de las funciones
áreas para cambiar las prioridades locales, y esto, a su vez, ralentiza a otros equipos. Cuando cada
equipo agiliza su trabajo, el resultado neto es que cada proyecto termina moviéndose al mismo
lento arrastre

Además de las largas colas y los largos plazos de entrega, esta situación resulta en transferencias pobres, grandes
cantidades de reelaboración, problemas de calidad, cuellos de botella y demoras. Este embotellamiento impide la
logro de objetivos organizacionales importantes, que a menudo superan con creces el deseo de
reducir costos. ¶

Del mismo modo, la orientación funcional también se puede encontrar con QA centralizado e Infosec
funciones, que pueden haber funcionado bien (o al menos, lo suficientemente bien) al realizar menos
lanzamientos frecuentes de software. Sin embargo, a medida que aumentamos el número de equipos de desarrollo
y sus frecuencias de despliegue y lanzamiento, la mayoría de las organizaciones orientadas funcionalmente

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 122 de 485
 tendrá dificultades para mantenerse y entregar resultados satisfactorios, especialmente cuando su
El trabajo se realiza manualmente. Ahora estudiaremos cómo las organizaciones orientadas al mercado
trabajo.

HABILITAR EQUIPOS ORIENTADOS AL MERCADO ("OPTIMIZAR PARA

VELOCIDAD")

En términos generales, para lograr los resultados de DevOps, necesitamos reducir los efectos de
orientación ("optimización de costos") y permitir la orientación del mercado ("optimización de velocidad")
para que podamos tener muchos equipos pequeños trabajando de forma segura e independiente, entregando rápidamente
valor para el cliente.

Llevado al extremo, los equipos orientados al mercado son responsables no solo de la función
desarrollo, pero también para probar, asegurar, implementar y respaldar su servicio en
producción, desde la concepción de la idea hasta la jubilación. Estos equipos están diseñados para ser cruzados

120

funcional e independiente: capaz de diseñar y ejecutar experimentos de usuarios, construir y entregar

nuevas características, despliegue y ejecute su servicio en producción, y repare cualquier defecto sin
dependencias manuales de otros equipos, lo que les permite moverse más rápido. Este modelo tiene
sido adoptado por Amazon y Netflix y Amazon lo promociona como uno de los principales
razones detrás de su capacidad de moverse rápido incluso a medida que crecen.

Para lograr la orientación al mercado, no haremos una gran reorganización de arriba hacia abajo, que a menudo
crea grandes cantidades de interrupción, miedo y parálisis. En su lugar, integraremos el
ingenieros funcionales y habilidades (por ejemplo, Ops, QA, Infosec) en cada equipo de servicio, o proporcionar
sus capacidades a los equipos a través de plataformas automáticas de autoservicio que brindan
entornos similares a la producción, iniciar pruebas automatizadas o realizar implementaciones.

Esto permite que cada equipo de servicio brinde valor de forma independiente al cliente sin
tener que abrir tickets con otros grupos, como IT Operations, QA o Infosec. ** **

HACIENDO TRABAJOS DE ORIENTACIÓN FUNCIONALES

Habiendo recomendado equipos orientados al mercado, vale la pena señalar que es

posible crear organizaciones efectivas de alta velocidad con orientación funcional. Cruzar-
Los equipos funcionales y orientados al mercado son una forma de lograr un flujo rápido y confiabilidad, pero
No son el único camino. También podemos lograr los resultados deseados de DevOps a través de
orientación funcional, siempre y cuando todos en el flujo de valor vean al cliente y
resultados organizacionales como un objetivo compartido, independientemente de dónde residan en el
organización.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 123 de 485
 Figura 12: orientación funcional frente a mercado

Izquierda: orientación funcional: todo el trabajo fluye a través de operaciones de TI centralizadas; Derecha: mercado
orientación: todos los equipos de productos pueden implementar sus componentes de autoservicio sueltos en
producción. (Fuente: Humble, Molesky y O'Reilly, Lean Enterprise , edición Kindle, 4523 y
4592.)

Por ejemplo, alto rendimiento con operaciones centralizadas y orientadas a la funcionalidad.

grupo es posible, siempre y cuando los equipos de servicio obtengan lo que necesitan de las operaciones de manera confiable y
rápidamente (idealmente bajo demanda) y viceversa. Muchos de los DevOps más admirados
Las organizaciones conservan la orientación funcional de las operaciones, incluidos Etsy, Google y
GitHub.

Lo que estas organizaciones tienen en común es una cultura de alta confianza que permite a todos
departamentos para trabajar juntos de manera efectiva, donde todo el trabajo tiene prioridad transparente y

Page 121

hay suficiente holgura en el sistema para permitir que el trabajo de alta prioridad se complete rápidamente.
Esto es, en parte, habilitado por plataformas automáticas de autoservicio que incorporan calidad en el
productos que todos están construyendo.

En el movimiento de manufactura esbelta de la década de 1980, muchos investigadores quedaron perplejos por
La orientación funcional de Toyota, que estaba en desacuerdo con la mejor práctica de tener cross-
equipos funcionales, orientados al mercado. Estaban tan perplejos que se llamó "el segundo Toyota
paradoja."

Como Mike Rother escribió en Toyota Kata : "Por tentador que parezca, uno no puede reorganizarse
su camino hacia la mejora continua y la adaptabilidad. Lo decisivo no es la forma de
la organización, pero cómo las personas actúan y reaccionan. Las raíces del éxito de Toyota no radican en su
estructuras organizativas, pero en el desarrollo de capacidades y hábitos en su gente. Sorprende
mucha gente, de hecho, para encontrar que Toyota está en gran medida organizada en un tradicional, funcional-
estilo departamento ". Es este desarrollo de hábitos y capacidades en las personas y el
mano de obra que es el foco de nuestras próximas secciones.

PRUEBAS, OPERACIONES Y SEGURIDAD COMO TODOS

TRABAJO CADA DÍA

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 124 de 485
 En las organizaciones de alto rendimiento, todos los miembros del equipo comparten un objetivo común:
la calidad, la disponibilidad y la seguridad no son responsabilidad de los departamentos individuales, pero
son parte del trabajo de todos, todos los días.

Esto significa que el problema más urgente del día puede ser trabajar o implementar un
característica del cliente o reparación de un incidente de producción de Gravedad 1. Alternativamente, el día puede
requieren revisar el cambio de un compañero ingeniero, aplicando parches de seguridad de emergencia para
servidores de producción o mejoras para que los compañeros ingenieros sean más productivos.

Reflexionando sobre objetivos compartidos entre Desarrollo y Operaciones, Jody Mulkey, CTO en
Ticketmaster dijo: "Durante casi 25 años, utilicé una metáfora del fútbol americano para describir
Dev y Ops. Sabes, Ops es defensa, quien evita que el otro equipo anote, y Dev es
ofensiva, tratando de marcar goles. Y un día, me di cuenta de cuán defectuosa era esta metáfora,
porque nunca todos juegan en el campo al mismo tiempo. En realidad no están en el mismo
¡equipo!"

Él continuó: "La analogía que uso ahora es que Ops son los linieros ofensivos, y Dev son
las posiciones de 'habilidad' (como el mariscal de campo y los receptores abiertos) cuyo trabajo es mover el
bola abajo en el campo: el trabajo de Ops es ayudar a garantizar que Dev tenga suficiente tiempo para
ejecutar las jugadas ".

Un ejemplo sorprendente de cómo el dolor compartido puede reforzar los objetivos compartidos es cuando Facebook fue
experimentando un enorme crecimiento en 2009. Experimentaban problemas significativos
relacionado con las implementaciones de código, aunque no todos los problemas causaron problemas que afectan al cliente, hay
Fue crónico de extinción de incendios y largas horas. Pedro Canahuati, su director de producción.
ingeniería, describió una reunión llena de ingenieros de operaciones donde alguien preguntó que todos
las personas que no trabajan en un incidente cierran sus computadoras portátiles y nadie puede hacerlo.

Una de las cosas más importantes que hicieron para ayudar a cambiar los resultados de las implementaciones
era hacer que todos los ingenieros, gerentes de ingeniería y arquitectos de Facebook rotaran

Page 122

servicio de guardia por los servicios que construyeron. Al hacer esto, todos los que trabajaron en el servicio
retroalimentación visceral experimentada sobre las decisiones arquitectónicas y de codificación aguas arriba que
hecho, lo que tuvo un enorme impacto positivo en los resultados posteriores.

PERMITA QUE CADA MIEMBRO DEL EQUIPO SEA GENERALISTA

En casos extremos de una organización de Operaciones orientada funcionalmente, tenemos departamentos

de especialistas, como administradores de red, administradores de almacenamiento, etc. Cuando
los departamentos se especializan en exceso , provoca la siloización , que el Dr. Spear describe como cuando
los departamentos "operan más como estados soberanos". Cualquier actividad operacional compleja entonces
requiere múltiples transferencias y colas entre las diferentes áreas de la infraestructura,

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 125 de 485
 lo que lleva a tiempos de entrega más largos (por ejemplo, porque cada cambio de red debe ser realizado por alguien
en el departamento de redes).

Debido a que confiamos en un número cada vez mayor de tecnologías, debemos tener ingenieros
que se han especializado y logrado el dominio en las áreas tecnológicas que necesitamos. Sin embargo, nos
no quieren crear especialistas que estén "congelados en el tiempo", que solo comprendan y puedan
contribuir a esa área del flujo de valor.

Una contramedida es permitir y alentar a cada miembro del equipo a ser generalista. Nosotros
haga esto proporcionando oportunidades para que los ingenieros aprendan todas las habilidades necesarias para construir
y ejecutar los sistemas de los que son responsables y rotar regularmente a las personas
diferentes roles El término ingeniero de pila completa ahora se usa comúnmente (a veces como un rico
fuente de parodia) para describir a los generalistas que están familiarizados, al menos tienen un nivel general de
comprensión: con toda la pila de aplicaciones (por ejemplo, código de aplicación, bases de datos,
sistemas operativos, redes, nube).

Tabla 2: Especialistas vs. Generalistas vs. Personal "en forma de E" (experiencia, pericia, exploración y
ejecución)

(Fuente: Scott Prugh, "Entrega continua", ScaledAgileFramework.com, 14 de febrero de 2013,

http://scaledagileframework.com/continuous-delivery/.)

Scott Prugh escribe que CSG International ha sufrido una transformación que trae
La mayoría de los recursos necesarios para compilar y ejecutar el producto en un equipo, incluido el análisis,
arquitectura, desarrollo, prueba y operaciones. "Por entrenamiento cruzado y crecimiento

123

habilidades de ingeniería, los generalistas pueden hacer mucho más trabajo que sus especialistas
contrapartes, y también mejora nuestro flujo general de trabajo al eliminar colas y esperar
hora." Este enfoque está en desacuerdo con las prácticas de contratación tradicionales, pero, como explica Prugh,
vale la pena "Los gerentes tradicionales a menudo se opondrán a contratar ingenieros con generalistas
conjuntos de habilidades, argumentando que son más caros y que 'puedo contratar dos servidores

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 126 de 485
 administradores para cada ingeniero de operaciones multidisciplinar ". Sin embargo, el negocio
Los beneficios de permitir un flujo más rápido son abrumadores. Además, como señala Prugh,
“[Invertir] en capacitación cruzada es lo correcto para el crecimiento profesional [de los empleados] y hace que
el trabajo de todos es más divertido ".

Cuando valoramos a las personas simplemente por sus habilidades o desempeño existentes en su rol actual
en lugar de por su capacidad de adquirir y desplegar nuevas habilidades, nosotros (a menudo inadvertidamente)
Reforzar lo que la Dra. Carol Dweck describe como la mentalidad fija , donde las personas ven sus
inteligencia y habilidades como "donaciones" estáticas que no se pueden cambiar de manera significativa.

En cambio, queremos fomentar el aprendizaje, ayudar a las personas a superar la ansiedad de aprendizaje, ayudar
asegúrese de que las personas tengan habilidades relevantes y una hoja de ruta profesional definida, y así sucesivamente. Por
Al hacer esto, ayudamos a fomentar una mentalidad de crecimiento en nuestros ingenieros, después de todo, un aprendizaje
La organización requiere personas que estén dispuestas a aprender. Al alentar a todos a aprender, como
además de brindar capacitación y apoyo, creamos los más sostenibles y menos costosos
forma de crear grandeza en nuestros equipos, invirtiendo en el desarrollo de las personas que
ya tengo.

Como Jason Cox, Director de Ingeniería de Sistemas en Disney, describió: "Dentro de las operaciones,
tuvimos que cambiar nuestras prácticas de contratación. Buscamos personas que tuvieran 'curiosidad, coraje,
y franqueza, 'que no solo eran capaces de ser generalistas sino también renegados ... Queremos
para promover la interrupción positiva para que nuestro negocio no se atasque y pueda pasar a la
futuro." Como veremos en la siguiente sección, cómo financiamos a nuestros equipos también afecta nuestros resultados.

FONDO NO PROYECTOS, SINO SERVICIOS Y PRODUCTOS

Otra forma de permitir resultados de alto rendimiento es crear equipos de servicio estables con
financiación continua para ejecutar su propia estrategia y hoja de ruta de iniciativas. Estos equipos
tienen los ingenieros dedicados necesarios para cumplir con los compromisos concretos contraídos a nivel interno
y clientes externos, como características, historias y tareas.

Compare esto con el modelo más tradicional donde los equipos de Desarrollo y Prueba son
asignado a un "proyecto" y luego reasignado a otro proyecto tan pronto como el proyecto esté
completado y se agota el financiamiento. Esto conduce a todo tipo de resultados no deseados, incluidos
los desarrolladores no pueden ver las consecuencias a largo plazo de las decisiones que toman (un formulario
de retroalimentación) y un modelo de financiación que solo valora y paga las primeras etapas de la
ciclo de vida del software, que, trágicamente, es también la parte menos costosa para productos exitosos
o servicios.††

Nuestro objetivo con un modelo de financiación basado en productos es valorar el logro de la organización
y resultados del cliente, como ingresos, valor de por vida del cliente o adopción del cliente
tasa, idealmente con el mínimo de salida (por ejemplo, cantidad de esfuerzo o tiempo, líneas de código).
Compare esto con la forma en que se miden los proyectos, por ejemplo, si se completó
dentro del presupuesto prometido, el tiempo y el alcance.

Page 124

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 127 de 485
 DISEÑO DE LÍMITES DE EQUIPO DE ACUERDO CON
LEY DE CONWAY

A medida que las organizaciones crecen, uno de los mayores desafíos es mantenerse eficaz
comunicación y coordinación entre personas y equipos. Con demasiada frecuencia, cuando las personas
y los equipos residen en un piso diferente, en un edificio diferente o en una zona horaria diferente,
crear y mantener un entendimiento compartido y una confianza mutua se vuelve más difícil,
impidiendo una colaboración efectiva. La colaboración también se ve obstaculizada cuando la primaria
Los mecanismos de comunicación son tickets de trabajo y solicitudes de cambio, o peor, cuando los equipos
están separados por límites contractuales, como cuando el trabajo lo realiza un subcontratado
equipo.

Como vimos en el ejemplo de Etsy Sprouter al comienzo de este capítulo, la forma en que
Organizar equipos puede generar malos resultados, un efecto secundario de la Ley de Conway. Éstos incluyen
dividir equipos por función (por ejemplo, colocando desarrolladores y probadores en diferentes ubicaciones o
subcontratando probadores por completo) o por capa arquitectónica (por ejemplo, aplicación, base de datos).

Estas configuraciones requieren una comunicación y coordinación significativas entre los equipos,
pero todavía resulta en una gran cantidad de retrabajo, desacuerdos sobre las especificaciones, pobre
traspasos, y personas sentadas ociosas esperando a alguien más.

Idealmente, nuestra arquitectura de software debería permitir que los equipos pequeños sean independientes
productivo, suficientemente desacoplado entre sí para poder trabajar sin
Comunicación y coordinación excesiva o innecesaria.

CREAR ARQUITECTURAS SOLAMENTE ACOPLADAS PARA

HABILITAR LA PRODUCTIVIDAD Y LA SEGURIDAD DEL DESARROLLADOR

Cuando tenemos una arquitectura estrechamente acoplada, pequeños cambios pueden resultar en una gran escala
fallas Como resultado, cualquier persona que trabaje en una parte del sistema debe coordinar constantemente
con cualquier otra persona que trabaje en otra parte del sistema que puedan afectar, incluyendo
navegando por procesos complejos y burocráticos de gestión del cambio.

Además, para probar que todo el sistema funciona en conjunto, se requieren cambios integrales
con los cambios de cientos, o incluso miles, de otros desarrolladores, que pueden, en
a su vez, dependen de decenas, cientos o miles de sistemas interconectados.
Las pruebas se realizan en entornos de pruebas de integración escasos, que a menudo requieren semanas para
obtener y configurar El resultado no es solo largos plazos de entrega para los cambios (generalmente medidos
en semanas o meses), pero también baja productividad del desarrollador y malos resultados de implementación.

Por el contrario, cuando tenemos una arquitectura que permite a pequeños equipos de desarrolladores
Implementamos, probamos e implementamos código de forma independiente en la producción de forma segura y rápida, podemos
aumentar y mantener la productividad del desarrollador y mejorar los resultados de la implementación. Estas
las características se pueden encontrar en arquitecturas orientadas a servicios (SOA) descritas por primera vez en
Década de 1990, en la que los servicios se pueden probar y desplegar de forma independiente. Una característica clave de las SOA
es que están compuestos de servicios poco acoplados con contextos limitados .‡‡

Tener una arquitectura débilmente acoplada significa que los servicios pueden actualizarse en producción
independientemente, sin tener que actualizar otros servicios. Los servicios deben estar desconectados de

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 128 de 485
125

otros servicios y, igual de importante, de bases de datos compartidas (aunque pueden compartir un
servicio de base de datos , siempre que no tengan ningún esquema común).

Los contextos limitados se describen en el libro Domain Driven Design de Eric J. Evans. los
La idea es que los desarrolladores puedan entender y actualizar el código de un servicio
sin saber nada sobre los aspectos internos de sus servicios pares. Los servicios interactúan con
sus pares estrictamente a través de API y, por lo tanto, no comparten estructuras de datos, esquemas de bases de datos,
u otras representaciones internas de objetos. Los contextos limitados aseguran que los servicios sean
compartimentados y tienen interfaces bien definidas, lo que también permite pruebas más fáciles.

Randy Shoup, ex Director de Ingeniería de Google App Engine, observó que

"Organizaciones con este tipo de arquitecturas orientadas a servicios, como Google y
Amazon, tiene una increíble flexibilidad y escalabilidad. Estas organizaciones tienen decenas de
miles de desarrolladores donde los equipos pequeños aún pueden ser increíblemente productivos ".

MANTENGA LOS TAMAÑOS DE EQUIPO PEQUEÑOS (LA REGLA DEL “EQUIPO DE DOS PIZZAS”)
La Ley de Conway nos ayuda a diseñar los límites de nuestro equipo en el contexto deseado
patrones de comunicación, pero también nos alienta a mantener pequeños los tamaños de nuestro equipo, reduciendo
la cantidad de comunicación entre equipos y nos anima a mantener el alcance de cada
El dominio del equipo es pequeño y acotado.

Como parte de su iniciativa de transformación lejos de una base de código monolítico en 2002, Amazon
usó la regla de las dos pizzas para mantener pequeños los tamaños de los equipos: un equipo tan grande como se pueda alimentar con
dos pizzas, generalmente de cinco a diez personas.

Este límite de tamaño tiene cuatro efectos importantes:

1. Asegura que el equipo tenga una comprensión clara y compartida del sistema en el que están trabajando
en. A medida que los equipos crecen, la cantidad de comunicación requerida para que todos sepan
lo que sucede en escalas de forma combinatoria.

2. Limita la tasa de crecimiento del producto o servicio en el que se trabaja. Al limitar el tamaño
del equipo, limitamos la velocidad a la que su sistema puede evolucionar. Esto también ayuda a garantizar
El equipo mantiene una comprensión compartida del sistema.

3. Descentraliza el poder y permite la autonomía. Cada equipo de dos pizzas (2PT) es como
lo más autónomo posible El líder del equipo, trabajando con el equipo ejecutivo, decide sobre
la métrica comercial clave de la que es responsable el equipo, conocida como la función de acondicionamiento físico,
que se convierte en el criterio general de evaluación para los experimentos del equipo. El equipo es
entonces capaz de actuar de forma autónoma para maximizar esa métrica. §§

4. Liderar un 2PT es una forma para que los empleados obtengan cierta experiencia de liderazgo en un
entorno donde el fracaso no tiene consecuencias catastróficas. Un esencial
El elemento de la estrategia de Amazon fue el vínculo entre la estructura organizativa de un 2PT
y el enfoque arquitectónico de una arquitectura orientada a servicios.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 129 de 485
 El CTO de Amazon Werner Vogels explicó las ventajas de esta estructura a Larry Dignan de
Línea de base en 2005. Dignan escribe:

"Los equipos pequeños son rápidos ... y no se atascan en la llamada administración ... cada uno
grupo asignado a un negocio en particular es completamente responsable de ello ... El equipo

Page 126

mira el arreglo, lo diseña, lo construye, lo implementa y monitorea su uso continuo. Esta

De esta manera, los programadores y arquitectos de tecnología obtienen retroalimentación directa de la empresa
personas que usan su código o aplicaciones, en reuniones regulares e informales
conversaciones ".

Otro ejemplo de cómo la arquitectura puede mejorar profundamente la productividad es la API

Programa de habilitación en Target, Inc.

Caso de estudio
Habilitación de API en Target (2015)

Target es el sexto minorista más grande de los EE. UU. Y gasta más de $ 1 mil millones en tecnología
anualmente. Heather Mickman, directora de desarrollo de Target, describió el
principios de su viaje DevOps: "En los viejos tiempos, solía tomar diez diferentes
equipos para aprovisionar un servidor en Target, y cuando las cosas se rompieron, tendíamos a detenernos
haciendo cambios para evitar más problemas, lo que, por supuesto, empeora todo ".

Las dificultades asociadas con obtener entornos y realizar implementaciones

creó dificultades significativas para los equipos de desarrollo, al igual que obtener acceso a los datos
que necesitaban. Como describió Mickman:

El problema era que gran parte de nuestros datos principales, como la información sobre el inventario,
los precios y las tiendas estaban encerrados en sistemas heredados y mainframes. Nosotros a menudo
tenía múltiples fuentes de verdades de datos, especialmente entre el comercio electrónico y nuestro
tiendas físicas, que eran propiedad de diferentes equipos, con diferentes datos
estructuras y diferentes prioridades .... El resultado fue que si un nuevo desarrollo
equipo quería construir algo para nuestros invitados, tomaría de tres a seis
meses para construir las integraciones para obtener los datos que necesitaban. Peor aún, sería
tomar otros tres a seis meses para hacer la prueba manual para asegurarse de que
no rompió nada crítico, debido a la cantidad personalizada de punto a punto
integraciones que tuvimos en un sistema muy bien acoplado. Tener que gestionar el
interacciones con los veinte a treinta equipos diferentes, junto con todos sus
dependencias, se requieren muchos gerentes de proyecto, debido a todas las
coordinación y traspasos. Significaba que el desarrollo estaba gastando todo su
tiempo esperando en colas, en lugar de entregar resultados y hacer cosas.

Este largo tiempo de espera para recuperar y crear datos en sus sistemas de registro fue
poner en peligro objetivos comerciales importantes, como la integración de la cadena de suministro
operaciones de las tiendas físicas de Target y su sitio de comercio electrónico, que ahora requerían

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 130 de 485
 conseguir inventario para tiendas y hogares de clientes. Esto empujó la cadena de suministro de Target
mucho más allá de lo que fue diseñado, que era simplemente para facilitar el movimiento de
bienes de vendedores a centros de distribución y tiendas.

En un intento por resolver el problema de los datos, en 2012 Mickman lideró la habilitación de API
equipo para permitir que los equipos de desarrollo "entreguen nuevas capacidades en días en lugar de
meses." Querían que cualquier equipo de ingeniería dentro de Target pudiera obtener y
almacenar los datos que necesitaban, como información sobre sus productos o sus tiendas,
incluidas las horas de operación, la ubicación, si hubo Starbucks en el sitio, y así
adelante.

Las limitaciones de tiempo jugaron un papel importante en la selección del equipo. Mickman explicó que:

Page 127

Debido a que nuestro equipo también necesitaba entregar capacidades en días, no meses, yo
necesitábamos un equipo que pudiera hacer el trabajo, no dárselo a los contratistas; queríamos
personas con habilidades ingeniosas de ingeniería, no personas que supieran manejar
contratos Y para asegurarnos de que nuestro trabajo no estaba en la cola, necesitábamos
poseer toda la pila, lo que significa que asumimos los requisitos de Ops como
bueno ... Trajimos muchas herramientas nuevas para apoyar la integración continua y
entrega continua Y porque sabíamos que si teníamos éxito, lo haríamos
tenemos que escalar con un crecimiento extremadamente alto, trajimos nuevas herramientas como el
Base de datos Cassandra y agente de mensajes Kafka. Cuando pedimos
permiso, nos dijeron que no, pero lo hicimos de todos modos, porque sabíamos que
lo necesitaba.

En los siguientes dos años, el equipo de API Enablement permitió cincuenta y tres nuevos
capacidades comerciales, incluido el envío a la tienda y el registro de regalos, así como su
integraciones con Instacart y Pinterest. Como describió Mickman, "Trabajar con
Pinterest de repente se volvió muy fácil, porque les proporcionamos nuestras API ".

En 2014, el equipo de API Enablement atendió más de 1.500 millones de llamadas API por mes. Por
2015, esto había crecido a diecisiete mil millones de llamadas por mes que abarca noventa diferentes
APIs. Para soportar esta capacidad, rutinariamente realizaron ochenta implementaciones por
semana.

Estos cambios han creado importantes beneficios comerciales para Target: ventas digitales
aumentó 42% durante la temporada de vacaciones de 2014 y aumentó otro 32% en el segundo trimestre.
Durante el fin de semana del Black Friday de 2015, se registraron más de 280 mil pedidos de recogida en la tienda
creado. Para 2015, su objetivo es permitir que 450 de sus 1,800 tiendas puedan cumplir
pedidos de comercio electrónico, por encima de cien.

"El equipo de API Enablement muestra lo que puede hacer un equipo de agentes de cambio apasionados
hacer ", dice Mickman. "Y nos ayuda a prepararnos para la siguiente etapa, que es expandir
DevOps en toda la organización tecnológica ".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 131 de 485
 CONCLUSIÓN

A través de los estudios de caso de Etsy y Target, podemos ver cómo la arquitectura y la organización
El diseño puede mejorar drásticamente nuestros resultados. Hecho incorrectamente, la Ley de Conway
Asegurar que la organización cree malos resultados, previniendo la seguridad y la agilidad. Hecho
bueno, la organización permite a los desarrolladores desarrollar, probar y
desplegar valor para el cliente.

† Entre muchas cosas, un ORM abstrae una base de datos, lo que permite a los desarrolladores hacer consultas y manipulación de datos como si fueran simplemente otro objeto en el
lenguaje de programación. Los ORM populares incluyen Hibernate para Java, SQLAlchemy para Python y ActiveRecord para Ruby on Rails.

‡ Sprouter fue una de las muchas tecnologías utilizadas en el desarrollo y la producción que Etsy eliminó como parte de su transformación.

§ Sin embargo, como se explicará más adelante, organizaciones igualmente importantes como Etsy y GitHub tienen orientación funcional.

¶ Adrian Cockcroft comentó: “Para las compañías que ahora están saliendo de contratos de outsourcing de TI de cinco años, es como si se hubieran congelado a tiempo, durante un
de los tiempos más disruptivos en tecnología ". En otras palabras, la externalización de TI es una táctica utilizada para controlar los costos a través de la estasis ejecutada contractualmente, con
precios fijos firmes que programan reducciones anuales de costos. Sin embargo, a menudo resulta en que las organizaciones no pueden responder a los cambios de negocios y
Necesidades tecnológicas.

** Para el resto de estos libros, utilizaremos equipos de servicio de manera intercambiable con equipos de características , equipos de productos , equipos de desarrollo y equipos de entrega .
La intención es especificar el equipo principalmente desarrollando, probando y asegurando el código para que el valor se entregue al cliente.

†† Como John Lauderbach, actualmente vicepresidente de tecnología de la información en los supermercados Roche Bros., bromeó: “Cada nueva aplicación es como un cachorro gratis. No es
el costo de capital inicial que lo mata ... Es el mantenimiento y soporte continuos ".

‡‡ Estas propiedades también se encuentran en los "microservicios", que se basan en los principios de SOA. Un conjunto popular de patrones para la arquitectura web moderna
basado en estos principios es la "aplicación de 12 factores".

§§ En la cultura de Netflix, uno de los siete valores clave es "altamente alineado, vagamente acoplado".

Page 129
128

8 Resultados por
Integrando
Cómo ser genial
Operaciones en el
Trabajo diario de
Desarrollo

Nuestro objetivo es permitir resultados orientados al mercado donde muchos equipos pequeños puedan
entregar valor de forma rápida e independiente al cliente. Esto puede ser un
desafío a alcanzar cuando las operaciones están centralizadas y funcionalmente
orientado, teniendo que atender las necesidades de muchos equipos de desarrollo diferentes
con necesidades potencialmente muy diferentes. El resultado a menudo puede ser largo plomo
tiempos para el trabajo necesario de Ops, repriorización y escalado constante, y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 132 de 485
 pobres resultados de despliegue.
Podemos crear resultados más orientados al mercado integrando mejor Ops
capacidades en equipos de desarrollo, lo que hace que sean más eficientes y productivos. En
En este capítulo, exploraremos muchas formas de lograr esto, tanto en el
nivel organizacional y a través de rituales diarios. Al hacer esto, Ops puede
Mejorar significativamente la productividad de los equipos de desarrollo en todo
organización, así como permitir una mejor colaboración y organización
resultados.

En Big Fish Games, que desarrolla y admite cientos de dispositivos móviles y

miles de juegos de PC y obtuvieron más de $ 266 millones en ingresos en 2013,
El vicepresidente de operaciones de TI, Paul Farrall, estaba a cargo de las operaciones centralizadas.
organización. Fue responsable de apoyar muchos negocios diferentes
unidades que tenían mucha autonomía.

Cada una de estas unidades de negocios tenía equipos de desarrollo dedicados que a menudo
eligió tecnologías muy diferentes. Cuando estos grupos querían desplegarse
nueva funcionalidad, tendrían que competir por un grupo común de escasos
Recursos de operaciones. Además, todos estaban luchando con una prueba poco confiable
y entornos de integración, así como una versión extremadamente engorrosa
procesos.

130

Farrall pensó que la mejor manera de resolver este problema era incrustando Ops
experiencia en equipos de desarrollo. Él observó: "Cuando los equipos de desarrollo tenían
problemas con las pruebas o la implementación, necesitaban más que solo tecnología
o ambientes. Lo que también necesitaban era ayuda y entrenamiento. Al principio, nosotros
ingenieros y arquitectos de Ops integrados en cada uno de los equipos de desarrollo, pero hay
simplemente no había suficientes ingenieros de operaciones para cubrir tantos equipos. Éramos
capaz de ayudar a más equipos con lo que llamamos un modelo de enlace de Ops y con
menos gente."

Farrall definió dos tipos de enlaces de operaciones: el gerente de relaciones comerciales

y el ingeniero de lanzamiento dedicado. Los gerentes de relaciones comerciales
trabajó con gestión de productos, propietarios de línea de negocio, proyecto
gestión, gestión de desarrollo y desarrolladores. Se volvieron íntimamente
familiarizado con los conductores de negocios del grupo de productos y las hojas de ruta de productos, actuó

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 133 de 485
 como defensores de los propietarios de productos dentro de Operaciones, y ayudaron a sus
los equipos de productos navegan por el panorama de Operaciones para priorizar y
agilizar las solicitudes de trabajo.

Del mismo modo, el ingeniero de lanzamiento dedicado se familiarizó íntimamente con el

Desarrollo de productos y problemas de control de calidad, y les ayudó a obtener lo que
necesario de la organización Ops para lograr sus objetivos. Estaban familiarizados
con las típicas solicitudes de Dev y QA para Ops, y a menudo ejecutaba el
Necesitaban trabajar ellos mismos. Según sea necesario, también atraerían a personas dedicadas
ingenieros técnicos de operaciones (p. ej., DBA, Infosec, ingenieros de almacenamiento, redes
ingenieros), y ayudan a determinar qué herramientas de autoservicio funcionan todas las operaciones
El grupo debe priorizar la construcción.

Al hacer esto, Farrall pudo ayudar a los equipos de desarrollo en toda la organización
ser más productivo y lograr sus objetivos de equipo. Además, él
ayudó a los equipos a priorizar alrededor de sus restricciones globales de operaciones, reduciendo el
Número de sorpresas descubiertas a mitad del proyecto y, en última instancia, aumentando el
rendimiento general del proyecto.

Farrall señala que ambas relaciones de trabajo con Operaciones y código

la velocidad de liberación mejoró notablemente como resultado de los cambios. Él
concluye: “El modelo de enlace de Ops nos permitió integrar las operaciones de TI
experiencia en los equipos de desarrollo y producto sin agregar nuevos empleados ".

La transformación DevOps en Big Fish Games muestra cómo un sistema centralizado

El equipo de operaciones pudo lograr los resultados típicamente asociados con
equipos orientados al mercado. Podemos emplear las tres estrategias generales siguientes:

131

Cree capacidades de autoservicio para permitir a los desarrolladores en los equipos de servicio
ser productivo

Incruste a los ingenieros de Ops en los equipos de servicio.

Asigne enlaces de Ops a los equipos de servicio cuando incrustar Ops no sea
posible.

Por último, describimos cómo los ingenieros de Ops pueden integrarse en el equipo de desarrollo

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 134 de 485
 rituales utilizados en su trabajo diario, incluidas las paradas diarias, la planificación y
retrospectivas

CREA SERVICIOS COMPARTIDOS PARA AUMENTAR

DESARROLLADOR PRODUCTIVIDAD

Una forma de permitir resultados orientados al mercado es que las Operaciones creen un conjunto
de plataformas centralizadas y servicios de herramientas que cualquier equipo de desarrollo puede usar para
ser más productivo, como obtener entornos de producción,
tuberías de implementación, herramientas de prueba automatizadas, telemetría de producción
paneles de instrumentos, y así sucesivamente.† Al hacer esto, permitimos que los equipos de desarrollo gasten más
funcionalidad de creación de tiempo para su cliente, en lugar de obtener todos los
infraestructura requerida para entregar y soportar esa característica en la producción.

Todas las plataformas y servicios que brindamos deberían (idealmente) ser automatizados y
disponible bajo demanda, sin requerir que un desarrollador abra un ticket y
esperar a que alguien realice el trabajo manualmente. Esto asegura que las operaciones
no se convierte en un cuello de botella para sus clientes (por ejemplo, "Recibimos su
solicitud de trabajo, y tomará seis semanas configurar manualmente esas pruebas
ambientes "). ‡

Al hacer esto, permitimos que los equipos de productos obtengan lo que necesitan, cuando
lo necesita, así como también reduce la necesidad de comunicaciones y coordinación. Como
Damon Edwards observó: "Sin estas plataformas de operaciones de autoservicio,
la nube es simplemente Hosting 2.0 caro ”.

En casi todos los casos, no exigiremos que los equipos internos usen estos
plataformas y servicios: estos equipos de plataforma tendrán que ganarse y
satisfacer a sus clientes internos, a veces incluso compitiendo con externos
vendedores. Al crear este mercado interno efectivo de capacidades, nosotros
ayudar a garantizar que las plataformas y servicios que creamos sean los más fáciles y
La opción más atractiva disponible (el camino de menor resistencia).

Page 132

Por ejemplo, podemos crear una plataforma que proporcione una versión compartida
repositorio de control con bibliotecas de seguridad previamente bendecidas, una tubería de implementación

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 135 de 485
 que ejecuta automáticamente la calidad del código y las herramientas de escaneo de seguridad, que
implementa nuestras aplicaciones en entornos conocidos y buenos que ya tienen
herramientas de monitoreo de producción instaladas en ellos. Idealmente, hacemos mucho la vida
más fácil para los equipos de desarrollo que decidirán abrumadoramente que usar nuestro
la plataforma es el medio más fácil, seguro y seguro para obtener su
aplicaciones en producción.

Construimos en estas plataformas la experiencia acumulativa y colectiva de

todos en la organización, incluidos QA, Operaciones e Infosec, que
Ayuda a crear un sistema de trabajo cada vez más seguro. Esto aumenta el desarrollador
productividad y facilita que los equipos de productos aprovechen lo común
procesos, como realizar pruebas automatizadas y satisfacer la seguridad y
requisitos de conformidad.

Crear y mantener estas plataformas y herramientas es un producto real

desarrollo: los clientes de nuestra plataforma no son nuestros clientes externos
pero nuestros equipos internos de desarrollo. Como crear un gran producto, crear un gran
Las plataformas que todos aman no suceden por accidente. Un interno
El equipo de plataforma con poca atención al cliente probablemente creará herramientas que todos
odiará y abandonará rápidamente por otras alternativas, ya sea por otra
equipo de plataforma interna o un proveedor externo.

Dianne Marsh, directora de herramientas de ingeniería en Netflix, afirma que ella

El estatuto del equipo es "apoyar la innovación y la velocidad de nuestros equipos de ingeniería.
No construimos, horneamos ni implementamos nada para estos equipos, ni gestionamos
sus configuraciones En cambio, creamos herramientas para permitir el autoservicio. Está bien
para que las personas dependan de nuestras herramientas, pero es importante que no
volverse dependiente de nosotros ".

A menudo, estos equipos de plataforma proporcionan otros servicios para ayudar a sus clientes.
aprender su tecnología, migrar de otras tecnologías e incluso proporcionar
Coaching y consultoría para ayudar a elevar el estado de la práctica dentro del
organización. Estos servicios compartidos también facilitan la estandarización, que
permitir a los ingenieros ser productivos rápidamente, incluso si cambian entre
equipos Por ejemplo, si cada equipo de producto elige una cadena de herramientas diferente,
los ingenieros pueden tener que aprender un conjunto completamente nuevo de tecnologías para hacer su
trabajo, colocando los objetivos del equipo por delante de los objetivos globales.

En organizaciones donde los equipos solo pueden usar herramientas aprobadas, podemos comenzar por
eliminar este requisito para algunos equipos, como el equipo de transformación,

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 136 de 485
Page 133

para que podamos experimentar y descubrir qué capacidades hacen esos equipos
más productivo.

Los equipos internos de servicios compartidos deben buscar continuamente

cadenas de herramientas que se están adoptando ampliamente en la organización, decidiendo qué
los que tienen sentido son apoyados centralmente y disponibles para todos.
En general, tomar algo que ya está funcionando en alguna parte y
expandir su uso es mucho más probable que tenga éxito que construir estos
capacidades desde cero.§

INGENIEROS DE OPS EMPOTRADOS EN NUESTRO SERVICIO

EQUIPOS

Otra forma en que podemos permitir resultados más orientados al mercado es habilitar
los equipos de productos se volverán más autosuficientes incorporando Operaciones
ingenieros dentro de ellos, reduciendo así su dependencia de centralizado
Operaciones Estos equipos de productos también pueden ser completamente responsables de
prestación de servicios y soporte de servicios.

Al incorporar ingenieros de operaciones en los equipos de desarrollo, sus prioridades son

impulsado casi por completo por los objetivos de los equipos de productos en los que están integrados
en - en lugar de que Ops se centre internamente en resolver sus propios problemas. Como un
Como resultado, los ingenieros de Ops se conectan más estrechamente con sus
Clientes externos. Además, los equipos de productos a menudo tienen el presupuesto.
para financiar la contratación de estos ingenieros de Ops, aunque entrevistando y contratando
las decisiones probablemente se tomarán del grupo de Operaciones centralizado, para
Garantizar la coherencia y la calidad del personal.

Jason Cox dijo: "En muchas partes de Disney hemos incorporado Ops (sistema
ingenieros) dentro de los equipos de productos en nuestras unidades de negocio, junto con
Desarrollo, prueba e incluso seguridad de la información. Ha cambiado totalmente el
dinámica de cómo trabajamos. Como ingenieros de operaciones, creamos las herramientas y
capacidades que transforman la forma en que trabajan las personas, e incluso la forma en que
pensar. En las operaciones tradicionales, simplemente conducíamos el tren que alguien más construyó.
Pero en la Ingeniería de Operaciones moderna, no solo ayudamos a construir el tren, sino que también
también los puentes sobre los que ruedan los trenes ".

Para nuevos proyectos de desarrollo grandes, inicialmente podemos incorporar ingenieros de Ops
en esos equipos. Su trabajo puede incluir ayudar a decidir qué construir y
cómo construirlo, influyendo en la arquitectura del producto, ayudando a influir
opciones tecnológicas internas y externas, que ayudan a crear nuevas capacidades en

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 137 de 485
 nuestras plataformas internas, y tal vez incluso generando nuevas operaciones

Page 134

capacidades. Después de que el producto se lanza a producción, Ops incrustado

Los ingenieros pueden ayudar con las responsabilidades de producción del equipo de desarrollo.

Participarán en todos los rituales del equipo de desarrollo, como la planificación de reuniones,
Standups diarios y demostraciones donde el equipo muestra nuevas características
y decide cuáles enviar. Como la necesidad de conocimiento de Ops y
las capacidades disminuyen, los ingenieros de Ops pueden hacer la transición a diferentes proyectos o
compromisos, siguiendo el patrón general que la composición dentro de
los equipos de productos cambian a lo largo de su ciclo de vida.

Este paradigma tiene otra ventaja importante: emparejar Dev y Ops

ingenieros juntos es una forma extremadamente eficiente de realizar operaciones de entrenamiento cruzado
conocimiento y experiencia en un equipo de servicio. También puede tener el poderoso
beneficio de transformar el conocimiento de operaciones en código automatizado que puede
Ser mucho más confiable y ampliamente reutilizado.

ASIGNAR UN ENLACE OPS A CADA SERVICIO

EQUIPO

Por una variedad de razones, como el costo y la escasez, es posible que no podamos
incrustar a los ingenieros de Ops en cada equipo de producto. Sin embargo, podemos obtener muchos de
los mismos beneficios al asignar un enlace designado para cada equipo de producto.

En Etsy, este modelo se llama "operaciones designadas". Sus operaciones centralizadas

group continúa administrando todos los entornos, no solo la producción
entornos, pero también entornos de preproducción, para ayudar a garantizar que
permanece consistente El ingeniero designado de Ops es responsable de
comprensión:

Cuál es la funcionalidad del nuevo producto y por qué lo estamos construyendo

Cómo funciona en lo que respecta a la operabilidad, escalabilidad y observabilidad

(se recomienda encarecidamente la diagramación)

Cómo monitorear y recopilar métricas para garantizar el progreso, el éxito o

falla de la funcionalidad

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 138 de 485
 Cualquier desviación de arquitecturas y patrones anteriores, y el
justificaciones para ellos

Cualquier necesidad adicional de infraestructura y cómo afectará el uso

capacidad de infraestructura

Page 135

Planes de lanzamiento de funciones

Además, al igual que en el modelo Ops incorporado, este enlace asiste a la

standups de equipo, integrando sus necesidades en la hoja de ruta de Operaciones y
realizar cualquier tarea necesaria. Confiamos en estos enlaces para escalar cualquier
problema de contención de recursos o priorización. Al hacer esto, identificamos cualquier
conflictos de recursos o tiempo que deben evaluarse y priorizarse en el
contexto de objetivos organizacionales más amplios.

Asignar enlaces Ops nos permite apoyar más equipos de productos que el
modelo Ops integrado. Nuestro objetivo es garantizar que Ops no sea una restricción para
Los equipos de producto. Si descubrimos que los enlaces Ops se estiran demasiado,
evitando que los equipos de producto logren sus objetivos, entonces probablemente
necesita reducir la cantidad de equipos que cada enlace admite o
incrustar temporalmente un ingeniero de operaciones en equipos específicos.

INTEGRAR OPS EN RITUALES DE DEV

Cuando los ingenieros de Ops están integrados o asignados como enlaces en nuestro producto
equipos, podemos integrarlos en los rituales de nuestro equipo de desarrollo. En esta sección, nuestro
El objetivo es ayudar a los ingenieros de Ops y otros no desarrolladores a comprender mejor
la cultura de desarrollo existente e integrarlos de manera proactiva en todos
aspectos de planificación y trabajo diario. Como resultado, Operaciones está mejor capacitada para
planificar e irradiar cualquier conocimiento necesario a los equipos de productos, influyendo
trabajar mucho antes de que entre en producción. Las siguientes secciones describen
Algunos de los rituales estándar utilizados por los equipos de desarrollo que utilizan ágil
métodos y cómo integraríamos a los ingenieros de Ops en ellos. De ninguna manera
Las prácticas ágiles son un requisito previo para este paso: como ingenieros de Ops, nuestro objetivo es

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 139 de 485
 para descubrir qué rituales siguen los equipos de productos, integrarlos y
agregar valor a ellos.¶

Como observó Ernest Mueller: "Creo que DevOps funciona mucho mejor si
Los equipos de operaciones adoptan los mismos rituales ágiles que los equipos de desarrollo han utilizado:
hemos tenido éxitos fantásticos resolviendo muchos problemas asociados con Ops
puntos débiles, además de integrarse mejor con los equipos de desarrollo ".

INVITE A OPS A NUESTROS STANDUPS DE DEV

Uno de los rituales de desarrollo popularizados por Scrum es el standup diario, un rápido
reunión donde todos en el equipo se reúnen y presentan a cada uno
otras tres cosas: lo que se hizo ayer, lo que se hará hoy,
y lo que te impide hacer tu trabajo. ** **

Page 136

El propósito de esta ceremonia es irradiar información a todo el equipo.

y entender el trabajo que se está haciendo y se va a hacer. Por
haciendo que los miembros del equipo se presenten esta información, aprendemos sobre
cualquier tarea que esté experimentando obstáculos y descubra formas de ayudar a cada uno
otros mueven nuestro trabajo hacia la finalización. Además, al tener gerentes
En la actualidad, podemos resolver rápidamente la priorización y los conflictos de recursos.

Un problema común es que esta información está compartimentada dentro de

Equipo de desarrollo. Al hacer que asistan los ingenieros de Ops, las operaciones pueden ganar un
conocimiento de las actividades del equipo de desarrollo, lo que permite una mejor planificación
y preparación, por ejemplo, si descubrimos que el equipo del producto es
planeando un gran despliegue de funciones en dos semanas, podemos asegurarnos de que
personas y recursos están disponibles para apoyar el lanzamiento. Alternativamente, nosotros
puede resaltar áreas donde se necesita una interacción más cercana o más preparación
(por ejemplo, crear más comprobaciones de supervisión o scripts de automatización). Al hacer esto,
Creamos las condiciones donde las operaciones pueden ayudar a resolver nuestro equipo actual
problemas (por ejemplo, mejorar el rendimiento ajustando la base de datos, en lugar de
código de optimización) o problemas futuros antes de que se conviertan en una crisis (por ejemplo,
creando más entornos de prueba de integración para permitir las pruebas de rendimiento).

INVITE A OPS A NUESTRAS RETROSPECTIVAS DE DEV

Otro ritual ágil generalizado es la retrospectiva. Al final de cada
intervalo de desarrollo, el equipo discute qué fue exitoso, qué podría ser

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 140 de 485
 mejorado, y cómo incorporar los éxitos y mejoras en el futuro
iteraciones o proyectos. El equipo tiene ideas para mejorar las cosas.
y revisa los experimentos de la iteración anterior. éste es uno de
mecanismos primarios donde el aprendizaje organizacional y el desarrollo de
ocurren contramedidas, con el trabajo resultante implementado inmediatamente o
agregado a la cartera de pedidos del equipo.

Tener ingenieros de Ops que asistan a las retrospectivas de nuestro equipo de proyecto significa que pueden
También se benefician de cualquier nuevo aprendizaje. Además, cuando hay un
despliegue o lanzamiento en ese intervalo, las operaciones deben presentar el
resultados y cualquier aprendizaje resultante, creando retroalimentación en el producto
equipo. Al hacer esto, podemos mejorar cómo se planifica el trabajo futuro y
realizado, mejorando nuestros resultados. Ejemplos de retroalimentación que Operaciones
puede traer a una retrospectiva incluyen:

"Hace dos semanas, encontramos un punto ciego de monitoreo y acordamos cómo

arreglalo. Funcionó. Tuvimos un incidente el martes pasado y pudimos
detectarlo y corregirlo rápidamente antes de que los clientes se vean afectados ".

137

"El despliegue de la semana pasada fue uno de los más difíciles y largos que hemos tenido
tenido en más de un año. Aquí hay algunas ideas sobre cómo se puede mejorar ".

"La campaña de promoción que hicimos la semana pasada fue mucho más difícil que nosotros
pensé que sería, y probablemente no deberíamos hacer una oferta como esa
de nuevo. Aquí hay algunas ideas sobre otras ofertas que podemos hacer para lograr nuestro
metas."

"Durante la última implementación, el mayor problema que tuvimos fue nuestro firewall
las reglas ahora tienen miles de líneas, lo que lo hace extremadamente difícil y
arriesgado de cambiar. Necesitamos rediseñar cómo evitamos las personas no autorizadas.
tráfico de red."

Los comentarios de Operaciones ayudan a nuestros equipos de productos a ver y mejorar

Comprender el impacto aguas abajo de las decisiones que toman. Cuando hay
resultados negativos, podemos hacer los cambios necesarios para prevenirlos en
el futuro. La retroalimentación de operaciones también probablemente identificará más problemas y
defectos que deben repararse, incluso puede descubrir problemas arquitectónicos más grandes

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 141 de 485
 eso debe ser abordado.

El trabajo adicional identificado durante las retrospectivas del equipo del proyecto cae en
la amplia categoría de trabajo de mejora, como la reparación de defectos, refactorización,
y automatizar el trabajo manual. Los gerentes de producto y gerentes de proyecto pueden
querer diferir o priorizar el trabajo de mejora a favor del cliente
caracteristicas.

Sin embargo, debemos recordar a todos que la mejora del trabajo diario es más
importante que el trabajo diario en sí, y que todos los equipos deben haber dedicado
capacidad para esto (por ejemplo, reservar el 20% de todos los ciclos para el trabajo de mejora,
programación de un día por semana o una semana por mes, etc.). Sin hacer
esto, la productividad del equipo seguramente se detendrá bajo
El peso de su propia deuda técnica y de proceso.

HAGA VISIBLE EL TRABAJO OPS RELEVANTE EN EL KANBAN COMPARTIDO

JUNTAS
A menudo, los equipos de desarrollo harán visible su trabajo en un tablero de proyecto o
tablero kanban Sin embargo, es mucho menos común que los tableros de trabajo muestren
Trabajo de operaciones relevante que debe realizarse para que el
aplicación para ejecutarse con éxito en producción, donde el valor para el cliente es
En realidad creado. Como resultado, no tenemos conocimiento del trabajo necesario de Operaciones
hasta que se convierta en una crisis urgente, poniendo en peligro los plazos o creando un
corte de producción.

Page 138

Debido a que las operaciones son parte del flujo de valor del producto, debemos poner el
Trabajo de operaciones que es relevante para la entrega del producto en el kanban compartido
tablero. Esto nos permite ver más claramente todo el trabajo requerido para mover nuestro
codificar en producción, así como realizar un seguimiento de todo el trabajo de Operaciones requerido para
Apoyar el producto. Además, nos permite ver dónde está el trabajo de Ops
bloqueado y donde el trabajo necesita escalar, destacando las áreas donde podemos
necesita mejorar.

Los tableros Kanban son una herramienta ideal para crear visibilidad, y la visibilidad es la clave.
componente para reconocer e integrar adecuadamente el trabajo de Ops en todos los
flujos de valor relevantes. Cuando lo hacemos bien, logramos orientarnos al mercado
resultados, independientemente de cómo hayamos dibujado nuestros organigramas.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 142 de 485
 CONCLUSIÓN

A lo largo de este capítulo, exploramos formas de integrar Operaciones en el

trabajo diario de desarrollo, y vimos cómo hacer que nuestro trabajo sea más
visible para las operaciones. Para lograr esto, exploramos tres estrategias generales,
incluida la creación de capacidades de autoservicio para permitir a los desarrolladores en servicio
equipos para ser productivos, integrando ingenieros de Ops en los equipos de servicio,
y asignando enlaces de Ops a los equipos de servicio al incorporar Ops
Los ingenieros no fueron posibles. Por último, describimos cómo los ingenieros de Ops pueden
integrarse con el equipo de desarrollo a través de la inclusión en su trabajo diario, incluyendo
Standups diarios, planificación y retrospectivas.

Page 139

PARTE II CONCLUSIÓN

En la Parte II: Dónde comenzar , exploramos una variedad de formas de pensar

Transformaciones de DevOps, incluido cómo elegir dónde comenzar, relevantes

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 143 de 485
 aspectos de arquitectura y diseño organizacional, y cómo organizar nuestro
equipos También exploramos cómo integrar Ops en todos los aspectos de Dev
planificación y trabajo diario.

En la Parte III: La primera forma, las prácticas técnicas de flujo , ahora comenzaremos
para explorar cómo implementar las prácticas técnicas específicas para realizar
principios de flujo, que permiten el flujo rápido de trabajo desde el desarrollo hasta
Operaciones sin causar caos e interrupción aguas abajo.

† Los términos plataforma , servicio compartido y cadena de herramientas se utilizarán indistintamente en este libro.

‡ Ernest Mueller observó: “En Bazaarvoice, el acuerdo fue que estos equipos de plataforma que fabrican herramientas aceptan requisitos, pero
no trabajo de otros equipos ".

§ Después de todo, diseñar un sistema por adelantado para su reutilización es un modo de falla común y costoso de muchas arquitecturas empresariales.

¶ Sin embargo, si descubrimos que toda la organización de Desarrollo simplemente se sienta en sus escritorios todo el día sin hablar con cada uno
otro, puede que tengamos que encontrar una forma diferente de involucrarlos, como comprarles el almuerzo, comenzar un club de lectura, turnarse para hacer
Presentaciones de "almuerzo y aprendizaje", o conversaciones para descubrir cuáles son los mayores problemas de todos, para que podamos entender
descubrimos cómo podemos mejorar sus vidas.

** Scrum es una metodología de desarrollo ágil, descrita como "una estrategia de desarrollo de producto flexible y holística donde un desarrollo
el equipo trabaja como una unidad para alcanzar un objetivo común ". Fue descrito por primera vez por completo por Ken Schwaber y Mike Beedle en el libro Agile
Desarrollo de software con Scrum . En este libro, utilizamos el término "desarrollo ágil" o "desarrollo iterativo" para abarcar
Las diversas técnicas utilizadas por metodologías especiales como Agile y Scrum.

141
140

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 144 de 485
 Parte
Introducción

En la Parte III, nuestro objetivo es crear las prácticas técnicas.

y arquitectura requerida para habilitar y sostener lo rápido
flujo de trabajo del desarrollo a las operaciones sin
causando caos e interrupción a la producción
Medio ambiente o nuestros clientes. Esto significa que necesitamos
reducir el riesgo asociado con el despliegue y la liberación
cambios en producción. Haremos esto por
implementar un conjunto de prácticas técnicas conocidas como
entrega continua .

La entrega continua incluye la creación de las bases de

nuestra línea de implementación automatizada, asegurando que
tenemos pruebas automatizadas que validan constantemente que somos
en un estado desplegable, haciendo que los desarrolladores integren sus
codificar en el tronco diariamente y diseñar nuestros entornos
y código para habilitar versiones de bajo riesgo. Enfoques primarios
dentro de estos capítulos incluyen:

Creando la base de nuestra tubería de implementación

Permitir pruebas automatizadas rápidas y confiables

Permitir y practicar la integración continua y

pruebas

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 145 de 485
Página 142

Automatización, habilitación y arquitectura para bajo riesgo

lanzamientos

La implementación de estas prácticas reduce el tiempo de espera para

obtener entornos de producción, permite continuo
pruebas que brindan a todos comentarios rápidos sobre su trabajo,
permite a pequeños equipos desarrollar de forma segura e independiente,
probar e implementar su código en producción, y hace
implementaciones de producción y libera una parte rutinaria de
trabajo diario.

Además, integrando los objetivos de QA y

Las operaciones en el trabajo diario de todos se reducen
lucha contra incendios, dificultades y trabajo duro, al tiempo que hace que las personas
Más alegría productiva y creciente en el trabajo que hacemos.
No solo mejoramos los resultados, sino que nuestra organización es
mejor capaz de ganar en el mercado.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 146 de 485
Page 143

9 Fundamentos de nuestro
Despliegue
Crea el
Tubería

Para crear un flujo rápido y confiable de Dev a Ops, debemos asegurarnos de que
siempre utilizamos entornos de producción en cada etapa del valor
corriente. Además, estos entornos deben crearse de forma automatizada.
de manera ideal, a pedido de scripts e información de configuración almacenada
en control de versiones, y totalmente autoservicio, sin ningún trabajo manual
requerido de Operaciones. Nuestro objetivo es asegurarnos de que podamos recrear el
entorno de producción completo basado en lo que hay en el control de versiones.

Con demasiada frecuencia, la única vez que descubrimos cómo funcionan nuestras aplicaciones en
cualquier cosa que se parezca a un entorno de producción es durante la producción
implementación: demasiado tarde para corregir problemas sin que el cliente sea
impactado negativamente. Un ejemplo ilustrativo del espectro de problemas que
puede ser causado por aplicaciones y entornos construidos inconsistentemente
Programa Enterprise Data Warehouse dirigido por Em Campbell-Pretty en general
Empresa australiana de telecomunicaciones en 2009. Campbell-Pretty se convirtió en
el gerente general y patrocinador comercial de este programa de $ 200 millones,
heredar la responsabilidad de todos los objetivos estratégicos que se basaron en esto
plataforma.

En su presentación en la Cumbre Empresarial DevOps 2014, Campbell-Pretty

explicó: “En ese momento, había diez flujos de trabajo en progreso, todos utilizando
procesos en cascada, y las diez corrientes estaban significativamente atrasadas.
Solo una de las diez transmisiones había alcanzado con éxito la Prueba de aceptación del usuario

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 147 de 485
 [UAT] según lo programado, y tardó otros seis meses para que esa transmisión
UAT completa, con la capacidad resultante que está muy por debajo de los negocios
Expectativas. Este bajo rendimiento fue el principal catalizador para el
transformación ágil del departamento ".

Sin embargo, después de usar Agile durante casi un año, experimentaron solo pequeñas
mejoras, aún por debajo de sus resultados comerciales necesarios.
Campbell-Pretty realizó una retrospectiva de todo el programa y preguntó: "Después

Page 144

Reflexionando sobre todas nuestras experiencias durante el último lanzamiento, ¿cuáles son las cosas que podríamos
¿eso duplicaría nuestra productividad?

A lo largo del proyecto, hubo quejas sobre la "falta de negocios

compromiso." Sin embargo, durante la retrospectiva, "mejorar la disponibilidad de
entornos "estaba en la parte superior de la lista. En retrospectiva, era obvio:
Los equipos de desarrollo necesitaban entornos aprovisionados para comenzar a trabajar,
y a menudo esperaban hasta ocho semanas.

Crearon una nueva integración y crearon un equipo responsable de

"Incorporando calidad en nuestros procesos, en lugar de tratar de inspeccionar la calidad después de
el hecho." Inicialmente estaba compuesto por administradores de bases de datos (DBA) y
especialistas en automatización encargados de automatizar la creación de su entorno
proceso. El equipo rápidamente hizo un descubrimiento sorprendente: solo el 50% de los
el código fuente en sus entornos de desarrollo y prueba coincidía con lo que era
corriendo en producción.

Campbell-Pretty observó: "De repente, entendimos por qué nos encontramos

muchos defectos cada vez que implementamos nuestro código en nuevos entornos. En cada
ambiente, seguimos avanzando, pero los cambios que hicimos no estaban siendo
volver a poner en control de versiones ".

El equipo realizó una ingeniería inversa de todos los cambios que se habían realizado para
los diferentes entornos y ponerlos a todos en control de versiones. Ellos también
automatizó su proceso de creación de entorno para que pudieran repetidamente y
girar correctamente los ambientes.

Campbell-Pretty describió los resultados y señaló que "el tiempo que tomó obtener un
El entorno correcto pasó de ocho semanas a un día. Este fue uno de los

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 148 de 485
 ajustes clave que nos permitieron alcanzar nuestros objetivos con respecto a nuestro liderazgo
tiempo, el costo de entrega y la cantidad de defectos escapados que lo convirtieron en
producción."

La historia de Campbell-Pretty muestra la variedad de problemas que se pueden rastrear

a ambientes construidos inconsistentemente y los cambios no son
volver a poner sistemáticamente en el control de versiones.

Durante el resto de este capítulo, discutiremos cómo construir el

mecanismos que nos permitirán crear entornos bajo demanda, expandir
el uso del control de versiones para todos en el flujo de valor, hacer infraestructura
más fácil de reconstruir que reparar, y garantizar que los desarrolladores ejecuten su código en
entornos de producción a lo largo de cada etapa del desarrollo de software
ciclo vital.

Page 145

HABILITAR A LA DEMANDA CREACIÓN DE DISPOSITIVO, PRUEBA,

Y ENTORNOS DE PRODUCCIÓN

Como se ve en el ejemplo del almacén de datos de la empresa anterior, uno de los principales
causas contribuyentes de caótica, disruptiva y, a veces, incluso catastrófica
lanzamientos de software, es la primera vez que vemos cómo funciona nuestra aplicación
se comporta en un entorno de producción con carga y producción realistas
conjuntos de datos es durante el lanzamiento.† En muchos casos, los equipos de desarrollo pueden tener
entornos de prueba solicitados en las primeras etapas del proyecto.

Sin embargo, cuando se requieren largos plazos de entrega para que las Operaciones entreguen
entornos de prueba, los equipos pueden no recibirlos lo suficientemente pronto como para realizar
prueba adecuada Peor aún, los entornos de prueba a menudo están mal configurados o lo son
diferente de nuestros entornos de producción que todavía terminamos con grandes
problemas de producción a pesar de haber realizado pruebas previas a la implementación.

En este paso, queremos que los desarrolladores ejecuten entornos similares a la producción en sus
Estaciones de trabajo propias, creadas bajo demanda y autoservicio. Al hacer esto,
los desarrolladores pueden ejecutar y probar su código en entornos de producción como
parte de su trabajo diario, proporcionando retroalimentación temprana y constante sobre la calidad
su trabajo.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 149 de 485
 En lugar de simplemente documentar las especificaciones de la producción
entorno en un documento o en una página wiki, creamos una compilación común
mecanismo que crea todos nuestros entornos, como el desarrollo,
prueba y producción. Al hacer esto, cualquiera puede obtener una producción
entornos en minutos, sin abrir un ticket, y mucho menos tener que esperar
semanas. ‡

Hacer esto requiere definir y automatizar la creación de nuestro bien conocido

entornos, que son estables, seguros y en un estado de riesgo reducido,
encarnando el conocimiento colectivo de la organización. Todos nuestros requisitos
están incrustados, no en documentos o como conocimiento en la cabeza de alguien, pero
codificado en nuestro proceso de construcción de entorno automatizado.

En lugar de Operaciones que construyen y configuran manualmente el entorno, nosotros

puede usar la automatización para cualquiera o todos los siguientes:

Copiar un entorno virtualizado (por ejemplo, una imagen de VMware, ejecutar un

Script vagabundo, iniciando un archivo de imagen de máquina de Amazon en EC2)

Crear un proceso de creación de entorno automatizado que comience desde

“Metal desnudo” (p. Ej., Instalación de PXE desde una imagen de referencia)

Page 146

Uso de herramientas de administración de configuración de "infraestructura como código" (por ejemplo,

Marioneta, Chef, Ansible, Sal, CFEngine, etc.)

Uso de herramientas de configuración del sistema operativo automatizado (p. Ej., Solaris
Jumpstart, Red Hat Kickstart, Debian preestablecido)

Ensamblar un entorno a partir de un conjunto de imágenes virtuales o contenedores

(p. ej., Vagabundo, Docker)

Hacer girar un nuevo entorno en una nube pública (por ejemplo, Amazon Web
Servicios, Google App Engine, Microsoft Azure), nube privada u otro
PaaS (plataforma como servicio, como OpenStack o Cloud Foundry, etc.).

Debido a que hemos definido cuidadosamente todos los aspectos del entorno antes de tiempo,
no solo podemos crear nuevos entornos rápidamente, sino también asegurarnos de que
Estos entornos serán estables, confiables, consistentes y seguros. Esta

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 150 de 485
 beneficia a todos.

Las operaciones se benefician de esta capacidad, para crear nuevos entornos rápidamente,
porque la automatización del proceso de creación del entorno impone consistencia
y reduce el trabajo manual tedioso y propenso a errores. Además, desarrollo
se beneficia al poder reproducir todas las partes necesarias de la producción
entorno para construir, ejecutar y probar su código en sus estaciones de trabajo. Haciendo
esto, permitimos que los desarrolladores encuentren y solucionen muchos problemas, incluso lo antes posible
etapas del proyecto, a diferencia de durante las pruebas de integración o peor, en
producción.

Al proporcionar a los desarrolladores un entorno que controlan completamente, les permitimos

Reproduzca, diagnostique y corrija defectos rápidamente, aislado de forma segura de la producción
servicios y otros recursos compartidos. También pueden experimentar con los cambios.
a los entornos, así como al código de infraestructura que lo crea (por ejemplo,
guiones de gestión de configuración), creando aún más el conocimiento compartido
entre Desarrollo y Operaciones.§

CREA NUESTRO ÚNICO REPOSITORIO DE VERDAD

PARA TODO EL SISTEMA

En el paso anterior, permitimos la creación a pedido del desarrollo,

prueba y entornos de producción. Ahora debemos asegurarnos de que todas las partes de nuestro
sistema de software.

Durante décadas, el uso integral del control de versiones se ha convertido cada vez más en un
práctica obligatoria de desarrolladores individuales y equipos de desarrollo.¶ A

Page 147

El sistema de control de versiones registra los cambios en los archivos o conjuntos de archivos almacenados en el
sistema. Esto puede ser código fuente, activos u otros documentos que pueden ser parte
de un proyecto de desarrollo de software. Hacemos cambios en grupos llamados
confirmaciones o revisiones. Cada revisión, junto con metadatos como quién hizo
el cambio y cuándo se almacena dentro del sistema de una forma u otra,
permitiéndonos comprometer, comparar, fusionar y restaurar revisiones pasadas a objetos
al repositorio. También minimiza los riesgos al establecer una forma de revertir
objetos en producción a versiones anteriores. (En este libro, los siguientes términos
se utilizará indistintamente: registrado en el control de versiones, comprometido en

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 151 de 485
 control de versiones, confirmación de código, confirmación de cambio, confirmación).

Cuando los desarrolladores colocan todos sus archivos de origen de aplicaciones y configuraciones en
control de versiones, se convierte en el único repositorio de verdad que contiene el
estado previsto preciso del sistema. Sin embargo, porque entregar valor a la
el cliente requiere tanto nuestro código como los entornos en los que se ejecuta, necesitamos
nuestros entornos en control de versiones también. En otras palabras, el control de versiones es
para todos en nuestro flujo de valor, incluidos QA, Operaciones, Infosec, así como
desarrolladores Al poner todos los artefactos de producción en control de versiones, nuestro
El repositorio de control de versiones nos permite reproducir de forma repetida y confiable
componentes de nuestro sistema de software en funcionamiento; esto incluye nuestras aplicaciones
y entorno de producción, así como toda nuestra preproducción
ambientes.

Para garantizar que podamos restaurar el servicio de producción de forma repetida y previsible
(e, idealmente, rápidamente) incluso cuando ocurren eventos catastróficos, debemos registrarnos
los siguientes activos para nuestro repositorio de control de versiones compartido:

Todo el código de aplicación y las dependencias (p. Ej., Bibliotecas, contenido estático, etc.)

Cualquier script utilizado para crear esquemas de bases de datos, datos de referencia de aplicaciones, etc.

Todas las herramientas y artefactos de creación de entornos descritos en el artículo anterior.

paso (p. ej., imágenes de VMware o AMI, recetas de marionetas o chefs, etc.)

Cualquier archivo utilizado para crear contenedores (por ejemplo, definición de Docker o Rocket o
archivos de composición)

Todas las pruebas automatizadas compatibles y cualquier script de prueba manual

Cualquier script que admita el empaquetado de código, la implementación, la migración de la base de datos,
y aprovisionamiento ambiental

Todos los artefactos del proyecto (por ejemplo, documentación de requisitos, implementación
procedimientos, notas de lanzamiento, etc.)

148 de 1189.

Todos los archivos de configuración en la nube (por ejemplo, plantillas de AWS Cloudformation,
Archivos Microsoft Azure Stack DSC, OpenStack HEAT)

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 152 de 485
 Cualquier otra secuencia de comandos o información de configuración requerida para crear
infraestructura que admite múltiples servicios (por ejemplo, servicio empresarial
buses, sistemas de gestión de bases de datos, archivos de zona DNS, reglas de configuración
para firewalls y otros dispositivos de red). ** **

Es posible que tengamos múltiples repositorios para diferentes tipos de objetos y servicios,
donde están etiquetados y etiquetados junto con nuestro código fuente. Por ejemplo,
podemos almacenar grandes imágenes de máquinas virtuales, archivos ISO, binarios compilados y
etc. en repositorios de artefactos (por ejemplo, Nexus, Artifactory). Alternativamente, nosotros
puede ponerlos en tiendas de blob (por ejemplo, cubos de Amazon S3) o poner imágenes de Docker
en los registros de Docker, y así sucesivamente.

No es suficiente simplemente poder recrear cualquier estado anterior del

entorno de producción; También debemos ser capaces de recrear todo el pre
procesos de producción y construcción también. En consecuencia, tenemos que poner en
control de versiones todo en lo que confían nuestros procesos de compilación, incluido nuestro
herramientas (por ejemplo, compiladores, herramientas de prueba) y los entornos de los que dependen.††

En el Informe de estado de DevOps 2014 de Puppet Labs , el uso del control de versiones por
Ops fue el mayor predictor tanto del rendimiento de TI como de la organización
actuación. De hecho, si Ops usó el control de versiones fue un predictor más alto
tanto para el desempeño de TI como para el desempeño organizacional que si Dev
control de versiones usado.

Los hallazgos del Informe de estado de DevOps de Puppet Labs 2014 subrayan el
El control crítico de la versión juega un papel en el proceso de desarrollo de software. Nosotros
ahora sepa cuándo se registran todos los cambios en la aplicación y el entorno
control de versiones, nos permite no solo ver rápidamente todos los cambios que podrían
ha contribuido a un problema, pero también proporciona los medios para volver a un
estado conocido anterior, en ejecución, lo que nos permite recuperarnos más rápidamente de
fallas

Pero, ¿por qué el uso del control de versiones para nuestros entornos predice TI y
¿Es mejor el desempeño organizacional que usar el control de versiones para nuestro código?

Porque en casi todos los casos, hay órdenes de magnitud más configurables
configuraciones en nuestro entorno que en nuestro código. En consecuencia, es el
entorno que necesita estar más en control de versiones.‡‡

El control de versiones también proporciona un medio de comunicación para todos.

trabajando en el flujo de valor: desarrollo, control de calidad, Infosec y
Las operaciones capaces de ver los cambios de los demás ayudan a reducir sorpresas, crea

Page 149

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 153 de 485
 visibilidad en el trabajo del otro, y ayuda a construir y reforzar la confianza. Ver
Apéndice 7 .

HAGA LA INFRAESTRUCTURA MÁS FÁCIL PARA RECONSTRUIR

QUE REPARAR

Cuando podemos reconstruir y recrear rápidamente nuestras aplicaciones y entornos

a pedido, también podemos reconstruirlos rápidamente en lugar de repararlos cuando
las cosas van mal. Aunque esto es algo que casi toda la web a gran escala
operaciones (es decir, más de mil servidores), también deberíamos adoptar
esta práctica incluso si solo tenemos un servidor en producción.

Bill Baker, un distinguido ingeniero de Microsoft, bromeó diciendo que solíamos

trata a los servidores como mascotas: "Los nombras y cuando se enferman, cuidas
ellos de vuelta a la salud. [Ahora] los servidores son [tratados] como ganado. Los numeras
y cuando se enferman, les disparas ".

Al tener sistemas de creación de entorno repetibles, somos capaces de

aumentar la capacidad al agregar más servidores en rotación (es decir, horizontal
escalada). También evitamos el desastre que inevitablemente resulta cuando debemos
restablecer el servicio después de una falla catastrófica de infraestructura irreproducible,
creado a través de años de cambios de producción indocumentados y manuales.

Para garantizar la coherencia de nuestros entornos, siempre que realizamos la producción.

cambios (cambios de configuración, parches, actualizaciones, etc.), esos cambios
necesita ser replicado en todas partes en nuestra producción y preproducción
entornos, así como en cualquier entorno recién creado.

En lugar de iniciar sesión manualmente en los servidores y hacer cambios, debemos hacer
cambios de una manera que garantiza que todos los cambios se replican en todas partes
automáticamente y que todos nuestros cambios se pongan en control de versiones.

Podemos confiar en nuestros sistemas de configuración automatizados para garantizar la coherencia

(p. ej., Puppet, Chef, Ansible, Salt, Bosh, etc.), o podemos crear nuevos virtuales
máquinas o contenedores de nuestro mecanismo automatizado de construcción y despliegue
en producción, destruyendo los viejos o sacándolos de
rotación.§§

El último patrón es lo que se conoce como infraestructura inmutable ,

donde los cambios manuales en el entorno de producción ya no están permitidos:
la única forma en que se pueden hacer cambios en la producción es poner los cambios en
control de versiones y recrea el código y los entornos desde cero. Por
Al hacer esto, ninguna variación puede arrastrarse a la producción.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 154 de 485
Page 150

Para evitar variaciones de configuración no controladas, podemos desactivar el control remoto

inicia sesión en servidores de producción ¶¶ o rutinariamente mata y reemplaza producción
instancias, asegurando que los cambios de producción aplicados manualmente se eliminen.
Esta acción motiva a todos a poner sus cambios de la manera correcta
a través del control de versiones. Al aplicar tales medidas, estamos sistemáticamente
Reducir las formas en que nuestra infraestructura puede derivar de nuestros conocidos y buenos estados
(por ejemplo, deriva de configuración, artefactos frágiles, obras de arte, copos de nieve, etc.
adelante).

Además, debemos mantener actualizados nuestros entornos de preproducción, específicamente,

necesitamos que los desarrolladores sigan funcionando en nuestro entorno más actual.
Los desarrolladores a menudo querrán seguir ejecutándose en entornos más antiguos porque
temen que las actualizaciones del entorno puedan romper la funcionalidad existente. Sin embargo, nos
queremos actualizarlos con frecuencia para que podamos encontrar problemas en la primera parte de
El ciclo de vida.***

MODIFICAR NUESTRA DEFINICIÓN DE DESARROLLO

"HECHO" PARA INCLUIR EL FUNCIONAMIENTO EN LA PRODUCCIÓN
ENTORNOS COMO

Ahora que nuestros entornos se pueden crear a pedido y todo está

registrado en el control de versiones, nuestro objetivo es garantizar que estos entornos
están siendo utilizados en el trabajo diario de desarrollo. Necesitamos verificar que nuestro
la aplicación se ejecuta como se esperaba en un entorno similar a la producción mucho antes de
final del proyecto o antes de nuestro primer despliegue de producción.

La mayoría de las metodologías modernas de desarrollo de software prescriben breves y

intervalos de desarrollo iterativos, en oposición al enfoque del big bang (por ejemplo, el
modelo de cascada). En general, cuanto más largo sea el intervalo entre la implementación, el
peores los resultados. Por ejemplo, en la metodología Scrum, un sprint es un
intervalo de desarrollo de tiempo (generalmente un mes o menos) dentro del cual
estamos obligados a terminar, ampliamente definidos como cuando tenemos "trabajando y
código potencialmente enviable ".

Nuestro objetivo es garantizar que el desarrollo y el control de calidad se integren habitualmente

codifique con entornos de producción a intervalos cada vez más frecuentes

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 155 de 485
 a lo largo del proyecto.††† Hacemos esto ampliando la definición de "hecho"
más allá de la funcionalidad correcta del código (adición en negrita): al final de
En cada intervalo de desarrollo, hemos integrado, probado, trabajando y
código potencialmente enviable, demostrado en una producción
medio ambiente .

Page 151

En otras palabras, solo aceptaremos el trabajo de desarrollo como hecho cuando puede ser
construido, implementado y confirmado con éxito que se ejecuta como se esperaba en un
entorno de producción, en lugar de simplemente cuando un desarrollador lo cree
para hacer, idealmente, se ejecuta bajo una carga de producción con una producción
como conjunto de datos, mucho antes del final de un sprint. Esto evita situaciones donde un
La función se llama hecho simplemente porque un desarrollador puede ejecutarla con éxito en
su computadora portátil pero en ningún otro lugar.

Al hacer que los desarrolladores escriban, prueben y ejecuten su propio código en una producción
entorno, la mayoría del trabajo para integrar con éxito nuestro código y
entornos ocurren durante nuestro trabajo diario, en lugar de al final de la
lanzamiento. Al final de nuestro primer intervalo, nuestra aplicación se puede demostrar
para ejecutarse correctamente en un entorno de producción, con el código y
El entorno se ha integrado muchas veces, idealmente con todos
los pasos automatizados (no se requieren modificaciones manuales).

Mejor aún, al final del proyecto, habremos desplegado con éxito y

ejecutar nuestro código en entornos de producción cientos o incluso miles de
veces, dándonos la confianza de que la mayoría de nuestros problemas de implementación de producción
han sido encontrados y reparados

Idealmente, utilizamos las mismas herramientas, como monitoreo, registro e implementación,

en nuestros entornos de preproducción como lo hacemos en producción. Al hacer esto, nosotros
tener familiaridad y experiencia que nos ayudará a implementar y ejecutar sin problemas, como
así como diagnosticar y reparar nuestro servicio cuando está en producción.

Al permitir que Development and Operations obtenga un dominio compartido de cómo

el código y el entorno interactúan, y practican implementaciones temprano y con frecuencia,
reducimos significativamente los riesgos de implementación asociados con
lanzamientos de código de producción. Esto también nos permite eliminar una clase completa de
defectos operacionales y de seguridad y problemas arquitectónicos que generalmente son
atrapado demasiado tarde en el proyecto para arreglarlo.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 156 de 485
 CONCLUSIÓN

El rápido flujo de trabajo desde el desarrollo hasta las operaciones requiere que cualquiera
puede obtener entornos de producción bajo demanda. Al permitir que los desarrolladores
usar entornos similares a la producción incluso en las primeras etapas de un software
proyecto, reducimos significativamente el riesgo de problemas de producción más adelante. Esto es
Una de las muchas prácticas que demuestran cómo las operaciones pueden hacer que los desarrolladores
Mucho más productivo. Aplicamos la práctica de los desarrolladores que ejecutan su código

Página 152

en entornos de producción al incorporarlo en la definición de

"hecho."

Además, al poner todos los artefactos de producción en control de versiones, tenemos

una "fuente única de verdad" que nos permite recrear toda la producción
entorno de forma rápida, repetible y documentada, utilizando el mismo
las prácticas de desarrollo para Operaciones funcionan como lo hacemos para el trabajo de Desarrollo.
Y al hacer que la infraestructura de producción sea más fácil de reconstruir que de reparar, nosotros
facilitar y agilizar la resolución de problemas, así como también facilitar
ampliar la capacidad

Tener estas prácticas en su lugar establece el escenario para permitir una prueba integral
automatización, que se explora en el próximo capítulo.

† En este contexto, el entorno se define como todo en la pila de aplicaciones, excepto la aplicación, incluidas las bases de datos,
sistemas operativos, redes, virtualización y todas las configuraciones asociadas.

‡ La mayoría de los desarrolladores quieren probar su código, y a menudo han hecho todo lo posible para obtener entornos de prueba para hacerlo.
Se sabe que los desarrolladores reutilizan entornos de prueba antiguos de proyectos anteriores (a menudo años) o preguntan a alguien que tiene un
reputación de poder encontrar uno, simplemente no preguntarán de dónde vino, porque, invariablemente, alguien en algún lugar está ahora
Falta un servidor.

§ Idealmente, deberíamos encontrar errores antes de las pruebas de integración cuando es demasiado tarde en el ciclo de pruebas para crear comentarios rápidos para
desarrolladores Si no podemos hacerlo, es probable que tengamos un problema arquitectónico que debe abordarse. Diseñando nuestros sistemas para
comprobabilidad, para incluir la capacidad de descubrir la mayoría de los defectos utilizando un entorno virtual no integrado en una estación de trabajo de desarrollo,
es una parte clave de la creación de una arquitectura que admita flujo rápido y retroalimentación.

¶ El primer sistema de control de versiones probablemente estaba ACTUALIZADO en el CDC6600 (1969). Más tarde llegó SCCS (1972), CMS en VMS (1978), RCS
(1982), y así sucesivamente.

** Se puede observar que el control de versiones cumple algunas de las construcciones ITIL de la Biblioteca de medios definitiva (DML) y la Configuración
Base de datos de gestión (CMDB), haciendo un inventario de todo lo necesario para volver a crear el entorno de producción.

†† En futuros pasos, también realizaremos el check-in para controlar la versión de toda la infraestructura de soporte que construimos, como las suites de prueba automatizadas
y nuestra infraestructura de tubería de integración y despliegue continuo.

‡‡ Cualquiera que haya realizado una migración de código para un sistema ERP (por ejemplo, SAP, Oracle Financials, etc.) puede reconocer la siguiente situación:
Cuando falla la migración de un código, rara vez se debe a un error de codificación. En cambio, es mucho más probable que la migración haya fallado debido a algunos
diferencia en los entornos, como entre Desarrollo y QA o QA y Producción.

§§ En Netflix, la edad promedio de la instancia de Netflix AWS es de veinticuatro días, con un 60% de menos de una semana de antigüedad.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 157 de 485
 ¶¶ O permitirlo solo en emergencias, asegurando que una copia del registro de la consola se envíe automáticamente por correo electrónico al equipo de operaciones.

*** Toda la pila de aplicaciones y el entorno pueden agruparse en contenedores, lo que puede permitir una simplicidad y
velocidad en toda la tubería de implementación.

††† El término integración tiene muchos usos ligeramente diferentes en Desarrollo y Operaciones. En desarrollo, la integración típicamente
se refiere a la integración de código, que es la integración de múltiples ramas de código en el tronco en el control de versiones. En entrega continua
y DevOps, las pruebas de integración se refieren a las pruebas de la aplicación en un entorno de producción o prueba integrada
ambiente.

Page 154
153

10 Habilitar rápido y
Pruebas automatizadas confiables

En este punto, el desarrollo y el control de calidad están utilizando entornos similares a la producción en su diario
trabajo, y estamos integrando y ejecutando con éxito nuestro código en una producción
entorno para cada característica que se acepta, con todos los cambios registrados en la versión
controlar. Sin embargo, es probable que obtengamos resultados no deseados si encontramos y corregimos errores en un
fase de prueba separada, ejecutada por un departamento de control de calidad separado solo después de que todo el desarrollo haya
ha sido completado Y, si las pruebas solo se realizan unas pocas veces al año, los desarrolladores aprenden
sobre sus errores meses después de que introdujeron el cambio que causó el error. Por
entonces, el vínculo entre causa y efecto probablemente se ha desvanecido, resolver el problema requiere
lucha contra incendios y arqueología y, lo peor de todo, nuestra capacidad de aprender del error y
integrarlo en nuestro trabajo futuro se ve significativamente disminuido.

Las pruebas automatizadas abordan otro problema significativo e inquietante. Gary Gruver
observa que "sin pruebas automatizadas, cuanto más código escribimos, más tiempo y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 158 de 485
 se requiere dinero para probar nuestro código; en la mayoría de los casos, este es un negocio totalmente escalable
modelo para cualquier organización tecnológica ".

Aunque Google ahora sin duda ejemplifica una cultura que valora las pruebas automatizadas en
escala, este no siempre fue el caso. En 2005, cuando Mike Bland se unió a la organización,
la implementación en Google.com a menudo era extremadamente problemática, especialmente para Google Web
Equipo de servidor (GWS).

Como explica Bland: "El equipo de GWS se había puesto en una posición a mediados de la década de 2000 donde
fue extremadamente difícil hacer cambios en el servidor web, una aplicación C ++ que manejaba
todas las solicitudes a la página de inicio de Google y muchas otras páginas web de Google. Tan importante y
prominente como lo fue Google.com, estar en el equipo de GWS no fue una tarea glamorosa:
a menudo era el vertedero de todos los diferentes equipos que estaban creando varios
funcionalidad de búsqueda, todos los cuales estaban desarrollando código independientemente uno del otro. Ellos
tuvo problemas como que las compilaciones y las pruebas demoraron demasiado, el código se puso en producción
sin ser probado, y los equipos controlan cambios grandes e infrecuentes que entran en conflicto con
los de otros equipos ".

Las consecuencias de esto fueron grandes: los resultados de búsqueda podrían tener errores o convertirse en
inaceptablemente lento, que afecta a miles de consultas de búsqueda en Google.com. El potencial
El resultado no fue solo la pérdida de ingresos, sino también la confianza del cliente.

Bland describe cómo afectó a los desarrolladores que implementaron cambios: "El miedo se convirtió en la mente-
asesino. El miedo evitó que los nuevos miembros del equipo cambiaran las cosas porque no lo hicieron
Entiende el sistema. Pero el miedo también impidió que las personas experimentadas cambiaran las cosas.
porque lo entendieron muy bien ".† Bland era parte del grupo que se determinó
para resolver este problema.

155 de 1189.

El líder del equipo de GWS, Bharat Mediratta, creía que las pruebas automatizadas ayudarían. Como Bland
describe: "Crearon una línea dura: no se aceptarían cambios en GWS sin
pruebas automatizadas de acompañamiento. Establecieron una construcción continua y la mantuvieron religiosamente
paso. Establecieron monitoreo de cobertura de prueba y se aseguraron de que su nivel de cobertura de prueba
subió con el tiempo. Redactaron políticas y guías de prueba e insistieron en que los contribuyentes
tanto dentro como fuera del equipo los siguen ".

Los resultados fueron sorprendentes. Como señala Bland, "GWS se convirtió rápidamente en uno de los más
equipos productivos en la empresa, integrando grandes cantidades de cambios de diferentes
equipos cada semana manteniendo un calendario de lanzamiento rápido. Los nuevos miembros del equipo fueron
capaz de hacer contribuciones productivas a este complejo sistema rápidamente, gracias a una buena prueba
cobertura y código de salud. Finalmente, su política radical permitió el inicio de Google.com
página para expandir rápidamente sus capacidades y prosperar en un movimiento increíblemente rápido y
panorama tecnológico competitivo ".

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 159 de 485
 Pero GWS seguía siendo un equipo relativamente pequeño en una empresa grande y en crecimiento. El equipo
quería expandir estas prácticas en toda la organización. Por lo tanto, el grupo de prueba
nació, un grupo informal de ingenieros que querían elevar las pruebas automatizadas
prácticas en toda la organización. Durante los siguientes cinco años, ayudaron a replicar esto
cultura de pruebas automatizadas en todo Google. ‡

Ahora, cuando cualquier desarrollador de Google confirma el código, se ejecuta automáticamente en un conjunto de
cientos de miles de pruebas automatizadas. Si el código pasa, se fusiona automáticamente
en el maletero, listo para ser desplegado en producción. Muchas propiedades de Google se crean cada hora o
diariamente, luego elija qué compilaciones lanzar; otros adoptan un continuo "Push on Green"
Filosofía de entrega.

Las apuestas son más altas que nunca: un solo error de implementación de código en Google puede eliminar
cada propiedad, todo al mismo tiempo (como un cambio de infraestructura global o cuando un
el defecto se introduce en una biblioteca central de la que depende cada propiedad).

Eran Messeri, ingeniero del grupo de Infraestructura de desarrolladores de Google, señala: "Grande
las fallas ocurren ocasionalmente. Recibirás un montón de mensajes instantáneos e ingenieros llamando
en tu puerta [Cuando la tubería de implementación se rompe,] necesitamos arreglarlo de inmediato,
porque los desarrolladores ya no pueden confirmar el código. En consecuencia, queremos que sea muy fácil.
retroceder ".

Lo que permite que este sistema funcione en Google es la profesionalidad de la ingeniería y una gran confianza
cultura que asume que todos quieren hacer un buen trabajo, así como la capacidad de detectar y
Corrija los problemas rápidamente. Messeri explica: "No hay políticas estrictas en Google, como" Si
interrumpe la producción de más de diez proyectos, tiene un SLA para solucionar el problema
diez minutos.' En cambio, existe un respeto mutuo entre los equipos y un acuerdo implícito.
que todo el mundo haga lo que sea necesario para mantener en funcionamiento la canalización de implementación. Todos sabemos
que un día romperé tu proyecto por accidente; al día siguiente, puedes romper el mío ".

Lo que Mike Bland y el equipo de Testing Grouplet lograron ha hecho de Google uno de los
organizaciones tecnológicas más productivas del mundo. Para 2013, pruebas automatizadas y
La integración continua en Google permitió a más de cuatro mil pequeños equipos trabajar juntos
y mantenerse productivo, todos desarrollando, integrando, probando e implementando simultáneamente
su código en producción. Todo su código está en un único repositorio compartido, compuesto por

Page 156

miles de millones de archivos, todos ellos continuamente construidos e integrados, con el 50% de su código siendo
cambiado cada mes Algunas otras estadísticas impresionantes sobre su desempeño incluyen:

40,000 confirmaciones de código / día

50,000 construcciones / día (entre semana, esto puede exceder 90,000)

120,000 suites de pruebas automatizadas

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 160 de 485
 75 millones de casos de prueba se ejecutan diariamente

Más de 100 ingenieros trabajando en ingeniería de prueba, integración continua y lanzamiento

herramientas de ingeniería para aumentar la productividad del desarrollador (que representan el 0,5% de la I + D
personal)

En el resto de este capítulo, veremos las prácticas de integración continua.

requerido para replicar estos resultados.

CONTINUAMENTE CONSTRUYA, PRUEBE E INTEGRE NUESTRO CÓDIGO

Y ENTORNOS

Nuestro objetivo es incorporar calidad a nuestro producto, incluso en las primeras etapas, al tener
Los desarrolladores crean pruebas automatizadas como parte de su trabajo diario. Esto crea una respuesta rápida
bucle que ayuda a los desarrolladores a encontrar problemas temprano y solucionarlos rápidamente, cuando hay
pocas limitaciones (p. ej., tiempo, recursos).

En este paso, creamos conjuntos de pruebas automatizadas que aumentan la frecuencia de integración y
prueba de nuestro código y nuestros entornos de periódicos a continuos. Hacemos esto por
construyendo nuestra tubería de implementación, que realizará la integración de nuestro código y
entornos y desencadenan una serie de pruebas cada vez que se introduce un nuevo cambio en la versión
controlar. § (Verfigura 13. )

La tubería de despliegue, definida por primera vez por Jez Humble y David Farley en su libro
Entrega continua: lanzamientos confiables de software a través de compilación, prueba e implementación
La automatización garantiza que todo el código registrado en el control de versiones se construya automáticamente y
probado en un entorno similar a la producción. Al hacer esto, encontramos cualquier compilación, prueba o
errores de integración tan pronto como se introduce un cambio, lo que nos permite corregirlos de inmediato.
Hecho correctamente, esto nos permite estar siempre seguros de que estamos en una implementación
Estado de envío.

Para lograr esto, debemos crear procesos automatizados de compilación y prueba que se ejecutan en
ambientes. Esto es crítico por las siguientes razones:

Nuestro proceso de compilación y prueba puede ejecutarse todo el tiempo, independientemente de los hábitos de trabajo de
ingenieros individuales

Un proceso de compilación y prueba segregado garantiza que comprendamos todas las dependencias
requerido para construir, empaquetar, ejecutar y probar nuestro código (es decir, eliminar el "funcionó en el
portátil de desarrollador, pero se rompió en la producción "problema").

Page 157

Podemos empaquetar nuestra aplicación para permitir la instalación repetible de código y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 161 de 485
 configuraciones en un entorno (por ejemplo, en Linux RPM, yum, npm; en Windows,
OneGet; Alternativamente, se pueden utilizar sistemas de embalaje específicos del marco, como EAR
y archivos WAR para Java, gemas para Ruby, etc.).

En lugar de poner nuestro código en paquetes, podemos optar por empaquetar nuestras aplicaciones en
contenedores desplegables (por ejemplo, Docker, Rkt, LXD, AMI).

Los entornos se pueden hacer más productivos de una manera consistente y

repetible (por ejemplo, los compiladores se eliminan del entorno, los indicadores de depuración son
apagado, etc.).

Nuestra tubería de implementación se valida después de cada cambio que nuestro código integra con éxito
en un entorno de producción. Se convierte en la plataforma a través de la cual los probadores solicitan
y certifica las compilaciones durante las pruebas de aceptación y las pruebas de usabilidad, y se ejecutará automáticamente
validaciones de rendimiento y seguridad.

>
Figura 13: La tubería de implementación (Fuente: Humble y Farley, Entrega continua , 3.)

Además, se usará para compilaciones de autoservicio para UAT (prueba de aceptación del usuario),
pruebas de integración y entornos de prueba de seguridad. En pasos futuros, a medida que evolucionamos
canalización de implementación, también se utilizará para administrar todas las actividades necesarias para llevar nuestro
cambios del control de versiones a la implementación.

Se ha diseñado una variedad de herramientas para proporcionar la funcionalidad de canalización de implementación, muchas
de ellos de código abierto (por ejemplo, Jenkins, ThoughtWorks Go, Concourse, Bamboo, Microsoft
Team Foundation Server, TeamCity, Gitlab CI, así como soluciones basadas en la nube como
Travis CI y Snap). ¶

Comenzamos la canalización de implementación ejecutando la etapa de confirmación, que compila y empaqueta

el software, ejecuta pruebas de unidad automatizadas y realiza validaciones adicionales, como estáticas
análisis de código, duplicación y análisis de cobertura de prueba, y verificación de estilo. ** Si tiene éxito,
esto desencadena la etapa de aceptación, que implementa automáticamente los paquetes creados en el
compromete la etapa en un entorno similar a la producción y ejecuta las pruebas de aceptación automatizadas.

Una vez que se aceptan los cambios en el control de versiones, queremos empaquetar nuestro código solo una vez, así que
que los mismos paquetes se utilizan para implementar código en toda nuestra línea de implementación.
Al hacer esto, el código se implementará en nuestros entornos integrados de prueba y preparación en
de la misma manera que se implementa en producción. Esto reduce las variaciones que pueden evitar
errores posteriores que son difíciles de diagnosticar (por ejemplo, usar diferentes compiladores, compiladores
banderas, versiones de biblioteca o configuraciones).††

El objetivo de la canalización de implementación es proporcionar a todos en la cadena de valor, especialmente

desarrolladores, la retroalimentación más rápida posible de que un cambio nos ha sacado de un despliegue
estado. Esto podría ser un cambio en nuestro código, en cualquiera de nuestros entornos, en nuestro
pruebas, o incluso a la infraestructura de la tubería de implementación (por ejemplo, una configuración de Jenkins
ajuste).

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 162 de 485
Page 158

Como resultado, nuestra infraestructura de canalización de implementación se vuelve fundamental para nuestra
procesos de desarrollo como nuestra infraestructura de control de versiones. Nuestra tubería de despliegue también
almacena el historial de cada compilación de código, incluida la información sobre qué pruebas fueron
realizado en qué compilación, qué compilaciones se han implementado en qué entorno, y
cuáles fueron los resultados de la prueba. En combinación con la información en nuestro control de versiones
historial, podemos determinar rápidamente qué causó la ruptura de nuestra tubería de implementación y,
probablemente, cómo solucionar el error.

Esta información también nos ayuda a cumplir con los requisitos de evidencia para auditoría y cumplimiento
propósitos, con evidencia que se genera automáticamente como parte del trabajo diario.

Ahora que tenemos una infraestructura de canalización de implementación en funcionamiento, debemos crear nuestra
Prácticas de integración continua , que requieren tres capacidades:

Un conjunto completo y confiable de pruebas automatizadas que validan que estamos en una implementación
estado.

Una cultura que "detiene toda la línea de producción" cuando nuestras pruebas de validación fallan.

Desarrolladores que trabajan en pequeños lotes en el tronco en lugar de ramas características de larga duración.

En la siguiente sección, describimos por qué se necesitan pruebas automatizadas rápidas y confiables y cómo
para construirlo

CONSTRUIR UNA VALIDACIÓN AUTOMÁTICA RÁPIDA Y CONFIABLE

BANCO DE PRUEBAS

En el paso anterior, comenzamos a crear la infraestructura de prueba automatizada que

valida que tenemos una compilación verde (es decir, lo que sea que esté en el control de versiones está en un compilador
y estado desplegable). Para subrayar por qué necesitamos realizar esta integración y pruebas
paso continuo, considere lo que sucede cuando solo realizamos esta operación
periódicamente, como durante un proceso de construcción nocturno.

Supongamos que tenemos un equipo de diez desarrolladores, y todos verifican su código en la versión
control diario, y un desarrollador introduce un cambio que rompe nuestra compilación y prueba nocturna
trabajo. En este escenario, cuando descubrimos al día siguiente que ya no tenemos una construcción verde,
nuestro equipo de desarrollo tardará minutos, o más horas, en determinar qué
El cambio causó el problema, quién lo introdujo y cómo solucionarlo.

Peor aún, suponga que el problema no fue causado por un cambio de código, sino que se debió a una prueba
problema de entorno (p. ej., una configuración incorrecta en alguna parte). El desarrollo
el equipo puede creer que resolvió el problema porque todas las pruebas unitarias pasan, solo para
descubre que las pruebas seguirán fallando más tarde esa noche.

Para complicar aún más el problema, se habrán registrado diez cambios más en la versión
control por el equipo ese día. Cada uno de estos cambios tiene el potencial de introducir más
errores que podrían romper nuestras pruebas automatizadas, aumentando aún más la dificultad de tener éxito
diagnosticando y solucionando el problema.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 163 de 485
 En resumen, la retroalimentación lenta y periódica mata. Especialmente para equipos de desarrollo más grandes. los
problema se vuelve aún más desalentador cuando tenemos decenas, cientos o incluso miles de

Page 159

otros desarrolladores verifican sus cambios en el control de versiones cada día. El resultado es que
nuestras compilaciones y pruebas automatizadas se rompen con frecuencia, y los desarrolladores incluso dejan de verificar
sus cambios en el control de versiones ("¿Por qué molestarse, ya que las compilaciones y las pruebas son siempre
¿roto?"). En cambio, esperan para integrar su código al final del proyecto, lo que resulta en todo
los resultados no deseados del gran tamaño de lote, integraciones de big bang y producción
despliegues‡‡

Para evitar este escenario, necesitamos pruebas automáticas rápidas que se ejecuten dentro de nuestra compilación y prueba
entornos cada vez que se introduce un nuevo cambio en el control de versiones. De esta manera nosotros
puede encontrar y solucionar cualquier problema de inmediato, como el ejemplo del servidor web de Google
demostrado Al hacer esto, nos aseguramos de que nuestros lotes sigan siendo pequeños y, en cualquier momento dado
a tiempo, permanecemos en un estado desplegable.

En general, las pruebas automatizadas se dividen en una de las siguientes categorías, de la más rápida a la más lenta:

Pruebas unitarias : por lo general, prueban un único método, clase o función de forma aislada,
Brindar al desarrollador la seguridad de que su código funciona según lo diseñado. Para muchos
razones, incluida la necesidad de mantener nuestras pruebas rápidas y sin estado, las pruebas unitarias suelen "
fuera "de bases de datos y otras dependencias externas (por ejemplo, las funciones se modifican para devolver
valores estáticos predefinidos, en lugar de llamar a la base de datos real).§§

Pruebas de aceptación : generalmente prueban la aplicación en su conjunto para garantizar

que un mayor nivel de funcionalidad opera según lo diseñado (por ejemplo, la aceptación comercial
criterios para una historia de usuario, la corrección de una API) y que los errores de regresión no
introducido (es decir, rompimos la funcionalidad que anteriormente funcionaba correctamente).
Humble y Farley definen la diferencia entre la unidad y las pruebas de aceptación como "El
El objetivo de una prueba unitaria es mostrar que una sola parte de la aplicación hace lo que el
programador tiene la intención de ... El objetivo de las pruebas de aceptación es demostrar que nuestro
la aplicación hace lo que el cliente quiso, no es que funcione de la manera
los programadores piensan que debería ". Después de que una compilación pasa nuestras pruebas unitarias, nuestro despliegue
la tubería lo ejecuta contra nuestras pruebas de aceptación. Cualquier compilación que pase nuestras pruebas de aceptación
normalmente se pone a disposición para pruebas manuales (por ejemplo, pruebas exploratorias, pruebas de IU,
etc.), así como para pruebas de integración.

Pruebas de integración : las pruebas de integración son donde nos aseguramos de que nuestra aplicación sea correcta
interactúa con otras aplicaciones y servicios de producción, en lugar de llamar a stubbed
fuera de las interfaces. Como observan Humble y Farley, "gran parte del trabajo en el SIT
El entorno implica la implementación de nuevas versiones de cada una de las aplicaciones hasta que todas
cooperar. En esta situación, la prueba de humo suele ser un conjunto completo de aceptación
pruebas que se ejecutan contra toda la aplicación ". Las pruebas de integración se realizan en compilaciones

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 164 de 485
 que han pasado nuestras pruebas de unidad y aceptación. Porque las pruebas de integración son a menudo
frágil, queremos minimizar el número de pruebas de integración y encontrar tantas de nuestras
defectos como sea posible durante la unidad y las pruebas de aceptación. La capacidad de usar virtual o
versiones simuladas de servicios remotos cuando la ejecución de pruebas de aceptación se convierte en un
Requisito arquitectónico esencial.

Al enfrentar presiones de fecha límite, los desarrolladores pueden dejar de crear pruebas unitarias como parte de su
trabajo diario, independientemente de cómo hayamos definido 'hecho'. Para detectar esto, podemos elegir
medir y hacer visible nuestra cobertura de prueba (en función del número de clases, líneas de

160 de 1189.

código, permutaciones, etc.), incluso puede fallar nuestro conjunto de pruebas de validación cuando cae por debajo
cierto nivel (p. ej., cuando menos del 80% de nuestras clases tienen pruebas unitarias).¶¶

Martin Fowler observa que, en general, "una construcción de diez minutos [y un proceso de prueba] es perfectamente
dentro de lo razonable ... [Primero] hacemos la compilación y ejecutamos pruebas que son unidades más localizadas
pruebas con la base de datos completamente apagada. Tales pruebas pueden ejecutarse muy rápido, manteniéndose dentro de
La directriz de diez minutos. Sin embargo, cualquier error que implique interacciones a mayor escala,
particularmente aquellos que involucran la base de datos real, no se encontrarán. La construcción de la segunda etapa se ejecuta
un conjunto diferente de pruebas [pruebas de aceptación] que llegan a la base de datos real e involucran más
comportamiento de extremo a extremo. Esta suite puede tardar un par de horas en ejecutarse ".

TENGA ERRORES TAN PRONTO EN NUESTRAS PRUEBAS AUTOMATIZADAS COMO POSIBLE

Un objetivo de diseño específico de nuestro conjunto de pruebas automatizadas es encontrar errores lo antes posible en las pruebas como
posible. Es por eso que ejecutamos pruebas automatizadas de ejecución más rápida (p. Ej., Pruebas unitarias) antes que más lento.
ejecutar pruebas automatizadas (por ejemplo, pruebas de aceptación e integración), que se ejecutan antes
Cualquier prueba manual.

Otro corolario de este principio es que cualquier error debe encontrarse con el más rápido.
categoría de prueba posible. Si la mayoría de nuestros errores se encuentran en nuestra aceptación y
pruebas de integración, los comentarios que brindamos a los desarrolladores son mucho más lentos que
con pruebas unitarias, y las pruebas de integración requieren el uso de pruebas de integración escasas y complejas
entornos, que solo pueden ser utilizados por un equipo a la vez, lo que retrasa aún más los comentarios.

Además, no solo los errores detectados durante las pruebas de integración son difíciles y el tiempo
consumir para los desarrolladores reproducir, incluso validar que se ha solucionado es difícil
(es decir, un desarrollador crea una solución pero luego necesita esperar cuatro horas para saber si el
las pruebas de integración ahora pasan).

Por lo tanto, siempre que encontremos un error con una prueba de aceptación o integración, debemos
cree una prueba unitaria que pueda encontrar el error más rápido, antes y más barato. Martin Fowler
describió la noción de la "pirámide de prueba ideal", donde podemos capturar la mayoría de nuestros
errores al usar nuestras pruebas unitarias. (Verfigura 14.) En contraste, en muchos programas de prueba el
lo inverso es cierto, donde la mayor parte de la inversión se realiza en pruebas manuales y de integración.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 165 de 485
 Figura 14: Las pirámides de prueba automatizadas ideales y no ideales (Fuente: Martin Fowler,
"TestPyramid")

Page 161

Si encontramos que la unidad o las pruebas de aceptación son demasiado difíciles y caras de escribir y
mantener, es probable que tengamos una arquitectura que esté demasiado unida, donde sea fuerte
La separación entre los límites de nuestro módulo ya no existe (o tal vez nunca existió). En
En este caso, tendremos que crear un sistema más débilmente acoplado para que los módulos puedan ser
probado de forma independiente sin entornos de integración. Conjuntos de pruebas de aceptación incluso para
Son posibles las aplicaciones más complejas que se ejecutan en minutos.

ASEGURAR QUE LAS PRUEBAS SE EJECUTEN RÁPIDAMENTE (EN PARALELO, SI ES NECESARIO)

Debido a que queremos que nuestras pruebas se ejecuten rápidamente, necesitamos diseñar nuestras pruebas para que se ejecuten en paralelo,
potencialmente en muchos servidores diferentes. También podemos querer ejecutar diferentes categorías de
pruebas en paralelo. Por ejemplo, cuando una compilación pasa nuestras pruebas de aceptación, podemos ejecutar nuestro
pruebas de rendimiento en paralelo con nuestras pruebas de seguridad, como se muestra en la figura 15. Podemos o
es posible que no permita las pruebas exploratorias manuales hasta que la compilación haya pasado todas nuestras pruebas automatizadas
—Que permite una retroalimentación más rápida, pero también puede permitir pruebas manuales en compilaciones que
eventualmente fallará.

Hacemos que cualquier compilación que pase todas nuestras pruebas automatizadas esté disponible para su uso para exploración
pruebas, así como para otras formas de pruebas manuales o intensivas en recursos (como
pruebas de rendimiento). Queremos hacer todas estas pruebas con la mayor frecuencia posible y práctica,
ya sea continuamente o en un horario.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 166 de 485
 Figura 15: Ejecución de pruebas automáticas y manuales en paralelo
(Fuente: Humble and Farley, Continuous Delivery , edición Kindle, ubicación 3868.)

Cualquier probador (que incluye a todos nuestros desarrolladores) debe usar la última compilación que haya pasado
todas las pruebas automatizadas, en lugar de esperar a que los desarrolladores marquen una compilación específica como lista
Probar. Al hacer esto, nos aseguramos de que las pruebas se realicen lo antes posible en el proceso.

ESCRIBE NUESTRAS PRUEBAS AUTOMATIZADAS ANTES DE ESCRIBIR EL CÓDIGO ("PRUEBA-

DESARROLLO IMPULSADO ")
Una de las formas más efectivas de garantizar que tengamos pruebas automáticas confiables es escribir
esas pruebas como parte de nuestro trabajo diario, utilizando técnicas como el desarrollo basado en pruebas
(TDD) y el desarrollo basado en pruebas de aceptación (ATDD). Esto es cuando comenzamos cada
cambiar al sistema escribiendo primero una prueba automatizada que valide el comportamiento esperado
falla , y luego escribimos el código para que las pruebas pasen.

Page 162

Esta técnica fue desarrollada por Kent Beck a fines de la década de 1990 como parte de Extreme
Programación, y tiene los siguientes tres pasos:

1. Asegúrese de que las pruebas fallen. "Escriba una prueba para el próximo bit de funcionalidad que desea agregar".
Registrarse.

2. Asegúrese de que las pruebas pasen. "Escriba el código funcional hasta que pase la prueba".

3. "Refactorice el código nuevo y el antiguo para hacerlo bien estructurado". Asegúrese de que las pruebas pasen.
Regístrese nuevamente.

Estas suites de pruebas automatizadas se registran en el control de versiones junto con nuestro código, que
proporciona una especificación actualizada y viva del sistema. Desarrolladores que deseen entender
cómo usar el sistema puede ver este conjunto de pruebas para encontrar ejemplos de trabajo sobre cómo usar el
API del sistema. ***

AUTOMATIZAR COMO MUCHAS DE NUESTRAS PRUEBAS MANUALES COMO POSIBLE

Nuestro objetivo es encontrar tantos errores de código a través de nuestras suites de pruebas automatizadas, reduciendo nuestro
dependencia en pruebas manuales. En su presentación de 2013 en Flowcon titulada "On the Care and

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 167 de 485
 Alimentación de los ciclos de retroalimentación ", observó Elisabeth Hendrickson," aunque las pruebas pueden ser
automatizado, la creación de calidad no puede. Tener humanos ejecutando pruebas que deberían ser
automatizado es una pérdida de potencial humano ".

Al hacer esto, permitimos que todos nuestros probadores (que, por supuesto, incluyen desarrolladores) trabajen en
actividades de alto valor que no pueden automatizarse, como pruebas exploratorias o mejoras
El proceso de prueba en sí.

Sin embargo, la simple automatización de todas nuestras pruebas manuales puede crear resultados no deseados.
no quiere pruebas automatizadas que no sean confiables o generen falsos positivos (es decir, pruebas que
debería haber pasado porque el código es funcionalmente correcto pero falló debido a problemas como
como rendimiento lento, causando tiempos de espera, estado de inicio no controlado o estado no deseado
debido al uso de stubs de bases de datos o entornos de prueba compartidos).

Las pruebas poco confiables que generan falsos positivos crean problemas importantes: desperdician
tiempo valioso (por ejemplo, obligar a los desarrolladores a volver a ejecutar la prueba para determinar si hay
en realidad un problema), aumentar el esfuerzo general de ejecutar e interpretar los resultados de nuestras pruebas,
y a menudo resultan en desarrolladores estresados ​que ignoran los resultados de las pruebas por completo o apagan el
pruebas automatizadas a favor de centrarse en la creación de código.

El resultado es siempre el mismo: detectamos los problemas más tarde, los problemas son más difíciles
para arreglar, y nuestros clientes tienen peores resultados, lo que a su vez crea estrés en todo el
flujo de valor.

Para mitigar esto, un pequeño número de pruebas confiables y automatizadas son casi siempre
preferible a una gran cantidad de pruebas automáticas manuales o poco confiables. por lo tanto, nosotros
enfóquese en automatizar solo las pruebas que realmente validan los objetivos comerciales que estamos intentando
conseguir. Si abandonar una prueba da como resultado defectos de producción, debemos agregarla nuevamente a nuestro
conjunto de pruebas manuales, con el ideal de eventualmente automatizarlo.

Como Gary Gruver, ex vicepresidente de ingeniería de calidad, ingeniería de lanzamiento y operaciones

para Macys.com, describe observa, "Para un gran sitio de comercio electrónico minorista, pasamos de

Page 163

ejecutar 1.300 pruebas manuales que realizamos cada diez días para ejecutar solo diez pruebas automatizadas
en cada confirmación de código: es mucho mejor ejecutar algunas pruebas en las que confiamos que ejecutar pruebas
que no son confiables Con el tiempo, crecimos este conjunto de pruebas para tener cientos de miles de
pruebas automatizadas ".

En otras palabras, comenzamos con una pequeña cantidad de pruebas automáticas confiables y las agregamos
con el tiempo, creando un nivel de seguridad cada vez mayor de que detectaremos rápidamente cualquier
cambios en el sistema que nos sacan de un estado desplegable.

PRUEBAS INTEGRALES DE DESEMPEÑO EN NUESTRO SUITE DE PRUEBAS

Con demasiada frecuencia, descubrimos que nuestra aplicación funciona mal durante las pruebas de integración o
después de que se haya implementado en producción. Los problemas de rendimiento son a menudo difíciles de resolver.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 168 de 485
 detectar, como cuando las cosas se ralentizan con el tiempo, pasan desapercibidas hasta que es demasiado tarde (por ejemplo,
consultas de bases de datos sin un índice). Y muchos problemas son difíciles de resolver, especialmente
cuando son causadas por decisiones arquitectónicas que tomamos o limitaciones imprevistas de nuestra
redes, bases de datos, almacenamiento u otros sistemas.

Nuestro objetivo es escribir y ejecutar pruebas de rendimiento automatizadas que validen nuestro rendimiento
en toda la pila de aplicaciones (código, base de datos, almacenamiento, red, virtualización, etc.) como
parte de la tubería de implementación, por lo que detectamos problemas temprano, cuando las soluciones son más baratas
Y más rápido.

Al comprender cómo se comportan nuestras aplicaciones y entornos bajo una producción

carga, podemos hacer un trabajo mucho mejor en la planificación de la capacidad, así como detectar condiciones tales
como:

Cuando los tiempos de consulta de nuestra base de datos crecen de forma no lineal (por ejemplo, olvidamos activar la base de datos)
indexación, y la carga de la página va de cien minutos a treinta segundos).

Cuando un cambio de código provoca la cantidad de llamadas a la base de datos, uso de almacenamiento o tráfico de red
para aumentar diez veces.

Cuando tenemos pruebas de aceptación que se pueden ejecutar en paralelo, podemos usarlas como
base de nuestras pruebas de rendimiento. Por ejemplo, supongamos que ejecutamos un sitio de comercio electrónico y tenemos
identificó "buscar" y "pagar" como dos operaciones de alto valor que deben funcionar bien
bajo carga Para probar esto, podemos ejecutar miles de pruebas de aceptación de búsqueda paralelas
simultáneamente con miles de pruebas de pago en paralelo.

Debido a la gran cantidad de cómputo y E / S que se requieren para ejecutar pruebas de rendimiento,
crear un entorno de prueba de rendimiento puede ser fácilmente más complejo que crear
entorno de producción para la aplicación en sí. Debido a esto, podemos construir nuestro
entorno de pruebas de rendimiento al comienzo de cualquier proyecto y asegúrese de que nos dediquemos
Cualesquiera recursos sean necesarios para construirlo temprano y correctamente.

Para encontrar problemas de rendimiento temprano, debemos registrar los resultados de rendimiento y evaluar cada
rendimiento contra resultados anteriores. Por ejemplo, podríamos fallar las pruebas de rendimiento
si el rendimiento se desvía más del 2% de la ejecución anterior.

INTEGRAR REQUISITOS NO FUNCIONALES PRUEBAS EN NUESTROS

BANCO DE PRUEBAS

Page 164

Además de probar que nuestro código funciona como está diseñado y funciona bajo
cargas similares a la producción, también queremos validar cualquier otro atributo del sistema que nos importa
acerca de. A menudo se denominan requisitos no funcionales, que incluyen disponibilidad,
escalabilidad, capacidad, seguridad, etc.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 169 de 485
 Muchos de estos requisitos se cumplen mediante la configuración correcta de nuestros entornos,
así que también debemos crear pruebas automatizadas para validar que nuestros entornos se han construido
y configurado correctamente. Por ejemplo, queremos hacer cumplir la coherencia y la corrección
de los siguientes, en los que se basan muchos requisitos no funcionales (por ejemplo, seguridad,
rendimiento, disponibilidad):

Aplicaciones de soporte, bases de datos, bibliotecas, etc.

Intérpretes de idiomas, compiladores, etc.

Sistemas operativos (por ejemplo, registro de auditoría habilitado, etc.)

Todas las dependencias

Cuando usamos la infraestructura como herramientas de gestión de configuración de código (por ejemplo, Puppet, Chef,
Ansible, Salt, Bosh), podemos usar los mismos marcos de prueba que usamos para probar nuestro código para
también compruebe que nuestros entornos están configurados y funcionan correctamente (p. ej., codificación
pruebas ambientales en pruebas de pepino o pepinillo).

Además, similar a cómo ejecutamos herramientas de análisis en nuestra aplicación en nuestro despliegue
tubería (por ejemplo, análisis de código estático, análisis de cobertura de prueba), debemos ejecutar herramientas que analicen
el código que construye nuestros entornos (p. ej., Foodcritic para Chef, puppet-lint para
Marioneta). También deberíamos ejecutar cualquier control de seguridad como parte de nuestras pruebas automatizadas.
para garantizar que todo esté configurado de forma segura y correcta (p. ej., especificaciones del servidor).

En cualquier momento, nuestras pruebas automatizadas pueden validar que tenemos una construcción ecológica y que
Estamos en un estado desplegable. Ahora, debemos crear un cable Andon para que cuando alguien
rompe la tubería de implementación, tomamos todos los pasos necesarios para volver a una construcción ecológica
estado.

TIRE DE NUESTRO CORDÓN ANDON CUANDO EL DESPLIEGUE

ESTANCIAS DE TUBERÍAS

Cuando tenemos una construcción ecológica en nuestra tubería de implementación, tenemos un alto grado de
confianza en que nuestro código y entorno funcionarán según lo diseñado cuando implementemos nuestro
cambios en producción.

Para mantener nuestro canal de implementación en un estado verde, crearemos un Andon virtual
Cordón, similar al físico en el sistema de producción de Toyota. Cuando alguien
introduce un cambio que hace que nuestras compilaciones o pruebas automatizadas fallen, no se permite ningún trabajo nuevo
para ingresar al sistema hasta que se solucione el problema. Y si alguien necesita ayuda para resolver el
problema, pueden traer cualquier ayuda que necesiten, como en el ejemplo de Google en el
comienzo de este capítulo.

Page 165

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 170 de 485
 Cuando nuestra tubería de implementación se rompe, como mínimo, notificamos a todo el equipo de la
falla, por lo que cualquiera puede solucionar el problema o revertir la confirmación. Podemos incluso
configurar el sistema de control de versiones para evitar más confirmaciones de código hasta la primera etapa
(es decir, compilaciones y pruebas unitarias) de la tubería de implementación vuelve a estar en estado verde. Si el
el problema se debió a una prueba automatizada que generó un error falso positivo, la prueba ofensiva
debe reescribirse o eliminarse.††† Todos los miembros del equipo deben estar capacitados
para revertir el compromiso para volver a un estado verde.

Randy Shoup, ex director de ingeniería de Google App Engine, escribió sobre el

importancia de devolver el despliegue a un estado verde. "Priorizamos el equipo
objetivos sobre objetivos individuales: cada vez que ayudamos a alguien a avanzar en su trabajo, ayudamos
todo el equipo Esto se aplica ya sea que ayudemos a alguien a arreglar la compilación o a un automatizado
prueba, o incluso realizar una revisión de código para ellos. Y, por supuesto, sabemos que harán el
lo mismo para nosotros, cuando necesitamos ayuda. Este sistema funcionó sin mucha formalidad o política:
todos sabían que nuestro trabajo no era solo 'escribir código', sino también 'ejecutar un servicio'. Esto es
por qué priorizamos todos los problemas de calidad, especialmente los relacionados con la confiabilidad y el escalado, en
el nivel más alto, tratándolos como problemas de prioridad 0 'show-stopper'. De un sistema
perspectiva, estas prácticas nos impiden deslizarnos hacia atrás ".

Cuando fallan las etapas posteriores de la tubería de implementación, como las pruebas de aceptación o el rendimiento
pruebas, en lugar de detener todo el trabajo nuevo, tendremos desarrolladores y probadores de guardia que están
responsable de solucionar estos problemas de inmediato. También deberían crear nuevas pruebas que
ejecutar en una etapa anterior en la tubería de implementación para detectar cualquier regresión futura. por
ejemplo, si descubrimos un defecto en nuestras pruebas de aceptación, deberíamos escribir una prueba unitaria para detectar
el problema. Del mismo modo, si descubrimos un defecto en las pruebas exploratorias, deberíamos escribir una unidad
o prueba de aceptación.

Para aumentar la visibilidad de las fallas de prueba automatizadas, debemos crear altamente visibles
indicadores para que todo el equipo pueda ver cuándo fallan nuestras pruebas de compilación o automatizadas.
Muchos equipos han creado luces de construcción altamente visibles que se montan en una pared, lo que indica
el estado de compilación actual u otras formas divertidas de decirle al equipo que la compilación está rota, incluyendo
lámparas de lava, reproducción de una muestra de voz o canción, klaxons, semáforos, etc.

En muchos sentidos, este paso es más desafiante que crear nuestras compilaciones y servidores de prueba:
esas eran actividades puramente técnicas, mientras que este paso requiere cambiar el comportamiento humano
e incentivos. Sin embargo, la integración continua y la entrega continua requieren estos
cambios, como exploramos en la siguiente sección.

POR QUÉ NECESITAMOS EXTRAER EL CORDÓN ANDON

La consecuencia de no tirar del cable Andon y arreglar inmediatamente cualquier despliegue
los problemas de la tubería resultan en un problema demasiado familiar donde se vuelve cada vez más difícil
para devolver nuestras aplicaciones y entorno a un estado desplegable. Considera el
siguiente situación:

Alguien registra el código que rompe la compilación o nuestras pruebas automatizadas, pero nadie corrige
eso.

Alguien más registra otro cambio en la construcción rota, que tampoco pasa
nuestras pruebas automatizadas, pero nadie ve los resultados fallidos de las pruebas que habrían permitido

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 171 de 485
Page 166

para ver el nuevo defecto, y mucho menos arreglarlo.

Nuestras pruebas existentes no se ejecutan de manera confiable, por lo que es muy poco probable que creemos nuevas pruebas. (Por qué
¿molestia? Ni siquiera podemos ejecutar las pruebas actuales).

Cuando esto sucede, nuestras implementaciones en cualquier entorno se vuelven tan poco confiables como cuando
no tenía pruebas automatizadas o estaba utilizando un método de cascada, donde la mayoría de nuestros
Se están descubriendo problemas en la producción. El resultado inevitable de este círculo vicioso es
que terminamos donde comenzamos, con una impredecible "fase de estabilización" que lleva
semanas o meses en los que todo nuestro equipo está sumido en una crisis, tratando de hacer que todas nuestras pruebas
aprobar, tomar atajos debido a las presiones de la fecha límite y aumentar nuestra deuda técnica. ‡‡‡

CONCLUSIÓN

En este capítulo, hemos creado un conjunto completo de pruebas automatizadas para confirmar que
tener una construcción verde que todavía está en un estado pasable y desplegable. Hemos organizado nuestra prueba
suites y actividades de prueba en una tubería de implementación. También hemos creado lo cultural
norma de hacer lo que sea necesario para volver a un estado de construcción verde si alguien introduce un
cambio que rompe cualquiera de nuestras pruebas automatizadas.

Al hacer esto, preparamos el escenario para implementar la integración continua, lo que permite
muchos equipos pequeños para desarrollar, probar e implementar código de forma independiente y segura en
producción, entregando valor a los clientes.

† Bland describió que en Google, una de las consecuencias de tener tantos desarrolladores talentosos fue que creó el "síndrome impostor", un término acuñado por
psicólogos para describir informalmente a personas que no pueden internalizar sus logros. Wikipedia afirma que "a pesar de la evidencia externa de su
competencia, quienes exhiben el síndrome siguen convencidos de que son fraudes y no merecen el éxito que han logrado. La prueba de éxito es
descartados como suerte, oportunidad o como resultado de engañar a otros para que piensen que son más inteligentes y competentes de lo que creen ser ".

‡ Crearon programas de capacitación, publicaron el famoso boletín de pruebas en el inodoro (que publicaron en los baños), la hoja de ruta de Test Certified y
programa de certificación, y llevó varios días de "arreglo" (es decir, bombardeos de mejora), que ayudaron a los equipos a mejorar sus procesos de prueba automatizados para que
podría replicar los sorprendentes resultados que el equipo de GWS pudo lograr.

§ En Desarrollo, la integración continua a menudo se refiere a la integración continua de múltiples ramas de código en el tronco y asegurar que pase la unidad

pruebas Sin embargo, en el contexto de la entrega continua y DevOps, la integración continua también exige la ejecución en entornos similares a la producción y
pasando las pruebas de aceptación e integración. Jez Humble y David Farley desambiguan estos llamando al último CI +. En este libro, integración continua
siempre se referirá a las prácticas de CI +.

¶ Si creamos contenedores en nuestra canalización de implementación y tenemos una arquitectura como microservicios, podemos permitir que cada desarrollador cree inmutables
artefactos donde los desarrolladores ensamblan y ejecutan todos los componentes de servicio en un entorno idéntico a la producción en su estación de trabajo. Esto permite
desarrolladores para construir y ejecutar más pruebas en su estación de trabajo en lugar de en servidores de prueba, dándonos comentarios aún más rápidos sobre su trabajo.

** Incluso podemos requerir que estas herramientas se ejecuten antes de que se acepten cambios en el control de versiones (por ejemplo, obtener ganchos de precompromiso). También podemos ejecutar estas herramientas
dentro del entorno de desarrollo integrado del desarrollador (IDE; donde el desarrollador edita, compila y ejecuta código), lo que crea un código aún más rápido
Bucle de retroalimentación.

†† También podemos usar contenedores, como Docker, como mecanismo de embalaje. Los contenedores permiten la capacidad de escribir una vez, ejecutar en cualquier lugar. Estos contenedores
se crean como parte de nuestro proceso de compilación y se pueden implementar y ejecutar rápidamente en cualquier entorno. Porque el mismo contenedor se ejecuta en cada
entorno, ayudamos a reforzar la consistencia de todos nuestros artefactos de construcción.

‡‡ Es exactamente este problema el que condujo al desarrollo de prácticas de integración continua.

§§ Existe una amplia categoría de técnicas arquitectónicas y de prueba utilizadas para manejar los problemas de las pruebas que requieren aportes de puntos de integración externos,
incluidos "talones", "simulacros", "virtualización de servicios", etc. Esto se vuelve aún más importante para las pruebas de aceptación e integración, que colocan
mucha más dependencia de estados externos.

¶¶ Deberíamos hacer esto solo cuando nuestros equipos ya valoran las pruebas automatizadas: este tipo de métrica es fácilmente elegible por desarrolladores y gerentes.

*** Nachi Nagappan, E. Michael Maximilien y Laurie Williams (de Microsoft Research, IBM Almaden Labs y North Carolina State University,
respectivamente) realizó un estudio que mostró que los equipos que utilizan el código TDD produjeron un 60% -90% mejor en términos de densidad de defectos que los equipos que no son TDD, mientras que
demorando solo 15% –35% más.

††† Si el proceso para deshacer el código no es bien conocido, una posible contramedida es programar un par de reversiones programadas , para que pueda ser mejor

documentado

‡‡‡ Esto a veces se denomina antipatrón de caída de Scrum de agua , que se refiere a cuando una organización afirma estar utilizando prácticas similares a las de Agile, pero, en realidad,
Todas las pruebas y la reparación de defectos se realizan al final del proyecto.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 172 de 485
Page 168
167

11 Habilitar y practicar
Integración continua

En el capítulo anterior, creamos el automatizado

prácticas de prueba para garantizar que los desarrolladores se vuelvan rápidos
retroalimentación sobre la calidad de su trabajo. Esto se vuelve parejo
más importante a medida que aumentamos el número de desarrolladores
y la cantidad de ramas en las que trabajan en la versión
controlar.

La capacidad de "ramificarse" en los sistemas de control de versiones era

creado principalmente para permitir a los desarrolladores trabajar en
diferentes partes del sistema de software en paralelo, sin
el riesgo de que los desarrolladores individuales verifiquen cambios que
podría desestabilizar o introducir errores en el tronco
(a veces también llamado maestro o línea principal).†

Sin embargo, a los desarrolladores más largos se les permite trabajar en

sus ramas aisladas, cuanto más difícil se vuelve

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 173 de 485
 para integrar y fusionar los cambios de todos en
maletero. De hecho, integrar esos cambios se convierte en
exponencialmente más difícil a medida que aumentamos el número
de ramas y la cantidad de cambios en cada código
rama.

Los problemas de integración resultan en una cantidad significativa de

volver a trabajar para volver a un estado desplegable, que incluye

Page 169

cambios conflictivos que deben fusionarse manualmente o

fusiones que rompen nuestras pruebas automáticas o manuales,
por lo general requiere que varios desarrolladores tengan éxito
resolver. Y porque la integración ha sido tradicionalmente
hecho al final del proyecto, cuando lleva mucho más tiempo
luego planeado, a menudo nos vemos obligados a cortar esquinas para hacer
La fecha de lanzamiento.

Esto provoca otra espiral descendente: al fusionar

el código es doloroso, tendemos a hacerlo con menos frecuencia, haciendo futuro
se fusiona aún peor. La integración continua fue diseñada
para resolver este problema haciendo que la fusión en el tronco sea
parte del trabajo diario de todos.

La sorprendente variedad de problemas que continúan

la integración resuelve, así como las soluciones mismas,
se ejemplifican en la experiencia de Gary Gruver como el
director de ingeniería para el firmware LaserJet de HP
división, que construye el firmware que ejecuta todos sus
escáneres, impresoras y dispositivos multifunción.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 174 de 485
 El equipo estaba formado por cuatrocientos desarrolladores.
distribuido en los Estados Unidos, Brasil e India. A pesar de la
tamaño de su equipo, se movían demasiado lento. por
años, no pudieron ofrecer nuevas funciones tan rápido
como el negocio lo necesitaba.

Gruver describió el problema de esta manera: "El marketing sería

ven a nosotros con un millón de ideas para deslumbrar a nuestro cliente,
y simplemente les decíamos: 'Fuera de tu lista, elige los dos
cosas que le gustaría obtener en los próximos seis a doce meses ".

Solo estaban completando dos versiones de firmware por

año, con la mayor parte de su tiempo dedicado a portar código

170 de 1189.

para apoyar nuevos productos. Gruver estimó que solo el 5%

dedicaron su tiempo a crear nuevas funciones, el resto de
el tiempo dedicado al trabajo no productivo asociado
con su deuda técnica, como la gestión de múltiples
ramas de código y pruebas manuales, como se muestra a continuación:

20% en planificación detallada (su bajo rendimiento y

los altos plazos de entrega se atribuyeron erróneamente a defectuosos
estimación, y con la esperanza de obtener una mejor respuesta, ellos
se les pidió que estimaran el trabajo con mayor detalle).

25% de código de portabilidad gastado, todo mantenido en separado

ramas de código

10% gastado integrando su código entre desarrolladores

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 175 de 485
 ramas
15% gastado completando pruebas manuales

Gruver y su equipo crearon el objetivo de aumentar el tiempo.

gastado en innovación y nueva funcionalidad por un factor de
diez. El equipo esperaba que este objetivo se pudiera lograr a través de:

Integración continua y desarrollo basado en troncales

Inversión significativa en automatización de pruebas

Creación de un simulador de hardware para que las pruebas puedan ser

correr en una plataforma virtual

La reproducción de fallas de prueba en el desarrollador

estaciones de trabajo

Página 171

Una nueva arquitectura para soportar la ejecución de todas las impresoras

una construcción y lanzamiento común

Antes de esto, cada línea de productos requeriría un nuevo código

rama, con cada modelo con una compilación de firmware única
con capacidades definidas en tiempo de compilación. ‡ El nuevo
arquitectura tendría todos los desarrolladores que trabajan en una
base de código común, con una única versión de firmware
compatible con todos los modelos LaserJet construidos fuera del maletero, con
capacidades de la impresora que se establecen en tiempo de ejecución en un

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 176 de 485
 Archivo de configuración XML.
Cuatro años después, tenían una base de código compatible con todos
veinticuatro líneas de productos HP LaserJet en desarrollo
en el maletero Gruver admite desarrollo basado en troncales
requiere un gran cambio de mentalidad. Los ingenieros pensaron que el tronco
el desarrollo basado nunca funcionaría, pero una vez que
comenzaron, no podían imaginar volver nunca más. Sobre el
años hemos tenido varios ingenieros dejar HP, y ellos
me llamaría para contarme qué tan atrasado
desarrollo estaba en sus nuevas empresas, señalando
cuán difícil es ser efectivo y lanzar un buen código
cuando no hay retroalimentación que la integración continua
les da.

Sin embargo, el desarrollo basado en troncales requería que

construir pruebas automatizadas más efectivas. Gruver observó,
"Sin pruebas automatizadas, la integración continua es
la forma más rápida de obtener un montón de basura que nunca
compila o se ejecuta correctamente ". Al principio, un completo
El ciclo de prueba manual requirió seis semanas.

Page 172

Para que todas las compilaciones de firmware se prueben automáticamente,

invirtieron mucho en sus simuladores de impresoras y
creó una granja de prueba en seis semanas, en pocos años
dos mil simuladores de impresoras corrieron en seis bastidores de
servidores que cargarían las compilaciones de firmware desde su
tubería de despliegue. Su integración continua (CI)

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 177 de 485
 el sistema ejecutó todo su conjunto de unidades automatizadas,
aceptación y pruebas de integración en compilaciones desde troncal,
tal como se describe en el capítulo anterior. Además,
crearon una cultura que detuvo todo el trabajo en cualquier momento
el desarrollador rompió la tubería de implementación, asegurando que
los desarrolladores rápidamente volvieron a poner el sistema en verde
estado.

Las pruebas automatizadas crearon comentarios rápidos que permitieron

desarrolladores para confirmar rápidamente que su código comprometido
En realidad funcionó. Las pruebas unitarias se ejecutarían en su
estaciones de trabajo en minutos, tres niveles de automatizado
las pruebas se ejecutarían en cada confirmación, así como cada dos
y cuatro horas La prueba de regresión completa final sería
corre cada veinticuatro horas. Durante este proceso, ellos:

Redujo la construcción a una construcción por día, eventualmente

haciendo de diez a quince construcciones por día

Pasé de alrededor de veinte confirmaciones por día

realizado por un "jefe de construcción" a más de cien
confirmaciones por día realizadas por desarrolladores individuales

Permitió a los desarrolladores cambiar o agregar líneas de 75k a 100k

de código cada día

Page 173

Reducción de los tiempos de prueba de regresión de seis semanas a uno.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 178 de 485
 día

Este nivel de productividad nunca podría haber sido

compatible antes de adoptar la integración continua,
cuando simplemente crea una construcción verde requiere días de
heroica Los beneficios comerciales resultantes fueron
asombroso:

Tiempo dedicado a impulsar la innovación y escribir nuevos

las características aumentaron del 5% del tiempo de desarrollador al 40%.

Los costos generales de desarrollo se redujeron en

aproximadamente 40%.

Los programas en desarrollo se incrementaron en

alrededor del 140%.

Los costos de desarrollo por programa disminuyeron en

78%

Lo que muestra la experiencia de Gruver es que, después

uso integral del control de versiones, continuo
la integración es una de las prácticas más críticas que
permitir el flujo rápido de trabajo en nuestro flujo de valor, permitiendo
muchos equipos de desarrollo para desarrollar, probar,
y entregar valor. Sin embargo, integración continua
sigue siendo una práctica controvertida. El resto de esto
el capítulo describe las prácticas necesarias para implementar
integración continua, así como cómo superar
objeciones comunes

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 179 de 485
Page 174

DESARROLLO DE LOTE PEQUEÑO Y

QUÉ SUCEDE CUANDO NOS COMPROMETEMOS
CÓDIGO PARA TRONCAR CON FRECUENCIA

Como se describe en los capítulos anteriores, cada vez que cambia

se introducen en el control de versiones que causan nuestra
la tubería de implementación fallará, rápidamente pululamos
problema para solucionarlo, devolviendo nuestra tubería de implementación
en un estado verde Sin embargo, se producen problemas importantes
cuando los desarrolladores trabajan en sucursales privadas de larga duración
(también conocido como "ramas de características"), solo fusionándose
en el tronco esporádicamente, lo que resulta en un gran tamaño de lote de
cambios Como se describe en el ejemplo de HP LaserJet, qué
Los resultados son un caos significativo y un nuevo trabajo para obtener
su código en un estado liberable.

Jeff Atwood, fundador del sitio Stack Overflow y

autor del blog Coding Horror , observa que mientras
hay muchas estrategias de ramificación, todas se pueden poner
en el siguiente espectro:

Optimice la productividad individual: cada

persona soltera en el proyecto trabaja en su propio
sucursal privada. Todos trabajan independientemente y
nadie puede interrumpir el trabajo de nadie más; sin embargo,
fusionarse se convierte en una pesadilla. Colaboración
se vuelve casi cómicamente difícil: el de cada persona
el trabajo tiene que fusionarse minuciosamente con todos
trabajo de otra persona para ver incluso la parte más pequeña de la
Sistema completo.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 180 de 485
175 de 1189.

Optimice la productividad del equipo: todos trabajan

En la misma zona común. No hay ramas
solo una línea recta de desarrollo larga e ininterrumpida.
No hay nada que entender, por lo que los compromisos son
simple, pero cada confirmación puede romper todo el proyecto
y detener todo el progreso.

La observación de Atwood es absolutamente correcta.

precisamente, el esfuerzo requerido para fusionar con éxito
ramas de nuevo juntas aumenta exponencialmente como el
aumento de número de sucursales. El problema no es solo
en la reelaboración que crea este "infierno de fusión", pero también en el
comentarios retrasados ​que recibimos de nuestro despliegue
tubería. Por ejemplo, en lugar de pruebas de rendimiento
contra un sistema totalmente integrado
continuamente, es probable que suceda solo al final de nuestro
proceso.

Además, a medida que aumentamos la tasa de producción de código

A medida que agregamos más desarrolladores, aumentamos la probabilidad
que cualquier cambio impactará a alguien más y
aumentar el número de desarrolladores que se verán afectados
cuando alguien rompe la tubería de implementación.

Aquí hay un último efecto secundario preocupante del gran tamaño de lote
fusiones: cuando la fusión es difícil, nos volvemos menos capaces
y motivado para mejorar y refactorizar nuestro código, porque

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 181 de 485
 Es más probable que las refactorizaciones causen reprocesos para todos
más. Cuando esto sucede, somos más reacios a
modificar el código que tiene dependencias en todo el
codebase, que es (trágicamente) donde podemos tener el
pagos más altos

Page 176

Así es como Ward Cunningham, desarrollador del primer

wiki, describió por primera vez la deuda técnica: cuando no lo hacemos
refactorizar agresivamente nuestra base de código, se vuelve más
difícil de hacer cambios y mantener con el tiempo,
ralentizando la velocidad a la que podemos agregar nuevas funciones.
Resolver este problema fue una de las razones principales
detrás de la creación de integración continua y troncal
prácticas de desarrollo basadas, para optimizar para el equipo
productividad sobre productividad individual.

ADOPTAR BASADO EN TRONCO

PRÁCTICAS DE DESARROLLO

Nuestra contramedida para las fusiones de lotes grandes es

instituir integración continua y basada en troncales
prácticas de desarrollo, donde todos los desarrolladores se registran
su código para troncalizar al menos una vez al día. Código de comprobación
en esto frecuentemente reduce nuestro tamaño de lote al trabajo
realizado por todo nuestro equipo de desarrolladores en un solo día.
Los desarrolladores más frecuentemente registran su código para
tronco, cuanto menor es el tamaño del lote y más cerca estamos de

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 182 de 485
 El ideal teórico del flujo de una sola pieza.

El código frecuente se compromete a troncal significa que podemos ejecutar todos

pruebas automatizadas en nuestro sistema de software en su conjunto y
recibir alertas cuando un cambio rompe alguna otra parte de
la aplicación o interfiere con el trabajo de otro
desarrollador. Y porque podemos detectar problemas de fusión
cuando son pequeños, podemos corregirlos más rápido.

Page 177

Incluso podemos configurar nuestra tubería de implementación para rechazar

cualquier confirmación (por ejemplo, cambios de código o entorno) que
sacarnos de un estado desplegable. Este método se llama
commits cerrados , donde la tubería de implementación primero
confirma que el cambio enviado se realizará correctamente
fusionar, construir como se esperaba y pasar todos los automatizados
pruebas antes de fusionarse realmente en el tronco. Si no, el
se notificará al desarrollador, permitiendo que las correcciones sean
hecho sin afectar a nadie más en el flujo de valor.

La disciplina de los compromisos diarios de código también nos obliga a

dividir nuestro trabajo en trozos más pequeños mientras todavía
manteniendo el tronco en un estado funcional y liberable. Y versión
el control se convierte en un mecanismo integral de cómo el equipo
se comunican entre sí, todos tienen una mejor
comprensión compartida del sistema, conoce el estado
de la tubería de implementación, y pueden ayudarse mutuamente
cuando se rompe Como resultado, logramos mayor calidad y

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 183 de 485
 tiempos de entrega más rápidos.

Una vez implementadas estas prácticas, ahora podemos modificar nuevamente

nuestra definición de "hecho" (adición en negrita): "En el
Al final de cada intervalo de desarrollo, debemos tener
integrado, probado, en funcionamiento y potencialmente enviable
código, demostrado en un entorno de producción,
creado desde el tronco usando un proceso de un clic,
y validado con pruebas automatizadas. "

Adherirse a esta definición revisada de hecho nos ayuda

Garantizar aún más la capacidad de prueba y la capacidad de implementación en curso
del código que estamos produciendo. Al mantener nuestro código en un
estado desplegable, somos capaces de eliminar lo común

Page 178

práctica de tener una prueba separada y una fase de estabilización

Al final del proyecto.

Caso de estudio
Integración continua en Bazaarvoice
(2012)
Ernest Mueller, quien ayudó a diseñar DevOps
transformación en National Instruments, luego ayudó
transformar los procesos de desarrollo y lanzamiento
en Bazaarvoice en 2012. Suministros de Bazaarvoice
contenido generado por el cliente (p. ej., reseñas, calificaciones)
para miles de minoristas, como Best Buy, Nike,
y Walmart

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 184 de 485
 En ese momento, Bazaarvoice tenía $ 120 millones en
ingresos y se estaba preparando para una salida a bolsa. § El
el negocio fue impulsado principalmente por el Bazaarvoice
Aplicación de conversaciones, un Java monolítico
aplicación compuesta por casi cinco millones de líneas de
código que data de 2006, que abarca quince años
mil archivos El servicio se ejecutó en 1.200 servidores.
en cuatro centros de datos y múltiples servicios en la nube
proveedores.

Parcialmente como resultado de cambiar a un Agile

proceso de desarrollo y de dos semanas
intervalos de desarrollo, hubo una tremenda
deseo de aumentar la frecuencia de liberación de su
calendario actual de lanzamiento de producción de diez semanas.
También habían comenzado a desacoplar partes de sus
aplicación monolítica, descomponiéndola en
microservicios

Page 179

Su primer intento de un calendario de lanzamiento de dos semanas

fue en enero de 2012. Mueller observó: "No lo hizo
ir bien. Causó un caos masivo, con cuarenta y cuatro
Incidentes de producción presentados por nuestros clientes. los
La reacción principal de la gerencia fue básicamente
"No volvamos a hacer eso nunca más".

Mueller se hizo cargo de los procesos de lanzamiento en breve

luego, con el objetivo de hacer lanzamientos quincenales

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 185 de 485
 sin causar tiempo de inactividad del cliente. El negocio
objetivos para liberar más frecuentemente incluidos
permitiendo pruebas A / B más rápidas (descritas en el próximo
capítulos) y aumentar el flujo de características en
producción. Mueller identificó tres problemas centrales:

La falta de automatización de prueba hizo que cualquier nivel de prueba

durante los intervalos de dos semanas inadecuados para
prevenir fallas a gran escala.

La estrategia de ramificación de control de versiones permitida

desarrolladores para registrar el nuevo código hasta el
lanzamiento de la producción.

Los equipos que ejecutan microservicios también fueron

realizar lanzamientos independientes, que fueron
a menudo causando problemas durante el lanzamiento del monolito
o viceversa.

Mueller concluyó que el monolítico

Proceso de implementación de la aplicación de conversaciones
necesitaba ser estabilizado, lo que requería continuo
integración. En las seis semanas que siguieron,
los desarrolladores dejaron de hacer trabajos de características para enfocarse

Page 180

en lugar de escribir suites de pruebas automatizadas,

incluyendo pruebas unitarias en JUnit, pruebas de regresión en
Selenio, y obtener una tubería de implementación
corriendo en TeamCity. "Al ejecutar estas pruebas todos los

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 186 de 485
 tiempo, sentimos que podríamos hacer cambios con
cierto nivel de seguridad. Y lo más importante, nosotros
podría encontrar de inmediato cuando alguien rompió
algo, en lugar de descubrirlo solo después de
está en producción ".

También cambiaron a una versión de tronco / rama

modelo, donde cada dos semanas creaban un nuevo
rama de lanzamiento dedicada, sin nuevos compromisos
permitido a esa rama a menos que hubiera una
emergencia: todos los cambios se resolverían
un proceso de cierre de sesión, ya sea por boleto o por equipo
a través de su wiki interno. Esa rama iría
a través de un proceso de control de calidad, que luego sería
promovido a producción.

Las mejoras en la previsibilidad y la calidad de

los lanzamientos fueron sorprendentes:

Lanzamiento de enero de 2012: cuarenta y cuatro clientes

incidentes (comienza el esfuerzo de integración continua)

Versión del 6 de marzo de 2012: cinco días tarde, cinco

incidentes de clientes

Versión del 22 de marzo de 2012: a tiempo, un cliente

incidente

Página 181

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 187 de 485
 Versión del 5 de abril de 2012: a tiempo, cero clientes
incidentes

Mueller describió además el éxito de este esfuerzo.

fue:

Tuvimos tanto éxito con lanzamientos cada

dos semanas, fuimos a lanzamientos semanales,
que casi no requiere cambios de la
equipos de ingenieria. Porque lanzamientos
se volvió tan rutinario, era tan simple como
duplicando el número de lanzamientos en el
calendario y lanzamiento cuando el calendario
nos dijo que lo hiciéramos. En serio, era casi un no
evento. La mayoría de los cambios requeridos fueron
en nuestros equipos de servicio al cliente y marketing,
quien tuvo que cambiar sus procesos, como
cambiando el horario de su semanal
correos electrónicos de clientes para asegurarse de que los clientes
Sabía que vendrían cambios de características.
Después de eso, comenzamos a trabajar hacia nuestro próximo
objetivos, que eventualmente llevaron a acelerar
nuestros tiempos de prueba de más de tres horas a menos
de una hora, reduciendo el número de
entornos de cuatro a tres (Dev, Test,
Producción, eliminación de etapas) y movimiento
a un modelo completo de entrega continua donde
habilite implementaciones rápidas con un solo clic.

CONCLUSIÓN

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 188 de 485
Page 182

El desarrollo basado en troncales es probablemente el más

práctica controvertida discutida en este libro. Muchos
los ingenieros no creerán que es posible, incluso aquellos
que prefieren trabajar sin interrupciones en una sucursal privada
sin tener que lidiar con otros desarrolladores. Sin embargo,
los datos del Informe de estado de DevOps 2015 de Puppet Labs
está claro: el desarrollo basado en troncales predice mayor
rendimiento y mejor estabilidad, y trabajo aún mayor
satisfacción y tasas más bajas de agotamiento.

Si bien convencer a los desarrolladores puede ser difícil al principio,

una vez que vean los beneficios extraordinarios, probablemente
convertirse en conversos de por vida, como el HP LaserJet y
Los ejemplos de Bazaarvoice ilustran. Integración continua
las prácticas preparan el escenario para el siguiente paso, que es
Automatizando el proceso de implementación y habilitando
liberaciones de riesgo.

† La ramificación en el control de versiones se ha usado de muchas maneras, pero generalmente se usa para dividir el trabajo
entre los miembros del equipo por lanzamiento, promoción, tarea, componente, plataformas tecnológicas, etc.
adelante.

‡ Se utilizaron indicadores de compilación (#define y #ifdef) para habilitar / deshabilitar la ejecución del código en presencia de
copiadoras, tamaño de papel compatible, etc.

§ El lanzamiento de la producción se retrasó debido a su (exitosa) OPI.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 189 de 485
Página
Page 184
183

12 Automatizar y habilitar
Lanzamientos de bajo riesgo

Chuck Rossi es el director de ingeniería de lanzamiento en Facebook. Una de sus responsabilidades es

supervisando el empuje diario del código. En 2012, Rossi describió su proceso de la siguiente manera: "Comenzando
alrededor de la 1 p.m., cambio al 'modo de operaciones' y trabajo con mi equipo para prepararme para
lanza los cambios que se enviarán a Facebook.com ese día. Esto es lo más estresante
parte del trabajo y realmente depende en gran medida del juicio y la experiencia pasada de mi equipo. Nosotros
trabaje para asegurarse de que todos los que tienen cambios están siendo contabilizados y estén activamente
probando y apoyando sus cambios ".

Justo antes del impulso de producción, todos los desarrolladores que tengan cambios deben estar presentes.
y verifique en su canal de chat IRC: cualquier desarrollador que no esté presente tendrá sus cambios
eliminado automáticamente del paquete de implementación. Rossi continuó: "Si todo parece
bueno y nuestros paneles de prueba y pruebas canarias† son verdes, presionamos el gran botón rojo y
toda la flota de servidores de Facebook.com recibe el nuevo código. Dentro de veinte minutos,
miles y miles de máquinas tienen un nuevo código sin impacto visible para el
personas que usan el sitio ". ‡

Más tarde ese año, Rossi duplicó su frecuencia de lanzamiento de software a dos veces al día. Él explicó
que el segundo impulso de código le dio a los ingenieros que no están en la costa oeste de los Estados Unidos la capacidad de "moverse
y enviar tan rápido como cualquier otro ingeniero en la empresa ", y también les dio a todos un segundo
oportunidad cada día para enviar código y lanzar funciones.

https://translate.googleusercontent.com/translate_f 06/03/20 13:31

Página 190 de 485
 Figura 16: Número de desarrolladores que implementan por semana en Facebook
(Fuente: Chuck Rossi, "Enviar temprano y enviar dos veces más seguido")

Kent Beck, el creador de la metodología Extreme Programming, una de las principales

Los defensores de Test Driven Development, y el entrenador técnico en Facebook, además

Page 185

comentarios sobre su estrategia de lanzamiento de código en un artículo publicado en su página de Facebook:

"Chuck Rossi hizo la observación de que parece haber un número fijo de cambios
Facebook puede manejar en una sola implementación. Si queremos más cambios, necesitamos más
despliegues Esto ha llevado a un aumento constante en el ritmo de implementación en los últimos cinco años,
desde implementaciones semanales a diarias hasta tres veces diarias de nuestro código PHP y de seis a cuatro para
ciclos de dos semanas para implementar nuestras aplicaciones móviles. Esta mejora ha sido impulsada
principalmente por el equipo de ingeniería de lanzamiento ".

Al usar la integración continua y hacer que la implementación del código sea un proceso de bajo riesgo, Facebook
ha permitido que el despliegue de código sea parte del trabajo diario de todos y sostenga al desarrollador
productividad. Esto requiere que la implementación del código sea automatizada, repetible y
previsible. En las prácticas descritas en el libro hasta ahora, a pesar de que nuestro código y
los entornos se han probado juntos, lo más probable es que no estemos implementando