Kehittäjä lähti — mitä ohjelmistolle nyt tapahtuu?

Eräänä päivänä kehittäjä lakkaa vastaamasta sähköposteihin. Tai ohjelmistotoimisto ilmoittaa lopettavansa. Tai ainoa järjestelmän tuntenut ihminen jää eläkkeelle tai vaihtaa työpaikkaa. Sovellus toimii toistaiseksi — laskut lähtevät, tilaukset tulevat —, mutta kukaan ei enää tiedä, miten se sisältä toimii tai mitä tapahtuu, kun jokin hajoaa.

Tilanne on yleisempi kuin luulisi, eikä se yleensä ole katastrofi. Katastrofiksi se muuttuu, jos ensimmäisinä viikkoina tehdään vääriä päätöksiä. Alla on järjestys, jota itse suosittelen.

Ensimmäinen askel: varmista käyttöoikeudet

Suurin riski ei ole se, että koodi on huonoa. Suurin riski on se, ettei se ole sinun hallinnassasi. Tee ennen kaikkea lista ja tarkista, onko tämä kaikki sinun käsissäsi:

• Koodivarasto (GitHub, GitLab, Bitbucket tai muu) — kenen tilillä se on, ja onko sinulla omistaja- tai ylläpitäjäoikeudet?
• Palvelin tai webhotelli — kenen nimissä sopimus on, kuka maksaa laskut, onko sinulla SSH- tai hallintapaneelin tunnukset?
• Verkkotunnus — kenen nimiin se on rekisteröity ja milloin se vanhenee? Vanhentunut verkkotunnus on nopein tapa kaataa palvelu.
• Tietokanta — missä se on, ja onko sinulla käyttäjätunnus ja salasana?
• Ulkoiset palvelut — sähköpostin lähetys, maksupalvelu, pilvitallennus, API-avaimet. Moni näistä on rekisteröity kehittäjän henkilökohtaiseen sähköpostiin.

Jos kehittäjään saa vielä yhteyden, pyydä kaikki tunnukset luovutettaviksi heti, ei "kun ehtii". Jos yhteyttä ei ole, aloita siitä, mikä on yrityksesi nimissä: verkkotunnusten välittäjät ja palveluntarjoajat palauttavat yleensä pääsyn omistajalle, kun omistus pystytään osoittamaan.

Toinen askel: ota varmuuskopio ennen kuin kosket mihinkään

Kun pääsy on hallussa, ota täydellinen varmuuskopio: koodi, tietokanta, ladatut tiedostot ja palvelimen asetukset. Ei siksi, että jokin olisi nyt rikki, vaan siksi, että seuraavien viikkojen aikana joku alkaa tehdä muutoksia järjestelmään — ja silloin on tiedettävä, millainen se oli ennen.

Tarkista myös, otetaanko automaattisia varmuuskopioita ylipäätään ja minne. Usein selviää, että ne menivät kehittäjän omalle koneelle tai ovat hiljaa lakanneet toimimasta muutama kuukausi sitten.

Kolmas askel: älä rakenna uutta paniikissa

Ensimmäinen reaktio on usein: "Kirjoitetaan koko juttu alusta, niin ainakin kaikki on omassa hallinnassa." Se on lähes aina väärä ensimmäinen siirto.

Toimiva järjestelmä sisältää vuosien aikana kertyneitä liiketoimintasääntöjä, poikkeuksia ja korjauksia, joita mikään määrittely ei kuvaa. Uudelleenkirjoitus tarkoittaa, että ne kaikki on löydettävä uudelleen — yleensä vasta kun jokin on jo mennyt pieleen. Sillä välin vanhan järjestelmän on pyörittävä ilman ylläpitäjää.

Järkevämpi järjestys on toinen: ensin nykyinen järjestelmä vakaaksi ja ymmärrettäväksi, sitten päätös siitä, kannattaako sitä kehittää edelleen vai korvata osa kerrallaan.

Miten otan vieraan koodin haltuun

Olen tehnyt verkkoprojekteja vuodesta 2014 ja palauttanut julkisella ja yksityisellä sektorilla yli kymmenen vuotta vanhoja sovelluksia, joiden alkuperäiset tekijät olivat lähteneet aikoja sitten. Työ etenee aina samassa järjestyksessä.

