Estado de DevOps en Rusia 2020

¿Cómo entender el estado de algo?

Puede confiar en su opinión, formada a partir de diversas fuentes de información, por ejemplo, publicaciones en sitios web o experiencia. Puedes preguntar a colegas, conocidos. Otra opción es mirar los temas de las conferencias: el comité del programa son representantes activos de la industria, por lo que confiamos en ellos para elegir temas relevantes. Un área separada es la investigación y los informes. Pero hay un problema. La investigación sobre el estado de DevOps se lleva a cabo anualmente en el mundo, las empresas extranjeras publican informes y casi no hay información sobre DevOps rusos.

Pero ha llegado el día en que se realizó un estudio de este tipo, y hoy hablaremos sobre los resultados. El estado de DevOps en Rusia fue estudiado conjuntamente por las empresas "expreso 42"Y"óntico". Express 42 ayuda a las empresas de tecnología a implementar y desarrollar prácticas y herramientas de DevOps y fue una de las primeras en hablar sobre DevOps en Rusia. Los autores del estudio, Igor Kurochkin y Vitaly Khabarov, se dedican al análisis y la consultoría en Express 42, y tienen antecedentes técnicos de operación y experiencia en diferentes empresas. Durante 8 años, los colegas han observado docenas de empresas y proyectos, desde nuevas empresas hasta empresas, con diferentes problemas, así como diferentes madurez cultural y de ingeniería.

En su informe, Igor y Vitaly contaron qué problemas hubo en el proceso de investigación, cómo los resolvieron, así como también cómo se lleva a cabo la investigación DevOps en principio y por qué Express 42 decidió realizar la suya propia. Su informe se puede ver aquí.

Investigación DevOps

La conversación la inició Igor Kurochkin.

Regularmente preguntamos a la audiencia en las conferencias de DevOps: "¿Ha leído el informe de estado de DevOps de este año?" Pocos levantan la mano, y nuestro estudio mostró que solo un tercio los estudia. Si nunca ha visto tales informes, digamos de inmediato que todos son muy similares. La mayoría de las veces hay frases como: "En comparación con el año pasado ..."

Aquí tenemos el primer problema, y ​​después de él dos más:

1. No tenemos datos del año pasado. El estado de DevOps en Rusia no interesa a nadie;
2. Metodología. No está claro cómo probar hipótesis, cómo construir preguntas, cómo analizar, comparar resultados, encontrar conexiones;
3. Terminología. Todos los informes están en inglés, se requiere traducción, aún no se ha inventado un marco DevOps común y todos crean el suyo propio.

Echemos un vistazo a cómo se han realizado los análisis de estado de DevOps en todo el mundo.

La información histórica

La investigación de DevOps se lleva a cabo desde 2011. Puppet, un desarrollador de sistemas de gestión de configuración, fue el primero en realizarlos. En ese momento, era una de las principales herramientas para describir la infraestructura en forma de código. Hasta 2013, estos estudios eran simplemente encuestas cerradas y ningún informe público.

En 2013, apareció IT Revolution, el editor de todos los libros importantes sobre DevOps. Junto a Puppet prepararon la primera publicación State of DevOps, donde aparecían por primera vez 4 métricas clave. Al año siguiente, se involucró ThoughtWorks, una firma consultora conocida por sus radares tecnológicos regulares sobre prácticas y herramientas de la industria. Y en 2015, se agregó una sección con metodología, y quedó claro cómo realizan el análisis.

En 2016, los autores del estudio, habiendo creado su propia empresa DORA (DevOps Research and Assessment), publicaron un informe anual. Al año siguiente, DORA y Puppet publicaron su último informe conjunto.

Y entonces comenzó algo interesante:

