La definición de DevOps es muy compleja, por lo que tenemos que empezar la discusión al respecto cada vez. Sólo sobre Habré hay mil publicaciones sobre este tema. Pero si estás leyendo esto, probablemente sepas qué es DevOps. Porque no soy. Hola, mi nombre es Alejandro Titov (@), y solo hablaremos sobre DevOps y compartiré mi experiencia.
He estado pensando durante mucho tiempo en cómo hacer que mi historia sea útil, por lo que aquí habrá muchas preguntas, las que me hago a mí mismo y las que les hago a los clientes de nuestra empresa. Al responder a estas preguntas, la comprensión mejora. Te diré por qué es necesario DevOps desde mi punto de vista, qué es, nuevamente, desde mi punto de vista y cómo entender que estás avanzando hacia DevOps nuevamente desde mi punto de vista. El último punto será a través de preguntas. Al responderlas usted mismo, podrá comprender si su empresa está avanzando hacia DevOps o si hay problemas de alguna manera.
Hubo un tiempo en que yo estaba navegando por las olas de fusiones y adquisiciones. Primero, trabajé para una pequeña startup llamada Qik, luego fue comprada por una empresa un poco más grande llamada Skype, que luego fue comprada por una empresa un poco más grande llamada Microsoft. En ese momento comencé a ver cómo la idea de DevOps se estaba transformando en empresas de diferentes tamaños. Después de eso, me interesé en ver DevOps desde el punto de vista del mercado, y mis colegas y yo fundamos la empresa Express 42. Desde hace 6 años nos movemos en las olas del mercado.
Entre otras cosas, soy uno de los organizadores de la comunidad DevOps Moscú y el organizador de los DevOps-Days 2017, pero no organicé el de 2018. Express 42 trabaja con muchas empresas. Hacemos crecer DevOps allí, observamos cómo sucede, sacamos conclusiones, analizamos, contamos a todos nuestras conclusiones y capacitamos a las personas en prácticas de DevOps. En general, estamos haciendo todo lo posible para aumentar nuestra experiencia y conocimientos en este sentido.
Por qué DevOps
La primera pregunta que atormenta a todos y siempre es: ¿por qué? Mucha gente piensa que DevOps es solo automatización o algo similar que ya tienen todas las empresas.
— Teníamos integración continua: esto significa que ya teníamos DevOps, y ¿por qué se necesita todo esto? ¡Se divierten en el extranjero, pero nos impiden trabajar!
Después de 9 años de desarrollo de la comunidad y la metodología, ya ha quedado claro que esto todavía no es brillo de marketing, pero aún no está del todo claro por qué es necesario. Como cualquier herramienta y proceso, DevOps tiene objetivos específicos que finalmente logra.
Todo esto se debe a que el mundo está cambiando. Se aleja del enfoque empresarial, cuando las empresas avanzan directamente hacia un sueño, como cantaba nuestro clásico de San Petersburgo, del punto A al punto B según una determinada estrategia, con una determinada estructura construida para ello.
En principio, todo en TI debería construirse de acuerdo con este enfoque. Aquí la TI se utiliza exclusivamente para automatizar procesos.
La automatización no cambia con frecuencia, porque cuando una empresa cae en una rutina muy trillada, ¿qué hay que cambiar? Funciona, no lo toques. Ahora los enfoques en el mundo están cambiando y el llamado Agile sugiere que el punto final B no es inmediatamente visible.
Cuando una empresa recorre el mercado, trabaja con un cliente, explora constantemente el mercado y cambia el punto final B. Además, cuanto más a menudo la empresa cambia de dirección, más éxito obtiene al final, porque elige más mercado. nichos.
La estrategia la demuestra una empresa interesante de la que conocí recientemente. One Box Shave es un servicio de entrega por suscripción de maquinillas de afeitar y accesorios de afeitado en una caja. Saben personalizar su “caja” para diferentes clientes. Esto lo hace un determinado software, que luego envía el pedido a la fábrica coreana que produce el producto.
Este producto fue comprado por Unilever por mil millones de dólares. Ahora compite con Gillette y le ha quitado una parte importante de los consumidores en el mercado americano. One Box Shave dice:
— ¿4 cuchillas? ¿Lo dices en serio? ¿Por qué necesitas esto? No mejora la calidad del afeitado. ¡Una crema especialmente seleccionada, una fragancia y una maquinilla de afeitar de dos hojas de alta calidad resuelven muchos más problemas que esas estúpidas 4 hojas Gillette! ¿Llegaremos pronto a 10?
Así cambia el mundo. Unilever afirma que tiene un excelente sistema de TI que le permite hacer esto. Al final parece un concepto. hora de comprar, del que nadie ha hablado ya.
El objetivo del Time-to-market no es la frecuencia con la que implementamos. A menudo se puede implementar, pero los ciclos de lanzamiento serán largos. Si se superponen ciclos de lanzamiento de tres meses, cambiándolos una semana, resulta que la empresa parece estar implementando una vez por semana. Y desde la idea hasta la implementación final se necesitan 3 meses.
El tiempo de comercialización consiste en minimizar el tiempo transcurrido desde la idea hasta la implementación final.
En este caso, el software interactúa con el mercado. Así es como interactúa el sitio web de One Box Shave con el cliente. No tienen vendedores, sólo un sitio web donde los visitantes hacen clic y dejan deseos. Por lo tanto, es necesario publicar constantemente algo nuevo en el sitio y actualizarlo según los deseos. Por ejemplo, en Corea del Sur se afeitan de forma diferente que en Rusia y no les gusta el olor a pino, sino, por ejemplo, a zanahoria y vainilla.
Dado que es necesario cambiar rápidamente el contenido del sitio, el desarrollo del software cambia mucho. A través del software debemos averiguar qué quiere el cliente. Anteriormente, aprendimos esto a través de algunos rodeos, por ejemplo, a través de la gestión empresarial. Luego lo diseñamos, pusimos los requisitos en el sistema de TI y todo estuvo bien. Ahora es diferente: el software lo diseñan todos los que participan en el proceso, incluidos los ingenieros, porque a través de las especificaciones técnicas aprenden cómo funciona el mercado y también comparten sus conocimientos con la empresa.
Por ejemplo, en Qik nos enteramos de repente de que a la gente le gustaba mucho subir listas de contactos al servidor y nos proporcionaron una aplicación. Al principio no pensamos en eso. En una empresa clásica, todos habrían decidido que esto era un error, ya que la especificación no decía que debería funcionar bien y generalmente se implementaba en la rodilla, habrían desactivado la función y habrían dicho: "Nadie necesita esto, lo más importante es que la funcionalidad principal funcione.” . Y la empresa de tecnología ve esto como una oportunidad y comienza a cambiar el software en consecuencia.
En 1968, un visionario, Melvin Conway, formuló la siguiente idea.
La organización que crea el sistema está limitada por un diseño que replica la estructura de comunicación de esa organización.
Más detalladamente, para producir sistemas de otro tipo, también es necesario 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.
Leer uno puede . Es importante para comprender la cultura o filosofía de DevOps porque Lo único que cambia fundamentalmente en DevOps es la estructura de comunicación entre 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 ocurren simultáneamente.
El tiempo de comercialización es la única manera de lograrlo. Para las personas que trabajaron en el proceso antiguo, esto parece algo cósmico y, en general, regular.
Entonces, ¿por qué necesitas DevOps?
Para el desarrollo de productos digitales. Si su empresa no tiene un producto digital, DevOps no es necesario; es muy importante.
DevOps supera las limitaciones de velocidad de la producción de software secuencial. En él todos los procesos ocurren simultáneamente.
La dificultad aumenta. Cuando los evangelistas de DevOps le dicen que le facilitará el lanzamiento de software, es una tontería.
Con DevOps, las cosas sólo se volverán más complicadas.
En la conferencia celebrada en el stand de Avito se pudo ver cómo es implementar un contenedor Docker: una tarea poco realista. La complejidad se vuelve prohibitiva: hay que hacer malabarismos con muchas bolas al mismo tiempo.
DevOps cambia por completo el proceso y la organización en la empresa — Más precisamente, no es DevOps lo que cambia, sino el producto digital. Para pasar a DevOps, aún es necesario cambiar completamente este proceso.
Preguntas para un especialista
¿Qué tienes? Preguntas que puedes hacerte mientras trabajas en una empresa y te desarrollas como especialista.
¿Tienes una estrategia para crear un producto digital? Si lo hay, ya está bien. Esto significa que su empresa está avanzando hacia DevOps.
¿Tu empresa ya está creando un producto digital? Esto significa que puede subir un nivel más y hacer las cosas de manera más interesante, nuevamente desde el punto de vista de DevOps. Sólo hablo desde este punto de vista.
¿Es su empresa uno de los líderes del mercado en el nicho de productos digitales? Spotify, Yandex, Uber son empresas que ahora se encuentran en la cima del progreso tecnológico.
Hágase estas preguntas y, si todas las respuestas son negativas, tal vez no debería hacer DevOps en esta empresa. Si el tema de DevOps es realmente interesante para ti, tal vez… ¿deberías mudarte a otra empresa? Si su empresa quiere dedicarse a DevOps, pero respondió "No" a todas las preguntas, entonces es como ese hermoso rinoceronte que nunca cambiará.
Organización
Como decía, según la Ley de Conway la organización de una empresa cambia. Empezaré por lo que impide que DevOps penetre en el interior de la empresa desde el punto de vista organizativo.
El problema de los "pozos"
La palabra inglesa "silo" aquí se traduce al ruso como "pozo". El punto de este problema es que no hay intercambio de información entre equipos. Cada equipo profundiza en su experiencia, sin crear un mapa común para navegar.
En cierto modo esto me recuerda a una persona que acaba de llegar a Moscú y aún no sabe cómo navegar por el mapa del metro. Los moscovitas suelen conocer muy bien su zona y pueden navegar por Moscú utilizando el mapa del metro. Cuando vienes a Moscú por primera vez, no tienes esta habilidad y simplemente estás desorientado.
DevOps sugiere superar este momento de desorientación y que todos los departamentos trabajen juntos para construir un mapa de interacción común.
Dos factores lo impiden.
Consecuencia del sistema de gestión empresarial. Está construido en “pozos” jerárquicos separados. Por ejemplo, existen determinados KPI en las empresas que soportan este sistema. Por otro lado, se interpone el cerebro de una persona a la que le resulta difícil ir más allá de los límites de su experiencia y navegar por todo el sistema. Es simplemente incómodo. Imagínese que está en el aeropuerto de Bangkok: no podrá orientarse rápidamente. DevOps también es difícil de navegar y es por eso que la gente dice que es necesario encontrar una guía para llegar allí.
Pero lo más importante es que el problema de los "pozos" para un ingeniero imbuido del espíritu de DevOps, que ha leído a Fowler y muchos otros libros, se expresa en el hecho de que Los "pozos" no te 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 sucede precisamente porque CI и Proceso de entrega continua están al borde de muchos exámenes. Simplemente sin superar el problema de los “pozos” a nivel organizacional no podrás avanzar, hagas lo que hagas y por muy triste que sea.
Cada participante en el proceso de la empresa: desarrolladores backend y frontend, pruebas, DBA, operación, red, excava en su propia dirección, y nadie tiene un mapa común excepto el gerente, quien de alguna manera los monitorea y administra usando la “dividir”. y conquistar”.
La gente lucha por algunas estrellas o banderas, todos buscan su experiencia.
Como resultado, cuando surge la tarea de conectar todo esto y construir un oleoducto común, y ya no hay necesidad de luchar por estrellas y banderas, surge la pregunta: ¿qué hacer de todos modos? Necesitamos llegar a un acuerdo de alguna manera, pero nadie nos enseñó cómo hacerlo en la escuela. Nos han enseñado desde la escuela: octavo grado - ¡guau! - ¡comparado con el séptimo grado! Es lo mismo aqui.
¿Ocurre lo mismo en tu empresa?
Para comprobarlo, puedes plantearte las siguientes preguntas.
¿Los equipos utilizan herramientas comunes y contribuyen a cambios en esas herramientas comunes?
¿Con qué frecuencia se reorganizan los equipos: algunos especialistas de un equipo se trasladan a otro? Es en un entorno DevOps donde esto se vuelve normal, porque a veces una persona simplemente no puede entender qué está haciendo otra área de especialización. Se traslada a otro departamento, trabaja allí durante dos semanas para crear un mapa de orientación e interacción con este departamento.
¿Es posible formar un comité de cambio y cambiar las cosas? ¿O requiere la mano fuerte de la más alta dirección y dirección? Recientemente escribí en Facebook cómo un banco poco conocido está implementando herramientas a través de pedidos: escribimos un pedido, lo implementamos durante un año y vemos qué sucede. Esto, por supuesto, es largo y triste.
¿Qué importancia tiene para los directivos recibir logros personales sin considerar los logros de la empresa?
Si responde usted mismo a estas preguntas, quedará más claro si existe un problema de este tipo en su empresa.
Infraestructura como código
Una vez superado este problema, la primera práctica importante, sin la cual es difícil avanzar más en DevOps, es infraestructura como código.
Muy a menudo, la infraestructura como código se percibe de la siguiente manera:
— ¡Automaticemos todo en bash, cúbranos de scripts para que los administradores tengan menos trabajo manual!
Pero eso no es cierto.
Infraestructura como código significa que usted describe el sistema de TI con el que trabaja en forma de código para comprender constantemente su estado.
Junto con otros equipos, crea un mapa en forma de código que todos pueden entender y navegar y navegar. No importa en qué se haga (Chef, Ansible, Salt o usar archivos YAML en Kubernetes), no hay diferencia.
En la conferencia, un colega de 2GIS contó cómo crearon su propio artículo interno para Kubernetes, que describe la estructura de los sistemas individuales. Para describir 500 sistemas, necesitaban una herramienta independiente que generara esta descripción. Cuando existe esta descripción, todos pueden consultar entre sí, monitorear los cambios, cómo cambiarla y mejorarla, qué falta.
De acuerdo, los scripts de bash individuales generalmente no brindan esta comprensión. En una de las empresas donde trabajé, incluso había un nombre para el guión de "solo escritura", cuando el guión está escrito, pero ya no es posible leerlo. Creo que esto también te resulta familiar.
La infraestructura como código es 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 deben comprender cómo funciona realmente este código.
El código se mantiene de acuerdo con las mejores prácticas de código.: desarrollo conjunto, revisión de código, programación XP, pruebas, solicitudes de extracción, CI para infraestructuras de código: todo esto es adecuado y se puede utilizar.
El código se convierte en un lenguaje común para todos los ingenieros.
Cambiar la infraestructura en el código no lleva mucho tiempo. Sí, el código de infraestructura también puede tener deuda técnica. Por lo general, los equipos lo encuentran un año y medio después de comenzar a implementar “infraestructura como código” en forma de un montón de scripts o incluso Ansible, que escriben como código espagueti, ¡y también agregan scripts bash a la mezcla!
Es importante: Si aún no has probado esto, recuerda que Ansible no es bash! Lee atentamente la documentación, estudia lo que escriben al respecto.
La infraestructura como código es la separación del código de infraestructura en capas separadas.
En nuestra empresa distinguimos 3 capas básicas, que son muy claras y sencillas, pero pueden haber más. Puede consultar su código de infraestructura y saber si tiene esta condición o no. Si no hay capas resaltadas, entonces necesitas tomarte un tiempo y refactorizar un poco.
capa base - Así es como se configura el sistema operativo, las copias de seguridad y otras cosas de bajo nivel, por ejemplo, cómo se implementa Kubernetes en el nivel básico.
Nivel de servicio - estos son los servicios que usted brinda al desarrollador: registro como servicio, monitoreo como servicio, base de datos como servicio, balanceador como servicio, cola como servicio, entrega continua como servicio: un conjunto de servicios que los equipos individuales puede aportar al desarrollo. Todo esto debe describirse en módulos separados en su sistema de gestión de configuración.
La capa donde se realizan las aplicaciones. y describe cómo se desplegarán sobre las dos capas anteriores.
Preguntas de seguridad
¿Su empresa tiene un repositorio de infraestructura común? ¿Estás gestionando deuda técnica en tu infraestructura? ¿Utiliza prácticas de desarrollo en un repositorio de infraestructura? ¿Su infraestructura está dividida en capas? Puedes consultar el diagrama Base-servicio-APP. ¿Qué tan difícil es hacer un cambio?
Si ha experimentado que le llevó un día y medio realizar cambios, esto significa que tiene una deuda técnica y necesita trabajar con ella. Acaba de tropezar con una comisión de deuda técnica en su código de infraestructura. Recuerdo muchas historias de este tipo cuando, para cambiar algún 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 todo está corroído por todas partes, se han eliminado todas las manijas y es necesario refactorizar.
Entrega continua
Comparemos el débito con el crédito. Primero viene una descripción de la infraestructura, que puede ser bastante básica. No es necesario que describas todo en detalle, pero se requiere alguna descripción básica para que puedas trabajar con él. De lo contrario, no está claro qué hacer a continuación con la entrega continua. Todas estas prácticas se desarrollan simultáneamente cuando llegas a DevOps, pero comienza con comprender lo que tienes y cómo administrarlo. Ésta es precisamente la práctica de la infraestructura como código.
Una vez que queda claro que lo tiene y cómo administrarlo, comienza a descubrir 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 son personas individuales las que idean esto, sino un equipo.
cuando estamos con Vanya Evtukhovich vi el primer libro Jez humilde y grupos de autores "Entrega continua", que se lanzó en 2009, pensamos durante mucho tiempo en cómo traducir su título al ruso. Querían traducirlo como “Entrega constante”, pero, lamentablemente, se tradujo como “Entrega continua”. Me parece que hay algo de ruso en nuestro nombre, con presión.
Entregar constantemente significa
El código que está en el repositorio del producto siempre se puede descargar a producción.. Puede que no esté desinflado, pero siempre está preparado para ello. En consecuencia, siempre escribes código con una sensación difícil de explicar de cierta ansiedad debajo del coxis. A menudo aparece cuando implementas código de infraestructura. Este sentimiento de cierta ansiedad debería estar presente: desencadena procesos cerebrales que le permiten escribir código de forma un poco diferente. Esto deberá quedar registrado en las normas dentro del desarrollo.
Para realizar entregas consistentes, necesita un formato de artefacto que se ejecute en una plataforma de infraestructura. Si arrojas “desperdicios de vida” de diferentes formatos en una plataforma de infraestructura, entonces se unifica, es difícil de mantener y surge el problema de la deuda técnica. El formato del artefacto debe armonizarse; esta también es una tarea colectiva: todos debemos reunirnos, hacer ruido y crear este formato.
El artefacto se mejora continuamente y cambia para adaptarse al entorno de producción a medida que avanza por el proceso de entrega. Cuando un artefacto se mueve a lo largo de la tubería, constantemente encuentra algunas cosas que le resultan inconvenientes, que son similares a las que encuentra el artefacto que usted pone en producción. Si en el desarrollo clásico esto lo hace un administrador del sistema que hace la implementación, entonces en el proceso DevOps esto sucede todo el tiempo: aquí lo probaron con algunas pruebas, aquí lo arrojaron a un clúster de Kubernetes, que es más o menos similar. a producción, y de repente comenzaron las pruebas de carga.
Esto recuerda un poco al juego Pac-Man: el artefacto pasa por una especie de historia. Al mismo tiempo, es importante controlar si el código realmente recorre la historia y si de alguna manera está relacionado con su producción. Las historias de producción se pueden arrastrar al proceso de Entrega Continua: fue así cuando algo cayó, ahora programemos este escenario dentro del sistema. Cada vez, el código también pasará por este escenario y no encontrará este problema la próxima vez. Lo sabrá mucho antes de que llegue a su cliente.
Diferentes estrategias de implementación. Por ejemplo, utiliza pruebas AB o implementaciones canary para probar el código de manera diferente en diferentes clientes, obtener información sobre cómo funciona el código y mucho antes de que se implemente para 100 millones de usuarios.
"Entregar constantemente" se ve así.
El proceso de entrega Dev, CI, Test, PreProd, Prod no es un entorno separado, son etapas o estaciones con sumas ignífugas por las que pasa su artefacto.
Si tiene un código de infraestructura que se describe como APLICACIÓN de servicio base, entonces será útil no olvides todos los guionesy escríbalos como código para este artefacto, promover artefacto y cámbialo sobre la marcha.
Preguntas de autoevaluación
¿El tiempo desde la descripción de la función hasta el lanzamiento a producción en el 95% de los casos es inferior a una semana? ¿Mejora la calidad del artefacto en cada etapa del proceso? ¿Hay alguna historia por la que pasa? ¿Utiliza diferentes estrategias de implementación?
Si todas las respuestas son sí, ¡entonces eres increíblemente genial! Escriba sus respuestas en los comentarios, estaré encantado).
Contáctanos
Esta es la práctica más difícil de todas. En la conferencia DevOpsConf, un colega de Infobip, hablando de esto, estaba un poco confundido en sus palabras, porque esta es realmente una práctica muy compleja sobre el hecho de que es necesario monitorear todo.
Por ejemplo, hace mucho tiempo, cuando trabajaba en Qik y nos dimos cuenta de que necesitábamos monitorear todo. Hicimos esto y ahora tenemos 150 artículos en Zabbix, que son monitoreados constantemente. Fue aterrador, el director técnico se torció el dedo en la sien:
- Chicos, ¿por qué violan el servidor con algo que no está claro?
Pero entonces ocurrió un incidente que demostró que ésta es realmente una estrategia genial.
Uno de los servicios empezó a fallar constantemente. Inicialmente, no falló, lo cual es interesante, el código no se agregó allí, porque era un corredor básico, que prácticamente no tenía funcionalidad comercial: simplemente enviaba mensajes entre servicios individuales. El servicio no cambió durante 4 meses y de repente empezó a fallar con el error “Fallo de segmentación”.
Nos sorprendimos, abrimos nuestros gráficos en Zabbix y resultó que hace una semana y media, el comportamiento de las solicitudes en el servicio API que utiliza este corredor cambió enormemente. A continuación vimos que la frecuencia de envío de cierto tipo de mensaje había cambiado. Más tarde descubrimos que se trataba de clientes de Android. Preguntamos:
— Chicos, ¿qué les pasó hace una semana y media?
En respuesta, escuchamos una historia interesante sobre cómo habían rediseñado la interfaz de usuario. Es poco probable que alguien diga inmediatamente que cambió la biblioteca HTTP. Para los clientes de Android, es como cambiar el jabón en el baño: simplemente no lo recuerdan. Como resultado, después de 40 minutos de conversación, descubrimos que habían cambiado la biblioteca HTTP y sus tiempos predeterminados habían cambiado. Esto provocó que el comportamiento del tráfico en el servidor API cambiara, lo que provocó una situación que provocó una carrera dentro del corredor y comenzó a fallar.
Sin un monitoreo profundo, generalmente es imposible abrir este. Si la organización todavía tiene el problema de los “pozos”, cuando todos se tiran dinero unos a otros, esto puede durar años. Simplemente reinicias el servidor porque es imposible solucionar el problema. Cuando monitorea, rastrea, rastrea todos los eventos que tiene y usa el monitoreo como prueba: escribe código e inmediatamente indica cómo monitorearlo, también en forma de código (ya tenemos la infraestructura como código), todo queda claro cómo en la palma. Incluso problemas tan complejos se pueden rastrear fácilmente.
Recopile toda la información sobre lo que sucede con el artefacto en cada etapa del proceso de entrega, no en producción.
Cargue el monitoreo en CI y algunas cosas básicas ya estarán visibles allí. Posteriormente los verás en Test, PredProd y pruebas de carga. Recopile información en todas las etapas, no solo métricas, estadísticas, sino también registros: cómo se implementó la aplicación, anomalías: recopile todo.
De lo contrario, será difícil resolverlo. Ya dije que DevOps es más complejo. Para hacer frente a esta complejidad, es necesario contar con análisis normales..
Preguntas para el autocontrol.
¿Su monitoreo y registro es la herramienta de desarrollo para usted? Al escribir código, ¿sus desarrolladores, incluido usted, piensan en cómo monitorearlo?
¿Escuchas sobre problemas de los clientes? ¿Entiende mejor al cliente gracias al seguimiento y el registro? ¿Entiende mejor el sistema a partir del monitoreo y el registro? ¿Cambias el sistema simplemente porque viste que la tendencia en el sistema está creciendo y entiendes que en otras 3 semanas todo morirá?
Una vez que tengas estos tres componentes, podrás pensar qué tipo de plataforma de infraestructura tienes en tu empresa.
Plataforma de infraestructura
La cuestión no es que se trate de un conjunto de herramientas dispares que cada empresa tiene.
El objetivo de una plataforma de infraestructura es que todos los equipos utilicen estas herramientas y las desarrollen juntos.
Está claro que existen equipos separados que son responsables del desarrollo de piezas individuales de la plataforma de infraestructura. Pero al mismo tiempo, cada ingeniero tiene la responsabilidad del desarrollo, rendimiento y promoción de la plataforma de infraestructura. A nivel interno se convierte en una herramienta común.
Todos los equipos desarrollan la plataforma de infraestructura y la tratan con cuidado como si fuera su propio IDE.. En tu IDE instalas diferentes complementos para que todo sea agradable y rápido, y configuras teclas de acceso rápido. Cuando abres Sublime, Atom o Visual Studio Code, aparecen errores de código y te das cuenta de que es imposible trabajar en absoluto, inmediatamente te sientes triste y corres a arreglar tu IDE.
Trate su plataforma de infraestructura de la misma manera. Si comprende que hay algún problema, deje una solicitud si no puede solucionarlo usted mismo. Si hay algo simple, edítelo usted mismo, envíe una solicitud de extracción, los chicos lo considerarán y lo agregarán. Este es un enfoque ligeramente diferente a las herramientas de ingeniería en la cabeza del desarrollador.
La plataforma de infraestructura asegura la transferencia del artefacto desde el desarrollo al cliente con una mejora continua en la calidad.. La IP está programada con un conjunto de historias que le suceden al código en producción. A lo largo de los años de desarrollo, han aparecido muchas de estas historias, algunas de ellas son únicas y se relacionan únicamente con usted; no se pueden buscar en Google.
En este punto, la plataforma de infraestructura se convierte en su ventaja competitiva., porque tiene algo incorporado que no está en la herramienta de la competencia. Cuanto más profunda sea su propiedad intelectual, mayor será su ventaja competitiva en términos de Time-to-market. Aparece aquí problema de bloqueo del proveedor: Puedes adoptar la plataforma de otra persona, pero utilizando la experiencia de otra persona no entenderás lo relevante que es para ti. Sí, no todas las empresas pueden crear una plataforma como Amazon. Esta es una línea difícil en la que la experiencia de la empresa es relevante para su posición en el mercado y no se puede utilizar un bloqueo de proveedor allí. También es importante pensar en esto.
esquema
Este es un diagrama básico de una plataforma de infraestructura que lo ayudará a configurar todas las prácticas y procesos en una empresa DevOps.
Veamos en qué consiste.
Sistema de orquestación de recursos, que proporciona CPU, memoria, disco a aplicaciones y otros servicios. En la parte superior de esta - servicios de bajo nivel: monitoreo, registro, motor CI/CD, almacenamiento de artefactos, infraestructura como código del sistema.
Servicios de nivel superior: base de datos como servicio, colas como servicio, equilibrio de carga como servicio, cambio de tamaño de imágenes como servicio, fábrica de Big Data como servicio. En la parte superior de esta - canalización que entrega código constantemente modificado a su cliente.
Usted recibe información sobre cómo funciona su software para el cliente, lo modifica, vuelve a proporcionar este código, recibe información, y así desarrolla constantemente tanto la plataforma de infraestructura como su software.
En el diagrama, el proceso de entrega consta de muchas etapas. Pero este es un diagrama esquemático que se presenta como ejemplo; no es necesario repetirlo uno por uno. Las etapas interactúan con los servicios como si fueran servicios: cada bloque de la plataforma tiene su propia historia: cómo se asignan los recursos, cómo se lanza la aplicación, cómo funciona con los recursos, cómo se monitorea y cómo cambia.
Es importante entender que cada parte de la plataforma lleva una historia, y preguntarse qué historia lleva ese ladrillo, tal vez debería desecharse y reemplazarse con un servicio de terceros. Por ejemplo, ¿es posible instalar Okmeter en lugar de un ladrillo? Quizás los muchachos ya hayan desarrollado esta experiencia mucho más que nosotros. Pero tal vez no, tal vez tengamos una experiencia única, necesitemos instalar Prometheus y desarrollarlo aún más.
Creación de la plataforma
Este es un proceso de comunicación complejo. Cuando tienes prácticas básicas, inicias la comunicación entre diferentes ingenieros y especialistas que desarrollan requisitos y estándares, y los cambian constantemente a diferentes herramientas y enfoques. La cultura que tenemos en DevOps es importante aquí.
Con la cultura todo es muy sencillo. se trata de colaboración y comunicación, es decir, el deseo de trabajar juntos en un campo común, el deseo de manejar juntos un instrumento. Aquí no hay ciencia espacial: todo es muy simple, banal. Por ejemplo, todos vivimos en la entrada y la mantenemos limpia: ese nivel de cultura.
¿Qué tienes?
Nuevamente, preguntas que puedes hacerte.
¿La plataforma de infraestructura está dedicada? ¿Quién es responsable de su desarrollo? ¿Conoce las ventajas competitivas de su plataforma de infraestructura?
Necesitas hacerte estas preguntas constantemente. Si algo se puede transferir a servicios de terceros, se debe transferir; si un servicio de terceros comienza a bloquear su movimiento, entonces necesita construir un sistema dentro de usted.
Entonces, DevOps...
... este es un sistema complejo, debe tener:
- Producto digital.
- Módulos de negocio que desarrollan este producto digital.
- Equipos de producto que escriben código.
- Prácticas de Entrega Continua.
- Plataformas como servicio.
- Infraestructura como un servicio.
- Infraestructura como código.
- Prácticas separadas para mantener la confiabilidad, integradas en DevOps.
- Una práctica de retroalimentación que lo describe todo.
Puede utilizar este diagrama, resaltando en él lo que ya tiene en su empresa de alguna forma: se ha desarrollado o aún necesita desarrollarse.
Terminará en un par de semanas. . como parte de RIT++. Venga a la conferencia, donde encontrará muchos informes interesantes sobre entrega continua, infraestructura como código y transformación de DevOps. , la última fecha límite para precios es el 20 de mayo.
Fuente: habr.com