Ciao, Habr! Da dieci anni supporto sistemi IT ad alta disponibilità. Non parlerò in questo articolo 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 nell'operazione di tali sistemi.
Monitoraggio
Il supporto tecnico non aspetta che arrivi una richiesta con contenuto "Perché... il sito non funziona di nuovo?". Il supporto deve già vedere il problema e cominciare a risolverlo un minuto dopo il malfunzionamento del sito. Ma il sito è solo la punta dell'iceberg.La sua disponibilità viene monitorata tra le prime cose.
Cosa fare se le scorte di prodotti di un negozio online hanno smesso di arrivare dal sistema ERP? O se il sistema CRM, che calcola gli sconti per i clienti, ha smesso di rispondere? Il sito, intanto, sembra funzionare. Il condizionale Zabbix riceve la sua risposta 200. Il turno di guardia non ha ricevuto alcuna notifica dal monitoraggio e si gode l'episodio finale della prima serie della nuova stagione de "Il Trono di Spade".
Spesso il monitoraggio si limita a misurare lo stato della memoria, della RAM e il carico dei processori. server. Ma per le aziende è molto più importante avere la disponibilità dei prodotti sul sito. Il guasto di una macchina virtuale in un cluster porterà a un'interruzione del traffico verso di essa e aumenterà il carico sugli altri server. L'azienda non perderà denaro.
Pertanto, oltre al monitoraggio dei parametri tecnici dei sistemi operativi sui server, è necessario impostare metriche di business. Metriche che influiscono direttamente sui soldi. Diverse interazioni con sistemi esterni (CRM, ERP e altro). Il numero di ordini in un certo lasso di tempo. Autenticazioni dei clienti riuscite o meno 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. A partire dai sopra menzionati CRM e ERP fino alla trasmissione di dati sulle vendite a un sistema di Big Data esterno per l'analisi degli acquisti e la proposta al cliente di un prodotto che acquisterà sicuramente (in realtà no). Ogni sistema di questo tipo ha il proprio supporto. E spesso interagire con questi sistemi può essere doloroso. Soprattutto quando il problema è globale e deve essere analizzato in diversi sistemi.
Alcuni sistemi forniscono il numero di telefono o Telegram dei loro amministratori. In altri casi, è necessario inviare email ai manager o accedere ai bug tracker di questi sistemi esterni. Anche all'interno di una grande azienda, diversi sistemi spesso operano in modi diversi per la gestione delle richieste. Seguire lo stato di una richiesta può diventare impossibile. Ricevi una richiesta in una certa Jira. Poi, nei commenti di questa prima Jira, metti un link ad un'attività in un'altra Jira. Nella seconda Jira, qualcuno sta già scrivendo un commento che è necessario contattare il presunto amministratore Andrej per risolvere la questione. E così via.
La soluzione ottimale per affrontare questo problema sarebbe la creazione di uno spazio unificato per la comunicazione, ad esempio in Slack. Invitare tutti i partecipanti al processo di gestione dei sistemi esterni. E anche un tracker unico, per non duplicare le richieste. Le richieste devono essere monitorate in un unico luogo, dalla notifica di monitoraggio fino alla risoluzione dei bug in produzione. Direte che è irrealistico e che storicamente avete sempre lavorato in un tracker, mentre loro in un altro. Sono emerse diverse soluzioni, ognuna con i propri team IT autonomi. Sono d'accordo e perciò il problema deve essere affrontato dall'alto, a livello di CIO o product owner.
Ogni sistema con cui interagite deve fornire supporto come servizio, con un chiaro SLA per la risoluzione dei problemi in base alle priorità. E non quando il presunto amministratore Andrej trova un momento libero per voi.
Una persona-collo di bottiglia
C'è qualcuno nel progetto (o prodotto) la cui assenza per ferie causa ansia ai dirigenti? Potrebbe essere un ingegnere DevOps, un analista o uno sviluppatore. Infatti, solo l'ingegnere DevOps sa su quali server sono installati quali container, come riavviare un container in caso di problemi e, in generale, qualsiasi problema complesso non può essere risolto senza di lui. L'analista è l'unico a sapere come funziona il vostro complicato meccanismo. Quali flussi di dati vanno dove e con quali parametri delle richieste a quali servizi, quali risposte riceveremo.
Chi capirà rapidamente perché ci sono errori nei log e risolverà rapidamente un bug critico in produzione? Certamente quello sviluppatore. Ci sono anche altri, ma per qualche motivo è solo lui a sapere come sono strutturati i diversi moduli del sistema.
Alla radice di questo problema c'è l'assenza di documentazione.. Infatti, se tutti i servizi del vostro sistema fossero descritti, sarebbe possibile affrontare il problema anche senza un analista. Se il devops riuscisse a ritagliarsi un paio di giorni dal suo fitto programma per descrivere tutti i server, i servizi e le istruzioni per risolvere problemi comuni, si potrebbe gestire il problema anche in sua assenza. Non bisogna accelerare il proprio drink in vacanza sulla spiaggia e cercare wi-fi per risolvere un problema.
Competenze e responsabilità del personale di supporto
Nei grandi progetti, le aziende non lesinano sullo stipendio degli sviluppatori. Reclutano costosi middle o senior da progetti simili. La situazione con il supporto è un po' diversa. Queste spese vengono cercate in ogni modo di ridurre. Le aziende assumono economici neolaureati e si lanciano senza paura. Tale strategia è possibile se si tratta di un sito vetrina di qualche fabbrica a Želenograd.
Se si tratta di un grande negozio online, ogni ora di inattività costa più dello stipendio mensile di un amministratore neolaureato. Prendiamo come punto di partenza un fatturato annuale di 1 miliardo di rubli. Questo è il fatturato minimo di qualsiasi negozio online in classifica . Dividiamo questa somma per il numero di ore in un anno e otteniamo più di 100.000 rubli di perdite nette. E se non consideriamo le ore notturne, possiamo tranquillamente raddoppiare l'importo.
Ma i soldi non sono tutto, giusto? (no, certo che sono tutto) Ci sono anche perdite reputazionali. Un'ora di inattività di un noto negozio online può generare sia una fiammata di recensioni sui social media che articoli sui media di settore. E le chiacchiere tra amici in cucina come "Non comprare nulla lì, il loro sito è sempre non funziona" non possono essere nemmeno misurate.
Ora parliamo di responsabilità. Nella mia esperienza, c'è stato un caso in cui un amministratore di turno non ha reagito in tempo a una segnalazione del sistema di monitoraggio riguardante l'inaccessibilità del sito. In una piacevole serata estiva di venerdì, il sito di un noto negozio online a Mosca era silenziosamente inattivo. Il sabato mattina, il product del sito non capiva perché il sito non si aprisse, e nei canali di supporto e nelle segnalazioni urgenti su Slack regnava il silenzio. Un errore del genere ci è costato una cifra a sei zeri, e al turno del giorno non è rimasta alcuna responsabilità.
La responsabilità è una competenza difficile da sviluppare. Una persona ha o non ha responsabilità. Pertanto, durante i colloqui cerco di rivelare la sua presenza con varie domande che mostrano indirettamente se la persona è abituata a prendersi la responsabilità. Se una persona risponde di aver scelto l'università perché glielo hanno detto i genitori, o cambia lavoro perché la moglie sostiene che guadagna poco, è meglio non averci a che fare.
Interazione con il team di sviluppo
Quando in produzione, durante l’uso, gli utenti affrontano problemi non complessi, il supporto li risolve autonomamente. Cerca di riprodurre il problema, analizza i log e così via. Ma cosa fare quando appare un bug in produzione? In questo caso, il supporto crea un ticket per gli sviluppatori e qui inizia la parte interessante.
Gli sviluppatori sono continuamente sovraccarichi. Sono occupati nella creazione di nuove funzionalità. Risolvere i bug in produzione è, diciamo, un compito non proprio interessante. Le scadenze per il completamento del prossimo sprint sono imminenti. E qui arrivano sgradevoli persone dal supporto che dicono: “Devi smettere tutto, abbiamo dei problemi”. La priorità di queste attività è minima. Soprattutto quando il problema non è il più critico e la funzionalità principale del sito è operativa, e quando il release manager non corre con gli occhi sbarrati chiedendo: “Devi assolutamente includere questo compito nella prossima release o nell’hotfix”.
I compiti con priorità normale o bassa si spostano da una release all'altra. Alla domanda “Quando sarà completato il compito?” riceverai risposte del tipo: “Scusa, ora abbiamo molti compiti, chiedi ai team lead o al release manager”.
I problemi in produzione hanno una priorità maggiore rispetto alla creazione di nuove funzionalità. Le recensioni negative non tarderanno ad arrivare se gli utenti continuano a imbattersi in bug. Ripristinare una reputazione danneggiata è difficile.
Le questioni relative all'interazione tra sviluppo e supporto sono gestite da DevOps. Questa abbreviazione è spesso utilizzata 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 e aiutano a creare e aggiornare più rapidamente prodotti e servizi software. Mi riferisco ad analisti, sviluppatori, tester e supporto.
Nel supporto e nello sviluppo di questo approccio, i dipartimenti non hanno obiettivi e compiti diversi. Lo sviluppo è coinvolto nell'operatività e viceversa. La famosa frase dei team distribuiti: «Il problema non è dalla mia parte» appare sempre meno spesso nelle chat, e gli utenti finali diventano un po' più felici.
Fonte: habr.com
