Dmitry Olefirenko lucrează ca Techlead DevOps la Provectus. În acest interviu, el a împărtășit parcursul său profesional și a vorbit în detaliu despre cine sunt DevOps-erii și de ce abilități are nevoie un astfel de specialist.

Puțină istorie

Mișcarea DevOps a luat naștere în 2007-2008, când comunitățile de operațiuni IT și de dezvoltare de software și-au exprimat îngrijorarea cu privire la ceea ce considerau a fi un nivel fatal de disfuncționalitate în industrie.

Aceștia au argumentat împotriva modelului tradițional de software development, conform căruia cei care scriu codul ar trebui să fie separați din punct de vedere organizațional și funcțional de cei care îl implementează și îl întrețin.

Developerii și departamentele IT aveau obiective separate (și adesea concurente), conducere separată a departamentelor, KPI-uri separate în raport cu care erau măsurați și adesea lucrau la etaje diferite sau chiar în clădiri diferite.

Rezultatul a fost echipe izolate, ore lungi de lucru, lansări eșuate și clienți nemulțumiți. Desigur, lucrurile s-au schimbat puțin în 16 ani, iar echipa de development apreciază contribuția echipei DevOps.

În calitate de product manager, înțeleg DevOps doar în sens general. Așa că a fost foarte interesant pentru mine să discut despre acest subiect cu fostul meu coleg, Dmitry Olefirenko, un specialist de nivel înalt.

DESPRE APARIȚIA PROFESIEI DE DEVOPS

Dmitry, spune-mi te rog cum ți-ai început drumul către profesia DevOps?

În primul rând, voi începe cu locul de unde a apărut această profesie. Dezvoltarea profesiilor în domeniul IT se aseamănă foarte mult cu dezvoltarea medicinei. Când medicina a început să se dezvolte și să acumuleze cunoștințe, a devenit clar că o persoană care poate face totul. Este nevoie de prea multă experiență practică. 

Iar medicina a început să fie împărțită în specializări limitate. Același lucru s-a întâmplat și în IT. Existau tehnicieni care puteau configura 1C și Windows și, în același timp, puteau spune unui contabil de ce nu poate face ceva în Excel.

Cum s-a ajuns la această divizare? Prin ce?

Profesia DevOps este una dintre cele mai recente. Pe scurt, poate fi numită interacțiunea dintre echipa de dezvoltare și operațiuni. De exemplu, echipa de development a scris un produs, dar există 100500 de întrebări deschise:

• Ce să fac în continuare cu acest produs?
• Cum se lansează acest produs în producție?
• Cum să păstrezi toate aspectele de securitate la locul lor, astfel încât să nu existe erori, astfel încât parolele să nu fie sparte, astfel încât parolele să nu fie divulgate
• Ceea ce urmează este o listă uriașă de probleme de observabilitate.

În unele companii, de exemplu Google, acest lucru este inclus chiar într-o poziție separată numită Site Reliability Engineering (SRE). Aceștia sunt oameni care se ocupă în mod special de observabilitatea produsului: monitorizare, logare, alertă, căi de alertă, ce se întâmplă dacă o alertă cade și așa mai departe.

Scrierea propriilor instrumente pentru monitorizare, pentru alertă sau cercetarea și implementarea celor existente. Aici, în ceea ce mă privește, vă pot recomanda să vă uitați la produsele de la Grafana.

Cum ai ajuns în această profesie? 

Am ajuns în această profesie într-un mod destul de interesant. Aceasta este o profesie care vine mai ales din partea administratorilor de sistem. Se presupune că cei de la DevOps trebuie să aibă o bună cunoaștere a sistemelor de operare, în special a diferitelor Linux-uri. Pentru că, în cea mai mare parte, toate produsele rulează pe aceste sisteme de operare. Dar eu am abordat problema puțin diferit. Am fost mai întâi programator PhP, făcând web development. Apoi am ajuns să lucrez într-o profesie apropiată de DevOps, numită Build Release Engineer. Și apoi am trecut fără probleme la DevOps.

Ce ai făcut când ai fost în rolul de Build Release Engineer?

Obișnuiam să organizez construcții. Când trebuia lansată o nouă versiune a unui produs, mă asiguram că totul se desfășoară conform procesului. Asta fac parțial și acum.

Poți detalia care sunt responsabilitățile tale acum?

DevOps are un volum imens de muncă într-o companie mare. Programarea nu a dispărut, ea este încă prezentă. Scriu destul de multe mici meșteșuguri, așa cum le numesc eu, care rulează, de exemplu, în interiorul clusterului Kubernetes: unele instrumente auxiliare, raportare și așa mai departe.

Ce limbaj folosești?

