Lastatempe tiaj reklamoj inundis la Interreton. Malgraŭ la agrabla salajro, oni ne povas ne embarasi, ke ene estas skribita sovaĝa herezo. Komence oni supozas, ke "DevOps" kaj "inĝeniero" iel povas esti kungluitaj en unu vorton, kaj tiam estas hazarda listo de postuloj, kelkaj el kiuj estas klare kopiitaj de la vakantaĵo de sysadmin.
En ĉi tiu afiŝo mi ŝatus paroli iomete pri kiel ni alvenis al ĉi tiu punkto de la vivo, kio vere estas DevOps kaj kion fari kun ĝi nun.
Tiaj vakantaĵoj povas esti kondamnitaj en ĉiuj eblaj manieroj, sed la fakto restas: estas multaj el ili, kaj tiel funkcias la merkato nuntempe. Ni okazigis devops-konferencon kaj malkaŝe deklaras: " - ne por DevOps-inĝenieroj." Ĉi tie, multaj trovos ĝin stranga kaj sovaĝa: kial homoj, kiuj faras tute komercan eventon, iras kontraŭ la merkato. Nun ni klarigos ĉion.
Pri kulturo kaj procezoj
Ni komencu per la fakto, ke DevOps ne estas inĝenieristiko. Ĉio komenciĝis per tio, ke la historie establita divido de roloj ne funkcias por la kvalito de produktoj. Kiam programistoj nur programas, sed ne volas aŭdi ion pri testado, la programaro estas plena de cimoj. Kiam administrantoj ne zorgas kiel aŭ kial la programaro estas skribita, subteno fariĝas infero.
Ekzemple, priskribante la diferencon inter sistemadministranto kaj SRE-aliro al serva administrado . Interesaj studoj estis faritaj ene — estas klare, ke la plej bonaj programistoj iel sukcesas disfaldi novajn ŝanĝojn al produktado pli rapide ol unufoje hore. Ili testas per siaj manoj ne pli ol 10% (ĉi tio videblas de ). Kiel ili faras ĉi tion? "Excel aŭ mortu" diras unu el la raportaj rubrikoj. Por detala diskuto pri ĉi tiuj statistikoj en la kunteksto de testado, vi povas raporti al la ĉefnoto de Baruch Sadogursky. ĉe nia alia konferenco, Heisenbug.
"Kiam ne estas interkonsento inter kamaradoj,
Aferoj ne iros bone por ili,
Kaj nenio el ĝi eliros, nur turmento.
Iam cigno, kankro kaj ezoko..."
Kiu parto de TTT-programistoj laŭ vi vere komprenas la kondiĉojn sub kiuj iliaj aplikoj estas uzataj en produktado? Kiom da ili iros al la administrantoj kaj provos ekscii, kio okazos se la datumbazo kraŝos? Kaj kiu el ili iros al la testantoj kaj petos ilin instrui al ili kiel ĝuste skribi testojn? Kaj estas ankaŭ sekurecgardistoj, produktmanaĝeroj, kaj amaso da aliaj homoj.
La ĝenerala ideo de DevOps estas krei kunlaboron inter roloj kaj fakoj. Antaŭ ĉio, tio estas atingita ne per iu lerte agordita programaro, sed per la praktiko de komunikado. DevOps temas pri kulturo, praktikoj, metodaro kaj procezoj. Ne ekzistas inĝenieristiko, kiu povas respondi ĉi tiujn demandojn.
Malvirta rondo
De kie venis la disciplino de "devops-inĝenieristiko" tiam? Ni havas version! DevOps-ideoj estis bonaj—tiel bonaj ke ili fariĝis viktimoj de sia propra sukceso. Kelkaj ombraj rekrutistoj kaj homaj ŝakristoj, kiuj havas sian propran etoson, komencis kirliĝi ĉirkaŭ ĉi tiu tuta temo.
Imagu: hieraŭ vi faris ŝavarmon en Ĥimki, kaj hodiaŭ vi jam estas granda viro, altranga rekrutisto. Estas tuta procezo de serĉado kaj elekto de kandidatoj, ĉio ne estas facila, vi devas kompreni. Ni diru, ke la estro de fako diras: trovu specialiston en X. Ni atribuas la vorton "inĝeniero" al X, kaj ni finis. Bezonas Linukson? Nu, ĉi tio certe estas Linukso-inĝeniero, se vi volas DevOps, tiam DevOps-inĝeniero. La vakantaĵo konsistas ne nur el titolo, sed ankaŭ ia teksto devas esti enigita enen. La plej facila maniero estas enigi aron da ŝlosilvortoj de Guglo, depende de via imago. DevOps konsistas el du vortoj - "Dev" kaj "Ops", kio signifas, ke ni devas kunglui ŝlosilvortojn rilatajn al programistoj kaj administrantoj, ĉio en unu amason. Jen kiel vakantaĵoj aperas pri scipovo en 42 programlingvoj kaj 20 jaroj de uzado de Kubernetes kaj Swarm samtempe. Labora diagramo.
Jen kiel la sensenca kaj senkompata bildo de certa "devops" superheroo enradikiĝis en la mensoj de homoj, kiuj agordos ĉiujn por deploji al Jenkins, kaj venos feliĉo. Ho, se ĉio estus tiel simpla. "Kaj ankaŭ jen kiel vi povas ĉasi sistemajn administrantojn," opinias HR, "ĝi estas moda vorto, la ŝlosilvortoj estas la samaj, ili devus preni la logilon."
Postulo kreas provizon, kaj ĉiuj ĉi tiuj rubo-vakantaĵoj estis plenigitaj de freneza nombro da sistemadministrantoj, kiuj rimarkis: vi povas fari ĉion same kiel antaŭe, sed ricevi plurajn fojojn pli nomante vin "devops". Same kiel vi agordis servilojn per SSH permane unuope, vi daŭre agordos ilin, sed nun ĉi tio estas supozeble praktiko de devops. Ĉi tio estas ia kompleksa fenomeno, parte rilata al la subtakso de klasikaj administrantoj kaj la hype ĉirkaŭ DevOps, sed ĝenerale, kio okazis, okazis.
Do ni havas proponon kaj postulon. Malica rondo, kiu sin nutras. Jen kontraŭ kio ni batalas (inkluzive kreante la DevOops-konferencon).
Kompreneble, krom la sistemaj administrantoj, kiuj renomis sin "devops", estas aliaj partoprenantoj - ekzemple profesiaj SRE-oj aŭ programistoj de Infrastructure-as-Code.
Kion homoj faras en DevOps (vere)
Do vi volas progresi en lernado kaj aplikado de DevOps-praktikoj. Sed kiel fari tion, en kiu direkto rigardi? Evidente, vi ne blinde fidi je popularaj ŝlosilvortoj.
Se estas laboro, iu devus fari ĝin. Ni jam eksciis, ke ĉi tiuj ne estas "devops-inĝenieroj", do kiuj estas? Ŝajnas pli ĝuste formuli tion ne laŭ pozicioj, sed laŭ specifaj laborfakoj.
Unue, vi povas trakti la koron de DevOps - procezoj kaj kulturo. Kulturo estas malrapida kaj malfacila komerco, kaj kvankam ĝi estas tradicie la respondeco de administrantoj, ĉiuj estas implikitaj laŭ unu maniero aŭ alia, de programistoj ĝis administrantoj. Antaŭ kelkaj monatoj Tim Lister :
"Kulturo estas determinita de la kernaj valoroj de la organizo. Kutime homoj ne rimarkas tion, sed laborinte en konsultado dum multaj jaroj, ni kutimas rimarki ĝin. Vi eniras kompanion kaj laŭvorte ene de kelkaj minutoj vi komencas senti tion, kio okazas. Ni nomas ĉi tion "gusto". Kelkfoje ĉi tiu odoro estas vere bona. Kelkfoje ĝi kaŭzas naŭzon. (...) Vi ne povas ŝanĝi kulturon ĝis la valoroj kaj kredoj malantaŭ specifaj agoj estas komprenitaj. Konduto estas facile observi, sed serĉi kredojn estas malfacila. DevOps estas nur bonega ekzemplo de kiel aferoj fariĝas pli kaj pli kompleksaj."
Estas ankaŭ teknika parto de la afero, kompreneble. Se via nova kodo estas provita post monato, sed estas publikigita nur jaron poste, kaj estas fizike neeble rapidigi ĉion, vi eble ne plenumas bonajn praktikojn. Bonaj praktikoj estas subtenataj de bonaj iloj. Ekzemple, kun la ideo de Infrastructure-as-Code en menso, vi povas uzi ion ajn de AWS CloudFormation kaj Terraform ĝis Chef-Ansible-Puppet. Vi devas scii kaj povi fari ĉion ĉi, kaj ĉi tio jam estas sufiĉe inĝenieristiko. Gravas ne konfuzi kaŭzon kun efiko: unue oni laboras laŭ la principoj de SRE kaj nur poste efektivigas ĉi tiujn principojn en la formo de iuj specifaj teknikaj solvoj. Samtempe, SRE estas tre ampleksa metodaro, kiu ne diras al vi kiel agordi Jenkins, sed pri kvin bazaj principoj:
- Plibonigita komunikado inter roloj kaj fakoj
- Akceptante erarojn kiel integran parton de la laboro
- Farante ŝanĝojn iom post iom
- Uzante ilaron kaj alian aŭtomatigon
- Mezuri ĉion, kio povas esti mezurita
Ĉi tio ne estas nur iu aro de deklaroj, sed specifa . Ekzemple, sur la vojo al akcepto de eraroj, vi devos kompreni la riskojn, mezuri la haveblecon kaj nehaveblecon de servoj uzante ion kiel SLI () kaj SLO (), lernu skribi postmortemojn kaj igi skribi ilin ne timiga.
En la SRE-disciplino, la uzo de iloj estas nur unu parto de sukceso, kvankam grava. Ni devas konstante disvolvi teknike, rigardi kio okazas en la mondo kaj kiel ĝi povas esti aplikata en nia laboro.
Siavice, Cloud Native-solvoj nun fariĝis tre popularaj. Kiel difinite de la Cloud Native Computing Foundation hodiaŭ, Cloud Native-teknologioj ebligas al organizoj evoluigi kaj funkcii skaleblajn aplikojn en hodiaŭaj dinamikaj medioj, kiel publikaj, privataj kaj hibridaj nuboj. Ekzemploj inkluzivas ujojn, servajn retojn, mikroservojn, neŝanĝeblan infrastrukturon kaj deklarajn APIojn. Ĉiuj tiuj teknikoj permesas al loze kunligitaj sistemoj resti elastaj, regeblaj kaj tre observeblaj. Bona aŭtomatigo permesas al inĝenieroj fari grandajn ŝanĝojn ofte kaj kun antaŭvideblaj rezultoj sen fari ĝin tasko. Ĉio ĉi estas subtenata de stako de konataj iloj kiel Docker kaj Kubernetes.
Ĉi tiu sufiĉe komplika kaj larĝa difino ŝuldiĝas al la fakto, ke la areo ankaŭ estas sufiĉe kompleksa. Unuflanke, oni argumentas, ke novaj ŝanĝoj al ĉi tiu sistemo devus esti aldonitaj tute simple. Aliflanke, eltrovi kiel krei specon de kontenerigita medio en kiu loze kunligitaj servoj vivas sur programaro difinita infrastrukturo kaj estas liveritaj tie uzante kontinuan CI/KD, kaj konstrui DevOps-praktikojn ĉirkaŭ ĉio ĉi - ĉio ĉi postulas pli. ol oni manĝas la hundon.
Kion fari kun ĉio ĉi
Ĉiuj solvas ĉi tiujn problemojn laŭ sia maniero: ekzemple, vi povas publikigi normalajn vakantaĵojn por rompi la malvirtan cirklon. Vi povas ekscii, kion signifas vortoj kiel DevOps kaj Cloud Native kaj uzi ilin ĝuste kaj al la punkto. Vi povas disvolviĝi en DevOps kaj montri la ĝustajn alirojn per via ekzemplo.
Ni faras konferencon , kiu donas ŝancon profundiĝi en la aferojn, pri kiuj ni ĵus parolis. Estas pluraj grupoj de raportoj por tio:
- Procezoj kaj kulturo;
- Site Reliability Engineering;
- Nubo Indiĝeno;
Kiel elekti kien iri? Estas subtila punkto ĉi tie. Unuflanke, DevOps temas pri interagado, kaj ni vere volas, ke vi ĉeestu prezentojn de malsamaj blokoj. Aliflanke, se vi estas evolumanaĝero, kiu venis al la konferenco por koncentriĝi pri unu specifa tasko, tiam neniu limigas vin - evidente, ĉi tio estos bloko pri procezoj kaj kulturo. Ne forgesu, ke vi havos surbendigojn post la konferenco (post plenigo de la sugesta formularo), do vi povas ĉiam spekti malpli gravajn prezentojn poste.
Evidente, ĉe la konferenco mem oni ne povas iri sur tri vojoj samtempe, do ni organizas la programon tiel, ke ĉiu tempoperiodo havas temojn por ĉiu gusto.
Restas nur kompreni kion fari se vi estas DevOps-inĝeniero! Unue, provu determini, kion vi efektive faras. Kutime ili ŝatas nomi ĉi tiun vorton:
- Programistoj, kiuj laboras pri infrastrukturo. La grupoj de raportoj pri SRE kaj Cloud Native plej taŭgas por vi.
- Sistemadministrantoj. Estas pli komplike ĉi tie. DevOops ne temas pri sistema administrado. Feliĉe ekzistas multaj bonegaj konferencoj, libroj, artikoloj, filmetoj en la interreto ktp pri la temo de sistema administrado. Aliflanke, se vi interesiĝas pri disvolvi vin mem laŭ komprenado de kulturo kaj procezoj, lerni pri nubaj teknologioj kaj detaloj de vivo kun Cloud Native, tiam ni ŝatus vidi vin! Pensu pri ĉi tio: vi faras administradon, kaj tiam kion vi faros? Por eviti subite trovi vin en malagrabla situacio, vi devus lerni nun.
Estas alia eblo: vi persistas kaj daŭre asertas, ke vi estas specife DevOps-inĝeniero kaj nenio alia, kion ajn tio signifas. Tiam ni devas seniluziigi vin, DevOops ne estas konferenco por DevOps-inĝenieroj!
Gliti el en Munkeno
DevOops 2020 Moskvo okazos la 29-30-an de aprilo en Moskvo, biletoj jam haveblas .
Alternative, vi povas ĝis la 8-a de februaro. Bonvolu noti, ke plenigante la formularon, vi devas elekti la celgrupon, kiu plej profitos el via raporto (estas surprizo enterigita ene de la listo).
fonto: www.habr.com