En 2018, las empresas se separaron y se publicaron dos informes independientes: uno de Puppet, el segundo de DORA en conjunto con Google. DORA ha seguido aprovechando su metodología con métricas clave, perfiles de desempeño y prácticas de ingeniería que impactan las métricas clave y el desempeño de toda la empresa. Y Puppet ofreció su propio enfoque con una descripción del proceso y la evolución de DevOps. Pero la historia no echó raíces, en 2019 Puppet abandonó esta metodología y lanzó una nueva versión de los informes, que enumeraba las prácticas clave y cómo afectan a DevOps desde su punto de vista. Luego sucedió otro evento: Google compró DORA y juntos publicaron otro informe. Es posible que lo hayas visto.

Este año, las cosas se complicaron. Se sabe que Puppet lanzó su propia encuesta. Lo hicieron una semana antes que nosotros, y ya terminó. Participamos en él y miramos qué temas les interesan. Ahora Puppet está haciendo su análisis y preparándose para publicar el informe.

Pero todavía no hay ningún anuncio de DORA y Google. En mayo, cuando normalmente comenzaba la encuesta, llegó la información de que Nicole Forsgren, una de las fundadoras de DORA, se había mudado a otra empresa. Por lo tanto, asumimos que no habría investigación ni informe de DORA este año.

¿Cómo están las cosas en Rusia?

No hemos hecho investigación de DevOps. Hablamos en conferencias, volvimos a contar los hallazgos de otras personas, y Raiffeisenbank tradujo "State of DevOps" para 2019 (puede encontrar su anuncio en Habré), muchas gracias a ellos. Y es todo

Por lo tanto, llevamos a cabo nuestra propia investigación en Rusia utilizando metodologías y hallazgos de DORA. Utilizamos el informe de colegas de Raiffeisenbank para nuestra investigación, incluida la sincronización de terminología y traducción. Y las preguntas relevantes para la industria se tomaron de los informes DORA y del cuestionario Puppet de este año.

Proceso de investigación

El informe es sólo la parte final. Todo el proceso de investigación consta de cuatro pasos principales:

Durante la fase de preparación, entrevistamos a expertos de la industria y preparamos una lista de hipótesis. Sobre esta base, se compilaron preguntas y se lanzó una encuesta para todo agosto. Luego analizamos y preparamos el propio informe. Para DORA, este proceso toma 6 meses. Nos reunimos en 3 meses, y ahora entendemos que apenas teníamos tiempo: solo al realizar el análisis, comprende qué preguntas debe hacer.

Los participantes

Todos los reportajes extranjeros comienzan con un retrato de los participantes, y la mayoría de ellos no son de Rusia. El porcentaje de encuestados rusos fluctúa entre el 5 y el 1 % de un año a otro, y esto no permite sacar ninguna conclusión.

Mapa del informe Accelerate State of DevOps 2019:

En nuestro estudio, logramos entrevistar a 889 personas, esto es bastante (DORA encuesta a unas mil personas anualmente en sus informes) y aquí hemos logrado el objetivo:

Es cierto que no todos nuestros participantes llegaron al final: el porcentaje de finalización resultó ser un poco menos de la mitad. Pero incluso esto fue suficiente para obtener una muestra representativa y realizar un análisis. DORA no revela los porcentajes de llenado en sus informes, por lo que aquí no hay comparación.

Industrias y posiciones

Nuestros encuestados representan una docena de industrias. Medio trabajo en tecnología de la información. Le siguen los servicios financieros, comercio, telecomunicaciones y otros. Entre los puestos se encuentran especialistas (desarrollador, probador, ingeniero de operaciones) y personal directivo (jefes de equipos, grupos, áreas, directores):

Uno de cada dos trabaja para una mediana empresa. Cada tercera persona trabaja en grandes empresas. La mayoría trabaja en equipos de hasta 9 personas. Por separado, preguntamos sobre las principales actividades, y la mayoría están relacionadas de alguna manera con la operación, y alrededor del 40% se dedican al desarrollo:

Entonces recopilamos información para comparar y analizar representantes de diferentes industrias, empresas, equipos. Mi colega Vitaly Khabarov hablará sobre el análisis.

Análisis y comparación

