Cómo comenzar la transformación de DevOps

Si no comprende qué es DevOps, aquí hay una breve hoja de trucos. DevOps es un conjunto de prácticas que reducen los temores de los ingenieros y reducen el número de fallas en la producción de software. Como regla general, también reducen el tiempo de comercialización : el período desde la idea hasta la entrega del producto final a los clientes, lo que le permite realizar rápidamente experimentos comerciales .

¿Cómo comenzar la transformación de DevOps? En resumen: seleccionamos el servicio desde el cual comenzaremos el proceso, identificamos a aquellos que están relacionados con el servicio, construimos el Mapa de flujo de valor, creamos un equipo temporal que se encargará de la transformación por primera vez y le asigna una tarea. Repetimos el ciclo tantas veces como sea necesario.


Un detallado plan de transformación de DevOps con ejemplos e instrucciones debajo del corte se encuentra en la decodificación del informe de Andrei Alexandrov , un ingeniero de Express42, que aconseja germinar DevOps, acelerar este proceso, porque ya ha construido un mapa de rastrillo. Si le parece que no necesita la transformación, o si tiene tales detalles que las prácticas de DevOps no son adecuadas, use el informe como una instrucción para encontrar y eliminar restricciones.

Si le preocupa el tema de la transformación de DevOps, entonces tiene una gran empresa y necesita escalar gradualmente este proceso a toda la estructura. Mientras exista la necesidad de transformar el equipo o eliminar algún tipo de restricción, el siguiente algoritmo puede repetirse.

Selección de servicios

Hemos delineado un plan, comience con el primer paso: elegir un servicio. El primer criterio es la vida útil : existen servicios antiguos, heredados y nuevos. Puedes comenzar con esos y otros.

Es lógico elegir un servicio joven . Es nuevo, no existe un proceso bien establecido de trabajo en un equipo que se encargue de ello. A su alrededor no hay una montaña de deudas técnicas, no es necesario repararla todo el tiempo. Podemos hacer lo que queramos con él.

En el caso del antiguo servicio, hay problemas asociados con el hecho de que siempre es difícil cambiarlo . Ya existe una serie de restricciones serias, pero tal vez las personas que están listas para empujar todo lo están haciendo, están cansadas y quieren hacer algo diferente, porque duele.

Trabajar con el servicio anterior crea un precedente poderoso en su empresa: puede cambiar algo. Si cambia un nuevo servicio, se activa para producir 100 veces por hora, y todo está bien, entonces las personas en su empresa pueden decir:

- Este es un nuevo servicio! Allí todo era simple, trata de hacer algo con nuestras proxenetas.

Tiene sentido llevar un servicio heredado a una transformación cuando lo haces con alguien, por ejemplo, si invitaste a un consultor externo. Seamos honestos, la transformación escalonará todo lo que sea posible . Está experimentando y no sabe de dónde vendrá, qué tecnologías y por qué utilizará, dónde y qué dificultades surgirán en los procesos. Por lo tanto, un nuevo cambio es más fácil.

Si hace todo usted mismo, pero la empresa no tiene una competencia seria, tomamos un nuevo servicio. Si conoce a un consultor externo y hay fondos, elija el anterior.

Hay servicios que son solo una interfaz para los usuarios, por ejemplo, un sitio web simple o una aplicación móvil. Pero hay cosas serias en el espíritu de la facturación. Si algo sale mal con la facturación, será difícil de entender. Aquí también tenemos una opción.

Trabajamos con un servicio crítico , pero ya sufrimos por eso, crea restricciones o trabajamos con la interfaz . Este es el segundo criterio de selección. Del mismo modo, es posible atraer a un consultor experimentado: trabajamos con una opción difícil.

Pero incluso en este caso, no recomendaría hacerlo, porque si bien no se entiende con qué trabajar y cómo transformar, tomar una cosa crítica y sacudirla no es una buena idea. Por lo tanto, en este caso, preferimos trabajar con una interfaz cuyo fallo no sea crítico.

A continuación, considere el comando de servicio . Con aquellos que participan en este servicio, tendremos que trabajar constantemente e interactuar en un contacto muy cercano.

