Parte 1 Introducción a DevOps
Capítulo 1 Entrega continua y ágil y el método de tres pasos 4
1.1 Flujo de valor de fabricación 4
1.2 Flujo de valor tecnológico 4
Por lo general, definimos los flujos de valor de la tecnología como "los procesos necesarios para transformar las ideas comerciales en servicios habilitados por tecnología que brindan valor a los clientes".
1.2.1 Centrarse en el plazo de ejecución de la implementación 5
El flujo de valor comienza cuando un "ingeniero" (incluido el personal de desarrollo, control de calidad, operaciones de TI y seguridad de la información) envía un cambio al sistema de control de versiones y finaliza cuando el cambio se ejecuta con éxito en producción, brinda valor a los clientes y genera comentarios efectivos. y seguimiento de la información.
No recomendamos que después de completar una gran cantidad de trabajo en serie en diseño y desarrollo, se transfiera a la fase de prueba, operación y mantenimiento (como usar un proceso de desarrollo basado en un modelo en cascada a gran escala y trabajar en una rama de características con un largo ciclo de vida). Por el contrario, nuestro objetivo es adoptar un patrón en el que las pruebas y las operaciones estén sincronizadas con el diseño y el desarrollo, lo que da como resultado un flujo de valor más rápido y una mayor calidad.
Tiempo de entrega y tiempo de procesamiento (a veces llamado tiempo de contacto o tiempo de tarea). son dos indicadores de uso común para medir el rendimiento de los flujos de valor.
El tiempo de entrega comienza a contar después de que se crea la orden de trabajo y finaliza cuando se completa el trabajo: el tiempo de procesamiento comienza a contar cuando el trabajo se procesa realmente y no incluye el tiempo que el trabajo está en la cola (consulte la Figura 1 -1) .
Debido a que el tiempo de entrega es el tiempo que experimentan los clientes, nos enfocamos en reducir el tiempo de entrega en lugar del tiempo de procesamiento.
En un ideal de DevOps, los desarrolladores rápidamente: obtienen comentarios continuos sobre su trabajo, desarrollan, integran y validan el código de forma rápida e independiente, e implementan el código en producción.
Este objetivo se puede lograr enviando continuamente pequeños lotes de cambios de código al sistema de control de versiones y realizando pruebas exploratorias y automatizadas en el código antes de implementarlo en el entorno de producción.
Para lograr los objetivos anteriores más fácilmente, también es necesario optimizar el diseño de la arquitectura a través de la modularización, alta cohesión y bajo acoplamiento.
1.2.2 Prestar atención a los indicadores de reelaboración - %C/A 7
Además del tiempo de entrega y el tiempo de procesamiento, una tercera métrica clave en el flujo de valor técnico es el tiempo de finalización y el porcentaje exacto del tiempo total invertido (% CIA). Esta métrica refleja la calidad de salida de cada paso en el flujo de valor.
1.3 Método de trabajo en tres pasos: los principios básicos de DevOps 7
El primer paso es darse cuenta del flujo rápido de trabajo desde el desarrollo hasta la operación y el mantenimiento de izquierda a derecha
. El segundo paso es aplicar un mecanismo de retroalimentación de trabajo continuo y rápido en cada etapa de derecha a izquierda. El
tercer paso es establecer un creativo y la cultura corporativa Creíble de alto nivel apoya experimentos dinámicos, rigurosos y científicos.
1.4 Resumen 8
Capítulo 2 Paso 1: El principio de flujo 9
2.1 Hacer visible el trabajo 9
Para poder identificar dónde está fluyendo, en cola o estancado el trabajo, es necesario visualizar el trabajo tanto como sea posible. Los tableros de trabajo visuales son una mejor manera de trabajar, como usar papel o tarjetas electrónicas para mostrar cada trabajo en un tablero de planificación Kanban o Sprint. El trabajo generalmente se inicia desde la izquierda (se extrae del trabajo pendiente), luego se extrae de un centro de trabajo al siguiente y, finalmente, al extremo derecho de la bolsa de trabajo, que también suele estar marcado como Listo o "En línea". De esta manera, no solo se puede visualizar el contenido del trabajo, sino que también se puede administrar el trabajo de manera eficiente y se puede acelerar su flujo de izquierda a derecha.
Idealmente, el kanban debería cubrir todo el flujo de valor; el trabajo solo se considera completo cuando llega al extremo derecho del kanban (consulte la Figura 2-1). El desarrollo de una determinada función no se puede considerar como "completado", solo cuando la aplicación se ejecuta con éxito en el entorno de producción y comienza a proporcionar valor a los clientes se puede considerar "completado".
Al poner todo el trabajo de cada centro de trabajo en la cola y mostrarlo visualmente, es más fácil para las partes interesadas determinar la prioridad de cada trabajo en función del objetivo general.
2.2 Límite WIP a 10
Al asignar a un ingeniero a múltiples proyectos al mismo tiempo, tiene que alternar entre múltiples tareas, reglas cognitivas y objetivos, y pagar el costo de volver a ingresar al rol. La multitarea da como resultado tiempos de procesamiento más largos.
Al usar kanban para administrar el trabajo, puede limitar la apariencia de multitarea, como establecer un límite en la cantidad de trabajo en curso para cada columna del kanban o cada centro de trabajo, y marcar el límite superior del número. de cartas en cada columna.
Por ejemplo, establezca la cantidad máxima de WIP para un trabajo de prueba en 3. Cuando ya hay 3 tarjetas en la cola de prueba, no se pueden agregar nuevas tarjetas hasta que se complete una tarjeta o se devuelva una de las 3 a la cola anterior.
Controlar la longitud de la cola (es decir, WIP) es una herramienta de gestión muy poderosa, ya que es uno de los factores importantes que afectan el tiempo de entrega: para la mayoría de los elementos de trabajo, no es predecible hasta que se completen. Exactamente cuánto tiempo tomará.
2.3 Reducción del tamaño del lote 11
Los altos volúmenes conducen a un WIP vertiginoso, lo que puede generar tiempos de entrega prolongados y una mala calidad del producto: si se descubre que un solo panel de la carrocería está defectuoso, se debe desechar todo el lote.
Para acortar el tiempo de entrega y mejorar la calidad de los entregables, se debe buscar continuamente el modo de bajo volumen. En teoría, el tamaño de lote más pequeño es el flujo de una sola pieza, es decir, el procesamiento de una sola unidad de producto se realiza por operación.
La gran diferencia entre lotes pequeños y grandes se ilustra con el caso clásico de "Folletos de correo simulado". Este ejemplo asume que se están enviando 10 folletos. Antes de enviar por correo, cada folleto debe pasar por 4 pasos: doblar, insertar el sobre, sellar el sobre y estampar.
En el caso de una estrategia de gran volumen (es decir, "producción en masa"), realizaremos los 4 pasos anteriores de forma secuencial en cada folleto. En otras palabras, primero doble las 10 hojas, luego inserte cada hoja en un sobre, luego selle todos los sobres y finalmente selle todos.
Otro enfoque es una estrategia de lotes bajos (es decir, "flujo de una sola pieza"), donde todos los pasos requeridos se realizan secuencialmente en cada folleto antes de que comience el procesamiento en el siguiente. En otras palabras, doble una hoja de papel, introdúzcala en el sobre, cierre el sobre y póngale el sello; luego, retire la hoja de papel y repita el proceso.
La diferencia entre adoptar una estrategia de lotes altos y lotes pequeños es enorme (consulte la Figura 2-2). Suponga que se deben realizar los 4 pasos anteriores para los 10 sobres, y cada paso toma 10 segundos. Si se procesa utilizando la política de lotes altos de 5 por lote, se tardaría 310 segundos en completar el primer sobre con franqueo pagado.
Peor aún, supongamos que descubrimos en la operación de sellado de sobres que el primer paso del pliegue está mal hecho, en cuyo caso lo más pronto que podemos encontrar el error es después de 200 segundos, entonces tendríamos que enviar el lote Los 10 folletos fueron entonces doblado y vuelto a poner en sobres.
Para los flujos de valor de la tecnología, los efectos secundarios de gran volumen son los mismos que para la fabricación. Este lanzamiento de gran volumen crea grandes y repentinos volúmenes de trabajo en curso, lo que provoca una gran confusión en todos los centros de trabajo posteriores1, lo que da como resultado un flujo más pobre y una calidad más baja. Es decir, cuanto mayores sean los cambios en el entorno de producción, más difícil será localizar y solucionar el problema, y más tiempo llevará solucionarlo.
2.4 Reducir el número de traspasos 13
En el proceso de flujo de valor del código, los diferentes departamentos deben cooperar para completar las tareas relacionadas, incluidas las pruebas funcionales, las pruebas de integración, la construcción del entorno, el servidor de configuración, el almacenamiento, la gestión, la red, el equipo de equilibrio de carga y el refuerzo de la seguridad de la información, etc.
Cuando un trabajo se entrega entre equipos, requiere mucha comunicación: solicitar, delegar, notificar, coordinar y, a menudo, priorizar, programar, resolver conflictos, probar y validar.
Cada enlace en el proceso anterior tiene su cola subyacente, y cuando se depende de recursos compartidos por diferentes flujos de valor, habrá una espera para el trabajo. Los plazos de entrega de estas solicitudes suelen ser elevados, lo que provoca continuos retrasos en el trabajo que debería haberse completado a tiempo. Incluso en las mejores circunstancias, parte de la información o el conocimiento se pierde inevitablemente en el traspaso.
Para reducir este tipo de problemas, esfuércese por reducir la cantidad de traspasos, automatice la mayoría de las operaciones o reestructure la organización para que los equipos puedan entregar valor de forma independiente a los clientes sin depender de otros.
2.5 Identificar y mejorar continuamente los puntos de restricción 14
En el proceso de transformación de DevOps, si desea que el tiempo de entrega se reduzca de meses o trimestres a unos pocos minutos, generalmente necesita optimizar las siguientes restricciones a su vez.
Construcción del entorno: la solución es establecer un entorno de autoservicio completo bajo demanda, que se puede crear de forma automatizada.
Implementación de código: la solución es automatizar el proceso de implementación tanto como sea posible para que cualquier desarrollador pueda automatizar la implementación a pedido. Preparación y ejecución de pruebas: la solución es automatizar las pruebas para que la velocidad de las pruebas pueda mantenerse al día con la velocidad del desarrollo del código
mientras la implementación se realiza de forma segura y en paralelo . Arquitectura estrechamente acoplada: la solución es crear una arquitectura débilmente acoplada para que los desarrolladores puedan realizar cambios de manera segura y autónoma y aumentar la productividad.
Nuestro objetivo es permitir que pequeños equipos de desarrollo desarrollen, prueben e implementen de forma independiente, rápida y confiable, y continúen creando valor para los clientes.
2.6 Eliminar dilemas y desperdicios en el flujo de valor15
2.7 Resumen 16
Mejorar la fluidez del flujo de valor de la tecnología es fundamental para implementar DevOps. Para hacer esto, necesitamos visualizar el trabajo, limitar el trabajo en proceso, reducir el tamaño de los lotes, reducir la cantidad de traspasos, identificar y mejorar continuamente las restricciones y eliminar los dilemas del día a día.
Capítulo 3 Paso 2: Principios de retroalimentación 17
3.1 Trabajar con seguridad en sistemas complejos 17
Los principios descritos en el método First Step Work permiten que el trabajo fluya rápidamente de izquierda a derecha en el flujo de valor. La descripción del método de trabajo del segundo paso.
3.2 Detección oportuna de problemas 18
El objetivo debe ser tener retroalimentación rápida y bucles de avance en toda la ejecución del trabajo en cada etapa del flujo de valor de la tecnología, incluida la gestión de productos, el desarrollo, el control de calidad, la seguridad de la información y las operaciones. Esto incluye la creación de procesos automatizados de compilación, integración y prueba para detectar de manera temprana los cambios en el código que podrían generar defectos.
También es necesario establecer un sistema de monitoreo integral para monitorear el estado de ejecución de los componentes del servicio en el entorno de producción, a fin de detectar rápidamente las excepciones del servicio.
3.3 Lluvia de ideas y trabajo conjunto para superar problemas y adquirir nuevos conocimientos 19
3.4 Garantía de calidad en origen 21
Evalúe los cambios propuestos contra la revisión por pares para asegurarse de que funcionarán según lo diseñado. Automatice tanto como sea posible los controles de calidad que normalmente realiza el personal de control de calidad y seguridad de la información. Ejecute pruebas automatizadas a pedido sin que los desarrolladores soliciten o inicien esfuerzos de prueba del equipo de prueba. De esta forma, los desarrolladores pueden probar rápidamente su código e incluso implementar cambios de código en el entorno de producción.
3.5 Optimización para centros de trabajo posteriores 22
3.6 Resumen 22
Capítulo 4 Paso tres: Principios del aprendizaje continuo y la experimentación 23
4.1 Construyendo una Organización de Aprendizaje y una Cultura de Seguridad 23
El primer paso es establecer un flujo de trabajo de izquierda a derecha, el segundo paso es establecer una retroalimentación rápida y continua de derecha a izquierda y el tercer paso es establecer una cultura de aprendizaje y experimentación continuos.
Se puede realizar una retrospectiva libre de culpa después de cada incidente, brindando una explicación objetiva de por qué y cómo sucedió y acordando las mejores acciones para optimizar el sistema. Idealmente, esto no solo previene la recurrencia del problema, sino que también facilita la localización y recuperación de fallas más rápidas. Eliminar la culpa puede realizar efectivamente una organización de aprendizaje.
4.2 Institucionalizar la mejora del día a día 25
Si el equipo no tiene la capacidad o la voluntad de mejorar el proceso existente, seguirá sufriendo y sufriendo los problemas que tiene entre manos, y el índice de dolor aumentará día a día.
El patrón de resolución de problemas con soluciones ad-hoc muchas veces conduce también a la acumulación de problemas y deuda técnica. Más importante que el trabajo diario es la mejora continua del trabajo diario.
Mejore el trabajo diario reservando explícitamente tiempo para pagar la deuda técnica, corregir errores, refactorizar y optimizar el código y los entornos. Puede reservar períodos de tiempo entre cada ciclo de desarrollo o programar sesiones de mejora en las que los ingenieros se autoorganizan como equipos para resolver los problemas que les interesan.
4.3 Transforme el descubrimiento local en optimización global 26
Una vez que los resultados se logran localmente, deben compartirse con otras personas en la organización para que más personas puedan beneficiarse de ellos.
Se deben escribir informes de fallas para cualquier proceso o desviaciones operativas para acumular experiencia. Independientemente de la fuerza de la señal de falla o la magnitud del riesgo, los diseños de procesos y sistemas se actualizan continuamente en función de estas experiencias.
4.4 Inyectar patrones de resiliencia en el trabajo cotidiano 27
Los simulacros también se pueden usar para ensayar fallas a gran escala, como cerrar un centro de datos. O inyecte fallas a gran escala en el entorno de producción (como el famoso "mono problemático" de Netflix, que mata aleatoriamente procesos y servidores en el entorno de producción), para verificar si la confiabilidad del sistema cumple con las expectativas.
4.5 El liderazgo refuerza la cultura de aprendizaje 27
4.6 Resumen 29
4.7 Resumen de la primera parte 29
Analiza el método de trabajo de tres pasos de la transformación organizacional de DevOps: el principio de flujo, el principio de retroalimentación y el principio de aprendizaje y experimentación continuos.
por donde empezar la segunda parte
Capítulo 5 Elegir el flujo de valor adecuado como punto de entrada 32
5.1 Proyectos Greenfield y Proyectos Brownfield 34
En tecnología, un proyecto greenfield se refiere a un proyecto de software completamente nuevo. Comenzando desde cero, por lo que no hay muchas preocupaciones sobre la base de código, el proceso y el equipo existentes.
Los proyectos greenfield de DevOps generalmente se refieren a algunos proyectos piloto para probar la viabilidad de las soluciones de nube pública o nube privada, o para tratar de adoptar herramientas de implementación automatizadas o herramientas relacionadas.
Los proyectos brownfield de DevOps son aquellos productos o servicios que han servido a los clientes durante años o incluso décadas. Este tipo de proyecto suele conllevar una gran deuda técnica, como pruebas no automatizadas, ejecución en una plataforma sin mantenimiento, etc.
5.2 Equilibrar los sistemas de grabación e interactivos 35
5.3 Empezar con los equipos más innovadores 36
Nuestro objetivo es encontrar equipos que crean en los principios y prácticas de DevOps, y que tengan la voluntad y la capacidad para innovar y mejorar los procesos existentes. Idealmente, estos grupos serán campeones de la transformación DevOps.
No dedicamos mucho tiempo a cambiar grupos conservadores, especialmente en las primeras etapas. En su lugar, concéntrese en equipos que generen éxito y estén dispuestos a asumir riesgos, y a partir de ahí, expanda lentamente.
Incluso con la aceptación de alto nivel, evite un enfoque de "gran explosión" (es decir, un comienzo floreciente) y, en cambio, concéntrese en algunas áreas piloto, asegure su éxito y luego expanda gradualmente.
5.4 Ampliación del alcance de DevOps 37
No importa cómo se elija el punto de entrada, los resultados deben demostrarse lo antes posible y publicitarse activamente. Divida los grandes objetivos de mejora en pequeños pasos incrementales. Hacerlo no solo aumenta la tasa de mejora, sino que también permite la detección temprana de flujos de valor mal seleccionados.
Aproveche los éxitos ya alcanzados y amplíe gradualmente el ámbito de aplicación del programa DevOps. Siga una secuencia de apuestas bajas para generar credibilidad, influencia y aceptación metódicamente.
Cómo ampliar su impacto en función del apoyo que ha recibido.
(1) Identifique a los innovadores y los primeros en adoptar: idealmente, estos colegas son respetados y tienen mucha influencia sobre los demás en la organización. Su apoyo contribuye a la credibilidad de la innovación.
(2) Ganar la mayoría silenciosa: en la siguiente fase, busque expandir las prácticas de DevOps a más equipos y flujos de valor, con el objetivo de construir una base de público más sólida.
(3) Identificar "hogares clave": Sólo después de obtener el apoyo de la mayoría de la gente y establecer una base de masas lo suficientemente sólida podemos considerar cómo tratar con este grupo.
5.5 Resumen 38
Capítulo 6 Comprensión, visualización y uso de flujos de valor 39
6.1 Identificar los equipos necesarios para crear valor para el cliente 40
Después de seleccionar una aplicación o servicio piloto de DevOps, se deben identificar todos los miembros del flujo de valor y, en general, incluir a los siguientes miembros.
Propietario del producto: como portavoz del lado comercial, defina las funciones que el sistema debe lograr.
Equipo de desarrollo: Responsable de desarrollar las funciones del sistema.
Equipo de control de calidad: proporcione retroalimentación al equipo de desarrollo y asegúrese de que el sistema funcione según lo requerido.
Equipo de operación y mantenimiento: Responsable de mantener el ambiente de producción y asegurar que el sistema pueda funcionar bien.
Equipo de seguridad de la información: Responsable de la seguridad del sistema y de los datos.
Gerente de lanzamiento: Responsable de administrar y coordinar el proceso de implementación y lanzamiento del entorno de producción.
Líder técnico o administrador del flujo de valor: (como lo define la metodología Lean) es responsable de "permitir, de principio a fin, que el resultado del flujo de valor
cumpla o supere las expectativas del cliente (y de la organización)".
6.2 Mapeo de flujos de valor para el trabajo en equipo 40
Después de identificar a los miembros relevantes del flujo de valor, el siguiente paso es obtener una mejor comprensión de cómo funcionan las cosas y documentarlos con un mapa del flujo de valor.
El objetivo del mapeo del flujo de valor no es registrar todos los pasos y detalles, sino identificar los vínculos que impiden el flujo rápido del flujo de valor.
Según toda la información proporcionada por el equipo de participación en el flujo de valor, se deben analizar y optimizar los siguientes dos tipos de trabajo:
Trabajo que debe esperar semanas o incluso meses, como la preparación de un entorno de producción, el proceso de aprobación de cambios o la seguridad. proceso de revisión
; Trabajo que maneja reelaboración importante.
La versión inicial del mapa de flujo de valor debe contener solo módulos de proceso importantes.
Como mínimo, cada módulo debe incluir el tiempo de entrega y el tiempo de procesamiento del elemento de trabajo (LT y VA, respectivamente, en la Figura 6-1) y el %C/A medido por los consumidores intermedios. Las métricas en el mapa de flujo de valor se pueden usar para guiar los esfuerzos de mejora.
Una vez que haya identificado las métricas que desea mejorar, dibuje un mapa de flujo de valor idealizado y utilícelo como el objetivo de mejora para la siguiente etapa.
6.3 Formar un equipo de transformación dedicado 42
Se debe formar un equipo de transformación dedicado y separarlo del departamento responsable de las operaciones diarias y, lo que es más importante, este equipo debe ser responsable de lograr objetivos bien definidos, medibles y a nivel del sistema (por ejemplo, pasar "del compromiso de código to deployment Reducción del 50% en lead time para el proceso de “to production environment”). Para hacer esto, se deben tomar las siguientes medidas:
Los miembros del equipo de transformación se dedican al trabajo de transformación DevOps (en lugar de permitirles continuar con su trabajo anterior, pero dedican el 20 % de su tiempo a la transformación DevOps); Elija familiarizarse con
varios generalistas en el campo como miembros del equipo;
Elija personas que tengan buenas relaciones a largo plazo con otros departamentos como miembros del equipo;
Si es posible, busque un área de oficina separada para el equipo, para que los miembros puedan comunicarse con entre sí tanto como sea posible Distancia adecuada.
Si es posible, libere al equipo de transformación de muchas reglas y regulaciones existentes.
6.3.1 Tener un objetivo común 43
6.3.2 Plan de mejora para mantener un pequeño vano 44
En cualquier proyecto de transformación de DevOps, debe mantener un plan de mejora pequeño y debe esforzarse por obtener resultados de mejora medibles o datos utilizables en semanas (o, en el peor de los casos, meses).
6.3.3 Reservar el 20% del tiempo de desarrollo para requisitos no funcionales y reducir la deuda técnica 44
Para administrar activamente la deuda técnica, asegúrese de que al menos el 20 % del tiempo de desarrollo y operaciones se dedique a la refactorización, los esfuerzos de automatización, la optimización arquitectónica y los requisitos no funcionales (a veces denominados "atributos de calidad"), como la mantenibilidad, la capacidad de administración, la escalabilidad, fiabilidad, capacidad de prueba, despliegue y seguridad.
A través de esta inversión del 20%, los desarrolladores y operadores pueden brindar soluciones a largo plazo a los problemas que se encuentran en el trabajo diario y garantizar que la deuda técnica no obstaculice el desarrollo y la operación rápida y segura.
6.3.4 Mejorar la visibilidad del trabajo 47
6.4 Uso de herramientas para reforzar el comportamiento deseado 47
Los desarrolladores y operadores no solo comparten objetivos comunes, sino que también tienen la misma lista de tareas. Idealmente, las listas de tareas se almacenan en un sistema de trabajo común,
Se pueden crear colas de trabajo compartidas en lugar de usar diferentes herramientas (por ejemplo, JIRA para desarrolladores y ServiceNow para operaciones)
Cuando los incidentes de producción son visibles en el sistema de trabajo del desarrollador, las personas pueden saber claramente cuándo el incidente afectará a otro trabajo.Esto es especialmente obvio cuando se utilizan diagramas de tablero Kanban.
Otro beneficio de la cola compartida es que la lista de tareas está unificada. Todos pueden pensar en la prioridad más alta desde una perspectiva global. Cuando se encuentra una deuda técnica, se puede agregar a la lista de tareas si no se puede resolver de inmediato. Para problemas pendientes, el 20% del tiempo reservado para requisitos no funcionales se puede utilizar para solucionarlos.
6.5 Resumen 48
Capítulo 7 Diseño de estructuras organizacionales usando la ley de Conway 49
7.1 Arquetipos organizacionales 51
7.2 Peligros de una excesiva orientación funcional (“optimización de costes”) 51
Las organizaciones tradicionales de operación y mantenimiento de TI a menudo adoptan una estructura funcional, organizando equipos según áreas de especialización. Los administradores de bases de datos se agrupan en un grupo, los administradores de redes en otro, los administradores de servidores en un tercero, y así sucesivamente. Este enfoque obviamente prolonga los plazos de entrega, especialmente en actividades complejas como implementaciones a gran escala donde tener que emitir un montón de órdenes de trabajo a varios equipos y coordinar las entregas de trabajo genera largas demoras en cada paso.
Además de provocar largas esperas y plazos de entrega prolongados, esta situación puede dar lugar a entregas deficientes, reelaboración extensa, calidad de entrega reducida, cuellos de botella y retrasos.
7.3 Creación de equipos orientados al mercado ("optimizados para la velocidad") 52
En casos extremos, los equipos orientados al mercado son responsables no solo del desarrollo de características, sino también de las operaciones de prueba, seguridad, implementación y producción a lo largo del ciclo de vida de la aplicación. Estos equipos multifuncionales pueden operar de forma independiente
Para lograr la orientación al mercado, incorpore ingenieros y sus habilidades profesionales (como operaciones y mantenimiento, control de calidad y seguridad de la información) en cada equipo de servicio, o proporcione a los equipos plataformas de autoservicio, cuyas funciones incluyan la configuración de entornos de producción, la realización de pruebas automatizadas o realizando el despliegue.
Esto permite que cada equipo de servicio entregue valor a los clientes de forma independiente sin tener que enviar tickets a otros departamentos, como operaciones de TI, control de calidad o seguridad de la información.
7.4 Hacer efectiva la orientación funcional 53
Siempre que el equipo de servicio pueda obtener ayuda confiable del equipo de operación y mantenimiento rápidamente (preferiblemente a pedido), la organización funcional centralizada de operación y mantenimiento también puede operar de manera eficiente, y viceversa. Muchas empresas conocidas de DevOps, incluidas Google, Etsy y GitHub, han conservado equipos de operaciones funcionales.
Siempre que todas las personas en el flujo de valor conozcan los objetivos del cliente y la organización, sin importar dónde se encuentren en la organización, pueden lograr los resultados DevOps deseados a través de la orientación funcional.
Lo que estas organizaciones tienen en común es una cultura de alta confianza, donde todos los departamentos pueden colaborar de manera efectiva, todo el trabajo se prioriza de manera transparente y el sistema reserva suficiente capacidad para completar rápidamente el trabajo de alta prioridad. Esto se logra en parte mediante una plataforma de autoservicio automatizada, que garantiza la calidad del producto.
7.5 Integrar las pruebas, la operación y el mantenimiento y la seguridad de la información en el trabajo diario 54
7.6 Convertir a los miembros del equipo en generalistas 54
Una contramedida es hacer que todos los miembros del equipo sean generalistas (consulte la tabla 7-1). Brinde a los ingenieros la oportunidad de aprender las habilidades necesarias para construir y ejecutar los sistemas de los que son responsables, y rotarlos entre roles de manera regular.
A través de la capacitación cruzada y la mejora de las habilidades, los generalistas pueden hacer más que los profesionales, al mismo tiempo que mejoran el flujo de trabajo general al reducir las tareas en las colas y los tiempos de espera.
El entrenamiento cruzado de habilidades múltiples es excelente para el desarrollo profesional de los empleados y hace que el trabajo sea más interesante para todos los empleados.
7.7 Invertir en servicios y productos, no en proyectos 56
7.8 Establecimiento de los límites del equipo de acuerdo con la Ley 56 de Conway
Cuando los equipos están en diferentes pisos, diferentes edificios de oficinas o incluso en diferentes zonas horarias, se vuelve más difícil establecer y mantener objetivos comunes y confianza mutua, lo que es perjudicial para una colaboración eficaz. Es difícil para los equipos colaborar de manera efectiva cuando el principal mecanismo de comunicación es un ticket o una solicitud de cambio.
La organización irrazonable del equipo puede tener consecuencias adversas. Estas formas inapropiadas incluyen dividir los equipos por función (como albergar a los desarrolladores y probadores en diferentes ubicaciones de oficina, o subcontratar completamente a los probadores) y dividir los equipos por capas arquitectónicas (como capa de aplicación, capa de base de datos, etc.).
La organización inadecuada requiere mucha comunicación y coordinación entre los equipos, pero aún puede dar lugar a una gran cantidad de reelaboración, desacuerdos sobre las definiciones de los requisitos, transferencias de trabajo ineficientes, personas ociosas que esperan que finalice el flujo ascendente, etc.
Idealmente, la arquitectura de software debería garantizar que los equipos pequeños puedan operar de forma independiente y estar completamente desvinculados entre sí, evitando así una comunicación y coordinación excesivas e innecesarias.
7.9 Creación de arquitecturas débilmente acopladas para mejorar la productividad y la seguridad 57
Una arquitectura que permite a los equipos pequeños desarrollar, probar e implementar de forma independiente, segura y rápida puede aumentar y mantener la productividad de los desarrolladores y mejorar la calidad de la implementación. La arquitectura orientada a servicios SOA tiene esta característica. Es un enfoque arquitectónico que admite la implementación y la prueba independientes de servicios y, por lo general, se caracteriza por servicios débilmente acoplados con contextos limitados.
Una arquitectura débilmente acoplada significa que un servicio se puede actualizar de forma independiente en un entorno de producción sin actualizar otros servicios.
Un contexto acotado es algo que un desarrollador debería poder comprender y actualizar el código de un servicio sin conocer la lógica interna de su servicio del mismo nivel. Los servicios interactúan estrictamente a través de API, por lo que no tienen que compartir estructuras de datos, esquemas de bases de datos u otras representaciones internas de objetos. Los contextos acotados aseguran que los servicios se dividan en partes independientes con interfaces bien definidas, lo que también facilita las pruebas.
7.10 Resumen 60
Capítulo 8 Integración de las operaciones y el mantenimiento en el trabajo de desarrollo diario 61
Cómo los equipos de operaciones centralizadas pueden lograr resultados impulsados por el mercado. Las siguientes son 3 estrategias generales:
Desarrollar capacidades de autoservicio para ayudar a los desarrolladores a mejorar la productividad;
Integrar a los ingenieros de operación y mantenimiento en el equipo de servicio;
Si el número de ingenieros de operación y mantenimiento es reducido, puede utilizar el enlace de operación y mantenimiento modelo.
8.1 Crear servicios compartidos para mejorar la productividad del desarrollo 62
Un enfoque para que las operaciones logren resultados impulsados por el mercado es crear un conjunto centralizado de plataformas y conjuntos de herramientas que todos los equipos de desarrollo puedan usar para aumentar la productividad, lo que permite que los equipos de desarrollo gasten más energía y tiempo en la creación de características que en la adquisición de la infraestructura necesaria para entregar y brindar soporte. características de producción.
Idealmente, todas las plataformas y servicios proporcionados por O&M deben estar completamente automatizados y disponibles bajo demanda, sin requerir que los desarrolladores envíen órdenes de trabajo y luego esperen a que el equipo de O&M procese manualmente, lo que puede garantizar que O&M no se convierta en un cuello de botella del cliente.
8.2 Integración de ingenieros de operación y mantenimiento en el equipo de servicio 63
Otra forma de lograr resultados impulsados por el mercado es reducir la dependencia de las operaciones centralizadas mediante la inclusión de ingenieros de operaciones para que los equipos de productos sean autosuficientes.
Al integrar a los ingenieros de operaciones en el equipo de desarrollo, sus prioridades de trabajo están impulsadas casi en su totalidad por los objetivos de sus equipos de productos.
Sin embargo, las entrevistas y las decisiones de contratación aún pueden ser realizadas por equipos de operaciones centralizadas para garantizar la coherencia y la calidad de los empleados.
Para nuevos proyectos de desarrollo a gran escala, los ingenieros de operaciones y mantenimiento pueden integrarse en la fase de puesta en marcha. Participarán en discusiones relevantes del equipo de desarrollo, como reuniones de planificación, reuniones diarias y demostraciones de nuevas funciones. A medida que la demanda del equipo de desarrollo de conocimientos y capacidades de operación y mantenimiento disminuye gradualmente, los ingenieros de operación y mantenimiento pueden transferirse a otros proyectos o trabajos intermedios,
8.3 Asignar enlaces de operación y mantenimiento a cada equipo de servicio 64
Debido a varios motivos (como el costo o la insuficiencia de recursos), es posible que no sea posible asignar un ingeniero de operación y mantenimiento a cada equipo de producto, pero se puede asignar una persona de contacto de operación y mantenimiento a cada equipo de producto.
Un equipo de operaciones centralizado sigue gestionando todos los entornos y es responsable de garantizar su coherencia. Es responsabilidad del ingeniero de operación y mantenimiento enviado entender lo siguiente:
Cuál es la función del nuevo producto y por qué se desarrolla este producto;
Cómo funciona, cómo es la operabilidad, escalabilidad y capacidades de monitoreo
Cómo monitorear y recopilar métricas, y cómo confirmar que la aplicación funciona correctamente; ¿Son la arquitectura y los patrones diferentes de lo que se ha
hecho en el pasado, y por qué? Programas de lanzamiento de características.
El enlace de operación y mantenimiento también debe participar en la reunión de trabajo del equipo, incorporar las necesidades del equipo en el plan general de operación y mantenimiento y realizar tareas relacionadas cuando sea necesario. Cuando surge la competencia por los recursos o las prioridades en conflicto, el equipo confía en el enlace de operaciones para hacer avanzar el problema.
En comparación con el modo de integración de ingenieros de operación y mantenimiento, el método de asignación de enlaces de operación y mantenimiento puede admitir más equipos de productos. Nuestro objetivo es asegurarnos de que Ops no se convierta en un cuello de botella para los equipos de productos. Si se descubre que los equipos de productos no están alcanzando sus objetivos debido a que el enlace de operaciones está abrumado, puede ser necesario reducir la cantidad de equipos respaldados por cada enlace o integrar temporalmente a los ingenieros de operaciones en algunos equipos de productos.
8.4 Invitar a los ingenieros de operación y mantenimiento a participar en las reuniones del equipo de desarrollo 65
8.4.1 Invitar a los ingenieros de operación y mantenimiento a participar en la reunión diaria de pie 65
El stand-up diario es el formato preferido por Scrum. Esta es una reunión de solución rápida, y todos deben aclarar tres cosas para todos: ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Qué problema encontraste?
Con la participación de los ingenieros de operaciones en la reunión, el departamento de operaciones puede comprender completamente las actividades del equipo de desarrollo, a fin de planificar y prepararse mejor. Por ejemplo, cuando el equipo de producto planea lanzar una característica principal en dos semanas, el equipo de operaciones puede asegurarse de que las personas y los recursos necesarios para implementar y lanzar estén listos con anticipación, o mejorar las áreas que requieren más comunicación y preparación ( como la creación de más puntos de supervisión o secuencias de comandos automatizadas, como el ajuste en segundo plano de la base de datos, como la creación de más entornos para pruebas de integración y pruebas de rendimiento
8.4.2 Invitar a los ingenieros de operación y mantenimiento a participar en la reunión retrospectiva 66
Reunión de revisión. Al final de cada ciclo de desarrollo, los miembros del equipo se reúnen para discutir: ¿qué tuvo éxito? ¿Qué áreas aún necesitan mejorar? ¿Cómo se trasladarán los éxitos y las mejoras logradas a la siguiente iteración o proyecto?
Cuando ocurre una implementación o lanzamiento durante el período de tiempo que se revisa, el ingeniero de operaciones debe informar los resultados a todos y proporcionar comentarios al equipo del producto. Si lo hace, puede mejorar la forma en que se planifica y ejecuta el trabajo futuro, aumentando la calidad del trabajo.
Debemos recordar a todos que mejorar el trabajo del día a día es más importante que el trabajo del día a día en sí mismo, y todos los equipos deben reservar tiempo para esto (por ejemplo, destinar el 20% de cada ciclo a mejorar el trabajo, programar un día a la semana o un día al mes) semana, etc.). Si esto no se hace, la productividad del equipo seguramente se destruirá bajo la enorme presión de pagar la deuda técnica.
8.4.3 Uso de diagramas Kanban para mostrar el trabajo de operación y mantenimiento 66
El trabajo de operaciones es parte del flujo de valor, por lo que debe estar representado en el tablero Kanban junto con otro trabajo relacionado con la entrega del producto.