Jeg deltog for nylig i DevOpsForum 2019, hostet af Logrocon. På denne konference forsøgte deltagerne at finde løsninger og nye værktøjer til effektiv interaktion mellem forretning og udvikling og IT-servicespecialister.
Konferencen var en succes: der var rigtig mange nyttige rapporter, interessante præsentationsformater og en masse kommunikation med talerne. Og det er især vigtigt, at ingen forsøgte at sælge mig noget, noget som talere på store konferencer har gjort sig skyldige i på det seneste.
Et uddrag fra talerne fra Raiffeisenbank, Alfastrakhovanie, Mango Telecoms erfaring med implementering af automatisering og andre detaljer under skæringen.
Mit navn er Yana, jeg arbejder som tester, jeg laver automatisering, samt DevOps, og jeg elsker at gå til konferencer og møder. I løbet af de sidste to år har jeg været til Oleg Bunins konferencer (HighLoad++, TeamLead Conf), Jug events (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Først og fremmest gør jeg opmærksom på konferenceprogrammet. Jeg ser mindre på, hvad rapporten skal handle om, og mere på taleren. Selvom rapporten viser sig at være meget teknologisk og interessant, er det ikke et faktum, at du vil kunne anvende nogle af de bedste praksisser fra rapporten i din virksomhed. Og så skal du have en højttaler.
Lys for enden af rørledningen ved Raiffeisenbank
Normalt leder jeg efter højttalere på sidelinjen, der interesserer mig. På DevOpsForum 2019 fangede en taler fra Raiffeisenbank, Mikhail Bizhan, min interesse. I løbet af sin tale talte han om, hvordan de gradvist får deres hold tilsluttet DevOps, hvorfor de har brug for det, og hvordan man sælger ideen om DevOps-transformation til erhvervslivet. Nå, generelt talte jeg om, hvordan man ser lyset for enden af rørledningen.
Mikhail Bizhan, direktør for automatisering hos Raiffeisenbank
Nu har de ikke "DevOps" i deres virksomhed. Det vil sige, at han arbejder, men ikke på alle hold. Når de implementerer DevOps, er de afhængige af teamenes parathed, både med hensyn til specifikke ingeniører og med hensyn til produktets behov og modenheden af den platform, som dette produkt er bygget på. Misha fortalte, hvordan man forklarer en virksomhed, hvorfor DevOps er nødvendig.
Banksegmentet har flere vækstdrivere: omkostninger til tjenester og udvidelse af kundebasen. At øge omkostningerne ved tjenester er ikke en særlig god drivkraft, men at øge kundebasen er det modsatte. Hvis konkurrenter frigiver et objektivt sejt produkt, går alle kunder dertil, så jævner markedet sig over tid. Derfor er introduktionen af nye produkter til markedet og hastigheden af deres introduktion det vigtigste, som bankerne fokuserer på. Det er præcis, hvad DevOps er til, og virksomheder forstår dette.
Den næste vigtige note: DevOps reducerer ikke altid time to market. DevOps kan ikke fungere alene, det er blot en del af processen med at skabe og bringe et produkt til markedet fra udvikling til produktion (fra kode til kunde). Men alt før koden er ikke direkte relateret til DevOps. Det vil sige, at marketingfolk kan studere markedet i årevis og bruge hele deres liv på at indhente konkurrenterne. Det er nødvendigt hurtigt at forstå, hvad kunden har brug for og planlægge implementeringen af denne eller hin funktion – ofte er det det, der ikke er nok til, at DevOps fungerer, og virksomheden kan nå sit mål. Derfor var Raiffeisenbank først og fremmest enig med erhvervslivet i, at det var nødvendigt at lære at bruge DevOps. Automatisering for automatiseringens skyld vil ikke hjælpe meget i kampen om nye kunder.
Generelt mener Misha, at DevOps skal implementeres, men klogt. Og vi skal være forberedt på, at i begyndelsen af transformationen vil holdets produktivitet falde, det vil tjene færre penge, men så vil det være berettiget.
Automatisering af test hos Mango Telecom
En anden interessant rapport for mig som tester blev givet af Egor Maslov fra Mango Telecom. Præsentationen hed "Automatisering af den fulde testcyklus i et SCRUM-team." Egor mener, at DevOps blev skabt specifikt til SCRUM, men samtidig er det ret problematisk at introducere DevOps i et SCRUM-team. Dette sker, fordi SCRUM-teamet altid kører et sted, der er ikke tid til at blive distraheret af innovationer og genopbygge processen. Problemet ligger også i, at SCRUM ikke involverer adskillelse af underteams i teamet (testteam, udviklingsteam og så videre). For at automatisere en eksisterende proces er der desuden brug for dokumentation, og i SCRUM er der oftest ingen fuldstændig dokumentation - "produktet er vigtigere end en form for skrivning."
Efter at have skiftet til SCRUM begyndte testere at rådføre sig med udviklere om, hvordan man tester funktioner. Efterhånden steg mængden af funktionalitet, der var ingen dokumentation, og de begyndte at fange en masse fejl i funktionaliteten, som ikke var dækket af test, og generelt var det ikke længere klart, hvem der testede det og hvornår. I en nøddeskal - forvirring og vaklen. Vi besluttede at skifte til testautomatisering. Men selv dengang var der en fuldstændig fiasko. De hyrede outsourcede automatiseringsspecialister, som skrev på en stak, der ikke var kendt for interne testere. Rammerne for autotest virkede selvfølgelig, men efter at outsourcerne rejste, varede det i to uger. Dernæst var et forsøg på at indføre autotest nummer to. Det begyndte med, at alt skal bygges inde i virksomheden, på egen hånd (den rigtige vektor: opbyg ekspertise internt), inden for rammerne af SCRUM, og skabe dokumentation i processen. Stakken til automatisering skal være lig med produktets stak (her tilføjer jeg den, test ikke dit JavaScript-projekt med noget andet). I slutningen af spurten lavede de en demo af, hvordan autotesten fungerer med hele holdet (nyttigt). Dermed øgedes involveringen af alle teammedlemmer i automatiseringsprocessen, samt tilliden til autotests og chancen for, at denne autotest helt sikkert vil blive brugt (og ikke vil blive kommenteret ud om en måned på grund af konstante fejl).
Forresten, på DevOpsForum 2019 var der en åben mikrofon - et længe kendt og efter min mening brugbart format for taler. Man går sådan rundt, lytter til rapporter og beslutter så, at det på konferencen er værd at diskutere et bestemt emne eller problem, dele relevante erfaringer med at løse problemet.
Jeg lagde også mærke til, at arrangørerne lavede en strøm af korte rapporter. Hver rapport varer ikke mere end 10 minutter, efterfulgt af spørgsmål. På denne måde kan du dække mange emner på én gang og stille spørgsmål til talere, der interesserer dig.
Mellem præsentationerne gik jeg rundt i konferencepartnernes stande og stjal/vandt en masse ting. Åh, jeg elsker uddelingen!
Round table og DevOps-problemer med udviklingsdirektøren hos Alfastrakhovanie
Prikken over i'et på DevOpsForum 2019-kagen for mig var den timelange plenarsession med DevOps-eksperter. Fire sessionsdeltagere blev inviteret til at se på DevOps fra forskellige vinkler: Anton Isanin (Alfastrakhovanie, udviklingsdirektør), Nailya Zamashkina (Fintech Lab, driftsdirektør), Oleg Egorkin (Rostelecom, Agile coach) og Anton Martyanov (uafhængig ekspert, kiggede på DevOps fra et forretningsmæssigt synspunkt).
Eksperterne satte sig tættere på folket, og så begyndte der at ske ting: I en hel time stillede deltagere fra publikum deres spørgsmål, og eksperterne tog rappen. Nogle gange var der virkelige debatter. Spørgsmålene var meget forskellige, for eksempel: er der overhovedet brug for DevOps-ingeniører, hvorfor kan de ikke uddannes som systemadministratorer, skal DevOps tilbydes alle, hvad er dets værdi, og så videre.
Så talte jeg personligt med Anton Isanin. Vi diskuterede behovet for at bringe DevOps-kulturen til ethvert hjem og afslørede den mørke side af DevOps-transformationen.
Lad os forestille os, at alle tog sig sammen og besluttede, at DevOps er nødvendig både af produktet og af virksomheden og teamet. Lad os implementere det. Alt fungerede. Vi pustede ud. DevOps har bragt os tættere på kunden, nu kan vi hurtigt opfylde alle hans ønsker. Som følge heraf har vi en stor Ops-afdeling med strenge regler og krav, og den finder hele tiden fejl i produktet og skaber en masse forespørgsler. Desuden tildeles alle defekter status "haster", selvom klienten uventet ønskede at farve knappen gul i stedet for grøn. Projektet vokser, antallet af udgivelser vokser og dermed antallet af defekter og misforståelser af ny funktionalitet hos kunder. Ops ansætter 10 personer mere til at holde trit med rapportering af fejl, og udvikling ansætter 15 mere til at holde trit med at lukke dem. Og i stedet for at introducere nye funktioner, arbejder teamet med endeløse SD'er, der forklarer funktionaliteten for brugeren og support på samme tid. Som et resultat er både Ops og udvikling i gang, men klienten og forretningen er utilfredse: nye funktioner sætter sig fast. Det viser sig, at DevOps ser ud til at eksistere, men det ser ikke ud til at eksistere.
Med hensyn til behovet for at implementere DevOps, sagde Anton klart, at dette afhænger direkte af virksomhedens omfang. Hvis servicering af én kunde om året giver virksomheden en milliard, er DevOps ikke nødvendig (forudsat at du ikke behøver at udrulle nye ændringer til denne klient regelmæssigt). Alt er dækket af chokolade. Men hvis virksomheden vokser, og der dukker flere kunder op, så skal du overholde det. Som regel er der ingen fede Ops i virksomheden i første omgang. Først skærer vi produktet, og først derefter forstår vi, at for at produktet kan fungere, skal vi holde øje med serverne og overvåge forsyninger. Det er, når Ops bliver til. Det er stadig at forstå, at Ops, som en separat division, vil begynde at sætte en masse barrierer op for udvikling, og alle leverancer vil begynde at gå i stå. Det vil sige, at i dette tilfælde er DevOps-kulturen allerede relevant, men vi må ikke glemme dens mørke side.
Kilde: www.habr.com