Las personas en el equipo se dividen condicionalmente en dos categorías: conservadores : viven en el viejo mundo o simplemente no saben nada sobre DevOps e innovadores que llevan todas las prácticas de moda. Estos últimos no siempre entienden el tema, pero al menos están listos para ello.

Por un lado, los conservadores son personas experimentadas: han estado con la empresa durante mucho tiempo, lo entienden completamente, pero no conocen las prácticas. Por otro lado, hay innovadores que han escuchado algo, pero lo más probable es que hayan estado trabajando para la compañía no hace mucho tiempo. ¿Con cuál de ellos es mejor trabajar?

En cualquier caso, tendrá que interactuar con los conservadores, ya que este es su servicio. Tendremos que comunicarnos con ellos, conocer los detalles del servicio, qué se puede hacer de esta manera y qué es diferente. Dependemos de sus consejos. Seguramente tendrán que confiar algo, porque conocen mejor su servicio. Por lo tanto, es importante con qué equipo eventualmente tendremos contacto.

Es lógico elegir un equipo innovador, porque los conservadores pueden poner un cerdo.

En la práctica, a menudo sucede que las personas conservadoras tienen una experiencia significativa, pero no se comprende cómo vivir. Simplemente tienen miedo de que después de la transformación y alteración del servicio, serán despedidos por ser innecesarios. A veces, simplemente debido a la falta de comprensión de lo que está sucediendo, sabotean el trabajo.

Tuve un caso cuando un chico de un equipo reparó algo, porque supuestamente es más crítico que lo que estamos haciendo ahora. Establecimos la tarea: realizar esta pieza hoy, no, hay un incendio en el otro lado del mundo, vamos a repararlo. Es difícil trabajar con esas personas.

Las personas del equipo conservador a menudo obstruyen las tareas o las posponen hasta el final. Y si John Willis lo salvó, cometió un error y los colgó con KPI por la cantidad de tareas completadas, y por alguna razón algunos de ellos no se incluyeron en KPI, entonces no harán nada en absoluto. En general, tendrán razón, porque luego pierden el bono.

Es más fácil con los innovadores: son más leales . Ya escucharon algo, quieren ir a algún lado, por lo que ayudarán. Necesitamos personas que estén listas para sufrir la primera vez: si el servicio cambia, entonces todos los conos y rastrillos serán capturados por los innovadores como pioneros. Los innovadores quieren lo más nuevo y lo más de moda, y sufren.

Los conservadores pueden luego convertirse. Cuando demuestres que has cambiado una pieza y que todo funciona bien, lo más probable es que también quieran probar y adoptar la nueva religión DevOps.

Para resumir. Si hacemos toda la transformación en nuestra empresa nosotros mismos, entonces elegimos: un nuevo servicio, preferiblemente una interfaz simple, para no sufrir mucho por su falla, y un equipo de innovadores.

Si es posible llamar a un consultor externo, en lugar de uno nuevo, tomamos el servicio anterior, por lo que ya estamos sufriendo. Las personas que han estado involucradas en la transformación durante bastante tiempo en diferentes compañías han visto diferentes casos y ya entienden cómo hacerlo correctamente y qué camino tomar en general.

¿Quien esta involucrado?

Necesitamos encontrar en general a todos los que tienen al menos algo que ver con el servicio: desarrolladores, evaluadores, administradores, guardias de seguridad, gerentes y posiblemente propietarios de productos. A pesar de que los propietarios de productos no son expertos en tecnología, están relacionados con el servicio: tomar una decisión, establecer una tarea.

Todos los que toman al menos algunas decisiones e influyen en lo que está sucediendo con el servicio deben encontrar, conocer y chatear.

¿Qué son para nosotros? Para saber con quién negociar . Durante la transformación, cuando cambia el principio habitual de trabajar con el servicio, se sacudirá de todos modos. Habrá fallas durante un tiempo mientras probamos nuevos enfoques. La gente debería estar preparada para esto y estar de acuerdo con eso.

Luego, debe crear un Mapa de flujo de valor y sin estas personas no puede construirlo, porque solo todos juntos saben la imagen completa de lo que está sucediendo. Una persona nunca sabe todo lo que sucede con el servicio.

