Kien iri kun ĉi tiu scio, kion fari en la projekto kaj kiom enspezi, kion diri kaj demandi ĉe intervjuo - diras Alexander Titov, administra partnero de Express 42 kaj aŭtoro. .
Saluton! Kvankam la termino DevOps ekzistas ekde 2009, ankoraŭ ne ekzistas konsento en la rusa komunumo. Vi verŝajne rimarkis, ke iuj konsideras DevOps specialaĵo, aliaj konsideras ĝin filozofio, kaj aliaj konsideras la terminon aro de teknologioj. Mi jam multfoje koncertis kun pri la evoluo de ĉi tiu direkto, do mi ne detale en ĉi tiu artikolo. Mi nur diru, ke ĉe Express 42 ni inkluzivas la jenajn en ĝi:
DevOps estas specifa metodaro, kulturo de kreado de cifereca produkto, kiam ĉiuj specialistoj en la teamo partoprenas en produktado.
En klasika kompania evoluo, ĉio iras sinsekve: programado, testado kaj nur tiam funkciado, kaj la rapideco de ĉi tiu procezo de ideo ĝis produktado estas 3 monatoj. Ĉi tio estas tutmonda problemo por ciferecaj produktoj, ĉar estas neeble rapide ricevi komentojn de klientoj.
En DevOps, iloj kaj aliroj estas dizajnitaj por certigi, ke evoluaj, testaj kaj operaciaj procezoj funkcias samtempe.
Kio sekvas el ĉi tiu aliro?
- Vi ne povas dungi iun "inĝenieron", kiu venos kaj solvos ĉiujn problemojn pri produktado. La tuta teamo devas apliki la teknikon.
- DevOps NE estas la sekva formo de administranto por ĝisdatigi. "DevOps-inĝeniero" sonas proksimume same kiel "Agile programisto".
- Se teamo uzas Kubernetes, Ansible, Prometheus, Mesosphere kaj Docker, tio ne signifas, ke DevOps-praktikoj estis efektivigitaj tie.
Vivo post DevOps neniam estos la sama
La aliro DevOps estas, antaŭ ĉio, malsama pensmaniero, percepto de evoluo kiel tuto kaj onies loko en la procezo. Ni dividis nian retan kurson en 2 blokojn:
1. Memdecido
Unue, ni ekzamenas detale la esencon de la DevOps-aliro, kaj studentoj malkovras novajn rolojn en la teamo, vidas, kiu respondas pli, kaj determinas mem, kiun direkton disvolvi.
2. Iloj kaj praktikoj
Studentoj regas specifajn teknologiojn el la vidpunkto de la metodo DevOps.
DevOps-iloj povas esti uzataj kaj en la DevOps-aliro kaj en klasika evoluo. La plej evidenta ekzemplo estus uzi la Ansible-agordan administran ilon. Ĝi estis kreita kaj konceptita por efektivigi la DevOps-praktikon "Infrastrukturo kiel Kodo", kio signifas, ke malsamaj statoj de la sistemo estas priskribitaj, de agordoj de operaciumo ĝis aplikaĵo. La priskribo estas dividita en tavolojn kaj permesas al vi administri kompleksan, konstante ŝanĝiĝantan agordon. Sed inĝenieroj ofte uzas Ansible kiel manieron ruli bash-skriptojn sur pluraj maŝinoj. Ĉi tio estas nek malbona nek bona, sed vi devas kompreni, ke la ĉeesto de Ansible ne garantias la ĉeeston de DevOps en la kompanio.
Ni estas en la procezo Vi estos mergita en la procezo de evoluigo de aplikaĵo simila al la fama Reddit, komencante de ĝia monolita versio, moviĝante paŝon post paŝo al mikroservoj. Paŝo post paŝo ni regos novajn ilojn: Git, Ansible, Gitlab kaj finos per Kubernetes kaj Prometheus.
Koncerne praktikojn, ni sekvos la taktikojn de la tri vojoj priskribitaj en la DevOps-Manlibro - daŭraj liveraj praktikoj, sugestaj praktikoj, kaj la esenco de la tuta kurso estas la praktiko de kontinua lernado kune kun via sistemo.
Kion donas ĉi tiu scio al ĉiu el la specialistoj?
Por sistemadministrantoj
Praktikoj permesos vin foriri de administrado al kreado de kontinua livera dukto kaj infrastruktura platformo por programaro livero. La punkto estas, ke li kreas produkton - infrastrukturan platformon por programistoj, kiu helpas ilin rapide antaŭenpuŝi iliajn ŝanĝojn al produktado.
Antaŭe, sistemadministrantoj estis la lasta bastiono, post kiu ĉio eniras en produktadon. Kaj esence ili okupiĝis pri kontinua fajroestingado - pro kio estas sufiĉe malfacile enprofundiĝi en la bezonojn de la komerco, pensi pri la produkto kaj la avantaĝoj por la uzanto.
Danke al la metodo DevOps, pensado ŝanĝiĝas. La sistemadministranto komprenas kiel traduki la agordon en kodon, kiaj praktikoj ekzistas por tio.
Ĉi tio estas grava ĉar kompanioj ĉiam pli rimarkas, ke ili ne nur bezonas aŭtomatigi ĉion, t.e. en kio malnovlernejaj sistemaj administrantoj esence kutimis fari, kiuj krom tio ĉi malmulte komunikis kaj ne informis la teamon pri ĉiuj faritaj ŝanĝoj. Nun la teamoj serĉas tiujn, kiuj fariĝos la fabrikanto de la interna infrastruktura produkto kaj helpos kombini la apartajn procezojn en unu.
Por programistoj
La programisto ĉesas pensi nur en algoritmoj. Li akiras la kapablon labori kun infrastrukturo, la kapablon de arkitektura konscio pri la pejzaĝo. Tia programisto komprenas kiel la aplikaĵo funkcias, kiel ĝi trairas la kontinuan liveran dukton, kiel kontroli ĝin, kiel registri ĝin por ke ĝi profitu al la kliento. Kiel rezulto, ĉi tiu tuta scio permesas skribi koncernan kodon.
Por testistoj
Testado delonge moviĝas al aŭtomata reĝimo; ni ĉiuj diras, ke multaj provoj ne devas esti faritaj, sed skribitaj :) Testado fariĝas parto de la tuta livera dukto de via produkto. Testanto devas ne nur lerni kiel skribi kodon, sed ankaŭ kompreni kiel integri ĝin en kontinuajn liversistemojn, kiel ricevi religojn de la kodo en ĉiuj stadioj de livero, kaj kiel konstante plibonigi testadon por detekti erarojn kiel. kiel eble frue.
Do rezultas ke ĉiuj tri stadioj okazas samtempe. Ekzemple, ĝi povus aspekti jene:
La programisto skribas la kodon, tuj skribas testojn por ĝi, kaj priskribas docker ujon por la kodo kiu devus esti rulita. Ĝi ankaŭ tuj priskribas la monitoradon, kiu kontrolos la funkciadon de ĉi tiu servo en produktado, kaj faras ĉion ĉi.
Kiam daŭra integriĝo komenciĝas, procezoj funkcias samtempe. La servo komenciĝas kaj estas agordita. Samtempe, la docker-ujo komenciĝas kaj oni kontrolas, ke ĝi funkcias. Samtempe, ĉiuj informoj iras al la registra sistemo. Kaj tiel plu en ĉiu etapo de evoluo - ĝi montriĝas vera teamlaboro de sistemadministrantoj, programistoj kaj testistoj.
Mi studis DevOps, kio poste?
Kiel vi scias, unu sur la kampo ne estas militisto. Se via kompanio ne uzas ĉi tiun metodon, la akiritaj kapabloj restos senutilaj. Kaj post konatiĝo kun DevOps-aliroj, vi plej verŝajne ne volos esti dentaĵo en kompania disvolviĝo. Eble ekzistas unu escepto: vi estas sistemadministranto en la teamo kaj povas rekonstrui ĉiujn procezojn en nova maniero. Indas aldoni ĉi tie, ke ekzistas multaj kompanioj, kiuj uzas ĉi tiun aliron, kaj ili ne estas tuŝitaj de la enfermo kaj serĉas specialistojn. Ĉar DevOps temas pri kreado de interretaj produktoj.
Kaj nun pri la bonaj aferoj: regado de praktikoj kaj iloj de DevOps estas proksimume +30% al via valoro sur la labormerkato. Salajroj komenciĝas de 140 mil rubloj, sed estas determinitaj, nature, de via ĉefa specialaĵo kaj funkcieco.
Vi povas rigardi vakantaĵojn markitajn "infrastruktur-orientitajn", kie ekzistas testaŭtomatigo, disvolviĝo de mikroservaj aplikoj uzante nubajn teknologiojn, vakantaĵoj por infrastrukturaj inĝenieroj kaj ĉiaj referencoj al DevOps. Nur memoru, ke ĉiu kompanio signifas ion malsaman laŭ ĉi tiu difino - atente legu la priskribon.
Dum la lanĉo de nia kurso venis al mi kompreno - multaj homoj post la kurso falas en la kaptilon de DevOps-inĝeniero. Ili trovas vakanton kun la supre menciita titolo, ricevas bonan oferton, kaj poste venas al laboro kaj rimarkas, ke ili devos konservi tri-paĝan bash-skripton en Jenkins. Kie estas Kubernetes, ChatOps, kanariaj eldonoj kaj ĉio tio? Sed estas nenio, ĉar la kompanio ne bezonas DevOps kiel metodaron, sed uzas individuajn novigojn.
Ĉi tio estas kialo por intense ekscii de la kompanio kiel funkcias la procezo de livero de programaro, la teknologia stako kaj kiajn respondecojn vi plenumos.
Se la dunganto respondas viajn demandojn abstrakte, kvazaŭ el libro, sen detaloj, tiam plej verŝajne ankoraŭ ne ekzistas DevOps-procezo en la kompanio, sed ĉi tio ne estas kialo por rifuzi, studi la kompanion kaj ĝiajn produktojn, ĉu ekzistas interrete. servoj, kiujn la kompanio mem disvolvas, moveblaj aplikoj, produktaj ideoj.
Se jes, tiam klarigu ĉu vi devos labori rekte kun ĉi tiuj sistemoj aŭ ĉu ekzistas la ebleco de horizontala movado al la teamoj de ĉi tiuj servoj dum vi pruvas bonajn rezultojn en DevOps-praktikoj. Se jes, do indas iri kaj esti aktiva kaj utila, kaj se vi kompletigas nian kurson, ĉi-lasta estas garantiita.
Gravas noti, ke Devops-praktikistoj akiras veran valoron nur kun sperto en evoluo/administrado/testado. Nur tiam la scioj ne estos abstraktaj, sed riĉigos la specialiston (ĉiusence). Tial la ideo "lerni DevOps de nulo" estas proksimume la sama kiel lerni "uzi lensojn de nulo" se vi neniam tenis fotilon en viaj manoj aŭ direktis pafadon. Por helpi vin decidi ĉu la kurso taŭgas por vi, ni faris enirteston, kiu kontrolos vian sufiĉan nivelon de scio.
Mi pensas, ke unu el la lertaĵoj — ke dum la trejnado ĉiu studento mem determinas, en kiu direkto li volas disvolviĝi. Ni ofte vidas transirojn kiam programisto fariĝas infrastruktura inĝeniero, kaj administranto rimarkas, ke li interesiĝas pri skribi kodon - tiam li plue studas la lingvon kaj kompletigas ĝin per la akiritaj DevOps-kapabloj. Tial ni precipe bonvenigas tiujn, kiuj sentas, ke ilia kariero estas blokita ĉe vojkruciĝo. La kurso komenciĝas la 28-an de majo, sed vi povas aliĝi 2 semajnojn post la komenco de la klasoj. Vi povas vidi la programon kaj fari la teston . Ĝis revido ĉe OTUS!
fonto: www.habr.com