DevOps

tightly: estrechamente
driven: impulsado, manejar, empujar, dirigir
certain: cierto, certero, exacto
although: a pesar de que, aunque, bien que
yet: aún, todavía, a pesar de
migrate: emigrar
announce: anunciar, comunicar, declarar, avisar
ravens: cuervos, devorar, raptar
misleading: engañoso, erróneo
still: todavía, aún
brings: traer, llevar, provocar, producir
together: juntos, a la vez
once: una vez, antes
reach: alcanzar

Es un proceso para desarrollar, entregar y operar Software.

Algunas definiciones impulsadas comercialmente de DevOps unen estrechamente a

DevOps con ciertas herramientas de compilación y entrega o plataformas de
infraestructura en la nube.
Algunas definiciones impulsadas comercialmente de DevOps unen estrechamente a
DevOps con ciertas herramientas de compilación y entrega o plataformas de
infraestructura en la nube.
Aunque estas herramientas y plataformas podrían ser realmente útiles para lograr
sus objetivos de TI y de organización con DevOps, realmente no puede conectar
otra herramienta (que generalmente no tiene mucho control sobre ella porque no la
ha escrito) o no puede migrar sus aplicaciones de software a plataformas de
computación en la nube y luego anunciar que usted y su organización ahora
entregan con DevOps.

Otra variante engañosa, pero aún mejor para definir DevOps es ver a DevOps como
una intersección de trabajo y personas en una organización de TI que reúne a
desarrolladores de software, evaluadores de software e ingenieros de operaciones
de producción de software. Dicho esto, una vez que llegas al final de este libro, no
puedes evitar ver qué tan seca es esta definición.

El mejor enfoque para definir DevOps es asemejarse a DevOps en marcos de

desarrollo de software ágil iterativo y mejora de procesos como Scrum, Lean, ITIL,
IDEAL (Iniciar, Definir, Establecer, Actuar y Aprender) y Six Sigma DMAIC (Definir,
Medir, Analizar, Mejora y control).
Aunque Agile Scrum, Lean, ITIL, IDEAL y Six Sigma DMAIC pueden servir como
habilitadores eficientes para DevOps, DevOps no pretende ser visto como un
superconjunto mejorado y combinado de estas metodologías y técnicas. El
razonamiento muy simple detrás de este hecho es que ninguna de estas
metodologías y marcos, excepto Agile Scrum, se han introducido para resolver
específicamente los problemas y servir para la industria del software.

Muchas prácticas y principios de DevOps se han derivado de Lean Movement

después de haber sido adaptados, experimentados, validados y ajustados para el
desarrollo, la entrega y las operaciones de software. Además, DevOps tomó
prestadas y adaptó muchas técnicas y filosofías del movimiento de entrega
continua, el kata de mejora de Toyota, la teoría de restricciones, el manifiesto ágil y
la infraestructura ágil.

Lean Movement
El Lean Movement puede resumirse por siete principios:
1. Usted ve el todo y crea valor para el cliente con el pensamiento sistémico.
2. Construyes la calidad, creas flujo y tiras.(en lugar de empujar).
3. Usted entrega lo más rápido posible (cortos plazos de entrega para convertir
materias primas en productos terminados, o en términos de software para
convertir ideas en ejecución en beneficios y características en sistemas de
producción).
4. Amplificas el aprendizaje y adaptas el pensamiento científico.
5. Empoderas a tu equipo, lideras con humildad y respetas a cada individuo.
6. Elimina el desperdicio (herramientas, sistemas, lo que es más importante, el
tiempo que puede dedicar a actividades improductivas).
7. Tú decides lo más tarde posible (das decisiones a tiempo).

Continuous Delivery Movement

brick: bloque
promote: promover
block: obstruir, bloquear

deployment pipeline es el conjunto de instrucciones que haces para pasar el

codigo que se tiene de algun proyecto a un software que el usuario final pueda
usar
Puede habilitar la entrega continua a través de la canalización de implementación.
El canal de implementación tiene tres misiones importantes: visibilidad,
retroalimentación y despliegue continuo.

● Visibilidad - Todos los miembros de su equipo y otros equipos hacen visibles

todos los aspectos del sistema de entrega, incluyendo la creación,
implementación, prueba y liberación, por lo que promueve la colaboración en
su equipo y ofrece transparencia a sus clientes y partes interesadas.
● FeedBack: Usted y los miembros de su equipo aprenden sobre los problemas
tan pronto como ocurren, de modo que puede solucionarlos rápidamente
antes de colocar otro ladrillo en un bloque ya colapsado.
● Continuous Deployment: Usted implementa y lanza cualquier versión del
software en cualquier entorno, incluidos los entornos de prueba y producción
a través de un proceso completamente automatizado.

Mejora de Toyota Kata

(​Una kata es un patrón que repites continuamente de forma deliberada
para generar memoria muscular y poder realizarlos casi sin pensar. Por
ejemplo en la película, Daniel-san repetía ese movimiento (encerar y
pulir) para tenerlos interiorizados y poder utilizarlos en la pelea de
karate de forma natural, casi automática.
Entonces en Toyota Kata, tanto el IK como el CK son patrones que
repetimos para generar una memoria muscular de mejora.
)
[Link]
ejora-continua
grasp: Agarrar, captar
approaches: enfoque
attempted: intento
focus: enfocar, concentrar
strive: esforzar
current: hoy en día
target, aim: objetivo
toward: hacia
improvement: mejora
reached: alcanzado
meant: significar, decir
sort: ordenar, clasificar
Utiliza el kata de mejora de Toyota como una rutina para pasar de la situación actual
a una nueva situación de una manera creativa, dirigida y significativa. Se basa en un
modelo de cuatro partes:

1. En su consideración de una visión más amplia o dirección mejorada…

2. Captas las condiciones actuales.
3. A continuación, se definen las siguientes condiciones de destino.
4. En última instancia, intenta de manera continua e iterativa avanzar hacia esa
condición objetivo. A lo largo de esta ruta, descubrirás los obstáculos en los
que hay que trabajar y los clasificarás.
En contraste con otros enfoques de mejora que intentó predecir la ruta y el enfoque
en la implementación, con los kata de mejora de Toyota que aprende y construye
sobre el descubrimiento que se produce en el camino. Tú y tus equipos usan el kata
de mejora de Toyota para aprender mientras te esfuerzas por alcanzar una
condición objetivo y te adaptas en función de lo que estás aprendiendo.

Teoría de las Restricciones:

ongoing: En marcha
whereas: mientras
still: todavía, aún
risk: riesgo
release: lanzamiento
enough: suficiente
ensure: seguro
En una organización, incluida la suya, que ofrece cualquier tipo de software, siempre
existe un conflicto continuo entre su TI y su negocio. Responde rápidamente a las
necesidades del negocio, mientras que asegurar que los entornos de producción
sean estables y predecibles es un compromiso continuo que enfrenta tu TI.
Suponiendo que ya está completamente consciente de que no existe un
lanzamiento de producción de riesgo, en un sistema complejo como el suyo, no
puede ser lo suficientemente rápido si desea garantizar un lanzamiento de
producción de bajo riesgo. Y no puede garantizar un lanzamiento de bajo riesgo si
desea liberar rápidamente su código a sus sistemas de producción.

Usted se enfrenta a este conflicto cuando:

 ● Divide su organización de TI en muchos equipos pequeños, autónomos,
independientes, autosuficientes y altamente colaborativos (debe comenzar a
ver a sus equipos como "unidades inteligentes" con misión).
● Reduce el tamaño de su lote (el tamaño de su trabajo en progreso) dado a
cada equipo.
● Reduce su tiempo de entrega (tiempo requerido para convertir ideas y
requisitos en beneficios y funciones de ejecución en sistemas de producción).
● Usted construye ciclos de retroalimentación más rápidos, confiables y
continuos para asegurar la preparación para la implementación.

Manifiesto Ágil
cornerstones: pilares, piedras angulares
processes: procesos
adhere: adherirse
over: por encima
Con DevOps te adhieres a los pilares definidos por el manifiesto ágil:
● Respetas a los individuos y las interacciones sobre los procesos y
herramientas.
● Usted respeta el funcionamiento del software sobre la documentación
completa.
● Respetas la colaboración del cliente sobre los términos del contrato.
● Respetas la respuesta al cambio siguiendo un plan.

Infraestructura ágil
relying: confiar
Therefore: por lo tanto
reward: recompensa, premio, gratificación

Nuestras organizaciones grandes y pequeñas, incluso las suyas dependen de

infraestructuras en la nube híbrida, Combinando nube pública y privada con
servidores dedicados Por lo tanto, se recogen las recompensas de Seguridad de
colocación en combinación con la flexibilidad y escalabilidad de la nube pública.

Aquí hay algunos de los principales impulsores de por qué una infraestructura ágil
es beneficioso para DevOps:
● Usted paga por lo que usa con transparencia y precios simples.
● Puede aprovisionar y desaprovisionar rápidamente su Entornos de prueba y
producción a partir de su código base (IaC - Infraestructura como código).
● Tienes flexibilidad arquitectónica.
● Puedes expandir fácilmente otras geografías.
 ● Probablemente tengas mejor seguridad.
● Sigues cumpliendo con las auditorías y los costos adicionales.

CONCLUSIÓN
caveat: advertencia
practitioners: practicantes
stick: pegarse
stone: piedra
dictate: dictar, mandar
En esta sección te explicamos qué es DevOps y lo que no es Para ti también hemos
cubierto la mayor parte movimientos y principios que DevOps era derivado.

Una pequeña advertencia: como muchos practicantes ágiles como muchos

practicantes ágiles han estado haciendo lamentablemente en sus prácticas ágiles
desde hace años, no debe apegarse a ninguna definición de DevOps en piedra para
dictar cómo debe su organización en particular, su producto, su servicio y, lo más
importante, su equipo utilizar DevOps. No hay una solución única para todos. Ni en
ágil ni en DevOps.
Nunca olvides que se trata de aprender, de experimentar y adaptarse. Como
DevOps hará un gran trabajo para nosotros, es nuestro deber principal como
mentes humanas identificar nuestra versión y el tono(clase) correcta de DevOps.
Esto es lo que cada organización DevOps exitosa incluyendo Google, Amazon,
Facebook, Netflix y Apple lo han estado haciendo.

¿Cuáles son sus problemas en TI sin DevOps?

assurance: garantía, seguridad
readiness: preparación, disponibilidad
audits: auditorias, revisión
conducted: conducir, dirigir
roll-out: desenrollar
stage: etapa, escenario
flaws: fallas
yield: rendimiento, productividad
reactified: rectificado
tired: cansado
silos:
lack: ausencia

En su mundo de TI sin DevOps, los equipos de desarrollo y operaciones suelen

entrar en conflicto. La garantía de calidad de extremo a extremo de las
características y beneficios requeridos por el cliente comienza por primera vez
después de que el equipo de desarrollo comienza a trabajar en un proyecto
completamente diferente. La seguridad de la información y las auditorías de
preparación para la producción se llevan a cabo el día antes del despliegue a
producción planificado. Resolver problemas de software en esta etapa crítica del
proyecto, especialmente los defectos de diseño y seguridad que ya deben haberse
identificado y rectificado hace 8 meses, no solo presenta desafíos para la
continuidad exitosa de su TI, sino también para la continuidad de su negocio. Los
desarrolladores cansados, las operaciones no cooperativas, las pruebas y los silos
de seguridad de la información, los gerentes de proyectos y productos exigentes
pero desesperados, los ejecutivos enojados y los clientes frustrados y las partes
interesadas de TI realmente no agregan mucho valor agregado.

Demasiado intercambio de actividades y dependencias en todas las direcciones

posbiles, innumerable descoordinación, manuales y trabajo no transparente en su
departamento de TI es solo otro día más en el negocio.
A pesar de los largos plazos de entrega para realizar cualquier trabajo, no hay una
mejor opción disponible, al menos no por ahora, y sabe que todavía necesita este
trabajo para ganar dinero.

Finalmente llega el gran día. Después de una implementación de producción

problemática y caótica que causó un tiempo de inactividad significativo en su
empresa, se pregunta si su implementación rompió algo en la funcionalidad de
producción existente. Empieza a pensar en la falta de claridad y en la evidencia
tangible de lo que realmente sucedió y lo que realmente se ha visto afectado en sus
sistemas de producción.

Y, sin embargo, la celebración de Go-Live ya comienza en los pasillos de su gran

sala de TI. También es hora de tomar una copa y recuperarse mentalmente de la
noche dura y sin sueño que dejó atrás. Lo que rompiste anoche en tu producción
será de todos modos el problema de alguien más. Esto no es un gran problema ...

Habiendo dicho eso, ahora debes estar preguntándote cómo es posible que estos
proyectos difíciles puedan terminar de una u otra manera, aunque alguna vez hayan
estado realmente en una forma fea y desesperada. La respuesta está en el teorema
del mono infinito. En pocas palabras, el teorema del mono infinito establece que un
mono que toca teclas al azar en un teclado de máquina de escribir durante un
tiempo infinito seguramente escribirá un texto determinado, como las obras
completas de William Shakespeare. Esto no es una broma.
De manera similar, más allá de cualquier previsibilidad acerca de cuándo puede
terminar el trabajo, siempre que su equipo de TI demore lo suficiente y gane tiempo
para un proyecto determinado, seguramente lo entregará.

Conflicto crónico entre desarrollo y operaciones

Entre muchas otras responsabilidades clave, hay dos misiones principales en su

organización de TI:
● Su equipo de desarrollo debe responder rápidamente a las demandas
cambiantes de sus clientes y del mercado al que sirve su empresa.
● Su equipo de operaciones debe garantizar un servicio estable, predecible,
seguro y continuo para servir a sus clientes y al mercado.

Dado que su organización de TI está estructurada de esta manera, sus equipos de

desarrollo y operaciones tienen misiones y motivaciones en conflicto. Este conflicto
reduce productividad, calidad de servicio, satisfacción al cliente y los resultados de
su departamento de TI, finalmente, el rendimiento general de su negocio.

Ahora estás en deuda técnica

La lucha contra incendios continua, las soluciones alternativas y las actividades no

planificadas para salvar su día solo resultarán en la acumulación de más deuda
técnica. Esto no solo afecta el rendimiento de su desarrollo y operaciones, sino que
también afecta negativamente a todas las demás unidades, incluida su arquitectura,
seguridad de la información, pruebas, gestión de productos, gestión de
lanzamientos y sus partes interesadas de negocios.

Puede parecerse a la deuda técnica en deuda financiera.

Cuanta más deuda financiera tenga, menos opciones tendrá para alcanzar los
objetivos deseados. En última instancia, es casi imposible tomar la decisión correcta
para alcanzar los resultados deseados y es más probable que usted obtenga una
deuda financiera adicional.

La deuda técnica no tiene diferencia. Cuanta más deuda técnica tenga, menos
opciones tendrá para crear y entregar soluciones correctas. Finalmente, terminas
construyendo soluciones en la parte superior de las soluciones, castillo de naipes en
el castillo de naipes. Y es cuestión de tiempo antes de que todos colapsen. Ya lo
sabes.
Su negocio gana de los sistemas más frágiles

Un hecho no sorprendente pero preocupante de su negocio es que sus sistemas

más críticos y generadores de ingresos son los más propensos a errores, caídas y
tiempos de inactividad.
Estos sistemas generalmente están en el centro de su negocio y aún no ha
participado en una reunión en la que no forman parte de las discusiones. Son los
sistemas más críticos impactados por casi todos los proyectos. Debido a la
gravedad de su negocio, merecen un trabajo continuo, cambios urgentes,
soluciones no planificadas y, sin embargo, estos sistemas nunca están cansados ​de
producir incidentes de Prioridad-1.

Si rompes una promesa luego te comprometes a cosas más grandes/difíciles

A medida que su organización de TI rompe constantemente las promesas y frustra a

sus partes interesadas, éstas se vuelven más exigentes para compensar el pasado.
Usted y sus líderes a menudo no dicen nada, pero "por qué no", a menos que haya
una oferta de trabajo mejor alineada.
Entonces a sus organizaciones de desarrollo y entrega de software se les asigna un
desafío mayor de lo habitual. Como sus sistemas críticos y su arquitectura de TI ni
siquiera están cerca para cubrir estos requisitos en determinados plazos "urgentes",
usted establece el diseño de sus nuevas soluciones en la parte superior de su
conjunto de soluciones existentes.

No tienes más diversión en el trabajo

Y finalmente todos se ponen un poco más ocupados. Su calendario no tiene más

espacio libre para realizar una hora de trabajo ininterrumpido para el puesto que le
contrataron y pagaron. Los correos electrónicos caen en su bandeja de entrada, por
lo que ahora está utilizando en su mayoría tiempo improductivo en sus reuniones
para limpiar y escanear sus correos electrónicos entrantes, en su mayoría inciertos y
sin sentido. Tiene curiosidad por saber por qué no hay capacitación obligatoria en su
organización para enseñar cómo usar y escribir correos electrónicos.

Por lo general, depende de otros equipos para poder continuar su propio trabajo. Y,
sin embargo, las expectativas que comunicó hace un par de semanas ni siquiera
están en el radar del otro equipo, ya que acaban de comenzar su nuevo proyecto
"Horizon 2400" mientras tenían que resolver 9 incidentes de Prioridad-1 causados
​por sus aplicaciones de software frágiles.
Poco a poco se siente impaciente porque necesita algunas respuestas de su punto
de contacto único designado en el otro equipo para comenzar su propio trabajo.

No pudo detenerse y envió otro correo electrónico para recordarle su solicitud. Esta
vez puso a su jefe en CC y pensó que debería haber hecho esto cuando envió su
solicitud por primera vez.

Aún no han pasado un par de segundos y dos notificaciones fuera de la oficina

aparecieron en tu pantalla.
Su único punto de contacto en el otro equipo estará en los talleres "Horizon 2400"
hasta el final de esta semana. Y su jefe está enfermo en casa hoy.

CONCLUSIÓN

En este capítulo explicamos los desafíos que enfrentan la mayoría de las empresas
y los profesionales de TI. Lo malo y ciclos viciosos con los que tienen que vivir.
Como podría haber sido claro para usted hasta este punto, este nivel de desperdicio
en una profesión altamente cognitiva, como la tecnología de la información, no es
trivial de comprender.

Gartner estima que las empresas de todo el mundo pierden anualmente unos 600
mil millones de dólares por trabajos de mantenimiento de TI no presupuestados y no
programados para mantener en funcionamiento los sistemas de TI que generan
ingresos. Solo para expresar este número con dígitos para ver cómo se ve: $
600,000,000,000.-

Como podría haber sido claro para usted hasta este punto, este nivel de desperdicio
en una profesión altamente cognitiva, como la tecnología de la información, no es
trivial de comprender.

Este es un buen desafío para enfrentar. DevOps tiene algunas respuestas para
algunas compañías y puede ser para su compañía también. Por supuesto, si su
empresa está lista para experimentar, aprender y adaptarse.

¿Cómo resuelve DevOps su problemas en TI?

Continuamente implementas

Compañías desde las que recien empiezan hasta las más grandes con cualquier
tipo de producto de software han demostrado que: Con DevOps, sus equipos
independientes, pequeños y autosuficientes entregan decenas de implementaciones
de producción todos los días. Usted diseña, construye, entrega y prueba en
entornos similares a la producción. Ya no liberas tu código a tus sistemas de
producción cada tres meses después de la medianoche, mientras todos los demás
duermen. Usted libera su código muchas veces al día y, lo que es más importante,
durante sus horas de trabajo habituales, mientras que sus clientes y el mercado al
que presta servicios aún disfrutan y obtienen los beneficios de su software.

DevOps no solo le permite entregar con frecuencia pequeñas funciones de software,

sino que, además, con la ayuda de las técnicas de DevOps Dark Launch(​es un
proceso en el que el software se lanza de forma gradual o sigilosa a los consumidores
para obtener comentarios de los usuarios y prueba de rendimiento​), con frecuencia
puede entregar pequeñas piezas de funciones de software gigantes de gran
volumen a su producción. Estas piezas pequeñas esperan en modo inactivo
(inactivo) en su producción hasta que active la función gigante desde un ajuste de
configuración. Incluso solo esta pequeña técnica puede mejorar significativamente la
calidad de vida de su equipo al evitar el despliegue del código Big Bang y sus
efectos adversos imprevisibles en sus sistemas de producción existentes, caos y
señalamiento en su organización.

Organizas tus equipos en torno a tu misión

Para servir a su mercado, como a su organización tienen una misión más grande
que la de sus competidores, usted organiza su departamento de TI con equipos a
largo plazo alrededor de sus productos, servicios, capacidades y microservicios de
servicio al cliente (clientes internos o externos).
En lugar de equipos de proyectos temporales que se disuelven tan pronto o incluso
antes de terminar los proyectos.

Con el modelo de equipos de proyectos temporales, los miembros individuales del

proyecto no tienen la propiedad adecuada de sus propias contribuciones porque
rara vez saben dónde se encuentra su proyecto en la gran misión de su
organización ni reciben comentarios sobre su trabajo. Su trabajo se dirige
constantemente a ellos en su área de experiencia (desarrollador de base de datos,
diseñador de aplicaciones para usuario, traductor, etc.) de varios proyectos
diferentes, y viven en un mundo de interrupciones continuas.

Con el modelo de equipos a largo plazo, sus equipos voluntariamente tienen la

propiedad de su trabajo y del rendimiento de TI. Están totalmente conscientes de
dónde están sus contribuciones y de cuán importantes son en la gran misión de su
organización.
Construyes sistemas para alcanzar tus objetivos comerciales

