Recentment vaig assistir a DevOpsForum 2019, organitzat per Logrocon. En aquesta conferència, els participants van intentar trobar solucions i noves eines per a una interacció eficaç entre els especialistes de negoci i desenvolupament i serveis de tecnologia de la informació.
La conferència va ser un èxit: realment hi havia molts informes útils, formats de presentació interessants i molta comunicació amb els ponents. I és especialment important que ningú no intentés vendre'm res, cosa de la qual han estat culpables darrerament els ponents de les grans conferències.
Un fragment dels discursos de Raiffeisenbank, Alfastrakhovanie, l'experiència de Mango Telecom en la implementació de l'automatització i altres detalls sota el tall.
Em dic Yana, treballo com a tester, faig automatització, així com DevOps, i m'encanta anar a conferències i reunions. Durant els últims dos anys, he estat a les conferències d'Oleg Bunin (HighLoad++, TeamLead Conf), esdeveniments Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
En primer lloc, crido l'atenció sobre el programa de la conferència. Miro menys de què tractarà l'informe i més al ponent. Encara que l'informe resulti molt tecnològic i interessant, no és cert que pugueu aplicar algunes de les millors pràctiques de l'informe a la vostra empresa. I llavors necessites un altaveu.
Llum al final del gasoducte a Raiffeisenbank
Normalment, busco parlants al marge que m'interessen. Al DevOpsForum 2019, un ponent de Raiffeisenbank, Mikhail Bizhan, va cridar el meu interès. Durant la seva intervenció, va parlar de com a poc a poc estan enganxant els seus equips a DevOps, per què ho necessiten i com vendre la idea de transformació de DevOps a les empreses. Bé, en general, vaig parlar de com veure la llum al final de la canonada.
Mikhail Bizhan, director d'automatització de Raiffeisenbank
Ara no tenen "DevOps" a la seva empresa. És a dir, treballa, però no en tots els equips. A l'hora d'implementar DevOps, confien en la preparació dels equips, tant pel que fa als enginyers específics, com pel que fa a la necessitat del producte i la maduresa de la plataforma sobre la qual es construeix aquest producte. Misha va dir com explicar a una empresa per què es necessita DevOps.
El segment bancari té diversos motors de creixement: cost dels serveis i expansió de la base de clients. Augmentar el cost dels serveis no és un motor molt bo, però fer créixer la base de clients és el contrari. Si els competidors llancen un producte objectivament genial, tots els clients hi van, i amb el temps el mercat s'anivella. Per tant, introduir nous productes al mercat i la rapidesa de la seva introducció és el principal en què se centren els bancs. Això és exactament per a què serveix DevOps, i les empreses ho entenen.
La següent nota important: DevOps no sempre redueix el temps de llançament al mercat. DevOps no pot funcionar sol, és només una part del procés de creació i comercialització d'un producte des del desenvolupament fins a la producció (des del codi fins al client). Però tot el que hi ha abans del codi no està directament relacionat amb DevOps. És a dir, els venedors poden estudiar el mercat durant anys i passar tota la vida posant-se al dia amb els competidors. Cal entendre ràpidament què necessita el client i planificar la implementació d'aquesta o aquella característica; sovint això no és suficient perquè DevOps funcioni i l'empresa assoleixi el seu objectiu. Per tant, en primer lloc, Raiffeisenbank va coincidir amb les empreses que calia aprendre a utilitzar DevOps. L'automatització pel bé de l'automatització no ajudarà gaire en la lluita per nous clients.
En general, Misha creu que DevOps s'ha d'implementar, però amb prudència. I hem d'estar preparats per al fet que a l'inici de la transformació la productivitat de l'equip baixarà, guanyarà menys diners, però després es justificarà.
Automatització de proves a Mango Telecom
Un altre informe interessant per a mi com a provador el va fer Egor Maslov de Mango Telecom. La presentació es va anomenar "Automatització del cicle complet de proves en un equip SCRUM". Egor creu que DevOps es va crear específicament per a SCRUM, però al mateix temps, introduir DevOps en un equip SCRUM és bastant problemàtic. Això passa perquè l'equip SCRUM sempre funciona en algun lloc, no hi ha temps per distreure's amb les innovacions i reconstruir el procés. El problema també rau en el fet que SCRUM no implica la separació de subequips en l'equip (equip de proves, equip de desenvolupament, etc.). Bé, a més, per automatitzar un procés existent, es necessita documentació, i a SCRUM, la majoria de vegades no hi ha documentació completament: "el producte és més important que algun tipus d'escriptura".
Després de canviar a SCRUM, els provadors van començar a consultar amb els desenvolupadors sobre com provar les funcions. A poc a poc, el volum de funcionalitats va augmentar, no hi havia documentació, i van començar a detectar molts errors en la funcionalitat que no estaven coberts per les proves i en general ja no estava clar qui ho provava i quan. En poques paraules: confusió i vacil·lació. Vam decidir canviar a l'automatització de proves. Però fins i tot llavors hi va haver un fracàs total. Van contractar especialistes en automatització subcontractats que escrivien en una pila desconeguda pels provadors interns. El marc per a les proves automàtiques va funcionar, és clar, però després que els subcontractistes van marxar, va durar dues setmanes. El següent va ser un intent d'introduir la prova automàtica número dos. Va començar amb el fet que tot s'ha de construir dins de l'empresa, pel vostre compte (el vector adequat: acumular experiència interna), en el marc de SCRUM, i crear documentació en el procés. La pila per a l'automatització hauria de ser igual a la pila del producte (aquí l'afegeixo, no proveu el vostre projecte JavaScript amb res més). Al final de l'esprint, van fer una demostració de com funciona l'autotest amb tot l'equip (útil). Així, s'ha incrementat la implicació de tots els membres de l'equip en el procés d'automatització, així com la confiança en els autotests i la possibilitat que aquest autotest s'utilitzi definitivament (i no es comentarà en un mes per errors constants).
Per cert, al DevOpsForum 2019 hi havia un micròfon obert, un format de discursos conegut des de fa temps i, al meu entendre, útil. Passeges així, escoltes informes i després decideixes que a la conferència val la pena parlar d'un determinat tema o problema, compartint l'experiència rellevant per resoldre el problema.
També em vaig adonar que els organitzadors feien una sèrie d'informes breus. Cada informe no dura més de 10 minuts, seguit de preguntes. D'aquesta manera podeu cobrir molts temes alhora i fer preguntes als ponents que us interessen.
Entre presentacions, vaig caminar pels estands dels socis de la conferència i vaig robar/guanyar moltes coses. Oh, m'encanta el fullet!
Taula rodona i problemes de DevOps amb el director de desenvolupament d'Alfastrakhovanie
La cirereta del pastís DevOpsForum 2019 per a mi va ser la sessió plenària d'una hora amb experts de DevOps. Es va convidar a quatre participants de la sessió a mirar DevOps des de diferents angles: Anton Isanin (Alfastrakhovanie, director de desenvolupament), Nailya Zamashkina (Fintech Lab, director d'operacions), Oleg Egorkin (Rostelecom, entrenador Agile) i Anton Martyanov (expert independent, va mirar DevOps). des del punt de vista empresarial).
Els experts es van asseure més a prop de la gent i aleshores van començar a passar coses: durant una hora sencera, els participants del públic van fer les seves preguntes i els experts van agafar el rap. De vegades hi havia debats reals. Les preguntes eren molt diferents, per exemple: es necessiten els enginyers de DevOps, per què no es poden formar com a administradors de sistemes, s'ha d'oferir DevOps a tothom, quin és el seu valor, etc.
Després, vaig parlar personalment amb Anton Isanin. Vam parlar de la necessitat de portar la cultura DevOps a totes les llars i vam revelar el costat fosc de la transformació de DevOps.
Imaginem que tothom es va reunir i va decidir que DevOps és necessari tant pel producte com per l'empresa i l'equip. Anem a implementar-ho. Tot va funcionar. Vam exhalar. DevOps ens ha apropat al client, ara podem complir ràpidament tots els seus desitjos. Com a resultat, tenim un gran departament d'operacions amb regulacions i requisits estrictes, i constantment troba defectes en el producte i crea un munt de peticions. A més, a tots els defectes se'ls assigna l'estat "urgent", fins i tot si el client inesperadament ha volgut pintar el botó de groc en lloc de verd. El projecte creix, creix el nombre de llançaments i, en conseqüència, el nombre de defectes i malentesos de noves funcionalitats per part dels clients. Ops contracta 10 persones més per mantenir-se al dia amb la notificació de defectes, i el desenvolupament en contracta 15 més per mantenir-se al dia amb el tancament. I en lloc d'introduir noves funcions, l'equip treballa amb SD infinites, explicant la funcionalitat a l'usuari i el suport alhora. Com a resultat, tant les operacions com el desenvolupament funcionen, però el client i l'empresa no estan contents: les noves funcions s'enganxen. Resulta que sembla que DevOps existeix, però sembla que no existeix.
Pel que fa a la necessitat d'implementar DevOps, Anton va afirmar clarament que això depèn directament de l'escala del negoci. Si el servei d'un client a l'any aporta mil milions a l'empresa, DevOps no és necessari (sempre que no calgui introduir nous canvis en aquest client amb regularitat). Tot està cobert de xocolata. Però si el negoci creix i apareixen més clients, cal que compleixis. Com a regla general, inicialment no hi ha cap operació genial a l'empresa. Primer tallem el producte i només després entenem que perquè el producte funcioni, hem de vigilar els servidors i controlar els subministraments. És llavors quan neix Ops. Cal entendre que Ops, com a divisió separada, començarà a posar un munt de barreres al desenvolupament i tots els lliuraments començaran a aturar-se. És a dir, en aquest cas, la cultura DevOps ja és rellevant, però no hem d'oblidar-nos del seu costat fosc.
Font: www.habr.com