Recentemente asistín a DevOpsForum 2019, organizado por Logrocon. Nesta conferencia, os participantes trataron de atopar solucións e novas ferramentas para unha interacción eficaz entre os especialistas en empresas e desenvolvemento e servizos de tecnoloxía da información.
A conferencia foi un éxito: houbo realmente moitos informes útiles, formatos de presentación interesantes e moita comunicación cos relatores. E é especialmente importante que ninguén intentou venderme nada, algo do que últimamente son culpables os relatores de grandes congresos.
Un fragmento dos discursos de Raiffeisenbank, Alfastrakhovanie, a experiencia de Mango Telecom na implementación da automatización e outros detalles baixo o corte.
Chámome Yana, traballo como probadora, fago automatización, así como DevOps e encántame ir a conferencias e reunións. Durante os últimos dous anos, estiven nas conferencias de Oleg Bunin (HighLoad++, TeamLead Conf), eventos Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
En primeiro lugar, chamo a atención sobre o programa da conferencia. Miro menos de que vai tratar o informe, e máis ao relator. Aínda que o informe resulte moi tecnolóxico e interesante, non é certo que poidas aplicar na túa empresa algunhas das mellores prácticas do informe. E entón necesitas un altofalante.
Luz ao final do gasoduto en Raiffeisenbank
Normalmente, busco oradores á marxe que me interesen. No DevOpsForum 2019, un orador de Raiffeisenbank, Mikhail Bizhan, chamou o meu interese. Durante a súa intervención, falou sobre como gradualmente os seus equipos están enganchados a DevOps, por que o necesitan e como vender a idea de transformación de DevOps ás empresas. Ben, en xeral, falei de como ver a luz ao final do gasoduto.
Mikhail Bizhan, director de automatización de Raiffeisenbank
Agora non teñen "DevOps" na súa empresa. É dicir, traballa, pero non en todos os equipos. Á hora de implementar DevOps, confían na preparación dos equipos, tanto en canto a enxeñeiros específicos, como en canto á necesidade do produto e á madurez da plataforma na que se constrúe este produto. Misha dixo como explicarlle a unha empresa por que se necesita DevOps.
O segmento bancario ten varios motores de crecemento: custo dos servizos e expansión da base de clientes. Aumentar o custo dos servizos non é un motor moi bo, pero aumentar a base de clientes é todo o contrario. Se os competidores lanzan un produto obxectivamente xenial, todos os clientes van alí, entón co paso do tempo o mercado se nivela. Polo tanto, a introdución de novos produtos no mercado e a rapidez da súa introdución é o principal no que se centran os bancos. Para iso é exactamente o DevOps, e as empresas entenden isto.
A seguinte nota importante: DevOps non sempre reduce o tempo de comercialización. DevOps non pode funcionar só, é só parte do proceso de creación e posta ao mercado dun produto desde o desenvolvemento ata a produción (do código ao cliente). Pero todo antes do código non está directamente relacionado con DevOps. É dicir, os comerciantes poden estudar o mercado durante anos e pasar a súa vida enteira poñéndose ao día dos competidores. É necesario comprender rapidamente o que necesita o cliente e planificar a implementación desta ou aquela función, moitas veces isto non é suficiente para que DevOps funcione e a empresa alcance o seu obxectivo. Polo tanto, en primeiro lugar, Raiffeisenbank coincidiu coas empresas en que era necesario aprender a usar DevOps. A automatización en aras da automatización non axudará moito na loita por novos clientes.
En xeral, Misha cre que DevOps debe ser implementado, pero con prudencia. E debemos estar preparados para o feito de que ao comezo da transformación a produtividade do equipo vai caer, gañará menos cartos, pero entón estará xustificado.
Automatización de probas en Mango Telecom
Outro informe interesante para min como probador deuno Egor Maslov de Mango Telecom. A presentación chamouse "Automatización do ciclo completo de probas nun equipo SCRUM". Egor cre que DevOps foi creado específicamente para SCRUM, pero ao mesmo tempo, introducir DevOps nun equipo SCRUM é bastante problemático. Isto ocorre porque o equipo SCRUM sempre está a funcionar nalgún lugar, non hai tempo para distraerse coas innovacións e reconstruír o proceso. O problema tamén radica en que SCRUM non implica a separación de subequipos no equipo (equipo de probas, equipo de desenvolvemento, etc.). Ben, ademais, para automatizar un proceso existente, é necesaria a documentación, e en SCRUM, a maioría das veces non hai documentación por completo: "o produto é máis importante que algún tipo de escritura".
Despois de cambiar a SCRUM, os probadores comezaron a consultar cos desenvolvedores sobre como probar as funcións. Pouco a pouco, o volume de funcionalidades aumentou, non había documentación, e comezaron a detectar moitos erros na funcionalidade que non estaban cubertos polas probas e en xeral xa non estaba claro quen a probaba e cando. En poucas palabras - confusión e vacilación. Decidimos pasar á automatización das probas. Pero aínda así houbo un fracaso total. Contrataron especialistas en automatización subcontratados que escribían nunha pila descoñecida para os probadores internos. O marco para as probas automáticas funcionou, por suposto, pero despois de que os subcontratistas marchasen, durou dúas semanas. O seguinte foi un intento de introducir a proba automática número dous. Comezou co feito de que todo ten que ser construído dentro da empresa, por conta propia (o vector correcto: acumular experiencia internamente), no marco de SCRUM, e crear documentación no proceso. A pila para a automatización debe ser igual á pila do produto (aquí estou engadindo, non probes o teu proxecto JavaScript con nada máis). Ao final do sprint, fixeron unha demostración de como funciona a autotest con todo o equipo (útil). Así, aumentou a implicación de todos os membros do equipo no proceso de automatización, así como a confianza nos autotests e a posibilidade de que este autotest se utilice definitivamente (e non se comentará nun mes debido a constantes fallos).
Por certo, no DevOpsForum 2019 había un micrófono aberto, un formato de discurso coñecido desde hai tempo e, na miña opinión, útil. Paseas así, escoitas informes e despois decides que na conferencia paga a pena discutir un determinado tema ou problema, compartindo experiencias relevantes na resolución do problema.
Tamén notei que os organizadores fixeron un fluxo de reportaxes breves. Cada informe non dura máis de 10 minutos, seguido de preguntas. Deste xeito podes cubrir moitos temas á vez e facer preguntas aos relatores que che interesen.
Entre presentacións, pasei polas casetas dos socios da conferencia e roubei/gañei moitas cousas. Oh, encántame o folleto!
Mesa redonda e problemas de DevOps co director de desenvolvemento de Alfastrakhovanie
A guinda do bolo do DevOpsForum 2019 para min foi a sesión plenaria de unha hora con expertos en DevOps. Convidouse a catro participantes da sesión para ver DevOps desde diferentes ángulos: Anton Isanin (Alfastrakhovanie, director de desenvolvemento), Nailya Zamashkina (Fintech Lab, director operativo), Oleg Egorkin (Rostelecom, adestrador Agile) e Anton Martyanov (experto independente, mirou DevOps). desde o punto de vista empresarial).
Os expertos sentáronse máis preto da xente e entón comezaron a suceder cousas: durante unha hora enteira, os participantes do público fixeron as súas preguntas e os expertos tomaron o rap. Ás veces había verdadeiros debates. As preguntas eran moi diferentes, por exemplo: se necesitan enxeñeiros de DevOps, por que non se poden formar como administradores de sistemas, debería ofrecerse DevOps a todos, cal é o seu valor, etc.
Despois, falei persoalmente con Anton Isanin. Discutimos a necesidade de levar a cultura DevOps a todos os fogares e revelamos o lado escuro da transformación DevOps.
Imaxinemos que todos se reuniron e decidiron que DevOps é necesario tanto para o produto como para a empresa e o equipo. Imos implementalo. Todo funcionou. Expiramos. DevOps achegounos ao cliente, agora podemos cumprir rapidamente todos os seus desexos. Como resultado, temos un gran departamento de Operacións con regulamentos e requisitos estritos, e constantemente atopa defectos no produto e crea un montón de solicitudes. Ademais, a todos os defectos asígnaselles o estado "urxente", aínda que o cliente quixese colorear inesperadamente o botón de amarelo en lugar de verde. O proxecto crece, crece o número de lanzamentos e, en consecuencia, o número de defectos e malentendidos de novas funcionalidades por parte dos clientes. Ops contrata a 10 persoas máis para seguir informando de defectos e o desenvolvemento contrata a 15 máis para pechalos. E en lugar de introducir novas funcións, o equipo traballa con SD infinitas, explicando a funcionalidade ao usuario e o soporte ao mesmo tempo. Como resultado, tanto as operacións como o desenvolvemento están funcionando, pero o cliente e a empresa están descontentos: as novas funcións quedan atascadas. Resulta que DevOps parece existir, pero non parece existir.
Respecto da necesidade de implementar DevOps, Anton afirmou claramente que isto depende directamente da escala do negocio. Se o servizo dun cliente ao ano dálle á empresa mil millóns, DevOps non é necesario (sempre que non necesites realizar novos cambios neste cliente con regularidade). Todo está cuberto de chocolate. Pero se o negocio crece e aparecen máis clientes, entón tes que cumprir. Como regra xeral, inicialmente non hai Ops interesantes na empresa. Primeiro cortamos o produto e só entón entendemos que para que o produto funcione, temos que estar atentos aos servidores e controlar os suministros. É entón cando nace Ops. Queda por entender que Ops, como división separada, comezará a poñer unha morea de barreiras ao desenvolvemento e todas as entregas comezarán a paralizarse. É dicir, neste caso, a cultura DevOps xa é relevante, pero non debemos esquecernos do seu lado escuro.
Fonte: www.habr.com