{"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\/sv\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Vad \u00e4r DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

F\u00f6r n\u00e4rvarande \u00e4r detta n\u00e4stan den dyraste positionen p\u00e5 marknaden. Hysterin kring DevOps-ingenj\u00f6rer \u00f6verstiger alla t\u00e4nkbara gr\u00e4nser, och det \u00e4r \u00e4nnu v\u00e4rre med Senior DevOps-ingenj\u00f6rer.
\nJag arbetar som chef f\u00f6r integrations- och automatiseringsavdelningen, gissa den engelska f\u00f6rkortningen \u2014 DevOps Manager. Speglar den engelska f\u00f6rkortningen verkligen v\u00e5r vardagliga verksamhet \u2014 knappast, men den ryska varianten \u00e4r i detta fall mer exakt. I min roll \u00e4r det naturligtvis n\u00f6dv\u00e4ndigt f\u00f6r mig att intervjua framtida medlemmar av mitt team, och under det g\u00e5ngna \u00e5ret har jag m\u00f6tt cirka 50 personer, och lika m\u00e5nga har sorterat bort under prescreening med mina anst\u00e4llda.<\/p>\n

<\/p>\n

Vi \u00e4r fortfarande p\u00e5 jakt efter kollegor, eftersom det bakom etiketten DevOps d\u00f6ljer sig en mycket stor grupp av olika typer av ingenj\u00f6rer.<\/a><\/noindex><\/p>\n

<\/p>\n

Allt som st\u00e5r nedan \u00e4r min personliga \u00e5sikt, ni beh\u00f6ver inte h\u00e5lla med, men jag till\u00e5ter mig att tro att det kan f\u00e4rga er uppfattning om \u00e4mnet. Trots risken att hamna i ogynnsam dager publicerar jag min \u00e5sikt, eftersom jag anser att den har sin plats.<\/p>\n

<\/p>\n

F\u00f6retag har olika uppfattningar om vem DevOps-ingenj\u00f6rer \u00e4r och f\u00f6r att snabbt rekrytera resurser s\u00e4tter de den etiketten p\u00e5 alla. Situationen \u00e4r ganska m\u00e4rklig, eftersom f\u00f6retagen \u00e4r villiga att betala osannolika bel\u00f6ningar till dessa personer, men i de flesta fall f\u00e5r de en administrat\u00f6r-verktygsspecialist.<\/p>\n

<\/p>\n

S\u00e5 vem \u00e4r egentligen DevOps-ingenj\u00f6rer?<\/h2>\n

<\/p>\n

L\u00e5t oss b\u00f6rja med historien om utvecklingen av Development Operations \u2014 det kom som ett steg mot att optimera samarbetet i sm\u00e5 team f\u00f6r att \u00f6ka produktionshastigheten, som en f\u00f6rv\u00e4ntad f\u00f6ljd. Id\u00e9n var att f\u00f6rst\u00e4rka utvecklingsteamet med kunskap om procedurer och metoder f\u00f6r att hantera produktmilj\u00f6er. Med andra ord borde en utvecklare f\u00f6rst\u00e5 och veta hur deras produkt fungerar under olika f\u00f6rh\u00e5llanden, f\u00f6rst\u00e5 hur man distribuerar sin produkt, vilka egenskaper i milj\u00f6n som ska justeras f\u00f6r att \u00f6ka prestandan. S\u00e5, under en tid, d\u00f6k det upp utvecklare med DevOps-ansats. DevOps-utvecklare skrev skript f\u00f6r byggande och paketering f\u00f6r att f\u00f6renkla sitt arbete och funktionaliteten i produktionsmilj\u00f6n. Men med tiden b\u00f6rjade komplexiteten i l\u00f6sningarnas arkitektur och det \u00f6msesidiga inflytandet av infrastrukturkomponenter f\u00f6rs\u00e4mra arbetsresultaten; med varje iteration kr\u00e4vdes en djupare f\u00f6rst\u00e5else av olika komponenter, vilket minskade utvecklarens produktivitet p\u00e5 grund av den extra tiden som beh\u00f6vdes f\u00f6r att f\u00f6rst\u00e5 komponenterna och finjustera systemen f\u00f6r specifika uppgifter. Utvecklarens egen kostnad \u00f6kade, kostnaden f\u00f6r produkten steg ocks\u00e5, och kraven p\u00e5 nya utvecklare i teamet sk\u00f6t i h\u00f6jden, eftersom de ocks\u00e5 beh\u00f6vde t\u00e4cka ansvaret f\u00f6r \"stj\u00e4rnorna\" i utvecklingen, och naturligtvis blev \"stj\u00e4rnorna\" allt mindre tillg\u00e4ngliga. Det \u00e4r ocks\u00e5 v\u00e4rt att notera att, enligt min erfarenhet, \u00e4r f\u00e5 utvecklare intresserade av specifikationer f\u00f6r hur paket behandlas av operativsystemets k\u00e4rna, regler f\u00f6r paket-routing, och aspekter av v\u00e4rd-s\u00e4kerhet. Det logiska steget blev att involvera en administrat\u00f6r, som \u00e4r bekant med dessa fr\u00e5gor, och \u00e5l\u00e4gga ansvar av det h\u00e4r formatet p\u00e5 honom; tack vare hans erfarenhet kunde samma resultat uppn\u00e5s till en l\u00e4gre kostnad j\u00e4mf\u00f6rt med \"stj\u00e4rnans\" kostnad i utvecklingen. Dessa administrat\u00f6rer placerades i teamet, och deras huvudsakliga uppgift var att hantera test- och produktionsmilj\u00f6er, baserat p\u00e5 reglerna f\u00f6r just det teamet, med resurser avdelade f\u00f6r just detta team. S\u00e5, i grund och botten, kom DevOps till de flestas uppfattning.<\/p>\n

<\/p>\n

Delvis eller helt, med tiden har dessa systemadministrat\u00f6rer b\u00f6rjat f\u00f6rst\u00e5 behoven hos just detta specifika team inom utveckling, hur man underl\u00e4ttar livet f\u00f6r utvecklare och testare, hur man rullar ut en uppdatering utan att beh\u00f6va spendera natten p\u00e5 kontoret p\u00e5 fredag f\u00f6r att \u00e5tg\u00e4rda deploy-fel. Tiden gick, nu blev systemadministrat\u00f6rerna \"stj\u00e4rnor\" som f\u00f6rstod vad utvecklarna ville ha. F\u00f6r att minimera effekten b\u00f6rjade verktyg f\u00f6r hantering dyka upp, alla kom ih\u00e5g gamla och p\u00e5litliga metoder f\u00f6r OS-isolering som kunde minimera s\u00e4kerhetskraven, hanteringen av n\u00e4tverksdelen och \u00e4ven konfigurationen av v\u00e4rden i stort, vilket i sin tur minskade kraven p\u00e5 de nya \"stj\u00e4rnorna\". <\/p>\n

<\/p>\n

En \"fantastisk\" sak d\u00f6k upp - docker. Varf\u00f6r fantastisk? Endast f\u00f6r att skapa isolering i chroot eller jail, liksom OpenVZ, kr\u00e4vde icke-triviala kunskaper om OS, medan det i kontrast med verktyget, som enkelt m\u00f6jligg\u00f6r skapandet av en isolerad applikationsmilj\u00f6 p\u00e5 en v\u00e4rd med allt n\u00f6dv\u00e4ndigt inuti, och \u00e5ter \u00f6verl\u00e4mna styrningen till utvecklingen, medan systemadministrat\u00f6ren bara beh\u00f6vde hantera en v\u00e4rd och s\u00e4kerst\u00e4lla dess s\u00e4kerhet och h\u00f6ga tillg\u00e4nglighet - en logisk f\u00f6renkling. Men framsteg st\u00e5r inte still, och systemen blir \u00e5terigen allt mer komplexa, komponenterna \u00f6kar i antal, en enda v\u00e4rd r\u00e4cker inte l\u00e4ngre f\u00f6r systemets behov och det \u00e4r n\u00f6dv\u00e4ndigt att bygga kluster, vi \u00e5terv\u00e4nder till systemadministrat\u00f6rerna som \u00e4r kapabla att bygga dessa system.<\/p>\n

<\/p>\n

Cykel efter cykel dyker olika system upp som f\u00f6renklar utveckling och\/eller administration, det dyker upp orkestreringssystem som, tills det beh\u00f6vs avvika fr\u00e5n standardprocessen, \u00e4r enkla att anv\u00e4nda. Mikrotj\u00e4nstarkitektur har ocks\u00e5 dykt upp med syftet att f\u00f6renkla allt ovanst\u00e5ende - f\u00e4rre relationer, l\u00e4ttare att hantera. I min erfarenhet har jag inte sett en helt mikrotj\u00e4nstarkitektur, jag skulle s\u00e4ga 50-50 - 50 procent mikrotj\u00e4nster, svarta l\u00e5dor, vad som kom in, kom ut bearbetat, andra 50 - en s\u00f6nderdelad monolit, tj\u00e4nster of\u00f6rm\u00f6gna att fungera oberoende av andra komponenter. Allt detta har \u00e5terigen inf\u00f6rt begr\u00e4nsningar p\u00e5 kunskapsniv\u00e5n b\u00e5de hos utvecklarna och administrat\u00f6rerna.<\/p>\n

<\/p>\n

Liknande expertkunskaper p\u00e5 olika resurser forts\u00e4tter \u00e4n idag. Men vi har kommit lite off-topic, det finns flera aspekter som f\u00f6rtj\u00e4nar att belysas.<\/p>\n

<\/p>\n

Byggingenj\u00f6r\/Release Engineer<\/h2>\n

<\/p>\n

Dessa mycket specialiserade ingenj\u00f6rer uppstod som ett s\u00e4tt att standardisera processerna f\u00f6r mjukvarubyggnation och dess releaser. I och med inf\u00f6randet av den allm\u00e4ldiga Agile-metodiken tycktes de ha f\u00f6rlorat sin relevans, men s\u00e5 \u00e4r verkligen inte fallet. Detta yrke har blivit till f\u00f6r att standardisera just byggnation och leverans av mjukvara i stor skala, det vill s\u00e4ga att anv\u00e4nda standardiserade tekniker f\u00f6r alla f\u00f6retagets produkter. Med inf\u00f6randet av DevOps har utvecklarna delvis tagit \u00f6ver funktionerna, eftersom det just \u00e4r utvecklarna som f\u00f6rbereder produkten f\u00f6r leverans, och med den f\u00f6r\u00e4nderliga infrastrukturen och tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r att leverera s\u00e5 snabbt som m\u00f6jligt utan att t\u00e4nka p\u00e5 kvalitet, har de \u00f6ver tid blivit ett hinder f\u00f6r f\u00f6r\u00e4ndringar, eftersom att f\u00f6lja kvalitetsstandarder ofr\u00e5nkomligen saktar ner leveranserna. S\u00e5ledes har gradvis delar av Build\/Release-ingenj\u00f6rernas funktioner \u00f6verg\u00e5tt till systemadministrat\u00f6rer.<\/p>\n

<\/p>\n

Ops’er \u00e4r s\u00e5 olika<\/h2>\n

<\/p>\n

Vi g\u00e5r vidare och \u00e5terigen driver en stor upps\u00e4ttning ansvarsomr\u00e5den och bristen p\u00e5 kvalificerad personal oss mot en str\u00e4ng specialisering. Som svampar efter regn dyker det upp olika Operations:<\/p>\n

<\/p>\n