Järjestelmäsi toimii loistavasti. Niin kauan kuin paikalla on henkilö, joka tietää miksi.
Yrityksellä on järjestelmä, joka on syntynyt seitsemän vuoden aikana. Se toimii. Palvelee asiakkaita. Yhdistyy muihin järjestelmiin. Toteuttaa prosesseja, ilman joita yritys ei käytännössä voisi toimia normaalisti.
Noiden seitsemän vuoden aikana projektissa työskenteli viisi ohjelmistokehittäjää. Lisäksi kaksi freelanceria ja yksi toimisto. Osa dokumentaatiosta on Confluencessa, osa Google Drivessa, osa tiketeissä. Jossain on vielä vanha dokumentti yhdestä integraatiosta. Ja kun joku kysyy, miksi jokin tietty järjestelmän osa toimii juuri tietyllä tavalla, vastaus kuuluu: "Luulen, että Mikael muisti sen."
Mikael lähti kolme vuotta sitten.
Ja juuri silloin alkaa todellinen ongelma.
Ei siksi, että järjestelmä olisi huonosti kirjoitettu. Ei siksi, että se yhtäkkiä lakkaisi toimimasta. Ongelma on siinä, että yritys ei enää omista täydellistä tietoa omasta järjestelmästään.
Järjestelmä toimii, mutta yritys ei välttämättä hallitse sitä
Tämä on yksi aliarvostetuimmista teknisen velan muodoista.
Kun puhumme teknisestä velasta, ajattelemme yleensä vanhaa koodia, vanhentuneita kirjastoja, arkkitehtuurivirheitä, testien puutetta tai ratkaisuja, jotka olivat joskus nopeita mutta haittaavat nyt kehitystä.
Samaan aikaan on olemassa myös toisenlainen velka. Tietovelka.
Se syntyy silloin, kun järjestelmä on riippuvainen tiedosta, jota ei ole dokumentaatiossa, repositoriossa, prosesseissa eikä organisaatiossa, vaan tiettyjen ihmisten päässä.
Ja niin kauan kuin nämä ihmiset ovat tavoitettavissa, kaikki voi näyttää normaalilta.
Ongelma ilmenee tiimin vaihtuessa, kehittäjän lähtiessä, yhteistyön päättyessä softatalon kanssa, palvelimen kaatuessa, ylläpitäjän vaihtuessa tai uuden ratkaisun kiireellisen käyttöönoton yhteydessä.
Yhtäkkiä käy ilmi, että yrityksellä on koodi, mutta ei tietoa.
Sillä on palvelin, mutta ei varmuutta siitä, kenellä on pääsy.
Sillä on integraatio, mutta ei tiedetä, millä tilillä se on luotu.
Sillä on dokumentaatio, mutta ei tiedetä, mikä versio siitä on ajantasainen.
Sillä on prosessi, mutta ei tiedetä, miksi se on suunniteltu juuri niin.
Ja silloin nousee hyvin nopeasti kysymys: kuka oikeastaan omistaa tämän järjestelmän?
Bus factor, eli mitä tapahtuu, jos yksi ihminen katoaa?
IT-maailmassa käytetään käsitettä bus factor. Yksinkertaistettuna se tarkoittaa niiden henkilöiden määrää, joiden poissaolo voi johtaa siihen, että tiimi ei enää pysty kehittämään tai ylläpitämään projektia tehokkaasti.
Kyse ei tietenkään ole kirjaimellisesta tapahtumasta. Se on tapa ajatella tiedon keskittymistä.
Jos vain yksi henkilö tietää, miten kriittinen integraatio toimii, kyseisen tiedon bus factor on yksi.
Jos vain yhdellä ylläpitäjällä on pääsy tuotantoon, bus factor on yksi.
Jos vain yksi ihminen tietää, miksi järjestelmä suorittaa tietyn prosessin joka yö, bus factor voi olla yksi.
Jos yritys tekee yhteistyötä ulkoisen softatalon kanssa ja asiakkaan puolella kukaan ei ymmärrä ratkaisun arkkitehtuuria, ongelma kasvaa entisestään - tieto voi sijaita organisaation ulkopuolella.
Tämä ei tarkoita, että jokaisella yrityksellä pitäisi olla viisi asiantuntijaa jokaisesta järjestelmän osasta.
Kyse on paljon yksinkertaisemmasta asiasta: yrityksen pitäisi tietää, missä kriittinen tieto sijaitsee ja pystyykö se palauttamaan sen ilman tiettyä henkilöä.
Koodi kertoo miten. Ei aina miksi.
Ohjelmistokehittäjä voi lukea koodia ja ymmärtää, mitä tietty funktio tekee.
Hän ei kuitenkaan aina tiedä, miksi se on kirjoitettu juuri sillä tavalla.
Se on valtava ero.
Voi löytää osan, joka vastaa tietojen lähettämisestä ulkoiseen järjestelmään. Voi analysoida endpointin, parametrit, autentikoinnin ja virheenkäsittelyn.
Mutta koodi ei välttämättä vastaa kysymyksiin:
- Miksi tiedot lähetetään klo 2.00 yöllä?
- Miksi tämä tietty status ohitetaan?
- Miksi järjestelmä yrittää uudelleen täsmälleen kolme kertaa virheen jälkeen?
- Miksi yksi arvo lasketaan uudelleen ennen lähettämistä?
- Miksi näiden toimintojen järjestystä ei voi muuttaa?
- Miksi tämä integraatio käyttää tiettyä tiliä?
Vastaus voi löytyä projektin historiasta, vanhasta tiketistä, kuusi vuotta vanhasta sähköpostista tai - mikä pahempaa - vain sen henkilön muistista, joka ei enää työskentele yrityksessä.
Siksi hyvän dokumentaation ei pitäisi olla pelkkä ohje siitä, "mitä klikata".
Sen pitäisi tallentaa myös konteksti ja päätökset.
Suurin ongelma voi olla integraatio, jota kukaan ei enää muista
Nykyaikainen järjestelmä toimii lähes koskaan täysin itsenäisesti.
Se yhdistyy ERP-järjestelmään. CRM:ään. Maksuyhdyskäytävään. SMS-palveluntarjoajaan. Kuljetusjärjestelmään. Kumppanin API:in. Pilvipalveluun. Analytiikka-alustaan. Kirjanpitojärjestelmään. Valtuutusmekanismiin.
Jokainen tällainen yhteys on osa teknologista ketjua.
Ja jokaisella ketjun osalla voi olla oma omistajansa, tilinsä, API-avaimensa, sertifikaattinsa, sopimuksensa, rajoituksensa, API-versionsa ja elinkaarensa.
Muutaman vuoden kuluttua kukaan ei ehkä enää muista, kuka loi kyseisen tilin.
Ja silloin jo sertifikaatin vanhentuminen tai API:n muutos riittää siihen, että järjestelmä lakkaa toimimasta.
Paljon pahempaa on, jos yritys ei edes tiedä kyseisen riippuvuuden olemassaolosta.
Siksi kypsässä järjestelmien hallinnassa ohjelmiston provenienssi, riippuvuuksien hallinta ja ohjelmiston toimitusketjun läpinäkyvyys korostuvat yhä enemmän. NIST nostaa nykyisissä toimitusketjun turvallisuutta koskevissa materiaaleissaan esiin muun muassa komponentteja, niiden alkuperää, elinkaarta ja riippuvuuksia koskevan tiedon merkityksen. SBOM eli Software Bill of Materials on yksi työkaluista, joiden avulla voidaan järjestää tieto siitä, mistä komponenteista ohjelmisto koostuu.
Tämä ei ole enää vain tietoturvatiimin asia.
Se on myös johdon asia.
Jos yritys ei tiedä, mistä sen järjestelmä on rakennettu, sen on vaikeampi arvioida riskiä, ylläpitokustannuksia ja muutosten seurauksia.
Dokumentaatio ei ole kustannus. Se on vakuutus.
Monissa yrityksissä dokumentaatiota pidetään asiana, joka "tehdään myöhemmin".
Ensin toiminnallisuus.
Sitten käyttöönotto.
Sitten korjaukset.
Sitten seuraava projekti.
Ja dokumentaatio?
"Kunhan on aikaa."
Ongelma on siinä, että aikaa dokumentaatiolle löytyy yleensä vasta silloin, kun on jo liian myöhäistä.
Dokumentaation pitäisi toimia kuin liiketoiminnan vakuutus. Ei siksi, että joku lukisi sitä joka päivä. Päinvastoin - sen toivottavasti tarvitsee harvoin hätätilanteessa.
Mutta kun ongelma tapahtuu, yrityksellä pitäisi olla mahdollisuus vastata peruskysymyksiin:
- Miten järjestelmä toimii?
- Mistä se koostuu?
- Missä tuotantoympäristö on?
- Kenellä on pääsy?
- Mitkä ovat kriittiset integraatiot?
- Mitä ulkoisia tilejä ja palveluja käytetään?
- Mitkä ovat riippuvuudet?
- Miten varmuuskopiot tehdään?
- Millainen on käyttöönottoprosessi?
- Mitä tapahtuu häiriön aikana?
- Mitkä osat ovat liiketoiminnan kannalta kriittisiä?
- Miksi keskeiset arkkitehtuuripäätökset tehtiin?
- Kuka voi ottaa järjestelmän ylläpidon hoitaakseen?
Tämä ei välttämättä tarkoita satoja sivuja dokumentaatiota.
Hyvän dokumentaation tulee ennen kaikkea olla hyödyllistä, ajantasaista ja oikeiden ihmisten saatavilla.
"Älkää koskeko siihen, koska se toimii" ei aina ole huono päätös
On vielä yksi hyvin yleinen ongelma.
Järjestelmä on toiminut vuosia, joten yritys noudattaa periaatetta: "Ei kosketa. Toimii."
Ja joskus se on täysin järkevää.
Jokainen vanha teknologia ei vaadi välitöntä vaihtamista. Kaikkea vanhaa koodia ei tarvitse kirjoittaa uudelleen. Jokainen kirjasto ei merkitse katastrofia. Jokainen muutaman vuoden takainen arkkitehtuuri ei ole väärä.
Ongelma alkaa silloin, kun "älkää koskeko" tarkoittaa myös:
- "Älkää analysoiko."
- "Älkää dokumentoiko."
- "Älkää tarkistako riippuvuuksia."
- "Älkää kysykö, kenellä on pääsy."
- "Älkää tarkistako, onko meillä edelleen kaikki tilit."
- "Älkää päättäkö, mitä tapahtuu, jos nykyinen toimittaja ei ole enää käytettävissä."
Silloin muutosten puute ei ole strategia.
Se on riskin lykkäämistä.
Joskus paras tekninen päätös on todella olla rakentamatta mitään uudelleen.
Mutta tämän päätöksen pitäisi perustua järjestelmän tuntemukseen, ei järjestelmän tuntemuksen puutteeseen.
Mitä perityn järjestelmän auditoinnin pitäisi kattaa?
Kun yritys ottaa järjestelmän haltuunsa toiselta ohjelmistotalolta, freelancerilta tai sisäiseltä tiimiltä, ensimmäinen askel ei saisi olla kaiken automaattinen uudelleenkirjoittaminen.
Ensin on ymmärrettävä, mitä oikeastaan on otettu haltuun.
Auditoinnin pitäisi vastata ainakin muutamaan perustavanlaatuiseen osa-alueeseen.
Arkkitehtuuri. Miten järjestelmä on rakennettu? Mitkä ovat sen tärkeimmät komponentit? Missä data sijaitsee? Miten yksittäiset osat kommunikoivat keskenään?
Koodi ja repositoriot. Onko yrityksellä täydellinen lähdekoodi? Tiedetäänkö, mikä haara ja versio on tuotannossa? Onko rakentamis- ja käyttöönottoprosessi mahdollista toistaa?
Infrastruktuuri. Missä tuotanto toimii? Millainen testiympäristö on? Kenellä on pääsy? Millainen valvonta ja varmuuskopiointi on?
Integraatiot. Mihin järjestelmä kommunikoi? Mitä API-rajapintoja se käyttää? Kuka omistaa yksittäiset tilit ja avaimet?
Riippuvuudet. Mitä kirjastoja, kehyksiä ja ulkoisia komponentteja käytetään? Päivitetäänkö niitä? Onko niissä tunnettuja tietoturvaongelmia? Millainen niiden elinkaari on?
Käyttöönottoprosessi. Pystyykö uusi henkilö valmistelemaan, testaamaan ja ottamaan muutoksen käyttöön ilman soittoa entiselle kehittäjälle?
Tieto. Mitä dokumentaatiossa on, ja mikä on edelleen vain ihmisten muistissa?
Liiketoimintariski. Mitä tapahtuu, jos tietty komponentti lakkaa toimimasta tunniksi, päiväksi tai viikoksi?
Nykyaikainen lähestymistapa ohjelmistojen toimitusketjun turvallisuuteen korostaa yhä vahvemmin juuri tarvetta tietää komponenteista, toimittajista, riippuvuuksista, niiden alkuperästä ja elinkaaresta. NIST korostaa myös teknologia-toimittajiin kohdistuvan due diligence -arvioinnin sekä koko toimitusketjuun liittyvän resilienssin ja riskin arvioinnin merkitystä.
Auditointi ei tarkoita "kirjoitetaan järjestelmä kokonaan uudelleen"
Tämä on tärkeää, koska tekninen auditointi sekoitetaan usein virheellisesti uudelleensuunnitteluun.
Todellisuudessa auditointi voi päättyä hyvin yksinkertaiseen johtopäätökseen: "Järjestelmä on kunnossa. Tarvitaan vain tiedon järjestämistä ja muutaman riskin poistamista."
Voi myös käydä ilmi, että järjestelmä tarvitsee modernisointia vain yhdellä alueella.
Tai että suurin ongelma ei ole koodi, vaan pääsyn puute infrastruktuuriin.
Tai että sovellus on hyvin tehty, mutta kukaan ei tunne ajantasaista käyttöönottoprosessia.
Tai että kaikki toimii, mutta yritys on riippuvainen yhdestä ulkoisesta toimittajasta.
Siksi hyvässä perityn projektin analyysissä pitäisi vastata kysymykseen: "Mitä todella pitää muuttaa, ja mitä ei tarvitse koskea?"
Vasta silloin voidaan tehdä investointipäätöksiä.
Entä jos vaihdat ohjelmistotaloa?
Se on yksi niistä hetkistä, jolloin näkymättömän tietovelan ongelma tulee esiin.
Yritys päättää yhteistyön toimittajan kanssa.
Uusi kumppani saa repositorion.
Ja alkaa esittää kysymyksiä:
- "Missä tuotanto on?"
- "Miten projekti käynnistetään paikallisesti?"
- "Mikä versio on ajantasainen?"
- "Mihin tätä palvelua käytetään?"
- "Kuka omistaa tämän API:n tilin?"
- "Mitä tämä cron tekee?"
- "Miksi tämä prosessi käynnistyy tähän aikaan?"
- "Mistä saamme tämän parametrin?"
- "Mitä tapahtuu, jos poistamme sen käytöstä?"
Jos vastaukseksi useimpiin kysymyksiin tulee "emme tiedä", uusi ohjelmistotalo ei ota projektia haltuunsa. Ensin sen täytyy selvittää se.
Ja järjestelmän selvittäminen maksaa aikaa. Aikaa, jonka asiakas maksaa myöhemmin.
Siksi projektin siirron tiimien välillä pitäisi olla prosessi, ei pelkkä ZIP-tiedoston heitto koodista ja yhden tilin salasanasta.
Järjestelmän pitäisi selvitä ihmisistä huolimatta
Se on ehkä tärkein periaate.
Ihmiset muuttuvat. Kehittäjät vaihtavat työpaikkaa. Freelancerit lopettavat yhteistyön. Ohjelmistotalot vaihtavat asiakkaita. Ylläpitäjät siirtyvät muihin yrityksiin. Johto vaihtuu.
Järjestelmä pysyy.
Siksi järjestelmä pitäisi suunnitella niin, että sen ylläpitoon tarvittava tieto on mahdollista palauttaa.
Tämä ei tarkoita, että jokaisen työntekijän pitäisi tietää kaikki.
Se tarkoittaa, että organisaatiolla pitäisi olla tiedon säilyttämisen mekanismi:
- Repositiot.
- Dokumentaatio.
- Integraatioiden rekisteri.
- Tietoja infrastruktuurista.
- Yrityksen hallinnoimat käyttöoikeudet.
- Keskeisten prosessien kuvaus.
- Merkittävien päätösten historia.
- Tietoa riippuvuuksista.
- Hätätilanneproseduurit.
- Ja ennen kaikkea - ihmiset, jotka osaavat käyttää tätä dokumentaatiota.
NIST kiinnittää nykyisissä järjestelmien tietoturvan suunnittelua koskevissa ohjeissaan huomiota myös vastuiden, järjestelmän operatiivisen tilan sekä niiden henkilöiden roolien viralliseen määrittelyyn, jotka hallinnoivat järjestelmää, tukevat sitä tai joilla on siihen pääsy.
Tämä osoittaa laajemman muutoksen tavassa ajatella teknologiaa.
Järjestelmä ei ole vain koodia. Järjestelmä on myös ihmisiä, prosesseja, infrastruktuuri, riippuvuudet, data, pääsy ja vastuu.
Web24:ssä aloitamme usein juuri kysymyksellä: "Mitä täällä oikeastaan on?"
Olemassa olevan projektin haltuunoton ei pitäisi alkaa lupauksella, että kaikki kirjoitetaan uudelleen alusta.
Sen pitäisi alkaa tilanteen ymmärtämisestä:
- Mikä toimii?
- Mikä ei toimi?
- Mikä on kriittistä?
- Mikä on vanhentunutta?
- Missä ovat suurimmat riskit?
- Mitä dokumentaatiosta puuttuu?
- Mitkä riippuvuudet ovat näkymättömiä?
- Voiko olemassa olevaa järjestelmää kehittää turvallisesti?
- Tarvitaanko modernisointia vai pelkkää järjestyksen palauttamista?
Vasta sitten voidaan päättää, tuleeko projektia kehittää, rakentaa uudelleen, kirjoittaa osittain uudestaan vai vain dokumentoida se kunnolla.
Tämä on erityisen tärkeää projekteissa, joita on vuosien ajan kehittänyt monta eri ihmistä ja eri yritystä.
Sillä hyvää teknologiakumppania ei pitäisi tarvita siksi, että vain hän tietää, miten järjestelmä toimii.
Häntä pitäisi tarvita siksi, että hän osaa kehittää tätä järjestelmää, turvata sen ja siirtää osaamista eteenpäin.
Vaarallisin virhe voi olla jo lähtenyt ihminen
Aina ongelma ei ole vanha koodi.
Aina ongelma ei ole vanhentunut teknologia.
Aina ongelma ei ole uudemman frameworkin puute.
Joskus suurin riski on tieto, jota kukaan ei kirjoittanut ylös.
Yksi iskulause.
Yksi arkkitehtuuripäätös.
Yksi integraatio.
Yksi poikkeus prosessissa.
Yksi ihminen, joka tiesi vuosien ajan, miten se toimii.
Ja sitten hän lähti.
Siksi kannattaa kysyä itseltään tänään hyvin yksinkertainen kysymys: Jos huomenna yrityksestä katoaisi henkilö, joka tuntee järjestelmänne parhaiten, pystyisitteko silti hallitsemaan sitä?
Jos vastaus on "kyllä" - hienoa.
Jos vastaus on "en tiedä" - kannattaa selvittää asia.
Ja jos vastaus on "ei todellakaan" - olette todennäköisesti juuri löytäneet yhden yrityksenne tärkeimmistä teknologisista riskialueista.
Järjestelmän pitäisi olla suurempi kuin yhden ihmisen muisti.
