Kako smo promijenili stanje uvijek povezane kako bismo spriječili izgaranje

Prijevod članka pripremljen je posebno za studente predmeta "DevOps prakse i alati".

Misija Intercoma je personalizirati online poslovanje. Ali ne možete personalizirati proizvod kada ne funkcionira. kako. Učinak je ključan za uspjeh našeg poslovanja, ne samo zato što nam klijenti plaćaju, već i zato što mi sami koristimo sa svojim proizvodom. Ako naša usluga ne radi, bukvalno osjećamo bol naših kupaca.

Nesmetan rad zavisi od mnogih faktora, poput arhitekture softvera i kvaliteta svakodnevnog rada. Međutim, često se sve svodi na to da se na pozive javlja osoba koja je uvijek u kontaktu pagerduty. Ova vrsta tehničke podrške može biti moćan alat usmjeren na kupca koji kombinira pomoć inženjera s onim što kupci dobiju kada kupe vaš proizvod. Ovo je također odlična prilika za učenje i rast, jer na kraju krajeva, neuspjesi i greške mogu biti dobra prilika za vježbanje vještina i razumijevanje složenih mehanizama rada.

Biti "uvijek uključen" van radnog vremena ima štetan učinak na vaš život.

Ali u isto vrijeme, biti "uvijek uključen" može imati štetan učinak na vaš život. Morate biti spremni da brzo i kompetentno odgovorite na upozorenje da je nešto pokvareno. Čak i ako vam se u bilo kojem trenutku ne šalje stranica, biti "uvijek uključen" može stvoriti anksioznost, kao što znam iz ličnog iskustva. Zbog toga se posebno jako pogoršava kvaliteta sna. Redovno boravak u zoni pristupa u bilo koje doba dana može dovesti do izgaranja, apatije ili, općenito, želje da nikada više ne vidite računar.

Istorija stanja „uvek povezani“ u Intercomu

U samim ranim danima Intercoma, naš tehnički direktor, Ciaran, samostalno je pružao cijeli tim tehničke podrške XNUMX/XNUMX, kako u kancelariji tako i van nje. Kako je Intercom rastao, stvorena je radna grupa da pomogne Ciaranu. Ubrzo nakon toga, novi razvojni timovi počeli su stvarati mnoge nove funkcije i usluge, te su preuzeli sve odgovornosti tehničke podrške.

Bilo je previše ljudi koji su „dežurni“ u svakom trenutku.

U to vrijeme, ovaj pristup se činio kao bezobzirni jer je to bio jednostavan način da u trenutku povećamo naš tim za tehničku podršku, bio je usklađen s našim vrijednostima i odgovarao je našim osjećaj vlasništva. Na kraju smo bez ikakvih planova dobili četiri-pet timova koji su redovno kontaktirali klijente u neradno vrijeme. Ostali razvojni timovi nisu imali mnogo složenih problema koji bi mogli da dovedu do greške, pa su retko, ako su ikad bili pozivani.

Shvatili smo da smo u situaciji da imamo mehaniku tehničke podrške na koju ne možemo biti ponosni, te niz kritičnih problema koje smo željeli popraviti, kao što su:

• Bilo je previše ljudi spremnih da prihvate izazov u svakom trenutku. Naša infrastruktura nije bila dovoljno velika da bi bilo potrebno najmanje pet razvojnih inženjera za rad bez redovnih slobodnih dana.
• Kvalitet naših alarma i procedura poziva nije bio dosljedan među timovima, te smo koristili ad hoc procese za pregled novih i postojećih upozorenja o problemima. Uputstva u priručniku (koje treba slijediti kada se dobije obavijest o problemu) su uglavnom bila upadljiva po njihovom odsustvu.
• Ovisno o timu u kojem su inženjeri radili, imali su oprečna očekivanja. Na primjer, samo prvi tim tehničke podrške imao je bilo kakvu naknadu za dežurstva i prekinute vikende.
• Činilo se da postoji opći nivo tolerancije na nepotrebne pozive u neparne sate.
• Konačno, ova vrsta posla nije za svakoga. Životne okolnosti su ponekad pokazivale da dežurstva nisu najbolje uticala na ljude.

Pronalaženje pravog "uvijek uključenog" stanja

