DevOps is de ôfrûne jierren in heul populêr ûnderwerp wurden. In protte minsken dreame derfan om mei te dwaan, mar, lykas de praktyk docht bliken, faak allinich fanwegen it nivo fan salaris.
Guon minsken listje DevOps op har CV, hoewol se de essinsje fan 'e term net altyd witte of begripe. Guon minsken tinke dat jo nei it studearjen fan Ansible, GitLab, Jenkins, Terraform en sa (de list kin wurde fuortset neffens jo smaak), jo daliks in "devopsist" wurde. Dit is fansels net wier.
De ôfrûne jierren bin ik benammen belutsen west by de ymplemintaasje fan DevOps yn ferskate bedriuwen. Dêrfoar wurke hy mear as 20 jier yn funksjes fariearjend fan systeembehearder oant IT-direkteur. Op it stuit DevOps Lead Engineer by Playgendary.
Wa is DevOps
It idee om in artikel te skriuwen ûntstie nei in oare fraach: "wa is DevOps?" Der is noch gjin fêststelde term foar wat of wa't it is. Guon fan 'e antwurden binne al yn dizze . Earst sil ik de haadpunten derút markearje, en dan sil ik myn observaasjes en tinzen diele.
DevOps is gjin spesjalist dy't kin wurde ynhierd, gjin set nutsbedriuwen, en net in ôfdieling fan ûntwikkelders mei yngenieurs.
DevOps is in filosofy en metodyk.
Mei oare wurden, it is in set fan praktiken dy't ûntwikkelders helpt aktyf ynteraksje mei systeembehearders. Dat wol sizze om wurkprosessen yn elkoar te ferbinen en te yntegrearjen.
Mei de komst fan DevOps bleaunen de struktuer en rollen fan spesjalisten itselde (d'r binne ûntwikkelders, d'r binne yngenieurs), mar de regels fan ynteraksje binne feroare. De grinzen tusken ôfdielingen binne fervage.
De doelen fan DevOps kinne wurde beskreaun yn trije punten:
- De software moat regelmjittich bywurke wurde.
- Software moat fluch dien wurde.
- De software moat maklik en yn koarte tiid ynset wurde.
D'r is gjin inkeld ark foar DevOps. It konfigurearjen, leverjen en studearjen fan ferskate produkten betsjuttet net dat DevOps yn it bedriuw is ferskynd. D'r binne in protte ark en se wurde allegear brûkt yn ferskate stadia, mar tsjinje ien mienskiplik doel.
En dit is mar in diel fan 'e DevOps-ark
Ik haw minsken ynterviewd foar de posysje fan DevOps-yngenieur foar mear dan 2 jier no, en ik bin realisearre hoe wichtich it is om de essinsje fan 'e term dúdlik te begripen. Ik haw spesifike ûnderfiningen, observaasjes en gedachten sammele dy't ik diele wol.
Ut ynterviewûnderfining sjoch ik de folgjende ôfbylding: spesjalisten dy't DevOps beskôgje as in baantitel hawwe meast misferstannen mei kollega's.
Der wie in opfallend foarbyld. In jonge man kaam ta in ynterview mei in protte tûke wurden op syn cv. By syn lêste trije banen hie hy 5-6 moannen ûnderfining. Ik ferliet twa startups, om't se "net opstien." Mar oer it tredde bedriuw sei hy dat gjinien him dêr ferstiet: de ûntwikkelders skriuwe koade op Windows, en de direkteur twingt dizze koade om te "ferpakt" yn gewoane Docker en ynboud yn 'e CI / CD-pipeline. De man sei in protte negative dingen oer syn hjoeddeistige wurkplak en syn kollega's - ik woe gewoan antwurdzje: "Dat jo sille gjin oaljefant ferkeapje."
Doe stelde ik him in fraach dy't foar elke kandidaat heech op myn list stiet.
- Wat betsjuttet DevOps foar jo persoanlik?
- Yn it algemien of hoe begryp ik it?
Ik wie ynteressearre yn syn persoanlike miening. Hy wist de teory en de oarsprong fan de term, mar hy wie it der bot net mei iens. Hy leaude dat DevOps in baantitel wie. Dit is wêr't de woartel fan syn problemen leit. Lykas oare spesjalisten mei deselde miening.
Wurkjouwers, dy't in protte heard hawwe oer de "magy fan DevOps", wolle in persoan fine dy't sil komme en dizze "magy" meitsje. En oanfregers út 'e kategory "DevOps is in baan" begripe net dat se mei dizze oanpak net oan ferwachtingen kinne foldwaan. En yn 't algemien skreaunen se DevOps op har cv, om't it in trend is en se betelje in protte foar.
DevOps metodyk en filosofy
De metodyk kin teoretysk en praktysk wêze. Yn ús gefal is it de twadde. Lykas ik hjirboppe neamde, is DevOps in set fan praktiken en strategyen dy't brûkt wurde om oanjûne doelen te berikken. En yn elk gefal, ôfhinklik fan 'e saaklike prosessen fan it bedriuw, kin it signifikant ferskille. Wat it net better of slimmer makket.
De DevOps-metoade is allinich in middel om doelen te berikken.
No oer wat de DevOps-filosofy is. En dit is wierskynlik de dreechste fraach.
It is frij lestich om in koart en koart antwurd te formulearjen, om't it noch net formalisearre is. En om't oanhingers fan 'e DevOps-filosofy mear dwaande binne mei de praktyk, is d'r gewoan gjin tiid foar filosofearjen. Dit is lykwols in heul wichtich proses. Boppedat is it direkt relatearre oan yngenieursaktiviteiten. D'r is sels in spesjalisearre gebiet fan kennis - .
Der wie gjin sa'n fak op myn universiteit, ik moast alles sels studearje mei de materialen dy't ik yn 'e jierren '90 fine koe. It ûnderwerp is opsjoneel foar yngenieursûnderwiis, dus it gebrek oan formalisaasje fan it antwurd. Mar dy minsken dy't serieus ûnderdompele yn DevOps begjinne te fiele in bepaalde "geast" of "ûnbewuste wiidweidichheden" fan alle prosessen fan it bedriuw.
Mei myn eigen ûnderfining besocht ik guon fan 'e "postulaten" fan dizze filosofy te formalisearjen. It resultaat is it folgjende:
- DevOps is net wat ûnôfhinklik dat kin wurde skieden yn in apart gebiet fan kennis of aktiviteit.
- Alle meiwurkers fan it bedriuw moatte wurde liede troch de DevOps-metoade by it plannen fan har aktiviteiten.
- DevOps hat ynfloed op alle prosessen binnen in bedriuw.
- DevOps bestiet om tiidkosten te ferminderjen foar alle prosessen binnen in bedriuw om de ûntwikkeling fan har tsjinsten en maksimale klantkomfort te garandearjen.
- DevOps, yn moderne taal, is de proaktive posysje fan elke meiwurker fan it bedriuw, rjochte op it ferminderjen fan tiidkosten en it ferbetterjen fan de kwaliteit fan 'e IT-produkten om ús hinne.
Ik tink dat myn "postulaten" in apart ûnderwerp foar diskusje binne. Mar no is der wat om op te bouwen.
Wat DevOps docht
It kaaiwurd hjir is kommunikaasje. D'r binne in protte kommunikaasje, wêrfan de inisjatyfnimmer krekt deselde DevOps-yngenieur moat wêze. Wêrom is dat? Want dit is filosofy en metodyk, en pas dan engineering kennis.
Ik kin net mei 100% fertrouwen prate oer de Westerske arbeidsmerk. Mar ik wit nochal in soad oer de DevOps-merk yn Ruslân. Neist hûnderten ynterviews haw ik it ôfrûne jier en in heal meidien oan hûnderten technyske foarferkeapen foar de tsjinst "Ymplemintaasje fan DevOps" foar grutte Russyske bedriuwen en banken.
Yn Ruslân is DevOps noch in heul jong, mar al trending ûnderwerp. Foar safier't ik wit, wie allinich yn Moskou it tekoart oan sokke spesjalisten yn 2019 mear dan 1000 minsken. En it wurd Kubernetes foar wurkjouwers is hast as in reade lap foar in bolle. Oanhingers fan dit ark binne ree om it te brûken, sels as it net nedich en ekonomysk rendabel is. De wurkjouwer begrypt net altyd yn hokker gefallen wat mear passend is om te brûken, en mei in goede ynset kostet it ûnderhâlden fan in Kubernetes-kluster 2-3 kear mear as it ynsetten fan in applikaasje mei in konvinsjonele klusterskema. Brûk it wêr't jo it echt nedich hawwe.
It ymplementearjen fan DevOps is djoer yn termen fan jild. En it is allinich rjochtfeardige wêr't it ekonomyske foardielen op oare gebieten bringt, en net op himsels.
DevOps-yngenieurs binne yn feite pioniers - se binne dejingen dy't de earste moatte wêze om dizze metodyk yn it bedriuw te ymplementearjen en prosessen te bouwen. Om dit te slagjen, moat de spesjalist konstant ynteraksje mei meiwurkers en kollega's op alle nivo's. Lykas ik gewoanlik sis, moatte alle bedriuwsmeiwurkers belutsen wurde by it ymplemintaasjeproses fan DevOps: fan 'e skjinmakster oant de CEO. En dit is in betingst. As it meast junior lid fan it team net wit en begrypt wat DevOps is en wêrom bepaalde organisatoaryske aksjes wurde útfierd, dan sil suksesfolle ymplemintaasje net wurkje.
Ek moat in DevOps-yngenieur fan tiid ta tiid in bestjoerlike boarne brûke. Bygelyks om "omjouwingsferset" te oerwinnen - as it team net ree is om DevOps-ark en metodyk te akseptearjen.
De ûntwikkelder moat allinich koade en tests skriuwe. Om dit te dwaan hat hy gjin superkrêftige laptop nedich wêrop hy de heule projektynfrastruktuer sil ynsette en lokaal stypje. Bygelyks, in front-end-ûntwikkelder hâldt alle eleminten fan 'e applikaasje op syn laptop, ynklusyf de databank, S3-emulator (minio), ensfh. Dat is, hy besteget in protte tiid oan it ûnderhâlden fan dizze lokale ynfrastruktuer en wrakselet mei alle problemen fan sa'n oplossing. Yn stee fan in ûntwikkeljen koade foar de foarkant. Sokke minsken kinne tige resistint wêze foar elke feroaring.
Mar d'r binne teams dy't, krekt oarsom, bliid binne om nije ark en metoaden yn te fieren, en aktyf meidwaan oan dit proses. Hoewol sels yn dit gefal waard kommunikaasje tusken de DevOps-yngenieur en it team net annulearre.
As DevOps net nedich is
D'r binne situaasjes as DevOps net nedich is. Dit is in feit - it moat wurde begrepen en akseptearre.
Alderearst jildt dit foar alle bedriuwen (benammen lytse bedriuwen), as har winst net direkt ôfhinklik is fan 'e oanwêzigens of ôfwêzigens fan IT-produkten dy't ynformaasjetsjinsten oan kliïnten leverje. En hjir hawwe wy it net oer de webside fan it bedriuw, of it no in statyske "visitekaart" is as mei dynamyske nijsblokken, ensfh.
DevOps is ferplichte as de tefredenheid fan jo klant en syn winsk om wer nei jo werom te kommen, ôfhingje fan de beskikberens fan dizze ynformaasjetsjinsten foar ynteraksje mei de klant, har kwaliteit en doelen.
In opfallend foarbyld is ien bekende bank. It bedriuw hat gjin tradisjonele kliïntkantoaren, dokumintstream wurdt útfierd fia post of koeriers, en in protte meiwurkers wurkje fan hûs. It bedriuw is ophâlden gewoan in bank te wêzen en, nei myn miening, is feroare yn in IT-bedriuw mei ûntwikkele DevOps-technologyen.
In protte oare foarbylden en lêzingen binne te finen yn 'e opnames fan tematyske gearkomsten en konferinsjes. Ik besocht guon fan har persoanlik - dit is in heul nuttige ûnderfining foar dyjingen dy't yn dizze rjochting wolle ûntwikkelje. Hjir binne keppelings nei YouTube-kanalen mei goede lêzingen en materialen oer DevOps:
Sjoch no nei jo bedriuw en tink oer dit: hoefolle hinget jo bedriuw en har winsten ôf fan IT-produkten om klantinteraksje mooglik te meitsjen?
As jo bedriuw fisk ferkeapet yn in lytse winkel en it ienige IT-produkt is twa 1C: Enterprise-konfiguraasjes (Accounting en UNF), dan makket it amper sin om oer DevOps te praten.
As jo wurkje by in grutte hannels- en produksjebedriuw (jo produsearje bygelyks jachtgewearen), dan moatte jo der oer tinke. Jo kinne it inisjatyf nimme en de perspektiven foar ymplemintaasje fan DevOps oan jo behear oerbringe. No, en tagelyk liede dit proses. In proaktive posysje is ien fan 'e wichtige útgongspunten fan' e DevOps-filosofy.
De grutte en folume fan jierlikse finansjele omset is net it wichtichste kritearium om te bepalen oft jo bedriuw DevOps nedich is.
Litte wy ús in grutte yndustriële ûndernimming foarstelle dy't net direkt ynteraksje mei klanten. Bygelyks guon autofabrikanten en autofabrikanten. Ik bin der no net wis fan, mar út myn eardere ûnderfining waard in protte jierren alle klantinteraksje dien fia e-post en tillefoan.
Harren kliïnten binne in beheinde list fan auto dealers. En elk wurdt tawiisd in spesjalist fan de fabrikant. Alle ynterne dokumintstream komt fia SAP ERP. Ynterne meiwurkers binne yn essinsje kliïnten fan it ynformaasjesysteem. Mar dizze IS wurdt regele troch klassike middels foar it behearen fan klustersystemen. Wat de mooglikheid om DevOps-praktiken te brûken útslút.
Dêrfandinne de konklúzje: foar sokke bedriuwen is de ymplemintaasje fan DevOps net wat kritysk wichtich, as wy de doelen fan 'e metodyk weromhelje fan it begjin fan it artikel. Mar ik slút net út dat se hjoed wat DevOps-ark brûke.
Oan 'e oare kant binne d'r in protte lytse bedriuwen dy't software ûntwikkelje mei DevOps-metodology, filosofy, praktiken en ark. En se leauwe dat de kosten foar it ymplementearjen fan DevOps de kosten binne wêrtroch se effektyf kinne konkurrearje yn 'e softwaremerk. Foarbylden fan sokke bedriuwen binne te sjen .
It wichtichste kritearium om te begripen oft DevOps nedich is: hokker wearde jo IT-produkten hawwe foar it bedriuw en klanten.
As it haadprodukt fan it bedriuw dat winst genereart software is, hawwe jo DevOps nedich. En it is net sa wichtich as jo fertsjinje echte jild mei help fan oare produkten. Dit omfettet ek online winkels of mobile applikaasjes mei spultsjes.
Eltse games bestean tank oan finansiering: direkt of yndirekt fan de spilers. By Playgendary ûntwikkelje wy fergese mobile spultsjes mei mear as 200 minsken dy't direkt belutsen binne by har skepping. Hoe brûke wy DevOps?
Ja, krekt itselde as hjirboppe beskreaun. Ik kommunisearje konstant mei ûntwikkelders en testers, en fiere ynterne training foar meiwurkers oer DevOps-metodology en ark.
Wy brûke Jenkins no aktyf as in CI/CD-pipelines-ark foar it útfieren fan alle assemblagepipelines mei Unity en folgjende ynset nei de App Store en Play Market. Mear út 'e klassike toolkit:
- Asana - foar projektbehear. Yntegraasje mei Jenkins is konfigurearre.
- Google Meet - foar fideogearkomsten.
- Slack - foar kommunikaasje en ferskate warskôgings, ynklusyf notifikaasjes fan Jenkins.
- Atlassian Confluence - foar dokumintaasje en groepswurk.
Us direkte plannen omfetsje it yntrodusearjen fan statyske koade-analyze mei SonarQube en it útfieren fan automatisearre UI-testen mei Selenium yn it poadium fan trochgeande yntegraasje.
Yn stee fan in konklúzje
Ik soe graach einigje mei de folgjende gedachte: om in heech kwalifisearre DevOps-yngenieur te wurden, is it essensjeel om te learen hoe't jo live kommunisearje kinne mei minsken.
In DevOps-yngenieur is in teamspiler. En neat oars. It inisjatyf yn 'e kommunikaasje mei kollega's moat fan him komme, en net ûnder ynfloed fan guon omstannichheden. In DevOps-spesjalist moat de bêste oplossing foar it team sjen en foarstelle.
En ja, de ymplemintaasje fan elke oplossing sil in protte diskusje fereaskje, en oan 'e ein kin it hielendal feroarje. Untwikkelje selsstannich, útstellen en útfieren fan syn ideeën, sa'n persoan is fan tanimmende wearde sawol foar it team en foar de wurkjouwer. Wat, úteinlik, wurdt wjerspegele yn it bedrach fan syn moanlikse fergoeding of yn 'e foarm fan ekstra bonussen.
Boarne: www.habr.com