Paano namin binago ang "palaging naka-on" na estado upang maiwasan ang pagka-burnout sa propesyonal

Ang pagsasalin ng artikulo ay partikular na inihanda para sa mga mag-aaral ng kurso "Mga kasanayan at tool ng DevOps".

Paano namin binago ang "palaging naka-on" na estado upang maiwasan ang pagka-burnout sa propesyonal

Ang misyon ng Intercom ay i-personalize ang online na negosyo. Ngunit hindi mo maaaring i-personalize ang isang produkto kapag hindi ito gumagana. Paano. Ang pagganap ay kritikal sa tagumpay ng aming negosyo, hindi lamang dahil binabayaran kami ng aming mga kliyente, kundi dahil kami mismo ang gumagamit kasama ang iyong produkto. Kung hindi gumana ang aming serbisyo, literal naming nararamdaman ang sakit ng aming mga customer.

Ang maayos na operasyon ay nakasalalay sa maraming mga kadahilanan, tulad ng arkitektura ng software at ang kalidad ng pang-araw-araw na gawain. Gayunpaman, kadalasan ang lahat ay nauuwi sa katotohanan na ang taong laging nakikipag-ugnayan ay sumasagot sa mga tawag mula sa PagerDuty. Ang ganitong uri ng teknikal na suporta ay maaaring maging isang mahusay na tool na nakatuon sa customer na pinagsasama ang tulong ng mga inhinyero sa kung ano ang nakukuha ng mga customer kapag binili nila ang iyong produkto. Ito rin ay isang magandang pagkakataon para sa pag-aaral at paglago, dahil pagkatapos ng lahat, ang mga pagkabigo at pagkakamali ay maaaring maging isang magandang pagkakataon upang magsanay ng mga kasanayan at maunawaan ang mga kumplikadong mekanismo ng pagtatrabaho.

Ang pagiging "palaging naka-on" sa labas ng oras ng trabaho ay may masamang epekto sa iyong buhay.

Ngunit sa parehong oras, ang pagiging "palaging naka-on" ay maaaring magkaroon ng masamang epekto sa iyong buhay. Dapat ay handa kang mabilis at mahusay na tumugon sa isang alerto na may sira. Kahit na hindi ka pinapa-page sa anumang partikular na sandali, ang pagiging "palaging naka-on" ay maaaring lumikha ng pagkabalisa, tulad ng alam ko mula sa personal na karanasan. Dahil dito, ang kalidad ng pagtulog ay lumalala lalo na nang malakas. Ang regular na pagiging nasa access zone sa anumang oras ng araw ay maaaring humantong sa pagka-burnout, kawalang-interes, o, sa pangkalahatan, isang pagnanais na hindi na muling makita ang computer.

Kasaysayan ng "palaging konektado" na estado sa Intercom

Sa mga unang araw ng Intercom, ang aming Teknikal na Direktor, si Ciaran, ay nag-iisang nagbigay ng buong koponan ng XNUMX/XNUMX na teknikal na suporta, sa loob at labas ng opisina. Habang lumalaki ang Intercom, isang task force ang nilikha upang tulungan si Ciaran. Di nagtagal, nagsimula ang mga bagong development team na lumikha ng maraming bagong feature at serbisyo, at kinuha nila ang lahat ng responsibilidad sa teknikal na suporta.

Napakaraming tao ang "nanawagan" sa anumang oras.

Noong panahong iyon, ang diskarte na ito ay tila walang utak dahil ito ay isang madaling paraan upang masukat ang aming tech support team sa isang sandali, naaayon ito sa aming mga halaga, at nababagay ito sa aming pakiramdam ng pagmamay-ari. Sa huli, nang walang anumang plano, napunta kami sa apat o limang koponan na regular na nakikipag-ugnayan sa mga kliyente sa kanilang mga oras na hindi nagtatrabaho. Ang iba sa mga development team ay walang maraming kumplikadong isyu na maaaring magdulot ng error, kaya bihira sila, kung sakaling, tinawag.

Napagtanto namin na nasa sitwasyon kami kung saan mayroon kaming mga teknikal na mekanika ng suporta na hindi namin maipagmamalaki, at ilang kritikal na isyu na gusto naming ayusin, gaya ng:

  • Napakaraming tao ang handang harapin ang hamon sa anumang oras. Hindi sapat ang laki ng aming imprastraktura upang mangailangan ng hindi bababa sa limang development engineer na magtrabaho nang walang regular na araw na walang pasok.
  • Ang kalidad ng aming mga alarma at mga pamamaraan sa pagtawag ay hindi pare-pareho sa lahat ng mga koponan, at gumamit kami ng mga ad hoc na proseso upang suriin ang bago at kasalukuyang mga alerto sa problema. Ang mga tagubilin sa runbook (na susundin kapag naabisuhan ng isang problema) ay halos kapansin-pansin sa kanilang kawalan.
  • Depende sa pangkat kung saan nagtrabaho ang mga inhinyero, mayroon silang magkasalungat na inaasahan. Halimbawa, ang pinakaunang technical support team lang ang nagkaroon ng anumang kabayaran para sa mga on-call shift at naabala sa katapusan ng linggo.
  • Lumilitaw na may pangkalahatang antas ng pagpapaubaya para sa mga hindi kinakailangang tawag sa mga kakaibang oras.
  • Sa wakas, ang ganitong uri ng trabaho ay hindi para sa lahat. Ang mga pangyayari sa buhay kung minsan ay nagpakita na ang mga paglilipat ng tungkulin ay walang pinakamagandang epekto sa mga tao.

