|
Kiek kartų tau buvo sakyta: daryk atsargines kopijas, tikrink, tikrink ir dar kartą tikrink prieš užkeldamas pakeitimus. Kiek kartų? Ir vistiek ateina ta diena, kai visų klaidų „neišmedžiojai“, atsarginės kopijos neturi ir... būtent tada tavo atnaujinimas visiškai užlaužia sistemą.
Nemalonus jausmelis. Ir ne vienam, ko gero, teko jį patirti. Atrodo, kaip galima taip neapdairiai pasielgti. Ir aš tuo stebėjausi... Iki tol, kol pats patyriau nelinksmą nuotykį. Tad slėpkime tas savo nuostabas, kad kažkas neapsižiūrėjo ir yra žioplys. Tai gali nutikti kiekvienam, nes visi mes – žmonės. Jei kompiuteriai daro klaidas, tai kaip žmogus gali jų nepadaryti? Bet šiandien ne apie tai, kas ir kiek skaudžiai nukentėjo dėl to, kad ne viską iki galo sužiūrėjo. Šiandien – apie tai, ką daryti, kai jau post factum.
Kiekvienas save gerbiantis programuotojas visada stengiasi sumažinti klaidų tikimybę iki minimumo. Ypač tada, kai tai liečia vartotojus, kurie sistema naudojasi nemokšiškai. Stengiamasi sistemą sukurti taip, jog kad ir kokie neteisingi būtų vartotojų veiksmai, padaryta žala būtų minimali. Bet beveik visais atvejais programuotojai besistengdami apsisaugoti nuo vartotojų klaidų pamiršta, kad ir patys jas daro. O kas apsaugos nuo programuotojo klaidų? Vienas iš būdų – automatizuoti testai, kurie iškart po bet kokių pakeitimų parodo, jei kažkas netaip. Bet kad ir kaip būtų bandoma apsisaugoti unit testais, skylių vistiek gali likti. Be to, unit testai praranda savo prasmę, kai kalbama apie esminį sistemos perdarymą.
Įsivaizduokime, kad ir unit testai nepadeda apsisaugoti nuo žioplos programuotojo klaidos ir ji įvyksta, sugriaudama visą sistemą (sugriovimas šiuo atveju yra duomenų bazės duomenų praradimas arba sumaišymas). Tokiu atveju būtų gerai, jei išsigelbėjimui tiktų serveryje atlikta paros atsarginė kopija. Būtų gerai ir tada, jei būtum pasidaręs kopiją lokaliai. Bet kopijos tu neturi, o vakarykštė versija netinka. Įsivaizduok, kad tau reikia vos ne kelių minučių senumo duomenų. Ką tada darai? Štai ir situacija, iš kurios kaip ir nėra išeities. Bet ji būtų, jei apie tai būtų pagalvota kuriant atitinkamą sistemą.
Kuriant bet kokią sudėtingesnę sistemą visada turi būti įvertinamas faktas, kad gali įvykti milžiniška klaida, kad gali prireikti greitai atstatyti kuo naujesnius duomenis. Be to, reikia įsileisti į galvą idėją, kad, nepriklausomai nuo apsaugų, vistiek gali įvykti rimta klaida – ar dėl vartotojo kaltės, ar dėl programuotojo, ar serverių lūžimo. Būtent čia yra svarbiausia akimirka – kas bus, jei lūš, kaip atstatysiu duomenis? 99% atvejų apie tai negalvojama – tiesiog pasikliaunama atsarginėmis kopijomis ar savo atidumu. Mano patirtis rodo, kad tuo pasikliauti 100% negalima.
Todėl jau projektuojant sistemą reikia įvertinti galimas klaidų pasekmes ir jų atstatymo būdus bei efektyvumą. Jei į tai bus atsižvelgta ir bus sudėliotas veiksmų planas, įvykus net ir kritinėms klaidoms (panašiai, kaip lėktuvuose, jei įvyksta avarija – yra manual'as su galimomis situacijomis) gyvenimas bus lengvesnis.
O mūsų, web sistemų kūrėjų, pasaulyje svarbiausia vieta yra duomenų bazė. Jei duomenų yra daug ir jie nuolat atsinaujina, tai jokiais būdais negalima pasikliauti pirminiu jų šaltiniu. RAW žaliava niekada negali būti įtakojama jokių apdorojimo mechanizmų. Vienintelis dalykas, ką su ja galima daryti – tai nuskaityti. O jau iš šios medžiagos galima daryti kažkokius modelius. Naudojant tokį principą, visada bus galima reversinti bet kokius įvykius iki paskutinio kaupto taško kokiu tik nori tikslumu. Žinoma, norint turėti tokį reverse variklį, reikia pakurti galingą statistikos modulį. Bet jei kuriama sistema akivaizdžiai to prašosi, kodėl to nepadarius? Gal tai apsaugos nuo tokios klaidos, kuri gali kainuoti ne vieną tūkstantį litų? Gerai, kad mano klaida nebuvo itin skausminga. Bet ir ji privertė susimąstyti – o kas, jeigu?
Pats laikas susivokti, kad internetas nėra vien tik elementarūs reprezetanciniai puslapiukai ir kreivai sulipdyti pažinčių ar naujienų portalai. Su kiekviena diena jam yra kuriamos vis sudėtingesnės sistemos, o nepatyrę programuotojai vis dar taiko mažiems puslapiams skirtus kūrimo principus. To tiesiog negalima leisti. Jautrių duomenų sistema turi būti išanalizuota ir suprojektuota tam, kad jos ne tik vartotojas, bet ir idiotas programuotojas negalėtų sugriauti.
Pabaigai – keletas patarimų, kaip iki minimumo sumažinti avarijų skaičių ar susitvarkyti jau joms įvykus:
1. Jei laukia koks rimtesnis duomenų pakeitimas, niekada jo nedarykite dienos pabaigoje.
2. Jei jaučiatės pavargę ar nepavyksta susikaupti – nukelkite atnaujinimą į kitą dieną.
3. Esant galimybei visada pasikonsultuokite su serverių administratoriais. Gal jie pasiūlys efektyvų atsarginių kopijų darymo ir atstatymo planą.
4. Ištikus bėdai – nepanikuokite. Išeikite įkvėpti gryno oro kelioms minutėms. Grįžę sistemiškai analizuokite padarytą žalą.
5. Jei yra žmonių, kurie galėtų padėti ieškoti sprendimo – būtinai klauskite.
6. (Už šitą galiu velnių gauti :)) Niekados nesakykite valdžiai, nes jos nekokia reakcija ir skubinimas sutvarkyti tik dar labiau apsunkins padėtį. Apie įvykį galima pasipasakoti po to, kai pavyksta sutvarkyti arba, blogiausiu atveju – kai nepavyksta.
7. Ir galiausiai – visados įvertinkite duomenų jautrį. Kad ir koks atrodytų mažas ir nereikšmingas pakeitimas, neleiskite sau dėl to atsipalaiduoti.
|
