Kaixo, Habr! Hamar urte daramatzat Highload IT sistemak onartzen. Ez dut artikulu honetan idatziko nginx 1000+ RPS moduan edo beste gauza tekniko batzuetan lan egiteko konfiguratzeko arazoei buruz. Sistema horien euskarri eta funtzionamenduan sortzen diren prozesuen arazoei buruzko nire oharrak partekatuko ditut.
jarraipenaren
Laguntza teknikoak ez du itxaron "Zer Zergatik... guneak ez du berriro funtzionatzen?" edukiarekin eskaera bat iritsi arte. Gunea huts egin eta minutu baten buruan, laguntzak arazoa ikusi eta konpontzen hasi beharko luke. Baina gunea icebergaren punta da. Bere erabilgarritasuna kontrolatzen den lehenetarikoa da.
Zer egin lineako denda bateko gainerako salgaiak ERP sistematik iristen ez diren egoerarekin? Edo bezeroentzako deskontuak kalkulatzen dituen CRM sistemak erantzuteari utzi dio? Guneak funtzionatzen duela dirudi. Baldintzazko Zabbix-ek bere 200 erantzuna jasotzen du. Duty Shift-ek ez du inolako jakinarazpenik jaso jarraipenetik eta pozik ikusten ari da Game of Thrones denboraldi berriko lehen atala.
Monitorizazioa memoriaren, RAMaren eta zerbitzariaren prozesadorearen kargaren egoera neurtzera mugatzen da askotan. Baina negozioentzat askoz garrantzitsuagoa da produktuen erabilgarritasuna webgunean lortzea. Klusterreko makina birtual baten baldintzapeko hutsegiteak trafikoa bertara joateari utziko dio eta beste zerbitzarietako karga areagotuko da. Enpresak ez du dirurik galduko.
Hori dela eta, zerbitzarietan sistema eragileen parametro teknikoak monitorizatzeaz gain, negozio-neurriak konfiguratu behar dituzu. Diruari zuzenean eragiten dioten neurketak. Hainbat interakzio kanpoko sistemekin (CRM, ERP eta beste). Denbora-tarte jakin baterako eskaera kopurua. Bezeroen baimenak eta beste neurketa arrakastatsuak edo arrakastatsuak.
Kanpoko sistemekin elkarrekintza
Urteko mila milioi errublo baino gehiagoko fakturazioa duen edozein webgune edo aplikazio mugikorrekin elkarreragin egiten du kanpoko sistemekin. Aipatutako CRM eta ERPtik hasi eta salmenta-datuak kanpoko Big Data sistema batera transferituz, erosketak aztertzeko eta bezeroari behin betiko erosiko duen produktua eskaintzeko (ez, hain zuzen ere). Horrelako sistema bakoitzak bere laguntza du. Eta askotan sistema hauekin komunikazioak mina eragiten du. Batez ere arazoa globala denean eta sistema ezberdinetan aztertu behar duzunean.
Sistema batzuek telefono-zenbaki bat edo telegrama bat eskaintzen diete administratzaileei. Nonbait kudeatzaileei gutunak idatzi behar diezu edo kanpoko sistema hauen akatsen jarraitzaileetara joan. Enpresa handi baten testuinguruan ere, sistema ezberdinek aplikazio kontabilitate sistema desberdinetan funtzionatzen dute sarritan. Batzuetan ezinezkoa bihurtzen da aplikazio baten egoeraren jarraipena egitea. Baldintzadun Jira batean eskaera bat jasotzen duzu. Gero lehen Jira honen iruzkinean beste Jira batean gaiari esteka jarri diozu. Aplikazioko bigarren Jira-n, norbait dagoeneko iruzkin bat idazten ari da Andrey baldintzapeko administratzaileari deitu behar diozu arazoa konpontzeko. Eta abar.
Arazo honen konponbiderik onena komunikaziorako espazio bakarra sortzea litzateke, Slack-en adibidez. Kanpoko sistemak ustiatzeko prozesuan parte-hartzaile guztiak sartzera gonbidatzea. Eta jarraitzaile bakarra ere bai, aplikazioak ez bikoizteko. Aplikazioak leku bakarrean jarraitu behar dira, jakinarazpenen monitorizaziotik hasi eta etorkizuneko akatsen konponbideen irteeraraino. Hau ez dela errealista esango duzu eta historikoki gertatu izan da jarraitzaile batean lan egiten dugula, eta beste batean lan egiten dutela. Sistema desberdinak agertu ziren, informatika talde autonomo propioak zituzten. Ados nago, eta, beraz, arazoa goitik konpondu behar da CIO edo produktuaren jabe mailan.
Elkarreragina duzun sistema guztiek laguntza eman behar dute zerbitzu gisa SLA argi batekin, arazoak lehentasunez konpontzeko. Eta ez Andrey baldintzapeko administratzaileak zuretzako minutu bat duenean.
Bottleck Man
Proiektu batean (edo produktuan) pertsona guztiek ba al dute oporretara joateak nagusien artean konbultsioak eragiten dituen pertsonarik? Hau devops ingeniaria, analista edo garatzailea izan daiteke. Azken finean, devops ingeniari batek bakarrik daki zer zerbitzariek zein edukiontzi duten instalatuta, edukiontzia nola berrabiarazi arazoren bat izanez gero eta, oro har, ezin da arazo konplexurik konpondu bera gabe. Analista da zure mekanismo konplexua nola funtzionatzen duen dakien bakarra. Zein datu-korronte nora doa. Eskaeren zer parametrotan zein zerbitzutan, zeintzuk jasoko ditugu erantzunak.
Nork ulertuko du azkar zergatik dauden akatsak erregistroetan eta berehala konponduko du produktuan akats kritiko bat? Garatzaile bera, noski. Beste batzuk ere badaude, baina arrazoiren batengatik berak bakarrik ulertzen du sistemaren modulu ezberdinek nola funtzionatzen duten.
Arazo honen oinarria dokumentazio falta da. Azken finean, zure sistemaren zerbitzu guztiak deskribatuko balira, posible izango litzateke arazoari aurre egitea analistarik gabe. Devops-ek bere ordutegi lanpetutik egun pare bat hartu eta arazo tipikoak konpontzeko zerbitzari, zerbitzu eta argibide guztiak deskribatuko balitu, orduan bere ezean arazoa bera gabe konpondu liteke. Ez duzu zertan hondartzan garagardoa azkar amaitu oporretan eta arazoa konpontzeko wi-fia bilatu behar.
Laguntza-langileen gaitasuna eta erantzukizuna
Proiektu handietan, enpresek ez dituzte sustatzaileen soldatak gutxitzen. Antzeko proiektuetako ertain edo senior garestien bila dabiltza. Laguntzarekin egoera apur bat ezberdina da. Kostu horiek ahalik eta modu guztietan murrizten saiatzen ari dira. Enpresek atzoko Enikeyko langile merkeak kontratatzen dituzte eta ausardiaz ekin diote borrokara. Estrategia hau posible da Zelenogradeko lantegi baten bisita-txartelen webguneaz ari bagara.
Lineako denda handi bati buruz ari bagara, orduan geldialdi-ordu bakoitzak Enikeyko administratzaile baten hileko soldata baino gehiago kostatzen da. Har dezagun urteko fakturazioaren 1 milioi errublo abiapuntu gisa. Hau da edozein lineako dendaren fakturazio minimoa baloraziotik . Zatitu kopuru hori urteko ordu kopuruaz eta lortu 100 errublo baino gehiago galera garbiak. Eta gaueko orduak zenbatzen ez badituzu, segurtasunez bikoiztu dezakezu zenbatekoa.
Baina dirua ez da gauza nagusia, ezta? (ez, noski gauza nagusia) Ospe galerak ere badaude. Lineako denda ezagun baten erorketak sare sozialetan zein gaikako komunikabideetako argitalpenen berrikuspen olatua eragin dezake. Eta sukaldeko lagunen elkarrizketak "Ez erosi han ezer, euren webgunea beti dago behera" estiloan ezin dira batere neurtu.
Orain erantzukizunari. Nire praktikan, guardiako administratzaileak gunearen erabilgarritasunari buruz jarraipen-sistemaren jakinarazpen bati garaiz erantzuten ez zion kasu bat egon zen. Udako ostiral arratsalde atsegin batean, Moskuko lineako denda ezagun baten webgunea lasai zegoen. Larunbat goizean, gune honetako produktu-kudeatzaileak ez zuen ulertzen zergatik ez zen gunea ireki, eta isiltasuna egon zen Slack-en laguntza eta premiazko jakinarazpen txatetan. Horrelako akats batek sei zifrako diru-kopurua kostatu zigun, eta betebeharreko ofizial honek bere lana.
Erantzukizuna garatzeko trebetasun zaila da. Pertsona batek dauka edo ez. Horregatik, elkarrizketetan zehar, pertsona bat ardurak hartzera ohituta dagoen ala ez adierazten duten hainbat galderekin identifikatzen saiatzen naiz haren presentzia. Pertsona batek erantzuten badu bere gurasoek esan zutelako unibertsitatea aukeratu zuela edo bere emazteak nahikoa irabazten ez duela esan zuelako lanez aldatzen duela, hobe da horrelakoekin ez sartzea.
Garapen taldearekin elkarreragina
Erabiltzaileek funtzionamenduan zehar produktu batekin arazo errazak aurkitzen dituztenean, laguntzak bere kabuz konpontzen ditu. Arazoa erreproduzitzen saiatzen da, erregistroak aztertzen ditu, etab. Baina zer egin produktuan akats bat agertzen denean? Kasu honetan, laguntzak garatzaileei esleitzen die zeregina eta hor hasten da dibertsioa.
Garatzaileak etengabe gainkargatuta daude. Ezaugarri berriak sortzen ari dira. Salmentekin akatsak konpontzea ez da jarduera interesgarriena. Hurrengo esprinta burutzeko epeak hurbiltzen ari dira. Eta orduan laguntzatik pertsona desatseginak etortzen dira eta esaten dute: "Utzi dena berehala, arazoak ditugu". Horrelako zereginen lehentasuna gutxienekoa da. Batez ere, arazoa ez denean kritikoena eta gunearen funtzionalitate nagusiak funtzionatzen duenean eta kaleratze-kudeatzaileak begi handiz ibiltzen ez duenean eta idazten ez duenean: "Gehitu zeregin hau hurrengo bertsiora edo konponketara".
Lehentasun normala edo txikia duten arazoak kaleratze batetik bestera mugitzen dira. "Noiz amaituko da zeregina?" galderari. honelako erantzunak jasoko dituzu: "Barkatu, zeregin asko daude une honetan, galdetu zure taldeko arduradunei edo kaleratze kudeatzaileari".
Produktibitate arazoek lehentasun handiagoa dute funtzio berriak sortzea baino. Iritzi txarrak ez dira denbora askorik izango erabiltzaileek akatsekin etengabe estropezu egiten badute. Kaltetutako ospea berreskuratzea zaila da.
Garapenaren eta laguntzaren arteko elkarrekintzaren arazoak DevOps-ek konpontzen ditu. Laburdura hau garatzeko proba-inguruneak sortzen laguntzen duen pertsona zehatz baten moduan erabiltzen da, CICD kanalizazioak eraikitzen eta probatutako kodea azkar ekartzen du ekoizpenera. DevOps softwarearen garapenaren ikuspegi bat da, prozesuko parte-hartzaile guztiek elkarren artean estuki elkarreragiten dutenean eta software produktuak eta zerbitzuak azkar sortzen eta eguneratzen laguntzen dutenean. Esan nahi dut analistak, garatzaileak, probatzaileak eta laguntza.
Planteamendu horretan, laguntza eta garapena ez dira sail desberdinak beren helburu eta helburuekin. Garapena funtzionamenduan parte hartzen du eta alderantziz. Banatutako taldeen esaldi famatua: βArazoa ez dago nire aldeβ jada ez da horren maiz agertzen txatetan, eta azken erabiltzaileak apur bat alaiago bihurtzen dira.
Iturria: www.habr.com