DevOps-työkalujen ylläpito AWS:ssä: 5 askelta huippuluokan tehokkuuteen

Miten yhdistät, käytät ja ylläpidät näitä täysin erilaisia työkaluja niin, että ne toimivat yhdessä? Ja miten teet sen ilman, että pilvikustannuksesi räjähtävät käsiin?

DevOps-työkalukokonaisuudestasi voi helposti tulla kriittisin järjestelmäsi, koska kaikki kulkee sen kautta. Jos järjestelmä kaatuu, et voi ottaa mitään käyttöön missään.

Ylläpito ei lopu koskaan, joten sekä tänään että huomenna on runsaasti mahdollisuuksia mennä pahasti pieleen. Usko pois: olen auttanut yrityksiä hallitsemaan DevOps-työkalukokonaisuuksiaan jo vuosien ajan, ja tiedän, missä yritykset tekevät virheitä AWS:n DevOps-työkalujen kanssa.

Jos noudatat alla olevia viittä askelta, säästät itseltäsi ja yritykseltäsi paljon rahaa ja murheita AWS:ssä olevien työkalujesi ylläpidossa.

Mennään suoraan ensimmäiseen:

Vaihe 1: Suunnittele pilviverkkosi ja sen ominaisuudet

Kuten muutkaan järjestelmät, AWS ei ole täydellinen. Käytössäsi on kuormantasaajia, aliverkkoja ja erilaisia verkkoja, joiden täytyy kommunikoida keskenään.

Haluat rajoittaa verkkosi altistumista. Kaikkien palveluiden ei pitäisi näkyä kaikkialla kaikille, joten verkko kannattaa jakaa eri osiin.

Esimerkki

AWS:ssä on erilaisia tapoja yhdistää kaksi tiliä verkon kautta, jotta kaksi tiimiä voi työskennellä omilla tileillään. Osa tavoista on hyviä, osa huonoja.

Voisit käyttää virtuaalista julkipilveä, joka yhdistää kaksi tiliä toisiinsa. Tämän lähestymistavan ongelma on, että verkot kommunikoivat keskenään liikaa. Liikennettä ei ole helppo hallita, joten kun alat tehdä tätä laajassa mittakaavassa, kokonaisuus voi hajota täysin. Kaikki verkot kommunikoivat keskenään.

Nykyään käytössämme on tähän parempi teknologia, joka ratkaisee ongelman laajassa mittakaavassa: transit gatewayt. Tällaisia uusia teknologioita syntyy jatkuvasti ratkaisemaan pilven haasteita.

Pilviverkkojen ja niiden ominaisuuksien keskeiset osa-alueet

Kun puhumme pilviverkon ja sen ominaisuuksien suunnittelusta, tärkeimmät tarkasteltavat osa-alueet ovat:

• Käyttäjien pääsy: miten käyttäjät pääsevät järjestelmääsi.

• Sisäinen järjestelmä: miten järjestelmä toimii itsenäisesti ja mitä sen sisällä on.

• Koneiden väliset verkot: sinulla voi olla esimerkiksi asioita, joita Jenkinsin ja GitLabin täytyy ottaa käyttöön.

• On-premise-yhteydet: vaikka niiden merkitys vähenee ajan myötä, sinulla voi olla jotain, jonka täytyy muodostaa yhteys on-premise-ympäristöön.

Verkko on kaiken tietoturvan perusta. Tee se oikein, niin kaikki on turvallista jo suunnittelusta lähtien. Mutta jos teet sen väärin, mikään ei ole enää turvallista, koska kaikki on avoinna kaikille. Sillä ei ole väliä, mitä teet: jos verkkosi ovat avoimia, et voi korjata asioita jälkikäteen. Myös nämä yhteydet on korjattava, mikä tarkoittaa, että asioita täytyy kirjoittaa uudelleen kerta toisensa jälkeen.

Väärin tehtynä tämä kasvattaa AWS-kustannuksiasi ja vaikeuttaa vianmääritystä. Et koskaan tiedä, mikä rikkoi järjestelmän.

Käytännön vinkkejä

• Suojaa endpointisi! Suojaa ne kuormantasaajien taakse äläkä koskaan altista niitä suoraan.

• Luo mahdollisimman suppeita käyttöoikeusryhmiä.

• Luo kehyksiä ja malleja, joita ihmiset voivat käyttää, sekä valmiita käyttöoikeusmalleja.

