Recent, astfel de reclame au inundat internetul. În ciuda salariului plăcut, nu se poate să nu fie jenat că înăuntru este scrisă erezie sălbatică. La început se presupune că „DevOps” și „inginer” pot fi cumva lipite într-un singur cuvânt, iar apoi există o listă aleatorie de cerințe, dintre care unele sunt copiate clar din postul vacant de administrator de sistem.
În această postare aș vrea să vorbesc puțin despre cum am ajuns în acest punct al vieții, ce este DevOps cu adevărat și ce să facem cu el acum.
Asemenea posturi vacante pot fi condamnate în orice mod posibil, dar adevărul rămâne: sunt multe și așa funcționează piața în acest moment. Am ținut o conferință devops și am declarat deschis: „ - nu pentru inginerii DevOps." Acest lucru va părea ciudat și sălbatic pentru mulți: de ce oamenii care fac un eveniment complet comercial merg împotriva pieței. Acum vom explica totul.
Despre cultură și procese
Să începem cu faptul că DevOps nu este o disciplină de inginerie. Totul a început cu faptul că împărțirea rolurilor stabilită istoric nu funcționează pentru calitatea produselor. Când programatorii doar programează, dar nu vor să audă nimic despre testare, software-ul este plin de erori. Când administratorilor nu le pasă cum sau de ce este scris software-ul, asistența se transformă într-un iad.
De exemplu, descriind diferența dintre un administrator de sistem și o abordare SRE a gestionării serviciilor . Au fost efectuate studii interesante în cadrul — este clar că cei mai buni dezvoltatori reușesc cumva să implementeze noi modificări în producție mai repede decât o dată pe oră. Ei testează cu mâinile lor nu mai mult de 10% (acest lucru poate fi văzut din ). Cum fac ei asta? „Excel sau die”, spune unul dintre titlurile raportului. Pentru o discuție detaliată a acestor statistici în contextul testării, puteți consulta nota principală a lui Baruch Sadogursky la cealaltă conferință a noastră, Heisenbug.
„Când nu există un acord între tovarăși,
Afacerile lor nu vor merge bine,
Și nu va ieși nimic din el, doar făină.
A fost odată o lebădă, un rac și o știucă...”
Ce parte a programatorilor web credeți că înțelege cu adevărat condițiile în care aplicațiile lor sunt utilizate în producție? Câți dintre ei vor merge la administratori și vor încerca să-și dea seama ce se va întâmpla dacă baza de date se blochează? Și care dintre ei va merge la testeri și le va cere să-i învețe cum să scrie corect testele? Și există și agenți de securitate, manageri de produs și o grămadă de alți oameni.
Ideea generală a DevOps este de a crea o colaborare între roluri și departamente. În primul rând, acest lucru se realizează nu printr-un software configurat inteligent, ci prin practica comunicării. DevOps este despre cultură, practici, metodologie și procese. Nu există nicio specialitate de inginerie care să poată răspunde la aceste întrebări.
Cercul vicios
De unde a venit atunci disciplina „devops engineering”? Avem o versiune! Ideile DevOps erau bune – atât de bune încât au devenit victime ale propriului succes. Unii recrutori dubioși și traficanți de persoane, care au propria lor atmosferă, au început să se învârte în jurul acestui subiect.
Imaginează-ți: ieri făceai shawarma în Khimki, iar astăzi ești un mare jucător, un recrutor senior. Există un întreg proces de căutare și selecție a candidaților, totul este complicat, trebuie să-l înțelegi. Să presupunem că șeful unui departament spune: găsește un specialist în X. Adaugă cuvântul „inginer” la X și gata. Trebuie... LinuxEi bine, asta e sigur. LinuxDacă ești inginer și vrei DevOps, ești inginer DevOps. Un anunț de angajare nu este doar un titlu; trebuie să incluzi text în interior. Cea mai ușoară modalitate este să introduci o serie de cuvinte cheie Google, cât mai creativ posibil. DevOps este format din două cuvinte - „Dev” și „Ops”, ceea ce înseamnă că trebuie să combini cuvinte cheie legate de dezvoltatori și administratori, toate într-un singur loc. Așa apar anunțurile de angajare, având în vedere competența în 42 de limbaje de programare și 20 de ani de utilizare simultană a Kubernetes și Swarm. Iată un exemplu funcțional.
Așa a prins rădăcini în mintea oamenilor imaginea lipsită de sens și fără milă a unui anumit super-erou „devops”, care îi va configura pe toți să se desfășoare la Jenkins, iar fericirea va veni. Oh, dacă totul ar fi atât de simplu. „Și așa poți urmări administratorii de sistem”, crede HR, „este un cuvânt la modă, cuvintele cheie sunt aceleași, ar trebui să ia momeala.”
Cererea creează ofertă și toate aceste locuri de gunoi libere au fost umplute cu un număr nebun de administratori de sistem care și-au dat seama: puteți face totul la fel ca înainte, dar obțineți de mai multe ori mai mult numindu-vă „devops”. Așa cum ați configurat manual serverele prin SSH pe rând, veți continua să le configurați, dar acum se presupune că aceasta este o practică devops. Acesta este un fel de fenomen complex, parțial legat de subestimarea administratorilor clasici și de hype-ul în jurul DevOps, dar, în general, ceea ce s-a întâmplat s-a întâmplat.
Deci avem cerere și ofertă. Un cerc vicios care se hrănește singur. Pentru aceasta luptăm (inclusiv prin crearea conferinței DevOops).
Desigur, în afară de administratorii de sistem care s-au redenumit „devops”, există și alți participanți - de exemplu, SRE profesioniști sau dezvoltatori Infrastructure-as-Code.
Ce fac oamenii în DevOps (de fapt)
Așa că doriți să mergeți înainte în învățarea și aplicarea practicilor DevOps. Dar cum să faci asta, în ce direcție să privești? Evident, nu ar trebui să vă bazați orbește pe cuvinte cheie populare.
Dacă există o slujbă, cineva ar trebui să o facă. Am aflat deja că aceștia nu sunt „ingineri devops”, atunci cine sunt? Pare mai corect să formulăm acest lucru nu în termeni de posturi, ci în termeni de domenii specifice de activitate.
În primul rând, puteți aborda inima DevOps - procese și cultură. Cultura este o afacere lentă și dificilă și, deși este în mod tradițional responsabilitatea managerilor, toată lumea este implicată într-un fel sau altul, de la programatori la administratori. Acum câteva luni, Tim Lister :
„Cultura este determinată de valorile de bază ale organizației. De obicei oamenii nu observă acest lucru, dar lucrând în consultanță de mulți ani, suntem obișnuiți să observăm acest lucru. Intri într-o companie și literalmente în câteva minute începi să simți ce se întâmplă. Numim aceasta „aromă”. Uneori, acest parfum este foarte bun. Uneori provoacă greață. (...) Nu poți schimba o cultură până când nu se înțeleg valorile și convingerile din spatele unor acțiuni specifice. Comportamentul este ușor de observat, dar căutarea credințelor este dificilă. DevOps este doar un exemplu minunat al modului în care lucrurile devin din ce în ce mai complexe.”
Există, desigur, și o parte tehnică a problemei. Dacă noul tău cod este testat într-o lună, dar este lansat doar un an mai târziu și este imposibil din punct de vedere fizic să accelerezi totul, este posibil să nu fii la înălțimea bunelor practici. Bunele practici sunt susținute de instrumente bune. De exemplu, având în vedere ideea de Infrastructure-as-Code, puteți utiliza orice, de la AWS CloudFormation și Terraform până la Chef-Ansible-Puppet. Trebuie să știi și să poți face toate acestea, iar aceasta este deja o disciplină de inginerie. Este important să nu confundați cauza cu efectul: mai întâi lucrați după principiile SRE și abia apoi implementați aceste principii sub forma unor soluții tehnice specifice. În același timp, SRE este o metodologie foarte cuprinzătoare care nu vă spune cum să configurați Jenkins, ci despre cinci principii de bază:
- Comunicare îmbunătățită între roluri și departamente
- Acceptarea greșelilor ca parte integrantă a jobului
- Făcând schimbări treptat
- Utilizarea sculelor și a altor automatizări
- Măsurând tot ceea ce poate fi măsurat
Acesta nu este doar un set de afirmații, ci un specific . De exemplu, pe calea acceptării erorilor, va trebui să înțelegeți riscurile, să măsurați disponibilitatea și indisponibilitatea serviciilor folosind ceva de genul SLI () și SLO (), învață să scrii autopsie și fă ca scrierea lor să nu fie înfricoșătoare.
În disciplina SRE, utilizarea instrumentelor este doar o parte a succesului, deși una importantă. Trebuie să ne dezvoltăm constant din punct de vedere tehnic, să privim ce se întâmplă în lume și cum poate fi aplicat în munca noastră.
La rândul lor, soluțiile Cloud Native au devenit acum foarte populare. După cum sunt definite astăzi de Cloud Native Computing Foundation, tehnologiile Cloud Native permit organizațiilor să dezvolte și să ruleze aplicații scalabile în mediile dinamice actuale, cum ar fi norii publici, privat și hibrid. Exemplele includ containere, rețele de servicii, microservicii, infrastructură imuabilă și API-uri declarative. Toate aceste tehnici permit sistemelor slab cuplate să rămână elastice, gestionabile și foarte observabile. O bună automatizare permite inginerilor să facă schimbări mari în mod frecvent și cu rezultate previzibile, fără a face din asta o corvoadă. Toate acestea sunt susținute de un teanc de instrumente binecunoscute, cum ar fi Docker și Kubernetes.
Această definiție destul de complicată și largă se datorează faptului că zona este, de asemenea, destul de complexă. Pe de o parte, se susține că noi modificări la acest sistem ar trebui adăugate destul de simplu. Pe de altă parte, să vă dați seama cum să creați un fel de mediu containerizat în care serviciile slab cuplate să trăiască pe o infrastructură definită de software și să fie livrate acolo folosind CI/CD continuu și să construiți practici DevOps în jurul tuturor acestor lucruri - toate acestea necesită mai mult decât unul mănâncă câinele.
Ce să faci cu toate astea
Fiecare rezolvă aceste probleme în felul său: de exemplu, puteți publica posturi normale vacante pentru a rupe cercul vicios. Vă puteți da seama ce înseamnă cuvinte precum DevOps și Cloud Native și să le folosiți corect și la obiect. Vă puteți dezvolta în DevOps și puteți demonstra abordările potrivite prin exemplul dvs.
Facem o conferință , care oferă o oportunitate de a aprofunda lucrurile despre care tocmai am vorbit. Există mai multe grupuri de rapoarte pentru aceasta:
- Procese și cultură;
- Ingineria fiabilității site-ului;
- Cloud Native;
Cum să alegi unde să mergi? Există un punct subtil aici. Pe de o parte, DevOps este despre interacțiune și ne dorim foarte mult să participați la prezentări din diferite blocuri. Pe de altă parte, dacă ești un manager de dezvoltare care a venit la conferință pentru a se concentra pe o anumită sarcină, atunci nimeni nu te limitează - evident, acesta va fi un blocaj despre procese și cultură. Nu uitați că veți avea înregistrări după conferință (după completarea formularului de feedback), astfel încât să puteți urmări oricând prezentări mai puțin importante mai târziu.
Evident, la conferința în sine nu poți merge pe trei piste deodată, așa că organizăm programul în așa fel încât fiecare interval orar să aibă subiecte pentru toate gusturile.
Tot ce rămâne este să înțelegi ce să faci dacă ești inginer DevOps! În primul rând, încercați să determinați ce faceți de fapt. De obicei, le place să numească acest cuvânt:
- Dezvoltatori care lucrează la infrastructură. Grupurile de rapoarte despre SRE și Cloud Native sunt cele mai potrivite pentru tine.
- Administratorii de sistem. Aici e mai complicat. DevOops nu este despre administrarea sistemului. Din fericire, există o mulțime de conferințe excelente, cărți, articole, videoclipuri pe Internet, etc. pe tema administrării sistemului. Pe de altă parte, dacă ești interesat să te dezvolți în ceea ce privește înțelegerea culturii și proceselor, a învăța despre tehnologiile cloud și detaliile vieții cu Cloud Native, atunci ne-ar plăcea să te vedem! Gândește-te la asta: faci administrație și apoi ce vei face? Pentru a evita să te găsești brusc într-o situație neplăcută, ar trebui să înveți acum.
Există o altă opțiune: persisti și continui să susții că ești în special un inginer DevOps și nimic altceva, orice înseamnă asta. Atunci trebuie să vă dezamăgim, DevOops nu este o conferință pentru inginerii DevOps!
Glisați din la Munchen
DevOops 2020 Moscova va avea loc în perioada 29-30 aprilie la Moscova, biletele sunt deja disponibile .
Alternativ, puteți până pe 8 februarie. Vă rugăm să rețineți că atunci când completați formularul, trebuie să selectați publicul țintă care va beneficia cel mai mult de pe urma raportului dvs. (e o surpriză îngropată în listă).
Sursa: www.habr.com
