Oversættelsen af artiklen er udarbejdet specifikt til kursets studerende .
Intercoms mission er at personliggøre online-forretning. Men du kan ikke personliggøre et produkt, når det ikke virker. . Ydeevne er afgørende for vores virksomheds succes, ikke kun fordi vores kunder betaler os, men også fordi vi selv bruger . Hvis vores service ikke virker, mærker vi bogstaveligt talt vores kunders smerte.
Jævn drift afhænger af mange faktorer, såsom softwarearkitektur og kvaliteten af det daglige arbejde. Det kommer dog ganske ofte ud på, at den, der altid er i kontakt, besvarer opkald fra . Denne form for teknisk support kan være et kraftfuldt kundecentreret værktøj, der kombinerer hjælp fra ingeniører med, hvad kunderne får, når de køber dit produkt. Dette er også en god mulighed for læring og vækst, for trods alt kan fejl og fejl være en god mulighed for at øve færdigheder og forstå komplekse arbejdsmekanismer.
At være "altid tændt" uden for arbejdstiden har en skadelig effekt på dit liv.
Men samtidig kan det have en skadelig effekt på dit liv at være "altid på". Du skal være klar til hurtigt og kompetent at reagere på en advarsel om, at noget er gået i stykker. Selvom du ikke bliver søgt på et givent tidspunkt, kan det at være "altid på" skabe angst, som jeg ved af personlig erfaring. På grund af dette forringes søvnkvaliteten særligt kraftigt. Regelmæssig at være i adgangszonen på et hvilket som helst tidspunkt af dagen kan føre til udbrændthed, apati eller generelt et ønske om aldrig at se computeren igen.
Historien om tilstanden "altid forbundet" i Intercom
I de meget tidlige dage af Intercom leverede vores tekniske direktør, Ciaran, på egen hånd et helt team af XNUMX/XNUMX teknisk support, både på og uden for kontoret. Efterhånden som Intercom voksede, blev der oprettet en taskforce for at hjælpe Ciaran. Kort efter begyndte nye udviklingsteams at skabe mange nye funktioner og tjenester, og de overtog alt teknisk supportansvar.
Der var for mange mennesker "på vagt" på et givet tidspunkt.
På det tidspunkt virkede denne tilgang som en ligegyldig måde, fordi det var en nem måde at skalere vores tekniske supportteam på med et øjebliks varsel, den passede med vores værdier, og den passede til vores . I sidste ende, uden nogen planer, endte vi med fire eller fem teams, der regelmæssigt kontaktede kunder i deres ikke-arbejdstid. Resten af udviklingsteamene havde ikke mange komplekse problemer, der kunne give en fejl, så de blev sjældent, hvis nogensinde, kaldt.
Vi indså, at vi var i en situation, hvor vi havde teknisk supportmekanik, som vi ikke kunne være stolte af, og en række kritiske problemer, som vi ønskede at løse, såsom:
- Der var for mange mennesker klar til at tage udfordringen op på et givet tidspunkt. Vores infrastruktur var ikke stor nok til at kræve mindst fem udviklingsingeniører til at arbejde uden almindelige fridage.
- Kvaliteten af vores alarmer og opkaldsprocedurer var ikke konsistent på tværs af teams, og vi brugte ad hoc-processer til at gennemgå nye og eksisterende problemalarmer. Instruktionerne i runbooken (der skal følges, når der bliver underrettet om et problem) var for det meste iøjnefaldende ved deres fravær.
- Afhængigt af det team, som ingeniørerne arbejdede i, havde de modstridende forventninger. For eksempel var det kun det allerførste tekniske supportteam, der havde nogen kompensation for vagtvagter og forstyrrede weekender.
- Der så ud til at være et generelt niveau af tolerance over for unødvendige opkald på skæve tidspunkter.
- Endelig er denne type arbejde ikke for alle. Livsomstændigheder viste nogle gange, at vagtskift ikke havde den bedste effekt på mennesker.
At finde den rigtige "altid tændt"-tilstand
Vi besluttede at oprette et nyt virtuelt team, der skulle udføre teknisk supportarbejde for hvert team uden for arbejdstiden. Holdet vil bestå af frivillige, ikke værnepligtige fra noget hold i organisationen. Ingeniører på det virtuelle team roterede cirka hver sjette måned og tilbragte uger "på vagt". Heldigvis havde vi ingen problemer med at finde nok frivillige til at samle et virtuelt hold.
Som et resultat blev vores supportteam reduceret fra 30 personer til kun 6 eller 7.
Teamet blev derefter enige om og definerede, hvordan problemalarmer og beskrivelser skulle se ud i runbooken, og beskrev en proces for videresendelse af alarmer til det nye supportteam. De definerede alle advarsler i koden ved hjælp af et Terraform-modul og begyndte at bruge peer review for hver ændring. Vi indførte et kompensationsniveau for en ugentlig vagt, som var ganske tilfredsstillende for vagthavende. Vi oprettede også et eskaleret team på andet niveau, som kun bestod af ledere. Dette team bør være det eneste eskaleringspunkt for tekniske supportingeniører.
Vi havde flere måneders hårdt arbejde, hvor vi fik etableret denne proces, og som følge heraf var der nu ikke 30 ingeniører på vagt som før, men kun 6 eller 7. I arbejdstiden håndterer teamene selvstændigt problemer med deres funktioner eller tjenester, på Dette er det tidspunkt, hvor det største antal nedbrud normalt forekommer, men på alle andre tidspunkter ydes teknisk support af frivillige.
Hvad vi lærte
Efter at vi havde lanceret vores virtuelle tekniske supportteam, forventede vi en tilstrømning af nye opgaver, såsom at undersøge årsagerne til problemer eller samles for at løse et enkelt problem, der forårsagede en afbrydelse. Vores udviklingsteam tog dog det fulde ansvar for de faktorer, der forårsagede fejlene, og ethvert efterfølgende svar var typisk øjeblikkeligt. Vi skulle også undgå en situation, hvor en teknisk konsultationsopgave ville blive sendt tilbage til det team, den kom fra, for ikke at tvinge ingeniører til at kontakte efter arbejdstid.
Antallet af efter-timers opkald er faldet til under 10 om måneden.
Vores eskaleringsproces blev sjældent brugt formelt. En mere almindelig tro var, at ingeniøren uofficielt blev hjulpet af det hold, der i øjeblikket var online, især vores fyre på San Francisco-kontoret. Mange problemer blev elimineret eller reduceret gennem teamwork og løsning af dem på farten.
Ingeniører på vores kontor i San Francisco sluttede sig til holdet på fuld tid og gik ud over typisk teknisk support. Vi stod over for nogle overheadomkostninger, men at sprede vores supportteammedlemskab på tværs af flere kontorer virkede til vores fordel, da det viste sig at være en god måde at opbygge relationer på, styrke dem og lære mere om teknologistakken, vi alle arbejder med.
Intercom-udviklernes arbejde er blevet mere konsekvent i vores teams, og vi kan trygt tale om fordelene ved at være systemingeniør på vores side , der angiver, at der ikke er behov for altid at være forbundet, medmindre du ønsker det.
Sammen med grundlæggende arbejde med at stabilisere og skalere vores datalagre, har et fortsat fokus på problemløsning fået antallet af opkald uden for arbejdstiden til at falde til under 10 om måneden. Vi er meget stolte af dette nummer.
Vi fortsætter med at arbejde på at vedligeholde og forbedre vores tekniske supportteam, og efterhånden som Intercom vokser, bliver vi muligvis nødt til at genoverveje vores beslutninger, for det, der fungerer i dag, vil ikke nødvendigvis fungere, næste gang vores personale fordobles. Denne oplevelse har dog været yderst positiv for vores organisation og har i høj grad forbedret livskvaliteten for vores udviklingsingeniører, kvaliteten af vores svar på opkald og mest af alt vores kunders oplevelse.
Kilde: www.habr.com