Jeg deltok nylig på DevOpsForum 2019, arrangert av Logrocon. På denne konferansen prøvde deltakerne å finne løsninger og nye verktøy for effektiv samhandling mellom forretnings- og utviklings- og informasjonsteknologitjenestespesialister.
Konferansen var en suksess: det var virkelig mange nyttige rapporter, interessante presentasjonsformater og mye kommunikasjon med foredragsholderne. Og det er spesielt viktig at ingen prøvde å selge meg noe, noe foredragsholdere på store konferanser har gjort seg skyldig i i det siste.
Et utdrag fra talene til Raiffeisenbank, Alfastrakhovanie, Mango Telecoms erfaring med å implementere automatisering og andre detaljer under kuttet.
Jeg heter Yana, jeg jobber som tester, driver med automatisering, samt DevOps, og jeg elsker å gå på konferanser og møter. I løpet av de siste to årene har jeg vært på Oleg Bunins konferanser (HighLoad++, TeamLead Conf), Jug-arrangementer (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Først og fremst trekker jeg oppmerksomheten til konferanseprogrammet. Jeg ser mindre på hva rapporten skal handle om, og mer på foredragsholderen. Selv om rapporten viser seg å være svært teknologisk og interessant, er det ikke et faktum at du vil kunne ta i bruk noen av de beste praksisene fra rapporten i din bedrift. Og så trenger du en høyttaler.
Lys i enden av rørledningen ved Raiffeisenbank
Vanligvis jakter jeg på høyttalere på sidelinjen som interesserer meg. På DevOpsForum 2019 fanget en foredragsholder fra Raiffeisenbank, Mikhail Bizhan, min interesse. Under talen hans snakket han om hvordan de gradvis får teamene sine hektet på DevOps, hvorfor de trenger det, og hvordan de kan selge ideen om DevOps-transformasjon til virksomheten. Vel, generelt snakket jeg om hvordan man kan se lyset på enden av rørledningen.
Mikhail Bizhan, direktør for automatisering i Raiffeisenbank
Nå har de ikke "DevOps" i selskapet sitt. Det vil si at han jobber, men ikke i alle lag. Når de implementerer DevOps, er de avhengige av teamenes beredskap, både når det gjelder spesifikke ingeniører, og når det gjelder behovet til produktet og modenheten til plattformen som dette produktet er bygget på. Misha fortalte hvordan man forklarer en bedrift hvorfor DevOps er nødvendig.
Banksegmentet har flere vekstdrivere: kostnader for tjenester og utvidelse av kundebasen. Å øke kostnadene for tjenester er ikke en veldig god driver, men å øke kundebasen er det motsatte. Hvis konkurrentene slipper et objektivt kult produkt, går alle kunder dit, så jevner markedet seg over tid ut. Derfor er introduksjon av nye produkter til markedet og hastigheten på introduksjonen deres det viktigste bankene fokuserer på. Dette er akkurat hva DevOps er for, og bedrifter forstår dette.
Den neste viktige merknaden: DevOps reduserer ikke alltid tiden til markedet. DevOps kan ikke fungere alene, det er bare en del av prosessen med å skape og bringe et produkt til markedet fra utvikling til produksjon (fra kode til kunde). Men alt før koden er ikke direkte relatert til DevOps. Det vil si at markedsførere kan studere markedet i årevis og bruke hele livet på å ta igjen konkurrentene. Det er nødvendig å raskt forstå hva klienten trenger og planlegge implementeringen av denne eller den funksjonen – ofte er dette det som ikke er nok for at DevOps skal fungere og selskapet skal nå målet sitt. Derfor var Raiffeisenbank først og fremst enig med næringslivet i at det var nødvendig å lære seg å bruke DevOps. Automatisering for automatiseringens skyld vil ikke hjelpe mye i kampen om nye kunder.
Generelt mener Misha at DevOps må implementeres, men klokt. Og vi må være forberedt på det faktum at i begynnelsen av transformasjonen vil teamets produktivitet falle, det vil tjene mindre penger, men da vil det være rettferdiggjort.
Automatisering av testing hos Mango Telecom
En annen interessant rapport for meg som tester ble gitt av Egor Maslov fra Mango Telecom. Presentasjonen ble kalt "Automasjon av hele testsyklusen i et SCRUM-team." Egor mener at DevOps ble laget spesielt for SCRUM, men samtidig er det ganske problematisk å introdusere DevOps i et SCRUM-team. Dette skjer fordi SCRUM-teamet alltid kjører et sted, det er ikke tid til å bli distrahert av innovasjoner og gjenoppbygge prosessen. Problemet ligger også i at SCRUM ikke innebærer separasjon av underteam i teamet (testteam, utviklingsteam, og så videre). Vel, dessuten, for å automatisere en eksisterende prosess, er det nødvendig med dokumentasjon, og i SCRUM er det oftest ingen dokumentasjon fullstendig - "produktet er viktigere enn en slags skriving."
Etter å ha byttet til SCRUM begynte testerne å rådføre seg med utviklere om hvordan de skulle teste funksjoner. Gradvis økte volumet av funksjonalitet, det var ingen dokumentasjon, og de begynte å fange opp mange feil i funksjonaliteten som ikke ble dekket av tester og generelt var det ikke lenger klart hvem som testet den og når. I et nøtteskall - forvirring og vakling. Vi bestemte oss for å gå over til testautomatisering. Men selv da var det fullstendig fiasko. De hyret inn outsourcede automasjonsspesialister som skrev på en stabel som er ukjent for interne testere. Rammeverket for autotester fungerte selvfølgelig, men etter at outsourcerne sluttet, varte det i to uker. Neste var et forsøk på å introdusere autotesting nummer to. Det begynte med at alt må bygges innad i bedriften, på egenhånd (rett vektor: bygge opp kompetanse internt), innenfor rammen av SCRUM, og lage dokumentasjon i prosessen. Stabelen for automatisering skal være lik stabelen til produktet (her legger jeg den til, ikke test JavaScript-prosjektet ditt med noe annet). På slutten av sprinten gjorde de en demo av hvordan autotesten fungerer med hele teamet (nyttig). Dermed økte involveringen av alle teammedlemmer i automatiseringsprosessen, samt tilliten til autotester og sjansen for at denne autotesten definitivt vil bli brukt (og vil ikke bli kommentert ut på en måned på grunn av konstante feil).
Forresten, på DevOpsForum 2019 var det en åpen mikrofon - et lenge kjent og, etter min mening, nyttig format for taler. Du går rundt slik, lytter til rapporter og bestemmer deg for at det på konferansen er verdt å diskutere et bestemt tema eller problem, dele relevant erfaring med å løse problemet.
Jeg la også merke til at arrangørene laget en strøm av korte reportasjer. Hver rapport varer ikke mer enn 10 minutter, etterfulgt av spørsmål. På denne måten kan du dekke mange emner samtidig og stille spørsmål til foredragsholdere som interesserer deg.
Mellom presentasjonene gikk jeg rundt i standene til konferansepartnerne og stjal/vant mye. Å, jeg elsker utdelingen!
Round table og DevOps-problemer med utviklingsdirektøren i Alfastrakhovanie
Toppen på DevOpsForum 2019-kaken for meg var den timelange plenumssesjonen med DevOps-eksperter. Fire sesjonsdeltakere ble invitert til å se på DevOps fra forskjellige vinkler: Anton Isanin (Alfastrakhovanie, utviklingsdirektør), Nailya Zamashkina (Fintech Lab, driftsdirektør), Oleg Egorkin (Rostelecom, Agile coach) og Anton Martyanov (uavhengig ekspert, så på DevOps fra et forretningsmessig synspunkt).
Ekspertene satte seg nærmere folket og så begynte ting å skje: I en hel time stilte deltakere fra salen sine spørsmål, og ekspertene tok rappen. Noen ganger var det virkelige debatter. Spørsmålene var svært forskjellige, for eksempel: trengs DevOps-ingeniører i det hele tatt, hvorfor kan de ikke utdannes som systemadministratorer, bør DevOps tilbys alle, hva er verdien av det, og så videre.
Så snakket jeg med Anton Isanin personlig. Vi diskuterte behovet for å bringe DevOps-kulturen til alle hjem og avslørte den mørke siden av DevOps-transformasjonen.
La oss forestille oss at alle kom sammen og bestemte at DevOps er nødvendig både av produktet og av virksomheten og teamet. La oss implementere det. Alt ordnet seg. Vi pustet ut. DevOps har brakt oss nærmere kunden, nå kan vi raskt oppfylle alle hans ønsker. Som et resultat av dette har vi en stor Ops-avdeling med strenge regler og krav, og den finner stadig feil i produktet og skaper en haug med forespørsler. Dessuten tildeles alle defekter statusen "haster", selv om klienten uventet ønsket å farge knappen gul i stedet for grønn. Prosjektet vokser, antallet utgivelser vokser og følgelig antallet defekter og misforståelser av ny funksjonalitet fra kunder. Ops ansetter 10 personer til for å holde tritt med rapportering av mangler, og Development ansetter 15 til for å holde tritt med å lukke dem. Og i stedet for å introdusere nye funksjoner, jobber teamet med endeløse SD-er, og forklarer funksjonaliteten til brukeren og støtten samtidig. Som et resultat fungerer både Ops og utvikling, men klienten og virksomheten er misfornøyde: nye funksjoner setter seg fast. Det viser seg at DevOps ser ut til å eksistere, men det ser ikke ut til å eksistere.
Når det gjelder behovet for å implementere DevOps, sa Anton tydelig at dette direkte avhenger av virksomhetens omfang. Hvis det å betjene én klient i året gir selskapet en milliard, er ikke DevOps nødvendig (forutsatt at du ikke trenger å rulle ut nye endringer til denne klienten regelmessig). Alt er dekket av sjokolade. Men hvis virksomheten vokser og flere kunder dukker opp, må du overholde det. Som regel er det ingen kule Ops i selskapet i utgangspunktet. Først kutter vi produktet, og først da forstår vi at for at produktet skal fungere, må vi holde øye med serverne og overvåke forsyninger. Det er da Ops blir til. Det gjenstår å forstå at Ops, som en egen divisjon, vil begynne å sette opp en haug med barrierer for utvikling og alle leveranser vil begynne å stoppe opp. Det vil si at i dette tilfellet er DevOps-kulturen allerede relevant, men vi må ikke glemme den mørke siden.
Kilde: www.habr.com