Tuotannon ylläpito ja jatkokehitys

Ketterät menetelmät vaativat ketterää ylläpitoa

Ketterien ohjelmistokehitysmenetelmien yksi merkittävä hyöty on se, että jokaisen lyhyen iteraation päätteeksi ohjelmistosta valmistuu uusi versio, joka voidaan ottaa tuotantokäyttöön. Näin uudet ominaisuudet saadaan nopeasti käyttöön.

Perinteisessä ohjelmistokehityksessä tuotantoonvientejä on saatettu tehdä kerran vuodessa, kun taas ketterässä ohjelmistokehityksessä niitä voidaan tehdä jopa päivittäin. Sen vuoksi ketterät menetelmät asettavat uusia vaatimuksia tuotanto-operoinnille, -ylläpidolle ja -valvonnalle.

Ylläpidettävyys luodaan jo kehityksen aikana

Jo järjestelmäkehityksen aikana pitää ottaa huomioon, että järjestelmä rakennetaan tuotantokäyttöä varten. Kehitystyössä pitää kiinnittää erityishuomiota virheenkäsittelyyn ja virhetilanteiden lokitukseen. Virheitä jää järjestelmään aina, sillä yksikkö-, integraatio- ja hyväksymistestauksessa ei koskaan saada kattavasti testattua kaikkia mahdollisia tapauksia. Virhe voi tapahtua myös järjestelmän "ulkopuolella" taustajärjestelmissä, verkkoliikenteessä, nimipalveluissa jne.

Järjestelmä kannattaa rakentaa niin, että esimerkiksi yksittäisen taustajärjestelmän vikaantuminen ei estä koko järjestelmän käyttöä. Järjestelmän tulisi lokittaa kaikki ajonaikaiset poikkeukset. Lisäksi usein kannattaa lokittaa tarkemmin esimerkiksi taustajärjestelmiin tehdyt kutsut ja saadut vastaukset. Kriittisimmät toiminnot, esimerkiksi verkkomaksut, on syytä lokittaa tarkemmalla tasolla.

Valvontaa varten pitää rakentaa jo kehitysvaiheessa erilaisia mekanismeja, joilla järjestelmän sisäistä tilaa ja toimintaa voidaan valvoa. Tätä kehitystyötä kannattaa tehdä yhteistyössä ylläpidon kanssa, jolloin ylläpito oppii samalla tuntemaan järjestelmää. Ylläpitotiimin on tärkeää olla mukana jo kehitysvaiheessa, varsinkin jos kehitystiimi siirtyy jossain vaiheessa uusiin projekteihin ja jatkokehitys jää kokonaan ylläpidolle. Ylläpitäjillä pitää olla pääsy lähdekoodeihin ja kaikkeen olemassa olevaan dokumentaatioon (esim. wiki-sivut, keskustelualueet, virhetietokanta). Kehittäjien ja ylläpidon välistä kommunikaatiota voidaan parantaa reaaliaikaisilla keskustelutyökaluilla (esim. Skype tai irc).

Usein tapahtuvat tuotantoonviennit vähentävät riskejä

Toisin kuin usein kuvitellaan, usein tapahtuva jatkuva tuotantoonvienti vähentää tuotantoonviennin riskejä. Kun tuotantoonvientejä tehdään useammin, muutokset ovat pieniä. Samalla huomataan nopeasti prosessin automatisoinnin tarpeet, mikä taas omalta osaltaan pienentää inhimillisen virheen mahdollisuutta.

Tuotantoonvienteihin on monia avoimen lähdekoodin ratkaisuja (esim. Fabric, Capistrano, Chef, Puppet), mutta oleellisinta on, että tuotantoonvientiprosessi on yksinkertainen, suoraviivainen ja toistettavissa samalla tavalla joka kerta.

Valvonta ja automatisointi nopeuttavat virhetilanteiden selvittelyä

Koska tuotantoonvientejä tehdään usein, jopa päivittäin, kenenkään aika ei riitä esimerkiksi sovelluksen lokien seuraamiseen. Ongelmat pitää kuitenkin tunnistaa heti niiden tapahtuessa tai mieluummin jo aiemmin. Tästä syystä paras käytäntö on kerätä ja tallentaa oleellista dataa jatkuvasti, ja automatisoida kaikki mahdollinen valvonta ja hälytykset. Valvontaan on monia kaupallisia ja avoimen lähdekoodin tuotteita (Zabbix, Nagios, Ganglia, Cacti jne.).

