¿Qué es DevOps?

Definir DevOps es muy complicado, por lo que debe reiniciar la discusión al respecto cada vez. Solo en Habré mil publicaciones sobre este tema. Pero si lee esto, probablemente sepa qué es DevOps. Porque yo no. Hola, mi nombre es Alexander Titov (@ osminog ) y solo hablaremos sobre DevOps y compartiré mi experiencia.



Durante mucho tiempo pensé en cómo hacer que mi historia sea útil, por lo que habrá muchas preguntas aquí: las que me hago y las que les hago a los clientes de nuestra empresa. Al responder estas preguntas, la comprensión está mejorando. Te diré por qué DevOps es necesario desde mi punto de vista, qué es, nuevamente, desde mi posición, y cómo entender que te estás moviendo a DevOps nuevamente desde mi punto de vista. El último artículo será a través de preguntas. Al contestarlas usted mismo, puede comprender si su empresa se está moviendo hacia DevOps o si hay problemas en algo.


En un momento caminé por las olas de fusiones y adquisiciones. Al principio trabajé en una pequeña startup Qik, luego fue comprada por una compañía un poco más grande Skype, que luego fue comprada por una compañía un poco más grande Microsoft. En ese momento, tuve una visión disponible para mí de cómo la idea de DevOps se estaba transformando en diferentes compañías. Después de eso, me resultó interesante mirar DevOps desde el punto de vista del mercado, y mis colegas y yo organizamos la empresa Express 42. Durante 6 años hemos estado avanzando a lo largo de las olas del mercado.

Entre otras cosas, soy uno de los organizadores de la comunidad DevOps de Moscú y el organizador de DevOps -Days 2017, pero no organicé 2018. Express 42 trabaja con muchas compañías. Germinamos DevOps allí, vemos cómo sucede esto, sacamos conclusiones, analizamos, contamos nuestros hallazgos a todos, enseñamos a las personas las prácticas de DevOps. En general, en todos los sentidos crecemos experiencia y pericia.

Por qué DevOps

La primera pregunta que persigue a todos y siempre: ¿por qué? Mucha gente piensa que DevOps es solo automatización o algo similar que todas las empresas ya tenían.

- Teníamos integración continua, eso significa que ya había DevOps, y ¿por qué se necesitan todas estas tapas? ¡Se divierten en el extranjero, pero interfieren con nuestro trabajo!

A lo largo de los 9 años de desarrollo de la comunidad y la metodología, ya ha quedado claro que no se trata de problemas de marketing, pero aún no está completamente claro por qué es necesario. Al igual que cualquier herramienta y proceso, DevOps tiene objetivos específicos que finalmente resuelve.

Todo esto se debe al hecho de que el mundo está cambiando. Se aleja del enfoque empresarial, cuando las empresas van directamente al sueño, como cantaba nuestro clásico de San Petersburgo, del punto A al punto B de acuerdo con una determinada estrategia, con una cierta estructura construida para esto.

En principio, en TI todo debe construirse para este enfoque. Aquí, TI se utiliza exclusivamente para la automatización de procesos.

La automatización no cambia con frecuencia, porque cuando una empresa avanza por una ruta en celo, ¿qué hay para cambiar? Funciona, no lo toques. Ahora en el mundo, los enfoques están cambiando, y la llamada palabra Ágil dice que el punto final B no es visible de inmediato.



Cuando una empresa se mueve por el mercado, trabaja con un cliente, investiga constantemente el mercado y cambia su punto final B. Además, cuanto más a menudo la empresa cambia de dirección, más exitosa es al final, porque selecciona más nichos de mercado.

La estrategia es demostrada por una compañía interesante, sobre la cual aprendí recientemente. One Box Shave: un servicio de entrega para máquinas de afeitar y máquinas de afeitar por caja. Saben cómo personalizar su "caja" para diferentes clientes. Esto lo hace cierto software, que luego envía un pedido a una fábrica coreana que produce bienes.

