Ciao, Habr! Supporto i sistemi IT Highload da dieci anni. Non scriverò in questo articolo sui problemi legati alla configurazione di nginx per funzionare in modalità 1000+ RPS o altre cose tecniche. Condividerò le mie osservazioni sui problemi nei processi che sorgono nel supporto e nel funzionamento di tali sistemi.
Monitoraggio
Il supporto tecnico non attende l'arrivo di una richiesta con il contenuto "Cosa perché... il sito non funziona più?" Entro un minuto dal crash del sito, il supporto dovrebbe già vedere il problema e iniziare a risolverlo. Ma il sito è la punta dell’iceberg. La sua disponibilità è una delle prime ad essere monitorata.
Cosa fare nel caso in cui la merce rimanente di un negozio online non arrivi più dal sistema ERP? Oppure il sistema CRM che calcola gli sconti per i clienti ha smesso di rispondere? Il sito sembra funzionare. Zabbix condizionale riceve la sua risposta 200. Il turno di turno non ha ricevuto alcuna notifica dal monitoraggio e sta guardando con gioia il primo episodio della nuova stagione di Game of Thrones.
Il monitoraggio è spesso limitato alla sola misurazione dello stato della memoria, della RAM e del carico del processore del server. Ma per le aziende è molto più importante ottenere la disponibilità dei prodotti sul sito web. Il fallimento condizionale di una macchina virtuale nel cluster porterà al fatto che il traffico smetterà di raggiungerla e il carico su altri server aumenterà. L'azienda non perderà soldi.
Pertanto, oltre a monitorare i parametri tecnici dei sistemi operativi sui server, è necessario configurare le metriche aziendali. Metriche che influiscono direttamente sul denaro. Varie interazioni con sistemi esterni (CRM, ERP e altri). Il numero di ordini per un certo periodo di tempo. Autorizzazioni client riuscite o non riuscite e altre metriche.
Interazione con sistemi esterni
Qualsiasi sito Web o applicazione mobile con un fatturato annuo superiore a un miliardo di rubli interagisce con sistemi esterni. Partendo dai suddetti CRM ed ERP per finire con il trasferimento dei dati di vendita a un sistema Big Data esterno per analizzare gli acquisti e offrire al cliente un prodotto che sicuramente acquisterà (anzi, no). Ciascuno di questi sistemi ha il proprio supporto. E spesso la comunicazione con questi sistemi provoca dolore. Soprattutto quando il problema è globale ed è necessario analizzarlo in diversi sistemi.
Alcuni sistemi forniscono un numero di telefono o un telegramma ai propri amministratori. Da qualche parte devi scrivere lettere ai manager o andare ai bug tracker di questi sistemi esterni. Anche nel contesto di una grande azienda, sistemi diversi spesso operano in sistemi di contabilità applicativa diversi. A volte diventa impossibile tenere traccia dello stato di una richiesta. Ricevi una richiesta in una Jira condizionale. Quindi nel commento di questa prima Jira hai inserito un collegamento al problema in un'altra Jira. Nella seconda Jira dell'applicazione, qualcuno sta già scrivendo un commento that devi chiamare l'amministratore condizionale Andrey per risolvere il problema. E così via.
La soluzione migliore a questo problema sarebbe creare un unico spazio per la comunicazione, ad esempio in Slack. Invito a partecipare a tutti i partecipanti al processo di gestione dei sistemi esterni. E anche un tracker unico per non duplicare le applicazioni. Le applicazioni dovrebbero essere monitorate in un unico posto, dal monitoraggio delle notifiche all'output di soluzioni ai bug in futuro. Dirai che questo non è realistico e storicamente è accaduto che noi lavoriamo in un tracker e loro lavorino in un altro. Apparvero diversi sistemi, avevano i propri team IT autonomi. Sono d'accordo, quindi il problema deve essere risolto dall'alto a livello di CIO o di proprietario del prodotto.
Ogni sistema con cui interagisci dovrebbe fornire supporto come servizio con uno SLA chiaro per risolvere i problemi in base alla priorità. E non quando l'amministratore condizionale Andrey ha un minuto per te.
L'uomo del collo di bottiglia
Tutti coloro che lavorano in un progetto (o prodotto) hanno una persona la cui vacanza provoca convulsioni tra i loro superiori? Potrebbe trattarsi di un ingegnere, analista o sviluppatore devops. Dopotutto, solo un ingegnere devops sa su quali server sono installati i contenitori, come riavviare il contenitore in caso di problemi e, in generale, qualsiasi problema complesso non può essere risolto senza di lui. L'analista è l'unico che sa come funziona il tuo complesso meccanismo. Quali flussi di dati vanno dove. In base a quali parametri di richieste, a quali servizi e a quali riceveremo risposta.
Chi capirà rapidamente perché ci sono errori nei registri e risolverà tempestivamente un bug critico nel prodotto? Ovviamente lo stesso sviluppatore. Ce ne sono altri, ma per qualche motivo solo lui capisce come funzionano i diversi moduli del sistema.
La radice di questo problema è la mancanza di documentazione. Dopotutto, se fossero descritti tutti i servizi del tuo sistema, sarebbe possibile affrontare il problema senza un analista. Se devops dedicasse un paio di giorni alla sua fitta agenda e descrivesse tutti i server, i servizi e le istruzioni per risolvere i problemi tipici, allora il problema in sua assenza potrebbe essere risolto senza di lui. Non è necessario finire velocemente la birra sulla spiaggia mentre si è in vacanza e cercare il wi-fi per risolvere il problema.
Competenza e responsabilità del personale di supporto
Sui progetti di grandi dimensioni, le aziende non lesinano sugli stipendi degli sviluppatori. Stanno cercando persone di livello intermedio o senior costose provenienti da progetti simili. Con il supporto la situazione è un po' diversa. Stanno cercando di ridurre questi costi in ogni modo possibile. Le aziende assumono a buon mercato i lavoratori Enikey di ieri e vanno coraggiosamente in battaglia. Questa strategia è possibile se parliamo del sito web del biglietto da visita di uno stabilimento a Zelenograd.
Se parliamo di un grande negozio online, ogni ora di inattività costa più dello stipendio mensile di un amministratore Enikey. Prendiamo come punto di partenza 1 miliardo di rubli di fatturato annuo. Questo è il fatturato minimo di qualsiasi negozio online dalla valutazione . Dividi questo importo per il numero di ore all'anno e ottieni più di 100 rubli di perdite nette. E se non conti le ore notturne puoi tranquillamente raddoppiare la cifra.
Ma i soldi non sono la cosa principale, giusto? (no, ovviamente la cosa principale) Ci sono anche perdite di reputazione. Il crollo di un noto negozio online può causare sia un'ondata di recensioni sui social network che pubblicazioni su media tematici. E le conversazioni tra amici in cucina nello stile di "Non comprare niente lì, il loro sito web è sempre inattivo" non possono essere affatto misurate.
Ora la responsabilità. Nella mia pratica, si è verificato un caso in cui l'amministratore di turno non ha risposto in tempo alla notifica del sistema di monitoraggio sull'indisponibilità del sito. In un piacevole venerdì sera estivo, il sito web di un noto negozio online di Mosca giaceva in silenzio. Sabato mattina, il product manager di questo sito non ha capito perché il sito non si è aperto e c'era silenzio nelle chat di supporto e di notifica urgente in Slack. Un simile errore ci è costato una somma a sei cifre e a questo ufficiale di servizio il suo lavoro.
La responsabilità è un’abilità difficile da sviluppare. O una persona ce l'ha oppure no. Pertanto, durante le interviste, cerco di identificare la sua presenza con varie domande che mostrano indirettamente se una persona è abituata ad assumersi la responsabilità. Se una persona risponde che ha scelto l’università perché lo dicono i suoi genitori o cambia lavoro perché sua moglie dice che non guadagna abbastanza, allora è meglio non farsi coinvolgere da queste persone.
Interazione con il team di sviluppo
Quando gli utenti riscontrano semplici problemi con un prodotto durante il funzionamento, il supporto li risolve da solo. Tenta di riprodurre il problema, analizza i log e così via. Ma cosa fare quando appare un bug nel prodotto? In questo caso il supporto assegna il compito agli sviluppatori ed è qui che inizia il divertimento.
Gli sviluppatori sono costantemente sovraccarichi. Stanno creando nuove funzionalità. Correggere i bug con le vendite non è l'attività più interessante. La scadenza per completare il prossimo sprint si avvicina. E poi vengono persone sgradevoli dell'assistenza e dicono: "Lascia tutto subito, abbiamo problemi". La priorità di tali compiti è minima. Soprattutto quando il problema non è dei più critici e la funzionalità principale del sito funziona, e quando il gestore del rilascio non corre in giro con gli occhi sporgenti e scrive: "Aggiungi urgentemente questa attività alla prossima versione o hotfix".
I problemi con priorità normale o bassa vengono spostati da un rilascio all'altro. Alla domanda "Quando verrà completata l'attività?" riceverai risposte nello stile di: "Scusa, ci sono molte attività in questo momento, chiedi ai responsabili del tuo team o al responsabile del rilascio".
I problemi di produttività hanno una priorità maggiore rispetto alla creazione di nuove funzionalità. Le recensioni negative non tarderanno ad arrivare se gli utenti si imbattono costantemente in bug. Una reputazione danneggiata è difficile da ripristinare.
I problemi di interazione tra sviluppo e supporto vengono risolti da DevOps. Questa abbreviazione viene spesso utilizzata sotto forma di una persona specifica che aiuta a creare ambienti di test per lo sviluppo, crea pipeline CICD e porta rapidamente in produzione il codice testato. DevOps è un approccio allo sviluppo software in cui tutti i partecipanti al processo interagiscono strettamente tra loro e aiutano a creare e aggiornare rapidamente prodotti e servizi software. Intendo analisti, sviluppatori, tester e supporto.
In questo approccio, supporto e sviluppo non sono dipartimenti diversi con i propri scopi e obiettivi. Lo sviluppo è coinvolto nel funzionamento e viceversa. La famosa frase dei team distribuiti: “Il problema non è dalla mia parte” non appare più così spesso nelle chat e gli utenti finali diventano un po’ più contenti.
Fonte: habr.com