Vitaly Khabarov: Muchas gracias a todos los participantes que completaron nuestra encuesta, completaron cuestionarios y nos proporcionaron datos para un mayor análisis y prueba de nuestras hipótesis. Y gracias a nuestros clientes y clientes, tenemos una gran experiencia que nos ha ayudado a identificar las preocupaciones de la industria y formular las hipótesis que probamos en nuestra investigación.

Desafortunadamente, no puede simplemente tomar una lista de preguntas por un lado y datos por el otro, compararlos de alguna manera, decir: "Sí, todo funciona así, teníamos razón" y dispersarse. No, se necesita metodología y métodos estadísticos para estar seguros de que no nos equivocamos y nuestras conclusiones son fiables. Entonces podemos construir nuestro trabajo adicional basado en estos datos:

Llaves metricas

Tomamos como base la metodología DORA, que describieron en detalle en el libro “Accelerate State of DevOps”. Verificamos si las métricas clave son adecuadas para el mercado ruso, si se pueden usar de la misma manera que DORA para responder a la pregunta: "¿Cómo se corresponde la industria en Rusia con la industria extranjera?"

Llaves metricas:

1. Frecuencia de despliegue. ¿Con qué frecuencia se implementa una nueva versión de la aplicación en el entorno de producción (cambios planificados, excluyendo revisiones y respuesta a incidentes)?
2. El tiempo de entrega. ¿Cuál es el tiempo promedio entre la confirmación de un cambio (escribir la funcionalidad como código) y la implementación del cambio en el entorno de producción?
3. Tiempo de recuperación. ¿Cuánto se tarda en promedio en restaurar una aplicación a un entorno de producción después de un incidente, una degradación del servicio o el descubrimiento de un error que afecta a los usuarios de la aplicación?
4. Cambios fallidos. ¿Qué porcentaje de implementaciones en el entorno de producción conducen a incidentes o degradación de la aplicación y requieren corrección (reversión de cambios, desarrollo de una revisión o parche)?

DORA en su investigación ha encontrado una conexión entre estas métricas y el desempeño organizacional. También lo probamos en nuestro estudio.

Pero para asegurarse de que las cuatro métricas clave puedan influir en algo, debe comprender: ¿están relacionadas entre sí de alguna manera? DORA respondió afirmativamente con una advertencia: la relación entre los cambios fallidos (tasa de fallas en el cambio) y otras tres métricas es ligeramente más débil. Tenemos más o menos la misma imagen. Si el tiempo de entrega, la frecuencia de implementación y el tiempo de recuperación se correlacionan entre sí (establecimos esta correlación a través de la correlación de Pearson y la escala de Chaddock), entonces no existe una correlación tan fuerte con los cambios fallidos.

En principio, la mayoría de los encuestados suelen responder que tienen un número bastante reducido de incidencias en producción. Aunque veremos más adelante que todavía hay una diferencia significativa entre los grupos de encuestados en términos de cambios fallidos, todavía no podemos usar esta métrica para esta división.

Esto lo atribuimos al hecho de que (tal como resultó durante el análisis y la comunicación con algunos de nuestros clientes) existe una ligera diferencia en la percepción de lo que se considera un incidente. Si logramos restaurar el rendimiento de nuestro servicio durante la ventana técnica, ¿se puede considerar esto como un incidente? Probablemente no, porque arreglamos todo, somos geniales. ¿Podemos considerar un incidente si tuviéramos que volver a ejecutar nuestra aplicación 10 veces en un modo normal y familiar para nosotros? parece que no Por lo tanto, la cuestión de la relación de los cambios fallidos con otras métricas permanece abierta. Lo perfeccionaremos más.

Aquí es importante que encontramos una correlación significativa entre los tiempos de entrega, los tiempos de recuperación y la frecuencia de implementación. Por lo tanto, tomamos estas tres métricas para dividir aún más a los encuestados en grupos de desempeño.

¿Cuánto cuesta en gramos?

Utilizamos análisis de conglomerados jerárquicos:

