DevDaysi, sad već tradicionalno godišnje okupljanje Infobipovaca, i ove je godine okupilo inženjere, stručnjake za razvoj proizvoda i korporativnu sigurnost kako bi razmijenili znanja i prakse. Donosimo neke od lekcija koje mogu koristiti i drugima u industriji.
Na dvodnevnoj konferenciji DevDays, Infobip je u zagrebačkom kampusu okupio više od 900 svojih inženjera iz 15 zemalja svijeta.
Nakon Infobip Shifta, ova konferencija daje Infobipovim zaposlenicima dublji uvid u specifičnosti njihovog posla i same organizacije. Od toga kako funkcionira infrastruktura Infobipovih aplikacija te kako je posložen Infobipov data pipeline do predavanja o dobrim Postgres praksama i Testcontainers libraryju.
Iako je premisa DevDaysa interni prijenos znanja iliti Infobipovci za Infobipovce, kao i 2020. kada su na DevDaysima ugostili Craiga Larmana, su-pokretača Large Scale Scrum metodološkog okvira, ova konferencija krije mnogo dobrih savjeta i za druge programere. Evo koje smo probrali…

50 nijansi incidenata i što iz njih naučiti?
Jedno od upečatljivijih predavanja na Infobipovim DevDaysima bilo je ono Infobipovog Principal Engineera, Ante Perića, pod nazivom 50 Shades of Incidents. U predavanju Ante nas je proveo kroz tri lekcije koje je naučio iz incidenata koji su znali zadesiti njega i tim, a posljedično i cijeli odjel. Lekcije su to kojih bi se svaki developer trebao prisjetiti u teškim trenucima.
1) Ne brzajte!
Vjerojatno ste i sami bili u situaciji (a neki od vas su i trenutno) da se nešto mora napraviti: jučer! Uvijek postoji pritisak da se treba nešto odraditi do određenog roka. Međutim, taj rok je često isforsiran, napominje Ante. Neki rok mora postojati, dodaje, “ali budite sigurni da se stvari uvijek mogu barem jednom odgoditi ako to znači da ćete neki element pustiti u produkciju sigurnije.”
Ukratko, pritisak vodi do žurbe, a žurba do neoptimiziranog koda.
U redu je biti brz, ali nemojte požurivati stvari. Kad netko kaže da morate biti brzi, shvatite to na način da morate biti agilan tim, a ne tim koji radi stvari nabrzinu.
Uz to, često inženjeri padaju u zamke poput “radio sam to već tisuću puta, ne bude se ništa zeznulo” ili preskoče testiranje, zbog kojeg god razloga. Požurivanje takvih stvari najčešći su okidači incidenata.

2) Ne paničarite!
Sigurno ste doživjeli i slučaj kada ste u žurbi ili pod pritiskom nešto ozbiljno potrgali, a umjesto da ste sjeli i razmislili kako to najbezbolnije riješiti – u panici ste napravili još goru stvar.
Kod ove lekcije, Ante se najviše vraćao na znanje odnosno poznavanje sustava na kojem radite (ili kontaktiranje onoga tko zna) i dobru pripremu za incidente ubuduće. Priprema će vam pomoći da znate što prvo napraviti i da ne reagirate u panici. Nekada je rješenje jednostavnije nego se na prvu čini.
Ante se osvrnuo i na trenutke kada je bio stalno u panici zbog svakog incidenta. Šef mu je tada objasnio kako je normalno imati incidente kad skalirate produkciju funkcionalnosti i općenito kao organizacija – samo je stvar toga kako tim incidentima pristupate.
3) I na kraju, ne zaboravite!
Nakon što je incident gotov, što možete napraviti?
Najgore je nakon incidenta nastaviti kao da se ništa nije dogodilo. Nakon što se slegla prašina, slučaj se ne zatvara, objašnjava Ante kroz konkretne točke.
Prvo morate shvatiti što je bio uzrok incidenta. Nakon toga je potrebno odrediti realne aktivnosti kojima ćete spriječiti takve incidente. Treće, trebate planirati i kako riješiti taj problem – jednom zasvagda.
I konačno, važno je sve što ste prošli zabilježiti – podijelite znanje. U tvrtku stalno dolaze novi ljudi koji ne znaju za prošlih 50 incidenata, sažeci tih incidenata će im itekako koristiti.
Ali ništa od toga ako oni vaš report ne pročitaju, zato se fokusirajte nakon što report napišete da do njih informacija i dođe. Ništa niste napravili samo pisanjem, zaključuje Ante.
Metrika govori tisuću riječi…
Znamo li koliko bolje možemo? Jesmo li sigurni da ulažemo u ono što se može unaprijediti? Kako osigurati da ne diramo stvari koje već funkcioniraju dobro? Pitanja su kojih bi se trebala dotaći svaka razvojna tvrtka barem par puta mjesečno. Ali za takva pitanja važno je imati konkretne odgovore.

