Izabrali smo top tri greške, koje su bile toliko velike, da je bilo hvatanja za glavu u našem progamerskom kružoku, neverice i odsecanja nogu.
Prvo, sledi upozorenje. Ne pokušavajte ovo kod kuće, na svom kodu.
Iako u praksi naših programera i bekap ima svoj bekap, a iza njega još jedan bekap, softver razvijaju ljudi, a svi znamo koliko je ljudski grešiti. Naši sjajni momci podelili su svoje greške, malo se smejući malo uzdišući, u jednom iskrenom razgovoru koji se povremeno, gotovo sa terapijskim dejstvom i uz malo pice i piva, održava pod nazivom Infostud Tech Talks. Ovog puta, društvance se okupilo online, ali priče bi se mogle svesti pod jedan naslov – najveći fuckup moje karijere.
Dok se atmosfera zahuktavala, jedan po jedan su otvarali dušu, govoreći o greškama koje su se dešavale i najiskusnijim developerima. Nekima prvog radnog dana. Drugima na mestu šefa IT-ja. Nekima zbog neiskustva, najsrčanijima u želji da promene sistem. Gasili su se sajtovi, brisale baze podataka, produkcije su padale kao snoplje, ali jedno je važno - sve to je unapredilo i sistem, i ljude.
I zato, izabrali smo top tri greške koje su bile taaako velike, da je bilo hvatanja za glavu u našem progamerskom kružoku, neverice i podsećanja na odsecanje nogu i po nekoliko besanih noći i dana dok se sve to peglalo. I ispeglalo se, srećom, baš sve. Pogađate zašto? Uglavnom zato što su kolege bile ok, što je šef imao razumevanja i što je onaj ko je pogrešio iz toga naučio ozbiljnu lekciju.
Bronzani FuckUp – IT tim sajta 4zida.rs
Kapetan broda koji tone
Postoje greške koje se dese kao posledica nepažnje ili nedostatka bezbednosnih mehanizama, bekapa itd. Ali, evo jedne priče koja nije imala veze sa tim. Ponekad se greške jednostavno kriju u predrasudama, u načinu razmišljanja. Elem, počeli smo da koristimo MongoDB, čiji sam bio jedan od velikih fanbojeva, a jedna od stvari koje je mogao da čuva je da u sklopu dokumenta stoje binarni podaci. Pošto smo mi stalno kuburili sa permisijama oko slika, (ko god je radio sa sisadminima, znaće o čemu pričam), palo mi je na pamet da snimimo slike direktno u oglas. Postojalo je ograničenje od nekih 16 mb, a kako sam analizirao ni jedna kolekcija nam nije to prelazila, jer to je bilo pre i kamere su bile slabije. U teoriji to bi radilo. Uradio sam istraživanje, pričao sa sisadminima šta misle o tome, sa kolegama, guglao... Niko to nije radio pre, ali nije bilo ni nekih jakih saveta protiv. I onda smo jedne srede rešili da to pustimo. Sve slike su počele da se snimaju u sam oglas, a ne na disk. Ali, naši oglasi se importuju periodično i ta promena nije odjednom zahvatila sve oglase, nego je polako išao kron i prebacivao.
U tom trenutku sam se osećao kao kapetan koji stoji i gleda brod kako tone. Ta količina binarnih podataka je usporila pretragu, apdejtove, insertove, sve! I tako gledaš kako sajt koji se učitavao za 2 sekunde kako učitava pretragu tri minuta. I ništa se nije polomilo, ništa nije izgorelo, sajt nije bio ofline, jednostavno je bio spor do neprepoznatljivosti. Prvo nam je trebalo vremena da skontamo šta se tu dešava, ali to je bila jedina velika izmena koju smo radili. I onda je samo bila stvar živaca iščekati dva sata koliko je trebalo da se te slike vrate nazad, sve gledajući kako se sajt vuče kao neki krš. Ni dan danas ja ne znam kako bih to mogao simulirati, testirati, na toj poseti i broju oglasa kao što smo imali tada, osim na taj način. I nije mi žao što sam pokušao.
Koja je prva reakcija programera na fuckup? Kolega je počeo da hiperventilira, navukao je kapuljaču i spustio glavu na sto. Obratio sam pažnju na njegov monitor i video da je izvršio jedan vrlo destuktivan query. Video sam da nešto moramo da uradimo. Zaustavili smo sajt, stavili ga oflajn, jer je query anulirao datume svih oglasa na sajtu. Sisadmini su imali bekap, ali potrebno je dovući sve, izvući podatke iz tabela, napisati skriptu da te podatke koje smo obrisali vratimo nazad u tabelu i to uopšte nije jednostavan proces. Kolega Danijel je imao sjajnu ideju, napisao je query koji je rekonstruisao datume postavljanja oglasa na osnovu datuma njihovog prvog pregleda.
Finalna posledica bila je 45 minuta oflajn sajta Polovni automobili, koji ima 750 000 poseta dnevno. Tada su nam sisadmini na razvojnom alatu koji se koristi na produkcionoj verziji, ubacili crno-žuto upozorenje RADITE NA LAJVU, kako bismo stalno bili svesni gde se nalazimo. Uvek postoji verovatnoća da ukoliko programer ne pazi da se takve stvari dese i sutra. Naravoučenije: pazimo u kom okruženju radimo, da li je testno ili je lajv i ne puštamo stvari petkom i pred kraj radnog vremena.
Bilo je to početkom 2013. Te godine radili smo na potpunom prepisivanju sajta Poslovi.Infostud. Kao svi dobri developeri, želeli smo sa novim sajtom da imamo glanc novi custom-made state-of-the-art email queue sistem za odloženo slanje transakcionih mejlova, sa automatskim arhiviranjem. U isto vreme naše kolege iz sistemske administracije planirale su da izvedu dugo najavljivanu promenu MySQL engine-a, sa MyISAM na InnoDB.
Desetak minuta nakon puštanja sajta, javlja nam se korisnik i tvrdi da je u mejlu za zaboravljenu šifru, dobio i dokument nepoznatog korisnika. Ideju da je naš novi sistem prouzrokovao ovu grešku, momentalno smo odbacili i pripisali greški korisnika. Ali, Infostud je godinama i pre toga davao apsolutni prioritet situacijama u kojima postoji mogućnost da lični podaci naših korisnika „procure“ trećim licima. Treba imati u vidu da je ovo 6 godina pre GDPR-a i da je čak i u nedostatku pravne regulative ovo shvaćeno kao veliki problem, a imalo je potencijal da se pretvori u ozbiljnu krizu. I samo zbog toga, odlučili smo da sajt stavimo van funkcije, dok ne utvrdimo kako i zašto je došlo do ovoga i da li je nova aplikacija Poslova odgovorna za to. Ovo se dešava u vreme kada se u Infostudu pojavila i potreba za uvođenjem kriznog PR-a.
IT sektor je bio sluđen. Satima nismo mogli da objasnimo kako se ovo desilo. U isto vreme, pristupili smo analizi logova, da bismo utvrdili koliko korisnika je zahvaćeno, koliko njih je došlo u posed tuđih informacija, i tačno, čiji lični podaci su ugroženi. Telefonski smo kontaktirali svakog ponaosob. I imali smo sreću da su korisnici veoma lepo reagovali na našu otvorenost.
Sajt je stavljen u funkciju tek nakon što smo tehnički utvrdili šta se zaista desilo. Nakon besomučnog guglanja, utvrdili smo da je prelaskom na novi MySQL engine, promenjena jedna od ključnih funkcionalnosti tzv autoincrement polja, koja se kod InnoDB-a postavljaju na nulu nakon restartovanja servera, a ukoliko je MySQL tabela prazna, što nije bilo slučaj sa MyISAM engine-om koji smo do tada godinama koristili. Deo novog email queue sistema koji imao zadatak da arhivira poslate mejlove je upravo stavljao sistem u tu situaciju i napravio "savršenu oluju". Bili su teški dani za IT, a i za kompletan Infostud. Uskoro će nam se otkriti da ovo nije jedina greška u aplikaciji koju smo morali da otkrijemo na teži način. O svemu tome, možda neki sledeći put.
„Neke stvari su jednostavno van naše kontrole i morale su da se dese. U svemu ovome, najviše mi je značilo da sam imao podršku ljudi sa kojima radim. Takav je život programera. U takvim situacijama, potrebno je smiriti se, razmisliti, žargonski rečeno „stati na loptu“, ne raditi kritične izmene sistema kada ste pod stresom, ili pred kraj nedelje. Tehnički gledano, Infostud je tada bio u mnogome jednostavniji sistem, ali je, sa druge strane, bilo je lakše napraviti grešku. U poslednjih nekoliko godina izgradili smo kompleksnu infrastrukturu i katastrofalne greške su manje verovatne, ali je zato vreme potrebno da se upozna ovakav sistem značajno veće. Na trenutnom tehničkom nivou razvoja, mlađim kolegama je značajno teže da se nađu u situacijama kroz koje smo mi gotovo redovno prolazili i obaveza je seniora je da konstantno razvijaju infrastrukturu u tom smeru“, time Borko iz IT tima sajta Poslovi.Infostud završava svoju priču.
Dakle, zapamtite. Nove stvari nikad ne puštajte petkom, ne eksperimentišite pri kraju radnog vremena, vaše greške mogu da utiču na ceo biznis i ako kolega pored vas počne da hiperventilira, sigurno je bio neki gadan query.
Ako si PHP medior sa minimum dve godine iskustva, i ok ti je da radiš sa otvorenom ekipom koja ponekad i greši, čekamo te u Subotici. Ili, ukoliko poznješ nekoga sličnog, prosledi mu ovaj oglas.