Asesorarán a las personas del equipo. Más adelante discutiremos por qué se necesita un equipo separado. Tendrá que tomar personas de los departamentos existentes. Quienes estén relacionados con el servicio podrán recomendar colegas que piensen en nuestra dirección, que nos puedan ayudar y que tengan la competencia en lo que necesitamos.

Luego reunimos a todas estas personas de diferentes departamentos en una habitación y comenzamos a construir un Mapa de flujo de valor.

Crear un mapa de flujo de valor

Value Stream Map es un diagrama o mapa que muestra el flujo de valores al cliente . Este es todo el proceso desde la invención de una idea hasta su implementación, incluidas todas las etapas intermedias y cómo el valor finalmente llega a nuestros clientes.

El Value Stream Map es necesario para visualizar todas las etapas de desarrollo , localizar problemas a través de mediciones que se encuentran en el proceso actual y comenzar a eliminar estos problemas y establecer una meta inicial . Este es el lugar donde realmente comenzaremos a hacer algo.

Métricas

Hay muchas métricas diferentes descritas en la literatura de Value Stream Map, pero para empezar, solo necesitamos tres.

Plazo de ejecución - retraso / espera - el tiempo cuando esperamos algo. Por ejemplo, el probador espera hasta que se libere el banco de pruebas y no puede hacer nada en este momento.

Tiempo de valor agregado, el tiempo de trabajo útil , el que pasamos en tal o cual etapa para crear el valor final para el usuario. Por ejemplo, un probador realizó su prueba y comenzó a probar algo. Este es el momento de trabajo útil cuando realmente hacemos algo por el producto. Esto es lo que pagan los clientes: un software de calidad.

% C / A: porcentaje del trabajo aceptado. Tenemos una etapa: desarrollo, la segunda etapa: pruebas. Cuántas características obtuvieron los probadores de los desarrolladores, y existe este porcentaje.

Así es como se ve nuestro mapa.



Puede verse diferente según la estructura de la organización, la cantidad de departamentos y lo que haga. Pero en el caso general, el mapa tendrá dos etapas: una idea y análisis . En este punto, se esperan datos, por ejemplo, Tiempo de entrega 2 semanas y Tiempo de valor agregado 2 días.

Las métricas cubren absolutamente todas las etapas.

Retraso : cuántas tareas quedan después de que los analistas se les ocurrieron.

El desarrollo (cuántas semanas los desarrolladores han estado esperando aclaraciones sobre tareas, stands o equipos) no importa, pero están esperando algo. Por ejemplo, implementan una función durante 4 días. La métrica% C / A aparece aquí. Los desarrolladores tomaron solo el 80% de las tareas de Backlog. Creen que el 20% restante no tienen conocimientos tradicionales claros y los enviaron para su revisión.

Pruebas En el esquema LT, se establecen 4 días. Por ejemplo, los evaluadores esperaban a que se lanzara el banco de pruebas, VA durante 2 días, realmente estaban probando algo y% C / A = 40%. - solo el 40% del código o las características que los desarrolladores enviaron fueron considerados por los evaluadores como adecuados. No les gustó el resto por alguna razón.

No me detendré en cómo llevar a cabo estas mediciones, al final del artículo recomendaré literatura de la que puede aprender sobre ellas.

Lo único que te aconsejo es que no creas a las personas que compondrán el Value Stream Map contigo. Representan cuánto tiempo toman los diferentes procesos, pero estas estimaciones no siempre son correctas, por lo tanto, es mejor medirse.

Tuvimos un caso cuando llegamos al departamento de Operaciones y preguntamos cuánto tiempo lleva entregar una nueva característica a la producción. Ellos respondieron que 10 minutos, y pensamos, ¿por qué vinimos a esta empresa? Resultó que 10 minutos es el tiempo de ejecución del script, que toma el código y lo entrega al servidor. Pero antes de esto, la versión se encuentra tres días en el servidor y solo acumula polvo: en Backlog se encuentra la tarea que debe implementarse. Resulta que antes de la etapa de implementación hay una etapa de espera cuando el proyecto simplemente se encuentra. Si no hubiéramos ido con un cuaderno, no hubiéramos captado nuestra atención en una tarea en Jira, y no hubiéramos comenzado a rastrearlo por etapas, habríamos pensado que todo era maravilloso y que no había ningún problema.