Chiar dacă este la modă să folosești GoLang pentru acest lucru, eu, ca majoritatea celor de la DevOps, prefer Python. Este excelent pentru tot felul de developments mici.

CE FEL DE COMPANII AU NEVOIE DE DEVOPS

Pentru ce tipuri de produse e nevoie de DevOPS? De exemplu, vreau să fac un mic produs pentru a vinde bilete. Trebuie să implic DevOPS sau nu?

Depinde de calificările celor care vor implementa și vor susține acest produs. Putem lua un cloud public dacă este un produs simplu. De exemplu, Amazon. Putem lua un AWS Elastic Beanstalk foarte ușor de utilizat și un developer experimentat, familiarizat cu Amazon, îl va implementa acolo perfect. Și atunci pot exista sau nu întrebări. De exemplu, ce fel de RTO sau RPO ne dorim?¹ Vom avea recuperare în caz de dezastru?²Câte ore suntem dispuși să așteptăm, dacă acest produs eșuează? În cât timp suntem dispuși să pierdem date? Și cât de ușor sau cât de dificil este să ne monitorizăm produsul? 

Se pare că, pentru produsele mici, acest rol este de obicei îndeplinit de developerii înșiși?

Aici trebuie să te uiți la ce înseamnă un produs mic. Și depinde de produsul în sine. Cu ce servicii ar trebui să interacționeze, ce fel de RTO și RPO are acest produs? De exemplu, dacă avem un magazin online - ar fi groaznic dacă, să zicem, ar sta timp de 2 ore? Probabil că nu. Dacă oamenii au intrat în acest magazin online, au făcut cumpărături, baza a dispărut, iar backup-ul a fost făcut acum 8 ore și am pierdut comenzi neprocesate timp de 8 ore. Este acest lucru critic pentru afacere? Pentru unii oameni da, pentru alții nu. Dar dacă este vorba, să zicem, de un sistem de check-in pentru o mare companie aeriană. Ce se întâmplă dacă acel sistem nu funcționează timp de o oră? Se prăbușește pe aeroporturile din întreaga lume unde operează compania respectivă.

În ce caz este necesar să se apeleze la DevOps? Depinde de numărul de servicii pe care le utilizează compania?

Depinde de numărul de servicii, de fiabilitatea lor, de pericolul pentru afacere.

• Ce se întâmplă dacă acest sistem nu mai funcționează?
• Ce se întâmplă dacă atacatorii intră în acel sistem și încep să încerce să-l spargă, să facă DDoS...³?

În unele cazuri, are sens ca o companie să aibă o echipă NOC.⁴Acesta este un sistem care va sta non-stop, va monitoriza, va supraveghea panourile, va înregistra incidentele și va trezi pe cineva noaptea dacă se întâmplă ceva. De aici și întrebarea pe care am menționat-o deja, care este observabilitatea - cât de mult ar trebui monitorizat acest sistem, înregistrat și așa mai departe. Adică, ce cerințe are afacerea?

Și, probabil, ultimul aspect este platforma pe care va fi rulat totul. Dacă este vorba de un cloud public, atunci există instrumente gata pregătite prin care un anumit serviciu poate fi lansat pur și simplu. Iar dacă o companie are mai multe produse, dacă sunt produse de microservicii, atunci, de exemplu, astăzi a devenit la modă să rulezi totul în Kubernetes. 

SERVICII

Ce este Kubernetes?

Kubernetes este o creație Google care are capacități extraordinare, dar are un prag de intrare foarte ridicat.

Care este motivul pentru care pragul de intrare este atât de ridicat?

Google nu a conceput acest sistem pentru a fi simplu. Google a proiectat acest sistem pentru a fi complex, dar cu un număr uriaș de caracteristici.

Deci, pentru a începe să o folosești, trebuie să ai deja un anumit nivel de cunoștințe?

Trebuie să ai un bagaj de cunoștințe despre cum să lucrezi cu acest orchestrator. Dar acesta oferă o cantitate extraordinară de capacități pentru a lansa servicii, pentru a restaura automat serviciile dacă ceva nu a mers bine și pentru a implementa produse foarte rapid în Kubernetes.

Dar, în același timp, Kubernetes este un sistem gol. Atunci când apar întrebările: cum vom implementa produse acolo, cum le vom monitoriza, cum vom colecta jurnale, cum vom păstra secrete? Se pare că Kubernetes are nevoie de aproximativ o duzină și jumătate de diagrame Helm diferite pentru ca acest cluster Kubernetes să fie gata să lucreze cu versiuni de producție. Apropo, acesta este subiectul raportului meu, pe care sunt gata să îl împărtășesc cu cei interesați.

