Hallo, Habr! Ik haw tsien jier Highload IT-systemen stipe. Ik sil yn dit artikel net skriuwe oer de problemen fan it ynstellen fan nginx om te wurkjen yn 1000+ RPS-modus of oare technyske dingen. Ik sil myn observaasjes diele oer de problemen yn 'e prosessen dy't ûntsteane yn' e stipe en eksploitaasje fan sokke systemen.
Monitoring
Technyske stipe wachtet net oant in fersyk komt mei de ynhâld "Wat wêrom ... de side wurket net wer?" Binnen in minút nei't de side crasht, soe stipe it probleem al moatte sjen en begjinne om it op te lossen. Mar de side is it tip fan 'e iisberch. De beskikberens dêrfan is ien fan 'e earsten dy't kontrolearre wurde.
Wat te dwaan mei de situaasje as de oerbleaune guod fan in online winkel net mear komme út it ERP systeem? Of hat it CRM-systeem dat koartingen foar kliïnten berekkent is stoppe te reagearjen? De side liket te wurkjen. Conditional Zabbix krijt syn 200 antwurd. De duty shift hat gjin notifikaasjes krigen fan 'e monitoaring en besjocht lokkich de earste ôflevering fan it nije seizoen fan Game of Thrones.
Monitoring wurdt faak beheind ta allinnich mjitten de steat fan ûnthâld, RAM en server prosessor load. Mar foar bedriuw is it folle wichtiger om produktbeskikberens op 'e webside te krijen. De betingst mislearring fan ien firtuele masine yn it kluster sil liede ta it feit dat ferkear sil stopje gean nei it en de lading op oare servers sil tanimme. It bedriuw sil gjin jild ferlieze.
Dêrom, neist it kontrolearjen fan de technyske parameters fan bestjoeringssystemen op servers, moatte jo saaklike metriken konfigurearje. Metriken dy't direkte ynfloed op jild. Ferskate ynteraksjes mei eksterne systemen (CRM, ERP en oaren). It oantal oarders foar in bepaalde perioade fan tiid. Súksesfolle as net suksesfolle klantautorisaasjes en oare metriken.
Ynteraksje mei eksterne systemen
Elke webside of mobile applikaasje mei in jierlikse omset fan mear as in miljard roebel ynteraksje mei eksterne systemen. Utgeande fan 'e boppeneamde CRM en ERP en einigje mei de oerdracht fan ferkeapgegevens nei in ekstern Big Data-systeem foar it analysearjen fan oankeapen en it oanbieden fan de klant in produkt dat hy perfoarst sil keapje (feitlik net). Elk sa'n systeem hat syn eigen stipe. En faaks feroarsaket kommunikaasje mei dizze systemen pine. Benammen as it probleem wrâldwiid is en jo it moatte analysearje yn ferskate systemen.
Guon systemen jouwe in telefoannûmer of telegram foar har behearders. Earne moatte jo brieven skriuwe oan managers of gean nei de bug trackers fan dizze eksterne systemen. Sels yn 'e kontekst fan ien grut bedriuw wurkje ferskate systemen faak yn ferskate applikaasje-boekhâldingsystemen. Soms wurdt it ûnmooglik om de status fan in applikaasje te folgjen. Jo ûntfange in fersyk yn ien betingst Jira. Dan sette jo yn it kommentaar fan dizze earste Jira in keppeling nei it probleem yn in oare Jira. Yn de twadde Jira yn de applikaasje, immen skriuwt al in reaksje dat jo moatte de betingsten admin Andrey skilje om it probleem op te lossen. En sa op.
De bêste oplossing foar dit probleem soe wêze om ien romte foar kommunikaasje te meitsjen, bygelyks yn Slack. Alle dielnimmers yn it proses fan it operearjen fan eksterne systemen útnoegje om mei te dwaan. En ek in inkele tracker om applikaasjes net te duplisearjen. Applikaasjes moatte op ien plak wurde folge, fan notifikaasjes kontrolearje oant de útfier fan brekoplossingen yn 'e takomst. Jo sille sizze dat dit ûnrealistysk is en it is histoarysk bard dat wy yn ien tracker wurkje, en se wurkje yn in oare. Ferskillende systemen ferskynden, se hiene har eigen autonome IT-teams. Ik gean akkoard, en dêrom moat it probleem fan boppen oplost wurde op it nivo fan CIO of produkteigner.
Elk systeem wêrmei jo ynteraksje moatte stypje as in tsjinst mei in dúdlike SLA om problemen op prioriteit op te lossen. En net as de betingsten admin Andrey in minút foar jo hat.
Flessehalsman
Hat elkenien op in projekt (of produkt) in persoan waans gean op fakânsje feroarsaakje krampen ûnder harren superieuren? Dit kin in devops-yngenieur, analist of ûntwikkelder wêze. Ommers, allinich in devops-yngenieur wit hokker servers hawwe hokker konteners binne ynstalleare, hoe't jo de kontener opnij starte yn gefal fan in probleem, en yn 't algemien kin elk kompleks probleem net sûnder him oplost wurde. De analist is de iennichste dy't wit hoe't jo komplekse meganisme wurket. Hokker datastreamen gean wêr. Under hokker parameters fan oanfragen op hokker tsjinsten, hokker sille wy antwurden krije.
Wa sil fluch begripe wêrom't d'r flaters binne yn 'e logs en in krityske brek yn it produkt prompt reparearje? Fansels deselde ûntwikkelder. D'r binne oaren, mar om ien of oare reden begrypt hy allinich hoe't de ferskate modules fan it systeem wurkje.
De woartel fan dit probleem is it gebrek oan dokumintaasje. Ommers, as alle tsjinsten fan jo systeem wurde beskreaun, dan soe it mooglik wêze om te gean mei it probleem sûnder in analist. As devops in pear dagen út syn drokke skema naam en alle servers, tsjinsten en ynstruksjes beskreau foar it oplossen fan typyske problemen, dan koe it probleem yn syn ôfwêzigens sûnder him oplost wurde. Jo hoege jo bier net fluch op it strân op te meitsjen wylst jo op fakânsje binne en sykje nei wi-fi om it probleem op te lossen.
Kompetinsje en ferantwurdlikens fan stypjende personiel
By grutte projekten besparje bedriuwen net op salarissen foar ûntwikkelders. Se sykje djoere middens of senioaren fan ferlykbere projekten. Mei stipe is de situaasje in bytsje oars. Se besykje dizze kosten op alle mooglike manieren te ferminderjen. Bedriuwen hiere goedkeape Enikey-arbeiders fan juster en geane frijmoedich yn 'e striid. Dizze strategy is mooglik as wy it hawwe oer in visitekaartwebside fan in plant yn Zelenograd.
As wy it hawwe oer in grutte online winkel, dan kostet elke oere fan downtime mear as it moanlikse salaris fan in Enikey-behearder. Litte wy 1 miljard roebels fan jierlikse omset as útgongspunt nimme. Dit is de minimale omset fan elke online winkel út 'e beoardieling . Diel dit bedrach troch it oantal oeren yn 't jier en krije mear as 100 roebel fan netto ferlies. En as jo de nacht oeren net telle, kinne jo it bedrach feilich ferdûbelje.
Mar jild is net it wichtichste ding, krekt? (nee, fansels it wichtichste) Der binne ek reputaasjeferlies. De ûndergong fan in bekende online winkel kin feroarsaakje sawol in weach fan resinsjes op sosjale netwurken en publikaasjes yn tematyske media. En de petearen fan freonen yn 'e keuken yn' e styl fan "Keapje dêr neat, har webside is altyd del" kinne hielendal net mjitten wurde.
No nei ferantwurdlikens. Yn myn praktyk wie d'r in gefal doe't de tsjinstbehearder net op 'e tiid reagearre op in notifikaasje fan it tafersjochsysteem oer de net-beskikberens fan' e side. Op in noflike simmer freedtejûn lei de webside fan in bekende online winkel yn Moskou rêstich. Op sneontemoarn begriep de produktmanager fan dizze side net wêrom't de side net iepene, en d'r wie stilte yn 'e stipe en urgente notifikaasjechats yn Slack. Sa'n flater koste ús in seisfiguer som, en dizze tsjinstoffisier syn baan.
Ferantwurdlikens is in drege feardigens om te ûntwikkeljen. Of in persoan hat it of net. Dêrom besykje ik by ynterviews har oanwêzigens te identifisearjen mei ferskate fragen dy't yndirekt sjen litte oft in persoan wend is om ferantwurdlikens te nimmen. As in persoan antwurdet dat hy in universiteit keas om't syn âlden dat seine of fan baan feroaret om't syn frou sei dat hy net genôch fertsjinnet, dan is it better om net mei sokke minsken te dwaan.
Ynteraksje mei it ûntwikkelingsteam
As brûkers ienfâldige problemen tsjinkomme mei in produkt by operaasje, lost stipe se op harsels op. Besiket it probleem te reprodusearjen, analysearret de logs, ensfh. Mar wat te dwaan as in brek ferskynt yn it produkt? Yn dit gefal jout stipe de taak oan de ûntwikkelders en dit is wêr't de wille begjint.
Untwikkelders wurde konstant oerladen. Se meitsje nije funksjes. It reparearjen fan bugs mei ferkeap is net de meast nijsgjirrige aktiviteit. Deadlines komme tichterby om de folgjende sprint te foltôgjen. En dan komme ûnnoflike minsken fan stipe en sizze: "Stop alles fuort, wy hawwe problemen." De prioriteit fan sokke taken is minimaal. Benammen as it probleem net it meast kritysk is en de haadfunksjonaliteit fan 'e side wurket, en as de releasebehearder net mei bulte eagen rûn en skriuwt: "Foegje dizze taak driuwend ta oan de folgjende release of hotfix."
Kwesties mei normale of lege prioriteit wurde ferpleatst fan release nei release. Op de fraach "Wannear sil de taak foltôge wurde?" jo sille antwurden krije yn 'e styl fan: "Sorry, d'r binne op it stuit in protte taken, freegje jo teamleaders of release manager."
Produktiviteitsproblemen hawwe hegere prioriteit dan it meitsjen fan nije funksjes. Minne resinsjes sille net lang duorje as brûkers konstant stroffelje op bugs. In skansearre reputaasje is dreech te herstellen.
Kwesties fan ynteraksje tusken ûntwikkeling en stipe wurde oplost troch DevOps. Dizze ôfkoarting wurdt faak brûkt yn 'e foarm fan in spesifike persoan dy't helpt te meitsjen testomjouwings foar ûntwikkeling, bout CICD pipelines en bringt fluch testen koade yn produksje. DevOps is in oanpak foar softwareûntwikkeling as alle dielnimmers oan it proses nau mei-inoar ynteraksje en helpe om softwareprodukten en tsjinsten fluch te meitsjen en te aktualisearjen. Ik bedoel analisten, ûntwikkelders, testers en stipe.
Yn dizze oanpak binne stipe en ûntwikkeling net ferskillende ôfdielingen mei har eigen doelen en doelstellingen. Untwikkeling is belutsen by operaasje en oarsom. De ferneamde sin fan ferspraat teams: "It probleem is net oan myn kant" komt net mear sa faak foar yn petearen, en ein brûkers wurde in bytsje lokkiger.
Boarne: www.habr.com