DevOpsista on tullut erittäin suosittu aihe muutaman viime vuoden aikana. Monet ihmiset haaveilevat liittymisestä siihen, mutta kuten käytäntö osoittaa, usein vain palkkatason vuoksi.
Jotkut ihmiset luettelevat DevOpsin ansioluetteloonsa, vaikka he eivät aina tiedä tai ymmärrä termin ydintä. Jotkut ajattelevat, että Ansiblen, GitLabin, Jenkinsin, Terraformin ja vastaavien opiskelun jälkeen (listaa voi jatkaa oman maun mukaan) sinusta tulee heti ”devopsist”. Tämä ei tietenkään pidä paikkaansa.
Olen viime vuodet ollut pääosin mukana DevOpsin toteutuksessa eri yrityksissä. Sitä ennen hän työskenteli yli 20 vuotta tehtävissä järjestelmävastaavasta IT-johtajaan. Tällä hetkellä DevOps-pääinsinööri Playgendaryssa.
Kuka on DevOps
Ajatus artikkelin kirjoittamisesta syntyi toisen kysymyksen jälkeen: "Kuka on DevOps?" Vielä ei ole olemassa vakiintunutta termiä sille, mikä tai kuka se on. Osa vastauksista on jo tässä . Ensin korostan siitä pääkohdat ja sitten jaan havaintoni ja ajatukseni.
DevOps ei ole asiantuntija, joka voidaan palkata, ei joukko apuohjelmia eikä kehittäjien osasto insinööreineen.
DevOps on filosofia ja metodologia.
Toisin sanoen se on joukko käytäntöjä, jotka auttavat kehittäjiä olemaan aktiivisesti vuorovaikutuksessa järjestelmänvalvojien kanssa. Eli työprosessien yhdistäminen ja integrointi toisiinsa.
DevOpsin myötä asiantuntijoiden rakenne ja roolit pysyivät ennallaan (on kehittäjiä, on insinöörejä), mutta vuorovaikutuksen säännöt ovat muuttuneet. Osastojen väliset rajat ovat hämärtyneet.
DevOpsin tavoitteet voidaan kuvata kolmessa kohdassa:
- Ohjelmisto on päivitettävä säännöllisesti.
- Ohjelmisto tulee tehdä nopeasti.
- Ohjelmisto tulee ottaa käyttöön kätevästi ja lyhyessä ajassa.
DevOpsille ei ole yhtä työkalua. Useiden tuotteiden konfigurointi, toimittaminen ja tutkiminen ei tarkoita, että DevOps olisi ilmestynyt yritykseen. Työkaluja on paljon ja niitä kaikkia käytetään eri vaiheissa, mutta ne palvelevat yhtä yhteistä tarkoitusta.
Ja tämä on vain osa DevOps-työkaluja
Olen haastatellut ihmisiä DevOps-insinöörin tehtävään nyt yli 2 vuotta, ja olen ymmärtänyt, kuinka tärkeää on ymmärtää selkeästi termin olemus. Minulla on kertynyt erityisiä kokemuksia, havaintoja ja ajatuksia, jotka haluan jakaa.
Haastattelukokemuksesta näen seuraavan kuvan: asiantuntijoilla, jotka pitävät DevOpsia ammattinimikkeenä, on yleensä väärinkäsityksiä kollegoiden kanssa.
Siellä oli silmiinpistävä esimerkki. Nuori mies tuli haastatteluun ansioluettelossaan paljon viisaita sanoja. Kolmesta viimeisestä työpaikastaan hänellä oli 5-6 kuukauden kokemus. Jätin kaksi startupia, koska ne "eivät lähteneet nousuun". Mutta kolmannesta yrityksestä hän sanoi, että kukaan ei ymmärrä häntä siellä: kehittäjät kirjoittavat koodia Windowsiin, ja johtaja pakottaa tämän koodin "käärimään" tavalliseen Dockeriin ja integroimaan CI/CD-putkeen. Kaveri sanoi paljon negatiivista nykyisestä työpaikastaan ja työtovereistaan - halusin vain vastata: "Et siis myy norsua."
Sitten esitin hänelle kysymyksen, joka on korkealla listallani jokaisen ehdokkaan kohdalla.
— Mitä DevOps merkitsee sinulle henkilökohtaisesti?
- Yleisesti vai miten minä sen ymmärrän?
Olin kiinnostunut hänen henkilökohtaisesta mielipiteestään. Hän tiesi termin teorian ja alkuperän, mutta oli jyrkästi eri mieltä niiden kanssa. Hän uskoi, että DevOps oli ammattinimike. Tässä on hänen ongelmiensa juuret. Kuten myös muut asiantuntijat, jotka ovat samaa mieltä.
Työnantajat, jotka ovat kuulleet paljon "DevOpsin taikuudesta", haluavat löytää henkilön, joka tulee luomaan tämän "taikuuden". Ja "DevOps on työ" -kategorian hakijat eivät ymmärrä, että tällä lähestymistavalla he eivät pysty täyttämään odotuksia. Ja yleensä he kirjoittivat DevOpsin ansioluetteloonsa, koska se on trendi ja he maksavat siitä paljon.
DevOps-metodologia ja filosofia
Metodologia voi olla teoreettinen ja käytännöllinen. Meidän tapauksessamme se on toinen. Kuten edellä mainitsin, DevOps on joukko käytäntöjä ja strategioita, joita käytetään asetettujen tavoitteiden saavuttamiseen. Ja kussakin tapauksessa, riippuen yrityksen liiketoimintaprosesseista, se voi vaihdella merkittävästi. Mikä ei tee siitä parempaa tai huonompaa.
DevOps-metodologia on vain keino saavuttaa tavoitteet.
Nyt siitä, mitä DevOps-filosofia on. Ja tämä on ehkä vaikein kysymys.
Lyhyt ja ytimekäs vastaus on melko vaikea muotoilla, koska sitä ei ole vielä virallistettu. Ja koska DevOps-filosofian kannattajat ovat enemmän sitoutuneita käytäntöön, filosofointiin ei yksinkertaisesti ole aikaa. Tämä on kuitenkin erittäin tärkeä prosessi. Lisäksi se liittyy suoraan insinööritoimintaan. Siellä on jopa erikoistunut osaamisalue - .
Yliopistossani ei ollut sellaista ainetta, jouduin opiskelemaan kaikkea itse 90-luvulla löytämäni materiaalin avulla. Aihe on valinnainen insinöörikoulutukselle, joten vastausta ei ole muotoiltu. Mutta ne ihmiset, jotka ovat vakavasti uppoaneet DevOpsiin, alkavat tuntea tietyn "hengen" tai "tajuttoman kattavuuden" kaikista yrityksen prosesseista.
Oman kokemukseni avulla yritin virallistaa joitain tämän filosofian "postulaatteja". Tulos on seuraava:
- DevOps ei ole jotain itsenäistä, joka voidaan erottaa erilliseksi tieto- tai toiminta-alueeksi.
- Kaikkien yrityksen työntekijöiden tulee noudattaa DevOps-metodologiaa toimintansa suunnittelussa.
- DevOps vaikuttaa kaikkiin yrityksen prosesseihin.
- DevOps on suunniteltu vähentämään yrityksen prosessien aikakustannuksia varmistaakseen sen palveluiden kehittämisen ja parhaan mahdollisen asiakasmukavuuden.
- DevOps on nykykielellä yrityksen jokaisen työntekijän ennakoiva asema, jonka tavoitteena on vähentää aikakustannuksia ja parantaa ympärillämme olevien IT-tuotteiden laatua.
Luulen, että "postulaatit" ovat erillinen keskustelunaihe. Mutta nyt on jotain, jolle rakentaa.
Mitä DevOps tekee
Avainsana tässä on viestintä. Viestintää on paljon, jonka aloittajan pitäisi olla täsmälleen sama DevOps-insinööri. Miksi niin? Koska tämä on filosofiaa ja metodologiaa ja vasta sitten teknistä tietoa.
En voi puhua 100 %:n luottamuksella länsimaisista työmarkkinoista. Mutta tiedän melko paljon DevOps-markkinoista Venäjällä. Satojen haastattelujen lisäksi olen viimeisen puolentoista vuoden aikana osallistunut satoihin venäläisten suuryritysten ja pankkien DevOps-palvelun "Implementation of DevOps" teknisiin ennakkomyyntiin.
Venäjällä DevOps on vielä hyvin nuori, mutta jo trendikäs aihe. Tietääkseni pelkästään Moskovassa pula tällaisista asiantuntijoista oli vuonna 2019 yli 1000 ihmistä. Ja sana Kubernetes on työnantajille melkein kuin punainen rätti härälle. Tämän työkalun kannattajat ovat valmiita käyttämään sitä myös siellä, missä se ei ole välttämätöntä ja taloudellisesti kannattavaa. Työnantaja ei aina ymmärrä, missä tapauksissa mikä on tarkoituksenmukaisempaa käyttää, ja kunnollisella käyttöönotolla Kubernetes-klusterin ylläpito maksaa 2-3 kertaa enemmän kuin sovelluksen käyttöönotto perinteisellä klusterimallilla. Käytä sitä siellä, missä sitä todella tarvitset.
DevOpsin käyttöönotto on rahallisesti kallista. Ja se on perusteltua vain silloin, kun se tuo taloudellista hyötyä muilla aloilla, ei yksinään.
DevOps-insinöörit ovat itse asiassa edelläkävijöitä – heidän tulisi olla ensimmäisiä, jotka ottavat tämän menetelmän käyttöön yrityksessä ja rakentavat prosesseja. Jotta tämä onnistuisi, asiantuntijan on jatkuvasti oltava vuorovaikutuksessa työntekijöiden ja kollegoiden kanssa kaikilla tasoilla. Kuten yleensä sanon, kaikkien yrityksen työntekijöiden tulisi olla mukana DevOpsin käyttöönottoprosessissa: siivoojasta toimitusjohtajaan. Ja tämä on edellytys. Jos tiimin nuorin jäsen ei tiedä ja ymmärrä mitä DevOps on ja miksi tiettyjä organisatorisia toimia suoritetaan, onnistunut toteutus ei toimi.
Lisäksi DevOps-insinöörin on käytettävä hallinnollisia resursseja ajoittain. Esimerkiksi "ympäristönkestävyyden" voittamiseksi - kun tiimi ei ole valmis hyväksymään DevOps-työkaluja ja -menetelmiä.
Kehittäjän tulee kirjoittaa vain koodia ja testejä. Tätä varten hän ei tarvitse supertehokasta kannettavaa tietokonetta, jolla hän ottaa käyttöön ja tukee paikallisesti koko projektin infrastruktuuria. Esimerkiksi käyttöliittymäkehittäjä säilyttää kaikki sovelluksen elementit kannettavassa tietokoneessaan, mukaan lukien tietokanta, S3-emulaattori (minio) jne. Eli hän viettää paljon aikaa tämän paikallisen infrastruktuurin ylläpitämiseen ja kamppailee yksin kaikkien tällaisen ratkaisun ongelmien kanssa. Sen sijaan, että kehitettäisiin koodia etupuolelle. Tällaiset ihmiset voivat vastustaa hyvin kaikkia muutoksia.
Mutta on ryhmiä, jotka päinvastoin esittelevät mielellään uusia työkaluja ja menetelmiä ja osallistuvat aktiivisesti tähän prosessiin. Vaikka tässäkään tapauksessa DevOps-insinöörin ja tiimin välistä viestintää ei peruttu.
Kun DevOpsia ei tarvita
On tilanteita, joissa DevOpsia ei tarvita. Tämä on tosiasia – se on ymmärrettävä ja hyväksyttävä.
Ensinnäkin tämä koskee kaikkia yrityksiä (etenkin pieniä yrityksiä), joiden voitto ei ole suoraan riippuvainen asiakkaille tietopalveluja tarjoavien IT-tuotteiden olemassaolosta tai puuttumisesta. Ja tässä ei puhuta yrityksen verkkosivuista, olipa kyseessä sitten staattinen "käyntikortti" tai dynaamisia uutislohkoja jne.
DevOpsia tarvitaan, kun asiakkaasi tyytyväisyys ja hänen halunsa palata luoksesi riippuvat näiden tietopalvelujen saatavuudesta asiakkaan kanssa vuorovaikutukseen, niiden laadusta ja kohdistamisesta.
Silmiinpistävä esimerkki on yksi tunnettu pankki. Yrityksellä ei ole perinteisiä asiakastoimistoja, asiakirjojen kulku hoidetaan postin tai kuriirien kautta ja monet työntekijät työskentelevät kotoa käsin. Yritys on lakannut olemasta pelkkä pankki, ja mielestäni siitä on tullut IT-yritys, jolla on kehitettyjä DevOps-tekniikoita.
Temaattisten tapaamisten ja konferenssien tallenteilta löytyy monia muita esimerkkejä ja luentoja. Vierailin joissakin heistä henkilökohtaisesti - tämä on erittäin hyödyllinen kokemus niille, jotka haluavat kehittyä tähän suuntaan. Tässä linkkejä YouTube-kanaville, joissa on hyviä luentoja ja materiaaleja DevOpsista:
Katso nyt liiketoimintaasi ja pohdi tätä: Kuinka paljon yrityksesi ja sen tuotot ovat riippuvaisia IT-tuotteista asiakasvuorovaikutuksen mahdollistamiseksi?
Jos yrityksesi myy kalaa pienessä myymälässä ja ainoa IT-tuote on kaksi 1C: Enterprise -kokoonpanoa (Accounting ja UNF), niin DevOpsista on tuskin järkevää puhua.
Jos työskentelet suuressa kauppa- ja valmistusyrityksessä (esimerkiksi valmistat metsästyskivääreitä), sinun tulee ajatella sitä. Voit tehdä aloitteen ja välittää johdolle DevOpsin käyttöönottonäkymät. No, ja samalla johda tätä prosessia. Ennakoiva asema on yksi DevOps-filosofian tärkeistä periaatteista.
Vuosittaisen taloudellisen liikevaihdon koko ja volyymi eivät ole pääkriteeri määritettäessä, tarvitseeko yrityksesi DevOpsia.
Kuvittelemme suurta teollisuusyritystä, joka ei ole suoraan vuorovaikutuksessa asiakkaiden kanssa. Esimerkiksi jotkut autonvalmistajat ja autonvalmistajat. En ole varma nyt, mutta aikaisemman kokemukseni mukaan useiden vuosien ajan kaikki asiakasvuorovaikutus tapahtui sähköpostitse ja puhelimitse.
Heidän asiakkaat ovat rajoitettu luettelo autokauppiaista. Ja jokaiselle on määrätty valmistajan asiantuntija. Kaikki sisäinen asiakirjavirtaus tapahtuu SAP ERP:n kautta. Sisäiset työntekijät ovat olennaisesti tietojärjestelmän asiakkaita. Mutta tätä IS:ää ohjataan klassisilla klusterijärjestelmien hallintakeinoilla. Tämä sulkee pois mahdollisuuden käyttää DevOps-käytäntöjä.
Tästä päätelmä: tällaisille yrityksille DevOpsin käyttöönotto ei ole kriittisesti tärkeää, jos muistelemme metodologian tavoitteet artikkelin alusta. Mutta en sulje pois sitä, että he käyttävät joitain DevOps-työkaluja tänään.
Toisaalta monet pienet yritykset kehittävät ohjelmistoja käyttämällä DevOps-metodologiaa, filosofiaa, käytäntöjä ja työkaluja. Ja he uskovat, että DevOpsin käyttöönottokustannukset ovat kustannukset, jotka antavat heille mahdollisuuden kilpailla tehokkaasti ohjelmistomarkkinoilla. Esimerkkejä tällaisista yrityksistä voidaan nähdä .
Pääkriteeri DevOpsin tarpeellisuuden ymmärtämiselle: mitä arvoa IT-tuotteillesi on yritykselle ja asiakkaille.
Jos yrityksen päätuote, joka tuottaa voittoa, on ohjelmisto, tarvitset DevOpsin. Ja se ei ole niin tärkeää, jos ansaitset oikeaa rahaa käyttämällä muita tuotteita. Tämä sisältää myös verkkokaupat tai mobiilisovellukset, joissa on pelejä.
Kaikki pelit ovat olemassa rahoituksen ansiosta: suoraan tai epäsuorasti pelaajilta. Playgendarylla kehitämme ilmaisia mobiilipelejä, joissa yli 200 ihmistä on suoraan mukana niiden luomisessa. Kuinka käytämme DevOpsia?
Kyllä, täsmälleen sama kuin yllä kuvattu. Kommunikoin jatkuvasti kehittäjien ja testaajien kanssa ja järjestän työntekijöille sisäistä koulutusta DevOps-menetelmistä ja -työkaluista.
Käytämme nyt aktiivisesti Jenkinsiä CI-/CD-putkistotyökaluna kaikkien kokoonpanoputkien suorittamiseen Unityn avulla ja myöhemmin App Storeen ja Play Marketiin. Lisää klassisesta työkalupakkista:
- Asana - projektinhallintaan. Integrointi Jenkinsin kanssa on määritetty.
- Google Meet - videokokouksiin.
- Slack - viestintään ja erilaisiin hälytyksiin, mukaan lukien Jenkinsin ilmoitukset.
- Atlassian Confluence - dokumentointiin ja ryhmätyöhön.
Lähisuunnitelmiimme kuuluu staattisen koodianalyysin käyttöönotto SonarQuben avulla ja automaattisen käyttöliittymätestauksen suorittaminen Seleniumin avulla jatkuvan integroinnin vaiheessa.
Sen sijaan johtopäätös
Haluaisin lopettaa seuraavaan ajatukseen: korkeasti päteväksi DevOps-insinööriksi pääsemiseksi on elintärkeää oppia kommunikoimaan ihmisten kanssa.
DevOps-insinööri on tiimipelaaja. Eikä mitään muuta. Aloitteen kommunikointiin kollegoiden kanssa tulisi tulla häneltä, eikä joidenkin olosuhteiden vaikutuksesta. DevOps-asiantuntijan tulee nähdä ja ehdottaa tiimille paras ratkaisu.
Ja kyllä, minkä tahansa ratkaisun toteuttaminen vaatii paljon keskustelua, ja lopulta se voi muuttua kokonaan. Itsenäisesti kehittyvä, ideoitaan ehdottava ja toteuttava henkilö on kasvava arvo sekä tiimille että työnantajalle. Mikä loppujen lopuksi heijastuu hänen kuukausipalkkionsa tai lisäbonusten muodossa.
Lähde: will.com