Bun, ce alte servicii folosești în activitatea ta? 

În cea mai mare parte, folosesc Kubernetes și toate serviciile de monitorizare, de logare, de observabilitate, de gestionare adecvată a secretelor. De asemenea, o mulțime de alte produse care sunt bine cunoscute în lume, diverse Jenkins, GitHub și așa mai departe.

PROCESUL DE LUCRU

Cum arată ziua ta de lucru? 

Acum lucrez remote. Orele mele de lucru sunt neregulate. Este posibil să am unele sarcini urgente atunci când ceva nu merge bine. Sau dacă cineva are o problemă urgentă, iar în cea mai mare parte, acestea sunt sarcini arhitecturale care pot dura două sau trei săptămâni. Așadar, pot începe lucrul la ore diferite din zi, chiar și în funcție de perioada anului, când trebuie să îmi duc fiica la școală. Pot să încep să lucrez la ora 09:00 și să termin la ora 18:00. În unele zile mai târziu, în altele mai devreme.

Cum interacționezi cu echipa de producție? Care este locul tău în procesul de dezvoltare a produsului? 

Încercăm să îi sfătuim pe developeri cu privire la ceea ce trebuie să facă pentru ca, de exemplu, produsul lor să poată fi implementat corect, în siguranță și fără erori într-un cluster. Pentru că există o serie de anti-patternuri, care produse este bine să fie implementate în Kubernetes și care dintre ele este mai bine să nu ruleze deloc acolo. Dacă este vorba de un monolit, probabil că este mai bine să îl implementezi în Amazon folosind Ansible.

Cine stabilește sarcinile pentru tine? Cum interacționezi în cadrul echipei? 

Avem o echipă mică de DevOps. Eu sunt responsabil pentru problemele de automatizare, pentru implementarea platformei Kubernetes. Comunicarea are loc adesea direct cu clientul, cu arhitecții tehnici ai clientului. Adică, ei vor ceva, iar apoi poate exista un proces lung de negocieri cu privire la modul cel mai bun de a face acel lucru. Pentru că nu întotdeauna când clientul vrea ceva, are sens să îl implementezi în acel fel. În primul rând, face sens să convingi clientul că ar trebui aleasă o metodă diferită.

În ce limbă comunici de obicei cu clientul? 

În limba engleză. Bineînțeles, trebuie să o cunoaști la un nivel bun de conversație. Și, de asemenea, este de dorit să înțelegi oameni dintr-o gamă largă de țări.

Cât de des este necesar să lucrezi seara, în timpul nopții?

Încerc să dedic mult timp proiectării unei arhitecturi, astfel încât să nu fiu nevoit să lucrez noaptea, dacă este posibil.

CUM SĂ DEVII DEVOPS

Să zicem că mă interesează să învăț să devin un DevOps. Ce trebuie să fac pentru a reuși acest lucru? Care este setul minim de calificări pe care ar trebui să le am?

Cunoașterea sistemelor de operare Linux. Cunoștințe de bază despre produse precum Ansible. Ar fi bine să începi să înveți Docker, ceva Kubernetes. De asemenea, o înțelegere a modului în care funcționează unul dintre cei mai populari trei cloud-uri publice - AWS, Azure sau Google Cloud - ar fi suficientă pentru început.

Ce sfat ai pentru cei care aspiră să devină DevOps-eri sau pentru cei care vor să devină unul? 

Văd că platforma Kubernetes va fi foarte în vogă în următorii ani, deci trebuie învățată. Pentru cei care doresc să facă acest lucru, pot să vă sfătuiesc să luați certificarea Certified Kubernetes Administrator, așa cum am făcut și eu la vremea mea. M-a ajutat foarte mult. Cursuri bune de formare pot fi găsite, de exemplu, pe Udemy.

Link curs: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests

Din câte îmi amintesc, certificarea poate fi făcută în Chișinău?

Da, la Chișinău am susținut live certificarea Amazon, pentru că în Chișinău sunt două companii care sunt reprezentante Pearson VUE, iar acest lucru îți oferă posibilitatea de a susține aproape orice examen live. Pearson VUE este principalul intermediar pentru certificare, în special pentru Amazon.

Ce întrebări pun de obicei cei de la DevOps la un interviu de angajare?

De obicei, cele mai multe companii au întrebări pregătite în prealabil cu privire la setul pe care îl folosesc. Cel mai bine este să puneți întrebări situaționale. De exemplu: imaginați-vă că aveți un cluster Kubernetes și că un nod nu mai răspunde. Întrebați candidatul despre acțiunile sale. V-aș recomanda să aveți cel puțin o persoană care s-a lovit deja de multe hopuri.

Există teste de interviu pentru oamenii DevOps?

