{"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\/hr\/blog\/administrirovanie\/chto-pomoglo-nam-bystro-perestroitsya-na-onlajn-torgovlyu-v-novyh-usloviyah","title":{"rendered":"\u0160to nam je pomoglo da se brzo prebacimo na online trgovinu u novim uvjetima","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozdrav!<\/p>\n

Zovem se Mihail, zamjenik sam direktora za IT u tvrtki \u201eSportmaster\u201c. \u017delim podijeliti pri\u010du o tome kako smo se nosili s izazovima koji su se pojavili tijekom pandemije.<\/p>\n

U prvim danima novih stvarnosti, uobi\u010dajeni format offline prodaje \u201eSportmastera\u201c stagnirao je, a optere\u0107enje na na\u0161em online kanalu, posebice u dijelu dostave na adresu kupcima, poraslo je deset puta. U nekoliko tjedana transformirali smo ogromno offline poslovanje u online, prilagodili smo uslugu potrebama na\u0161ih klijenata.<\/p>\n

Op\u0107enito, ono \u0161to je u biti bila na\u0161a sekundarna operacija postalo je glavni posao. Va\u017enost svake internet narud\u017ebe ekstremno je porasla. Morali smo zadr\u017eati svaki nov\u010di\u0107 koji je klijent donio u tvrtku. <\/p>\n

\"\u0160to<\/p>\n

Kako bismo odmah reagirali na zahtjeve kupaca, otvorili smo dodatni kontaktni centar u glavnom uredu tvrtke i sada mo\u017eemo primiti oko 285 tisu\u0107a poziva tjedno. U isto vrijeme, prebacili smo 270 trgovina u novi format bezkontaktnog i sigurnog rada, \u0161to je omogu\u0107ilo kupcima da preuzmu narud\u017ebe, a zaposlenicima da zadr\u017ee svoja radna mjesta.<\/p>\n

Tijekom transformacije imali smo dva glavna problema. Prvo, optere\u0107enje na na\u0161im online resursima zna\u010dajno je poraslo (o tome kako smo se borili s tim, govorit \u0107e Sergey). Drugo, broj rijetkih operacija (do COVID-a) vi\u0161estruko je porastao, \u0161to je zauzvrat zahtijevalo veliku brzinu automatizacije. Kako bismo rije\u0161ili ovaj problem, morali smo brzo prebaciti resurse s podru\u010dja koja su ranije bila glavna. O tome kako smo to u\u010dinili, govoriti \u0107e Elena.<\/p>\n

Eksploatacija online usluga<\/h2>\n

Kolesnikov Sergey, odgovara za eksploataciju internetske trgovine i mikroservisa<\/em><\/p>\n

Od trenutka kada su na\u0161e maloprodajne trgovine po\u010dele zatvarati vrata kupcima, po\u010deli smo bilje\u017eiti porast takvih metrika kao \u0161to su broj korisnika, broj narud\u017ebi obra\u0111enih u na\u0161oj aplikaciji, broj zahtjeva prema aplikacijama. <\/p>\n

\"\u0160toBroj narud\u017ebi od 18. do 31. o\u017eujka\"\u0160toBroj zahtjeva prema mikroservisima online pla\u0107anja\"\u0160toBroj narud\u017ebi napravljenih na web stranici<\/p>\n

Na prvom grafikonu vidimo da je porast iznosio otprilike 14 puta, a na drugom \u2014 4 puta. Najdokaznije mjerilo pri tome smatramo vremenom odgovora na\u0161ih aplikacija. <\/p>\n

\"\u0160to<\/p>\n

Na ovom grafu vidimo odgovore frontova i aplikacija, a za sebe smo utvrdili da nismo primijetili nikakav rast.<\/p>\n

Prvo, to je povezano s tim \u0161to smo zapo\u010deli pripremne radove krajem 2019. godine. Sada su na\u0161i servisi rezervirani, osigurana je otpornost na kvarove na razini fizi\u010dkih servera, sustava virtualizacije, dockera i usluga unutar njih. Istodobno, kapaciteti na\u0161ih serverskih resursa omogu\u0107uju nam da izdr\u017eimo vi\u0161estruko optere\u0107enje.<\/p>\n

Glavni alat koji nam je pomogao u cijeloj ovoj pri\u010di postao je na\u0161 sustav nadzora. Ipak, jo\u0161 nedavno nismo imali jedinstveni sustav koji bi omogu\u0107io prikupljanje metrika na svim razinama, od fizi\u010dke opreme i hardvera do poslovnih metrika. <\/p>\n

Formalno, monitoring je u kompaniji postojao, ali je obi\u010dno bio raspr\u0161en i smatran odgovorno\u0161\u0107u konkretnih odjela. U stvarnosti, kada bi se dogodio neki incident, gotovo nikada nismo imali jedinstveno razumijevanje \u0161to se zapravo dogodilo, nije bilo informacija, a \u010desto je to vodilo do beskrajnog tr\u010danja u potrazi za i lokalizacijom problema radi njegovog kasnijeg uklanjanja.<\/p>\n

U nekom trenutku smo pomislili i odlu\u010dili da je dosta toga \u2014 potrebna nam je jedinstvena sustav, kako bismo vidjeli cijelu sliku u cjelini. Glavne tehnologije koje \u010dine na\u0161u infrastrukturu su Zabbix kao centar za upozoravanje i pohranu metrika, Prometheus za prikupljanje i pohranu metrika aplikacija, Stack ELK za logiranje i pohranu podataka cijelog sustava nadzora, te Grafana za vizualizaciju, Swagger, Docker i druge korisne i poznate stvari.<\/p>\n

Uz to, ne koristimo samo dostupne tehnologije na tr\u017ei\u0161tu, ve\u0107 i razvijamo ne\u0161to sami. Na primjer, izra\u0111ujemo servise za integraciju sustava jednih s drugima, odnosno neku vrstu API-ja za prikupljanje metrika. Plus, radimo na vlastitim sustavima nadzora \u2014 na razini poslovnih metrika koristimo UI testove. Tako\u0111er, imamo bot u Telegramu za obavje\u0161tavanje timova.<\/p>\n

Pored toga, trudimo se u\u010diniti sustav nadzora dostupnim timovima, kako bi oni mogli samostalno pohraniti svoje metrike i raditi s njima, uklju\u010duju\u0107i pode\u0161avanje upozorenja na uskim metrikama koje imaju zna\u010daj, a ne \u0161iroku primjenu. <\/p>\n

U okviru cijelog sustava te\u017eimo proaktivnosti i maksimalno brzoj lokalizaciji incidenata. Osim toga, broj na\u0161ih mikrosustava i sustava znatno je porastao u posljednje vrijeme, pa tako raste i broj integracija. U cilju optimizacije procesa dijagnostike incidenata na razini integracije razvijamo sustav koji omogu\u0107ava provo\u0111enje me\u0111usustavnih provjera i prikazivanje rezultata, \u0161to omogu\u0107uje pronala\u017eenje glavnih problema vezanih uz uvoze i me\u0111usobnu interakciju sustava. <\/p>\n

Naravno, imamo jo\u0161 prostora za rast i razvoj u pogledu upravljanja sustavima, i aktivno radimo na tome. Vi\u0161e o na\u0161em sustavu pra\u0107enja mo\u017eete pro\u010ditati ovdje<\/u><\/a><\/noindex>. <\/p>\n

Tehni\u010dka ispitivanja <\/h2>\n

Sergije Orlov vodi centar kompetencije za web i mobilni razvoj<\/em><\/p>\n

Od po\u010detka zatvaranja fizi\u010dkih trgovina suo\u010dili smo se s raznim izazovima u pogledu razvoja. Prvo, skok optere\u0107enja kao takvog. Jasno je da ako se ne poduzmu odgovaraju\u0107e mjere, pod jakim optere\u0107enjem sustav se mo\u017ee s tu\u017enim zvukom pretvoriti u bundevu, ili potpuno degradirati u performansama, ili uop\u0107e izgubiti svoju funkcionalnost.<\/p>\n

Drugi aspekt, ne\u0161to manje o\u010digledan, jest da je sustav pod visokim optere\u0107enjem trebao biti vrlo brzo promijenjen, prilago\u0111avaju\u0107i se promjenama poslovnih procesa. Ponekad i nekoliko puta dnevno. Mnoge tvrtke imaju pravilo da prilikom velikih marketin\u0161kih aktivnosti ne treba unositi nikakve promjene u sustav. Uop\u0107e nikakve, neka radi, \u010dim radi.<\/p>\n

A mi smo, u su\u0161tini, imali beskrajni crni petak, u kojem smo tako\u0111er morali mijenjati sustav. Svaka gre\u0161ka, problem ili kvar u sustavu bili bi vrlo skupi za poslovanje.<\/p>\n

S obzirom na sve, mogu re\u0107i da smo uspjeli suo\u010diti se s tim izazovima, svi sustavi su izdr\u017eali optere\u0107enje, lako su se skalirali i nismo imali globalnih tehni\u010dkih kvarova.<\/p>\n

Postoje \u010detiri stuba na kojima se temelji sposobnost sustava da podnese visoke skokovite optere\u0107enja. Prvi od njih je pra\u0107enje, o kojem ste malo ranije \u010ditali. Bez dobro uspostavljenog sustava pra\u0107enja gotovo je nemogu\u0107e prona\u0107i uska mjesta u sustavu. Dobar sustav pra\u0107enja je kao doma\u0107a odje\u0107a, mora biti udoban i prilago\u0111en vama.<\/p>\n

Drugi aspekt je testiranje. Ovo pitanje shva\u0107amo vrlo ozbiljno: pi\u0161emo klasi\u010dne jedinice, integracijske, optere\u0107enjske testove i mnoge druge za svaki sustav. Tako\u0111er pi\u0161emo strategiju testiranja, te nastojimo unaprijediti razinu testiranja do to\u010dke gdje nam vi\u0161e ne trebaju ru\u010dne provjere.<\/p>\n

Tre\u0107i stub je CI\/CD Pipeline. Procesi izgradnje, testiranja i implementacije aplikacija trebaju biti maksimalno automatizirani, bez ru\u010dnih intervencija. Tema CI\/CD Pipeline je prili\u010dno opse\u017ena, i doti\u010dem je samo povr\u0161no. Vrijedi spomenuti da imamo kontrolni popis CI\/CD Pipeline, prema kojem kroz centre kompetencija prolazi svaki razvojni tim.<\/p>\n

\"\u0160toEvo kontrolnog popisa<\/p>\n

Na taj na\u010din posti\u017ee se mnogo ciljeva. To je verzioniranje API-ja, i feature toggle kako bi se izbjegli problemi s objavama, i postizanje razine pokrivenosti razli\u010ditih testova tako da testiranje bude potpuno automatizirano, a implementacije besprijekorne i drugo.<\/p>\n

\u010cetvrti stub su arhitektonski principi i tehni\u010dka rje\u0161enja. O arhitekturi se mo\u017ee govoriti puno i dugo, ali \u017eelim naglasiti nekoliko principa na koje bih \u017eelio skrenuti pozornost.<\/p>\n

Prvo, treba odabrati specijalizirane alate za specifi\u010dne zadatke. Da, zvu\u010di o\u010digledno, i jasno je da se \u010davli trebaju zabijati \u010deki\u0107em, a ru\u010dni satovi rastavljati posebnim odvija\u010dima. No, u na\u0161e doba mnogo alata te\u017ei univerzalizaciji kako bi obuhvatili maksimalan segment korisnika: baze podataka, ke\u0161eve, okvire i ostalo. Na primjer, ako uzmemo bazu podataka MongoDB, ona radi s vi\u0161edokumentarnim transakcijama, dok baza podataka Oracle radi s json-ima. I \u010dinilo bi se da se sve mo\u017ee koristiti za sve. Ali ako se zalagamo za performanse, moramo jasno razumjeti snage i slabosti svakog alata i koristiti one koji su nam potrebni za na\u0161 razred zadataka. <\/p>\n

Drugo, prilikom projektiranja sustava svako pove\u0107anje slo\u017eenosti treba biti opravdano. Trebamo stalno imati to na umu, princip niske povezanosti je svima poznat. Smatram da se treba primjenjivati i na razini konkretnog servisa, i na razini cijelog sustava, te na razini arhitektonskog pejza\u017ea. Tako\u0111er je va\u017ena sposobnost horizontalnog skaliranja svakog komponeneta sustava pod optere\u0107enjem. Ako imamo tu sposobnost, skaliranje ne\u0107e biti nikakav problem.<\/p>\n

\u0160to se ti\u010de tehni\u010dkih rje\u0161enja, zamolili smo proizvodne timove da pripreme svje\u017e skup preporuka, ideja i rje\u0161enja koja su implementirali u pripremi za sljede\u0107i val optere\u0107enja.<\/p>\n

Ke\u0161evi<\/h2>\n

Moramo svjesno pristupiti izboru lokalnih i distribuiranih ke\u0161eva. Ponekad ima smisla koristiti i jedne i druge unutar istog sustava. Na primjer, imamo sustave u kojima su neki podaci u osnovi izlo\u017ebeni ke\u0161, \u0161to zna\u010di da se izvor a\u017euriranja nalazi izvan samog sustava, a sustavi ne mijenjaju te podatke. Za takav pristup koristimo lokalni Caffeine Cache. <\/p>\n

A postoje podaci koje sustav aktivno mijenja tijekom rada, i tu ve\u0107 primjenjujemo distribuirani ke\u0161 s Hazelcastom. Takav pristup nam omogu\u0107ava da iskoristimo prednosti distribuiranog ke\u0161a gdje su doista potrebne, i minimiziramo tro\u0161kove servisa za cirkulaciju podataka klastera Hazelcast gdje mo\u017eemo bez toga. O ke\u0161evima smo puno pisali. ovdje <\/u><\/a><\/noindex>i ovdje<\/u><\/a><\/noindex>.<\/p>\n

Osim toga, promjena serijalizatora na Kryo u Hazelcastu donijela nam je zna\u010dajan porast. A prijelaz s ReplicatedMap na IMap + Near Cache u Hazelcastu omogu\u0107io nam je minimiziranje kretanja podataka kroz klaster. <\/p>\n

Mali savjet: pri masovnoj invalidaciji cache-a ponekad se mo\u017ee primijeniti taktika zagrijavanja drugog cache-a s kasnijim prebacivanjem na njega. Iako bi se na prvi pogled \u010dinilo da \u0107emo ovim pristupom dobiti dvostruku potro\u0161nju memorije, u praksi, u sustavima gdje se to primjenjivalo, potro\u0161nja memorije se smanjivala.<\/p>\n

Reaktivni okvir<\/h2>\n

Reaktivni okvir koristimo ve\u0107 u prili\u010dno velikom broju sustava. U na\u0161em slu\u010daju to je Webflux ili Kotlin s korutinama. Posebno dobro reaktivni okvir dolazi do izra\u017eaja kada o\u010dekujemo spore operacije ulaza i izlaza. Na primjer, pozivi sporih servisa, rad s datote\u010dnim sustavima ili sustavima za pohranu.<\/p>\n

Najva\u017eniji princip je izbjegavati blokiraju\u0107e pozive. Ispod poklopca reaktivnih okvira radi manji broj aktivnih uslu\u017enih niti. Ako nepa\u017eljivo dozvolimo sebi da napravimo izravan blokiraju\u0107i poziv, kao \u0161to je poziv JDBC drajvera, sustav \u0107e jednostavno stati. <\/p>\n

Poku\u0161ajte pretvoriti gre\u0161ke u vlastite runtime exceptione. Stvarna nit izvr\u0161enja programa prelazi na reaktivne okvire, izvr\u0161avanje koda postaje nelinearno. Kao posljedica, vrlo je te\u0161ko dijagnosticirati probleme prema stack trace-ovima. Rje\u0161enje ovdje \u0107e biti stvaranje jasnih objektivnih runtime exceptiona za svaku gre\u0161ku.<\/p>\n

Elasticsearch<\/h2>\n

Prilikom kori\u0161tenja Elastica ne odabirejte neiskori\u0161tene podatke. To je, u osnovi, vrlo jednostavan savjet, ali naj\u010de\u0161\u0107e se upravo toga zaboravlja. Ako trebate odabrati vi\u0161e od 10 tisu\u0107a zapisa odjednom, potrebno je koristiti Scroll. U analogiji, to nalikuje kursoru u relacijskoj bazi podataka. <\/p>\n

Ne koristite postfilter bez potrebe. Pri velikim podacima u osnovnom odabiru ova operacija jako optere\u0107uje bazu podataka. <\/p>\n

Koristite bulk operacije gdje je to primjenjivo.<\/p>\n

API<\/h2>\n

Pri dizajniranju API-ja postavite zahtjeve za minimizaciju prenesenih podataka. To je posebno va\u017eno na spoju s front-endom: upravo na toj to\u010dki izlazimo iz kanala na\u0161ih podatkovnih centara i ve\u0107 radimo na kanalu koji nas povezuje s klijentom. Ako postoje i najmanji problemi na njemu, preveliki promet izaziva negativno korisni\u010dko iskustvo.<\/p>\n

I na kraju, nemojte preopteretiti podatke, jasno pristupite ugovoru izme\u0111u potro\u0161a\u010da i dobavlja\u010da.<\/p>\n

Organizacijska transformacija<\/h2>\n

Ero\u0161kina Jelena, zamjenica direktora za IT<\/em><\/p>\n

U trenutku kada je do\u0161lo do karantene i nastala potreba za brzom digitalizacijom i uvo\u0111enjem omnichannel usluga, ve\u0107 smo bili u procesu organizacijske transformacije. <\/p>\n

Dio na\u0161e strukture pre\u0161ao je na rad prema principima i praksama produktnog pristupa. Formirane su ekipe koje sada odgovaraju za funkcioniranje i razvoj svakog proizvoda. Zaposlenici u tim timovima anga\u017eirani su 100% i organiziraju svoj rad prema Scrum ili Kanban metodi, ovisno o tome \u0161to im vi\u0161e odgovara, postavljaju konvejer za implementaciju, uvode tehni\u010dke prakse, prakse osiguravanja kvalitete i mnogo toga drugog.<\/p>\n

Sretna okolnost je da je ve\u0107ina tih produktnih timova radila u podru\u010dju online i omnichannel usluga. To nam je omogu\u0107ilo da u najkra\u0107em mogu\u0107em roku (ozbiljno, doslovno za dva dana) pre\u0111emo u re\u017eim rada na daljinu bez gubitka u\u010dinkovitosti. Uspostavljeni proces omogu\u0107io je brzu prilagodbu novim uvjetima rada i odr\u017eavanje prili\u010dno visokog tempa isporuke nove funkcionalnosti.<\/p>\n

Osim toga, nastala je potreba da osna\u017eimo timove koji su na prvoj liniji online posla. U tom trenutku postalo je jasno da to mo\u017eemo u\u010diniti samo kori\u0161tenjem unutarnjih resursa. Otprilike 50 ljudi je u roku od dva tjedna promijenilo podru\u010dje rada i uklju\u010dilo se u rad na novom proizvodu. <\/p>\n

Za to nisu bila potrebna posebna upravlja\u010dka nastojanja, jer uz organizaciju vlastitog procesa, tehni\u010dkim usavr\u0161avanjem proizvoda i praksom osiguravanja kvalitete, u\u010dimo na\u0161e timove samoupravljanju \u2014 upravljaju vlastitim proizvodnim procesom bez uklju\u010divanja administrativnih resursa.<\/p>\n

Upravlja\u010dki resurs smo uspjeli fokusirati upravo tamo gdje je to bilo potrebno u tom trenutku \u2014 na koordinaciju s poslovanjem: \u0160to je sada va\u017eno za na\u0161eg klijenta, koja funkcionalnost treba biti prioritetno realizirana, \u0161to treba u\u010diniti kako bismo pove\u0107ali na\u0161u propusnost u dostavi i obradi narud\u017ebi. Sve to i jasna uloga omogu\u0107ili su nam tijekom ovog razdoblja da opteretimo na\u0161e proizvodne tokove stvaranja vrijednosti onim \u0161to zaista jest va\u017eno i potrebno. <\/p>\n

Jasno je da se u uvjetima daljinskog rada i visoke dinamike promjena, kada poslovni pokazatelji ovise o sudjelovanju svakoga, ne mo\u017ee oslanjati isklju\u010divo na unutarnje osje\u0107aje poput \u201eJe li sve dobro? Pa, izgleda da jest\u201c. Potrebne su objektivne metrike proizvodnog procesa. One su nam dostupne, svakome tko se interesira za metrike produktnih timova. Prvenstveno samom timu, poslovanju, suradnicima i menad\u017ementu.<\/p>\n

Svaki drugi tjedan odr\u017eava se sastanak sa svakim timom gdje se tijekom 10 minuta analizira metrike, identificiraju uska mjesta u proizvodnom procesu i razvijaju zajedni\u010dka rje\u0161enja: \u0161to se mo\u017ee u\u010diniti za otklanjanje tih uskih mjesta. Tu se tako\u0111er mo\u017ee odmah zatra\u017eiti pomo\u0107 od vodstva ako neki identificirani problem le\u017ei izvan utjecaja timova, ili se mo\u017ee zatra\u017eiti stru\u010dnost kolega koji su se mo\u017eda ve\u0107 susreli s sli\u010dnim problemom.<\/p>\n

Ipak, razumijemo da za vi\u0161estruko ubrzanje (a to je cilj koji smo postavili) jo\u0161 mnogo toga moramo nau\u010diti i uvesti u svakodnevni rad. Trenutno nastavljamo s \u0161irenjem pristupa proizvodima na druge timove i nove proizvode. Da bismo to postigli, morali smo savladati novi format online \u0161kole metodologa.<\/p>\n

Metodolozi, ljudi koji poma\u017eu timovima da uspostave procese, pobolj\u0161aju komunikaciju i pove\u0107aju u\u010dinkovitost rada, zapravo su agenti promjena. Trenutno, diplomanti na\u0161e prve generacije rade s timovima i poma\u017eu im da postanu uspje\u0161ni. <\/p>\n

Mislim da trenutna situacija otvara pred nama mogu\u0107nosti i perspektive koje mo\u017eda sami jo\u0161 nismo potpuno svjesni. No iskustvo i praksa koju sada stje\u010demo potvr\u0111uju da smo odabrali pravi put razvoja, ne\u0107emo propustiti te nove mogu\u0107nosti u budu\u0107nosti i mo\u0107i \u0107emo jednako u\u010dinkovito odgovoriti na izazove koji \u0107e biti pred 'Sportmasterom'.<\/p>\n

Zaklju\u010dci<\/h3>\n

Tijekom ovog te\u0161kog razdoblja formulirali smo glavne principe na kojima se temelji razvoj softvera, koji \u0107e, mislim, biti relevantni za svaku tvrtku koja se tim bavi.<\/p>\n

Ljudi<\/strong>. To je ono na \u010demu sve po\u010diva. Zaposlenici trebaju u\u017eivati u radu, razumjeti ciljeve tvrtke i ciljeve proizvoda s kojima rade. I, naravno, moraju imati mogu\u0107nosti za profesionalni razvoj. <\/p>\n

Tehnologija<\/strong>. Potrebno je da tvrtka zrelo pristupa radu sa svojim tehnolo\u0161kim stogom i razvija kompetencije tamo gdje je to zaista potrebno. Zvu\u010di vrlo jednostavno i o\u010dito. A \u010desto se ignorira.<\/p>\n

Procesi<\/strong>. Va\u017eno je pravilno organizirati rad produktnih timova i centara kompetencija, uspostaviti suradnju s poslovanjem kako bi se radilo s njim kao s partnerom.<\/p>\n<\/p>\n

Uglavnom, otprilike tako smo i pre\u017eivjeli. Glavna teza modernog doba jo\u0161 jednom je potvr\u0111ena, zvu\u010dno udaraju\u0107i po \u010delu.<\/p>\n

\u010cak i ako si ogroman offline biznis s mno\u0161tvom trgovina i brojnim gradovima prisutnosti, razvijaj svoju online prisutnost. Ovo nije samo dodatni kanal prodaje ili lijepa aplikacija preko koje se tako\u0111er mo\u017ee ne\u0161to kupiti (a i zato \u0161to i konkurencija ima ne\u0161to sli\u010dno). Ovo nije rezervni kota\u010d za svaki slu\u010daj, koji \u0107e pomo\u0107i prebroditi oluju.<\/p>\n

To je apsolutna nu\u017enost. Na koju trebaju biti spremne ne samo va\u0161a tehni\u010dka snaga i infrastruktura, ve\u0107 i ljudi i procesi. Naime, brzo kupiti memoriju, prostor, implementirati nove instance i sli\u010dno mo\u017ee se obaviti u nekoliko sati. No, ljude i procese treba pripremati unaprijed.<\/p>\n<\/p>\n

Izvor: 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\udd47\u0160to nam je pomoglo brzo se prebaciti na online prodaju u novim uvjetima | ProHoster","description":"Bok! Zovem se Mihail, ja sam zamjenik direktora za IT u tvrtki 'Sportmaster'.","canonical_url":"https:\/\/prohoster.info\/hr\/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":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/94520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=94520"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/94520\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/94521"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=94520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=94520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=94520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}