Mitä IT-yritykseltä vaaditaan menestyäkseen vuonna 2019? Konferensseissa ja tapaamisissa luennoitsijat sanovat paljon kovia sanoja, joita normaali ihminen ei aina ymmärrä. Taistelu käyttöönottoajasta, mikropalveluista, monoliitista luopumisesta, DevOps-muunnoksista ja paljon, paljon muuta. Jos hylkäämme sanallisen kauneuden ja puhumme suoraan ja venäjäksi, kaikki tulee yksinkertaiseen teesiin: tee korkealaatuinen tuote ja tee se mukavasti tiimille.
Jälkimmäisestä on tullut erittäin tärkeä. Yritys on vihdoin tullut siihen tulokseen, että mukava kehitysprosessi lisää tuottavuutta, ja jos kaikki on debuggoitu ja toimii kuin kello, se antaa myös liikkumavaraa kriittisissä tilanteissa. Olipa kerran tämän liikkeen vuoksi eräs älykäs henkilö keksi varmuuskopiot, mutta ala kehittyy, ja tulimme DevOps-insinööreihin - ihmisiin, jotka muuttavat kehityksen ja ulkoisen infrastruktuurin välisen vuorovaikutuksen joksikin riittäväksi ja sopivaksi. ei liity shamanismiin.
Tämä koko "modulaarinen" tarina on ihana, mutta... Sattui niin, että osa järjestelmänvalvojista nimettiin äkillisesti DevOpsiksi ja DevOps-insinööreiltä itseltään alettiin vaatia ainakin telepatian ja selvänäköisyyden taitoja.
Ennen kuin puhumme infrastruktuurin tarjoamisen nykyaikaisista ongelmista, määritellään, mitä tarkoitamme tällä termillä. Tällä hetkellä tilanne on kehittynyt niin, että olemme saavuttaneet tämän käsitteen kaksinaisuuden: infrastruktuuri voi olla ehdollisesti ulkoista ja ehdollisesti sisäistä.
Ulkoisella infrastruktuurilla tarkoitetaan kaikkea, mikä varmistaa tiimin kehittämän palvelun tai tuotteen toimivuuden. Nämä ovat sovellus- tai verkkosivustopalvelimia, hosting- ja muita palveluita, jotka varmistavat tuotteen toimivuuden.
Sisäiseen infrastruktuuriin kuuluvat palvelut ja laitteet, joita käyttävät kehitystiimi itse ja muut työntekijät, joita on yleensä paljon. Nämä ovat kooditallennusjärjestelmien sisäisiä palvelimia, paikallisesti käyttöön otettu tehtävähallinta ja kaikki, kaikki, kaikki, mitä yrityksen intranetissä on.
Mitä järjestelmänvalvoja tekee yrityksessä? Tämän yrityksen intranetin hallintatyön lisäksi se kantaa usein taloudellisten huolenaiheiden taakkaa toimistolaitteiden toimivuuden varmistamisesta. Ylläpitäjä on sama kaveri, joka raahaa nopeasti takahuoneesta käyttövalmiin uuden järjestelmäyksikön tai ylimääräisen kannettavan tietokoneen, antaa tuoreen näppäimistön ja ryömii nelijalkain toimistojen läpi Ethernet-kaapelia venytellen. Järjestelmänvalvoja on paitsi sisäisten ja ulkoisten palvelimien paikallinen omistaja ja hallitsija, myös yritysjohtaja. Kyllä, jotkut järjestelmänvalvojat voivat työskennellä vain järjestelmätasolla ilman laitteistoa. Ne tulisi erottaa erilliseksi alaluokkaan "infrastruktuurijärjestelmän ylläpitäjät". Ja jotkut ovat erikoistuneet yksinomaan toimistolaitteiden huoltoon, onneksi työ ei lopu koskaan, jos yrityksessä on yli sata henkilöä. Mutta kumpikaan heistä ei ole devoppeja.
Keitä DevOps ovat? Devopit ovat tyyppejä, jotka puhuvat ohjelmistokehityksen vuorovaikutuksesta ulkoisen infrastruktuurin kanssa. Tarkemmin sanottuna nykyaikaiset devopit ovat mukana kehitys- ja käyttöönottoprosesseissa paljon syvemmällä kuin järjestelmänvalvojat, jotka vain latasivat päivityksiä ftp:hen, olivat koskaan mukana. Yksi DevOps-insinöörin tärkeimmistä tehtävistä on nyt varmistaa mukava ja tehokkaasti jäsennelty vuorovaikutusprosessi kehitystiimien ja tuoteinfrastruktuurin välillä. Juuri nämä ihmiset ovat vastuussa palautus- ja käyttöönottojärjestelmien käyttöönotosta; nämä ihmiset ottavat osan kehittäjiltä taakasta ja keskittyvät mahdollisimman paljon äärimmäisen tärkeään tehtäväänsä. Samaan aikaan devops ei koskaan käynnistä uutta kaapelia tai anna uutta kannettavaa takahuoneesta (c) KO
Mikä on juju?
Kysymykseen "Kuka on DevOps?" puolet alan työntekijöistä alkaa vastata jotain "No, lyhyesti sanottuna, tämä on ylläpitäjä, joka ..." ja edelleen tekstissä. Kyllä, joskus, kun DevOps-insinöörin ammatti oli juuri nousemassa palvelun ylläpidon lahjakkaimmista ylläpitäjistä, heidän väliset erot eivät olleet ilmeisiä kaikille. Mutta nyt, kun devoppien ja järjestelmänvalvojan toiminnot tiimissä ovat muuttuneet radikaalisti erilaisiksi, ei ole hyväksyttävää sekoittaa niitä toisiinsa tai edes rinnastaa niitä.
Mutta mitä tämä tarkoittaa liiketoiminnalle?
Palkkaaminen, siinä on kyse.
Avaat "Järjestelmänvalvojan" työpaikan ja siellä luetellut vaatimukset ovat "vuorovaikutus kehitys- ja asiakkaiden kanssa", "CI/CD-toimitusjärjestelmä", "yrityksen palvelimien ja laitteiden ylläpito", "sisäisten järjestelmien hallinta" jne. päällä; ymmärrät, että työnantaja puhuu hölynpölyä. Ongelma on siinä, että "Järjestelmänvalvojan" sijasta avoimen työpaikan otsikon tulisi olla "DevOps Engineer", ja jos tätä nimikettä muutetaan, kaikki loksahtaa paikoilleen.
Millaisen vaikutelman kuitenkin saa, kun lukee tällaisen avoimen työpaikan? Että yritys etsii monen koneen kuljettajaa, joka ottaa käyttöön sekä versionhallinta- että valvontajärjestelmän ja puristaa twisteriä hampaillaan...
Mutta jotta huumeriippuvuuden astetta ei lisätä työmarkkinoilla, riittää, että kutsut avoimia työpaikkoja niiden oikeilla nimillä ja ymmärrät selvästi, että DevOps-insinööri ja järjestelmänvalvoja ovat kaksi eri kokonaisuutta. Mutta joidenkin työnantajien hillitön halu esittää hakijalle mahdollisimman laaja vaatimusluettelo johtaa siihen, että "klassiset" järjestelmänvalvojat eivät ymmärrä, mitä heidän ympärillään tapahtuu. Mitä, ammatti muuttuu ja he ovat ajastaan jäljessä?
Ei ei ja vielä kerran ei. Yrityksen sisäisiä palvelimia hallinnoivat tai L2/L3-tukitehtäviä hoitavat ja muita työntekijöitä auttavat infrastruktuurin ylläpitäjät eivät ole lähteneet eivätkä aio poistua.
Voiko näistä asiantuntijoista tulla DevOps-insinöörejä? Tietysti he voivat. Itse asiassa tämä on asiaan liittyvä ympäristö, joka vaatii järjestelmänhallinnan taitoja, mutta tämän lisäksi lisätään työskentely valvonta-, toimitusjärjestelmien kanssa ja ylipäätään tiivis vuorovaikutus kehitys- ja testaustiimin kanssa.
Toinen DevOps-ongelma
Itse asiassa kaikki ei rajoitu vain palkkaamiseen ja jatkuvaan sekaannukseen järjestelmänvalvojien ja devopien välillä. Jossain vaiheessa yritys kohtasi ongelman päivitysten toimittamisessa ja kehitystiimin vuorovaikutuksessa lopullisen infrastruktuurin kanssa.
Ehkä se tapahtui, kun setä kimaltelevilla silmillä nousi jonkin konferenssin lavalla ja sanoi: "Teemme tätä ja kutsumme sitä DevOpsiksi. Nämä kaverit ratkaisevat kaikki ongelmasi” - ja alkoivat kertoa kuinka hyvää elämä yrityksessä on DevOps-käytäntöjen käyttöönoton jälkeen.
DevOps-insinöörin palkkaaminen ei kuitenkaan riitä, jotta kaikki toimisi niin kuin pitää. Yrityksen tulee käydä läpi täydellinen DevOps-muutos, eli DevOpsiemme rooli ja kyvyt on ymmärrettävä selkeästi myös tuotekehitys- ja testaustiimin puolelta. Meillä on tästä aiheesta "ihana" tarina, joka havainnollistaa täysin sitä raakuutta, jota joissain paikoissa tapahtuu.
Tilanne. DevOps vaaditaan ottamaan käyttöön version palautusjärjestelmä ilman, että se todellakaan toimii. Oletetaan, että Käyttäjät-järjestelmässä on erilliset kentät etunimelle, sukunimelle ja salasanalle. Tuotteesta tulee uusi versio, mutta kehittäjille "palautus" on vain taikasauva, joka korjaa kaiken, eivätkä he edes tiedä, miten se toimii. Joten esimerkiksi seuraavassa korjauspäivityksessä kehittäjät yhdistivät etu- ja sukunimikentät, veivät sen tuotantoon, mutta versio on jostain syystä hidas. Mitä tapahtuu? Johto tulee devopsiin ja sanoo "Pull the switch!", eli pyytää häntä palaamaan edelliseen versioon. Mitä devops tekee? Se palaa edelliseen versioon, mutta koska kehittäjät eivät halunneet selvittää, kuinka tämä palautus tehtiin, kukaan ei kertonut devops-tiimille, että tietokanta oli myös palautettava. Tämän seurauksena kaikki kaatuu puolestamme ja hitaan verkkosivuston sijaan käyttäjät näkevät "500" -virheen, koska vanha versio ei toimi uuden tietokannan kenttien kanssa. Devops ei tiedä tästä. Kehittäjät ovat hiljaa. Johto alkaa menettää hermojaan ja rahaa ja muistaa varmuuskopiot tarjoutuen perääntymään niistä, jotta "ainakin jotain toimisi". Tämän seurauksena käyttäjät menettävät kaikki tietonsa tietyn ajan kuluessa.
Pähkinät menevät tietysti devopsiin, jotka "ei tehneet kunnollista palautusjärjestelmää", eikä ketään kiinnosta, että tämän tarinan hirvet ovat kehittäjiä.
Johtopäätös on yksinkertainen: ilman normaalia lähestymistapaa DevOpsiin sellaisenaan siitä ei ole juurikaan hyötyä.
Tärkein asia muistaa: DevOps-insinööri ei ole taikuri, ja ilman laadukasta viestintää ja kaksisuuntaista vuorovaikutusta kehityksen kanssa hän ei selviä tehtävistään. Kehittäjiä ei voida jättää yksin "ongelmiensa" kanssa tai antaa komentoa "älä sekaannu kehittäjiin, heidän tehtävänsä on koodata" ja sitten toivoa, että kriittisellä hetkellä kaikki toimii niin kuin pitää. Näin se ei toimi.
Pohjimmiltaan DevOps on osaaminen hallinnan ja teknologian rajalla. Lisäksi on kaikkea muuta kuin ilmeistä, että tässä cocktailissa pitäisi olla enemmän teknologiaa kuin hallintaa. Jos haluat todella rakentaa nopeampia ja tehokkaampia kehitysprosesseja, sinun on luotettava devops-tiimiisi. Hän tuntee oikeat työkalut, hän on toteuttanut vastaavia projekteja, hän osaa tehdä sen. Auta häntä, kuuntele hänen neuvojaan, älä yritä eristää häntä jonkinlaiseen autonomiseen yksikköön. Jos järjestelmänvalvojat voivat työskennellä yksin, niin devopit ovat tässä tapauksessa hyödyttömiä; he eivät voi auttaa sinua tulemaan paremmaksi, jos et itse halua ottaa tätä apua vastaan.
Ja viimeinen asia: lopeta infrastruktuurin ylläpitäjien loukkaaminen. Heillä on oma, äärimmäisen tärkeä työrintamansa. Kyllä, järjestelmänvalvojasta voi tulla DevOps-insinööri, mutta tämän pitäisi tapahtua henkilön itsensä pyynnöstä, ei paineen alla. Eikä siinä ole mitään väärää, että järjestelmänvalvoja haluaa pysyä järjestelmänvalvojana - tämä on hänen erillinen ammattinsa ja hänen oikeutensa. Jos haluat käydä läpi ammatillisen muutoksen, sinun ei saa koskaan unohtaa, että sinun on kehitettävä teknisten taitojen lisäksi myös johtamistaitoja. Todennäköisesti sinun johtajana on sinun tuoda kaikki nämä ihmiset yhteen ja opettaa heidät kommunikoimaan samalla kielellä.
Lähde: will.com