🥇Po ofrojmë mbështetje më të lirë, duke u përpjekur të mos humbasim cilësinë

Modi emergjente (i njohur gjithashtu si IPKVM), që lejon lidhjen me VPS pa RDP direkt nga niveli i hipervizorit, kursen 15-20 minuta në javë.

E para dhe më e rëndësishmja - mos i irritoni njerëzit. Përgjigja teknike në mbarë botën ndahet në nivele, dhe punonjësit e nivelit të parë duhet të provojnë mënyrat tipike të zgjidhjes. Nëse detyra del jashtë këtyre kufijve - duhet ta kalojnë në nivelin e dytë. Por, mes administratorëve të VDS, mjaft shpesh hasen njerëz që dinë të mendojnë. Ndryshe nga shumë mbështetje të tjera. Së paku, ndjeshëm më shpesh. Dhe ata strukturizojnë mirë biletat, duke përshkruar menjëherë gjithçka që nevojitet. Nëse nivelit të parë i

Detyra është shumë e thjeshtë: të bëjmë mbështetje për hostimin tonë VDS adekuate me minimumin e kostove. Sepse ne jemi fast food i botës së ofruesve të hostimit: pa ndonjë "shtresim" të veçantë, çmime të ulëta, cilësi normale. Më parë Tashmë është folur se me shfaqjen e Instagram-linjave që përpiqen të automatizojnë menaxhimin e llogarive dhe pronarët e bizneseve të vogla me kontabilitet të largët dhe të tjerë që nuk janë shumë të avancuar në teknologji, komunikimi "si administrator me administrator" ka pushuar së funksionuari. Duhej të ndryshonim gjuhën e komunikimit.

Tani do flas pak më shumë për proceset - dhe gabimet e pashmangshme që vijnë me to.

Mos irritoni njerëzit Nr. 1

Çdo mbështetje është një prodhim në zinxhir. Kërkesa arrin, punonjësi i nivelit të parë përpiqet menjëherë të njohë situatën tipike, e cila ka ndodhur një mijë herë dhe do ndodhë një mijë herë tjetër. Ka një mundësi 90% që kërkesa të jetë tipike, dhe për t'i përgjigjur asaj, mund të klikosh thjesht disa butona, për ta futur modelin. Në model zakonisht duhet të shkruash disa fjalë - dhe e ke gati. Ose të hysh në ndërfaqen e menaxhimit dhe të klikosh disa butona atje. Në raste më të komplikuara (si transferimet nga zona në zonë, për shembull) duhet të ndjekësh hapa sipas algoritmit.

Ajo që i nervozon më shumë njerëzit pavarësisht nga cilësitë e tjera të mbështetjes, është reagimi tipik ndaj një kërkese jo tipike. Arrin një biletë, ku gjithçka është përshkruar në hollësi, ka shumë të dhëna të nevojshme për tre pyetje përpara, klienti parashikon dialogun... Dhe nga fjalët e para, punonjësi i mbështetjes në autopilot shkruan akordin për të futur modelin "provo të rijesh, duhet të ndihmojë".

Kjo pikërisht e hap këtë çështje për njerëzit, dhe pas situatave të tilla mbeten më shumë komente negative dhe komente zemërimi. Është e qartë se ne kemi gabuar, dhe nga aty e dimë statistikën. Ne me të vërtetë kemi gabuar në mënyra të ndryshme, por raste të tilla janë gjithmonë thjesht të çmendura. Përfshirë edhe për ne vete. Sigurisht, do të donim që kjo të mos ndodhte fare. Por kjo nuk është shumë e mundur në praktikë: çdo disa javë, një punonjës i lodhur nga monotonia mbase do të shtypë ndonjë buton të gëzuar.

Mos i nervozoni njerëzit № 2

E dyta, që po ashtu e hap mendjen, është kur askush nuk i përgjigjet biletës për një kohë të gjatë. Në Evropë, një sjellje e tillë mbështetjeje është normale: tri ditë deri në pranimin e ndodhisë për trajtim — është më shumë se norma. Edhe nëse është urgjente dhe diçka ndizet — asnjë rrjet social, as telefon, as mesazher, vetëm email dhe prisni radhën tuaj. Në Rusi, kjo është shumë më pak e zakonshme, por përsëri disa bileta

