Oversettelsen av artikkelen ble utarbeidet spesielt for studentene på kurset .
Intercoms oppgave er å tilpasse nettvirksomheten. Men du kan ikke tilpasse et produkt når det ikke fungerer. . Ytelse er avgjørende for suksessen til virksomheten vår, ikke bare fordi kundene våre betaler oss, men også fordi vi selv bruker . Hvis tjenesten vår ikke fungerer, føler vi bokstavelig talt kundenes smerte.
Glatt drift avhenger av mange faktorer, som programvarearkitektur og kvaliteten på det daglige arbeidet. Men ganske ofte handler det hele om at den som alltid er i kontakt svarer på anrop fra . Denne typen teknisk støtte kan være et kraftig kundesentrert verktøy som kombinerer hjelp fra ingeniører med det kundene får når de kjøper produktet ditt. Dette er også en fin mulighet for læring og vekst, for tross alt kan feil og feil være en god mulighet til å øve på ferdigheter og forstå komplekse arbeidsmekanismer.
Å være "alltid på" utenom arbeidstiden har en skadelig effekt på livet ditt.
Men samtidig kan det å være "alltid på" ha en skadelig effekt på livet ditt. Du må være klar til å raskt og kompetent svare på et varsel om at noe er ødelagt. Selv om du ikke blir søkt på et gitt tidspunkt, kan det å være "alltid på" skape angst, som jeg vet av personlig erfaring. På grunn av dette forringes søvnkvaliteten spesielt sterkt. Regelmessig å være i tilgangssonen når som helst på dagen kan føre til utbrenthet, apati eller generelt et ønske om å aldri se datamaskinen igjen.
Historien om tilstanden "alltid tilkoblet" i Intercom
I de aller første dagene av Intercom ga vår tekniske direktør, Ciaran, på egenhånd et helt team med XNUMX/XNUMX teknisk støtte, både på og utenfor kontoret. Etter hvert som intercom vokste, ble det opprettet en arbeidsgruppe for å hjelpe Ciaran. Like etter begynte nye utviklingsteam å lage mange nye funksjoner og tjenester, og de tok over alt teknisk støtteansvar.
Det var for mange mennesker på vakt til enhver tid.
På det tidspunktet virket denne tilnærmingen som en enkel måte, fordi det var en enkel måte å skalere vårt tekniske supportteam på et øyeblikks varsel, det stemte overens med våre verdier, og det passet våre . Til slutt, uten noen planer, endte vi opp med fire eller fem team som regelmessig kontaktet klienter i løpet av arbeidstiden. Resten av utviklingsteamene hadde ikke mange komplekse problemer som kunne forårsake en feil, så de ble sjelden, om noen gang, oppringt.
Vi innså at vi var i en situasjon der vi hadde teknisk støttemekanikk som vi ikke kunne være stolte av, og en rekke kritiske problemer som vi ønsket å fikse, for eksempel:
- Det var for mange mennesker klare til å ta utfordringen til enhver tid. Infrastrukturen vår var ikke stor nok til å kreve at minimum fem utviklingsingeniører skulle jobbe uten vanlige fridager.
- Kvaliteten på våre alarmer og anropsprosedyrer var ikke konsistent på tvers av teamene, og vi brukte ad hoc-prosesser for å gjennomgå nye og eksisterende problemvarsler. Instruksjonene i kjøreboken (som skal følges når det ble varslet om et problem) var for det meste iøynefallende ved fravær.
- Avhengig av hvilket team ingeniørene jobbet i, hadde de motstridende forventninger. For eksempel var det bare det aller første tekniske supportteamet som hadde noen kompensasjon for vaktvakter og forstyrrede helger.
- Det så ut til å være et generelt nivå av toleranse for unødvendige anrop til uvanlige timer.
- Til slutt, denne typen arbeid er ikke for alle. Livsomstendigheter viste noen ganger at vaktskifter ikke hadde den beste effekten på mennesker.
Finne den riktige "alltid på"-tilstanden
Vi bestemte oss for å opprette et nytt virtuelt team som skulle utføre teknisk støttearbeid for hvert team utenom arbeidstid. Teamet vil bestå av frivillige, ikke vernepliktige fra noen lag i organisasjonen. Ingeniører på det virtuelle teamet roterte omtrent hver sjette måned, og brukte uker "på vakt." Heldigvis hadde vi ingen problemer med å finne nok frivillige til å sette sammen et virtuelt team.
Som et resultat ble supportteamet vårt redusert fra 30 personer til bare 6 eller 7.
Teamet ble så enige om og definerte hvordan problemvarsler og beskrivelser skulle se ut i runbooken, og beskrev en prosess for videresending av varsler til det nye supportteamet. De definerte alle varsler i koden ved hjelp av en Terraform-modul, og begynte å bruke fagfellevurdering for hver endring. Vi innførte et kompensasjonsnivå for en ukevakt som var ganske tilfredsstillende for vakthavende. Vi opprettet også et eskalert team på andre nivå som bare besto av ledere. Dette teamet bør være det eneste eskaleringspunktet for tekniske støtteingeniører.
Vi hadde flere måneder med hardt arbeid, der vi etablerte denne prosessen, som et resultat var det nå ikke 30 ingeniører på vakt som før, men bare 6 eller 7. I arbeidstiden håndterer teamene uavhengig av problemer med sine funksjoner eller tjenester, på Dette er tidspunktet da det vanligvis oppstår flest sammenbrudd, men til enhver tid gis teknisk støtte av frivillige.
Hva vi lærte
Etter at vi lanserte vårt virtuelle tekniske støtteteam, forventet vi en tilstrømning av nye oppgaver, for eksempel å undersøke årsakene til problemer eller samles for å løse et enkelt problem som forårsaket strømbrudd. Utviklingsteamene våre tok imidlertid fullt ansvar for faktorene som forårsaket feilene, og enhver påfølgende respons var vanligvis umiddelbar. Vi trengte også å unngå en situasjon der en teknisk konsultasjonsoppgave ville bli sendt tilbake til teamet den kom fra, for ikke å tvinge ingeniører til å kontakte etter arbeidstid.
Antall samtaler etter arbeidstid har sunket til under 10 per måned.
Opptrappingsprosessen vår ble sjelden brukt formelt. En mer vanlig oppfatning var at ingeniøren uoffisielt ble hjulpet av teamet som for øyeblikket var online, spesielt gutta våre på San Francisco-kontoret. Mange problemer ble eliminert eller redusert gjennom teamarbeid og å løse dem umiddelbart.
Ingeniører på vårt San Francisco-kontor ble med i teamet på heltid og gikk utover vanlig teknisk støtte. Vi ble møtt med noen overheadkostnader, men å spre medlemskapet vårt i støtteteamet på flere kontorer fungerte til vår fordel, da det viste seg å være en god måte å bygge relasjoner på, styrke dem og lære mer om teknologistakken vi alle jobber med.
Arbeidet til Intercom-utviklere har blitt mer konsistent i teamene våre, og vi kan trygt snakke om fordelene ved å være systemingeniør på siden vår , som sier at det ikke er nødvendig å alltid være tilkoblet med mindre du ønsker det.
Sammen med grunnleggende arbeid for å stabilisere og skalere datalagrene våre, har et fortsatt fokus på problemløsning ført til at antall samtaler utenom arbeidstid har sunket til under 10 per måned. Vi er veldig stolte av dette tallet.
Vi fortsetter å jobbe med å vedlikeholde og forbedre vårt tekniske supportteam, og etter hvert som Intercom vokser, må vi kanskje revurdere beslutningene våre, fordi det som fungerer i dag vil ikke nødvendigvis fungere neste gang personalet vårt dobles. Denne erfaringen har imidlertid vært ekstremt positiv for organisasjonen vår og har i stor grad forbedret livskvaliteten til våre utviklingsingeniører, kvaliteten på våre svar på samtaler, og mest av alt, opplevelsen til kundene våre.
Kilde: www.habr.com