Usted y sus equipos son plenamente conscientes de que se les paga para atender a
sus clientes y cumplir la misión de su organización. Por lo tanto, usted es
respetuoso con el tiempo y los recursos de su organización y sus clientes. Antes de
realizar un proyecto a largo plazo, pruebe y valide el valor comercial propuesto y
previsto que espera de su solución de TI. Le muestra a sus clientes los modelos,
prototipos, diversas variaciones A/B o versiones ligeras de lo que pretende construir.
Luego, mide y registra sus reacciones y comentarios para comprender cómo ajustas
tu producto y servicio, y si a tus clientes les gusta.

No agrega funciones a su producto solo porque tiene un buen presentimiento sobre

ellos. Pruebas tus ideas y construyes evidencia tangible, demostrable y reproducible
de que lo que estás construyendo e invirtiendo los recursos de tu organización
probablemente agregará la línea de fondo y diferenciará positivamente a tu
empleador de sus competidores.

Usted crea con calidad y monitoreo incorporados

Crea bucles de retroalimentación rápidos, confiables y amplificados en todas las

etapas de la entrega de software y el ciclo de vida de las operaciones. Debido a que
la calidad no es un monopolio que pertenece a un determinado equipo, todos se
esfuerzan por lograr una calidad integrada. Para asegurarse de que ha hecho su
trabajo correctamente, no espere recibir comentarios de otro equipo. O no le pide
permiso a otra persona para implementar su código en producción. Confía en su
equipo con revisiones de su diseño, código, prueba e infraestructura.

Siempre se construyen pruebas de automatización y monitoreo (telemetría) para

cada característica que se pueda medir y probar. Es consciente de que si una
función merece su tiempo para ser codificada y entregada, también merece pruebas
continuas, confiables, rápidas y consistentes con la automatización de pruebas.
Además, también merece un monitoreo continuo y analíticas integradas en su
software para validar lo que gana con esta función y por qué lo construyó en primer
lugar. En todos los ambientes incluyendo producción y no producción.

Cada registro en su repositorio de código se adapta, reestructura o, si es necesario,

reconstruye sus entornos operativos, reconstruye automáticamente las aplicaciones
afectadas y, en última instancia, ejecuta todas las pruebas automatizadas para
validar las funciones existentes y el propósito de su último registro. Una vez que la
validación es exitosa, los mismos cambios se adaptan automáticamente a su
producción.
Sus analíticas y telemetría integradas en sus aplicaciones monitorean y registran
continuamente eventos clave en su software y en sus entornos operativos. Las
métricas clave (como el número de pedidos, el número de inicios de sesión, el uso
de la CPU, el uso de la RAM, la carga de la CPU, el número de errores, la longitud
de las consultas de la base de datos y muchos otros) se registran y presentan
continuamente en tiempo real, por lo que es en cuestión de minutos, si no
segundos, antes de que su equipo descubra un impacto negativo provocado por una
implementación. Esta es la razón por la cual los ciclos rápidos de retroalimentación
son vitales para hacer su trabajo rápidamente.

Gracias a los errores que aprendes y enseñas

Si se produce un error, resuélvelo con calma y confianza.

Usted identifica la causa raíz de un incidente al confiar en la evidencia científica
obtenida y observada en sus pruebas automatizadas y telemetría. Si identifica un
caso de prueba faltante o una telemetría faltante después de la resolución del
problema, agréguelos al repositorio de código junto con su solución.

En un sistema complejo como el suyo, ninguna persona puede saberlo y preverlo

todo. Por lo tanto, todos en su organización creen que los errores no son malas
sorpresas, pero son parte del proceso de madurez de sus productos y servicios. Los
errores son oportunidades para aprender y crecer. Usted y su organización conciben
los errores como un medio de nuevos aprendizajes personales y organizacionales.

Las autopsias de errores sin errores también le permitirán identificar aún mejor las
causas de los incidentes y descubrir técnicas para evitar errores similares y
similares en el futuro. Gracias a su incidente, ahora convierte sus aprendizajes
locales de su equipo y software en la memoria de la organización que servirá a
todos en su organización.

Usted y su equipo nunca son castigados por este error, pero se le otorga debido a
las lecciones que aprendió y compartió después de este incidente. Gracias a su
contribución, muchos equipos de su organización saben cómo evitar este tipo de
incidente en el futuro.

Sus equipos se escalan aún mejor mientras su negocio se hace más grande

Ahora imagine una organización promedio que evolucione de 1 a 1,000

desarrolladores. Como la organización era pequeña, los desarrolladores
continuamente construían y desplegaban su código en producción. Sin embargo, a
medida que la organización crece, ahora hay una jerarquía organizativa y
burocrática mucho más grande, más miedo a los errores. Ahora hay más esfuerzo
de coordinación y comunicación requerido para implementar su código en
producción. Por lo tanto, la cantidad promedio de implementaciones de código por
día por desarrollador generalmente se reduce y, en el mejor de los casos, se
mantiene igual a medida que las organizaciones crecen.

Sin embargo, los de alto rendimiento de DevOps juegan en una liga diferente y
logran aumentar el número promedio de implementaciones de código por día por
desarrollador ya que tienen más desarrolladores. Con la arquitectura de software
correcta, los equipos correctos, la misión correcta, el liderazgo correcto y la cultura
correcta, los empleados de alto rendimiento de DevOps como Google, Amazon,
Facebook, Netflix y Apple ya han demostrado que esto es posible. Su organización
puede ser la siguiente en convertirse en uno de estos DevOps High Performers.

Conclusión
Las organizaciones DevOps de alto rendimiento superan a sus rivales en las
siguientes dimensiones.
● Implementaciones de código 46 veces más frecuentes.
● 440 veces más rápido que el compromiso de despliegue.
● 96 veces más rápido que el tiempo medio para recuperarse del tiempo de
inactividad.
 ● Tasa de fallos de cambio 5 veces menor (lo que significa que los cambios son
1/5 de probabilidad de fallar).
● Mejora de la productividad y el rendimiento.
● Código mejorado y confiabilidad operacional.
● Mejora el desempeño organizacional y la satisfacción del cliente.
● Mejor penetración en el mercado, participación de mercado y rentabilidad de
la organización (2 veces más probabilidades de lograr).
● Mejora del crecimiento de la capitalización de mercado.

¿Cómo debería iniciar DevOps en tu organización?

La forma en que comience su viaje DevOps en su organización determinará el éxito

de su iniciativa DevOps. Por lo tanto, obtengamos lo mejor de su primer disparo y,
probablemente, de un solo disparo.

Comienza pequeño y evita el Big Bang

Como ya sabe, realmente no puede cambiar el status quo de una sola vez y
anunciar una transformación de DevOps organizativa el primer día. Primero debe
identificar los equipos que abordan continuamente con problemas y objetivos no
alcanzados. Los equipos que son definitivamente conscientes de la necesidad de
mejoras y que son los más receptivos a considerar una forma diferente de trabajar.
Y equipos que están incondicionalmente dispuestos a servir a su organización y
clientes.

Demostrar ganancias rápidas y tempranas

Su misión es demostrar ganancias rápidas y tempranas de su iniciativa DevOps y
demostrar a los escépticos y detractores los problemas que resuelve y el valor que
crea con DevOps. Y luego, replicará paso a paso estas mejoras en las otras áreas
de su organización.

Esto es más o menos así como un fabricante líder de ERP, CRM y SaaS de
Alemania organizó su viaje DevOps. Su equipo de mantenimiento estaba realizando
una sola entrega por año, lo que resultó rápidamente en una acumulación de código
no publicado en varias sucursales de códigos de incidentes diferentes. Esto hizo
que para ellos fuera extremadamente difícil fusionar su código y lanzar versiones de
mantenimiento completamente probadas y confiables.

Su equipo de desarrollo de mantenimiento se combinó por primera vez con la

planificación de la entrega de mantenimiento, el control de calidad y los equipos de
gestión de entornos operativos. También comenzaron a utilizar un sistema conjunto
de gestión de tareas y tickets para simplificar los esfuerzos de coordinación y
comunicación. Luego parten mensualmente y poco después de los lanzamientos de
dos semanas.

En el primer año de esta nueva práctica en grupo de mantenimiento, el equipo logró

resolver 6 veces más incidentes en comparación con el año anterior.
Tan importante como eso, la proporción de incidentes reabiertos y retrabajo
asociado se redujo de 39% a 4%.

Después de haber tenido esta mejora significativa y métricas de mejora

demostrables en el bolsillo, una pequeña iniciativa DevOps ganó un gran apoyo y
credibilidad en la organización y patrocinio ejecutivo para la expansión a otros
equipos de productos y servicios.

Identificar un producto y servicio Greenfield o BrownField apropiado

Otra consideración para comenzar con su iniciativa DevOps es si debe elegir un

producto y servicio de Greenfield o Brownfield.

Un producto y servicio greenfield es nuevo en su organización. Por lo tanto, lo mejor

para usted es crear un equipo nuevo e independiente que trabaje de manera
aislada, especialmente mientras comienza. Gracias a este aislamiento, los
miembros de su equipo tendrán una mejor oportunidad de romper el status quo
existente y pensar fuera de la caja. Además, se espera que su equipo sea menos
interrumpido debido a sus responsabilidades anteriores en la organización. Le
asigna a su nuevo equipo de DevOps métricas y resultados tangibles de rendimiento
empresarial y de TI, tales como mejores ventas, mayor compromiso con el cliente o
menor tiempo de entrega, etc. Dado que su iniciativa Greenfield DevOps no se basa
en el código y las dependencias heredadas, plantea menos riesgos para usted y su
equipo para iniciar una exitosa iniciativa DevOps. Sin embargo, su éxito será menos
impactante en su organización, ya que su iniciativa DevOps en greenfield no
probará si DevOps puede resolver los problemas existentes en su organización y si
su éxito también puede replicarse en otras áreas.
Por otro lado, también puede comenzar su viaje con DevOps con un producto y
servicio brownfield. Muchos productos y servicios de Brownfield ya se ejecutan en
sus sistemas de producción y sirven a su empresa y clientes. Si usted es del mismo
planeta que nosotros, es muy probable que su aplicación de software de Brownfield
tenga una deuda técnica significativa y no tenga una automatización de pruebas
confiable. Debido a esta naturaleza, comenzar su iniciativa DevOps con un producto
y servicio brownfield podría ser más desafiante y, sin embargo, el rendimiento
positivo de una iniciativa DevOps brownfield será más premiado, convincente e
impactante en su organización.

DevOps es también para grandes organizaciones con muchos sistemas de

ejecución heredados

Muchas personas creen erróneamente que DevOps no está diseñado para los
productos y servicios de Brownfield. Su creencia errónea va aún más lejos al afirmar
que DevOps es solo para empresas de nueva creación. Y, sin embargo, algunas de
las iniciativas DevOps más ejemplares se iniciaron en compañías con
organizaciones de TI gigantescas y maduras que tienen innumerables sistemas
heredados críticos para la empresa y miles de empleados. Amazon, Easy y
Facebook son algunos ejemplos para nombrar. Como se describe en el caso de
estudio del fabricante de SaaS más arriba, también puede iniciar DevOps en una
organización ya existente con productos y servicios industriales. De hecho, debido a
que la mayoría de los productos y servicios de Brownfield tienen una brecha
importante entre su rendimiento de desempeño y las expectativas de los clientes,
generalmente son los mejores candidatos para beneficiarse de su transformación
DevOps. Para usted, un buen consejo para comenzar con su iniciativa DevOps de
Brownfield es: Para empezar, invierta su tiempo para eliminar o al menos reducir la
deuda técnica y luego genere la automatización de pruebas faltantes para las
características y beneficios de los productos existentes. De lo contrario, su producto
y servicio de Brownfield nunca le permitirá realizar implementaciones de producción
confiables en ciclos más cortos.

Identificar un sistema apropiado de registros o sistema de compromiso

Durante su primera iniciativa DevOps, puede sentirse libre de elegir un sistema de

registros o un sistema de participación. Los sistemas de registros son sistemas
centralizados para administrar una sola fuente de verdad en su organización.
Dominan en gran medida la gestión de sus datos, incluidos clientes, transacciones,
seguridad y privacidad. Los sistemas de participación son, en su mayoría,
aplicaciones descentralizadas para permitir y animar a sus clientes y usuarios a
interactuar con su organización a través de portales de respuesta omnicanal o
aplicaciones móviles, tabletas y de escritorio.

Con su preferencia de un sistema de registro, su ventaja será que demostrará cómo

su equipo de DevOps maneja de manera competente las tareas altamente
burocráticas que requieren mucho tiempo, como el cumplimiento, la seguridad y la
privacidad. Usted y su equipo logran esto generando pruebas científicas y tangibles
y utilizando la automatización de pruebas y la telemetría durante todo el ciclo de
vida de las operaciones y el desarrollo de su producto y servicio. Un ejemplo típico
puede ser un programa de migración de sus datos distribuidos geográficamente
desde sus servidores de bases de datos locales a la nube, asegurando que su única
fuente de verdad siga cumpliendo con las normas y regulaciones legales,
industriales, locales e internacionales.

Si prefiere un sistema de participación, va a demostrar con qué rapidez e innovación

innovará con ciclos de entrega rápidos. Esto se debe a que la mayoría de las
innovaciones visibles que resultan en éxitos comerciales hoy en día se originan a
partir de sistemas de compromiso. Un ejemplo típico puede ser un flujo de salida
más intuitivo y simplificado en su portal de comercio electrónico que mejore sus
ventas en un 25%. En el momento en que logres esto, tus ejecutivos no solo
adorarán a DevOps, sino que también te adorarán a ti.

Su receta para la transformación exitosa de DevOps

Al comienzo de su viaje DevOps, no pierda su tiempo para ganar equipos
conservadores para su iniciativa DevOps. Identifique los equipos más innovadores,
de mente abierta, bien conectados e influyentes que creen en la necesidad de la
metodología y los principios de DevOps. Comienza pequeño con uno o dos equipos.
Al utilizar los consejos proporcionados anteriormente, identifique el producto y el
servicio más adecuado para áreas verdes o en zonas industriales abandonadas ... Y
el sistema apropiado de registros o sistema de participación para comenzar.

Después de sus primeras historias de éxito, estos equipos que tiene a bordo serán sus
mayores partidarios para difundir DevOps en toda su organización. Luego extiende su
coalición a otros grupos y aumenta el número de historias de éxito. Estos éxitos crearán
más y más pruebas y confianza social para su iniciativa DevOps. Una vez que vean los
beneficios medibles, también tendrá más apoyo, patrocinio y atención por parte de su
gerencia.
En la etapa final se identifican destructores influyentes y fuertes detractores (Curmudgeons).
Probablemente pueda vencerlos usando su propia técnica, que se extiende alrededor del
riesgo y el miedo. Usted les explica qué tan malos serán sus equipos y productos y se
convertirán en la última cadena débil de su organización si niegan el aprendizaje y el uso de
DevOps.

Conclusión
No es una tarea fácil impulsar cualquier transformación de TI organizacional. DevOps no es
una excepción. Sin embargo, al comenzar poco a poco, no correrá mucho riesgo. Por otra
parte, nunca olvide que uno de los deberes más profundos de cualquier líder joven o
experimentado es poder motivar y movilizar a su equipo para que actúe en aras de mejorar
el rendimiento empresarial ...
Y tomar algunos riesgos calculados para la mejor satisfacción profesional.

¿Cómo debe construir su organización de DevOps y diseñar su arquitectura de

software?
De acuerdo con la ley de Conway, las organizaciones cuyos sistemas de diseño están
obligados a producir sistemas que sean copias de sus propias estructuras de comunicación.
En otras palabras, su software no puede hacer nada mejor que la eficiencia con la que sus
equipos se comunican e interactúan. Por lo tanto, la forma en que estructuren sus equipos
seguramente afectará su arquitectura de software, TI y, finalmente, también el rendimiento
empresarial.

Cómo configura su organización define qué tipo de software obtiene

La mayoría de las compañías, que probablemente también incluyen a su compañía,
compartimentan sus organizaciones de distribución de software en varios equipos, y
terminan produciendo su software con la misma cantidad de capas. Los experimentos
controlados también han demostrado que cuando se pidió a una organización de 6 equipos
que construyeran un software, sus equipos crearon una arquitectura de 6 capas. Cuando se
pidió a otra organización con 3 equipos que construyeran el mismo software, crearon una
arquitectura de 3 capas. De hecho, hay muchos ejemplos similares.
Una reconocida compañía de seguros con 86,000 empleados en todo el mundo se
estructuró casualmente en 2 equipos funcionales principales para una de sus
organizaciones de TI, que ofrece el backend para administrar sus clientes, contratos,
facturas y servicios. Uno de estos equipos funcionales estaba orientado en lenguaje de
programación Java y el otro equipo funcional estaba orientado en procedimientos
almacenados PL / SQL. Además, dependían de las operaciones de TI centralizadas y de
toda la organización, los administradores de bases de datos, la infraestructura de TI, las
redes de TI, la seguridad de TI y los escritorios de servicios de garantía de calidad de TI, lo
que hizo su vida aún más difícil para poder entregar su software de forma segura.

El otro desafío de esta organización era que: aunque los equipos estaban
separados, en su arquitectura no podían separar de manera competente la lógica de
organización empresarial en Java de la lógica de acceso a datos en PL / SQL.
Entregaron cientos de funciones, cada una de las cuales es un espagueti de códigos
Java / PL / SQL. Por lo tanto, cada cambio y solicitud de nuevas funciones requerían
decenas de transferencias de un equipo a otro, y resultaron en largas colas de
espera y plazos de entrega para lograr que incluso se hicieran cambios menores.
Además, en este entorno complejo, como era muy difícil prever el impacto general
de incluso los cambios menores, rompieron continuamente las características
existentes en la producción y causaron tiempos de inactividad que también
requerían largos plazos de entrega, reprocesos, escalados y estrés para resolverlos.

Para recuperarse de este modus operandi, estos dos equipos funcionales se fusionaron en
un solo equipo de producto. Rediseñaron gradualmente su software convirtiendo su capa de
acceso a datos en un conjunto de funciones API. Además, crearon un nuevo sistema de
negocios completamente separado de la dinámica interna de su API de acceso a datos.
Incluso en su etapa inicial, esta iniciativa mejoró la moral del equipo porque los expertos de
Java y PL / SQL comenzaron a trabajar para el éxito de su equipo de producto conjunto en
lugar de los motivos de sus pasados ​silos funcionales. A medida que construyeron una
arquitectura poco acoplada, ahora el impacto de los cambios es más fácil de identificar, los
cambios son más fáciles y rápidos de implementar y los defectos son más sencillos de
localizar y corregir. Como resultado, el tiempo de entrega promedio de las nuevas funciones
se redujo de 4 meses a 3 semanas, y la cola de incidentes del equipo ahora está casi vacía,
por lo que se benefician de esta capacidad gratuita al revisar, refactorizar y mejorar su
código base.

Matriz de Organizaciones, Equipos Funcionales e Ilusión de Optimización de Costos

Sus compañías están organizadas con una serie de equipos funcionales en torno a
diferentes expertos en materia de temas tales como bases de datos, redes, operaciones,
seguridad de la información, control de calidad, gestión de lanzamientos, gestión de
proyectos, gestión de productos, etc. Los equipos de proyecto están formados por personas
de diferentes silos funcionales. En estas organizaciones de proyectos matriciales que
intentan ofrecer productos y servicios comerciales, los gerentes de proyecto generalmente
son responsables de obtener algo entregado, y los gerentes de producto son responsables
de garantizar que se entregue lo correcto.

Su problema en esta configuración organizativa es que los equipos funcionales no tienen

muy poca comprensión sobre el alcance del trabajo que contribuyen. En casos extremos,
pero a menudo típicos, a sus equipos funcionales no les importa el panorama general ni el
rendimiento global de TI y de negocio del producto y servicio que contribuyen. Lo que les
importa es asegurarse de que ninguna de sus puertas quede abierta después de que los
proyectos se vuelvan desagradables y todos empiecen a señalar con el dedo.

Como sus equipos funcionales generalmente tienen que gestionar largas colas de tickets,
generalmente requieren largos plazos de entrega para respaldar su proyecto. Debido a que
los proyectos luchan por recursos funcionales, las escalas son la única forma de obtener
atención rápida para su proyecto. Las escaladas sobre las escaladas obviamente
contaminan el clima laboral y la confianza entre sus equipos.

Múltiples transferencias de un equipo a otro, retrasos, problemas de calidad, reparaciones,

cuellos de botella y estrés son ahora parte de su trabajo diario. Esto se debe a que sus
organizaciones matriciales no están destinadas a hacer nada mejor que eso, siempre que
sigan enfocándose en una ilusión opaca y falsa de optimización de costos. De hecho,
debido a problemas de calidad, repeticiones y retrasos, las organizaciones funcionales
probablemente sean incluso más caras que cualquier otra reorganización aleatoria que
puedas imaginar. Además de esto, si su organización ya logró subcontratar algunas de sus
habilidades funcionales vitales, como el control de calidad y las operaciones de TI en
ubicaciones geográficamente remotas, su organización de TI ahora debe sobrevivir apenas
para cumplir y cumplir con las demandas que son críticas para la continuidad de su negocio.

Este es de hecho un gran problema. ¿Cómo resuelve esto DevOps? Respuesta: Con
equipos orientados a productos y servicios.
Para resolver este problema, DevOps sugiere que cambie los engranajes de la ilusión de
optimización de costos de los equipos funcionales a la optimización de velocidad válida y
probada de DevOps. De hecho, hecho correctamente, DevOps le permitirá ahorrar costos
mientras que usted y su equipo realizan entregas de manera rápida y continua.