Linia e parë — operatorët, të cilëve iu janë dhënë skenarë dhe janë mësuar të reagojnë ndaj situatave tipike. Ata shpejt-shtyjnë problemet dhe përpiqen brenda 15 minutash ose të përgjigjen me një veprim tipik, ose të njoftojnë se bileta është në proces dhe ta kalojnë tek e dyta.

Linia e dytë — tashmë administratorët e hostingut, ata dinë të bëjnë pothuajse gjithçka manualisht. Po ashtu është të paktën menaxheri i mbështetjes, i cili di të bëjë gjithçka dhe pak më shumë. Linia e tretë — tashmë zhvilluesit, të cilëve u kalohen biletat si "korrigjoni këtë në ndërfaqe" ose "paraqitja e një parametri të tillë aty."

Të zvogëlohet numri i kërkesave

Për arsye të qarta, nëse dëshiron të ofrosh mbështetje të lirë, nuk duhet të rritësh numrin e parë të linjës për të lejuar që njerëzit me skripte të përballen më shpejt, por duhet të rritësh automatizimin. Kështu, në vend të njerëzve me skripte, duhet të kemi skripte të vërteta. Prandaj, një nga gjërat e para që bëmë ishte automatizimi i proceseve të ngritjes së makinave virtuale, shkallëzimin e burimeve (përfshirë diskun lart dhe poshtë, por jo frekuencën e procesorit) dhe gjëra të tjera të ngjashme. Sa më shumë mundësi t’i japësh përdoruesit nga ndërfaqja, aq më e lehtë bëhet jeta e linjës së parë dhe aq më e vogël mund të jetë ajo. Kur përdoruesi i drejtohet me diçka që ndodhet në kabinetin e tij personal, duhet t'i tregosh dhe t'i shpjegosh se si mund ta realizojë vetë.

Nëse nuk ke nevojë për mbështetje, atëherë ajo po funksionon mirë.

Karakteristika e dytë që kursen shumë kohë është plotësimi i gjatë i bazës së njohurive. Nëse përdoruesi ka një problem që nuk është në listën e veprimeve të mbështjetura (më së shpeshti këto janë pyetje si 'si të vendos një server të Minecraft-it' ose 'ku të konfiguroj VPS në Win Server'), atëherë shkruhet një artikull në bazën e njohurive. Një artikull po aq i detajuar shkruhet për çdo kërkesë të çuditshme. Për shembull, nëse përdoruesi kërkon mbështetje për të hequr firewall-in e integruar të Windows Server, atëherë ne dërgojmë të lexojë rreth asaj që do të ndodhë nëse realisht e çaktivizon dhe si të vendosë lejet vetëm për softuerin e zgjedhur. Sepse problemi shpesh është që diçka nuk mund të lidhet për shkak të konfigurimeve, e jo për shkak të firewall-it. Por të shpjegosh këtë çdo herë në një bisedë është shumë e vështirë. Dhe nuk dëshirojmë ta çaktivizojmë firewall-in, sepse shumë shpejt do të humbim ose makinën virtuale, ose klientin.

Nëse diçka në aplikacionin e njohurive bëhet shumë e aksesuar, mund të krijohet distribuimi në tregun e shërbimeve, në mënyrë që të kem një shërbim 'ngrit një server me tashmë të instaluar këtë'. Saktësisht kështu ndodhi me Docker-in dhe kështu ndodhi me serverin e Minecraft-it. Sërish, një buton 'ma bëni mirë' në ndërfaqe kursen deri në njëqind tiketa në vit.

Regjimi emergjent

Pas këtyre veprimeve, problemet më serioze që kërkojnë punë manuale mbeten me faktin se përdoruesi për ndonjë arsye ka humbur shërbimin e aksesit në distancë në sistemin operativ të hostit në hypervisor. Rasti më i zakonshëm është një konfigurim i gabuar i firewall-it, rasti i dytë më i shpeshtë — disa bug-e që nuk lejojnë dështimin e Windows të funksionojë normalisht dhe e detyrojnë të rifillojë në Modalitetin e Sigurt. Në modalitetin e sigurt, RDP është i pavlefshëm nga default.

