Jag deltog nyligen i DevOpsForum 2019, värd av Logrocon. Vid denna konferens försökte deltagarna hitta lösningar och nya verktyg för effektiv interaktion mellan affärs- och utvecklings- och IT-tjänstespecialister.
Konferensen var en succé: det var verkligen många användbara rapporter, intressanta presentationsformat och mycket kommunikation med talarna. Och det är särskilt viktigt att ingen försökte sälja mig något, något som talare på stora konferenser har gjort sig skyldiga till på sistone.
Ett utdrag från tal från Raiffeisenbank, Alfastrakhovanie, Mango Telecoms erfarenhet av att implementera automation och andra detaljer under snittet.
Jag heter Yana, jag arbetar som testare, jag gör automation, samt DevOps, och jag älskar att gå på konferenser och möten. Under de senaste två åren har jag varit på Oleg Bunins konferenser (HighLoad++, TeamLead Conf), Jug-event (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Först och främst uppmärksammar jag konferensprogrammet. Jag tittar mindre på vad rapporten kommer att handla om, och mer på talaren. Även om rapporten visar sig vara mycket teknisk och intressant är det inte ett faktum att du kommer att kunna tillämpa några av de bästa metoderna från rapporten i ditt företag. Och då behöver du en högtalare.
Ljus i slutet av rörledningen vid Raiffeisenbank
Vanligtvis letar jag efter talare vid sidan av som intresserar mig. På DevOpsForum 2019 fångade en talare från Raiffeisenbank, Mikhail Bizhan, mitt intresse. Under sitt tal pratade han om hur de gradvis håller på att få sina team fast på DevOps, varför de behöver det och hur man säljer idén om DevOps-transformation till företag. Tja, i allmänhet pratade jag om hur man ser ljuset i slutet av rörledningen.
Mikhail Bizhan, chef för automation på Raiffeisenbank
Nu har de inte "DevOps" i sitt företag. Det vill säga han jobbar, men inte i alla lag. När de implementerar DevOps förlitar de sig på teamens beredskap, både när det gäller specifika ingenjörer, och när det gäller behovet av produkten och mognad på plattformen som denna produkt är byggd på. Misha berättade hur man förklarar för ett företag varför DevOps behövs.
Banksegmentet har flera tillväxtfaktorer: kostnader för tjänster och expansion av kundbasen. Att öka kostnaderna för tjänster är inte en särskilt bra drivkraft, men att växa kundbasen är motsatsen. Om konkurrenter släpper en objektivt cool produkt går alla kunder dit, sedan planar marknaden ut med tiden. Därför är introduktionen av nya produkter på marknaden och hastigheten på deras introduktion det viktigaste som bankerna fokuserar på. Det är precis vad DevOps är till för, och företag förstår detta.
Nästa viktiga anmärkning: DevOps minskar inte alltid tiden till marknaden. DevOps kan inte fungera ensamt, det är bara en del av processen att skapa och föra en produkt till marknaden från utveckling till produktion (från kod till kund). Men allt före koden är inte direkt relaterat till DevOps. Det vill säga marknadsförare kan studera marknaden i flera år och ägna hela livet åt att komma ikapp konkurrenterna. Det är nödvändigt att snabbt förstå vad kunden behöver och planera implementeringen av den eller den funktionen – ofta är det detta som inte räcker för att DevOps ska fungera och företaget ska nå sitt mål. Därför kom Raiffeisenbank först och främst överens med näringslivet om att det var nödvändigt att lära sig hur man använder DevOps. Automatisering för automatiseringens skull kommer inte att hjälpa mycket i kampen om nya kunder.
I allmänhet anser Misha att DevOps behöver implementeras, men klokt. Och vi måste vara beredda på det faktum att i början av omvandlingen kommer teamets produktivitet att sjunka, det kommer att tjäna mindre pengar, men då kommer det att vara motiverat.
Automatisering av testning hos Mango Telecom
En annan intressant rapport för mig som testare gavs av Egor Maslov från Mango Telecom. Presentationen kallades "Automatisering av hela testcykeln i ett SCRUM-team." Egor tror att DevOps skapades specifikt för SCRUM, men samtidigt är det ganska problematiskt att introducera DevOps i ett SCRUM-team. Detta beror på att SCRUM-teamet alltid kör någonstans, det finns ingen tid att distraheras av innovationer och bygga om processen. Problemet ligger också i det faktum att SCRUM inte innebär separation av underteam i teamet (testteam, utvecklingsteam och så vidare). Tja, dessutom, för att automatisera en befintlig process, behövs dokumentation, och i SCRUM finns det oftast ingen dokumentation helt - "produkten är viktigare än någon form av skrift."
Efter att ha bytt till SCRUM började testare rådgöra med utvecklare om hur man testar funktioner. Efter hand ökade funktionalitetsvolymen, det fanns ingen dokumentation och man började fånga en massa buggar i funktionaliteten som inte omfattades av tester och i allmänhet var det inte längre klart vem som testade den och när. I ett nötskal - förvirring och vacklande. Vi bestämde oss för att byta till testautomatisering. Men även då var det ett fullständigt misslyckande. De anställde outsourcade automationsspecialister som skrev på en stack okänd för interna testare. Ramverket för autotester fungerade förstås, men efter att outsourcarna slutade varade det i två veckor. Nästa var ett försök att införa autotestning nummer två. Det började med att allt behöver byggas inom företaget, på egen hand (rätt vektor: bygg upp kompetens internt), inom ramen för SCRUM, och skapa dokumentation i processen. Stapeln för automatisering bör vara lika med produktens stapel (här lägger jag till den, testa inte ditt JavaScript-projekt med något annat). I slutet av sprinten gjorde de en demo av hur autotestet fungerar med hela laget (nyttigt). Därmed ökade engagemanget från alla teammedlemmar i automatiseringsprocessen, liksom förtroendet för autotester och chansen att detta autotest definitivt kommer att användas (och inte kommer att kommenteras ut på en månad på grund av ständiga misslyckanden).
Förresten, på DevOpsForum 2019 fanns en öppen mikrofon - ett sedan länge känt och, enligt min mening, användbart format av tal. Du går runt så här, lyssnar på rapporter och bestämmer dig sedan för att på konferensen är det värt att diskutera ett visst ämne eller problem, dela med dig av relevant erfarenhet av att lösa problemet.
Jag noterade också att arrangörerna gjorde en ström av korta reportage. Varje rapport varar inte mer än 10 minuter, följt av frågor. På så sätt kan du ta upp många ämnen samtidigt och ställa frågor till talare som intresserar dig.
Mellan presentationerna gick jag runt i båsen hos konferenspartnerna och stal/vann en massa grejer. Åh, jag älskar utdelningen!
Rundabords- och DevOps-frågor med utvecklingsdirektören på Alfastrakhovanie
Glasyren på DevOpsForum 2019-tårtan för mig var den timslånga plenarsessionen med DevOps-experter. Fyra sessionsdeltagare bjöds in att titta på DevOps från olika vinklar: Anton Isanin (Alfastrakhovanie, utvecklingsdirektör), Nailya Zamashkina (Fintech Lab, operativ chef), Oleg Egorkin (Rostelecom, Agile coach) och Anton Martyanov (oberoende expert, tittade på DevOps ur affärsmässig synvinkel).
Experterna satte sig närmare folket och sedan började det hända saker: under en hel timme ställde deltagare från publiken sina frågor, och experterna tog rappen. Ibland blev det riktiga debatter. Frågorna var väldigt olika, till exempel: behövs DevOps ingenjörer överhuvudtaget, varför kan de inte utbildas till systemadministratörer, ska DevOps erbjudas alla, vad är dess värde osv.
Sedan pratade jag med Anton Isanin personligen. Vi diskuterade behovet av att ta med DevOps-kulturen till alla hem och avslöjade den mörka sidan av DevOps-transformationen.
Låt oss föreställa oss att alla gick samman och bestämde att DevOps behövs både av produkten och av verksamheten och teamet. Låt oss genomföra det. Allt löste sig. Vi andades ut. DevOps har fört oss närmare kunden, nu kan vi snabbt uppfylla alla hans önskemål. Som ett resultat har vi en stor Ops-avdelning med strikta regler och krav, och den hittar hela tiden defekter i produkten och skapar ett gäng förfrågningar. Dessutom tilldelas alla defekter statusen "brådskande", även om klienten oväntat ville färga knappen gul istället för grön. Projektet växer, antalet releaser växer och följaktligen antalet defekter och missförstånd av ny funktionalitet hos kunder. Ops anställer ytterligare 10 personer för att hålla jämna steg med att rapportera defekter, och Development anställer 15 till för att hänga med i att stänga dem. Och istället för att introducera nya funktioner arbetar teamet med oändliga SD:s, och förklarar funktionaliteten för användaren och supporten på samma gång. Som ett resultat fungerar både Ops och utveckling, men kunden och verksamheten är missnöjda: nya funktioner fastnar. Det visar sig att DevOps verkar existera, men det verkar inte existera.
Angående behovet av att implementera DevOps sa Anton tydligt att detta direkt beror på verksamhetens omfattning. Om att betjäna en kund om året ger företaget en miljard, behövs inte DevOps (förutsatt att du inte behöver rulla ut nya ändringar till denna klient regelbundet). Allt är täckt av choklad. Men om verksamheten växer och fler kunder dyker upp, måste du följa det. Som regel finns det inga coola Ops i företaget initialt. Först skär vi produkten, och först då förstår vi att för att produkten ska fungera måste vi hålla ett öga på servrarna och övervaka leveranser. Det är då Ops kommer till. Det återstår att förstå att Ops, som en separat division, kommer att börja sätta upp ett gäng hinder för utveckling och alla leveranser kommer att börja avstanna. Det vill säga, i det här fallet är DevOps-kulturen redan relevant, men vi får inte glömma dess mörka sida.
Källa: will.com