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

\u00cen prezent, aceasta este aproape cea mai costisitoare pozi\u021bie de pe pia\u021b\u0103. V\u00e2lva din jurul inginerilor \u201eDevOps\u201d dep\u0103\u0219e\u0219te toate limitele imaginabile, iar situa\u021bia este \u0219i mai grav\u0103 \u00een cazul inginerilor Senior DevOps.
\nLucrez ca \u0219ef al departamentului de integrare \u0219i automatizare, ghici\u021bi traducerea \u00een englez\u0103 \u2014 DevOps Manager. Reflect\u0103 oare exact traducerea \u00een englez\u0103 activit\u0103\u021bile noastre zilnice \u2014 \u00een niciun caz, \u00eens\u0103 varianta \u00een rus\u0103 este \u00een acest caz mai exact\u0103. Din natura activit\u0103\u021bii mele, este evident c\u0103 trebuie s\u0103 intervievez viitorii membri ai echipei mele \u0219i, \u00een ultimul an, aproximativ 50 de persoane au trecut prin fa\u021ba mea, iar \u00eenc\u0103 at\u00e2t de multe au fost eliminate \u00een pre-scriere cu colaboratorii mei.<\/p>\n

<\/p>\n

\u00cenc\u0103 suntem \u00een c\u0103utarea de colegi, deoarece sub eticheta DevOps se ascunde un strat foarte mare de diferite tipuri de ingineri.<\/a><\/noindex><\/p>\n

<\/p>\n

Tot ceea ce este scris mai jos este doar opinia mea personal\u0103, nu sunte\u021bi obliga\u021bi s\u0103 fi\u021bi de acord cu ea, totu\u0219i admit c\u0103 ar putea ad\u0103uga o nuan\u021b\u0103 \u00een percep\u021bia dumneavoastr\u0103 asupra subiectului. \u00cen ciuda riscului de a c\u0103dea \u00een dizgra\u021bie, public opinia mea, deoarece consider c\u0103 are un loc de a fi.<\/p>\n

<\/p>\n

Companiile \u00een\u021beleg diferit cine sunt inginerii DevOps \u0219i, pentru a angaja rapid resurse, lipe\u0219te aceast\u0103 etichet\u0103 tuturor. Situa\u021bia este destul de ciudat\u0103, deoarece companiile sunt dispuse s\u0103 pl\u0103teasc\u0103 recompense nerealiste acestor persoane, ob\u021bin\u00e2nd pentru ele, \u00een cele mai multe cazuri, un administrator-toolist.<\/p>\n

<\/p>\n

Atunci, cine sunt inginerii DevOps?<\/h2>\n

<\/p>\n