Para usted, la sugerencia de DevOps es equipos orientados a productos y servicios. Los

equipos orientados a productos y servicios son equipos independientes, multifuncionales,
autónomos, autosuficientes y generalmente pequeños que pueden cubrir todas las fases del
ciclo de vida de la ingeniería de software de un producto y servicio dado (pero no un
proyecto temporal), incluyendo la arquitectura, el diseño y la codificación. , pruebas,
experimentación, despliegue, operación y mantenimiento de software. Sí. Lo has leído bien.
¿Quién más puede operar y mantener el software mejor que sus propios creadores? La
respuesta es, por supuesto: nadie. Por lo tanto, no es sorprendente que los equipos
DevOps más exitosos en Amazon y Netflix no abandonen sus productos y servicios una vez
que los liberen. También están a cargo de operar y mantener su software en sus propios
sistemas de producción.
Su organización ya no financia proyectos temporales, pero financia productos
y servicios
Para hacer que su desempeño empresarial prospere, su organización ya no financia
proyectos temporales cuyos resultados comerciales tangibles no son triviales para
evaluar a largo plazo. Ahora con DevOps, su organización financia su propia misión,
su propio propósito y sus propios productos y servicios asociados con esta misión y
propósito. El éxito de sus equipos ahora se evalúa y evalúa en función de su
rendimiento de TI y de negocio. Basado en el retorno de la inversión dentro de sus
dominios comerciales particulares, donde sirven sus productos, servicios y
microservicios a sus clientes internos y / o externos. Tus equipos ahora actúan
como propietarios de productos y servicios que crean y proporcionan, en lugar de
ser simplemente miembros de silos funcionales que no prestan mucha atención a
los resultados comerciales.

¿Cómo puedes construir tus equipos de DevOps y la arquitectura de

software?
DevOps, por supuesto, no sugiere que rompa y reorganice todos los proyectos en
curso en su organización de una sola vez. Una manera no disruptiva, pero aún así
impactante de adaptar sus equipos a la metodología de DevOps es inyectar
expertos funcionales en los equipos de proyectos. Una vez que sus equipos
obtengan expertos funcionales en sus dominios deseados, tales como control de
calidad, seguridad de la información, bases de datos, redes, servidores,
operaciones, etc., puede esperar que estos equipos diseñen, implementen y
mantengan sus productos de software de forma independiente y autosuficiente.
servicios.

En estos nuevos equipos DevOps orientados a productos y servicios, la

disponibilidad, la calidad, el rendimiento, la seguridad de la información y el
cumplimiento son tareas diarias de todos. ¿Cómo pueden sus equipos crear
aplicaciones de software de alta disponibilidad, seguras y de alta calidad que
puedan hacer frente al estrés y la carga que demandan sus clientes si los equipos
nunca prestan atención a estos requisitos no funcionales hasta que finalizan su
diseño y desarrollo? ¿Qué tan buenos pueden los expertos externos juzgar y validar
la seguridad y la calidad de sus aplicaciones de software sin involucrarse en
ninguna etapa de ingeniería de software de sus productos y servicios? Esta es la
razón por la que los equipos de DevOps de alto rendimiento confían en expertos
externos en la materia solo para obtener asesoría, pero aún son dueños de todos
los requisitos no funcionales en cada etapa de su ciclo de vida de ingeniería de
software.

Hay una alternativa que puede considerar

Una organización DevOps excepcionalmente exitosa que aún utiliza equipos
funcionales en combinación con equipos DevOps orientados a productos y servicios
es Google. En Google DevOps, los equipos y equipos funcionales ven su misión
organizativa con sus productos y servicios como un objetivo compartido. Los
equipos funcionales crean planos (como plantillas, listas de verificación, esqueletos
de aplicaciones, etc.) y sistemas de autoservicio (por ejemplo, para aprovisionar y
configurar servidores y redes de manera independiente) para asegurarse de que
nunca se conviertan en cuellos de botella que frenen los equipos de productos y
servicios de DevOps. . Los equipos funcionales de Google colaboran y apoyan a los
equipos de productos y servicios en las primeras etapas del ciclo de vida de la
ingeniería de software, realizan de forma constructiva revisiones de diseños,
códigos y pruebas, y proporcionan asesoría continua a los equipos de servicio y
productos de DevOps.

¿Qué tan grande debe ser tu equipo de DevOps?

El tamaño ideal para un equipo de DevOps es de 5 a 10 personas. Un tamaño de
equipo tan limitado reduce la complejidad de la comunicación y la alineación dentro
de su equipo. Además, el líder de su equipo y los miembros del equipo no gastan y
pierden mucho tiempo con los recados y los gastos generales. Esto también
mantiene el tamaño del producto y el servicio del que es responsable su equipo
hasta cierto límite, lo que reduce aún más la complejidad, el mantenimiento y la
dificultad de las operaciones de las aplicaciones de software. Cada miembro del
equipo en equipos tan pequeños ve el panorama general, y todos reúnen poca
experiencia de liderazgo al convertirse en parte de una misión crucial para su
organización. El líder de su equipo trabaja con la gerencia superior para comprender
los objetivos y traducirlos a los miembros de su equipo.

¿Qué sucede si un producto de hasta 10 personas no puede manejar su producto y

servicio?
Entonces su solución es crear un nuevo producto y servicio, y construir otro equipo de
DevOps que se haga cargo. Aquí no debe concebir conceptos de productos y servicios solo
como entidades servidas y proporcionadas a clientes externos que pagan por ellos. Pero
también puede crear libremente productos, servicios internos o las llamadas "API de
microservicio" y sus respectivos equipos DevOps para sus clientes internos. Por ejemplo, si
su sistema de facturación se vuelve demasiado grande para un equipo de hasta 10
personas, debe elegir otro equipo de DevOps que se haga cargo de la API de acceso a la
base de datos. Puede ser otro para hacerse cargo de la API de pago en línea. Y luego
puede ser otro para hacerse cargo de los procesos por lotes. Por supuesto, todos estos
equipos deben utilizar un repositorio de código común y un canal de implementación
conjunta para garantizar la integración continua, la entrega rápida y el éxito de sus
organizaciones.

Como ya sabe, en una arquitectura estrechamente acoplada, pequeños cambios en una

aplicación pueden eventualmente causar muchos efectos adversos para numerosos flujos
de trabajo. Por lo tanto, los productos, servicios y API de microservicio en su arquitectura
deben estar acoplados libremente. Cada equipo de DevOps debe ser el único responsable
de una pieza de una arquitectura débilmente acoplada. Cada equipo de DevOps puede
diseñar, desarrollar e implementar de forma independiente su software. El mecanismo de
alerta temprana incorporado en el canal de implementación debe informar de forma
automática y rápida a los equipos de DevOps sobre los posibles efectos adversos de
cualquier causa de verificación de código.

¿Cómo pueden estos equipos pequeños de hasta 10 personas manejar de forma

autosuficiente todas las fases del ciclo de vida de la ingeniería de software desde la
arquitectura hasta las operaciones por sí mismos?

Para gestionar esto, debe alentar a todos en su equipo a convertirse en un

generalista. Debe alentarlos y permitirles desarrollar continuamente nuevas
habilidades.

Solo debe contratar a miembros del equipo que estén ansiosos por aprender y crecer,
independientemente de su nivel efectivo de conocimiento y experiencia. Debe evitar
estrictamente a las personas que esperan ser evaluadas en un conjunto fijo de roles y
responsabilidades. Ya sabe que ni su organización ni sus productos y servicios permanecen
fijos.
La demanda cambiará mañana, si no es hoy.
Conclusion
En este capítulo, explicamos los resultados subóptimos de las organizaciones matriciales,
los silos funcionales asociados con ellos y la solución de DevOps para abordar esto.

La sugerencia de DevOps para usted es crear equipos pequeños orientados a API de

productos, servicios o microservicios de hasta 10 personas.

Estos equipos de DevOps deben constituir ingenieros de software de pila completa

generalistas que sean capaces de cubrir de manera autosuficiente todas las fases del ciclo
de vida de la ingeniería de software desde el diseño hasta el mantenimiento.

DevOps se basa en una arquitectura orientada a servicios (SOA) de acoplamiento flexible,

en la que cada equipo de DevOps posee y opera una parte de su arquitectura de
acoplamiento flexible.

¿Cuáles son los roles en su organización de DevOps?

DevOps Generalist
El rol principal de un DevOps Generalist es garantizar un establecimiento sin problemas, un
progreso eficiente y saludable y una mejora continua de las Prácticas DevOps en una
organización DevOps y en sus equipos DevOps. Por lo tanto, la competencia y la
perspectiva de cada empleado en una organización de DevOps para poder actuar con los
equipos de DevOps es un factor fundamental que determina el nivel de éxito y la vida útil de
las organizaciones de DevOps.

Ya sea que forme parte de una organización de DevOps o simplemente colabore y trabaje
con otros equipos de DevOps, es sumamente importante que tenga una comprensión clara
de cómo y qué hace que la metodología de DevOps sea mucho más exitosa, eficiente y
placentera con la que trabajar. Desarrollo de software y metodologías de entrega. Por lo
tanto, independientemente de que usted sea un profesional, líder o gerente de TI, software y
tecnología o no, todos los profesionales en esta era de digitalización actual (cuando el
software y todo lo que lo rodea son los reyes) son altamente recomendados para ser un
Generalista de DevOps.

DevOps Executive
Los ejecutivos de DevOps son responsables de la utilización exitosa y la aplicación del
conocimiento de DevOps dentro de sus organizaciones. Son jugadores clave para los
equipos de DevOps que permiten el cambio cultural de hacer y pensar en la forma de
DevOps. Han demostrado su capacidad para influir de manera constructiva en los equipos y
la administración para que hagan las cosas. Los ejecutivos de DevOps apoyan la alineación
de los equipos de DevOps con las estrategias comerciales, y son responsables de la
identificación, selección, alcance, priorización y, en última instancia, gestión de la
penetración de DevOps en sus organizaciones.
Los ejecutivos de DevOps seleccionan a los miembros clave de sus organizaciones
de DevOps y se aseguran de que todos los profesionales de DevOps hayan sido
entrenados, asignados y asignados adecuadamente a los proyectos de DevOps que
mejor se adapten a sus niveles de experiencia y habilidades. Trabajan duro para
entrenar y guiar a los equipos de DevOps, apoyan la planificación de recursos y
eliminan problemas y obstáculos para que toda la organización de DevOps sea
exitosa.

Los ejecutivos de DevOps informan a la gerencia ejecutiva en términos de los

objetivos de la misión comercial de DevOps preestablecidos y las métricas de
rendimiento de negocio identificadas. Promueven soluciones de mejores prácticas,
mejoras logradas, historias de éxito y las aprovechan para toda su organización
DevOps. Trabajan muy de cerca con todos los equipos de DevOps, pero con
especial énfasis en los gerentes de proyecto de DevOps, los propietarios de
productos de DevOps, los gerentes de lanzamiento de DevOps, los capacitadores
de DevOps y los entrenadores de DevOps debido a su misión organizativa particular
que se esfuerzan por lograr.

DevOps Project Manager

DevOps Project Manager es la persona responsable de cumplir los objetivos del
proyecto establecidos. Las responsabilidades clave de DevOps Project Manager
incluyen la creación de objetivos de proyecto claros y alcanzables, la creación de los
requisitos del proyecto y la gestión de las restricciones del triángulo de gestión del
proyecto, que son costo, cronograma, alcance y calidad.

DevOps Project Manager es a menudo un representante del cliente y tiene que

determinar e implementar las necesidades exactas del cliente, basándose en el
conocimiento de la empresa a la que representa. DevOps Project Manager es la
brecha puente entre el equipo de desarrollo / entrega y el cliente. Por lo tanto,
DevOps Project Manager tiene un conocimiento justo de la industria en la que se
encuentra, por lo que es capaz de comprender y discutir los problemas con el
equipo de entrega y el cliente. La capacidad de adaptarse a los diversos
procedimientos internos de la parte contratante, y de establecer vínculos estrechos
con los representantes designados, es esencial para garantizar que las cuestiones
clave relacionadas con el costo, el cronograma, el alcance y la calidad puedan
resolverse de manera eficiente y, sobre todo, de los clientes. la satisfacción puede
ser realizada.

El término y el título "DevOps Project Manager" describen a la persona a quien se le

asigna la responsabilidad de completar un proyecto. DevOps Project Manager es la
persona con total responsabilidad y tiene el nivel requerido de responsabilidad y
autoridad para cumplir los objetivos deseados del proyecto dentro del presupuesto
del proyecto, a tiempo y con la mayor calidad posible.

DevOps Product Owner

El rol de DevOps Product Owner es un rol muy amplio y único en DevOps que combina
todos los aspectos desafiantes de los roles tradicionales de Project Manager y Product
Manager. Además, DevOps Product Owner representa el punto de vista del cliente en un
equipo de DevOps al garantizar que se realice el trabajo correcto en el momento adecuado.
Debe estar estrechamente integrado con los Equipos y Procesos de Desarrollo y Entrega de
Software de DevOps para garantizar el máximo valor añadido para cada Lanzamiento de
Producto.

Los ​DevOps Product Owner tienen una serie de responsabilidades clave. Algunos de
ellos son:
● Gestión de la cartera de productos DevOps.
● Soporte a creaciones de product release roadmaps (​es una herramienta
poderosa para describir cómo es probable que crezca un ​producto , para
alinear a las partes interesadas y para adquirir un presupuesto para
desarrollar el ​producto​) y planes de lanzamiento.
● Identifique las dependencias del producto y la priorización adecuada
impulsada por la misión organizacional.
● Gestión y comunicación de grupos de interés.

Ya sea que actúes como un Propietario del Producto DevOps o no en tu equipo de

DevOps, siempre que trabajes directamente con tus clientes, es fundamental para ti
comprender el papel del Propietario del Producto DevOps para que sea lo más útil
posible. y para crear el máximo valor añadido para ellos.

DevOps Architect
Un Devops Architect posee arquitectura, diseño y desarrollo de herramientas y procesos de
implementación de productos. En esta función, se espera que DevOps Architect diseñe y
desarrolle soluciones innovadoras para construir y mantener la arquitectura del producto,
sus herramientas relacionadas y los procesos para la integración continua y el despliegue
continuo.

Los arquitectos de DevOps están a cargo de definir un conjunto de servicios acoplados de

manera flexible cuyos consumidores se ven afectados mínimamente por los cambios en
estos servicios o sus entornos. Obviamente, es inevitable que se produzca algún
acoplamiento, ya que el consumidor debe hacer uso del servicio, pero DevOps Architects
minimiza estas dependencias mediante la separación de la interfaz y la implementación, las
políticas de control de versiones, los contratos de tiempo de ejecución, la independencia de
la plataforma y la transparencia de la ubicación.
Los arquitectos de DevOps se vuelven extremadamente críticos para el éxito de las
organizaciones y equipos de DevOps. En la parte superior de la construcción de una
arquitectura óptima para productos y servicios, las organizaciones de DevOps deben poseer
un entorno extremadamente confiable, totalmente automatizado y sin obstáculos. Con la
cascada, todos tenían que tener automóviles 4x4 para conducir fuera de la carretera en
terrenos difíciles. El rol de DevOps Architect tiene la tarea de construir la autopista para que
el resto de nosotros podamos usar autos más rápidos.

DevOps Developer
Como desarrollador de DevOps, transforma los objetivos comerciales de sus clientes en
soluciones y sistemas de software. La principal diferencia entre un desarrollador ordinario y
un desarrollador de DevOps es que: como desarrollador de DevOps, durante el curso
completo de su trabajo, es consciente de los objetivos comerciales y las demandas
comerciales de sus clientes. Usted es plenamente consciente de por qué su empleador lo
ha contratado y de lo que sus clientes necesitan y esperan de usted.

Además, como desarrollador de DevOps, usted es el socio tecnológico de confianza de sus

clientes. Le da a sus empleadores y clientes la plena confianza y todas las razones para
mantenerlo a bordo. Usted es la única persona que conecta los objetivos comerciales y los
requisitos empresariales con los diseños de software y las líneas de código de software
ejecutable. Ya no eres un único diseñador o programador. Usted es el propietario del ciclo
de vida de ingeniería de todo el software desde su análisis de requisitos, visión
arquitectónica y automatización de pruebas hasta su experiencia de usuario, extensiones,
operaciones, mantenimiento y final de vida.

Como desarrollador de DevOps, usted está a cargo de implementar las soluciones de

software en iteraciones pequeñas y frecuentes. Usted es excelente y garantiza la entrega
continua de sus diseños y software a sus clientes para crear un valor rápido e
ininterrumpido para su empresa y la suya. Siempre recuerda que: ¡Su misión es tener
clientes felices mientras crea el software que usted y sus clientes aman!

Si usted es un Desarrollador apasionado y un Profesional de Ingeniería de Software

DevOps dedicado a construir sistemas eficientes, de clase mundial y de alta calidad,
se recomienda encarecidamente que sea un Desarrollador DevOps.

DevOps Operations Engineer

Los ingenieros de operaciones de DevOps son responsables de monitorear, mantener y
desplegar el software y la infraestructura más avanzados detrás de la tecnología de sus
productos. Implementan y mantienen Infraestructuras y Servidores de Red en los Centros
de Datos. También participan en los equipos de implementación y entrega de DevOps en
las instalaciones y desarrollan planes de contingencia de implementación y entrega de
productos.

En este rol, los deberes van desde la implementación física de la tecnología relacionada con
el centro de datos hasta el trabajo en conjunto con los diferentes interesados,
especialmente con los desarrolladores de DevOps para garantizar que la disponibilidad, la
capacidad de mantenimiento, la capacidad de supervisión y el análisis estén integrados en
los núcleos de los productos.

Detrás de todo lo que ven los clientes de su organización, se encuentra la arquitectura

construida por DevOps Operations Engineers. Y los ingenieros de operaciones de DevOps
están a cargo de mantener estos sistemas en funcionamiento. Desde el desarrollo y
mantenimiento de productos y servicios hasta la construcción de la próxima generación de
sus plataformas, los Ingenieros de Operaciones de DevOps hacen posible la cartera de
productos de su organización.

Los ingenieros de operaciones de DevOps se enorgullecen de ser ingenieros de ingenieros

y aman anular las garantías al desarmar las cosas para que puedan reconstruirlas. Siempre
están preparados para estar disponibles para mantener sus sistemas y redes en
funcionamiento, asegurando que sus clientes tengan la mejor y más rápida experiencia
posible.

Ingeniero de control de calidad de DevOps-DevOps Quality Assurance Engineer

Los ingenieros de control de calidad de DevOps desempeñan un papel proactivo en

el procesamiento de puntos de venta únicos de su producto, requisitos, casos de
uso, arquitectura de software y otros materiales de diseño de software para conocer
los tipos de prueba deseados para validar la calidad del producto bajo prueba.
Trabajan con DevOps Developers y DevOps Project Managers para determinar las
metodologías y herramientas de implementación de prueba para ejecutar y operar el
trabajo de prueba.

Los ingenieros de control de calidad de DevOps escriben listas de casos de prueba

creativos con una fuerte actitud de "Romper". También clasifican las prioridades y los
niveles de dificultad de sus casos de prueba. Crean y revisan la documentación detallada de
los casos de prueba para asegurarse de que sus casos de prueba sean percibidos
correctamente por el resto del equipo de DevOps.

Los ingenieros de control de calidad de DevOps realizan un seguimiento y una revisión

continuas de las fases de ejecución de prueba para garantizar que los casos de prueba
implementados cumplan sus objetivos. Actúan como expertos en la materia seguros de sí
mismos y confiables para enfatizar el objetivo y la importancia de sus casos de prueba.
Plantean y revisan los defectos, y se aseguran de que no haya ningún compromiso con las
Características del Producto planificadas.

Además, los ingenieros de control de calidad de DevOps nutren a todo el equipo de

DevOps para revisar sus diseños de prueba y procesar sus comentarios para
agregar casos de prueba creativos adicionales y reducir las redundancias en sus
diseños de prueba. Por último, pero no menos importante, durante una parte
importante de sus tiempos, automatizan, ejecutan pruebas y vuelven a ejecutar las
pruebas para validar las correcciones de errores que provienen de los Equipos de
Desarrollo de Software.

Ingeniero de Seguridad de la Información de DevOps

En las configuraciones tradicionales de las organizaciones de TI, la seguridad de la
información es, en gran medida, una reflexión tardía Es otro requisito no funcional que a
menudo se cuida cuando es más difícil, costoso y agitado identificar y solucionar los
problemas.

Los ingenieros de seguridad de la información de DevOps diseñan la estrategia de

seguridad de imagen grande de sus organizaciones al tiempo que presentan los
detalles de un plan de implementación. Comprenden la necesidad constante de
equilibrar los beneficios de las medidas de seguridad incrementales con las cargas
potenciales para el negocio. Ellos encuentran y solucionan proactivamente los
problemas de seguridad en los diseños en las primeras etapas de ingeniería de los
productos y en la ejecución de los sistemas de software. Supervisan redes,
telemetría de software y priorizan los esfuerzos basados ​en el riesgo.

Las organizaciones de DevOps tienen ingenieros de seguridad de la información de DevOps

que trabajan conjuntamente con los desarrolladores de DevOps y los ingenieros de
operaciones de DevOps. Incrustan sus recomendaciones y expertos en el tema mucho
antes en el proceso de desarrollo y entrega de software. Los ingenieros de seguridad de la
información de DevOps permiten a sus organizaciones incorporar la seguridad en el
producto durante todo su ciclo de vida de entrega de extremo a extremo.

DevOps Release Manager

