{"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\/nl\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","title":{"rendered":"Wat ons hielp om snel over te schakelen naar online winkelen in de nieuwe omstandigheden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo!<\/p>\n

Mijn naam is Michail, ik ben de IT-directeur bij het bedrijf \u201cSportmaster\u201d. Ik wil een verhaal delen over hoe we de uitdagingen tijdens de pandemie hebben overwonnen.<\/p>\n

In de eerste dagen van de nieuwe realiteit kwam het gebruikelijke offline winkelmodel van \u201cSportmaster\u201d stil te liggen, terwijl de druk op ons online kanaal, met name wat betreft leveringen aan klanten, tien keer toenam. In enkele weken hebben we een enorme offline business omgevormd naar online en onze service aangepast aan de behoeften van onze klanten.<\/p>\n

Kortom, wat ooit onze secundaire operatie was, werd de belangrijkste business. Het belang van elke online bestelling nam extreem toe. We moesten elke euro behouden die een klant in het bedrijf bracht. <\/p>\n

\"Wat<\/p>\n

Om snel te reageren op klantverzoeken, hebben we een extra contactcentrum geopend in het hoofdkantoor van het bedrijf, en we kunnen nu ongeveer 285.000 telefoongesprekken per week aannemen. Tegelijkertijd hebben we 270 winkels omgevormd naar een nieuw formaat voor contactloze en veilige werking, wat klanten in staat stelde om hun bestellingen te ontvangen en medewerkers hun banen te behouden.<\/p>\n

Tijdens het transformatieproces stuitten we op twee hoofdproblemen. Ten eerste steeg de druk op onze online middelen aanzienlijk (hoe we dit hebben aangepakt, zal Sergey uitleggen). Ten tweede nam de stroom van zeldzame (voor COVID) transacties exponentieel toe, wat op zijn beurt een grote hoeveelheid snelle automatisering vereiste. Om dit probleem op te lossen, moesten we snel middelen overhevelen van gebieden die eerder hoofdzakelijk waren. Hoe we dit hebben opgelost, zal Elena vertellen.<\/p>\n

Exploitation van online diensten<\/h2>\n

Koliesnikov Sergey, verantwoordelijk voor de exploitatie van de webshop en microservices<\/em><\/p>\n

Vanaf het moment dat onze fysieke winkels werden gesloten voor bezoekers, begonnen we een stijging te registreren in metriek zoals het aantal gebruikers, het aantal bestellingen dat via onze applicatie werd geplaatst, en het aantal verzoeken naar de applicaties. <\/p>\n

\"WatAantal bestellingen van 18 tot 31 maart\"WatAantal verzoeken naar de microservices voor online betalingen\"WatAantal bestellingen geplaatst op de website<\/p>\n

In de eerste grafiek zien we dat de groei ongeveer 14 keer was, en in de tweede 4 keer. We beschouwen de metriek van de responstijd van onze applicaties als de meest sprekende. <\/p>\n

\"Wat<\/p>\n

In dit diagram zien we de respons van front- en applicaties, en voor ons hebben we vastgesteld dat we geen significante groei hebben opgemerkt.<\/p>\n

Dit komt voornamelijk doordat we eind 2019 zijn begonnen met voorbereidingen. Onze diensten zijn nu gereserveerd, waarbij redundantie is gegarandeerd op het niveau van fysieke servers, virtualisatiesystemen, Docker en de diensten daarin. Daarnaast maken de capaciteit van onze serverbronnen het mogelijk om meerdere belastingen te verwerken.<\/p>\n

Het belangrijkste hulpmiddel dat ons heeft geholpen in dit proces, is ons monitorsysteem. Eerlijk gezegd hadden we niet zo lang geleden geen uniform systeem dat het mogelijk maakte om metrics op alle lagen te verzamelen, van de fysieke apparatuur en hardware tot bedrijfsmetrics. <\/p>\n

Formeel hadden we monitoring in het bedrijf, maar meestal was dit verspreid en viel het onder de verantwoordelijkheid van specifieke afdelingen. In feite hadden we bijna nooit een gezamenlijk begrip van wat er precies was gebeurd wanneer er een incident plaatsvond, er was geen informatievoorziening, en vaak leidde dit tot een constante zoektocht naar het lokaliseren en oplossen van problemen.<\/p>\n

Op een gegeven moment hebben we nagedacht en besloten dat we dit niet langer konden tolereren \u2014 we hadden een uniform systeem nodig om het volledige plaatje te zien. De belangrijkste technologie\u00ebn die in onze stack zitten, zijn Zabbix als het centrum voor waarschuwingen en metric-opslag, Prometheus voor het verzamelen en opslaan van applicatie-metrics, Stack ELK voor logging en gegevensopslag van het volledige monitorsysteem, evenals Grafana voor visualisatie, Swagger, Docker en andere handige en vertrouwde hulpmiddelen.<\/p>\n

Daarnaast gebruiken we niet alleen de beschikbare technologie\u00ebn op de markt, maar ontwikkelen we ook enkele dingen zelf. Bijvoorbeeld, we maken diensten voor de integratie van systemen met elkaar, dat wil zeggen een soort API voor het verzamelen van metrics. Bovendien werken we aan onze eigen monitorsystemen \u2014 op het niveau van bedrijfsmetrics gebruiken we UI-tests. We hebben ook een bot in Telegram voor het informeren van teams.<\/p>\n

En we proberen ook het monitorsysteem toegankelijk te maken voor teams, zodat ze zelf hun metrics kunnen opslaan en ermee kunnen werken, inclusief het instellen van waarschuwingen voor bepaalde specifieke metrics die niet van brede toepassing zijn. <\/p>\n

Binnen het hele systeem streven we naar proactiviteit en de snelste mogelijke lokale incidentoplossing. Bovendien is het aantal van onze microservices en systemen de laatste tijd aanzienlijk toegenomen, wat ook het aantal integraties doet stijgen. In het kader van het optimaliseren van het diagnoseproces op het gebied van integratie ontwikkelen we een systeem dat cross-systemcontrole mogelijk maakt en een resultaat presenteert, waardoor we de belangrijkste problemen met imports en de interactie tussen systemen kunnen identificeren. <\/p>\n

Natuurlijk hebben we nog ruimte om te groeien en ons te ontwikkelen op het gebied van systeemoperaties, en we werken daar actief aan. Meer informatie over ons monitoringsysteem is te lezen. hier<\/u><\/a><\/noindex>. <\/p>\n

Technische testen <\/h2>\n

Sergio Orlov, leidt het competentiecentrum voor web- en mobiele ontwikkeling.<\/em><\/p>\n

Sinds de sluiting van fysieke winkels zijn we met verschillende uitdagingen geconfronteerd vanuit het perspectief van ontwikkeling. Ten eerste, de sprong in de belasting zelf. Het is duidelijk dat, als er geen passende maatregelen worden genomen, een systeem onder hoge belasting met een trieste klap kan veranderen in een pompoen, of volledig kan degraderen in prestaties, of zelfs zijn functionaliteit kan verliezen.<\/p>\n

Het tweede aspect, dat iets minder voor de hand liggend is, is dat het systeem onder hoge belasting zeer snel moest worden aangepast aan de wijzigingen in bedrijfsprocessen. Soms meerdere keren per dag. Veel bedrijven hanteren de regel dat er tijdens grote marketingactiviteiten geen wijzigingen in het systeem mogen worden aangebracht. Helemaal geen, laat het maar werken zoals het werkt.<\/p>\n

En wij hadden eigenlijk een eindeloze zwarte vrijdag, waarbij we het systeem moesten aanpassen. En elke fout, probleem of storing in het systeem zou de onderneming enorm veel kosten.<\/p>\n

Om vooruit te lopen, kan ik zeggen dat we deze uitdagingen hebben weten te overwinnen; alle systemen hebben de belasting doorstaan, zijn eenvoudig geschaald en we hebben geen grote technische storingen gehad.<\/p>\n

Er zijn vier pijlers waarop het vermogen van het systeem om hoge pieklasten te weerstaan rust. De eerste is monitoring, waar je hierboven al over hebt gelezen. Zonder een goed opgezet monitoringsysteem is het vrijwel onmogelijk om knelpunten in het systeem te identificeren. Een goed monitoringsysteem is als comfy huiskleding, het moet comfortabel zijn en op jou aangepast worden.<\/p>\n

Het tweede aspect is testen. We nemen dit aspect heel serieus: we schrijven zowel klassieke unit tests, integratietests, belastingstests als vele andere voor elk systeem. Daarnaast schrijven we een teststrategie en proberen we het testniveau zo hoog te krijgen dat handmatige controles niet langer nodig zijn.<\/p>\n

De derde pijler is de CI\/CD-pijplijn. De processen van builden, testen en implementeren van de applicatie moeten zo veel mogelijk geautomatiseerd zijn; er mogen geen handmatige ingrepen zijn. Het onderwerp CI\/CD-pijplijn is behoorlijk diepgaand, en ik zal het slechts kort aanstippen. Het is alleen vermeldenswaard dat we een checklist voor de CI\/CD-pijplijn hebben, waaraan elke productteam via competentiecentra werkt.<\/p>\n

\"WatEn hier is de checklist<\/p>\n

Op deze manier worden veel doelen bereikt. Dit omvat versiebeheer van de API, feature toggles om een kettingreactie van releases te voorkomen, en het bereiken van een testdekking zo hoog dat testen volledig geautomatiseerd is, implementaties naadloos zijn, en meer.<\/p>\n

De vierde pijler zijn de architecturale principes en technische oplossingen. Er valt veel te zeggen over architectuur, maar ik wil een paar principes benadrukken waarop ik de nadruk wil leggen.<\/p>\n

Ten eerste moet je gespecialiseerde tools kiezen voor specifieke taken. Ja, het klinkt vanzelfsprekend, en het is duidelijk dat je spijkers met een hamer moet slaan en dat je een speciale schroevendraaier voor het demonteren van horloges nodig hebt. Maar in onze tijd proberen veel tools te generaliseren om zoveel mogelijk gebruikerssegmenten te bereiken: databases, caches, frameworks en meer. Neem bijvoorbeeld de database MongoDB, die werkt met multi-documenttransacties, terwijl de Oracle-database met JSON werkt. En het lijkt misschien dat alles voor alles gebruikt kan worden. Maar als we pleiten voor prestaties, moeten we de sterke en zwakke punten van elke tool duidelijk begrijpen en de juiste tools voor onze specifieke taak gebruiken. <\/p>\n

Ten tweede moet iedere verhoging van de complexiteit bij het ontwerpen van systemen gerechtvaardigd zijn. We moeten dit constant in gedachten houden, het principe van low coupling is algemeen bekend. Ik geloof dat het op zowel het niveau van specifieke diensten, als op het niveau van het gehele systeem en het architectonische landschap moet worden toegepast. Ook is de mogelijkheid van horizontale schaalbaarheid van elk systeemcomponent onder belasting belangrijk. Als je over deze mogelijkheid beschikt, zal schaalvergroting geen probleem zijn.<\/p>\n

Als we het hebben over technische oplossingen, hebben we de productteams gevraagd om een frisse set aanbevelingen, idee\u00ebn en oplossingen voor te bereiden die zij hebben ge\u00efmplementeerd in de aanloop naar de volgende golf van belasting.<\/p>\n

Caches<\/h2>\n

Het is belangrijk om bewust om te gaan met de keuze tussen lokale en gedistribueerde caches. Soms is het zinvol om beide types binnen \u00e9\u00e9n systeem te gebruiken. Bijvoorbeeld, we hebben systemen waarin een deel van de data in wezen een vitrinedatabase is, wat betekent dat de bron van updates zich buiten het systeem bevindt en dat het systeem deze data niet wijzigt. Voor deze aanpak gebruiken we de lokale Caffeine Cache. <\/p>\n

Er zijn ook data die het systeem actief wijzigt tijdens de werking, en in dit geval gebruiken we een gedistribueerde cache met Hazelcast. Deze aanpak stelt ons in staat de voordelen van een gedistribueerde cache te benutten waar dat echt nodig is, en de operationele kosten voor het circuleren van data in de Hazelcast-cluster te minimaliseren waar dat mogelijk is. We hebben veel over caches geschreven. hier <\/u><\/a><\/noindex>en hier<\/u><\/a><\/noindex>.<\/p>\n

Bovendien heeft het veranderen van de serializer naar Kryo in Hazelcast een behoorlijke verbetering opgeleverd. De overstap van ReplicatedMap naar IMap + Near Cache in Hazelcast heeft ons in staat gesteld om de databeweging door de cluster tot een minimum te beperken. <\/p>\n

Een kleine tip: bij massale invalidatie van de cache kan het soms handig zijn om een tweede cache voor te verwarmen, waarna je vervolgens naar die cache overschakelt. Het lijkt misschien dat we met deze aanpak dubbele geheugengebruik zouden krijgen, maar in de praktijk, in systemen waar dit is toegepast, nam het geheugengebruik af.<\/p>\n

Reactieve stack<\/h2>\n

We gebruiken de reactieve stack al in een behoorlijk aantal systemen. In ons geval is dat Webflux of Kotlin met coroutines. De reactieve stack werkt bijzonder goed in situaties waar we trage input-output operaties verwachten. Bijvoorbeeld, bij het aanroepen van trage services, het werken met het bestandssysteem of opslagsystemen.<\/p>\n

Het belangrijkste principe is om blokkering oproepen te vermijden. Onder de motorkap draaien er een klein aantal actieve service-threads in reactieve frameworks. Als we onoplettend een directe blokkering oproep doen, zoals een aanroep naar een JDBC-driver, dan zal het systeem gewoon stoppen. <\/p>\n

Probeer fouten om te zetten in eigen runtime exceptions. De echte uitvoeringsstroom van het programma schakelt over naar reactieve frameworks, waardoor de uitvoering van de code niet-lineair wordt. Dit maakt het moeilijk om problemen te diagnosticeren op basis van stack traces. Een oplossing is hier het cre\u00ebren van begrijpelijke, objectieve runtime exceptions voor elke fout.<\/p>\n

Elasticsearch<\/h2>\n

Bij het gebruik van Elasticsearch is het belangrijk om ongebruikte data niet te selecteren. Dit is in principe ook een heel eenvoudige tip, maar vaak wordt dit vergeten. Als je meer dan 10.000 records in \u00e9\u00e9n keer moet selecteren, gebruik dan Scroll. Vergelijk het met een cursor in een relationele database. <\/p>\n

Gebruik geen postfilter tenzij het nodig is. Bij grote datasets in de primaire selectie belast deze operatie de database enorm. <\/p>\n

Gebruik bulk-operaties waar mogelijk.<\/p>\n

API<\/h2>\n

Bij het ontwerpen van API's moet je vereisten opnemen voor het minimaliseren van de over te dragen data. Dit is vooral relevant in combinatie met de front-end: precies op dat raakvlak gaan we buiten de kanalen van onze datacenters en werken we al op de lijn die ons met de klant verbindt. Als er op die lijn de kleinste problemen zijn, veroorzaakt te veel verkeer een negatieve gebruikerservaring.<\/p>\n

En tot slot, dump niet alle gegevens; benader het contract tussen consumenten en leveranciers doelgericht.<\/p>\n

Organisatorische transformatie<\/h2>\n

Yelena Eroshkina, plaatsvervangend directeur IT<\/em><\/p>\n

Op het moment dat de lockdown begon en het noodzakelijk werd om de groei van online diensten en de implementatie van omnichannel-services snel te versnellen, waren we al bezig met een organisatorische transformatie. <\/p>\n

Een deel van onze structuur is overgestapt op werken volgens de principes en praktijken van een productgerichte aanpak. Teams zijn gevormd die nu verantwoordelijk zijn voor de werking en ontwikkeling van elk product. Werknemers in dergelijke teams zijn voor 100% betrokken en organiseren hun werk volgens scrum of kanban, afhankelijk van wat voor hen het meest geschikt is, en optimaliseren de implementatieprocessen, voeren technische praktijken en kwaliteitsborging in en nog veel meer.<\/p>\n

Gelukkig bevond het grootste deel van dergelijke productteams zich bij ons al op het gebied van online en omnichannel-services. Dit stelde ons in staat om binnen zeer korte tijd (echt, letterlijk binnen twee dagen) over te stappen op thuiswerken zonder verlies van effici\u00ebntie. Het ingerichte proces stelde ons in staat om snel aan te passen aan de nieuwe werkomstandigheden en een behoorlijk hoge snelheid van levering van nieuwe functionaliteit vast te houden.<\/p>\n

Bovendien ontstond de noodzaak om de teams te versterken die zich aan de frontlinie van de online business bevinden. In dat moment werd duidelijk dat we dit alleen konden doen met interne middelen. Ongeveer 50 mensen veranderden binnen twee weken van werkgebied en sloten zich aan bij de ontwikkeling van een nieuw product voor hen. <\/p>\n

Hiervoor waren geen bijzondere managementinspanningen nodig, omdat we parallel met de organisatie van onze eigen processen, de technische verfijning van het product en de kwaliteitsborging, onze teams leren zelforganiserend te zijn \u2014 hun eigen productieproces te beheren zonder administratieve hulp.<\/p>\n

We were able to focus our management resources precisely where it was necessary at that moment\u2014on coordinating with the business: What is currently important for our client, what functionality should be implemented first, and what needs to be done to increase our delivery and order processing capacity. All of this, along with a clear role model, allowed us to load our value creation processes with what is truly important and needed during this period. <\/p>\n

Clearly, with remote work and the rapid pace of change, when the participation of each individual affects business metrics, one cannot rely solely on internal feelings like \"Is everything going well? It seems fine.\" Objective metrics of the production process are necessary. We have these metrics; they are available to anyone interested in the metrics of product teams. Primarily for the team itself, the business, stakeholders, and management.<\/p>\n

Elke twee weken vindt er een statusmeeting met elk team plaats, waarin gedurende 10 minuten de metrics worden geanalyseerd, knelpunten in het productieproces worden ge\u00efdentificeerd en gezamenlijke oplossingen worden ontwikkeld: wat kunnen we doen om deze knelpunten te verhelpen. Hier kan ook meteen hulp van het management worden gevraagd als een identific probleem buiten de invloedssfeer van de teams ligt, of van collega-experts die wellicht al met een soortgelijk probleem zijn geconfronteerd.<\/p>\n

Desondanks begrijpen we dat we nog veel moeten leren en implementeren in ons dagelijks werk om een significante versnelling te realiseren (wat precies ons doel is). Op dit moment blijven we de productbenadering opschalen naar andere teams en nieuwe producten. Hiervoor moesten we een nieuw format van online school voor methodologen beheersen.<\/p>\n

Methodologists, the people who help teams build processes, establish communications, and improve work efficiency, essentially act as change agents. Right now, graduates from our first cohort are working with teams and helping them become successful. <\/p>\n

Ik denk dat de huidige situatie ons mogelijkheden en perspectieven biedt die we misschien nog niet volledig beseffen. Maar de ervaring en praktijk die we op dit moment opdoen, bevestigt dat we de juiste ontwikkelingsrichting hebben gekozen, zodat we in de toekomst deze nieuwe mogelijkheden niet zullen missen en effectief kunnen blijven reageren op de uitdagingen die voor \u2018Sportmaster\u2019 zullen komen.<\/p>\n

Conclusies<\/h3>\n

Gedurende deze uitdagende tijd hebben we de belangrijkste principes geformuleerd die de ontwikkeling van software ondersteunen, die, denk ik, relevant zullen zijn voor elk bedrijf dat hieraan werkt.<\/p>\n

Mensen<\/strong>. Dit is waar alles op steunt. Medewerkers moeten plezier hebben in hun werk, de doelen van het bedrijf en de producten waar ze mee bezig zijn begrijpen. En natuurlijk moeten ze zich professioneel kunnen ontwikkelen. <\/p>\n

Technologie<\/strong>. Het is noodzakelijk dat het bedrijf op een volwassen manier omgaat met zijn technologische stack en competenties opbouwt waar dat echt nodig is. Het klinkt erg simpel en voor de hand liggend. En wordt vaak genegeerd.<\/p>\n

Processen<\/strong>. Het is belangrijk om de samenwerking binnen productteams en competentiecentra goed te organiseren en interactie met het bedrijfsleven op te zetten, zodat we als partners kunnen samenwerken.<\/p>\n<\/p>\n

Over het algemeen hebben we zo overleefd. De belangrijkste stelling van de moderniteit bevestigde zich weer eens, met een duidelijke klap op het voorhoofd.<\/p>\n

Zelfs als je een enorm offline bedrijf bent met veel winkels en in tal van steden aanwezig bent, ontwikkel je je online. Dit is niet zomaar een extra verkoopkanaal of een mooie applicatie waar je ook iets kunt kopen (en ook omdat de concurrentie ook mooie applicaties heeft). Dit is geen reserveband voor als het nodig is, die je helpt om de storm door te komen.<\/p>\n

Dit is een absolute noodzaak. Waarvoor niet alleen je technische mogelijkheden en infrastructuur, maar ook mensen en processen voorbereid moeten zijn. Want het is mogelijk om snel extra geheugen, ruimte, nieuwe instanties en dergelijke aan te schaffen in een paar uur. Maar mensen en processen moeten hiervoor van tevoren worden voorbereid.<\/p>\n<\/p>\n

Bron: 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\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\udd47Wat ons hielp om snel over te schakelen naar online winkelen onder de nieuwe omstandigheden | ProHoster","description":"Hallo! Mijn naam is Michail, ik ben de IT-directeur bij 'Sportmaster'.","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/94520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=94520"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/94520\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/94521"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=94520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=94520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=94520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}