• Skannaa ja testaa jatkuvasti, jotta saat selville, mikä on edelleen avoinna.

• Tee Infrastructure-as-a-Codesta lähtökohtasi.

• Älä ota kaikkea käyttöön kerralla – etene pala kerrallaan, kun tiedät jonkin toimivan.

Suojaa päätepisteesi! Suojaa ne kuormantasaajien taakse äläkä koskaan altista niitä suoraan.

Luo mahdollisimman suppeita käyttöoikeusryhmiä.

Luo kehyksiä, malleja ja valmiita käyttöoikeusmalleja, joita ihmiset voivat käyttää.

Skannaa ja testaa jatkuvasti selvittääksesi, mitä on vielä avoinna.

Tee Infrastructure-as-a-Codesta lähtökohtasi.

Älä ota kaikkea käyttöön kerralla – etene pala kerrallaan, kun tiedät jonkin toimivan.

Vaihe 2: Ota Infrastructure-as-a-Code haltuun

Koodisi sijaitsee jo Git- (tai muussa) repositoriossasi – infrastruktuurisi tulisi olla samassa paikassa. Sinun on voitava tietää, mikä on muuttunut, kuka muutoksen teki ja mihin se vaikuttaa. Näin voit suunnitella, sinulle jää audit trail ja asioiden toistaminen helpottuu.

Jos teet tämän väärin, päädyt ClickOpsiin: klikkailet käyttöliittymässä, ja sitten kaikki hajoaa. Et tiedä, mitä muutettiin, etkä pysty helposti palaamaan IaaC:hen.

Tässä tilanteessa infrastruktuurisi hallitsee sinua, et sinä infrastruktuuria. Jos järjestelmää ei hallita versionhallinnalla, sen pitäisi olla muuttumaton. Mutta se ei ole.

Infrastructure-as-a-Coden keskeiset osa-alueet

Sinun tulisi tarkastella koko infrastruktuuriasi, mutta pitkälti kaikki kiteytyy seuraaviin asioihin:

• Moduulit: uudelleenkäytettävät mallit, sillä et halua kirjoittaa kaikkea uudelleen – se aiheuttaa virheitä. Voit tehdä omia moduuleja, mutta suosittelen käyttämään virallisia moduuleja, jotta muiden on helpompi tehdä vastaavia malleja.

• Selkeät tiedostot: standardoi tiedostojen nimeäminen ja tapa, jolla otat kaiken käyttöön. Jos esimerkiksi päätät käyttää Terraformia, käytä vain Terraformia äläkä tee puolia jossain toisessa järjestelmässä. Älä yritä hallita kahta kieltä yhdessä tiimissä.

• Koodikatselmoinnit: ota käyttöön jonkinlaista automaatiota ja varmista, että se pysyy järjestelmässä. Terraform käyttää esimerkiksi stateja, joiden avulla näet, mitä muutetaan sitä mukaa kuin muutoksia tehdään. Tämä ehkäisee jonkin asian poistamisen vahingossa.

• Päivitykset: IaaC voi vanhentua hyvin nopeasti. Päivitä sitä tarpeen mukaan, jotta et päädy käyttämään vanhaa versiota, jota ei tueta tai joka ei yksinkertaisesti enää toimi.

Tämän laiminlyönti aiheuttaa kaikenlaisia ongelmia. IaaC on elävä kokonaisuus, jota on päivitettävä ja kehitettävä jatkuvasti.

Tämä ei ole helppoa. Käytännössä dokumentoit koko infrastruktuurisi etukäteen. Automaation varaan luottamisen sijaan sinun on määriteltävä tarkasti, miltä infrastruktuurisi tulee näyttää. Sinun on alusta asti päätettävä: ”tämän aiomme ottaa käyttöön” ja ”tällainen siitä tulee”.

Käytännön neuvoja

Noudata kunnollisia koodausstandardeja äläkä ajattele tätä skriptauksena. Hyvät koodausstandardit auttavat onnistumaan IaaC:n kanssa.

Vaihe 3: Suunnittele liikenne ja migraatio

Kuten edellä vaiheessa 1 mainitsin: verkotuksen tekeminen väärin tulee nopeasti kalliiksi. Liikenne liittyy myös verkotukseen: siihen, mitä liikkuu ylimmällä tasolla sisään ja ulos.

