Skip to main content

29 Tekniikkaa

29Tekniikkaa
29Tekniikka logo
29Tekniikkaa

Recent Post

Konfiguraatiodrifti IT-infrastruktuurissa – mistä se syntyy, miksi se on riski ja miten sitä voidaan hallita

Yrityksen ympäristö voi näyttää paperilla selkeältä. Palvelimet on dokumentoitu, pilviresurssit määritelty ja käyttöönotot automatisoitu. Silti monessa organisaatiossa tulee vastaan tilanne, jossa testiympäristö toimii moitteettomasti, mutta tuotannossa sama ratkaisu käyttäytyy eri tavalla.
Yleensä syy ei löydy sovelluskoodista.
Monesti ongelman taustalla on konfiguraatiodrifti.
Kyse on tilanteesta, jossa järjestelmän asetukset muuttuvat ajan myötä niin, että eri ympäristöt eivät enää vastaa toisiaan. Muutos voi olla pieni: yksi käsin tehty verkkosääntö, päivitetty palvelinpaketti tai ympäristömuuttuja, jota ei koskaan lisätty versionhallintaan. Kun tällaisia muutoksia kertyy kuukausien aikana riittävästi, lopputuloksena on ympäristö, jota kukaan ei täysin tunne.
Tämä on yksi yleisimmistä syistä sille, miksi ohjelmisto toimii yhdessä ympäristössä mutta ei toisessa.

Ongelma alkaa usein hyvästä tarkoituksesta

Konfiguraatiodrifti ei yleensä synny huolimattomuudesta.

Tyypillinen tilanne on kiireinen tuotantohäiriö. Palvelu on alhaalla, asiakkaat odottavat ja tiimi yrittää palauttaa järjestelmän toimintaan mahdollisimman nopeasti.

Joku kirjautuu palvelimelle ja tekee korjauksen käsin.

Tilanne ratkeaa.

Parin viikon kuluttua kukaan ei enää muista tarkalleen, mitä muutettiin.

Kun seuraava käyttöönotto tehdään, ympäristö ei enää vastaa dokumentaatiota eikä automaatiota.

Olen nähnyt organisaatioita, joissa ongelmaa etsittiin päiviä ennen kuin huomattiin, että yksi tuotantopalvelin käytti eri konfiguraatiota kuin muut saman klusterin palvelimet. Kukaan ei ollut muuttanut asetuksia tarkoituksella väärin. Muutos oli vain jäänyt elämään vuosien aikana.

Mistä konfiguraatiodrifti käytännössä syntyy?

Useimmiten syynä ei ole yksi iso virhe vaan useiden pienten muutosten kasaantuminen.

Ympäristöihin tehdään korjauksia eri aikaan. Palvelimia päivitetään eri versiolle. Tietoturvasääntöjä lisätään kiireessä. Pilvipalveluiden asetuksia muutetaan hallintapaneelista ilman, että muutokset päätyvät infrastruktuurikoodiin.

Muutaman kuukauden kuluttua ympäristöt näyttävät edelleen samanlaisilta, mutta niiden käyttäytyminen on erilaista.

Erityisen yleistä tämä on hybridiympäristöissä, joissa osa palveluista toimii pilvessä ja osa omissa konesaleissa. Mitä enemmän järjestelmässä on komponentteja, sitä helpommin pieniä eroja alkaa syntyä.

Miksi ongelma huomataan usein vasta tuotannossa?

Kehitysympäristössä käyttäjiä on vähän.
Tuotannossa liikenne on erilaista, tietoa on enemmän ja integraatioita on enemmän käytössä samanaikaisesti.
Tämän vuoksi konfiguraatioero voi pysyä pitkään piilossa.
Esimerkiksi kuormantasaajan aikakatkaisu voi olla testiympäristössä 120 sekuntia ja tuotannossa 60 sekuntia. Kehitysvaiheessa kukaan ei huomaa eroa. Kun järjestelmä alkaa käsitellä suurempia tietomääriä, käyttäjät alkavat saada virheilmoituksia.
Sovellus ei välttämättä ole muuttunut lainkaan.
Asetukset ovat.

Pilviympäristöt eivät poista ongelmaa

Joskus ajatellaan, että AWS, Azure tai Google Cloud ratkaisevat tämän automaattisesti.

Todellisuudessa pilvi voi jopa lisätä riskiä.

Pilvipalveluissa muutoksia on helppo tehdä käyttöliittymästä muutamalla klikkauksella. Tämä nopeuttaa työtä, mutta samalla syntyy houkutus tehdä korjauksia suoraan tuotantoon.

Jos muutosta ei viedä takaisin Terraformiin, CloudFormationiin tai muuhun infrastruktuurin hallintamalliin, ympäristön todellinen tila alkaa erota dokumentoidusta tilasta.