Virheen syyn selvittämisessä on usein tärkeää tietää järjestelmän tila kyseisellä ajanhetkellä. Jos ylläpitäjä alkaa selvittää tapahtunutta esimerkiksi 30 minuuttia myöhemmin, järjestelmä on voinut jo toipua tilanteesta, joten syiden ja seuraamusten selvittäminen voi olla vaikeaa . Kun valvonta on jatkuvaa ja automaattista, voidaan nähdä jälkikäteen olosuhteet, joissa virhe tapahtui. Tämä on oleellista tietoa paitsi ongelman selvittelyssä, myös ongelmien ennaltaehkäisyssä, kun voidaan asettaa hälytyksiä tietyistä raja-arvoista ja mahdollisesti tehdä toimenpiteitä ennen kuin tilanne pahenee.

Kun tuotantoympäristössä tapahtuu virhe, sen selvittäminen pitää aloittaa heti, syy pitää tunnistaa nopeasti, tilapäinen korjaus pitää tehdä mahdollisimman pikaisesti ja varsinaisen korjauksen tekeminen pitää aloittaa heti. Yleensä käyttäjiä on samanaikaisesti informoitava ongelmasta ja sen laajuudesta, vaikutuksesta ja korjauksen aikataulusta.

Usein ongelmanratkaisuun tarvitaan päätöksiä liiketoimintapuolelta: kuinka vakavasta ongelmasta on kysymys, miten korjaus priorisoidaan ja mitkä ovat välittömät toimenpiteet. Ongelman selvittäminen ei siis voi olla pelkästään ylläpidon vastuulla, vaan todennäköisesti tarvitaan ainakin kehittäjien, asiakaspalvelun ja liiketoiminnan apua. Jotta tilanne saadaan selvitettyä nopeasti, kommunikoinnin pitää olla toimivaa ja avointa ja osapuolten on työskenneltävä yhdessä organisaatiorajoista välittämättä.

Valvonnassa prosessien ja työkalujen merkitys on suuri, mutta tärkein tekijä ovat ihmiset ja yrityksen kulttuuri. Oleellista on virheisiin suhtautuminen, kun virheitä kuitenkin väistämättä tapahtuu. Virheisiin reagointia voidaan kehittää ja virheistä voidaan oppia.

Valvonnalla läpinäkyvyyttä tuotantoon

Kaikki valvonnassa kerätty data pitää olla helposti ja reaaliaikaisesti kehittäjien saatavilla, jotta he pystyvät seuraamaan järjestelmän tilaa ja toimivuutta ja esimerkiksi tuotantoonvientien vaikutusta suorituskykyyn. Tämän pitäisi olla jokaisen työtään arvostavan kehittäjän intresseissä. Liiketoiminnan edustajia varten kannattaa tehdä omat näkymänsä niin, että he pystyvät näkemään heille tärkeää informaatiota (esimerkiksi tilausmäärät, kävijämäärät) ja käyttämään tätä tietoa päätöstensä tukena.

Pidemmällä aikavälillä kerättyä dataa voidaan käyttää tarvittavan kapasiteetin suunnittelussa (engl. capacity planning). Graafeja tutkimalla voidaan ennustaa, milloin tarvitaan lisää levytilaa, muistia, prosessoritehoa tai lisää palvelimia. Tämä on tärkeä kustannustekijä: palvelinrauta vanhenee nopeasti, joten hankinta-ajankohdan lykkääminen myöhemmäksi todennäköisesti parantaa hankinnan hinta-laatusuhdetta. Toisaalta liian myöhään jätetty hankintapäätös voi aiheuttaa suuria ongelmia ja taloudellisia menetyksiä. Kerätty data on ainoa luotettava tapa ennustaa tulevia tarpeita.

Mielenrauhaa 24/7-päivystyksellä

Kriittisten järjestelmien on toimittava aina, joten tarvitaan joku taho, joka voidaan hälyttää selvittämään ja korjaamaan ongelmia mihin vuorokaudenaikaan tahansa. Oleellista on, että päivystävä tiimi tuntee järjestelmän toiminnan ja pystyy välittömästi aloittamaan ongelman selvittämisen. Ensisijainen tavoite kaikissa ongelmatilanteissa on minimoida ongelmasta aiheutuva vahinko. Tämä voi tarkoittaa esimerkiksi vikaantuneen palvelimen poistamista klusterista, tiettyjen palveluiden poistamista käytöstä tai koko palvelun alasajoa.

Ongelmatilanteissa vaaditaan yleensä nopeita toimenpiteitä ja päätöksiä ja tilanne voi olla hyvin stressaava. Ongelmanratkaisussa korostuu se, kuinka hyvin ylläpito tuntee järjestelmän toiminnan, kuinka hyvin ylläpitäjät ovat valmistautuneet esimerkiksi automatisoimalla yleisimpiä toimintoja ja kuinka hyvin kehitysvaiheessa on varauduttu ongelmatilanteisiin. Usein tällaisissa tilanteissa punnitaan paineensietokykyä, mutta tässäkin kokemus tuo varmuutta.

