Zdravo, Habr! Podržavam Highload IT sisteme deset godina. U ovom članku neću pisati o problemima postavljanja nginxa za rad u 1000+ RPS modu ili drugim tehničkim stvarima. Iznijet ću svoja zapažanja o problemima u procesima koji nastaju u podršci i radu ovakvih sistema.
Monitoring
Tehnička podrška ne čeka da stigne zahtjev sa sadržajem „Šta zašto... stranica ponovo ne radi?“ U roku od minute nakon pada web lokacije, podrška bi već trebala vidjeti problem i početi ga rješavati. Ali stranica je vrh ledenog brega. Njegova dostupnost je jedna od prvih koja se prati.
Šta učiniti u situaciji kada preostala roba online prodavnice više ne stiže iz ERP sistema? Ili je CRM sistem koji obračunava popuste za klijente prestao da odgovara? Čini se da stranica radi. Uslovni Zabbix prima svoj 200 odgovor. Dežurna smjena nije dobila nikakva obavještenja od monitoringa i sa zadovoljstvom gleda prvu epizodu nove sezone Igre prijestolja.
Nadgledanje je često ograničeno samo na mjerenje stanja memorije, RAM-a i opterećenja procesora servera. Ali za posao je mnogo važnije dobiti dostupnost proizvoda na web stranici. Uvjetni kvar jedne virtualne mašine u klasteru dovest će do činjenice da će promet prestati ići na nju i povećati opterećenje na drugim serverima. Kompanija neće izgubiti novac.
Stoga, pored praćenja tehničkih parametara operativnih sistema na serverima, potrebno je konfigurisati poslovnu metriku. Mere koje direktno utiču na novac. Različite interakcije sa eksternim sistemima (CRM, ERP i drugi). Broj narudžbi za određeni vremenski period. Uspješne ili neuspješne autorizacije klijenata i drugi pokazatelji.
Interakcija sa eksternim sistemima
Svaka web stranica ili mobilna aplikacija s godišnjim prometom većim od milijardu rubalja komuniciraju s vanjskim sustavima. Počevši od gore navedenih CRM-a i ERP-a pa do transfera podataka o prodaji na eksterni Big Data sistem za analizu kupovina i nuđenje klijentu proizvoda koji će sigurno kupiti (u stvari, ne). Svaki takav sistem ima svoju podršku. I često komunikacija sa ovim sistemima uzrokuje bol. Pogotovo kada je problem globalan i morate ga analizirati u različitim sistemima.
Neki sistemi daju telefonski broj ili telegram za svoje administratore. Negdje trebate pisati pisma menadžerima ili ići na praćenje grešaka ovih vanjskih sistema. Čak iu kontekstu jedne velike kompanije, različiti sistemi često funkcionišu u različitim računovodstvenim sistemima aplikacija. Ponekad postaje nemoguće pratiti status aplikacije. Zahtjev dobijate u jednom uslovnom Jira. Onda ste u komentaru ove prve Jira stavili link do problema u drugoj Jira. U drugom Jira u aplikaciji neko već piše komentar koji morate nazvati uslovnog administratora Andreja da riješite problem. I tako dalje.
Najbolje rješenje za ovaj problem bilo bi stvaranje jedinstvenog prostora za komunikaciju, na primjer u Slacku. Pozivanje svih učesnika u procesu rada eksternih sistema da se pridruže. I također jedan tracker kako ne bi duplicirali aplikacije. Aplikacije bi trebalo pratiti na jednom mjestu, od praćenja obavijesti do izlaza rješenja za greške u budućnosti. Reći ćete da je to nerealno i istorijski se dešavalo da mi radimo u jednom trackeru, a oni u drugom. Pojavili su se različiti sistemi, imali su svoje autonomne IT timove. Slažem se i stoga problem treba riješiti odozgo na nivou CIO-a ili vlasnika proizvoda.
Svaki sistem sa kojim komunicirate treba da pruži podršku kao uslugu sa jasnim SLA za rešavanje problema po prioritetu. A ne kada uslovni administrator Andrej ima minut za vas.
Bottleneck Man
Da li svako na projektu (ili proizvodu) ima osobu čiji odlazak na godišnji odmor izaziva grčeve kod nadređenih? To može biti devops inženjer, analitičar ili programer. Na kraju krajeva, samo devops inženjer zna koji serveri imaju instalirane kontejnere, kako ponovo pokrenuti kontejner u slučaju problema, i općenito, nijedan složeni problem ne može se riješiti bez njega. Analitičar je jedini koji zna kako funkcioniše vaš složeni mehanizam. Koji tokovi podataka kamo idu. Pod kojim parametrima zahtjeva na koje usluge, na koje ćemo dobiti odgovore.
Ko će brzo shvatiti zašto postoje greške u zapisnicima i odmah popraviti kritičnu grešku u proizvodu? Naravno, isti programer. Ima i drugih, ali iz nekog razloga samo on razumije kako različiti moduli sistema funkcionišu.
Koren ovog problema je nedostatak dokumentacije. Uostalom, kada bi se opisali svi servisi vašeg sistema, onda bi bilo moguće riješiti problem bez analitičara. Ako bi devops odvojio par dana od svog zauzetog rasporeda i opisao sve servere, servise i uputstva za rješavanje tipičnih problema, onda bi problem u njegovom odsustvu mogao biti riješen i bez njega. Ne morate brzo popiti pivo na plaži dok ste na odmoru i tražiti wi-fi da riješite problem.
Kompetentnost i odgovornost pomoćnog osoblja
Na velikim projektima kompanije ne štede na platama programera. Traže skupe srednje ili starije osobe iz sličnih projekata. Sa podrškom situacija je malo drugačija. Te troškove pokušavaju smanjiti na sve moguće načine. Kompanije zapošljavaju jeftine jučerašnje Enikey radnike i hrabro kreću u bitku. Ova strategija je moguća ako je riječ o web stranici vizit karte fabrike u Zelenogradu.
Ako govorimo o velikoj online trgovini, onda svaki sat zastoja košta više od mjesečne plaće Enikey administratora. Uzmimo za početnu tačku 1 milijardu rubalja godišnjeg prometa. Ovo je minimalni promet bilo koje online trgovine iz rejtinga . Podijelite ovaj iznos s brojem sati godišnje i dobit ćete više od 100 rubalja neto gubitka. A ako ne računate noćne sate, možete sigurno udvostručiti iznos.
Ali novac nije glavna stvar, zar ne? (ne, naravno glavna stvar) Postoje i gubici ugleda. Propast poznate online trgovine može izazvati kako val recenzija na društvenim mrežama, tako i objave u tematskim medijima. A razgovori prijatelja u kuhinji u stilu „Ne kupujte ništa tamo, sajt im je uvijek neispravan“ nikako se ne mogu mjeriti.
Sada na odgovornost. U mojoj praksi je bio slučaj da dežurni administrator nije na vrijeme odgovorio na obavještenje sistema za praćenje o nedostupnosti stranice. Jednog prijatnog letnjeg petka uveče, veb lokacija poznate internet prodavnice u Moskvi je mirno ležala. U subotu ujutro, produkt menadžer ove stranice nije razumio zašto se stranica ne otvara, a u Slack-u je vladala tišina u razgovorima o podršci i hitnim obavijestima. Takva greška nas je koštala šestocifrene sume, a ovog dežurnog posla.
Odgovornost je vještina koja se teško razvija. Ili ga osoba ima ili ne. Stoga, tokom intervjua, pokušavam da identifikujem njegovo prisustvo raznim pitanjima koja indirektno pokazuju da li je osoba navikla da preuzme odgovornost. Ako čovjek odgovori da je izabrao fakultet jer su mu roditelji tako rekli ili promijeni posao jer mu je žena rekla da ne zarađuje dovoljno, onda je bolje da se ne petlja sa takvim ljudima.
Interakcija sa razvojnim timom
Kada korisnici tokom rada naiđu na jednostavne probleme s proizvodom, podrška ih rješava sama. Pokušava da reproducira problem, analizira dnevnike, itd. Ali što učiniti kada se u proizvodu pojavi greška? U ovom slučaju, podrška dodjeljuje zadatak programerima i tu počinje zabava.
Programeri su stalno preopterećeni. Oni stvaraju nove karakteristike. Ispravljanje grešaka u prodaji nije najzanimljivija aktivnost. Približavaju se rokovi za završetak sljedećeg sprinta. A onda dođu neugodni ljudi iz podrške i kažu: "Odmah prestanite sa svime, imamo problema." Prioritet takvih zadataka je minimalan. Pogotovo kada problem nije najkritičniji i glavna funkcionalnost stranice radi, i kada upravitelj izdanja ne trči okolo izbuljenih očiju i ne piše: “Hitno dodajte ovaj zadatak sljedećem izdanju ili hitnoj ispravci.”
Problemi sa normalnim ili niskim prioritetom se premještaju iz izdanja u izdanje. Na pitanje "Kada će zadatak biti završen?" dobićete odgovore u stilu: „Izvinite, trenutno ima puno zadataka, pitajte svoje vođe tima ili menadžera za oslobađanje“.
Problemi s produktivnošću imaju veći prioritet od stvaranja novih funkcija. Loše kritike neće dugo čekati ako korisnici stalno naiđu na greške. Narušenu reputaciju je teško vratiti.
Pitanja interakcije između razvoja i podrške rješavaju DevOps. Ova skraćenica se često koristi u obliku određene osobe koja pomaže u stvaranju testnih okruženja za razvoj, gradi CICD kanale i brzo dovodi testirani kod u proizvodnju. DevOps je pristup razvoju softvera kada svi učesnici u procesu blisko komuniciraju jedni s drugima i pomažu u brzom kreiranju i ažuriranju softverskih proizvoda i usluga. Mislim na analitičare, programere, testere i podršku.
U ovom pristupu podrška i razvoj nisu različiti odjeli sa vlastitim ciljevima i zadacima. Razvoj je uključen u rad i obrnuto. Čuvena fraza distribuiranih timova: “Problem nije na mojoj strani” više se ne pojavljuje tako često u četovima, a krajnji korisnici postaju malo sretniji.
izvor: www.habr.com