Hej, Habr! Under tio Är har jag stöttat Highload IT-system. Jag kommer inte att skriva om problemen med att konfigurera nginx för att fungera i lÀget 1000+ RPS eller andra tekniska saker i den hÀr artikeln. Jag vill dela med mig av mina observationer kring problemen i processerna som uppstÄr i stöd och drift av sÄdana system.
Ăvervakning
Supporten vÀntar inte pÄ att en begÀran ska komma med innehÄllet "Varför... fungerar inte sidan igen?" Supporten mÄste omedelbart efter att sidan har kraschat se problemet och börja lösa det. Men sidan Àr bara toppen av isberget.Dess tillgÀnglighet övervakas som en av de första sakerna.
Hur ska man hantera situationen nÀr lagret av varor i nÀtbutiken slutat komma frÄn ERP-systemet? Eller nÀr CRM-systemet som berÀknar rabatter för kunderna slutar svara? Sidan fungerar ju utÄt sett. Det vill sÀga Zabbix fÄr sitt 200-svar. Den vakande skiftet fick inga meddelanden frÄn övervakningen och ser gladeligen pÄ det första avsnittet av den nya sÀsongen av "Game of Thrones".
Ăvervakning begrĂ€nsas ofta bara till att mĂ€ta minnesanvĂ€ndning, RAM och processorbelastning. servrar. Men för företag Ă€r det mycket viktigare att fĂ„ tillgĂ„ng till varorna pĂ„ sidan. Ett hypotetiskt fel pĂ„ en virtuell maskin i en kluster kommer att leda till att trafiken slutar gĂ„ dit och belastningen ökar pĂ„ andra servrar. Företaget kommer inte att förlora nĂ„gra pengar.
DÀrför, förutom att övervaka tekniska parametrar för operativsystemen pÄ servrarna, behöver man stÀlla in affÀrsmetrik. Metrik som direkt pÄverkar ekonomin. Olika interaktioner med externa system (CRM, ERP och andra). Antalet bestÀllningar under en viss tidsperiod. FramgÄngsrika eller misslyckade kundautoriseringar och andra metrik.
Interaktion med externa system
Varje webbplats eller mobilapplikation med en Ärlig intÀkt pÄ mer Àn en miljard rubel interagerar med externa system. FrÄn de nÀmnda CRM och ERP till överföring av försÀljningsdata till externa Big Data-system som analyserar köp och erbjuder kunden varor som hen sannolikt kommer att köpa (eller inte). Varje sÄdant system har sin egen support. Och ofta orsakar kommunikationen med dessa system problem. Speciellt nÀr problemet Àr globalt och krÀver analys i olika system.
Vissa system ger telefonnummer eller Telegram till sina administratörer. NĂ„gonstans mĂ„ste man skriva e-post till cheferna eller gĂ„ till bugtracking-systemen för dessa externa system. Ăven inom ett stort företag fungerar olika system ofta i olika system för hantering av Ă€renden. Att spĂ„ra statusen för ett Ă€rende blir ibland omöjligt. Du fĂ„r ett Ă€rende i en hypotetisk Jira. Sedan lĂ€gger du i kommentarerna till den första Jira en lĂ€nk till Ă€rendet i en annan Jira. I den andra Jira skriver nĂ„gon redan en kommentar om att man behöver ringa den hypotetiska administratören Andrei för att lösa frĂ„gan. Och sĂ„ vidare.
Den mest optimala lösningen pĂ„ detta problem skulle vara att skapa ett gemensamt utrymme för kommunikation, till exempel i Slack. Att bjuda in alla deltagare i processen av drift av externa system. Och ocksĂ„ ha en gemensam tracker för att undvika att duplicera Ă€renden. Ărenden bör spĂ„ras pĂ„ ett stĂ€lle, frĂ„n meddelandet i övervakningen tills att lösningen av buggar implementeras i produktion. Du kanske sĂ€ger att detta Ă€r orealistiskt och att ni historiskt har arbetat i en tracker, medan de arbetar i en annan. Det har dykt upp olika system, och de hade sina egna autonomiska IT-team. Jag hĂ„ller med och dĂ€rför behöver problemet lösas pĂ„ ledningsnivĂ„, pĂ„ CIO eller produktĂ€gares nivĂ„.
Varje system som du interagerar med bör erbjuda support som en tjÀnst med tydliga SLA:er för att lösa problem baserat pÄ prioritet. Och inte nÀr den hypotetiska administratören Andrei fÄr en minut över för dig.
En flaskhals
Finns det nÄgon i projektet (eller produkten) vars frÄnvaro i ledningen orsakar Ängest? Det kan vara en devops-ingenjör, analytiker eller utvecklare. För bara devops-ingenjören vet pÄ vilka servrar olika containrar Àr installerade, hur man startar om en container vid problem, och överhuvudtaget kan inga komplexa problem lösas utan honom. Analytikern Àr den enda som vet hur din komplexa mekanism fungerar. Vilka datastreamar som gÄr dit, vilka parametrar för förfrÄgningar till vilka tjÀnster och vilka svar vi fÄr.
Vem förstÄr snabbt varför det finns fel i loggarna och snabbt fixar en kritisk bugg i produktion? SjÀlvklart Àr det den utvecklaren. Det finns andra, men av nÄgon anledning Àr det bara han som förstÄr hur olika moduler i systemet Àr uppbyggda.
KÀrnan i detta problem Àr bristen pÄ dokumentation.Om alla tjÀnster i ditt system hade dokumenterats, skulle man kunna lösa problemet utan analytiker. Om devops avsatt ett par dagar frÄn sitt fullspÀckade schema för att dokumentera servrar, tjÀnster och instruktioner för att lösa typiska problem, skulle problemet kunna lösas utan honom. Det Àr inte nödvÀndigt att snabbt dricka sitt öl pÄ stranden under semestern och leta efter wi-fi för att lösa problemet.
Kompetens och ansvar bland supportmedarbetare
PÄ stora projekt sparar inte företagen pÄ löner till utvecklarna. De rekryterar dyra medel- eller seniorutvecklare frÄn liknande projekt. Situationen för support ser lite annorlunda ut. Dessa kostnader försöker man pÄ olika sÀtt att reducera. Företagen anstÀller billiga nybörjare och Àr beredda att gÄ till strid. Denna strategi kan vara möjlig om det handlar om en visitkortssajt för en fabrik i Zelenograd.
Om det handlar om en stor e-handelsbutik kostar varje timmes driftstopp mer Àn en mÄnads lön för en nybörjare. LÄt oss ta en utgÄngspunkt pÄ 1 miljard rubel i ÄrsomsÀttning. Detta Àr den minimiomsÀttning som vilken e-handelsbutik som helst i topplistan har. . Delar vi denna summa med antalet timmar per Är, fÄr vi mer Àn 100 000 rubel i rena förluster. Och om vi inte rÀknar med nattimmar kan vi utan tvekan dubbla summan.
Men pengar Àr ju inte allt, eller? (Nej, sjÀlvklart Àr det viktigt) Det finns ocksÄ ett vÀrde i reputationsförluster. En timmes driftstopp pÄ en kÀnd e-handelswebbplats kan orsaka en vÄg av klagomÄl pÄ sociala medier och publiceringar i specialiserade medier. Och samtalen mellan vÀnner i köket i stil med "Köp inget dÀr, deras webbplats fungerar alltid inte" kan överhuvudtaget inte mÀtas.
Nu till ansvaret. I min erfarenhet har det förekommit ett fall dÀr den jourhavande administratören inte reagerade i tid pÄ ett meddelande frÄn övervakningssystemet om att webbplatsen var otillgÀnglig. En trevlig sommarkvÀll i fredags lÄg en kÀnd e-handelswebbplats i Moskva tyst nere. PÄ lördagmorgonen förstod produktansvarig för denna webbplats inte varför den inte öppnades, och det var tyst i supportchattarna och i akuta meddelanden pÄ Slack. Ett sÄdant misstag kostade oss en sexsiffrig summa, och denna jourhavande administratör fick jobbet.
Ansvar Àr en fÀrdighet som Àr svÄr att utveckla. Antingen har en person det eller sÄ har de det inte. DÀrför försöker jag vid intervjuer att identifiera dess nÀrvaro genom olika frÄgor som indirekt visar om personen Àr van vid att ta ansvar. Om en person sÀger att de valde universitetet för att förÀldrarna sa sÄ, eller byter jobb för att frun sa att de tjÀnar för lite, Àr det bÀttre att inte blanda sig med sÄdana mÀnniskor.
Samarbete med utvecklingsteamet
NÀr anvÀndare stöter pÄ mindre problem under drift, sÄ löser supporten dem internt. De försöker reproducera problemet, analyserar loggar och sÄ vidare. Men vad gör man nÀr en bugg dyker upp i produktionen? I det fallet stÀller supporten en uppgift till utvecklarna och hÀr börjar det intressanta.
Utvecklarna Àr stÀndigt överbelastade. De sysslar med att skapa nya funktioner. Att fixa buggar i produktionen Àr i sÀger inte den mest intressanta sysslan. Deadlines för att avsluta nÀsta sprint hÄller pÄ att pressa dem. Och sÄ kommer obehagliga mÀnniskor frÄn supporten och sÀger: "Sluta med allt, vi har problem." Prioriteten för sÄdana uppgifter Àr minimal. SÀrskilt nÀr problemet inte Àr av kritisk natur och grundfunktionaliteten pÄ sajten fungerar, och nÀr release-managern inte springer omkring med uppspÀrrade ögon och skriver: "Inkludera denna uppgift i nÀsta release eller hotfix."
Uppgifter med vanlig eller lÄg prioritet övergÄr frÄn release till release. PÄ frÄgan "NÀr kommer uppgiften att vara utförd?" fÄr du svar i stil med: "FörlÄt, vi har mycket att göra just nu, frÄga teamledarna eller release-managern."
Problem i produktionen har högre prioritet Àn att skapa nya funktioner. DÄliga recensioner dröjer inte, om anvÀndarna konstant snubblar över buggar. Det Àr svÄrt att ÄterstÀlla ett förstört rykte.
FrÄgorna kring samarbetet mellan utveckling och support hanteras av DevOps. Denna förkortning anvÀnds ofta som en specifik person som hjÀlper till att skapa testmiljöer för utveckling, bygger CICD-pipelines och snabbt fÄr testad kod i produktion. DevOps Àr ett tillvÀgagÄngssÀtt för programvaruutveckling dÀr alla deltagare i processen samarbetar nÀra och hjÀlper till att snabbare skapa och uppdatera mjukvaruprodukter och tjÀnster. Jag syftar pÄ analytiker, utvecklare, testare och support.
Stöd och utveckling i en sÄdan strategi Àr inte olika avdelningar med sina egna mÄl och uppgifter. Utvecklingen Àr involverad i driften och vice versa. Den berömda frasen frÄn distribuerade team: "Problemet Àr inte pÄ min sida" dyker inte lÀngre upp sÄ ofta i chattarna, och slutkunderna blir lite lyckligare.
KĂ€lla: habr.com
