Vi gör supporten billigare och försöker inte tappa kvalitet

Vi gör supporten billigare och försöker inte tappa kvalitetReservläge (även kallat IPKVM), som låter dig ansluta till en VPS utan RDP direkt från hypervisorlagret, sparar 15-20 minuter per vecka.

Det första och viktigaste är att inte göra folk förbannade. Över hela världen är supporten uppdelad i linjer och medarbetaren är den första som provar typiska lösningar. Om uppgiften går utöver deras gränser, överför den till den andra raden. Så bland VDS-administratörer finns det ganska ofta människor som vet hur man tänker. Till skillnad från många andra stöd. Jo, åtminstone betydligt oftare. Och de strukturerar biljetten väl och beskriver omedelbart allt som behövs. Om den första raden blir "suddig" och de av misstag ber dig att slå på och av den som svar på detta, är det ett fiasko.

Uppgiften är mycket enkel: att tillhandahålla adekvat support för vår VDS-hosting till en lägsta kostnad. Eftersom vi är snabbmaten i världen av värdleverantörer: ingen speciell "slickning", låga priser, normal kvalitet. Tidigare Det fanns redan en historia om det faktum att med tillkomsten av Instagram-älsklingar som försöker automatisera kontohantering och småföretagare med fjärrredovisning och andra människor som inte är särskilt avancerade inom teknik, slutade kommunikationen "som administratör till en administratör" att fungera. Jag var tvungen att byta kommunikationsspråk.

Nu ska jag berätta lite mer om processerna - och om de oundvikliga problemen med dem.

Gör inte folk förbannade #1

All support är en löpande bandproduktion. En ansökan kommer in, den första linjens medarbetare försöker genast känna igen en typisk situation som redan har hänt tusen gånger och kommer att hända tusen gånger igen. Det finns en 90% chans att ansökan är en typisk sådan, och du kan svara på den genom att bokstavligen trycka på ett par knappar så att mallen ersätts. Du behöver vanligtvis bara skriva ett par ord i mallen och du är klar. Eller gå till hanteringsgränssnittet och tryck på ett par knappar där. I mer komplexa fall (till exempel överföringar från zon till zon) måste du följa algoritmen.

Det som irriterar människor mest, oavsett andra stödkvaliteter, är den typiska reaktionen på en atypisk begäran. En biljett anländer, där allt beskrivs i detalj, det finns mycket nödvändig data för tre frågor framåt, klienten förväntar sig en dialog... Och enligt de första orden skriver supportmedarbetaren på autopiloten ett ackord för att ersätta mallen "försök att starta om, det borde hjälpa."

Detta är vad som verkligen öppnar människors sinnen, och det är efter sådana situationer som de mest negativa recensionerna och arga kommentarerna kvarstår. Det är tydligt att vi hade så fel, det är där vi känner till statistiken. I allmänhet gjorde vi misstag på olika sätt, men sådana fall är alltid bara vilda. Inklusive för oss själva. Naturligtvis vill vi att detta inte ska hända alls. Men detta är inte särskilt möjligt i praktiken: en gång varannan vecka kommer en anställd som är trött på monotonin att trycka på de roliga knapparna.

Gör inte folk förbannade #2

Den andra saken som lika öppnar sinnet är när ingen svarar på en biljett tillräckligt länge. I Europa är detta stödbeteende normalt: tre dagar innan en incident accepteras för arbetet är mer än normen. Även om du är väldigt akut och något brinner – inga sociala nätverk, ingen telefon, ingen messenger, bara maila och vänta på din tur. I Ryssland är detta mycket mindre vanligt, men vissa biljetter är fortfarande "glömda". Allra i början av arbetet satte vi en SLA för det första svaret på 15 minuter. Och detta är ärligt 24/7. Det är uppenbart att när VDS-hosting blir stort så dyker det upp. Men tvivelaktiga tjänsteleverantörer har inte detta. Och vi var bara tveksamma i starten och först då blev vi mer eller mindre stora. Okej, mer eller mindre medelmåttig.

Den första raden är operatörer som fick manus och lärde sig att reagera på typiska situationer. De reder snabbt ut problem och försöker inom 15 minuter att antingen svara med en typisk åtgärd, eller rapportera att biljetten är på gång och överföra den till den andra.

