DevOps-onderhoud antipatrone

Groete aan julle almal, my liewe lesers!

Vandag wil ek my gedagtes oor 'n jarelange onderwerp deel, en dit dalk in die kommentaar bespreek.
Ek kom gereeld op artikels af oor slegte onderhoudspraktyke vir die pos van 'n programmeerder, wat na my mening redelik relevant is en, ek hoop, deur die MH-afdelings van groot en nie so groot maatskappye gelees word nie.

In ons area, sover ek kan sê, is daar 'n aanvraag vir sulke interessante entiteite soos DevOps-ingenieurs. Ek is een van daardie mense wat nie regtig hierdie frase verstaan ​​nie (ja, DevOps-metodologie, ens.), so ek sien 'n paar verskille in die ontwikkelingspaaie van hierdie groep spesialiste.
Eerstens glo ek vas dat elke persoon sy eie reeks belangstellings het, selfs in die werkarea, dit wil sê, sommige hou van die wolk, sommige hou daarvan om diep in toepassingsbedieners te delf, diep Java op te stel, en sommige skryf kode in Python of God verbied yaml-kode. Dit wil sê, die sogenaamde Infrastruktuur-ingenieur, Bou-ingenieur, Senior Yaml-ontwikkelaar verskyn hier :)
Dit alles laat aan die een kant toe om 'n persoon te vind wat die beste by jou poel take pas, en aan die ander kant skep dit misverstande tydens onderhoude
Op grond van persoonlike ervaring het ek tientalle onderhoude gevoer, en ook as verweerder aan verskeie deelgeneem, wil ek my siening deel van alles wat gebeur.

Die eerste en waarskynlik my gunsteling anti-patroon is die begeerte dat iemand alles moet doen, of dit is nie duidelik wie nodig is nie, ons sal na 'n klomp kandidate kyk en ons sal verstaan. Dit geld waarskynlik enige gebied, maar dit het sy eie kenmerke.
Soos ek opgemerk het, is mense meer lus vir poste met die woorde DevOps as Stelseladministrateur, alhoewel myns insiens, op Senior vlak, die omvang van take soveel as moontlik verskil in hierdie twee areas.
Enige werkgewer wat werklik 'n stelseladministrateur benodig, skryf devops in die titel van die vakature, en lys absoluut alles in die liggaam van die versoek, K8S/Java/gradle/oracleDB, ens. op die lys, alhoewel die persoon van binne sal moet handel oor die ondersteuning van die K8S-groepering en die ondersteuning van die OracleDB-stapel in isolasie van die span.
Wel, dit wil sê, watter soort interaksie is daar tussen die ontwikkelaars / bedrywighede-formaat?
Verder blyk dit dat daar nie so 'n proses van interaksie met die span is nie en in die algemeen is daar geen bedrywighede as 'n departement nie en jy moet die ontwikkelaars se rekenaars opstel.
Hierdie opsie pas eintlik by sommige aansoekers, maar kom ons wees eerlik, dit is 'n Senior Stelseladministrateur, so hoekom wil hulle nie so skryf nie en wat is so skandelik daaraan? Verskille in salaris tussen verskillende postitels? Maar die maatskappy het een begroting, en maak nie saak wat jy die skip noem nie, dit sal op sy eie begroting vaar.
Wel, ek het selfs hiervan gehoor, nou sal die kandidaat vinnig alles outomatiseer en deelneem aan die ontwikkeling van 'n produk in Python, wat is die verskil, Python is oral dieselfde. Verskille in wêreldbeskouing en benaderings word nie in ag geneem nie.

Vervolgens onderskei ek gewoonlik die vlak van spesialiste wat hul probleme afsonderlik vir elkeen kom sien
Junior - vir my persoonlik is Junior DevOps 'n persoon wat stelseladministrasie / -ontwikkeling op 'n gemiddelde vlak bemeester het. Hier is dit lekker om te onderskei tussen sterk Linux-gebruikers wat in 'n nuwe area wil groei, of ontwikkelaars wat 'n begeerte het om goed te doen vir ander ontwikkelaars. Sterk, met 'n paar vaardighede in ontfouting, soek na logboeke, of met 'n voorraad gekodeerde projekte.
Ek het beide stelseladministrateurs ontmoet wat iets probeer het en aan die wolke wil raak, en diegene wat voor en agter probeer het en om een ​​of ander rede het 'n belangstelling in DevOps-prosesse gevind.
Op hierdie vlak verwar dit my altyd as hulle begin om 'n groot stapel tegnologieë, Puppet, Ansible rond te gooi - hoekom het ek nie alles probeer nie? K8S, K3S - wat is die verskil? Hoeveel tipes databasisse ken jy? hoekom so min? Hoe werk enkripsie in Java? Veral diegene wat uit ontwikkeling gekom het, hoewel dit baie nuttige personeel is, is daar altyd werk vir hulle op hierdie gebied.
Ek is altyd in 'n stupor as dit gebeur, die eerste ding wat ek wil vra is hoekom??? die tweede ding wat by my opkom is - is die onderhoudvoerder self gereed om vrae oor so 'n diverse stapel te beantwoord? Wil hulle regtig vir June vat en alles op hom vaspen?
Dikwels gebeur dit in allerhande liggaamswinkels, wanneer jy 'n persoon moet verkoop vir een of ander projek en jy benodig meer cool woorde vir jou CV, of die maatskappy wil niemand aanstel nie, maar kyk net na watter soort juniors daar is.