Jos sinulla on paljon artefakteja – esimerkiksi 6 TB dataa – ja siirrät jatkuvasti 2 TB dataa pilveen ja sieltä pois, kustannuksesi nousevat pilviin. Datan siirtäminen pilveen on edullisempaa, mutta sen siirtäminen ulos pilvestä on kallista.

Sinun on siis pohdittava: ”Mitä yritän tehdä?” ja ”Voinko suunnitella liikenteen paremmin?”

Tämä liittyy myös migraatioon, sillä sinun on mietittävä, ”miten siirrän datan on-premise-ympäristöstä pilveen”. Lopulta kaikki päätyy pilveen, joten sinun on suunniteltava, miten se onnistuu mahdollisimman kustannustehokkaasti ja tehokkaasti.

Liikenteen ja migraation keskeiset osa-alueet

Tähän liittyy paljon pieniä liikkuvia osia, mutta keskitytään tärkeimpiin alueisiin, joista saat eniten hyötyä. Ne ovat:

• Yhteydet ja integraatiot: mitä yhteyksiä ja integraatioita sinulla on? Nykyisessä DevOpsissa olet yhteydessä useisiin eri pisteisiin. Mitä otat käyttöön ja mikä kulkee CI/CD-järjestelmän kautta? Mikä on pilvessä ja minkä pitäisi olla siellä? Jos jonkin ei pitäisi olla pilvessä, tarvitset sitä varten fiksun suunnitelman.

• Käyttöoikeuksien hallinta: tarvitset toimivan menetelmän päättääksesi, kenellä pitäisi olla pääsy mihinkin ja missä.

Yhteydet ja integraatiot: mitä yhteyksiä ja integraatioita sinulla on? Nykyisessä DevOpsissa olet yhteydessä useisiin eri pisteisiin. Mitä otat käyttöön ja mikä kulkee CI/CD-järjestelmän kautta? Mikä on pilvessä ja minkä pitäisi olla siellä? Jos jonkin ei pitäisi olla pilvessä, tarvitset sitä varten fiksun suunnitelman.

Käyttöoikeuksien hallinta: tarvitset toimivan menetelmän päättääksesi, kenellä pitäisi olla pääsy mihinkin ja missä.

Jos et suunnittele liikennettäsi ja migraatiotasi, sinulle kertyy valtavia, tarpeettomia kustannuksia.

Lisäksi riskinä on, että järjestelmä ei vastaa riittävän nopeasti ja käyttäjäkokemus kärsii. Tämä on todennäköisesti päinvastaista kuin mitä tavoittelit, kun alun perin päätit siirtyä pilveen. Sen sijaan, että yksinkertaistaisit asioita, lisäät pilveen uusia monimutkaisuuden tasoja ja hidastat toimintaa.

Vaikeinta liikenteen ja migraation suunnittelussa on se, että… et luultavasti ole joutunut miettimään sitä aiemmin kovin paljon. Kyse ei siis ole rakettitieteestä, mutta se on uutta. Ja uudet asiat ovat vaikeampia.

Käytännön neuvo — yksinkertainen 1–2–3-prosessi:

1. Aloita analysoimalla, mitä integraatiopisteitä on ja missä ne sijaitsevat.

2. Selvitä, kuinka paljon dataa on kyseessä — tämän voit mitata.

3. Mieti, mitä yrität tehdä, mikä on tärkeää kussakin integraatiossa ja mikä on helpoin tapa päästä tavoitteeseen. ”Voimmeko siirtää sen helposti sinne, ja vaikuttaako se käyttäjäkokemukseen?”

Aloita analysoimalla, mitä integraatiopisteitä on ja missä ne sijaitsevat.

Selvitä, kuinka paljon dataa on kyseessä — tämän voit mitata.

Mieti, mitä yrität tehdä, mikä on tärkeää kussakin integraatiossa ja mikä on helpoin tapa päästä tavoitteeseen. ”Voimmeko siirtää sen helposti sinne, ja vaikuttaako se käyttäjäkokemukseen?”

Vaihe 4: Hallitse monitorointia, käyttöoikeuksia ja lokeja

Tämä on melko itsestään selvää, mutta olennaista on, että sinulla on pilvessä hallinta ja jäljitettävyys. Sinun on tiedettävä, mitä järjestelmässä tapahtuu. Kuka käytti mitäkin ja milloin, ja mitä hän teki? Tätä varten tarvitset lokeja ja käyttöoikeuksien hallintaa.