Den andra raden är värdadministratörer, de vet hur man gör nästan allt för hand. Det finns även en supportansvarig som kan allt och lite till. Den tredje raden är utvecklarna, de får biljetter som "fixa detta i gränssnittet" eller "sådan och en sådan parameter beaktas felaktigt."

Minska antalet ansökningar

Av förklarliga skäl, om du vill ge support billigt, bör du inte öka den första raden så att folk kan hantera skript snabbare, utan öka automatiseringen. Så att istället för människor med manus finns det riktiga manus. Därför var en av de första sakerna vi gjorde att automatisera processerna för att höja en virtuell maskin, skala efter resurser (inklusive genom disk upp och ner, men inte efter processorfrekvens) och andra liknande saker. Ju mer användaren kan göra från gränssnittet, desto lättare är det att leva med den första raden, och desto mindre kan den vara. När en användare kommer åt något som finns på hans personliga konto måste han göra det och berätta för honom hur han kan göra det själv.

Om du inte behöver stöd, så gör hon ett bra jobb.

Den andra funktionen, som sparar mycket tid, är den långa tid det tar att fylla i kunskapsbasen. Om användaren har ett problem som inte finns med i listan över åtgärder som stöds (oftast är dessa frågor på nivån "hur man installerar en Minecraft-server" eller "Var man ställer in en VPS i Win Server"), då artikeln är skriven i kunskapsbasen. Samma detaljerade artikel är skriven för alla konstiga förfrågningar. Till exempel, om en användare ber support för att ta bort den inbyggda Windows Server-brandväggen, skickar vi dem för att läsa om vad som kommer att hända om den faktiskt är inaktiverad, och hur man ändrar behörigheter endast för utvald programvara. För problemet ligger oftast i att något inte kan ansluta på grund av inställningarna, och inte med själva brandväggen. Men det är väldigt svårt att förklara detta varje gång i dialog. Men på något sätt vill jag inte inaktivera brandväggen, för ganska snart kommer vi att förlora antingen den virtuella maskinen eller klienten.

Om något om applikationsprogramvara i kunskapsbasen blir väldigt populärt kan du lägga till distributionen på marknadsplatsen så att tjänsten "set upp en server med detta redan installerat" dyker upp. Det här är faktiskt vad som hände med Docker, och det här är vad som hände med Minecraft-servern. Återigen, en "gör mig bra"-knapp i gränssnittet sparar upp till hundratals biljetter per år.

Nödläge

Efter dessa steg kvarstår de allvarligaste felen som kräver manuellt arbete med det faktum att användaren av någon anledning förlorade möjligheten att fjärråtkomst till gäst-OS i hypervisorn. Det vanligaste fallet är en helt enkelt felaktig brandväggsinställning, det näst vanligaste är några buggar som hindrar Win från att starta normalt och tvingar dig att starta om till felsäkert läge. Och i säkert läge är RDP inte tillgängligt som standard.

Vi har skapat ett nödläge för det här fallet. Faktum är att vanligtvis för att komma åt en VDS-maskin behöver du ha någon form av klient för fjärrarbete. Oftast pratar vi om konsolåtkomst, RDP, VNC eller något liknande. Nackdelen med dessa metoder är att de inte fungerar utan ett OS. Men på hypervisornivå kan vi ta emot bilden på skärmen och sända tangentbordstryckningar dit! Det är sant att detta laddar processorn ganska mycket (på grund av den faktiska videosändningen), men det låter dig få önskat resultat.

Därför har vi gett tillgång till nödläge till alla användare, men det är begränsat vad gäller varaktigheten av kontinuerlig användning. Lyckligtvis, som praktiken visar, är den här tiden tillräckligt för att starta om och fixa något.

Resultatet är ännu färre supportbiljetter. Och där administratören kan fixa biljetten själv, behöver supporten inte gå in och ta reda på det.

Återstående problem

Mycket ofta tror användarna att support pressar dem något. Tyvärr kan ingenting göras åt detta (eller så har vi inte kommit på något). De två vanligaste exemplen är resursbegränsningar och DDoS-skydd.

