Kiam aplikaĵo ne funkcias, la lasta afero, kiun vi volas aŭdi de viaj kolegoj, estas la frazo "la problemo estas via flanko." Kiel rezulto, uzantoj suferas - kaj ili ne zorgas pri kiu parto de la teamo respondecas pri la paneo. DevOps-kulturo aperis ĝuste por kunigi evoluon kaj subtenon ĉirkaŭ komuna respondeco por la fina produkto.
Kiuj praktikoj estas inkluzivitaj en la koncepto de DevOps kaj kial ili bezonas? Kion faras DevOps-inĝenieroj kaj kion ili devus povi fari? Fakuloj de EPAM respondas ĉi tiujn kaj aliajn demandojn: Kirill Sergeev, sistem-inĝeniero kaj DevOps evangeliisto, kaj Igor Boyko, gvida sistem-inĝeniero kaj kunordiganto de unu el la DevOps-teamoj de la firmao.
Kial DevOps bezonas?
Antaŭe, ekzistis baro inter programistoj kaj subteno (tielnomitaj operacioj). Sonas paradokse, sed ili havis malsamajn celojn kaj KPIojn, kvankam ili faris la samon. La celo de la evoluo estis efektivigi komercajn postulojn kiel eble plej rapide kaj aldoni ilin al funkcianta produkto. Subteno estis respondeca por certigi ke la aplikaĵo funkciis stabile - kaj ajnaj ŝanĝoj riskas stabilecon. Estas konflikto de intereso - DevOps ŝajnis solvi ĝin.
Kio estas DevOps?
Ĝi estas bona demando - kaj polemika: la mondo ankoraŭ ne finfine konsentis pri tio. EPAM kredas, ke DevOps kombinas teknologiojn, procezojn kaj kulturon de interagado ene de teamo. Ĉi tiu asocio celas kontinue liveri valoron al finaj uzantoj.
Kiril Sergeev: "Programistoj skribas kodon, testistoj revizias ĝin, kaj administrantoj deplojas la finan produkton al produktado. Dum longa tempo, ĉi tiuj partoj de la teamo estis iom disaj, kaj tiam ekestis la ideo unuigi ilin per komuna procezo. Jen kiel DevOps-praktikoj aperis."
Venis la tago, kiam programistoj kaj sisteminĝenieroj interesiĝis pri la laboro de unu la alian. La baro inter produktado kaj subteno komencis malaperi. Jen kiel aperis DevOps, kiu inkluzivas praktikojn, kulturon kaj teaminteragadon.
Kio estas la esenco de DevOps-kulturo?
La fakto estas, ke respondeco pri la fina rezulto kuŝas sur ĉiu teamano. La plej interesa kaj malfacila afero en la filozofio DevOps estas kompreni, ke specifa persono ne nur respondecas pri sia propra etapo de laboro, sed respondecas pri kiel la tuta produkto funkcios. La problemo ne kuŝas flanke de iu ajn - ĝi estas dividita, kaj ĉiu teamano helpas ĝin solvi.
La plej grava afero en DevOps-kulturo estas solvi la problemon, ne nur apliki DevOps-praktikojn. Krome, ĉi tiuj praktikoj ne estas efektivigitaj "flanke de iu", sed tra la tuta produkto. Projekto ne bezonas DevOps-inĝenieron en si mem - ĝi bezonas solvon al problemo, kaj la rolo de DevOps-inĝeniero povas esti distribuita inter pluraj teamanoj kun malsamaj specialiĝoj.
Kio estas la specoj de DevOps-praktikoj?
DevOps-praktikoj kovras ĉiujn stadiojn de la programara vivociklo.
Igor Boyko: "La ideala kazo estas kiam ni komencas uzi DevOps-praktikojn ĝuste ĉe la komenco de projekto. Kune kun la arkitektoj, ni planas kian arkitekturan pejzaĝon havos la aplikaĵo, kie ĝi situos kaj kiel grimpi, kaj elektas platformon. Nuntempe, mikroserva arkitekturo estas en modo - por ĝi ni elektas orkestradsistemon: vi devas povi administri ĉiun elementon de la aplikaĵo aparte kaj ĝisdatigi ĝin sendepende de la aliaj. Alia praktiko estas "infrastrukturo kiel kodo". Ĉi tiu estas la nomo por aliro en kiu la projekta infrastrukturo estas kreita kaj administrita uzante kodon, prefere ol per rekta interago kun serviloj.
Poste ni transiru al la evolufazo. Unu el la plej grandaj praktikoj ĉi tie estas konstruado de CI/KD: vi devas helpi programistojn integri ŝanĝojn en la produkton rapide, en malgrandaj partoj, pli ofte kaj sendolore. CI/KD kovras kodrevizion, alŝutante la majstron al la kodbazo, kaj deplojante la aplikaĵon por testi kaj produktadmedioj.
En la CI/KD-stadioj, la kodo pasas tra bonkvalitaj pordegoj. Kun ilia helpo, ili kontrolas, ke la kodo, kiu eliras el la laborstacio de la programisto, plenumas la specifitajn kvalitajn kriteriojn. Testado pri unuo kaj UI estas aldonita ĉi tie. Por rapida, sendolora kaj fokusita produkto-deplojo, vi povas elekti la taŭgan disfaldan tipon.
DevOps-praktikistoj ankaŭ havas lokon en la stadio de subteno de la preta produkto. Ili estas uzataj por monitorado, retrosciigo, sekureco kaj enkonduko de ŝanĝoj. DevOps rigardas ĉiujn ĉi tiujn taskojn el daŭra pliboniga perspektivo. Ni minimumigas ripetajn operaciojn kaj aŭtomatigas ilin. Ĉi tio ankaŭ inkluzivas migradojn, aplikaĵan ekspansion kaj rendimentan subtenon."
Kio estas la avantaĝoj de DevOps-praktikoj?
Se ni skribus lernolibron pri modernaj DevOps-praktikoj, estus tri punktoj sur la unua paĝo: aŭtomatigo, rapidigo de eldonoj kaj rapidaj reagoj de uzantoj.
Kiril Sergeev: “La unua afero estas aŭtomatigo. Ni povas aŭtomatigi ĉiujn interagojn en la teamo: skribis la kodon - ruliĝis ĝin - kontrolis ĝin - instalis ĝin - kolektis sugestojn - revenis al la komenco. Ĉio ĉi estas aŭtomata.
La dua akcelas la liberigon kaj eĉ simpligas evoluon. Ĉiam gravas por la kliento, ke la produkto eniras la merkaton kiel eble plej baldaŭ kaj komencas doni avantaĝojn pli frue ol la analogoj de konkurantoj. La produkta liveroprocezo povas esti plibonigita senfine: redukti tempon, aldoni pliajn kontrolmarkojn, plibonigi monitoradon.
Trie estas la akcelo de uzantreagoj. Se li havas komentojn, ni povas tuj fari ĝustigojn kaj tuj ĝisdatigi la aplikaĵon."
Kiel rilatas la konceptoj "inĝeniero pri sistemoj", "inĝeniero pri konstruado" kaj "inĝeniero DevOps"?
Ili interkovras, sed apartenas al iomete malsamaj areoj.
Sisteminĝeniero ĉe EPAM estas pozicio. Ili venas en malsamaj niveloj: de juniora ĝis ĉefspecialisto.
Konstruinĝeniero estas pli ol rolo, kiu povas esti plenumita en projekto. Nun tiel nomiĝas homoj respondecaj pri CI/CD.
DevOps-inĝeniero estas specialisto kiu efektivigas DevOps-praktikojn en projekto.
Se ni resumas ĉion, ni ricevas ion tian: persono en la pozicio de sistema inĝeniero ludas la rolon de konstrua inĝeniero en projekto kaj estas implikita en la efektivigo de DevOps-praktikoj tie.
Kion precize faras DevOps-inĝeniero?
DevOps-inĝenieroj kunigas ĉiujn pecojn, kiuj konsistigas projekton. Ili konas la specifaĵojn de la laboro de programistoj, testistoj, sistemaj administrantoj kaj helpas simpligi ilian laboron. Ili komprenas la bezonojn kaj postulojn de la komerco, ĝian rolon en la evoluprocezo - kaj konstruas la procezon konsiderante la interesojn de la kliento.
Ni multe parolis pri aŭtomatigo - jen kion traktas DevOps-inĝenieroj unue kaj ĉefe. Ĉi tio estas tre granda punkto, kiu, interalie, inkluzivas preparon de la medio.
Kiril Sergeev: "Antaŭ ol efektivigi ĝisdatigojn en la produkton, ili devas esti provitaj en triaparta medio. Ĝi estas preparita de DevOps-inĝenieroj. Ili instigas DevOps-kulturon en la projekto kiel tuto: ili enkondukas DevOps-praktikojn ĉe ĉiuj tavoloj de siaj projektoj. Ĉi tiuj tri principoj: aŭtomatigo, simpligo, akcelo - ili alportas kien ajn ili povas atingi."
Kion devus scii DevOps-inĝeniero?
Ĝenerale, li devas havi scion de malsamaj areoj: programado, laborado kun operaciumoj, datumbazoj, kunigo kaj agordaj sistemoj. Ĉi tiuj estas kompletigitaj per la kapablo labori kun nuba infrastrukturo, instrumentado kaj monitoraj sistemoj.
1. Programlingvoj
DevOps-inĝenieroj konas plurajn bazajn lingvojn por aŭtomatigo kaj povas, ekzemple, diri al programisto: "Kion vi instalas la kodon ne mane, sed uzante nian skripton, kiu aŭtomatigas ĉion? Ni preparos agordan dosieron por ĝi, estos oportune por vi kaj ni legi, kaj ni povos ŝanĝi ĝin kiam ajn. Ni ankaŭ vidos kiu, kiam kaj kial faras ŝanĝojn al ĝi."
DevOps-inĝeniero povas lerni unu aŭ pli el ĉi tiuj lingvoj: Python, Groovy, Bash, Powershell, Ruby, Go. Ne necesas koni ilin je profunda nivelo - la bazoj de sintakso, OOP-principoj kaj la kapablo skribi simplajn skriptojn por aŭtomatigo sufiĉas.
2. Operaciumoj
DevOps-inĝeniero devas kompreni sur kiu servilo la produkto estos instalita, en kiu medio ĝi funkcios kaj kun kiuj servoj ĝi interagos. Vi povas elekti specialiĝi pri Vindozo aŭ la familio Linukso.
3. Sistemoj de kontrolo de versioj
Sen scio pri versio-kontrolsistemo, DevOps-inĝeniero estas nenie. Git estas unu el la plej popularaj sistemoj nuntempe.
4. Nubaj provizantoj
AWS, Google, Azure - precipe se ni parolas pri la Vindoza direkto.
Kiril Sergeev: “Nubaj provizantoj provizas al ni virtualajn servilojn, kiuj perfekte konvenas en CI/KD.
Instali dek fizikajn servilojn postulas ĉirkaŭ cent manajn operaciojn. Ĉiu servilo devas esti mane lanĉita, instalita kaj agordita la bezonata operaciumo, instalita nian aplikaĵon sur ĉi tiuj dek serviloj, kaj poste duoble kontroli ĉion dek fojojn. Nubaj servoj anstataŭigas ĉi tiun proceduron per dek linioj de kodo, kaj bona DevOps-inĝeniero devus povi funkcii kun ili. Ĉi tio ŝparas tempon, penadon kaj monon - kaj por la kliento kaj por la kompanio."
5. Orkestraj sistemoj: Docker kaj Kubernetes
Kiril Sergeev: “Virtualaj serviloj estas dividitaj en ujojn, en ĉiu el kiuj ni povas instali nian aplikaĵon. Kiam estas multaj ujoj, vi devas administri ilin: ŝalti unu, malŝalti alian, fari sekurkopiojn ie. Ĉi tio fariĝas sufiĉe kompleksa kaj postulas orkestradsistemon.
Antaŭe, ĉiu aplikaĵo estis pritraktata de aparta servilo - ajnaj ŝanĝoj en ĝia funkciado povus influi la servadon de la aplikaĵo. Danke al ujoj, aplikaĵoj izoliĝas kaj funkcias aparte - ĉiu sur sia propra virtuala maŝino. Se okazas malsukceso, ne necesas perdi tempon serĉante la kaŭzon. Estas pli facile detrui la malnovan ujon kaj aldoni novan."
6. Agordaj sistemoj: Chef, Ansible, Puppet
Kiam vi bezonas konservi tutan aron da serviloj, vi devas fari multajn samajn operaciojn. Ĝi estas longa kaj malfacila, kaj mana laboro ankaŭ pliigas la ŝancon de eraro. Ĉi tie estas kie agordaj sistemoj venas al la savo. Kun ilia helpo, ili kreas skripton facile legeblan por programistoj, DevOps-inĝenieroj kaj sistemaj administrantoj. Ĉi tiu skripto helpas efektivigi la samajn operaciojn sur serviloj aŭtomate. Ĉi tio reduktas manajn operaciojn (kaj tial erarojn).
Kian karieron povas konstrui DevOps-inĝeniero?
Vi povas disvolvi ambaŭ horizontale kaj vertikale.
Igor Boyko: "El la vidpunkto de horizontala evoluo, DevOps-inĝenieroj nun havas la plej larĝajn perspektivojn. Ĉio konstante ŝanĝiĝas, kaj vi povas konstrui kapablojn en diversaj areoj: de versio-kontrolsistemoj ĝis monitorado, de agorda administrado ĝis datumbazoj.
Vi povas fariĝi sistemarkitekto se dungito interesiĝas pri kompreni kiel aplikaĵo funkcias en ĉiuj stadioj de sia vivociklo - de evoluo ĝis subteno."
Kiel fariĝi DevOps-inĝeniero?
- Legu La Phoenix Project kaj DevOps Manlibron. Ĉi tiuj estas la veraj kolonoj de la DevOps-filozofio, kun la unua estas verko de fikcio.
- Lernu teknologiojn el la supra listo: memstare aŭ per interretaj kursoj.
- Aliĝu kiel DevOps-inĝeniero por malfermfonta projekto.
- Praktiku kaj ofertu DevOps-praktikojn pri viaj personaj kaj laborprojektoj.
fonto: www.habr.com