Hallo, Habr! Al tien jaar ondersteun ik Highload IT-systemen. Ik zal in dit artikel niet schrijven over de problemen met het configureren van nginx om te werken in de modus van 1000+ RPS of andere technische zaken. Ik deel mijn observaties over de problemen in de processen die zich voordoen bij de ondersteuning en exploitatie van dergelijke systemen.
Monitoring
De technische ondersteuning wacht niet tot er een aanvraag komt met de inhoud "Waarom... is de site weer down?". Ondersteuning zou binnen een minuut na de uitval van de site het probleem al moeten zien en beginnen met het oplossen ervan. Maar de website is de top van de ijsberg. De beschikbaarheid ervan wordt als een van de eerste dingen gemonitord.
Wat te doen als de voorraden van de webshop zijn gestopt met binnenkomen vanuit het ERP-systeem? Of als het CRM-systeem dat kortingen voor klanten berekent, niet meer reageert? De website zelf lijkt echter te werken. De hypothetische Zabbix ontvangt zijn 200-respons. De wachtende ploeg kreeg geen meldingen van de monitoring en kijkt blij naar de eerste aflevering van het nieuwe seizoen van "Game of Thrones".
Vaak is de monitoring beperkt tot het meten van het geheugen, het werkgeheugen en de CPU-belasting. servers. Maar voor bedrijven is het veel belangrijker om de beschikbaarheid van producten op de website te krijgen. De hypothetische uitval van Ć©Ć©n virtuele machine in de cluster leidt ertoe dat het verkeer stopt naar deze machine en de belasting op andere servers toeneemt. Het bedrijf verliest hierdoor geen geld.
Daarom moeten naast de monitoring van technische parameters van besturingssystemen op servers ook bedrijfsmetrics worden ingesteld. Metrics die direct invloed hebben op geld. Verschillende interacties met externe systemen (CRM, ERP, enz.). Het aantal bestellingen in een bepaalde periode. Succesvolle of niet-succesvolle klantautorisaties en andere metrics.
Interacties met externe systemen
Elk website of mobiele applicatie met een jaarlijkse omzet van meer dan een miljard roebel heeft interactie met externe systemen. Van de eerder genoemde CRM- en ERP-systemen tot het doorgeven van verkoopgegevens aan een externe Big Data-analyse systeem, dat de klant het product aanbiedt dat hij beslist zal kopen (wat in werkelijkheid niet het geval is). Elk van deze systemen heeft zijn eigen ondersteuning. Vaak veroorzaakt de communicatie met deze systemen pijn. Vooral wanneer het probleem globaal is en het nodig is om het in verschillende systemen te analyseren.
Sommige systemen geven de telefoon of telegram van hun beheerders. Soms moet je een e-mail sturen naar managers of naar bugtrackers van deze externe systemen gaan. Zelfs binnen een groot bedrijf werken verschillende systemen vaak in verschillende ticket-systemen. Het kan soms onmogelijk zijn om de status van een aanvraag te volgen. Je ontvangt een aanvraag in een bepaalde Jira. Daarna plaats je in de opmerkingen van deze eerste Jira een link naar de taak in een andere Jira. In de tweede Jira schrijft iemand al een opmerking in de aanvraag dat je de administrator Andrei moet bellen om het probleem op te lossen. En ga zo maar door.
De optimale oplossing voor dit probleem zou de creatie van een uniforme ruimte voor communicatie zijn, bijvoorbeeld in Slack. Nodig alle deelnemers van het proces dat externe systemen exploiteert uit. En een enkele tracker om aanvragen niet te dupliceren. Aanvragen moeten op Ć©Ć©n plek worden gevolgd, vanaf de waarschuwing van monitoring tot het oplossen van bugs in productie. Je zult zeggen dat dit niet realistisch is en dat het historisch zo is ontstaan dat wij in Ć©Ć©n tracker werken, terwijl zij in een andere werken. Verschillende systemen zijn verschenen, zij hebben hun eigen autonome IT-teams gehad. Ik ben het ermee eens, en daarom moet het probleem van bovenaf worden opgelost op het niveau van de CIO of product owner.
Elk systeem waarmee je interactie hebt, moet ondersteuning bieden als een dienst met een duidelijke SLA voor het oplossen van problemen op prioriteiten. En niet pas wanneer er een minuutje beschikbaar is voor je bij de administrator Andrei.
De persoon is de bottleneck.
Heeft elke project (of product) zo iemand wiens verlof paniek bij het management oproept? Dit kan een devops-engineer, analist of ontwikkelaar zijn. Want alleen de devops-engineer weet op welke servers welke containers zijn geĆÆnstalleerd, hoe je een container opnieuw opstart bij een probleem en in het algemeen kan geen enkele complexe kwestie zonder hem worden opgelost. De analist is de enige die weet hoe jouw complexe mechanisme werkt. Welke datastromen waarheen gaan. Bij welke parameters verzoeken naar welke diensten worden gestuurd, en welke antwoorden we zullen ontvangen.
Wie begrijpt snel waarom er fouten in de logs staan en fixeert proactief de kritieke bug in productie? Natuurlijk is dat diezelfde ontwikkelaar. Er zijn ook anderen, maar om de een of andere reden is het alleen hij die begrijpt hoe de verschillende modules van het systeem zijn ingericht.
De kern van dit probleem is het gebrek aan documentatie. Want als alle diensten van jouw systeem goed beschreven waren, zou het mogelijk zijn om het probleem ook zonder analist op te lossen. Als de devops een paar dagen uit zijn drukke schema zou kunnen vrijmaken en alle servers, diensten en instructies voor het oplossen van gangbare problemen zou beschrijven, dan zou het probleem zonder hem kunnen worden opgelost. Je hoeft je biertje op het strand niet snel op te drinken en wifi te zoeken om een probleem op te lossen.
De competentie en verantwoordelijkheid van supportmedewerkers
Bij grote projecten stelt het bedrijf niet aan salarissen voor ontwikkelaars. Ze jagen op dure midden- of senior professionals van vergelijkbare projecten. De situatie met support is echter iets anders. Deze kosten proberen ze op alle manieren te verlagen. Bedrijven huren goedkope, net afgestudeerde IT'ers in en gaan vol vertrouwen de strijd aan. Deze strategie is mogelijk als het gaat om de website van een fabrieksbedrijf in Zelenograd.
Als het gaat om een grote online winkel, kost elke stilstand meer dan het maandloon van een IT'er. Laten we uitgaan van een jaarlijkse omzet van 1 miljard roebel. Dit is de minimale omzet voor elke online winkel in de ranking . We delen dit bedrag door het aantal uren in het jaar en krijgen meer dan 100.000 roebel aan nettaverlies. En als we de nachten niet meerekenen, kunnen we het bedrag gerust verdubbelen.
Maar geld is toch niet het belangrijkste, hĆØ? (nee, natuurlijk is het belangrijkste) Er zijn ook reputatieschade. Een uur dat een bekende internetwinkel offline is, kan zowel een golf van reacties op sociale media als publicaties in relevante media veroorzaken. En de gesprekken van vrienden in de keuken zoals "Koop daar niets, hun website is altijd down" zijn Ć¼berhaupt niet meetbaar.
Laten we over verantwoordelijkheid spreken. In mijn ervaring was er een geval waarin de dienstdoende administrator niet tijdig reageerde op de waarschuwing van het monitorsysteem over de onbereikbaarheid van de website. Op een mooie zomerse vrijdagavond lag de website van een bekende internetwinkel in Moskou stil. Zaterdagmorgen begreep de productmanager niet waarom de site niet opende, en in de ondersteuningschat en op Slack was het rustig. Deze fout kostte ons een bedrag met zes nullen, en de dienstdoende administratie.
Verantwoordelijkheid is een vaardigheid die moeilijk te ontwikkelen is. Of je hebt het, of je hebt het niet. Daarom probeer ik tijdens sollicitaties zijn aanwezigheid vast te stellen met verschillende vragen die indirect laten zien of iemand gewend is om verantwoordelijkheid te nemen. Als iemand zegt dat hij de universiteit heeft gekozen omdat zijn ouders dat zeiden, of zijn baan verandert omdat zijn vrouw zegt dat hij te weinig verdient, kun je beter niet met zulke mensen omgaan.
Samenwerking met het ontwikkelingsteam
Wanneer gebruikers in de productie eenvoudig problemen tegenkomen, lost de ondersteuning deze met eigen middelen op. Ze proberen het probleem te reproduceren, analyseren de logs, enzovoort. Maar wat te doen als er een bug opdook in de productie? In dat geval open de ondersteuning een taak voor de ontwikkelaars en hier begint het interessante.
Ontwikkelaars zijn voortdurend overbelast. Ze zijn druk bezig met het creƫren van nieuwe functies. Bugs in de productie oplossen is niet bepaald de meest interessante bezigheid. Deadlines voor het afronden van de volgende sprint branden. En dan komen er vervelende mensen van de ondersteuning en zeggen: "Stop urgent alles, we hebben problemen". De prioriteit van dergelijke taken is minimaal. Vooral als het probleem niet het meest kritisch is en de belangrijkste functionaliteit van de website werkt, en wanneer de release manager niet met opgewipperde ogen rondrent en niet schrijft: "Voeg deze taak urgent toe aan de dichtstbijzijnde release of hotfix".
Taken met een normale of lage prioriteit worden van release naar release overgedragen. Op de vraag 'Wanneer wordt de taak uitgevoerd?' krijg je antwoorden in de trant van: 'Sorry, er zijn op dit moment veel taken, vraag het aan de teamleiders of de release manager.'
Problemen in productie hebben een hogere prioriteit dan het creƫren van nieuwe functies. Slechte beoordelingen laten niet op zich wachten als gebruikers voortdurend tegen bugs aanlopen. Een beschadigde reputatie herstellen is moeilijk.
De vragen over de interactie tussen ontwikkeling en support worden opgelost door DevOps. Deze afkorting wordt vaak gebruikt om een specifiek persoon aan te duiden die helpt bij het creƫren van testomgevingen voor ontwikkeling, het opzetten van CI/CD-pijplijnen en het snel implementeren van getestte code in productie. DevOps is een benadering van softwareontwikkeling waarbij alle deelnemers in het proces nauw met elkaar samenwerken om sneller softwareproducten en -diensten te creƫren en bij te werken. Ik bedoel analisten, ontwikkelaars, testers en support.
Ondersteuning en ontwikkeling zijn in deze aanpak geen aparte afdelingen met hun eigen doelen en taken. Ontwikkeling is betrokken bij exploitatie en vice versa. De beroemde uitspraak van gedistribueerde teams: 'Het probleem ligt niet aan mijn kant' verschijnt niet meer zo vaak in chats, en eindgebruikers worden een beetje gelukkiger.
Bron: habr.com
