{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"\u00abBitrix24\u00bb: \u00abAjo q\u00eb ngrihet shpejt nuk quhet se ka r\u00ebn\u00eb\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Aktualisht, sh\u00ebrbimi \"Bitrix24\" nuk ka qindra gigabit trafik, as nj\u00eb park t\u00eb madh serverash (edhe pse ekzistojn\u00eb disa). Por p\u00ebr shum\u00eb klient\u00eb, ai \u00ebsht\u00eb instrumenti kryesor i pun\u00ebs n\u00eb kompani, nj\u00eb aplikacion q\u00eb \u00ebsht\u00eb thelb\u00ebsor p\u00ebr biznesin. Prandaj, nuk duhet t\u00eb d\u00ebshtoj\u00eb. Por \u00e7far\u00eb n\u00ebse ndodhi nj\u00eb r\u00ebnie dhe sh\u00ebrbimi u rikuperua kaq shpejt sa askush nuk e vuri re? Si realizohet kjo mbrojtje pa humbje t\u00eb cil\u00ebsis\u00eb s\u00eb pun\u00ebs dhe numrit t\u00eb klient\u00ebve? Aleksand\u00ebr Demidov, drejtor i drejtimit t\u00eb sh\u00ebrbimeve cloud t\u00eb \"Bitrix24\", na tregoi p\u00ebr blogun ton\u00eb se si \u00ebsht\u00eb evoluar sistemi i rezervimit n\u00eb 7 vitet e ekzistenc\u00ebs s\u00eb produktit.<\/p>\n

\"\u00abBitrix24\u00bb:
\n<\/a><\/noindex>
\nNe lan\u00e7uam \"Bitrix24\" 7 vjet m\u00eb par\u00eb n\u00eb formatin SaaS. Sfid\u00ebn kryesore, ndoshta, e kishte n\u00eb k\u00ebt\u00eb: para lan\u00e7imit t\u00eb tij n\u00eb publik si SaaS, ky produkt ekzistonte thjesht n\u00eb formatin e zgjidhjes me kutin\u00eb. Klient\u00ebt e blejn\u00eb nga ne, e instalonin n\u00eb serverat e tyre, krijonin portalin korporativ - nj\u00eb zgjidhje e p\u00ebrbashk\u00ebt p\u00ebr komunikimin mes punonj\u00ebsve, ruajtjen e skedar\u00ebve, menaxhimin e detyrave, CRM, gjith\u00eb k\u00ebto. Dhe ne vendos\u00ebm n\u00eb vitin 2012 q\u00eb do t\u00eb donim ta lan\u00e7onim k\u00ebt\u00eb si SaaS, duke e administruar vet\u00eb, duke siguruar q\u00ebndrushm\u00ebri dhe besueshm\u00ebri. Eksperienc\u00ebn e kemi fituar gjat\u00eb procesit, sepse deri n\u00eb at\u00eb koh\u00eb thjesht nuk e kishim - ishim vet\u00ebm prodhues t\u00eb programeve, jo ofrues sh\u00ebrbimesh. <\/p>\n

Kur lancuam sh\u00ebrbimin, e dinim se gj\u00ebja m\u00eb e r\u00ebnd\u00ebsishme ishte t\u00eb siguronim q\u00ebndrushm\u00ebri, besueshm\u00ebri dhe p\u00ebrhershm\u00ebri t\u00eb aksesit n\u00eb sh\u00ebrbim, sepse n\u00ebse keni nj\u00eb faqe t\u00eb zakonshme, nj\u00eb dyqan, p\u00ebr shembull, dhe ajo d\u00ebshton p\u00ebr nj\u00eb or\u00eb - ju vet\u00ebm vuani, humbni porosi, humbni klient\u00eb, por p\u00ebr klientin tuaj - p\u00ebr t\u00eb nuk \u00ebsht\u00eb shum\u00eb kritike. Sigurisht, ai do t\u00eb shqet\u00ebsohet, por do t\u00eb shkoj\u00eb dhe do t\u00eb blej\u00eb n\u00eb nj\u00eb tjet\u00ebr faqe. Por n\u00ebse \u00ebsht\u00eb nj\u00eb aplikacion, mbi t\u00eb cilin mb\u00ebshtetet e gjith\u00eb puna brenda kompanis\u00eb, komunikimi, vendimmarrja, ajo q\u00eb \u00ebsht\u00eb thelb\u00ebsore - \u00ebsht\u00eb t\u00eb fitojm\u00eb besimin e p\u00ebrdoruesve, pra, t\u00eb mos i l\u00ebm\u00eb ata pas dhe t\u00eb mos d\u00ebshtojm\u00eb. Sepse e gjith\u00eb puna mund t\u00eb ndalet n\u00ebse di\u00e7ka brenda nuk funksionon.<\/p>\n

Bitrix.24 si SaaS<\/h4>\n

\nPrototipi i par\u00eb e kemi mbledhur nj\u00eb vit para lan\u00e7imit publik, n\u00eb vitin 2011. E mbledh\u00ebm p\u00ebr rreth nj\u00eb jav\u00eb, e shikuam, e testuam \u2013 madje ishte funksional. Dometh\u00ebn\u00eb, mund t\u00eb hynim n\u00eb form\u00eb, t\u00eb shkruanim emrin e portalit, dhe krijohej nj\u00eb portal i ri, duke u hapur baza e p\u00ebrdoruesve. E shikuam, e vler\u00ebsuam produktin n\u00eb p\u00ebrgjith\u00ebsi, e mbyll\u00ebm, dhe kaluam nj\u00eb vit duke e p\u00ebrmir\u00ebsuar. Sepse kishim nj\u00eb detyr\u00eb t\u00eb madhe: nuk donim t\u00eb b\u00ebnim dy baza kode t\u00eb ndryshme, nuk donim t\u00eb mb\u00ebshtetnim ve\u00e7mas produktin kutin\u00eb, ve\u00e7mas zgjidhjet cloud \u2013 donim t\u00eb b\u00ebnim gjith\u00e7ka brenda nj\u00eb kodi. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nNj\u00eb aplikacion tipik web n\u00eb at\u00eb koh\u00eb \u00ebsht\u00eb nj\u00eb server, n\u00eb t\u00eb cilin shkojm\u00eb nj\u00eb kod php, baza mysql, skedar\u00ebt ngarkohen, dokumentet, fotografit\u00eb vendosen n\u00eb dosjen upload \u2013 dhe gjith\u00e7ka funksionon. Fatkeq\u00ebsisht, nuk \u00ebsht\u00eb e mundur t\u00eb lansosh nj\u00eb sh\u00ebrbim web kritik q\u00eb mb\u00ebshtetet n\u00eb k\u00ebt\u00eb. Aty nuk mb\u00ebshtetet caching i shp\u00ebrndar\u00eb, nuk mb\u00ebshtetet replikimi i bazave t\u00eb t\u00eb dh\u00ebnave. <\/p>\n

Ne formuluam k\u00ebrkesat: t\u00eb jemi n\u00eb gjendje t\u00eb vendosim n\u00eb lokacione t\u00eb ndryshme, t\u00eb mb\u00ebshtesim replikimin, n\u00eb ideal t\u00eb vendosim n\u00eb qendra t\u00eb dh\u00ebnash q\u00eb jan\u00eb gjeografikisht t\u00eb shp\u00ebrndara. T\u00eb ndahet logjika e produktit dhe, konkretisht, ruajtja e t\u00eb dh\u00ebnave. T\u00eb jemi n\u00eb gjendje t\u00eb zgjeroheshim dinamikisht sipas ngarkes\u00ebs, statik\u00ebn ta transferojm\u00eb t\u00ebr\u00ebsisht. Nga k\u00ebto arsyetim, u formuan n\u00eb thelb k\u00ebrkesat p\u00ebr produktin q\u00eb ne pik\u00ebrisht gjat\u00eb vitit i p\u00ebrmir\u00ebsuam. N\u00eb k\u00ebt\u00eb koh\u00eb, n\u00eb platform\u00ebn q\u00eb rezultoi t\u00eb ishte e nj\u00ebjt\u00eb \u2013 p\u00ebr zgjidhjet kutin\u00eb, p\u00ebr sh\u00ebrbimin ton\u00eb t\u00eb vet \u2013 realizuam mb\u00ebshtetje p\u00ebr gj\u00ebrat q\u00eb na ishin t\u00eb nevojshme. Mb\u00ebshtetje p\u00ebr replikimin mysql n\u00eb nivelin e produktit: dometh\u00ebn\u00eb, zhvilluesi q\u00eb shkruan kod \u2013 nuk mendohet se si do t\u00eb shp\u00ebrndahen k\u00ebrkesat e tij, ai p\u00ebrdor API-n\u00eb ton\u00eb, dhe ne dim\u00eb t\u00eb shp\u00ebrndajm\u00eb sakt\u00ebsisht k\u00ebrkesat p\u00ebr t\u00eb shkruar dhe p\u00ebr t\u00eb lexuar mes masterave dhe slaveve. <\/p>\n

Ne realizuam mb\u00ebshtetje n\u00eb nivelin e produktit p\u00ebr ruajtjet e objektit cloud t\u00eb ndryshme: google storage, amazon s3 \u2013 p\u00ebrve\u00e7 k\u00ebsaj, mb\u00ebshtetje p\u00ebr open stack swift. Kjo ishte e p\u00ebrshtatshme p\u00ebr ne si sh\u00ebrbim dhe p\u00ebr zhvilluesit q\u00eb punojn\u00eb me zgjidhje kutie: n\u00ebse ata p\u00ebrdorin thjesht API-n\u00eb ton\u00eb p\u00ebr pun\u00eb, ata nuk mendojn\u00eb se ku n\u00eb fund do t\u00eb ruhen skedar\u00ebt, n\u00eb sistemin lokal t\u00eb skedar\u00ebve apo do t\u00eb p\u00ebrfundojn\u00eb n\u00eb ruajtjen e skedar\u00ebve t\u00eb objektit.<\/p>\n

N\u00eb fund vendos\u00ebm menj\u00ebher\u00eb q\u00eb do t\u00eb rezervonim n\u00eb nivelin e t\u00ebr\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave. N\u00eb vitin 2012, ne u lansuam plot\u00ebsisht n\u00eb Amazon AWS, pasi kishim p\u00ebrvoj\u00eb t\u00eb pun\u00ebs me k\u00ebt\u00eb platform\u00eb \u2014 faqja jon\u00eb e vetme ishte aty. Na t\u00ebrheqte fakti q\u00eb n\u00eb \u00e7do rajon n\u00eb Amazon ka disa zona disponueshm\u00ebrie \u2014 n\u00eb thelb, (n\u00eb terminologjin\u00eb e tyre) disa qendra t\u00eb t\u00eb dh\u00ebnave, t\u00eb cilat jan\u00eb m\u00eb shum\u00eb ose m\u00eb pak t\u00eb pavarura nga nj\u00ebra-tjetra dhe na lejojn\u00eb t\u00eb rezervojm\u00eb n\u00eb nivelin e t\u00ebr\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave: n\u00ebse ajo ndonj\u00ebher\u00eb d\u00ebshton, bazat replikohen master-master, server\u00ebt e aplikacioneve t\u00eb uebit jan\u00eb t\u00eb rezervuar, dhe statika \u00ebsht\u00eb transferuar n\u00eb sistemin e ruajtjes objektive s3. Ngarkesa balancohet \u2014 n\u00eb at\u00eb koh\u00eb nga elb i Amazon, por pak m\u00eb von\u00eb erdh\u00ebm tek balancuesit tan\u00eb, sepse na duhej nj\u00eb logjik\u00eb m\u00eb e komplikuar. <\/p>\n

\u00c7far\u00eb donim - at\u00eb mor\u00ebm...<\/h4>\n

\nT\u00eb gjitha gj\u00ebrat bazike q\u00eb ne donim t\u00eb siguroheshim - q\u00ebndrueshm\u00ebria e vet\u00eb server\u00ebve, aplikacioneve ueb, bazave t\u00eb t\u00eb dh\u00ebnave - gjith\u00e7ka funksiononte mir\u00eb. Scenari m\u00eb i thjesht\u00eb: n\u00ebse na d\u00ebshton ndonj\u00eb nga aplikacionet e uebit, at\u00ebher\u00eb gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb - ato fik\u00ebn nga balancimi. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nMakinat e dal\u00eb jasht\u00eb funksionit balancuesi (at\u00ebher\u00eb ishte elb i Amazon) i sh\u00ebnonte automatikisht si unhealthy, ndalte shp\u00ebrndarjen e ngarkes\u00ebs te ato. Punonte auto-skalimi i Amazon: kur ngarkesa rritej, makina t\u00eb reja shtoheshin n\u00eb grupin e auto-skalimit, ngarkesa shp\u00ebrndahej te makinat e reja - gjith\u00e7ka ishte mir\u00eb. Me balancuesit tan\u00eb logjika \u00ebsht\u00eb m\u00eb pak e nj\u00ebjt\u00eb: n\u00ebse ndodh di\u00e7ka me serverin e aplikacioneve, ne heqim k\u00ebrkesat nga ai, heqim k\u00ebto makina, nis\u00ebm t\u00eb reja dhe vazhdojm\u00eb t\u00eb punojm\u00eb. Schema p\u00ebr gjith\u00eb k\u00ebto vite ka ndryshuar pak, por vazhdon t\u00eb funksionoj\u00eb: ajo \u00ebsht\u00eb e thjesht\u00eb, e qart\u00eb, dhe nuk ka asnj\u00eb v\u00ebshtir\u00ebsi me k\u00ebt\u00eb. <\/p>\n

Ne punojm\u00eb n\u00eb mbar\u00eb bot\u00ebn, kulmet e ngarkes\u00ebs te klient\u00ebt jan\u00eb krejt\u00ebsisht t\u00eb ndryshme, dhe, n\u00eb thelb, duhet t\u00eb kemi mund\u00ebsin\u00eb t\u00eb kryejm\u00eb ato ose ato punime sh\u00ebrbimi me \u00e7do komponent t\u00eb sistemit ton\u00eb n\u00eb \u00e7do koh\u00eb \u2013 pa u v\u00ebn\u00eb re nga klient\u00ebt. Prandaj kemi mund\u00ebsin\u00eb t\u00eb fikim nga puna baz\u00ebn e t\u00eb dh\u00ebnave, duke shp\u00ebrndar\u00eb ngarkes\u00ebn n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave. <\/p>\n

Si si ndihmoni q\u00eb t\u00eb gjith\u00e7ka t\u00eb funksionoj\u00eb? \u2014 Ne transferojm\u00eb trafikun n\u00eb qendr\u00ebn e t\u00eb dh\u00ebnave q\u00eb punon \u2014 n\u00ebse ka nj\u00eb emergjenc\u00eb n\u00eb qendr\u00ebn e t\u00eb dh\u00ebnave, at\u00ebher\u00eb e b\u00ebjm\u00eb plot\u00ebsisht, n\u00ebse jan\u00eb pun\u00ebt tona t\u00eb planifikuara me ndonj\u00eb baz\u00eb specifike, at\u00ebher\u00eb ne transferojm\u00eb pjes\u00ebn e trafikut q\u00eb sh\u00ebrben p\u00ebr ato klient\u00eb n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave dhe nd\u00ebrpresim replikimin. N\u00ebse ne na nevojiten makina t\u00eb reja p\u00ebr aplikacionet web, pasi \u00ebsht\u00eb rritur ngarkesa n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave, ato fillojn\u00eb automatikisht. P\u00ebrfundojm\u00eb pun\u00ebt, rivendosim replikimin dhe kthejm\u00eb gjith\u00eb ngarkes\u00ebn prapa. N\u00ebse na duhen t\u00eb kryejm\u00eb ndonj\u00eb pun\u00eb t\u00eb dyfisht\u00eb n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave, p\u00ebr shembull, t\u00eb instalojm\u00eb p\u00ebrdit\u00ebsime sistemike ose t\u00eb nd\u00ebrruam cil\u00ebsimet n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb dyt\u00eb, at\u00ebher\u00eb, n\u00eb p\u00ebrgjith\u00ebsi, p\u00ebrs\u00ebrisim t\u00eb nj\u00ebjtat procedura, thjesht n\u00eb drejtimin tjet\u00ebr. Dhe n\u00ebse ka nj\u00eb emergjenc\u00eb, ne vepruam n\u00eb m\u00ebnyr\u00eb t\u00eb thjesht\u00eb: n\u00eb sistemin e monitorimit p\u00ebrdorim mekanizmin e event-handlers. N\u00ebse disa kontrolla aktivizohen dhe statusi kalon n\u00eb kritike, at\u00ebher\u00eb nisi ky handler, p\u00ebrpunuesi, i cili mund t\u00eb ekzekutoj\u00eb logjik\u00ebn p\u00ebrkat\u00ebse. P\u00ebr \u00e7do baz\u00eb t\u00eb dh\u00ebnash kemi t\u00eb p\u00ebrshkruar se cili server \u00ebsht\u00eb p\u00ebr t\u00eb dhe ku duhet transferuar trafiku n\u00eb rast se ajo nuk \u00ebsht\u00eb e qasshme. Ne \u2014 si\u00e7 ndodhi historikisht \u2014 p\u00ebrdorim n\u00eb nj\u00eb form\u00eb ose nj\u00eb tjet\u00ebr Nagios ose ndonj\u00eb nga deg\u00ebzimet e tij. N\u00eb parim, mekanizma t\u00eb till\u00eb ka pothuajse n\u00eb \u00e7do sistem monitorimi, nuk po p\u00ebrdorim di\u00e7ka m\u00eb t\u00eb komplikuar deri tani, por ndoshta nj\u00eb dit\u00eb do ta b\u00ebjm\u00eb. Tani monitorimi aktivizohet n\u00eb rast t\u00eb pap\u00ebrshtatshm\u00ebris\u00eb dhe ka mund\u00ebsin\u00eb p\u00ebr t\u00eb transferuar di\u00e7ka.<\/p>\n

A kemi rezervuar gjith\u00e7ka?<\/h4>\n

\nNe kemi shum\u00eb klient\u00eb nga SHBA, shum\u00eb klient\u00eb nga Evropa, shum\u00eb klient\u00eb q\u00eb jan\u00eb m\u00eb af\u00ebr Lindjes \u2014 Japoni, Singapor dhe k\u00ebshtu me radh\u00eb. Sigurisht, nj\u00eb pjes\u00eb e madhe e klient\u00ebve \u00ebsht\u00eb n\u00eb Rusi. Pra, puna nuk p\u00ebrfshin vet\u00ebm nj\u00eb rajon. P\u00ebrdoruesit d\u00ebshirojn\u00eb reagim t\u00eb shpejt\u00eb, ka k\u00ebrkesa p\u00ebr respektimin e ligjeve t\u00eb ndryshme lokale, dhe brenda \u00e7do regjioni ne rezervojm\u00eb dy qendra t\u00eb t\u00eb dh\u00ebnave, plus ka disa sh\u00ebrbime shtes\u00eb q\u00eb gjithashtu jan\u00eb t\u00eb p\u00ebrshtatshme t\u00eb vendosen brenda nj\u00eb rajoni \u2014 p\u00ebr klient\u00ebt q\u00eb punojn\u00eb n\u00eb at\u00eb rajon. Menaxher\u00ebt REST, server\u00ebt e autorizimit, jan\u00eb m\u00eb pak kritik\u00eb p\u00ebr pun\u00ebn e klientit si nj\u00eb e t\u00ebr\u00eb, p\u00ebr ta mund t\u00eb kaloni me nj\u00eb vones\u00eb t\u00eb pranueshme, por nuk d\u00ebshirojm\u00eb t\u00eb shpikim bi\u00e7ikleta, si t'i monitorojm\u00eb dhe \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb me to. Prandaj, ne p\u00ebrpiqemi maksimalisht t\u00eb p\u00ebrdorim zgjidhjet ekzistuese, dhe jo t\u00eb zhvillojm\u00eb ndonj\u00eb kompetenc\u00eb p\u00ebr produkte shtes\u00eb. Diku p\u00ebrdorim thjesht kalimin n\u00eb nivelin dns, dhe p\u00ebrve\u00e7 k\u00ebsaj, caktimin e sh\u00ebrbimit e p\u00ebrcaktojm\u00eb me t\u00eb nj\u00ebjtin dns. N\u00eb Amazon ka sh\u00ebrbimin Route 53, por kjo nuk \u00ebsht\u00eb vet\u00ebm dns, ku mund t\u00eb regjistroni disa sh\u00ebnime dhe mbaroi \u2014 ai \u00ebsht\u00eb shum\u00eb m\u00eb fleksib\u00ebl dhe i p\u00ebrshtatsh\u00ebm. N\u00ebp\u00ebrmjet tij, mund t\u00eb krijoni sh\u00ebrbime t\u00eb shp\u00ebrndara gjeo-me gjeolokacione, kur me ndihm\u00ebn e tij p\u00ebrcaktoni nga erdhi klienti dhe i jepni ato ose ato sh\u00ebnime \u2014 me ndihm\u00ebn e tij mund t\u00eb nd\u00ebrtoni arkitektura failover. Po ashtu kontrollet e sh\u00ebndetit konfigurohen n\u00eb vet\u00eb Route 53, ju caktoni endpointet q\u00eb monitorohen, caktoni metrikat, caktoni se me \u00e7far\u00eb protokollesh t\u00eb p\u00ebrcaktoni \"jet\u00ebsin\u00eb\" e sh\u00ebrbimit \u2014 tcp, http, https; caktoni periodicitetin e kontrolleve q\u00eb p\u00ebrcaktojn\u00eb, n\u00ebse sh\u00ebrbimi \u00ebsht\u00eb aktiv apo jo. Dhe n\u00eb vet\u00eb dns, ju shkruani se \u00e7far\u00eb do t\u00eb jet\u00eb primar, \u00e7far\u00eb do t\u00eb jet\u00eb sekondar, ku do t\u00eb kaloni n\u00ebse funksionon kontrolli i sh\u00ebndetit brenda route 53. T\u00eb gjitha k\u00ebto mund t\u00eb b\u00ebhen me disa mjetet t\u00eb tjera, por ajo q\u00eb \u00ebsht\u00eb e p\u00ebrshtatshme \u2014 e konfiguroni nj\u00eb her\u00eb dhe pastaj nuk mendojm\u00eb fare p\u00ebr se si b\u00ebhen kontrollimet, si ndodh kalimi: gjith\u00e7ka funksionon vet\u00eb.<\/p>\n

E para \"por\"<\/b>: si dhe me \u00e7far\u00eb duhet t\u00eb b\u00ebjm\u00eb \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u043c \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438 53? Ndoshta ndodh ndonj\u00eb gj\u00eb me t\u00eb? Fatmir\u00ebsisht, ne nuk kemi pasur asnj\u00ebher\u00eb ndonj\u00eb problem me k\u00ebt\u00eb, por gjithsesi, un\u00eb kam p\u00ebr t\u00eb treguar se pse menduam se duhet ta rezervojm\u00eb. K\u00ebtu po e p\u00ebrgatitim vetveten paraprakisht. K several her\u00eb n\u00eb dit\u00eb, ne b\u00ebjm\u00eb nj\u00eb eksport t\u00eb plot\u00eb t\u00eb t\u00eb gjitha zonave q\u00eb kemi n\u00eb \u043c\u0430\u0440\u0448\u0440\u0443\u0442 53. API i Amazon-it lejon t\u00eb nxjerrim ato leht\u00ebsisht n\u00eb JSON, dhe ne kemi ngritur disa server\u00eb rezerv\u00eb, ku ne e konvertojm\u00eb k\u00ebt\u00eb informacion, e eksportojm\u00eb n\u00eb form\u00eb konfiguracionesh dhe kemi, thjesht, nj\u00eb konfigurim rezerv\u00eb. N\u00eb rast nevoje, ne mund ta rikthejm\u00eb at\u00eb manualisht shpejt, pa humbur t\u00eb dh\u00ebnat e konfigurimeve DNS.<\/p>\n

Porosia e dyt\u00eb<\/b>: \u00e7far\u00eb tjet\u00ebr nuk \u00ebsht\u00eb rezervuar n\u00eb k\u00ebt\u00eb skenar? Balancuesi vet\u00eb! Ne kemi ndarjen e klient\u00ebve sipas rajoneve b\u00ebr\u00eb shum\u00eb thjesht. Kemi disa domen\u00eb si bitrix24.ru, bitrix24.com, .de \u2014 tani jan\u00eb rreth 13 t\u00eb ndrysh\u00ebm, t\u00eb cil\u00ebt punojn\u00eb n\u00eb zona shum\u00eb t\u00eb ndryshme. Arrit\u00ebm n\u00eb p\u00ebrfundimin se n\u00eb \u00e7do rajon ka balancues t\u00eb vet. K\u00ebshtu \u00ebsht\u00eb m\u00eb e leht\u00eb t\u00eb ndahen sipas rajoneve, n\u00eb var\u00ebsi t\u00eb ngarkes\u00ebs maksimale n\u00eb rrjet. N\u00ebse ka nj\u00eb gabim n\u00eb nivelin e ndonj\u00eb balancuesi, ai thjesht p\u00ebrjashtohet nga p\u00ebrdorimi dhe hiqet nga dns. N\u00ebse ndodh ndonj\u00eb problem me grupin e balancuesve, ata rezervohen n\u00eb platformat e tjera, dhe kalimi midis tyre b\u00ebhet me an\u00eb t\u00eb route53, sepse p\u00ebr shkak t\u00eb ttl t\u00eb shkurt\u00ebr, kalimi ndodh maksimumi brenda 2, 3, 5 minutash. <\/p>\n

Porosia e tret\u00eb<\/b>: \u00e7far\u00eb tjet\u00ebr nuk \u00ebsht\u00eb rezervuar? S3, e sakt\u00eb. Ne, kur vendosim skedar\u00ebt q\u00eb ruajm\u00eb p\u00ebr p\u00ebrdoruesit n\u00eb s3, kemi besuar sinqerisht se \u00ebsht\u00eb mbi \u00e7do k\u00ebrkes\u00eb dhe nuk ka nevoj\u00eb p\u00ebr rezervim atje. Por historia tregon se ndodhin ndryshe gj\u00ebrat. N\u00eb p\u00ebrgjith\u00ebsi, Amazon e p\u00ebrshkruan S3 si nj\u00eb sh\u00ebrbim thelb\u00ebsor, sepse vet\u00eb Amazon p\u00ebrdor S3 p\u00ebr ruajtjen e imazheve t\u00eb makinave, konfigurimeve, imazheve AMI, snapshot-eve... Dhe n\u00ebse S3 d\u00ebshton, si\u00e7 ka ndodhur nj\u00eb her\u00eb gjat\u00eb k\u00ebtyre 7 viteve q\u00eb e p\u00ebrdorim bitrix24, ai merr me vete shum\u00eb gj\u00ebra \u2014 pamund\u00ebsin\u00eb e fillimit t\u00eb virtualkave, gabim n\u00eb funksionimin e api-s\u00eb dhe k\u00ebshtu me radh\u00eb. <\/p>\n

Edhe S3 mund t\u00eb d\u00ebshtoj\u00eb - ndodhi nj\u00ebher\u00eb. Prandaj, ne arrit\u00ebm n\u00eb skem\u00ebn e ardhshme: disa vite m\u00eb par\u00eb nuk kishte ruajtje publike t\u00eb objekteve serioze n\u00eb Rusi, dhe ne po shqyrtonim mund\u00ebsin\u00eb p\u00ebr t\u00eb b\u00ebr\u00eb di\u00e7ka ton\u00ebn... P\u00ebr fat, nuk e filluam k\u00ebt\u00eb, pasi do t\u00eb ishim n\u00eb v\u00ebshtir\u00ebsi me ekspertiz\u00ebn q\u00eb nuk e kishim dhe sigurisht do t\u00eb kishim gabuar. Tani, ka ruajtje q\u00eb jan\u00eb t\u00eb pajtueshme me s3 nga Mail.ru, ka nga Yandex dhe disa ofrues t\u00eb tjer\u00eb. N\u00eb fund, arrit\u00ebm n\u00eb p\u00ebrfundimin se d\u00ebshironim t\u00eb kishim, nga nj\u00ebra an\u00eb, rezervim dhe, nga ana tjet\u00ebr, mund\u00ebsin\u00eb p\u00ebr t\u00eb punuar me kopje lokale. P\u00ebr rajonin konkret rus, ne p\u00ebrdorim sh\u00ebrbimin Mail.ru Hotbox, i cili \u00ebsht\u00eb i pajtuesh\u00ebm me s3 p\u00ebrmes api. Nuk na nevojiteshin ndryshime t\u00eb m\u00ebdha n\u00eb kodin e brendsh\u00ebm t\u00eb aplikacionit, dhe ne krijuam mekanizmin e m\u00ebposht\u00ebm: n\u00eb s3 ka sinjale, t\u00eb cilat aktivizohen kur krijohen\/fshihen objekte, Amazon ka nj\u00eb sh\u00ebrbim t\u00eb till\u00eb si Lambda - kjo \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb ekzekutuar kod pa server, e cila do t\u00eb ekzekutohet kur t\u00eb aktivizohen ato sinjale t\u00eb caktuara.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nE b\u00ebm\u00eb shum\u00eb thjesht: n\u00ebse aktivizohet nj\u00eb sinjal, ne ekzekutojm\u00eb kodin q\u00eb kopjon objektin n\u00eb ruajtjen e Mail.ru. P\u00ebr t\u00eb filluar plot\u00ebsisht pun\u00ebn me kopjet lokale t\u00eb t\u00eb dh\u00ebnave, na nevojitet gjithashtu nj\u00eb sinkronizim prapavij\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb klient\u00ebt q\u00eb ndodhen n\u00eb segmentin rus t\u00eb mund t\u00eb punojn\u00eb me ruajtjen e cila \u00ebsht\u00eb m\u00eb af\u00ebr tyre. Mail sapo ka p\u00ebrfunduar shtesat e sinjalizimeve n\u00eb ruajtjen e tij - do t\u00eb jet\u00eb e mundur p\u00ebr t\u00eb ekzekutuar sinkronizimin prapavij\u00eb n\u00eb nivelin e infrastruktur\u00ebs, p\u00ebr momentin ne e b\u00ebjm\u00eb k\u00ebt\u00eb n\u00eb nivelin e kodit ton\u00eb. N\u00ebse shohim se nj\u00eb klient ka vendosur nj\u00eb skedar, at\u00ebher\u00eb ne n\u00eb nivelin ton\u00eb t\u00eb kodit vendosim nj\u00eb ngjarje n\u00eb radh\u00eb, e procesojm\u00eb at\u00eb dhe kryejm\u00eb replikimin prapavij\u00eb. \u00c7far\u00eb \u00ebsht\u00eb problematike: n\u00ebse ndodhin ndonj\u00eb aktivitet me objektet tona jasht\u00eb produktit ton\u00eb, do t\u00eb thot\u00eb me ndihm\u00ebn e disa mjeteve t\u00eb jashtme, ne nuk do ta marrim parasysh. Prandaj ne po presim deri n\u00eb fund, kur t\u00eb shfaqen sinjalizimet n\u00eb nivelin e ruajtjes, q\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur nga vendi ku e ekzekutuam kodin, objekti q\u00eb na erdhi t\u00eb kopjohet n\u00eb an\u00ebn tjet\u00ebr. <\/p>\n

N\u00eb nivelin e kodit, p\u00ebr \u00e7do klient regjistrojm\u00eb t\u00eb dy depozitat: nj\u00ebra konsiderohet kryesore, tjetra si rezerv\u00eb. N\u00ebse gjith\u00e7ka shkon mir\u00eb, punojm\u00eb me at\u00eb depozit\u00eb q\u00eb \u00ebsht\u00eb m\u00eb af\u00ebr: pra, klient\u00ebt tan\u00eb q\u00eb jan\u00eb n\u00eb Amazon, p\u00ebrdorin S3, nd\u00ebrsa ata q\u00eb punojn\u00eb n\u00eb Rusi, p\u00ebrdorin Hotbox. N\u00ebse ndizet sinjali, duhet t\u00eb aktivizohet failover, dhe ne i kalojm\u00eb klient\u00ebt n\u00eb nj\u00eb depozit\u00eb tjet\u00ebr. Ne mund ta vendosim k\u00ebt\u00eb sinjal n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur sipas rajoneve dhe t\u2019i switchojm\u00eb aty-k\u00ebtu. N\u00eb praktik\u00eb akoma nuk e kemi p\u00ebrdorur, por mekanizmi \u00ebsht\u00eb parashikuar dhe mendojm\u00eb se nj\u00eb her\u00eb do na nevojitet kalimi dhe do t\u00eb jet\u00eb i dobish\u00ebm. Nj\u00eb her\u00eb ka ndodhur tashm\u00eb. <\/p>\n

O, por Amazon u largua nga ju...<\/h4>\n

\nKy prill sh\u00ebnon p\u00ebrvjetorin e fillimit t\u00eb bllokimeve t\u00eb Telegram n\u00eb Rusi. Operatori m\u00eb i goditur nga kjo \u00ebsht\u00eb Amazon. Dhe, fatkeq\u00ebsisht, kompanit\u00eb ruse t\u00eb cilat punonin p\u00ebr t\u00eb gjith\u00eb bot\u00ebn kan\u00eb pasur m\u00eb shum\u00eb humbje. <\/p>\n

N\u00ebse kompania \u00ebsht\u00eb globale dhe Rusia p\u00ebr t\u00eb \u00ebsht\u00eb nj\u00eb segment shum\u00eb i vog\u00ebl, 3-5% \u2014 k\u00ebshtu ose ndryshe, mund t\u00eb sakrifikohen. <\/p>\n

N\u00ebse kjo \u00ebsht\u00eb nj\u00eb kompani q\u00eb punon vet\u00ebm n\u00eb Rusi \u2014 jam i sigurt se duhet t\u00eb pozicionohet lokal \u2014 thjesht p\u00ebr p\u00ebrdoruesit do t\u00eb jet\u00eb m\u00eb e leht\u00eb, komode, dhe do t\u00eb ket\u00eb m\u00eb pak rreziqe. <\/p>\n

Dhe n\u00ebse kjo \u00ebsht\u00eb nj\u00eb kompani q\u00eb punon globalisht, dhe ka p\u00ebraf\u00ebrsisht nj\u00eb num\u00ebr t\u00eb barabart\u00eb klient\u00ebsh nga Rusia dhe nga vende t\u00eb tjera? Lidhshm\u00ebria e segmenteve \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, dhe ata duhet t\u00eb punojn\u00eb s\u00eb bashku n\u00eb nj\u00eb m\u00ebnyr\u00eb ose n\u00eb nj\u00eb tjet\u00ebr. <\/p>\n

N\u00eb fund t\u00eb marsit 2018, Roskomnadzor d\u00ebrgoi nj\u00eb let\u00ebr operatoreve m\u00eb t\u00eb m\u00ebdhenj, duke njoftuar se kishin nd\u00ebrmend t\u00eb bllokonin disa miliona IP t\u00eb Amazon, p\u00ebr t\u00eb bllokuar\u2026 mesazherin Zello. Fal\u00eb k\u00ebtyre operator\u00ebve, ata p\u00ebrhap\u00ebn letr\u00ebn, dhe ndodhi e kuptuar se lidhshm\u00ebria me Amazon mund t\u00eb prisheshin. Ishte e premte, ne u fut\u00ebm n\u00eb panik te koleg\u00ebt tan\u00eb nga servers.ru, me fjal\u00ebt: \u201cMiq, na duhen disa servera, q\u00eb do t\u00eb jen\u00eb jo n\u00eb Rusi, jo n\u00eb Amazon, por, p\u00ebr shembull, diku n\u00eb Amsterdam\u201d, p\u00ebr t\u00eb pasur mund\u00ebsi t\u00eb pakt\u00ebn p\u00ebr ndonj\u00eb m\u00ebnyr\u00eb t\u00eb vendosim atje tonat. vpn<\/a> dhe proxy p\u00ebr disa endpoint-e, n\u00eb t\u00eb cilat ne nuk mund t\u00eb ndikojm\u00eb aspak, p\u00ebr shembull endpoint-et e s3 \u2014 nuk mund t\u00eb p\u00ebrpiqemi t\u00eb ngrisim nj\u00eb sh\u00ebrbim t\u00eb ri dhe t\u00eb marrim nj\u00eb IP tjet\u00ebr, gjithsesi na nevojitet t\u00eb lidhim me at\u00eb. Pasi e konfigurav\u00ebm, ngrit\u00ebm k\u00ebta server\u00eb brenda disa dit\u00ebsh dhe, n\u00eb p\u00ebrgjith\u00ebsi, ishim t\u00eb p\u00ebrgatitur deri n\u00eb momentin e fillimit t\u00eb bllokimeve. \u00cbsht\u00eb interesante q\u00eb RKN, duke par\u00eb gjith\u00eb buj\u00ebn dhe panikun e krijuar, tha: 'Jo, ne tani nuk do t\u00eb bllokojm\u00eb asgj\u00eb.' (Megjithat\u00eb, kjo ishte deri n\u00eb momentin kur filluan t\u00eb bllokojn\u00eb Telegram-in.) Pas krijimit t\u00eb mund\u00ebsive p\u00ebr t\u00eb shmangur dhe kuptuar q\u00eb bllokimi nuk u aplikua, megjithat\u00eb, ne nuk vendos\u00ebm t\u00eb merremi me k\u00ebt\u00eb \u00e7\u00ebshtje. Thjesht, si nj\u00eb mas\u00eb paraprake. <\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nDhe k\u00ebshtu, n\u00eb vitin 2019 ne jetojm\u00eb n\u00eb kushte bllokimesh. Un\u00eb dje n\u00eb mbr\u00ebmje po shikoja: rreth nj\u00eb milion IP vazhdojn\u00eb t\u00eb bllokohen. Megjithat\u00eb, Amazon u rivendos n\u00eb t\u00ebr\u00ebsi, gjat\u00eb pik\u00ebs arriti deri n\u00eb 20 milion adresash\u2026 N\u00eb p\u00ebrgjith\u00ebsi, realiteti \u00ebsht\u00eb se lidhshm\u00ebria, nj\u00eb lidhshm\u00ebri e mir\u00eb \u2014 mund t\u00eb mos ekzistoj\u00eb. Papritur. Ajo mund t\u00eb mos ekzistoj\u00eb p\u00ebr arsye teknike \u2014 zjarre, ekskavator\u00eb, \u00e7do gj\u00eb e till\u00eb. Ose, si\u00e7 e pam\u00eb, p\u00ebr arsye jo krejt\u00ebsisht teknike. Prandaj, ndoshta, dikush i madh dhe i fuqish\u00ebm, me AS-t\u00eb e tij, mund t\u00eb menaxhoj\u00eb ndryshe, \u2014 direkt lidhje dhe gj\u00ebra t\u00eb tjera tashm\u00eb n\u00eb nivelin l2. Por, n\u00eb variantin e thjesht\u00eb, si ne apo ndokush m\u00eb i vog\u00ebl, \u00ebsht\u00eb e dobishme t\u00eb kemi rezervar n\u00eb nivelin e server\u00ebve, t\u00eb ngritur diku tjet\u00ebr, me VPN t\u00eb konfigurara paraprakisht, proxy, me mund\u00ebsin\u00eb p\u00ebr t\u00eb kaluar shpejt n\u00eb konfigurimin e atyre segmenteve q\u00eb jan\u00eb kritike p\u00ebr lidhshm\u00ebrin\u00eb tuaj. Kjo na ka ndihmuar disa her\u00eb, kur filluan bllokimet e Amazon, ne e kaluam n\u00eb rastin m\u00eb t\u00eb keq pik\u00ebrisht trafikun S3, por gradualisht gjith\u00e7ka u zgjidh.<\/p>\n

Si t\u00eb rezervohet\u2026 nj\u00eb t\u00eb gjith\u00eb ofruesin?<\/h4>\n

\nAktualisht, ne nuk kemi nj\u00eb skenar p\u00ebr r\u00ebnien e t\u00eb gjith\u00eb Amazon. Ne kemi nj\u00eb skenar t\u00eb ngjash\u00ebm p\u00ebr Rusin\u00eb. Ne kemi p\u00ebrdorur nj\u00eb furnizues n\u00eb Rusi, nga i cili zgjodh\u00ebm disa vende. Dhe nj\u00eb vit m\u00eb par\u00eb, p\u00ebrball\u00ebm me nj\u00eb problem: pavar\u00ebsisht se ishin dy qendra t\u00eb t\u00eb dh\u00ebnave, n\u00eb nivelin e konfigurimit t\u00eb rrjetit t\u00eb furnizuesit mund t\u00eb kishte probleme q\u00eb do t\u00eb preknin t\u00eb dyja qendrat e t\u00eb dh\u00ebnave. Dhe mund t\u00eb p\u00ebrjetonim munges\u00eb aksesi n\u00eb t\u00eb dy vendet. Sigurisht, ashtu ndodhi. Ne p\u00ebrfundimisht rivler\u00ebsuam arkitektur\u00ebn ton\u00eb. Ajo nuk ka ndryshuar shum\u00eb, por tani n\u00eb Rusi kemi dy vende q\u00eb nuk jan\u00eb tek nj\u00eb furnizues, por tek dy t\u00eb ndrysh\u00ebm. N\u00ebse ndonj\u00ebher\u00eb ndodh nj\u00eb defekt n\u00eb nj\u00ebrin, ne mund t\u00eb kalojm\u00eb te tjetri.<\/p>\n

Hipotetikisht, ne p\u00ebr Amazon jemi duke shqyrtuar mund\u00ebsin\u00eb e rezervimit n\u00eb nivelin e nj\u00eb furnizuesi tjet\u00ebr; ndoshta Google, ndoshta dikush tjet\u00ebr... Por deri tani kemi v\u00ebzhguar n\u00eb praktik\u00eb se n\u00ebse ndodhin aksidente n\u00eb nivelin e nj\u00eb zone t\u00eb disponueshm\u00ebris\u00eb t\u00eb Amazon, aksidentet n\u00eb nivelin e nj\u00eb regioni t\u00eb t\u00ebr\u00eb jan\u00eb nj\u00eb fenomen mjaft t\u00eb rrall\u00eb. Prandaj, teorikisht kemi nj\u00eb ide se ndoshta do t\u00eb b\u00ebjm\u00eb rezervimin \"Amazon - jo Amazon\", por n\u00eb praktik\u00eb, deri tani nuk ka ndodhur. <\/p>\n

Nj\u00eb fjal\u00eb p\u00ebr automatizimin<\/h4>\n

\nA \u00ebsht\u00eb gjithmon\u00eb e nevojshme automatizimi? K\u00ebtu \u00ebsht\u00eb e p\u00ebrshtatshme t\u00eb kujtojm\u00eb efektin Dunning-Kruger. N\u00eb boshtin \"x\" jan\u00eb njohurit\u00eb dhe eksperienca q\u00eb ne grumbullojm\u00eb, dhe n\u00eb boshtin \"y\" - besimi n\u00eb veprimet tona. Fillimisht nuk dim\u00eb asgj\u00eb dhe nuk jemi t\u00eb sigurt. M\u00eb pas, dim\u00eb ca dhe b\u00ebhemi mega t\u00eb sigurt - kjo quhet \"pik\u00eb e marr\u00ebzis\u00eb\", e ilustruar mir\u00eb me imazhin \"budallall\u00ebku dhe guximi\". Pastaj, kemi m\u00ebsuar pak dhe jemi gati t\u00eb shkojm\u00eb n\u00eb betej\u00eb. M\u00eb pas, hasim ndonj\u00ebher\u00eb n\u00eb disa probleme serioze, p\u00ebrfundojm\u00eb n\u00eb lugin\u00ebn e d\u00ebshp\u00ebrimit, kur duket se dim\u00eb di\u00e7ka, por n\u00eb t\u00eb v\u00ebrtet\u00eb nuk dim\u00eb shum\u00eb. Pastaj, me sa m\u00eb shum\u00eb p\u00ebrvoj\u00eb, b\u00ebhemi m\u00eb t\u00eb sigurt\u00eb.<\/p>\n

\"\u00abBitrix24\u00bb:
\n
\nLogjika jon\u00eb p\u00ebr kalimet e ndryshme automatike n\u00eb aksidente t\u00eb caktuara p\u00ebrshkruhet shum\u00eb mir\u00eb nga kjo grafike. Ne filluam \u2014 nuk dinim asgj\u00eb, pothuajse gjith\u00eb pun\u00ebt b\u00ebnin manualisht. M\u00eb pas, e kuptuam se mund t\u00eb instalonim automatizim p\u00ebr gjith\u00e7ka dhe, n\u00eb thelb, t\u00eb flinim qet\u00eb. Papritmas, p\u00ebrball\u00ebm nj\u00eb ndarje t\u00eb madhe: na ndodhi nj\u00eb false positive dhe ne kalonim trafikun aty-k\u00ebtu, kur, me t\u00eb v\u00ebrtet\u00eb, \u00ebsht\u00eb e panevojshme ta b\u00ebjm\u00eb k\u00ebt\u00eb. Si pasoj\u00eb, ndodhnin probleme me replikimin ose di\u00e7ka tjet\u00ebr \u2014 kjo \u00ebsht\u00eb vallja e d\u00ebshp\u00ebrimit. Dhe pastaj arrijm\u00eb n\u00eb kuptimin se duhet t'i qasemi gjith\u00e7kaje me mend. Kjo do t\u00eb thot\u00eb se ka kuptim t\u00eb mb\u00ebshtetemi n\u00eb automatizim, duke parashikuar mund\u00ebsin\u00eb e gabimeve t\u00eb rreme. Por! n\u00ebse pasojat mund t\u00eb jen\u00eb shkat\u00ebrruese, at\u00ebher\u00eb \u00ebsht\u00eb m\u00eb mir\u00eb t'i l\u00ebm\u00eb ato n\u00eb duar t\u00eb ekipit t\u00eb ndihm\u00ebs, inxhinier\u00ebve n\u00eb detyr\u00eb, t\u00eb cil\u00ebt do t\u00eb sigurojn\u00eb dhe verifikojn\u00eb, me t\u00eb v\u00ebrtet\u00eb, n\u00ebse ka nj\u00eb aksident dhe se veprimet e nevojshme do t\u00eb kryhen me dor\u00eb...<\/p>\n

P\u00ebrfundim<\/h4>\n

\nGjat\u00eb 7 vjet\u00ebve, ne kaluam nga panika panikisht kur ndodhte ndonj\u00eb r\u00ebnie, n\u00eb kuptimin se problemet nuk ekzistojn\u00eb, por ka vet\u00ebm detyra q\u00eb duhet t'i zgjidhni \u2014 dhe q\u00eb \u00ebsht\u00eb e mundur. Kur ndiheni p\u00ebr t\u00eb nd\u00ebrtuar nj\u00eb sh\u00ebrbim, shikoni at\u00eb nga nj\u00eb k\u00ebndv\u00ebshtrim m\u00eb t\u00eb lart\u00eb, vler\u00ebsoni t\u00eb gjitha rreziqet q\u00eb mund t\u00eb ndodhin. N\u00ebse i parashikoni ato menj\u00ebher\u00eb \u2014 at\u00ebher\u00eb parashikoni rezerva dhe mund\u00ebsin\u00eb e nd\u00ebrtimit t\u00eb nj\u00eb infrastrukture t\u00eb q\u00ebndrueshme, sepse \u00e7do pik\u00eb q\u00eb mund t\u00eb d\u00ebshtoje dhe t\u00eb \u00e7onte n\u00eb mosfunksionimin e sh\u00ebrbimit \u2014 sigurisht do ta b\u00ebj\u00eb k\u00ebt\u00eb. Edhe n\u00ebse ju duket se disa elemente t\u00eb infrastruktur\u00ebs sigurisht nuk do t\u00eb dalin jasht\u00eb funksionit \u2014 si p.sh. s3, prap\u00ebseprap\u00eb, mbani mend se ata mund t\u00eb d\u00ebshtojn\u00eb. Dhe t\u00eb pakt\u00ebn n\u00eb teori, keni nj\u00eb ide p\u00ebr at\u00eb q\u00eb do t\u00eb b\u00ebni me ta n\u00ebse di\u00e7ka ndodh. Keni nj\u00eb plan p\u00ebr menaxhimin e rreziqeve. Kur mendoni se t\u00eb b\u00ebni gjith\u00e7ka me automatizim ose manualisht \u2014 vler\u00ebsoni rreziqet: \u00e7far\u00eb do t\u00eb ndodh\u00eb n\u00ebse automatizimi fillon t\u00eb kaloj\u00eb gjith\u00e7ka \u2014 a do t\u00eb \u00e7oj\u00eb kjo n\u00eb nj\u00eb situat\u00eb akoma m\u00eb t\u00eb keqe krahasuar me nj\u00eb aksident? Ndoshta, n\u00eb disa raste, duhet t\u00eb p\u00ebrdorni nj\u00eb kompromis t\u00eb arsyesh\u00ebm midis p\u00ebrdorimit t\u00eb automatizimit dhe reagimit t\u00eb inxhinier\u00ebve n\u00eb detyr\u00eb, t\u00eb cil\u00ebt do t\u00eb vler\u00ebsojn\u00eb situat\u00ebn reale dhe do t\u00eb kuptojn\u00eb n\u00ebse duhet t\u00eb kalojn\u00eb di\u00e7ka menj\u00ebher\u00eb ose \"po, por jo tani\".<\/p>\n

Nj\u00eb kompromis i arsyesh\u00ebm mes p\u00ebrsosm\u00ebris\u00eb dhe forcave reale, koh\u00ebs, parave q\u00eb mund t\u00eb shpenzoni p\u00ebr skem\u00ebn q\u00eb do t\u00eb keni n\u00eb fund.<\/p>\n

Ky tekst \u00ebsht\u00eb nj\u00eb version i zgjeruar dhe i plot\u00ebsuar i raportit t\u00eb Aleksand\u00ebr Demidov n\u00eb konferenc\u00eb Uptime dit\u00ebn 4<\/a><\/noindex>.<\/i>
\n
Burimi: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","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\udd47\"Bitrix24\": \"E ngritur shpejt nuk konsiderohet e r\u00ebn\u00eb\" | ProHoster","description":"Derisa, deri m\u00eb sot, sh\u00ebrbimi \"Bitrix24\" nuk ka qindra gigabit trafik, nuk ka nj\u00eb park t\u00eb madh server\u00ebsh (ndon\u00ebse ka disa ekzistues, sigurisht).","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e).","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","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":"2019-10-31T19:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","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":"2026-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/35092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}