{"id":94520,"date":"2020-09-18T07:42:20","date_gmt":"2020-09-18T05:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah"},"modified":"2020-09-18T07:42:20","modified_gmt":"2020-09-18T05:42:20","slug":"chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","title":{"rendered":"Cosa ci ha aiutato a adattarci rapidamente al commercio online in nuove condizioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao!<\/p>\n

Mi chiamo Mikhail, sono il vice direttore IT di Sportmaster. Volevo condividere una storia su come abbiamo affrontato le difficolt\u00e0 emerse durante la pandemia.<\/p>\n

Nei primi giorni della nuova realt\u00e0, il formato abituale del commercio offline di Sportmaster si \u00e8 fermato, e il carico sul nostro canale online, in particolare per quanto riguarda le consegne a domicilio, \u00e8 aumentato di 10 volte. In poche settimane abbiamo trasformato un gigantesco business offline in un online, adattando il servizio alle esigenze dei nostri clienti.<\/p>\n

In sostanza, ci\u00f2 che era una nostra operazione secondaria \u00e8 diventato il business principale. L'importanza di ogni ordine online \u00e8 aumentata in modo estremo. Dovevamo preservare ogni rublo che il cliente portava in azienda. <\/p>\n

\"Cosa<\/p>\n

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.<\/p>\n

Durante il processo di trasformazione, abbiamo affrontato due principali problemi. Innanzitutto, il carico sui nostri risorse online \u00e8 aumentato notevolmente (Sergio spiegher\u00e0 come abbiamo affrontato questo problema). Secondariamente, il flusso di operazioni rare (fino al COVID) \u00e8 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 \u2014 lo racconter\u00e0 Elena.<\/p>\n

Servizi online<\/h2>\n

Sergej Kolesnikov, responsabile dell'operativit\u00e0 del negozio online e dei microservizi<\/em><\/p>\n

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. <\/p>\n

\"CosaNumero di ordini dal 18 al 31 marzo\"CosaNumero di richieste ai microservizi di pagamento online\"CosaNumero di ordini effettuati sul sito<\/p>\n

Nel primo grafico vediamo che l'aumento \u00e8 stato di circa 14 volte, nel secondo \u2014 4 volte. Riteniamo che la metrica pi\u00f9 indicativa in questo caso sia quella del tempo di risposta delle nostre applicazioni. <\/p>\n

\"Cosa<\/p>\n

In questo grafico vediamo la risposta dei fronti e delle applicazioni, e ci siamo resi conto che non abbiamo notato alcuna crescita significativa.<\/p>\n

In primo luogo, ci\u00f2 \u00e8 dovuto al fatto che abbiamo iniziato i lavori preparatori alla fine del 2019. Ora i nostri servizi sono riservati, \u00e8 stata garantita la resilienza a livello di server fisici, sistemi di virtualizzazione, Docker e servizi in essi. Inoltre, le capacit\u00e0 delle nostre risorse server ci consentono di affrontare carichi multipli.<\/p>\n

Lo strumento principale che ci ha aiutato in tutta questa storia \u00e8 stato il nostro sistema di monitoraggio. In verit\u00e0, 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. <\/p>\n

Formalmente, c'era un monitoraggio in azienda, ma di solito era disperso ed era sotto la responsabilit\u00e0 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Cerchiamo anche di rendere il sistema di monitoraggio accessibile ai team, affinch\u00e9 possano archiviare autonomamente le proprie metriche e lavorarci, incluso configurare allerta su metriche specifiche che non hanno un'applicazione troppo ampia. <\/p>\n

Nell'ambito del sistema, puntiamo alla proattivit\u00e0 e alla localizzazione rapida degli incidenti. Inoltre, il numero dei nostri microservizi e sistemi \u00e8 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. <\/p>\n

Naturalmente, abbiamo ancora molto da fare e da sviluppare per quanto riguarda l'operativit\u00e0 dei sistemi, e stiamo lavorando attivamente in tal senso. Maggiori dettagli sul nostro sistema di monitoraggio possono essere letti qui<\/u><\/a><\/noindex>. <\/p>\n

Collaudi tecnici <\/h2>\n

Sergei Orlov, dirige il centro di competenza per lo sviluppo web e mobile<\/em><\/p>\n

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. \u00c8 chiaro che, se non vengono adottate le misure necessarie, un sistema sottoposto a un carico elevato pu\u00f2 trasformarsi in una zucca con un triste tonfo, oppure degradare completamente in termini di prestazioni, o addirittura perdere la propria operativit\u00e0.<\/p>\n

Il secondo aspetto, un po' meno ovvio, \u00e8 che il sistema sotto carico elevato doveva essere modificato molto rapidamente, adattandosi ai cambiamenti dei processi aziendali. A volte pi\u00f9 volte al giorno. Molte aziende hanno la regola che durante grandi attivit\u00e0 di marketing non si dovrebbero apportare modifiche al sistema. Nessuna modifica, lasciatelo funzionare, dato che funziona.<\/p>\n

Per noi, in pratica, c'era un venerd\u00ec 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.<\/p>\n

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.<\/p>\n

Ci sono quattro pilastri su cui si basa la capacit\u00e0 del sistema di gestire carichi di lavoro elevati. Il primo di essi \u00e8 il monitoraggio, di cui hai letto sopra. Senza un sistema di monitoraggio ben strutturato, \u00e8 praticamente impossibile individuare i punti deboli del sistema. Un buon sistema di monitoraggio \u00e8 come un abbigliamento comodo, deve essere conveniente e adattato a te.<\/p>\n

Il secondo aspetto \u00e8 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\u00f9 necessarie le verifiche manuali.<\/p>\n

Il terzo pilastro \u00e8 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 \u00e8 piuttosto ampio, e lo toccher\u00f2 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.<\/p>\n

\"CosaEcco la checklist<\/p>\n

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\u00e0, e altro ancora.<\/p>\n

Il quarto pilastro sono i principi architettonici e le soluzioni tecniche. Si pu\u00f2 parlare a lungo di architettura, ma voglio sottolineare un paio di principi sui quali vorrei attirare l'attenzione.<\/p>\n

In primo luogo, \u00e8 necessario scegliere strumenti specializzati per compiti specifici. S\u00ec, sembra ovvio e \u00e8 chiaro che \u00e8 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. <\/p>\n

In secondo luogo, quando si progettano sistemi, ogni aumento di complessit\u00e0 deve essere motivato. Dobbiamo tenerlo presente, il principio del low coupling \u00e8 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. \u00c8 anche importante la capacit\u00e0 di scalare orizzontalmente ogni componente del sistema sotto carico. Possedere questa capacit\u00e0 rende lo scaling un compito semplice.<\/p>\n

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.<\/p>\n

Cache<\/h2>\n

\u00c8 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 \u00e8 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. <\/p>\n

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 \u00e8 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. qui <\/u><\/a><\/noindex>e qui<\/u><\/a><\/noindex>.<\/p>\n

Inoltre, la sostituzione del serializzatore con Kryo in Hazelcast ci ha fornito un buon incremento. Il passaggio da ReplicatedMap a IMap + Near Cache in Hazelcast ci ha permesso di minimizzare il movimento dei dati all'interno del cluster. <\/p>\n

Un piccolo consiglio: durante l'invalidazione massiva della cache, a volte \u00e8 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 \u00e8 stato applicato, il consumo di memoria \u00e8 diminuito.<\/p>\n

Stack reattivo<\/h2>\n

Utilizziamo lo stack reattivo in un numero gi\u00e0 considerevole di sistemi. Nel nostro caso si tratta di Webflux o Kotlin con coroutine. Lo stack reattivo \u00e8 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.<\/p>\n

Il principio pi\u00f9 importante \u00e8 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\u00e0. <\/p>\n

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, \u00e8 molto difficile diagnosticare problemi basandosi sugli stack trace. La soluzione qui \u00e8 creare eccezioni runtime obiettive e chiare per ogni errore.<\/p>\n

Elasticsearch<\/h2>\n

Quando si utilizza Elasticsearch, evitare di selezionare dati non utilizzati. \u00c8 un consiglio piuttosto semplice, ma spesso viene dimenticato. Se \u00e8 necessario selezionare pi\u00f9 di 10.000 record in una volta, bisogna utilizzare Scroll. In un certo senso, \u00e8 un po' simile a un cursore in un database relazionale. <\/p>\n

Non utilizzare postfilter senza necessit\u00e0. Con grandi quantit\u00e0 di dati nel set principale, questa operazione grava notevolmente sul database. <\/p>\n

Utilizzare operazioni bulk dove applicabile.<\/p>\n

API<\/h2>\n

Quando si progetta l'API, considerare i requisiti per minimizzare i dati trasferiti. Questo \u00e8 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.<\/p>\n

E, infine, non presentate una montagna di dati, concentratevi chiaramente sul contratto tra consumatori e fornitori.<\/p>\n

Trasformazione organizzativa<\/h2>\n

Eroshkina Elena, Vice Direttore IT<\/em><\/p>\n

Nel momento in cui \u00e8 iniziato il lockdown e c'\u00e8 stata la necessit\u00e0 di aumentare rapidamente il ritmo dello sviluppo online e di implementare servizi omnicanale, eravamo gi\u00e0 nel processo di trasformazione organizzativa. <\/p>\n

Una parte della nostra struttura \u00e8 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\u00f2 che preferiscono, impostano la pipeline di distribuzione, implementano pratiche tecniche, pratiche di assicurazione della qualit\u00e0 e molto altro.<\/p>\n

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\u00e0 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\u00e0.<\/p>\n

Inoltre, \u00e8 emersa la necessit\u00e0 di rafforzare quei team che operano nella frontiera del business online. In quel momento \u00e8 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. <\/p>\n

Per questo non \u00e8 stato necessario alcuno sforzo gestionale speciale, poich\u00e9 insieme all'organizzazione del proprio processo, al perfezionamento tecnico del prodotto, alla pratica di assicurazione della qualit\u00e0, insegniamo ai nostri team l'autoorganizzazione \u2014 gestire il proprio processo produttivo senza ricorrere a risorse amministrative.<\/p>\n

Siamo riusciti a concentrare le risorse di gestione proprio dove era necessario in quel momento, ovvero nella coordinazione con il business: cosa \u00e8 attualmente importante per il nostro cliente, quale funzionalit\u00e0 deve essere realizzata per prima, cosa dobbiamo fare per aumentare la nostra capacit\u00e0 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\u00f2 che \u00e8 veramente importante e necessario. <\/p>\n

\u00c8 chiaro che, con il lavoro a distanza e l'elevato ritmo di cambiamenti, quando le prestazioni aziendali dipendono dalla partecipazione di ciascuno, non \u00e8 possibile fare affidamento solo sulle sensazioni interne come \u00abVa tutto bene? S\u00ec, sembra di s\u00ec\u00bb. 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.<\/p>\n

Ogni due settimane, svolgiamo uno stato con ogni team, dove per dieci minuti analizziamo le metriche, identifichiamo i punti deboli del processo produttivo e troviamo insieme una soluzione: cosa possiamo fare per eliminare questi punti critici. Qui abbiamo anche la possibilit\u00e0 di chiedere supporto alla direzione nel caso in cui un problema rilevato sia al di fuori della nostra portata, o ai colleghi che potrebbero aver gi\u00e0 affrontato un problema simile.<\/p>\n

Tuttavia, comprendiamo che per accelerare significativamente (ed \u00e8 esattamente questo l'obiettivo che ci poniamo) dobbiamo ancora imparare molto e integrare nella nostra routine quotidiana. Attualmente stiamo continuando a espandere l'approccio al prodotto ad altri team e a nuovi prodotti. Per questo abbiamo dovuto acquisire un nuovo formato per noi, quello della scuola online per metodologi.<\/p>\n

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. <\/p>\n

Penso che la situazione attuale ci offra opportunit\u00e0 e prospettive che forse non comprendiamo del tutto. Ma l'esperienza e la pratica che stiamo acquisendo in questo momento confermano che abbiamo scelto la strada giusta per la nostra evoluzione, e non perderemo in futuro queste nuove opportunit\u00e0, potendo rispondere altrettanto efficacemente alle sfide che ci attendono.<\/p>\n

Conclusioni<\/h3>\n

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.<\/p>\n

Le persone<\/strong>. Questo \u00e8 ci\u00f2 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. <\/p>\n

Tecnologia<\/strong>. \u00c8 necessario che l'azienda si approcci alla gestione del proprio stack tecnologico in modo maturo e accresca le competenze dove \u00e8 veramente necessario. Sembra molto semplice e ovvio. E molto spesso viene ignorato.<\/p>\n

Processi<\/strong>. \u00c8 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.<\/p>\n<\/p>\n

In generale, \u00e8 pi\u00f9 o meno cos\u00ec che abbiamo sopravvissuto. Il principale aforisma della modernit\u00e0 si \u00e8 confermato ancora una volta, colpendo sonoramente in fronte.<\/p>\n

Anche se sei un enorme business offline con moltissimi negozi e una miriade di citt\u00e0 in cui sei presente, sviluppa il tuo online. Non \u00e8 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 \u00e8 una ruota di scorta da usare in caso di necessit\u00e0, capace di aiutarti a superare la tempesta.<\/p>\n

\u00c8 una vera necessit\u00e0. Alla quale non devono essere pronti solo le tue capacit\u00e0 tecniche e l'infrastruttura, ma anche le persone e i processi. Infatti, acquistare velocemente memoria, spazio, avviare nuove istanze e altro si pu\u00f2 fare in poche ore. Ma le persone e i processi devono essere preparati in anticipo per questo.<\/p>\n<\/p>\n

Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0445\u0430\u0438\u043b, \u044f \u0437\u0430\u043c\u0435\u0441\u0442\u0438\u0442\u0435\u043b\u044c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0418\u0422 \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u00ab\u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u00bb. \u042f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u0435\u0439 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0441\u043f\u0440\u0430\u0432\u0438\u043b\u0438\u0441\u044c \u0441 \u0442\u0440\u0443\u0434\u043d\u043e\u0441\u0442\u044f\u043c\u0438, \u0432\u043e\u0437\u043d\u0438\u043a\u0448\u0438\u043c\u0438 \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0430\u043d\u0434\u0435\u043c\u0438\u0438. \u0412 \u043f\u0435\u0440\u0432\u044b\u0435 \u0434\u043d\u0438 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u0430\u043b\u0438\u0439 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0439 \u0444\u043e\u0440\u043c\u0430\u0442 \u043e\u0444\u043b\u0430\u0439\u043d-\u0442\u043e\u0440\u0433\u043e\u0432\u043b\u0438 \u00ab\u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0430\u00bb \u0437\u0430\u043c\u0435\u0440, \u0438 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0430 \u043d\u0430 \u043d\u0430\u0448 \u043e\u043d\u043b\u0430\u0439\u043d-\u043a\u0430\u043d\u0430\u043b, \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0432 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043d\u0430 \u0430\u0434\u0440\u0435\u0441 \u043a\u043b\u0438\u0435\u043d\u0442\u0443, \u0432\u043e\u0437\u0440\u043e\u0441\u043b\u0430 \u0432 10 \u0440\u0430\u0437. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94521,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94520","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cosa ci ha aiutato a riorganizzarci rapidamente per il commercio online in nuove condizioni | ProHoster","description":"Ciao! Mi chiamo Michail, sono il vice direttore IT della compagnia \u00abSportmaster\u00bb.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u043b\u043e \u043d\u0430\u043c \u0431\u044b\u0441\u0442\u0440\u043e \u043f\u0435\u0440\u0435\u0441\u0442\u0440\u043e\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u0442\u043e\u0440\u0433\u043e\u0432\u043b\u044e \u0432 \u043d\u043e\u0432\u044b\u0445 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442!\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0445\u0430\u0438\u043b, \u044f \u0437\u0430\u043c\u0435\u0441\u0442\u0438\u0442\u0435\u043b\u044c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0418\u0422 \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u00ab\u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u00bb.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-18T05:42:20+00:00","article:modified_time":"2020-09-18T05:42:20+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94520","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:25:23","updated":"2022-09-29 04:36:15","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=94520"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94520\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/94521"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=94520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=94520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=94520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}