Odlučili smo da napravimo novi virtuelni tim koji će obavljati poslove tehničke podrške za svaki tim u neradno vreme. Tim će biti sastavljen od volontera, a ne vojnih obveznika iz bilo kojeg tima u organizaciji. Inženjeri u virtuelnom timu rotirali su se otprilike svakih šest mjeseci, provodeći sedmice "na poziv". Srećom, nismo imali problema da pronađemo dovoljno volontera da okupimo virtuelni tim.

Kao rezultat toga, naš tim za podršku smanjen je sa 30 ljudi na samo 6 ili 7.

Tim se zatim dogovorio i definisao kako bi upozorenja i opisi problema trebali izgledati u priručniku i opisao proces prosljeđivanja upozorenja novom timu za podršku. Definisali su sva upozorenja u kodu koristeći Terraform modul i počeli da koriste recenziju kolega za svaku promjenu. Uveli smo nivo naknade za sedmičnu smjenu koji je dežurne bio sasvim zadovoljavajući. Također smo stvorili eskalirani tim drugog nivoa koji se sastojao samo od menadžera. Ovaj tim bi trebao biti jedina tačka eskalacije za inženjere tehničke podrške.

Imali smo nekoliko mjeseci mukotrpnog rada, tokom kojih smo uspostavili ovaj proces, tako da sada nije bilo 30 inžinjera na dežurstvu kao prije, već samo 6 ili 7. Tokom radnog vremena timovi se samostalno rješavaju problema sa svojim funkcijama ili usluge, na Ovo je vrijeme kada se obično dešava najveći broj kvarova, ali u svim ostalim trenucima tehničku podršku pružaju volonteri.

Šta smo naučili

Nakon što smo pokrenuli naš virtualni tim tehničke podrške, očekivali smo priliv novih zadataka, kao što je istraživanje uzroka problema ili okupljanje radi rješavanja jednog problema koji je uzrokovao prekid rada. Međutim, naši razvojni timovi preuzeli su punu odgovornost za faktore koji su uzrokovali kvarove, a svaki naknadni odgovor je obično bio trenutan. Također smo trebali izbjeći situaciju u kojoj bi zadatak tehničkog savjetovanja bio vraćen timu iz kojeg je došao, kako ne bismo prisilili inženjere da kontaktiraju nakon radnog vremena.

Broj poziva nakon radnog vremena pao je na manje od 10 mjesečno.

Naš proces eskalacije rijetko se formalno koristio. Češće se vjerovalo da je inženjeru neslužbeno pomogao tim koji je trenutno na mreži, posebno naši momci iz ureda u San Franciscu. Mnogi problemi su otklonjeni ili smanjeni kroz timski rad i njihovo rješavanje u hodu.

Inženjeri u našoj kancelariji u San Franciscu pridružili su se timu sa punim radnim vremenom i prevazišli tipičnu tehničku podršku. Bili smo suočeni s nekim režijskim troškovima, ali širenje članstva našeg tima za podršku u više ureda išlo je u našu korist jer se pokazalo kao dobar način da izgradimo odnose, ojačamo ih i naučimo više o tehnološkom nizu s kojim svi radimo.

Rad programera interkoma postao je dosljedniji u našim timovima, i možemo sa sigurnošću govoriti o prednostima sistemskog inženjera na našoj web stranici Karijera, navodeći da nema potrebe da uvijek budete povezani osim ako to ne želite.

Uz temeljni rad na stabilizaciji i skaliranju naših skladišta podataka, kontinuirani fokus na rješavanju problema doveo je do smanjenja broja poziva van radnog vremena na manje od 10 mjesečno. Veoma smo ponosni na ovaj broj.

Nastavljamo da radimo na održavanju i poboljšanju našeg tima tehničke podrške, a kako Intercom raste, možda ćemo morati preispitati svoje odluke, jer ono što funkcionira danas neće nužno funkcionirati sljedeći put kada se naše osoblje udvostruči. Međutim, ovo iskustvo je bilo izuzetno pozitivno za našu organizaciju i uvelike je poboljšalo kvalitetu života naših razvojnih inženjera, kvalitet naših odgovora na pozive, a prije svega iskustvo naših kupaca.

izvor: www.habr.com