Konferenca e tretë u mbajt më 7 dhjetor , organizuar nga komuniteti Moskë DevOps me mbështetjen e Mail.ru Cloud Solutions. Përveç prezantimeve nga praktikuesit kryesorë të DevOps, pjesëmarrësit mund të marrin pjesë në biseda të shkurtra motivuese Lightning, seminare dhe të komunikojnë në hapësira të hapura.
Ne mblodhëm njohuri të rëndësishme nga gjashtë fjalime dhe zhvilluam intervista me disa folës për të zbuluar se çfarë kishte mbetur pas raporteve.
Brenda:
- Baruch Sadogursky, JFrog: "Lëreni softuerin të rrjedhë nga shitësi tek përdoruesi si lëng"
- Pavel Selivanov, Southbridge: "Dev dhe Ops kanë një detyrë të përbashkët - të bëjnë një produkt që funksionon"
- Vladimir Utratenko, Grupi i Shitje me Pakicë X5: "DevOps në Ndërmarrje është zhvillim pa dhimbje dhe zjarre"
- Sergey Puzyrev, Facebook: "Inxhinieri i prodhimit kujdeset për shërbimin në tërësi: në mënyrë që përdoruesit dhe zhvilluesit të kalojnë mirë"
- Mikhail Chinkov, AMBOSS: "Një departament nuk mund të ndjekë rrugën DevOps, e gjithë kompania duhet ta ndjekë atë"
- Entuziastët e DevOps të Rosbank: "1000 ditë për të zbatuar DevOps në një ndërmarrje të përgjakshme"
1. Baruch Sadogursky, JFrog: "Lëreni softuerin të rrjedhë nga shitësi te përdoruesi si lëng"
Dështimet e përditësimit të softuerit ndodhin çdo orë dhe për të gjithë. Këtu është vetëm një histori horror nga fjalimi: Knight Capital humbi 440 milionë dollarë në një orë pas një përditësimi të pasuksesshëm.
Baruch foli për modelet DevOps të përditësimeve të vazhdueshme që do të ndihmojnë në shmangien e dështimeve dhe urrejtjes së përdoruesve:
Rikthim lokal — Mbani versionin e mëparshëm të softuerit në pajisjen tuaj për t'u rikthyer nëse ndodh diçka. Kjo do t'ju mbrojë nëse gjërat përkeqësohen aq shumë sa nuk mund të dërgoni një copë toke në ajër.
Përditësimet në ajër - më mirë i vazhdueshëm. Përndryshe, do të jetë si me zhvilluesit Jaguar: për shkak të një defekti në sistemin e frenimit, i cili nuk mund të përditësohej në ajër, makinat duhej të tërhiqeshin nga shitja. Ishte e dhimbshme dhe e shtrenjtë.
Përditësime të vazhdueshme — përditësoni vazhdimisht softuerin sapo të jetë gati një veçori e re. Me përditësime të rralla, veçoritë grupohen së bashku; një përditësim kritik mund të presë për ato jo kritike. Ashtu si në Tesla, një përditësim që supozohej të rregullonte frenimin e rastësishëm ishte duke pritur për një përditësim të lojës së shahut.
Vendosja e automatizuar - Zëvendësoni njerëzit me makina, pasi njerëzit janë të keq në kryerjen e veprimeve rutinë.
Përditësimet e shpeshta - ju ndihmon të zhvilloni një zakon dhe të largoni frikën. Përditësimet e rralla kthehen në ngjarje urgjente.
Njohja e gjendjes së pajisjes — testoni përditësimet, jo instalimin nga e para. Kjo është e rëndësishme sepse përditësimet mund të sillen ndryshe në varësi të gjendjes së pajisjes.
Liron kanarina — shpërndani përditësimet për një numër të vogël përdoruesish dhe vëzhgoni. Kjo zvogëlon dëmin nëse diçka shkon keq.
Përditësimet pa padisponueshmëri — Lërini klientët të vërejnë vetëm veçori të reja dhe të mos mbeten pa shërbim për disa javë, ndërkohë që bëni një përditësim.
Ne folëm me Baruch Sadogursky se si ndryshon pamja në DevOps në IT ruse dhe perëndimore, nëse Cloud së shpejti do të bëjë gjithçka për ne dhe nëse të gjitha shërbimet e softuerit do të rrëshqasin në skemën aaS - shikoni intervistën:
2. Pavel Selivanov, Southbridge: "Dev dhe Ops kanë një detyrë të përbashkët - të bëjnë një produkt që funksionon"
Zbatimi i Kubernetes nuk do të ndihmojë në arritjen e DevOps, dhe përkundrazi, mund të prishë gjithçka. Pavel shpjegoi pse teknologjia (madje edhe më interesante) nuk mund t'i zgjidhë të gjitha problemet tuaja:
Kompleksiteti i projektit ka kaluar përtej kodit. Më parë, kishte një aplikim kompleks: ndërveprim brenda projektit dhe zhvillim kompleks, por një strukturë e thjeshtë - administratori e vendosi atë, gjithçka funksionon. Ne kaluam në mikroshërbime: çdo shërbim është një aplikacion i thjeshtë, komunikim duke përdorur protokolle standarde dhe zhvillim të shpejtë, por struktura e projektit është bërë më komplekse. Kompleksiteti i një projekti me një arkitekturë mikroservice nuk është zhdukur - ai ka kaluar përtej kodit. Tani inxhinieri DevOps është përgjegjës për të.
Zhvilluesit nuk duan ndryshime pas zbatimit të DevOps. Si rezultat, rrjedha e punës me Kubernetes vazhdon të duket si hedhja e detyrave nga Dev në Ops mbi një mur, por jo metaforike - Git bëhet një mur i tillë. Zhvilluesi vendos kodin atje dhe funksionon si më parë, dhe administratorët kanë Kubernetes, CI/CD dhe gjithçka tjetër.
Sidoqoftë, zhvilluesit duhet të pranojnë ndryshimet. Situata kur zhvilluesit nuk e dinë se çfarë po bëjnë administratorët dhe administratorët nuk e dinë se çfarë po ndodh me zhvilluesit, krijon probleme.
Nëse asgjë nuk ka ndryshuar për zhvilluesit, ata nuk e kuptojnë se funksionimi i aplikacionit është përgjegjësia e tyre - truket e ndryshme teknike nuk do të funksionojnë.
Me ardhjen e DevOps dhe Kubernetes, shumë do të ndryshojnë në zhvillim. Devs duhet të jenë kompetent në Ops dhe anasjelltas. Këta specialistë kanë aftësitë e tyre specifike, por duhet të jenë të vetëdijshëm për punën e njëri-tjetrit. Dev dhe Ops duhet të jenë miq përpara se të zbatojnë Kubernetes, përndryshe do të thyeni atë që keni.
Pavel Selivanov foli për atë që do të ndodhë me Kubernetes në 5 vjet dhe se çfarë një startup modern duhet të ndërtojë një grumbull teknologjie - shikoni intervistën:
3. Vladimir Utratenko, Grupi i shitjeve me pakicë X5: "DevOps në Ndërmarrje është zhvillim pa dhimbje dhe zjarre"
Kompanitë vijnë në transformimin e DevOps kur kuptojnë se zhvillimi është shumë i ngadaltë dhe nuk i plotëson realitetet, ata kanë një dëshirë për t'u zhvilluar më mirë dhe për të dalë më shpejt.
Vladimir shpjegoi se si ndodh kjo dhe cila është kapja:
- Së pari, kompanitë punësojnë një inxhinier DevOps. Ky është një Administrator i Lartë i Sistemit, ai është i përfshirë në vendosjen e një lëshimi në prodhim, standardizimin e mjedisit të zhvillimit, vendosjen e infrastrukturës, zbulimin dhe rregullimin e problemeve të ndryshme, automatizimin e proceseve dhe detyra të tjera teknike.
- Atëherë një inxhinier DevOps nuk është më i mjaftueshëm dhe kompania punëson një ekip DevOps. Kjo është një qendër kompetencash që organizon përpjekjet e inxhinierëve të ndryshëm dhe i lejon ata të përqendrohen në një drejtim.
- Në fakt, inxhinierët e DevOps dhe ekipet e DevOps janë anti-modele të transformimit të DevOps. Meqenëse DevOps ka të bëjë me praktikat dhe kulturën, përveç kësaj, ka zbatime të DevOps në kompanitë e teknologjisë (SRE, Inxhinieria e Prodhimit).
Çfarë duhet bërë? Punësoni një ekip të përkohshëm DevOps që do të ndihmojë në zbatimin e transformimit të DevOps, kryerjen e praktikave, kultivimin e një kulture zhvillimi dhe një kulture teknologjike.
Kur një biznes hyn në lojë dhe investon në DevOps, disa skenarë janë të mundshëm: gjithçka do të shembet në nisje; do të mbetet si SRE/Inxhinieri e Prodhimit ose Opsione të Embedded; do të kalojë në BizOps, kur proceset bazohen në matjet e biznesit.
Vladimir Utratenko na tregoi se sa "të përgjakshëm" janë DevOps në një ndërmarrje dhe si zbatohen praktikat brenda shitjeve të mëdha me pakicë - shikoni intervistën:
4. Sergey Puzyrev, Facebook: "Inxhinieri i prodhimit kujdeset për shërbimin në tërësi: në mënyrë që përdoruesit dhe zhvilluesit të kalojnë mirë"
Facebook është një kompani e madhe, me një numër të madh komponentësh, serverësh, njerëzish dhe qendrash të dhënash. Pavarësisht nga madhësia e tij e madhe, ai është shumë i shpejtë - zhvilluesit mund të nxjerrin shërbimet shumë herë në ditë. Gjithashtu, Facebook po rritet me shpejtësi, dhe nuk është vetëm numri i përdoruesve dhe serverëve që po rritet, por edhe numri i zhvilluesve, gjë që i bën proceset më komplekse.
Sergey tregoi se çfarë bën një inxhinier prodhimi në Facebook:
- Një Inxhinier Prodhimi kodon shumë, ai duhet të ketë njohuri të sistemit: sistemet operative, sistemet e skedarëve, bazat e të dhënave, rrjetet dhe të ngjashme. Duhet të ketë përvojë pune me sisteme të shpërndara dhe Inxhinieri të Besueshmërisë, domethënë të mbështesë besueshmërinë e produktit. Ai duhet të jetë në thirrje, domethënë i disponueshëm për t'u telefonuar në çdo kohë.
- Inxhinieri i Prodhimit ndryshon nga Inxhinieri Softuerësh për të pasur aftësi të avancuara në funksionim, por, në fakt, është një nënlloj i Inxhinierit Softuerësh. Inxhinierët e Softuerit kodojnë më shumë; ata mund të kenë aftësi shtesë që lidhen, për shembull, me përpunimin e të dhënave. Në Facebook, specialistë të tillë duhet të jenë edhe në gatishmëri, gjë që për shumëkënd vjen si një surprizë e pakëndshme.
- Piramida e nevojave të një Inxhinieri Prodhimi në një kompani fillon me monitorimin e serverëve dhe ciklit të jetës së tyre, domethënë marrjen e pajisjeve të reja, vendosjen e tij, vënien në funksion të tij. Niveli tjetër është i njëjtë në nivelin e shërbimit: shërbimet e monitorimit dhe cikli i tyre jetësor. Pastaj vjen shkallëzimi pa probleme dhe monitorimi i avancuar. Ata kalojnë në shkallëzimin automatik pasi të jetë automatizuar cikli i jetës së shërbimit. Dhe në fund, është e nevojshme të bëhet akordimi në mënyrë që shkallëzimi të jetë efektiv dhe kompania të kursejë para dhe burime.
5. Mikhail Chinkov, AMBOSS: "Një departament nuk mund të ndjekë rrugën DevOps, e gjithë kompania duhet ta ndjekë atë"
Mikhail beson se DevOps është një zhvillim i vazhdueshëm. Ju nuk mund të prezantoni disa mjete dhe të ndaleni atje. Cilat probleme i pengojnë kompanitë të bëhen DevOps dhe si të zbatojnë praktikat?
Dallimi në të kuptuarit e DevOps. Devosi kanonik, siç e shohin ungjilltarët, mbështetet në 5 shtylla:
- kultura - fokusi te njerëzit dhe bashkëpunimi;
- automatizimi - delegimi i rutinës në rrjedhën e punës;
- ligët - theksi në dhënien e vlerës për përdoruesit;
- shkëmbim - shkëmbim i vazhdueshëm i njohurive;
- metrikat dhe marrjen e reagimeve duke i përdorur ato.
Kompanitë zakonisht fokusohen vetëm në automatizimin dhe dhënien e vlerës për përdoruesit. Por kultura, ndarja e njohurive dhe metrikat e DevOps për të gjurmuar zhvillimin zbehen në sfond.
Sfidat e standardizimit të DevOps. Qëllimet e produktit janë të ndryshme për të gjitha kompanitë dhe nuk mund të standardizohen. Gjendja e DevOps në një kompani varet nga vetë kompania, por shumë nuk e kuptojnë këtë dhe besojnë se mjafton të punësosh një inxhinier DevOps.
Pse nuk jemi ende DevOps? Ka dy probleme kryesore. Në Enterprise ka një zhvillim të ngadaltë të organizatës, vështirësi me ndryshimin e vektorit në mendjet e mijëra punonjësve. Në startup-et, ka mungesë të burimeve të njohurive dhe problem me ndarjen e burimeve për transformim.
Fazat e zhvillimit të DevOps në një kompani:
- e para është infrastruktura në cloud, por askush nuk e di se si funksionon përveç një ose dy administratorëve;
- së dyti, infrastruktura është transparente dhe e kuptueshme për të gjithë inxhinierët, por proceset nuk janë të thjeshta;
- e treta - inxhinierët nisin dhe riparojnë në mënyrë të pavarur shërbimet e drejtpërdrejta;
- së katërti - inxhinierët do të kontribuojnë opsionalisht në infrastrukturën bazë, kodin transparent në cloud, vendosjen me buton.
Skema ideale është që të gjithë të kenë të njëjtën akses në infrastrukturë, të gjithë inxhinierët të kenë akses në produktin dhe të kuptojnë se çfarë po bëjnë.
Duke mbyllur të gjitha gestaltet kulturore dhe teknike, transformimi i kompanisë DevOps do të marrë parasysh reagimet nga matjet e biznesit dhe platformës.
6. Entuziastët e DevOps të Rosbank: "1000 ditë për të zbatuar DevOps në një ndërmarrje të përgjakshme"
Yuri Bulich, Dina Maltseva, Evgeny Pankov nga Rosbank treguan se si erdhën në DevOps në tre vjet. Kishte dy qëllime: zgjidhjen e problemeve specifike në ekipe specifike dhe zbatimin e mjeteve të centralizuara.
Këtu janë rezultatet e arritura:
Rezultatet për ekipet e produkteve: montim 30 herë më i shpejtë, instalim 6 herë më i shpejtë, deri në 30% kursime në ciklin e plotë. Tani kemi mundësinë të shtypim një buton për të shkuar te produktiviteti
Rezultatet për komandat e platformës: Montim dhe instalim 10 herë më i shpejtë, 87% rritje e numrit të instalimeve, 46% mbulim autotest. Ekipi i integrimit nuk është më një pengesë
Pra, si të zbatoni praktikat DevOps në një ndërmarrje të përgjakshme?
Fillimisht zbatoni një projekt pilot: Zgjidhni ekipet, vendosni se si të zbatoni arkitekturën dhe zgjidhni mjetet. Zgjodhëm mjete me licencë të hapur, me instalim në bankë dhe ekspertizë në punën me to. Rosbank vendosi njëkohësisht një re private së bashku me platformën DevOps, dhe kjo ndihmoi në fillim. Në re, ishte e mundur të merreshin burimet e nevojshme me prekjen e një butoni në 15 minuta; më parë, një proces i tillë mund të zgjaste një javë.
Në banka dhe ndërmarrje të tjera, është e nevojshme të përpunohen paraprakisht kufizimet me ekipin e sigurisë së informacionit dhe të gjendet një zgjidhje që do të lejojë zbatimin e ndryshimeve.
Pas pilotimit, një zgjidhje e suksesshme duhet të rritet.
- Është e rëndësishme të "drejtojmë" tubacionin sa më shumë që të jetë e mundur, duke eliminuar lidhjet e panevojshme prej tij, duke theksuar ofruesit e vlerës dhe duke hequr komponentët e mbetur. Ndërmjetësuesit janë antimodele. Për shembull, në Rosbank, një numër ekipesh nuk zhvilluan zhvillim të brendshëm, duke lënë vetëm zhvillimin e jashtëm. Kjo çoi në shfaqjen e një ekipi të dedikuar DevOps, i cili siguroi transferimin e kodit nga zhvilluesit e jashtëm tek ata të brendshëm. Problemi u zgjidh duke integruar zhvillimin e jashtëm në CI/CD, në mënyrë që ata jo vetëm ta transferonin kodin nga vetja në bankë, por edhe të ishin përgjegjës për suksesin e tij.
- Modeli i pjekurisë përfshinte elementë të praktikave të DevOps, mjete të listuara dhe mori parasysh veçoritë e punës me furnitorë të jashtëm - në të ardhmen, kjo ndihmoi në uljen e shpejtë të numrit të detyrave të mbetura gjatë zbatimit të tyre në ekipe të reja.
- Ne kemi nevojë për qeverisje në formën e kontrollit të butë dhe rekomandimeve. Një manual DevOps që funksionon mirë është një grup karakteristikash organizative dhe instrumentale që i ndihmojnë ekipet të përdorin saktë platformën.
- Menjëherë duhet t'i kushtoni vëmendje kulturës, atëherë shumë ndryshime do të ndodhin më shpejt dhe më lehtë. Rriteni komunitetin tuaj të brendshëm, zhvilloni takime, seminare teknike, trajnime dhe aktivitete argëtuese. Kjo jep fryte: njerëzit ndajnë praktikat, shohin kush bëri çfarë, dinë se ku të drejtohen, ka zhurmë dhe konkurrencë të shëndetshme brenda kompanisë.
- Nuk ka kuptim të punosh me ata që nuk janë të përfshirë në proces, me ekipe që nuk janë pjekur; është më mirë të investosh në ekipe të interesuara dhe njerëz besnikë.
- Zgjidhja e zgjedhur duhet të jetë e përshtatshme për ata inxhinierë që e përdorin atë.
- Zhvillimi i jashtëm nuk është bllokues; praktikat mund të zbatohen gjithashtu atje, gjëja kryesore është që vetë ekipi të ketë dëshirën.
Pak më shumë përfitim
Lista e librave që ia vlen të lexohen për ata në DevOps, nga Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Vullneti dhe vetëkontrolli".
- Daniel Kahneman "Të menduarit, shpejt dhe ngadalë".
- Barbara Oakley "Një mendje për numrat".
- Maxim Dorofeev "Teknikat Jedi".
- Viktor Frankl "Kërkimi i njeriut për kuptimin".
Qëndroni të sintonizuar
Ne e duam gjithashtu DevOps. Ndiqni njoftimet e serialeve dhe @Kubernetes, si dhe ngjarje të tjera të Mail.ru Cloud Solutions, në kanalin tonë Telegram:
Burimi: www.habr.com