Како ја сменивме состојбата „секогаш вклучена“ за да спречиме професионално исцрпување

Преводот на статијата е подготвен специјално за студентите на курсот „Практики и алатки на DevOps“.

Мисијата на Интерком е да го персонализира онлајн бизнисот. Но, не можете да персонализирате производ кога тој не функционира. како да. Перформансите се клучни за успехот на нашиот бизнис, не само затоа што нашите клиенти ни плаќаат, туку и затоа што ние самите користиме со вашиот производ. Ако нашата услуга не работи, ние буквално ја чувствуваме болката на нашите клиенти.

Непреченото работење зависи од многу фактори, како што се софтверската архитектура и квалитетот на секојдневната работа. Меѓутоа, многу често се се сведува на тоа дека личноста која е постојано во контакт одговара на повици од Должност. Овој вид техничка поддршка може да биде моќна алатка насочена кон клиентите која ја комбинира помошта на инженерите со она што клиентите го добиваат кога го купуваат вашиот производ. Ова е исто така одлична можност за учење и раст, бидејќи на крајот на краиштата, неуспесите и грешките можат да бидат добра можност за вежбање вештини и разбирање сложени механизми за работа.

Да се ​​биде „секогаш вклучен“ надвор од работното време има штетен ефект врз вашиот живот.

Но, во исто време, да се биде „секогаш вклучен“ може да има штетен ефект врз вашиот живот. Мора да бидете подготвени брзо и компетентно да одговорите на предупредувањето дека нешто е скршено. Дури и ако не ви се страници во даден момент, да се биде „секогаш вклучен“ може да создаде вознемиреност, како што знам од лично искуство. Поради ова, квалитетот на сонот особено силно се влошува. Редовното наоѓање во зоната за пристап во секое време од денот може да доведе до исцрпеност, апатија или, воопшто, желба никогаш повеќе да не го видите компјутерот.

Историја на состојбата „секогаш поврзана“ во интерком

Во раните денови на Интерком, нашиот технички директор, Сиаран, сам обезбеди цел тим од 24/7 техничка поддршка, и во и надвор од канцеларијата. Како што растеше Intercom, беше создадена работна група за да му помогне на Ciaran. Набргу потоа, новите развојни тимови почнаа да создаваат многу нови функции и услуги и ги презедоа сите одговорности за техничка поддршка.

Имаше премногу луѓе „на повик“ во секој момент.

Во тоа време, овој пристап изгледаше како бесмислен затоа што беше лесен начин да го зголемиме нашиот тим за техничка поддршка во момент, тој беше усогласен со нашите вредности и одговараше на нашите чувство на сопственост. На крајот, без никакви планови, завршивме со четири-пет тимови кои редовно контактираа со клиентите во нивното неработно време. Остатокот од развојните тимови немаа многу сложени проблеми што може да предизвикаат грешка, па затоа ретко, ако некогаш, беа повикани.

Сфативме дека сме во ситуација кога имавме механика за техничка поддршка со која не можевме да се гордееме, и голем број критични проблеми што сакавме да ги поправиме, како што се:

• Имаше премногу луѓе подготвени да го преземат предизвикот во секој момент. Нашата инфраструктура не беше доволно голема за да бара најмалку пет развојни инженери да работат без редовни слободни денови.
• Квалитетот на нашите процедури за аларми и повици не беше конзистентен меѓу тимовите и користевме ад хок процеси за прегледување на новите и постоечките предупредувања за проблеми. Упатствата во тековната книга (кои треба да се следат кога се известени за проблем) беа претежно видливи со нивното отсуство.
• Во зависност од тимот во кој работеле инженерите, тие имале спротивставени очекувања. На пример, само првиот тим за техничка поддршка имаше компензација за дежурства и нарушени викенди.
• Се чинеше дека постои општо ниво на толеранција за непотребни повици во непарни часови.
• Конечно, овој тип на работа не е за секого. Животните околности понекогаш покажаа дека смените на дежурствата немаат најдобар ефект врз луѓето.