S\u0103 \u00eencepem cu istoria apari\u021biei \u2014 Development Operations a ap\u0103rut ca un pas suplimentar \u00een optimizarea interac\u021biunii \u00een echipe mici pentru a spori viteza de produc\u021bie a produselor, ca o consecin\u021b\u0103 a\u0219teptat\u0103. Ideea era de a \u00eent\u0103ri echipa de dezvoltare cu cuno\u0219tin\u021be despre procedurile \u0219i abord\u0103rile din managementul mediului de produs. Cu alte cuvinte, un dezvoltator trebuie s\u0103 \u00een\u021beleag\u0103 \u0219i s\u0103 \u0219tie cum func\u021bioneaz\u0103 produsul s\u0103u \u00een diferite condi\u021bii, trebuie s\u0103 \u00een\u021beleag\u0103 cum s\u0103 \u00eel desf\u0103\u0219oare, ce caracteristici ale mediului s\u0103 ajusteze pentru a \u00eembun\u0103t\u0103\u021bi performan\u021ba. Astfel, \u00een decursul timpului, au ap\u0103rut dezvoltatori cu o abordare DevOps. Dezvoltatorii DevOps scriau scripturi de construire \u0219i ambalare pentru a-\u0219i simplifica activitatea \u0219i operarea mediului de produc\u021bie. Totu\u0219i, complexitatea arhitecturii solu\u021biilor \u0219i interac\u021biunea reciproc\u0103 a componentelor infrastructurii au \u00eenceput s\u0103 afecteze performan\u021bele mediilor; cu fiecare itera\u021bie, erau necesare \u00een\u021belegeri tot mai profunde ale diferitelor componente, reduc\u00e2nd productivitatea dezvoltatorului din cauza costurilor suplimentare pentru \u00een\u021belegerea componentelor \u0219i tuning-ul sistemelor pentru sarcini specifice. Costul propriu-zis al dezvoltatorului a crescut, costul produsului odat\u0103 cu el, cererea pentru noi dezvoltatori din echip\u0103 a crescut drastic, av\u00e2nd \u00een vedere c\u0103 ace\u0219tia trebuiau s\u0103 \u00eendeplineasc\u0103 \u0219i responsabilit\u0103\u021bile \u201estarului\u201d dezvolt\u0103rii, iar, bine\u00een\u021beles, \u201estarurile\u201d deveneau din ce \u00een ce mai pu\u021bin accesibile. De asemenea, din experien\u021ba mea, pu\u021bini dezvoltatori sunt interesa\u021bi de specificul proces\u0103rii pachetelor de c\u0103tre nucleul sistemului de operare, regulile de rutare a pachetelor, aspectele de securitate ale gazdelor. O m\u0103sur\u0103 logic\u0103 a fost s\u0103 angajeze un administrator care s\u0103 fie familiarizat cu acest lucru \u0219i s\u0103 \u00eencredin\u021beze acest tip de responsabilit\u0103\u021bi, ceea ce, datorit\u0103 experien\u021bei sale, a permis atingerea unor indicatori similari la un cost mai mic \u00een compara\u021bie cu costul \u201estarului\u201d dezvolt\u0103rii. Ace\u0219tia erau integra\u021bi \u00een echip\u0103, iar principalul s\u0103u obiectiv era gestionarea mediilor de testare \u0219i de produc\u021bie, conform regulilor echipei respective, cu resursele alocate specific acestei echipe. Astfel, au ap\u0103rut DevOps \u00een viziunea majorit\u0103\u021bii.<\/p>\n

<\/p>\n

Par\u021bial sau complet, \u00een timp, ace\u0219ti administratori de sistem au \u00eenceput s\u0103 \u00een\u021beleag\u0103 nevoile acestei echipe specifice \u00een dezvoltare, cum s\u0103 le simplifice via\u021ba dezvoltatorilor \u0219i testerilor, cum s\u0103 gestioneze actualiz\u0103rile \u0219i s\u0103 nu r\u0103m\u00e2n\u0103 s\u0103 \u00eendrepte gre\u0219elile de implementare vineri noapte la birou. Timpul a trecut, iar administratorii de sistem au devenit \u201estaruri\u201d, \u00een\u021beleg\u00e2nd ceea ce \u00ee\u0219i doresc dezvoltatorii. Cu scopul de a minimiza impactul, au \u00eenceput s\u0103 apar\u0103 utilit\u0103\u021bile de gestionare, iar to\u021bi \u0219i-au amintit metodele vechi \u0219i de \u00eencredere de izolare la nivel de sistem de operare, care permiteau minimizarea cerin\u021belor de securitate, gestionarea re\u021belei \u0219i chiar a configura\u021biei gazdelor \u00een ansamblu, \u0219i, prin urmare, reducerea cerin\u021belor pentru noile \u201estaruri\u201d. <\/p>\n

<\/p>\n

A ap\u0103rut un lucru \u201eminunat\u201d \u2014 docker. De ce minunat? Doar pentru c\u0103 crearea izola\u021biei \u00een chroot sau jail, la fel ca OpenVZ, necesita cuno\u0219tin\u021be considerabile despre sistemele de operare, \u00een timp ce utilitatea care permite s\u0103 creezi u\u0219or un mediu izolat de aplica\u021bie pe o gazd\u0103 cu tot ce este necesar \u00een interior \u0219i s\u0103 predai din nou conducerea dezvolt\u0103rii, \u00een timp ce administratorul de sistem se ocup\u0103 doar de o singur\u0103 gazd\u0103, asigur\u00e2ndu-i securitatea \u0219i disponibilitatea \u2014 o simplificare logic\u0103. Dar progresul nu st\u0103 pe loc \u0219i sistemele devin din ce \u00een ce mai complexe, cu din ce \u00een ce mai multe componente; o singur\u0103 gazd\u0103 nu mai satisface nevoile sistemului \u0219i este necesar s\u0103 construie\u0219ti clustere. Ne \u00eentoarcem din nou la administratorii de sistem care pot construi aceste sisteme.<\/p>\n

