Saluton, Habr! Mi subtenas Highload IT-sistemojn dum dek jaroj. Mi ne skribos en ĉi tiu artikolo pri la problemoj de agordo de nginx por funkcii en 1000+ RPS-reĝimo aŭ aliaj teknikaj aferoj. Mi dividos miajn observojn pri la problemoj en la procezoj, kiuj ŝprucas en la subteno kaj funkciado de tiaj sistemoj.
Monitorado
Teknika subteno ne atendas ĝis alvenos peto kun la enhavo "Kio Kial... la retejo ne funkcias denove?" Ene de minuto post la kraŝo de la retejo, subteno jam devus vidi la problemon kaj komenci solvi ĝin. Sed la retejo estas la pinto de la glacimonto. Ĝia havebleco estas unu el la unuaj monitorataj.
Kion fari kun la situacio, kiam la ceteraj varoj de reta vendejo ne plu alvenas de la ERP-sistemo? Aŭ ĉu la CRM-sistemo, kiu kalkulas rabatojn por klientoj, ĉesis respondi? La retejo ŝajnas funkcii. Kondiĉa Zabbix ricevas sian 200 respondon. La devoŝanĝo ne ricevis sciigojn de la monitorado kaj ĝoje spektas la unuan epizodon de la nova sezono de Ludo de Tronoj.
Monitorado ofte estas limigita al nur mezurado de la stato de memoro, RAM kaj servila procesoroŝarĝo. Sed por komerco estas multe pli grave akiri produktan haveblecon en la retejo. La kondiĉa fiasko de unu virtuala maŝino en la areto kondukos al tio, ke trafiko ĉesos iri al ĝi kaj la ŝarĝo sur aliaj serviloj pliiĝos. La kompanio ne perdos monon.
Tial, krom monitori la teknikajn parametrojn de operaciumoj sur serviloj, vi devas agordi komercajn metrikojn. Metrikoj kiuj rekte influas monon. Diversaj interagoj kun eksteraj sistemoj (CRM, ERP kaj aliaj). La nombro da mendoj por certa tempodaŭro. Sukcesaj aŭ malsukcesaj klientorajtigoj kaj aliaj metrikoj.
Interago kun eksteraj sistemoj
Ajna retejo aŭ movebla aplikaĵo kun jara spezo de pli ol miliardo da rubloj interagas kun eksteraj sistemoj. Komencante de la supre menciitaj CRM kaj ERP kaj finiĝante per la translokigo de vendaj datumoj al ekstera Big Data-sistemo por analizi aĉetojn kaj oferti al la kliento produkton, kiun li certe aĉetos (fakte, ne). Ĉiu tia sistemo havas sian propran subtenon. Kaj ofte komunikado kun ĉi tiuj sistemoj kaŭzas doloron. Precipe kiam la problemo estas tutmonda kaj vi devas analizi ĝin en malsamaj sistemoj.
Iuj sistemoj disponigas telefonnumeron aŭ telegramon por siaj administrantoj. Ie vi devas skribi leterojn al administrantoj aŭ iri al la cimspuriloj de ĉi tiuj eksteraj sistemoj. Eĉ ene de la kunteksto de unu granda firmao, malsamaj sistemoj ofte funkcias en malsamaj aplikaj kontadaj sistemoj. Kelkfoje fariĝas neeble spuri la statuson de aplikaĵo. Vi ricevas peton en unu kondiĉa Jira. Tiam en la komento de ĉi tiu unua Jira vi metas ligilon al la afero en alia Jira. En la dua Jira en la aplikaĵo, iu jam skribas komenton tion vi devas voki la kondiĉan administranton Andrey por solvi la problemon. Kaj tiel plu.
La plej bona solvo al ĉi tiu problemo estus krei ununuran spacon por komunikado, ekzemple en Slack. Invitante ĉiujn partoprenantojn en la procezo de funkciado de eksteraj sistemoj aliĝi. Kaj ankaŭ ununura spurilo por ne duobligi aplikojn. Aplikoj devas esti spuritaj en unu loko, de monitorado de sciigoj ĝis la eligo de cimsolvoj estonte. Vi diros, ke ĉi tio estas nereala kaj historie okazis, ke ni laboras en unu spurilo, kaj ili funkcias en alia. Aperis malsamaj sistemoj, ili havis siajn proprajn sendependajn IT-teamojn. Mi konsentas, kaj tial la problemo devas esti solvita de supre sur la nivelo de CIO aŭ produktposedanto.
Ĉiu sistemo kun kiu vi interagas devus provizi subtenon kiel servo kun klara SLA por solvi problemojn laŭ prioritato. Kaj ne kiam la kondiĉa administranto Andrey havas minuton por vi.
Botelkolo Viro
Ĉu ĉiuj en projekto (aŭ produkto) havas homon, kies feriado kaŭzas konvulsiojn inter siaj superuloj? Ĉi tio povus esti devops-inĝeniero, analizisto aŭ programisto. Post ĉio, nur devops-inĝeniero scias, kiuj serviloj havas kiujn ujojn instalitajn, kiel rekomenci la ujon en kazo de problemo, kaj ĝenerale, ajna kompleksa problemo ne povas esti solvita sen li. La analizisto estas la sola, kiu scias kiel funkcias via kompleksa mekanismo. Kiuj datumfluoj iras kien. Sub kiaj parametroj de petoj al kiuj servoj, kiuj ni ricevos respondojn.
Kiu rapide komprenos kial estas eraroj en la protokoloj kaj tuj riparos kritikan cimon en la produkto? Kompreneble la sama programisto. Estas aliaj, sed ial nur li komprenas kiel funkcias la malsamaj moduloj de la sistemo.
La radiko de ĉi tiu problemo estas la manko de dokumentado. Post ĉio, se ĉiuj servoj de via sistemo estus priskribitaj, tiam eblus trakti la problemon sen analizisto. Se devops prenis kelkajn tagojn el sia okupata horaro kaj priskribis ĉiujn servilojn, servojn kaj instrukciojn por solvi tipaj problemoj, tiam la problemo en lia foresto povus esti solvita sen li. Vi ne bezonas rapide fini vian bieron sur la strando dum feriado kaj serĉi wi-fi por solvi la problemon.
Kompetenteco kaj respondeco de helppersonaro
En grandaj projektoj, kompanioj ne ŝparas je programistaj salajroj. Ili serĉas multekostajn mezajn aŭ maljunulojn de similaj projektoj. Kun subteno la situacio estas iom malsama. Ili provas redukti ĉi tiujn kostojn en ĉiu ebla maniero. Firmaoj dungas malmultekostajn hieraŭajn laboristojn de Enikey kaj kuraĝe iras en batalon. Ĉi tiu strategio eblas se ni parolas pri vizitkarta retejo de planto en Zelenograd.
Se ni parolas pri granda reta vendejo, tiam ĉiu horo da malfunkcio kostas pli ol la monata salajro de Enikey-administranto. Ni prenu 1 miliardo da rubloj da jara spezo kiel deirpunkto. Ĉi tio estas la minimuma spezo de iu ajn reta butiko de la takso . Dividu ĉi tiun kvanton per la nombro da horoj jare kaj ricevu pli ol 100 000 rublojn da netaj perdoj. Kaj se vi ne kalkulas la noktajn horojn, vi povas sekure duobligi la kvanton.
Sed mono ne estas la ĉefa afero, ĉu ne? (ne, kompreneble la ĉefa afero) Estas ankaŭ reputaciaj perdoj. La falo de konata interreta vendejo povas kaŭzi kaj ondon de recenzoj en sociaj retoj kaj publikaĵoj en temaj amaskomunikiloj. Kaj la konversacioj de amikoj en la kuirejo en la stilo de "Ne aĉetu ion tie, ilia retejo ĉiam malfunkcias" tute ne povas esti mezuritaj.
Nun al respondeco. En mia praktiko, estis kazo kiam la deĵoranta administranto ne respondis ĝustatempe al sciigo de la monitora sistemo pri la malhavebleco de la retejo. En agrabla somera vendredo vespere kuŝis kviete la retejo de konata reta vendejo en Moskvo. Sabate matene, la produktmanaĝero de ĉi tiu retejo ne komprenis kial la retejo ne malfermiĝis, kaj estis silento en la subteno kaj urĝaj sciigaj babilejoj en Slack. Tia eraro kostis al ni ses-ciferan sumon, kaj ĉi tiu deĵoranto lian laboron.
Respondeco estas malfacila kapablo disvolvi. Aŭ homo havas ĝin aŭ ne. Tial, dum intervjuoj, mi provas identigi ĝian ĉeeston kun diversaj demandoj, kiuj nerekte montras, ĉu homo kutimas preni respondecon. Se persono respondas, ke li elektis universitaton ĉar liaj gepatroj tion diris aŭ ŝanĝas laboron ĉar lia edzino diris, ke li ne sufiĉe enspezas, tiam estas pli bone ne okupiĝi pri tiaj homoj.
Interago kun la evoluiga teamo
Kiam uzantoj renkontas simplajn problemojn kun produkto dum operacio, subteno solvas ilin memstare. Provas reprodukti la problemon, analizas la protokolojn, ktp. Sed kion fari kiam cimo aperas en la produkto? En ĉi tiu kazo, subteno asignas la taskon al la programistoj kaj ĉi tie komenciĝas la amuzo.
Programistoj estas konstante troŝarĝitaj. Ili kreas novajn funkciojn. Ripari erarojn kun vendoj ne estas la plej interesa agado. Limdatoj alproksimiĝas por kompletigi la sekvan spurton. Kaj tiam malagrablaj homoj de subteno venas kaj diras: "Forlasu ĉion tuj, ni havas problemojn." La prioritato de tiaj taskoj estas minimuma. Precipe kiam la problemo ne estas la plej kritika kaj la ĉefa funkcieco de la retejo funkcias, kaj kiam la eldonadministranto ne kuras kun ŝvelantaj okuloj kaj skribas: "Urĝe aldonu ĉi tiun taskon al la sekva eldono aŭ korekto."
Problemoj kun normala aŭ malalta prioritato estas movitaj de eldono al eldono. Al la demando "Kiam la tasko estos plenumita?" vi ricevos respondojn en la stilo de: "Pardonu, estas multaj taskoj nun, demandu viajn teamajn gvidantojn aŭ liberigan administranton."
Produktivecaj problemoj havas pli altan prioritaton ol krei novajn funkciojn. Malbonaj recenzoj ne longe venos, se uzantoj konstante trovas cimojn. Difektita reputacio estas malfacile restarebla.
Temoj de interagado inter evoluo kaj subteno estas solvitaj de DevOps. Ĉi tiu mallongigo ofte estas uzata en la formo de specifa persono, kiu helpas krei testajn mediojn por evoluo, konstruas CICD-duktojn kaj rapide alportas testitan kodon en produktadon. DevOps estas aliro al programaro, kiam ĉiuj partoprenantoj en la procezo proksime interagas unu kun la alia kaj helpas rapide krei kaj ĝisdatigi softvaraĵojn kaj servojn. Mi volas diri analizistojn, programistojn, testistojn kaj subtenon.
En ĉi tiu aliro, subteno kaj evoluo ne estas malsamaj fakoj kun siaj propraj celoj kaj celoj. Evoluo estas implikita en operacio kaj inverse. La fama frazo de distribuitaj teamoj: "La problemo ne estas miaflanke" ne plu aperas tiom ofte en babilejoj, kaj finaj uzantoj fariĝas iom pli feliĉaj.
fonto: www.habr.com