Varje virtuell maskin har begränsningar för diskbelastning, minne och tillåten trafik. Möjligheten att sätta gränser anges i erbjudandet, men själva gränserna är valda så att de flesta användare kan arbeta tyst utan att ens veta om dem. Men om du plötsligt börjar pilla med kanalen och disken för mycket, då varnar algoritmerna automatiskt användaren. Sedan april förra året har vi tagit bort automatiska lås. Istället sätter du mjuka gränser för en variabel period.

Tidigare var det så här: en varning, sedan, om användaren inte lyssnade, en automatisk blockering. Och i det ögonblicket blev folk förolämpade: "Vad pratar du om, det är ditt system som är buggigt, ingenting hände!" - och då kan du antingen försöka förstå applikationsmjukvaran, eller erbjuda dig att höja tariffplanen. Vi har inte möjlighet att förstå hur applikationsmjukvara fungerar, eftersom detta ligger utanför stödets omfattning. Även om de första fallen löstes tillsammans med användarna. Jag minns särskilt den där YouTube-visningsfuskaren hade en inbyggd trojan, och den här trojanen läckte minne. Till slut kom vi fram till att dessa inte var Heisenbugs, utan problem med användare, annars skulle vi ha översvämmats med liknande förfrågningar. Men ännu har inte en enda person erkänt att han själv skulle kunna överskrida taxorna.

En liknande historia är med DDoS: vi skriver att du, kära användare, är under attack. Anslut skyddet, tack. Och användaren: "Ja, du attackerar mig själv!" Naturligtvis DDoS vi bara en användare för att lura dem på 300 rubel. Det är en lönsam affär. Ja, jag vet att många stora värdsajter i den dyrare kategorin inkluderar detta skydd i tariffen, men det kan vi inte göra: snabbmatsekonomin dikterar andra minimipriser.

Lika ofta är de vars data vi har raderat missnöjda med supporten. I den meningen att den lagligen raderades efter utgången av den betalda perioden. Om någon inte förnyar sin VDS-hyra skickas flera meddelanden som förklarar vad som kommer att hända härnäst. När betalningen är genomförd stannar den virtuella maskinen, men dess bild sparas. Ytterligare ett meddelande kommer, och sedan ett par till. Bilden lagras i ytterligare sju dagar innan den raderas permanent. Så det finns en kategori människor som är väldigt missnöjda med detta. Från att "administratören slutade, meddelanden skickades till hans e-post, återställs" och slutade med anklagelser om bedrägeri och hot om fysisk skada. Anledningen är samma priser för alla andra användare. Om vi ​​lagrar den i en månad behöver vi mer lagring. Detta kommer att innebära högre priser för varje enskild kund. Och ekonomin med snabbmat... Ja, ni fattar. Och som ett resultat, på forumen får vi recensioner i andan av "de tog pengar, raderade data, bedragare."

Jag skulle vilja notera att vi har en linje med premiumtariffer. Där är situationen naturligtvis annorlunda, eftersom vi tar hänsyn till kundens önskemål och flexibelt ställer in både gräns och radering vid utebliven betalning (vi sätter det i minus, bara för att inte blockera det). Där är det redan ekonomiskt genomförbart, för verkligen vad som helst kan hända, och att behålla en permanent stor kund är dyrt.

Ibland är användare illvilliga. Flera gånger upplevde vårt system fel med hundratals virtuella maskiner som blockerades på grund av några klart olagliga handlingar från klienter. Egentligen var det just på grund av sådana situationer som vi behövde våra egna nätverksdrivrutiner för att övervaka nätverksaktivitet och se att användaren inte utförde en attack från sin server. Övervakning av en sådan plan är viktig så att gränserna för angränsande virtuella maskiner inte kränks av bråkiga killar.

Det finns de som bara spammar, bryter eller på annat sätt bryter mot erbjudandet. Sedan knackar han på för stöd och frågar vad som gick fel och varför bilen är blockerad. Om processen i biljetten i skärmdumpen kallas "spam sender.exe", så är det förmodligen något som går fel. Ungefär en gång varannan vecka får vi klagomål från Sony eller Lucasfilm (numera Disney) om att någon från vår virtuella maskin från vårt utbud av IP-adresser distribuerar en bränd film. För detta kommer du omedelbart att blockera och returnera de återstående pengarna på kontot enligt erbjudandet (låt mig påminna dig: vår kvantisering är per sekund, det vill säga det kommer alltid att finnas ett saldo säkert). Och för att få tillbaka pengarna måste du enligt lagen visa upp ditt pass: det här är anti-penningtvätt. Av någon anledning, istället för att visa ett pass, skriver piraterna att vi pressade pengar ur dem och glömmer att klargöra några av omständigheterna.

