Ciao!
Mi chiamo Mikhail, sono il vice direttore IT di Sportmaster. Volevo condividere una storia su come abbiamo affrontato le difficoltà emerse durante la pandemia.
Nei primi giorni della nuova realtà, il formato abituale del commercio offline di Sportmaster si è fermato, e il carico sul nostro canale online, in particolare per quanto riguarda le consegne a domicilio, è aumentato di 10 volte. In poche settimane abbiamo trasformato un gigantesco business offline in un online, adattando il servizio alle esigenze dei nostri clienti.
In sostanza, ciò che era una nostra operazione secondaria è diventato il business principale. L'importanza di ogni ordine online è aumentata in modo estremo. Dovevamo preservare ogni rublo che il cliente portava in azienda.
Per rispondere rapidamente alle richieste dei clienti, abbiamo aperto un centro di contatto aggiuntivo nella sede centrale dell'azienda e ora possiamo ricevere circa 285.000 chiamate a settimana. Allo stesso tempo, abbiamo convertito 270 negozi in un nuovo formato di lavoro senza contatto e sicuro, il che ha permesso ai clienti di ricevere i propri ordini e ai dipendenti di mantenere il posto di lavoro.
Durante il processo di trasformazione, abbiamo affrontato due principali problemi. Innanzitutto, il carico sui nostri risorse online è aumentato notevolmente (Sergio spiegherà come abbiamo affrontato questo problema). Secondariamente, il flusso di operazioni rare (fino al COVID) è aumentato molte volte, il che ha richiesto un grande volume di automazione rapida. Per risolvere questo problema, abbiamo dovuto rapidamente deviare risorse da settori che prima erano principali. Come abbiamo affrontato questo problema — lo racconterà Elena.
Servizi online
Sergej Kolesnikov, responsabile dell'operatività del negozio online e dei microservizi
Da quando i nostri negozi al dettaglio hanno iniziato a chiudere per i visitatori, abbiamo iniziato a registrare un aumento di metriche come il numero di utenti, il numero di ordini effettuati nella nostra applicazione e il numero di richieste alle applicazioni.
Numero di ordini dal 18 al 31 marzo
Numero di richieste ai microservizi di pagamento online
Numero di ordini effettuati sul sito
Nel primo grafico vediamo che l'aumento è stato di circa 14 volte, nel secondo — 4 volte. Riteniamo che la metrica più indicativa in questo caso sia quella del tempo di risposta delle nostre applicazioni.
In questo grafico vediamo la risposta dei fronti e delle applicazioni, e ci siamo resi conto che non abbiamo notato alcuna crescita significativa.
In primo luogo, ciò è dovuto al fatto che abbiamo iniziato i lavori preparatori alla fine del 2019. Ora i nostri servizi sono riservati, è stata garantita la resilienza a livello di server fisici, sistemi di virtualizzazione, Docker e servizi in essi. Inoltre, le capacità delle nostre risorse server ci consentono di affrontare carichi multipli.
Lo strumento principale che ci ha aiutato in tutta questa storia è stato il nostro sistema di monitoraggio. In verità, fino a poco tempo fa non avevamo un sistema unico in grado di raccogliere metriche su tutti i livelli, dal livello hardware fisico e delle apparecchiature fino al livello delle metriche aziendali.
Formalmente, c'era un monitoraggio in azienda, ma di solito era disperso ed era sotto la responsabilità di specifici reparti. Di fatto, quando si verificava un incidente, quasi mai avevamo una comprensione unitaria di cosa fosse successo, non c'era informazione, e spesso questo portava a una ricerca circolare per trovare e localizzare il problema per una successiva risoluzione.
A un certo punto abbiamo pensato e deciso che era sufficiente tollerare tutto questo: avevamo bisogno di un sistema unico per vedere l'intera situazione. Le principali tecnologie nel nostro stack sono Zabbix come centro di allerta e archiviazione delle metriche, Prometheus per la raccolta e archiviazione delle metriche delle applicazioni, Stack ELK per il logging e l'archiviazione dei dati dell'intero sistema di monitoraggio, oltre a Grafana per la visualizzazione, Swagger, Docker e altre utili e familiari tecnologie.
Inoltre, utilizziamo non solo tecnologie disponibili sul mercato, ma sviluppiamo anche qualcosa di autonomo. Ad esempio, creiamo servizi per integrare i sistemi tra loro, quindi un'API per la raccolta delle metriche. Inoltre, stiamo lavorando su sistemi di monitoraggio proprietari: a livello di metriche aziendali utilizziamo test UI. E un bot su Telegram per notificare i team.
Cerchiamo anche di rendere il sistema di monitoraggio accessibile ai team, affinché possano archiviare autonomamente le proprie metriche e lavorarci, incluso configurare allerta su metriche specifiche che non hanno un'applicazione troppo ampia.
Nell'ambito del sistema, puntiamo alla proattività e alla localizzazione rapida degli incidenti. Inoltre, il numero dei nostri microservizi e sistemi è aumentato significativamente di recente, di conseguenza, cresce anche il numero di integrazioni. Nell'ottica di ottimizzare il processo di diagnosi degli incidenti a livello di integrazione, stiamo sviluppando un sistema che consente di effettuare controlli incrociati tra sistemi e di fornire un risultato, utile per identificare i principali problemi legati agli import e all'interazione tra i sistemi.
Naturalmente, abbiamo ancora molto da fare e da sviluppare per quanto riguarda l'operatività dei sistemi, e stiamo lavorando attivamente in tal senso. Maggiori dettagli sul nostro sistema di monitoraggio possono essere letti .
Collaudi tecnici
Sergei Orlov, dirige il centro di competenza per lo sviluppo web e mobile
Dall'inizio della chiusura dei negozi fisici, abbiamo dovuto affrontare diverse sfide dal punto di vista dello sviluppo. In primo luogo, un aumento del carico stesso. È chiaro che, se non vengono adottate le misure necessarie, un sistema sottoposto a un carico elevato può trasformarsi in una zucca con un triste tonfo, oppure degradare completamente in termini di prestazioni, o addirittura perdere la propria operatività.
Il secondo aspetto, un po' meno ovvio, è che il sistema sotto carico elevato doveva essere modificato molto rapidamente, adattandosi ai cambiamenti dei processi aziendali. A volte più volte al giorno. Molte aziende hanno la regola che durante grandi attività di marketing non si dovrebbero apportare modifiche al sistema. Nessuna modifica, lasciatelo funzionare, dato che funziona.
Per noi, in pratica, c'era un venerdì nero infinito, durante il quale era comunque necessario modificare il sistema. Qualsiasi errore, problema, guasto nel sistema avrebbe avuto un costo molto elevato per l'azienda.
Anticipando, posso dire che siamo riusciti a far fronte a queste sfide, tutti i sistemi hanno sostenuto il carico, si sono scalati facilmente e non abbiamo avuto grandi guasti tecnici.
Esistono quattro pilastri su cui si basa la capacità del sistema di sostenere carichi elevati e istantanei. Il primo è il monitoraggio, di cui hai letto poco sopra. Senza un sistema di monitoraggio ben strutturato, è praticamente impossibile individuare i colli di bottiglia del sistema. Un buon sistema di monitoraggio è come un abito comodo, deve essere pratico e adattato a te.
Il secondo aspetto è il testing. Prendiamo molto sul serio questo punto: scriviamo unit test classici, test di integrazione, test di carico e molti altri per ogni sistema. Inoltre, scriviamo una strategia di testing e ci sforziamo di portare il livello di testing a un punto in cui non siano più necessarie le verifiche manuali.
Il terzo pilastro è il CI/CD Pipeline. I processi di build, testing e deployment dell'applicazione devono essere massimamente automatizzati, senza interventi manuali. Il tema del CI/CD Pipeline è piuttosto ampio, e lo toccherò solo brevemente. Va detto che abbiamo una checklist per il CI/CD Pipeline, secondo la quale ogni team di prodotto esamina con l'aiuto dei centri di competenza.
Ecco la checklist
In questo modo si raggiungono molti obiettivi. Questo include la versioning dell'API, e il feature toggle per evitare il treno delle release, e il raggiungimento di una copertura test tale da rendere il testing completamente automatizzato, con deployment senza soluzione di continuità, e altro ancora.
Il quarto pilastro sono i principi architettonici e le soluzioni tecniche. Si può parlare a lungo di architettura, ma voglio sottolineare un paio di principi sui quali vorrei attirare l'attenzione.
In primo luogo, è necessario scegliere strumenti specializzati per compiti specifici. Sì, sembra ovvio e è chiaro che è meglio usare un martello per piantare chiodi e cacciaviti speciali per smontare orologi. Ma nella nostra epoca, molti strumenti tendono a diventare universali, per coprire il massimo segmento di utenti: database, cache, framework e altro ancora. Ad esempio, se prendiamo il database MongoDB, esso funziona con transazioni multi-documento, mentre il database Oracle gestisce i JSON. E sembrerebbe che tutto possa essere usato per tutto. Ma se ci battiamo per le prestazioni, dobbiamo avere una chiara comprensione dei punti di forza e di debolezza di ciascun strumento e utilizzare quelli necessari per la nostra categoria di compiti.
In secondo luogo, quando si progettano sistemi, ogni aumento di complessità deve essere motivato. Dobbiamo tenerlo presente, il principio del low coupling è ben noto. Credo che debba essere applicato sia a livello di servizio specifico, sia a livello dell'intero sistema, sia a livello del paesaggio architettonico. È anche importante la capacità di scalare orizzontalmente ogni componente del sistema sotto carico. Possedere questa capacità rende lo scaling un compito semplice.
Parlando di soluzioni tecniche, abbiamo chiesto ai team di prodotto di preparare un nuovo insieme di raccomandazioni, idee e soluzioni che hanno realizzato nel processo di preparazione per l'ennesima ondata di carico.
Cache
È necessario approcciarsi alla scelta delle cache locali e distribuite in modo consapevole. A volte ha senso utilizzare entrambe all'interno di un unico sistema. Ad esempio, abbiamo sistemi in cui parte dei dati è essenzialmente una cache di vetrina, quindi la fonte degli aggiornamenti si trova al di fuori del sistema stesso e questi dati non vengono modificati. Per questo approccio utilizziamo la cache locale Caffeine.
Ci sono anche dati che il sistema modifica attivamente durante il funzionamento, e in questo caso utilizziamo una cache distribuita con Hazelcast. Questo approccio ci consente di sfruttare i vantaggi della cache distribuita dove è realmente necessaria, e di minimizzare i costi di servizio per la circolazione dei dati nel cluster Hazelcast dove possiamo evitarlo. Abbiamo scritto molto sulle cache. e .
Inoltre, il cambio del serializzatore in Kryo in Hazelcast ci ha fornito un buon guadagno. La transizione da ReplicatedMap a IMap + Near Cache in Hazelcast ci ha permesso di ridurre al minimo il movimento dei dati nel cluster.
Un piccolo consiglio: durante l'invalidazione massiva della cache, a volte è utile adottare la strategia di riscaldare una seconda cache da cui poi passare. A prima vista, con questo approccio dovremmo avere un doppio consumo di memoria, ma nella pratica, nei sistemi dove è stato applicato, il consumo di memoria è diminuito.
Stack reattivo
Utilizziamo lo stack reattivo in un numero già considerevole di sistemi. Nel nostro caso si tratta di Webflux o Kotlin con coroutine. Lo stack reattivo è particolarmente efficace dove ci aspettiamo operazioni di input-output lente. Ad esempio, nelle chiamate a servizi lenti, nel lavoro con il filesystem o nei sistemi di archiviazione.
Il principio più importante è evitare le chiamate bloccanti. Sotto il cofano degli framework reattivi ci sono un numero limitato di thread di servizio attivi. Se non stiamo attenti e facciamo una chiamata bloccante diretta, come nel caso di una chiamata al driver JDBC, il sistema semplicemente si fermerà.
Cercate di convertire gli errori in eccezioni runtime personalizzate. Il flusso reale dell'esecuzione del programma si sposta verso gli framework reattivi, e l'esecuzione del codice diventa non lineare. Di conseguenza, è molto difficile diagnosticare problemi basandosi sugli stack trace. La soluzione qui è creare eccezioni runtime obiettive e chiare per ogni errore.
Elasticsearch
Quando si utilizza Elasticsearch, evitare di selezionare dati non utilizzati. È un consiglio piuttosto semplice, ma spesso viene dimenticato. Se è necessario selezionare più di 10.000 record in una volta, bisogna utilizzare Scroll. In un certo senso, è un po' simile a un cursore in un database relazionale.
Non utilizzare postfilter senza necessità. Con grandi quantità di dati nel set principale, questa operazione grava notevolmente sul database.
Utilizzare operazioni bulk dove applicabile.
API
Quando si progetta l'API, considerare i requisiti per minimizzare i dati trasferiti. Questo è particolarmente rilevante per l'interazione con il frontend: proprio in quel punto superiamo i canali dei nostri data center e operiamo su quel canale che ci collega al cliente. Se ci sono anche solo piccoli problemi su quel canale, un traffico eccessivo genera un'esperienza utente negativa.
E, infine, non presentate una montagna di dati, concentratevi chiaramente sul contratto tra consumatori e fornitori.
Trasformazione organizzativa
Eroshkina Elena, Vice Direttore IT
Nel momento in cui è iniziato il lockdown e c'è stata la necessità di aumentare rapidamente il ritmo dello sviluppo online e di implementare servizi omnicanale, eravamo già nel processo di trasformazione organizzativa.
Una parte della nostra struttura è stata trasferita a lavorare secondo principi e pratiche di approccio ai prodotti. Sono stati formati team che ora sono responsabili del funzionamento e dello sviluppo di ogni prodotto. I membri di questi team sono coinvolti al 100% e organizzano il loro lavoro secondo Scrum o Kanban, a seconda di ciò che preferiscono, impostano la pipeline di distribuzione, implementano pratiche tecniche, pratiche di assicurazione della qualità e molto altro.
Per una felice coincidenza, la maggior parte di questi team di prodotto si trovava proprio nell'ambito dei servizi online e omnicanale. Questo ci ha permesso di passare rapidamente (seriamente, letteralmente in due giorni) alla modalità di lavoro da remoto senza perdere efficienza. Il processo strutturato ci ha permesso di adattarci rapidamente alle nuove condizioni lavorative e di mantenere un ritmo elevato nella fornitura di nuove funzionalità.
Inoltre, è emersa la necessità di rafforzare quei team che operano nella frontiera del business online. In quel momento è diventato chiaro che potevamo farlo solo grazie alle risorse interne. Circa 50 persone hanno cambiato area di lavoro in due settimane e si sono integrate nel lavoro su un nuovo prodotto per loro.
Per questo non è stato necessario alcuno sforzo gestionale speciale, poiché insieme all'organizzazione del proprio processo, al perfezionamento tecnico del prodotto, alla pratica di assicurazione della qualità, insegniamo ai nostri team l'autoorganizzazione — gestire il proprio processo produttivo senza ricorrere a risorse amministrative.
Siamo riusciti a concentrare le risorse di gestione proprio dove era necessario in quel momento, ovvero nella coordinazione con il business: cosa è attualmente importante per il nostro cliente, quale funzionalità deve essere realizzata per prima, cosa dobbiamo fare per aumentare la nostra capacità di consegna e elaborazione degli ordini. Tutto questo, insieme a un modello di ruolo chiaro, ci ha permesso in questo periodo di caricare i nostri flussi produttivi di creazione di valore con ciò che è veramente importante e necessario.
È chiaro che, con il lavoro a distanza e l'elevato ritmo di cambiamenti, quando le prestazioni aziendali dipendono dalla partecipazione di ciascuno, non è possibile fare affidamento solo sulle sensazioni interne come «Va tutto bene? Sì, sembra di sì». Sono necessarie metriche oggettive del processo produttivo. Le abbiamo, sono accessibili a chiunque sia interessato alle metriche dei team di prodotto. Prima di tutto al team stesso, al business, ai partner e alla direzione.
Ogni due settimane si tiene un incontro di stato con ciascun team, durante il quale si analizzano per 10 minuti le metriche, si identificano i colli di bottiglia del processo produttivo e si trova una soluzione congiunta: cosa si può fare per eliminare questi colli di bottiglia. Qui si può anche chiedere immediatamente aiuto alla direzione nel caso in cui qualche problema identificato sia al di fuori dell'area di influenza dei team, o delle competenze dei colleghi che, forse, hanno già affrontato un problema simile.
Tuttavia, comprendiamo che per un'accelerazione esponenziale (ed è proprio questo l'obiettivo che ci poniamo) dobbiamo ancora imparare molto e implementare nella nostra routine quotidiana. Proprio ora stiamo continuando a scalare l'approccio prodotto ad altri team e a nuovi prodotti. Per questo abbiamo dovuto acquisire un nuovo formato per noi: la scuola online per metodologi.
I metodologi, le persone che aiutano i team a costruire processi, migliorare le comunicazioni e aumentare l'efficienza del lavoro, sono essenzialmente agenti di cambiamento. Proprio ora i laureati del nostro primo gruppo stanno lavorando con i team e aiutandoli a diventare di successo.
Credo che la situazione attuale ci offra opportunità e prospettive che forse non abbiamo ancora del tutto compreso. Ma l'esperienza e la pratica che stiamo acquisendo in questo momento confermano che abbiamo scelto la strada giusta per lo sviluppo, non perderemo in futuro queste nuove opportunità e saremo anche in grado di rispondere in modo efficace alle sfide che si presenteranno di fronte a «Sportmaster».
Conclusioni
In questo periodo difficile abbiamo formulato i principi fondamentali su cui si basa lo sviluppo del software, che credo saranno pertinenti per ogni azienda che opera in questo settore.
Le persone. Questo è ciò su cui si basa tutto. I dipendenti devono trarre soddisfazione dal lavoro, comprendere gli obiettivi dell'azienda e quelli dei prodotti di cui si occupano. E, naturalmente, devono poter crescere professionalmente.
Tecnologia. È necessario che l'azienda si approcci alla gestione del proprio stack tecnologico in modo maturo e accresca le competenze dove è veramente necessario. Sembra molto semplice e ovvio. E molto spesso viene ignorato.
Processi. È importante organizzare correttamente il lavoro dei team di prodotto e dei centri di competenze, stabilire una collaborazione con il business per lavorare con esso come con un partner.
In generale, è più o meno così che abbiamo sopravvissuto. Il principale aforisma della modernità si è confermato ancora una volta, colpendo sonoramente in fronte.
Anche se sei un enorme business offline con moltissimi negozi e una miriade di città in cui sei presente, sviluppa il tuo online. Non è solo un canale di vendita aggiuntivo o una bella applicazione tramite la quale comprare qualcosa (anche per il fatto che anche i concorrenti hanno applicazioni belle). Non è una ruota di scorta da usare in caso di necessità, capace di aiutarti a superare la tempesta.
È una vera necessità. Alla quale non devono essere pronti solo le tue capacità tecniche e l'infrastruttura, ma anche le persone e i processi. Infatti, acquistare velocemente memoria, spazio, avviare nuove istanze e altro si può fare in poche ore. Ma le persone e i processi devono essere preparati in anticipo per questo.
Fonte: habr.com