Da, există. Chiar nu-mi place să le fac. Ca să fiu sincer, aș fi refuzat să fiu intervievat dacă mi s-ar fi oferit un interviu test.

În ce constă de obicei?

Ca introvertit, mă pot pierde ușor la un test de task . Nu-mi plac astfel de sarcini, când mi se cere doar să mă uit pe ecran și să scriu ceva rapid. Da, mă pierd. Nu mă înțelege greșit, nu sunt un chirurg operator, nu trebuie să iau o decizie instantaneu. Dar chiar nu-mi place acest tip de sarcină. Sunt un mare fan al întrebărilor de interviu. De exemplu, avem asta și asta, cum ai implementa asta? Ce ai sugera?

DEVOPS-OM

Companiile, majoritatea de dimensiuni mici, doresc să economisească bani. Ce se întâmplă dacă iei un specialist junior?

Așa cum am mai spus, oamenii DevOps trebuie să se ocupe adesea de problemele legate de o defecțiune. Este puțin probabil ca un specialist junior să fie capabil să descopere cauzele problemelor și, în general, să configureze tot ce este necesar.

Are sens să apelezi la o firmă de consultanță DevOps într-un astfel de caz?

Dacă cineva are o experiență practică cu serviciile sau, dimpotrivă, o experiență negativă cu unele servicii, a petrecut deja multe luni aflând care dintre aceste servicii este bun și care nu este, atunci de ce nu ar trebui ca firma să cumpere această experiență?

Ce sfaturi ai pentru angajatori?

1.Este demn de remarcat faptul că, dacă DevOps tinde să lucreze peste program sau caută să facă ceva mai repede, s-ar putea să nu fie de cea mai bună calitate.

2. Dacă ați cerut DevOps să proiecteze o arhitectură care va determina supraviețuirea producției, nu-l grăbiți. Și nu-l puneți să proiecteze simultan ceva într-un sprint de două săptămâni, în timp ce în același timp face calificarea și răspunde la întrebările a cinci echipe despre motivul pentru care ceva nu funcționează pentru ei? Asta înseamnă că nu aveți suficienți oameni DevOps.

3. Investiți în dezvoltarea competențelor DevOps, motivați-i să ia certificări, plătiți-i pentru cursuri pe Udemy. De exemplu, compania pentru care lucrez îi motivează să ia certificări la Amazon, plătește pentru certificare și apoi plătește un mic bonus.

Cum îți dai seama că DevOps aduce valoare companiei?

Există o vorbă veche: "Dacă administratorul de sistem nu face nimic, este un administrator de sistem bun". Același lucru este valabil și pentru DevOps. De asemenea, în legătură cu povestea despre Henry Ford și modul său de a plăti lăcătușii. Când linia de asamblare a lui Henry Ford funcționa în camera lăcătușilor, un contor se învârtea cu salariile acestora. Când linia de asamblare se oprea, contorul se oprea. Salariile lăcătușilor depindeau de faptul dacă banda rulantă funcționa sau nu. Poate că a fost o fabulă, dar DevOps are o poveste similară. Procesele CI/CD bine organizate, un sistem de backup bine pus la punct, un sistem de monitorizare și de alertă bine pus la punct economisesc timp și bani pe termen lung pentru companie. 

SPECIALIST ÎN FERICIRE DEVOPS

Ce-ți place la profesia ta? De ce o faci?

Îmi place să dezvolt arhitectura, să proiectez ceva nou. Cel mai mult îmi place să obțin rezultate pozitive, să văd că ceea ce am proiectat funcționează și nu se prăbușește.

Adică, fericirea unui DevOps este .....

Fericirea unui DevOps este că poate dormi liniștit noaptea. Pentru că problema cu DevOps este că, dacă se întâmplă ceva în producție, este primul lucru care le vine în minte, pentru că de acolo începe totul.

Note de subsol:

1. RTO (Recovery Time Objective) sau RPO (Recovery Point Objective) sunt factori cheie în definirea scenariilor de backup și de recuperare în caz de dezastru pentru bazele de date. ↩︎
2. Recuperarea în caz de dezastru (DR) este capacitatea unei organizații de a restabili accesul și disponibilitatea infrastructurii IT după un dezastru, fie că este natural sau cauzat de o eroare umană. ↩︎
3. Un atac DDoS este o modalitate de a bloca funcționarea unui site web prin trimiterea unui număr mare de cereri care depășesc capacitatea de lățime de bandă a rețelei. ↩︎
4. Echipa NOC (Network Operating Centre) este echipa care are capacitatea de a seta alerte și de a monitoriza starea de sănătate a infrastructurii 24 de ore din 24, 7 zile din 7. ↩︎