Kodiranje u kompleksnom domenu

Kako smo naučili da rešavamo kompleksne izazove?

Za početak imamo pitanje: šta je teže – sagraditi most preko Korintskog zaliva ili izvršiti operaciju srca? Građenje mosta zahteva ekipu od stotinu ljudi, dane i mesece rada. Za operaciju srca je neophodno nekoliko stručnjaka i par sati. Pa ipak, jednostavnije je sagraditi most. Zašto? Zato što „težina” zavisi od domena u kom se izazovi nalaze.

Gradnja mosta (ili kuće, oblakodera) se dešava u komplikovanom domenu. To znači da taj domen, ili sistem, mogu da se podele na manje celine od kojih svaka može da se reši pojedinačno. Dakle, ako je nestabilno tlo – postavićemo šipove. Zatim, postavićemo temelje, pa zidati sprat po sprat. I tako sve do najfinijih detalja.

S druge strane, operacija srca je stvar koja se dešava u kompleksnom domenu. Kompleksni domen je mreža interakcija, koje se ne mogu posmatrati (ni rešavati) odvojeno – već jedinstveno, kao sistem. Dakle, neophodno je da svi aspekti operacije funkcionišu zajedno – i istovremeno.

Mi smo uvek u kompleksnom domenu

United Cloud razvojni centri nalaze se u više zemalja regiona i Evrope, i u njima se razvijaju naši proizvodi. Kada nešto razvijaš, to podrazumeva inovaciju. To znači da ne postoji već ustanovljen proces ili gotovo rešenje za problem koji rešavamo. Čak i kada znaš šta želiš da bude output (recimo, feature koji već postoji na nekim drugim streaming platformama), proces kojim dolazimo do tog output-a je uvek priča za sebe.

Kada operišeš u kompleksnom domenu, to znači da neće sve ići kao podmazano. Lansiranje EON TV-a je jedna od priča koju često prepričavamo za ručkom u United Cloud-u.

Svaki početak je kompleksan

Na početku, trebalo je vrlo brzo da razvijemo EON TV sa kompletnim funkcionalnostima. Prvi izazov je bila streaming platforma. Iako smo već imali streaming platformu, morali smo dosta da je preradimo kako bi odgovarala našem proizvodu. Drugi izazov su bili Metadata serveri, koji klijentskoj aplikaciji pružaju podatke poput EPG-a, liste kanala, opisa event-a, ali i vode računa o klijentskim paketima, polisama, kredencijalima, itd. (Dakle, sve što je neophodno da postoji da bi platforma bila funkcionalna). Takođe, bilo je potrebno projektovati i postaviti infrastrukturu, međutim, najveći izazov kod EON TV-a je činjenica da platforma treba da bude dostupna 24 sata svakog dana u godini sa apsolutno svakog uređaja!

Veći deo 2017. godine smo proveli razvijajući EON TV platformu, sa ciljem da je lansiramo 5. septembra. I to bi bilo super, jer je taj dan bio početak Evropskog prvenstva u košarci. Mi smo lansirali EON TV istovremeno u Srbiji, Sloveniji, Crnoj Gori i Bosni. Delovalo nam je kao da je početak prvenstva odličan start – da odmah privučemo gledaoce na EON TV. Zbog kratkih rokova, razvijali smo platformu do poslednjeg dana. Uradili smo sve testove, koje smo mogli da uradimo u tom trenutku, sve je odlično radilo, dok…

Režija?!

Nije počelo da radi! U kompleksnim domenima vlada nepredvidivost. Ono što radi savršeno u testnoj fazi, ponekad ne proradi u realnom svetu. Tako nas je na samom startu dočekalo nekoliko ozbiljnih problema. Prvi problem je bio Distributed Denial of Service (DDoS). To je distribuirani (hakerski) napad sa idejom da se infrastruktura preoptereti i prestane da funkcioniše. Dok smo mi provalili ko nama to radi... Na kraju se ispostavilo da je trebalo dodatno optimizovati našu IOS aplikaciju!

