Tehnički due diligence: prvo pročitajte račun, pa kod

Tehnički due diligence prije kupovine ili ulaganja odgovara na jedno pitanje: šta tačno preuzimate? Demo pokazuje šta proizvod radi. Ne pokazuje koliko košta rad sistema, koje bi dijelove trebalo prepisati ni šta prestaje raditi ako odu dvoje ljudi koji ga poznaju.

Nisam ga radio pod tim imenom za neku akviziciju. Način na koji bih ga uradio dolazi sa sistema na koje sam dolazio i koje sam morao brzo razumjeti, kad mi niko nije mogao reći sve što kod radi. Na svakom od njih prvi koristan dokument bio je račun.

Na nacionalnom sistemu za identitet u Zapadnoj Africi AWS račun je iznosio 24.000 $ mjesečno. Opterećenje je tražilo otprilike osminu toga, a ništa nije prijavilo grešku. Šest mjeseci kasnije isti sistem koštao je 2.000 $ mjesečno, s istim korisnicima koji rade isti posao, i bez gašenja ijednog dijela.

Višak je imao tri uzroka i svaki je pronađen na drugi način:

• Dimenzionisanje. Sve je bilo predimenzionisano, a to se vidi kad uporedite rezervisani kapacitet sa stvarnom upotrebom.
• Greška. Beskonačne petlje trošile su procesor danju i noću. Vide se kao trošak koji ne prati saobraćaj: veliko opterećenje koje ne objašnjava nijedna radnja korisnika.
• Arhitektura. Upload je na putu do S3 išao kroz backend. To se vidi samo u kodu.

Za kupca je ta podjela važnija od ukupnog iznosa. Dimenzionisanje je promjena konfiguracije. Greška je popravka buga. Uzrok u arhitekturi znači prepisivanje jednog puta kroz sistem, s vlastitom cijenom i rokom. Prevelik račun vam malo govori dok ne znate za koji od ta tri uzroka plaćate.

Račun ide prvi i zato što je to jedini zapis koji niko nije napisao da bi opisao sistem. On bilježi šta je radilo, svaki sat, bez obzira na to šta tim misli da sistem radi.

Typecheck, lint i zeleni build malo govore o tome radi li sistem ono što njegovi autori misle da radi. Uz to daju duge liste, a lista od dvjesto nalaza ne govori koliko košta njihova popravka.

Iza mnogih od njih često stoji jedan uzrok. Kad upload ide kroz backend, svaka fotografija zauzima memoriju servera dok traje zahtjev, zahtjevi traju duže, a serverima treba više kapaciteta nego što saobraćaj pokazuje. To izgleda kao tri problema, a jedna je odluka o tome kuda fajl ide. Procjena treba imenovati tu odluku i pod nju staviti sto simptoma.

Na skladištu podataka jednog dobavljača velikih američkih maloprodajnih lanaca nisu se smjeli mijenjati ni upiti ni šema. Upite je generisao BI alat, a klijenti su na šemi imali sačuvane izvještaje. Izvještaj najvećeg klijenta trajao je preko petnaest minuta. Sada se otvara za 0,2 sekunde, i nijedan klijent nije morao ponovo praviti sačuvani izvještaj, jer se posao radio na sistemu nad kojim se upiti izvršavaju.

Novi vlasnik nailazi na istu vrstu ograničenja. Sačuvani izvještaji klijenata, aplikacije već instalirane na telefonima i sistemi trećih strana koji pozivaju vaš API drže interfejse tamo gdje jesu. Ta ograničenja, više od bilo čijih želja, odlučuju šta se može promijeniti, pa time i koliko to košta. Procjena koja preporučuje prepisivanje, a ne navodi ih, nagađa cijenu.

Skupi problemi izgledaju kao normalan rad: beskonačna petlja, upload koji ide kroz backend, komentar u kodu koji i dalje opisuje raniju verziju funkcije ispod sebe. Monitoring hvata greške, a ništa od ovoga nije greška. Pronalaze se samo kad ih namjerno tražite, i to je najveći dio posla procjene.

• Koliko košta rad sistema, po stavkama na računu, i koliko od toga otpada na dimenzionisanje, na greške i na arhitekturu.
• Gdje su rizici: pristup podacima, tajni ključevi, autentifikacija i sve drugo što ne bi prošlo sigurnosnu provjeru.
• Pregled po dijelovima: šta može ostati, a šta bi trebalo prepisati, uz zapisano obrazloženje.
• Šta nije provjereno, također zapisano, da se dokument ne bi shvatio kao nešto više nego što jeste.

I codebase u dobrom stanju dobija cijeli dokument: zašto je u dobrom stanju, koliko košta njegov rad i listu onoga što nije provjereno. To je dobro imati crno na bijelo prije potpisivanja.

Pristup za čitanje repozitorija koda i podataka o naplati. Produkcijski podaci nisu potrebni. Hoće li tim znati za procjenu, vaša je odluka, ali posao ide brže ako tim može posvetiti malo vremena da potvrdi ono što se iz koda ne vidi. Datum isporuke dogovara se prije početka rada, a NDA potpisujemo ako ga želite.

Ako imate samo jedno popodne, počnite od računa. Raščlanite ga po stavkama i za svaku stavku pitajte koja je radnja korisnika plaća. Stavka za koju niko nema odgovor mjesto je odakle treba početi čitati kod.