Recentemente, astfel de anunțuri au inundat internetul. În ciuda unui salariu atractiv, este imposibil să nu te deranjeze faptul că în interior este scrisă o prostie grozavă. La început, se presupune că "DevOps" și "inginer" pot fi somehow lipite într-un singur cuvânt, iar apoi urmează o listă aleatorie de cerințe, parte dintre ele fiind evident copiate dintr-o ofertă de muncă pentru sistem administrator.
În această postare, vrem să discutăm puțin despre cum am ajuns aici, ce este, de fapt, DevOps și ce ar trebui să facem cu aceasta acum.
Astfel de oferte de muncă pot fi criticate în multe feluri, dar faptul rămâne: sunt multe și așa arată piața în acest moment. Am organizat o conferință de DevOps și declarăm deschis: " — nu pentru inginerii DevOps". Aici mulți vor considera ciudat și absurd: de ce oamenii care organizează 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ă inginerescă. Totul a început din cauza faptului că diviziunea istorică pe roluri nu funcționează pentru calitatea produselor. Când programatorii doar programează, dar nu vor să audă nimic despre testare, software-ul este umplut cu bug-uri. Când administratorii nu le pasă cum și de ce este scris software-ul, suportul se transformă într-un coșmar.
De exemplu, descrierea diferenței dintre abordarea de sistem administrator și cea SRE în managementul serviciilor . S-au realizat studii interesante în cadrul — se observă că cei mai buni dezvoltatori reușesc somehow să implementeze noi modificări în producție mai repede decât o dată la oră. Ei testează manual nu mai mult de 10% (asta se vede după ). Cum reușesc să facă acest lucru? "Excel sau nu" – spune unul dintre titlurile raportului. Pentru o discuție detaliată despre această statistică în contextul testării, puteți să consultați keynote-ul lui Baruch Sadogursky la o altă conferință a noastră, Heisenbug.
"Când nu există acord între camarazi,
Lucrul lor nu va merge,
Și nu va ieși nimic din el, decât suferință.
Cândva, Lebăda, Raca și Țarca..."
Ce părere aveți, câți web-developeri înțeleg cu adevărat în ce condiții funcționează aplicațiile lor în producție? Câți dintre ei se vor duce la administratori pentru a încerca să înțeleagă ce se întâmplă în cazul unei căderi a bazei de date? Și câți dintre ei se vor duce la testerii și vor cere să învețe cum să scrie corespunzător teste? Iar acolo mai sunt și specialiști în securitate, manageri de produs și o grămadă de alți oameni.
Ideea generală a DevOps este de a îmbunătăți colaborarea între roluri și departamente. Acest lucru se realizează în primul rând nu printr-un software sofisticat, ci prin comunicare practică. DevOps este despre cultură, practică, metodologie și procese. Nu există o specialitate inginerescă care să răspundă la aceste întrebări.
Cercul vicios
De unde provine disciplina „inginerie DevOps”? Avem o teorie! Ideile DevOps s-au dovedit a fi atât de bune, încât au devenit victime ale succesului lor. În jurul acestui subiect au început să-și facă apariția recruți dubioși și comercianți de oameni, cu o atmosferă proprie.
Imaginați-vă: ieri ați vândut shaorma în HImki, iar astăzi sunteți un om mare, senior recruiter. Aici existe un întreg proces de căutare și selecție a candidaților, lucrurile nu sunt simple, trebuie să înțelegeți. Să presupunem că șeful departamentului spune: găsește un specialist în X. Adăugăm cuvântul „inginer” la X și problema este rezolvată. Aveți nevoie de Linux? Atunci cu siguranță este un inginer Linux, dacă doriți DevOps — inginer DevOps. Ofertele de muncă nu constau doar în titlu, ci trebuie inclus un text. Cel mai simplu este să adăugăm un set de cuvinte cheie din Google, cât poate fiecare să-și folosească imaginația. DevOps consta în două cuvinte — „Dev” și „Ops”, deci trebuie să lipim cuvinte cheie legate de dezvoltatori și administratori, toate împreună. Așa apar anunțuri de muncă pentru stăpânirea a 42 de limbaje de programare și 20 de ani de utilizare simultană a Kubernetes și Swarm. O schemă de lucru.
Astfel, în mintea oamenilor s-a întipărit o imagine lipsită de sens și nemiloasă a unui supererou „DevOps”, care va configura depozitele pentru toată lumea pe Jenkins, iar fericirea va veni. Ah, dacă totul ar fi atât de simplu. „Și mai poți să-i atragi pe administratorii de sistem”, gândește HR-ul, „este un cuvânt la modă, aceleași cuvinte cheie, ar trebui să muște.”
Cererea generează ofertă, iar pentru toate aceste anunțuri de muncă ciudate a venit o mulțime de administratori de sistem care au înghițit ideea: pot face exact același lucru ca înainte, dar pot câștiga de câteva ori mai mult, numindu-se „DevOps”. Așa cum configurai serverele prin SSH manual, unul câte unul, tot așa vei continua să le configurezi, dar acum aceasta este, se pare, o practică DevOps. Este un fenomen complicat, parțial legat de subestimarea administratorilor tradiționali și de hype-ul din jurul DevOps, dar în general — ce a ieșit, a ieșit.
Așadar, avem cerere și ofertă. Un ciclu închis care se hrănește singur. Iată cu ce ne confruntăm (inclusiv prin crearea conferinței DevOops).
Desigur, pe lângă administratorii de sistem care s-au redenumit „DevOps”, există și alți participanți — de exemplu, SRE profesioniști sau dezvoltatori de Infrastructure-as-Code.
Ce fac oamenii în DevOps (de fapt)
Deci, vrei să avansezi în învățarea și aplicarea practicilor DevOps. Dar cum să faci asta, în ce direcție să te îndrepți? Este evident că nu ar trebui să te ghidezi orbeste după cuvinte cheie populare.
Dacă există muncă, cineva trebuie să o facă. Am stabilit deja că nu sunt „inginerii DevOps”, atunci cine? Se pare că ar fi mai corect să formulăm acest lucru nu în termeni de posturi, ci în termeni de direcții de lucru concrete.
În primul rând, poți să te ocupi de inima DevOps — procesele și cultura. Cultura este un lucru care nu se dezvoltă rapid și este dificil, și deși acesta este, în mod tradițional, domeniul de responsabilitate al conducătorilor, toți, de la programatori la administratori, participă la această activitate. Cu câteva luni în urmă, Tim Lister :
„Cultura este definită de valorile fundamentale ale organizației. De obicei, oamenii nu observă asta, dar noi, lucrând în consultanță de-a lungul anilor, ne-am obișnuit să observăm. Intri într-o companie și, literalmente, în câteva minute începi să simți ce se întâmplă. Noi numim asta „mirosul”. Uneori, acest miros este într-adevăr plăcut. Alteori, provoacă greață. (…) Nu poți schimba cultura până când nu au fost înțelese valorile și credințele care stau la baza acțiunilor concrete. Comportamentul este ușor de observat, iar găsirea credințelor este greu. DevOps este un exemplu excelent de cum devine totul mai complicat.”
Există, desigur, și partea tehnică a întrebării. Dacă ai un cod nou pentru testare care ajunge după o lună, iar în versiunea finală apare abia după un an, și nu este fizic posibil să accelerezi tot acest proces - este greu de ajuns la bunele practici. Bunele practici sunt susținute de instrumente de calitate. De exemplu, având în minte ideea de Infrastructure-as-Code, poți folosi orice, de la AWS CloudFormation și Terraform până la Chef-Ansible-Puppet. Toate acestea trebuie să fie cunoscute și stăpânite, iar aceasta este deja o disciplină inginerescă. Este important să nu confunzi cauzele cu efectele: la început lucrezi pe principiile SRE și abia apoi concretizezi aceste principii sub formă de soluții tehnice specifice. SRE este o metodologie foarte complexă, care nu se referă la cum să configurezi Jenkins, ci la cele cinci principii de bază:
- Îmbunătățirea interacțiunii dintre roluri și departamente
- Acceptarea greșelilor ca parte integrantă a muncii
- Implementarea treptată a schimbărilor
- Utilizarea instrumentelor și automatizării
- Măsurarea tot ce poate fi măsurat
Acesta nu este doar un set de afirmații, ci un ghid concret . De exemplu, pe calea acceptării greșelilor, va trebui să te ocupi de riscuri, să măsori disponibilitatea și indisponibilitatea serviciilor cu ajutorul unor indicatori precum SLI () și SLO (), să înveți să scrii post-mortem-uri și să faci în așa fel încât să nu fie înfricoșător să le scrii.
În disciplina SRE, utilizarea instrumentelor este doar una dintre părțile succesului, deși nu lipsită de importanță. Trebuie să ne dezvoltăm constant din punct de vedere tehnic, să observăm ce se întâmplă în lume și cum putem aplica acest lucru în munca noastră.
În prezent, soluțiile Cloud Native au devenit foarte populare. Conform înțelegerii moderne a Cloud Native Computing Foundation, tehnologiile Cloud Native permit organizațiilor să dezvolte și să desfășoare aplicații scalabile în medii dinamice moderne, cum ar fi cloud-uri publice, private și hibride. Exemple includ containere, servicii mesh, microservicii, infrastructură imutabilă și API-uri declarative. Toate aceste tehnici permit sistemelor slab legate să rămână elastice, gestionabile și bine observabile. O bună automatizare le permite inginerilor să facă modificări mari frecvent și cu rezultate previzibile, fără a transforma acest lucru într-o muncă infernală. Toate acestea sunt susținute de un stack de instrumente bine cunoscute, precum Docker și Kubernetes.
Această definiție este destul de complexă și vastă, deoarece domeniul este destul de complicat. Pe de o parte, se afirmă că noile modificări în acest sistem ar trebui să fie adăugate destul de ușor. Pe de altă parte, pentru a înțelege cum să creezi un mediu containerizat în care serviciile slab legate funcționează pe o infrastructură definită prin software și sunt livrate acolo printr-un CI/CD continuu, și să construiești practici DevOps în jurul acestui lucru – trebuie să ai o experiență semnificativă.
Ce să facem cu toate acestea
Fiecare își rezolvă aceste probleme în modul său: de exemplu, se pot publica anunțuri de angajare adecvate pentru a sparge cercul vicios. Se poate înțelege ce înseamnă termenii precum DevOps și Cloud Native și să îi folosească corect și în mod relevant. Se poate avansa în DevOps și să demonstreze prin exemplul propriu abordările corecte.
Noi organizăm o conferință , care oferă ocazia de a explora mai în profunzime subiectele despre care am discutat. Pentru asta, există mai multe grupuri de prezentări:
- Procese și cultură;
- Site Reliability Engineering;
- Cloud Native;
Cum să alegi pe unde să mergi? Aici există un aspect delicat. Pe de o parte, DevOps înseamnă colaborare și ne dorim foarte mult să participi la prezentări din diverse blocuri. Pe de altă parte, dacă ești un manager de dezvoltare venit la conferință pentru a te concentra pe o sarcină specifică, nimeni nu te limitează — evident, acesta va fi blocul referitor la procese și cultură. Nu uita că după conferință vor rămâne înregistrări (după completarea formularului de feedback), așa că vei putea viziona prezentările mai puțin importante mai târziu.
Este evident că la conferință nu poți participa în același timp la trei track-uri, de aceea programul este structurat astfel încât fiecare slot de timp să ofere subiecte pe gustul tuturor.
Rămâne doar să înțelegi ce să faci dacă ești inginer DevOps! În primul rând, încearcă să definești ce faci cu adevărat. De obicei, acest termen este folosit pentru a descrie:
- Dezvoltatori care se ocupă de infrastructură. Pentru tine, cele mai potrivite vor fi grupurile de prezentări despre SRE și Cloud Native.
- Administratori de sistem. Aici este mai complicat. DevOops nu este despre administrarea sistemelor. Din fericire, există o mulțime de conferințe, cărți, articole și videoclipuri excelente pe tema administrării sistemelor. Pe de altă parte, dacă ești interesat să te dezvolți în ceea ce privește înțelegerea culturii și proceselor, să înveți despre tehnologiile cloud și detaliile vieții cu Cloud Native, te vom primi cu bucurie! Gândește-te la asta: te ocupi de administrare, iar mai departe ce vei face? Ca să nu te trezești într-o situație neplăcută, ar fi bine să începi să înveți deja acum.
Există încă o variantă: insiști și continui să susții că ești exact inginer DevOps și nicidecum altceva, indiferent ce ar însemna. Atunci trebuie să te dezamăgesc, DevOops este o conferință care nu este pentru inginerii DevOps!
Slide din la München
DevOops 2020 Moscova va avea loc pe 29-30 aprilie la Moscova, biletele sunt deja disponibile .
În plus, poți până pe 8 februarie. Te rugăm să reții că atunci când completezi formularul trebuie să alegi publicul țintă căruia prezentarea ta îi va aduce cel mai mare beneficiu (în lista aceasta se ascunde o surpriză).
Sursa: habr.com