<\/p>\n

Cicluri dup\u0103 cicluri, apar diverse sisteme care simplific\u0103 dezvoltarea \u0219i\/sau administrarea, apar sisteme de orchestrare care, p\u00e2n\u0103 \u00een momentul \u00een care nu este necesar s\u0103 te abate\u021bi de la procesul standard, sunt u\u0219or de utilizat. Arhitectura microserviciilor a ap\u0103rut de asemenea cu scopul de a simplifica tot ce este descris mai sus \u2014 mai pu\u021bine interconexiuni, mai u\u0219or de gestionat. Din experien\u021ba mea, nu am \u00eent\u00e2lnit o arhitectur\u0103 microserviciu complet\u0103; a\u0219 spune c\u0103 este un 50% \u2014 50%: 50% microservicii, cutii negre, intr\u0103 ce a fost procesat, ie\u0219it, iar celelalte 50% \u2014 un monolit distras, servicii incapabile s\u0103 func\u021bioneze separat de celelalte componente. Toate acestea au impus din nou restric\u021bii asupra nivelului de cuno\u0219tin\u021be at\u00e2t pentru dezvoltatori, c\u00e2t \u0219i pentru administratori.<\/p>\n

<\/p>\n

Aceste \u201ebalansoare\u201d de nivel expert al unei resurse sau altuia continu\u0103 \u0219i ast\u0103zi. Dar ne-am ab\u0103tut pu\u021bin, sunt multe puncte care merit\u0103 discutate.<\/p>\n

<\/p>\n

Inginer de construc\u021bie \/ Inginer de lansare<\/h2>\n

<\/p>\n

Inginerii foarte specializa\u021bi, ap\u0103ruti ca un mijloc de standardizare a proceselor de construire a software-ului \u0219i a lans\u0103rilor acestuia. Odat\u0103 cu introducerea pe scar\u0103 larg\u0103 a Agile, p\u0103rea c\u0103 nu mai sunt solicita\u021bi, totu\u0219i acest lucru nu este deloc adev\u0103rat. Aceast\u0103 specializare a ap\u0103rut ca un mijloc de standardizare a construirii \u0219i livr\u0103rii software-ului la scar\u0103 industrial\u0103, adic\u0103 utiliz\u00e2nd tehnici standard pentru toate produsele companiei. Odat\u0103 cu apari\u021bia DevOps, dezvoltatorii au pierdut par\u021bial func\u021bii, deoarece ace\u0219tia au \u00eenceput s\u0103 preg\u0103teasc\u0103 produsul pentru livrare, iar av\u00e2nd \u00een vedere infrastructura \u00een continu\u0103 schimbare \u0219i abordarea \u00een livrarea c\u00e2t mai rapid\u0103 f\u0103r\u0103 a lua \u00een considerare calitatea, cu timpul au devenit un blocaj \u00een procesele de schimbare, deoarece respectarea standardelor de calitate \u00eencetine\u0219te inevitabil livr\u0103rile. Astfel, treptat, o parte din func\u021bionalitatea inginerilor de Build\/Release a fost transferat\u0103 pe umerii administratorilor de sistem.<\/p>\n

<\/p>\n

Ops-urile sunt at\u00e2t de diferite<\/h2>\n

<\/p>\n

Continu\u0103m mai departe \u0219i din nou, existen\u021ba unui num\u0103r mare de responsabilit\u0103\u021bi \u0219i lipsa personalului calificat ne \u00eempinge c\u0103tre o specializare riguroas\u0103, cum ar fi ciupercile dup\u0103 ploaie, apar diferite Operations:<\/p>\n

<\/p>\n