Jag deltog nyligen i DevOpsForum 2019, som anordnades av Logrocon. PÄ denna konferens försökte deltagarna hitta lösningar och nya verktyg för effektiv samverkan mellan företag och utvecklare samt IT-specialister.
Konferensen var lyckad: det fanns verkligen mÄnga nyttiga förelÀsningar, intressanta format och massor av kommunikation med talarna. Och sÀrskilt viktigt var att ingen försökte sÀlja mig nÄgot, vilket har blivit vanligt pÄ stora konferenser pÄ senare tid.
Sammanfattning av förelÀsningar frÄn Raiffeisenbanken, Alfa Insurance, erfarenheter frÄn Mango Telecom om implementering av automatisering och andra detaljer under kat.
Jag heter Yana, jag arbetar som testare, sysslar med automatisering, samt DevOps och Àlskar att gÄ pÄ konferenser och meetups. Under de senaste tvÄ Ären har jag varit pÄ konferenser som Oleg Bunins (HighLoad++, TeamLead Conf), pÄ evenemang som Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Det första jag lĂ€gger mĂ€rke till Ă€r konferensprogrammet. I mindre utstrĂ€ckning ser jag pĂ„ vad som kommer att diskuteras, i större utstrĂ€ckning pĂ„ talaren. Ăven om förelĂ€sningen visar sig vara mycket teknisk och intressant, Ă€r det inte sĂ€kert att du kan tillĂ€mpa nĂ„gra best practices frĂ„n förelĂ€sningen i ditt eget företag. DĂ„ behövs en talare.
Ljus i slutet av pipeline i Raiffeisenbanken
Vanligtvis jagar jag intressanta talare i korridorerna. PÄ DevOpsForum 2019 föll en talare, Mikhail Bijan frÄn Raiffeisenbanken, inom mitt intresseomrÄde. Under sin presentation berÀttade han hur de stegvis introducerar sina team i DevOps, varför de behöver det och hur man sÀljer idén om DevOps-transformation till företaget. Dessutom pratade han om hur man ser ljuset i slutet av pipelinen.
Mikhail Bijan, chef för automatisering pÄ Raiffeisenbanken
Just nu har de inte «Àkta DevOps» i företaget. Det vill sÀga, det Àr Àkta, men inte i alla team. Vid implementeringen av DevOps lutar de sig mot teamens beredskap, bÄde nÀr det gÀller specifika ingenjörer, samt produktens behov och mognaden av den plattform som produkten Àr byggd pÄ. Misha berÀttade hur man förklarar för företaget varför DevOps behövs.
Banksektorn har flera tillvĂ€xtdrivkrafter: kostnaden för tjĂ€nster och utvidgningen av kundbasen. Ăkningen av tjĂ€nstekostnader Ă€r inte en sĂ€rskilt bra drivkraft, men tillvĂ€xten av kundbasen Ă€r det. Om konkurrenterna slĂ€pper en objektivt bra produkt, kommer alla kunder att vĂ€nda sig dit, och med tiden jĂ€mnar marknaden ut sig. DĂ€rför Ă€r det frĂ€mst produktlansering och hastigheten pĂ„ dessa lanseringar som bankerna fokuserar pĂ„. Just för detta behövs DevOps, och företagen förstĂ„r detta.
NĂ€sta viktiga observation: DevOps minskar inte alltid time to market. DevOps kan inte fungera ensam, det Ă€r bara en del av processen för att skapa och lansera en produkt pĂ„ marknaden, frĂ„n utveckling till produktion (frĂ„n kod till kund). Men allt som före kodningen inte har nĂ„got direkt att göra med DevOps. Det betyder att marknadsförare kan studera marknaden i Ă„ratal och fortfarande jaga efter konkurrenter. Det Ă€r viktigt att snabbt förstĂ„ vad kunden behöver och planera för genomförandet av en viss funktion â ofta Ă€r det just detta som saknas för att DevOps ska fungera och företaget ska nĂ„ sina mĂ„l. DĂ€rför har Raiffeizenbank, först och frĂ€mst, kommit överens med verksamheten om att lĂ€ra sig anvĂ€nda DevOps. Automatisering för automatiseringens skull hjĂ€lper inte mycket i kampen om nya kunder.
Sammanfattningsvis anser Misha att DevOps bör införas, men med eftertÀnksamhet. Och man mÄste vara beredd pÄ att produktiviteten i teamet kommer att falla i början av transformationen, de kommer att tjÀna mindre pengar, men senare kommer det att löna sig.
Automatisering av testning pÄ "Mango Telekom"
Ett annat intressant föredrag för mig som testare höll Egor Maslov frÄn "Mango Telecom". Presentationen var titulerad "Automatisering av hela testcykeln i SCRUM-teamet". Egor anser att DevOps Àr skapat just för SCRUM, men samtidigt Àr det ganska problematiskt att införa DevOps i ett SCRUM-team. Detta beror pÄ att SCRUM-teamet alltid Àr i rörelse och har inte tid att avbryta för nyheter och omstrukturera processen. Problemet Àr ocksÄ att SCRUM inte förutsÀtter att det finns underlag för att skapa sub-team (testteam, utvecklarteam, och sÄ vidare). Dessutom behövs dokumentation för att automatisera den befintliga processen, och i SCRUM saknas det oftast helt - "produkten Àr viktigare Àn nÄgot skrivande".
Efter övergÄngen till SCRUM började testarna rÄdgöra med utvecklarna om hur man skulle testa funktioner. Gradvis ökade mÀngden funktionalitet, dokumentationen saknades, och de började hitta mÄnga buggar i den funktionalitet som inte hade testats och i allmÀnhet var det oklart vem och nÀr som testade den. Kort sagt - kaos. De beslutade att gÄ över till automatisering av testningen. Men Àven dÄ intrÀffade ett totalt misslyckande. De tog in externa specialister för automatisering, som skrev pÄ en stack som var okÀnd för de interna testarna. Ramverket för automatiserade tester fungerade sjÀlvklart, men efter att de externa hade lÀmnat, överlevde det i tvÄ veckor. Sedan gjorde de ett försök med automatiserad testning nummer tvÄ. Det började med att allt skulle byggas internt, med egna resurser (rÀtt vektor: bygg upp expertisen internt), inom ramen för SCRUM, och under processen skapa dokumentation. Stacken för automatisering mÄste vara densamma som produktstacken (och hÀr hÄller jag verkligen med, testa inte projektet pÄ JavaScript med nÄgot annat). I slutet av sprinten hade de en demo av hur automatiska tester fungerade, med hela teamet delaktigt (mycket nyttigt). PÄ sÄ sÀtt ökade engagemanget i automatiseringsprocessen för alla teammedlemmar, samt förtroendet för de automatiska testerna och chansen att de verkligen skulle anvÀndas (och inte skulle kommenteras bort efter en mÄnad pÄ grund av stÀndiga misslyckanden).
För övrigt fanns det en öppen mikrofon pĂ„ DevOpsForum 2019 â en lĂ€nge etablerad och, enligt mig, nyttig format för presentationer. Man gĂ„r omkring, lyssnar pĂ„ förelĂ€sningar, och sedan bestĂ€mmer man sig för att diskutera ett visst Ă€mne eller problem inom ramen för konferensen, eller dela relevant erfarenhet av att lösa en uppgift.
Jag noterade ocksÄ att arrangörerna hade lagt upp en serie korta förelÀsningar. Varje förelÀsning varade högst 10 minuter, följt av frÄgor. PÄ sÄ sÀtt kan mÄnga Àmnen tÀckas direkt och man kan stÀlla frÄgor till de talare som man blev intresserad av.
Mellan förelĂ€sningarna tog jag en promenad bland partnernas montrar och snappade upp/vann mycket diverse grejer. Ă
h, jag Àlskar giveaways!
Rundabordssamtal och frÄgor om DevOps med utvecklingschefen pÄ Alfastrahovanye.
Kring denna tÄrta av DevOpsForum 2019 var den timmeslÄnga plenarsessionen med DevOps-experter som verkligen höjdaren för mig. Fyra deltagare inbjudna till sessionen skulle belysa DevOps frÄn olika hÄll: Anton Isanin (Alfastrahovanye, utvecklingschef), Nailya Zamashkina (Fintech Lab, operativ chef), Oleg Egorkin (Rostelekom, Agile-coach) och Anton Martyanov (oavhÀngig expert, som sÄg pÄ DevOps ur ett affÀrsperspektiv).
Experterna satte sig nÀrmare publiken och dÀr började det: under en timme stÀllde deltagarna frÄgor frÄn salen, och experterna svarade. Ibland blev det riktiga debatter. FrÄgorna var vÀldigt olika, till exempel: behövs DevOps-ingenjörer överhuvudtaget, varför kan man inte odla dem frÄn systemadministratörer, borde alla erbjudas DevOps, vad Àr dess vÀrde och sÄ vidare.
Sedan pratade jag personligen med Anton Isanin. Vi diskuterade behovet av att sprida DevOps-kulturen till varje hem och avslöjade den mörka sidan av DevOps-transformation.
FörestÀll dig att alla har samlats och beslutat att DevOps behövs för bÄde produkten, företaget och teamet. Implementationerna började. Allt gick bra. Vi andades ut. DevOps gjorde oss nÀrmare kunden, nu kan vi snabbt uppfylla alla deras önskemÄl. Resultatet Àr en stor Ops-avdelning med strikta regler och krav, och den producerar stÀndigt defekter pÄ produkten och skapar en massa Àrenden. Och alla defekter har prioritet "brÄdskande", Àven om kunden plötsligt ville mÄla en knapp gul istÀllet för grön. Projektet vÀxer, antalet releaser ökar och dÀrmed Àven antalet defekter och kundernas oförstÄelse för den nya funktionaliteten. Ops anstÀller 10 personer för att hinna rapportera defekter, och utvecklingen anstÀller 15 för att hinna stÀnga dem. IstÀllet för att implementera nya funktioner arbetar teamet med oÀndliga SD:er, förklarar funktionaliteten för anvÀndaren och supporten. Resultatet Àr att bÄde Ops och utveckling Àr sysselsatta, men kunden och företaget Àr missnöjda: nya funktioner fastnar. Det verkar som att DevOps finns, men ÀndÄ inte.
AngĂ„ende behovet av att införa DevOps pĂ„pekade Anton entydigt att det direkt beror pĂ„ verksamhetens omfattning. Om service för en kund per Ă„r ger företaget en miljard â behövs inte DevOps (förutsatt att du inte behöver rulla ut nya Ă€ndringar regelbundet för denna kund). Allt gĂ„r bra. Men om företaget vĂ€xer och fler kunder tillkommer, dĂ„ mĂ„ste man anpassa sig. Vanligtvis finns det inte en gedigen Ops-avdelning i företaget frĂ„n början. Först utvecklar vi produkten, och först dĂ€refter inser vi att för att produkten ska fungera, mĂ„ste vi hĂ„lla koll pĂ„ leveranserna. DĂ„ uppstĂ„r Ops. Det kvarstĂ„r att förstĂ„ att Ops, som en separat avdelning, kommer att sĂ€tta upp mĂ„nga hinder för utvecklingen, och alla leveranser kommer att börja fastna. SĂ„ i detta fall Ă€r DevOps-kulturen redan relevant, men man fĂ„r inte glömma dess mörka sida. servrar, övervaka leveranserna. DĂ„ blir det tydligt att Ops, som en separat enhet, kommer att börja stĂ€lla upp en massa hinder för utvecklingen och alla leveranser kommer att kunna stanna av. I detta fall Ă€r DevOps-kulturen redan aktuellt, men vi fĂ„r inte glömma den mörka sidan av den.
KĂ€lla: habr.com