Tarvitset myös monitorointia, jotta tiedät, jos jokin rikkoutuu. Jos siirryt pilveen ja käytät esimerkiksi automaattista skaalausjärjestelmää, monitoroinnin on oltava kunnossa. Pilvessä et nimittäin ”vain monitoroi” jotain, vaan käytät monitorointimittareita ohjataksesi sitä, mitä infrastruktuurisi todella tekee.

Jos et hallitse monitorointia, palvelu voi esimerkiksi kaatua suuren tapahtuman aikana, koska et huomioinut, että kapasiteettia piti skaalata ylös ennen tapahtumaa.

Monitoroinnin, käyttöoikeuksien ja lokien keskeiset osa-alueet

Nämä keskeiset toiminnot voidaan jakaa helposti kahteen osaan:

• Havainnoitavuus: seuraat, miten asiat toimivat.

• Jäljitettävyys: saat selville, kuka teki mitä. Jos järjestelmä esimerkiksi hidastuu eikä jäljitettävyyslokeissa näy mitään, järjestelmässä tapahtuu todennäköisesti jotain muuta, joka vaatii huomiotasi. 

Havainnoitavuus: seuraat, miten asiat toimivat. 

Jäljitettävyys: saat selville, kuka teki mitä. Jos järjestelmä esimerkiksi hidastuu eikä jäljitettävyyslokeissa näy mitään, järjestelmässä tapahtuu todennäköisesti jotain muuta, joka vaatii huomiotasi. 

Jos et tee tätä, et yksinkertaisesti tiedä, onko järjestelmäsi alhaalla tai kuka sen rikkoi. Et myöskään tiedä, mitä tietoturvauhkia kohtaat. 

Yksi pilven eduista on, että järjestelmän voi ottaa käyttöön uudelleen useita kertoja. Osaa työstä ei voi hallita, ellei tietoa tallenneta muualle. Et voi seurata järjestelmää, jos se on alhaalla, etkä tiedä, mitä tapahtui juuri ennen sen kaatumista, koska olet jo poistanut vioittuneen osan. Jos järjestelmä hidastuu, et myöskään voi reagoida ajoissa korjataksesi sen, koska auto-scaling on jo poistanut sen. Siksi mittarit ja lokit on tallennettava järjestelmän ulkopuolelle, jotta mahdollisia ongelmia voidaan selvittää tehokkaasti.

Monitorointi ei kuitenkaan ole helppoa. Käytännössä vaihtoehtoja on kaksi:

1. Tietoa on aivan liikaa

2. Tietoa on liian vähän

Tietoa on aivan liikaa

Tietoa on liian vähän

Jos tietoa on liikaa, et tee sillä mitään – aivan kuten 10 000-sivuisen kirjan kanssa, jota et uskalla edes avata. Toisaalta 50-sivuinen opus ei anna riittävästi tietoa, jotta siihen kannattaisi käyttää aikaa.

Haasteena on löytää sopiva määrä käyttökelpoista tietoa, joka ei aiheuta hämmennystä. 

Internetissä on valtavasti ”parhaita käytäntöjä”, mutta tiivistän asian sinulle yksinkertaisesti seuraaviksi:

Käytännönläheiset neuvot

• Kannattaa aloittaa ”liiallisesta” tietomäärästä ja karsia sitä, kunnes tietoa on liian vähän. Lisää sitten tietoa takaisin, kunnes löydät riittävän määrän. Kyse on kokeilu- ja oppimisprosessista. Kultaisia sääntöjä ei ole, joten sinun on löydettävä kussakin tilanteessa toimiva ratkaisu.

• Varmista, että monitoroit endpointtejasi. Jos ne ovat alhaalla, palvelusi eivät ole käyttäjiesi saatavilla, vaikka palvelu tai koodi toimisi. (Käyttäjät eivät pidä siitä lainkaan.)

Vaihe 5: Ratkaise jatkuva ylläpito ja huolto

Et ota palvelujasi käyttöön vain kerran ja jätä niitä sitten toimimaan. Niiden käyttämisestä aiheutuu aina jatkuvia kustannuksia. 

Näihin kustannuksiin kuuluvat esimerkiksi palvelutuki, elinkaarensa lopussa olevat kirjastot ja järjestelmät, integraatiot sekä IP-osoitteiden sallittujen listojen hallinta – vain muutamia infrastruktuurisi edellyttämiä jatkuvia ylläpitotoimia mainitakseni.