U Infobipu se tako prije dvije godine okupio tim ljudi unutar Engineeringa koji istražuje i mjeri kako se odvijaju stvari unutar organizacije. Svojim inputima danas su podrška svim razvojnim i produktnim timovima u njihovom radu. Prije nego nas je upoznao s metrikama njihovog istraživanja, Valerii Akopov, Engineering Manager u Infobipu, otvorio je svoje predavanje s napomenom:
Nije stvar u mjerenju, bit je u transparentnosti. U konačnici, cilj naših istraživanja i mjerenja je da svakom timu možemo pokazati te podatke, upoznati ih s rezultatima onog što rade, usporediti i smjestiti njihove pojedinačne aktivnosti u veću sliku unutar organizacije te im na taj način dati alat za informirane odluke što, kako i zašto nešto napraviti.
Definirali su četiri kategorije unutar kojih su ušli još dublje sa specifičnim metrikama.
Kao prvo, to je učinkovitost (Efectiveness). Odnosno koliko su kao organizacija učinkoviti u izvršavanju stvari. Unutar ove kategorije mjerili su nekoliko stvari. Npr. koliko im je potrebno da nešto izbace na tržište, ali i na što se raspodjeljuje trud inženjera: da li na razvoj proizvoda, učenje, troubleshooting, rješavanje bugova, skaliranje ili operativne zadatke… Uz to su mjerili i ciklus razvoja te unutar njega koliko vremena je neka stavka “u planu”, koliko odlazi na njeno definiranje, a koliko na sam razvoj i implementaciju.
Drugo, uspješnost isporuke koja odgovara na potrebe korisnika u datom periodu tzv. Software Delivery Performance. Ovdje se, između ostalog oslanjaju na mnogima poznate metrike koje su definirane po uzoru na rezultate šestogodišnjeg istraživanja State od DevOps, a koje je objedinjeno u DORA program.
Treće, zadovoljstvo i angažiranost ljudi (People and Engagement). Željeli su dati timovima alat za samoprocjenu – kako bi lakše pokazali osjećaje i osvijestili svoje mentalno stanje. Što se pogotovo ispostavilo korisno u vrijeme rada na udaljeno i asinkrone komunikacije. Za to im je poslužio Niko-Niko kalendar raspoloženja.
I zadnje, ali ne manje bitno kako je Valerii isticao – kvaliteta rada. Ovdje se najviše fokusiraju na podatke koji im mogu pokazati koliko su stabilni njihovi proizvodi kroz mjesec, kvartal ili godinu dana.
Valerii je za kraj poručio da se samo nada da će ga se kolege Infobipovci sjetiti kada sljedeći put budu pisali izvještaje i popunjavali još jedno polje u Jiri… Sad barem znaju, there is a greater cause to it!
Sukladno članku 94. Zakona o elektroničkim medijima, komentiranje članaka na Netokraciji dopušteno je samo korisnicima koji ostave svoje ime i prezime te mail adresu i prihvate pravila ponašanja.
Pravila ponašanja
Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja, kao i Zakon, držeći se sljedećih pravila ponašanja:
Kako koristimo podatke koje ostavljate? Bacite oko na našu izjavu o privatnosti.
Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.