Preklad článku bol pripravený špeciálne pre študentov kurzu .
Poslaním Intercomu je personalizácia online podnikania. Ale nemôžete personalizovať produkt, keď nefunguje. . Výkon je rozhodujúci pre úspech nášho podnikania nielen preto, že nás platia naši klienti, ale aj preto, že my sami používame . Ak naša služba nefunguje, doslova cítime bolesť našich zákazníkov.
Bezproblémová prevádzka závisí od mnohých faktorov, ako je architektúra softvéru a kvalita každodennej práce. Pomerne často to však všetko súvisí s tým, že telefonátom odpovedá osoba, ktorá je vždy v kontakte . Tento druh technickej podpory môže byť výkonným nástrojom zameraným na zákazníka, ktorý kombinuje pomoc inžinierov s tým, čo zákazníci dostanú, keď si kúpia váš produkt. Je to tiež skvelá príležitosť na učenie a rast, pretože koniec koncov, zlyhania a chyby môžu byť dobrou príležitosťou na precvičenie zručností a pochopenie zložitých pracovných mechanizmov.
Byť „vždy zapnutý“ mimo pracovného času má škodlivý vplyv na váš život.
Ale zároveň byť „vždy zapnutý“ môže mať škodlivý vplyv na váš život. Musíte byť pripravení rýchlo a kompetentne reagovať na upozornenie, že je niečo pokazené. Ako viem z vlastnej skúsenosti, aj keď nie ste v žiadnom momente volaní, byť „vždy zapnutý“ môže vyvolať úzkosť. Z tohto dôvodu sa kvalita spánku obzvlášť výrazne zhoršuje. Pravidelný pobyt v prístupovej zóne kedykoľvek počas dňa môže viesť k vyhoreniu, apatii alebo vo všeobecnosti k túžbe už nikdy nevidieť počítač.
História stavu „vždy pripojený“ v interkome
Vo veľmi začiatkoch Intercomu náš technický riaditeľ Ciaran bez pomoci poskytoval celému tímu XNUMX/XNUMX technickú podporu v kancelárii aj mimo nej. Ako Intercom rástol, bola vytvorená pracovná skupina na pomoc Ciaranovi. Čoskoro nato nové vývojové tímy začali vytvárať mnoho nových funkcií a služieb a prevzali všetky zodpovednosti za technickú podporu.
V každom okamihu bolo príliš veľa ľudí „na pohotovosti“.
V tom čase sa tento prístup zdal ako zbytočný, pretože to bol jednoduchý spôsob, ako okamžite rozšíriť náš tím technickej podpory, bol v súlade s našimi hodnotami a vyhovoval našim . Nakoniec sme bez plánov skončili so štyrmi alebo piatimi tímami, ktoré pravidelne kontaktovali klientov počas ich mimopracovnej doby. Zvyšok vývojových tímov nemal veľa zložitých problémov, ktoré by mohli spôsobiť chybu, takže ich volali len zriedka, ak vôbec.
Uvedomili sme si, že sme boli v situácii, keď sme mali mechaniku technickej podpory, na ktorú sme nemohli byť hrdí, a množstvo kritických problémov, ktoré sme chceli opraviť, ako napríklad:
- V danom čase bolo príliš veľa ľudí pripravených prijať výzvu. Naša infraštruktúra nebola dostatočne veľká na to, aby si vyžadovala minimálne päť vývojových inžinierov, ktorí by pracovali bez pravidelných dní voľna.
- Kvalita našich alarmov a volacích postupov nebola konzistentná medzi tímami a na kontrolu nových a existujúcich upozornení na problémy sme použili procesy ad hoc. Pokyny v runbooku (ktoré sa majú dodržiavať pri upozornení na problém) boli väčšinou nápadné svojou absenciou.
- V závislosti od tímu, v ktorom inžinieri pracovali, mali protichodné očakávania. Napríklad len prvý tím technickej podpory mal nejakú kompenzáciu za pracovné zmeny a prerušené víkendy.
- Zdá sa, že existuje všeobecná úroveň tolerancie pre zbytočné hovory v nepárnych hodinách.
- Napokon, tento typ práce nie je pre každého. Životné okolnosti niekedy ukázali, že služobné zmeny nemali na ľudí najlepší vplyv.
Nájdenie správneho stavu „vždy zapnutý“.
Rozhodli sme sa vytvoriť nový virtuálny tím, ktorý bude vykonávať technickú podporu pre každý tím v mimopracovných hodinách. Tím budú tvoriť dobrovoľníci, nie branci zo žiadneho tímu v organizácii. Inžinieri vo virtuálnom tíme sa striedali približne každých šesť mesiacov a trávili týždne „na pohotovosti“. Našťastie sme nemali problém nájsť dostatok dobrovoľníkov na zostavenie virtuálneho tímu.
V dôsledku toho sa náš podporný tím zmenšil z 30 ľudí na iba 6 alebo 7.
Tím sa potom dohodol a definoval, ako by mali upozornenia a popisy problémov vyzerať v príručke runbook, a opísal proces preposielania upozornení novému tímu podpory. Definovali všetky výstrahy v kóde pomocou modulu Terraform a začali používať partnerské hodnotenie pre každú zmenu. Zaviedli sme úroveň kompenzácie za týždennú zmenu, ktorá bola pre služobných dôstojníkov celkom uspokojivá. Vytvorili sme tiež eskalovaný tím druhej úrovne, ktorý pozostával iba z manažérov. Tento tím by mal byť jediným bodom eskalácie pre inžinierov technickej podpory.
Mali sme za sebou niekoľko mesiacov tvrdej práce, počas ktorej sme tento proces nastolili, v dôsledku čoho už nebolo v pohotovosti 30 inžinierov ako predtým, ale len 6 alebo 7. Počas pracovnej doby tímy samostatne riešia problémy so svojimi funkciami resp. služieb, na Toto je čas, kedy zvyčajne dochádza k najväčšiemu počtu porúch, ale vo všetkých ostatných časoch technickú podporu poskytujú dobrovoľníci.
Čo sme sa naučili
Po spustení nášho virtuálneho tímu technickej podpory sme očakávali prílev nových úloh, ako je vyšetrovanie príčin problémov alebo zhromažďovanie sa pri riešení jedného problému, ktorý spôsoboval výpadok. Naše vývojové tímy však prevzali plnú zodpovednosť za faktory spôsobujúce zlyhania a akákoľvek následná reakcia bola zvyčajne okamžitá. Potrebovali sme sa tiež vyhnúť situácii, v ktorej by bola technická konzultačná úloha odoslaná späť tímu, z ktorého prišla, aby sme inžinierov nenútili kontaktovať po pracovnej dobe.
Počet telefonátov po pracovnej dobe klesol na menej ako 10 za mesiac.
Náš proces eskalácie sa formálne používal len zriedka. Častejším názorom bolo, že inžinierovi neoficiálne pomáhal tím, ktorý bol práve online, najmä naši chlapci v kancelárii v San Franciscu. Mnohé problémy boli odstránené alebo zredukované vďaka tímovej práci a ich vyriešeniu za behu.
Inžinieri v našej kancelárii v San Franciscu sa pripojili k tímu na plný úväzok a prekročili rámec bežnej technickej podpory. Boli sme konfrontovaní s určitými režijnými nákladmi, ale rozšírenie členstva v tíme podpory do viacerých kancelárií nám pomohlo, pretože sa ukázalo ako dobrý spôsob, ako budovať vzťahy, posilňovať ich a dozvedieť sa viac o technologickom balíku, s ktorým všetci pracujeme.
Práca vývojárov Intercomu sa v našich tímoch stala konzistentnejšou a na našej stránke môžeme s istotou hovoriť o výhodách systémového inžiniera. , v ktorom sa uvádza, že nie je potrebné byť vždy pripojení, pokiaľ sami nechcete.
Spolu so základnou prácou na stabilizácii a škálovaní našich dátových úložísk, pokračujúce zameranie sa na riešenie problémov zaznamenalo pokles počtu hovorov mimo pracovnej doby na menej ako 10 za mesiac. Na toto číslo sme veľmi hrdí.
Naďalej pracujeme na udržiavaní a zlepšovaní nášho tímu technickej podpory a ako sa Intercom rozrastá, možno budeme musieť prehodnotiť svoje rozhodnutia, pretože to, čo funguje dnes, nemusí nutne fungovať, keď sa nabudúce zdvojnásobí počet našich zamestnancov. Táto skúsenosť však bola pre našu organizáciu mimoriadne pozitívna a výrazne zlepšila kvalitu života našich vývojových inžinierov, kvalitu našich odpovedí na hovory a predovšetkým skúsenosti našich zákazníkov.
Zdroj: hab.com