Recientemente asistí al DevOpsForum 2019, organizado por Logrocon. En esta conferencia, los participantes buscaron soluciones y nuevas herramientas para una interacción eficaz entre el negocio y los especialistas en desarrollo y mantenimiento de tecnología de la información.
La conferencia fue un éxito: había realmente muchas presentaciones útiles, formatos interesantes y un montón de interacciones con los ponentes. Y lo más importante, nadie intentó venderme nada, lo que últimamente sucede con frecuencia en grandes conferencias.
Extractos de las presentaciones de Raiffeisenbank, AlfaStrakhovanie, la experiencia de Mango Telecom en la implementación de la automatización y otros detalles a continuación.
Me llamo Yana, soy probadora, me dedico a la automatización y DevOps, y me encanta asistir a conferencias y meetups. En los últimos dos años, he estado en conferencias de Oleg Bunin (HighLoad++, TeamLead Conf), en eventos de Jug (Heisenbug, JPoint), en TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Lo primero que miro es el programa de la conferencia. En menor medida, observo el tema de la presentación, y en mayor medida, al ponente. Incluso si la presentación es muy técnica e interesante, no es un hecho que puedas aplicar algunas de las mejores prácticas en tu empresa. Y entonces necesitas al ponente.
Luz al final de la tubería en Raiffeisenbank
Normalmente, organizo cacerías de ponentes que me interesan en los pasillos. En DevOpsForum 2019, un ponente que captó mi interés fue Mikhail Bijan de Raiffeisenbank. Durante su intervención, explicó cómo introducen gradualmente a sus equipos en DevOps, por qué lo necesitan y cómo venderle a la empresa la idea de la transformación DevOps. En general, habló sobre cómo ver la luz al final de la tubería.
Mikhail Bijan, Director de Automatización en Raiffeisenbank
Actualmente, en su empresa no hay 'true DevOps'. Es decir, lo hay, pero no en todos los equipos. Al implementar DevOps, se basan en la preparación de los equipos, tanto desde la perspectiva de los ingenieros concretos, como desde la necesidad del producto y la madurez de la plataforma sobre la que se construye dicho producto. Misha explicó cómo hacer entender a la empresa por qué necesita DevOps.
El segmento bancario tiene varios impulsores de crecimiento: el costo de los servicios y la expansión de la base de clientes. El aumento del costo de los servicios no es un buen impulsor, mientras que el crecimiento de la base de clientes sí lo es. Si los competidores lanzan un producto realmente impresionante, todos los clientes se van hacia allí, y luego, con el tiempo, el mercado se equilibra. Por lo tanto, el lanzamiento de nuevos productos y la velocidad de su introducción son lo principal en lo que se enfocan los bancos. Precisamente para eso se necesita DevOps, y el negocio lo entiende.
La siguiente observación importante: DevOps no siempre reduce el time to market. DevOps no puede funcionar solo, es solo una parte del proceso de creación y lanzamiento de un producto al mercado, desde el desarrollo hasta la producción (del código al cliente). Pero todo lo que ocurre antes del código no está directamente relacionado con DevOps. Es decir, los mercadólogos pueden estudiar el mercado durante años y pasar toda su vida alcanzando a los competidores. Es crucial entender rápidamente lo que necesita el cliente y planificar la implementación de una característica u otra; a menudo, precisamente esto es lo que falta para que DevOps funcione y la empresa alcance sus objetivos. Así que, en primer lugar, en Raiffeisenbank se acordó con el negocio 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 DevOps debe implementarse, pero con sensatez. Y hay que estar preparado para que al principio de la transformación el rendimiento del equipo disminuya, ganarán menos dinero, pero luego esto se justificará.
Automatización de pruebas en 'Mango Telecom'
Otro informe interesante para mí, como tester, lo presentó Egor Maslov de «Mango Telecom». La presentación se tituló «Automatización del ciclo completo de pruebas en un equipo SCRUM». Egor considera que DevOps está creado específicamente para SCRUM, pero al mismo tiempo, implementar DevOps en un equipo SCRUM puede ser bastante problemático. Esto ocurre porque el equipo SCRUM siempre está corriendo, no hay tiempo para distraerse con innovaciones y reorganizar procesos. El problema también radica en que SCRUM no contempla la formación de sub-equipos (equipo de testers, equipo de desarrolladores, etc.). Además, para automatizar un proceso existente, se necesita documentación, y en SCRUM, la documentación suele estar completamente ausente: «el producto es más importante que cualquier documento».
Después de pasar a SCRUM, los testers comenzaron a consultar a los desarrolladores sobre cómo probar las funcionalidades. Gradualmente, el volumen de funcionalidades aumentó, la documentación faltaba y comenzaron a detectar muchos errores en funcionalidades que no tenían cobertura de pruebas y ya no estaba claro quién y cuándo las había probado. En pocas palabras: desorganización total. Decidieron pasar a la automatización de pruebas. Pero incluso entonces, se produjo un desastre completo. Contrataron a especialistas externos para la automatización, que programaron en un stack desconocido para los testers internos. El marco para las pruebas automáticas funcionó, pero después de que los externos se fueron, sobrevivió solo dos semanas. Luego hubo un segundo intento de introducir las pruebas automáticas. Esto comenzó con la necesidad de construir todo dentro de la empresa, con sus propios recursos (la dirección correcta: aumentar la experiencia interna), dentro del marco de SCRUM, y en el proceso crear documentación. El stack para la automatización debe ser igual al stack del producto (aquí estoy totalmente de acuerdo, no prueben un proyecto en JavaScript con algo diferente). Al final del sprint, organizaban una demostración de cómo funcionaba la prueba automática, con la participación de todo el equipo (útil). Así, se incrementaba la implicació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 dicha prueba automática se utilizara efectivamente (y no se comentara después de un mes debido a fracasos constantes).
Por cierto, en DevOpsForum 2019 hubo un micrófono abierto, un formato de presentaciones conocido y, en mi opinión, útil. Vas, escuchas las charlas y luego decides que dentro de la conferencia vale la pena discutir un tema o problema específico, compartir una experiencia relevante para resolver una tarea.
También noté que los organizadores crearon una serie de charlas breves. Cada charla dura no más de 10 minutos, seguidas de preguntas. De esta manera, se pueden abordar muchos temas a la vez y hacer preguntas a los ponentes que han despertado interés.
Entre las charlas, paseé por los stands de los socios de la conferencia y recogí/gané muchas cosas interesantes. ¡Ah, me encanta el material promocional!
Mesa redonda y preguntas sobre DevOps con el director de desarrollo de Alfastrakhovanie.
La guinda del pastel de DevOpsForum 2019 para mí fue la sesión plenaria de una hora con expertos en DevOps. Se invitaron a cuatro participantes en la sesión, que debían analizar DevOps desde diversas perspectivas: Anton Isanin (Alfastrakhovanie, director de desarrollo), Nailya Zamashkina (Fintech Lab, directora de operaciones), Oleg Egorkin (Rostelecom, Agile coach) y Anton Martyanov (experto independiente, evaluando DevOps desde el punto de vista del negocio).
Los expertos se acercaron al público y comenzaron: durante una hora, los participantes del público hicieron sus preguntas, mientras que los expertos respondían. A veces, se generaban auténticos debates. Las preguntas fueron de lo más variado, por ejemplo: ¿realmente necesitamos ingenieros de DevOps?, ¿por qué no se pueden formar a partir de administradores de sistemas?, ¿deberíamos ofrecer DevOps a todos?, ¿cuál es su valor?, y así sucesivamente.
Luego, hablé personalmente con Anton Isanin. Discutimos la necesidad de llevar la cultura DevOps a cada hogar y revelamos el lado oscuro de la transformación DevOps.
Imaginemos que todos se reunieron y decidieron que DevOps es necesario tanto para el producto como para el negocio y el equipo. Comenzaron a implementarlo. Todo salió bien. Respiran aliviados. DevOps nos acercó al cliente, ahora podemos cumplir rápidamente con todas sus solicitudes. Al final, tenemos un gran departamento de Ops con regulaciones y requisitos estrictos, y constantemente están generando defectos en el producto, creando una gran cantidad de solicitudes. Además, todos los defectos llegan con el estado "urgente", incluso si al cliente de repente le gustaría cambiar el color de un botón de verde a amarillo. El proyecto crece, aumenta la cantidad de lanzamientos y, por lo tanto, la cantidad de defectos y la confusión de los clientes con las nuevas funcionalidades. Ops contrata otros 10 personas para poder reportar los defectos, y desarrollo contrata 15 más para cerrarlos. Y en lugar de implementar nuevas características, el equipo trabaja con interminables tickets de soporte, explicando la funcionalidad al usuario y también al soporte técnico. Al final, tanto Ops como desarrollo están ocupados, pero el cliente y el negocio están descontentos: nuevas funcionalidades se estancan. Resulta que DevOps parece estar presente, pero en realidad no lo está.
Sobre la necesidad de implementar DevOps, Anton declaró sin lugar a dudas que depende directamente de la escala del negocio. Si atender a un cliente al año le aporta a la compañía mil millones, no se necesita DevOps (siempre que no sea necesario lanzar cambios nuevos a ese cliente regularmente). Todo va bien. Pero si el negocio crece y hay más clientes, entonces ya se debe estar a la altura. Generalmente, no hay un ops competente en la empresa desde el principio. Primero desarrollamos el producto, y solo después entendemos que para que el producto funcione, necesitamos vigilar las entregas. servidores, mantener un control sobre ellas. Entonces surge Ops. Queda por entender que Ops, como departamento separado, comenzará a imponer una serie de barreras para el desarrollo y todas las entregas empezarán a atascarse. Es decir, en este caso, la cultura DevOps ya es relevante, pero no hay que olvidar su lado oscuro.
Fuente: habr.com