Наоѓање на вистинската состојба „секогаш вклучено“.

Решивме да создадеме нов виртуелен тим кој ќе врши работи за техничка поддршка за секој тим во неработно време. Тимот ќе биде составен од волонтери, а не регрути од кој било тим во организацијата. Инженерите во виртуелниот тим ротираат приближно на секои шест месеци, поминувајќи неколку недели „на повик“. За среќа, немавме проблем да најдеме доволно волонтери за да составиме виртуелен тим.

Како резултат на тоа, нашиот тим за поддршка беше намален од 30 луѓе на само 6 или 7.

Тимот потоа се согласи и дефинираше како треба да изгледаат предупредувањата и описите на проблемите во книгата, и опиша процес за препраќање предупредувања до новиот тим за поддршка. Тие ги дефинираа сите предупредувања во кодот користејќи Terraform модул и почнаа да користат рецензија за секоја промена. Воведовме ниво на надоместок за неделна смена што беше сосема задоволително за дежурните. Создадовме и ескалиран тим од второ ниво кој се состоеше само од менаџери. Овој тим треба да биде единствената точка на ескалација за инженерите за техничка поддршка.

Имавме неколку месеци напорна работа, при што го воспоставивме овој процес, како резултат на тоа, сега немаше 30 инженери на повик како порано, туку само 6 или 7. Во текот на работното време, тимовите самостојно се справуваат со проблемите со нивните функции или услуги, на Ова е време кога вообичаено се случуваат најголем број на дефекти, но во сите други времиња, техничка поддршка се обезбедува од волонтери.

Она што го научивме

Откако го лансиравме нашиот виртуелен тим за техничка поддршка, очекувавме прилив на нови задачи, како што е истражување на причините за проблемите или собирање заедно за да решиме единствен проблем што предизвикуваше прекин. Сепак, нашите развојни тимови ја презедоа целосната одговорност за факторите кои предизвикуваат неуспеси и секој последователен одговор обично беше моментален. Исто така, требаше да избегнеме ситуација во која задачата за техничка консултација ќе биде вратена назад до тимот од кој дојде, за да не ги принудиме инженерите да контактираат по работното време.

Бројот на повици после работното време е намален на помалку од 10 месечно.

Нашиот процес на ескалација ретко се користеше формално. Почесто верување беше дека на инженерот неофицијално му помага тимот кој моментално беше онлајн, особено нашите момци во канцеларијата во Сан Франциско. Многу прашања беа елиминирани или намалени преку тимска работа и нивно решавање во лет.

Инженерите во нашата канцеларија во Сан Франциско му се придружија на тимот со полно работно време и ја надминаа вообичаената техничка поддршка. Се соочивме со некои режиски трошоци, но ширењето на членството на нашиот тим за поддршка низ повеќе канцеларии работеше во наша корист бидејќи се покажа како добар начин да изградиме односи, да ги зајакнеме и да дознаеме повеќе за технолошкиот куп со кој сите работиме.

Работата на развивачите на интерком стана поконзистентна во нашите тимови и можеме со сигурност да зборуваме за придобивките од тоа да се биде системски инженер на нашата страница Вработувања, наведувајќи дека нема потреба секогаш да бидете поврзани освен ако не сакате да бидете.

Заедно со фундаменталната работа за стабилизирање и зголемување на нашите складишта на податоци, континуираниот фокус на решавање проблеми бележи намалување на бројот на повици надвор од работното време на помалку од 10 месечно. Многу сме горди на оваа бројка.

Продолжуваме да работиме на одржување и подобрување на нашиот тим за техничка поддршка, и како што Intercom расте, можеби ќе треба да ги преиспитаме нашите одлуки, бидејќи она што функционира денес нема да мора да функционира следниот пат кога нашиот персонал ќе се удвои. Сепак, ова искуство беше исклучително позитивно за нашата организација и во голема мера го подобри квалитетот на животот на нашите развојни инженери, квалитетот на нашите одговори на повиците и најмногу од сè, искуството на нашите клиенти.

Извор: www.habr.com