Este producto fue comprado por Unilever por $ 1 mil millones. Ahora está compitiendo con Gillette y le ha robado una parte importante de los consumidores en el mercado estadounidense. One Box Shave dice:

- 4 cuchillas? ¿Hablas en serio? ¿Por qué necesita esto? No mejora la calidad del afeitado. ¡Una crema especialmente seleccionada, un perfume y una maquinilla de afeitar de alta calidad con dos cuchillas resuelven muchas más preguntas que estas estúpidas 4 cuchillas de Gillette! ¿Tan pronto llegaremos a 10?

Entonces el mundo está cambiando. Unilever afirma tener un excelente sistema de TI que lo permite. Al final, parece un concepto de tiempo de comercialización del que nadie ya ha hablado.



El objetivo del Time-to-market no es con qué frecuencia implementamos. A menudo puede implementar, pero los ciclos de lanzamiento serán largos. Si los ciclos de lanzamiento de tres meses se superponen entre sí, cambiando una semana, resulta que la compañía parece desplegarse una vez por semana. Y desde la idea hasta la implementación final, pasan 3 meses.

El tiempo de comercialización se trata de minimizar el tiempo desde una idea hasta la implementación final.

En este caso, el software interactúa con el mercado. Así es como One Box Shave interactúa con el sitio. No tienen vendedores, solo un sitio donde el visitante hace clic y deja sus deseos. En consecuencia, el sitio debe publicar constantemente algo nuevo, actualizarlo de acuerdo con los deseos. Por ejemplo, en Corea del Sur, se afeitan de manera diferente que en Rusia, y les gusta el olor a pino, pero, por ejemplo, las zanahorias de vainilla en la fragancia.

Dado que necesita cambiar rápidamente el contenido del sitio, el desarrollo de software está cambiando enormemente. A través del software, debemos averiguar qué quiere el cliente. Anteriormente, aprendimos esto mediante algunas soluciones, por ejemplo, a través de la gestión empresarial. Luego diseñaron, establecieron los requisitos en el sistema de TI y todo fue genial. Ahora es diferente: el software está diseñado por todos los involucrados en el proceso, incluidos los ingenieros, porque aprenden a través de las especificaciones técnicas cómo funciona el mercado y también comparten sus ideas con el negocio.

Por ejemplo, en Qik, de repente descubrimos que a la gente realmente le gusta subir listas de contactos al servidor, y nos pusieron la aplicación. Inicialmente, no pensamos en esto. En una empresa clásica, todos decidirían que se trataba de un error, ya que la especificación no dice que debería funcionar bien y generalmente se implementó en la rodilla, apagarían la función y dirían: "Esto no necesita a nadie, lo más importante es que la funcionalidad principal funciona" . Y la compañía de tecnología ve esto como una oportunidad y comienza a cambiar el software de acuerdo con esto.



En 1968, el visionario Melvin Conway formuló la siguiente idea.

La organización que crea el sistema está limitada a un diseño que copia la estructura de comunicación en esa organización.

Más detalladamente, para producir sistemas de un tipo diferente, uno también debe tener una estructura de comunicación dentro de una empresa de otro tipo. Si su estructura de comunicación es jerárquica superior, esto no le permitirá crear sistemas que puedan proporcionar un indicador de tiempo de comercialización muy alto.

Puede leer sobre la ley de Conway siguiendo los enlaces . Es importante para comprender la cultura o la filosofía de DevOps, ya que lo único que cambia fundamentalmente en DevOps es la estructura de comunicación entre los equipos .

Desde el punto de vista del proceso, antes de DevOps, todas las etapas: análisis, desarrollo, pruebas, operación, eran lineales.
En el caso de DevOps, todos estos procesos se ejecutan simultáneamente.



El tiempo de comercialización solo se puede hacer de esta manera. Para las personas que trabajaron en el proceso anterior, parece algo cósmico, y en general regular.

Entonces, ¿por qué necesitas DevOps?

