Kohet e fundit, këto shpallje kanë mbushur internetin. Pavarësisht nga rroga tërheqëse, nuk mund të mos të shqetësojë se brenda është shkruar një marrëzi e çuditshme. Fillimisht supozohet se "DevOps" dhe "inxhinier" mund të bashkohen ndonjëfarë mënyre në një fjalë, dhe më pas vjen një listë rastësore kërkesash, disa prej të cilave janë qartë të kopjuara nga një njoftim për punë të administratorit të rrjetit.
Në këtë postim duam të flasim pak se si arritëm deri këtu, çfarë është në të vërtetë DevOps dhe çfarë duhet të bëjmë tani me të.
Këto vende pune mund të kritikohen në shumë mënyra, por fakti mbetet fakt: ka shumë dhe kështu është organizuar tregu për momentin. Ne organizuam një konferencë DevOps dhe e deklarojmë hapur: " — nuk është për inxhinierët DevOps". Këtu shumë do t'u duket e çuditshme dhe e pazakontë: pse ndodhin njerëzit që organizojnë një ngjarje krejtësisht tregtare përballë tregut. Tani do ta shpjegojmë gjithçka.
Rreth kulturës dhe proceseve
Le të fillojmë me faktin se DevOps nuk është një disiplinë inxhinierike. E gjithë historia filloi me ndarjen e rolit që historikisht nuk funksionon për cilësinë e produkteve. Kur programuesit programojnë vetëm, por nuk dëshirojnë të dëgjojnë për testimin — softueri mbushet me defekte. Kur administratorët nuk i bëjnë përshtypje se si dhe pse është shkruar softueri — mbështetje shndërrohet në një ferr.
Për shembull, duke përshkruar dallimin midis qasjes së administratorëve dhe qasjes SRE në menaxhimin e shërbimeve . Kërkime interesante janë kryer në kuadër të — është e qartë se zhvilluesit më të mirë në një farë mënyre arrijnë të deplojnë ndryshime të reja në prodhim më shpesh se një herë në orë. Ata gjithashtu e testojnë me duar jo më shumë se 10% (kjo është e dukshme nga ). Si ia arrijnë atyre? "Excel or die" – thotë një nga titujt e raportit. Për diskutimin e detajuar të kësaj statistike në kontekstin e testimeve, mund të referoheni në keynote-in e Baruch Sadogursky në një tjetër konferencë tonë, Heisenbug.
"Kur nuk ka pajtimi midis shokëve,
Punët e tyre nuk do të shkojnë,
Dhe kjo nuk do të prodhojë ndonjë rezultat, vetëm mundim.
Një herë e një kohë, Kacan, Krabi dhe Peshkaqeni…"
Çfarë mendoni, sa pjesë e programuesve web në të vërtetë e kuptojnë se në cilat kushte mundësohen aplikacionet e tyre në prodhim? Sa prej tyre do të shkojnë te administratorët dhe do të përpiqen të kuptojnë se çfarë do të ndodhë në rastin e dështimit të bazës? Dhe sa prej tyre do të shkojnë te testuesit dhe do të kërkojnë të mësojnë si të shkruajnë teste siç duhet? Ata gjithashtu kanë siguri, menaxherë produkti, një mori njerëzish të tjerë.
Ideja kryesore e DevOps është që të përmirësojë bashkëpunimin midis roleve dhe departamenteve. Në radhë të parë, kjo arrihet jo me ndonjë soft të ndërlikuar, por me praktikën e komunikimit. DevOps është për kulturën, praktikën, metodologjinë dhe proceset. Nuk ekziston një profesion inxhinierik që do të përgjigjej për këto pyetje.
Cikli i mbyllur
Nga e mori atëherë disiplina e "inxhinierisë DevOps"? Ne kemi një version! Ideja e DevOps doli të ishte e mirë - aq e mirë sa u bë viktimë e suksesit të saj. Rreth kësaj teme u grumbulluan disa rekruterë të dyshimtë dhe tregtarë njerëzish, të cilët kanë një atmosferë të veçantë.
Imagjinoni: dje ju po bënit shawarma në Himki, dhe sot - ju jeni një njeri i madh, rekruter i njohur. Këtu ka një proces të tërë për të kërkuar dhe selektuar kandidatë, është e komplikuar, duhet ta kuptoni. Le të themi, shefi i departamentit thotë: gjej një specialist për X. Shtojmë fjalën "inxhinier" pas X, dhe puna është e mbyllur. Nevojitet Linux? Atëherë sigurisht që është inxhinier Linux, dëshiron DevOps - inxhinier DevOps. Vendimi nuk përbëhet vetëm nga titulli, por brenda duhet të shkruhet një tekst. Më e lehtë është të shkruani një grup fjalësh kyçe nga Google, sa më shumë fantazi të keni. DevOps përbëhet nga dy fjalë - "Dev" dhe "Ops", pra, duhet të pezullohen fjalët kyçe që lidhen me zhvilluesit dhe administratorët, të gjitha në një grumbull. Kështu lindin vendet e punës për zotërimin e 42 gjuhëve të programimit dhe 20 vjet përdorimi të Kubernetes dhe Swarm njëkohësisht. Një skemë punuese.
Kjo është siç është ngulitur në mendjen e njerëzve, një imazh pa kuptim dhe të pamëshirshëm i një superheroi "DevOps", që do të konfigurojë për të gjithë deploy në Jenkins, dhe do të vihet lumturia. Ah, nëse do të ishte kaq e thjeshtë. "Po ashtu, kështu mund të gjuajmë për sysadmin, mendon HR-i, fjala është moderne, fjalët kyçe janë të njëjta, duhet të kapen."
Kërkesa krijon ofertën, dhe mbi të gjitha këto vende pune absurde, ka pasur një fluks të çmendur të sysadminëve që e kuptuan: mund të bëni të njëjtën gjë si më parë, por të fitoni disa herë më shumë, duke u quajtur "DevOps". Si keni configure serverët përmes SSH me duar njëri pas tjetrit, ashtu do të vazhdoni të konfiguroheni, por tani kjo quhet praktikë DevOps. Është një fenomen i komplikuar, pjesërisht i lidhur me nënvlerësimin e administratorëve klasikë dhe me zhurmën rreth DevOps, por në tërësi - çdo gjë rezultoi siç rezultoi.
Pra, ne kemi kërkesë dhe ofertë. Një rreth që ushqen veten. Këtë po luftojmë (përfshirë, duke krijuar konferencën DevOops).
Pa dyshim, përveç sysadminëve që u riformuluan si "DevOps", ka edhe pjesëmarrës të tjerë - për shembull, SRE profesionistë ose zhvillues të Infrastructure-as-Code.
Çfarë bëjnë njerëzit në DevOps (në të vërtetë)
Pra, dëshironi të avanconi në studimin dhe zbatimin e praktikave DevOps. Por si ta bëni këtë, në çfarë direktioni duhet të shikoni? Sinqerisht, nuk ka kuptim të drejtoheni verbërisht nga fjalët kyçe të njohura.
Nëse ka punë, dikush duhet ta bëjë atë. Ne tashmë kemi zbuluar se nuk janë "inxhinierët DevOps", atëherë kush? Duket se është më e saktë ta formuloni këtë jo në terma të pozitat, por në terma të drejtimeve të veçanta të punës.
Së pari, mund të merremi me zemrën e DevOps - proceset dhe kulturën. Kultura është një çështje që nuk është e lehtë dhe e shpejtë, dhe megjithëse tradicionalisht është përgjegjësi e menaxherëve, në të njëjtën mënyrë, të gjithë përfshihen, nga programuesit deri te administratorët. Disa muaj më parë, Tim Lister :
«Kultura formohet nga vlerat themelore të organizatës. Zakonisht, njerëzit nuk e vërejnë këtë, por ne, duke punuar në konsultim për shumë vite, jemi mësuar ta vërejmë. Hyn në një kompani dhe dosido pas disa minutash fillon të ndiesh se çfarë ndodh. E quajmë këtë «aromë». Ndonjëherë kjo aromë është vërtet e mirë. Ndonjëherë shkakton të vjella. (…) Nuk mund të ndryshosh kulturën përpara se të kuptosh vlerat dhe besimet që qëndrojnë pas veprimeve të caktuara. Vëzhgimi i sjelljes është i lehtë, por të kërkosh besimet është e vështirë. DevOps është pikërisht një shembull i shkëlqyer se si çdo gjë bëhet më e komplikuar dhe më e komplikuar».
Ka gjithashtu njërën pjesë teknike të çështjes, sigurisht. Nëse një kod i ri arrin për testim pas një muaji, por në lançimin e tij del vetëm pas një viti, dhe ta përshpejtosh këtë fizikisht është e pamundur - mund të mos arrish të implementosh praktika të mira. Praktikat e mira mbështeten nga mjetet e mira. Për shembull, duke mbajtur mend idenë e Infrastructure-as-Code, mund të përdorësh çdo gjë, nga AWS CloudFormation dhe Terraform deri te Chef-Ansible-Puppet. E gjitha kjo duhen të dihet dhe të praktikohet, dhe kjo është në të vërtetë një disiplinë inxhinierike. Është e rëndësishme të mos ngatërrosh shkakun me pasojat: fillimisht punoni sipas parimeve SRE dhe vetëm më pas implementoni këto parime në formën e disa zgjidhjeve teknike konkrete. Ndërkohë, SRE është një metodologji shumë komplekse që tregon jo se si të konfigurosh Jenkins, por për pesë parime kryesore:
- Përmirësimi i bashkëpunimit midis roleve dhe departamenteve
- Pranimi i gabimeve si një pjesë e pandashme e punës
- Realizimi gradual i ndryshimeve
- Përdorimi i mjeteve dhe automatizimit të tjera
- Matja e gjithçkaje që mund të matet
Kjo nuk është thjesht një grup pohimesh, por një . Për shembull, në rrugën e pranimit të gabimeve, do të duhet të merresh me rreziqet, të matësh disponueshmërinë dhe mungesën e shërbimeve duke përdorur diçka si SLI () dhe SLO (), të mësosh se si të shkruash postmortemet dhe të bësh që të shkruash ato të mos jetë frikësuese.
Në disiplinën SRE, përdorimi i mjeteve është vetëm një pjesë e suksesit, megjithatë, një pjesë e rëndësishme. Na nevojitet të zhvillojmë vazhdimisht në aspektin teknik, të shikojmë se çfarë po ndodh në botë dhe si mund ta aplikojmë këtë në punën tonë.
Nga ana e sajilja, zgjidhjet Cloud Native kanë filluar të jenë shumë të popullshme. Sipas kuptimit modern të Cloud Native Computing Foundation, teknologjitë Cloud Native lejojnë organizatat të zhvillojnë dhe ekzekutojnë aplikacione të shkallëzueshme në mjedise dinamike moderne, siç janë reja publike, private dhe hibrid. Një shembull i këtij koncepti janë kontejnerët, mesh-at e shërbimit, mikro-shërbimet, infrastruktura e pandryshueshme dhe API-të deklaruese. Të gjitha këto teknika lejojnë sistemet me lidhje të dobët të mbeten elastike, të menaxhueshme dhe të lehta për t'u vëzhguar. Automatizimi i mirë lejon inxhinierët të bëjnë ndryshime të mëdha shpesh dhe me rezultate të parashikueshme, pa e bërë këtë një punë të vështirë. E gjithë kjo mbështetet nga një grumbull mjetesh të njohura, si Docker dhe Kubernetes.
Kjo është një përkufizim mjaft i ndërlikuar dhe i gjerë, i njëkohshëm me faktin se fusha është gjithashtu mjaft e ndërlikuar. Nga njëra anë, thuhet se ndryshimet e reja në këtë sistem duhet të shtohen mjaft lehtë. Nga ana tjetër, për të kuptuar se si të krijoni një mjedis të kontejnerizuar, ku shërbimet me lidhje të dobët jetojnë në një infrastrukturë të definuar nga software dhe dërgohen atje përmes një CI/CD të vazhdueshëm, si dhe të ndërtoni praktikat DevOps rreth kësaj, është e nevojshme të keni përvojë të madhe.
Çfarë duhet të bëjmë me gjithë këtë
Të gjithë i zgjidhin këto probleme në mënyrat e tyre: për shembull, mund të publikoni oferta pune të pranuara për të ndalur ciklin e mbyllur. Mund të kuptoni se çfarë do të thonë fjalët si DevOps dhe Cloud Native dhe t'i përdorni ato saktësisht dhe me domethënie. Mund të zhvilloheni në DevOps dhe të tregoni qasjet e duhura me anë të shembujve tuaj.
Ne po organizojmë një konferencë , e cila ofron mundësinë për të kuptuar më thellë çështjet që sapo diskutuam. Për këtë, ka disa grupe referimesh:
- Proceset dhe kultura;
- Inxhinieria e Besueshmërisë së Site-ve;
- Cloud Native;
Si të zgjidhni se ku të shkoni? Ka një nuancë të hollë. Nga njëra anë, DevOps është për ndërveprimin, dhe ne me të vërtetë shpresojmë që ju të shkoni në referime nga blloqe të ndryshme. Nga ana tjetër, nëse jeni udhëheqës i zhvillimit dhe keni ardhur në konferencë për t'u përqëndruar në një detyrë të caktuar, askush nuk ju kufizon — është e qartë se do të jetë blloku për proceset dhe kulturën. Mos harroni se, pas konferencës, do të keni regjistrime (pas plotësimit të formulës së feedback-ut), kështu që gjithmonë mund të shikoni referimet më pak të rëndësishme më vonë.
Kjo është e qartë, në konferencë nuk mund të shkoni në tri rrugë njëkohësisht, prandaj e formojmë programin në këtë mënyrë që në çdo hapësirë kohore të ketë tema për çdo shije.
Është e mbetur vetëm të kuptoni se çfarë të bëni, nëse jeni një inxhinier DevOps! Së pari, provoni të përcaktoni se çfarë realisht bëni. Zakonisht, ky term përdoret për të përshkruar:
- Zhvilluesit që merren me infrastrukturën. Grupet e sesioneve për SRE dhe Cloud Native janë më tërheqësit për ju.
- Administruesit e sistemeve. Këtu bëhet më e komplikuar. DevOops - nuk është për administrimin e sistemeve. Fatmirësisht, ka shumë konferenca, libra, artikuj, video etj. që flasin për administrimin e sistemeve. Nga ana tjetër, nëse ju intereson të zhvilloni njohuritë tuaja në kulturën dhe proceset, me studimin e teknologjive cloud dhe detajeve të jetës me Cloud Native, ne do të jemi të lumtur t'ju mirëpresim! Mendoni për këtë: ju jeni në administrimin e sistemeve, por çfarë do të bëni më pas? Për të mos u gjetur në një situatë të pakëndshme, është mirë të filloni të mësoni tashmë.
Ka edhe një mundësi tjetër: ju insistoni dhe vazhdoni të pohoni se jeni pikërisht një inxhinier DevOps dhe ashtu siç është, çfarëdo që të nënkuptojë kjo. Atëherë me keqardhje ju informojmë, DevOops - është një konferencë që nuk është për inxhinierët DevOps!
Slide nga në Mynih
DevOops 2020 Moskë do të zhvillohet nga 29-30 prill në Moskë, biletat tashmë mund të blihen .
Për më tepër, ju mund të deri më 8 shkurt. Ju lutemi vini re se kur plotësoni formularin duhet të zgjidhni audiencën e synuar, që përfiton më shumë nga prezantimi juaj (në brendësi të listës është një surprizë).
Burimi: habr.com
