Arendaja kadus — mis saab meie tarkvarast?

Ühel päeval ei vasta arendaja enam e-kirjadele. Või teatab agentuur, et lõpetab tegevuse. Või läheb ainus inimene, kes süsteemi tundis, pensionile või teise firmasse. Rakendus töötab esialgu edasi — arveid tehakse, tellimusi võetakse vastu —, aga keegi ei tea enam, kuidas see sees käib ja mis juhtub, kui midagi katki läheb.

See olukord on sagedasem, kui arvata võiks, ja enamasti ei ole see katastroof. Katastroofiks muutub see siis, kui esimestel nädalatel tehakse valed otsused. Allpool on järjekord, mida ise sellises olukorras soovitan.

Esimene samm: kindlusta ligipääsud

Kõige suurem oht ei ole see, et kood on halb. Kõige suurem oht on see, et sul ei ole selle üle kontrolli. Enne kui midagi muud teed, tee nimekiri ja kontrolli, kas need on sinu käes:

• Koodihoidla (GitHub, GitLab, Bitbucket või muu) — kelle kontol see on ja kas sul on omaniku- või administraatoriõigus?
• Server või majutus — kelle nimel on leping, kes maksab arveid, kas sul on SSH- või paneeliligipääs?
• Domeen — kelle nimele see on registreeritud ja millal aegub? Aegunud domeen on kõige kiirem viis teenus maha võtta.
• Andmebaas — kus see asub ja kas sul on kasutajanimi ja parool?
• Välisteenused — e-posti saatmine, makselahendus, pilvesalvestus, API-võtmed. Paljud neist on registreeritud arendaja isikliku e-posti peale.

Kui arendajaga on veel side olemas, palu tal kõik ligipääsud üle anda kohe, mitte „kui aega on". Kui sidet ei ole, alusta sellest, mis on sinu nimel — domeeniregistripidaja ja majutuspakkuja taastavad ligipääsu üldjuhul omanikule, kui suudad omandi tõendada.

Teine samm: tee varukoopia enne, kui midagi puutud

Kui ligipääs on käes, tee täielik varukoopia: kood, andmebaas, üleslaaditud failid ja serveri seadistus. Mitte sellepärast, et midagi oleks praegu katki, vaid sellepärast, et järgmistel nädalatel hakkab keegi süsteemis tegutsema — ja siis on vaja teada, milline see enne oli.

Kontrolli ka, kas automaatsed varukoopiad üldse tehakse ja kuhu. Tihti selgub, et varundus käis arendaja enda masinasse või on mõne kuu eest vaikselt seiskunud.

Kolmas samm: ära hakka paanikas uut süsteemi ehitama

Esimene reaktsioon on sageli: „Kirjutame kogu asja nullist ümber, siis on vähemalt kõik meie kontrolli all." See on peaaegu alati vale esimene samm.

Töötav süsteem sisaldab aastate jooksul kogunenud ärireegleid, erandeid ja parandusi, mida ükski spetsifikatsioon ei kirjelda. Ümberkirjutamine tähendab, et need tuleb kõik uuesti avastada — tavaliselt alles siis, kui midagi juba valesti läheb. Samal ajal peab vana süsteem edasi töötama, ilma et keegi seda hooldaks.

Mõistlik järjekord on teistsugune: kõigepealt tee olemasolev süsteem stabiilseks ja arusaadavaks, siis otsusta, kas seda tasub edasi arendada või osade kaupa välja vahetada.

Kuidas ma võõra koodi üle võtan

Olen veebiprojekte teinud alates 2014. aastast ja taastanud riigi- ja erasektoris üle kümne aasta vanuseid rakendusi, mille algne arendaja oli ammu läinud. Töö käib alati samas järjekorras.

1. Audit. Vaatan läbi, millest süsteem koosneb: programmeerimiskeel ja raamistikud, nende versioonid, andmebaas, serveri seadistus, välised sõltuvused. Selgitan välja, mis on aegunud, mis on turvarisk ja mis töötab hästi.