Por lo tanto, las mediciones deberán realizarse usted mismo, preferiblemente más de una vez, para tener una representación cercana a la realidad. Dependiendo del Value Stream Map, usted decidirá dónde comenzar y qué solucionar primero.

Equipo temporal

Muchas empresas que han decidido presentar DevOps crean un equipo, no solo temporal, sino que existe desde hace varios años. Si va al servicio de disculpas de DevOps, que describe los diferentes patrones para construir una estructura organizacional en DevOps, entonces comprenderá que esto es un antipatrón.

Cuando el equipo de DevOps ha existido continuamente durante varios años, esto es un gran error, porque DevOps se trata de la comunicación entre departamentos, de la velocidad y la eficiencia.

Si un equipo existe entre departamentos, solo para hacer otra cosa por separado, y existe por mucho tiempo, entonces crea una barrera adicional. Ahora, en lugar de dirigirse directamente al administrador, el programador debe contactar primero al departamento de DevOps, y él irá más allá.

Por lo tanto, para comenzar, debe crear un equipo temporal . Existirá por un período suspendido de seis meses, máximo un año, dependiendo de la tarea, solo para eliminar una limitación que hayamos elegido. Entonces ella morirá. Si elegimos el siguiente punto donde duele mucho y entendemos que también necesitamos un equipo separado para ello, lo crearemos nuevamente. Pero tales equipos no deberían existir de forma "permanente", entonces solo interrumpen la comunicación y asumen tareas separadas en general, solo para hacer algo. Estas tareas pueden no estar relacionadas con DevOps o la transformación en absoluto. ¿Por qué no asignamos esta tarea a los departamentos existentes?

¿Por qué necesitas un equipo temporal?

Conflicto con los procesos actuales . La transformación de DevOps es un cambio no solo de las tecnologías y herramientas que usamos, sino también un cambio en el proceso de trabajo, pensamiento y valores. Si el equipo funciona como solía hacerlo, no podrá probar otros enfoques.

Estas personas deben vivir según reglas diferentes: ignorar todos los KPI de la empresa, porque intentan trabajar de manera diferente. Los equipos temporales no completarán las solicitudes para obtener un servidor, sino que irán directamente al departamento que los administra, exigiendo que sean los primeros en dar lo que necesitan, porque esta es una tarea prioritaria y porque intentan vivir de manera diferente. El equipo tiene un conflicto completo con todos los procesos actuales. Para que los métodos de trabajo existentes no interfieran con ellos ahora, y no interfieran con otros, aislamos a estas personas separándolas como un equipo separado.

Evitar la burocracia en los experimentos . No existe burocracia en los equipos temporales; no completan informes sobre las horas de trabajo; no informan a los gerentes. Este es un mundo completamente separado en el que las personas viven y piensan de manera diferente, y hacen cosas completamente diferentes. No los molestes una vez más.

Trabajo ininterrumpido en el servicio . En el primer párrafo, hemos elegido algo con lo que experimentar. Experimentar y encontrar formas de trabajar mejor es bueno, pero también queremos hacer funciones. Si todo el equipo se involucra en la transformación en lugar de las características, entonces comenzaremos a perder ingresos, los errores se bloquearán durante mucho tiempo, no lo necesitamos. Crear un equipo temporal le permite experimentar sin detener el trabajo en el producto.

No pierdas el tiempo en tareas de trabajo . Esto es nuevamente sobre el producto. Al equipo le lleva mucho tiempo probar otras herramientas y otras cosas. Para que las personas dominen las herramientas, comiencen a implementarlas y las usen normalmente, tomará al menos seis meses. Si también se ocuparán del producto, seis meses se estiran cósmicamente. Si las personas se dedican a un producto, vuelven a trabajar con procesos antiguos; no necesitamos esto.