Para el desarrollo de productos digitales . Si no tiene un producto digital en su empresa, no se necesita DevOps, esto es muy importante.

DevOps supera los límites de velocidad de un esquema de producción de software consistente . En él, todos los procesos ocurren simultáneamente.

Aumenta la dificultad. Cuando los evangelistas de DevOps le dicen que le será más fácil lanzar software con él, esto no tiene sentido.

Con DevOps, las cosas solo se volverán más complicadas.

En la conferencia en el stand de Avito, uno podía ver qué es desplegar un contenedor Docker, una tarea poco realista. La complejidad se vuelve prohibitiva, tienes que hacer malabarismos con muchas bolas al mismo tiempo.

DevOps cambia completamente el proceso y la organización en la empresa ; más precisamente, no cambia DevOps, sino un producto digital. Para venir a DevOps, aún necesita cambiar completamente este proceso.

Preguntas para un especialista

Que hay de ti Preguntas que puede hacerse cuando trabaja en una empresa y se desarrolla como especialista.

¿Tienes una estrategia de producto digital? Si lo hay, ya está bien. Esto significa que su empresa se está moviendo hacia DevOps.

¿Su empresa ya está creando un producto digital? Esto significa que puede subir de nivel y hacer cosas más interesantes, nuevamente, desde el punto de vista de DevOps. Solo hablo desde este punto de vista.

¿Es su empresa uno de los líderes del mercado en un nicho con un producto digital? Spotify, Yandex, Uber: compañías que están en la cima del progreso tecnológico ahora.

Hágase estas preguntas, y si todas las respuestas son negativas, entonces quizás no debería tratar con DevOps en esta empresa. Si el tema DevOps es realmente interesante para usted, tal vez ... ¿debería mudarse a otra empresa? Si su empresa quiere ir a DevOps, pero respondió "No" a todas las preguntas, entonces se parece a este hermoso rinoceronte que nunca cambiará.

Organizacion

Como dije, de acuerdo con la ley de Conway, una organización cambia en una empresa. Para empezar, lo que impide que DevOps ingrese a la empresa desde el punto de vista de la organización.

El problema de los "pozos"

La palabra inglesa "Silo" se traduce aquí al ruso como "bien". El significado de este problema es que entre los equipos no hay intercambio de información . Cada equipo profundiza en su experiencia, sin construir un mapa común en el que pueda navegar.

De alguna manera, se parece a una persona que acaba de llegar a Moscú y que todavía no sabe cómo navegar por el mapa del metro. Los moscovitas generalmente conocen muy bien su área, y en todo Moscú están guiados por el mapa del metro. Cuando vienes a Moscú por primera vez, no existe esta habilidad, y simplemente estás desorientado.

DevOps ofrece pasar este momento de desorientación y a todos los departamentos juntos para construir un mapa común de interacción.

Dos factores interfieren con esto.

Una consecuencia del sistema de gestión empresarial. Está construido por "pozos" jerárquicos separados. Por ejemplo, hay ciertos KPI en empresas que admiten este sistema. Por otro lado, interfieren los cerebros de una persona que es difícil ir más allá de los límites de su experiencia y navegar por todo el sistema. Es simplemente incómodo. Imagina que llegaste al aeropuerto de Bangkok; allí no podrás orientarte rápidamente. DevOps también es difícil de navegar y, por lo tanto, la gente dice que necesita encontrar una guía para encontrarlo para llegar allí.

Pero lo más importante, el problema de los "pozos" para un ingeniero inspirado en el espíritu de DevOps, fue leído por Fowler y un montón de otros libros, se expresa en el hecho de que los "pozos" no le permiten hacer cosas "obvias" . A menudo nos reunimos después de DevOps Moscú, hablamos y la gente se queja:

- Solo queríamos lanzar CI, pero resultó que la gerencia no lo necesitaba.

Esto se debe precisamente al hecho de que CI y el proceso de entrega continua están al borde de muchos exámenes. Simplemente no superando el problema de los “pozos” a nivel organizacional, no podrá avanzar más, haga lo que haga y lo triste que pueda ser.