2. Dokumenteerimine. Kirjutan üles, kuidas süsteem on üles ehitatud, kuidas seda käivitada ja kus mis asub. See dokument jääb sulle — järgmine kord ei pea keegi otsast alustama.

3. Kohalikult tööle saamine. Enne kui midagi muudan, panen süsteemi tööle eraldi keskkonnas, mis ei puuduta päris kasutajaid. Ainult nii saab muudatusi turvaliselt proovida.

4. Väikesed ja ohutud parandused. Esimesed muudatused on teadlikult väikesed: turvauuendused, kõige pakilisemad vead, varunduse korda tegemine. Iga muudatus on jälgitav ja vajadusel tagasi pööratav.

5. Alles siis suuremad sammud. Kui süsteem on stabiilne ja arusaadav, saab rääkida komponentide uuendamisest uutele versioonidele ja uue funktsionaalsuse lisamisest. Varasemates projektides on just see järjekord võimaldanud ärilise funktsionaalsuse täielikult säilitada ja seejärel uut juurde arendada.

Kui rakendus jookseb Linuxi serveris, võtan vajadusel üle ka serveri halduse — tihti on serveri seadistus sama dokumenteerimata kui kood ise. Kui server on vaja hoopis vahetada, on sellest eraldi juttu postituses serveri kolimine ilma seisakuta.

Hoiatusmärgid, et olukord on kriitilisem

Mõnel juhul ei saa oodata. Võta kiiresti ühendust kellegagi, kes oskab süsteemi üle vaadata, kui:

• serveri operatsioonisüsteem või raamistik on toeta jäänud ja turvauuendusi enam ei tule;
• domeeni või sertifikaadi aegumine on lähinädalatel;
• varukoopiaid ei ole või neid ei ole kunagi taastamiseks proovitud;
• süsteem on hakanud aeglustuma või vahel „ise" seiskuma;
• keegi ei tea, kus asub lähtekood — on olemas ainult serveris jooksev versioon.

Viimane on keerulisem, aga ka sellest saab edasi. Aegunud komponentide ohtudest laiemalt räägib postitus uuendamata WordPressi ja moodulite ohud — põhimõte kehtib iga platvormi kohta.

Kuidas edaspidi sama olukorda vältida

Kui süsteem on jälle kontrolli all, tasub paika panna kolm asja: kõik ligipääsud on ettevõtte, mitte isiku nimel; kood on koodihoidlas, millele on ligipääs vähemalt kahel inimesel; ning olemas on lühike dokument selle kohta, kuidas süsteemi käivitada ja taastada. See ei maksa palju, aga järgmine arendaja vahetus ei ole siis enam kriis.

Kirjuta mulle

Kui su arendaja on kadunud ja süsteem töötab veel, aga keegi ei julge seda puutuda, kirjelda oma olukorda paari lausega siin — vastan ühe tööpäeva jooksul ja ütlen ausalt, kas ja kuidas saan aidata. Konfidentsiaalsusleping on minu jaoks tavapärane, nii et koodi ja andmeid võib julgelt näidata. Kui eelistad lihtsalt rääkida, leiad muud võimalused kontaktilehelt.

Kas ma saan süsteemi üle võtta, kui lähtekoodi ei ole?

Sageli jah, aga see sõltub tehnoloogiast. Osa rakendusi (nt PHP-põhised) jooksevad serveris lähtekoodina ja kood on seega olemas. Kompileeritud rakenduste puhul on töö mahukam. Vaatan selle auditi käigus üle.

Kas pean kohe otsustama, kas süsteem kirjutatakse ümber?

Ei. Esmalt tuleb süsteem stabiilseks ja arusaadavaks teha. Otsus edasiarenduse või väljavahetamise kohta on palju lihtsam, kui on teada, mis seal sees on.