Wêr te gean mei dizze kennis, wat te dwaan yn it projekt en hoefolle te fertsjinjen, wat te sizzen en te freegjen by in ynterview - seit Alexander Titov, managing partner fan Express 42 en skriuwer .
Hallo! Hoewol de term DevOps bestiet sûnt 2009, is d'r noch gjin konsensus yn 'e Russyske mienskip. Jo hawwe wierskynlik opfallen dat guon DevOps beskôgje as in spesjaliteit, oaren beskôgje it in filosofy, en oaren beskôgje de term in set technologyen. Ik haw al in protte kearen optreden mei oer de ûntwikkeling fan dizze rjochting, dus ik sil net yn detail yn dit artikel gean. Lit my gewoan sizze dat wy by Express 42 it folgjende deryn opnimme:
DevOps is in spesifike metodyk, in kultuer fan it meitsjen fan in digitaal produkt, as alle spesjalisten yn it team dielnimme oan produksje.
Yn klassike bedriuwsûntwikkeling giet alles sequentieel: programmearring, testen en allinich operaasje, en de snelheid fan dit proses fan idee oant produksje is 3 moannen. Dit is in wrâldwide probleem foar digitale produkten, om't it ûnmooglik is om fluch feedback fan klanten te ûntfangen.
Yn DevOps binne ark en oanpak ûntworpen om te soargjen dat ûntwikkeling, testen en operaasjeprosessen tagelyk rinne.
Wat folget út dizze oanpak?
- Jo kinne gjin "yngenieur" hiere dy't sil komme en alle problemen mei produksje oplosse. It hiele team moat de technyk tapasse.
- DevOps is NET de folgjende foarm fan sysadmin om nei te upgrade. "DevOps-yngenieur" klinkt sawat itselde as "Agile ûntwikkelder."
- As in team Kubernetes, Ansible, Prometheus, Mesosphere en Docker brûkt, betsjut dit net dat DevOps-praktiken dêr binne ymplementearre.
It libben nei DevOps sil nea itselde wêze
De DevOps-oanpak is foarearst in oare manier fan tinken, in belibbing fan ûntwikkeling as gehiel en ien syn plak yn it proses. Wy hawwe ús online kursus ferdield yn 2 blokken:
1. Selsbeskikking
Earst ûndersykje wy yn detail de essinsje fan 'e DevOps-oanpak, en studinten ûntdekke nije rollen yn it team, sjoch hokker reagearret mear, en bepale foar harsels hokker rjochting te ûntwikkeljen.
2. Tools en praktiken
Studinten behearskje spesifike technologyen út it eachpunt fan 'e DevOps-metoade.
DevOps-ark kinne sawol brûkt wurde yn 'e DevOps-oanpak as yn klassike ûntwikkeling. It meast foar de hân lizzende foarbyld soe wêze it brûken fan it Ansible konfiguraasje behear ark. It is makke en betocht om de DevOps-praktyk "Ynfrastruktuer as koade" út te fieren, wat betsjut dat ferskate steaten fan it systeem wurde beskreaun, fan bestjoeringssysteemynstellingen oant applikaasjesoftware. De beskriuwing is ferdield yn lagen en lit jo in komplekse, konstant feroarjende konfiguraasje beheare. Mar yngenieurs brûke faaks Ansible as in manier om bash-skripts op meardere masines út te fieren. Dit is net min noch goed, mar jo moatte begripe dat de oanwêzigens fan Ansible de oanwêzigens fan DevOps yn it bedriuw net garandearret.
Wy binne yn it proses Jo sille wurde ûnderdompele yn it proses fan it ûntwikkeljen fan in applikaasje fergelykber mei de ferneamde Reddit, begjinnend mei syn monolithyske ferzje, stap foar stap ferpleatse nei mikrotsjinsten. Stap foar stap sille wy nije ark behearskje: Git, Ansible, Gitlab en einigje mei Kubernetes en Prometheus.
Wat praktiken oanbelanget, sille wy de taktyk folgje fan 'e trije paden beskreaun yn it DevOps Hânboek - trochgeande leveringpraktiken, feedbackpraktiken, en de essinsje fan 'e heule kursus is de praktyk fan trochgeand learen tegearre mei jo systeem.
Wat jout dizze kennis oan elk fan 'e spesjalisten?
Foar systeembehearders
Praktyken kinne jo fuortgean fan administraasje nei it meitsjen fan in trochgeande leveringpipeline en in ynfrastruktuerplatfoarm foar softwarelevering. It punt is dat hy in produkt makket - in ynfrastruktuerplatfoarm foar ûntwikkelders dat har helpt har feroaringen fluch nei produksje te drukken.
Earder wiene systeembehearders it lêste bastion, wêrnei't alles yn produksje giet. En yn prinsipe wiene se dwaande mei trochgeande brânbestriding - yn it ljocht wêrfan it frij lestich is om te ferdjipjen yn 'e behoeften fan it bedriuw, tinke oer it produkt en de foardielen foar de brûker.
Mei tank oan de DevOps-metoade feroaret tinken. De systeembehearder begrypt hoe't jo de konfiguraasje oersette yn koade, hokker praktiken hjirfoar bestean.
Dit is wichtich om't bedriuwen har hieltyd mear realisearje dat se net allinich alles automatisearje moatte, d.w.s. yn wat âld-skoalle systeem behearders wiene yn wêzen wend om te dwaan, dy't plus dit kommunisearre bytsje en net ynformearje it team oer alle feroarings makke. No binne de teams op syk nei dyjingen dy't de fabrikant sille wurde fan it ynterne ynfrastruktuerprodukt en helpe de skieden prosessen yn ien te kombinearjen.
Untwikkelders
De ûntwikkelder hâldt op mei tinken allinich yn algoritmen. Hy krijt de feardigens fan it wurkjen mei ynfrastruktuer, de feardigens fan arsjitektoanysk bewustwêzen fan it lânskip. Sa'n ûntwikkelder begrypt hoe't de applikaasje wurket, hoe't it troch de trochgeande leveringspipeline giet, hoe't jo it kontrolearje, hoe't jo it registrearje, sadat it de klant profitearret. As gefolch, al dizze kennis kinne jo skriuwe relevante koade.
Foar testers
Testen is al lang yn 'e automatyske modus ferpleatst; wy sizze allegear dat in protte tests net moatte wurde dien, mar skreaun :) Testen wurdt diel fan 'e heule leveringpipeline fan jo produkt. In tester moat net allinich leare hoe't jo koade skriuwe, mar ek om te begripen hoe't jo it kinne yntegrearje yn systemen foar trochgeande levering, hoe't jo feedback kinne ûntfange fan 'e koade yn alle stadia fan levering, en hoe't jo testen konstant ferbetterje kinne om flaters te ûntdekken as betiid mooglik.
Sa docht bliken dat alle trije stadia komme tagelyk. It kin bygelyks sa útsjen:
De ûntwikkelder skriuwt de koade, skriuwt der fuortendaliks tests foar, en beskriuwt in docker-kontener foar de koade dy't útfierd wurde moat. It beskriuwt ek daliks de monitoaring dy't de wurking fan dizze tsjinst yn 'e produksje sil kontrolearje, en docht dit alles.
As trochgeande yntegraasje begjint, rinne prosessen tagelyk. De tsjinst begjint en is konfigurearre. Tagelyk begjint de docker-kontener en wurdt kontrolearre dat it rint. Tagelyk giet alle ynformaasje nei it logsysteem. En sa fierder yn elke stadia fan ûntwikkeling - it docht bliken dat it in echt teamwurk is fan systeembehearders, ûntwikkelders en testers.
Ik studearre DevOps, wat fierder?
Sa't jo witte, ien yn it fjild is gjin strider. As jo bedriuw dizze metoade net brûkt, sille de ferwurven feardigens idle lizze. En nei't jo yn 'e kunde kommen binne mei DevOps-oanpak, wolle jo nei alle gedachten gjin tandwiel wêze yn bedriuwsûntwikkeling. D'r kin ien útsûndering wêze: jo binne in systeembehearder yn it team en kinne alle prosessen op in nije manier opnij opbouwe. It is hjir de muoite wurdich ta te foegjen dat d'r in protte bedriuwen binne dy't dizze oanpak brûke, en se wurde net beynfloede troch de lockdown en sykje spesjalisten. Omdat DevOps giet oer it meitsjen fan online produkten.
En no oer it goede spul: behearsking fan DevOps-praktiken en ark is sawat +30% fan jo wearde op 'e arbeidsmerk. Salarissen begjinne fan 140 tûzen roebel, mar wurde fansels bepaald troch jo haadspesjaliteit en funksjonaliteit.
Jo kinne sjen nei fakatueres markearre "ynfrastruktuer-rjochte", dêr't test automatisearring, ûntwikkeling fan microservice applikaasjes mei help fan wolk technologyen, fakatueres foar ynfrastruktuer yngenieurs en allerhanne ferwizings nei DevOps. Unthâld gewoan dat elk bedriuw wat oars betsjut troch dizze definysje - lês de beskriuwing soarchfâldich.
By de lansearring fan ús kursus kaam in ynsjoch by my - in protte minsken falle nei de kursus yn 'e fal fan in DevOps-yngenieur. Se fine in fakatuere mei de boppeneamde titel, krije in goed oanbod, en komme dan oan it wurk en beseffe dat se in trije-side-bash-skript yn Jenkins byhâlde moatte. Wêr binne Kubernetes, ChatOps, kanaryske releases en al dat? Mar d'r is neat, om't it bedriuw DevOps net nedich hat as metodyk, mar yndividuele ynnovaasjes brûkt.
Dit is in reden om yntinsyf út te finen fan it bedriuw hoe't it softwareferlieningsproses wurket, de technologystapel en hokker ferantwurdlikheden jo sille útfiere.
As de wurkjouwer jo fragen abstrakt beäntwurdet, as út in boek, sûnder details, dan is d'r nei alle gedachten noch gjin DevOps-proses yn it bedriuw, mar dit is gjin reden om te wegerjen, it bedriuw en har produkten te bestudearjen, oft d'r online binne tsjinsten dy't it bedriuw sels ûntwikkelet, mobile applikaasjes, produktideeën.
As ja, ferdúdlikje dan as jo direkt mei dizze systemen moatte wurkje of oft d'r de mooglikheid is fan horizontale beweging nei de teams fan dizze tsjinsten, wylst jo goede resultaten yn DevOps-praktiken demonstrearje. As ja, dan is it wurdich om te gean en aktyf en nuttich te wêzen, en as jo ús kursus foltôgje, is de lêste garandearre.
It is wichtich om te notearjen dat Devops-beoefeners allinich wiere wearde krije mei ûnderfining yn ûntwikkeling / administraasje / testen. Allinne dan sil de kennis net abstrakt wêze, mar de spesjalist (yn alle opsichten) ferrykje. Dêrom is it idee fan "DevOps fanôf it begjin te learen" sawat itselde as it learen om "linzen fanôf it begjin te brûken" as jo noch noait in kamera yn jo hannen hawwe holden of in foto regissearre. Om jo te helpen beslute as de kursus goed is foar jo, hawwe wy in yngongstest makke dy't jo genôch kennisnivo sil kontrolearje.
Ik tink ien fan 'e trúkjes - dat yn de rin fan de oplieding eltse studint foar himsels bepaalt yn hokker rjochting er him ûntjaan wol. Wy sjogge faak oergongen as in ûntwikkelder in ynfrastruktuer-yngenieur wurdt, en in behearder beseft dat hy ynteressearre is yn it skriuwen fan koade - dan studearret hy de taal fierder en oanfolje it mei de oanhelle DevOps-feardigens. Dêrom ferwolkomje wy benammen dyjingen dy't fiele dat har karriêre fêst sit op in krúspunt. De kursus begjint op 28 maaie, mar jo kinne 2 wiken nei it begjin fan de lessen meidwaan. Jo kinne it programma besjen en de test nimme . Oant sjen by OTUS!
Boarne: www.habr.com