Překlad článku byl připraven speciálně pro studenty kurzu .
Posláním Intercomu je personalizovat online podnikání. Ale nemůžete personalizovat produkt, když nefunguje. . Výkon je rozhodující pro úspěch našeho podnikání nejen proto, že nás naši klienti platí, ale také proto, že my sami využíváme . Pokud naše služba nefunguje, doslova cítíme bolest našich zákazníků.
Bezproblémový provoz závisí na mnoha faktorech, jako je architektura softwaru a kvalita každodenní práce. Poměrně často to ale všechno souvisí s tím, že telefonáty odpoví vždy ten, kdo je v kontaktu . Tento druh technické podpory může být výkonným nástrojem zaměřeným na zákazníka, který kombinuje pomoc inženýrů s tím, co zákazníci získají, když si koupí váš produkt. Je to také skvělá příležitost k učení a růstu, protože koneckonců neúspěchy a chyby mohou být dobrou příležitostí k procvičení dovedností a pochopení složitých pracovních mechanismů.
Být „vždy zapnutý“ mimo pracovní dobu má škodlivý vliv na váš život.
Ale zároveň být „vždy zapnutý“ může mít škodlivý vliv na váš život. Musíte být připraveni rychle a kompetentně reagovat na upozornění, že je něco rozbité. I když nejste v žádném okamžiku voláni, být „vždy zapnutý“ může vyvolat úzkost, jak vím z vlastní zkušenosti. Z tohoto důvodu se kvalita spánku zvláště silně zhoršuje. Pravidelný pobyt v přístupové zóně v kteroukoli denní dobu může vést k vyhoření, apatii nebo obecně k touze počítač už nikdy nevidět.
Historie stavu „vždy připojeno“ v interkomu
Ve velmi raných dobách Intercomu náš technický ředitel Ciaran sám poskytoval celému týmu XNUMX/XNUMX technickou podporu v kanceláři i mimo ni. Jak Intercom rostl, byla vytvořena pracovní skupina na pomoc Ciaranovi. Brzy poté začaly nové vývojové týmy vytvářet mnoho nových funkcí a služeb a převzaly veškerou odpovědnost za technickou podporu.
V každém okamžiku bylo „v pohotovosti“ příliš mnoho lidí.
V té době se tento přístup zdál být bez rozmyslu, protože to byl snadný způsob, jak okamžitě rozšířit náš tým technické podpory, byl v souladu s našimi hodnotami a vyhovoval našim . Nakonec jsme bez plánů skončili se čtyřmi nebo pěti týmy, které pravidelně kontaktovaly klienty v jejich mimopracovní době. Zbytek vývojových týmů neměl mnoho složitých problémů, které by mohly způsobit chybu, takže byli voláni zřídka, pokud vůbec.
Uvědomili jsme si, že jsme byli v situaci, kdy jsme měli mechaniku technické podpory, na kterou jsme nemohli být hrdí, a řadu kritických problémů, které jsme chtěli opravit, jako například:
- Bylo příliš mnoho lidí připravených přijmout výzvu v kteroukoli danou chvíli. Naše infrastruktura nebyla dostatečně velká, aby vyžadovala minimálně pět vývojových inženýrů, kteří by pracovali bez pravidelných dnů volna.
- Kvalita našich alarmů a postupů volání nebyla napříč týmy konzistentní a ke kontrole nových a stávajících výstrah na problémy jsme používali procesy ad hoc. Pokyny v runbooku (které je třeba dodržovat při upozornění na problém) byly většinou nápadné svou nepřítomností.
- V závislosti na týmu, ve kterém inženýři pracovali, měli protichůdná očekávání. Například pouze první tým technické podpory měl nějakou kompenzaci za směny na zavolání a narušené víkendy.
- Zdálo se, že existuje obecná úroveň tolerance pro zbytečné hovory v liché hodiny.
- Konečně, tento typ práce není pro každého. Životní okolnosti někdy ukázaly, že služební směny neměly na lidi nejlepší vliv.
Nalezení správného stavu „vždy zapnuto“.
Rozhodli jsme se vytvořit nový virtuální tým, který by pro každý tým prováděl technickou podporu v mimopracovní době. Tým se bude skládat z dobrovolníků, nikoli z branců z žádného týmu v organizaci. Inženýři ve virtuálním týmu se střídali přibližně každých šest měsíců a trávili týdny „na zavolání“. Naštěstí jsme neměli problém najít dostatek dobrovolníků na sestavení virtuálního týmu.
V důsledku toho byl náš podpůrný tým zredukován z 30 lidí na pouhých 6 nebo 7.
Tým se poté dohodl a definoval, jak by výstrahy a popisy problémů měly v sadě runbook vypadat, a popsal proces předávání výstrah novému týmu podpory. Definovali všechna upozornění v kódu pomocí modulu Terraform a začali používat peer review pro každou změnu. Zavedli jsme úroveň kompenzace za týdenní směnu, která byla pro důstojníky ve službě docela uspokojivá. Vytvořili jsme také eskalovaný tým druhé úrovně, který se skládal pouze z manažerů. Tento tým by měl být jediným bodem eskalace pro inženýry technické podpory.
Měli jsme za sebou několik měsíců tvrdé práce, během které jsme tento proces nastavili, v důsledku toho nyní nebylo v pohotovosti 30 inženýrů jako dříve, ale pouze 6 nebo 7. V pracovní době týmy samostatně řeší problémy se svými funkcemi resp. služby, dne V této době obvykle dochází k největšímu počtu poruch, ale ve všech ostatních časech je technická podpora zajišťována dobrovolníky.
Co jsme se naučili
Poté, co jsme spustili náš virtuální tým technické podpory, očekávali jsme příliv nových úkolů, jako je zkoumání příčin problémů nebo shromažďování se k vyřešení jediného problému, který způsoboval výpadek. Naše vývojové týmy však převzaly plnou odpovědnost za faktory způsobující selhání a jakákoli následná reakce byla obvykle okamžitá. Potřebovali jsme se také vyhnout situaci, kdy by byl úkol technické konzultace poslán zpět týmu, ze kterého přišel, abychom nenutili inženýry kontaktovat po pracovní době.
Počet hovorů po pracovní době klesl na méně než 10 za měsíc.
Náš proces eskalace byl jen zřídka používán formálně. Častějším názorem bylo, že inženýrovi neoficiálně pomáhal tým, který byl právě online, zejména naši kluci v kanceláři v San Franciscu. Mnoho problémů bylo odstraněno nebo redukováno díky týmové práci a jejich řešením za chodu.
Inženýři v naší kanceláři v San Franciscu se k týmu připojili na plný úvazek a šli nad rámec obvyklé technické podpory. Potýkali jsme se s určitými režijními náklady, ale rozložení členství v týmu podpory do více kanceláří nám přineslo výhodu, protože se ukázalo jako dobrý způsob, jak budovat vztahy, posilovat je a dozvědět se více o technologickém balíčku, se kterým všichni pracujeme.
Práce vývojářů Intercomu se v našich týmech stala konzistentnější a na našem webu můžeme s jistotou mluvit o výhodách systémového inženýra. , uvádějící, že není nutné být vždy připojeni, pokud sami nechcete.
Spolu se základní prací na stabilizaci a škálování našich datových úložišť se díky pokračujícímu zaměření na řešení problémů snížil počet hovorů mimo pracovní dobu na méně než 10 za měsíc. Na toto číslo jsme velmi hrdí.
Nadále pracujeme na udržování a zlepšování našeho týmu technické podpory a jak se Intercom rozrůstá, možná budeme muset přehodnotit svá rozhodnutí, protože to, co funguje dnes, nemusí nutně fungovat, až se náš personál zdvojnásobí. Tato zkušenost však byla pro naši organizaci mimořádně pozitivní a výrazně zlepšila kvalitu života našich vývojových inženýrů, kvalitu našich odpovědí na volání a především zkušenost našich zákazníků.
Zdroj: www.habr.com