Ne kemi krijuar një modalitet të bllokimit për këtë rast. Në përgjithësi, për të aksesuar makinën VDS, nevojitet ndonjë klient për punë në distancë. Shpeshherë bëhet fjalë për aksesin konsol, RDP, VNC ose diçka të ngjashme. Disavantazhi i këtyre metodave është se ato nuk funksionojnë pa sistemin operativ. Por ne në nivelin e hypervisor-it mund të marrim si pamjen në ekran, ashtu edhe të transmetojmë goditjet në tastierë! Për fat të keq, kjo ngarkon dukshëm procesorin (për shkak të transmetimit të videos), por lejon të arrihet rezultati i dëshiruar.

Prandaj i dhamë të gjithë përdoruesve akses në modalitetin e bllokimit, por ai është i kufizuar në kohën e përdorimit të pandërprerë. Për fat të mirë, siç tregon prakikës, ky kohë është mjaft e mjaftueshme për të rifilluar dhe për të bërë disa korrigjime.

Rezultati — edhe më pak bileta në mbështetje. Dhe aty ku admini mund të ndreqë biletën vetë, mbështetje nuk ka nevojë të ndërhyjë me duar dhe të merret me të.

Problemet e mbetura

Shumë shpesh përdoruesit mendojnë se mbështetja po i ofron diçka të pavërtetë. Fatkeqësisht, nuk mund të bëjmë asgjë për këtë (ose nuk kemi menduar për ndonjë zgjidhje). Dy shembujt më të zakonshëm janë kufijtë e burimeve dhe mbrojtja DDoS.

Në çdo makinë virtuale ka kufij për ngarkesën në disk, memorie dhe trafikun e pranueshëm. Mundësia për vendosjen e kufijve është e parashikuar në ofertë, realisht kufijtë përcaktohen në mënyrë që shumica e përdoruesve të punojnë pa shqetësime, edhe pa e ditur këtë. Por nëse filloni të ngacmoni shumë kanal dhe disk, algoritmet e paralajmërojnë automatikisht përdoruesin. Që nga prilli i vitit të kaluar, kemi hequr autoblokimet. Në vend të kësaj, vendosim kufij të butë për një periudhë të ndryshueshme.

Njëherë ishte kështu: paralajmërim, pastaj, nëse përdoruesi nuk e merr parasysh, ndodhte automatike bllokimi. Dhe në atë moment, njerëzit inatoseshin: "Çfarë po bënit, kjo sistem juaj po gabon, nuk kishte asgjë!" - dhe më pas mund të provonin ose të kuptojnë programin aplikativ, ose t'i propozojnë të rrisin planin e tarifës. Të kuptojnë funksionimin e softuerit aplikativ nuk është diçka që kemi mundësi, sepse është jashtë mbështetjes. Edhe pse rastet e para u shqyrtuan së bashku me përdoruesit. Sidomos mbetet në mendje ai rasti, ku një përdorues me rritje të shikimeve në YouTube kishte një trojan të integruar, dhe ky trojan kishte një rrjedhje memorie. Në fund, erdhëm në përfundimin se nuk ishin gjezenbug, por probleme të përdoruesve, përndryshe do na bombardonin me kërkesa të ngjashme. Por asnjë person nuk pranoi se mund ta ketë tejkaluar vetë tarifën.

Një histori e ngjashme është me DDoS: ne shkruajmë, se ju, përdorues i nderuar, jeni nën sulm. Ju lutemi, aktivizoni mbrojtjen. E përdoruesi: "Po ju po më sulmoni vetë!" Sigurisht, ne vetëm një përdorues e bllokojmë me DDoS-in, për t'u nxjerrë 300 rubla. Një biznes i favorshëm. Po, e di që shumë hoste të mëdhenj nga kategoria më të shtrenjta e përfshijnë këtë mbrojtje në tarifë, por ne nuk mund ta bëjmë kështu: ekonomia e fastfoodit dikton çmime të tjera minimale.