• Distribuimos a los encuestados en un espacio de n dimensiones, donde la coordenada de cada encuestado son sus respuestas a las preguntas.
• Cada encuestado se declara un pequeño grupo.
• Combinamos los dos grupos más cercanos entre sí en un grupo más grande.
• Encontramos el siguiente par de grupos y los combinamos en un grupo más grande.

Así es como agrupamos a todos nuestros encuestados en la cantidad de grupos que necesitamos. Con la ayuda de un dendrograma (un árbol de conexiones entre clústeres), vemos la distancia entre dos clústeres vecinos. Todo lo que nos queda es establecer un cierto límite de distancia entre estos grupos y decir: "Estos dos grupos se distinguen bastante entre sí porque la distancia entre ellos es gigantesca".

Pero aquí hay un problema oculto: no tenemos restricciones en la cantidad de grupos: podemos obtener 2, 3, 4, 10 grupos. Y la primera idea fue: ¿por qué no dividir a todos nuestros encuestados en 4 grupos, como lo hace DORA? Pero encontramos que las diferencias entre estos grupos se vuelven insignificantes, y no podemos estar seguros de que el encuestado realmente pertenezca a su grupo, y no al vecino. Todavía no podemos dividir el mercado ruso en cuatro grupos. Por ello, nos decidimos por tres perfiles entre los que existe una diferencia estadísticamente significativa:

A continuación, determinamos el perfil por clústeres: tomamos la mediana de cada métrica para cada grupo y compilamos una tabla de perfiles de desempeño. De hecho, obtuvimos los perfiles de desempeño del participante promedio en cada grupo. Hemos identificado tres perfiles de eficiencia: Bajo, Medio, Alto:

Aquí confirmamos nuestra hipótesis de que 4 métricas clave son adecuadas para determinar el perfil de rendimiento y funcionan tanto en el mercado occidental como en el ruso. Hay una diferencia entre los grupos y es estadísticamente significativa. Destaco que existe una diferencia significativa entre los perfiles de desempeño en términos de la métrica de cambios fallidos en términos del promedio, aunque inicialmente no dividimos a los encuestados por este parámetro.

Entonces surge la pregunta: ¿cómo usar todo esto?

Cómo usar

Si tomamos cualquier equipo, 4 métricas clave y las aplicamos a la mesa, en el 85% de los casos no obtendremos una coincidencia completa; este es solo un participante promedio, y no lo que es en realidad. Todos somos (y cada equipo) ligeramente diferentes.

Verificamos: tomamos a nuestros encuestados y el perfil de rendimiento de DORA, y observamos cuántos encuestados se ajustan a este o aquel perfil. Encontramos que solo el 16% de los encuestados encajaba definitivamente en uno de los perfiles. Todos los demás están dispersos en algún punto intermedio:

Esto significa que el perfil de eficiencia tiene un alcance limitado. Para comprender dónde se encuentra en la primera aproximación, puede usar esta tabla: "¡Oh, parece que estamos más cerca de Medio o Alto!" Si entiende adónde ir después, esto puede ser suficiente. Pero si su objetivo es la mejora constante y continua, y quiere saber más exactamente dónde desarrollar y qué hacer, entonces se necesitan fondos adicionales. Las llamamos calculadoras:

• calculadora dora
• Calculadora Express 42* (en desarrollo)
• Desarrollo propio (puedes crear tu propia calculadora interna).

¿Para qué se necesitan? Comprender:

• ¿Está el equipo dentro de nuestra organización a la altura de nuestros estándares?
• Si no, ¿podemos ayudarlo, acelerarlo en el marco de la experiencia que tiene nuestra empresa?
• Si es así, ¿podemos hacerlo aún mejor?

También puede usarlos para recopilar estadísticas dentro de la empresa:

• ¿Qué equipos tenemos?
• Divida los equipos en perfiles;
• Ver: Oh, estos comandos tienen un bajo rendimiento (no se retiran un poco), pero son geniales: se implementan todos los días, sin errores, tienen un tiempo de espera de menos de una hora.

