Hi!
Mi chiamo Mikhail, sono il vicedirettore IT della società Sportmaster. Voglio condividere la storia di come abbiamo affrontato le sfide emerse durante la pandemia.
Nei primi giorni delle nuove realtà, il consueto formato di trading offline di Sportmaster si è bloccato e il carico sul nostro canale online, principalmente in termini di consegna all'indirizzo del cliente, è aumentato di 10 volte. In poche settimane abbiamo trasformato un gigantesco business offline in online e abbiamo adattato il servizio alle esigenze dei nostri clienti.
Fondamentalmente, quella che essenzialmente era la nostra attività secondaria è diventata il nostro core business. L'importanza di ogni ordine online è aumentata estremamente. Era necessario risparmiare ogni rublo che il cliente ha portato in azienda.
Per rispondere velocemente alle richieste dei clienti, abbiamo aperto un ulteriore contact center presso la sede principale dell'azienda, e oggi possiamo ricevere circa 285mila chiamate a settimana. Allo stesso tempo, abbiamo trasferito 270 negozi in un nuovo formato operativo contactless e sicuro, che ha consentito ai clienti di ricevere gli ordini e ai dipendenti di mantenere il proprio posto di lavoro.
Durante il processo di trasformazione, abbiamo riscontrato due problemi principali. In primo luogo, il carico sulle nostre risorse online è aumentato in modo significativo (Sergey ti dirà come abbiamo affrontato questo problema). In secondo luogo, il flusso di operazioni rare (pre-COVID) è aumentato molte volte, il che a sua volta ha richiesto una grande quantità di rapida automazione. Per risolvere questo problema abbiamo dovuto trasferire rapidamente risorse da aree che prima erano quelle principali. Elena ti racconterà come abbiamo affrontato questa situazione.
Funzionamento dei servizi on-line
Kolesnikov Sergey, responsabile del funzionamento del negozio online e dei microservizi
Dal momento in cui i nostri negozi al dettaglio hanno iniziato a chiudere ai visitatori, abbiamo iniziato a registrare un aumento di parametri 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 marzo al 31 marzoNumero di richieste ai microservizi di pagamento onlineNumero di ordini effettuati sul sito web
Nel primo grafico vediamo che l'aumento è stato di circa 14 volte, nel secondo di 4 volte. Riteniamo che la metrica del tempo di risposta delle nostre applicazioni sia la più indicativa.
In questo grafico vediamo la risposta dei fronti e delle applicazioni, e noi stessi abbiamo constatato di non aver notato alcuna crescita in quanto tale.
Ciò è dovuto principalmente al fatto che abbiamo iniziato i lavori preparatori alla fine del 2019. Ora i nostri servizi sono riservati, la tolleranza agli errori è garantita a livello di server fisici, sistemi di virtualizzazione, docker e servizi in essi contenuti. Allo stesso tempo, la capacità delle nostre risorse server ci consente di sopportare più carichi.
Lo strumento principale che ci ha aiutato in tutta questa storia è stato il nostro sistema di monitoraggio. È vero, fino a poco tempo fa non disponevamo di un unico sistema che ci permettesse di raccogliere parametri a tutti i livelli, dal livello delle apparecchiature fisiche e dell’hardware al livello dei parametri aziendali.
Formalmente il monitoraggio era presente in azienda, ma di norma era disperso e rientrava nell'area di responsabilità di reparti specifici. Infatti, quando si verificava un incidente, non avevamo quasi mai una comprensione comune di ciò che era successo esattamente, non c’era comunicazione e spesso questo portava a correre in tondo per trovare e isolare il problema in modo che potesse essere risolto.
Ad un certo punto, abbiamo pensato e deciso che ne avevamo abbastanza di sopportare tutto questo: avevamo bisogno di un sistema unificato per vedere l'intero quadro nella sua interezza. Le principali tecnologie incluse nel nostro stack sono Zabbix come centro di avviso e archiviazione delle metriche, Prometheus per la raccolta e l'archiviazione delle metriche dell'applicazione, Stack ELK per la registrazione e l'archiviazione dei dati dall'intero sistema di monitoraggio, nonché Grafana per la visualizzazione, Swagger, Docker e altre cose utili e che ti sono familiari.
Allo stesso tempo, non solo utilizziamo le tecnologie disponibili sul mercato, ma ne sviluppiamo anche alcune nostre. Ad esempio, realizziamo servizi per l'integrazione dei sistemi tra loro, ovvero una sorta di API per la raccolta di parametri. Inoltre stiamo lavorando sui nostri sistemi di monitoraggio: a livello di metriche aziendali utilizziamo test dell'interfaccia utente. E anche un bot in Telegram per avvisare i team.
Stiamo anche cercando di rendere il sistema di monitoraggio accessibile ai team in modo che possano archiviare e lavorare in modo indipendente con i propri parametri, inclusa l'impostazione di avvisi per alcuni parametri ristretti che non sono ampiamente utilizzati.
In tutto il sistema, ci impegniamo a garantire la proattività e la localizzazione degli incidenti il più rapidamente possibile. Inoltre, negli ultimi tempi il numero dei nostri microservizi e sistemi è cresciuto notevolmente e di conseguenza anche il numero delle integrazioni. E come parte dell'ottimizzazione del processo di diagnosi degli incidenti a livello di integrazione, stiamo sviluppando un sistema che consente di effettuare controlli intersistemici e visualizzare il risultato, che consente di trovare i principali problemi associati alle importazioni e all'interazione dei sistemi con l'un l'altro.
Naturalmente abbiamo ancora spazio per crescere e svilupparci in termini di sistemi operativi e stiamo lavorando attivamente su questo. Puoi leggere ulteriori informazioni sul nostro sistema di monitoraggio .
Prove tecniche
Orlov Sergey, dirige il centro di competenza per lo sviluppo web e mobile
Da quando sono iniziate le chiusure dei negozi fisici, abbiamo dovuto affrontare diverse sfide dal punto di vista dello sviluppo. Prima di tutto, l'aumento del carico in quanto tale. È chiaro che se non vengono prese le misure appropriate, quando viene applicato un carico elevato al sistema, può trasformarsi in una zucca con un botto triste, o degradare completamente le prestazioni o addirittura perdere la sua funzionalità.
Il secondo aspetto, un po’ meno evidente, è che il sistema sotto carico elevato doveva essere modificato molto velocemente, adattandosi ai cambiamenti dei processi aziendali. A volte più volte al giorno. Molte aziende hanno una regola secondo cui se c'è molta attività di marketing, non è necessario apportare modifiche al sistema. Niente affatto, lasciamo che funzioni finché funziona.
E in sostanza abbiamo avuto un Black Friday senza fine, durante il quale è stato necessario cambiare il sistema. E qualsiasi errore, problema o guasto nel sistema sarebbe molto costoso per l’azienda.
Guardando al futuro, dirò che siamo riusciti a far fronte a questi test, tutti i sistemi hanno resistito al carico, sono stati facilmente scalabili e non abbiamo riscontrato alcun guasto tecnico globale.
Ci sono quattro pilastri su cui poggia la capacità del sistema di resistere a carichi di picco elevati. Il primo di questi è il monitoraggio, di cui hai letto poco sopra. Senza un sistema di monitoraggio integrato è quasi impossibile individuare i colli di bottiglia del sistema. Un buon sistema di monitoraggio è come i vestiti per la casa: dovrebbe essere comodo e su misura per te.
Il secondo aspetto è la sperimentazione. Prendiamo molto sul serio questo punto: scriviamo unità classiche, test di integrazione, test di carico e molti altri per ogni sistema. Stiamo anche scrivendo una strategia di test e allo stesso tempo cercando di aumentare il livello dei test al punto da non aver più bisogno di controlli manuali.
Il terzo pilastro è CI/CD Pipeline. I processi di creazione, test e distribuzione di un'applicazione dovrebbero essere automatizzati il più possibile; non dovrebbe essere previsto alcun intervento manuale. L'argomento CI/CD Pipeline è piuttosto profondo e lo toccherò solo brevemente. Vale solo la pena ricordare che disponiamo di una lista di controllo della pipeline CI/CD, che ogni team di prodotto esegue con l'aiuto dei centri di competenza.
Ed ecco la lista di controllo
In questo modo si raggiungono molti obiettivi. Si tratta del controllo delle versioni dell'API e dell'attivazione/disattivazione delle funzionalità per evitare il treno di rilasci e ottenere la copertura di vari test a un livello tale che i test siano completamente automatizzati, le distribuzioni siano senza interruzioni e così via.
Il quarto pilastro sono i principi architettonici e le soluzioni tecniche. Di architettura si può parlare molto a lungo, ma voglio sottolineare un paio di principi su cui vorrei soffermarmi.
Innanzitutto, devi scegliere strumenti specializzati per compiti specifici. Sì, sembra ovvio, ed è chiaro che i chiodi dovrebbero essere piantati con un martello e gli orologi da polso dovrebbero essere smontati con cacciaviti speciali. Ma nella nostra epoca, molti strumenti puntano all'universalizzazione per coprire il segmento massimo di utenti: database, cache, framework e tutto il resto. Ad esempio, se prendi il database MongoDB, funziona con transazioni multi-documento e il database Oracle funziona con json. E sembrerebbe che tutto possa essere usato per tutto. Ma se puntiamo alla produttività, allora dobbiamo comprendere chiaramente i punti di forza e di debolezza di ciascuno strumento e utilizzare quelli di cui abbiamo bisogno per la nostra classe di compiti.
In secondo luogo, quando si progettano i sistemi, ogni aumento di complessità deve essere giustificato. Dobbiamo tenerlo costantemente presente; il principio del basso accoppiamento è noto a tutti. Credo che dovrebbe essere applicato a livello di un servizio specifico, a livello dell'intero sistema e a livello del paesaggio architettonico. È importante anche la capacità di scalare orizzontalmente ciascun componente del sistema lungo il percorso di carico. Se hai questa capacità, il ridimensionamento non sarà difficile.
Parlando di soluzioni tecniche, abbiamo chiesto ai team di prodotto di preparare una nuova serie di raccomandazioni, idee e soluzioni, che avrebbero implementato in preparazione alla successiva ondata di carico di lavoro.
Keshi
È necessario avvicinarsi consapevolmente alla scelta delle cache locali e distribuite. A volte ha senso utilizzarli entrambi all'interno dello stesso sistema. Ad esempio, abbiamo sistemi in cui alcuni dati sono essenzialmente una cache vetrina, ovvero la fonte degli aggiornamenti si trova dietro il sistema stesso e i sistemi non cambiano questi dati. Per questo approccio utilizziamo la Caffeine Cache locale.
E ci sono dati che il sistema cambia attivamente durante il funzionamento, e qui stiamo già utilizzando una cache distribuita con Hazelcast. Questo approccio ci consente di sfruttare i vantaggi di una cache distribuita dove sono realmente necessari e di ridurre al minimo i costi del servizio di circolazione dei dati del cluster Hazelcast dove possiamo farne a meno. Abbiamo scritto molto sulle cache. и .
Inoltre, cambiare il serializzatore in Kryo in Hazelcast ci ha dato una bella spinta. E la transizione da ReplicatedMap a IMap + Near Cache in Hazelcast ci ha permesso di ridurre al minimo lo spostamento dei dati nel cluster.
Un piccolo consiglio: in caso di invalidazione di massa della cache, a volte è applicabile la tattica di riscaldare la seconda cache e poi passare ad essa. Sembrerebbe che con questo approccio dovremmo ottenere un consumo di memoria doppio, ma in pratica, in quei sistemi in cui ciò veniva praticato, il consumo di memoria è diminuito.
Pila reattiva
Usiamo lo stack reattivo in un numero piuttosto elevato di sistemi. Nel nostro caso si tratta di Webflux o Kotlin con coroutine. Lo stack reattivo è particolarmente buono laddove ci aspettiamo operazioni di input-output lente. Ad esempio, chiamate a servizi lenti, che lavorano con il file system o i sistemi di archiviazione.
Il principio più importante è evitare di bloccare le chiamate. I framework reattivi hanno un numero limitato di thread di servizi live in esecuzione sotto il cofano. Se incautamente permettiamo a noi stessi di effettuare una chiamata di blocco diretto, come una chiamata dell'autista JDBC, il sistema semplicemente si fermerà.
Prova a trasformare gli errori nella tua eccezione di runtime. Il flusso effettivo di esecuzione del programma si sposta verso framework reattivi e l'esecuzione del codice diventa non lineare. Di conseguenza, è molto difficile diagnosticare i problemi utilizzando le analisi dello stack. E la soluzione in questo caso sarebbe creare eccezioni di runtime chiare e oggettive per ogni errore.
elasticsearch
Quando si utilizza Elasticsearch, non selezionare dati inutilizzati. Questo, in linea di principio, è anche un consiglio molto semplice, ma molto spesso è ciò che viene dimenticato. Se è necessario selezionare più di 10mila record alla volta, è necessario utilizzare Scorri. Per usare un'analogia, è un po' come un cursore in un database relazionale.
Non utilizzare il postfiltro se non necessario. Con dati di grandi dimensioni nell'esempio principale, questa operazione carica notevolmente il database.
Utilizzare le operazioni collettive ove applicabile.
API
Quando si progetta un'API, includere i requisiti per ridurre al minimo i dati trasmessi. Ciò è particolarmente vero in relazione al fronte: è a questo bivio che andiamo oltre i canali dei nostri data center e stiamo già lavorando sul canale che ci collega con il cliente. Se presenta il minimo problema, troppo traffico provoca un'esperienza utente negativa.
E infine, non buttare via un sacco di dati, sii chiaro riguardo al contratto tra consumatori e fornitori.
Trasformazione organizzativa
Eroshkina Elena, vicedirettore per l'IT
Nel momento in cui è avvenuta la quarantena ed è emersa la necessità di aumentare drasticamente il ritmo dello sviluppo online e introdurre servizi omnicanale, eravamo già in fase di trasformazione organizzativa.
Parte della nostra struttura è stata trasferita per lavorare secondo i principi e le pratiche dell'approccio al prodotto. Sono stati formati team che ora sono responsabili del funzionamento e dello sviluppo di ciascun prodotto. I dipendenti di questi team sono coinvolti al 100% e strutturano il proprio lavoro utilizzando Scrum o Kanban, a seconda di ciò che preferiscono, impostando una pipeline di distribuzione, implementando pratiche tecniche, pratiche di garanzia della qualità e molto altro.
Per fortuna, la maggior parte dei nostri team di prodotto operava nel settore dei servizi online e omnicanale. Questo ci ha permesso di passare alla modalità di lavoro da remoto nel più breve tempo possibile (sul serio, letteralmente in due giorni) senza perdita di efficienza. Il processo personalizzato ci ha permesso di adattarci rapidamente alle nuove condizioni di lavoro e di mantenere un ritmo abbastanza elevato nella fornitura di nuove funzionalità.
Inoltre, abbiamo la necessità di rafforzare quei team che si trovano alla frontiera del business online. In quel momento è diventato chiaro che avremmo potuto farlo solo utilizzando risorse interne. E circa 50 persone in due settimane hanno cambiato l'area in cui lavoravano prima e si sono lasciate coinvolgere nella lavorazione di un prodotto per loro nuovo.
Ciò non ha richiesto particolari sforzi di gestione, perché oltre all'organizzazione del nostro processo, al miglioramento tecnico del prodotto e alle pratiche di garanzia della qualità, insegniamo ai nostri team ad auto-organizzarsi, a gestire il proprio processo di produzione senza coinvolgere risorse amministrative.
Siamo stati in grado di concentrare le nostre risorse di gestione esattamente dove era necessario in quel momento - sul coordinamento insieme all'azienda: cosa è importante per il nostro cliente in questo momento, quale funzionalità dovrebbe essere implementata per prima, cosa è necessario fare per aumentare la nostra capacità di rendimento per consegnare ed elaborare gli ordini. Tutto questo e un chiaro modello di ruolo hanno permesso durante questo periodo di caricare i nostri flussi di valore della produzione con ciò che è veramente importante e necessario.
È chiaro che con il lavoro a distanza e un ritmo elevato di cambiamento, quando gli indicatori aziendali dipendono dalla partecipazione di tutti, non si può fare affidamento solo sui sentimenti interni della serie “Sta andando tutto bene con noi? Sì, sembra buono." Sono necessarie metriche oggettive del processo produttivo. Li abbiamo, sono disponibili per chiunque sia interessato alle metriche dei team di prodotto. Innanzitutto il team stesso, l'azienda, i subappaltatori e il management.
Una volta ogni due settimane, viene tenuto uno stato con ciascun team, in cui i parametri vengono analizzati per 10 minuti, vengono identificati i colli di bottiglia nel processo di produzione e viene sviluppata una soluzione congiunta: cosa si può fare per eliminare questi colli di bottiglia. Qui puoi chiedere immediatamente aiuto alla direzione se qualche problema identificato è al di fuori della zona di influenza dei team o della competenza dei colleghi che potrebbero aver già riscontrato un problema simile.
Tuttavia, comprendiamo che per accelerare più volte (e questo è esattamente l'obiettivo che ci siamo prefissati), dobbiamo ancora imparare molto e implementarlo nel nostro lavoro quotidiano. In questo momento stiamo continuando ad adattare il nostro approccio al prodotto ad altri team e nuovi prodotti. Per fare ciò, abbiamo dovuto padroneggiare un nuovo formato per noi: una scuola online di metodologi.
I metodologi, le persone che aiutano i team a costruire un processo, stabilire comunicazioni e migliorare l’efficienza del lavoro, sono essenzialmente agenti di cambiamento. In questo momento, i laureati del nostro primo gruppo lavorano con i team e li aiutano ad avere successo.
Penso che la situazione attuale ci apra opportunità e prospettive di cui forse noi stessi non siamo ancora pienamente consapevoli. Ma l’esperienza e la pratica che stiamo maturando in questo momento conferma che abbiamo scelto la giusta strada di sviluppo, non perderemo queste nuove opportunità in futuro e saremo in grado di rispondere altrettanto efficacemente alle sfide che Sportmaster dovrà affrontare.
risultati
Durante questo momento difficile, abbiamo formulato i principi fondamentali su cui si basa lo sviluppo del software, che, credo, saranno rilevanti per ogni azienda che si occupa di questo.
Persone. Questo è ciò su cui poggia tutto. I dipendenti devono apprezzare il proprio lavoro e comprendere gli obiettivi dell'azienda e quelli dei prodotti su cui lavorano. E, naturalmente, potrebbero svilupparsi professionalmente.
Технология. È necessario che l’azienda adotti un approccio maturo nel lavorare con il proprio stack tecnologico e sviluppare competenze dove è realmente necessario. Sembra molto semplice e ovvio. E molto spesso ignorato.
processi. È importante organizzare adeguatamente il lavoro dei team di prodotto e dei centri di competenza, stabilire un'interazione con l'azienda per lavorare con essa come partner.
In generale, è più o meno così che siamo sopravvissuti. La tesi principale del nostro tempo è stata confermata ancora una volta, con un sonoro clic sulla fronte
Anche se hai una grande azienda offline con molti negozi e molte città in cui operi, sviluppa il tuo business online. Questo non è solo un canale di vendita aggiuntivo o una bella applicazione attraverso la quale puoi anche comprare qualcosa (e anche perché anche i concorrenti ne hanno di belli). Questa non è una ruota di scorta per ogni evenienza per aiutarti a superare la tempesta.
Questa è una necessità assoluta. Per questo non devono essere preparate solo le vostre capacità tecniche e la vostra infrastruttura, ma anche il vostro personale e i vostri processi. Dopotutto, puoi acquistare rapidamente memoria aggiuntiva, spazio, distribuire nuove istanze, ecc. in un paio d'ore. Ma le persone e i processi devono essere preparati in anticipo.
Fonte: habr.com