Innovaation jalanjäljillä, osa 2.4

Viides peruspilari: Koko elinkaaren hallinta yhtenä tuotteena

Kun kuherruskuukausi on ohi

Olen usein törmännyt palvelinkeskuksen infrastruktuurista vastaavien tahojen toteavan ”nyt se on valmis”, kun viimeisetkin testit ovat valmistuneet ja onnistuneesti läpäisty. Tämän jälkeen onkin sitten aika siirtää palvelualusta tuotantoon sekä aloittaa työkuormien ja sovellusten asennukset/migraatiot uudelle alustalle.

Jos olet rakentanut referenssiarkkitehtuurin, sen arvolupaus on toimitettu myös tässä ajankohdassa ja seuraavat viisi vuotta onkin sitten taas sitä työlästä ja manuaalista perinteistä palvelualustan elinkaaren hallintaa.

Lähtökohtaisesti palvelualusta on varmasti ajan tasalla niin turvallisuuden kuin ominaisuuksiensa puolesta. Varsinainen elinkaaren hallinta alkaa yleensä vaiheittain sitä mukaa kun osakomponentit kaipaavat päivityksiä. Valitettavan usein näitä päivityksiä tehdään yksittäisten komponenttien näkökulmasta. Virtualisoinnista vastaavat tahot päivittävät hypervisoria omaan tahtiinsa, kuten palvelimista vastaavat tekevät firmware-päivitystensä kanssa, täysin omaa peliään pelaavaa verkkopuolta unohtamatta.

Haaste

1825 päivää palvelualustan ylläpitoa ja päivityksiä

Suurin haaste elinkaaren hallinnan kanssa on ehdottomasti siinä, että kun järjestelmää ei ole alun perinkään lähdetty suunnittelemaan tai toteuttamaan kokonaisuutena, niin miten sitä olisi tarkoitus 1825 päivää ylläpitää kokonaisuutena koko elinkaarensa ajan? Lisäksi, liiketoiminta on yleensä jättänyt tämän haasteen (sekä välilliset että välittömät!) ongelmat täysin budjetoimatta.

Harva testaa eri komponenttien riippuvuuksia tai yhteensopivuutta elinkaaren aikana. Riippuvuuksia aiheutuu erityisesti eri ohjelmistoversioista, mutta myös erilaisista lähempänä rautaa olevista ajureista ja firmiksistä.

Useat eri osakomponenttien huoltoikkunat työllistävät tasaisesti useita henkilöitä, ja etenkin silloin kun päivitys ei jonkin yhteensopimattomuuden vuoksi menekään niin kuin oli ajateltu. Olen itsekin ollut todistamassa näitä tapauksia, joissa suunniteltua käyttökatkoa on jatkettu suunnittelemattomalla, ja kuitenkin lopulta on palattu alkuperäiseen kokoonpanoon koska päivitystä ei vaan ole yhteensopimattomuuden tai jonkin muun syyn vuoksi saatu vietyä läpi.

Puhumattakaan että järjestelmää olisi testattu päivityksen jälkeen. Tämä on vielä ylimääräinen pökäle potkurissa, kun ajateltiin että järjestelmän osakomponentin päivitys meni onnistuneesti läpi, mutta jossain muussa osassa alkoikin ilmetä ongelmia, jotka tiedostettiin vasta kun asiakassovellukset alkoivat oireilla.

Ratkaisu

Kun VCE toimittaa yhdistetyn infrastruktuurijärjestelmän asiakkaalle, niin siitä matka oikeastaan vasta alkaa. Ensiluokkainen tukiorganisaatio on asiakkaan IT:n saumattomana jatkeena, mutta lisäksi VCE kantaa vastuunsa koko elinkaaren hallinnasta ja ennen kaikkea riskien mitigoinnista. VCE:n tuki työskentelee proaktiivisesti ja reaktiivisesti ensimmäisestä päivästä elinkaaren viimeiseen asti, löytääkseen kaikki haasteet joita matkalla saattaa ilmetä.

VCE seuraa jatkuvasti toimittamiensa eri komponenttien ja ohjelmistojen päivityksiä sekä testaa niiden keskinäisiä yhteensopivuudesta ristiin. Myös kuormitustestaukset ovat osana rutiinia, kuten turvallisuuteenkin liittyvät koestukset. Kaikki testaukset tehdään täsmälleen samanlaisella palvelualustalla, kun asiakkaallekin on toimitettu, ja tämä kaikki tehdään sillä välin, kun asiakas itse keskittyy ydinliiketoimintaansa, joka hyvin harvoin on palvelualustan järjestelmäkomponenttien kuormitus- ja yhteensopivuustestausta.

Tämän satoja miestyötunteja vaativan prosessin lopputuloksena on puolivuosittain julkaistava nk. ”major release”, joka sisältää eri komponenttivalmistajien uusimmat yhteensopivat ohjelmisto- ja ajuriversiot. Testattuina, todennettuina ja riskivapaina.

Lisäksi kuukausittain julkaistaan pienempiä ”minor release” päivityksiä, joihin on koottu yleensä lähinnä akuutteja tietoturvaan liittyviä päivityksiä. Nämäkin tietysti testattuina ja koestettuina kuten isommatkin päivitykset.

Myös erittäin kriittisiin tietoturvapäivityksiä on olemassa oma prosessinsa joka takaa riskittömät päivitykset, vaikka asioiden on syytä tapahtua nopeastikin. VCE:llä on eksklusiivinen asema tässä toimiessaan erittäin tiiviissä yhteistyössä eri komponenttitoimittajien kanssa. Me tiedämme (sekä osaamme varautua ja auttaa asiakkaitamme varautumaan) ongelmista ja haasteista ennen ketään muuta.

Kaiken tämän piiriin kuuluu kaikki mitä VCE on toimittanut. Olipa sitten kysymys esimerkiksi EMC Isilon Scale-Out NAS -järjestelmästä, tai vaikkapa EMC VPLEX -toteutuksesta. Myös Federation Enterprise Hybrid Cloud toteuttaa samanlaista testausta ja on suoraan linjassa VCE:n elinkaaren hallinnan kanssa.

Kiitos!

Tämä päättää viisiosaisen ”Innovaation jalanjäljillä” -sarjan. Kaikki viisi osaa ovat edelleen erittäin relevantteja nykyaikaisen IT-infrastruktuurin parissa työskentelevälle ammattilaiselle. Ja etenkin niille joita kiinnostavat näiden ammattilaisten pyörittämän palvelualustan riskit, kustannukset ja tuottavuus.

Jiri Vidgen

< Takaisin Blogit pääsivulle

Jiri Vidgren
vArchitect

Jiri Vidgren on kokenut it-infrastruktuuriasiantuntija. Hän on työskennellyt Dell EMC:n palveluksessa vuodesta 2014 alkaen päävastuunaan konvergoidut ja hyperkonvergoidut infrastruktuuriratkaisut ja niihin perustuva arkkitehtuurisuunnittelu. Kokemusta löytyy niin ohjelmistokehityksen kuin it-palveluntarjoajasektorinkin parista.