Y luego podrá descubrir que dentro de nuestra empresa existe la experiencia y las herramientas necesarias para aquellos equipos que aún no están a la altura.

O, si entiendes que te sientes muy bien dentro de la empresa, eres mejor que muchos, entonces puedes mirar un poco más. Esta es solo la industria rusa: ¿podemos obtener la experiencia necesaria en la industria rusa para acelerarnos? La calculadora Express 42 ayudará aquí (está en desarrollo). Si ha superado el mercado ruso, mire calculadora dora y al mercado mundial.

Bien. Y si estás en el grupo Élit de la calculadora DORA, ¿qué debes hacer? Aquí no hay una buena solución. Lo más probable es que se encuentre a la vanguardia de la industria, y es posible una mayor aceleración y confiabilidad a través de la I+D interna y el gasto de más recursos.

Pasemos a lo más dulce: comparación.

Comparación

Inicialmente queríamos comparar la industria rusa con la industria occidental. Si comparamos directamente, vemos que tenemos menos perfiles, y están un poco más mezclados entre sí, los bordes están un poco más difuminados:

Nuestros artistas de élite están ocultos entre los de alto rendimiento, pero están ahí: estos son los unicornios de élite que han alcanzado alturas significativas. En Rusia, la diferencia entre el perfil Elite y el perfil Alto aún no es lo suficientemente significativa. Creemos que en el futuro esta separación ocurrirá debido a un aumento en la cultura de la ingeniería, la calidad de la implementación de las prácticas de ingeniería y la experiencia dentro de las empresas.

Si pasamos a una comparación directa dentro de la industria rusa, podemos ver que los equipos de alto perfil son mejores en todos los aspectos. También confirmamos nuestra hipótesis de que existe una relación entre estas métricas y el desempeño organizacional: es mucho más probable que los equipos de alto perfil no solo alcancen los objetivos, sino que también los superen.
Convirtámonos en equipos de alto perfil y no nos detengamos ahí:

Pero este año es especial, y decidimos verificar cómo les está yendo a las empresas en una pandemia: los equipos de alto perfil lo están haciendo mucho mejor y se sienten mejor que el promedio de la industria:

• 1,5-2 veces más probabilidades de lanzar nuevos productos,
• 2 veces más probabilidades de mejorar la confiabilidad y/o el rendimiento de la infraestructura de la aplicación.

Es decir, las competencias que ya tenían les ayudaron a desarrollarse más rápido, lanzar nuevos productos, modificar productos existentes, conquistando así nuevos mercados y nuevos usuarios:

¿Qué más ayudó a nuestros equipos?

Prácticas de ingeniería

Le informaré acerca de los hallazgos significativos para cada práctica que probamos. Quizás algo más ayudó a los equipos, pero estamos hablando de DevOps. Y dentro de DevOps, vemos una diferencia entre equipos de diferentes perfiles.

Plataforma como servicio

No encontramos una relación significativa entre la edad de la plataforma y el perfil del equipo: las plataformas aparecieron aproximadamente al mismo tiempo para los equipos bajos y los equipos altos. Pero para estos últimos, la plataforma proporciona, en promedio, más servicios y más interfaces de programación para el control a través del código del programa. Y es más probable que los equipos de la plataforma ayuden a sus desarrolladores y equipos a usar la plataforma, resolver sus problemas e incidentes relacionados con la plataforma con más frecuencia y educar a otros equipos.

Infraestructura como código

Todo es bastante estándar aquí. Encontramos una relación entre la automatización del trabajo del código de infraestructura y la cantidad de información almacenada dentro del repositorio de infraestructura. Los comandos de perfil alto almacenan más información en los repositorios: esta es la configuración de la infraestructura, la canalización de CI/CD, la configuración del entorno y los parámetros de compilación. Almacenan esta información con mayor frecuencia, funcionan mejor con código de infraestructura y automatizan más procesos y tareas para trabajar con código de infraestructura.

