Hallo, Habr! Ik ondersteun al tien jaar Highload IT-systemen. Ik zal in dit artikel niet schrijven over de problemen bij het instellen van nginx om te werken in de 1000+ RPS-modus of andere technische zaken. Ik zal mijn observaties delen over de problemen in de processen die ontstaan bij de ondersteuning en werking van dergelijke systemen.
controle
Technische ondersteuning wacht niet tot er een verzoek binnenkomt met de inhoud “Wat waarom... werkt de site weer niet?” Binnen een minuut nadat de site crasht, zou de ondersteuning het probleem al moeten zien en beginnen met het oplossen ervan. Maar de locatie is het topje van de ijsberg. De beschikbaarheid ervan is een van de eerste die wordt gecontroleerd.
Wat te doen met de situatie waarin de resterende goederen van een webwinkel niet meer vanuit het ERP-systeem aankomen? Of reageert het CRM-systeem dat kortingen voor klanten berekent niet meer? De site lijkt te werken. Voorwaardelijke Zabbix ontvangt zijn 200-reactie. De dienstploeg heeft geen meldingen ontvangen van de monitoring en kijkt met plezier naar de eerste aflevering van het nieuwe seizoen van Game of Thrones.
Monitoring beperkt zich vaak tot alleen het meten van de toestand van het geheugen, het RAM-geheugen en de belasting van de serverprocessor. Maar voor bedrijven is het veel belangrijker om productbeschikbaarheid op de website te krijgen. Het voorwaardelijk falen van één virtuele machine in het cluster zal ertoe leiden dat er geen verkeer meer naartoe gaat en dat de belasting op andere servers zal toenemen. Het bedrijf zal geen geld verliezen.
Daarom moet u, naast het monitoren van de technische parameters van besturingssystemen op servers, bedrijfsstatistieken configureren. Metrieken die rechtstreeks van invloed zijn op geld. Diverse interacties met externe systemen (CRM, ERP en andere). Het aantal bestellingen voor een bepaalde periode. Succesvolle of niet-succesvolle klantautorisaties en andere statistieken.
Interactie met externe systemen
Elke website of mobiele applicatie met een jaaromzet van meer dan een miljard roebel heeft interactie met externe systemen. Beginnend bij het bovengenoemde CRM en ERP en eindigend met de overdracht van verkoopgegevens naar een extern Big Data-systeem voor het analyseren van aankopen en het aanbieden van de klant een product dat hij zeker zal kopen (in feite niet). Elk dergelijk systeem heeft zijn eigen ondersteuning. En vaak veroorzaakt communicatie met deze systemen pijn. Vooral als het probleem mondiaal is en je het in verschillende systemen moet analyseren.
Sommige systemen bieden een telefoonnummer of telegram aan hun beheerders. Ergens moet je brieven schrijven naar managers of naar de bugtrackers van deze externe systemen gaan. Zelfs binnen de context van één groot bedrijf werken er vaak verschillende systemen in verschillende applicatieboekhoudingssystemen. Soms wordt het onmogelijk om de status van een aanvraag te volgen. Je ontvangt een verzoek in één voorwaardelijke Jira. Vervolgens zet je in de reactie van deze eerste Jira een link naar het issue in een andere Jira. In de tweede Jira in de applicatie schrijft iemand daar al een opmerking over u moet de voorwaardelijke beheerder Andrey bellen om het probleem op te lossen. En ga zo maar door.
De beste oplossing voor dit probleem zou zijn om één enkele ruimte voor communicatie te creëren, bijvoorbeeld in Slack. Het uitnodigen van alle deelnemers aan het proces van het bedienen van externe systemen om deel te nemen. En ook een single tracker om applicaties niet te dupliceren. Applicaties moeten op één plek worden gevolgd, van het monitoren van meldingen tot de output van bugoplossingen in de toekomst. Je zult zeggen dat dit onrealistisch is en dat het historisch gezien is gebeurd dat wij in de ene tracker werken, en zij in een andere. Er verschenen verschillende systemen, ze hadden hun eigen autonome IT-teams. Daar ben ik het mee eens, en daarom moet het probleem van bovenaf worden opgelost, op het niveau van de CIO of de producteigenaar.
Elk systeem waarmee u communiceert, moet ondersteuning bieden als een service met een duidelijke SLA om problemen met prioriteit op te lossen. En niet als de voorwaardelijke administrateur Andrey een minuutje voor je heeft.
Knelpunt mens
Heeft iedereen in een project (of product) een persoon wiens vakantie stuiptrekkingen veroorzaakt bij hun superieuren? Dit kan een devops engineer, analist of ontwikkelaar zijn. Alleen een devops-engineer weet immers op welke servers welke containers zijn geïnstalleerd, hoe de container opnieuw moet worden opgestart in geval van een probleem, en in het algemeen kan elk complex probleem zonder hem niet worden opgelost. De analist is de enige die weet hoe jouw complexe mechanisme werkt. Welke datastromen waar naartoe. Onder welke parameters van verzoeken op welke diensten, welke zullen we antwoorden ontvangen.
Wie begrijpt snel waarom er fouten in de logboeken staan en kan snel een kritieke fout in het product oplossen? Uiteraard dezelfde ontwikkelaar. Er zijn er nog meer, maar om de een of andere reden begrijpt alleen hij hoe de verschillende modules van het systeem werken.
De oorzaak van dit probleem is het gebrek aan documentatie. Als alle diensten van uw systeem beschreven zouden zijn, zou het probleem immers zonder analist kunnen worden opgelost. Als devops een paar dagen uit zijn drukke schema zouden nemen en alle servers, services en instructies zouden beschrijven voor het oplossen van typische problemen, dan zou het probleem tijdens zijn afwezigheid zonder hem kunnen worden opgelost. Je hoeft tijdens je vakantie niet snel je biertje op het strand leeg te drinken en op zoek te gaan naar wifi om het probleem op te lossen.
Competenties en verantwoordelijkheid van ondersteunend personeel
Bij grote projecten bezuinigen bedrijven niet op de salarissen van ontwikkelaars. Ze zijn op zoek naar dure midden- of senioren uit soortgelijke projecten. Met steun is de situatie een beetje anders. Ze proberen deze kosten op alle mogelijke manieren te verlagen. Bedrijven huren goedkope Enikey-werknemers van gisteren in en gaan moedig de strijd aan. Deze strategie is mogelijk als we het hebben over een visitekaartjewebsite van een fabriek in Zelenograd.
Als we het over een grote online winkel hebben, kost elk uur downtime meer dan het maandsalaris van een Enikey-beheerder. Laten we een jaaromzet van 1 miljard roebel als uitgangspunt nemen. Dit is de minimale omzet van elke online winkel volgens de beoordeling . Verdeel dit bedrag door het aantal uren per jaar en ontvang meer dan 100 roebel aan nettoverliezen. En als u de nachturen niet meetelt, kunt u het bedrag gerust verdubbelen.
Maar geld is niet het belangrijkste, toch? (nee, natuurlijk het belangrijkste) Er zijn ook reputatieverliezen. De ondergang van een bekende online winkel kan zowel een golf van recensies op sociale netwerken als publicaties in thematische media veroorzaken. En de gesprekken van vrienden in de keuken in de stijl van “Koop daar niets, hun website is altijd offline” zijn helemaal niet te meten.
Nu de verantwoordelijkheid. In mijn praktijk was er een geval waarin de dienstdoende beheerder niet op tijd reageerde op een melding van het monitoringsysteem over de onbeschikbaarheid van de site. Op een gezellige zomerse vrijdagavond lag de website van een bekende online winkel in Moskou stil. Zaterdagochtend begreep de productmanager van deze site niet waarom de site niet openging, en er viel stilte in de ondersteunings- en dringende notificatiechats in Slack. Zo'n fout kostte ons een bedrag van zes cijfers, en deze officier van dienst zijn baan.
Verantwoordelijkheid is een moeilijk te ontwikkelen vaardigheid. Of iemand het heeft of niet. Daarom probeer ik tijdens interviews de aanwezigheid ervan te identificeren met verschillende vragen die indirect laten zien of iemand gewend is verantwoordelijkheid te nemen. Als iemand antwoordt dat hij een universiteit heeft gekozen omdat zijn ouders dat zeiden, of van baan verandert omdat zijn vrouw zei dat hij niet genoeg verdient, dan is het beter om niet met zulke mensen in aanraking te komen.
Interactie met het ontwikkelteam
Wanneer gebruikers tijdens het gebruik eenvoudige problemen met een product tegenkomen, lost de ondersteuning deze zelf op. Probeert het probleem te reproduceren, analyseert de logboeken, enzovoort. Maar wat te doen als er een bug in het product verschijnt? In dit geval wijst de ondersteuning de taak toe aan de ontwikkelaars en dit is waar het plezier begint.
Ontwikkelaars worden voortdurend overbelast. Ze creëren nieuwe functies. Het oplossen van bugs bij de verkoop is niet de meest interessante activiteit. Deadlines naderen om de volgende sprint te voltooien. En dan komen er vervelende mensen uit de hulpverlening en zeggen: “Stop meteen met alles, we hebben problemen.” De prioriteit van dergelijke taken is minimaal. Vooral als het probleem niet het meest kritiek is en de hoofdfunctionaliteit van de site werkt, en als de releasemanager niet met uitpuilende ogen rondloopt en schrijft: “Voeg deze taak dringend toe aan de volgende release of hotfix.”
Problemen met een normale of lage prioriteit worden van release naar release verplaatst. Op de vraag “Wanneer is de taak voltooid?” je krijgt antwoorden in de stijl van: “Sorry, er zijn momenteel veel taken, vraag het aan je teamleiders of releasemanager.”
Productiviteitsproblemen hebben een hogere prioriteit dan het creëren van nieuwe functies. Slechte recensies zullen niet lang op zich laten wachten als gebruikers voortdurend op bugs stuiten. Een beschadigde reputatie is moeilijk te herstellen.
Kwesties van interactie tussen ontwikkeling en ondersteuning worden opgelost door DevOps. Deze afkorting wordt vaak gebruikt in de vorm van een specifieke persoon die helpt bij het creëren van testomgevingen voor ontwikkeling, het bouwen van CICD-pijplijnen en het snel in productie brengen van geteste code. DevOps is een benadering van softwareontwikkeling waarbij alle deelnemers aan het proces nauw met elkaar samenwerken en helpen om snel softwareproducten en -diensten te creëren en bij te werken. Ik bedoel analisten, ontwikkelaars, testers en ondersteuning.
In deze aanpak zijn ondersteuning en ontwikkeling geen verschillende afdelingen met hun eigen doelstellingen. Ontwikkeling is betrokken bij exploitatie en omgekeerd. De beroemde zin van gedistribueerde teams: “Het probleem ligt niet aan mijn kant” verschijnt niet meer zo vaak in chats en eindgebruikers worden een beetje gelukkiger.
Bron: www.habr.com