Jo më pak shpesh mbështetja është e pakënaqur me ata, të dhënat e të cilëve ne i kemi fshirë. Në kuptimin që legjitimisht i kemi fshirë pas përfundimit të afatit të paguar. Nëse dikush nuk rinovon qiranë e VDS, vijnë disa njoftime me shpjegim se çfarë do ndodhë më pas. Në momentin e përfundimit të pagesës, makina virtuale ndalon, por imazhi i saj ruhen. Vjen një tjetër njoftim dhe pastaj - edhe disa të tjera. Imazhi ruhet shtatë ditë shtesë dhe vetëm pastaj fshihet përgjithmonë. Kështu që, ka një kategori njerëzish që janë shumë të pakënaqur me këtë. Nga "administratori u largua, njoftimet shkonin në postën e tij, riktheni" dhe deri te akuzat për mashtrim dhe kërcënime për dhunë fizike. Arsyetimi është i njëjtë: çmimet për të gjithë përdoruesit e tjerë. Nëse do të ruanim për një muaj, atëherë do të na nevojiteshin më shumë depo. Kjo do të thoshte çmime më të larta për çdo klient të veçantë. Dhe ekonomia e fastfoodit... Po, e kuptuat. Dhe si rezultat, në forume marrim komente në frymën e "morrën para, fshinë të dhënat, mashtrues".

Dua të theksoj se kemi një gamë të tarifave premium. Atje, sigurisht, situata është ndryshe, pasi ne marrim parasysh dëshirat e klientit dhe i përshtatim fleksibël si limitin ashtu edhe heqjen në rast të mos-pagesës (e çojmë në minus, për të mos e bllokuar). Atje kjo është ekonomikisht e arsyeshme, sepse ndodhin vërtetë përplasje, dhe ruajtja e një klienti të madh dhe të përhershëm ka një kosto të lartë.

Ndonjëherë përdoruesit janë të keq-intencionuar. Disa herë kemi pasur prishje në sistemin tonë që bllokuan qindra makina virtuale për shkak të disa veprimeve të hapura të paligjshme nga klientët. Në thelb, pikërisht për shkak të këtyre situatave na nevojiteshin drejtuesit tanë të rrjetit për të monitoruar aktivitetin në rrjet dhe për të parë se përdoruesi nuk po bën ndonjë sulm nga serveri i tij. Monitorimi i tillë është i rëndësishëm për të siguruar që kufijtë e makinëve virtuale fqinjë të mos shkelet nga njerëz të dhunshëm.

Ka ata që thjesht e bëjnë spamin, minojnë ose ndryshe shkelin ofertën. Pastaj dërgojnë ankesë në suport dhe pyesin se çfarë ka shkuar keq dhe pse makina është bllokuar. Nëse procesi në biletën e mbështetjes quhet 'dërgues_spami.exe', ndoshta diçka po shkon keq. Një herë në dy javë, na vijnë ankesa nga kompanitë Sony ose Lucasfilm (tani — Disney), se dikush nga makina jonë virtuale në gamën tonë të IP-ve po shpërndan një film të piratuar. Për këtë, ndodhi bllokimi dhe kthimi i parave të mbetura në llogari sipas ofertës (të kujtojmë: kuantizimi ynë është për sekondë, pra mbetja gjithmonë do të jetë e saktë). Dhe për të kthyer paratë, sipas ligjit, nevojitet të tregoni një dokument identifikimi: kjo është një masë kundër pastrimit të parave. Piraët për ndonjë arsye, në vend që të tregojnë dokumentin, shkruajnë se ne u morëm paratë e tyre, duke harruar të saktësojnë disa rrethana.

Ah, po. Kërkesa më e mirë e vitit për ne është kjo: 'A mund të testoj për disa ditë makinën virtuale sipas tarifës prej 30 rubla në muaj përpara blerjes?'.

Përfundimi

