See juhtub tavaliselt vaikselt. Arendaja, kes ehitas su süsteemi, teatab lahkumisest, viimane töönädal lendab mööda ja siis on ta läinud. Järgmisel nädalal küsib keegi, kuidas midagi muuta, ja selgub, et keegi majas ei tea, kus kood asub, mis paroolid kehtivad ega mille otsas server üldse töötab.
Paanika on loomulik reaktsioon, aga see on ka kõige kallim reaktsioon. Siin on rahulik ja järjekindel plaan, kuidas seda olukorda käsitleda, ilma et teeksid asja hullemaks.
Esimene reegel: ära lase kellelgi kohe „lihtsalt ümber kirjutada”
Kõige levinum viga on kutsuda kohale uus arendaja, kes vaatab olematut dokumentatsiooni, ohkab ja pakub: „Lihtsam on see nullist üles ehitada.” See on sageli tõsi tema jaoks, sest tema jaoks on olemasoleva süsteemi mõistmine aeglasem kui uue kirjutamine. Sinu jaoks tähendab see aga kuid tööd, mille jooksul vana süsteem peab ikkagi töötama, ja rahasummat, mis ületab tegeliku probleemi mitmekordselt.
Enne kui keegi kirjutab ühtegi uut rida koodi, tuleb aru saada, mis olemasoleval süsteemil viga on. Sageli selgub, et probleem ei ole kood ise, vaid see, et keegi ei tea, kuidas seda hallata.
Mida tuleb kõigepealt üles leida
Enne mistahes tehnilist otsust pead teadma, kus süsteem elab, kes sellele ligi pääseb, kust kood pärineb ja mis on juba dokumenteeritud. Käi need läbi süsteemselt, mitte mälu järgi.
- Domeen ja DNS. Kus on domeen registreeritud ja kelle kontol? Kes juhib DNS-kirjeid?
- Majutus ja serverid. Kus süsteem füüsiliselt töötab (AWS, mõni Eesti majutaja, arendaja enda server)? Kellele kuulub konto ja kes maksab arve?
- Lähtekood. Kas on olemas versioonihaldus (GitHub, GitLab vms)? Kas viimane töötav versioon on üldse seal, või on serveris kood, mida repos ei ole?
- Andmebaas ja varukoopiad. Kus andmed asuvad ja kas on olemas taastatavaid varukoopiaid?
- Kolmandate osapoolte teenused. Makseteenus, e-kirjade saatja, kaardid, analüütika, API võtmed. Iga selline teenus on eraldi konto, mille juurde vajad ligipääsu.
- Dokumentatsioon (kui seda on). Isegi paar lehekülge märkmeid või README on parem kui mitte midagi.
Kui osa neist on kättesaamatu, sest arendaja ei vasta, on see infoturbe küsimus, mitte ainult ebamugavus: keegi väljastpoolt firmat omab endiselt ligipääsu sinu süsteemidele. See tuleb lahendada esimesena, isegi enne tehnilist analüüsi.
Tehniline audit ilma paanikata
Kui ligipääsud on käes või vähemalt kaardistatud, on aeg lasta sõltumatul inimesel süsteem läbi vaadata. Hea audit ei ütle „see kõik on jama”, vaid annab konkreetse pildi: mis tehnoloogial süsteem töötab, kui vana see on, kus on suurimad riskid (turvaaugud, aegunud sõltuvused, puuduvad varukoopiad) ja mis töötab tegelikult päris hästi.
Sellise auditi eesmärk ei ole leida süüdlast, vaid anda sulle otsustamiseks fakte, mitte hirmu. Mõnikord selgub, et süsteem on tehniliselt korras ja probleem oli ainult see, et keegi ei osanud seda hallata. Mõnikord selgub, et vundament on tõesti nõrk ja vajab plaanipärast uuendamist. Kumbki vastus on parem kui teadmatus.
Stabiliseeri enne, kui teed suuri otsuseid
Enne suuri arhitektuuriotsuseid tasub süsteem lihtsalt stabiilsesse seisu viia: ligipääsud korras, varukoopiad olemas ja testitud, kriitilised turvaparandused paigaldatud, keegi jälgib, kas süsteem üldse töötab. Sellest hetkest ei pea sa enam tulekahjusid kustutama ja saad rahulikult otsustada, kas süsteem vajab järkjärgulist uuendamist, ümberehitust või on tegelikult sinu ärile piisavalt hea niisugusena.
- Kas midagi on parasjagu katki või lekib andmeid? Kui jah, siis see läheb esimesena.
- Kas varukoopiad tekivad ja on taastatavad? Kui ei, siis see on järgmine.
- Kas keegi näeb, kui süsteem maha jookseb? Kui ei, lisa seire.
- Kas ligipääsud on nüüd ainult nende käes, keda usaldad? Kontrolli üle.
Kui su ettevõte on täpselt selles olukorras, siis esimene samm ei ole uue arendaja otsimine, vaid selge pilt sellest, mis sul praegu on. Tehnilise auditi ja koodiülevaate teen IT-konsultatsiooni raames. Kui vajad pärast seda kedagi, kes hoiab IT-l pidevalt silma peal ja räägib arendajatega sinu nimel, vaata osalise ajaga IT-juhi teenust.
Kirjuta mulle lühidalt, mis on juhtunud ja mis süsteemiga tegu, ning räägime, kuidas kõige kiiremini stabiilsesse seisu jõuda.