Paghahanap ng tamang "palaging naka-on" na estado

Nagpasya kaming lumikha ng bagong virtual na koponan na magsasagawa ng teknikal na suporta sa trabaho para sa bawat koponan sa mga oras na hindi nagtatrabaho. Ang koponan ay bubuuin ng mga boluntaryo, hindi mga conscript mula sa alinmang koponan sa organisasyon. Ang mga inhinyero sa virtual na koponan ay umiikot ng humigit-kumulang bawat anim na buwan, na gumugugol ng mga linggo "on call." Sa kabutihang palad, wala kaming problema sa paghahanap ng sapat na mga boluntaryo upang bumuo ng isang virtual na koponan.

Bilang resulta, ang aming team ng suporta ay nabawasan mula 30 tao hanggang 6 o 7 na lang.

Pagkatapos ay sumang-ayon ang koponan at tinukoy kung ano ang magiging hitsura ng mga alerto at paglalarawan ng isyu sa runbook, at inilarawan ang isang proseso para sa pagpapasa ng mga alerto sa bagong team ng suporta. Tinukoy nila ang lahat ng alerto sa code gamit ang isang Terraform module, at nagsimulang gumamit ng peer review para sa bawat pagbabago. Ipinakilala namin ang isang antas ng kabayaran para sa isang lingguhang shift na medyo kasiya-siya sa mga opisyal ng tungkulin. Gumawa din kami ng second-level escalated team na binubuo lang ng mga manager. Ang pangkat na ito ay dapat na ang nag-iisang punto ng pagdami para sa mga inhinyero ng teknikal na suporta.

Nagkaroon kami ng ilang buwan ng pagsusumikap, kung saan itinatag namin ang prosesong ito; bilang resulta, wala na ngayong 30 inhinyero ang nakatawag tulad ng dati, ngunit 6 o 7 lamang. Sa mga oras ng pagtatrabaho, ang mga koponan ay independyenteng humaharap sa mga problema sa kanilang mga tungkulin o mga serbisyo, sa Ito ang oras kung kailan kadalasang nangyayari ang pinakamalaking bilang ng mga pagkasira, ngunit sa lahat ng iba pang pagkakataon, ang teknikal na suporta ay ibinibigay ng mga boluntaryo.

Ang natutunan namin

Pagkatapos naming ilunsad ang aming virtual technical support team, inaasahan namin ang pagdagsa ng mga bagong gawain, gaya ng pagsisiyasat sa mga sanhi ng mga problema o pagsasama-sama upang malutas ang isang problema na nagdudulot ng outage. Gayunpaman, buong pananagutan ng aming mga development team para sa mga salik na nagdudulot ng mga pagkabigo, at ang anumang kasunod na tugon ay karaniwang agaran. Kailangan din naming iwasan ang isang sitwasyon kung saan ang isang teknikal na gawain sa konsultasyon ay ipapadala pabalik sa koponan kung saan ito nanggaling, upang hindi mapilitan ang mga inhinyero na makipag-ugnayan pagkatapos ng mga oras.

Ang bilang ng mga tawag pagkatapos ng oras ay bumaba sa mas mababa sa 10 bawat buwan.

Ang aming proseso ng escalation ay bihirang ginamit nang pormal. Ang isang mas karaniwang paniniwala ay na ang engineer ay hindi opisyal na tinulungan ng team na kasalukuyang online, lalo na ang aming mga tao sa opisina ng San Francisco. Maraming mga isyu ang inalis o nabawasan sa pamamagitan ng pagtutulungan ng magkakasama at paglutas ng mga ito sa mabilisang.

Ang mga inhinyero sa aming tanggapan sa San Francisco ay sumali sa koponan nang buong-panahon at lumampas sa karaniwang teknikal na suporta. Kami ay nahaharap sa ilang mga overhead na gastos, ngunit ang pagpapakalat ng aming support team membership sa maraming opisina ay nagtrabaho sa aming kalamangan dahil ito ay napatunayang isang mahusay na paraan upang bumuo ng mga relasyon, palakasin ang mga ito, at matuto nang higit pa tungkol sa teknolohiya stack na pinagtatrabahuhan naming lahat.

Ang gawain ng mga developer ng Intercom ay naging mas pare-pareho sa aming mga koponan, at maaari naming kumpiyansa na pag-usapan ang tungkol sa mga benepisyo ng pagiging isang system engineer sa aming site I-bookmark Kami, na nagsasabi na hindi kailangang palaging konektado maliban kung gusto mong maging.

Kasabay ng pangunahing gawain upang patatagin at sukatin ang aming mga data store, ang patuloy na pagtuon sa paglutas ng problema ay nakitang bumaba ang bilang ng mga tawag sa labas ng oras sa mas mababa sa 10 bawat buwan. Ipinagmamalaki namin ang numerong ito.

Patuloy kaming nagsusumikap sa pagpapanatili at pagpapahusay sa aming technical support team, at habang lumalaki ang Intercom ay maaaring kailanganin naming muling isaalang-alang ang aming mga desisyon, dahil kung ano ang gumagana ngayon ay hindi naman gagana sa susunod na magdoble ang aming staff. Gayunpaman, ang karanasang ito ay lubhang positibo para sa aming organisasyon at lubos na nagpabuti sa kalidad ng buhay ng aming mga development engineer, ang kalidad ng aming mga tugon sa mga tawag, at higit sa lahat, ang karanasan ng aming mga customer.

Pinagmulan: www.habr.com

Magdagdag ng komento