Ciao, Habr! Aghju supportatu i sistemi IT Highload per deci anni. Ùn scriveraghju micca in questu articulu nantu à i prublemi di stallà nginx per travaglià in modu 1000+ RPS o altre cose tecniche. Aghju da sparte e mo osservazioni nantu à i prublemi in i prucessi chì si sviluppanu in u sustegnu è u funziunamentu di tali sistemi.
Monitoramentu
U supportu tecnicu ùn aspetta micca chì una dumanda ghjunghje cù u cuntenutu "Chì perchè ... u situ ùn hè micca travagliatu di novu?" In un minutu dopu à u crash di u situ, u supportu deve digià vede u prublema è cumincià à risolve. Ma u situ hè a punta di l'iceberg. A so dispunibilità hè unu di i primi à esse monitoratu.
Chì fà cù a situazione quandu e merchenzie restante di una tenda in linea ùn ghjunghjenu più da u sistema ERP? O u sistema CRM chì calcula sconti per i clienti hà cessatu di risponde? U situ pare chì travaglia. Conditional Zabbix riceve a so risposta 200. U turnu di u duvere ùn hà micca ricevutu notificazioni da u monitoraghju è hè felice di fighjà u primu episodiu di a nova stagione di Game of Thrones.
U monitoraghju hè spessu limitatu à misurà solu u statu di memoria, RAM è carica di u processatore di u servitore. Ma per l'affari hè assai più impurtante per ottene a dispunibilità di u produttu nantu à u situ web. U fallimentu condicionale di una macchina virtuale in u cluster hà da purtà à u fattu chì u trafficu cesserà di andà in questu è a carica in altri servitori aumenterà. A cumpagnia ùn perderà soldi.
Dunque, in più di monitorà i paràmetri tecnichi di i sistemi operativi nantu à i servitori, avete bisognu di cunfigurà e metriche di l'affari. Metriche chì affettanu direttamente i soldi. Diverse interazzione cù sistemi esterni (CRM, ERP è altri). U numeru di ordini per un certu periodu di tempu. Autorizzazioni di u cliente riesciuti o senza successu è altre metriche.
Interazzione cù sistemi esterni
Ogni situ web o applicazione mobile cù un fatturatu annu di più di un miliardo di rubli interagisce cù sistemi esterni. Partendu da u CRM è l'ERP sopra citati è finiscinu cù u trasferimentu di dati di vendita à un sistema di Big Data esternu per analizà e compra è offre à u cliente un pruduttu chì hà da cumprà (in fattu, micca). Ogni tali sistema hà u so sustegnu. È spessu a cumunicazione cù questi sistemi provoca dolore. In particulare quandu u prublema hè globale è avete bisognu di analizà in diversi sistemi.
Certi sistemi furnisce un numeru di telefunu o telegramma per i so amministratori. In qualchì locu avete bisognu di scrive lettere à i gestori o andate à i bug trackers di questi sistemi esterni. Ancu in u cuntestu di una grande cumpagnia, diversi sistemi spessu operanu in diversi sistemi di cuntabilità di l'applicazione. Calchì volta diventa impussibile à seguità u statutu di una dumanda. Ricevete una dumanda in una Jira cundizionale. Allora in u cumentu di sta prima Jira mette un ligame à u prublema in un altru Jira. In a seconda Jira in l'appiecazione, qualchissia hà digià scrittu un cumentu chì avete bisognu di chjamà l'amministratore condizionale Andrey per risolve u prublema. E accussì.
A megliu suluzione à stu prublema seria di creà un spaziu unicu per a cumunicazione, per esempiu in Slack. Invitendu tutti i participanti in u prucessu di uperazione di sistemi esterni à unisce. È ancu un tracker unicu per ùn duplicà l'applicazioni. L'applicazioni devenu esse tracciate in un locu, da a monitorizazione di e notificazioni à l'output di soluzioni di bug in u futuru. Diterete chì questu ùn hè micca realisticu è hè accadutu storicamente chì travagliammu in un tracker, è travaglianu in un altru. Diversi sistemi apparsu, anu avutu i so squadre IT autonomi. Sò d'accordu, è dunque u prublema deve esse risolta da sopra à u livellu di u CIO o di u pruprietariu di u produttu.
Ogni sistema chì interagisce cù deve furnisce un supportu cum'è serviziu cù un SLA chjaru per risolve i prublemi per priorità. È micca quandu l'amministratore condicionale Andrey hà un minutu per voi.
L'omu à collu di bottiglia
Tutti in un prughjettu (o pruduttu) anu una persona chì andendu in vacanze provoca cunvulsioni trà i so superiori? Questu puderia esse un ingegnere devops, analista o sviluppatore. Dopu tuttu, solu un ingegnere di devops sà quale servitori anu chì cuntenituri installati, cumu reboot u cuntinuu in casu di prublema, è in generale, ogni prublema cumplessu ùn pò esse risoltu senza ellu. L'analista hè l'unicu chì sà cumu funziona u vostru mecanismu cumplessu. Quali flussi di dati vanu induve. Sottu quali parametri di dumande à quale servizii, quale ricevemu risposte.
Quale hà da capisce rapidamente perchè ci sò errori in i logs è prontamente riparà un bug criticu in u pruduttu? Di sicuru, u listessu sviluppatore. Ci sò altri, ma per qualchi ragiuni solu ellu capisce cumu funziona i diversi moduli di u sistema.
A radica di stu prublema hè a mancanza di documentazione. Dopu tuttu, se tutti i servizii di u vostru sistema sò stati discritti, allora saria pussibule di trattà u prublema senza un analista. Se devops hà pigliatu un paru di ghjorni fora di u so impegnu è hà descrittu tutti i servitori, servizii è struzzioni per risolve i prublemi tipici, allora u prublema in a so assenza puderia esse risolta senza ellu. Ùn avete bisognu di finisce rapidamente a vostra biera nantu à a spiaggia mentre in vacanze è cercate wi-fi per risolve u prublema.
Cumpetenza è rispunsabilità di u persunale di supportu
Nantu à i grandi prughjetti, l'imprese ùn mancanu micca i salarii di sviluppatori. Anu cercanu medii caru o anziani da prughjetti simili. Cù sustegnu a situazione hè un pocu sfarente. Pruvate di riduce sti costi in ogni modu pussibule. L'imprese assumenu i travagliadori Enikey d'ieri à pocu costu è si mettenu in battaglia cun audacia. Questa strategia hè pussibule se parlemu di un situ web di una carta di cummerciale di una pianta in Zelenograd.
Se parlemu di una grande tenda in linea, allora ogni ora di downtime costa più di u salariu mensuale di un amministratore Enikey. Pigliemu 1 miliardo di rubli di fatturatu annuale cum'è puntu di partenza. Questu hè u fatturatu minimu di ogni tenda in linea da a valutazione . Divide sta quantità per u numeru di ore per annu è uttene più di 100 000 rubles di perdite nette. È se ùn cuntate micca l'ore di notte, pudete duppià in modu sicuru a quantità.
Ma i soldi ùn hè micca u principale, nò? (nò, di sicuru u principale) Ci sò ancu pèrdite di reputazione. A caduta di una tenda in linea ben cunnisciuta pò causà à tempu una onda di recensioni nantu à e rete suciale è publicazioni in i media tematichi. È e conversazioni di l'amichi in a cucina in u stilu di "Ùn cumprà nunda, u so situ web hè sempre falatu" ùn pò micca esse misuratu in tuttu.
Avà à rispunsabilità. In a mo pratica, ci era un casu quandu l'amministratore in u duvere ùn hà micca rispostu in u tempu à una notificazione da u sistema di surviglianza nantu à a indisponibilità di u situ. In una piacevule sera di u venneri d'estate, u situ web di una famosa tenda in linea in Mosca stava tranquillamente. U sabbatu matina, u capu di produttu di stu situ ùn hà micca capitu perchè u situ ùn hà micca apertu, è ci era u silenziu in u supportu è i chats di notificazione urgente in Slack. Un tali sbagliu ci hà custatu una somma di sei cifre, è questu ufficiale di u so travagliu.
A rispunsabilità hè una cumpetenza difficiuli di sviluppà. O una persona hà o micca. Per quessa, durante l'entrevista, pruvate d'identificà a so prisenza cù parechje dumande chì indirettamente mostranu se una persona hè abituata à piglià a rispunsabilità. Se una persona risponde chì ellu hà sceltu una università perchè i so genitori l'anu dettu o cambia u travagliu perchè a so moglia hà dettu ch'ellu ùn guadagna micca abbastanza, allora hè megliu ùn avè micca implicatu cù tali persone.
Interazzione cù u squadra di sviluppu
Quandu l'utilizatori scontranu prublemi simplici cù un pruduttu durante l'operazione, u supportu li risolve per sè stessu. Prova à ripruduce u prublema, analizà i logs, è cusì. Ma chì fà quandu un bug appare in u pruduttu? In questu casu, u supportu assigna u compitu à i sviluppatori è questu hè quì u divertimentu principia.
I sviluppatori sò constantemente sovraccarichi. Creanu novi funziunalità. Fixing bugs with sales ùn hè micca l'attività più interessante. I termini si avvicinanu per compie u prossimu sprint. E poi persone sgradevoli da u sustegnu venenu è dicenu: "Lascia tuttu immediatamente, avemu prublemi". A priorità di tali compiti hè minima. Soprattuttu quandu u prublema ùn hè micca u più criticu è a funziunalità principale di u situ funziona, è quandu u gestore di liberazione ùn corre micca cù l'ochji sbucciati è scrive: "Aghjunghje urgentemente questu compitu à a prossima versione o hotfix".
I prublemi cù priorità normale o bassa sò spustati da liberazione à liberazione. À a quistione "Quandu serà finitu u compitu?" vi riceverete risposte in u stilu di: "Scusate, ci sò assai travaglii avà, dumandate à i vostri capi di squadra o u manager di liberazione".
I prublemi di produttività piglianu una priorità più alta chè a creazione di novi funzioni. I critichi cattivi ùn saranu micca longu se l'utilizatori sbattulanu constantemente in bug. Una reputazione dannata hè difficiule di restaurà.
I prublemi di interazzione trà u sviluppu è u supportu sò risolti da DevOps. Questa abbreviazione hè spessu usata in a forma di una persona specifica chì aiuta à creà ambienti di prova per u sviluppu, custruisce pipeline CICD è porta rapidamente codice testatu in a produzzione. DevOps hè un approcciu à u sviluppu di software quandu tutti i participanti in u prucessu interagiscenu strettamente cù l'altri è aiutanu à creà rapidamente è aghjurnà i prudutti è i servizii di software. Vogliu dì analisti, sviluppatori, testatori è supportu.
In questu approcciu, u sustegnu è u sviluppu ùn sò micca dipartimenti diffirenti cù i so scopi è ugettivi. U sviluppu hè implicatu in l'operazione è vice versa. A famosa frasa di squadre distribuite: "U prublema ùn hè micca da u mo latu" ùn hè più apparsu in i chats cusì spessu, è l'utilizatori finali diventanu un pocu più felice.
Source: www.habr.com