Jos jätät IaaC:n sellaiseksi kuin se on, se vanhenee nopeasti ja lakkaa lopulta toimimasta. 

Tarvitset ylläpitoa, joka vie resursseja. Useimpiin näistä tarpeista löytyy ratkaisu AWS-teknologioista, mutta niitä on silti seurattava ja hallittava. Kuten kaikki muukin teknologia, myös nämä AWS-ratkaisut saavuttavat joskus oman elinkaarensa lopun.

Ylläpidon ja huollon keskeiset osa-alueet

Ylläpito- ja huoltovastuusi voidaan jakaa seuraaviin osa-alueisiin:

• Tietoturva: miten ylläpidät tietoturvaa.

• Ylläpidettävyys ja tulevaisuudenkestävyys: kuten kaikessa IaaC:ssa, sinun on varmistettava, että voit jatkossakin tehdä muutoksia järjestelmääsi. Kun se vanhenee liikaa, sitä ei voi enää edes päivittää.

• Ohjelmistosi ja arkkitehtuurisi tuntemus: sinun on tiedettävä, mitä tehdä, jotta ne pysyvät toiminnassa.

• Varmuuskopiot ja yleinen datanhallinta: varmista, että järjestelmästäsi otetaan varmuuskopiot, se toimii ja data on saatavilla, vaikka yksi alue kaatuisi.

• Monitorointi: tämäkin on osa ylläpitoa. Jonkun on seurattava, mitä monitorointidata kertoo, onko se oikein ja pitääkö jotain korjata.

Jos epäonnistut tässä ylläpidossa, sinulla on järjestelmä, jonka kaikki tuntevat, mutta johon kukaan ei uskalla koskea. Jos yrität ajaa automaation, se ei enää toimi. Saatat joutua palaamaan tutkimaan, mitä otit käyttöön kuusi vuotta sitten, ja ryhtymään aikaa vievään, kalliiseen takaisinmallinnukseen. Ja siinä samalla saatat huomata, että joku on murtautunut järjestelmääsi jo vuoden ajan.

Elämme kvartaalitaloudessa. Jos vastaat tästä ylläpitotyöstä, et kehitä palveluusi uusia ominaisuuksia etkä etsi uusia tapoja tehdä rahaa. Vaikka hoitaisit ylläpidon täydellisesti, se ei näy suoraan yrityksesi EBITDAssa, vaikka se vaikuttaakin siihen pitkällä aikavälillä. Työsi ei ole hohdokasta eikä luo arvoa seuraavan kvartaalin aikana.

Käytännön neuvoja

Jatkuvan ylläpidon tarpeeseen on käytännössä kolme vaihtoehtoa:

• Ulkoistaminen: Yhä useammat organisaatiot välttävät kohdentamasta omia kehittäjiään tällaiseen työhön, jotta nämä voivat keskittyä palveluiden kehittämiseen, ja ulkoistavat sen sen sijaan. Ne solmivat pitkäaikaisen ylläpitosopimuksen Eficoden kaltaisen yrityksen kanssa, joka pitää työkalut optimoituina ja ylläpidettyinä niin kauan kuin sopimus on voimassa.

• Oma ylläpitotiimi: Tämä tiimi vastaa kaikesta ylläpidosta, ja sille on varattu budjetti sitä varten.

• Yhteisten käytäntöjen luominen ja jatkuva noudattaminen: Kun luot jotain uutta, se hyödyntää oletusarvoisesti muilla alueilla vakiintuneita ja toimiviksi todettuja käytäntöjä. Tämä on kolmesta vaihtoehdosta vaikein, sillä sinun on varmistettava, että kaikki uusi on taaksepäin yhteensopivaa ja kaikki vanha eteenpäin yhteensopivaa. Muuten tuotat jatkuvasti lisää teknistä velkaa.

Yhteenveto

Tilanne on todellinen viidakko. DevOps-työkaluja on valtavasti, ja pilvi on yhä verrattain uusi sekä kehittyy jatkuvasti.

Ylläpito ei yleensä ole se seksikkäin asia — keskitymme mieluummin uuteen ja seuraavaan — mutta jos huomio herpaantuu, seuraukset ovat ikäviä. Asiat rikkoutuvat ja rahaa katoaa pohjattomaan kaivoon.

Kun seuraat viittä vaihettani ja kiinnität niihin huomiota, vältyt monelta harmilta. Sellaiselta harmilta, jota monet samassa tilanteessa olevat kokevat joka päivä.