{"id":77783,"date":"2020-04-14T01:42:28","date_gmt":"2020-04-13T23:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack"},"modified":"2020-04-14T01:42:28","modified_gmt":"2020-04-13T23:42:28","slug":"metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","title":{"rendered":"Metodologia de desf\u0103\u0219urare a proiectelor utilizat\u0103 \u00een Slack","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Lansarea unei noi versiuni a proiectului \u00een produc\u021bie necesit\u0103 respectarea atent\u0103 a echilibrului \u00eentre viteza desf\u0103\u0219ur\u0103rii \u0219i fiabilitatea solu\u021biei. La Slack, se apreciaz\u0103 itera\u021biile rapide, ciclurile scurte de feedback \u0219i reac\u021bia rapid\u0103 la solicit\u0103rile utilizatorilor. \u00cen plus, compania dispune de sute de programatori care \u00ee\u0219i doresc maxim\u0103 productivitate.<\/p>\n

\"Metodologia<\/a><\/noindex><\/p>\n

Autorii materialului, traducerea c\u0103ruia o public\u0103m ast\u0103zi, afirm\u0103 c\u0103 o companie care aspir\u0103 s\u0103 respecte astfel de valori \u0219i \u00een acela\u0219i timp se dezvolt\u0103, trebuie s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 \u00een mod constant sistemul s\u0103u de desf\u0103\u0219urare a proiectelor. Compania trebuie s\u0103 investeasc\u0103 \u00een transparen\u021ba \u0219i fiabilitatea proceselor de lucru, pentru a se asigura c\u0103 acestea sunt propor\u021bionale cu dimensiunea proiectului. Aici va fi vorba despre procesele de lucru dezvoltate \u00een Slack \u0219i despre unele solu\u021bii care au condus compania s\u0103 utilizeze ast\u0103zi sistemul existent de desf\u0103\u0219urare a proiectelor.
\n<\/a><\/noindex><\/p>\n

Cum func\u021bioneaz\u0103 ast\u0103zi procesele de desf\u0103\u0219urare a proiectelor<\/h2>\n

\nFiecare PR (pull request) \u00een Slack trebuie s\u0103 fie supus \u00een mod obligatoriu unei revizii de cod \u0219i s\u0103 treac\u0103 cu succes toate testele. Numai dup\u0103 ce aceste condi\u021bii sunt \u00eendeplinite, programatorul poate face fuziunea codului s\u0103u cu ramura master a proiectului. Totu\u0219i, desf\u0103\u0219urarea acestui cod are loc doar \u00een orele de lucru conform fusului orar nord-american. Prin urmare, av\u00e2nd \u00een vedere c\u0103 angaja\u021bii no\u0219tri sunt la locurile de munc\u0103, suntem complet preg\u0103ti\u021bi pentru a rezolva orice probleme nea\u0219teptate.<\/p>\n

\u00cen fiecare zi, efectu\u0103m aproximativ 12 desf\u0103\u0219ur\u0103ri planificate. \u00cen timpul fiec\u0103rei desf\u0103\u0219ur\u0103ri, programatorul desemnat ca responsabil de desf\u0103\u0219urare este responsabil pentru lansarea noii versiuni \u00een produc\u021bie. Acesta este un proces \u00een mai mul\u021bi pa\u0219i care asigur\u0103 o trecere lin\u0103 a versiunii \u00een modul de lucru. Datorit\u0103 acestui abord\u0103ri, putem identifica erorile \u00eenainte ca acestea s\u0103 afecteze to\u021bi utilizatorii no\u0219tri. Dac\u0103 se descoper\u0103 prea multe erori, desf\u0103\u0219urarea versiunii poate fi anulat\u0103. Dac\u0103 o problem\u0103 specific\u0103 este identificat\u0103 dup\u0103 lansare, poate fi emis\u0103 o corectare cu u\u0219urin\u021b\u0103.<\/p>\n

\"Metodologia
\nInterfa\u021ba sistemului Checkpoint, utilizat\u0103 \u00een Slack pentru desf\u0103\u0219urarea proiectelor<\/i><\/p>\n

Procesul de desf\u0103\u0219urare a unei noi versiuni \u00een produc\u021bie poate fi reprezentat prin patru pa\u0219i.<\/p>\n

\u258d1. Crearea unei ramuri de versiune<\/h3>\n

\nFiecare versiune \u00eencepe cu o nou\u0103 ramur\u0103 de versiune, de la un moment din istoria noastr\u0103 Git. Aceasta permite atribuirea de etichete versiunii \u0219i ofer\u0103 un loc unde pot fi aplicate corecturile rapide pentru erorile descoperite \u00een timpul preg\u0103tirii versiunii pentru lansare \u00een produc\u021bie.<\/p>\n

\u258d2. Desf\u0103\u0219urarea \u00een mediu intermediar<\/h3>\n

\nUrm\u0103torul pas \u00een proces este desf\u0103\u0219urarea construc\u021biei pe serverele intermediare (staging) \u0219i executarea testului automatizat pentru verificarea func\u021bionalit\u0103\u021bii generale a proiectului (smoke test). Mediu intermediar este un mediu de produc\u021bie care nu prime\u0219te trafic extern. \u00cen acest mediu, efectu\u0103m teste manuale suplimentare. Acest lucru ne ofer\u0103 o siguran\u021b\u0103 suplimentar\u0103 c\u0103 proiectul modificat func\u021bioneaz\u0103 corect. Doar testele automatizate nu sunt suficiente pentru a ob\u021bine o asemenea siguran\u021b\u0103.<\/p>\n

\u258d3. Desf\u0103\u0219urarea \u00een medii dogfood \u0219i canary<\/h3>\n

\nDesf\u0103\u0219urarea \u00een produc\u021bie \u00eencepe cu mediu dogfood, reprezentat de un set de gazde care asigur\u0103 spa\u021biile noastre de lucru interne Slack. Fiind utilizatori destul de activi ai Slack, aplicarea acestei abord\u0103ri ne-a ajutat s\u0103 descoperim numeroase erori \u00een stadii incipiente ale desf\u0103\u0219ur\u0103rii. Dup\u0103 ce ne-am asigurat c\u0103 func\u021bionalitatea de baz\u0103 a sistemului nu este afectat\u0103, desf\u0103\u0219ur\u0103m construc\u021bia \u00een mediu canary. Acesta reprezint\u0103 sistemele care primesc aproximativ 2% din trafic de produc\u021bie.<\/p>\n

\u258d4. Trecerea treptat\u0103 \u00een produc\u021bie<\/h3>\n

\nDac\u0103 indicatorii de monitorizare ai noii versiuni se dovedesc a fi stabili, iar dup\u0103 desf\u0103\u0219urarea proiectului \u00een mediu canary nu primim pl\u00e2ngeri, continu\u0103m trecerea treptat\u0103 a serverelor de produc\u021bie la noua versiune. Procesul de desf\u0103\u0219urare este \u00eemp\u0103r\u021bit \u00een etape: 10%, 25%, 50%, 75% \u0219i 100%. Ca rezultat, putem transfera \u00eencet traficul de produc\u021bie c\u0103tre noua versiune a sistemului. \u00cen acest fel, avem timp s\u0103 investig\u0103m situa\u021bia \u00een cazul \u00een care se descoper\u0103 anomalii.<\/p>\n

\u258dCe s\u0103 facem dac\u0103 ceva a mers prost \u00een timpul desf\u0103\u0219ur\u0103rii?<\/h3>\n

\nModific\u0103rile codului sunt \u00eentotdeauna riscante. Dar facem fa\u021b\u0103 acestei provoc\u0103ri datorit\u0103 \u00abresponsabililor de desf\u0103\u0219urare\u00bb bine preg\u0103ti\u021bi, care coordoneaz\u0103 procesul de lansare a noilor versiuni \u00een produc\u021bie, monitorizeaz\u0103 indicatorii \u0219i coordoneaz\u0103 activitatea programatorilor care lanseaz\u0103 cod.<\/p>\n

\u00cen cazul \u00een care ceva a mers gre\u0219it, \u00eencerc\u0103m s\u0103 identific\u0103m problema c\u00e2t mai repede posibil. Investig\u0103m problema, g\u0103sim PR-ul care cauzeaz\u0103 erorile, \u00eel respingem, analiz\u0103m cu aten\u021bie \u0219i cre\u0103m o nou\u0103 versiune. Totu\u0219i, uneori problema r\u0103m\u00e2ne nedetectat\u0103 p\u00e2n\u0103 la lansarea proiectului \u00een produc\u021bie. \u00cen aceast\u0103 situa\u021bie, cel mai important lucru este s\u0103 restabilim func\u021bionarea serviciului. Prin urmare, \u00eenainte de a \u00eencepe investiga\u021bia problemei, revenim imediat la cea mai recent\u0103 versiune care a func\u021bionat.<\/p>\n

Modulele sistemului de desf\u0103\u0219urare<\/h2>\n

\nS\u0103 analiz\u0103m tehnologiile care stau la baza sistemului nostru de desf\u0103\u0219urare a proiectelor.<\/p>\n

\u258dDesf\u0103\u0219ur\u0103ri rapide<\/h3>\n

\nProcesele de lucru descrise mai sus pot p\u0103rea, \u00een retrospectiv\u0103, complet evidente. Dar sistemul nostru de desf\u0103\u0219urare nu a ajuns la acest punct imediat.<\/p>\n

C\u00e2nd compania era mult mai mic\u0103, \u00eentregul nostru aplica\u021bie putea func\u021biona pe 10 instan\u021be Amazon EC2. Desf\u0103\u0219urarea unui proiect \u00een aceast\u0103 situa\u021bie \u00eensemna utilizarea rsync pentru sincronizarea rapid\u0103 a tuturor serverelor. Anterior, noul cod era separat de produc\u021bie doar printr-un singur pas, reprezentat de un mediu intermediar. Versiunile erau create \u0219i testate \u00een acest mediu, apoi mergeau direct \u00een produc\u021bie. Era foarte simplu s\u0103 \u00een\u021belegi un astfel de sistem, permitea oric\u0103rui programator s\u0103 desf\u0103\u0219oare codul scris de el oric\u00e2nd.<\/p>\n

Dar pe m\u0103sur\u0103 ce num\u0103rul clien\u021bilor a crescut, a crescut \u0219i dimensiunea infrastructurii necesare pentru a sus\u021bine proiectul. Cur\u00e2nd, \u00een contextul cre\u0219terii constante a sistemului, modelul nostru de desf\u0103\u0219urare, bazat pe trimiterea de cod nou pe servere, a \u00eenceput s\u0103 nu mai func\u021bioneze. Anume, ad\u0103ugarea fiec\u0103rui nou server a dus la cre\u0219terea timpului necesar pentru desf\u0103\u0219urare. Chiar \u0219i strategiile bazate pe aplicarea paralel\u0103 a rsync au anumite limit\u0103ri.<\/p>\n

\u00cen cele din urm\u0103, am rezolvat aceast\u0103 problem\u0103 trec\u00e2nd la un sistem de desf\u0103\u0219urare complet paralel, structurat diferit fa\u021b\u0103 de vechiul sistem. Mai precis, acum nu mai trimiteam cod pe servere folosind scripturi de sincronizare. Fiecare server desc\u0103rca acum singur noua versiune, afl\u00e2nd c\u0103 trebuie s\u0103 o fac\u0103 prin monitorizarea modific\u0103rii cheii Consul. Serverele desc\u0103rcau codul \u00een paralel. Acest lucru ne-a permis s\u0103 men\u021binem o vitez\u0103 mare de desf\u0103\u0219urare chiar \u0219i \u00een condi\u021biile unei cre\u0219teri constante a sistemului.<\/p>\n

\"Metodologia
\n1. Serverele de produc\u021bie monitorizeaz\u0103 cheia Consul. 2. Cheia se schimb\u0103, comunic\u00e2nd serverelor c\u0103 trebuie s\u0103 \u00eenceap\u0103 desc\u0103rcarea noului cod. 3. Serverele descarc\u0103 fi\u0219ierele tarball cu codul aplica\u021biei.<\/i><\/p>\n

\u258dDesf\u0103\u0219ur\u0103ri atomice<\/h3>\n

\nO alt\u0103 solu\u021bie care ne-a ajutat s\u0103 ajungem la un sistem de desf\u0103\u0219urare multi-nivel a fost desf\u0103\u0219urarea atomic\u0103.<\/p>\n

P\u00e2n\u0103 la utilizarea desf\u0103\u0219ur\u0103rilor atomice, fiecare desf\u0103\u0219urare putea duce la apari\u021bia unui num\u0103r mare de mesaje de eroare. Asta se datora faptului c\u0103 procesul de copiere a fi\u0219ierelor noi pe serverele de produc\u021bie nu eraatomic. Aceasta ducea la existen\u021ba unei perioade scurte de timp \u00een care codul care apelase func\u021bii noi devenea disponibil \u00eenainte ca aceste func\u021bii s\u0103 fie accesibile. C\u00e2nd un astfel de cod era apelat, acesta conducea la returnarea unor erori interne. Acest lucru se manifesta prin cereri nereu\u0219ite la API \u0219i prin pagini web \"stricate\".<\/p>\n

Echipa care s-a ocupat de aceast\u0103 problem\u0103 a rezolvat-o introduc\u00e2nd conceptele de directorii \"calde\" (hot) \u0219i \"reci\" (cold). Codul din directorul \"cald\" se ocup\u0103 de gestionarea traficului de produc\u021bie. \u00cen directorii \"reci\", codul se preg\u0103te\u0219te pentru utilizare \u00een timpul func\u021bion\u0103rii sistemului. \u00cen timpul desf\u0103\u0219ur\u0103rii, noul cod este copiat \u00een directorul \"rece\" neutilizat. Apoi, c\u00e2nd pe server nu mai exist\u0103 procese active, se face un switch instantaneu \u00eentre directoare.<\/p>\n

\"Metodologia
\n1. Dezarhivarea codului aplica\u021biei \u00een directorul \"rece\". 2. Schimbarea sistemului pe directorul \"rece\", care devine \"cald\" (opera\u021bie atomic\u0103)<\/i><\/p>\n

Concluzii: accentul pe fiabilitate<\/h2>\n

\n\u00cen 2018, proiectul a crescut at\u00e2t de mult \u00eenc\u00e2t desf\u0103\u0219urarea rapid\u0103 a \u00eenceput s\u0103 afecteze stabilitatea produsului. Am avut un sistem de desf\u0103\u0219urare destul de avansat, \u00een care am investit mult\u0103 munc\u0103 \u0219i timp. Trebuia doar s\u0103 reorganiz\u0103m \u0219i s\u0103 \u00eembun\u0103t\u0103\u021bim procesele de organizare a desf\u0103\u0219ur\u0103rii. Ne-am transformat \u00eentr-o companie destul de mare, iar solu\u021biile noastre erau utilizate \u00een \u00eentreaga lume pentru a asigura comunica\u021bii ne\u00eencetate \u0219i pentru a rezolva probleme importante. De aceea, fiabilitatea a devenit centrul aten\u021biei noastre.<\/p>\n

Trebuia s\u0103 facem procesul de desf\u0103\u0219urare a noilor versiuni Slack mai sigur. Aceast\u0103 necesitate ne-a condus la \u00eembun\u0103t\u0103\u021birea sistemului nostru de desf\u0103\u0219urare. De fapt, despre acest sistem \u00eembun\u0103t\u0103\u021bit am discutat mai sus. \u00cen ad\u00e2ncurile sistemului, continu\u0103m s\u0103 folosim tehnologii de desf\u0103\u0219urare rapid\u0103 \u0219i atomic\u0103. S-a schimbat modul \u00een care se desf\u0103\u0219oar\u0103 desf\u0103\u0219urarea. Noua noastr\u0103 sistem\u0103 este destinat\u0103 desf\u0103\u0219ur\u0103rii gradate a noului cod la diferite niveluri, \u00een diferite medii. Acum folosim instrumente auxiliare \u0219i instrumente de monitorizare mai avansate dec\u00e2t \u00eenainte. Aceasta ne ofer\u0103 posibilitatea de a captura \u0219i remedia erorile cu mult \u00eenainte ca ele s\u0103 ajung\u0103 la utilizatorul final.<\/p>\n

Dar nu ne oprim aici. \u00cembun\u0103t\u0103\u021bim constant acest sistem, aplic\u00e2nd instrumente auxiliare \u0219i solu\u021bii de automatizare mai avansate.<\/p>\n

Stima\u021bi cititori!<\/b> Cum este organizat procesul de desf\u0103\u0219urare a noilor versiuni ale proiectelor acolo unde lucra\u021bi dumneavoastr\u0103?<\/p>\n

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

\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","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\udd47Metodologia de desf\u0103\u0219urare a proiectelor utilizat\u0103 \u00een Slack | ProHoster","description":"Lansarea unei noi versiuni a proiectului \u00een produc\u021bie necesit\u0103 o respectare atent\u0103 a echilibrului \u00eentre viteza desf\u0103\u0219ur\u0103rii \u0219i fiabilitatea solu\u021biei.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\u041c\u0435\u0442\u043e\u0434\u0438\u043a\u0430 \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0435\u043c\u0430\u044f \u0432 Slack | ProHoster","og:description":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","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-04-13T23:42:28+00:00","article:modified_time":"2020-04-13T23:42:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77783","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"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 17:11:30","updated":"2026-08-11 12:50:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/77783","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=77783"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/77783\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/77784"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=77783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=77783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=77783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}