Monessa tapauksessa ongelma löytyy vasta seuraavan käyttöönoton yhteydessä, kun automaatio yrittää rakentaa ympäristön uudelleen vanhojen määritysten perusteella.

Miten konfiguraatiodrifti näkyy liiketoiminnassa?

Teknisestä näkökulmasta kyse on asetuseroista.

Liiketoiminnan näkökulmasta seuraukset voivat olla huomattavasti vakavampia.

Käyttöönotot epäonnistuvat.

Vikatilanteiden selvittäminen hidastuu.

Palveluiden palautuminen kestää kauemmin.

Tietoturvariskit kasvavat.

Joissakin tapauksissa auditoinneissa havaitaan, ettei ympäristö vastaa dokumentoituja määrityksiä.

Erityisesti finanssi-, terveydenhuolto- ja viranomaisjärjestelmissä tällaiset erot voivat muodostua merkittäväksi riskiksi.

Ensimmäinen askel: selvitä mikä on todellinen tila

Moni tiimi yrittää ratkaista ongelmaa päivittämällä dokumentaatiota.
Usein kannattaa tehdä päinvastoin.
Ensin täytyy selvittää, millainen ympäristö oikeasti on.
Tämä tarkoittaa palvelinasetusten, verkkomääritysten, käyttöoikeuksien, tietokantojen ja pilviresurssien läpikäyntiä.
Yllättävän usein dokumentaatio kertoo yhden asian ja ympäristö jotain aivan muuta.
Vasta tämän jälkeen voidaan päättää, mikä tila on oikea ja mikä poikkeama pitää korjata.

Infrastructure as Code vähentää ongelmia

Yksi tehokkaimmista tavoista hallita konfiguraatiodriftiä on siirtää määritykset versionhallintaan.

Kun verkot, palvelimet, käyttöoikeudet ja muut resurssit määritellään koodina, muutoksista jää jälki.

Samalla voidaan nähdä:
• kuka teki muutoksen
• milloin muutos tehtiin
• miksi muutos tehtiin
• mitä vaikutuksia muutoksella oli

Tämä ei estä kaikkia ongelmia, mutta vähentää merkittävästi tilanteita, joissa ympäristö alkaa elää omaa elämäänsä.

Automaattinen valvonta auttaa löytämään poikkeamat ajoissa

Moni organisaatio huomaa driftin vasta häiriön jälkeen.

Parempi vaihtoehto on havaita muutokset heti niiden syntyessä.

Pilvipalveluissa voidaan seurata resurssimuutoksia automaattisesti. Lisäksi ympäristöjä voidaan verrata määriteltyyn tavoitetilaan säännöllisesti.

Tavoitteena ei ole estää kaikkea muutosta.

Tavoitteena on tietää, mitä on muuttunut.

Kun näkyvyys paranee, myös ongelmien ratkaiseminen nopeutuu huomattavasti.

Kaikkia muutoksia ei kannata tehdä käsin

Käsin tehdyt muutokset ovat yksi yleisimmistä driftin lähteistä.
Tämän vuoksi monet kokeneet infrastruktuuritiimit noudattavat yksinkertaista sääntöä:
  • Jos muutos pitää tehdä kahdesti, sitä ei pitäisi tehdä käsin.
  • Kun sama työ automatisoidaan, ympäristöt pysyvät yhtenäisempinä ja virheiden määrä vähenee.
  • Samalla uusien ympäristöjen rakentaminen nopeutuu.

Konfiguraatiodrifti on usein oire suuremmasta ongelmasta

Jos ympäristöissä esiintyy jatkuvasti poikkeamia, syy ei välttämättä ole tekninen.

Taustalla voi olla puutteellinen muutoshallinta, epäselvät vastuut tai liian kiireinen toimintamalli.

Siksi ongelmaa ei kannata tarkastella pelkästään infrastruktuurin näkökulmasta.

Jos prosessi sallii hallitsemattomat muutokset, uusia poikkeamia syntyy riippumatta siitä, mitä työkaluja käytetään.

Lopuksi

Konfiguraatiodrifti ei yleensä aiheuta ongelmia heti. Juuri siksi se on niin hankala ilmiö.

Ympäristö toimii tänään, ensi viikolla ja ehkä vielä ensi kuussakin. Vähitellen asetukset kuitenkin erkanevat toisistaan, dokumentaatio vanhenee ja järjestelmästä tulee vaikeampi ylläpitää.

Kun ensimmäinen vakava häiriö lopulta tapahtuu, huomio kiinnittyy usein sovellukseen, verkkoon tai palvelimeen. Todellinen syy löytyy kuitenkin joskus paljon arkisemmasta asiasta: ympäristö ei enää ole sellainen kuin sen luultiin olevan.

Siksi konfiguraatiodriftin hallinta ei ole vain tekninen tehtävä. Se on osa luotettavan IT-ympäristön rakentamista, ylläpitoa ja pitkäjänteistä kehittämistä.