El 7 de diciembre, la comunidad DevOps de Moscú organizó la tercera conferencia
DevOpsDays Moscú con el apoyo de Mail.ru Cloud Solutions. Además de los informes de los principales profesionales de DevOps, los participantes pudieron asistir a breves charlas, talleres y charlas en espacios abiertos.
Recolectamos información importante de seis presentaciones y realizamos entrevistas con varios oradores para averiguar qué quedaba fuera de los informes.
Dentro:
- Baruch Sadogursky, JFrog: "Deje que el software fluya del vendedor al usuario, como un líquido"
- Pavel Selivanov, Southbridge: "Dev y Ops tienen una tarea común: hacer un producto que funcione"
- Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise es desarrollo sin dolor ni incendios"
- Sergey Puzyrev, Facebook: "El ingeniero de producción se encarga del servicio en su conjunto: para que tanto los usuarios como los desarrolladores se sientan bien"
- Mikhail Chinkov, AMBOSS: "Una unidad no puede seguir el camino de DevOps, toda la compañía debería seguirlo"
- Entusiastas de Rosbank DevOps: "1000 días para implementar DevOps en la empresa sangrienta"
1. Baruch Sadogursky, JFrog: "Deje que el software fluya del vendedor al usuario, como un líquido"
Las fallas al actualizar el software ocurren cada hora y para todos. Aquí hay una historia aterradora del discurso: Knight Capital perdió $ 440 millones por hora después de una actualización fallida.
Baruch habló sobre los patrones de DevOps de actualizaciones continuas que ayudarán a evitar fallas y odio de los usuarios:
Reversión local : mantenga la versión anterior del software en el dispositivo para revertirla en caso de que ocurra algo. Esto lo protegerá si todo es tan malo que no puede enviar el parche por el aire.
Las actualizaciones de aire son mejores continuas. Será diferente, como con los desarrolladores de Jaguar: debido a un error en el sistema de frenos que no pudo actualizarse por aire, fue necesario retirar los autos de la venta. Fue doloroso y costoso.
Actualizaciones continuas : actualice el software continuamente tan pronto como una nueva característica esté lista. Con actualizaciones raras, las características se agrupan, una actualización crítica puede esperar a las no críticas. Al igual que en Tesla, una actualización que supuestamente solucionaría el frenado aleatorio estaba esperando que se actualizara el juego de ajedrez.
Implementación automatizada : reemplace a las personas con máquinas, porque las personas no saben cómo realizar acciones de rutina.
Actualizaciones frecuentes : ayuda a desarrollar un hábito y a deshacerte del miedo. Las actualizaciones raras se convierten en un evento de emergencia.
Conocimiento del estado del dispositivo : actualizaciones de prueba, no instalación desde cero. Esto es importante, ya que las actualizaciones pueden comportarse de manera diferente según el estado del dispositivo.
Lanzamientos de Canarias : despliegue actualizaciones para un pequeño número de usuarios y mire. Esto reduce el daño si algo sale mal.
Actualizaciones sin inaccesibilidad : permita que los clientes noten solo nuevas funciones y no permanezcan sin servicio durante varias semanas hasta que implemente la actualización.
Hablamos con Baruch Sadogursky acerca de cómo las perspectivas de DevOps difieren en la TI rusa y occidental, si Cloud hará todo por nosotros pronto y si todos los servicios de software se deslizarán en un esquema aaS - vea la entrevista:
2. Pavel Selivanov, Southbridge: "Dev y Ops tienen una tarea común: hacer un producto que funcione"
Implementar Kubernetes no ayudará a lograr DevOps, e incluso viceversa, puede romper todo. Pavel dijo por qué las tecnologías (incluso las mejores) no pueden resolver todos sus problemas:
La complejidad del proyecto ha ido más allá del código . Anteriormente, había una aplicación compleja: interacción dentro del proyecto y desarrollo complejo, pero una estructura simple: el administrador desplegado, todo funciona. Cambiamos a microservicios: cada servicio es una aplicación simple, comunicación usando protocolos estándar y desarrollo rápido, pero la estructura del proyecto se ha vuelto más complicada. La complejidad del proyecto con la arquitectura de microservicios no ha desaparecido, ha ido más allá del código. Ahora el ingeniero DevOps es responsable de ello.
Los desarrolladores no desean cambios después de la implementación de DevOps . Como resultado, el flujo de trabajo con Kubernetes continúa pareciendo lanzar tareas de Dev a Ops a través de un muro, pero ya no es metafórico: Git se convierte en un muro de ese tipo. El desarrollador coloca el código allí y funciona como antes, y los administradores tienen Kubernetes, CI / CD y todo lo demás.
Sin embargo, los desarrolladores deben aceptar los cambios . La situación cuando los desarrolladores no saben lo que hacen los administradores, y los administradores no saben lo que está sucediendo con los desarrolladores, crea problemas.
Si los desarrolladores no han cambiado nada, no se dan cuenta de que el trabajo de la aplicación es su responsabilidad; diferentes trucos técnicos no funcionarán.
Con la llegada de DevOps y Kubernetes, mucho cambiará en el desarrollo. Dev debe ser competente en operaciones, y viceversa. Estos especialistas tienen sus propias habilidades específicas, pero deben conocer el trabajo del otro. Dev y Ops deben ser amigos antes de implementar Kubernetes, de lo contrario romperás lo que es.
Pavel Selivanov habló sobre lo que le sucederá a Kubernetes en 5 años y sobre qué construir una pila tecnológica para una startup moderna. Ver entrevista:
3. Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise es desarrollo sin dolor ni incendios"
Las empresas llegan a la transformación DevOps cuando se dan cuenta de que el desarrollo es demasiado lento y no cumple con la realidad, tienen el deseo de desarrollarse mejor y desplegarse más rápido.
Vladimir contó cómo sucede esto y cuál es el problema:
- Primero, las empresas contratan a un ingeniero DevOps. Este es un administrador sénior del sistema, se dedica a la implementación de la versión en producción, a la estandarización del entorno de desarrollo, a la configuración de la infraestructura, a la detección y solución de diversos problemas, a la automatización de procesos y a otras tareas técnicas.
- Entonces, un ingeniero de DevOps ya no es suficiente, y la compañía contrata a un equipo de DevOps. Este es un centro de competencia, que organiza los esfuerzos de ingenieros dispares, le permite enfocarlos en una dirección.
- De hecho, el ingeniero de DevOps y los equipos de DevOps son los antipatrones de las transformaciones de DevOps. Dado que DevOps se trata de prácticas y cultura, además, hay implementaciones de DevOps en empresas de tecnología (SRE, Ingeniería de Producción).
Que hacer Contratar un equipo temporal de DevOps para ayudar a implementar la transformación de DevOps llevará a cabo prácticas, cultivará una cultura de desarrollo y cultura tecnológica.
Cuando una empresa ingresa al juego e invierte en DevOps, son posibles varios escenarios: todo se desmoronará en el despegue; permanecerá como SRE / Ingeniería de producción o Operaciones integradas; se moverá a BizOps cuando los procesos se basen en métricas comerciales.
Vladimir Utratenko nos dijo cuán "sangrientos" son realmente los DevOps en la empresa y cómo se están implementando las prácticas dentro de las grandes tiendas minoristas. Ver entrevista:
4. Sergey Puzyrev, Facebook: "El ingeniero de producción se encarga del servicio en su conjunto: para que tanto los usuarios como los desarrolladores se sientan bien"
Facebook es una gran empresa con muchos componentes, servidores, personas, centros de datos. A pesar de su gran tamaño, es muy rápido: los desarrolladores pueden implementar servicios muchas veces al día. Facebook también está creciendo rápidamente, y no se trata solo del aumento en el número de usuarios y servidores, sino que también está aumentando el número de desarrolladores, lo que complica los procesos.
Sergey dijo lo que el ingeniero de producción está haciendo en Facebook:
- El ingeniero de producción codifica mucho, debe tener conocimiento del sistema: sistemas operativos, sistemas de archivos, bases de datos, redes y similares. Debe tener experiencia con sistemas distribuidos e Ingeniería de confiabilidad, es decir, para respaldar la confiabilidad del producto. Debe estar de guardia, es decir, disponible para llamar en cualquier momento.
- El ingeniero de producción difiere del ingeniero de software en habilidades avanzadas de operación, pero, de hecho, es una subespecie de ingeniero de software. El ingeniero de software codifica más, pueden tener habilidades adicionales relacionadas, por ejemplo, con el procesamiento de datos. En Facebook, tales especialistas también deberían estar de guardia, lo que para muchos es una sorpresa desagradable.
- La pirámide de necesidades del ingeniero de producción en la empresa comienza con el monitoreo de los servidores y su ciclo de vida, es decir, recibir nuevo hardware, configurarlo y ponerlo en funcionamiento. El siguiente nivel es el mismo en el nivel de servicio: servicios de monitoreo y su ciclo de vida. Luego viene el escalado continuo y el monitoreo avanzado. Cambian a escalado automático después de que el ciclo de vida del servicio está automatizado. Y al final, debe realizar ajustes para que el escalado sea efectivo, la empresa ahorre dinero y recursos.
5. Mikhail Chinkov, AMBOSS: "Una unidad no puede seguir el camino de DevOps, toda la compañía debería seguirlo"
Michael cree que DevOps es un desarrollo continuo. No puede introducir ninguna herramienta y detenerse allí. ¿Qué problemas evitan que las empresas se conviertan en DevOps y cómo implementar prácticas?
Diferencia en la comprensión de DevOps . Los devops canónicos, como lo ven los evangelistas, se basan en 5 pilares:
- cultura: enfoque en las personas y la colaboración;
- automatización: delegación de la rutina al flujo de trabajo;
- Lean - énfasis en la entrega de valor al usuario;
- compartir - intercambio continuo de conocimientos;
- métricas y obtener comentarios con su ayuda.
Las empresas generalmente se centran solo en la automatización y la entrega de valor al usuario. Pero la cultura, el intercambio de conocimientos y las métricas de DevOps, mediante las cuales puede rastrear el desarrollo, se van por el camino.
Problemas de estandarización de DevOps . Los objetivos del producto son diferentes para todas las empresas; no pueden estandarizarse. El estado de DevOps en la compañía depende de la compañía misma, pero muchos no entienden esto y creen que es suficiente contratar a un ingeniero de DevOps.
¿Por qué todavía no somos DevOps? Hay dos cuestiones clave. En Enterprise, el lento desarrollo de la organización, la dificultad de cambiar el vector en la cabeza de miles de empleados. En las startups, hay una falta de fuentes de conocimiento, un problema con la asignación de recursos para la transformación.
Etapas de desarrollo de DevOps en la empresa :
- el primero es la infraestructura en la nube, pero nadie sabe cómo funciona, excepto uno o dos administradores;
- el segundo: la infraestructura es transparente y comprensible para todos los ingenieros, pero los procesos no se ponen en marcha;
- el tercero: los ingenieros lanzan y reparan independientemente servicios en vivo;
- el cuarto: los ingenieros, si lo desean, contribuirán a la infraestructura central, el código transparente en la nube, el despliegue de botones.
El esquema ideal: todos tienen el mismo acceso a la infraestructura, todos los ingenieros tienen acceso al producto y entienden lo que están haciendo.
Cerrando todas las gestalt culturales y técnicas, la transformación de DevOps de la compañía tendrá en cuenta los comentarios de las métricas comerciales y de la plataforma.
6. Entusiastas de DevOps de Rosbank: "1000 días para implementar DevOps en la empresa sangrienta"
Yuri Bulich, Dina Maltseva, Eugene Pankov de Rosbank contaron cómo llegaron a DevOps en tres años. Había dos objetivos: resolver problemas específicos en equipos específicos e implementar herramientas centralizadas.
Aquí están los resultados logrados:
Resultados para equipos de productos : montaje 30 veces más rápido, instalación 6 veces más rápida, hasta 30% de ahorro en un ciclo completo. Tenemos la oportunidad de pasar el botón a la productividad
Resultados para equipos de plataforma : el montaje y la instalación es 10 veces más rápido, el número de instalaciones ha aumentado en un 87%, la cobertura con autotest es del 46%. El equipo de integración dejó de ser un cuello de botella
Entonces, ¿cómo implementar las prácticas de DevOps en la empresa sangrienta?
Primero, presente un proyecto piloto : elija equipos, decida cómo implementar la arquitectura y elija herramientas. Elegimos herramientas con una licencia abierta, con la instalación en el banco y la experiencia en trabajar con ellas. En Rosbank, junto con la plataforma DevOps, se implementó una nube privada, y esto ayudó al principio. En la nube, era posible obtener los recursos necesarios mediante un botón en 15 minutos, anteriormente dicho proceso podría llevar una semana.
En bancos y otras empresas, debe resolver las restricciones con el equipo de seguridad de la información con anticipación y encontrar una solución que le permita implementar los cambios.
Después del piloto, se debe escalar una solución exitosa .
- Es importante "enderezar" el transportador tanto como sea posible, eliminando enlaces innecesarios, resaltar proveedores de valor y eliminar los componentes restantes. Los intermedios son antipatrones. Por ejemplo, en Rosbank, varios equipos no tenían desarrollo interno, solo quedaban externos. Esto llevó a la aparición de un equipo dedicado de DevOps, que proporcionó la transferencia de código de los desarrolladores externos a los internos. El problema se resolvió integrando el desarrollo externo en CI / CD para que no solo transfirieran el código de sí mismos al banco, sino que también fueran responsables de su éxito.
- Se incluyeron elementos de la práctica de DevOps en el modelo de madurez, se enumeraron las herramientas y se tuvieron en cuenta las características de trabajar con proveedores externos; en el futuro, esto ayudó a reducir rápidamente la acumulación de tareas cuando se implementan en nuevos equipos.
- La gobernanza es necesaria en forma de control suave y recomendaciones. El manual de DevOps funciona bien: es un conjunto de características organizativas e instrumentales que ayudan a los equipos a utilizar la plataforma correctamente.
- Vale la pena prestar atención inmediata a la cultura, luego muchos cambios serán más rápidos y fáciles. Crecer la comunidad interna, celebrar reuniones, talleres técnicos, entrenamientos, actividades divertidas. Da fruto: las personas comparten sus prácticas, ven quién ha hecho qué, saben a dónde acudir, hay una exageración y una competencia saludable dentro de la empresa.
- No tiene sentido trabajar con aquellos que no están involucrados en el proceso, con equipos que no están maduros, es mejor invertir en equipos interesados y personas leales.
- La solución seleccionada debe ser conveniente para aquellos ingenieros que la usan.
- El desarrollo externo no es un bloqueador, también puede implementar prácticas allí, lo principal es que el equipo en sí tiene un deseo.
Un poco más bueno
La lista de libros que se deben leer a quienes están en DevOps, de Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Voluntad y autocontrol".
- Daniel Kahneman "Pensamiento, rápido y lento".
- Barbara Oakley "Una mente para los números".
- Maxim Dorofeev "Técnicas Jedi".
- Viktor Frankl "La búsqueda del hombre por el significado".
Estén atentos
También amamos DevOps. Siga los anuncios de las
series @DevOps y @Kubernetes, así como otros eventos de Mail.ru Cloud Solutions, en nuestro canal de Telegram:
t.me/k8s_mail