Ek het onlangs DevOpsForum 2019 bygewoon, aangebied deur Logrocon. By hierdie konferensie het deelnemers probeer om oplossings en nuwe hulpmiddels te vind vir effektiewe interaksie tussen sake- en ontwikkelings- en inligtingstegnologiediensspesialiste.
Die konferensie was 'n sukses: daar was werklik baie nuttige verslae, interessante aanbiedingsformate en baie kommunikasie met die sprekers. En dit is veral belangrik dat niemand my iets probeer verkoop het nie, iets waaraan sprekers by groot konferensies hulle die afgelope tyd skuldig gemaak het.
'n Uittreksel uit die toesprake van Raiffeisenbank, Alfastrakhovanie, Mango Telecom se ervaring in die implementering van outomatisering en ander besonderhede onder die snit.
My naam is Yana, ek werk as 'n toetser, ek doen outomatisering, sowel as DevOps, en ek gaan graag na konferensies en ontmoetings. Oor die afgelope twee jaar was ek by Oleg Bunin se konferensies (HighLoad++, TeamLead Conf), Jug-geleenthede (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Eerstens vestig ek die aandag op die konferensieprogram. Ek kyk minder waaroor die verslag gaan handel, en meer na die spreker. Selfs al blyk die verslag baie tegnologies en interessant te wees, is dit nie 'n feit dat jy van die beste praktyke uit die verslag in jou onderneming sal kan toepas nie. En dan het jy 'n luidspreker nodig.
Lig aan die einde van die pyplyn by Raiffeisenbank
Gewoonlik soek ek na sprekers op die kantlyn wat my interesseer. By DevOpsForum 2019 het 'n spreker van Raiffeisenbank, Mikhail Bizhan, my belangstelling gevang. Tydens sy toespraak het hy gepraat oor hoe hulle hul spanne geleidelik aan DevOps vasgehaak kry, hoekom hulle dit nodig het, en hoe om die idee van DevOps-transformasie aan besigheid te verkoop. Wel, oor die algemeen het ek gepraat oor hoe om die lig aan die einde van die pyplyn te sien.
Mikhail Bizhan, direkteur van outomatisering by Raiffeisenbank
Nou het hulle nie “DevOps” in hul maatskappy nie. Dit wil sê, hy werk, maar nie in alle spanne nie. By die implementering van DevOps maak hulle staat op die gereedheid van die spanne, beide in terme van spesifieke ingenieurs, en in terme van die behoefte van die produk en die volwassenheid van die platform waarop hierdie produk gebou is. Misha het vertel hoe om aan 'n besigheid te verduidelik waarom DevOps nodig is.
Die banksegment het verskeie groeidrywers: koste van dienste en uitbreiding van die kliëntebasis. Die verhoging van die koste van dienste is nie 'n baie goeie drywer nie, maar om die kliëntebasis te laat groei is die teenoorgestelde. As mededingers 'n objektief koel produk vrystel, gaan alle klante daarheen, dan word die mark mettertyd gelyk. Daarom is die bekendstelling van nuwe produkte aan die mark en die spoed van hul bekendstelling die belangrikste ding waarop banke fokus. Dit is presies waarvoor DevOps is, en besighede verstaan dit.
Die volgende belangrike opmerking: DevOps verminder nie altyd die tyd om te bemark nie. DevOps kan nie alleen werk nie, dit is net deel van die proses om 'n produk te skep en na die mark te bring van ontwikkeling tot produksie (van kode tot kliënt). Maar alles voor die kode hou nie direk verband met DevOps nie. Dit wil sê, bemarkers kan die mark vir jare bestudeer en hul hele lewe spandeer om mededingers in te haal. Dit is nodig om vinnig te verstaan wat die kliënt nodig het en die implementering van hierdie of daardie kenmerk te beplan - dikwels is dit wat nie genoeg is vir DevOps om te werk en die maatskappy om sy doel te bereik nie. Daarom het Raiffeisenbank eerstens met besigheid ooreengekom dat dit nodig is om te leer hoe om DevOps te gebruik. Outomatisering ter wille van outomatisering sal nie veel help in die stryd om nuwe kliënte nie.
Oor die algemeen glo Misha dat DevOps geïmplementeer moet word, maar verstandig. En ons moet daarop voorbereid wees dat aan die begin van die transformasie die span se produktiwiteit sal daal, dit sal minder geld verdien, maar dan sal dit geregverdig wees.
Outomatisering van toetsing by Mango Telecom
Nog 'n interessante verslag vir my as 'n toetser is gegee deur Egor Maslov van Mango Telecom. Die aanbieding is genoem "Outomatisering van die volledige toetssiklus in 'n SCRUM-span." Egor glo dat DevOps spesifiek vir SCRUM geskep is, maar terselfdertyd is dit nogal problematies om DevOps in 'n SCRUM-span bekend te stel. Dit gebeur omdat die SCRUM-span altyd iewers heen hardloop, daar is nie tyd om deur innovasies afgelei te word en die proses te herbou nie. Die probleem lê ook daarin dat SCRUM nie die skeiding van subspanne in die span (toetsspan, ontwikkelingspan, ensovoorts) behels nie. Wel, buitendien, om 'n bestaande proses te outomatiseer, is dokumentasie nodig, en in SCRUM is daar meestal geen dokumentasie heeltemal nie - "die produk is belangriker as 'n soort skryfwerk."
Nadat hulle na SCRUM oorgeskakel het, het toetsers met ontwikkelaars begin konsulteer oor hoe om kenmerke te toets. Geleidelik het die volume van funksionaliteit toegeneem, daar was geen dokumentasie nie, en hulle het baie foute in die funksionaliteit begin opvang wat nie deur toetse gedek is nie en oor die algemeen was dit nie meer duidelik wie dit getoets het en wanneer nie. In 'n neutedop - verwarring en swaai. Ons het besluit om oor te skakel na toetsoutomatisering. Maar selfs toe was daar 'n volslae mislukking. Hulle het uitgekontrakteerde outomatiseringspesialiste gehuur wat op 'n stapel geskryf het wat onbekend is aan interne toetsers. Die raamwerk vir outotoetse het natuurlik gewerk, maar nadat die uitkontrakteurs weg is, het dit vir twee weke geduur. Volgende was 'n poging om outotoetsing nommer twee in te voer. Dit het begin met die feit dat alles binne die maatskappy gebou moet word, op jou eie (die regte vektor: bou kundigheid intern op), binne die raamwerk van SCRUM, en skep dokumentasie in die proses. Die stapel vir outomatisering moet gelyk wees aan die stapel van die produk (hier voeg ek dit by, moenie jou JavaScript-projek met enigiets anders toets nie). Aan die einde van die naelloop het hulle 'n demonstrasie gedoen van hoe die outotoets werk met die hele span (nuttig). So het die betrokkenheid van alle spanlede by die outomatiseringsproses toegeneem, asook vertroue in outotoetse en die kans dat hierdie outotoets beslis gebruik gaan word (en nie oor 'n maand kommentaar gelewer sal word nie weens voortdurende mislukkings).
Terloops, by DevOpsForum 2019 was daar 'n oop mikrofoon - 'n lank bekende en, na my mening, nuttige toesprakeformaat. Jy loop so rond, luister na berigte en besluit dan dat dit by die konferensie die moeite werd is om 'n sekere onderwerp of probleem te bespreek, en relevante ervaring te deel om die probleem op te los.
Ek het ook opgemerk dat die organiseerders 'n stroom kort verslae gemaak het. Elke verslag duur nie meer as 10 minute nie, gevolg deur vrae. Op hierdie manier kan jy baie onderwerpe tegelyk dek en vrae vra aan sprekers wat jou interesseer.
Tussen aanbiedings deur het ek by die konferensievennote se hokkies rondgeloop en baie goed gesteel/gewen. Eh, ek is mal oor die uitdeelstuk!
Tafelronde en DevOps-kwessies met die ontwikkelingsdirekteur by Alfastrakhovanie
Die kersie op die DevOpsForum 2019-koek vir my was die uurlange voltallige sessie met DevOps-kundiges. Vier sessiedeelnemers is genooi om na DevOps vanuit verskillende hoeke te kyk: Anton Isanin (Alfastrakhovanie, ontwikkelingsdirekteur), Nailya Zamashkina (Fintech Lab, bedryfsdirekteur), Oleg Egorkin (Rostelecom, Agile-afrigter) en Anton Martyanov (onafhanklike kenner, het na DevOps gekyk vanuit 'n besigheidsoogpunt).
Die kenners het nader aan die mense gaan sit en toe begin dinge gebeur: ’n hele uur lank het deelnemers uit die gehoor hul vrae gevra, en die kenners het die rap gevat. Soms was daar werklike debatte. Die vrae was byvoorbeeld baie anders: is DevOps-ingenieurs hoegenaamd nodig, hoekom kan hulle nie as stelseladministrateurs opgelei word nie, moet DevOps aan almal gebied word, wat is die waarde daarvan, ensovoorts.
Toe het ek persoonlik met Anton Isanin gepraat. Ons het die behoefte bespreek om die DevOps-kultuur na elke huis te bring en die donker kant van DevOps-transformasie onthul.
Kom ons stel ons voor dat almal bymekaar gekom het en besluit het dat DevOps beide deur die produk en deur die besigheid en die span nodig is. Kom ons gaan implementeer dit. Alles het uitgewerk. Ons het uitasem. DevOps het ons nader aan die kliënt gebring, nou kan ons vinnig aan al sy wense voldoen. Gevolglik het ons 'n groot Ops-afdeling met streng regulasies en vereistes, en dit vind voortdurend defekte in die produk en skep 'n klomp versoeke. Boonop word alle gebreke die "dringende" status toegeken, selfs al wou die kliënt onverwags die knoppie geel in plaas van groen kleur. Die projek groei, die aantal vrystellings groei en dienooreenkomstig die aantal defekte en misverstande van nuwe funksionaliteit deur kliënte. Ops stel nog 10 mense aan om tred te hou met die aanmelding van gebreke, en ontwikkeling neem nog 15 aan om tred te hou met die sluiting daarvan. En in plaas daarvan om nuwe kenmerke bekend te stel, werk die span met eindelose SD's, wat terselfdertyd die funksionaliteit aan die gebruiker en ondersteuning verduidelik. As gevolg hiervan werk beide Ops en ontwikkeling, maar die kliënt en besigheid is ontevrede: nuwe funksies sit vas. Dit blyk dat DevOps blyk te bestaan, maar dit lyk nie of dit bestaan nie.
Met betrekking tot die behoefte om DevOps te implementeer, het Anton duidelik gestel dat dit direk afhang van die omvang van die besigheid. As die diens van een kliënt per jaar die maatskappy 'n miljard bring, is DevOps nie nodig nie (mits jy nie gereeld nuwe veranderinge aan hierdie kliënt hoef uit te voer nie). Alles is bedek met sjokolade. Maar as die besigheid groei en meer kliënte verskyn, dan moet jy daaraan voldoen. As 'n reël is daar aanvanklik geen cool Ops in die maatskappy nie. Eers sny ons die produk, en eers dan verstaan ons dat ons 'n ogie oor die bedieners moet hou en voorraad moet monitor om die produk te laat werk. Dit is wanneer Ops tot stand kom. Dit moet nog verstaan word dat Ops, as 'n aparte afdeling, 'n klomp hindernisse vir ontwikkeling sal begin opstel en alle aflewerings sal begin staak. Dit wil sê, in hierdie geval is die DevOps-kultuur reeds relevant, maar ons moet nie van die donker kant daarvan vergeet nie.
Bron: will.com