Åh ja. Vår bästa begäran för året är: "Kan jag testa en virtuell maskin i några dagar med en hastighet av 30 rubel per månad innan jag köper?"

Totalt

Den första raden sorterar biljetter och svarar med typiska åtgärder. Det är här det mesta av missnöjet ligger. Det kommer fortfarande inte att vara möjligt att fixa detta, eftersom grunden för att fixa det är i hosting automation, det vill säga i en enorm eftersläpning. Ja, vi har fler än många på marknaden, men ändå inte tillräckligt. Därför är det bästa som kan göras att etablera första linjens övervakning. Help Desk Monitoring - First line KPI implementering. Förseningar i SLA är synliga i realtid: vem tjatar, ofta - varför. Tack vare sådana varningar går applikationer aldrig förlorade. Ja, biljetten kan besvaras med en mall som inte är på ämnet, men det får vi reda på redan från feedbacken.

Om klienten verkligen frågar kan den andra linjens specialist gå till servern och göra vad klienten behöver där (villkoret är en bekräftelse via brev där han kommer att tillhandahålla inloggningsinformationen till servern).

Vi gör detta mycket sällan och vi anförtror sådant arbete endast till de bästa, eftersom vi vill ha garantier för att användardata inte kommer att skadas. De bästa är den andra stödlinjen.

Den första raden har en kunskapsbas dit du kan skicka för att leta upp komplexa saker.

Ett personligt konto rikt på funktioner plus en kunskapsbas – och nu kunde vi minska antalet förfrågningar till 1–1,5 per år per kund i snitt.

Den andra raden behandlar vanligtvis komplexa applikationer som kräver manuellt arbete. Vad är typiskt: ju dyrare taxeplanen är, desto färre sådana förfrågningar per virtuell maskin. Vanligtvis för att de som har råd med en dyr taxa antingen har specialister på personal, eller helt enkelt hälften av problemen inte uppstår på grund av att det finns tillräckligt med konfiguration för allt. Jag minns fortfarande hjälten som installerade den inte äldsta Windows-servern på en konfiguration med 256 MB RAM.

Den andra raden har en uppsättning distributionskit och en uppsättning automatiseringsskript. Båda kan uppdateras vid behov.

Den andra linjen och personliga chefer för VIP-tariffer kan lägga till anteckningar till kundens profil. Om han är en Linux-administratör kommer vi att skriva ner det. Detta kommer att vara den första ledtråden: användaren vet säkert att detta inte kommer att vara ett skott i benet, utan kontrollerad förstörelse.

Den tredje raden regerar märkligast. Till exempel hade vi en bugg som gjorde det omöjligt att komma åt en av funktionerna på ditt personliga konto i Firefox. Användaren utpressade direkt: "Om du inte fixar det inom 12 timmar kommer jag att skriva om alla värdrecensioner." Som det visade sig låg problemet i det anpassade annonsblocket. På användarsidan, konstigt nog. Ofta uppstår komplexa fel utan detaljer, och de kan inte längre upprepas. Det finns detektiver med en skärmdump: "Varför fixar du det i en månad?" - "Ja, vi har letat efter din bugg hela tiden," "Oh, ja, jag stötte på det igen idag, men jag kunde inte upprepa det igen"...

Generellt sett vet man aldrig var en skärmdump av en dialog med support hamnar, och om en person knackar på för att få stöd så har han ett problem. Du kan förbättra din attityd. Försök åtminstone.

Ja, vi vet att vår support inte är perfekt, men jag skulle vilja tro att den kombinerar tillräcklig hastighet med tillräcklig kvalitet. Och det höjer inte tullpriserna för dem som klarar sig utan det.

Vi gör supporten billigare och försöker inte tappa kvalitet

Källa: will.com

Lägg en kommentar