Los gerentes de lanzamiento de DevOps trabajan para abordar la gestión y coordinación del
producto desde el desarrollo hasta la producción. Por lo general, trabajan en más detalles
técnicos y obstáculos en los que no puede participar un gerente de proyecto tradicional. Los
gerentes de lanzamiento de DevOps supervisan la coordinación, la integración y el flujo de
desarrollo, pruebas y despliegue para admitir la entrega continua. Se centran no solo en la
creación, sino también en el mantenimiento de la cadena de herramientas de entrega de
aplicaciones de extremo a extremo.

DevOps Release Managers trabaja estrechamente con DevOps Project Managers y

DevOps Product Owners para crear hojas de ruta de lanzamiento de productos, lanzar
planes, identificar dependencias, hacerlas visibles, asegurar la priorización de tareas
dependientes por parte de los equipos de DevOps, apoyar la gestión de DevOps Product
Backlog, la gestión de las partes interesadas y la comunicación.

DevOps Trainer
Al igual que todas las demás tendencias de hipercrecimiento en nuestra industria de TI, la
adopción de la metodología DevOps tampoco es inmune a posibles malentendidos y
conceptos erróneos. Un número significativo de equipos y empresas de DevOps cometen
errores organizativos, de comportamiento y operativos que afectan negativamente el
rendimiento de los equipos de DevOps y su adaptación a las organizaciones en general, y
por lo general aún no realmente ágiles. Desafortunadamente, estas inconsistencias a veces
terminan con la abolición de las prácticas de DevOps de las organizaciones que perjudican
a nuestra industria y los partidarios de DevOps.

Los Entrenadores de DevOps son simpatizantes de DevOps talentosos como usted para
garantizar la capacitación y educación correctas de las prácticas de DevOps dentro de las
organizaciones.

Los capacitadores de DevOps pueden ser personas independientes de los equipos de

DevOps en las organizaciones y pueden ser patrocinados directamente por los ejecutivos
para permitir la capacitación organizativa integral de DevOps. Alternativamente, los
capacitadores de DevOps pueden formar parte de los equipos de DevOps y trabajar con los
ejecutivos para obtener el apoyo requerido y capacitar de manera consistente a otras partes
de las organizaciones para que se adapten a los equipos de DevOps. Si desea ayudar a sus
equipos de DevOps, equipos de negocios y patrocinadores ejecutivos a aprender e
implementar adecuadamente las prácticas de DevOps, se recomienda encarecidamente
que sea un Entrenador de DevOps.

Los capacitadores de DevOps brindan servicios de capacitación generalmente a sus

clientes externos para enseñarles DevOps en un entorno educativo. Los
entrenadores de DevOps entrenan a los miembros del equipo de DevOps
generalmente dentro de las organizaciones de sus clientes y se aseguran de que
entiendan y operen adecuadamente con DevOps. Proporcionan consejos y trucos a
los equipos mientras los equipos de DevOps hacen su trabajo en el entorno de
trabajo real.

DevOps Coach
Al igual que todas las demás tendencias de hipercrecimiento en nuestra industria de TI, la
adopción de la metodología DevOps tampoco es inmune a posibles malentendidos y
conceptos erróneos. Un número significativo de equipos y empresas de DevOps cometen
errores organizativos, de comportamiento y operativos que afectan negativamente el
rendimiento de los equipos de DevOps y su adaptación a las organizaciones en general, y
por lo general aún no realmente ágiles. Desafortunadamente, estas inconsistencias a veces
terminan con la abolición de las prácticas de DevOps de las organizaciones que perjudican
a nuestra industria y los partidarios de DevOps.

Al igual que los capacitadores de DevOps, los entrenadores de DevOps también son
talentosos partidarios de DevOps como usted para garantizar la comprensión correcta, la
penetración y la adopción de las prácticas de DevOps dentro de las organizaciones.

Los Entrenadores de DevOps pueden ser personas independientes de los equipos de

DevOps en las organizaciones y pueden ser patrocinados directamente por los ejecutivos
para permitir la adopción organizativa y cultural de DevOps de principio a fin.
Alternativamente, los Entrenadores de DevOps pueden ser parte de los equipos de DevOps
y trabajar con los ejecutivos para obtener el apoyo requerido y para evolucionar
constantemente a otras partes de las organizaciones para que se adapten a los equipos de
DevOps. Si desea ayudar a sus equipos de DevOps, equipos de negocios y patrocinadores
ejecutivos a comprender, adoptar e implementar adecuadamente las prácticas de DevOps,
se recomienda encarecidamente que sea un Entrenador de DevOps.

Conclusión
En este capítulo, cubrimos los roles más utilizados en una organización DevOps. Tengamos
en cuenta que no todos los equipos de DevOps en su organización deben tener a alguien
con cada uno de estos roles. Menos es más. Asegúrese de que su equipo se centre en
pocos importantes y elimine muchos triviales para lograr el rendimiento de TI y de negocios
que su organización pretende.
La mejor regla general es que su equipo debe tener roles y habilidades para permitir el
mejor flujo continuo de trabajo posible. El flujo es el tema que comenzaremos a cubrir a
partir del próximo capítulo y en adelante.

¿Cómo debería habilitar el flujo de DevOps?

En DevOps, Flow significa una cadena de fabricación de software de extremo a extremo,
desde la idea hasta la ejecución de líneas de códigos en sus sistemas de producción. Usted
y sus equipos de DevOps están a cargo de crear y mantener un flujo confiable, consistente
y rápido para cumplir y superar sus objetivos organizacionales y superar a otros productos y
servicios en su mercado particular.

Defina una misión para la transformación de su DevOps

Después de que tenga su equipo DevOps en su lugar, el siguiente paso es definir una
misión. Solo al tener una misión común, su equipo estará equipado para funcionar
correctamente. Sin una misión, su equipo nunca podrá priorizar el trabajo crítico y distinguir
a las personas que se quedan sin trabajo. La misión debe ser desafiante e impresionante,
pero aún debe ser alcanzable en un plazo determinado.

Una misión debe ser personalizada para su propio equipo de DevOps. Se basa en
las características de la organización, los desafíos y los objetivos para servir a
clientes internos y externos que interactúan con su equipo de DevOps.

Algunos ejemplos de declaraciones de misión para iniciar su transformación DevOps

pueden ser:
● Reducción del 75% del tiempo promedio de entrega desde el código de entrada a los
sistemas de producción en vivo en 3 meses.
● Reducción del 33% del tiempo de espera promedio desde la solicitud hasta
los sistemas de producción en vivo en 6 meses.
● Reducción del 50% del número de incidencias de producción en 12 meses.
¿Qué es y quiénes están involucrados en su Value Stream(serie de pasos para
generar valor)?
Para mejorar su trabajo, necesita conocer su flujo de valor. Un flujo de valor en los sistemas
de tecnología de la información es una secuencia de actividades necesarias para diseñar,
construir y operar un producto y servicio de software específico. Además, un flujo de valor
define recursos humanos, conocimientos, utilidades y materiales que permiten que el flujo
de valor fluya.

En una estructura organizativa compleja, nadie es completamente capaz de

identificar un flujo de valor de extremo a extremo. Por lo tanto, es importante que
todos los miembros de su equipo DevOps, partes interesadas, proveedores,
representantes de clientes, si es posible, sus propios clientes deben participar para
identificar su flujo de valor.

Construya su mapa de flujo de valor para descubrir los potenciales de mejora

Un mapa de flujo de valor le permite a usted y a su equipo de DevOps visualizar cómo se
realiza un trabajo típico en su organización de desarrollo y entrega de software. Al construir
un mapa de flujo de valor, su objetivo no es hacer una documentación completa sobre cada
uno de los pasos para realizar su trabajo. Su objetivo es obtener información suficiente
sobre su flujo de trabajo típico para identificar dónde se encuentran las principales
ineficiencias, limitaciones, problemas y pérdida de tiempo y recursos.

Cuando los ingenieros de desarrollo de software y operaciones se sientan juntos por

primera vez y crean un mapa de flujo de valor, generalmente es la primera vez que un
ingeniero de operaciones comprende los efectos negativos de los servidores de bases de
datos mal configurados sin espacios de tablas en los equipos de desarrollo. De manera
similar, generalmente es la primera vez que un ingeniero de desarrollo de software ve las
consecuencias de la entrega de software sin las funciones integradas de monitoreo,
disponibilidad, capacidad de prueba y configuración.
Elimine las entregas, restricciones y desperdicios tanto como pueda
Algunos de los factores de eficiencia más importantes, pero pasados ​por alto, son
las transferencias, el desperdicio y las limitaciones. Cuando una actividad se
transfiere de un equipo a otro, requiere señalización, solicitud, programación,
priorización, desaprobación y resolución de conflictos.

Cuando se pasa un trabajo de un equipo a otro, cada transferencia no solo resultará

en la pérdida de información, sino que también tendrá un impacto negativo en el
tiempo de entrega general de su flujo de valor.

Para superar estos problemas:

● Es necesario desafiar la duración requerida para cada transferencia. Por
ejemplo, de acuerdo con el ejemplo de asignación de flujo de valor anterior,
se requieren 80 horas hasta que el equipo de implementación selecciona un
código probado con éxito. ¿Por qué esto es así? ¿No podemos automatizar
este proceso? Por supuesto que podemos.
● Es necesario eliminar los residuos causados ​por las transferencias
repetitivas. De acuerdo con el ejemplo anterior del mapeo de flujo de valor,
el equipo de prueba entrega el 65% de las funciones al desarrollo. Los
arreglos para algunos defectos deben entregarse hasta 3 veces hasta que
sean aprobados por los evaluadores. ¿No podríamos acelerar estas
iteraciones al permitir una mejor integración entre los equipos de desarrollo y
de prueba? Y una gran cantidad de defectos muestra que algo no funciona de
manera óptima para su equipo de desarrollo. Las razones de estos
problemas de calidad deben identificarse y ordenarse.
● Necesitas desafiar y eliminar las transferencias tanto como puedas. De
acuerdo con el ejemplo de asignación de flujo de valor anterior, una vez que
se refina una solicitud, se demora 320 horas hasta que la autoridad
autorizada la procesa. ¿Por qué necesita una autoridad de aprobación en su
organización? ¿Cuál es el valor de esta autoridad para su flujo de valor?
¿Tiene esta autoridad suficiente nivel de información y visión para tomar una
buena decisión? ¿Por qué esta autoridad de aprobación no se convierte en
parte del equipo de refinamiento de solicitudes, por lo que sabe mucho mejor
acerca de lo que se está firmando y habrá una transferencia de menos
tiempo que demora 320 horas? A menos que elimine las restricciones y las
barreras que ralentizan su flujo, realmente no puede esperar mucho de
DevOps.

