Recientemente asistí al DevOpsForum 2019, organizado por Logrocon. En esta conferencia los participantes intentaron encontrar soluciones y nuevas herramientas para una interacción efectiva entre los especialistas en negocios y desarrollo y servicios de tecnología de la información.
La conferencia fue un éxito: realmente hubo muchos informes útiles, formatos de presentación interesantes y mucha comunicación con los ponentes. Y es especialmente importante que nadie haya intentado venderme nada, algo de lo que últimamente son culpables los ponentes de grandes congresos.
Un extracto de los discursos de Raiffeisenbank, Alfastrakhovanie, la experiencia de Mango Telecom en la implementación de la automatización y otros detalles bajo el corte.
Mi nombre es Yana, trabajo como tester, hago automatización, además de DevOps, y me encanta ir a conferencias y reuniones. Durante los últimos dos años, he asistido a las conferencias de Oleg Bunin (HighLoad++, TeamLead Conf), eventos Jug (Heisenbug, JPoint), TestCon Moscú, DevOps Pro Moscú, Big Data Moscú.
En primer lugar, llamo la atención sobre el programa de la conferencia. Miro menos de qué tratará el informe y más al orador. Incluso si el informe resulta muy tecnológico e interesante, no es un hecho que podrá aplicar algunas de las mejores prácticas del informe en su empresa. Y luego necesitas un altavoz.
Luz al final del oleoducto en Raiffeisenbank
Por lo general, busco oradores al margen que me interesen. En DevOpsForum 2019, me llamó la atención un orador de Raiffeisenbank, Mikhail Bizhan. Durante su discurso, habló sobre cómo poco a poco están logrando que sus equipos se enganchen a DevOps, por qué lo necesitan y cómo vender la idea de la transformación de DevOps a las empresas. Bueno, en general, hablé de cómo ver la luz al final del proceso.
Mikhail Bizhan, director de automatización de Raiffeisenbank
Ahora no tienen "DevOps" en su empresa. Es decir, trabaja, pero no en todos los equipos. Al implementar DevOps, confían en la preparación de los equipos, tanto en términos de ingenieros específicos como en términos de la necesidad del producto y la madurez de la plataforma sobre la que se construye este producto. Misha contó cómo explicarle a una empresa por qué se necesita DevOps.
El segmento bancario tiene varios motores de crecimiento: costo de los servicios y expansión de la base de clientes. Aumentar el costo de los servicios no es un buen impulsor, pero aumentar la base de clientes es todo lo contrario. Si los competidores lanzan un producto objetivamente interesante, todos los clientes van allí y, con el tiempo, el mercado se estabiliza. Por tanto, la introducción de nuevos productos en el mercado y la velocidad de su introducción es lo principal en lo que se centran los bancos. Esto es exactamente para lo que sirve DevOps y las empresas lo entienden.
La siguiente nota importante: DevOps no siempre reduce el tiempo de comercialización. DevOps no puede funcionar solo, es solo parte del proceso de creación y lanzamiento de un producto al mercado desde el desarrollo hasta la producción (desde el código hasta el cliente). Pero todo lo anterior al código no está directamente relacionado con DevOps. Es decir, los especialistas en marketing pueden estudiar el mercado durante años y pasar toda su vida poniéndose al día con la competencia. Es necesario comprender rápidamente qué necesita el cliente y planificar la implementación de tal o cual característica; a menudo esto es lo que no es suficiente para que DevOps funcione y la empresa logre su objetivo. Por lo tanto, en primer lugar, Raiffeisenbank estuvo de acuerdo con las empresas en que era necesario aprender a utilizar DevOps. La automatización por la automatización no ayudará mucho en la lucha por nuevos clientes.
En general, Misha cree que es necesario implementar DevOps, pero con prudencia. Y debemos estar preparados para el hecho de que al inicio de la transformación la productividad del equipo bajará, ganará menos dinero, pero luego estará justificado.
Automatización de pruebas en Mango Telecom
Otro informe interesante para mí como tester lo dio Egor Maslov de Mango Telecom. La presentación se denominó “Automatización del ciclo completo de pruebas en un equipo SCRUM”. Egor cree que DevOps fue creado específicamente para SCRUM, pero al mismo tiempo introducir DevOps en un equipo SCRUM es bastante problemático. Esto sucede porque el equipo SCRUM siempre está funcionando en alguna parte, no hay tiempo para distraerse con innovaciones y reconstruir el proceso. El problema también radica en el hecho de que SCRUM no implica la separación de subequipos en el equipo (equipo de pruebas, equipo de desarrollo, etc.). Bueno, además, para automatizar un proceso existente, se necesita documentación, y en SCRUM, la mayoría de las veces no hay documentación completa: "el producto es más importante que algún tipo de escritura".
Después de cambiar a SCRUM, los evaluadores comenzaron a consultar con los desarrolladores sobre cómo probar funciones. Poco a poco, el volumen de funcionalidad aumentó, no había documentación y comenzaron a detectar muchos errores en la funcionalidad que no estaba cubierta por las pruebas y, en general, ya no estaba claro quién la probó y cuándo. En pocas palabras: confusión y vacilación. Decidimos pasar a la automatización de pruebas. Pero incluso entonces hubo un completo fracaso. Contrataron especialistas en automatización subcontratados que escribieron en una pila desconocida para los evaluadores internos. El marco para las pruebas automáticas funcionó, por supuesto, pero después de que los subcontratistas se marcharon, duró dos semanas. Lo siguiente fue un intento de introducir el autotest número dos. Todo comenzó con el hecho de que todo debe construirse dentro de la empresa, por su cuenta (el vector correcto: desarrollar experiencia internamente), en el marco de SCRUM, y crear documentación en el proceso. La pila para la automatización debe ser igual a la pila del producto (aquí la agrego, no pruebes tu proyecto JavaScript con nada más). Al final del sprint, hicieron una demostración de cómo funciona el autotest con todo el equipo (útil). Así, aumentó la participación de todos los miembros del equipo en el proceso de automatización, así como la confianza en los autotests y la posibilidad de que este autotest definitivamente se utilice (y no se comente en un mes debido a constantes fallas).
Por cierto, en DevOpsForum 2019 hubo un micrófono abierto, un formato de discurso conocido desde hace mucho tiempo y, en mi opinión, útil. Caminas así, escuchas informes y luego decides que en la conferencia vale la pena discutir un tema o problema determinado, compartiendo experiencias relevantes para resolver el problema.
También noté que los organizadores hicieron una serie de informes breves. Cada informe no dura más de 10 minutos, seguido de preguntas. De esta manera podrás cubrir muchos temas a la vez y hacer preguntas a los oradores que te interesen.
Entre presentaciones, caminé por los stands de los socios de la conferencia y robé/gané muchas cosas. ¡Eh, me encanta el folleto!
Mesa redonda y temas de DevOps con el director de desarrollo de Alfastrakhovanie
Para mí, la guinda del pastel del DevOpsForum 2019 fue la sesión plenaria de una hora con expertos en DevOps. Se invitó a cuatro participantes de la sesión a observar DevOps desde diferentes ángulos: Anton Isanin (Alfastrakhovanie, director de desarrollo), Nailya Zamashkina (Fintech Lab, director de operaciones), Oleg Egorkin (Rostelecom, entrenador Agile) y Anton Martyanov (experto independiente, analizó DevOps). desde el punto de vista empresarial).
Los expertos se sentaron más cerca de la gente y entonces empezaron a suceder cosas: durante una hora entera, los participantes del público formularon sus preguntas y los expertos cargaron con la culpa. A veces hubo verdaderos debates. Las preguntas eran muy diferentes, por ejemplo: ¿se necesitan ingenieros de DevOps?, ¿por qué no pueden capacitarse como administradores de sistemas?, ¿debería ofrecerse DevOps a todos?, ¿cuál es su valor?, etc.
Luego hablé personalmente con Anton Isanin. Discutimos la necesidad de llevar la cultura DevOps a todos los hogares y revelamos el lado oscuro de la transformación de DevOps.
Imaginemos que todos se reunieron y decidieron que DevOps es necesario tanto para el producto como para la empresa y el equipo. Vamos a implementarlo. Todo salió bien. Exhalamos. DevOps nos ha acercado al cliente, ahora podemos cumplir rápidamente todos sus deseos. Como resultado, tenemos un gran departamento de operaciones con regulaciones y requisitos estrictos, que constantemente encuentra defectos en el producto y crea un montón de solicitudes. Además, a todos los defectos se les asigna el estado "urgente", incluso si el cliente inesperadamente quisiera colorear el botón de amarillo en lugar de verde. El proyecto está creciendo, el número de lanzamientos está creciendo y, en consecuencia, el número de defectos y malentendidos sobre las nuevas funciones por parte de los clientes. Operaciones contrata a 10 personas más para mantenerse al día con los defectos de notificación, y desarrollo contrata a 15 más para seguir cerrándolos. Y en lugar de introducir nuevas funciones, el equipo trabaja con infinitas SD, explicando la funcionalidad al usuario y brindando soporte al mismo tiempo. Como resultado, tanto Operaciones como Desarrollo están funcionando, pero el cliente y la empresa no están contentos: las nuevas funciones se atascan. Resulta que DevOps parece existir, pero no parece existir.
En cuanto a la necesidad de implementar DevOps, Anton afirmó claramente que esto depende directamente de la escala del negocio. Si atender a un cliente al año le aporta a la empresa mil millones, DevOps no es necesario (siempre que no sea necesario implementar nuevos cambios en este cliente con regularidad). Todo está cubierto de chocolate. Pero si el negocio crece y aparecen más clientes, entonces hay que cumplir. Como regla general, inicialmente no hay operaciones interesantes en la empresa. Primero cortamos el producto y solo entonces entendemos que para que el producto funcione debemos estar atentos a los servidores y monitorear los suministros. Ahí es cuando surge Ops. Queda por entender que Ops, como división separada, comenzará a poner muchas barreras al desarrollo y todas las entregas comenzarán a estancarse. Es decir, en este caso la cultura DevOps ya es relevante, pero no debemos olvidarnos de su lado oscuro.
Fuente: habr.com