Hallo, Habr! Ek ondersteun Highload IT-stelsels al vir tien jaar. Ek sal nie in hierdie artikel skryf oor die probleme om nginx op te stel om in 1000+ RPS-modus of ander tegniese dinge te werk nie. Ek sal my waarnemings deel oor die probleme in die prosesse wat in die ondersteuning en werking van sulke stelsels ontstaan.
Monitering
Tegniese ondersteuning wag nie totdat 'n versoek kom met die inhoud "Wat Hoekom... werk die webwerf nie weer nie?" Binne 'n minuut nadat die webwerf ineengestort het, behoort ondersteuning reeds die probleem te sien en dit te begin oplos. Maar die terrein is die punt van die ysberg. Die beskikbaarheid daarvan is een van die eerstes wat gemonitor word.
Wat om te doen met die situasie wanneer die oorblywende goedere van 'n aanlynwinkel nie meer van die ERP-stelsel af kom nie? Of het die CRM-stelsel wat afslag vir kliënte bereken, opgehou om te reageer? Dit lyk of die webwerf werk. Voorwaardelike Zabbix ontvang sy 200 reaksie. Die diensverskuiwing het geen kennisgewings van die monitering ontvang nie en kyk met graagte na die eerste episode van die nuwe seisoen van Game of Thrones.
Monitering is dikwels beperk tot net die meting van die toestand van geheue, RAM en bedienerverwerkerlading. Maar vir besigheid is dit baie belangriker om produkbeskikbaarheid op die webwerf te kry. Die voorwaardelike mislukking van een virtuele masjien in die groep sal daartoe lei dat die verkeer daarheen sal ophou en die las op ander bedieners sal toeneem. Die maatskappy sal nie geld verloor nie.
Benewens die monitering van die tegniese parameters van bedryfstelsels op bedieners, moet u dus besigheidsstatistieke opstel. Metrieke wat geld direk raak. Verskeie interaksies met eksterne stelsels (CRM, ERP en ander). Die aantal bestellings vir 'n sekere tydperk. Suksesvolle of onsuksesvolle kliëntmagtigings en ander maatstawwe.
Interaksie met eksterne stelsels
Enige webwerf of mobiele toepassing met 'n jaarlikse omset van meer as 'n miljard roebels is in wisselwerking met eksterne stelsels. Begin by die bogenoemde CRM en ERP en eindig met die oordrag van verkoopsdata na 'n eksterne Big Data-stelsel vir die ontleding van aankope en die aanbied van die kliënt 'n produk wat hy beslis sal koop (in werklikheid nie). Elke so 'n stelsel het sy eie ondersteuning. En dikwels veroorsaak kommunikasie met hierdie stelsels pyn. Veral as die probleem wêreldwyd is en jy dit in verskillende stelsels moet ontleed.
Sommige stelsels verskaf 'n telefoonnommer of telegram vir hul administrateurs. Iewers moet jy briewe aan bestuurders skryf of na die foutspoorders van hierdie eksterne stelsels gaan. Selfs binne die konteks van een groot maatskappy werk verskillende stelsels dikwels in verskillende toepassingsrekeningkundige stelsels. Soms word dit onmoontlik om die status van 'n aansoek na te spoor. Jy ontvang 'n versoek in een voorwaardelike Jira. Dan plaas jy in die kommentaar van hierdie eerste Jira 'n skakel na die kwessie in 'n ander Jira. In die tweede Jira in die aansoek skryf iemand reeds 'n opmerking wat jy moet die voorwaardelike admin Andrey bel om die probleem op te los. En so aan.
Die beste oplossing vir hierdie probleem sou wees om 'n enkele ruimte vir kommunikasie te skep, byvoorbeeld in Slack. Nooi alle deelnemers in die proses om eksterne stelsels te bedryf om aan te sluit. En ook 'n enkele spoorsnyer om nie toepassings te dupliseer nie. Aansoeke moet op een plek opgespoor word, van monitering van kennisgewings tot die uitvoer van foutoplossings in die toekoms. Jy sal sê dat dit onrealisties is en dit het histories gebeur dat ons in een spoorsnyer werk, en hulle werk in 'n ander. Verskillende stelsels het verskyn, hulle het hul eie outonome IT-spanne gehad. Ek stem saam, en daarom moet die probleem van bo opgelos word op die CIO of produk eienaar vlak.
Elke stelsel waarmee u interaksie het, moet ondersteuning as 'n diens bied met 'n duidelike SLA om probleme volgens prioriteit op te los. En nie wanneer die voorwaardelike admin Andrey 'n minuut vir jou het nie.
Bottelnek Man
Het almal op 'n projek (of produk) 'n persoon wie se gaan met vakansie stuiptrekkings onder hul meerderes veroorsaak? Dit kan 'n devops-ingenieur, ontleder of ontwikkelaar wees. Slegs 'n devops-ingenieur weet immers watter bedieners watter houers geïnstalleer het, hoe om die houer te herlaai in geval van 'n probleem, en in die algemeen kan enige komplekse probleem nie sonder hom opgelos word nie. Die ontleder is die enigste een wat weet hoe jou komplekse meganisme werk. Watter datastrome gaan waarheen. Onder watter parameters van versoeke op watter dienste, watter sal ons antwoorde ontvang.
Wie sal vinnig verstaan hoekom daar foute in die logs is en 'n kritieke fout in die produk dadelik regstel? Natuurlik dieselfde ontwikkelaar. Daar is ander, maar om een of ander rede verstaan net hy hoe die verskillende modules van die stelsel werk.
Die wortel van hierdie probleem is die gebrek aan dokumentasie. Na alles, as al die dienste van u stelsel beskryf word, sou dit moontlik wees om die probleem sonder 'n ontleder te hanteer. As devops 'n paar dae uit sy besige skedule geneem het en al die bedieners, dienste en instruksies beskryf het om tipiese probleme op te los, dan kon die probleem in sy afwesigheid sonder hom opgelos word. Jy hoef nie vinnig jou bier op die strand te drink terwyl jy op vakansie is en na wi-fi soek om die probleem op te los nie.
Bevoegdheid en verantwoordelikheid van ondersteuningspersoneel
By groot projekte spaar maatskappye nie op ontwikkelaarsalarisse nie. Hulle soek duur middels of seniors van soortgelyke projekte. Met ondersteuning is die situasie 'n bietjie anders. Hulle probeer hierdie koste op elke moontlike manier verminder. Maatskappye huur goedkoop gister se Enikey-werkers en gaan met vrymoedigheid die stryd aan. Hierdie strategie is moontlik as ons praat oor 'n besigheidskaartjie-webwerf van 'n plant in Zelenograd.
As ons van 'n groot aanlynwinkel praat, kos elke uur van stilstand meer as die maandelikse salaris van 'n Enikey-administrateur. Kom ons neem 1 miljard roebels se jaarlikse omset as 'n beginpunt. Dit is die minimum omset van enige aanlynwinkel vanaf die gradering . Deel hierdie bedrag deur die aantal ure per jaar en kry meer as 100 000 roebels se netto verliese. En as jy nie die nag-ure tel nie, kan jy die hoeveelheid veilig verdubbel.
Maar geld is nie die belangrikste ding nie, reg? (nee, natuurlik die belangrikste ding) Daar is ook reputasieverliese. Die ondergang van 'n bekende aanlynwinkel kan beide 'n golf van resensies op sosiale netwerke en publikasies in tematiese media veroorsaak. En die gesprekke van vriende in die kombuis in die styl van "Moenie iets daar koop nie, hul webwerf is altyd af" kan glad nie gemeet word nie.
Nou na verantwoordelikheid. In my praktyk was daar 'n geval toe die administrateur aan diens nie betyds gereageer het op 'n kennisgewing van die moniteringstelsel oor die onbeskikbaarheid van die webwerf nie. Op 'n aangename somer Vrydagaand het die webwerf van 'n bekende aanlyn winkel in Moskou rustig gelê. Saterdagoggend het die produkbestuurder van hierdie webwerf nie verstaan hoekom die webwerf nie oopmaak nie, en daar was stilte in die ondersteuning en dringende kennisgewing-kletse in Slack. So 'n fout het ons 'n ses-syfer bedrag gekos, en hierdie diensbeampte sy werk.
Verantwoordelikheid is 'n moeilike vaardigheid om te ontwikkel. Of 'n persoon dit het of nie. Daarom probeer ek tydens onderhoude die teenwoordigheid daarvan identifiseer met verskeie vrae wat indirek wys of 'n persoon gewoond is om verantwoordelikheid te neem. As 'n persoon antwoord dat hy 'n universiteit gekies het omdat sy ouers dit gesê het of van werk verander omdat sy vrou gesê het dat hy nie genoeg verdien nie, dan is dit beter om nie by sulke mense betrokke te raak nie.
Interaksie met die ontwikkelingspan
Wanneer gebruikers eenvoudige probleme met 'n produk tydens werking ondervind, los ondersteuning dit op hul eie op. Probeer om die probleem te reproduseer, ontleed die logs, ensovoorts. Maar wat om te doen wanneer 'n fout in die produk verskyn? In hierdie geval ken ondersteuning die taak aan die ontwikkelaars toe en dit is waar die pret begin.
Ontwikkelaars word voortdurend oorlaai. Hulle skep nuwe funksies. Om foute met verkope reg te stel is nie die interessantste aktiwiteit nie. Spertye kom nader om die volgende naelloop te voltooi. En dan kom onaangename mense van ondersteuning en sê: "Staan dadelik alles, ons het probleme." Die prioriteit van sulke take is minimaal. Veral wanneer die probleem nie die mees kritieke is nie en die hooffunksie van die webwerf werk, en wanneer die vrystellingbestuurder nie met bultende oë rondhardloop en skryf: "Voeg hierdie taak dringend by die volgende vrystelling of hotfix."
Kwessies met normale of lae prioriteit word van vrystelling na vrystelling verskuif. Op die vraag "Wanneer sal die taak voltooi wees?" jy sal antwoorde ontvang in die styl van: "Jammer, daar is tans baie take, vra jou spanleiers of vrystellingbestuurder."
Produktiwiteitsprobleme geniet hoër prioriteit as om nuwe funksies te skep. Slegte resensies sal nie lank wees om te kom as gebruikers voortdurend op foute struikel nie. ’n Beskadigde reputasie is moeilik om te herstel.
Kwessies van interaksie tussen ontwikkeling en ondersteuning word deur DevOps opgelos. Hierdie afkorting word dikwels gebruik in die vorm van 'n spesifieke persoon wat help om toetsomgewings vir ontwikkeling te skep, CICD-pyplyne te bou en getoetste kode vinnig in produksie te bring. DevOps is 'n benadering tot sagteware-ontwikkeling wanneer alle deelnemers aan die proses noue interaksie met mekaar het en help om vinnig sagtewareprodukte en -dienste te skep en op te dateer. Ek bedoel ontleders, ontwikkelaars, toetsers en ondersteuning.
In hierdie benadering is ondersteuning en ontwikkeling nie verskillende departemente met hul eie doelwitte en doelwitte nie. Ontwikkeling is betrokke by werking en omgekeerd. Die bekende frase van verspreide spanne: "Die probleem is nie aan my kant nie" kom nie meer so gereeld in kletse voor nie, en eindgebruikers word 'n bietjie gelukkiger.
Bron: will.com