Recientemente visité DevOpsForum 2019 alojado por Logrocon. En esta conferencia, los participantes trataron de encontrar soluciones y nuevas herramientas para la interacción efectiva de empresas y especialistas en los servicios de desarrollo y 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 oradores. Y es especialmente importante que nadie haya intentado venderme nada, ya que los oradores de las grandes conferencias han culpado últimamente.
Al exprimir 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 probador, me dedico a la automatización, así como a DevOps y me encanta ir a conferencias y reuniones. En los últimos dos años, he estado en las conferencias de Oleg Bunin (HighLoad ++, TeamLead Conf), eventos de Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
En primer lugar, presto atención al programa de la conferencia. En menor medida, miro de qué se tratará el informe, en mayor medida, para el orador. Incluso si el informe resulta ser 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 de la tubería en Raiffeisenbank
Por lo general, voy en busca de oradores interesantes al margen. En DevOpsForum 2019, un orador de Raiffeisenbank, Mikhail Bizhan, entró en mi campo de interés. Durante el discurso, contó cómo están plantando constantemente sus equipos en DevOps, por qué lo necesitan y cómo vender la idea de la transformación de DevOps a las empresas. Bueno, en general, hablé sobre cómo ver la luz al final de la tubería.
Mikhail Bizhan, Director de Automatización en RaiffeisenbankAhora su compañía no tiene "DevOps". Es decir, él es cierto, pero no en todos los equipos. Al implementar DevOps, confían en la voluntad de los equipos tanto desde el punto de vista de ingenieros específicos como desde el punto de vista de las necesidades del producto y la madurez de la plataforma en la que se basa este producto. Misha dijo cómo explicarle al negocio por qué se necesita DevOps.
El segmento bancario tiene varios motores de crecimiento: el costo de los servicios y la expansión de la base de clientes. Aumentar el costo de los servicios no es un buen impulsor, pero el crecimiento de la base de clientes es al revés. Si los competidores producen un producto objetivamente genial, todos los clientes van allí y, con el tiempo, el mercado se igualará. Por lo tanto, el lanzamiento de nuevos productos en el mercado y la velocidad de su lanzamiento es lo principal que guían los bancos. Esto es exactamente para lo que sirve DevOps, y la empresa lo comprende.
La siguiente nota importante: DevOps no siempre reduce el tiempo de comercialización. DevOps no puede funcionar solo, es solo una parte del proceso de creación y lanzamiento de un producto en el mercado desde el desarrollo hasta la producción (desde el código hasta el cliente). Pero todo antes del código no tiene relación directa con DevOps. Es decir, los especialistas en marketing pueden estudiar el mercado durante años y ponerse al día con los competidores toda su vida. Debe comprender rápidamente lo que necesita el cliente y planificar la implementación de una característica en particular; a menudo esto no es suficiente para que DevOps funcione y la empresa alcance el objetivo. Por lo tanto, en primer lugar, Raiffeisenbank acordó con el negocio que era necesario aprender a usar DevOps. La automatización en aras de la automatización no será de gran ayuda en la lucha por nuevos clientes.
En general, Misha cree que DevOps debe implementarse, pero sabiamente. Y debe estar preparado para el hecho de que al comienzo de la transformación el equipo perderá productividad, ganará menos dinero, pero luego se hará realidad.
Prueba de automatización en Mango Telecom
Yegor Maslov de Mango Telecom hizo otro informe interesante para mí como probador. La presentación se llamó "Automatización del ciclo de prueba completo en el equipo SCRUM". Egor cree que DevOps fue creado específicamente para SCRUM, pero al mismo tiempo, introducir DevOps en el equipo SCRUM es bastante problemático. Esto se debe a que el equipo SCRUM siempre se está ejecutando en algún lugar, no hay tiempo para distraerse con las innovaciones y reconstruir el proceso. El problema también radica en el hecho de que SCRUM no implica sub-equipos (equipo de probadores, equipo de desarrollo, etc.). Bueno, además, se necesita documentación para automatizar el proceso existente, y en SCRUM a menudo no hay ninguna documentación: "un producto es más importante que algún tipo de garabato".
Después de cambiar a SCRUM, los evaluadores comenzaron a consultar con los desarrolladores sobre cómo probar las características. Poco a poco, el volumen de la funcionalidad aumentó, la documentación faltaba y comenzaron a detectar muchos errores en la funcionalidad en la que no había cobertura de prueba y, en general, ya no estaba claro quién y cuándo la probó. En pocas palabras: confusión y tambaleo. Decidimos pasar a la automatización de pruebas. Pero luego hubo un completo fracaso. Atrajeron especialistas externos para la automatización que escribieron en una pila desconocida para los evaluadores habituales. El marco de autotest ciertamente funcionó, pero después de que los subcontratistas se fueron, vivió durante dos semanas. Luego hubo un intento de introducir la autoevaluación número dos. Comenzó con el hecho de que todo debe construirse dentro de la empresa, por sí solo (el vector correcto: aumentar la experiencia interna), en el marco de SCRUM y en el proceso de creación de documentación. La pila para la automatización debe ser igual a la pila del producto (aquí diré más, bueno, no pruebes tu proyecto en JavaScript con nada más). Al final del sprint, organizaron una demostración de cómo funciona la prueba automática, con la participación de todo el equipo (útil). Por lo tanto, aumentó la participación de todos los miembros del equipo en el proceso de automatización, así como la confianza en las pruebas automáticas y la posibilidad de que esta prueba automática se use con precisión (y no se comente en un mes debido a fallas constantes).
Por cierto, un micrófono abierto funcionó en DevOpsForum 2019, un formato de presentaciones muy conocido y, en mi opinión, útil. Camina así, escucha los informes y luego decide que vale la pena discutir un tema o problema en el marco de la conferencia y compartir 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, luego vienen las preguntas. Por lo tanto, puede cubrir muchos temas a la vez y molestar a los oradores que estén interesados.
Entre los informes, caminé por las gradas de los socios de la conferencia y saqué / gané muchas cosas. Eh, me encanta razdatku!Mesa redonda y preguntas de DevOps con el Director de Desarrollo de Alfastrah
La guinda del pastel DevOpsForum 2019 para mí fue una sesión plenaria de una hora de duración con expertos de DevOps. Cuatro participantes fueron invitados a ver DevOps desde diferentes ángulos: Anton Isanin (Alfastrakhovanie, Director de Desarrollo), Naila Zamashkina (Fintech Lab, Director de Operaciones), Oleg Egorkin (Rostelecom, Agile-coach) y Anton Martyanov (independiente experto, miró a DevOps desde una perspectiva comercial).
Los expertos se sentaron más cerca de la gente y comenzó: durante una hora, los participantes de la audiencia hicieron sus preguntas y los expertos se quedaron sin aliento. A veces surgió un verdadero debate. Las preguntas eran muy diferentes, por ejemplo: si los ingenieros de DevOps son necesarios, por qué no se los puede hacer crecer a través de los administradores del sistema, si DevOps debería ofrecerse a todos, cuál es su valor, etc.
Entonces, hablé con Anton Isanin personalmente. Discutimos la necesidad de llevar la cultura DevOps a cada hogar y revelamos el lado oscuro de la transformación DevOps.
Imagine que todos se reunieron y decidieron que DevOps es necesario tanto para el producto como para el negocio y el equipo. Se apresuró a presentar. Todo salió bien. Exhalado DevOps nos acercó al cliente, ahora podemos cumplir rápidamente todos sus deseos. Como resultado, tenemos una gran división Ops con estrictos reglamentos y requisitos, y constantemente descubre defectos para el producto, crea un montón de aplicaciones. Además, todos los defectos vienen con el estado de "urgente", incluso si el cliente de repente quería pintar el botón en 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 de las nuevas funcionalidades por parte de los clientes. Ops contrata a otras 10 personas para mantenerse al día con los defectos, y el desarrollo contrata a otras 15 para mantenerse al día con ellos. Y en lugar de introducir nuevas características, el equipo trabaja con SD infinitas, explicando la funcionalidad al usuario y el soporte para una. Como resultado, tanto Ops como el desarrollo están funcionando, pero el cliente y la empresa no están contentos: las nuevas características se atascan. Resulta que DevOps parece estar allí, pero no parece estarlo.
Sobre la necesidad de implementar DevOps, Anton declaró inequívocamente que esto depende directamente de la escala del negocio. Si el servicio a un cliente al año genera mil millones para la compañía, no se necesita DevOps (siempre que no sea necesario implementar nuevos cambios en este cliente regularmente). Todo es muy chocolate. Pero si el negocio crece, aparecen más clientes, entonces ya debemos cumplir. Como regla general, la compañía no tiene buenas operaciones inicialmente. Primero vimos el producto, y solo entonces entendemos que el producto debería funcionar, debe mirar los servidores, monitorear las entregas. Entonces surge Ops. Queda por entender que Ops, como una unidad separada, comenzará a exponer un montón de barreras para el desarrollo y todas las entregas comenzarán a detenerse. Es decir, en este caso, la cultura DevOps ya es relevante, pero no debe olvidarse de su lado oscuro.