Kriittisen järjestelmän ylläpitoa varten kannattaa yleensä olla kokonaan erillinen, dedikoitu tiimi, jonka ensisijainen tehtävä on ongelmatilanteisiin reagointi. Etukäteen on vaikea arvioida, kuinka paljon työtä tilanne vaatii, joten muiden tehtävien aikatauluttaminen on haastavaa. Dedikoidun tiimin etu on se, että kun tilanne ei ole ns. päällä, tiimi voi keskittyä järjestelmän ja tuotantoympäristön jatkokehittämiseen ja ylläpidettävyyden parantamiseen.

Tuotannossa oleva järjestelmä vaatii huomiota ja huolenpitoa

Järjestelmän operointi tuotannossa tuo usein esiin uusia kehitystarpeita esimerkiksi tuotantoajoympäristöön ja operointiin liittyen. Lähes aina kehitystarpeisiin liittyy toimintojen automatisointi. Tästä esimerkkejä ovat ajoympäristön pystyttäminen uudelle palvelimelle, konfiguraatiomuutokset, diagnostiikkadatan kerääminen, palvelinten/prosessien uudelleenkäynnistykset ja tietysti tuotantoonviennit.

Usein esimerkiksi suorituskyky- ja skaalautuvuusongelmat ilmenevät vasta tuotannossa. Näitä ongelmia voidaan ratkaista monella eri tasolla. Ratkaisuun vaikuttaa merkittävästi se, kuinka järjestelmän arkkitehtuuri skaalautuu. Palvelinkapasiteettia voidaan kasvattaa horisontaalisesti eli esimerkiksi lisäämällä uusia palvelimia klusteriin tai vertikaalisesti eli lisäämällä yksittäisen palvelimen kapasiteettia (prosessoritehon kasvattaminen, muistin lisääminen jne.). Ongelmia ei voida kuitenkaan aina ratkaista palvelinkapasiteettia kasvattamalla, vaan myös järjestelmää ja arkkitehtuuria joudutaan muuttamaan. Tässä oleellista on, että valvonnalla ja diagnosoimalla on voitu löytää ongelmakohta, ja kehittäjät ja ylläpito työskentelevät yhdessä ongelman korjaamiseksi. Tätäkin parantamista tehdään yleensä iteratiivisesti: yhden pullonkaulan korjaamisen jälkeen löytyy yleensä seuraava optimointia vaativa kohta.

Edellä mainittujen asioiden lisäksi ylläpidon vastuulla ovat tietysti myös perinteisesti ylläpidolle kuuluvat työtehtävät ja niiden organisointi: varmuuskopiointi, kuormanjaon konfiguraatiot, tietoturvapäivitykset, huoltokatkoihin reagointi ja niin edelleen.

DevOps muuttaa organisaatiokulttuuria ja toimintatapoja

Verkkopalveluiden rakentaminen, kehittäminen ja ylläpito vaativat ketteryyttä, ja vain tuotantokäytössä oleva toimiva palvelu tuottaa lisäarvoa. On ehdottoman tärkeää, että kehittäjät, testaajat, ylläpitäjät, liiketoiminnan ihmiset ja muut mukana olevat tekevät jatkuvasti yhteistyötä ja tukevat toisiaan omilla vahvuuksillaan ja omalla osaamisellaan. Aika on rahaa erityisesti verkkopalveluiden kehittämisessä ja käyttöönotossa, joten kaikki mahdollinen tulisi automatisoida. Pelkästään testien ja paketoinnin automatisointi ei riitä, vaan muun muassa tuotantoonviennit, konfiguraatiomuutokset ja tietokantamigraatiot tulisi automatisoida.

Näiden käytäntöjen muodostamaa kokonaisuutta kutsutaan maailmalla usein DevOps-nimellä, joka tulee sanoista development (kehitys) ja operations (ylläpito). Nimi on kuitenkin hieman harhaanjohtava: kehittäjien ja ylläpidon lisäksi myös esimerkiksi liiketoiminnan osallistumisella on suuri merkitys tässä prosessissa. DevOps-käytäntö on parin viime vuoden aikana kasvattanut suosiotaan eri kokoisissa organisaatioissa ympäri maailman. DevOpsin tuominen perinteiseen organisaatio- ja toimintamalliin on yleensä iso muutos. Se muuttaa it-osaston, tuotekehitysorganisaation ja jopa koko yrityksen kulttuuria ja toimintatapoja. Muutos on kuitenkin välttämätön, jotta yritys pystyy reagoimaan muutoksiin ja uuteen tietoon nopeasti ja pitämään liiketoimintakriittiset järjestelmänsä, kuten vaikkapa verkkopankin, toimintavarmana.

Markus Ylä-Ilomäki, ohjelmistoarkkitehti

Markuksella on laaja kokemus kriittisten järjestelmien ylläpidosta ja jatkokehityksestä erilaisissa ympäristöissä. Hän on käyttänyt ketteriä ohjelmistokehitysmenetelmiä lähes kymmenen vuoden ajan.