{"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\/sv\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"Det finns inga DevOps-ingenj\u00f6rer. Vem existerar d\u00e5, och vad ska vi g\u00f6ra med det?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Det<\/p>\n

<\/p>\n

P\u00e5 senare tid har s\u00e5dana annonser fyllt internet. Trots den attraktiva l\u00f6nen kan man inte undg\u00e5 att notera att det som st\u00e5r skrivet inuti \u00e4r ren galenskap. I b\u00f6rjan f\u00f6ruts\u00e4tts att \"DevOps\" och \"ingenj\u00f6r\" p\u00e5 n\u00e5got s\u00e4tt kan sammanfogas till ett enda ord, och sedan f\u00f6ljer en slumpm\u00e4ssig lista av krav, varav en del tydligt har kopierats fr\u00e5n en administrat\u00f6rs jobbannons.<\/p>\n

<\/p>\n

I det h\u00e4r inl\u00e4gget vill jag prata lite om hur vi kommit till denna situation, vad DevOps verkligen \u00e4r och vad som nu ska g\u00f6ras med det.<\/p>\n

<\/p>\n

S\u00e5dana jobbannonser kan man kritisera p\u00e5 m\u00e5nga s\u00e4tt, men faktum kvarst\u00e5r: de \u00e4r m\u00e5nga, och s\u00e5 ser marknaden ut just nu. Vi har anordnat en DevOps-konferens och s\u00e4ger \u00f6ppet: \"DevOops<\/a><\/noindex> \u2014 inte f\u00f6r DevOps-ingenj\u00f6rer.\" M\u00e5nga kommer att tycka att det \u00e4r b\u00e5de konstigt och galet: varf\u00f6r g\u00e5r m\u00e4nniskor som arrangerar ett helt kommersiellt evenemang emot marknaden? Nu ska vi f\u00f6rklara allt.<\/p>\n

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

Om kultur och processer<\/h2>\n

<\/p>\n

L\u00e5t oss b\u00f6rja med att s\u00e4ga att DevOps inte \u00e4r en ingenj\u00f6rsdiciplin. Det hela b\u00f6rjade med att den historiskt inarbetade uppdelningen av roller inte fungerar f\u00f6r produktens kvalitet. N\u00e4r programmerare bara programmerar, men inte vill h\u00f6ra n\u00e5got om testning, blir mjukvaran fylld med buggar. N\u00e4r administrat\u00f6rer inte bryr sig om hur och varf\u00f6r mjukvaran \u00e4r skriven, s\u00e5 blir st\u00f6det en mardr\u00f6m. <\/p>\n

<\/p>\n

Till exempel b\u00f6rjar beskrivningen av skillnaden mellan en administrat\u00f6rs och ett SRE:s tillv\u00e4gag\u00e5ngss\u00e4tt till service management den ber\u00f6mda Google SRE-boken.<\/a><\/noindex>Intressanta studier har genomf\u00f6rts i samband med DORA-unders\u00f6kningen,<\/a><\/noindex> \u2014 det \u00e4r tydligt att de b\u00e4sta utvecklarna p\u00e5 n\u00e5got s\u00e4tt lyckas f\u00e5 ut nya f\u00f6r\u00e4ndringar i produktion snabbare \u00e4n en g\u00e5ng i timmen. De testar dessutom manuellt inte mer \u00e4n 10% (det syns i f\u00f6rra \u00e5rets DORA).<\/a><\/noindex>Hur lyckas de med detta? \"Excel or die\" \u2013 s\u00e4ger en av rubrikerna i rapporten. F\u00f6r en djupare diskussion kring dessa statistiken i testningsperspektiv kan man h\u00e4nvisa till keynoten av Baruch Sadogursky \"Vi har DevOps. L\u00e5t oss sparka alla testare\"<\/a><\/noindex> vid v\u00e5r andra konferens, Heisenbug.<\/p>\n

<\/p>\n

\"N\u00e4r det inte finns n\u00e5gon samst\u00e4mmighet bland kamrater,
\nD\u00e5 kommer ingenting att g\u00e5 fram\u00e5t,
\nOch det kommer att resultera i inget annat \u00e4n lidande. \"
\nEn g\u00e5ng var det en Svane, en Krabba och en G\u00e4rs\u2026\"<\/p><\/blockquote>\n

Vad tror ni, vilken del av webbprogrammerare verkligen f\u00f6rst\u00e5r under vilka f\u00f6rh\u00e5llanden deras applikationer k\u00f6rs i produktion? Hur m\u00e5nga av dem kommer att g\u00e5 till admin och f\u00f6rs\u00f6ka r\u00e4kna ut vad som h\u00e4nder vid en databasnedg\u00e5ng? Och vem av dem kommer att g\u00e5 till testarna och be att f\u00e5 l\u00e4ra sig hur man skriver tester p\u00e5 r\u00e4tt s\u00e4tt? Och s\u00e5 finns det s\u00e4kerhetsfolk, produktchefer, en m\u00e4ngd andra m\u00e4nniskor.<\/p>\n

<\/p>\n

Den \u00f6vergripande id\u00e9n med DevOps \u00e4r att f\u00f6rb\u00e4ttra samarbetet mellan roller och avdelningar. Detta uppn\u00e5s i f\u00f6rsta hand inte genom n\u00e5gon smart konfigurerad mjukvara, utan genom kommunikationspraxis. DevOps handlar om kultur, praktik, metodik och processer. Det finns ingen s\u00e5dan ingenj\u00f6rsspecialitet som svarar p\u00e5 dessa fr\u00e5gor.<\/p>\n

<\/p>\n

En ond cirkel<\/h2>\n

<\/p>\n

Varifr\u00e5n kom d\u00e5 disciplinen \"DevOps-ingenj\u00f6r\"? Vi har en version! Id\u00e9erna bakom DevOps visade sig vara s\u00e5 bra att de blev offer f\u00f6r sin egen framg\u00e5ng. Runt hela detta \u00e4mne b\u00f6rjade det surra av suspekta rekryterare och m\u00e4nniskohandlare, som har sin egen speciella atmosf\u00e4r.<\/p>\n

<\/p>\n

T\u00e4nk dig: ig\u00e5r lagade du shawarma i Khimki, och idag \u00e4r du redan en stor person, senior rekryterare. H\u00e4r finns en hel process f\u00f6r att hitta och v\u00e4lja kandidater, allt \u00e4r inte enkelt, man m\u00e5ste f\u00f6rst\u00e5. Anta att avdelningschefen s\u00e4ger: hitta en specialist p\u00e5 X. Vi l\u00e4gger till ordet \"ingenj\u00f6r\" till X, och d\u00e4r \u00e4r problemet l\u00f6st. Beh\u00f6vs Linux? Ja, det \u00e4r definitivt en Linux-ingenj\u00f6r, vill du ha DevOps \u2013 en DevOps-ingenj\u00f6r. En jobbannons best\u00e5r inte bara av en rubrik, utan det beh\u00f6vs ocks\u00e5 n\u00e5gon text inuti. Det enklaste \u00e4r att skriva en upps\u00e4ttning nyckelord fr\u00e5n Google, vad man nu kan t\u00e4nka sig. DevOps best\u00e5r av tv\u00e5 ord \u2013 \"Dev\" och \"Ops\", s\u00e5 det m\u00e5ste klistras ihop nyckelord relaterade till utvecklare och administrat\u00f6rer till en enda h\u00f6g. S\u00e5 h\u00e4r uppst\u00e5r jobbannonser om att beh\u00e4rska 42 programmeringsspr\u00e5k och 20 \u00e5rs erfarenhet av att anv\u00e4nda Kubernetes och Swarm samtidigt. En fungerande strategi.<\/p>\n

<\/p>\n

S\u00e5dana bilder har rotat sig djupt i m\u00e4nniskors medvetande om en meningsl\u00f6s och h\u00e4nsynsl\u00f6s bild av en superhj\u00e4lte \"DevOps\", som konfigurerar alla distributioner p\u00e5 Jenkins, och d\u00e5 kommer lyckan. \u00c5h, om bara allt var s\u00e5 enkelt. \"Och s\u00e5 kan man ocks\u00e5 jaga systemadministrat\u00f6rer, t\u00e4nker HR, ett trendigt ord, samma nyckelord, de borde nappa.\"<\/p>\n

<\/p>\n

Efterfr\u00e5gan skapar utbud, och p\u00e5 alla dessa tramsjobb har en galen m\u00e4ngd systemadministrat\u00f6rer kommit in, som har insett: man kan g\u00f6ra samma sak som tidigare, men f\u00e5 mycket mer betalt, genom att kalla sig 'DevOps'. S\u00e5 som du konfigurerade servrar via SSH handgripligen en i taget, forts\u00e4tter du nu att g\u00f6ra det, men nu \u00e4r det s\u00e5 kallad DevOps-praxis. Detta \u00e4r en komplex f\u00f6reteelse, delvis relaterad till underv\u00e4rderingen av klassiska admin-personer och hypen kring DevOps, men i stort sett \u2014 vad som har h\u00e4nt, har h\u00e4nt.<\/p>\n

<\/p>\n

S\u00e5, vi har efterfr\u00e5gan och utbud. En sluten krets som f\u00f6der sig sj\u00e4lv. Det h\u00e4r k\u00e4mpa vi emot (inklusive genom att skapa konferensen DevOops).<\/p>\n

<\/p>\n

Sj\u00e4lvklart, f\u00f6rutom systemadministrat\u00f6rer som har omd\u00f6pt sig till 'DevOps', finns det andra deltagare \u2014 till exempel professionella SRE eller utvecklare av Infrastructure-as-Code.<\/p>\n

<\/p>\n

Vad m\u00e4nniskor faktiskt sysslar med inom DevOps<\/h2>\n

<\/p>\n

S\u00e5, du vill g\u00e5 vidare med att l\u00e4ra dig och till\u00e4mpa DevOps-praktiker. Men hur g\u00f6r man det, vilken riktning ska man titta mot? Det \u00e4r uppenbart att man inte ska blint f\u00f6lja popul\u00e4ra nyckelord.<\/p>\n

<\/p>\n

Om det finns arbete, m\u00e5ste n\u00e5gon utf\u00f6ra det. Vi har redan kommit fram till att det inte \u00e4r 'DevOps-ingenj\u00f6rer', s\u00e5 vem \u00e4r det? Det verkar b\u00e4ttre att formulera detta inte i termer av positioner, utan i specifika arbetsomr\u00e5den.<\/p>\n

<\/p>\n

F\u00f6r det f\u00f6rsta kan man syssla med sj\u00e4lva k\u00e4rnan av DevOps \u2014 processer och kultur. Kultur \u00e4r ingen snabb eller l\u00e4tt sak, och \u00e4ven om det traditionellt \u00e4r ett ansvar som vilar p\u00e5 ledarna, deltar alla p\u00e5 n\u00e5got s\u00e4tt i detta, fr\u00e5n programmerare till administrat\u00f6rer. F\u00f6r n\u00e5gra m\u00e5nader sedan sa Tim Lister i en intervju<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u2018Kultur definieras av de grundl\u00e4ggande v\u00e4rderingarna i organisationen. Vanligtvis m\u00e4rker m\u00e4nniskor inte detta, men vi, som har arbetat inom konsultverksamhet i m\u00e5nga \u00e5r, \u00e4r vana vid att notera det. Du g\u00e5r in i ett f\u00f6retag och bokstavligen inom n\u00e5gra minuter b\u00f6rjar du k\u00e4nna vad som p\u00e5g\u00e5r. Vi kallar det 'doften'. Ibland \u00e4r denna doft verkligen trevlig. Ibland orsakar den illam\u00e5ende. (\u2026) Du kan inte f\u00f6r\u00e4ndra kulturen innan v\u00e4rderingarna och \u00f6vertygelserna bakom specifika handlingar har blivit medvetna. Det \u00e4r l\u00e4tt att observera beteende, men sv\u00e5rt att leta efter \u00f6vertygelser. DevOps \u00e4r faktiskt ett utm\u00e4rkt exempel p\u00e5 hur allt blir mer och mer komplicerat.\u2019<\/p><\/blockquote>\n

Det finns s\u00e5klart en teknisk del av fr\u00e5gan. Om du f\u00e5r ny kod f\u00f6r testning om en m\u00e5nad, men den inte sl\u00e4pps f\u00f6rr\u00e4n om ett \u00e5r, och det rent fysiskt inte g\u00e5r att p\u00e5skynda allt detta \u2013 d\u00e5 kan man missa de b\u00e4sta metoderna. Bra metoder underst\u00f6ds av bra verktyg. Till exempel, genom att ha id\u00e9en om Infrastructure-as-Code i \u00e5tanke kan du anv\u00e4nda vad som helst, fr\u00e5n AWS CloudFormation och Terraform till Chef-Ansible-Puppet. Allt detta m\u00e5ste man k\u00e4nna till och kunna, och det \u00e4r verkligen en ingenj\u00f6rsdiciplin. Det \u00e4r viktigt att inte blanda ihop orsaken och verkan: f\u00f6rst arbetar man efter SRE-principerna och sedan f\u00f6rverkligar man dessa principer i form av specifika tekniska l\u00f6sningar. Samtidigt \u00e4r SRE en mycket komplex metodik som handlar om mer \u00e4n hur man konfigurerar Jenkins; det handlar om fem grundprinciper:<\/p>\n

<\/p>\n