Hej, Habr! Jag har stöttat Highload IT-system i tio år. Jag kommer inte att skriva i den här artikeln om problemen med att ställa in nginx för att fungera i 1000+ RPS-läge eller andra tekniska saker. Jag kommer att dela med mig av mina iakttagelser om problemen i de processer som uppstår vid stöd och drift av sådana system.
övervakning
Teknisk support väntar inte tills en förfrågan kommer med innehållet "Vad Varför... fungerar inte sajten igen?" Inom en minut efter att webbplatsen kraschar bör supporten redan se problemet och börja lösa det. Men sajten är toppen av isberget. Tillgängligheten är en av de första som övervakas.
Vad ska man göra med situationen när de återstående varorna i en webbutik inte längre kommer från affärssystemet? Eller har CRM-systemet som beräknar rabatter för kunder slutat svara? Sajten verkar fungera. Villkorlig Zabbix får sitt 200-svar. Tullskiftet har inte fått några aviseringar från bevakningen och tittar glatt på det första avsnittet av den nya säsongen av Game of Thrones.
Övervakning är ofta begränsad till att endast mäta tillståndet för minne, RAM och serverprocessorbelastning. Men för företag är det mycket viktigare att få produkttillgänglighet på webbplatsen. Det villkorliga felet på en virtuell maskin i klustret kommer att leda till att trafiken slutar gå till den och belastningen på andra servrar kommer att öka. Företaget kommer inte att förlora pengar.
Därför, förutom att övervaka de tekniska parametrarna för operativsystem på servrar, måste du konfigurera affärsmått. Mätvärden som direkt påverkar pengar. Olika interaktioner med externa system (CRM, ERP och andra). Antalet beställningar för en viss tidsperiod. Lyckade eller misslyckade klientauktoriseringar och andra mätvärden.
Interaktion med externa system
Varje webbplats eller mobilapplikation med en årlig omsättning på mer än en miljard rubel interagerar med externa system. Utgående från ovan nämnda CRM och ERP och slutar med överföring av försäljningsdata till ett externt Big Data-system för att analysera inköp och erbjuda kunden en produkt som han definitivt kommer att köpa (i själva verket inte). Varje sådant system har sitt eget stöd. Och ofta orsakar kommunikation med dessa system smärta. Speciellt när problemet är globalt och man behöver analysera det i olika system.
Vissa system tillhandahåller ett telefonnummer eller telegram för sina administratörer. Någonstans måste du skriva brev till chefer eller gå till felspårarna för dessa externa system. Även inom ramen för ett stort företag fungerar olika system ofta i olika applikationsredovisningssystem. Ibland blir det omöjligt att spåra statusen för en applikation. Du får en förfrågan i en villkorad Jira. Sedan lägger du i kommentaren till denna första Jira en länk till frågan i en annan Jira. I den andra Jira i ansökan skriver någon redan en kommentar som du måste ringa den villkorliga administratören Andrey för att lösa problemet. Och så vidare.
Den bästa lösningen på detta problem skulle vara att skapa ett enda utrymme för kommunikation, till exempel i Slack. Inbjuder alla deltagare i processen att driva externa system att gå med. Och även en enda spårare för att inte duplicera applikationer. Applikationer bör spåras på ett ställe, från övervakningsmeddelanden till utdata av bugglösningar i framtiden. Du kommer att säga att detta är orealistiskt och det har historiskt hänt att vi arbetar i en tracker, och de fungerar i en annan. Olika system dök upp, de hade sina egna autonoma IT-team. Jag håller med, och därför måste problemet lösas uppifrån på CIO- eller produktägarnivå.
Varje system du interagerar med bör ge support som en tjänst med en tydlig SLA för att lösa problem efter prioritet. Och inte när den villkorliga administratören Andrey har en minut för dig.
Flaskhalsman
Har alla på ett projekt (eller en produkt) en person vars resa på semester orsakar konvulsioner bland deras överordnade? Detta kan vara en devops-ingenjör, analytiker eller utvecklare. När allt kommer omkring är det bara en devops-ingenjör som vet vilka servrar som har vilka behållare installerade, hur man startar om behållaren i händelse av ett problem, och i allmänhet kan alla komplexa problem inte lösas utan honom. Analytikern är den enda som vet hur din komplexa mekanism fungerar. Vilka dataströmmar går vart. Under vilka parametrar för förfrågningar till vilka tjänster, vilka kommer vi att få svar på.
Vem kommer snabbt att förstå varför det finns fel i loggarna och omedelbart fixa en kritisk bugg i produkten? Självklart samma utvecklare. Det finns andra, men av någon anledning är det bara han som förstår hur de olika modulerna i systemet fungerar.
Roten till detta problem är bristen på dokumentation. När allt kommer omkring, om alla tjänster i ditt system beskrevs, skulle det vara möjligt att hantera problemet utan en analytiker. Om devops tog ett par dagar utanför sitt fullspäckade schema och beskrev alla servrar, tjänster och instruktioner för att lösa typiska problem, så kunde problemet i hans frånvaro lösas utan honom. Du behöver inte snabbt avsluta din öl på stranden när du är på semester och leta efter wi-fi för att lösa problemet.
Stödpersonalens kompetens och ansvar
På stora projekt snålar inte företagen med utvecklarlöner. De letar efter dyra mellan- eller seniorer från liknande projekt. Med stöd är situationen lite annorlunda. De försöker minska dessa kostnader på alla möjliga sätt. Företag anställer billiga gårdagens Enikey-arbetare och går djärvt ut i strid. Denna strategi är möjlig om vi pratar om en visitkortswebbplats för en anläggning i Zelenograd.
Om vi pratar om en stor onlinebutik, kostar varje timmes driftstopp mer än månadslönen för en Enikey-administratör. Låt oss ta 1 miljard rubel av årlig omsättning som utgångspunkt. Detta är den lägsta omsättningen för alla onlinebutiker från betyget . Dela detta belopp med antalet timmar per år och få mer än 100 000 rubel i nettoförluster. Och om du inte räknar natttimmarna kan du säkert dubbla mängden.
Men pengar är inte huvudsaken, eller hur? (nej, självklart huvudsaken) Det finns också ryktesförluster. Nedgången av en välkänd webbutik kan orsaka både en våg av recensioner på sociala nätverk och publikationer i tematiska medier. Och samtalen från vänner i köket i stil med "Köp inget där, deras hemsida är alltid nere" kan inte mätas alls.
Nu till ansvar. I min praxis förekom ett fall då den jourhavande administratören inte svarade i tid på ett meddelande från övervakningssystemet om att sidan inte var tillgänglig. En trevlig sommarfredagkväll låg webbplatsen för en välkänd webbutik i Moskva tyst. På lördagsmorgonen förstod inte produktchefen för denna sajt varför sajten inte öppnade, och det var tyst i support- och brådskande meddelandechattar i Slack. Ett sådant misstag kostade oss en sexsiffrig summa, och den här tjänstemannen hans jobb.
Ansvar är en svår färdighet att utveckla. Antingen har en person det eller inte. Därför försöker jag under intervjuer identifiera dess närvaro med olika frågor som indirekt visar om en person är van vid att ta ansvar. Om en person svarar att han valde ett universitet för att hans föräldrar sa det eller byter jobb för att hans fru sa att han inte tjänar tillräckligt, då är det bättre att inte engagera sig i sådana människor.
Interaktion med utvecklingsteamet
När användare stöter på enkla problem med en produkt under drift löser support dem på egen hand. Försöker reproducera problemet, analyserar loggarna och så vidare. Men vad ska man göra när en bugg dyker upp i produkten? I det här fallet tilldelar supporten uppgiften till utvecklarna och det är här det roliga börjar.
Utvecklare är ständigt överbelastade. De skapar nya funktioner. Att fixa buggar med försäljning är inte den mest intressanta aktiviteten. Deadlines närmar sig för att klara nästa sprint. Och så kommer otrevliga personer från supporten och säger: "Sluta genast med allt, vi har problem." Prioriteten för sådana uppgifter är minimal. Speciellt när problemet inte är det mest kritiska och sajtens huvudfunktioner fungerar, och när releasehanteraren inte springer runt med utbuktande ögon och skriver: "Lägg till den här uppgiften brådskande i nästa version eller snabbkorrigering."
Frågor med normal eller låg prioritet flyttas från release till release. Till frågan "När ska uppgiften vara klar?" du kommer att få svar i stil med: "Tyvärr, det finns många uppgifter just nu, fråga dina teamledare eller release manager."
Produktivitetsproblem har högre prioritet än att skapa nya funktioner. Dåliga recensioner kommer inte att vänta på sig om användare ständigt snubblar på buggar. Ett skadat rykte är svårt att återställa.
Frågor om interaktion mellan utveckling och support löses av DevOps. Denna förkortning används ofta i form av en specifik person som hjälper till att skapa testmiljöer för utveckling, bygger CICD-pipelines och snabbt tar in testad kod i produktion. DevOps är ett förhållningssätt till mjukvaruutveckling när alla deltagare i processen nära interagerar med varandra och hjälper till att snabbt skapa och uppdatera mjukvaruprodukter och tjänster. Jag menar analytiker, utvecklare, testare och support.
I detta synsätt är stöd och utveckling inte olika avdelningar med sina egna mål och mål. Utveckling är inblandat i drift och vice versa. Den berömda frasen av distribuerade team: "Problemet är inte på min sida" dyker inte längre upp i chattar så ofta, och slutanvändarna blir lite gladare.
Källa: will.com