Rezigna reĝimo (ankaŭ nomata IPKVM), kiu permesas vin konekti al VPS sen RDP rekte de la hipervizia tavolo, ŝparas 15-20 minutojn semajne.
La unua kaj plej grava afero estas ne kolerigi homojn. Ĉie en la mondo, subteno estas dividita en liniojn, kaj la dungito estas la unua, kiu provas tipajn solvojn. Se la tasko superas iliajn limojn, translokigu ĝin al la dua linio. Do, inter VDS-administrantoj sufiĉe ofte estas homoj, kiuj scias pensi. Male al multaj aliaj subtenoj. Nu, almenaŭ signife pli ofte. Kaj ili bone strukturas la bileton, tuj priskribante ĉion, kio necesas. Se la unua linio fariĝas "neklara" kaj ili hazarde petas vin ŝalti kaj malŝalti ĝin responde al ĉi tio, ĝi estas fiasko.
La tasko estas tre simpla: provizi taŭgan subtenon por nia VDS-gastigado je minimuma kosto. Ĉar ni estas la rapida manĝo de la mondo de gastigaj provizantoj: neniu speciala "lekado", malaltaj prezoj, normala kvalito. Jam estis rakonto pri tio, ke kun la apero de Instagram-baĉuloj provantaj aŭtomatigi kontadministradon kaj malgrandajn komercajn posedantojn kun fora kontado kaj aliaj homoj, kiuj ne estas tre progresintaj en teknologio, komunikado "kiel administranto al administranto" ĉesis funkcii. Mi devis ŝanĝi la lingvon de komunikado.
Nun mi rakontos al vi iom pli pri la procezoj - kaj pri la neeviteblaj problemoj kun ili.
Ne koleru homojn #1
Ajna subteno estas muntaĵĉena produktado. Alvenas aplikaĵo, la unualinia dungito tuj provas rekoni tipan situacion, kiu jam milfoje okazis kaj milfoje denove okazos. Estas 90% da ŝanco, ke la aplikaĵo estas tipa, kaj vi povas respondi ĝin laŭvorte premante kelkajn butonojn por ke la ŝablono estas anstataŭigita. Vi kutime nur bezonas skribi kelkajn vortojn en la ŝablonon kaj vi finis. Aŭ iru al la administrada interfaco kaj premu kelkajn butonojn tie. En pli kompleksaj kazoj (translokigoj de zono al zono, ekzemple), vi devas sekvi la algoritmon.
Kio plej iritas homojn, sendepende de aliaj kvalitoj de subteno, estas la tipa reago al maltipa peto. Alvenas bileto, kie ĉio estas detale priskribita, estas amaso da necesaj datumoj por tri demandoj antaŭen, la kliento antaŭvidas dialogon... Kaj laŭ la unuaj vortoj, la subtena oficisto sur aŭtomata piloto tajpas akordon por anstataŭigi la ŝablonon. "Provu rekomenci, ĝi devus helpi."
Ĉi tio vere malfermas la mensojn de homoj, kaj post tiaj situacioj restas la plej negativaj recenzoj kaj koleraj komentoj. Estas klare, ke ni tiom eraris, tie ni konas la statistikojn. Ĝenerale, ni faris erarojn en malsamaj manieroj, sed tiaj kazoj ĉiam estas nur sovaĝaj. Inkluzive por ni mem. Kompreneble, ni ŝatus, ke tio tute ne okazu. Sed ĉi tio ne estas tre ebla en la praktiko: unufoje ĉiun kelkajn semajnojn, dungito laca de la monotoneco premos la amuzajn butonojn.
Ne koleru homojn #2
La dua afero, kiu same malfermas la menson, estas kiam neniu respondas al bileto sufiĉe longe. En Eŭropo, ĉi tiu subtena konduto estas normala: tri tagoj antaŭ ol okazaĵo estas akceptita por laboro estas pli ol la normo. Eĉ se vi estas tre urĝa kaj io brulas - neniuj sociaj retoj, neniu telefono, neniu mesaĝisto, nur retpoŝtu kaj atendu vian vicon. En Rusio tio estas multe malpli ofta, sed iuj biletoj ankoraŭ estas "forgesitaj". Je la komenco de laboro, ni starigis SLA por la unua respondo de 15 minutoj. Kaj ĉi tio estas honesta 24/7. Estas klare, ke kiam VDS-gastigado fariĝas granda, tio aperas. Sed dubindaj servaj provizantoj ne havas ĉi tion. Kaj ni estis nur dubindaj ĉe la komenco kaj nur tiam fariĝis pli-malpli grandaj. Bone, pli-malpli averaĝe.
La unua linio estas funkciigistoj, kiuj ricevis skriptojn kaj instruis reagi al tipaj situacioj. Ili rapide ordigas problemojn kaj provas ene de 15 minutoj aŭ respondi per tipa ago, aŭ raporti, ke la bileto estas en progreso kaj transdoni ĝin al la dua.
La dua linio estas gastigaj administrantoj; ili scias kiel fari preskaŭ ĉion mane. Estas ankaŭ subtena administranto, kiu povas fari ĉion kaj iom pli. La tria linio estas la programistoj, ili ricevas biletojn kiel "ripari ĉi tion en la interfaco" aŭ "tian kaj tia parametron estas konsiderata malĝuste."
Redukti la nombron da aplikoj
Pro evidentaj kialoj, se vi volas provizi subtenon malmultekoste, tiam vi ne devus pliigi la unuan linion por ke homoj povu pritrakti skriptojn pli rapide, sed pliigi aŭtomatigon. Do ke anstataŭ homoj kun skriptoj ekzistas veraj skriptoj. Sekve, unu el la unuaj aferoj, kiujn ni faris, estis aŭtomatigi la procezojn de altigado de virtuala maŝino, skalado per rimedoj (inkluzive per disko supren kaj malsupren, sed ne per procesoro-frekvenco) kaj aliaj similaj aferoj. Ju pli la uzanto povas fari de la interfaco, des pli facile estas vivi kun la unua linio, kaj des pli malgranda ĝi povas esti. Kiam uzanto aliras ion, kio estas en sia persona konto, li devas fari ĝin kaj diri al li kiel li povas fari ĝin mem.
Se vi ne bezonas subtenon, tiam ŝi faras bonan laboron.
La dua trajto, kiu ŝparas multan tempon, estas la longa tempo necesa por plenigi la scion. Se la uzanto havas problemon, kiu ne estas inkluzivita en la listo de subtenataj agoj (plej ofte ĉi tiuj estas demandoj je la nivelo de "kiel instali Minecraft-servilon" aŭ "Kie agordi VPS en Win Server"), tiam artikolo estas skribita en la sciobazo. La sama detala artikolo estas skribita por ĉiuj strangaj petoj. Ekzemple, se uzanto petas subtenon forigi la enkonstruitan fajroŝirmilon de Windows Server, tiam ni sendas ilin legi pri kio okazos se ĝi efektive estas malŝaltita, kaj kiel ŝanĝi permesojn nur por elektita programaro. Ĉar la problemo kutime estas kun la fakto, ke io ne povas konektiĝi pro la agordoj, kaj ne kun la fajroŝirmilo mem. Sed estas tre malfacile klarigi ĉi tion ĉiufoje en dialogo. Sed iel mi ne volas malŝalti la fajroŝirmilon, ĉar sufiĉe baldaŭ ni perdos aŭ la virtualan maŝinon aŭ la klienton.
Se io pri aplikaĵo-programaro en la scio-bazo fariĝas tre populara, tiam vi povas aldoni la distribuon al la vendoplaco, por ke aperu la servo "instali servilon kun ĉi tio jam instalita". Efektive, jen kio okazis kun Docker, kaj jen kio okazis kun la Minecraft-servilo. Denove, unu butono "faru al mi bonon" en la interfaco ŝparas ĝis centojn da biletoj jare.
Krizreĝimo
Post ĉi tiuj paŝoj, la plej gravaj paneoj, kiuj postulas manan laboron, restas kun la fakto, ke la uzanto ial perdis la rimedojn de fora aliro al la gasto OS en la hiperviziero. La plej ofta kazo estas simple malĝusta fajroŝirmilo, la dua plej ofta estas iuj cimoj, kiuj malhelpas Win komenci normale kaj devigas vin rekomenci al Sekura Reĝimo. Kaj en sekura reĝimo, RDP ne disponeblas defaŭlte.
Ni kreis kriz-reĝimon por ĉi tiu kazo. Fakte, kutime por aliri VDS-maŝinon vi bezonas havi ian klienton por fora laboro. Plej ofte ni parolas pri konzola aliro, RDP, VNC aŭ io simila. La malavantaĝo de ĉi tiuj metodoj estas, ke ili ne funkcias sen OS. Sed ĉe la hipervizora nivelo ni povas ricevi la bildon sur la ekrano kaj transdoni klavarojn tie! Vere, ĉi tio sufiĉe multe ŝarĝas la procesoron (pro la reala video-elsendo), sed ĝi permesas vin akiri la deziratan rezulton.
Tial ni donis aliron al kriz-reĝimo al ĉiuj uzantoj, sed ĝi estas limigita laŭ la daŭro de daŭra uzo. Feliĉe, kiel praktiko montras, ĉi tiu tempo sufiĉas por rekomenci kaj ripari ion.
La rezulto estas eĉ malpli da subtenaj biletoj. Kaj kie la administranto povas ripari la bileton mem, subteno ne devas eniri kaj eltrovi ĝin.
Restantaj problemoj
Tre ofte, uzantoj pensas, ke subteno puŝas ion sur ilin. Bedaŭrinde, nenio povas esti farita pri tio (aŭ ni nenion elpensis). La du plej oftaj ekzemploj estas rimedlimoj kaj DDoS-protekto.
Ĉiu virtuala maŝino havas limojn pri diskoŝarĝo, memoro kaj permesita trafiko. La kapablo agordi limojn estas specifita en la oferto, sed la limoj mem estas elektitaj por ke la plej multaj uzantoj povu labori trankvile sen eĉ scii pri ili. Sed se vi subite tro tro trempas la kanalon kaj diskon, tiam la algoritmoj aŭtomate avertas la uzanton. Ekde aprilo pasintjare, ni forigis aŭtomatajn serurojn. Anstataŭe, fiksante molajn limojn por ŝanĝiĝema periodo.
Antaŭe, estis tiel: averto, tiam, se la uzanto ne atentis, aŭtomata blokado. Kaj en tiu momento homoj ofendiĝis: "Pri kio vi parolas, via sistemo estas fuŝa, nenio okazis!" - kaj tiam vi povas aŭ provi kompreni la aplikaĵon, aŭ proponi pliigi la tarifplanon. Ni ne havas la ŝancon kompreni la funkciadon de aplikaĵo programaro, ĉar ĉi tio estas ekster la amplekso de subteno. Kvankam la unuaj malmultaj kazoj estis aranĝitaj kune kun la uzantoj. Mi precipe memoras tiun, kie la trojano de jutuba vidpunkto havis enkonstruitan trojanon, kaj ĉi tiu trojano likis memoron. Fine ni alvenis al la konkludo, ke ĉi tiuj ne estis Heisenbugs, sed problemoj kun uzantoj, alie ni estus inunditaj de similaj petoj. Sed eĉ ne unu homo ankoraŭ konfesis, ke li mem povus superi la tarifojn.
Simila historio estas kun DDoS: ni skribas, ke vi, kara uzanto, estas atakata. Konekti la protekton, mi petas. Kaj la uzanto: "Jes, vi mem atakas min!" Kompreneble, ni DDoS nur unu uzanton por trompi ilin el 300 rubloj. Ĝi estas profita komerco. Jes, mi scias, ke multaj grandaj gastigaj retejoj en la pli multekosta kategorio inkluzivas ĉi tiun protekton en la tarifo, sed ni ne povas fari tion: la rapida manĝaĵa ekonomio diktas aliajn minimumajn prezojn.
Same ofte, tiuj, kies datumojn ni forigis, estas malkontenta pri subteno. En la senco, ke ĝi estis laŭleĝe forigita post la fino de la pagita periodo. Se iu ne renovigas sian VDS-luon, tiam pluraj sciigoj estas senditaj klarigante kio okazos poste. Kiam la pago estas finita, la virtuala maŝino haltas, sed ĝia bildo estas konservita. Alia sciigo alvenas, kaj poste kelkaj pli. La bildo estas konservita dum sep pliaj tagoj antaŭ esti forigita konstante. Do, estas kategorio da homoj, kiuj tre malĝojas pri tio. Komencante de "la administranto ĉesis, sciigoj estis senditaj al lia retpoŝto, reinstali" kaj finiĝante kun akuzoj pri fraŭdo kaj minacoj de fizika damaĝo. La kialo estas la samaj prezoj por ĉiuj aliaj uzantoj. Se ni stokas ĝin dum monato, ni bezonos pli da stokado. Ĉi tio signifos pli altajn prezojn por ĉiu individua kliento. Kaj la ekonomio de rapida manĝo... Nu, vi komprenas. Kaj kiel rezulto, en la forumoj ni ricevas recenzojn en la spirito de "ili prenis monon, forigis datumojn, skamistoj."
Mi ŝatus noti, ke ni havas linion de superaj tarifoj. Tie, kompreneble, la situacio estas malsama, ĉar ni konsideras la dezirojn de la kliento kaj flekseble starigas kaj la limon kaj forigon en kazo de nepago (ni metas ĝin en la minuson, nur por ne bloki ĝin). Tie ĝi jam estas ekonomie farebla, ĉar vere ĉio povas okazi, kaj reteni konstantan grandan klienton estas multekosta.
Kelkfoje uzantoj estas malicaj. Plurfoje nia sistemo spertis fiaskojn kun centoj da virtualaj maŝinoj blokitaj pro iuj klare nelegitimaj agoj de klientoj. Efektive, ĝuste pro tiaj situacioj ni bezonis niajn proprajn retajn ŝoforojn por kontroli retan agadon kaj vidi, ke la uzanto ne efektivigas atakon de sia servilo. Monitorado de tia plano estas grava por ke la limoj de najbaraj virtualaj maŝinoj ne estu malobservitaj de tumultuloj.
Estas tiuj, kiuj simple spamas, miajn, aŭ alie malobservas la oferton. Tiam li frapas por subteno kaj demandas kio misfunkciis kaj kial la aŭto estas blokita. Se la procezo en la bileto en la ekrankopio nomiĝas "spam sender.exe", tiam io verŝajne misfunkcias. Ĉirkaŭ unufoje ĉiun duan semajnon ni ricevas plendojn de Sony aŭ Lucasfilm (nun Disney), ke iu el nia virtuala maŝino el nia gamo da IP-adresoj distribuas bruligitan filmon. Por tio, vi tuj blokos kaj resendos la restantan monon en la konto laŭ la oferto (mi memorigu vin: nia kvantigo estas sekundo, tio estas, ĉiam estos saldo certe). Kaj por rericevi la monon, laŭ la leĝo, vi devas montri vian pasporton: ĉi tio estas kontraŭ-monlavado. Ial, anstataŭ montri pasporton, la piratoj skribas, ke ni elpremis monon el ili, forgesante klarigi kelkajn el la cirkonstancoj.
Ho jes. Nia plej bona peto de la jaro estas: "Ĉu mi povas testi virtualan maŝinon dum kelkaj tagoj kun rapideco de 30 rubloj monate antaŭ ol aĉeti?"
La rezulto
La unua linio ordigas biletojn kaj respondas per tipaj agoj. Ĉi tie estas la plej malkontento. Ankoraŭ ne eblos ripari ĉi tion, ĉar la bazo por ripari ĝin estas en gastiga aŭtomatigo, tio estas, en grandega restaro. Jes, ni havas pli ol multaj sur la merkato, sed ankoraŭ ne sufiĉas. Tial, la plej bona afero farebla estas establi unualinian monitoradon. Help Desk Monitoring - Unua linio KPI-efektivigo. Prokrastoj en SLA estas videblaj en reala tempo: kiu fiaskas, ofte - kial. Danke al tiaj atentigoj, aplikoj neniam estas perditaj. Jes, la bileto povas esti respondita per ŝablono, kiu ne temas, sed tion ni ekscias jam el la sugestoj.
Se la kliento vere demandas, tiam la dualinia specialisto povas iri al la servilo kaj fari tion, kion la kliento bezonas tie (la kondiĉo estas konfirmo per letero, en kiu li provizos la ensalutinformojn al la servilo).
Ni faras tion tre malofte kaj ni konfidas tian laboron nur al la plej bonaj, ĉar ni volas havi garantiojn, ke uzantdatenoj ne estos difektitaj. La plej bonaj estas la dua linio de subteno.
La unua linio havas scion, kie vi povas sendi por serĉi kompleksajn aferojn.
Persona konto riĉa je funkcioj plus sciobazo - kaj nun ni povis redukti la nombron da petoj al 1–1,5 jare po kliento averaĝe.
La dua linio kutime prilaboras kompleksajn aplikojn, kiuj postulas manan laboron. Kio estas tipa: ju pli multekosta la tarifplano, des malpli da tiaj petoj per virtuala maŝino. Kutime ĉar tiuj, kiuj povas pagi multekostan tarifon, aŭ havas specialistojn en dungitaro, aŭ simple duono de la problemoj ne aperas pro la fakto, ke ekzistas sufiĉe da agordo por ĉio. Mi ankoraŭ memoras la heroon, kiu instalis la ne plej malnovan Vindozan Servilon sur agordo kun 256 MB da RAM.
La dua linio havas aron de distribuokompletoj kaj aron de aŭtomatigaj skriptoj. Ambaŭ povas esti ĝisdatigitaj laŭbezone.
La dua linio kaj personaj administrantoj de VIP-tarifoj povas aldoni notojn al la profilo de la kliento. Se li estas Linukso-administranto, ni skribos tion. Ĉi tio estos la unua linio sugesto: la uzanto scias certe, ke tio ne estos pafo en la kruro, sed kontrolita detruo.
La tria linio regas la plej strangan. Ekzemple, ni havis cimon, kiu malebligis aliri unu el la funkcioj de via persona konto en Firefox. La uzanto rekte ĉantaĝis: "Se vi ne riparas ĝin ene de 12 horoj, mi skribos sur ĉiuj gastigaj recenzoj." Kiel evidentiĝis, la problemo estis en la kutima adbloko. Sur la uzanta flanko, sufiĉe strange. Ofte kompleksaj eraroj okazas sen detaloj, kaj ili ne plu povas esti ripetitaj. Estas detektivoj kun ekrankopio: "Kial vi riparas ĝin dum monato?" - "Jes, ni serĉis vian cimon dum ĉi tiu tempo," "Ho, nu, mi renkontis ĝin denove hodiaŭ, sed mi ne povis ripeti ĝin denove"...
Ĝenerale, vi neniam scias kie ekrankopio de dialogo kun subteno finiĝos, kaj se persono frapas por subteno, tiam li havas problemon. Vi povas plibonigi vian sintenon. Almenaŭ provu.
Jes, ni scias, ke nia subteno ne estas perfekta, sed mi ŝatus kredi, ke ĝi kombinas sufiĉan rapidecon kun sufiĉa kvalito. Kaj ĝi ne pliigas tarifojn por tiuj, kiuj povas malhavi ĝin.
fonto: www.habr.com