Tere! Pavasaris tradiciškai yra švaros ir tvarkos laikas. Vienas iš efektyviausių būdų pradėti apsikuopimą – tinkamai įvertinti turimą situaciją, o tam gali padėti auditas. Anot vikipedijos, tai – ūkio subjekto patikrinimas, analizė ar įvertinimas. Audituoti iš esmės galima bet ką – vieni atlieka juos finansams, o, pavyzdžiui, mano kolegė Justina auditus daro ir naudotojo patirčiai įvertinti.

Lygiai taip pat mes inspektuojame ir IT sistemas. Tokius auditus galima skirstyti į dvi pagrindines grupes: vidinį, kurį atliekame sau, ir išorinį – tada, kai į mus kreipiasi klientas, ieškantis, kaip patobulinti savo turimas sistemas, kad jos veiktų patikimai ir efektyviausiai išnaudotų turimus resursus (tiek žmogiškus, tiek serverių, tiek kodo).

Na, enciklopedija dar rašo, kad auditai būna ir valstybiniai, bet juos jau palikime rimtiems dėdėms su didelėmis barzdomis.

Kada reikia audito?

Nėra vieno konkretaus atsakymo, kada geriausias metas peržiūrėti savo sistemų daržą, bet esu įsitikinęs, kad tvarką pasitikrinti būtina kaip galima dažniau. Kodėl? Todėl, kad žiniomis būtina dalintis ir dar todėl, kad gerųjų praktikų atsiranda vis naujų. Žiūrint truputį plačiau, savotišku mikro-auditu aš pavadinčiau net žodžiu išsakytą kritiką ar pastebėjimą, kas galėtų veikti geriau.

Tuo tarpu klientai į mus kreipiasi norėdami savo projektuose išsiaiškinti kelias situacijas. Pirma – kai keičia sistemos programuotojus (pradeda samdyti vidinę komandą ar tiesiog keičia įmonę, su kuria dirbo) ir nori pasižiūrėti, kur ir ką jie padarė ne taip. Antroji – kai jiems norisi padaryti pakeitimus ir suprasti, kodėl jie prie savo projektų užtrunka tokį ilgą laiką. Į šį klausimą, beje, atsakymų gali būti daug: nuo turimos sistemos iki keliamų reikalavimų specifikos.

Kaip vykdomas techninis auditas?

Techninį auditą atlieka dviejų arba trijų sričių specialistai – dažniausiai devops ir programuotojai. Jų pagrindinis tikslas – išsiaiškinti sistemos statusą, t.y., ar ji dar palaikoma, ar jau atėjo laikas ją išmesti ir pradėti galvoti apie naują. Yra ir šalutinis – pažiūrėti kurios vietos yra kertinės ir trukdančios normaliam darbui.

Auditas būna panašus į retrospektyvą – klausiama ne, kas ką padarė, ne kodėl, o ką galime padaryti kitaip, kad projektas būtų tvarkingas. Svarbiausia čia nepamiršti, kad tai nėra kaltų paieškos, o veikiau būdas pasakyti, ką būtų galima padaryti geriau. 

Atliekant auditą iš esmės keičiamės komandomis – ateina techninis žmogus ir pradeda klausinėti – o kodėl čia taip padaryta? Gal būtų galima panaudoti X sprendimą? Kodėl naudojate Y, kai Z veikia greičiau?

Ką vertiname tokio audito metu?

Karkasai ir jų versijos

Visų pirma turime atkapstyti su kokiu karkasu (-ais) dirbame. Praktikoje pasitaiko visko: tiek labai senų arba parašytų nuo 0 ir, savaime aišku, jau nebetobulinamų iki pačių naujausių jų versijų. Blogai būna, kai karkasas yra baisiai senas, o blogiausia tada, kai keli karkasai yra suplakami į vieną vietą. Taip dažniausiai nutinka, kai įmonėje, kuri vysto projektą, nėra nusistovėjusių gerųjų praktikų. 

Kadangi esu iš PHP pasaulio, pateiksiu pavyzdį susijusį su būtent juo. Įsivaizduokime, kad projekte naudojamas Yii karkasas. Jis senas. Ir į jį kažkas sugalvojo įdėti Laravel komponentų. Praktikoje toks būdas gali net ir suveikti. Bet tada vieną dieną prie projekto prisijungia naujas programuotojas, kuris yra užkietėjęs Symfony fanas ir prideda keletą jo komponentų. Ir kokį karkasą turime dabar? Kokia jo versija? Auditas padeda atraizgyti tokias painiavas.

Kodo kokybė

Mūsų požiūriu, ji apibrėžia, ar laikomasi kodo standartų ir tvarkos, pagal kurią kodas atsiduria produkcinėje aplinkoje. Jei vienoje vietoje yra rašoma su snake_case, o kitoje camelCase, tai jau indikuoja standartų nesilaikymą. Jeigu nevykdomos PR’ų peržiūros, nerašomi testai, neatliekama kodo stiliaus atitikimo statinė analizė ar klaidų paieškos dar prieš praleidžiant produktą, tai identifikuoja dideles bėdas.

