Developers’ mDay 2019. - Zvonimir Gembec, Sysbee – Developers vs Sysadmins – kako se bolje razumeti
•Download as PPTX, PDF•
0 likes•167 views
Developers’ mDay 2019. - Zvonimir Gembec, Sysbee – Developers vs Sysadmins – kako se bolje razumeti Developers’ mDay konferencija okuplja inspirativne ljude iz oblasti web developmenta. U pitanju je događaj stručnog karaktera, namenjen web developerima sa ciljem da se upoznaju sa aktuelnim tehnologijama u projektovanju web sistema, iskustvima u korišćenju najnovijih tehnika i tehnologija, kao i u rešavanju problema sa kojima se svakodnevno suočavaju.
Recommended
Recommended
More Related Content
More from mCloud
More from mCloud (20)
Developers’ mDay 2019. - Zvonimir Gembec, Sysbee – Developers vs Sysadmins – kako se bolje razumeti
- 1. Sysadmins vs Developers Zvonimir Gembec Serving your uptime.
- 2. Ukratko o meni Zvonimir Gembec, Sysbee CEO ● 18 godina u web hostingu ● Osnivač Plus Hosting-a ○ Od startupa do vodećeg regionalnog web hosting providera ○ 30 zaposlenika i 20.000+ korisnika ● 2018 Sysbee je pokrenut kao najnoviji član DHH grupe ○ Managed hosting usluge, veliki web portali i Magento trgovine ○ Custom riješenja
- 3. Developeri i sistemaši: Love & hate relationship ● Automatike po serverima ● Izvještaji ● “Auto heal” sustavi ● IaC sustavi Sistemaši znaju i developirati Developeri znaju podesiti i administrirati sustave ● Development platforme ● Staging platforme ● Linode, heroku, AWS ● Kubernetes / Docker sustavi
- 4. Trebamo li uopće sysadmine u 2019? ● Developeri znaju održavati i kompleksnije sustave ○ mCloud, AWS, Azure, Heroku, VPS, Docker, Kubernetes ● Developeri znaju najbolje što točno trebaju ○ infrastruktura je prilagođena aplikaciji ○ podešavanje i promjene infrastrukture se mogu odraditi odmah ● Dovoljan je jedan “sistemaš” u development timu ○ jedan developer koji razumije sistemski dio je “good enough” ○ samo da podesi da to radi i ok smo
- 5. Što kada krene za ozbiljno? ● Prava produkcija sa pravim korisnicima ● 24 / 7 / 365 ● Korisnici iz cijelog svijeta ● Black Friday i slične akcije Što ako se sysadmin razboli? Smije li sysadmin na godišnji? Što ćemo ako ga udari autobus? Tko rješava probleme usred noći?
- 6. ● Firewalls ● Web i mail filters (WAFs, anti-spam, anti-phishing) ● Help and support ● Reports ● Certifications Što točno sistemaši rade? ● Rješavanje problema ● Security ● Updates and upgrades ● Network management ● Database management ● Monitoring sustava
- 7. A kako to sistemaši rade? reaktivno vs proaktivno rješavanje problema
- 8. Dobra komunikacija rješava probleme ● Prijavljujte probleme kako biste vi željeli da se vama prijave ● Uvijek navedite korake za reproducirati problem ● Screenshoti, tekst greške i logovi znatno pomažu ● Komunicirajte preko za to predviđenih kanala ● Budite pristojni i uvažavajte mišljenje kolege na drugoj strani ● Ako imate 7 problema, grupirajte ih, pa makar otvorili 5 ticketa ● Ne zloupotrebljavajte riječ hitno
- 9. Što je loša komunikacija? ● Nedefiniran opis problema ○ Javilo mi je neku grešku ○ Iskočio mi je neki popup, ja sam kliknuo na “Yes”, i ne radi ○ “Wordpress mi baguje!!!” ● Komunikacija putem telefona ○ Čekanje na liniji dok se problem ne riješi ○ Inzistiranje na jednom konkretnom sysadminu, jer “on dobro poznaje vaš server”
- 10. Što je loša komunikacija? ● Odgovor bez objašnjenja ili rješenja problema ○ Nakon što se potrudite detaljno opisati problem, nazad dobijete: “Probajte sada.” ● Prijava 7 različitih problema u jednom ticketu ● Subject: HITNO!!!!!
- 11. Severity levels ● Nije hitno - ostalo ● Hitno - ne radi jednom korisniku ● Jako hitno - ne radi više korisnika ili servisa
- 12. Level 1 Level 2 Level 3 Naplata Uprava “Regular” customersVIP customers Trijaža Trijaža Trijaža
Editor's Notes
- Ime mi je Zvonimir Gembec i u web hosting svijetu sam od 2001. godine. kada sam se pridružio. tada friško osnovanom Plus Hostingu kao part time sysadmin. Kada kažem sysadmin, mislim na sve tehničke stvari, jer nas je bilo samo dvojica. Nakon par mjeseci, postao sam i službeno sysadmin i tada ustvari počinje moj profesionalni put u web hostingu. Puno, puno godina nakon toga, pošto sam bio najstariji, a nekako su svi zaključili da sam i najpametniji, postao sam i CEO Plus Hostinga, no i dalje vrlo involviran u sve tehničke odluke, business development procese i ključne business odluke. u 2018. godine, odjel koji se bavio managed hostingom je već dovoljno zreo, a i dovoljno drukčiji od ostatka tvrtke, plus hosting smo podijelili na dva dijela, Plus Hosting se i dalje bavi shared hostingom, te Sysbee, koji se bavi samo managed hostingom. Pitati koliko ima developera, a koliko sistemaša u publici Developeri su u ovom slučaju svi oni koji ili programiraju, ili samo koriste web sustave. Npr, oni koji znaju instalirati wordpress, podesiti temu i naći i instalirati plugin, recimo da su i oni developeri Sistemaši su svi oni koji imaju root pristup serveru, sami održavaju, upgradaju, npr, znaju točno što znaći uname -a, što je grub ili initrd, šta je u /var particiji Prilagoditi pitch ovisno
- Developeri imaju love and hate relationship, ono što jedni i drugi rade se jako često preklapa, sistemaši znaju developirati, naime, istina zvuči malo čusdno, ali oni moraju znati developširati, odnosno programirati. Naime tko radi automatike po serverima? Tko developira sustave za izradu izvještaja po serverima. Tko radi sustave koji ih čuva da mogu spavati po noći? Odnosno, kako to oni zaovu, auto heal sustave? Danas iu doba clouda, u doba kontejnera i mikroservisa infrastruktura je kod, koriste se Iac siustavi kao što su Chef Ansible, Terraform, puppet…. Nema više monolitnih sustava, da tri tjedna drviš po jednom te istom serveru, instaliraš i podešavaš hrpu servisa. Danas se deployment sastoji od programiranja i ono što trebaš postići je da u pola sata možeš reproducirati infrastrukturu. Isto tako i developeri znaju kako podesiti infrastrukturu, naiem kako si oni podese development platformu. Kako si podese staging platformu. Posebno u vrijeme clouda, linidea, herokua, AWS-a, to samo naklikaš i radi. A kamoli kada još u priću stavimo i docker kontejnere, tehnologiju koja je baš napravljena da nema gap-a izmedju stageing i production enviromenta. Kako developeri imaju negdje u glavi, ili na papiru, ili po rantanju po facebooku popis najdražih sysadmina, bilo to interni syadmini bilo to popis hostera, i sydamini imaju isto tako popis najdražih developera I to je zato što ih razlikuju po načini kao prijavljuju probleme, kako rješavaju probleme i kako komuniciraju. IaC sustavi, kao što su Ansible, Puppet, Chef Terraform
- Trebamo li onda uopće sysadmina 2019? Ionako je sve kod, right? u principu nam treba jedan devloper koji voli malo čeprkati po serverima i on će nam sve to pokliktati? čak i ako nešto ne zna, ima sve na youtubeu, right? Ima tutoriala kako nešto podesiti koliko hočeš, right? Infrastrukturu ionako treba podesiti prema palikaciji, a kao izgleda aplikacija, to developeri najbolje znaju JEdan developer koji razumije malo nešto sa serverima, neka nam to podesi i ok smo Napisati
- Kada je sustav malen, po pitanju broja kupaca, ili korisnika, ili jednostavno posjetioca, downtime od par minuta ili čak par desetaka minuta će uglavnom proći ne zapažen. Posebno ukoliko korisnik nije podesio si nekaive notifikacije, tipa pingdom ili tako nešto, a vjerojatno i nije jer je sustav mali i dosta nevažan. Ukoliko je sustav dovoljno velik, itekako će se osjetiti downtime. To ide toliko daleko, da bilo kakav downtime recimo Facebooka, gmaila ili recimo instagrama bude udarna vijest na dnevniku, viralna vijest na drugim društvnim mrežama itd. Isto Vam je kada ste majstor pekar i radite odlične lepinje, i tako dolazite do prvog pravog, velikog kupca, koji proba Vašu lepinju i onda naruči 7 tona lepinja, dnevno, svaki dan, 7 dana u tjednu, nedjeljom, praznikom….. Koliko god ste dobar pekar, ovakva količina posla zahtjeva totalno drukčiji approach: trebate naučiti voziti viljuškar industrijske peći skladište za dovoljno repromaterijala nekoliko dobavljača sustav kontrole kvalitete dovoljno stručnih ljudi
- proaktivno vs reaktivno rješavanje problema proaktivno je ono kada korisnik javi da nešto ne radi kako treba, a vi onda popravljate actualy imate nekakav monitoring obično nešto rudimentarno ili nekakav online servis kao što je pingdom ili tako nešto prate se samo ping ili 200 OK response sa servera samo rudimentarni servisi "fire and forget" ima se redudantni sustav, ali se ne prati rad svake komponente ima se backup, ali se ne provjerava da li on actualy “radi" reaktivno je kada monitoring sustavi jave da nešto ne radi kako treba i Vi to popravite prije nego korisnik primjeti pravi monitoring koji prati SVE servise i sve komponente SOME AI koji prati trendove moguće je predvidjati probleme moguće je otkloniti probleme i prije nego nastane downtime obično to bude cca 300 “senzora” po hostu čak je i monitoring redudantan network i web filtering / firewals upravljanje mrežom DDOS zaštita / mitigacija capacity planning security web filtering patches and updates
- proaktivno vs reaktivno rješavanje problema proaktivno je ono kada korisnik javi da nešto ne radi kako treba, a vi onda popravljate actualy imate nekakav monitoring obično nešto rudimentarno ili nekakav online servis kao što je pingdom ili tako nešto prate se samo ping ili 200 OK response sa servera samo rudimentarni servisi "fire and forget" ima se redudantni sustav, ali se ne prati rad svake komponente ima se backup, ali se ne provjerava da li on actualy “radi" reaktivno je kada monitoring sustavi jave da nešto ne radi kako treba i Vi to popravite prije nego korisnik primjeti pravi monitoring koji prati SVE servise i sve komponente SOME AI koji prati trendove moguće je predvidjati probleme moguće je otkloniti probleme i prije nego nastane downtime obično to bude cca 300 “senzora” po hostu čak je i monitoring redudantan network i web filtering / firewals upravljanje mrežom DDOS zaštita / mitigacija capacity planning security web filtering patches and updates
- Prijavljivanje problema i feedback: Prijavljujte problem na način kako biste ga vi voljeli da vam se prijavi Obavzeno uključite sve relevantne podatke Browser, OS, verzije korake koji su Vas doveli do greške uvjerite se da je to zbilja postupak za naletjeti na grešku Napravite screenshot greške Copy pasteajte kod greške ( ako postoji ) ili baš sam error message Napišite svojim riječima što ste sve poduzeli da biste napravili workaround Nemojte navoditi drugu stranu što bi mogao biti problem!!! Koristite kanale koji su za to namjenjeni Nazad biste trebali dobiti: Potvrdu da je developer ili sysadmin uspio reproducirati grešku make sure da ima i pristupne podatke od tog dijela gdje je greška nastala ionako ima pristup do svih Vaših podataka ili barem potvrdu da je dobio i razumio Vaš problem, i da ce tada i tada početi raditi na tome Rješenje problema Kratak report, izbalansiran, što je bio problem i kako je nastao, te što se poduzelo da se problem ne ponovi eventualno, nekakav savjet ukoliko ste problem sami i izazvali, što napraviti da opet ne dodje do istog problema.
- Vrlo je bitno izbjegavati situacije koje mogu uzrokovati probleme i nejasnoće. Najgore je kada se sami dovedete u situaciju da Vam se ne može pomoći. Kada ne iskomunicirate problem dovoljno jasno, kada sugrerirate rješenaj i donosite sami zaključke bez dovoljno podataka
- Vrlo je bitno izbjegavati situacije koje mogu uzrokovati probleme i nejasnoće. Najgore je kada se sami dovedete u situaciju da Vam se ne može pomoći. Kada ne iskomunicirate problem dovoljno jasno, kada sugrerirate rješenja i donosite sami zaključke bez dovoljno podataka Vrlo je bitno da ne prijavljujete različite probleme u istom support ticketu, ardije ih grupirajte pa otvorite više ticketa za svaku vrstu problema, npr ako imate: problem sa podacima na računu problem sa trenasferom domene ili ako neki A recordi na domeni fale nakon migracije ako imate probleme sa nekakvim errorima koji su se počeli ppojavljivati nakon migracije sa verzijom PHP-a sa brzinom weba I onda to sve prijaveite u istom ticketu, vrlo se lako može desiti da će te odgovor duže čekati ili da dobijete odgovore samo na neke upite, ali ne na sve. Zašto je to tako, to cemo vidjeti vrlo brzo. Umjetno dizanje severitijy sa HITNO!!! u subjectu mejal ili ticketa, nije baš dobra ideja, naime operateri korisničke podrške imaju jako dobar filter za to, naime potoje samo tri severity levela, a to su:
- Ovo su tri severity levela koji sistemaši poznaju ostalo su sva “druga” pitanja, savjeti, ponude i računi, debugiranja u non production enviromentu, migracije webova “ne radi jednom korisniku” - je kada produkcija ne radi, e to je hitno, to se uzima preko reda, ma što god pisalo u Subjectu “ne radi više korisnika” - to je situacija kada se sve ostalo stavlja on hold dok se ne rješi prekid servisa Zato postoje ticketing sistemi, naime svugdje i uvijek postoji nešto što se u medicini zove trijaža, gdje bez obzira što korisnik kaže, čovjek koji je zadužen za trijažu filtrira i dodjeljuje tickete u odjele, koji opet, ako su veći, opet imaju vlastitu trijažu
- Ovo je nekakav layout kako otprilike izgleda layout hosting ili cloud provider organizacije. Ovo uzmite sa malo soli, ovo je nekakav idealni layout kojeg imaju više manje svi. Ok neki nemaju level2 i level3, nego je sto sve u istom odjelu, Neki nemaju level1 level2, nego je to sbvs u istom odjelu, a odjel infrastrukture, odn level3, je poseban odjel, ali logički gledano, ovo je nekakav idealni layout. Glavni sustav za komunikaciju s korisnicima je ticketing sustav, nekad bude i telefonska i podrška putem chat-a Defaultni put je Level1, pa Level2 Level1 je prva linija podrške, i tu ćete najvjerojatnije završiti prvo. level 1 rješava najviše upita korisnika. Oni rješavaju najčešće probleme, oni će Vam podesiti mejl, njih obično pitate za ponude i z aplaćanje i rješavanje osnovnih problema. Level2 su obično napredniji tehničari, kadkad bude to podijeljeno na nekoliko poddojela, bilo cloud / web hosting ili window / linux to jako ovisi kakva je organizacija u pitanju. Level2 rješava kompleksnije upite, upite za koje em treba puno više znanja, em treba puno više vremena. To su nekakve migracije sajtova, transferi domena, debugiranje ukoliko nešto ne radi itd. Level3 su tehničari koji brinu o infrastrukturi, networkaši, database admini, njih u principu ne možete dobiti na telefon. Ali će te nekad dobiti odgovor na ticket od njih, ne često, ali nekada hoćete. To su u principu vrlo kompleksni upiti i vrlo kompleksni problemi. I imate i odjel naplate, i naravno, upravu, bez njih ne možemo. Da bi komunikacija bila učinkovita, sva komunikacija ide preko ticketinga. Čak i ako nazovete telefonom i prijavite problem, vrlo često će to završiti tako, da netko iz levela1 otvori ticket i napiše ono što ste mu rekli telefonom, te dodijeli recimo levelu 2. Zato postoje ticketing sistemi, naime svugdje i uvijek postoji nešto što se u medicini zove trijaža, gdje bez obzira što korisnik kaže, čovjek koji je zadužen za trijažu filtrira i dodjeljuje tickete u odjele, koji opet, ako su veći, opet imaju vlastitu trijažu