Cada participante en el proceso en la empresa: desarrolladores de back-end y frontend, pruebas, DBA, operación, red, excava en su propia dirección, y nadie tiene una tarjeta común, excepto un gerente que de alguna manera observa y controla el método de divide y vencerás.

La gente lucha por algunas pequeñas estrellas o banderas, cada uno cava su propia experiencia.

Como resultado, cuando la tarea parece conectar todo esto y construir una tubería común, y no hay necesidad de luchar por las estrellas y banderas, surge la pregunta: ¿qué debo hacer? De alguna manera debemos estar de acuerdo, pero nadie nos enseñó cómo hacerlo. Nos han enseñado desde la escuela: octavo grado - ¡guau! - En comparación con el séptimo grado! Es lo mismo aquí.

¿Es lo mismo en su empresa?

Para verificar esto, puede hacerse las siguientes preguntas.

¿Los equipos usan herramientas comunes, contribuyen a los cambios en estas herramientas comunes?

¿Con qué frecuencia se reforman los equipos? ¿Se trasladan algunos especialistas de un equipo a otro? Es en el entorno de DevOps que esto se vuelve normal, porque a veces una persona simplemente no puede entender lo que está haciendo otra área de especialización. Se muda a otro departamento, trabaja allí durante dos semanas para crear un mapa de orientación e interacción con este departamento.

¿Es posible crear un comité de cambio y cambiar algo? ¿O esto requiere una mano fuerte del más alto liderazgo y dirección? Recientemente escribí en Facebook cómo un banco poco conocido implementa herramientas a través de pedidos: redactamos un pedido, lo implementamos durante un año y veremos qué sucede. Esto, por supuesto, es largo y triste.

¿Qué tan importante es para los gerentes recibir logros personales sin tener en cuenta los logros de la empresa?

Si responde estas preguntas por sí mismo, será más claro si tiene ese problema en la empresa.

Infraestructura como código

Una vez que se ha resuelto este problema, la primera práctica importante, sin la cual es difícil avanzar más en DevOps, es la infraestructura como código .

Muy a menudo, la infraestructura como código se percibe de la siguiente manera:

- ¡Automaticemos todo en bash, cúbranos con scripts para que el área de administración tenga menos trabajo manual!

Pero esto no es así.

La infraestructura como código implica que usted describa el sistema de TI con el que trabaja para comprender constantemente su estado.

Junto con otros equipos, crea un mapa en forma de código que todos entienden, que puede navegar y navegar. No importa lo que se haga: los archivos Chef, Ansible, Salt o YAML se usan en Kubernetes, no hay diferencia.

En la conferencia, un colega de 2GIS habló sobre cómo hicieron su propia cosa interna para Kubernetes, que describe la estructura de los sistemas individuales. Para describir 500 sistemas, necesitaban una herramienta separada que genere esta descripción. Cuando existe esta descripción, todos pueden consultar entre sí, monitorear los cambios, cómo cambiarlos y mejorarlos, lo que falta.

De acuerdo, los scripts de bash separados generalmente no dan esta comprensión. En una de las compañías donde trabajé, incluso había un nombre "solo escribir", un guión, cuando se escribe el guión, y ya es imposible leerlo. Creo que esto también te es familiar.

La infraestructura como código es un código que describe el estado actual de la infraestructura . Muchos equipos de productos, infraestructura y servicios trabajan juntos en este código, y lo más importante, todos necesitan entender cómo funciona este código en general.

El código se acompaña de acuerdo con las mejores prácticas de trabajo con código : desarrollo conjunto, revisión de código, programación XP, pruebas, pull-quests, CI para infraestructuras de código: todo esto es adecuado y puede usarse.

El código se está convirtiendo en un lenguaje común para todos los ingenieros.