Middelvlak
daar is verskeie uiterstes hier, myns insiens, eerstens is dit seker moeilik om duidelik te bepaal presies wat 'n persoon getrek word om 'n middel te wees, hulle probeer hom óf verkwis tot Junie, óf hulle begin hom ry soos 'n senior, probeer gryp 'n senior teen die prys van 'n middel (ja, die mark besluit dit, niks persoonlik nie)
Die wonderlikste ding wat ek gesien het, is om diep in kodering te gaan, met Python rond te mors, die Java GC te torring, dit wil sê met meer dieper spesifieke onderwerpe, of omgekeerd, om gapings in kennis te openbaar wat vir 'n lang tyd nie gebruik is nie. , ry deur netwerke, tipes OS-bestuurders, grinnik en verheug, Hoe kan 'n persoon dit vergeet? En hier gebeur die interessantste ding!
Teen die middelvlak ontwikkel 'n spesialis na my mening 'n belangstellingskring en 'n persoonlike siening van waarmee hy wil werk - om op die nuutste stapel te hype, 'n truuk in 'n kubus te druk, of om te swaai vir 'n verskriklike onderneming, gaan diep in kodeprestasie.
Na my mening is dit die moeite werd om hier te vra oor die prosesse waaraan die persoon gewerk het, te vra wat die interessantste was en wat nie, en op grond van hierdie kennis 'n groep vrae te bou, gewoonlik om vrae by jou stapel te voeg. Andersins, na 'n fassinerende gesprek vir 'n uur of twee oor die opstel van 'n OpenShift-kluster, huur 'n persoon en gee hom toe om monitering te bou. Waarskynlik sal albei kante daarvan hou.

Senior vlak
Ag my gunsteling vlak.
Hier is 'n sterk spesialis wat homself op verskeie soorte projekte grootgemaak het, 'n persoon wat reeds weet wat hy wil hê en waarvan hy nie so baie hou nie.
En so begin die vertoning:
- diep vrae oor stelseladministrasie (sien die eerste antipatroon)
- diep vrae oor Linux in die algemeen uit die veld van teorie, ver van praktiese kennis (OSI vlakke top vraag)
— akademiese vrae oor kodering (omdat die onderhoudvoerder self nie regtig die veld ken nie, is hy bloot gevra om 'n onderhoud met 'n vreemde devops-ou te voer)
Ek sal hier 'n klein opmerking maak. Op 'n dag, tydens 'n onderhoud, is ek gevra om 'n stukkie kode te skryf. Op 'n stuk papier. Wel, soos almal lief is, skryf hulle elke dag, die pamflet is ons alles.
Nadat die taak voltooi is, nadat ek my stuk papier en die oplossing bekyk het, is die uitspraak bereik dat die algoritme suboptimaal sou wees. Ek het voorgestel dat die onderhoudvoerder sy eie algoritme skryf, waarop ek die antwoord ontvang het: "Dit is nie binne die omvang van die onderhoud nie." Ek het vir 'n minuut gevra, die kode 'n bietjie verander en dit gewys en gevra, sal dit vinniger of stadiger wees? Waarop ek 'n antwoord gekry het, kom ons gaan aan na die volgende vraag. Die verskil was in hoe die kode in 'n lus en sonder 'n lus gewerk het, en ek het 'n voorbereide antwoord gehad waarom dit beter is om dit so te doen en nie so nie. Wel, daarna wou ek nie meer vrae beantwoord en saam met hierdie persoon werk nie.
Ons moet in ag neem dat ons almal verskillend is en 'n kandidaat kan afgeskrik word deur enige ding wat nie vir jou belangrik is nie.
— gewoonlik het senior-vlak spesialiste 'n duidelike beskrywing van die werkstapel, maar nee, jy moet iets na aan jou begin gebruik, byvoorbeeld, jy het Ansible geskryf, wonderlik, maar ons het Puppet, ons het jou sopas gebel, so vertel ons oor Puppet. Perfek! Het jy al met OpenShift gewerk? Ons het K8's, ons ken nie die verskille nie, maar jou ervaring is irrelevant. Wonderlik!

Daar is ook so 'n subklas - ek neem persoonlik leerlinge aan om tot juniors te groei.
Ek wil graag hê dat almal moet verstaan ​​dat 'n intern 'n entiteit is wat nog glad nie gevorm is nie. Dit maak my vreeslik bang as hulle leerlinge na die sterk Junior-vlak begin stoot en dan met 'n tevrede kyk vir hulle 'n internskap aanbied (soms onbetaald, 'n nagmerrie!)
Moenie dit op hierdie manier doen nie.
'n Intern, na my mening, is óf 'n senior student, óf iemand wat regtig wil "in IT gaan."
Met studente is alles eenvoudig - dit is wonderlik om uit te vind wat hy by die universiteit doen, wat hy self gedoen het, te sien op watter vrae sy oë lig - as hulle oplig, vra hoekom in devops en wat algemeen daaroor bekend is. Voel aan die persoon en verstaan ​​of dit aangenaam sal wees om verder saam met hom te werk, of jy hierdie spesifieke persoon iets wil leer.
Met diegene wat in IT wil gaan, is alles 'n bietjie strenger - kyk hoeveel 'n persoon homself bestudeer, wat hy gedoen het voordat hy by jou onderhoud uitgekom het, hier is 'n goeie opsie om na Github te kyk, as daar natuurlik, die digtheid van commits en watter oefeninge gedoen is. Vra ook hoekom dit devops is, want dit is meer pret en ingewikkelder in die frontend?

En laastens wil ek weereens raad gee: besluit wie jy regtig nodig het en jy sal dadelik die regte persoon kry. Identifiseer die behoeftes, kyk na die spesialis as 'n spesialis, vind sy sterk punte en gebruik dit suksesvol in jou werk. Wees oplettend vir die onderhoudvoerder, hy het na jou toe gekom vir 'n gesprek, en nie vir 'n kompetisie om te sien wie vir wie sal druip of nie.

Bron: will.com

Voeg 'n opmerking