Šioje dalyje labai svarbus “continuous integration” principas, ryškiausią akcentą dedant ant žodžio “continuous”. Tai sistema, kuri pranaršo kiekvieną dalelę kodo ir kur reikia paleidžia testus, padaro statinę kodo analizę ar išleidžia pakeitimus į staging’o ar produkcinę aplinką. Nes bet kokia gera intencija programavime atsiremia į “pavargau jau” arba “šita užduotis yra savaime suprantama, tai kam ją aprašinėti”.

Kodo peržiūros yra kita dalis, kuriai skiriame daug dėmesio. Net nebūtina, kad jos būtų nepriekaištingai atliktos, pirmiausia svarbu, kad jos būtų, o po to jau žiūrime į kokybę.

Pavyzdžiui, neseniai vienam klientui atlikome techninį auditą, kurio metu radome krūvą necenzūrinių žodžių kodo komentaruose ir slaptažodžiuose (beje, slaptažodžiai buvo pačiame kode). Aišku, skonio reikalas, bet kodo peržiūros iš karto durtų pirštu į tokius dalykus.

Palaikomumas

Šioje dalyje vertiname, kaip lengva palaikyti ir įdiegti naujas funkcijas į dabartinę sistemą. Ką reikėtų sutvarkyti ar padaryti, kad tai įvyktų žymiai sklandžiau. Atsakomi paprasti klausimai – ar naudojamos bibliotekos? Ar neišradinėjamas vis toks pats, bet naujas dviratis? Ar rašomi testai? Jeigu visi atsakymai tenkina, keliame sėkmės vėliavą, o jei ne, detalizuojame, ką galima padaryti kitaip.

Saugumo skylės

Tai turbūt svarbiausia dalis, kartu reikalaujanti ir mažiausiai paaiškinimo. Kur radome paprasčiausias įsilaužimo, suniokojimo ar sistemos užlūžimo grėsmes? Čia neapsimetinėjame Mr. Robot ir nedarome super sudėtingų machinacijų – greičiau patikriname, ar nėra palikta saugumo skylių pačio frameworko naudojime, kode, firewalluose ar kitose vietose.

Infrastruktūra

Čia vertiname, kaip ji sudėliota. Aišku, būtų labai smagu, jeigu pamatytume Kubernetes arba automatiškai didėjančius ir mažėjančius resursų pajėgumus. Bet realybė yra šiek tiek kitokia. Dažniausiai klientas permoka už nenaudojamus pajėgumus, nes OS arba susijusi programinė įranga (kaip taisyklė, PHP) yra tiek pasenusi, kad net neverta jos atnaujinti. 

Pradėdami šitą audito skiltį iš pradžių nubraižome diagramą: kas stovi kokiose mašinose, kokios OS, kokia įranga stovi kiekvienoje mašinoje. Tada pasižiūrime jų apkrovimus, versijas (tiek OS’o, tiek servisų). Ir iš šito pasakome, kaip darytume, jei būtume projekto savininkai. 

Audito išvados

Kaip ir kiekviename dorame tyrime, audito pabaigoje prieiname prie išvadų ir jas skirstome į dvi kategorijas. Pirmoji – Technical Action Points – pirmuose punktuose įvardiname tai, ką reikia pasidaryti čia ir dabar. Po to seka techninio proceso išgryninimo darbai, kaštų optimizavimas ir kodo kokybė.

Antroji tema – Team Action Points. Tai yra, kokius pakeitimus rekomenduojame iš komandos dalies – gal reikia įvairesnių kompetencijų? Gal reikia testavimo resursų? Gal reikia techninio lyderio? Jei matome, kad komanda sukomplektuota teisingai, šią skiltį praleidžiame.

Dažniausiai pasitaikančios problemos

Nors kiekvienas atvejis individualus, iš atliktų auditų patirties jau galime pastebėti kelias pasikartojančias problemas. Pradžioje derėtų pasirūpinti, kad projekte būtų:

• Tinkamai atliekamos pull-requestų peržiūros.
• Jei neturite CI (Continuous Integration) – būtinai įsidiekite ir pasidarykite, kad kodas būtų tikrinamas.
• Testai, testai, testai. Čia siūlau įsivesti paprastą piramidę – daugiausiai būtų unit’ų, po to seka integraciniai, o mažiausiai – E2E (End To End) testų.
• Užsidėkite priminimą, kad kas kažkokį laiko tarpą reikia peržiūrėti serverius, jų versijas ir įvertinti ar visa infrastruktūra yra tikrai reikalinga projektui

Ar būna projektų, kuriuose nėra ką pridėti?

Turbūt visi suprantame, kad tobulų projektų nėra. Kiekvienoje audituojamoje sistemoje mums atsiranda progų, ką pasakyti, o kitai pusei – kaip pasiteisinti. Vis tik, labai svarbu suprasti, kad audito metu neturėtų būti teisinamasi ar kitaip bandoma apginti poziciją, kurioje atsidūrėte. 

Savo ruožtu mes nedarome prielaidos, kad pažįstame visas audituojamos sistemos niuansus ir kliurkas, todėl visą darbą kurį padarome audituodami, pirmiausia reikėtų žiūrėti kaip į pasidalinimą patirtimi ir geranoriška pagalba. Galiausiai audito užsakovams svarbiausia turėtų būti sužinoti atsakymą tik į vieną klausimą – ką galime daryti kad projektas būtų kiek įmanoma geresnis?