{"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\/ro\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"Nu exist\u0103 ingineri DevOps. Atunci, cine exist\u0103 \u0219i ce s\u0103 facem cu asta?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nu<\/p>\n

<\/p>\n

Recentemente, astfel de anun\u021buri au inundat internetul. \u00cen ciuda unui salariu atractiv, este imposibil s\u0103 nu te deranjeze faptul c\u0103 \u00een interior este scris\u0103 o prostie grozav\u0103. La \u00eenceput, se presupune c\u0103 \"DevOps\" \u0219i \"inginer\" pot fi somehow lipite \u00eentr-un singur cuv\u00e2nt, iar apoi urmeaz\u0103 o list\u0103 aleatorie de cerin\u021be, parte dintre ele fiind evident copiate dintr-o ofert\u0103 de munc\u0103 pentru sistem administrator.<\/p>\n

<\/p>\n

\u00cen aceast\u0103 postare, vrem s\u0103 discut\u0103m pu\u021bin despre cum am ajuns aici, ce este, de fapt, DevOps \u0219i ce ar trebui s\u0103 facem cu aceasta acum.<\/p>\n

<\/p>\n

Astfel de oferte de munc\u0103 pot fi criticate \u00een multe feluri, dar faptul r\u0103m\u00e2ne: sunt multe \u0219i a\u0219a arat\u0103 pia\u021ba \u00een acest moment. Am organizat o conferin\u021b\u0103 de DevOps \u0219i declar\u0103m deschis: \"DevOops<\/a><\/noindex> \u2014 nu pentru inginerii DevOps\". Aici mul\u021bi vor considera ciudat \u0219i absurd: de ce oamenii care organizeaz\u0103 un eveniment complet comercial merg \u00eempotriva pie\u021bei. Acum vom explica totul.<\/p>\n

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

Despre cultur\u0103 \u0219i procese<\/h2>\n

<\/p>\n

S\u0103 \u00eencepem cu faptul c\u0103 DevOps nu este o disciplin\u0103 ingineresc\u0103. Totul a \u00eenceput din cauza faptului c\u0103 diviziunea istoric\u0103 pe roluri nu func\u021bioneaz\u0103 pentru calitatea produselor. C\u00e2nd programatorii doar programeaz\u0103, dar nu vor s\u0103 aud\u0103 nimic despre testare, software-ul este umplut cu bug-uri. C\u00e2nd administratorii nu le pas\u0103 cum \u0219i de ce este scris software-ul, suportul se transform\u0103 \u00eentr-un co\u0219mar. <\/p>\n

<\/p>\n

De exemplu, descrierea diferen\u021bei dintre abordarea de sistem administrator \u0219i cea SRE \u00een managementul serviciilor \u00eencepe celebra Google SRE Book.<\/a><\/noindex>. S-au realizat studii interesante \u00een cadrul sondajului DORA<\/a><\/noindex> \u2014 se observ\u0103 c\u0103 cei mai buni dezvoltatori reu\u0219esc somehow s\u0103 implementeze noi modific\u0103ri \u00een produc\u021bie mai repede dec\u00e2t o dat\u0103 la or\u0103. Ei testeaz\u0103 manual nu mai mult de 10% (asta se vede dup\u0103 sondajul DORA de anul trecut<\/a><\/noindex>). Cum reu\u0219esc s\u0103 fac\u0103 acest lucru? \"Excel sau nu\" \u2013 spune unul dintre titlurile raportului. Pentru o discu\u021bie detaliat\u0103 despre aceast\u0103 statistic\u0103 \u00een contextul test\u0103rii, pute\u021bi s\u0103 consulta\u021bi keynote-ul lui Baruch Sadogursky \"Avem DevOps. S\u0103-i concediem pe to\u021bi testeri\"<\/a><\/noindex> la o alt\u0103 conferin\u021b\u0103 a noastr\u0103, Heisenbug.<\/p>\n

<\/p>\n

\"C\u00e2nd nu exist\u0103 acord \u00eentre camarazi,
\nLucrul lor nu va merge,
\n\u0218i nu va ie\u0219i nimic din el, dec\u00e2t suferin\u021b\u0103.
\nC\u00e2ndva, Leb\u0103da, Raca \u0219i \u021aarca...\"<\/p><\/blockquote>\n

Ce p\u0103rere ave\u021bi, c\u00e2\u021bi web-developeri \u00een\u021beleg cu adev\u0103rat \u00een ce condi\u021bii func\u021bioneaz\u0103 aplica\u021biile lor \u00een produc\u021bie? C\u00e2\u021bi dintre ei se vor duce la administratori pentru a \u00eencerca s\u0103 \u00een\u021beleag\u0103 ce se \u00eent\u00e2mpl\u0103 \u00een cazul unei c\u0103deri a bazei de date? \u0218i c\u00e2\u021bi dintre ei se vor duce la testerii \u0219i vor cere s\u0103 \u00eenve\u021be cum s\u0103 scrie corespunz\u0103tor teste? Iar acolo mai sunt \u0219i speciali\u0219ti \u00een securitate, manageri de produs \u0219i o gr\u0103mad\u0103 de al\u021bi oameni.<\/p>\n

<\/p>\n

Ideea general\u0103 a DevOps este de a \u00eembun\u0103t\u0103\u021bi colaborarea \u00eentre roluri \u0219i departamente. Acest lucru se realizeaz\u0103 \u00een primul r\u00e2nd nu printr-un software sofisticat, ci prin comunicare practic\u0103. DevOps este despre cultur\u0103, practic\u0103, metodologie \u0219i procese. Nu exist\u0103 o specialitate ingineresc\u0103 care s\u0103 r\u0103spund\u0103 la aceste \u00eentreb\u0103ri.<\/p>\n

<\/p>\n

Cercul vicios<\/h2>\n

<\/p>\n

De unde provine disciplina \u201einginerie DevOps\u201d? Avem o teorie! Ideile DevOps s-au dovedit a fi at\u00e2t de bune, \u00eenc\u00e2t au devenit victime ale succesului lor. \u00cen jurul acestui subiect au \u00eenceput s\u0103-\u0219i fac\u0103 apari\u021bia recru\u021bi dubio\u0219i \u0219i comercian\u021bi de oameni, cu o atmosfer\u0103 proprie.<\/p>\n

<\/p>\n

Imagina\u021bi-v\u0103: ieri a\u021bi v\u00e2ndut shaorma \u00een HImki, iar ast\u0103zi sunte\u021bi un om mare, senior recruiter. Aici existe un \u00eentreg proces de c\u0103utare \u0219i selec\u021bie a candida\u021bilor, lucrurile nu sunt simple, trebuie s\u0103 \u00een\u021belege\u021bi. S\u0103 presupunem c\u0103 \u0219eful departamentului spune: g\u0103se\u0219te un specialist \u00een X. Ad\u0103ug\u0103m cuv\u00e2ntul \u201einginer\u201d la X \u0219i problema este rezolvat\u0103. Ave\u021bi nevoie de Linux? Atunci cu siguran\u021b\u0103 este un inginer Linux, dac\u0103 dori\u021bi DevOps \u2014 inginer DevOps. Ofertele de munc\u0103 nu constau doar \u00een titlu, ci trebuie inclus un text. Cel mai simplu este s\u0103 ad\u0103ug\u0103m un set de cuvinte cheie din Google, c\u00e2t poate fiecare s\u0103-\u0219i foloseasc\u0103 imagina\u021bia. DevOps consta \u00een dou\u0103 cuvinte \u2014 \u201eDev\u201d \u0219i \u201eOps\u201d, deci trebuie s\u0103 lipim cuvinte cheie legate de dezvoltatori \u0219i administratori, toate \u00eempreun\u0103. A\u0219a apar anun\u021buri de munc\u0103 pentru st\u0103p\u00e2nirea a 42 de limbaje de programare \u0219i 20 de ani de utilizare simultan\u0103 a Kubernetes \u0219i Swarm. O schem\u0103 de lucru.<\/p>\n

<\/p>\n

Astfel, \u00een mintea oamenilor s-a \u00eentip\u0103rit o imagine lipsit\u0103 de sens \u0219i nemiloas\u0103 a unui supererou \u201eDevOps\u201d, care va configura depozitele pentru toat\u0103 lumea pe Jenkins, iar fericirea va veni. Ah, dac\u0103 totul ar fi at\u00e2t de simplu. \u201e\u0218i mai po\u021bi s\u0103-i atragi pe administratorii de sistem\u201d, g\u00e2nde\u0219te HR-ul, \u201eeste un cuv\u00e2nt la mod\u0103, acelea\u0219i cuvinte cheie, ar trebui s\u0103 mu\u0219te.\u201d<\/p>\n

<\/p>\n

Cererea genereaz\u0103 ofert\u0103, iar pentru toate aceste anun\u021buri de munc\u0103 ciudate a venit o mul\u021bime de administratori de sistem care au \u00eenghi\u021bit ideea: pot face exact acela\u0219i lucru ca \u00eenainte, dar pot c\u00e2\u0219tiga de c\u00e2teva ori mai mult, numindu-se \u201eDevOps\u201d. A\u0219a cum configurai serverele prin SSH manual, unul c\u00e2te unul, tot a\u0219a vei continua s\u0103 le configurezi, dar acum aceasta este, se pare, o practic\u0103 DevOps. Este un fenomen complicat, par\u021bial legat de subestimarea administratorilor tradi\u021bionali \u0219i de hype-ul din jurul DevOps, dar \u00een general \u2014 ce a ie\u0219it, a ie\u0219it.<\/p>\n

<\/p>\n

A\u0219adar, avem cerere \u0219i ofert\u0103. Un ciclu \u00eenchis care se hr\u0103ne\u0219te singur. Iat\u0103 cu ce ne confrunt\u0103m (inclusiv prin crearea conferin\u021bei DevOops).<\/p>\n

<\/p>\n

Desigur, pe l\u00e2ng\u0103 administratorii de sistem care s-au redenumit \u201eDevOps\u201d, exist\u0103 \u0219i al\u021bi participan\u021bi \u2014 de exemplu, SRE profesioni\u0219ti sau dezvoltatori de Infrastructure-as-Code.<\/p>\n

<\/p>\n

Ce fac oamenii \u00een DevOps (de fapt)<\/h2>\n

<\/p>\n

Deci, vrei s\u0103 avansezi \u00een \u00eenv\u0103\u021barea \u0219i aplicarea practicilor DevOps. Dar cum s\u0103 faci asta, \u00een ce direc\u021bie s\u0103 te \u00eendrep\u021bi? Este evident c\u0103 nu ar trebui s\u0103 te ghidezi orbeste dup\u0103 cuvinte cheie populare.<\/p>\n

<\/p>\n

Dac\u0103 exist\u0103 munc\u0103, cineva trebuie s\u0103 o fac\u0103. Am stabilit deja c\u0103 nu sunt \u201einginerii DevOps\u201d, atunci cine? Se pare c\u0103 ar fi mai corect s\u0103 formul\u0103m acest lucru nu \u00een termeni de posturi, ci \u00een termeni de direc\u021bii de lucru concrete.<\/p>\n

<\/p>\n

\u00cen primul r\u00e2nd, po\u021bi s\u0103 te ocupi de inima DevOps \u2014 procesele \u0219i cultura. Cultura este un lucru care nu se dezvolt\u0103 rapid \u0219i este dificil, \u0219i de\u0219i acesta este, \u00een mod tradi\u021bional, domeniul de responsabilitate al conduc\u0103torilor, to\u021bi, de la programatori la administratori, particip\u0103 la aceast\u0103 activitate. Cu c\u00e2teva luni \u00een urm\u0103, Tim Lister a spus \u00eentr-un interviu<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u201eCultura este definit\u0103 de valorile fundamentale ale organiza\u021biei. De obicei, oamenii nu observ\u0103 asta, dar noi, lucr\u00e2nd \u00een consultan\u021b\u0103 de-a lungul anilor, ne-am obi\u0219nuit s\u0103 observ\u0103m. Intri \u00eentr-o companie \u0219i, literalmente, \u00een c\u00e2teva minute \u00eencepi s\u0103 sim\u021bi ce se \u00eent\u00e2mpl\u0103. Noi numim asta \u201emirosul\u201d. Uneori, acest miros este \u00eentr-adev\u0103r pl\u0103cut. Alteori, provoac\u0103 grea\u021b\u0103. (\u2026) Nu po\u021bi schimba cultura p\u00e2n\u0103 c\u00e2nd nu au fost \u00een\u021belese valorile \u0219i credin\u021bele care stau la baza ac\u021biunilor concrete. Comportamentul este u\u0219or de observat, iar g\u0103sirea credin\u021belor este greu. DevOps este un exemplu excelent de cum devine totul mai complicat.\u201d<\/p><\/blockquote>\n

Exist\u0103, desigur, \u0219i partea tehnic\u0103 a \u00eentreb\u0103rii. Dac\u0103 ai un cod nou pentru testare care ajunge dup\u0103 o lun\u0103, iar \u00een versiunea final\u0103 apare abia dup\u0103 un an, \u0219i nu este fizic posibil s\u0103 accelerezi tot acest proces - este greu de ajuns la bunele practici. Bunele practici sunt sus\u021binute de instrumente de calitate. De exemplu, av\u00e2nd \u00een minte ideea de Infrastructure-as-Code, po\u021bi folosi orice, de la AWS CloudFormation \u0219i Terraform p\u00e2n\u0103 la Chef-Ansible-Puppet. Toate acestea trebuie s\u0103 fie cunoscute \u0219i st\u0103p\u00e2nite, iar aceasta este deja o disciplin\u0103 ingineresc\u0103. Este important s\u0103 nu confunzi cauzele cu efectele: la \u00eenceput lucrezi pe principiile SRE \u0219i abia apoi concretizezi aceste principii sub form\u0103 de solu\u021bii tehnice specifice. SRE este o metodologie foarte complex\u0103, care nu se refer\u0103 la cum s\u0103 configurezi Jenkins, ci la cele cinci principii de baz\u0103:<\/p>\n

<\/p>\n