Ciao, Habr! Da dieci anni supporto sistemi IT Highload. In questo articolo non parlerò dei problemi di configurazione di nginx per funzionare in modalità 1000+ RPS o di altre questioni tecniche. Condividerò osservazioni sui problemi nei processi che sorgono nel supporto e nella gestione di tali sistemi.
Monitoraggio
Il supporto tecnico non aspetta che arrivi una richiesta con contenuto come "Perché... il sito non funziona di nuovo?". Il supporto deve già vedere il problema un minuto dopo il crash del sito e iniziare a risolverlo. Ma il sito è solo la punta dell'iceberg. La sua disponibilità è monitorata come una delle prime cose.
Cosa fare quando le scorte dei prodotti di un negozio online smettono di arrivare dal sistema ERP? O quando il sistema CRM, che calcola gli sconti per i clienti, smette di rispondere? Il sito, nel frattempo, sembra funzionare. Il condizionale Zabbix riceve la sua risposta 200. Il turno di guardia non ha ricevuto alcuna notifica dal monitoraggio e sta serenamente guardando il primo episodio della nuova stagione di "Game of Thrones".
Spesso il monitoraggio si limita a misurare solo lo stato della memoria, della RAM e del carico dei processori. server. Tuttavia, per un'azienda è molto più importante avere disponibilità dei prodotti sul sito. L'eventuale caduta di una macchina virtuale nel cluster porterà a un'interruzione del traffico e a un aumento del carico sugli altri server. L'azienda non subirà perdite economiche.
Perciò, oltre al monitoraggio dei parametri tecnici dei sistemi operativi sui server, è necessario impostare metriche aziendali. Metriche che influiscono direttamente sui guadagni. Diverse interazioni con sistemi esterni (CRM, ERP e altri). Il numero di ordini in un dato intervallo di tempo. Autorizzazioni cliente riuscite o non riuscite e altre metriche.
Interazione con sistemi esterni
Qualsiasi sito o applicazione mobile con un fatturato annuale superiore a un miliardo di rubli interagisce con sistemi esterni. Dalle CRM e ERP menzionate in precedenza fino al trasferimento di dati di vendita a sistemi esterni di Big Data per l'analisi delle acquisti e l'offerta al cliente di un prodotto che sicuramente comprerà (in realtà no). Ogni sistema di questo tipo ha il proprio supporto. E spesso, interagire con questi sistemi provoca frustrazione. Soprattutto quando il problema è globale e deve essere analizzato in diversi sistemi.
Alcuni sistemi forniscono il numero di telefono o il telegram del loro amministratore. In altri casi, è necessario scrivere email ai manager o andare nei bug tracker di questi sistemi esterni. Anche all'interno di una grande azienda, diversi sistemi spesso operano in diversi sistemi di gestione delle richieste. A volte diventa impossibile tracciare lo stato di una richiesta. Ricevi una richiesta in una certa Jira. Poi, nei commenti di quella prima Jira, metti un link a un'attività in un'altra Jira. Nella seconda Jira qualcuno già scrive un commento che bisogna chiamare l'amministratore condizionale Andrea per risolvere la questione. E così via.
Una soluzione ottimale a questo problema sarebbe creare uno spazio comune per la comunicazione, ad esempio in Slack, invitando tutti i partecipanti al processo di gestione dei sistemi esterni. Inoltre, sarebbe utile avere un unico tracker per non duplicare le richieste. Le richieste dovrebbero essere monitorate in un solo posto, dalla notifica del monitoraggio fino alla risoluzione dei bug in produzione. Potreste dire che è irreale e che storicamente avete sempre lavorato in un tracker, mentre loro ne usano un altro. Sono emersi diversi sistemi, ognuno con i propri team IT autonomi. Sono d'accordo, quindi la questione deve essere affrontata a livello dirigenziale, dal CIO o dal product owner.
Ogni sistema con cui interagite dovrebbe fornire supporto come servizio, con un chiaro SLA per la risoluzione dei problemi in base alle priorità. Non quando il coordinatore Andrei ha un momento libero per voi.
Persona-collo di bottiglia
Ciascun progetto (o prodotto) ha quella persona il cui congedo provoca ansia nei superiori? Potrebbe essere un ingegnere DevOps, un analista o uno sviluppatore. Solo l'ingegnere DevOps sa su quali server sono installati quali container, come riavviare un container in caso di problemi e, in generale, nessun problema complesso viene risolto senza di lui. L'analista è l'unico che capisce come funziona il vostro meccanismo complesso. Quali flussi di dati vanno dove. Con quali parametri le richieste vengono effettuate a quali servizi e quali risposte riceveremo.
Chi capirà rapidamente perché ci sono errori nei log e risolverà rapidamente un bug critico in produzione? Certamente lo sviluppatore. Ce ne sono altri, ma sembra che solo lui comprenda come siano strutturati i vari moduli del sistema.
La radice di questo problema è l'assenza di documentazione.. Infatti, se tutti i servizi del tuo sistema fossero descritti, si potrebbe affrontare il problema anche senza un analista. Se il devops trovasse un paio di giorni nel suo fitto programma per descrivere tutti i server, i servizi e le istruzioni per risolvere problemi comuni, il problema della sua assenza potrebbe essere affrontato anche senza di lui. Non è necessario bere rapidamente la birra in spiaggia durante le vacanze e cercare Wi-Fi per risolvere un problema.
Competenze e responsabilità del personale di supporto
Nei grandi progetti, le aziende non badano a spese per gli sviluppatori. Cacciano cari midores o senior da progetti simili. La situazione con il supporto è un po' diversa. Queste spese vengono ridotte il più possibile. Le aziende assumono ex aiutanti di basso costo e si lanciano nella mischia. Questa strategia è possibile se si parla di un sito web vetrina di qualche fabbrica a Zelenograd.
Se si tratta di un grande negozio online, ogni ora di inattività costa più di uno stipendio mensile per un amministratore ex aiutante. Prendiamo come punto di partenza 1 miliardo di rubli di fatturato annuale. Questo è il fatturato minimo di qualsiasi negozio online della classifica . Dividiamo questa somma per il numero di ore in un anno e otteniamo oltre 100.000 rubli di perdite nette. E se non consideriamo le ore notturne, possiamo tranquillamente raddoppiare l'importo.
Ma i soldi non sono tutto, vero? (no, certo che sono importanti) Ci sono anche le perdite reputazionali. Un'ora di inattività di un noto negozio online può generare sia una raffica di commenti sui social media, sia articoli sui media di settore. E le conversazioni tra amici sul tipo di “Non comprare nulla da loro, il loro sito non funziona mai” sono praticamente impossibili da misurare.
Ora parliamo di responsabilità. Nella mia esperienza, c'è stata una situazione in cui l'amministratore di turno non ha reagito in tempo all'avviso del sistema di monitoraggio riguardante l'inaccessibilità del sito. In una piacevole serata estiva di venerdì, il sito di un noto negozio online di Mosca era silenziosamente inattivo. Sabato mattina, il responsabile di quel sito non capiva perché il sito non si aprisse, mentre nei canali di supporto e nelle comunicazioni urgenti su Slack regnava il silenzio. Questo errore ci è costato una somma a sei cifre e ha messo in difficoltà quel turno.
La responsabilità è un'abilità difficile da sviluppare. Una persona può avere responsabilità o meno. Per questo, durante i colloqui cerco di scoprire se le ha ponendo domande che rivelano indirettamente se la persona è abituata a prendersi le proprie responsabilità. Se una persona risponde di aver scelto l'università perché lo hanno detto i genitori o cambia lavoro perché la moglie ha detto che guadagna poco, è meglio non avere a che fare con tali persone.
Interazione con il team di sviluppo
Quando gli utenti incontrano problemi semplici durante l'uso in produzione, il supporto li risolve per conto proprio. Cerca di riprodurre il problema, analizza i log e così via. Ma cosa fare quando emerge un bug in produzione? In questo caso, il supporto apre un ticket per gli sviluppatori e qui inizia la parte più interessante.
Gli sviluppatori sono costantemente sovraccarichi. Si occupano della creazione di nuove funzionalità. Risolvere i bug di produzione non è esattamente un compito stimolante. Le scadenze per il completamento di un altro sprint sono pressanti. E poi arrivano persone poco gradite dal supporto e dicono: «Devi smettere subito, abbiamo dei problemi». La priorità di questi compiti è minima. Soprattutto quando il problema non è critico e le funzioni principali del sito sono operative, e quando il release manager non corre con gli occhi sgranati dicendo: «Devi assolutamente includere questo compito nel prossimo rilascio o hotfix».
I compiti con priorità normale o bassa passano da un rilascio all'altro. Alla domanda «Quando sarà completato il compito?» riceverai risposte del tipo: «Scusami, ci sono molte cose da fare, chiedi ai team leader o al release manager».
I problemi in produzione hanno una priorità maggiore rispetto alla creazione di nuove funzionalità. Le recensioni negative non si faranno attendere se gli utenti continuano a imbattersi in bug. Ripristinare una reputazione danneggiata è difficile.
Le problematiche relative all'interazione tra sviluppo e supporto sono gestite da DevOps. Questa abbreviazione è spesso usata per riferirsi a una persona specifica che aiuta a creare ambienti di test per lo sviluppo, costruisce pipeline CICD e porta rapidamente il codice testato in produzione. DevOps è un approccio allo sviluppo software in cui tutti i partecipanti al processo collaborano strettamente tra loro, contribuendo a creare e aggiornare più velocemente i prodotti e servizi software. Mi riferisco ad analisti, sviluppatori, tester e supporto.
In questo approccio, supporto e sviluppo non sono diversi reparti con obiettivi e compiti propri. Lo sviluppo è coinvolto nelle operazioni e viceversa. La famosa frase dei team distribuiti: "Il problema non è dalla mia parte" è meno frequentemente presente nelle chat, e gli utenti finali diventano un po' più felici.
Fonte: habr.com