Curiosamente, no vimos una diferencia significativa en las pruebas de infraestructura. Atribuyo esto al hecho de que los equipos de alto perfil tienen más automatización de pruebas en general. Quizá no deberían distraerse por separado con las pruebas de infraestructura, sino con esas pruebas con las que comprueban las aplicaciones, y gracias a ellas ya ven qué y dónde se han estropeado.

Integración y entrega

La sección más aburrida, porque comprobamos que cuanta más automatización tengas, mejor trabajas con el código, más posibilidades tienes de obtener mejores resultados.

Arquitectura

Queríamos ver cómo los microservicios afectan el rendimiento. En verdad, no lo hacen, ya que el uso de microservicios no está asociado con un aumento en los indicadores de desempeño. Los microservicios se utilizan tanto para comandos de perfil alto como para comandos de perfil bajo.

Pero lo que es significativo es que, para High-Teams, la transición a una arquitectura de microservicios les permite desarrollar e implementar sus servicios de forma independiente. Si la arquitectura permite que los desarrolladores actúen de forma autónoma, sin esperar a alguien externo al equipo, entonces esta es una competencia clave para aumentar la velocidad. En este caso, los microservicios ayudan. Y solo su implementación no juega un papel importante.

¿Cómo descubrimos todo esto?

Teníamos un plan ambicioso para replicar completamente la metodología DORA, pero carecíamos de los recursos. Si DORA usa mucho patrocinio y su investigación lleva medio año, hicimos nuestra investigación en poco tiempo. Queríamos construir un modelo DevOps como lo hace DORA, y lo haremos en el futuro. Hasta ahora nos hemos limitado a los mapas de calor:

Observamos la distribución de las prácticas de ingeniería entre los equipos en cada perfil y descubrimos que los equipos de alto perfil, en promedio, tenían más probabilidades de usar prácticas de ingeniería. Puedes leer más sobre todo esto en nuestro informe.

Para variar, pasemos de estadísticas complejas a estadísticas simples.

¿Qué más hemos descubierto?

Instrumentos

Observamos que la mayoría de los comandos son utilizados por los SO de la familia Linux. Pero Windows sigue estando de moda: al menos una cuarta parte de nuestros encuestados señaló el uso de una u otra de sus versiones. Parece que el mercado tiene esta necesidad. Por lo tanto, puede desarrollar estas competencias y hacer presentaciones en conferencias.

Entre los orquestadores, para nadie es un secreto, Kubernetes está a la cabeza (52%). El siguiente orquestador en línea es Docker Swarm (alrededor del 12%). Los sistemas CI más populares son Jenkins y GitLab. El sistema de gestión de configuración más popular es Ansible, seguido de nuestro amado Shell.

Amazon es actualmente el proveedor líder de alojamiento en la nube. La proporción de nubes rusas está aumentando gradualmente. El próximo año será interesante ver cómo se sentirán los proveedores de la nube rusos, si aumentará su cuota de mercado. Lo son, se pueden usar, y eso es bueno:

Le paso la palabra a Igor, quien dará algunas estadísticas más.

Difusión de prácticas

Igor Kurochkin: Por separado, les pedimos a los encuestados que indicaran cómo se distribuyen las prácticas de ingeniería consideradas en la empresa. En la mayoría de las empresas, existe un enfoque mixto, que consiste en un conjunto diferente de patrones, y los proyectos piloto son muy populares. También vimos una ligera diferencia entre los perfiles. Los representantes del perfil alto utilizan con mayor frecuencia el patrón de "Iniciativa desde abajo", cuando pequeños equipos de especialistas cambian los procesos de trabajo, las herramientas y comparten prácticas exitosas con otros equipos. En Medium, esta es una iniciativa de arriba hacia abajo que afecta a toda la empresa a través de la creación de comunidades y centros de excelencia:

Ágil y DevOps