1. Auditointi. Käyn läpi, mistä järjestelmä koostuu: ohjelmointikieli ja kehykset, niiden versiot, tietokanta, palvelimen asetukset, ulkoiset riippuvuudet. Selvitän, mikä on vanhentunutta, mikä on tietoturvariski ja mikä toimii hyvin.

2. Dokumentointi. Kirjaan ylös, miten järjestelmä on rakennettu, miten se käynnistetään ja missä mikäkin on. Dokumentti jää sinulle — seuraavalla kerralla kenenkään ei tarvitse aloittaa tyhjästä.

3. Käyntiin erillisessä ympäristössä. Ennen kuin muutan mitään, saan järjestelmän toimimaan erillisessä ympäristössä, joka ei koske oikeisiin käyttäjiin. Vain niin muutoksia voi kokeilla turvallisesti.

4. Ensin pienet ja turvalliset korjaukset. Ensimmäiset muutokset ovat tarkoituksella pieniä: tietoturvapäivitykset, kiireellisimmät virheet, varmuuskopioinnin kuntoon laittaminen. Jokainen muutos on jäljitettävissä ja tarvittaessa peruttavissa.

5. Vasta sitten isommat askeleet. Kun järjestelmä on vakaa ja ymmärretty, voidaan puhua komponenttien päivittämisestä uusiin versioihin ja uusista toiminnoista. Aiemmissa projekteissa juuri tämä järjestys on mahdollistanut sen, että liiketoiminnallinen toiminnallisuus säilyi kokonaan ja uutta voitiin kehittää lisää.

Jos sovellus pyörii Linux-palvelimella, voin ottaa hoitaakseni myös palvelimen ylläpidon — palvelimen asetukset ovat usein yhtä dokumentoimattomia kuin koodi. Jos palvelin on vaihdettava, siitä on oma kirjoituksensa: palvelimen siirto ilman käyttökatkoa.

Varoitusmerkit: milloin ei voi odottaa

Joskus odottaminen ei ole vaihtoehto. Pyydä joku katsomaan järjestelmää nopeasti, jos:

• palvelimen käyttöjärjestelmän tai kehyksen tuki on päättynyt eikä tietoturvapäivityksiä enää tule;
• verkkotunnus tai varmenne vanhenee lähiviikkoina;
• varmuuskopioita ei ole, tai palautusta ei ole koskaan kokeiltu;
• järjestelmä on alkanut hidastua tai pysähtyy välillä "itsestään";
• kukaan ei tiedä, missä lähdekoodi on — on vain palvelimella pyörivä versio.

Viimeinen on hankalampi, mutta siitäkin pääsee eteenpäin. Vanhentuneiden komponenttien riskeistä laajemmin kertoo kirjoitus päivittämättömän WordPressin riskit — periaate pätee kaikkiin alustoihin.

Miten saman tilanteen välttää jatkossa

Kun järjestelmä on taas hallinnassa, kannattaa sopia kolmesta asiasta: kaikki tunnukset ovat yrityksen, eivät yksittäisen henkilön nimissä; koodi on varastossa, johon on pääsy vähintään kahdella ihmisellä; ja on olemassa lyhyt dokumentti järjestelmän käynnistämisestä ja palauttamisesta. Se ei maksa paljon, ja seuraava kehittäjän vaihdos ei ole enää kriisi.

Kirjoita minulle

Jos kehittäjäsi on poissa ja järjestelmä vielä toimii, mutta kukaan ei uskalla koskea siihen, kuvaa tilanteesi parilla lauseella täällä — vastaan yhden työpäivän kuluessa ja kerron rehellisesti, voinko auttaa ja miten. Salassapitosopimus on minulle tavallinen asia, joten koodia ja tietoja voi näyttää huoletta. Jos haluat mieluummin vain jutella, muut yhteystavat löydät yhteystietosivulta.

Voitko ottaa järjestelmän haltuun, jos lähdekoodia ei ole?

Usein kyllä, mutta se riippuu tekniikasta. Osa sovelluksista (esimerkiksi PHP-pohjaiset) toimii palvelimella lähdekoodina, joten koodi on käytännössä olemassa. Käännettyjen sovellusten kanssa työtä on enemmän. Tarkistan tämän auditoinnin aikana.

Pitääkö heti päättää, kirjoitetaanko järjestelmä uudelleen?

Ei. Ensin järjestelmä on saatava vakaaksi ja ymmärrettäväksi. Valinta jatkokehityksen ja korvaamisen välillä on paljon helpompi, kun tiedetään, mitä sisällä on.