Sutradan je bila druga stvar. Igrala je Srbija i broj uređaja sa kojih se gleda utakmica se sve više povećao. Trebalo je da utakmica krene u 20 časova i sve je radilo savršeno... Sve do 19.58, kada su svi odjednom krenuli da se loguju... Tada smo shvatili da naša landing strana ima previše informacija. Dakle, previše je „teška“, jer mora da se potroši mnogo procesiranja i memorije kako bi ona funkcionisala. Pod naletima gomile logova, serveri padaju – a mi ih dižemo. I sve to u realnom vremenu, dok traje meč, kako ne bi došlo ni do najmanjeg prekida u prenosu! Tih dana nismo mnogo spavali.

Za vreme utakmica, platforma je bila opterećenija, a van utakmica smo imali manji protok i više prostora da manevrišemo. U toku prvenstva smo se šalili da bi nam još samo falilo da u finalu igraju Srbija i Slovenija. Par dana kasnije, kada su u finale prošle Srbija i Slovenija, nije nam bilo toliko smešno!

Sada je druga priča

Baš zbog tako izazovnog rešenja, mi smo rešili neke kompleksne probleme još na početku. Od 10.000 uređaja na samom početku, došli smo do više od pola miliona. Tada smo izbacivali po par stotina megabita u sekundi – a sada 1.5 TERABIT. I to bez situacije da iko bude budan noću!

Sada sve radimo drugačije. Ustanovili smo proces koji je odgovor na rad u kompleksnom domenu. Ne dozvoljavamo sebi da imamo tako velike deployment-e i posebno razmišljamo koji je to trenutak u kom ćemo da odemo u produkciju, ali ono što je mnogo bitnije, kompletan taj proces od početka implementacije do kraja implementacije je drugačiji, mnogo drugačiji.

Osnovni korak za implementaciju kvalitetnog procesa je kvalitet code base-a:

Kvalitet code base-a

Trudimo se da u svakom koraku ugradimo kvalitet što je moguće više. Dakle, na početku vodimo računa o kvalitetu našeg code base-a. To je prva stvar. Postoje code standardi, code review-ovi u okviru kojih mi zapravo diskutujemo o kompleksnosti implementacije. U ovoj fazi postavljamo sebi sledeća pitanja:

a. Da li nešto može jednostavnije da se iskodira?
b. Da li je dovoljno jednostavno za održavanje?
c. Da li je dovoljno robusno rešenje?
d. Da li smo uveli u startu neke security probleme?
e. Da li treba da update-ujemo naše code standarde?

Ovaj prvi korak je izuzetno bitan. Osim što obezbeđuje kvalitet, čini i da svi novi članovi tima koriste iste prakse u radu. Tako se brže i uklope u tim, radeći na sličan način i sa istim mindset-om.

Statička analiza je integralni deo kvaliteta code base-a

Kroz statičku analizu mi zapravo proveravamo kakav je kvalitet našeg koda. To su relativno kompleksni algoritmi koji proveravaju status, da li smo dodali neki „tehnički dug“ koji posle mora da se vrati, da li je aplikacija sama po sebi dovoljno robusna (otporna na probleme). Na automatizovan način dobijemo feedback odmah. Dakle, algoritam sam signalizira. Na primer, dobijemo informaciju da neka klasa mora da se promeni jer je predugačka, ima 300 linija koda, i toj klasi često pristupa više od jednog developer-a. To znači da će tu potencijalno nastati problem. Čak imamo i predložene solucije, npr. da se ta određena klasa podeli na više manjih ili da se refaktoriše kod.

Sledeći bitan korak u implementaciji procesa je deployment pipeline koji smo uspešno optimizovali za ovih pet godina. O njemu smo napisali odvojeni tekst, jer znamo da niko nema interval pažnje da prati tekst duži od tri strane!

I za kraj, ako i ti kodiraš u komplekson domenu - javi nam se i hajde da (više) pričamo o dobrim praksama! Pogledaj i otvorene pozicije na United cloud Joberty stranici i pridruži nam se.

Autor: Igor Tanacković, Chief System Architect