Osallistuin äskettäin Logroconin isännöimään DevOpsForumiin 2019. Konferenssissa osallistujat yrittivät löytää ratkaisuja ja uusia työkaluja tehokkaaseen vuorovaikutukseen liiketoiminnan ja kehitys- ja tietotekniikan palveluasiantuntijoiden välillä.
Konferenssi oli menestys: siellä oli todella paljon hyödyllisiä raportteja, mielenkiintoisia esitysmuotoja ja paljon keskustelua puhujien kanssa. Ja erityisen tärkeää on, ettei kukaan yrittänyt myydä minulle mitään, mihin isojen konferenssejen puhujat ovat syyllistyneet viime aikoina.
Ote Raiffeisenbankin puheista, Alfastrakhovanie, Mango Telecomin kokemus automaation toteuttamisesta ja muista leikkauksen alla olevista yksityiskohdista.
Nimeni on Yana, työskentelen testaajana, teen automaatiota sekä DevOpsia ja tykkään käydä konferensseissa ja tapaamisissa. Viimeisen kahden vuoden aikana olen ollut Oleg Buninin konferensseissa (HighLoad++, TeamLead Conf), Jug-tapahtumissa (Heisenbug, JPoint), TestCon Moskovassa, DevOps Pro Moscowissa, Big Data Moscowissa.
Ensinnäkin kiinnitän huomion konferenssin ohjelmaan. Katson vähemmän sitä, mistä mietinnössä on kyse, vaan enemmän puhujaa. Vaikka raportti osoittautuukin erittäin tekniseksi ja kiinnostavaksi, ei ole tosiasia, että pystyt soveltamaan joitain raportin parhaista käytännöistä yrityksessäsi. Ja sitten tarvitset kaiuttimen.
Valoa putkilinjan päässä Raiffeisenbankissa
Yleensä etsin kaiuttimia sivusta, jotka kiinnostavat minua. DevOpsForumissa 2019 kiinnostukseni sai Raiffeisenbankin puhuja Mikhail Bizhan. Puheessaan hän puhui siitä, kuinka he vähitellen saavat tiiminsä koukkuun DevOpsiin, miksi he tarvitsevat sitä ja kuinka myydä idea DevOps-muutoksesta liiketoiminnalle. No, yleensä, puhuin siitä, kuinka nähdä valo putkilinjan päässä.
Mikhail Bizhan, Raiffeisenbankin automaatiojohtaja
Nyt heillä ei ole "DevOpsia" yrityksessään. Eli hän työskentelee, mutta ei kaikissa ryhmissä. DevOpsia ottaessaan he luottavat tiimien valmiuteen sekä tiettyjen insinöörien suhteen että tuotteen tarpeiden ja sen alustan kypsyyden suhteen, jolle tämä tuote on rakennettu. Misha kertoi kuinka selittää yritykselle, miksi DevOpsia tarvitaan.
Pankkisegmentillä on useita kasvutekijöitä: palveluiden kustannukset ja asiakaskunnan laajentaminen. Palvelukustannusten nostaminen ei ole kovin hyvä tekijä, mutta asiakaskunnan kasvattaminen on päinvastoin. Jos kilpailijat julkaisevat objektiivisesti hienon tuotteen, kaikki asiakkaat menevät sinne, niin ajan myötä markkinat tasoittuvat. Siksi uusien tuotteiden tuominen markkinoille ja niiden markkinoilletulon nopeus on tärkein asia, johon pankit keskittyvät. Juuri tätä varten DevOps on tarkoitettu, ja yritykset ymmärtävät tämän.
Seuraava tärkeä huomautus: DevOps ei aina lyhennä markkinoilletuloaikaa. DevOps ei voi toimia yksin, se on vain osa prosessia, jossa tuote luodaan ja tuodaan markkinoille kehityksestä tuotantoon (koodista asiakkaalle). Mutta kaikki ennen koodia ei liity suoraan DevOpsiin. Toisin sanoen markkinoijat voivat tutkia markkinoita vuosia ja viettää koko elämänsä kilpailijoiden kuromisessa. On tarpeen ymmärtää nopeasti, mitä asiakas tarvitsee, ja suunnitella tämän tai toisen ominaisuuden käyttöönotto - usein tämä ei riitä, jotta DevOps toimisi ja yritys saavuttaa tavoitteensa. Siksi Raiffeisenbank oli ensinnäkin samaa mieltä yritysten kanssa siitä, että DevOpsia oli opeteltava käyttämään. Automaatio automaation vuoksi ei juurikaan auta taistelussa uusista asiakkaista.
Yleisesti ottaen Misha uskoo, että DevOps on otettava käyttöön, mutta viisaasti. Ja meidän on varauduttava siihen, että muutoksen alussa joukkueen tuottavuus laskee, se ansaitsee vähemmän rahaa, mutta sitten se on perusteltua.
Mango Telecomin testauksen automatisointi
Toisen mielenkiintoisen raportin minulle testaajana antoi Egor Maslov Mango Telecomista. Esityksen nimi oli "Täyden testaussyklin automatisointi SCRUM-tiimissä". Egor uskoo, että DevOps on luotu nimenomaan SCRUMia varten, mutta samaan aikaan DevOpsin tuominen SCRUM-tiimiin on melko ongelmallista. Tämä johtuu siitä, että SCRUM-tiimi on aina käynnissä jossain, ei ole aikaa häiritä innovaatioita ja rakentaa prosessia uudelleen. Ongelma piilee myös siinä, että SCRUM ei sisällä alaryhmien erottamista tiimissä (testaustiimi, kehitystiimi ja niin edelleen). No, lisäksi olemassa olevan prosessin automatisoimiseksi tarvitaan dokumentaatiota, ja SCRUMissa ei useimmiten ole dokumentaatiota kokonaan - "tuote on tärkeämpi kuin jonkinlainen kirjoitus."
Vaihdettuaan SCRUMiin testaajat alkoivat neuvotella kehittäjien kanssa ominaisuuksien testaamisesta. Pikkuhiljaa toiminnallisuuden määrä kasvoi, dokumentaatiota ei ollut ja toiminnallisuudesta alettiin havaita paljon bugeja, jotka eivät olleet testeissä ja yleensäkään ei ollut enää selvää, kuka sen testasi ja milloin. Pähkinänkuoressa - hämmennystä ja horjumista. Päätimme siirtyä testausautomaatioon. Mutta silloinkin tapahtui täydellinen epäonnistuminen. He palkkasivat ulkoistettuja automaatioasiantuntijoita, jotka kirjoittivat pinoon, jota talon testaajat eivät tunteneet. Automaattitestien kehys tietysti toimi, mutta ulkoistajien lähdön jälkeen se kesti kaksi viikkoa. Seuraavaksi yritettiin ottaa käyttöön automaattinen testaus numero kaksi. Se alkoi siitä, että kaikki on rakennettava yrityksen sisällä, itse (oikea vektori: hanki sisäinen asiantuntemus), SCRUMin puitteissa ja luoda dokumentaatiota prosessissa. Automaatiopinon tulee olla yhtä suuri kuin tuotteen pino (tähän lisään sen, älä testaa JavaScript-projektiasi millään muulla). Sprintin lopussa he tekivät demon siitä, kuinka automaattinen testi toimii koko tiimin kanssa (hyödyllinen). Näin ollen kaikkien tiimin jäsenten osallistuminen automaatioprosessiin kasvoi, samoin kuin luottamus autotesteihin ja mahdollisuus, että tämä autotesti tulee varmasti käyttöön (eikä sitä kommentoida kuukaudessa jatkuvien vikojen takia).
Muuten, DevOpsForumissa 2019 oli avoin mikrofoni - kauan tunnettu ja mielestäni hyödyllinen puhemuoto. Kävelet näin, kuuntelet raportteja ja päätät sitten, että konferenssissa kannattaa keskustella tietystä aiheesta tai ongelmasta ja jakaa asiaankuuluvia kokemuksia ongelman ratkaisemisesta.
Huomasin myös, että järjestäjät tekivät virran lyhyitä raportteja. Jokainen raportti kestää enintään 10 minuuttia, ja sen jälkeen esitetään kysymyksiä. Näin voit käsitellä useita aiheita kerralla ja esittää kysymyksiä sinua kiinnostaville puhujille.
Esitysten välillä kiertelin konferenssikumppanien kopeissa ja varastin/voitin paljon tavaraa. Oi, rakastan monistetta!
Pyöreän pöydän ja DevOps-ongelmat Alfastrakhovanien kehitysjohtajan kanssa
Kirsteenä DevOpsForum 2019 -kakun päällä minulle oli tunnin mittainen täysistunto DevOps-asiantuntijoiden kanssa. Neljä istunnon osallistujaa kutsuttiin katsomaan DevOpsia eri näkökulmista: Anton Isanin (Alfastrakhovanie, kehitysjohtaja), Nailya Zamashkina (Fintech Lab, käyttöjohtaja), Oleg Egorkin (Rostelecom, ketterä valmentaja) ja Anton Martyanov (riippumaton asiantuntija, katseli DevOpsia) liiketoiminnan näkökulmasta).
Asiantuntijat istuutuivat lähemmäs ihmisiä ja sitten alkoi tapahtua: kokonaisen tunnin ajan yleisön joukossa oli kysymyksiä ja asiantuntijat ottivat rapin. Joskus käytiin oikeita keskusteluja. Kysymykset olivat hyvin erilaisia, esimerkiksi: tarvitaanko DevOps-insinöörejä ollenkaan, miksi heitä ei voi kouluttaa järjestelmänvalvojiksi, pitäisikö DevOpsia tarjota kaikille, mikä sen arvo on jne.
Sitten puhuin Anton Isaninin kanssa henkilökohtaisesti. Keskustelimme tarpeesta tuoda DevOps-kulttuuri jokaiseen kotiin ja paljastimme DevOps-muutoksen pimeän puolen.
Kuvitellaan, että kaikki kokoontuivat ja päättivät, että DevOpsia tarvitaan sekä tuotteelle että liiketoiminnalle ja tiimille. Mennään toteuttamaan se. Kaikki toimi. Hengitimme ulos. DevOps on tuonut meidät lähemmäksi asiakasta, nyt voimme toteuttaa nopeasti kaikki hänen toiveensa. Tästä johtuen meillä on suuri Ops-osasto, jolla on tiukat määräykset ja vaatimukset, ja se löytää jatkuvasti tuotteessa vikoja ja tekee joukon pyyntöjä. Lisäksi kaikki viat saavat "kiireellisen" tilan, vaikka asiakas olisi odottamatta halunnut värjätä painikkeen keltaiseksi vihreän sijaan. Projekti kasvaa, julkaisujen määrä kasvaa ja vastaavasti asiakkaiden uusien toimintojen vikojen ja väärinkäsitysten määrä. Ops palkkaa 10 henkilöä lisää raportoimaan vioista, ja kehitystyö palkkaa 15 henkilöä lisäämään niiden sulkemista. Ja sen sijaan, että esittelemme uusia ominaisuuksia, tiimi työskentelee loputtomien SD:iden kanssa, selittää toiminnallisuuden käyttäjälle ja tuen samanaikaisesti. Tämän seurauksena sekä toiminnot että kehitys toimivat, mutta asiakas ja yritys ovat tyytymättömiä: uudet ominaisuudet juuttuvat. Osoittautuu, että DevOps näyttää olevan olemassa, mutta sitä ei näytä olevan olemassa.
DevOpsin käyttöönoton tarpeesta Anton totesi selvästi, että tämä riippuu suoraan liiketoiminnan laajuudesta. Jos yhden asiakkaan palveleminen vuodessa tuo yritykselle miljardin, DevOpsia ei tarvita (edellyttäen, että sinun ei tarvitse tehdä uusia muutoksia tälle asiakkaalle säännöllisesti). Kaikki on peitetty suklaalla. Mutta jos liiketoiminta kasvaa ja asiakkaita tulee lisää, sinun on noudatettava vaatimuksia. Yleensä yhtiössä ei aluksi ole siistejä oppaita. Ensin leikkaamme tuotteen ja vasta sitten ymmärrämme, että jotta tuote toimisi, meidän on pidettävä silmällä palvelimia ja valvottava tarvikkeita. Silloin Ops syntyy. On vielä ymmärrettävä, että Ops, erillisenä divisioonana, alkaa asettaa esteitä kehitykselle ja kaikki toimitukset alkavat pysähtyä. Eli tässä tapauksessa DevOps-kulttuuri on jo relevantti, mutta emme saa unohtaa sen pimeää puolta.
Lähde: will.com