Kun sovellus ei toimi, viimeinen asia, jonka haluat kuulla kollegoiltasi, on lause "ongelma on sinun puolellasi". Tämän seurauksena käyttäjät kärsivät – ja he eivät välitä siitä, mikä osa tiimistä on vastuussa rikkoutumisesta. DevOps-kulttuuri syntyi juuri tuomaan kehitys ja tuki yhteen jaetun vastuun ympärille lopputuotteesta.
Mitä käytäntöjä DevOps-konsepti sisältää ja miksi niitä tarvitaan? Mitä DevOps-insinöörit tekevät ja mitä heidän pitäisi pystyä tekemään? EPAM:n asiantuntijat vastaavat näihin ja muihin kysymyksiin: Kirill Sergeev, järjestelmäinsinööri ja DevOps-evankelista, ja Igor Boyko, johtava järjestelmäinsinööri ja yhden yrityksen DevOps-tiimin koordinaattori.
Miksi DevOpsia tarvitaan?
Aikaisemmin kehittäjien ja tuen (ns. toiminnan) välillä oli este. Se kuulostaa paradoksaalista, mutta heillä oli erilaiset tavoitteet ja KPI:t, vaikka he tekivät saman asian. Kehityksen tavoitteena oli toteuttaa liiketoiminnan vaatimukset mahdollisimman nopeasti ja lisätä ne toimivaan tuotteeseen. Tuki vastasi sen varmistamisesta, että sovellus toimii vakaasti - ja kaikki muutokset vaaransivat vakauden. Eturistiriita on olemassa – DevOps näytti ratkaisevan sen.
Mikä DevOps on?
Se on hyvä kysymys – ja kiistanalainen: maailma ei ole vielä lopullisesti sopinut tästä. EPAM uskoo, että DevOps yhdistää teknologiat, prosessit ja vuorovaikutuskulttuurin tiimissä. Tämä yhdistys pyrkii jatkuvasti tuottamaan lisäarvoa loppukäyttäjille.
Kirill Sergeev: "Kehittäjät kirjoittavat koodia, testaajat tarkistavat sen ja järjestelmänvalvojat ottavat lopullisen tuotteen tuotantoon. Pitkän aikaa nämä tiimin osat olivat jonkin verran hajallaan, ja sitten syntyi ajatus yhdistää ne yhteisen prosessin kautta. Näin DevOps-käytännöt ilmestyivät."
Päivä koitti, jolloin kehittäjät ja järjestelmäsuunnittelijat kiinnostuivat toistensa työstä. Tuotannon ja tuen välinen raja alkoi hävitä. Näin syntyi DevOps, joka sisältää käytännöt, kulttuurin ja tiimivuorovaikutuksen.
Mikä on DevOps-kulttuurin ydin?
Tosiasia on, että vastuu lopputuloksesta on jokaisella tiimin jäsenellä. Mielenkiintoisin ja vaikein asia DevOps-filosofiassa on ymmärtää, että tietty henkilö ei ole vastuussa vain omasta työvaiheestaan, vaan on vastuussa siitä, kuinka koko tuote toimii. Ongelma ei ole kenenkään puolella - se jaetaan, ja jokainen tiimin jäsen auttaa ratkaisemaan sen.
Tärkeintä DevOps-kulttuurissa on ratkaista ongelma, ei vain soveltaa DevOps-käytäntöjä. Lisäksi näitä käytäntöjä ei toteuteta "jonkun puolella", vaan koko tuotteessa. Projekti ei sinänsä tarvitse DevOps-insinööriä - se tarvitsee ratkaisun ongelmaan, ja DevOps-insinöörin rooli voidaan jakaa useiden eri erikoisalojen tiimin jäsenten kesken.
Millaisia DevOps-käytäntöjä on?
DevOps-käytännöt kattavat ohjelmiston elinkaaren kaikki vaiheet.
Igor Boyko: "Ihanteellinen tapaus on, kun aloitamme DevOps-käytäntöjen käytön heti projektin alussa. Suunnittelemme yhdessä arkkitehtien kanssa, millainen arkkitehtoninen maisema sovelluksella tulee olemaan, missä se sijoitetaan ja miten skaalautuu, sekä valitsemme alustan. Nykyään mikropalveluarkkitehtuuri on muodissa - siihen valitsemme orkestrointijärjestelmän: jokaista sovelluksen elementtiä pitää pystyä hallitsemaan erikseen ja päivittämään se muista riippumatta. Toinen käytäntö on "infrastruktuuri koodina". Tämä on nimi lähestymistavalle, jossa projektin infrastruktuuri luodaan ja sitä hallitaan koodin avulla suoran vuorovaikutuksen sijaan palvelimien kanssa.
Seuraavaksi siirrytään kehitysvaiheeseen. Yksi suurimmista käytännöistä täällä on CI/CD:n rakentaminen: sinun on autettava kehittäjiä integroimaan muutokset tuotteeseen nopeasti, pieninä annoksina, useammin ja kivuttomasti. CI/CD kattaa koodin tarkastelun, isäntätiedoston lataamisen koodikantaan ja sovelluksen käyttöönoton testaus- ja tuotantoympäristöissä.
CI/CD-vaiheissa koodi kulkee laatuporttien läpi. Heidän avullaan he tarkistavat, että kehittäjän työasemalta tuleva koodi täyttää määritetyt laatukriteerit. Yksikkö- ja käyttöliittymätestaus on lisätty tähän. Nopeaa, kivutonta ja kohdennettua tuotteen käyttöönottoa varten voit valita sopivan käyttöönottotyypin.
DevOps-harjoitsijoilla on myös paikka valmiin tuotteen tukivaiheessa. Niitä käytetään seurantaan, palautteeseen, turvallisuuteen ja muutosten tekemiseen. DevOps tarkastelee kaikkia näitä tehtäviä jatkuvan parantamisen näkökulmasta. Minimoimme toistuvat toiminnot ja automatisoimme ne. Tämä sisältää myös siirrot, sovellusten laajentamisen ja suorituskykytuen."
Mitä hyötyä DevOps-käytännöistä on?
Jos kirjoittaisimme oppikirjaa moderneista DevOps-käytännöistä, ensimmäisellä sivulla olisi kolme kohtaa: automaatio, julkaisujen nopeuttaminen ja nopea palaute käyttäjiltä.
Kirill Sergeev: "Ensimmäinen asia on automaatio. Voimme automatisoida kaiken vuorovaikutuksen tiimissä: kirjoittanut koodin - rullannut sen ulos - tarkistanut sen - asentanut sen - kerätä palautetta - palannut alkuun. Kaikki tämä on automaattista.
Toinen nopeuttaa julkaisua ja jopa yksinkertaistaa kehitystä. Asiakkaalle on aina tärkeää, että tuote tulee markkinoille mahdollisimman pian ja alkaa tuottaa etuja aikaisemmin kuin kilpailijoiden analogit. Tuotteiden toimitusprosessia voidaan parantaa loputtomasti: lyhentää aikaa, lisää valvontamerkkejä, parantaa valvontaa.
Kolmas on käyttäjien palautteen nopeutuminen. Jos hänellä on kommentteja, voimme välittömästi tehdä muutoksia ja päivittää sovelluksen välittömästi."
Miten käsitteet "järjestelmäsuunnittelija", "rakennusinsinööri" ja "kehittäjäinsinööri" liittyvät toisiinsa?
Ne menevät päällekkäin, mutta kuuluvat hieman eri alueille.
Järjestelmäinsinööri EPAM:ssa on tehtävä. Niitä on eri tasoilla: juniorista pääasiantuntijaan.
Rakennusinsinööri on enemmän rooli, joka voidaan suorittaa projektissa. Nyt CI/CD:stä vastaavia ihmisiä kutsutaan tällä tavalla.
DevOps-insinööri on asiantuntija, joka toteuttaa DevOps-käytäntöjä projektissa.
Jos kaikki summataan, saadaan jotain tällaista: järjestelmäinsinöörin asemassa oleva henkilö toimii projektin rakennusinsinöörinä ja on mukana DevOps-käytäntöjen toteuttamisessa.
Mitä DevOps-insinööri tarkalleen tekee?
DevOps-insinöörit kokoavat yhteen kaikki osat, jotka muodostavat projektin. He tuntevat ohjelmoijien, testaajien, järjestelmänvalvojien työn erityispiirteet ja auttavat yksinkertaistamaan heidän työtään. Hän ymmärtää liiketoiminnan tarpeet ja vaatimukset, sen roolin kehitysprosessissa - ja rakentaa prosessia asiakkaan edut huomioiden.
Puhuimme paljon automaatiosta – tämä on se, mitä DevOps-insinöörit käsittelevät ennen kaikkea. Tämä on erittäin suuri asia, johon kuuluu muun muassa ympäristön valmistelu.
Kirill Sergeev: "Ennen päivitysten käyttöönottoa tuotteeseen, ne on testattava kolmannen osapuolen ympäristössä. Sen ovat valmistaneet DevOps-insinöörit. He juurruttavat DevOps-kulttuurin koko projektiin: he esittelevät DevOps-käytäntöjä projektinsa kaikilla tasoilla. Nämä kolme periaatetta: automaatio, yksinkertaistaminen, kiihtyvyys – ne tuovat sinne minne pääsevätkin.”
Mitä DevOps-insinöörin pitäisi tietää?
Yleisesti ottaen hänellä tulee olla tietoa eri aloilta: ohjelmointi, käyttöjärjestelmien, tietokantojen, kokoonpano- ja konfigurointijärjestelmien kanssa työskentely. Näitä täydentää kyky työskennellä pilviinfrastruktuurin, orkestrointi- ja valvontajärjestelmien kanssa.
1. Ohjelmointikielet
DevOps-insinöörit osaavat useita automaation peruskieliä ja voivat esimerkiksi kertoa ohjelmoijalle: ”Entä jos asennat koodin etkä käsin, vaan käyttämällä komentosarjaamme, joka automatisoi kaiken? Valmistelemme sille konfigurointitiedoston, joka on sekä sinulle että meille kätevä lukea, ja voimme muuttaa sitä milloin tahansa. Katsomme myös, kuka, milloin ja miksi tekee siihen muutoksia."
DevOps-insinööri voi oppia yhden tai useamman näistä kielistä: Python, Groovy, Bash, Powershell, Ruby, Go. Niitä ei tarvitse tuntea syvällä - syntaksin perusteet, OOP-periaatteet ja kyky kirjoittaa yksinkertaisia skriptejä automatisointia varten riittää.
2. Käyttöjärjestelmät
DevOps-insinöörin on ymmärrettävä, mille palvelimelle tuote asennetaan, missä ympäristössä se toimii ja minkä palvelujen kanssa se on vuorovaikutuksessa. Voit erikoistua Windowsiin tai Linux-perheeseen.
3. Versionhallintajärjestelmät
Ilman versionhallintajärjestelmän tuntemusta DevOps-insinööri ei ole missään. Git on yksi suosituimmista järjestelmistä tällä hetkellä.
4. Pilvipalveluntarjoajat
AWS, Google, Azure - varsinkin jos puhumme Windows-suunnasta.
Kirill Sergeev: “Pilvipalveluntarjoajat tarjoavat meille virtuaalipalvelimia, jotka sopivat täydellisesti CI/CD:hen.
Kymmenen fyysisen palvelimen asentaminen vaatii noin sata manuaalista toimintoa. Jokainen palvelin on käynnistettävä manuaalisesti, asennettava ja konfiguroitava tarvittava käyttöjärjestelmä, asennettava sovelluksemme näille kymmenelle palvelimelle ja tarkistettava sitten kaikki kymmenen kertaa. Pilvipalvelut korvaavat tämän menettelyn kymmenellä koodirivillä, ja hyvän DevOps-insinöörin pitäisi pystyä käyttämään niitä. Tämä säästää aikaa, vaivaa ja rahaa – sekä asiakkaalta että yritykseltä.
5. Orkesterijärjestelmät: Docker ja Kubernetes
Kirill Sergeev: “Virtuaalipalvelimet on jaettu kontteihin, joihin voimme asentaa sovelluksemme. Kun säilöjä on paljon, sinun on hallittava niitä: kytke yksi päälle, toinen pois päältä, tee varmuuskopiot jonnekin. Tästä tulee melko monimutkainen ja vaatii orkestrointijärjestelmän.
Aiemmin jokaista sovellusta käsitteli erillinen palvelin – sen toiminnassa tapahtuneet muutokset saattoivat vaikuttaa sovelluksen toimivuuteen. Säilöjen ansiosta sovellukset eristyvät ja toimivat erikseen - jokainen omassa virtuaalikoneessaan. Jos vika ilmenee, ei tarvitse tuhlata aikaa syyn etsimiseen. On helpompi tuhota vanha kontti ja lisätä uusi."
6. Konfigurointijärjestelmät: Chef, Ansible, Puppet
Kun sinun on ylläpidettävä kokonaista palvelimia, sinun on suoritettava paljon samantyyppisiä toimintoja. Se on pitkää ja vaikeaa, ja manuaalinen työ lisää myös virhemahdollisuutta. Tässä konfigurointijärjestelmät tulevat apuun. Heidän avullaan he luovat skriptin, joka on helppolukuinen ohjelmoijille, DevOps-insinööreille ja järjestelmänvalvojille. Tämä komentosarja auttaa suorittamaan samat toiminnot palvelimilla automaattisesti. Tämä vähentää manuaalisia toimintoja (ja siten virheitä).
Millaisen uran DevOps-insinööri voi rakentaa?
Voit kehittää sekä vaaka- että pystysuunnassa.
Igor Boyko: “Vaakasuuntaisen kehityksen näkökulmasta DevOps-insinööreillä on nyt laajimmat mahdollisuudet. Kaikki muuttuu jatkuvasti, ja voit kehittää taitoja useilla eri aloilla: versionhallintajärjestelmistä valvontaan, kokoonpanonhallinnasta tietokantoihin.
Järjestelmäarkkitehdiksi voi tulla, jos työntekijä on kiinnostunut ymmärtämään, miten sovellus toimii sen elinkaaren kaikissa vaiheissa – kehityksestä tukeen.”
Kuinka tulla DevOps-insinööriksi?
- Lue Phoenix-projekti ja DevOps-käsikirja. Nämä ovat DevOps-filosofian todellisia pylväitä, joista ensimmäinen on fiktio.
- Opi tekniikoita yllä olevasta luettelosta: itse tai verkkokurssien kautta.
- Liity DevOps-insinööriksi avoimen lähdekoodin projektiin.
- Harjoittele ja tarjoa DevOps-käytäntöjä henkilökohtaisissa ja työprojekteissasi.
Lähde: will.com