<\/a><\/noindex>DevOps omfatter mange forskellige koncepter (kontinuerlig levering, kontinuerlig integration, automatisering osv.), s\u00e5 det kan v\u00e6re sv\u00e6rt at fremh\u00e6ve hovedpunkterne, is\u00e6r n\u00e5r man har en interesse i emnet. Men denne evne er meget nyttig, uanset om du pr\u00f8ver at kommunikere dine id\u00e9er til ledelsen eller fort\u00e6ller om dit arbejde til familiemedlemmer eller bekendte. S\u00e5 lad os s\u00e6tte de terminologiske nuancer af DevOps til side og fokusere p\u00e5 det overordnede billede.<\/p>\n
Hvad er DevOps: 6 definitioner og analogier<\/h3>\n \nVi har bedt eksperter om at forklare essensen af DevOps s\u00e5 enkelt og kort som muligt, s\u00e5 dens v\u00e6rdi bliver tydelig for l\u00e6sere med enhver teknisk baggrund. Efter disse samtaler har vi udvalgt de mest markante analogier og pr\u00e6cise formuleringer, der hj\u00e6lper dig med at opbygge din fort\u00e6lling om DevOps.<\/p>\n
1. DevOps \u2013 det er en kulturbev\u00e6gelse<\/h4>\n \n\u00abDevOps \u2013 det er en kulturbev\u00e6gelse, hvor begge sider (softwareudviklere og IT-driftsspecialister) anerkender, at software ikke giver reel v\u00e6rdi, f\u00f8r nogen begynder at bruge det: kunder, klienter, medarbejdere, det er ligegyldigt,\u00bb siger Eveline Oehrlich, senior analytiker-researcher ved DevOps Institute. \u00abDerfor sikrer begge parter sammen hurtig og kvalitetsm\u00e6ssig levering af software.\u00bb<\/p>\n
2. DevOps \u2013 det er det, der giver udviklerne magt<\/h4>\n \n\u00abDevOps giver udviklere bef\u00f8jelser til at eje applikationer, starte dem og styre leveringen fra start til slut\u00bb<\/b><\/p>\n
\u00abNormalt taler man om DevOps som en m\u00e5de at fremskynde levering af applikationer til produktion ved at opbygge og anvende automatiserede processer, \u2013 siger Jai Schniepp, direkt\u00f8r for DevOps-platforme i forsikringsselskabet Liberty Mutual. \u2013 Men for mig er det en meget mere grundl\u00e6ggende ting. DevOps giver udviklere bef\u00f8jelser til at eje applikationer eller specifikke dele af software, til at starte dem og styre leveringen fra start til slut. DevOps fjerner forvirringen omkring ansvar og f\u00f8rer alle deltagere i processen mod at skabe en automatiseret og udviklerstyret infrastruktur\u00bb.<\/p>\n
3. DevOps er samarbejde om skabelse og levering af applikationer<\/h4>\n \n\u00abKort sagt er DevOps en tilgang til produktion og levering af software, hvor alle arbejder sammen\u00bb, \u2013 bem\u00e6rker Gur Staff, pr\u00e6sident og leder af digital forretningsautomatisering hos BMC.<\/p>\n
4. DevOps er en samleb\u00e5ndsproces<\/h4>\n \n\u00abSamleb\u00e5ndsproduktion er kun mulig, hvis alle dele passer sammen\u00bb.<\/b><\/p>\n
\u00abJeg ville sammenligne DevOps med samleb\u00e5ndet i bilproduktionen, \u2013 forts\u00e6tter Gur Staff. \u2013 Ideen er at designe og lave alle dele p\u00e5 forh\u00e5nd, s\u00e5 de senere kan samles uden individuel tilpasning. Samleb\u00e5ndsproduktion er kun mulig, hvis alle dele passer sammen. Dem, der designer og laver motoren, skal t\u00e6nke over, hvordan den skal fastg\u00f8res til karrosseriet eller rammen. Dem, der laver bremserne, skal t\u00e6nke over hjulene, og s\u00e5 videre. Det skal v\u00e6re det samme med softwaren. <\/p>\n
Udvikleren, der skaber forretningslogik eller brugerflade, skal t\u00e6nke over databasen, der opbevarer oplysninger om kunderne, over sikkerhedsforanstaltningerne for at beskytte brugerdata, samt hvordan alt dette vil fungere, n\u00e5r tjenesten begynder at betjene et stort, m\u00e5ske endda millionpublikum af brugere\u00bb.<\/p>\n
\u00abAt skabe samarbejde blandt mennesker og f\u00e5 dem til at t\u00e6nke p\u00e5 de dele af arbejdet, som andre udf\u00f8rer, i stedet for kun at fokusere p\u00e5 deres egne opgaver, er den st\u00f8rste hindring, der skal overvindes. Hvis man lykkes med dette, f\u00e5r man fremragende chancer for digital transformation\u00bb, tilf\u00f8jer Gur Staff.<\/p>\n
5. DevOps er den rigtige kombination af mennesker, processer og automatisering<\/h4>\n \nJayne Groll, administrerende direkt\u00f8r for DevOps Institute, pr\u00e6senterede en fremragende analogi til at forklare DevOps. If\u00f8lge hende: \u00abDevOps er som en opskrift, der har tre hovedkategorier af ingredienser: mennesker, processer og automatisering. De fleste af disse ingredienser kan komme fra andre omr\u00e5der og kilder: Lean, Agile, SRE, CI\/CD, ITIL, ledelse, kultur, v\u00e6rkt\u00f8jer. Hemmeligheden bag DevOps, ligesom enhver god opskrift, er at finde de rigtige proportioner og blande disse ingredienser for at \u00f8ge hastigheden og effektiviteten i arbejdet med at udvikle og levere applikationer\u00bb.<\/p>\n
6. DevOps er, n\u00e5r programm\u00f8rer arbejder som et Formel 1-hold<\/h4>\n \n\u00abL\u00f8bet planl\u00e6gges ikke fra start til m\u00e5l, men derimod fra m\u00e5l til start\u00bb.<\/b><\/p>\n
\u00abN\u00e5r jeg taler om, hvad man kan forvente af en DevOps-initiativ, giver jeg et eksempel p\u00e5 et racingteam i NASCAR eller Formel 1, \u2013 siger Chris Short, hovedmarkedsf\u00f8ringschef for Red Hats cloud platforms og udgiver af nyhedsbrevet DevOps'ish. \u2013 En teamleder har \u00e9n m\u00e5l: at ende s\u00e5 h\u00f8jt som muligt i l\u00f8bet, givet de ressourcer teamet har haft og de udfordringer, de har m\u00f8dt. L\u00f8bet planl\u00e6gges ikke fra start til m\u00e5l, men derimod fra m\u00e5l til start. F\u00f8rst s\u00e6ttes et ambiti\u00f8st m\u00e5l, hvorefter man definerer veje til at n\u00e5 det. Derefter opdeles de i delopgaver og delegeres til teammedlemmerne\u00bb.<\/p>\n
\u00abHele ugen f\u00f8r l\u00f8bet finpudser teamet pitstop. De tr\u00e6ner i styrke og kondition for at v\u00e6re i god form p\u00e5 den udmattende racedag. De \u00f8ver teamwork for at h\u00e5ndtere eventuelle problemer, der m\u00e5tte opst\u00e5 under l\u00f8bet. P\u00e5 samme m\u00e5de b\u00f8r udviklingsteamet tr\u00e6ne evnerne til at frigive nye versioner hyppigt. Med disse f\u00e6rdigheder og et velfungerende sikkerhedssystem kan lanceringen af nye versioner i produktion ogs\u00e5 ske oftere. I denne tankegang betyder \u00f8get hastighed \u00f8get sikkerhed,\u00bb siger Short.<\/p>\n
\u00abDet handler ikke om at g\u00f8re \u2018de rigtige ting\u2019, \u2013 tilf\u00f8jer Short, \u2013 men om at fjerne s\u00e5 mange hindringer som muligt p\u00e5 vejen mod det \u00f8nskede resultat. Samarbejd og tilpas jer ud fra den feedback, I f\u00e5r i realtid. V\u00e6r forberedt p\u00e5 afvigelser og arbejd p\u00e5 at forbedre kvaliteten for at mindske deres indvirkning p\u00e5 m\u00e5let. Det er pr\u00e6cis, hvad der venter os i DevOps-verdenen.\u00bb<\/p>\n
Hvordan man skalerer DevOps: 10 r\u00e5d fra eksperter<\/h3>\n \nSimpel DevOps og masseskala DevOps er to helt forskellige ting. Vi vil fort\u00e6lle, hvordan man overvinder barriererne fra det f\u00f8rste til det andet.<\/b><\/p>\n
For mange organisationer begynder vejen til DevOps let og tiltalende. Sm\u00e5 passionerede teams oprettes, gamle processer erstattes af nye, og de f\u00f8rste succeser lader ikke vente p\u00e5 sig.<\/p>\n
Desv\u00e6rre er dette blot falsk glans, en illusion af fremskridt, som Ben Grinnell, Managing Director og leder af det digitale r\u00e5dgivningsomr\u00e5de i North Highland, siger. Tidlige sejre er selvf\u00f8lgelig opmuntrende, men hj\u00e6lper ikke med at n\u00e5 det endelige m\u00e5l, nemlig massebrug af DevOps i organisationen.<\/p>\n
Det er let at se, at der dannes en kultur af opdeling mellem \u2018vi\u2019 og \u2018de\u2019.<\/b><\/p>\n
\u00abOfte lancerer organisationer s\u00e5danne banebrydende projekter i h\u00e5bet om, at de vil banebryde vejen for bredt DevOps, uden at t\u00e6nke over, om andre \u00f8nsker at g\u00e5 denne vej,\u00ab forklarer Ben Grinnell. \u00abTeams, der arbejder med s\u00e5danne projekter, sammens\u00e6ttes ofte af overbeviste 'vikingere', som allerede har lavet noget lignende andre steder, men som er nye i jeres organisation. De opmuntres til at bryde og omg\u00e5 de regler, der fortsat g\u00e6lder for alle andre. Det er nemt at se, at resultatet bliver en kultur, hvor der skabes en kl\u00f8ft mellem 'vi' og 'de', hvilket h\u00e6mmer overf\u00f8rsel af viden og f\u00e6rdigheder.\u00ab<\/p>\n
\u00abOg dette kulturelle problem er blot en af \u00e5rsagerne til, at DevOps er sv\u00e6rt at skalere. DevOps-teams st\u00e5r over for stigende tekniske kompleksiteter, som er typiske for hurtigt voksende virksomheder, der har satset p\u00e5 IT-teknologier,\u00ab siger Steve Newman, grundl\u00e6gger og formand for Scalyr.<\/p>\n
\u00abI den moderne verden \u00e6ndres tjenester straks, s\u00e5 snart behovet opst\u00e5r. At implementere og lancere nye funktioner er selvf\u00f8lgelig fantastisk, men at koordinere denne proces og h\u00e5ndtere opst\u00e5ede problemer er en \u00e6gte hovedpine,\u00ab tilf\u00f8jer Steve Newman. \u00abI meget hurtigt voksende organisationer k\u00e6mper ingeni\u00f8rer i tv\u00e6rfunktionelle teams for at bevare muligheden for at f\u00f8lge med i \u00e6ndringerne og de deraf f\u00f8lgende kaskadeeffekter p\u00e5 afh\u00e6ngigheder. Desuden er ingeni\u00f8rer bestemt ikke begejstrede, n\u00e5r de fratages denne mulighed, og som f\u00f8lge heraf bliver det sv\u00e6rere for dem at forst\u00e5 kernen i de problemer, der opst\u00e5r.\u00ab<\/p>\n
Hvordan kan man s\u00e5 overvinde de n\u00e6vnte udfordringer og overg\u00e5 til bred anvendelse af DevOps i en stor organisation? Eksperter opfordrer til at udvise t\u00e5lmodighed, selvom jeres endelige m\u00e5l er at fremskynde softwareudviklingscyklussen og forretningsprocesserne.<\/b><\/p>\n1. Husk, at \u00e6ndringer i kulturen tager tid<\/h4>\n
\nJayne Groll, administrerende direkt\u00f8r for DevOps Institute:<\/b> \u00abJeg mener, at DevOps-udvidelsen b\u00f8r v\u00e6re lige s\u00e5 gradvis og iterativ som agil udvikling (og lige s\u00e5 meget ber\u00f8re kulturen). I Agile og DevOps fokuseres der p\u00e5 sm\u00e5 teams. Men i takt med at antallet og integrationen af s\u00e5danne teams vokser, f\u00e5r vi flere og flere mennesker, der anvender nye arbejdsmetoder, og som f\u00f8lge heraf opst\u00e5r en omfattende kulturel transformation\u00bb.<\/p>\n2. Brug tilstr\u00e6kkelig tid p\u00e5 planl\u00e6gning og valg af platform<\/h4>\n
\nEran Kinsbruner, ledende teknisk evangelist hos Perfecto:<\/b> \u00abFor at skaleringsprocessen fungerer, m\u00e5 DevOps-teams i starten l\u00e6re at kombinere traditionelle processer, v\u00e6rkt\u00f8jer og kompetencer, og derefter langsomt opbygge hver fase af DevOps og stabilisere den. Det hele starter med n\u00f8je planl\u00e6gning af brugerhistorier og v\u00e6rdistr\u00f8mme, hvorefter der f\u00f8lger en fase af softwareudvikling og versionskontrol ved brug af trunk-based development eller andre tilgange, der er mest velegnede til kodernes forgrening og sammenl\u00e6gning\u00bb.<\/p>\n
\u00abDern\u00e6st f\u00f8lger en fase med integration og test, hvor en skalerbar platform til automatisering er n\u00f8dvendig. Her er det vigtigt for DevOps-teams at v\u00e6lge den rigtige platform, der passer til deres f\u00e6rdigheder og de overordnede m\u00e5l for projektet. <\/p>\n
Den n\u00e6ste fase er implementering i produktionsmilj\u00f8et, og den skal v\u00e6re helt automatiseret ved hj\u00e6lp af orkestreringsv\u00e6rkt\u00f8jer og containere. Det er vigtigt at have virtualiserede milj\u00f8er p\u00e5 alle faser af DevOps (simulator for produktionsmilj\u00f8, kvalitetskontrolmilj\u00f8 og selve produktionsmilj\u00f8et) og altid anvende de nyeste data til test for at f\u00e5 relevante indsigter. Analytik skal v\u00e6re intelligent og capabel til at h\u00e5ndtere store data med hurtig og effektiv feedback\u00bb.<\/p>\n
3. Befri ansvar fra skyldfornemmelse<\/h4>\n \nGordon Haff, evangelist hos RedHat:<\/b> At skabe et system og en atmosf\u00e6re, der tillader og fremmer eksperimenter, muligg\u00f8r s\u00e5kaldte succesfulde fejl i agile softwareudvikling. Det betyder ikke, at ingen l\u00e6ngere kan holdes ansvarlig for fejl. Faktisk bliver det lettere at finde en ansvarlig, fordi at 'v\u00e6re ansvarlig' ikke l\u00e6ngere betyder 'at blive synderen'. Med andre ord \u00e6ndrer essensen af ansvarlighed sig kvalitativt. Her bliver fire faktorer ekstremt vigtige: omfanget af fejlen, tilgange, produktionsprocesser og incitamenter. (Du kan l\u00e6se mere om disse faktorer i Gordon Hauffs artikel \"DevOps lessons: 4 aspects of healthy experiments\".)<\/p>\n4. Ryd vejen fremad<\/h4>\n
\nBen Grinnell, administrerende direkt\u00f8r og leder af digital teknologi i konsulentfirmaet North Highland:<\/b> \"For at opn\u00e5 skalering anbefaler jeg at lancere et 'rydning af vejen' program sammen med pionerprojekter. M\u00e5let med dette program er at fjerne det rod, som bliver efter pionererne i DevOps, s\u00e5som for\u00e6ldede regler og lignende, s\u00e5 vejen fremad forbliver fri.\"<\/p>\n
\"Giv folk organisatorisk st\u00f8tte og skab momentum gennem kommunikation, der r\u00e6kker langt ud over gruppen af pionerer, ved at fejre succeserne med de nye arbejdsmetoder bredt. Uddan folk, der er involveret i den n\u00e6ste b\u00f8lge af DevOps-projekter og som er nerv\u00f8se for, at de bruger DevOps for f\u00f8rste gang. Og husk, at disse personer er meget forskellige fra pionererne.\"<\/p>\n
5. G\u00f8r v\u00e6rkt\u00f8jerne mere demokratiske<\/h4>\n \nSteve Newman, grundl\u00e6gger og formand for Scalyr:<\/b> \"V\u00e6rkt\u00f8jerne b\u00f8r ikke skjules for folk, og de skal v\u00e6re relativt enkle at l\u00e6re for alle, der er villige til at investere tid i det. Hvis muligheden for at anmode om logs kun gives til tre personer 'certificeret' til at arbejde med et bestemt v\u00e6rkt\u00f8j, vil du altid have maksimalt tre personer, der kan h\u00e5ndtere det relevante problem, selvom du har et meget stort beregningsmilj\u00f8. Med andre ord, her opst\u00e5r der en flaskehals, som kan have alvorlige (for forretningen) konsekvenser.\"<\/p>\n6. Skab ideelle betingelser for teamets arbejde<\/h4>\n
\nTom Clark, leder af Common Platform i ITV:<\/b> \u00abDu kan g\u00f8re hvad som helst, men ikke alt p\u00e5 \u00e9n gang. S\u00e5 s\u00e6t store m\u00e5l, start sm\u00e5t og bev\u00e6g dig fremad med hurtige iterationer. Over tid vil du opn\u00e5 et omd\u00f8mme som et team, der f\u00e5r tingene til at ske, hvilket g\u00f8r, at andre ogs\u00e5 vil \u00f8nske at anvende jeres metoder. Og jagter ikke opbygningen af et h\u00f8jt effektivt team. S\u00f8rg i stedet for, at folk har de bedste betingelser for at arbejde, og effektiviteten vil komme af sig selv\u00bb.<\/p>\n7. Glem ikke Conway's lov og kanban-tavler.<\/h4>\n
\nLogan Daigle, direkt\u00f8r for softwarelevering og DevOps-strategi hos CollabNetVersionOne:<\/b> \u00abDet er vigtigt at v\u00e6re opm\u00e6rksom p\u00e5 konsekvenserne af Conway's lov. I min frie omskrivning siger denne lov, at de produkter, vi skaber, og de processer, vi bruger, inklusive DevOps, ender med at v\u00e6re struktureret ligesom vores organisation\u00bb.<\/p>\n
\u00abHvis der er stor fragmentering i organisationen, og ledelsen skifter h\u00e6nder mange gange under planl\u00e6gning, udvikling og frigivelse af software, vil skaleringsresultatet v\u00e6re nul eller kortvarigt. Men hvis organisationen danner tv\u00e6rfunktionelle teams omkring produkter, der finansieres med fokus p\u00e5 markedet, s\u00e5 stiger chancerne for succes dramatisk\u00bb.<\/p>\n
\u00abEn anden vigtig aspekt ved skalering er at vise alt arbejde, der er i gang (WIP, work-in-progress), p\u00e5 kanban-tavlerne. N\u00e5r der skabes et sted i organisationen, hvor folk kan se disse ting, fremmer det samarbejdet betydeligt, hvilket har en positiv indvirkning p\u00e5 skaleringen\u00bb.<\/p>\n
8. S\u00f8g efter gamle ar.<\/h4>\n \nManuel Pais, DevOps-konsulent og medforfatter af bogen 'Team Topologies':<\/b> \u00abAt anvende DevOps-praksis uden for selve Dev og Ops og fors\u00f8ge at anvende dem p\u00e5 andre funktioner kan n\u00e6ppe kaldes en optimal tilgang. Det vil uden tvivl give en vis effekt (for eksempel ved at automatisere manuel styring), men der kan opn\u00e5s meget mere ved at starte med at forst\u00e5 leverings- og feedbackprocesserne.\u00bb<\/p>\n
\u00abHvis der i en organisations IT-system er gamle ar \u2013 procedurer og styringsmekanismer, der blev implementeret som f\u00f8lge af tidligere h\u00e6ndelser, men som har mistet relevans (p\u00e5 grund af \u00e6ndringer i produkter, teknologier eller processer), s\u00e5 skal de uden tvivl fjernes eller glattes ud, og ikke automatiseres ineffektive eller un\u00f8dvendige processer\u00bb.<\/p>\n
9. Skab ikke flere varianter af DevOps<\/h4>\n \nAntony Edwards, direkt\u00f8r for produktion hos Eggplant:<\/b> \u00abDevOps er et meget vagt udtryk, som g\u00f8r, at hver team f\u00e5r sin egen variant af DevOps. Og der er ikke noget v\u00e6rre end, n\u00e5r der i en organisation er 20 forskellige versioner af DevOps, der ikke rigtig trives sammen. Det kan ikke v\u00e6re, at hver af de tre udviklingsteams har sit eget unikke interface mellem udvikling og produktledelse. Det kan heller ikke v\u00e6re, at produkter har deres egne, unikke forventninger til h\u00e5ndtering af feedback, n\u00e5r de flyttes til simuleringen af produktionsmilj\u00f8et. Ellers vil det aldrig lykkes for jer at skalere DevOps\u00bb.<\/p>\n10. Fork\u00e6l v\u00e6rdien af DevOps for forretningen<\/h4>\n
\nSteve Newman, grundl\u00e6gger og formand for Scalyr:<\/b> \u00abArbejd p\u00e5 at anerkende v\u00e6rdien af DevOps. L\u00e6r og v\u00e6r ikke genert med at fort\u00e6lle om fordelene ved det, I laver. DevOps sparer utrolig meget tid og penge (bare t\u00e6nk: f\u00e6rre nedbrud, kortere gennemsnitlig genopretningstid), og DevOps-teams skal utr\u00e6tteligt fremh\u00e6ve (og pr\u00e6dike) vigtigheden af disse initiativer for forretningssucces. P\u00e5 den m\u00e5de kan I udvide kredsen af fortalere og styrke DevOps' indflydelse i organisationen\u00bb.<\/p>\nBONUS<\/h3>\n
\nP\u00e5 Red Hat Forum Rusland<\/a><\/noindex> Den 13. september ankommer vores egen DevOps \u2013 ja, hos Red Hat har vi, som softwareproducent, vores egne DevOps-teams og praksisser.<\/b><\/p>\nVores ingeni\u00f8r Mark Birger, som arbejder med udvikling af interne automatiseringstjenester til andre grupper i hele organisationen, vil p\u00e5 klart dansk fort\u00e6lle sin egen historie \u2013 hvordan Red Hats DevOps-team migrerede applikationer fra virtuelle milj\u00f8er drevet af Hat Virtualization, kontrolleret af Ansible, til et fuldt containerformat p\u00e5 OpenShift-platformen.<\/p>\n
Men det er stadig ikke alt:<\/b><\/p>\n
Efter at organisationer har flyttet arbejdsbelastning til containere, kan traditionelle metoder til overv\u00e5gning af applikationer ikke fungere. I den anden rapport vil vi forklare vores motivation til at \u00e6ndre m\u00e5den, vi registrerer p\u00e5, og vise forts\u00e6ttelsen af den rejse, der har f\u00f8rt os til moderne metoder til logf\u00f8ring og overv\u00e5gning.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
![\"Vi](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")