{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"DevOps-ingeni\u00f8rer eksisterer ikke. Hvem eksisterer s\u00e5, og hvad skal vi g\u00f8re ved det?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DevOps-ingeni\u00f8rer<\/p>\n

<\/p>\n

P\u00e5 det seneste har s\u00e5danne annoncer oversv\u00f8mmet internettet. P\u00e5 trods af en attraktiv l\u00f8n kan man ikke undg\u00e5 at blive foruroliget over, at der ligger vildt vr\u00f8vl bag. I starten antages det, at 'DevOps' og 'ingeni\u00f8r' p\u00e5 en eller anden m\u00e5de kan s\u00e6ttes sammen til \u00e9t ord, hvorefter der f\u00f8lger en tilf\u00e6ldig liste af krav, hvoraf en del \u00e5benlyst er kopieret fra en sysadmin-jobbeskrivelse.<\/p>\n

<\/p>\n

I dette indl\u00e6g vil jeg gerne tale lidt om, hvordan vi er n\u00e5et dertil, hvor vi er nu, hvad DevOps faktisk er, og hvad vi nu skal g\u00f8re ved det.<\/p>\n

<\/p>\n

Disse jobopslag kan kritiseres p\u00e5 mange m\u00e5der, men faktum er, at der er mange af dem, og det er s\u00e5dan, markedet er i \u00f8jeblikket. Vi har lavet en DevOps-konference og erkl\u00e6rer \u00e5bent: 'DevOops<\/a><\/noindex> \u2014 ikke for DevOps-ingeni\u00f8rer'. Dette vil virke underligt og bizart for mange: hvorfor g\u00e5r folk, der laver et helt kommercielt arrangement, imod markedet. Vi vil nu forklare alt.<\/p>\n

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

Om kultur og processer<\/h2>\n

<\/p>\n

Lad os starte med at sige, at DevOps ikke er en ingeni\u00f8rdisciplin. Det hele startede med, at det historisk etablerede rolleopdelinger ikke fungerer for produktkvaliteten. N\u00e5r programm\u00f8rer kun programmerer, men ikke vil h\u00f8re noget om testning - fyldes softwaren med fejl. N\u00e5r administratorer ikke bryder sig om, hvordan og hvorfor softwaren er skrevet - bliver supporten til et helvede. <\/p>\n

<\/p>\n

For eksempel begyndelsen p\u00e5 beskrivelsen af forskellen mellem sysadmin- og SRE-tilgangen til service management begyndes i den ber\u00f8mte Google SRE Book.<\/a><\/noindex>Interessante unders\u00f8gelser er blevet udf\u00f8rt inden for DORA-unders\u00f8gelsen<\/a><\/noindex> \u2014 det ses, at de bedste udviklere somehow lykkes med at implementere nye \u00e6ndringer i produktion hurtigere end \u00e9n gang i timen. De tester heller ikke manuelt mere end 10% (det ses i sidste \u00e5rs DORA<\/a><\/noindex>). Hvordan kan de g\u00f8re det? 'Excel or die' \u2013 siger en af overskrifterne i rapporten. For en dybere diskussion af disse statistikker med fokus p\u00e5 testning kan man henvise til keynoten af Baruch Sadogursky. 'Vi har DevOps. Lad os fyre alle testere'<\/a><\/noindex> p\u00e5 vores anden konference, Heisenbug.<\/p>\n

<\/p>\n

'N\u00e5r der ikke er enighed blandt kammerater,
\ng\u00f8r deres arbejde ikke fremskridt,
\nog vil det ikke f\u00f8re til noget, kun elendighed.
\nEngang var der en svane, en krabbe og en gedde\u2026'<\/p><\/blockquote>\n

Hvad mener du, hvor mange webudviklere forst\u00e5r virkelig de forhold, deres applikationer k\u00f8rer under i produktion? Hvor mange af dem vil g\u00e5 til administratorerne og fors\u00f8ge at finde ud af, hvad der sker ved databasefejl? Og hvem vil ind til testeren og bede om at l\u00e6re, hvordan man korrekt skriver tests? Og der er ogs\u00e5 sikkerhedseksperter, produktmanagere og en masse andre folk.<\/p>\n

<\/p>\n

Den overordnede id\u00e9 med DevOps er at forbedre samarbejdet mellem roller og afdelinger. Dette opn\u00e5s prim\u00e6rt ikke med en smart konfigureret software, men gennem kommunikation. DevOps handler om kultur, praksis, metodologi og processer. Der findes ikke nogen ingeni\u00f8rspeciale, der kan besvare disse sp\u00f8rgsm\u00e5l.<\/p>\n

<\/p>\n

Den r\u00e5dne cirkel<\/h2>\n

<\/p>\n

Hvor stammer s\u00e5 disciplinen 'devops-ingeni\u00f8r' fra? Vi har en teori! Id\u00e9erne bag DevOps var s\u00e5 gode, at de blev ofre for deres egen succes. Omkring dette emne begyndte nogle tvivlsomme rekrutteringsfolk og menneskehandlere at samle sig, med en helt s\u00e6rlig atmosf\u00e6re.<\/p>\n

<\/p>\n

Forestil dig: i g\u00e5r lavede du shawarma i Khimki, og i dag er du allerede en vigtig person, seniorrekrutterer. Her er der en hel proces til at finde og udv\u00e6lge kandidater, det er ikke enkelt, man skal forst\u00e5 det. Antag, at afdelingslederen siger: find en specialist i X. S\u00e5 tils\u00e6tter vi 'ingeni\u00f8r' til X, s\u00e5 er det klaret. Er det Linux? S\u00e5 er det helt sikkert en Linux-ingeni\u00f8r, vil du have DevOps \u2013 s\u00e5 er det en DevOps-ingeni\u00f8r. Jobopslaget best\u00e5r ikke kun af en overskrift, men der er ogs\u00e5 brug for noget tekst. Det nemmeste er at skrive et s\u00e6t keywords fra Google, alt efter hvad man kan finde p\u00e5. DevOps best\u00e5r af to ord \u2013 'Dev' og 'Ops', s\u00e5 man skal samle keywords relateret til udviklere og administratorer, alt sammen i en bunke. S\u00e5 opst\u00e5r der jobopslag om at have kendskab til 42 programmeringssprog og 20 \u00e5rs erfaring med Kubernetes og Swarm samtidigt. Det er arbejdsmodellen.<\/p>\n

<\/p>\n

Dermed har folk f\u00e5et en meningsl\u00f8s og ubarmhjertig opfattelse af en slags superhelt 'DevOps', der vil s\u00e6tte alles deployment op p\u00e5 Jenkins, og s\u00e5 vil lykken v\u00e6re gjort. \u00c5h, hvis bare det var s\u00e5 enkelt. 'Og man kan ogs\u00e5 jage systemadministratorer med det,' t\u00e6nker HR, 'det er et moderne ord, de samme keywords, de m\u00e5 bidrage.'<\/p>\n

<\/p>\n

Eftersp\u00f8rgsel skaber udbud, og et vanvittigt antal systemadministratorer har kastet sig over disse nonsensjob, da de inds\u00e5: man kan g\u00f8re det samme som f\u00f8r, men f\u00e5 mange gange mere, ved at kalde sig selv \"devopsere\". Som du tidligere har konfigureret servere via SSH \u00e9n ad gangen, vil du forts\u00e6tte med at konfigurere, men nu er det angiveligt en devops-praksis. Det er et komplekst f\u00e6nomen, delvist knyttet til undervurdering af de klassiske administratorer og hypen omkring DevOps, men generelt \u2014 hvad der er, det er.<\/p>\n

<\/p>\n

S\u00e5 vi har eftersp\u00f8rgsel og udbud. En lukket cirkel, der n\u00e6rer sig selv. Det er dette, vi k\u00e6mper imod (herunder ved at skabe konferencen DevOops).<\/p>\n

<\/p>\n

Uden tvivl er der, udover systemadministratorer, der har omd\u00f8bt sig til \"devopsere\", ogs\u00e5 andre deltagere \u2014 for eksempel professionelle SRE'er eller Infrastructure-as-Code-udviklere.<\/p>\n

<\/p>\n

Hvad laver folk i DevOps (i virkeligheden)<\/h2>\n

<\/p>\n

S\u00e5 du \u00f8nsker at fremme din forst\u00e5else og anvendelse af DevOps-praksisser. Men hvordan g\u00f8r man det, hvilken retning skal man kigge? Det er \u00e5benlyst, at man ikke b\u00f8r blindt f\u00f8lge popul\u00e6re n\u00f8gleord.<\/p>\n

<\/p>\n

Hvis der er arbejde, er der nogen, der skal tage sig af det. Vi har allerede afklaret, at det ikke er \"devopsingeni\u00f8rer\", s\u00e5 hvem er det? Det virker mere korrekt at formulere det ikke i termer af stillinger, men i termer af specifikke arbejdsretninger.<\/p>\n

<\/p>\n

For det f\u00f8rste kan man arbejde med selve hjertet af DevOps \u2014 processer og kultur. Kultur er en langsommelig og vanskelig opgave, og selvom det traditionelt er ledernes ansvar, deltager alle, fra programm\u00f8rer til administratorer, p\u00e5 en eller anden m\u00e5de. For et par m\u00e5neder siden sagde Tim Lister i et interview<\/a><\/noindex>:<\/p>\n

<\/p>\n

\"Kultur defineres af de grundl\u00e6ggende v\u00e6rdier i organisationen. Folk l\u00e6gger som regel ikke m\u00e6rke til det, men vi, der har arbejdet i konsulentbranchen i mange \u00e5r, er vant til at afl\u00e6se det. Du tr\u00e6der ind i en virksomhed, og bogstaveligt talt efter f\u00e5 minutter begynder du at f\u00f8le, hvad der sker. Vi kalder det \"duften\". Nogle gange er denne duft virkelig behagelig. Nogle gange fremkalder den kvalme. (...) Du kan ikke \u00e6ndre kulturen, f\u00f8r v\u00e6rdierne og overbevisningerne, der ligger bag de konkrete handlinger, er blevet bevidste. Adf\u00e6rd er let at observere, men at finde overbevisninger er sv\u00e6rt. DevOps er netop et glimrende eksempel p\u00e5, hvordan alt bliver mere og mere kompliceret.\"<\/p><\/blockquote>\n

Der er selvf\u00f8lgelig ogs\u00e5 en teknisk del af sp\u00f8rgsm\u00e5let. Hvis du f\u00e5r ny kode til testning om en m\u00e5ned, men den f\u00f8rst bliver udgivet om et \u00e5r, og det ikke er fysisk muligt at fremskynde det - s\u00e5 vil du ikke n\u00e5 de gode praksisser. Gode praksisser st\u00f8ttes af gode v\u00e6rkt\u00f8jer. For eksempel, ved at have id\u00e9en om Infrastructure-as-Code i tankerne, kan man bruge hvad som helst fra AWS CloudFormation og Terraform til Chef-Ansible-Puppet. Alt dette skal man kende til og kunne, og det er allerede en ingeni\u00f8rdisciplin. Det er vigtigt ikke at forveksle \u00e5rsag med virkning: F\u00f8rst arbejder du efter SRE-principperne, og derefter oms\u00e6tter du disse principper i form af konkrete tekniske l\u00f8sninger. SRE er en meget kompleks metode, der ikke handler om, hvordan man konfigurerer Jenkins, men om fem grundl\u00e6ggende principper:<\/p>\n

<\/p>\n