DevOps espera que hagas esas preguntas para romper el status quo. Por supuesto,
no todos los miembros de su organización estarán felices de escuchar estas
preguntas. Pero ya estás preparado para esto.
Haz que tu flujo sea visible para todos
Para asegurarse de que su trabajo fluya de izquierda a derecha y que su
organización DevOps logre sus objetivos, debe contar con herramientas y
mecanismos que hagan que su flujo sea visible. En el negocio de la tecnología de la
información, se trata de hacer clic con el mouse para asignar un trabajo de un
equipo a otro en su flujo de valor. Sin embargo, debido a un trabajo incompleto,
dependencias inconsistentes y malentendidos, es parte de su trabajo diario que su
trabajo salta de un equipo a otro (también llamado "un paso adelante, dos pasos
atrás") y fluye muy lentamente si fluye a todos.

Por lo tanto, es importante asegurarse de que su flujo sea visible. No solo para tu
equipo, sino para todos. DevOps se basa en Product Backlog, Sprint Planning
Backlog y Kanban para visualizar los flujos. Estas placas no solo involucran los
trabajos (tareas) que pertenecen a su propio equipo de DevOps, sino que también
deben hacer que todo el flujo sea visible desde la concepción de la idea de sus
productos y servicios hasta el mantenimiento operativo y el final de la vida útil. De
esta manera, siempre que un trabajo no fluya, será rápidamente visible para todos.
Y será responsabilidad conjunta de todos eliminar los obstáculos e impedimentos
para permitir un flujo continuo y exitoso de su trabajo.

Limitar el tamaño del lote y el trabajo en progreso-Limit Batch Size and Work
in Progress

La investigación realizada en la Universidad de Stanford encontró que la multitarea

es menos productiva que hacer una sola cosa a la vez. Los investigadores también
encontraron que las personas que son bombardeadas regularmente con varias
corrientes de información electrónica no pueden prestar atención, recordar
información, o cambiar de un trabajo a otro, así como las que completan una tarea a
la vez.
¿Qué significa esto para tu equipo de DevOps? Esto significa que necesita reducir el
trabajo en curso y limitar los tamaños de lote de las entregas de código. Como
ejemplo ilustrativo: su equipo puede tener un máximo de 6 tareas de trabajo en
progreso en desarrollo para evitar el cambio continuo de contexto y permitir un
enfoque completo en el trabajo en cuestión. Alternativamente, puede estimar cada
tarea con un punto de historia ponderado por los números de Fibonacci (0, 1, 2, 3, 5,
8, 13, 21, 34, ...) y su equipo de DevOps procesa hasta un cierto número total de
historias Puntos (velocidad) en un período de tiempo dado (sprint).

Además de aumentar la calidad y la productividad, al limitar el tamaño de los lotes

de las entregas, será más rápido identificar las causas raíz de los problemas y
resolverlos. Una vez que finalice una tarea, la revisará en su repositorio de código
común, la validará con su plataforma de integración continua y, posteriormente, la
implementará en su producción. Como el tamaño del lote es pequeño, la
identificación de los problemas de producción debidos a las entregas de códigos
será más fácil, los reintegros potencialmente necesarios serán menos engorrosos.
Además, al entregar continuamente en producción, su equipo tendrá el orgullo
constante de contribuir con su misión organizativa. Le dejaremos esto para que
compare este modo de trabajar con la moral, la motivación y los desafíos técnicos
de los equipos que desarrollan sus códigos durante 8 meses sin entregar una sola
línea de código a sus sistemas de producción.

Use el 20% de su tiempo para reducir la deuda técnica

Cuando su organización no reserva tiempo para reducir su deuda técnica, pero

continúa creando soluciones en la parte superior de las soluciones provisionales,
llegará un momento en el que todos los ingenieros dedicarán todo su tiempo a
solucionar los problemas. En analogía financiera del concepto de deuda: su
organización solo pagará intereses de deuda.

Conclusion
En este capítulo cubrimos para usted qué flujo de valor y flujo en DevOps son, por
qué son importantes y qué hace para que su trabajo fluya en flujo de valor.

¿Cómo debe diseñar su entrega de DevOps y su canal de implementación?

En muchas organizaciones, probablemente incluyendo la suya, los desarrolladores
realizan trabajos de codificación aislados en ramas de código separadas. Si bien
este modo de operación engañosamente parece fomentar la productividad individual
de sus desarrolladores, hace que la productividad de su equipo se vea afectada.
En muchas organizaciones, probablemente incluyendo la suya, los desarrolladores
realizan trabajos de codificación aislados en ramas de código separadas. Si bien
este modo de operación engañosamente parece fomentar la productividad individual
de sus desarrolladores, hace que la productividad de su equipo se vea afectada.

Tu desafío se hace más grande si no te integras continuamente

Irónicamente, como la combinación de códigos es una actividad desafiante y
agotadora dentro de los ciclos de creación de códigos, la mayoría de los equipos de
desarrollo desafortunadamente combinan su código antes de entregar su aplicación
a los evaluadores de integración o aceptación de usuarios, lo que hace que el
problema sea aún más impactante. Hacen que la integración exitosa y la calidad de
su codificación conjunta sean responsabilidad exclusiva de los equipos de control de
calidad. Esto no solo es ridículo, sino que también explica perfectamente por qué los
proyectos se retrasan, los déficits presupuestarios de los proyectos se disparan, la
moral y la motivación de los equipos, las metas y promesas organizacionales fallan,
y las empresas de todo el mundo desperdician anualmente alrededor de 600 mil
millones de dólares por trabajo de TI no presupuestado y no programado . O
digamos que el retrabajo de TI o las soluciones de TI funcionan ...

¿Cómo puede ayudarle el desarrollo basado en Trunk (Main Code Branch)?

Su solución para este desafío es el desarrollo basado en troncales (rama de código
principal) en combinación con la integración continua y la automatización de
pruebas. El desarrollo basado en troncales es un modelo de bifurcación de control
de fuente, donde los desarrolladores colaboran en el código en una única rama
llamada "troncal". Resisten cualquier presión para crear otras ramas de desarrollo
de larga vida.

El desarrollo basado en troncales es su habilitador clave para la integración continua

y, por extensión, la entrega continua. Cuando sus desarrolladores comprometen sus
cambios en el troncal varias veces al día, resulta fácil satisfacer el requisito central
de la integración continua que todos los miembros de su equipo se comprometen a
troncal al menos una vez cada 24 horas. Esto garantiza que su base de código
siempre sea liberable a pedido y ayuda a hacer que la entrega continua sea una
realidad.
La integración continua le permite entregar su código en porciones más
pequeñas en estado implementable

Además, los controles frecuentes de sus desarrolladores permiten pequeños lotes

de desarrollo y entrega que aumentan la calidad y facilitan la resolución de
problemas y conflictos. La integración continua con los registros diarios motiva a su
equipo a construir códigos implementables, pero aún significativos en partes más
pequeñas sin romper la integridad de sus trabajos de integración continua y marco
de entrega continua. Las actualizaciones en este repositorio de código fuente común
también proporcionan un medio y un medio para usted y para los miembros de su
equipo para obtener alineaciones, decisiones y comentarios rápidos.

Cada vez que se ingresa un código, su marco de integración continua ejecuta casos
de prueba automatizados para las funciones y características que dependen del
impacto del módulo modificado. Si algo no funciona, el propietario de este check-in
particular ahora es responsable de arreglar el check-in. Con la máxima prioridad.
Nada más es más importante en este momento para garantizar que el resto de su
equipo pueda continuar integrando su trabajo al tronco. Hasta que el registro
erróneo se arregle o retroceda rápidamente, no se permite ningún otro registro en
este módulo del principal para proteger la estabilidad y confiabilidad de su troncal.

Si piensa que es diferente de uno de estos principios principales de DevOps, la

pregunta que debe responder es: ¿Por qué agregaría otro código nuevo a un
módulo que ya tiene errores?
Puede tener razones legítimas, pero asegurémonos de evitar las deudas técnicas y
las soluciones alternativas.

Gated Commits es una red de seguridad adicional posterior para su desarrollo

basado en troncales
Alternativamente, su equipo de DevOps también puede confiar en compromisos
cerrados que aumentan aún más la calidad y crean otra capa de red de seguridad
para su troncal.

Cada vez que un desarrollador intenta registrar un código, la automatización de

prueba se ejecuta primero para validar el código. Solo después de la validación
exitosa, el código se registra formalmente en su troncal.

Utilice entornos similares a los de producción en cada etapa de su flujo de

valor de ingeniería de software
Otro desafío típico en muchas organizaciones de TI son las inconsistencias entre los
entornos de producción y preproducción (desarrollo, integración y pruebas).
Inconsistencias entre sus configuraciones, versiones y niveles de parches de
sistemas operativos, bases de datos, herramientas de terceros y API. O diferentes
versiones de su propio código dispersas en diferentes entornos de producción y
preproducción. Incluso diferencias muy pequeñas en las versiones de JVM entre los
entornos de preproducción y producción pueden hacer o deshacer toda su
implementación de producción. A menos que tenga el control total de sus entornos y
sepa lo que tienen dentro, nunca podrá saber qué obtendrá de ellos.

Embrace Environment Management parte de su trabajo diario de desarrollo y

entrega de software
Por lo tanto, no es obvio que sus sistemas de preproducción sean las réplicas de
sus sistemas de producción. Debe permitir que su equipo cree entornos de
autoservicio a pedido de manera automatizada para poder realizar de forma segura
sus tareas diarias de ingeniería de software en entornos similares a la producción.

Su flujo de valor de TI en su organización no solo ofrece valor con el código de su

software, sino también con los entornos en que se ejecutan estos códigos. Tanto su
especialista en desarrollo como en operaciones deben aceptar el hecho de que su
flujo de valor de TI constituye dos bloques de construcción igualmente importantes:
● Códigos para construir su software que sirvan de valor a sus clientes internos
y / o externos.
● Códigos para construir sus entornos de preproducción y producción para
alojar su software.
Use su única fuente de verdad (troncal) para controlar su software y entornos
(también conocido como Adopt Infrastructure as Code (IaC))
Con DevOps, las tareas para construir sus entornos de preproducción y producción
ahora forman parte de su troncal, que es la definición más pura de Infraestructura
como código (IaC). En lugar de sus equipos de operaciones aisladas que apenas
conocen los detalles específicos del software que sus entornos deben alojar, su
especialista en desarrollo y operaciones trabajan juntos para construir su
infraestructura como código.

Con el fin de garantizar que el código de su software y el código de sus entornos

sean tratados de igual importancia, utiliza su única fuente de verdad (troncal) para
almacenar el código de su software y sus entornos.

Para poder construir todos sus sistemas de preproducción y producción y su canal

de implementación, incluidos sus marcos de integración y entrega continua, usted y
su equipo no solo almacenan el código de su software en el sistema de control de
versiones, sino que también almacenan las configuraciones, scripts y cualquier cosa
requerida para construir su cadena de entrega de extremo a extremo. Si desea
cambiar de forma permanente una configuración en un entorno, debe hacer este
cambio en su entorno creando scripts, por lo que la próxima vez que un miembro de
su equipo DevOps cree un entorno, no tendrá que reinventar la rueda.

La mayoría de las documentaciones detalladas se vuelven obsoletas rápidamente,

por lo que para usted será obviamente una mejor inversión gastar su energía para
mantener actualizados los scripts de creación de entornos. Esto se debe
principalmente a que, sin contar con autoservicio y entornos de poca demanda, su
infraestructura en la nube seguirá siendo otra plataforma de alojamiento subutilizada
y su iniciativa DevOps será otro intento de mejora de procesos subutilizados.
Debería poder crear entornos completos de producción y preproducción desde su
sistema de control de versiones. Con DevOps es más fácil y rápido reconstruir
entornos que arreglarlos. Los cambios de manuel en tus ambientes ya no están
permitidos. Solo el código y la configuración deben reconstruirse, configurar y
ejecutar sus entornos.

Tiene una nueva definición de hecho (DoD)-You Have a New Definition of Done
(DoD)
Teniendo en marcha el marco de entrega continua y el canal de implementación,
ahora necesita una nueva definición de "Definición de Hecho (DoD)".

Una tarea debe clasificarse ahora como "Finalizada" cuando sus características y
beneficios asociados para el cliente son:
 ● Creado desde su troncal ya sea automáticamente o con un proceso de un
clic,
● Probado en producción como entornos con pruebas automatizadas,
● Demostrado en producción como entornos,
● Listo para implementar o incluso mejor implementado en entornos de
producción nuevamente, ya sea de forma automática o con un solo clic.

Conclusión
Con DevOps, la integración de su código pasa a formar parte de su trabajo diario en
lugar de al final de sus proyectos. Los desarrolladores, los equipos de operaciones,
los especialistas en seguridad de la información, los tiempos interminables ensayan
la implementación de su trabajo durante el ciclo de vida de la ingeniería de software,
lo que sin duda mejora la posibilidad de implementaciones en vivo sin problemas.

Una mayor productividad empresarial, un mejor software y una mayor estabilidad en

el entorno, una mayor satisfacción laboral, una mejor calidad de servicio para sus
clientes internos y externos serán también sus otros beneficios tan pronto como
adopte la integración continua.
¿Por qué necesita automatización de pruebas en su organización DevOps?
Si su departamento de entrega de software aún no cuenta con una automatización
de pruebas decente, entonces debe haber una clara desconexión entre su
desarrollo y sus esfuerzos de prueba. Sus desarrolladores solo reciben comentarios
tardíos sobre la calidad de su trabajo mientras ya están ocupados con otras tareas.
Por lo general, pierden la relación de causa y efecto entre el código que han escrito
(o no han escrito) y los defectos. Los esfuerzos que sus desarrolladores ponen para
que este cambio de contexto vuelva a los tiempos en que introdujeron defectos
claramente reducen la productividad. Debido a que la conexión entre los sistemas y
los defectos es compleja y confusa después de una retroalimentación tardía,
obtener correcciones de calidad sin una solución alternativa no es ni realista ni
esperado.

Puede automatizar sus pruebas, pero no puede automatizar la creación de

calidad
Su equipo de DevOps debe automatizar tantos casos de prueba como sea posible.
Debido a que puede automatizar sus pruebas, pero no puede automatizar la
capacidad cognitiva de su equipo DevOps para crear calidad, no debe desperdiciar
su capital humano en ningún trabajo repetitivo y repetitivo que el software pueda
hacer por usted.

Principios de DevOps para una buena automatización de pruebas

● La Automatización de Pruebas debe proporcionar comentarios rápidos y
tempranos sobre su calidad de trabajo.
● Las pruebas deben generar resultados consistentes, deterministas y
repetibles con las mismas condiciones para diferentes ejecuciones de
prueba.
● Las pruebas no deben generar falsos positivos.
● La pequeña cantidad de casos de prueba automatizados y confiables es
mejor que la gran cantidad de pruebas no automatizadas y no confiables que
pueden dar resultados inconsistentes a pesar de que se proporcionan las
mismas condiciones para diferentes ejecuciones de prueba.
● La automatización de pruebas debe centrarse primero en la validación de las
características y los beneficios clave que sus sistemas brindan a sus clientes
internos y externos. Incluso este nivel de automatización de pruebas es
mucho mejor que ninguna automatización de pruebas.
● Después, concéntrese en automatizar tantos casos de prueba como sea
posible para obtener el mejor uso de su capital humano en sus equipos
DevOps.
 ● Con su automatización de prueba, evite retroalimentación lenta y periódica.
Lo que necesita es retroalimentación rápida cuando usted o su desarrollador
intenten ingresar el código en su troncal.
● Si sus pruebas automatizadas no son lo suficientemente rápidas, busque
formas de acelerar sus pruebas y / o su software. Esto no solo es
fundamental para contar con una plataforma de distribución y un sistema de
implementación continua y confiable, sino también para tener una excelente
calidad de servicio para sus clientes. Para obtener aún más rápido paralelice
sus pruebas automatizadas.
● Considere el desarrollo guiado por pruebas. Primero escribe tus pruebas
automatizadas, luego construye tu software.

La automatización de pruebas es su principal habilitador para la entrega

continua y la implementación de la canalización

Como hemos cubierto anteriormente, la metodología DevOps le brinda a sus

desarrolladores la capacidad de implementar su código en sus sistemas de
producción. Y, sin embargo, las observaciones con los primeros equipos de DevOps
en las organizaciones han demostrado que: aunque los desarrolladores son lo
suficientemente rápidos como para registrar su código para interrumpir y cerrar
tareas y tickets, son bastante reacios a presionar el botón para lanzar su código a
los sistemas de producción. Tienen un poco de miedo de romper la producción y ser
culpados por ello.

Solo después de que los equipos de DevOps hayan desarrollado una cobertura de
prueba completa y confiable con automatización de prueba, los desarrolladores
podrían superar este temor.

Por ejemplo: en Google, cuando un desarrollador ingresa un código en el tronco,

después de las verificaciones iniciales, como el análisis de código estático, el
análisis de duplicación y el análisis de cobertura de prueba, este código se valida
con casi un millón de casos de prueba automatizados. Si todas las comprobaciones
y los casos de prueba pasan, la generación se genera desde el tronco, se pone en
producción y se replica en todos los demás servidores de producción. Esto es más o
menos como 5,000 equipos de Google pequeños e independientes se mantienen
productivos y realizan diez mil de despliegue de producción cada día. Sin la
automatización de pruebas, esto no podría ser una opción.

La retroalimentación rápida y confiable es la única manera de tener un canal de

implementación seguro y proteger su integridad. Cuando se interrumpe el proceso
de implementación debido a fallos en los casos de prueba automatizados, su equipo
de DevOps corrige códigos y configuraciones erróneas antes de registrar cualquier
otro trabajo en su troncal. Además, siempre que encuentre un error en su canal de
implementación que podría haber sido identificado de antemano y prevenido con un
caso de prueba automatizado, también crea y agrega este caso de prueba a su
repositorio de automatización de pruebas.

Tipos de pruebas que puede automatizar

● Pruebas unitarias: valide funciones individuales, clases o módulos de sus
aplicaciones.
● Pruebas de aceptación: valide las características y los beneficios que sus
aplicaciones brindan a sus clientes.
● Pruebas de integración (servicio): valide la interacción de sus aplicaciones y
sus flujos de servicio de extremo a extremo.
● Prueba de rendimiento y estrés: valide cómo sus servicios se escalan (o no
escalan) con las cargas de clientes esperadas e inesperadas. Esto es
particularmente importante para los servicios más utilizados.
● Pruebas no funcionales: para validar la seguridad, la disponibilidad, la
capacidad y la escalabilidad.

Si a usted y su equipo les resulta difícil automatizar las pruebas de unidad y de

aceptación, pero dependen en gran medida de las pruebas de automatización de
integración (servicio), probablemente tenga una arquitectura muy pareja. Debes
identificar formas de desacoplar los elementos de tu arquitectura.

Conclusión
En este capítulo cubrimos la importancia de la automatización de pruebas en
DevOps. La automatización de pruebas es un elemento clave para entregar de
forma segura y rápida.
Independientemente de que su organización adopte DevOps o no, sin la
automatización de pruebas no hay manera de tener una organización de TI exitosa,
productiva y rentable de clase mundial que logre servir bien a sus clientes internos y
externos.

¿Cómo habilitar las implementaciones de código DevOps de bajo riesgo en su

producción?
En muchas organizaciones de TI puede observar que las implementaciones de
producción son complicadas y estresantes. Para mantenerse en paz, esto se
traduce en una tendencia a reducir la frecuencia de los despliegues de producción
tanto como sea posible. Entonces, las organizaciones inevitablemente se enfrentan
a implementaciones con tamaños de lotes más grandes que causan problemas aún
mayores. Este círculo vicioso destructivo solo empeora y, lamentablemente,
representa el estado de la mayoría de las organizaciones más grandes, incluidas
aquellas cuyos negocios centrales son el software y la tecnología.

Su equipo de DevOps tiene mecanismos incorporados de control y mitigación

de riesgos

En una organización de TI típica, el equipo de desarrollo crea software y el equipo

de operaciones se encarga de su implementación. En contraste, la metodología
DevOps cambia la dependencia de los mecanismos de control y mitigación de
riesgos de otros equipos independientes a su propio equipo autosuficiente y
competente. Para la implementación automatizada y los procesos de revisión por
pares, nuevamente dentro de su propio equipo.

Como toda la producción y los no entornos son activos tan importantes como el
software que produce su equipo de DevOps, su equipo de DevOps abarca estos
tres principios importantes:
1. Asegure la coherencia de todos los entornos en términos de sistemas
operativos, componentes, interfaces, niveles de parches, todas las demás
dependencias y, por supuesto, su propio software y configuraciones.
2. Es una actividad prioritaria número uno para corregir un impedimento que
rompe la coherencia de sus entornos.
3. Despliegue con las mismas técnicas en todos los entornos, de modo que el
ensayo de las implementaciones de producción se convertirá en una de sus
tareas y hábitos diarios.

Su mecanismo de implementación de autoservicio incorporado

Su mecanismo de implementación de autoservicio automatizado sigue el siguiente
patrón.
1. Código y registro troncal
2. Construir paquetes desplegables.
3. Valide paquetes desplegables, dependencias y disponibilidad de
configuración.
4. Validar la preparación del entorno.
5. Ejecutar pruebas automatizadas.
6. Registre toda la validación y los resultados de las pruebas automatizadas por
motivos de auditoría y cumplimiento.
7. Implementar paquetes en el entorno de destino.
8. Ejecutar pruebas automatizadas en el entorno de destino para validar la
implementación.
9. Monitorear las métricas del sistema, rendimiento y actividad del entorno
objetivo.
10. Proporcione retroalimentación rápida, corrija o restablezca la implementación
si algo sale mal.
Sus implementaciones NO son idénticas a sus lanzamientos

Con un mecanismo de autoservicio automatizado para implementar su código en

entornos de producción y no producción, su equipo de DevOps ahora está habilitado
y habilitado para realizar implementaciones diarias en sus sistemas. Debido a que
cada implementación individual no se puede categorizar como una característica o
lanzamiento de beneficios para sus clientes a los que sirve su equipo, su equipo de
DevOps necesita diseñar sus aplicaciones y / o sus entornos de manera que las
liberaciones no requieran cambios de código y otras implementaciones asociadas.

Patrón de despliegue azul-verde

Uno de los desafíos con la automatización de la implementación es el recorte en sí
mismo, llevando el software desde la etapa final de las pruebas hasta la producción
en vivo. Por lo general, debe hacer esto rápidamente para minimizar el tiempo de
inactividad. El enfoque de implementación azul-verde lo hace asegurándose de que
tiene dos entornos de producción, tan idénticos como sea posible. En cualquier
momento, uno de ellos, digamos azul para el ejemplo, es en vivo. A medida que
prepara una nueva versión de su software, realiza su etapa final de prueba en el
entorno verde. Una vez que el software está funcionando en el entorno verde,
cambia el enrutador para que todas las solicitudes entrantes vayan al entorno verde,
el azul ahora está inactivo.
Canary Deployment Pattern (aka The Dark Launch)
Los canarios una vez se usaban regularmente en la minería del carbón como un
sistema de alerta temprana. Los gases tóxicos como el metano o el dióxido de
carbono en la mina matarían al ave antes de afectar a los mineros. Las señales de
angustia del ave indicaron a los mineros que las condiciones no eran seguras.

Inspirado en los canarios de la industria minera, el despliegue de Canary es un

patrón para desplegar lanzamientos a un subconjunto de usuarios o servidores. La
idea es implementar primero el cambio en un pequeño subconjunto de servidores,
probarlo y luego extender el cambio al resto de los servidores. El despliegue del
canario sirve como un indicador de alerta temprana con menos impacto en el tiempo
de inactividad: si el despliegue del canario falla, el resto de los servidores no se ven
afectados.

Facebook y Google, junto con muchos de los principales gigantes de la tecnología,

utilizan un patrón de despliegue canario llamado "The Dark Launch". Gradualmente
lanzan y prueban nuevas funciones para un pequeño grupo de usuarios antes de
lanzarlas a todos. Esto les permite ver si lo amas o lo odias y evaluar cómo afecta el
rendimiento de su sistema. Facebook llama a su herramienta de inicio oscura
"Gatekeeper" porque controla el acceso de los consumidores a cada nueva función.
Se denomina lanzamiento oscuro porque estos lanzamientos de características
generalmente no se publican, sino que se lanzan sigilosamente al 1 por ciento,
luego al 5 por ciento, luego al 30 por ciento de los usuarios y así sucesivamente. A
veces, una nueva característica se pondrá en marcha durante unos días y nunca
volverás a verla. Probablemente, esto se debe a que no tuvo un buen desempeño o
la compañía solo quería obtener algunos comentarios iniciales para guiar el
desarrollo.

Patrón de lanzamiento del sistema inmune de clúster

Este patrón de lanzamiento es una extensión del patrón de despliegue de canario.
Requiere sistemas de monitoreo de la actividad del software y el rendimiento
estrechamente integrados con su proceso de lanzamiento.

En el patrón de despliegue de canario que se muestra arriba, una vez que se realiza
el despliegue inicial en un servidor de color naranja, sus sistemas de monitoreo
registran todas las métricas del sistema, rendimiento y actividad del software y
generan alertas tempranas si los problemas aumentan por encima de ciertos
umbrales. Esto da como resultado la reversión automática del código instalado del
servidor de color naranja.

Si las pruebas automatizadas en el servidor de color naranja y el sistema de

monitoreo brindan resultados positivos, su equipo de DevOps ahora tiene mucha
más confianza para implementar su código en todos los otros grupos de servidores
de color azul también. En resumen, Cluster Immune System Release Pattern ofrece
para su equipo de DevOps:
● Protección adicional para los problemas que la automatización de pruebas
podría pasar por alto.
● Respuesta rápida y acción de retroceso automatizado para problemas de
producción.

Función alterna-Feature Toggles

Con los conmutadores de funciones, puede activar y desactivar las funciones de su
aplicación. Por lo tanto, una vez que todos los códigos necesarios para una
determinada característica se implementan en su sistema de producción, el
lanzamiento de esta característica no es más que activar su conmutador. Los
conmutadores de funciones suelen ser configuraciones en los archivos de
configuración del sistema en tiempo de ejecución o bases de datos de configuración
del sistema.

Gracias a Feature Toggles, su equipo de DevOps ahora puede desactivar una

función si una implementación de Canary produce errores o una experiencia de
usuario subóptima. Con la alternancia de funciones, también tiene la capacidad de
deshabilitar recursos intensivos, pero características relativamente menos
importantes si su sistema tiene desafíos para escalar. Por lo tanto, incluso si su
sistema puede tener problemas para escalar con todas sus características, aún
puede permitir que sus clientes obtengan el mejor rendimiento de las funciones más
importantes de su software. Como ejemplo, en un portal de comercio electrónico,
puede desactivar temporalmente la alternancia de visualización de facturas, por lo
que su flujo de verificación tiene más recursos de CPU y memoria para consumir.

Además, en una arquitectura orientada a servicios, sus equipos de DevOps pueden

implementar diferentes versiones de servicios sin tener que activarlos. Una vez que
se implementan todas las nuevas versiones de servicios requeridos para una nueva
característica o flujo de servicios, puede activar la alternancia de estos servicios
para habilitar el nuevo flujo de servicios.

Arquitecto para lanzamientos más seguros

No existe una arquitectura perfecta para todos los productos y servicios de software
en todas las escalas.

Cuando la plataforma de TI de una organización de inicio se construye inicialmente,

una arquitectura monolítica es la mayoría de las veces la primera opción para
garantizar la entrada más rápida y barata al mercado y para validar el caso de
negocios. El problema con las arquitecturas monolíticas es que los aspectos
funcionalmente distinguibles (funciones básicas, funciones suplementarias,
interfaces de usuario y sistemas e integraciones) están todos entrelazados, en lugar
de contener componentes arquitectónicamente separados. Durante la vida útil de
muchas organizaciones grandes como Amazon, Google, Facebook y Ebay, deben
abandonar sus arquitecturas monolíticas para escalar rápidamente y permitir
lanzamientos de bajo riesgo y expansiones de sus funciones que sirven para sus
clientes. Y su siguiente dirección fueron las arquitecturas orientadas a servicios (o
microservicios) con la adopción del patrón de aplicación de Strangler.

Patrón de aplicación de Strangler para habilitar migraciones de bajo riesgo a

microservicios-Strangler Application Pattern To Enable Low Risk
Migrations to Micro-Services

Reemplazar completamente su complejo sistema puede ser una empresa enorme. A

menudo, necesitará una migración gradual a un nuevo sistema, mientras mantiene
el sistema anterior para manejar las características que aún no se han migrado. Sin
embargo, ejecutar dos versiones separadas de una aplicación significa que los
clientes deben saber dónde se encuentran las características particulares. Cada vez
que se migra una característica o servicio, los clientes deben actualizarse para que
apunten a la nueva ubicación.

Strangler Application Pattern reemplaza de manera incremental piezas específicas

de funcionalidad con nuevas aplicaciones y servicios. Cree una fachada que
intercepte las solicitudes que van al sistema heredado de back-end. La fachada
dirige estas solicitudes a la aplicación heredada oa los nuevos servicios. Las
características existentes se pueden migrar gradualmente al nuevo sistema, y ​los
consumidores pueden seguir utilizando la misma interfaz, sin saber que se ha
producido ninguna migración.

Ebay es una de las primeras organizaciones que han usado Strangler Application
Pattern para migrar su arquitectura monolítica heredada a microservicios.
Comenzaron su migración simplemente colocando sus aplicaciones detrás de API
universales bien definidas en el ecosistema de Ebay, para que no tuvieran que
volver a escribir todo el código existente en un solo intento de migración.
Reorganizaron sus grupos de ingeniería con pequeños equipos de 6 a 10
ingenieros. Un equipo tan grande como 10 personas ahora puede manejar la API
universal para la plataforma de subastas, que es la API de subastas más utilizada
en el mundo.

Conclusión

En la mayoría de los departamentos de TI, los equipos no son responsables de

crear patrones de implementación escalables y más seguros para el futuro y sus
arquitecturas asociadas. Y, sin embargo, construir una arquitectura y características
de aplicación que permitan a sus equipos realizar implementaciones más rápidas y
seguras es un requisito previo importante para tener éxito con DevOps.
Solo al permitir que sus equipos realicen implementaciones diarias, más rápidas y
de bajo riesgo, usted y sus equipos pueden aprovechar los beneficios de la
implementación continua y las versiones sin problemas.

¿Cómo protege su canal de implementación de DevOps?

Después de que usted y su equipo de DevOps construyan un flujo de despliegue de

trabajo para la entrega continua de su organización de TI, al adherirse a los
principios que ha aprendido anteriormente, ahora están autorizados a realizar
despliegues de producción de bajo riesgo sin aprobaciones externas. Ahora la
mayoría de sus implementaciones de producción no necesitan pasar por un proceso
de aprobación de cambios. Esto se debe a que confía en el diseño adecuado de su
metodología de entrega de software, las pruebas automatizadas, el monitoreo
automatizado y las alertas inteligentes de sus entornos, en lugar de simplemente
confiar en autoridades externas. Y aún así, tenga en cuenta que la seguridad y el
cumplimiento siguen siendo un deber importante de su equipo de DevOps. Esto no
solo es para cumplir con los requisitos de los legisladores, sino también para cuidar
bien a sus clientes. Por supuesto, su equipo de DevOps seguirá confiando y
colaborando con expertos en temas de seguridad y cumplimiento en su organización
y, sin embargo, el diseño de sistemas seguros compatibles con el ecosistema de
legislación que su organización navega debe ser una tarea y un hábito diario.

Tipo de cambios en sus sistemas de producción

● Cambios estándar: ​cambios de bajo riesgo, no requieren aprobaciones,

implementaciones rápidas porque están completamente automatizadas y
registradas. Las actualizaciones de las tablas de búsqueda de bases de
datos, actualizaciones de contenido, cambios de estilo, sistema operativo
estándar, base de datos u otros parches de componentes externos son
algunos de los cambios estándar.
● Cambios normales: los cambios de alto riesgo, requieren la aprobación de
la Junta Asesora de Cambios (CAB, por sus siglas en inglés), el CAB espera
que el Formulario de Solicitud de Cambio (RFC) evalúe los cambios, requiere
largos plazos de entrega porque la mayoría de las veces los miembros del
CAB no tienen el conocimiento suficiente para evaluar los cambios.
Mantienen cambios para tomar decisiones en última instancia, en función de
su experiencia, intuición y sesgo sobre quién solicitó cambios.
● Cambios urgentes: cambios de alto riesgo, requieren la aprobación de la
alta gerencia. Los errores críticos en los sistemas de producción que afectan
a los clientes, las correcciones de las implementaciones problemáticas, los
 parches de seguridad y las restauraciones de servicios son algunos de los
cambios urgentes.

Independientemente de los tipos de cambios, usted y su equipo de DevOps deben

documentar todos los cambios en sus sistemas de gestión de cambios y
planificación de trabajo (como Remedy y Jira), para que el trabajo sea visible para
todos dentro y fuera de su equipo de DevOps.

Use su registro de seguimiento de un exitoso historial de implementaciones

automatizadas para convertir los cambios normales en cambios estándar

Solo al aumentar la proporción de cambios estándar sobre los cambios normales,

puede evitar las aprobaciones de la Junta Consultiva de Cambios (CAB) y puede
permitir un flujo más rápido y una canalización de implementación de mayor calidad.

Usted y su equipo de DevOps ahora utilizan su historial de implementaciones

automatizadas exitosas para convertir tantos cambios normales como sea posible
en cambios estándar. Le muestra a CAB su historial de implementaciones, la lista de
incidentes de producción y los prueba que las implementaciones de producción
automatizadas no causan ninguno o son solo incidentes insignificantes en sus
sistemas de producción.

Acelerar los despliegues de cambios normales

Para los cambios que aún deben permanecer normales, automatice el proceso de
composición del Formulario de solicitud de cambio (RFC). Enlace todos los
resultados de pruebas automatizadas y no automatizadas, incidentes resueltos y no
resueltos, registros de monitoreo y registros de sistemas de no producción a RFC.
Intente simplificar el trabajo de CAB y brinde toda la información que está buscando
en la primera versión de RFC, para que pueda acelerar las aprobaciones de CAB
tanto como sea posible.

Una vez aprobado, habilite las implementaciones de un solo clic de los cambios
normales. Revise regularmente los tipos de cambios normales con CAB, identifique
y defina las expectativas que los convencerían de convertir los cambios normales en
cambios estándar, de modo que pueda implementar automáticamente la mayoría de
sus cambios en su organización DevOps.

Reduzca la burocracia y la confianza en otros en su organización de DevOps

Cuanto más grande se vuelve una organización, mayor es la burocracia alimentaria.
La burocracia tiene una habilidad invisible para crecer exponencialmente y vivir para
siempre. Una vez que confíe en la autoridad y los mecanismos de control un nivel
por encima de usted para aprobar su propio trabajo, ya no se sentirá facultado y
responsable de los resultados de su propio trabajo. Esto hará que la autoridad un
nivel por encima de usted falle regularmente.

Finalmente, esta autoridad también requeriría otra autoridad para confiar y ser
auditada. Esta espiral descendente solo se alarga hasta la próxima reorganización
en su empresa. Después de la reorganización, hay casi el 100% de que una nueva
espiral descendente con una forma ligeramente diferente reemplazará su espiral
descendente real.

Su empresa debe recordar que la separación de tareas y los mecanismos de

dependencia y control fuera de su propio equipo no solo reducirán y reducirán la
calidad del flujo de entrega de su software, sino que también harán que su
organización sea menos segura. Una importante organización financiera de los
Estados Unidos se convirtió en víctima de un fraude en los cajeros automáticos
debido a una puerta trasera que un desarrollador de software había incorporado en
el software de cajeros automáticos. Ninguno de los auditores externos, expertos en
seguridad externos, oficiales de cumplimiento externos y figuras de autoridad de
CAB externos pudieron identificar el código fuente fraudulento implementado en los
sistemas de producción. Este fraude solo se pudo identificar dentro del equipo que
se desarrolló al implementar técnicas DevOps fundamentales, como la inspección
de los registros de código y las revisiones de código.

Para poder realizar una entrega rápida y segura, necesita reducir la dependencia de
los demás y la separación de tareas, ya que solo evitarían que su equipo de
DevOps asumiera la responsabilidad. En su equipo de DevOps, debe implementar
otros mecanismos de control, como la inspección de los registros de código, la
programación de pares, las revisiones de pares, las pruebas automatizadas y el
monitoreo. Si la separación de tareas es obligatoria debido a razones legales, sus
controles incorporados en su equipo de DevOps aún permitirán a los auditores y
responsables de cumplimiento dar decisiones mejores, informadas y más rápidas.

Conclusión

DevOps aporta una dimensión nueva y dinámica para el cumplimiento y la seguridad

de la información. Donde su infraestructura es el código, cuando el código hace que
sus sistemas aparezcan y desaparezcan, y donde su código se implementa
automáticamente, no es un proceso trivial para que los auditores entiendan lo que
realmente está sucediendo. Este es un nuevo desafío, pero también es una
oportunidad para crear y desplegar mecanismos y oficiales de auditoría y
cumplimiento más ágiles e inteligentes.
En el equipo de DevOps, la seguridad de la información, el cumplimiento y la
implementación más rápida son tareas de todos. Es un objetivo importante para su
equipo DevOps permitir que los oficiales de cumplimiento accedan a información de
autoservicio, registros, informes y métricas que demuestren una entrega de alta
calidad de su equipo DevOps. Esto simplificará los procesos de aprobación
burocráticos o, incluso mejor, eliminarlos por completo.

¿Cómo se asegura la seguridad de la información de DevOps?

En la mayoría de las organizaciones, las preocupaciones de seguridad de la

información son una de las objeciones más frecuentes contra la adopción de
DevOps. Y, sin embargo, la metodología DevOps es una de las mejores técnicas
para ofrecer los sistemas más seguros del mundo.

En muchas organizaciones, quizás también en su organización, la proporción de

especialistas en seguridad de la información en todo el equipo de ingeniería de
software es de 1/100. En otras palabras, en un equipo de ingeniería de software con
100 personas, por lo general, se encuentra con un solo especialista en seguridad de
la información. Esto se traduce en largos plazos de entrega para resolver cualquier
problema relacionado con la seguridad del software, retrasos en las entregas de
software e incluso un peor nivel de seguridad de la información para sus clientes.

Si ha aprendido una sola cosa de su experiencia en la entrega de software, esto

debe ser que las detenciones al final de los proyectos son malas, pero las
comparaciones relacionadas con los problemas de seguridad son aún peores. Por lo
tanto, cada miembro de su equipo de DevOps debe adoptar la parte de seguridad
de la información del trabajo diario de ingeniería, en lugar de una casilla de
verificación marcada (o sin marcar) al final de sus proyectos.

Involucrar a especialistas en seguridad de la información en etapas tempranas

del proceso de ingeniería de software

Para garantizar que un problema de seguridad de la información no se convierta en

un obstáculo y un cuello de botella justo antes de la implementación de su software,
involucre a especialistas en seguridad de la información en las etapas iniciales de su
proceso de ingeniería de software. Los invita a demostraciones, planificación
temprana y sesiones de revisión, para que tengan una idea del negocio con el que
está asociado su software. De esta manera, pueden juzgar mejor los posibles
riesgos y problemas de seguridad de la información, por lo que apoyan al equipo de
DevOps para definir los objetivos de seguridad de la información y cumplimiento que
deben manejarse durante el curso de su proceso de ingeniería de software.

La seguridad de la información es parte del trabajo diario

Usted y su equipo de DevOps necesitan realizar un seguimiento de las funciones de

seguridad así como los incidentes de seguridad con sus herramientas estándar de
planificación de tareas y gestión de incidentes, en lugar de utilizarlas en las
herramientas de gestión de cumplimiento a las que su equipo de DevOps no presta
mucha atención. Siempre que haya un problema relacionado con la seguridad de la
información en su arquitectura de software, diseño o sistemas en ejecución, informe
a su equipo de DevOps sobre estos problemas. Haga que comprendan las causas
fundamentales de estos problemas y cómo deberían pensar y abordar situaciones
similares en el futuro para no recrear el mismo problema.

En términos de seguridad de la información, el enfoque táctico de su equipo de

DevOps es:
● Para evitar que los errores de seguridad se repitan.
● Integrar los objetivos de seguridad en los objetivos del proyecto, herramientas
de planificación y seguimiento.
● Hacer que las pruebas de seguridad formen parte de las pruebas
automatizadas en su canal de implementación.
● Para definir herramientas de autoservicio reutilizables y bibliotecas de
software que combinen las mejores prácticas de seguridad de la información
de su organización, después de realizar un análisis completo de la seguridad
de la información desde todos los ángulos de ciertas características de
productos y servicios.
● Educar y confiar en los desarrolladores de DevOps y los ingenieros de
operaciones de DevOps cuyas competencias básicas no son necesariamente
seguridad de la información.

Cree bibliotecas, procedimientos, planos, arquitecturas y diseños seguros

para su software
Al construir dichos activos reutilizables, su equipo de DevOps debe estandarizar los
aspectos de seguridad de la información de su software en varias dimensiones
críticas, tales como:
● Comunicación y transferencia de datos entre clientes y software.
● Almacenamiento de datos.
● Entornos seguros.
● Sistemas operativos, bases de datos y configuraciones de herramientas,
componentes y otras interfaces de terceros para evitar vulnerabilidades.
● Almacenamiento de contraseñas.
 ● Manejo de contraseñas olvidadas.
● Manejo del registro de información confidencial del cliente.
● Evitar las secuencias de comandos entre sitios (XSS).
● Inyecciones de SQL.
● Otras vulnerabilidades de seguridad de la información específicas de su
empresa y el ecosistema de legislación en el que opera su empresa.

Técnicas recomendadas para la seguridad de la información con la metodología

DevOps
● Análisis estático: análisis de código para identificar las puertas traseras y
las vulnerabilidades de seguridad.
● Análisis dinámico: análisis de puerta trasera y vulnerabilidad mientras el
sistema se está ejecutando. Supervisión y análisis continuos de las
operaciones de CPU, RAM, E / S de red y E / S de disco en entornos no
productivos y de producción.
● Análisis de dependencia: análisis estático y dinámico para herramientas
externas y dependencias que contienen código fuente que no puede
controlar. Cuando su organización utiliza herramientas, bibliotecas o servicios
de terceros, también hereda sus problemas de seguridad de la información.
No se olvide de revisar los incidentes de seguridad abiertos de componentes
de terceros y el historial de los proveedores de la rapidez con la que rectifican
dichos problemas.
● Seguridad para el acceso al código fuente: ​su equipo de DevOps debe
usar una infraestructura de clave pública donde todos deben poseer una
clave pública y una privada. De esta manera, todos los registros de entrada /
salida y las lecturas del repositorio de códigos se autorizan, se supervisan y
todos los cambios están firmados por sus respectivos artistas.
● Integre el monitoreo de seguridad (telemetría) en sus entornos: para
verificar los detalles de uso del sistema para identificar violaciones de
seguridad. Estas violaciones suelen estar indicadas por un número excesivo
de algunos eventos críticos generados por el usuario, como intentos fallidos
de inicio de sesión, número de solicitudes de recuperación de contraseña y
transacciones de compra del mismo usuario con varias tarjetas de crédito
diferentes, etc.

Conclusión
En este capítulo, se le han proporcionado algunas recomendaciones sobre la forma
de seguridad de la información de DevOps. La seguridad de la información en sí
misma es un arte y una ciencia, por lo que el enfoque articulado en este capítulo no
pretende convertirlo en un experto en seguridad de la información, sino en explicar
cómo la metodología de desarrollo y entrega del software DevOps se acerca a la
seguridad de la información.

Es evidente que DevOps empodera y muy bien integra la seguridad de la

información y los objetivos de cumplimiento de su organización al trabajo diario de
sus ingenieros de DevOps al hacer que la seguridad de la información sea el trabajo
de todos en su organización. Las empresas más dinámicas del mundo ya han
demostrado que esta es una forma segura de brindar servicios seguros a sus
clientes.

¿Cómo debería habilitar la retroalimentación de su DevOps?

En su ecosistema de TI donde las demandas y solicitudes de sus clientes se
vuelven cada vez más desafiantes, usted y su equipo de DevOps deben esforzarse
por mejorar continuamente la calidad del trabajo que está realizando. Para lograr
esto, habilita bucles de retroalimentación rápidos, continuos y confiables de derecha
a izquierda en su flujo de valor.

Estos bucles de retroalimentación le ayudarán a enfrentar rápidamente los

impedimentos mientras son pequeños, baratos y fáciles de eliminar. Te ayudarán a
crear una cultura de aprendizaje organizacional mientras haces tu trabajo. Cuando
surgen problemas, usted y su equipo de DevOps los tratan como oportunidades
para aprender y mejorar la calidad de sus productos y servicios de software.

¿Por qué necesita calidad incorporada habilitada por DevOps Feedback

Loops?
Según su experiencia en la industria de la ingeniería de software, debe tener tanto
claro que, en un sistema complejo, nadie puede saberlo todo. Incluso hacer
exactamente el mismo trabajo dos veces no produce los mismos resultados. Debido
a que este nivel de incertidumbre de resultados no es tolerable en ninguna empresa,
las organizaciones tienden a desarrollar el control y la confianza en los mecanismos
de control de calidad mediante el despliegue de listas de verificación, auditorías,
cumplimiento, profesionales de control de calidad y microgestión. Y sin embargo,
todas estas medidas a veces no son suficientes para evitar errores y
equivocaciones.

Por lo tanto, la creación de una organización que genere calidad incorporada

comienza con la aceptación de errores y errores parte de su trabajo diario.

Diseñar un sistema seguro de cultura laboral

Se diseña un sistema seguro de cultura laboral. Nadie en su equipo de DevOps
tiene miedo de cometer errores porque usted y su equipo de DevOps saben que los
errores se detectan y solucionan rápidamente cuando son pequeños y antes de que
causen catástrofes como defectos importantes, tiempos de inactividad de los
servicios y críticas negativas de los clientes.

Al crear un sistema seguro de cultura de trabajo, usted, su equipo de DevOps y toda

su organización empresarial y de TI disfrutarán de los siguientes beneficios:
1. Se gestionará la complejidad de sus sistemas, por lo que los problemas en
los diseños y las operaciones se detectarán rápidamente.
2. Los problemas se resuelven rápidamente mientras son pequeños. Resolver
problemas resultará en la construcción espontánea de nuevos conocimientos
y experiencias organizacionales.
3. Los nuevos conocimientos y experiencias se distribuyen y distribuyen a toda
su organización.
4. Los líderes en su organización DevOps desarrollan otros líderes que crean y
mejoran continuamente los sistemas de trabajo seguros.

Identificar problemas mientras ocurren

Si el mecanismo de retroalimentación en su organización es lento, infrecuente y
tardío, también es tarde y costoso evitar resultados indeseables. Al igual que los
buenos días de entrega de software en cascada, cuando las aplicaciones se crean
durante un año antes de que se muestren por primera vez a los clientes, y luego se
vuelven a escribir para otro año, ninguna de las empresas de hoy tiene el lujo de
trabajar con este modus operandi.

Su objetivo es crear bucles de retroalimentación rápida. Cuando su trabajo se

mueve de izquierda a derecha en su flujo de valor, debe proporcionar
continuamente retroalimentación de derecha a izquierda. Construir calidad en su
organización DevOps tiene que ver con construir ciclos de retroalimentación rápidos.
Cuando se presenta un problema, su equipo de DevOps lo identifica cuando se
produce por primera vez en su flujo de valor. Usted y su equipo de DevOps
resuelven rápidamente los problemas y validan constantemente la correlación entre
las expectativas de los clientes (clientes internos, clientes externos y todos los
demás interesados ​en el flujo de valor que se ven afectados por su trabajo) y su
implementación para cumplir con estas expectativas. Los ciclos de retroalimentación
rápidos no solo le permiten solucionar rápidamente los problemas, sino que también
le permiten aprender de ellos y evitar que vuelvan a cometer los mismos errores en
el futuro.
Deshaga sus errores cuando sean más fáciles, rápidos y económicos de
solucionar
La búsqueda rápida de problemas le permite solucionarlos rápidamente también. De
otra manera,
● El costo y el esfuerzo para solucionarlos crecen exponencialmente y usted
permite que se acumulen las deudas técnicas (soluciones alternativas en la
parte superior de las soluciones alternativas).
● Los errores proceden a los centros de trabajo posteriores en su flujo de valor
que probablemente contribuyan a la construcción de otros errores.
● Los errores ocurren una y otra vez lejos del centro de trabajo donde se
introdujeron por primera vez y requerirán más soluciones y trabajarán para
deshacerlos.
● Los recuerdos sobre por qué ocurrieron los errores en primer lugar se
desvanecieron y las circunstancias contribuyeron a la construcción del
cambio de errores. Si los errores se identifican por primera vez meses
después de su introducción, realmente no puede descubrir la verdadera
causa raíz y, lo peor de todo, no puede aprender de ellos. Haría una solución
para salvar el día y pasar a la siguiente solución. Ya sabes que esto es
exactamente lo que quieres evitar con DevOps.

Anime a su equipo de DevOps y a usted mismo a elevar su voz y a construir

mecanismos de retroalimentación continua para identificar y corregir errores
rápidamente. NO introduzca el trabajo erróneo en la parte superior del trabajo
erróneo. En otras palabras, no permita que su equipo de DevOps desarrolle nuevas
características antes de corregir errores que podrían tener un impacto negativo en la
construcción de estas nuevas características. La mejora continua de la calidad de su
trabajo y la eliminación continua de errores mientras ocurren se asegurará de que
genere los mejores productos y servicios de software en su mercado particular.

No presione las decisiones de control de calidad más allá de donde se realiza

el trabajo real
Empujar las decisiones sobre los controles de calidad más lejos de donde se realiza
el trabajo reduce la calidad, aumenta los plazos de entrega, disminuye la fuerza de
la retroalimentación entre causa y efecto y reduce su capacidad de aprender de sus
errores.

En pocas palabras:

● No exija a sus equipos que realicen un trabajo de control de calidad manual

que se pueda automatizar.
 ● No requiera aprobaciones de personas ocupadas que no tienen un
conocimiento limitado sobre el trabajo que se está realizando.
● No cree grandes documentaciones para aprobaciones que pronto se volverán
obsoletas debido a la naturaleza de su trabajo.
● No envíe grandes lotes de trabajo a las autoridades para obtener
aprobaciones.

En su lugar, cada miembro de su equipo de DevOps debe encontrar, corregir,

compartir, hablar y enseñar sobre los errores en su propia área de control. La
programación de pares, las revisiones entre pares, las pruebas automatizadas, la
inspección de los registros de código, los puntos de control internos, las
demostraciones muy frecuentes deben hacer que la responsabilidad de todos sea
responsabilidad de todos, en lugar de la responsabilidad de un departamento
dedicado de control de calidad.

Conclusión
Usted y su equipo de DevOps siempre están conscientes de que le están pagando
para servir a sus clientes. Por lo tanto, siempre debe trabajar para el mejor interés
de sus clientes internos y externos.

Y, sin embargo, el siguiente centro de trabajo en su flujo de valor es particularmente

importante. Debes optimizar tu trabajo para ellos con empatía. Debe generar flujos
de retroalimentación rápidos y confiables con ellos para permitir un flujo rápido,
suave y de alta calidad en su flujo de valor, de modo que su equipo de DevOps
pueda identificar y resolver problemas lo más rápido posible.

¿Cómo se crea una supervisión (telemetría) para administrar el ciclo de vida

de su software DevOps?
Por su experiencia en la industria de TI, ya puede decir fácilmente que cuando las
cosas van mal, no es trivial identificar las causas raíz de los problemas. El problema
puede estar en sus aplicaciones de software, en sus entornos o en otros
componentes en los que sus aplicaciones y entornos estén integrados.

Cuando observa el desarrollo de plataformas cliente y servidor relativamente

complejas durante los últimos 50 años, un tipo de evento que ocurre con frecuencia
es el siguiente: cuando un servidor comienza a comportarse de manera subóptima,
genera errores y no se entrega, simplemente lo reinicia Esperando que el reinicio
resolverá los problemas. De hecho, un reinicio a veces puede deshacer
temporalmente un problema que nunca has comprendido. Y, sin embargo, si esto no
ayuda, su próxima parada son los desarrolladores y evaluadores que no entregaron
correctamente y que no identificaron correctamente los problemas mientras se
probó el software. Todo este caos no solo afectará la satisfacción del cliente por sus
servicios, sino que también contaminará el clima laboral en su organización.

Las organizaciones Champion DevOps apenas reinician sus servidores durante la

rectificación de sus problemas. Despliegan enfoques sistemáticos para identificar y
resolver problemas. Se basan en la telemetría de producción para comprender las
causas raíz y los factores que contribuyen a los problemas en lugar de reiniciar a
ciegas los servidores. Tienen 96 veces mejor MTTR (tiempo medio de recuperación)
que otras organizaciones. En otras palabras, resuelven sus problemas de
producción 96 veces más rápido que una compañía promedio. La práctica técnica
más destacada de las organizaciones campeonas de DevOps es que implementan
la telemetría en su software y en sus aplicaciones.

¿Qué es la telemetría?

En términos bastante simples, la telemetría es el proceso de registrar el

comportamiento de sus sistemas.

Para que esto suceda, debe diseñar su software, sus entornos de producción y
preproducción y su canal de implementación de manera que generen registros de
telemetría de forma continua. Su objetivo es implementar suficiente telemetría para
que pueda confirmar que sus servicios funcionan correctamente en sus entornos de
producción. Cuando ocurre un problema, gracias a la visualización de sus registros
de telemetría, puede comprender rápidamente cuál es el problema y tomar
decisiones informadas para rectificarlo.

Además, la telemetría lo ayuda a validar su comprensión de lo que está sucediendo

en sus sistemas de producción en comparación con lo que está sucediendo en sus
sistemas de producción en la realidad, para que pueda ver fácilmente si están
relacionados.

Construya su infraestructura de telemetría

Para tener telemetría necesita tener dos componentes principales en su lugar:
1. Registro de métricas de telemetría: todas las organizaciones de alto
rendimiento de DevOps registran constantemente cientos de miles de
métricas en cada capa de sus aplicaciones, entornos y procesos de
implementación. Algunos ejemplos son eventos en la lógica empresarial,
como el número de ventas o las comprobaciones de estado de la plataforma
del servidor, como el monitoreo de sistemas operativos, bases de datos,
operaciones de E / S de disco, operaciones de E / S de red, RAM, CPU y
seguridad.
 2. Una plataforma central para administrar las métricas de telemetría: esta
plataforma almacena métricas y eventos. Permite la visualización,
tendencias, muestreo, alerta, detección de anomalías. Convierte los registros
en métricas, como el número de excepciones fatales en una aplicación de
software. Además, los eventos en su canal de implementación, tales como
confirmaciones, retrocesos, instalaciones, desinstalaciones, resultados de
pruebas automatizadas en entornos de producción y preproducción también
deben almacenarse en la misma infraestructura de telemetría.

Usted, su equipo de DevOps y todas las demás partes interesadas que trabajan
junto con su equipo de DevOps deberían poder recuperar información de su
Plataforma de telemetría a través de API y GUI de autoservicio, en lugar de abrir
tickets para enviar solicitudes para acceder a información de telemetría.

Toda su información de telemetría debe ser 100% accesible para toda su

organización, excepto las métricas de telemetría que pueden violar la privacidad y
poner en peligro la seguridad de sus clientes.

Tipos de métricas de telemetría

1. Métricas de la capa de negocios: como los resultados de las pruebas A / B,
los beneficios, los ingresos, la cantidad de usuarios nuevos, la duración
promedio de las sesiones, la cantidad de órdenes completadas y la cantidad
de cajas abandonadas.
2. Métricas de la capa de aplicación: como los tiempos de respuesta de la
aplicación, la duración de las transacciones, el número de volcados de núcleo
y el número de excepciones fatales.
3. Métricas de la capa de infraestructura: ​como el tráfico del servidor, las
operaciones de E / S del disco, las operaciones de E / S de la red, la memoria
RAM, la CPU y el uso del disco.
4. Métricas de la capa del cliente: como los tiempos de respuesta de las
aplicaciones cliente y los errores de los clientes en la web, dispositivos
móviles, JavaScript y otras aplicaciones cliente.
5. Métricas de la capa de canalización de la implementación: tales como
controles, tiempos de entrega, frecuencias, estado de los entornos y
resultados de estado verde / ámbar / rojo después de la ejecución de pruebas
automatizadas.

Es profundamente importante construir sus métricas dentro de jerarquías en varias

categorías y subcategorías anidadas, para que usted y su equipo de DevOps
puedan interpretarlos fácilmente.
Facilite la comprensión de las entradas de registro de sus aplicaciones que luego se
convertirán en métricas de telemetría. Al igual que usted agrupa los registros en
varias categorías de eventos, haga una agrupación similar para sus métricas de
telemetría también. Un ejemplo de tal agrupación es: depuración, información,
advertencia, error y niveles fatales de métricas de telemetría.

Use su información de telemetría para guiar la resolución de problemas

Si su organización tiene una cultura de culpa, nadie quiere hacer cambios en los
sistemas de producción totalmente visibles y nadie está dispuesto a mostrar la
telemetría. En esta atmósfera, las causas raíz de los problemas apenas se
identifican correctamente y, lo que es peor, no ocurren nuevos aprendizajes
organizacionales.

Para asegurarse de que puede usar su telemetría para guiar la resolución de

problemas, asegúrese de que la creación de telemetría se convierta en un trabajo
diario para todo su equipo de DevOps. Cree bibliotecas fáciles de usar, para que
una línea de código cree fácilmente un registro de telemetría.

Además, cree registros de telemetría para los eventos de escritura de su versión

que controla el sistema y los entornos en ejecución, por lo que, desde el monitoreo
de la telemetría, será muy claro y fácil visualizar la correlación entre los cambios que
realiza en sus sistemas y su impacto asociado en sus clientes.

A modo de ejemplo: en el cuadro a continuación, es muy claro que uno de los

últimos despliegues del jueves por la noche es una causa raíz probable que
incrementó los eventos de compra fallidos de su flujo de pago.
La telemetría le ayudará a comunicarse acerca de los problemas en detalle. Usted y
sus equipos de DevOps no tienen nada que ocultar de ustedes mismos y de sus
partes interesadas. Por lo tanto, constantemente monitorea y presenta gráficos
como los anteriores a sus partes interesadas en tiempo real para admitir una rápida
identificación de los problemas y para ver las posibles relaciones de causa y efecto
entre sus implementaciones y eventos empresariales clave. La gente de negocios
se convierte en una mejor comprensión y transparencia sobre el trabajo que usted y
su equipo realizan. Además, los desarrolladores de DevOps y los ingenieros de
operaciones de DevOps ven la correlación entre incidentes y despliegues.

La telemetría le permite ver los problemas mientras son fáciles y baratos de

solucionar, por lo que los deshace antes de que se propaguen y genera otros
problemas en ellos.

Con la telemetría, usted y su equipo de DevOps pueden identificar patrones de

métricas clave de negocios y tecnología y crear alertas si ocurren anomalías. Sus
umbrales de alerta al principio pueden ser falsos y pueden generar falsos positivos.
Esto es totalmente normal. No te asustes. Y no permita que nadie socave su
esfuerzo e inversión para construir su infraestructura de telemetría. Como todo lo
demás en sus sistemas complejos, también lo resolverá y ajustará los umbrales
aceptables para sus alertas, para que funcionen para usted, sus clientes y su
negocio.

Conclusión
Las organizaciones Champion DevOps identifican el impacto de los problemas como
métricas de negocios medibles, como la cantidad de clientes perdidos o la pérdida
de ingresos. Por lo tanto, todos en sus organizaciones DevOps se vuelven más
sensibles con la telemetría. No solo en producción, sino también en entornos de
preproducción. Invierten tiempo y recursos para construir y utilizar la telemetría, y
confían en el uso de la telemetría para identificar y deshacer rápidamente sus
errores.

¿Por qué debería habilitar comentarios para sus implementaciones de

producción más seguras?
En mercados competitivos como el suyo, tener un departamento separado de
control de calidad y operaciones de su equipo de desarrollo no es realmente
aceptable si desea servir rápidamente a sus clientes y cumplir constantemente con
sus demandas. Y, sin embargo, aunque la mayoría de los desarrolladores se quejan
de la burocracia en sus organizaciones, cuando se les brinda la oportunidad de
colaborar con especialistas de control de calidad y operaciones en sus propios
equipos, todavía tienen miedo de realizar despliegues de producción no
supervisados ​por su cuenta. Esto nos lleva a las técnicas y medidas que debemos
implementar para garantizar implementaciones de producción más seguras.

Cómo habilitar el flujo continuo de DevOps

Para permitir un flujo suave y continuo, la salsa secreta de la mayoría de las

organizaciones de DevOps exitosas son las implementaciones frecuentes en
pequeños lotes de cambios en sus sistemas de producción. Por lo tanto, todos los
integrantes de los equipos de DevOps pueden evaluar y comprender los cambios y
corregirlos cuando sea necesario.

La construcción de un canal de despliegue automatizado no es completamente

suficiente. Debe integrar la telemetría operativa en su canal de implementación para
obtener rápidamente comentarios sobre los resultados de sus cambios en los
entornos de producción y preproducción. Además, en su organización necesita crear
un entendimiento cultural común acerca de: Todos los integrantes de su equipo de
DevOps son responsables de la salud y la continuidad exitosa de toda la cadena de
valor y el flujo de implementación.

Confíe en la telemetría para sus implementaciones más seguras

Nunca consideras un cambio y una implementación marcados como "realizados"

hasta que pruebes que funciona para lo que fue diseñado y codificado. Después de
sus implementaciones, monitorea de cerca las métricas de los módulos modificados,
las métricas recién creadas, si las hubiera, y las métricas de otros componentes en
su sistema que pueden verse afectadas por su cambio.

Si bien utiliza sus entornos de preproducción para ejecutar pruebas automatizadas y

monitorea su sistema bajo prueba con su infraestructura de telemetría, todavía
habrá problemas en sus sistemas de producción. No puede evitar que ocurran todos
los problemas, pero puede estar muy bien preparado para corregirlos cuando
ocurran. Si un cambio rompe su canal de implementación, trae a todos los expertos
en la materia requeridos para deshacer el problema y hacer que su canal de
implementación vuelva a funcionar. Los siguientes son tres de los métodos
utilizados con frecuencia para resolver problemas:
1. Desactive la función: ​Esta es la forma más fácil de solucionar un problema.
No requiere un despliegue de código urgente. Simplemente apaga la función
con la función de alternar. No tiene que corregir rápidamente piezas erróneas
en su implementación, por lo que su equipo de DevOps puede tomarse el
tiempo para identificar correctamente la causa raíz de este problema y
 mejorar sus técnicas para garantizar que ese problema no vuelva a ocurrir en
el futuro.
2. Solucione el problema: implemente un nuevo código para solucionar el
problema. Si bien el arreglo hacia adelante es una forma peligrosa de abordar
los problemas de producción en las organizaciones de TI tradicionales, en las
organizaciones de DevOps puede funcionar muy bien, de manera eficiente y
segura si se implementa la automatización de pruebas, el despliegue
automatizado y la telemetría de producción integral.
3. Deshacer el cambio: elimina el código erróneo, por lo que el problema (con
suerte) desaparece.

Haga que sus desarrolladores obtengan comentarios de la vida real de las

operaciones

Rote a su gente en el equipo de DevOps para manejar las responsabilidades de los

equipos de operaciones, de modo que manejen y traten los incidentes operativos.
De esta manera, todos en su flujo de valor ganan un sentido de los desafíos y
responsabilidades de los centros de trabajo posteriores. Ponga a sus
desarrolladores, evaluadores, arquitectos, diseñadores, gerentes y directores en
tareas operativas no programadas, para que reciban llamadas de alerta de
incidentes a las 3 am de la mañana. Esto hace que todos los integrantes de su flujo
de valor construyan una opinión sólida sobre las consecuencias de las decisiones
que toman durante sus trabajos diarios.

Tal rotación alienta a los especialistas en operaciones a no sentirse aislados y solos.

Todos los miembros de su equipo de DevOps apoyan el establecimiento de un
equilibrio adecuado entre la solución de incidentes de producción, la reducción de la
deuda técnica y el desarrollo de nuevas funciones. Es bastante claro que cuando
despierte a los arquitectos y desarrolladores a las 3 am de la mañana, los incidentes
se solucionarán más rápido que nunca.

Cuando se les pide a los desarrolladores que observen a sus clientes mientras los
clientes usan su software, tienen muchos momentos de aha para descubrir qué
deben mejorar de inmediato. Esto también es cierto cuando los arquitectos,
diseñadores, desarrolladores y evaluadores monitorean internamente otros centros
de trabajo posteriores en el ciclo de vida de la ingeniería de software. Cuando
comprenden el impacto de su trabajo en los centros de trabajo intermedios, obtienen
un nuevo ángulo para mejorar la calidad de su trabajo y afinar los resultados para
ayudar a que los centros de trabajo intermedios tengan un mejor desempeño. Todos
los integrantes de su equipo de DevOps comienzan a asumir los requisitos
operacionales no funcionales parte de su trabajo diario dentro de sus atrasos. Y esto
solo es posible al permitir bucles de retroalimentación rápidos y continuos dentro de
su organización DevOps.

Haga que sus desarrolladores operen su propio sistema

Es muy difícil transferir experiencias de aprendizaje de sistemas de producción

reales a equipos de desarrollo. Por lo tanto, algunas organizaciones de DevOps
prominentes, como Google, hacen que sus equipos de desarrollo sean responsables
de las operaciones del software durante y después del lanzamiento inicial del
producto. En este estado gestionado por el desarrollador de un producto, los
ingenieros de operaciones actúan como consultores. Una vez comprobado que el
producto es lo suficientemente estable en producción durante aproximadamente 6
meses, se entrega a los equipos de operaciones. Esta transferencia solo puede
suceder si el producto en producción ya cumple con una serie de comprobaciones,
como defectos pasados ​y en curso, cobertura de telemetría, incidentes fuera del
horario de trabajo, diseño arquitectónico acoplado de forma flexible y seguridad de
cambios y despliegue.

Si el producto en estado administrado de operaciones terminó con problemas

significativos de codificación y diseño, puede ser devuelto a los desarrolladores. En
la etapa administrada por el desarrollador, los desarrolladores están a cargo de
estabilizar el software, mientras que los ingenieros de operaciones actúan como
consultores.

Conclusión
En este capítulo, se cubren varias técnicas para garantizar un flujo exitoso y seguro
de las tuberías de implementación en su organización DevOps.
Estas técnicas demuestran el respeto mutuo ejemplar y la colaboración entre los
desarrolladores y los ingenieros de operaciones en sus equipos de DevOps.

¿Cómo mejora sus hipótesis con DevOps y potencia su experiencia y

organización de DevOps impulsada por el aprendizaje?
En las organizaciones de TI típicas que solía crear, lo más probable es que todavía
esté creando varias versiones de productos y características del producto sin validar
si los resultados de negocio deseados de estos productos y funciones se cumplen o
incluso si están siendo utilizados por algunos seres humanos vivos. . La forma más
ineficiente de probar un modelo de negocio o una idea de producto y característica
es que: usted construye un producto y servicio de software completo para ver si la
demanda comercial prevista ya existe y su idea puede satisfacer esta demanda.
Antes de crear un producto y un servicio completo, debe preguntar: "¿Por qué
debería crear esto?", "¿Realmente vale esto mi tiempo y mis recursos?". Debe crear
y ejecutar los experimentos más rápidos y económicos posibles para validar si sus
ideas, productos y características cumplen con los resultados comerciales
deseados.

Los experimentos estadísticos a largo plazo y las mediciones con diversos trajes de
productos empresariales han demostrado que: solo una tercera parte de todos los
cambios realizados pueden mejorar considerablemente una métrica empresarial
clave, como ingresos, conversiones, pedidos, suscripciones, adquisición de nuevos
clientes, etc. En otras palabras, 2/3 de los cambios pasan de no a una mejora
insignificante o empeoran los resultados de la métrica. Para estos 2/3 de cambios,
su organización estaría mejor si le diera vacaciones a todo el equipo, en lugar de
construir estas características que no agregan valor.

Su medida para contrarrestar este desafío es la investigación del usuario mediante

la realización de pruebas A / B. Pruebas los resultados de tus características antes
de construirlas. Usted integra los comentarios de la investigación del usuario a su
proceso de ingeniería de software para asegurarse de que no solo está
construyendo correctamente con la metodología DevOps, sino que está
construyendo lo correcto. Cuanto más rápido pueda experimentar, aprender e
integrar los comentarios de los clientes en su ciclo de vida de ingeniería de software,
mejor será nuestra capacidad para superar a sus competidores en su mercado
particular.

La técnica de prueba A / B se hizo popular por primera vez con el marketing de

respuesta directa por correo postal. Al cambiar la redacción, el esquema de color, el
diseño, el título, el texto de la copia, etc., los especialistas en marketing han estado
probando numerosas variaciones de volantes y tarjetas postales para descubrir las
versiones que funcionan y venden más que otras. El gobierno británico ha estado
haciendo pruebas A / B para identificar la carta de mejor desempeño para recaudar
los ingresos fiscales vencidos de sus ciudadanos. Las pruebas A / B son hoy en día
un método general no solo para probar elementos de marketing y comunicación,
sino también para identificar qué ideas, productos y características funcionan y
cuáles no.

Para adoptar las pruebas A / B en su equipo de DevOps, debe poder implementar

rápida y fácilmente múltiples versiones de las características del producto y
presentarlas a diferentes segmentos de usuarios. Con su telemetría integral y las
métricas de la capa de negocios, usted identifica si la característica produce mejores
resultados de negocios. En caso afirmativo, qué versión de esta característica
funciona mejor.
Un ejemplo: su organización DevOps desea lanzar un nuevo flujo de pago para un
portal de comercio electrónico. Antes de que este nuevo flujo de pago se convierta
en un nuevo trabajo importante para su equipo de DevOps, es solo una hipótesis
para obtener mejores resultados de negocios. Solo después de que esta hipótesis
sea investigada y validada, su nuevo flujo de pago puede convertirse en un proyecto
real que consumirá tiempo, recursos y energía significativos de su equipo. El primer
paquete de trabajo de su equipo de DevOps con este flujo de pago es:

Validar hipótesis: creemos que una nueva versión del flujo de pago, puede resultar
en mejores tasas de conversión. Estaremos seguros de construir y ofrecer esta
función completamente cuando veamos que una de las versiones experimentales de
flujo de salida presentadas al 1% de los visitantes aumenta las ventas al menos el
5% durante los próximos 7 días.

Conlusión
En lugar de simplemente confiar en su instinto y sus mejores prácticas, tanto usted
como su equipo de DevOps han estado aprendiendo y observando hasta ahora, el
enfoque debe ser lograr que personas reales en el mundo real se desempeñen
realmente en sus experimentos.

Los propietarios de productos de DevOps deben ver sus ideas de productos y

funciones como hipótesis a validar. Estas hipótesis pueden diseñarse, construirse y
probarse de manera integral solo después de que se demuestre racionalmente que
son buenas ideas.

¿Por qué establece su proceso de revisión continua para garantizar la

calidad?

Sus organizaciones dependen en gran medida de revisiones, auditorías,

inspecciones y aprobaciones justo antes de las implementaciones de producción.
Estas inspecciones suelen ser realizadas por personas que solo participan de forma
remota en su trabajo, si corresponde. Lo peor de todas estas autoridades de
inspección y aprobación a veces tienen un entendimiento incorrecto sobre su
trabajo, por lo que necesita educarlos justo antes de que desee implementar su
código en producción.

Problemas con los mecanismos de control externo

En la mayoría de las organizaciones, construir mecanismos de control es más fácil
que generar confianza mutua. Por lo tanto, agregar más preguntas para cambiar los
formularios de control, agregar capas de aprobación adicionales en la jerarquía y
requerir tiempos de entrega adicionales para comprender y aprobar los cambios son
problemas típicos con mecanismos de control externos.

Los entornos de baja confianza de las culturas de comando y control están

condenados a vivir con muchos incidentes que se repiten continuamente. Un círculo
vicioso negativo surge en estas organizaciones porque no hay una transparencia
clara sobre el trabajo real realizado, porque no hay transparencia sobre los
problemas recurrentes y porque el trabajo se realiza en grandes lotes para mantener
el número de implementaciones dolorosas tan bajo como sea posible. Los plazos de
entrega más largos perjudican la competitividad del tiempo de comercialización. La
retroalimentación lenta, tardía y no procesable a sus equipos hace que aprender de
los errores sea imposible.

Una organización de DevOps competente como la suya sabe que: las personas que
están más cerca del trabajo real y sus problemas asociados son quienes más saben
de ellas. Por lo tanto, tener un control externo adicional y mecanismos de
aprobación no aportan valor agregado a su flujo de valor. Lo que nos lleva al mayor
desafío de administración y liderazgo de nuestro tiempo. La construcción de culturas
de alta confianza donde el trabajo realizado es transparente, donde el respeto
genuino y la confianza mutua son la esencia del trabajo diario.

Debe cambiar la dependencia de las inspecciones periódicas y comenzar a confiar

en las revisiones de pares parte de su trabajo diario. Haga que sus desarrolladores,
ingenieros de operaciones, especialistas en control de calidad y seguridad de la
información en su equipo de DevOps colaboren y revisen constantemente el trabajo
de cada uno para hacer posibles implementaciones seguras.

Coordinación de trabajos complejos sin mecanismos de control externos.

Ya es complejo cuando un solo equipo trabaja en un proyecto, pero el trabajo puede

volverse aún más complejo cuando varios equipos trabajan en diferentes
componentes del mismo sistema. Algunas medidas para mantenerlo a usted y al
equipo de DevOps en la parte superior de su juego son:
● Los tableros de cambios que son expertos en la materia, no solo los
gerentes, pueden ayudarlo a identificar las dependencias de varios equipos
antes de que ocurran los cambios.
● Las arquitecturas poco acopladas basadas en SOA y microservicios reducen
las dependencias y el esfuerzo de comunicación.
● Los representantes técnicos de los equipos de DevOps deben identificar las
dependencias, el desarrollo y las secuencias de implementación.
 ● Comunicación continua con plataformas de chat comunes para sincronizar
los cambios y comprender y revisar la comprensión de los demás.
● Los cambios más impactantes y arriesgados, como las migraciones o los
cambios en la infraestructura, requieren ensayos en entornos de prueba y
contramedidas técnicas como la conmutación por error y los mecanismos de
reversión total.

Las organizaciones DevOps de alto rendimiento confían en las revisiones por

pares y menos en las aprobaciones externas
Muchas organizaciones de DevOps prominentes, incluidas Amazon, Netflix, Etsy y
GitHub, utilizan el proceso de revisión e implementación de "Solicitud de extracción".
Así es como funciona:
1. El desarrollador crea una rama de desarrollo separada del tronco. Esta rama
no debe vivir más de unos pocos días hábiles y debe tener un nombre claro y
descriptivo como "loginscreen-v2". El desarrollador trabaja en esta sucursal
localmente en su estación de trabajo y verifica regularmente esta sucursal al
sistema de control de versiones.
2. Cuando la desarrolladora cree que la rama de desarrollo está lista para
fusionar troncales, abre una "solicitud de extracción" para solicitar
comentarios de revisión.
3. Después de que el desarrollador recibe comentarios y aprobación de otros
miembros de su equipo de DevOps, ella combina su código con el tronco.
Luego implementa su código en los sistemas de producción.

Para cambios de alto perfil, como esquemas de base de datos o cambios que
pueden afectar la seguridad de la información de las aplicaciones, el desarrollador
también puede enviar "solicitudes de extracción" adicionales para obtener
comentarios de otros expertos en la materia de su organización, como
administradores de bases de datos o especialistas en seguridad de la información.

El principio de tamaño de lote pequeño debe usarse nuevamente mientras se

visualizan los códigos. De lo contrario, revisar el código lleva más tiempo y esto
supone una gran carga para los ingenieros de revisión. Cuando el cambio aumenta,
el riesgo de este cambio aumenta exponencialmente y la revisión se vuelve menos
confiable. Si un cambio es demasiado grande y difícil de entender, se le puede pedir
al desarrollador que divida su cambio en múltiples partes más pequeñas y
comprensibles.

Todos los integrantes de su equipo de DevOps, independientemente de la

antigüedad y el nivel de experiencia, deben hacer que alguien revise sus propios
cambios. Todos deben monitorear los flujos de confirmación, de modo que los
conflictos potenciales puedan ser identificados y resueltos rápidamente antes de
que causen problemas mayores en el proceso de implementación, incluso peor
durante las implementaciones de producción.

La programación por pares en sí misma y la programación por pares en

combinación con el desarrollo dirigido por pruebas (TDD) (un desarrollador escribe
el código de la aplicación y la otra prueba automática del desarrollador) puede
permitir que su equipo de DevOps realice revisiones entre pares mientras se escribe
el código. Dado el mismo tamaño de equipo y los requisitos del proyecto, se mide y
se demuestra que la programación de pares toma un 15% más de tiempo, pero
reduce el 85% de los errores de codificación. Por lo tanto, la programación de pares
es una práctica importante que usted y su equipo de DevOps deben evaluar para
usar.

Además, las revisiones por encima del hombro, las notificaciones automáticas de los
vapores de registro y las herramientas para ayudar a las revisiones de códigos y el
aumento de la calidad del código son otras alternativas que debería considerar
implementar.

Conclusión
Haga que cada equipo de DevOps en su organización sea responsable de la calidad
propia de sus entregables. Cree una cultura que valore las revisiones de códigos
continuos y de alta calidad, así como la escritura de códigos de alta calidad.

¿Cómo debería habilitar el aprendizaje continuo de su DevOps?

Por sus proyectos de software, ya lo sabe: a pesar de que tiene listas de

verificación, revisiones de pares, control, auditoría y mecanismos de cumplimiento,
todavía tiene problemas. Esto es inevitable. Es hora de que su equipo y
organización de DevOps construyan una cultura de autodiagnóstico,
autoaprendizaje y superación personal. Tu cultura acepta problemas y tus equipos
están listos cuando surgen problemas. Resolver problemas no es un estado
excepcional de trabajo. Pero deben ser parte de su trabajo diario para contribuir en
el aprendizaje continuo y el viaje de mejora de su organización. Y multiplica los
efectos de estas soluciones para los problemas que resuelve, haciéndolos
transparentes, disponibles y fácilmente accesibles dentro de toda su organización
DevOps.

Una de las organizaciones de DevOps prominentes, Netflix, ha desarrollado un

software interno (Chaos Monkey) para simular eventos catastróficos en sus centros
de datos basados ​en la nube. Chaos Monkey destruye servidores al azar en los
sistemas de producción, por lo que el equipo de Netflix puede crear una seguridad
adicional en su capacidad operativa para la resiliencia, estabilidad y calidad de
servicio ininterrumpida para sus clientes. De cada falla, aprenden nuevas lecciones
y explotan estas lecciones para hacer que sus sistemas sean aún más estables y
resistentes.

Comprender la importancia de construir una cultura de aprendizaje

En su organización, si hay señales con el dedo después de los incidentes, esto
creará una cultura del miedo para los ingenieros. Por lo tanto, su organización
simplemente se vuelve lenta, burocrática y un paisaje político resbaladizo. En lugar
de aprender conscientemente de los errores, ser orgánicamente más resistente y
resistente a los errores y ser más atento y cuidadoso para evitar errores. Todos en
esas organizaciones se preocupan por la autoprotección. El trabajo, los problemas e
incluso las soluciones nunca son completamente transparentes.

Debido a que los problemas son inevitables en sistemas complejos, en lugar de

señalar con el dedo, culpar y avergonzar a los que causan problemas, su
organización debe valorar las acciones para hacer que los problemas sean visibles
en su trabajo diario. Debería fomentar el aprendizaje organizacional a partir de
errores e ineficiencias, de modo que todos en su organización DevOps también
puedan aprender y beneficiarse de estos problemas, soluciones y conocimientos.

Cuando los ingenieros de su organización DevOps se sienten seguros al dar

detalles sobre los errores, voluntariamente hacen un esfuerzo adicional y gastan
mucha energía para asegurarse de que un problema similar no vuelva a ocurrir en
su propio centro de trabajo y en otros centros de trabajo en su valor organizativo
corriente. Si los ingenieros son castigados o incluso si sienten que son castigados
cuando cometen errores, entonces tendrán miedo de cometer errores, entonces
1. Producen menos trabajo para hacer menos errores.
2. No son transparentes sobre trabajo, problemas y soluciones.
3. No se les incentiva a convertir soluciones de problemas en aprendizajes
organizacionales.
4. Se garantiza que el mismo problema o uno muy similar volverá a suceder
porque nadie gasta tiempo y energía para aprender, compartir y enseñar
sobre problemas / soluciones y hacerlos visibles.

Ejecute post mortem tan pronto como ocurran los incidentes, antes de que los
recuerdos sobre las causas de los problemas se desvanezcan

Los objetivos de una revisión post mortem son muy simples:

● Para identificar las cosas que hizo bien, para que pueda recordar intentarlas
de nuevo en situaciones similares.
 ● Anotar las cosas que deberían haberse hecho de manera diferente, para que
pueda refinar sus técnicas en el futuro.
● Para anotar las cosas que hizo mal y sugerir enfoques alternativos o medidas
de seguridad que debería emplear la próxima vez que enfrente un problema
similar.
● Para averiguar por qué tenía sentido tomar (o no tomar) la acción que causó
el incidente.

Explorar lo que hizo mal es aterrador y en algunas organizaciones es peligroso. Si

admitir haber cometido errores te abre a la crítica o la disciplina, es poco probable
que hagas esas admisiones. Esta estrategia es, en última instancia,
contraproducente, ya que no entender un error pasado generalmente te condena a
repetirlo nuevamente en el futuro. Las organizaciones que se toman en serio la
mejora, entienden esto y se toman la molestia de crear un proceso y una cultura
donde es seguro explorar errores.

Cuando entra en un proceso de revisión post mortem, debe aceptar algunas

premisas básicas:
● Todos tratan de hacer lo mejor que pueden, como mejor lo entienden.
● Usted toma nuestras decisiones en situaciones de estrés, con información
imperfecta.
● A menudo se le pide que realice tareas para las que no ha recibido
capacitación, con las herramientas y recursos disponibles.
● Los errores son inevitables en tales situaciones.
● El objetivo de este proceso no es encontrar fallas en ningún individuo o sus
acciones. Más bien es mirar lo que sucedió y ver qué lecciones puedes
aprender de él.
● El resultado de este proceso no será una evaluación de ninguna persona o
grupo de personas, sino una evaluación de nuestros procesos y cómo se
pueden mejorar.

Es absolutamente esencial que todas las personas involucradas acepten

completamente este "Sin culpa, estamos aquí para aprender el modelo". Muchas
organizaciones se molestan en crear entornos tan seguros. La FAA, por ejemplo,
tiene un sistema de informes de seguridad de la aviación, por el cual los pilotos que
cometen "errores" pueden obtener inmunidad de la disciplina reglamentaria si
reportan esos incidentes.

Las revisiones post mortem siempre deben definir medidas procesables para evitar
que el incidente vuelva a ocurrir en el futuro. Las nuevas métricas de telemetría, los
nuevos casos de prueba automatizados, la identificación del tipo de cambios que
requieren revisiones adicionales de códigos, el código de refactorización o el
desacoplamiento de componentes complejos del sistema que causan problemas
frecuentes pueden ser ejemplos de tales medidas preventivas.

Publique protocolos de revisión post mortem y lecciones aprendidas ampliamente en

su organización. Esto le ayudará a convertir sus aprendizajes locales de un centro
de trabajo en su flujo de valor en aprendizajes globales de toda la organización. Y
este será un mensaje claro en su organización de DevOps para fomentar la
transparencia, la apertura y la cultura de aprendizaje.

Organiza días de juegos para mejorar tus sistemas

Un día de juego no es uno de los típicos eventos aburridos de tu equipo donde los
extravertidos disfrutan del espectáculo y los introvertidos juegan con sus teléfonos
móviles para acelerar el flujo del tiempo.

En un día de juego se simulan fallas catastróficas en sus sistemas de prueba. Y los

equipos de DevOps trabajan para solucionar y aprender de estos fracasos.

Por ejemplo, un servidor crítico se termina para validar la operación exitosa del
mecanismo de conmutación por error sin interrupciones del servicio. Luego, su
equipo de DevOps valida si / cómo funciona su mecanismo de recuperación de las
copias de seguridad o de su Infraestructura como Código (IaC). La identificación de
problemas en estos escenarios de fallas ayuda a su equipo de DevOps a construir
sistemas resistentes y tolerantes a fallas y a crear aprendizajes.

Durante el proceso de resolución de problemas, su equipo de DevOps construye

una relación con otros departamentos mientras ensayan eventos fallidos en
condiciones sin estrés. Hará pruebas y tendrá una oportunidad visible de mejorar los
procesos de comunicación y solución de problemas dentro de su organización
global más grande.

Además, tendrá la capacidad de observar señales más débiles para posibles

problemas mayores que pueden revelarse en el futuro. Con frecuencia ocurren
incidentes de baja prioridad durante estos escenarios fallidos, o un pequeño efecto
secundario que puede haberse acercado a la caída de otro componente crítico en
su arquitectura son señales importantes de la semana que debe tener en cuenta y
trabajar para mejorar sus sistemas.

Conclusión

En su equipo DevOps fomente la toma de riesgos calculados. Las organizaciones

de alto rendimiento de DevOps como la tuya cometen errores más frecuentes. Esto
no solo está bien, sino que también es lo que su organización necesita. Para
aprender y rendir mejor.
Sobre las organizaciones típicas, los de alto desempeño tienen un 80% menos de
fallas críticas en sus sistemas de producción. En otras palabras, tienen 5 veces
menos incidentes que afectan a sus clientes. Esta es la razón por la que sus
ingenieros en su organización DevOps necesitan sentirse libres para cometer
errores y aprender de ellos.

¿Por qué su equipo de DevOps necesita bloquear el tiempo para mejorar el

trabajo?
No es una técnica nueva de DevOps bloquear su tiempo para mejorar su trabajo.
Hace décadas, Lean Manufacturing adoptó el lema: "Mejorar el trabajo es más
importante que el trabajo en sí mismo".

En otras palabras, esto implica que, sin mejorar la forma en que trabaja hoy, su
trabajo quedará obsoleto mañana. Y, en última instancia, esto a cambio dificultará
su fortaleza competitiva en su mercado. Esta es la razón por la cual la metodología
DevOps tomó prestada esta técnica de Lean Manufacturing para que sus equipos y
su organización aprendan continuamente.

Aquí hay algunas ideas de la metodología de desarrollo y entrega del software

DevOps acerca de cómo usted y su equipo de DevOps pueden usar su tiempo para
mejorar su trabajo y aprender continuamente:
1. Comentarios de personas externas: apoyo concentrado de personas fuera
de sus procesos de negocios a las personas dentro de sus propios procesos
de negocios. La retroalimentación de los forasteros puede ser realmente útil y
reveladora para mejorar los procesos y eliminar las ineficiencias.
2. Regularmente reducir la deuda técnica: regularmente reúne a su equipo
para dejar de trabajar en nuevas características y trabajar para reducir la
deuda técnica. Los ingenieros cuyas habilidades abarcan todo su flujo de
valor trabajan en (no solo discuten) el código, los entornos, las herramientas,
los componentes y las arquitecturas para reducir la deuda técnica, por lo que
sus nuevas características se construirán sobre una base más sólida y sólida.
3. Regularmente reserve tiempo para la innovación: libere un cierto
porcentaje del tiempo de trabajo de sus ingenieros, para que puedan usar
este tiempo para innovar su tecnología y negocio. Google es una de las
organizaciones de DevOps prominentes que utilizan esta práctica desde hace
años. Los empleados de Google tienen un 20% de tiempo no asignado que
utilizan para desarrollar prototipos, productos, características, suites de
prueba y soluciones. Gmail, Google Maps y AdSense son algunos de los
principales productos innovados dentro de este 20%.
 4. Fomentar la enseñanza y el aprendizaje: dedicar tiempo para la
enseñanza. Organice conferencias internas, talleres, tutorías, entrenamiento,
asesoramiento para enseñar regularmente a sus equipos. Los
desarrolladores aprenden sobre el trabajo operativo y sus desafíos, y los
ingenieros de operaciones aprenden sobre el desarrollo. Esto ayudará a crear
y mantener un mejor entendimiento mutuo sobre el trabajo de cada uno. A
cambio, sus desarrolladores e ingenieros de operaciones construyen una
base de cooperación informada y conectada personalmente. Además, anime
a sus equipos de DevOps a asistir a conferencias para comprender mejor
cómo otras organizaciones resuelven desafíos operativos y de ingeniería
similares, como el suyo.
5. Separe a los maestros de las PYME: asegúrese de que sus expertos en la
materia tengan horas libres en las que cualquier persona pueda ir y haga
preguntas para discutir asuntos que pueden no estar relacionados con un
proyecto en curso. Somos aprendices de por vida. Su equipo no solo respeta
esto, sino que también lo saben porque también aprenden de por vida.
6. Organice Hackathons para la innovación: Aquí es cómo Marc Zuckerberg
de Facebook explica esta idea: "Cada pocos meses tenemos un hackathon,
donde todos construyen prototipos para las nuevas ideas que tienen. Al final,
todo el equipo se reúne y observa todo lo que se ha construido. "Muchos de
nuestros productos más exitosos provinieron de hackathons, incluyendo
Timeline, chat, video, nuestro marco de desarrollo móvil y algunas de
nuestras infraestructuras más importantes como el compilador HipHop".

Conclusión
Al programar regularmente los búferes para mejorar, permite que todos los
miembros de su flujo de valor organizativo se apropien de la innovación y la calidad.
Por lo tanto, todos los ingenieros de su equipo de DevOps integran continuamente
seguridad, calidad, aprendizaje, confiabilidad y mejora en el trabajo diario que
finalmente se integra en los productos y servicios de software que sus
organizaciones ofrecen a sus clientes.

Al ayudarse mutuamente en sus equipos DevOps, su organización superará a sus

competidores y los miembros de su equipo desarrollarán sus máximos potenciales
como seres humanos e ingenieros.

¿Cómo se habilitan los aprendizajes organizativos del trabajo diario de

DevOps?
Uno de los principios principales que usted y su equipo capturan de DevOps es:
Aprende continuamente de su trabajo diario y convierte estos aprendizajes en
activos globales reutilizables para toda su organización.
Utilice salas de chat para difundir el conocimiento

Usa salas de chat para capturar y crear conocimiento organizacional. Cree bots que
se integren a sus salas de chat para realizar rápidamente tareas operativas para
usted. Por ejemplo, el siguiente mensaje que dirige a su bot en la sala de chat
puede instalar la aplicación FrontEndApp en el entorno TestServer-9 e imprimir el
resultado de este comando nuevamente en la sala de chat como si ejecutara el
comando desde su interfaz de línea de comandos.
@bot install FrontEndApp TestServer-9

Gracias a este mecanismo, todos en su equipo pueden sincronizar rápidamente el

progreso de su trabajo. No se pierde información en mensajes instantáneos
privados y correos electrónicos. Esto nutre una cultura de colaboración y
transparencia con el trabajo que realiza. Y esta es una manera muy efectiva de
convertir el conocimiento local en aprendizajes organizacionales.

Por último, pero no menos importante, el uso de salas de cartas comunes agiliza el
proceso de incorporación de nuevos miembros a su equipo de DevOps o a su
compañía, de modo que puedan supervisar fácilmente una parte sustancial de la
forma en que se realiza el trabajo en sus equipos. Puede considerar el uso de salas
de chat separadas para diferentes productos, servicios, componentes, herramientas,
bibliotecas o integraciones, por lo que será más fácil buscar y encontrar actividades
pasadas asociadas con un determinado elemento en su sistema.

Ponga su enfoque en los ejecutables en lugar de las documentaciones

En lugar de poner su know-how y experiencia en documentos o Wikis, cree
estándares y procesos ejecutables tanto como sea posible. Una de las mejores
formas de generar y compartir conocimientos en su organización de DevOps es
crear una herramienta reutilizable y almacenarla en su sistema de control de versión
de código, para que cualquier persona que necesite algo como esto pueda
encontrarlo. Cuando expresa un estándar y la forma en que trabaja como código
ejecutable en lugar de documentos estáticos que pueden interpretarse de manera
errónea y diferente según quién lo lea, este código no solo acelerará y simplificará
su negocio, sino que también ayudará a su organización DevOps a: pasar varias
auditorías y verificaciones de cumplimiento dado que el código tiene al menos un
documento liviano que explica qué tan bien maneja el código el proceso que
requiere auditoría y cumplimiento.

Para el trabajo, los procesos y los estándares que no se pueden automatizar, cree
historias de usuarios reutilizables con pasos y listas de verificación claros y
distinguibles, para que todos los miembros de su organización DevOps puedan
reutilizar y aprovechar los beneficios de dichos activos. Gracias a estos activos
reutilizables, diferentes equipos pueden realizar un trabajo similar de manera
consistente. Y mejoran estos activos al igual que continuamente revisan, reutilizan y
mejoran las bibliotecas de códigos.

Crear planos de software reutilizables

Cree planos listos para usar para componentes, aplicaciones, servicios y

microservicios que manejan requisitos no funcionales incorporados por diseño. De
esta manera, los desarrolladores no tendrán que preocuparse por los requisitos no
funcionales cada vez que escriban un nuevo código.

Además, su organización tendrá un conjunto consistente de requisitos no

funcionales implementados en toda su pila de aplicaciones. Además, esta
implementación integrada de características no funcionales simplificará la
implementación, el monitoreo, la resolución de problemas y las operaciones del
software en general mientras se ejecuta en plataformas de prueba y producción.
Ejemplos de tales requisitos no funcionales son:

● Métricas de telemetría.
● Configuraciones en tiempo de ejecución.
● Función alterna.
● Capacidad para rastrear dependencias.
● Capacidad para rastrear solicitudes iniciadas por los usuarios.
● Servicios resilientes y tolerantes a fallos.
● Servicios que pueden ser degradados graciosamente a pedido.
● Posibilidad de buscar mensajes de registro.
● Compatibilidad con versiones anteriores y posteriores.
● Archivado de datos y gestión de conjuntos de datos de producción.
● Gestión y archivo de logs.

Las pruebas automatizadas integrales deben formar parte de sus planos

codificados. Las pruebas automatizadas aclaran el propósito de su código, explican
cómo utilizar el código reutilizable de la manera más eficiente y aceleran la
composición de las pruebas automatizadas para sus aplicaciones personalizadas
heredadas de los planos de código reutilizables.

Utilice un repositorio de código único

Para asegurarse de que todos sus aprendizajes y trabajo se compartan con todos,
no solo almacena el código fuente en su único repositorio, sino que también
almacena herramientas para la implementación, código para compilar y ejecutar el
canal de implementación, pruebas automatizadas, código para compilar e integra
telemetría, estándares, tutoriales, documentos, wikis, herramientas de ayuda y
estándares de configuración para las plataformas.

De esta manera, todos los activos se comparten de forma transparente con todos
los miembros de su organización DevOps. Se evitan duplicaciones, múltiples
versiones de los mismos artefactos, componentes y herramientas de terceros. Un
repositorio también le permite compilar, vincular y construir todo en tiempo de
ejecución y usar la última versión de todo cuando desarrolle, pruebe y despliegue su
software.

Tener estándares de tecnología, pero mantenerse flexible

Si desea que todos en su equipo de DevOps lean, revisen y corrijan el código de
cada uno, defina sus estándares de tecnología de transmisión principal con los que
todos los integrantes de sus equipos de desarrollo y operaciones puedan aprender y
trabajar. Lo que necesita es: un lenguaje de compilación, un lenguaje de scripting y
un lenguaje GUI. Pero aún así, deje que todos exploren las tecnologías en las que
estén interesados, para que su equipo de DevOps pueda aprender y experimentar
continuamente. ¿Cómo va a ganar con su próxima innovación si no está explorando
y haciendo pruebas en los límites?

Conclusión
En este capítulo, resumimos para usted algunas de las técnicas de DevOps
ampliamente aceptadas que le permitirán a su organización de DevOps aprender y
crear activos mientras realiza su trabajo diario. Al aprovechar estos métodos, la
experiencia acumulada y la experiencia de toda su organización DevOps
respaldarán y habilitarán la experiencia profesional y la calidad laboral de cada
individuo en su equipo DevOps.