Artikuluaren itzulpena ikastaroko ikasleentzat bereziki prestatu zen .
Intercom-en eginkizuna lineako negozioak pertsonalizatzea da. Baina ezin duzu produktu bat pertsonalizatu funtzionatzen ez duenean. . Errendimendua funtsezkoa da gure negozioaren arrakastarako, ez bakarrik gure bezeroek ordaintzen digutelako, baita geuk ere erabiltzen dugulako. . Gure zerbitzuak funtzionatzen ez badu, literalki gure bezeroen mina sentitzen dugu.
Funtzionamendu leuna faktore askoren araberakoa da, hala nola software-arkitektura eta eguneroko lanaren kalitatea. Hala ere, sarritan dena beti harremanetan dagoenak deiei erantzuten die . Laguntza tekniko mota hau bezeroarengan oinarritutako tresna indartsua izan daiteke, ingeniarien laguntzarekin bezeroek zure produktua erostean lortzen dutenarekin konbinatzen duena. Ikasteko eta hazteko aukera paregabea ere bada hau, izan ere, azken finean, hutsegiteak eta akatsak aukera ona izan daitezke gaitasunak lantzeko eta lan mekanismo konplexuak ulertzeko.
Lan orduetatik kanpo "beti piztuta" egoteak eragin kaltegarria du zure bizitzan.
Baina, aldi berean, "beti piztuta" egoteak eragin kaltegarria izan dezake zure bizitzan. Zerbait hautsita dagoela dioen alertari azkar eta gaitasun handiz erantzuteko prest egon behar duzu. Nahiz eta momentu jakin batean orririk jaso ez, "beti piztuta" egoteak antsietatea sor dezake, esperientzia pertsonaletik dakidanez. Horregatik, loaren kalitatea nabarmen okertzen da. Eguneko edozein ordutan sarbide-eremuan erregular egoteak erredura, apatia edo, oro har, ordenagailua berriro ez ikusteko gogoa ekar dezake.
Intercom-en "beti konektatuta" egoeraren historia
Intercom-en hasierako egunetan, gure zuzendari teknikoak, Ciaranek, bakarka, XNUMX/XNUMX laguntza teknikoko talde oso bat eskaini zuen, bulegoan zein kanpoan. Intercom hazi ahala, lantalde bat sortu zen Ciaran laguntzeko. Handik gutxira, garapen-talde berriak funtzio eta zerbitzu berri asko sortzen hasi ziren, eta laguntza teknikoko ardura guztiak hartu zituzten.
Jende gehiegi zegoen "deialdian" une bakoitzean.
Garai hartan, planteamendu hau hutsala zirudien, gure laguntza teknologikoko taldea momentu batean eskalatzeko modu erraza zelako, gure balioekin bat egiten zuelako eta gure . Azkenean, inolako planik gabe, lauzpabost talderekin amaitu genuen lanorduz kanpoko orduetan bezeroekin harremanetan jartzen zirenak. Gainontzeko garapen-taldeek ez zuten arazo konplexu askorik izan errore bat bota zezaketenik, beraz, oso gutxitan deitzen zitzaien, inoiz ez bazen ere.
Konturatu ginen harro egon ezin gintezkeen laguntza teknikoko mekanika genuela eta konpondu nahi genituen hainbat arazo kritiko, hala nola:
- Jende gehiegi zegoen une bakoitzean erronkari aurre egiteko prest. Gure azpiegitura ez zen nahikoa garapenerako bost ingeniari gutxienez lan egin behar izateko ohiko egun librerik gabe.
- Gure alarmen eta deien prozeduren kalitatea ez zen koherentea talde guztietan, eta ad hoc prozesuak erabili genituen arazoen alerta berriak eta lehendik zeuden berrikusteko. Runbook-eko argibideak (arazoren bat jakinarazten zaienean jarraitu beharrekoak) nabarmenak ziren gehienetan ez zirelako.
- Ingeniariek lan egiten zuten taldearen arabera, itxaropen kontrajarriak zituzten. Esaterako, lehen laguntza teknikoko taldeak bakarrik izan zuen guardiako txandengatik eta etendako asteburuengatik.
- Ordu bakoitietan beharrezkoak ez diren deiekiko tolerantzia-maila orokorra zegoela ematen zuen.
- Azkenik, lan mota hau ez da guztiontzat. Bizitza-egoerek batzuetan erakutsi zuten betebehar-aldaketak ez zutela eraginik onena pertsonengan.
"Beti piztuta" egoera egokia aurkitzea
Talde birtual berri bat sortzea erabaki genuen, lanorduz kanpoko orduetan talde bakoitzarentzako laguntza teknikoko lanak egingo zituena. Taldea boluntarioek osatuko dute, ez erakundeko edozein taldetako beharginek. Talde birtualeko ingeniariek sei hilabetez behin txandakatzen zuten gutxi gorabehera, asteak emanez "deialdian". Zorionez, ez genuen arazorik izan talde birtual bat osatzeko behar adina boluntario aurkitzeko.
Ondorioz, gure laguntza taldea 30 lagunetik 6 edo 7ra murriztu zen.
Ondoren, taldeak adostu eta zehaztu zuen arazoen alertak eta deskribapenak runbook-ean nolakoak izan behar ziren, eta laguntza-talde berriari alertak bidaltzeko prozesu bat deskribatu zuen. Kodeko alerta guztiak Terraform modulu bat erabiliz definitu zituzten, eta aldaketa bakoitzerako parekideen berrikuspena erabiltzen hasi ziren. Asteko txanda baterako konpentsazio maila bat sartu genuen, betebeharko ofizialentzat nahiko asegarria zena. Zuzendariez soilik osatutako bigarren mailako talde eskalatu bat ere sortu genuen. Talde honek laguntza teknikoko ingeniarientzako eskalatze puntu bakarra izan behar du.
Hainbat hilabetetako lan gogorra egin genuen, prozesu hori finkatu genuen eta, ondorioz, orain ez zeuden 30 ingeniari lehen bezala, 6 edo 7 baino ez. zerbitzuak, on Hau da matxura gehien gertatu ohi den unea, baina beste guztietan, laguntza teknikoa boluntarioek ematen dute.
Zer ikasi genuen
Gure laguntza teknikoko talde birtuala martxan jarri ondoren, zeregin berrien ugaritzea espero genuen, hala nola, arazoen arrazoiak ikertzea edo etenaldi bat eragiten ari zen arazo bakar bat konpontzeko biltzea. Hala ere, gure garapen-taldeek hutsegiteen eragileen erantzukizun osoa hartu zuten eta geroko erantzuna berehalakoa izan ohi zen. Era berean, saihestu behar genuen egoera bat non kontsulta teknikoko zeregin bat datorren taldera itzuliko zen, ingeniariak orduetatik kanpo harremanetan jartzera ez behartzeko.
Orduz kanpoko deien kopurua hilean 10 baino gutxiagora jaitsi da.
Gure eskalatze prozesua oso gutxitan erabili zen formalki. Uste arruntagoa zen ingeniariari ez-ofizialki lagundu ziola gaur egun sarean zegoen taldeak, batez ere San Frantziskoko bulegoko gure mutilak. Arazo asko ezabatu edo murriztu ziren talde-lanaren bidez eta berehala konponduz.
Gure San Frantziskoko bulegoko ingeniariak taldean sartu ziren lanaldi osoan eta ohiko laguntza teknikotik harago joan ziren. Kostu orokorrak jasan genituen, baina gure laguntza-taldearen kideak bulego askotan zabaltzeak gure abantaila izan zuen, harremanak eraikitzeko, sendotzeko eta guztiok lan egiten dugun teknologia pilari buruz gehiago ikasteko modu ona izan zelako.
Intercom garatzaileen lana koherenteagoa bihurtu da gure taldeetan, eta konfiantzaz hitz egin dezakegu gure gunean sistemen ingeniari izatearen abantailez. , nahi ez baduzu beti konektatuta egon beharrik ez dagoela adieraziz.
Gure datu-biltegiak egonkortzeko eta eskalatzeko oinarrizko lanarekin batera, arazoen konponketan etengabe arreta jarriz gero, orduz kanpoko deien kopurua hilean 10 baino gutxiagora jaitsi da. Oso harro gaude zenbaki honekin.
Gure laguntza teknikoko taldea mantendu eta hobetzeko lanean jarraitzen dugu, eta Intercom hazten doan heinean baliteke gure erabakiak birplanteatu behar izatea, gaur egun funtzionatzen duena ez delako zertan funtzionatuko gure langileak bikoiztu diren hurrengoan. Hala ere, esperientzia hau oso positiboa izan da gure erakundearentzat eta asko hobetu du gure garapen ingeniarien bizi-kalitatea, deien erantzunen kalitatea eta, batez ere, gure bezeroen esperientzia.
Iturria: www.habr.com