Пераклад артыкула падрыхтаваны спецыяльна для студэнтаў курса .
Місія Intercom заключаецца ў тым, каб зрабіць бізнэс у інтэрнэце персаналізаваным. Але персаналізаванай прадукт немагчыма, калі ён не працуе . Працаздольнасць крытычная для поспеху нашай справы і не толькі таму, што нашы кліенты плацяць нам, але і таму што мы самі карыстаемся . Калі наш сэрвіс не працуе, мы літаральна адчуваем боль нашых кліентаў.
Бесперабойная праца залежыць ад шматлікіх фактараў, такіх як архітэктура праграмнага забеспячэння і якасць штодзённай працы. Аднак даволі часта ўсё зводзіцца да таго, што чалавек, які заўсёды на сувязі, адказвае на выклікі ад . Такая тэхнічная падтрымка можа быць магутным кліентаарыентаваным інструментам, які аб'ядноўвае дапамогу інжынераў з тым, што кліенты атрымліваюць, набываючы ваш прадукт. Таксама тут адкрываецца выдатная магчымасць для навучання і росту, бо ў рэшце рэшт, выхады са строю і памылкі могуць быць добрым полем для адпрацоўкі навыкаў і разумення складаных механізмаў працы.
Знаходжанне "заўсёды на сувязі" па-за працоўным часам дзейнічае на ваша жыццё згубна.
Але ў той жа час стан "заўсёды на сувязі" можа аказваць на ваша жыццё згубнае ўздзеянне. Вы павінны быць гатовыя хутка і пісьменна адрэагаваць на апавяшчэнне аб тым, што нешта зламалася. Нават калі вас не выклікаюць па пэйджары ў дадзены пэўны момант, стан "заўсёды на сувязі" ўсяляе пачуццё турботы, я і сам ведаю гэта з асабістага досведу. Асабліва моцна з-за гэтага пагаршаецца якасць сну. Рэгулярнае знаходжанне ў зоне доступу ў любы час сутак можа прывесці да выгарання, апатыі ці ў цэлым да жадання больш ніколі не бачыць кампутар.
Гісторыя стану "заўсёды на сувязі" у Intercom
У самыя першыя дні працы Intercom наш тэхнічны дырэктар Кьяран у адзіночку быў цэлай камандай кругласутачнай тэхнічнай падтрымкі, як у офісе, так і па-за ім. Па меры таго, як рос Intercom была створана аператыўная група для дапамогі Кьяран. Неўзабаве пасля гэтага новыя каманды распрацоўшчыкаў пачалі ствараць мноства новых функцый і сэрвісаў, і ўжо яны ўзялі на сябе ўсе абавязкі па тэхнічнай падтрымцы.
У любы момант людзей "на сувязі" было занадта шмат.
У той час такі падыход здаваўся самым разумным, паколькі гэта быў лёгкі спосаб маштабаваць каманду тэхнічнай падтрымкі ў любы момант, ён адказваў нашым каштоўнасцям і цешыў наша . У выніку, без якіх-небудзь планаў у нас атрымалася чатыры ці пяць каманд, якія рэгулярна выходзілі на сувязь з кліентамі ў свой непрацоўны час. У астатніх каманд распрацоўшчыкаў было не так шмат складаных момантаў, якія маглі выдаць памылку, таму іх выклікалі рэдка, калі наогул калі-небудзь выклікалі.
Мы ўсвядомілі, што апынуліся ў сітуацыі, калі ў нас ёсць механіка працы тэхнічнай падтрымкі, якой нельга ганарыцца, і шэраг крытычных праблем, якія мы хацелі ўхіліць, такіх як:
- У любы момант часу прыняць выклік былі гатовы занадта шмат людзей. Наша інфраструктура была не настолькі вялікая, каб патрабавалася мінімум пяць інжынераў-распрацоўшчыкаў, якія працавалі б без нармальных выходных.
- Якасць нашых сігналаў трывогі і працэдур выкліку было не ўзгоднена паміж камандамі, мы выкарыстоўвалі спецыяльныя працэсы агляду новых і наяўных абвестках аб праблемах. Указанні ў runbook (якім трэба прытрымлівацца пры атрыманні абвесткі аб праблеме) у асноўным кідаліся ў вочы сваёй адсутнасцю.
- У залежнасці ад каманды, у які інжынеры працавалі, у іх складаліся супярэчлівыя чаканні. Напрыклад, толькі самая першая каманда тэхнічнай падтрымкі мела якую-небудзь кампенсацыю за дзяжурныя змены і сарваныя выходныя.
- Аказалася, што існуе агульны ўзровень цярпімасці да непатрэбных выклікаў у нявызначаны час.
- Нарэшце такі тып працы падыходзіць не ўсім. Жыццёвыя абставіны часам паказвалі, што дзяжурныя змены ўплываюць на людзей не лепшым чынам.
Пошук правільнага стану "заўсёды на сувязі"
Мы вырашылі стварыць новую віртуальную каманду, якая будзе выконваць працу тэхнічнай падтрымкі кожнай каманды, калі ў той будзе непрацоўны час. Каманда будзе складацца з добраахвотнікаў, а не прызыўнікоў з любой каманды арганізацыі. Інжынеры ў віртуальнай камандзе мяняліся прыкладна кожныя шэсць месяцаў, праводзячы тыдні "на сувязі". На шчасце, у нас не было праблем са знаходжаннем дастатковай колькасці добраахвотнікаў для збору віртуальнай каманды.
У выніку наша каманда падтрымкі скарацілася з 30 чалавек усяго да 6 ці 7.
Затым гэтая каманда ўзгадніла і вызначыла, як павінны выглядаць абвесткі аб праблемах і апісанні ў runbook, і апісала працэс пераадрасацыі абвестак у новую каманду падтрымкі. Яны вызначылі ўсе абвесткі ў кодзе з дапамогай модуля Terraform, і пачалі выкарыстоўваць экспертную адзнаку для кожнай змены. Мы ўвялі такі ўзровень кампенсацыі за тыднёвую змену, які цалкам задавальняў дзяжурных. Мы таксама стварылі эскаляваную каманду другога ўзроўню, якая складалася толькі з мэнэджэраў. Гэтая каманда павінна быць адзінай кропкай эскалацыі інжынераў тэхнічнай падтрымкі.
У нас было некалькі месяцаў напружанай працы, на працягу якіх мы наладжвалі гэты працэс, у выніку на сувязі зараз заставаліся не 30 інжынераў як раней, а ўсяго 6 ці 7. На працягу працоўнага часу каманды самастойна разбіраюцца з праблемамі са сваімі функцыямі ці сэрвісамі, на гэты час звычайна даводзіцца самая вялікая колькасць паломак, аднак ва ўвесь астатні час тэхнічнай падтрымкай займаюцца добраахвотнікі.
Што мы даведаліся
Пасля таго як мы запусцілі нашу віртуальную каманду тэхнічнай падтрымкі, мы чакалі наплыву новых задач, такіх як даследаванне прычын з'яўлення праблем або агульны збор для вырашэння нейкай адной праблемы, якая выклікала збой. Тым не менш, нашы каманды распрацоўшчыкаў узялі на сябе ўсю адказнасць за фактары, якія выклікаюць збоі, і любой наступнай рэакцыяй як правіла былі неадкладныя меры. Таксама нам трэба было пазбегнуць сітуацыі, пры якой задача па тэхнічнай кансультацыі вярталася б назад камандзе, ад якой яна паступіла, каб не прымушаць інжынераў выходзіць на сувязь у непрацоўны час.
Колькасць выклікаў у непрацоўны час скарацілася менш, чым да 10 за месяц.
Фармальна наш працэс эскалацыі выкарыстоўваўся рэдка. Больш распаўсюджаным меркаваннем было, што інжынеру неафіцыйна дапамагае каманда, якая ў дадзены момант знаходзіцца ў сетцы, асабліва гэта датычылася нашых хлопцаў з офіса ў Сан-Францыска. Многія праблемы былі ліквідаваны або іх колькасць была зменшана з дапамогай каманднай працы і вырашэння іх на лета.
Інжынеры ў нашым офісе ў Сан-Францыска далучыся да каманды поўным складам і выйшлі за рамкі звычайнай тэхнічнай падтрымкі. Перад намі стаяла пытанне аб пэўных накладных выдатках, аднак распаўсюджванне сяброўства ў камандзе падтрымкі на некалькі офісаў згуляла нам на руку, бо гэта аказалася добрым спосабам пабудаваць адносіны, умацаваць іх і даведацца больш аб стэку тэхналогій, з якім мы ўсе працуем.
У нашых камандах праца распрацоўнікаў Intercom стала больш паслядоўнай, і мы можам упэўнена казаць аб перавагах пасады сістэмнага інжынера на нашым сайце , заяўляючы, што няма неабходнасці заўсёды быць на сувязі, калі вы гэтага не хочаце самі.
Нараўне з фундаментальнай працай па стабілізацыі і маштабаванні нашых сховішчаў дадзеных, сталая ўвага да рашэння праблем прывяла да таго, што колькасць выклікаў у непрацоўны час скарацілася менш, чым да 10 у месяц. Гэтым лікам мы вельмі ганарымся.
Мы працягваем працаваць над зместам і паляпшэннем нашай каманды тэхнічнай падтрымкі, і па меры росту Intercom нам, магчыма, давядзецца перагледзець свае рашэнні, бо тое, што працуе сёння, не абавязкова будзе працаваць наступным разам, калі колькасць нашых супрацоўнікаў павялічыцца ўдвая. Тым не менш, гэты вопыт быў вельмі пазітыўным для нашай арганізацыі, ён значна палепшыў якасць жыцця нашых інжынераў-распрацоўшчыкаў, якасць нашых адказаў на выклікі і, перш за ўсё, досвед нашых кліентаў.
Крыніца: habr.com