La cuestión de la conexión entre Agile y DevOps se discute a menudo en la industria. Este problema también se plantea en el Informe sobre el estado de Agile para 2019/2020, por lo que decidimos comparar cómo se conectan las actividades de Agile y DevOps en las empresas. Descubrimos que DevOps sin Agile es raro. Para la mitad de los encuestados, la difusión de Agile comenzó mucho antes, y alrededor del 20 % observó el inicio simultáneo, y uno de los signos de un perfil bajo será la ausencia de prácticas Agile y DevOps:

Topologías de comando

A fines del año pasado, el libro "topologías de equipo”, que propone un marco para describir topologías de comando. Nos resultó interesante si es aplicable a las empresas rusas. Y nos hicimos la pregunta: “¿Qué patrones encuentras?”.

Se observan equipos de infraestructura en la mitad de los encuestados, así como equipos separados para desarrollo, prueba y operación. Los equipos separados de DevOps notaron el 45%, entre los cuales los representantes de High son más comunes. Luego vienen los equipos multifuncionales, que también son más comunes en High. Los comandos SRE separados aparecen en los perfiles alto y medio y rara vez se ven en el perfil bajo:

Relación DevQaOps

Vimos esta pregunta en FaceBook del líder del equipo de la plataforma Skyeng: estaba interesado en la proporción de desarrolladores, evaluadores y administradores en las empresas. Lo preguntamos y analizamos las respuestas en función de los perfiles: los representantes de alto perfil tienen menos ingenieros de pruebas y operaciones para cada desarrollador:

Planes para 2021 año

En los planes para el próximo año, los encuestados señalaron las siguientes actividades:

Aquí puede ver la intersección con la conferencia DevOps Live 2020. Revisamos cuidadosamente el programa:

• La infraestructura como producto
• Transformación DevOps
• Distribución de prácticas DevOps
• DevSecOps
• Clubes de casos y debates

Pero el tiempo de nuestra presentación no es suficiente para cubrir todos los temas. Detrás de escena:

• Plataforma como servicio y como producto;
• Infraestructura como código, entornos y nubes;
• Integración y Entrega Continuas;
• Arquitectura;
• patrones DevSecOps;
• Plataforma y equipos multifuncionales.

Informe tenemos un voluminoso, 50 páginas, y lo pueden ver con más detalle.

En resumen

Esperamos que nuestra investigación e informe lo inspiren a experimentar con nuevos enfoques para el desarrollo, las pruebas y las operaciones, además de ayudarlo a navegar, compararse con otros participantes en el estudio e identificar áreas en las que puede mejorar sus propios enfoques.

Resultados del primer estudio del estado de DevOps en Rusia:

• Llaves metricas. Hemos descubierto que las métricas clave (tiempo de entrega, frecuencia de implementación, tiempo de recuperación y errores de cambio) son adecuadas para analizar la eficacia de los procesos de desarrollo, pruebas y operaciones.
• Perfiles Alto, Medio, Bajo. Con base en los datos recopilados, podemos distinguir estadísticamente diferentes grupos de Alto, Medio, Bajo con características distintivas en términos de métricas, prácticas, procesos y herramientas. Los representantes del perfil alto muestran mejores resultados que los bajos. Es más probable que alcancen y superen sus objetivos.
• Indicadores, pandemia y planes para 2021. Un indicador especial este año es cómo las empresas enfrentaron la pandemia. A los altos representantes les fue mejor, experimentaron una mayor participación de los usuarios y las principales razones del éxito fueron procesos de desarrollo eficientes y una sólida cultura de ingeniería.
• Prácticas DevOps, herramientas y su desarrollo. Los principales planes de las empresas para el próximo año incluyen el desarrollo de prácticas y herramientas DevOps, la introducción de prácticas DevSecOps y cambios en la estructura organizacional. Y la implementación y desarrollo efectivo de las prácticas DevOps se lleva a cabo con la ayuda de proyectos piloto, la formación de comunidades y centros de excelencia, iniciativas en los niveles superiores e inferiores de la empresa.

Nos encantaría escuchar sus comentarios, historias, comentarios. Agradecemos a todos los que participaron en el estudio y esperamos su participación el próximo año.

Fuente: habr.com