De vertaling van het artikel is speciaal gemaakt voor de studenten van de cursus .
De missie van Intercom is om online ondernemen persoonlijk te maken. Maar het is onmogelijk om een product te personaliseren als het niet werkt. . Uptime is cruciaal voor het succes van ons bedrijf, niet alleen omdat onze klanten ons betalen, maar ook omdat we gebruiken . Als onze service niet werkt, voelen we letterlijk de pijn van onze klanten.
Een ononderbroken werking is afhankelijk van vele factoren, zoals de softwarearchitectuur en de kwaliteit van het dagelijkse werk. Het komt er echter vaak op neer dat de persoon die altijd contact heeft, oproepen beantwoordt . Deze technische ondersteuning kan een krachtige klantgerichte tool zijn die de hulp van ingenieurs combineert met wat klanten krijgen als ze uw product kopen. Het opent ook een geweldige kans om te leren en te groeien, want mislukkingen en fouten kunnen immers een goed veld zijn om vaardigheden te oefenen en complexe werkmechanismen te begrijpen.
Buiten werktijd "altijd in contact" blijven, is schadelijk voor uw leven.
Maar tegelijkertijd kan "altijd verbonden" zijn een nadelig effect hebben op uw leven. Je moet klaar staan om snel en vakkundig te reageren op de melding dat er iets kapot is. Ook als je op dat moment niet op een semafoon wordt gebeld, geeft de "altijd aan"-status een gevoel van onbehagen, dat weet ik zelf uit persoonlijke ervaring. Vooral hierdoor verslechtert de kwaliteit van de slaap. Regelmatig op elk moment van de dag in de toegangszone zijn, kan leiden tot burn-out, apathie of, in het algemeen, tot de wens om de computer nooit meer te zien.
Geschiedenis van de status "altijd verbonden" in de intercom
In de allereerste dagen van Intercom was onze CTO Ciaran in zijn eentje het hele XNUMX/XNUMX technische ondersteuningsteam, zowel binnen als buiten kantoor. Naarmate Intercom groeide, werd er een taskforce opgericht om Ciaran bij te staan. Kort daarna begonnen nieuwe ontwikkelingsteams veel nieuwe functies en services te creëren, en ze namen al alle verantwoordelijkheden voor technische ondersteuning over.
Op elk moment waren er te veel mensen “aan de lijn”.
Op dat moment leek deze aanpak een no-brainer, aangezien het een gemakkelijke manier was om ons technische ondersteuningsteam op elk gewenst moment te schalen, het in overeenstemming was met onze waarden en het bevredigde onze . Het resultaat was dat we zonder enige plannen vier of vijf teams hadden die regelmatig buiten werktijd contact opnamen met klanten. De rest van de ontwikkelingsteams hadden niet veel moeilijke punten die een fout konden veroorzaken, dus werden ze zelden of nooit gebeld.
We realiseerden ons dat we ons in een situatie bevonden waarin we technische ondersteuningsmonteurs hadden om trots op te zijn en een aantal kritieke problemen die we wilden aanpakken, zoals:
- Op een gegeven moment waren er te veel mensen klaar om de uitdaging aan te gaan. Onze infrastructuur was niet groot genoeg om minimaal vijf ontwikkelingsingenieurs nodig te hebben die zonder normale vrije dagen aan het werk waren.
- De kwaliteit van onze waarschuwingen en belprocedures was niet consistent tussen teams, we gebruikten ad-hocbeoordelingsprocessen voor nieuwe en bestaande probleemwaarschuwingen. De aanwijzingen in het runbook (te volgen wanneer een probleem wordt opgeworpen) schitterden meestal door afwezigheid.
- Afhankelijk van het team waarvoor de ingenieurs werkten, hadden ze tegenstrijdige verwachtingen. Alleen het allereerste technische ondersteuningsteam had bijvoorbeeld een vergoeding voor dienstverschuivingen en verstoorde vakanties.
- Het bleek dat er een algemeen tolerantieniveau bestaat voor onnodige oproepen op vreemde uren.
- Ten slotte is dit soort werk niet voor iedereen weggelegd. De levensomstandigheden lieten soms zien dat dienstdoende diensten mensen niet op de beste manier raken.
De juiste staat van "always connected" vinden
We hebben besloten om een nieuw virtueel team te creëren dat het technische ondersteuningswerk van elk team zal doen wanneer ze vrije uren hebben. Het team zal bestaan uit vrijwilligers, niet uit dienstplichtigen van een team in de organisatie. De ingenieurs van het virtuele team rouleerden ongeveer elke zes maanden en brachten weken "in contact" door. Gelukkig hadden we geen probleem om voldoende vrijwilligers te vinden om een virtueel team samen te stellen.
Als gevolg hiervan werd ons ondersteuningsteam teruggebracht van 30 mensen tot slechts 6 of 7.
Het team kwam vervolgens overeen en definieerde hoe probleemwaarschuwingen en runbookbeschrijvingen eruit moesten zien, en schetste het proces voor het doorsturen van waarschuwingen naar het nieuwe ondersteuningsteam. Ze identificeerden alle waarschuwingen in de code met behulp van de Terraform-module en begonnen voor elke wijziging peer review te gebruiken. We voerden een vergoeding in voor een wekelijkse dienst die de dienstdoende officieren vrij goed uitkwam. We creëerden ook een geëscaleerd team op het tweede niveau, dat alleen uit managers bestond. Deze opdracht moet het enige escalatiepunt zijn voor technische ondersteuningstechnici.
We hebben een aantal maanden hard gewerkt waarin we dit proces tot stand hebben gebracht, met als resultaat dat nu niet 30 ingenieurs contact hielden zoals voorheen, maar slechts 6 of 7. Tijdens werkuren lossen teams zelfstandig problemen op met hun functies of diensten, op deze tijd is meestal goed voor het grootste aantal storingen, maar de rest van de tijd wordt de technische ondersteuning verzorgd door vrijwilligers.
Wat hebben we geleerd
Nadat we ons virtuele technische ondersteuningsteam hadden gelanceerd, verwachtten we een stortvloed aan nieuwe taken, zoals het onderzoeken van de oorzaken van problemen of een algemene bijeenkomst om een enkel probleem op te lossen dat een crash veroorzaakte. Onze ontwikkelingsteams namen echter de volledige verantwoordelijkheid voor de factoren die de crashes veroorzaakten, en elke daaropvolgende reactie was meestal onmiddellijke actie. We moesten ook de situatie vermijden waarin de technische consultatietaak zou worden teruggegeven aan het team waarvan het afkomstig was, om de technici niet te dwingen om na uren contact op te nemen.
Het aantal oproepen buiten kantooruren is teruggebracht tot minder dan 10 per maand.
Formeel werd ons escalatieproces zelden gebruikt. De meer algemene perceptie was dat de ingenieur onofficieel werd bijgestaan door het team dat op dat moment online was, vooral onze jongens in het kantoor in San Francisco. Veel problemen zijn opgelost of verminderd door teamwerk en snelle oplossingen.
Ingenieurs in ons kantoor in San Francisco voegen zich bij het team als een volledig team en gaan verder dan gewone technische ondersteuning. Er waren wat overheadkosten aan verbonden, maar het uitbreiden van ons ondersteuningsteamlidmaatschap over meerdere locaties heeft in ons voordeel gewerkt, omdat het een goede manier is gebleken om relaties op te bouwen, te versterken en meer te leren over de technologiestapel waarmee we allemaal werken.
In onze teams is het werk van intercomontwikkelaars consistenter geworden en kunnen we vol vertrouwen praten over de voordelen van de functie van systeemingenieur op onze website , waarin staat dat het niet nodig is om altijd contact te hebben als je dat zelf niet wilt.
Naast het fundamentele werk van het stabiliseren en schalen van onze datawarehouses, heeft de constante focus op het oplossen van problemen ertoe geleid dat het aantal oproepen buiten kantooruren is teruggebracht tot minder dan 10 per maand. We zijn erg trots op dit aantal.
We blijven werken aan het onderhouden en verbeteren van ons technische ondersteuningsteam, en naarmate Intercom groeit, moeten we misschien onze beslissingen heroverwegen, want wat vandaag werkt, hoeft niet noodzakelijkerwijs te werken de volgende keer dat ons personeelsbestand verdubbelt. Deze ervaring is echter buitengewoon positief geweest voor onze organisatie en heeft de levenskwaliteit van onze ontwikkelingsingenieurs, de kwaliteit van onze reacties op uitdagingen en vooral de ervaring van onze klanten aanzienlijk verbeterd.
Bron: www.habr.com