Por lo tanto, separamos a las personas de diferentes departamentos en un equipo separado que se encargará de la transformación del servicio. Como resultado, el servicio funciona, continúa desarrollándose y, al mismo tiempo, realizamos algunos experimentos.

El equipo temporal solo participa en la transformación de DevOps, eliminando la restricción que encontramos y nada más.

El equipo está formado por personas universales . Esto significa que no solo tomamos desarrolladores. No vinimos al servicio y no tomamos medio equipo desde allí; no, tomamos personas de diferentes departamentos . Hace unos pocos puntos, encontramos diferentes departamentos y diferentes empleados relacionados con el servicio transformador. De estos, estamos reclutando un equipo, porque debe ser universal: cambiaremos el proceso de prueba, el proceso de desarrollo y el proceso de servicio del servicio. Se necesitan diferentes competencias.

Por lo general, tomamos condicionalmente a un desarrollador, probador e ingeniero, cada uno a la vez, y junto con ellos encontramos una solución que le permite vivir de manera diferente.

Es deseable que estas personas tengan autoridad en la organización . Puede que tenga que tomar uno conservador, aunque no lo desee. Si tenemos una gran empresa, no todos creerán en nuestra empresa, y alguien puede poner palos en las ruedas, por ejemplo, no destacar un stand. Aquí necesitará "autoridad": una persona respetada con una amplia experiencia, que merece una buena actitud de sus colegas. La autoridad del empleado en el equipo simplificará la tarea y el trabajo del equipo temporal. La gente pensará:

- Sí, este tipo genial que todos conocemos y amamos, encaja allí, aparentemente, ¡DevOps tiene algo que vale la pena mirar!

Fijamos una meta

Reunimos personas, elegimos un servicio, observamos las restricciones, determinamos en qué personas influiremos. Ahora debe establecer un objetivo y debe estar justo en SMART ; eso es todo lo que amamos.

Específico - específico .

Medible - medible . Este es un punto muy importante de SMART. Si no puede medir algo, entonces no puede cambiarlo y comprender qué y cómo lo ha hecho mejor o peor.

Alcanzable es alcanzable . Ajuste para sus detalles. Si es una empresa empresarial con una larga historia y una gran carga de responsabilidades, que lanza una versión del producto una vez al año, no podrá lograr el lanzamiento de nuevas versiones del producto cada hora en seis meses. No funcionará de esa manera. Por lo tanto, establezca un objetivo real que se pueda lograr en un período aceptable.

Relevante - Relevante. Solo eliminamos la limitación que realmente persigue nuestros objetivos actuales.

Tiempo limitado: tiempo limitado . Si no hay una fecha límite, el equipo hará cualquier cosa: probar 15 tecnologías en lugar de 3, escribir informes enormes, realizar investigaciones inútiles, hacer que su implementación brille cuando el objetivo ya se haya alcanzado.

Tomamos la meta con la ayuda del Value Stream Map; nuevamente, reunimos a todas las personas y dibujamos. Pero solo ahora, con base en el Mapa de flujo de valor anterior, dibujamos lo que queremos obtener.



Seleccionamos una limitación que eliminaremos en este momento: esto es lo que hará el equipo. Como ejemplo, tomé la expectativa de una versión final para su implementación en producción: esta es la limitación más común que las personas recurren a los consultores.

En base a esto, establecemos la tarea: queremos que la espera entre un lanzamiento listo y entrar en acción sea de un máximo de una hora.

Ejemplos de tareas.

• Reduzca las pruebas de tiempo de entrega de 4 días a 1 hora.
• Reduzca el tiempo de valor agregado para las pruebas de 2 días a 3 horas.
• Reduzca la implementación del tiempo de entrega de 5 horas a 10 minutos.
• Aumentar C / A de 50% a 95%, es decir, aumentar la cantidad de características que los probadores aceptan, en otras palabras, mejorar la calidad de los desarrolladores.

Los ejemplos de tareas no se toman de la cabeza: se basan en las mediciones que hicimos al desarrollar el Mapa de flujo de valor.

Establecemos una tarea similar a nuestro equipo y un límite de tiempo. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

Por qué , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

— DevOps . - , , DevOpsConf , – QaulityConf . ++ Whale Rider — . 27 28 , .