Cambiar la infraestructura en el código no lleva mucho tiempo . Sí, también puede haber deuda técnica en el código de infraestructura. Por lo general, los equipos lo encuentran un año y medio después de que comenzaron a implementar "infraestructura como código" en forma de un conjunto de scripts o incluso Ansible, que escriben como código de spaghetti, ¡e incluso los scripts de bash lo pusieron en la caja de fuego!

Importante : si aún no has probado estas cosas, ¡recuerda que Ansible no es bash ! Lea la documentación detenidamente, estudie lo que generalmente escriben sobre ella.

Infraestructura como código es la división del código de infraestructura en capas separadas.

En nuestra empresa, distinguimos 3 capas básicas, que son muy claras y simples, pero puede haber más. Puede mirar su código de infraestructura y decir si tiene esta condición o no. Si no hay capas resaltadas, debe asignar un poco de tiempo y refactorizar.


La capa base es cómo se configuran el sistema operativo, las copias de seguridad y otras cosas de bajo nivel, por ejemplo, cómo se implementa Kubernetes en un nivel básico.

El nivel de servicios son aquellos servicios que le brinda al desarrollador: inicio de sesión como servicio, monitoreo como servicio, una base de datos como servicio, un equilibrador como servicio, una cola como servicio, Entrega continua como servicio: un conjunto de servicios que los equipos individuales pueden proporcionar desarrollo. Todo esto debe describirse como módulos separados en su sistema de gestión de configuración.

La capa donde se realizan las aplicaciones y cómo se implementarán en la parte superior de las dos capas anteriores.

Preguntas de seguridad

¿Tiene un repositorio de infraestructura común en su empresa? ¿Controlas la deuda técnica en infraestructura? ¿Utiliza prácticas de desarrollo en el repositorio de infraestructura? ¿Se corta su infraestructura? Puede consultar el esquema Base-service-APP. ¿Qué tan difícil es hacer un cambio?

Si se enfrenta al hecho de que la introducción de cambios tomó un día y medio, esto significa que tiene una deuda técnica y necesita trabajar con ella. Acaba de toparse con un rastrillo de deuda técnica en el código de infraestructura. Recuerdo muchas de esas historias cuando para cambiar cualquier CCTL, es necesario reescribir la mitad del código de infraestructura, porque la creatividad y el deseo de automatizar todo llevaron al hecho de que en todas partes todo está en cortocircuito, se eliminan todos los bolígrafos y es necesario refactorizar.

Entrega continua

Débito similar con un préstamo. Primero, aparece una descripción de la infraestructura, que puede ser bastante básica. No es necesario describir todo en detalle, pero se requiere una descripción básica para que pueda trabajar con ella. De lo contrario, no está claro además qué hacer para la entrega continua. Todas estas prácticas se desarrollan al mismo tiempo cuando viene a DevOps, pero debe comenzar por comprender lo que tiene y cómo administrarlo. Esta es solo la práctica de la infraestructura como código.

Después de que quedó claro que tiene cómo administrar esto, comienza a pensar en cómo enviar el código de desarrollador a producción lo más rápido posible. Quiero decir, junto con el desarrollador, recordamos el problema de los "pozos", es decir, no a las personas individuales se les ocurre esto, sino al equipo.

Cuando Vanya Yevtukhovich y yo vimos el primer libro de Jes Hamble y el grupo de autores "Continuous Delivery" , que se lanzó en 2009, pensamos durante mucho tiempo cómo traducir su nombre al ruso. Querían traducirlo como "Entrega constante", pero, desafortunadamente, traducido como "Entrega continua". Me parece que hay algo ruso en nuestro título con presión.

Entregar constantemente, eso significa

El código que se encuentra en el repositorio de comestibles siempre se puede descargar en producción . Puede que no se desinfle, pero siempre está listo para ello. En consecuencia, siempre se escribe código con una sensación de preocupación difícil de explicar debajo de la columna vertebral. A menudo aparece cuando implementa el código de infraestructura. — , -. .

, , . « », , , . — : , .

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

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

Retroalimentación

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20