Översättningen av artikeln förbereddes speciellt för kursens studenter .
Intercoms uppdrag är att göra onlineaffärer personliga. Men det är omöjligt att anpassa en produkt när den inte fungerar. . Drifttid är avgörande för vår verksamhets framgång, inte bara för att våra kunder betalar oss, utan också för att vi använder . Om vår tjänst inte fungerar känner vi bokstavligen smärtan av våra kunder.
Oavbruten drift beror på många faktorer, såsom mjukvaruarkitektur och kvaliteten på det dagliga arbetet. Men ganska ofta handlar det om att den som alltid har kontakt svarar på samtal från . Denna tekniska support kan vara ett kraftfullt kundfokuserat verktyg som kombinerar hjälp från ingenjörer med vad kunderna får när de köper din produkt. Det öppnar också upp en stor möjlighet för lärande och tillväxt, för trots allt kan misslyckanden och misstag vara ett bra fält för att öva färdigheter och förstå komplexa arbetsmekanismer.
Att hålla sig "alltid i kontakt" utanför arbetstid är skadligt för ditt liv.
Men samtidigt kan det ha en skadlig effekt på ditt liv att vara "alltid uppkopplad". Du måste vara redo att svara snabbt och kompetent på meddelandet om att något är trasigt. Även om du inte blir sökt vid just det ögonblicket, skapar "alltid på"-tillståndet en känsla av obehag, och jag vet detta av personlig erfarenhet. Särskilt på grund av detta försämras sömnkvaliteten. Att regelbundet vara i åtkomstzonen när som helst på dygnet kan leda till utbrändhet, apati, eller i allmänhet till en önskan att aldrig se datorn igen.
Historik om "alltid ansluten" tillstånd i Intercom
I de allra första dagarna av Intercom var vår CTO Ciaran på egen hand hela tekniska supportteamet dygnet runt, både på och utanför kontoret. När Intercom växte skapades en arbetsgrupp för att hjälpa Ciaran. Kort därefter började nya utvecklingsteam skapa många nya funktioner och tjänster, och de tog redan över allt tekniskt supportansvar.
När som helst var det för många människor "på linjen".
På den tiden verkade det här tillvägagångssättet vara en självklarhet, eftersom det var ett enkelt sätt att skala vårt tekniska supportteam när som helst, det var i linje med våra värderingar och det tillfredsställde våra . Som ett resultat, utan några planer, hamnade vi med fyra eller fem team som regelbundet kontaktade kunder under deras icke-arbetstid. Resten av utvecklingsteamen hade inte många svåra poäng som kunde skapa ett fel, så de blev sällan, om aldrig, synade.
Vi insåg att vi var i en situation där vi hade teknisk supportmekaniker att vara stolta över och ett antal kritiska frågor som vi ville ta itu med, som:
- Vid varje given tidpunkt var för många människor redo att anta utmaningen. Vår infrastruktur var inte tillräckligt stor för att kräva att minst fem utvecklingsingenjörer arbetade utan vanliga lediga dagar.
- Kvaliteten på våra varningar och anropsprocedurer var inte konsekvent mellan teamen, vi använde ad hoc granskningsprocesser för nya och befintliga problemvarningar. Anvisningarna i runbooken (som ska följas när ett problem tas upp) var mestadels iögonfallande genom sin frånvaro.
- Beroende på vilket team ingenjörerna arbetade för hade de motstridiga förväntningar. Till exempel var det bara det allra första tekniska supportteamet som hade någon kompensation för tjänstgöringsskift och störda semester.
- Det visade sig att det finns en generell toleransnivå för onödiga samtal på udda tider.
- Slutligen, den här typen av arbete är inte för alla. Livsförhållandena visade ibland att skift i tjänst inte påverkar människor på bästa sätt.
Hitta rätt tillstånd "alltid uppkopplad"
Vi har beslutat att skapa ett nytt virtuellt team som kommer att göra det tekniska supportarbetet för varje team när de har lediga timmar. Teamet kommer att bestå av frivilliga, inte värnpliktiga från något lag i organisationen. Ingenjörerna i det virtuella teamet roterade ungefär var sjätte månad och tillbringade veckor "i kontakt". Som tur var hade vi inga problem med att hitta tillräckligt många volontärer för att sätta ihop ett virtuellt team.
Som ett resultat minskade vårt supportteam från 30 personer till bara 6 eller 7.
Teamet kom sedan överens och definierade hur problemvarningar och runbook-beskrivningar skulle se ut, och beskrev processen för vidarebefordran av varningar till det nya supportteamet. De identifierade alla varningar i koden med Terraform-modulen och började använda peer review för varje förändring. Vi införde en ersättningsnivå för ett veckoskifte som passade vakthavarna ganska bra. Vi skapade också ett eskalerat team på andra nivån, som endast bestod av chefer. Detta kommando bör vara den enda eskaleringspunkten för tekniska supportingenjörer.
Vi hade flera månaders hårt arbete under vilket vi etablerade denna process, som ett resultat av att nu inte 30 ingenjörer höll kontakten som tidigare, utan bara 6 eller 7. Under arbetstid hanterar teamen självständigt problem med sina funktioner eller tjänster, på denna tid står vanligtvis för det högsta antalet haverier, men resten av tiden hanteras teknisk support av frivilliga.
Vad har vi lärt oss
Efter att vi lanserat vårt virtuella tekniska supportteam förväntade vi oss en flod av nya uppgifter, som att undersöka orsakerna till problem eller en allmän sammankomst för att lösa ett enskilt problem som orsakade en krasch. Våra utvecklingsteam tog dock fullt ansvar för faktorerna som orsakade kraschen, och varje efterföljande svar var vanligtvis omedelbar åtgärd. Vi behövde också undvika situationen där den tekniska konsultuppgiften skulle återföras till teamet som den kom från, för att inte tvinga ingenjörerna att höra av sig efter arbetstid.
Utomhussamtal har sänkts till mindre än 10 per månad.
Formellt användes vår eskaleringsprocess sällan. Den vanligare uppfattningen var att ingenjören inofficiellt fick hjälp av teamet som för närvarande var online, särskilt våra killar på San Francisco-kontoret. Många problem har åtgärdats eller reducerats genom lagarbete och snabb lösning.
Ingenjörer på vårt kontor i San Francisco går med i teamet som ett helt team och går längre än vanlig teknisk support. Det fanns vissa omkostnader inblandade, men att utöka vårt supportteammedlemskap över flera platser har fungerat till vår fördel eftersom det har visat sig vara ett bra sätt att bygga relationer, stärka dem och lära oss mer om teknikstacken vi alla arbetar med.
I våra team har arbetet med Intercom-utvecklare blivit mer konsekvent, och vi kan med tillförsikt prata om fördelarna med positionen som systemingenjör på vår webbplats , med angivande av att det inte finns något behov av att alltid ha kontakt om du inte vill ha det själv.
Tillsammans med det grundläggande arbetet med att stabilisera och skala våra datalager har det ständiga fokuset på problemlösning resulterat i att samtal utanför arbetstid har reducerats till mindre än 10 per månad. Vi är mycket stolta över detta antal.
Vi fortsätter att arbeta med att underhålla och förbättra vårt tekniska supportteam, och när Intercom växer kan vi behöva tänka om våra beslut, eftersom det som fungerar idag kanske inte nödvändigtvis fungerar nästa gång vår personalstyrka fördubblas. Denna erfarenhet har dock varit oerhört positiv för vår organisation, och avsevärt förbättrat livskvaliteten för våra utvecklingsingenjörer, kvaliteten på våra svar på utmaningar och framför allt, upplevelsen hos våra kunder.
Källa: will.com