{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Hvem er DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I \u00f8jeblikket er dette muligvis den dyreste position p\u00e5 markedet. Hype omkring 'DevOps' ingeni\u00f8rer overstiger alle t\u00e6nkelige gr\u00e6nser, endnu v\u00e6rre er det med Senior DevOps ingeni\u00f8rer.
\nJeg arbejder som leder af integrations- og automatiseringsafdelingen, s\u00e5 g\u00e6t den engelske forkortelse \u2014 DevOps Manager. Reflekterer den engelske version pr\u00e6cist vores daglige arbejde? N\u00e6ppe, men den russiske betegnelse er mere pr\u00e6cis i dette tilf\u00e6lde. I mit job er det naturligvis n\u00f8dvendigt for mig at interviewe potentielle nye medlemmer af mit team, og i l\u00f8bet af det seneste \u00e5r har jeg haft omkring 50 ans\u00f8gere igennem, og lige s\u00e5 mange er blevet sorteret fra efter mine medarbejderes pr\u00e6screening.<\/p>\n

<\/p>\n

Vi er stadig p\u00e5 udkig efter kolleger, da der under betegnelsen DevOps gemmer sig en stor og varieret gruppe ingeni\u00f8rer.<\/a><\/noindex><\/p>\n

<\/p>\n

Alt, hvad der st\u00e5r nedenfor, er min personlige mening; du er ikke forpligtet til at v\u00e6re enig, men jeg tillader mig at tro, at det kan give et nuanceret perspektiv p\u00e5 emnet. P\u00e5 trods af risikoen for at tr\u00e6de forkert offentligg\u00f8r jeg mit synspunkt, fordi jeg mener, der er plads til det.<\/p>\n

<\/p>\n

Virksomheder har forskellige opfattelser af, hvem DevOps ingeni\u00f8rer er, og for hurtigt at ans\u00e6tte arbejdskraft h\u00e6nger de denne etikette p\u00e5 alle. Situationen er ret m\u00e6rkelig, da virksomheder er villige til at betale uh\u00f8rte bel\u00f8b til disse mennesker, mens de ofte kun f\u00e5r en administrator-mulighed i stedet.<\/p>\n

<\/p>\n

S\u00e5 hvem er DevOps ingeni\u00f8rer egentlig?<\/h2>\n

<\/p>\n

Lad os starte med historien om udviklingen \u2013 Development Operations opstod som et endnu et skridt hen imod at optimere samarbejdet i sm\u00e5 teams for at \u00f8ge hastigheden i produktionsprocessen som en forventet konsekvens. Ideen var at styrke udviklingsteamet med viden om processer og metoder i produktmilj\u00f8styring. Med andre ord skal en udvikler forst\u00e5, hvordan hans produkt fungerer under forskellige forhold, forst\u00e5 hvordan man deployer sit produkt, og hvilke milj\u00f8karakteristika der skal justeres for at forbedre ydeevnen. P\u00e5 den m\u00e5de opstod der over tid udviklere med en DevOps tilgang. DevOps udviklere skrev build- og pakkescripts for at forenkle deres opgaver og funktionaliteten i det produktive milj\u00f8. Men kompleksiteten i arkitekturen af l\u00f8sninger og interaktionen mellem infrastrukturkomponenter begyndte med tiden at forv\u00e6rre arbejdseffektiviteten i milj\u00f8erne; med hver iteration kr\u00e6vedes der dybere forst\u00e5else af diverse komponenter, hvilket s\u00e6nkede selve udviklerens produktivitet p\u00e5 grund af de ekstra omkostninger ved at forst\u00e5 komponenterne og tilpasse systemer til specifikke opgaver. Den reelle omkostning for udvikleren voksede, ligesom produktets omkostning, og kravene til nye udviklere i teamet steg markant, da de ogs\u00e5 skulle d\u00e6kke de opgaver, som \"stjernen\" i udviklingen havde. Og naturligvis blev \"stjernerne\" mindre tilg\u00e6ngelige. Det er ogs\u00e5 v\u00e6rd at n\u00e6vne, at efter min erfaring er der ikke mange udviklere, der er interesseret i detaljerne omkring pakkeh\u00e5ndtering i operativsystemets kerne, regler for pakketrafik og aspekter af v\u00e6rtssikkerhed. Det logiske skridt var at involvere en administrator, som netop har erfaring med dette, og p\u00e5l\u00e6gge s\u00e5danne opgaver til ham, hvilket, takket v\u00e6re hans erfaring, muligg\u00f8r at n\u00e5 de samme m\u00e5ls\u00e6tninger til en lavere omkostning sammenlignet med omkostningerne ved en \"stjerne\" i udviklingen. Disse administratorer blev integreret i teamet med det prim\u00e6re m\u00e5l at styre test- og produktionsmilj\u00f8er, baseret p\u00e5 reglerne for det specifikke team, med ressourcer tildelt netop dette team. P\u00e5 den m\u00e5de opstod DevOps som de fleste kender dem.<\/p>\n

<\/p>\n

Over time, partially or completely, system administrators began to understand the needs of this specific development team\u2014how to simplify the lives of developers and testers, how to roll out updates without staying overnight in the office on a Friday to fix deployment errors. As time went by, system administrators became the 'stars,' understanding what developers wanted. To minimize impact, management utilities started to emerge, and everyone remembered the old and reliable OS-level isolation methods that minimized security, network management requirements, and overall host configuration, consequently reducing demands on the new 'stars.' <\/p>\n

<\/p>\n

A 'wonderful' thing emerged\u2014Docker. Why is it wonderful? Simply because creating isolation in chroot or jail, just like OpenVZ, required non-trivial OS knowledge, while the utility allows you to easily create an isolated application environment on a host with everything you need inside, handing control back to developers while the system administrator only has to manage one host, ensuring its security and high availability\u2014logical simplification. But progress does not stand still, and systems are becoming increasingly complex, with more and more components; one host no longer meets system needs, and it is necessary to build clusters, bringing us back to system administrators who can construct these systems.<\/p>\n

<\/p>\n

Cycle after cycle, various systems emerge to simplify development and\/or administration, along with orchestration systems that remain easy to use\u2014up until the point where there is a deviation from the standard process. Microservice architecture also emerged to simplify all of the above\u2014fewer interconnections, easier management. In my experience, I have not encountered a fully microservice architecture; I would say it's 50\/50\u201450 percent microservices, black boxes that take input and return processed output, and 50 percent a fragmented monolith, where services cannot function independently of other components. All of this again placed limitations on the knowledge levels required of both developers and administrators.<\/p>\n

<\/p>\n

De samme \"gynger\" af ekspertviden om en eller anden ressource forts\u00e6tter den dag i dag. Men vi blev lidt distraheret, der er mange aspekter, som det er v\u00e6rd at belyse.<\/p>\n

<\/p>\n

Build Engineer\/Release Engineer<\/h2>\n

<\/p>\n

Meget specialiserede ingeni\u00f8rer, der opstod som et middel til at standardisere processerne for softwarebygning og udgivelser. I takt med indf\u00f8relsen af den udbredte Agile metode syntes de at v\u00e6re blevet irrelevante, men det er langt fra tilf\u00e6ldet. Denne specialisering blev skabt som en m\u00e5de at standardisere netop bygning og levering af software i industriel skala, dvs. ved at bruge standardteknikker for alle virksomhedens produkter. Med fremkomsten af DevOps har udviklerne delvist mistet funktioner, da det netop er udviklerne, der er kommet til at forberede produktet til levering, og med den \u00e6ndrede infrastruktur og tilgang til hurtig levering uden hensyntagen til kvalitet er de over tid blevet en hindring for \u00e6ndringer, da overholdelse af kvalitetsstandarder uundg\u00e5eligt bremser leveringen. S\u00e5ledes er en del af funktionaliteten fra Build\/Release ingeni\u00f8rerne gradvist flyttet til systemadministratorerne.<\/p>\n

<\/p>\n

Ops'ene er s\u00e5 forskellige<\/h2>\n

<\/p>\n

Vi bev\u00e6ger os videre, og atter en gang presser mange opgaver og mangel p\u00e5 kvalificeret arbejdskraft os til st\u00e6rk specialisering; som svampe efter regn dukker forskellige operations-specialiseringer op:<\/p>\n

<\/p>\n