Linja e parë rendit biletat dhe përgjigjet me veprime tipike. Shumë nga pakënaqësitë ndodhin pikërisht këtu. Ta rregullosh këtë nuk do të funksionojë, sepse baza e rregullimit është në automatizimin e hostimit, domethënë në një backlog të madh. Po, ne kemi më shumë sesa shumë në treg, por akoma nuk është mjaftueshëm. Prandaj, gjëja më e mirë që mund të bëjmë është të vendosim monitorim të linjës së parë. Monitorimi i shërbimit të mbështetjes – përmbushja e KPI-ve të linjës së parë. Në kohë reale shihen vonesat në SLA: kush dështon, shpesh – përse. Kërkesat falë këtyre alerteve kurrë nuk humbasin. Po, një biletë mund të përgjigjet me një shabllon jashtë temës, por këtë e mësojmë vetëm përmes feedback-ut.

Nëse klienti kërkon shumë, atëherë specialisti i linjës së dytë mund të hyjë në server dhe të bëjë atë që i nevojitet klientit (kushti është konfirmimi me email, në të cilin ai do të njoftojë të dhënat për hyrje në server).

Ne e bëjmë këtë shumë rrallë dhe këtë punë ia besojmë vetëm më të mirëve, sepse duam të kemi garanci që të dhënat e përdoruesve nuk do të dëmtohen. Më të mirët janë linja e dytë e mbështetjes.

Linja e parë ka një bazë njohurish, ku mund të dërgojë të shohë të komplikuar.

Një panel personal i pasur me funksione plus një bazë njohurish – dhe kështu arritëm të ulim numrin e kërkesave në 1–1,5 në vit për klient në mesatare.

Linja e dytë zakonisht trajton kërkesat komplekse, që kërkojnë punë manuale. E veçanta është: sa më e shtrenjtë të jetë plani i tarifës, aq më pak janë këto kërkesa në përllogaritje për makinat virtuale. Zakonisht, sepse ata që mund të ofrojnë një plan të shtrenjtë, ose kanë specialistë në staf, ose thjesht gjysma e problemeve nuk ekzistojnë sepse konfigurimet mjaftojnë për gjithçka. Edhe tani e mbaj mend atë heroi, i cili vendosi një Windows Server jo shumë të vjetër në një konfigurim me 256 MB memorie RAM.

Linja e dytë ka një set distribucionesh dhe një set skriptesh automatizimi. Të dyja mund të përditësohen sipas nevojës.

Linja e dytë dhe menaxherët personalë të tarifave VIP dinë të shtojnë shënime në profilin e klientit. Nëse ai është admin Linux - kështu edhe ta shkruajmë. Kjo do të jetë një sugjerim për linjën e parë: përdoruesi e di saktësisht se kjo nuk do të jetë një goditje në këmbë, por një shkatërrim i kontrolluar.

Linia e tretë menaxhon gjërat më të çuditshme. Për shembull, patëm një bug, ku nuk mund të arrihej një nga funksionet e panelit personal në Firefox. Përdoruesi thjesht na kërcënoi: "Nëse nuk e rregulloni brenda 12 orëve, do të shkruaj në të gjitha vlerësimet e hostit." Siç u dërgua, problemi ishte në një adblock të personalizuar. Në anën e përdoruesit, sa çuditshme që tingëllon. Shpesh vijnë gabime të komplikuara pa detaje, dhe nuk mund të riprodhohen. Ka detektivë me screenshot: "Pse e rregulloni atë për një muaj?" — "Po e kërkojmë bug-un tuaj gjithë këtë kohë thjesht", "Ah, po, sërish më ndodhi sot, por nuk mund ta riprodhoj përsëri..."

Në përgjithësi, kurrë nuk e dini se ku do të përfundojë një screenshot i bisedës me mbështetje, dhe nëse dikush i drejtohet mbështetjes, atëherë ka një problem. Mund të përmirësohet marrëdhënia. Të paktën, të provoni.

Po, e dimë që mbështetja jonë nuk është perfekte, por, siç do të doja të besoj, ajo kombinon shpejtësi të mjaftueshme me cilësi të mjaftueshme. Dhe nuk rrit çmimet e tarifave për ata që mund të kalojnë pa të.