Pozdrav, Habr! Već deset godina podržavam Highload IT sustave. U ovom članku neću pisati o problemima postavljanja nginxa za rad u 1000+ RPS modu ili drugim tehničkim stvarima. Podijelit ću svoja zapažanja o problemima u procesima koji nastaju u podršci i radu takvih sustava.
nadgledanje
Tehnička podrška ne čeka dok ne stigne zahtjev sa sadržajem “Što zašto... stranica opet ne radi?” U roku od jedne minute nakon što se stranica sruši, podrška bi već trebala vidjeti problem i početi ga rješavati. Ali stranica je vrh ledenog brijega. Njegova dostupnost jedna je od prvih koja se prati.
Što učiniti u situaciji kada preostala roba internet trgovine više ne stiže iz ERP sustava? Ili je CRM sustav koji računa popuste za klijente prestao odgovarati? Čini se da stranica radi. Uvjetni Zabbix prima svoj odgovor 200. Dežurna smjena nije dobila nikakve dojave od nadzora i veselo prati prvu epizodu nove sezone Igre prijestolja.
Praćenje je često ograničeno samo na mjerenje stanja memorije, RAM-a i opterećenja procesora poslužitelja. Ali za posao je puno važnije da proizvod bude dostupan na web stranici. Uvjetni kvar jednog virtualnog stroja u klasteru dovest će do činjenice da će promet prestati ići na njega, a opterećenje na drugim poslužiteljima će se povećati. Tvrtka neće izgubiti novac.
Stoga, osim praćenja tehničkih parametara operativnih sustava na poslužiteljima, potrebno je konfigurirati poslovne metrike. Mjerni podaci koji izravno utječu na novac. Razne interakcije s vanjskim sustavima (CRM, ERP i drugi). Broj narudžbi za određeno vremensko razdoblje. Uspješne ili neuspješne autorizacije klijenta i druge metrike.
Interakcija s vanjskim sustavima
Svaka web stranica ili mobilna aplikacija s godišnjim prometom većim od milijardu rubalja komunicira s vanjskim sustavima. Počevši od gore spomenutog CRM-a i ERP-a pa sve do prijenosa podataka o prodaji u eksterni Big Data sustav za analizu kupnje i ponudu klijentu proizvoda koji će sigurno kupiti (zapravo ne). Svaki takav sustav ima svoju podršku. I često komunikacija s tim sustavima uzrokuje bol. Pogotovo kada je problem globalan i potrebno ga je analizirati u različitim sustavima.
Neki sustavi daju telefonski broj ili telegram za svoje administratore. Negdje trebate pisati pisma upraviteljima ili otići do alata za praćenje grešaka ovih vanjskih sustava. Čak i unutar konteksta jedne velike tvrtke, različiti sustavi često rade u različitim aplikacijskim računovodstvenim sustavima. Ponekad postane nemoguće pratiti status aplikacije. Primate zahtjev u jednom uvjetnom Jira. Zatim u komentar ovog prvog Jira stavite poveznicu na problem u drugom Jira. U drugoj Jiri u aplikaciji već netko piše komentar koji trebate nazvati uvjetnog administratora Andreya da riješi problem. I tako dalje.
Najbolje rješenje za ovaj problem bilo bi stvaranje jedinstvenog prostora za komunikaciju, primjerice u Slacku. Pozivanje svih sudionika u procesu rada vanjskih sustava da se pridruže. I također jedan tracker kako se aplikacije ne bi duplicirale. Aplikacije bi se trebale pratiti na jednom mjestu, od praćenja obavijesti do rezultata rješenja bugova u budućnosti. Reći ćete da je to nerealno i povijesno se događalo da mi radimo u jednom trackeru, a oni u drugom. Pojavili su se različiti sustavi, imali su svoje autonomne IT timove. Slažem se i stoga problem treba riješiti odozgo na razini CIO-a ili vlasnika proizvoda.
Svaki sustav s kojim komunicirate trebao bi pružiti podršku kao uslugu s jasnim SLA za rješavanje problema prema prioritetu. A ne kada uvjetni admin Andrey ima minutu za vas.
Čovjek usko grlo
Ima li svatko na projektu (ili proizvodu) osobu čiji odlazak na godišnji odmor izaziva trzavice među nadređenima? To može biti devops inženjer, analitičar ili programer. Na kraju krajeva, samo devops inženjer zna na kojim serverima su instalirani koji kontejneri, kako restartati kontejner u slučaju problema, i općenito, bilo koji složeni problem ne može se riješiti bez njega. Analitičar je jedini koji zna kako funkcionira vaš složeni mehanizam. Koji tokovi podataka kamo idu. Pod kojim parametrima zahtjeva na koje usluge, na koje ćemo dobiti odgovore.
Tko će brzo shvatiti zašto postoje pogreške u zapisima i odmah popraviti kritičnu grešku u proizvodu? Naravno isti programer. Postoje i drugi, ali iz nekog razloga samo on razumije kako različiti moduli sustava rade.
Korijen ovog problema je nedostatak dokumentacije. Uostalom, ako su opisane sve usluge vašeg sustava, tada bi bilo moguće riješiti problem bez analitičara. Kad bi devops odvojio par dana od svog pretrpanog rasporeda i opisao sve servere, usluge i upute za rješavanje tipičnih problema, onda bi se problem u njegovoj odsutnosti mogao riješiti i bez njega. Ne morate brzo popiti pivo na plaži dok ste na odmoru i tražiti wi-fi kako biste riješili problem.
Kompetentnost i odgovornost pomoćnog osoblja
Na velikim projektima tvrtke ne štede na plaćama programera. Traže skupe srednje ili starije osobe iz sličnih projekata. S podrškom je situacija 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 govorimo o web stranici posjetnice tvornice u Zelenogradu.
Ako govorimo o velikoj online trgovini, onda svaki sat zastoja košta više od mjesečne plaće Enikey administratora. Uzmimo 1 milijardu rubalja godišnjeg prometa kao početnu točku. Ovo je minimalni promet bilo koje online trgovine iz ocjene . Podijelite ovaj iznos s brojem sati godišnje i dobit ćete više od 100 rubalja neto gubitaka. A ako ne računate noćne sate, možete sigurno udvostručiti količinu.
Ali novac nije glavna stvar, zar ne? (ne, naravno glavna stvar) Tu su i reputacijski gubici. Pad poznate internetske trgovine može izazvati i val recenzija na društvenim mrežama i publikacije u tematskim medijima. A razgovori prijatelja u kuhinji u stilu "Nemoj ništa kupovati tamo, njihova web stranica uvijek ne radi" uopće se ne mogu mjeriti.
Sada na odgovornost. U mojoj praksi bilo je slučajeva kada dežurni administrator nije na vrijeme reagirao na obavijest sustava za nadzor o nedostupnosti stranice. Ugodne ljetne petkove večeri, web stranica poznate internetske trgovine u Moskvi mirno je ležala. U subotu ujutro voditelju proizvoda ove stranice nije bilo jasno zašto se stranica ne otvara, a u chatovima podrške i hitnih obavijesti u Slacku vladala je tišina. Takva pogreška koštala nas je šesteroznamenkaste svote, a ovog dežurnog posla.
Odgovornost je vještina koju je teško razviti. Ili ga osoba ima ili nema. Stoga njezinu prisutnost tijekom intervjua nastojim identificirati raznim pitanjima koja posredno pokazuju je li osoba navikla preuzeti odgovornost. Ako osoba odgovori da je odabrala sveučilište jer su mu tako rekli roditelji ili promijeni posao jer mu je supruga rekla da ne zarađuje dovoljno, onda je bolje ne družiti se s takvim ljudima.
Interakcija s razvojnim timom
Kada korisnici naiđu na jednostavne probleme s proizvodom tijekom rada, podrška ih rješava sama. Pokušava reproducirati problem, analizira zapisnike i tako dalje. 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 značajke. Ispravljanje grešaka u prodaji nije najzanimljivija aktivnost. Bliže se rokovi za dovršetak sljedećeg sprinta. A onda dođu neugodni ljudi iz podrške i kažu: “Odmah sve prekinite, 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 piše: “Hitno dodajte ovaj zadatak u sljedeće izdanje ili hitni popravak.”
Problemi s normalnim ili niskim prioritetom premještaju se iz izdanja u izdanje. Na pitanje "Kada će zadatak biti završen?" dobit ćete odgovore u stilu: "Žao nam je, trenutno ima puno zadataka, pitajte svoje voditelje tima ili voditelja izdanja."
Problemi produktivnosti imaju veći prioritet od stvaranja novih značajki. Loše recenzije neće dugo čekati ako korisnici stalno nailaze na pogreške. Narušeni ugled teško je vratiti.
Probleme interakcije između razvoja i podrške rješava DevOps. Ova se kratica često koristi u obliku određene osobe koja pomaže u stvaranju testnih okruženja za razvoj, gradi CICD cjevovode i brzo dovodi testirani kod u proizvodnju. DevOps je pristup razvoju softvera kada svi sudionici u procesu blisko međusobno komuniciraju i pomažu u brzom stvaranju 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 svojim ciljevima i ciljevima. Razvoj je uključen u rad i obrnuto. Poznata rečenica distribuiranih timova: “Problem nije na mojoj strani” više se ne pojavljuje tako često u chatovima, a krajnji korisnici postaju malo sretniji.
Izvor: www.habr.com