<\/a><\/noindex>DevOps vklju\u010duje mnogo razli\u010dnih konceptov (nene\u0161no dostavljanje, nene\u0161na integracija, avtomatizacija itd.), zato je lahko te\u017eko izlu\u0161\u010diti bistvo, \u0161e posebej, \u010de do teme niste brezbri\u017eni. Vendar je to znanje zelo koristno, ne glede na to, ali posku\u0161ate prenesti svoje ideje svojemu nadrejenemu ali pa preprosto pripovedujete o svojem delu nekomu izmed svojcev ali znancev. Zato bomo zaenkrat pustili ob strani terminolo\u0161ke nianse DevOpsa in se osredoto\u010dili na celotno sliko.<\/p>\n
Kaj je DevOps: 6 opredelitev in analogij<\/h3>\n \nProsili smo strokovnjake, da razlo\u017eijo bistvo DevOpsa na kar najpreprostej\u0161i in najkraj\u0161i na\u010din, da bi njeno vrednost razumel bralec katere koli ravni tehni\u010dne usposobljenosti. Na podlagi teh pogovorov smo izbrali najsvetlej\u0161e analogije in udarne formulacije, ki vam bodo pomagale oblikovati svojo pripoved o DevOpsu.<\/p>\n
1. DevOps \u2013 to je kulturno gibanje<\/h4>\n \n\u00abDevOps \u2013 to je kulturno gibanje, v okviru katerega obe strani (razvijalci programske opreme in strokovnjaki za delovanje IT sistemov) priznajo, da programska oprema ne prina\u0161a prave koristi, dokler je ne za\u010dne uporabljati nekdo: naro\u010dniki, stranke, zaposleni, ni va\u017eno,\u00ab pravi Eveline Oehrlich, vi\u0161ja analiti\u010darka raziskovalka v In\u0161titutu DevOps. \u00abZato obe strani skupaj zagotavljata hitro in kakovostno dostavo programske opreme\u00bb.<\/p>\n
2. DevOps \u2013 to je tisto, kar daje mo\u010d razvijalcem<\/h4>\n \n\u201eDevOps empowers developers with the ability to own applications, deploy them, and manage delivery from start to finish\u201c<\/b><\/p>\n
\u201eTypically, DevOps is discussed as a way to speed up application delivery to production by building and employing automated processes,\u201d says Jai Schniepp, director of DevOps platforms at Liberty Mutual insurance. \u201cBut for me, it is a much more fundamental matter. DevOps gives developers the authority over applications or specific parts of software, to deploy them and manage delivery from beginning to end. DevOps eliminates confusion regarding responsibility and guides all participants in the process towards creating an automated and developer-managed infrastructure.\u201d<\/p>\n
3. DevOps is about collaboration in creating and delivering applications<\/h4>\n \n\u201eIn simple terms, DevOps is an approach to software production and delivery where everyone works together,\u201d notes Gur Staff, president and head of digital business automation at BMC.<\/p>\n
4. DevOps is a pipeline<\/h4>\n \n\u201eA pipeline assembly is only possible if all parts fit together.\u201d<\/b><\/p>\n
\u201eI would compare DevOps to an assembly line for cars,\u201d continues Gur Staff. \u201cThe idea is to design and create all parts in advance so they can be assembled without individual adjustments. A pipeline assembly is only possible if all parts fit one another. Those who design and create the engine must consider how to attach it to the chassis or frame. Those who make the brakes need to think about the wheels, and so on. The same applies to software.\u201d <\/p>\n
A developer creating business logic or a user interface must consider the database that holds customer information, the security measures to protect user data, and how all this will function when the service serves a large, possibly even millions-strong audience of users.\u201d<\/p>\n
\u201eZagotovi, da ljudje sodelujejo in razmi\u0161ljajo o tistih delih dela, ki jih opravljajo drugi, namesto da se osredoto\u010dajo izklju\u010dno na svoje naloge \u2013 to je najve\u010dja ovira, ki jo je treba premagati. \u010ce to uspe, imate odli\u010dne mo\u017enosti za digitalno preobrazbo,\u201c dodaja Gur Staf.<\/p>\n
5. DevOps je prava kombinacija ljudi, procesov in avtomatizacije.<\/h4>\n \nJayne Groll, izvr\u0161na direktorica In\u0161tituta DevOps, je predlagala odli\u010dno analogijo za razlago DevOps-a. Po njenih besedah je \u201eDevOps kot kulinari\u010dni recept, v katerem so trije osnovni kategorije sestavin: ljudje, procesi in avtomatizacija. Ve\u010dina teh sestavin se lahko vzame iz drugih podro\u010dij in virov: Lean, Agile, SRE, CI\/CD, ITIL, vodstvo, kultura, orodja. Klju\u010d do DevOps-a, kot pri katerem koli dobrem receptu, je v pravilnem izbiranju proporcij in me\u0161anju teh sestavin, da se pove\u010da hitrost in u\u010dinkovitost pri ustvarjanju in izdaji aplikacij.\u201c<\/p>\n
6. DevOps je, kadar programerji delajo kot ekipa Formule 1.<\/h4>\n \n\u201eDirka se ne na\u010drtuje od starta do cilja, ampak obratno, od cilja do starta.\u201c<\/b><\/p>\n
\u201eKo govorim o tem, \u010desa pri\u010dakovati od iniciative DevOps, navajam primer dirka\u0161ke ekipe NASCAR ali Formule 1,\u201c pravi Chris Short, glavni vodja za tr\u017eenje obla\u010dnih platform Red Hat in urednik novi\u010dnika DevOps\u2019ish. \u201eVodja tak\u0161ne ekipe ima en sam cilj: dose\u010di najvi\u0161jo mo\u017eno mesto na koncu dirke, ob upo\u0161tevanju razpolo\u017eljivih virov in izzivov, s katerimi se ekipa soo\u010da. Pri tem se dirka ne na\u010drtuje od starta do cilja, ampak obratno, od cilja do starta. Najprej se postavi ambiciozen cilj, nato se dolo\u010dijo poti za njegovo dosego. Po tem se razdelijo v podnaloge in dodelijo \u010dlanom ekipe.\u201c<\/p>\n
\u201eCel teden pred dirko ekipa izpopolnjuje postopek pit-stop. Opravljajo mo\u010d in kardio treninge, da ostanejo v formi na napornem dirka\u0161kem dnevu. Vadijo usklajeno delovanje pri re\u0161evanju morebitnih te\u017eav, ki se lahko pojavijo med dirko. Podobno se mora razvojna ekipa usposabljati za pogosto spro\u0161\u010danje novih razli\u010dic. S tak\u0161nimi ve\u0161\u010dinami in delujo\u010dim sistemom varnosti je spro\u0161\u010danje novih razli\u010dic v produkcijo tudi pogostej\u0161e. V okviru tega prepri\u010danja pove\u010danje hitrosti pomeni pove\u010danje varnosti,\u201d pravi Short.<\/p>\n
\u201eGre za to, da ne gre za \u201epravilne stvari\u201c, dodaja Short, \u201etemve\u010d za odpravljanje \u010dim ve\u010d stvari, ki ovirajo dosego \u017eelenega rezultata. Sodelujte in prilagajajte se glede na povratne informacije, ki jih prejemate v realnem \u010dasu. Bodite pripravljeni na anomaliije in delajte na izbolj\u0161anju kakovosti, da zmanj\u0161ate njihov vpliv na napredovanje k cilju. To nas \u010daka v svetu DevOps.\u201c<\/p>\n
Kako raz\u0161iriti DevOps: 10 nasvetov strokovnjakov<\/h3>\n \nPreprost DevOps in mno\u017ei\u010dni DevOps sta popolnoma razli\u010dni stvari. Povedali vam bomo, kako premagati ovire na poti od prvega do drugega.<\/b><\/p>\n
Za mnoge organizacije je pot do DevOps za\u010denjala enostavno in prijetno. Ustvarjajo se majhne strastne ekipe, stari procesi so zamenjani z novimi, prve uspehe pa ni te\u017eko dose\u010di.<\/p>\n
\u017dal je to le la\u017eni sijaj, iluzija napredka, kot pravi Ben Grinnell, izvr\u0161ni direktor in vodja oddelka za digitalno tehnologijo svetovalnega podjetja North Highland. Zgodnje zmage so vsekakor obetavne, vendar ne pomagajo dose\u010di kon\u010dnega cilja, in sicer mno\u017ei\u010dne uporabe DevOps v organizaciji.<\/p>\n
Zlahka je videti, da se tako oblikuje kultura delitve na \u201emi\u201c in \u201eoni\u201c.<\/b><\/p>\n
\u00abPogosto organizacije za\u010denjajo tovrstne pionirske projekte, prepri\u010dane, da bodo utirale pot mno\u017ei\u010dnemu DevOpsu, ne da bi razmi\u0161ljale, ali se bodo drugi \u017eeleli in mogli podati na to pot,\u00ab pojasnjuje Ben Greennell. \u00abEkipo za izvajanje teh projektov obi\u010dajno sestavljajo samozavestni 'vikingi', ki so \u017ee izvajali kaj podobnega drugje, a so novinci v va\u0161i organizaciji. Hkrati jih spodbujajo, da ru\u0161ijo in uni\u010dujejo pravila, ki ostajajo obvezna za vse druge. Enostavno je opaziti, da se tako oblikuje kultura lo\u010ditve na 'mi' in 'oni', kar ovira prenos znanja in ve\u0161\u010din.\u00bb<\/p>\n
\u00abIn ta kulturna te\u017eava je le en od razlogov, zakaj je DevOps te\u017eko raz\u0161iriti. DevOps ekipe se soo\u010dajo z nara\u0161\u010dajo\u010dimi tehni\u010dnimi te\u017eavami, zna\u010dilnimi za hitro razvijajo\u010de se podjetja, ki stavijo na IT-tehnologije,\u00ab pravi Steve Newman, ustanovitelj in predsednik uprave podjetja Scalyr.<\/p>\n
\u00abV sodobnem svetu se storitve spreminjajo takoj, ko se pojavi potreba. Nenehno izvajati in uvajati nove funkcije je seveda odli\u010dno, toda usklajevati ta postopek in odpravljati vznikle te\u017eave je prava glavobol,\u00ab dodaja Steve Newman. \u00abV zelo hitro rasto\u010dih organizacijah se in\u017eenirji v sestavljenih ekipah trudijo, da ohranijo sposobnost spremljanja sprememb in povzro\u010dajo\u010dih kaskadnih u\u010dinkov na ravni odvisnosti. Poleg tega in\u017eenirje nikakor ne veseli, ko jih prikraj\u0161ajo za to sposobnost in jim posledi\u010dno postane te\u017eje razumeti naravo vzniklih te\u017eav.\u00bb<\/p>\n
Kako premagati zgoraj omenjene izzive in preiti na mno\u017ei\u010dno uporabo DevOps v veliki organizaciji? Strokovnjaki pozivajo, naj razvijete potrpljenje, tudi \u010de je va\u0161 kon\u010dni cilj pospe\u0161itev cikla razvoja programske opreme in poslovnih procesov.<\/b><\/p>\n1. Ne pozabite, da potrebujejo spremembe v kulturi \u010das<\/h4>\n
\nJayne Groll, izvr\u0161na direktorica In\u0161tituta DevOps:<\/b> \u00abPo mojem mnenju bi morala biti \u0161iritev DevOps prav tako postopna in iterativna kot agilni razvoj (in prav tako obravnavati kulturo). V Agile in DevOps je poudarek na majhnih ekipah. Vendar pa, ko se \u0161tevilo in integracija teh ekip pove\u010duje, dobivamo vedno ve\u010d ljudi, ki uvajajo nove delovne metode, kar posledi\u010dno vodi k obse\u017eni kulturni transformaciji\u00bb.<\/p>\n2. Dajte dovolj \u010dasa za na\u010drtovanje in izbiro platforme<\/h4>\n
\nEran Kinsbruner, glavni tehni\u010dni evangelist podjetja Perfecto:<\/b> \u00abDa bi bila \u0161iritev uspe\u0161na, se morajo DevOps ekipe sprva nau\u010diti kombinirati tradicionalne procese, orodja in ve\u0161\u010dine, nato pa postopoma razvijati vsako fazo DevOps in jo stabilizirati. Vse se za\u010dne z natan\u010dnim na\u010drtovanjem uporabni\u0161kih zgodb in tokov ustvarjanja vrednosti, nato pa sledi faza pisanja programske opreme in nadzora razli\u010dic z uporabo trunk-based development ali drugih pristopov, ki so najbolj primerni za razvejitve in zdru\u017eevanje kode\u00bb.<\/p>\n
\u00abSledi faza integracije in testiranja, kjer je potrebna skalabilna platforma za avtomatizacijo. In tukaj je za DevOps ekipe klju\u010dno izbrati pravo platformo, ki ustreza njihovim ve\u0161\u010dinam in kon\u010dnim ciljem projekta. <\/p>\n
Naslednja faza je implementacija v produkcijsko okolje, ki mora biti povsem avtomatizirana z uporabo orodij za orkestracijo in kontejnerje. Pri tem je pomembno imeti virtualizirana okolja v vseh fazah DevOps (simulator produkcijskega okolja, okolje za nadzor kakovosti in samo produkcijsko okolje) ter vedno uporabljati le najnovej\u0161e podatke za teste, da bi pridobili \u0430\u043a\u0442\u0443alne vpoglede. Analitika mora biti inteligentna in sposobna obdelovati velike podatke z hitro in u\u010dinkovito povratno informacijo\u00bb.<\/p>\n
3. Osvobodite odgovornost od okusa krivde<\/h4>\n \nGordon Haff, evangelist podjetja RedHat:<\/b> \u201eUstvarjanje sistema in vzdu\u0161ja, ki dovoljuje in spodbuja eksperimente, omogo\u010da uresni\u010ditev tistih uspe\u0161nih napak v agilnem razvoju programske opreme. To ne pomeni, da za napake ne odgovarja ve\u010d nih\u010de. V resnici je iskanje odgovornega \u0161e la\u017eje, saj 'biti odgovoren' ne pomeni ve\u010d 'postati krivec za nesre\u010do'. To pomeni, da se bistvo odgovornosti kakovostno spreminja. Ob tem postanejo izjemno pomembni \u0161tirje dejavniki: obseg napake, pristopi, proizvodni procesi in spodbude.\u201c (Ve\u010d o teh dejavnikih lahko preberete v \u010dlanku Gordona Haffa \u201eDevOps lessons: 4 aspects of healthy experiments\u201c.)<\/p>\n4. O\u010distite pot naprej<\/h4>\n
\nBen Grinnell, izvr\u0161ni direktor in vodja podro\u010dja digitalnih tehnologij svetovalne firme North Highland:<\/b> \u201eDa bi dosegli raz\u0161iritev, priporo\u010dam, da ob projektih pionirjev za\u010dnete tudi program 'o\u010distimo pot'. Cilj tega programa je odstranjevanje smeti, ki ostajajo za pionirji DevOps, kot so neveljavna pravila in druge podobne stvari, da pot naprej ostane prosta.\u201c<\/p>\n
\u201eZagotovite organizacijsko podporo in dajte zagon s komunikacijo, ki presega skupino pionirjev, ter \u0161iroko proslavite uspehe novih delovnih metod. Usposabljajte ljudi, ki sodelujejo v naslednji valovi projektov DevOps in so \u017eiv\u010dni, ker DevOps uporabljajo prvi\u010d. In ne pozabite, da so ti ljudje bistveno druga\u010dni od pionirjev.\u201c<\/p>\n
5. U\u010dinite orodja bolj demokrati\u010dna<\/h4>\n \nSteve Newman, ustanovitelj in predsednik uprave podjetja Scalyr:<\/b> \u201eOrodij ni treba skrivati pred ljudmi, in morajo biti razmeroma enostavna za u\u010denje za vsakogar, ki je pripravljen vlo\u017eiti \u010das vanje. \u010ce je mo\u017enost zahtevanja logov omogo\u010dena le trem ljudem, 'certificiranim' za delo s katerim koli orodjem, boste vedno imeli najve\u010d tri osebe, sposobne re\u0161iti ustrezen problem, tudi \u010de imate zelo veliko ra\u010dunalni\u0161ko okolje. Drugimi besedami, to ustvari ozko grlo, ki lahko povzro\u010di resne (za posel) posledice.\u201c<\/p>\n6. Ustvarite idealne pogoje za delo ekipe<\/h4>\n
\nTom Clark, vodja podro\u010dja Common Platform v telekomunikacijski dru\u017ebi ITV:<\/b> \u201eLahko storite karkoli, a ne vse hkrati. Zato postavite velike cilje, za\u010dnite po\u010dasi in napredujte s hitrimi iteracijami. S\u010dasoma boste pridobili ugled ekipe, ki ji uspeva, tako da bodo drugi \u017eeleli uporabljati va\u0161e metode. Ne zasledujte visokou\u010dinkovitosti ekipe. Namesto tega zagotovite ljudem idealne pogoje za delo, u\u010dinkovitost pa bo pri\u0161la sama od sebe.\u201c<\/p>\n7. Ne pozabite na Conwayev zakon in kanban tablo<\/h4>\n
\nLogan Daigle, direktor za dostavo programske opreme in strategijo DevOps pri podjetju CollabNetVersionOne:<\/b> \u201ePomembno je zavedati se posledic Conwayevega zakona. V mojem prostem prevodu ta zakon pravi, da so izdelki, ki jih ustvarjamo, in procesi, ki jih pri tem uporabljamo, vklju\u010dno z DevOps, organizirani tako, kot je na\u0161a organizacija.\u201c<\/p>\n
\u201e\u010ce je v organizaciji visoka razdrobljenost, in ko pri na\u010drtovanju, ustvarjanju in spro\u0161\u010danju programske opreme upravljanje ve\u010dkrat prehaja iz rok v roke, bo u\u010dinek skaliranja ni\u010delni ali kratkotrajen. \u010ce pa organizacija oblikuje \u010dez funkcionalne ekipe okoli izdelkov, ki so financirani ob upo\u0161tevanju trga, se mo\u017enosti za uspeh drasti\u010dno pove\u010dajo.\u201c<\/p>\n
\u201e\u0160e en pomemben vidik skaliranja je, da na kanban tablah prika\u017eemo vse delo, ki je v teku (WIP, work in progress). Ko v organizaciji obstaja prostor, kjer ljudje lahko vidijo tak\u0161ne stvari, to mo\u010dno spodbuja sodelovanje, kar pozitivno vpliva na skaliranje.\u201c<\/p>\n
8. I\u0161\u010dite stare brazgotine<\/h4>\n \nManuel Pais, svetovalec za DevOps in soavtor knjige \u201eTeam Topologies\u201c:<\/b> \u201eIzvoz praks DevOps iz lastnega Dev in Ops ter poskus njihove uporabe za druge funkcije zagotovo ne moremo obravnavati kot optimalen pristop. To bo nedvomno prineslo dolo\u010den u\u010dinek (na primer z avtomatizacijo ro\u010dnega upravljanja), vendar lahko dose\u017eemo mnogo ve\u010d, \u010de za\u010dnemo z razumevanjem procesov dostave in povratnih informacij\u201c.<\/p>\n
\u201e\u010ce v IT-sistemu organizacije obstajajo stari made\u017ei \u2013 postopki in mehanizmi upravljanja, ki so bili uvedeni kot posledica prej\u0161njih incidentov, vendar so izgubili pomembnost (zaradi spremembe izdelkov, tehnologij ali procesov), jih je seveda treba odstraniti ali izravnati, ne pa avtomatizirati neu\u010dinkovitih ali nepotrebnih procesov.\u201c<\/p>\n
9. Ne ustvarjajte razli\u010dic DevOps<\/h4>\n \nAntony Edwards, direktor proizvodnje podjetja Eggplant:<\/b> \u201eDevOps je zelo nejasen izraz, zato ima vsaka ekipa svojo razli\u010dico DevOps. Ni\u010d ni huj\u0161ega, kot ko v organizaciji nastane kar 20 razli\u010dnih razli\u010dic DevOps, ki se ne ujemajo dobro med seboj. Ne sme biti, da ima vsaka od treh razvojnih ekip svoj, posebni vmesnik med razvojem in upravljanjem izdelka. Prav tako ne sme biti, da imajo izdelki svoje, edinstvene pri\u010dakovanja glede obravnave povratnih informacij pri selitvi v simulacijo proizvodnega okolja. V nasprotnem primeru DevOps nikoli ne bo mogo\u010de raz\u0161iriti.\u201c<\/p>\n10. Poudarjajte vrednost DevOps za podjetje<\/h4>\n
\nSteve Newman, ustanovitelj in predsednik uprave podjetja Scalyr:<\/b> \u201eDelajte na priznanju vrednosti DevOps. Nau\u010dite se in ne bojte se govoriti o koristih tega, kar po\u010dnete. DevOps izjemno prihrani \u010das in denar (le pomislite: manj izpadov, kraj\u0161i povpre\u010dni \u010das okrevanja), ekipe DevOps pa morajo nepretrgoma poudarjati (in propagirati) pomembnost teh pobud za uspeh podjetja. Tako boste lahko raz\u0161irili \u0161tevilo privr\u017eencev in okrepili vpliv DevOps v organizaciji.\u201c<\/p>\nBONUS<\/h3>\n
\nNa Red Hat Forum Slovenija<\/a><\/noindex> 13. septembra bo na\u0161 lastni DevOps \u2013 da, Red Hat, kot proizvajalec programske opreme, ima svoje DevOps ekipe in prakse.<\/b><\/p>\nNa\u0161 in\u017eenir Mark Birger, ki se ukvarja z razvojem storitev notranje avtomatizacije za druge skupine v celotni organizaciji, bo v sloven\u0161\u010dini delil svojo zgodbo \u2013 kako je DevOps ekipa Red Hat migrirala aplikacije iz virtualnih okolij Hat Virtualization, upravljanih z Ansible, v celovit kontejnerski format na platformi OpenShift.<\/p>\n
Ampak to niti ni vse:<\/b><\/p>\n
Ko je organizacija prenesla delovne obremenitve v kontejnerje, tradicijski na\u010dini spremljanja aplikacij morda ne bodo delovali. V drugem poro\u010dilu bomo razlo\u017eili na\u0161e razloge za spremembo pristopa k bele\u017eenju in pokazali nadaljevanje poti, ki nas je pripeljala do sodobnih metod bele\u017eenja in spremljanja.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0440\u0443\u0434\u043d\u043e \u0443\u043b\u043e\u0432\u0438\u0442\u044c \u0433\u043b\u0430\u0432\u043d\u043e\u0435, \u0433\u043e\u0432\u043e\u0440\u044f \u043e DevOps? \u041c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u044f\u0440\u043a\u0438\u0435 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0438, \u0443\u0434\u0430\u0440\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0443\u043b\u0438\u0440\u043e\u0432\u043a\u0438 \u0438 \u0441\u043e\u0432\u0435\u0442\u044b \u043e\u0442 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0434\u043e\u0439\u0442\u0438 \u0434\u043e \u0441\u0443\u0442\u0438 \u0434\u0430\u0436\u0435 \u043d\u0435\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430\u043c. \u0412 \u043a\u043e\u043d\u0446\u0435 \u0431\u043e\u043d\u0443\u0441 \u2013 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 DevOps \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u043e\u0432 Red Hat. \u0422\u0435\u0440\u043c\u0438\u043d DevOps \u0432\u043e\u0437\u043d\u0438\u043a 10 \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u0438 \u043f\u0440\u043e\u0448\u0435\u043b \u043f\u0443\u0442\u044c \u043e\u0442 \u0445\u044d\u0448\u0442\u0435\u0433\u0430 \u0432 \u0422\u0432\u0438\u0442\u0442\u0435\u0440\u0435 \u0434\u043e \u043c\u043e\u0449\u043d\u043e\u0433\u043e \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043d\u043e\u0433\u043e \u0434\u0432\u0438\u0436\u0435\u043d\u0438\u044f \u0432 \u043c\u0438\u0440\u0435 \u0418\u0422, \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-37551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Govorimo](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")