Как сменихме винаги свързаното състояние, за да предотвратим прегаряне

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

Мисията на Intercom е да персонализира онлайн бизнеса. Но не можете да персонализирате продукт, когато не работи. как да. Изпълнението е от решаващо значение за успеха на нашия бизнес, не само защото нашите клиенти ни плащат, но и защото ние самите използваме с вашия продукт. Ако нашата услуга не работи, ние буквално усещаме болката на нашите клиенти.

Безпроблемната работа зависи от много фактори, като например софтуерната архитектура и качеството на ежедневната работа. Въпреки това, доста често всичко се свежда до факта, че човекът, който винаги е във връзка, отговаря на обаждания от PagerDuty. Този вид техническа поддръжка може да бъде мощен ориентиран към клиента инструмент, който съчетава помощта на инженерите с това, което клиентите получават, когато закупят вашия продукт. Това също е чудесна възможност за учене и растеж, защото в крайна сметка неуспехите и грешките могат да бъдат добра възможност за практикуване на умения и разбиране на сложни механизми на работа.

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

Но в същото време да си „винаги включен“ може да има пагубен ефект върху живота ти. Трябва да сте готови бързо и компетентно да реагирате на сигнал за повреда. Дори и да не ви звънят в даден момент, това, че сте „винаги включени“, може да създаде безпокойство, както знам от личен опит. Поради това качеството на съня се влошава особено силно. Редовното пребиваване в зоната за достъп по всяко време на деня може да доведе до прегаряне, апатия или като цяло желание никога повече да не видите компютъра.

История на състоянието „винаги свързан“ в Intercom

В най-ранните дни на Intercom, нашият технически директор, Ciaran, еднолично осигури цял екип от XNUMX/XNUMX техническа поддръжка, както в офиса, така и извън него. С разрастването на Intercom беше създадена работна група, за да помогне на Ciaran. Скоро след това нови екипи за разработка започнаха да създават много нови функции и услуги и поеха всички отговорности за техническа поддръжка.

Във всеки един момент имаше твърде много хора „на повикване“.

По онова време този подход изглеждаше безсмислен, защото беше лесен начин за мащабиране на нашия екип за техническа поддръжка в един момент, беше в съответствие с нашите ценности и отговаряше на нашите чувство за собственост. В крайна сметка, без никакви планове, се оказахме с четири-пет екипа, които редовно контактуваха с клиенти в извънработно време. Останалите екипи за разработка не са имали много сложни проблеми, които биха могли да доведат до грешка, така че рядко, ако изобщо са били извиквани.

Осъзнахме, че сме в ситуация, в която имаме механици за техническа поддръжка, с които не можем да се гордеем, и редица критични проблеми, които искахме да коригираме, като например:

• Имаше твърде много хора, готови да поемат предизвикателството във всеки един момент. Нашата инфраструктура не беше достатъчно голяма, за да изисква минимум петима инженери по разработката да работят без редовни почивни дни.
• Качеството на нашите аларми и процедури за обаждания не беше последователно в екипите и ние използвахме ad hoc процеси, за да прегледаме нови и съществуващи сигнали за проблеми. Инструкциите в сборника (които трябва да се следват при уведомяване за проблем) бяха най-вече забележими с липсата си.
• В зависимост от екипа, в който са работили инженерите, те са имали противоречиви очаквания. Например, само първият екип за техническа поддръжка имаше някаква компенсация за смени на повикване и прекъснати почивни дни.
• Изглежда, че има общо ниво на толерантност към ненужни обаждания в нечетни часове.
• И накрая, този вид работа не е за всеки. Житейските обстоятелства понякога показваха, че дежурствата не се отразяват най-добре на хората.

Намиране на правилното състояние „винаги включено“.

Решихме да създадем нов виртуален екип, който да извършва техническа поддръжка за всеки екип в извънработно време. Екипът ще бъде съставен от доброволци, а не наборници от който и да е екип в организацията. Инженерите във виртуалния екип се сменят приблизително на всеки шест месеца, прекарвайки седмици „на повикване“. За щастие нямахме проблем с намирането на достатъчно доброволци, за да съберем виртуален екип.

В резултат на това нашият екип за поддръжка беше намален от 30 души на само 6 или 7.

След това екипът се споразумя и определи как трябва да изглеждат предупрежденията и описанията за проблеми в сборника и описа процес за препращане на предупреждения към новия екип за поддръжка. Те дефинираха всички предупреждения в кода с помощта на модул Terraform и започнаха да използват партньорска проверка за всяка промяна. Въведохме ниво на възнаграждение за седмична смяна, което беше доста задоволително за дежурните. Създадохме и ескалиран екип от второ ниво, който се състоеше само от мениджъри. Този екип трябва да бъде единствената точка за ескалация за инженерите по техническа поддръжка.

Имахме няколко месеца упорита работа, през които установихме този процес, в резултат на което вече нямаше 30 инженери на повикване, както преди, а само 6 или 7. В работно време екипите самостоятелно се справят с проблеми във функциите си или услуги, на Това е времето, когато обикновено се случва най-голям брой повреди, но през всички останали моменти техническата поддръжка се осигурява от доброволци.

Какво научихме

След като стартирахме нашия виртуален екип за техническа поддръжка, очаквахме приток на нови задачи, като например разследване на причината за проблемите или събиране за решаване на един проблем, който причиняваше прекъсване. Нашите екипи за разработка обаче поеха пълната отговорност за факторите, причиняващи неуспехите, и всеки последващ отговор обикновено беше незабавен. Също така трябваше да избегнем ситуация, при която задача за техническа консултация ще бъде изпратена обратно на екипа, от който е дошла, за да не принуждаваме инженерите да се свързват след работно време.

Броят на обажданията в извънработно време е спаднал до под 10 на месец.

Нашият процес на ескалация рядко се използва официално. По-разпространеното вярване беше, че инженерът е бил неофициално подпомогнат от екипа, който в момента е бил онлайн, особено от нашите момчета в офиса в Сан Франциско. Много проблеми бяха елиминирани или намалени чрез екипна работа и разрешаването им в движение.

Инженерите в нашия офис в Сан Франциско се присъединиха към екипа на пълен работен ден и надхвърлиха обичайната техническа поддръжка. Бяхме изправени пред някои режийни разходи, но разпределянето на членството в нашия екип за поддръжка в множество офиси беше в наша полза, тъй като се оказа добър начин да изградим връзки, да ги укрепим и да научим повече за технологичния пакет, с който всички работим.

Работата на Intercom разработчиците стана по-последователна в нашите екипи и можем уверено да говорим за предимствата да бъдеш системен инженер на нашия сайт Кариери, заявявайки, че няма нужда винаги да сте свързани, освен ако не искате да бъдете.

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

Продължаваме да работим върху поддържането и подобряването на нашия екип за техническа поддръжка и с нарастването на Intercom може да се наложи да преразгледаме решенията си, защото това, което работи днес, не е задължително да работи следващия път, когато персоналът ни се удвои. Този опит обаче беше изключително положителен за нашата организация и значително подобри качеството на живот на нашите инженери по разработката, качеството на нашите отговори на обаждания и най-вече опита на нашите клиенти.

Източник: www.habr.com