Ne po flasim, natyrisht, për . Nëse nuk hyni në detaje, atëherë më 30 shtator dhe 1 tetor do të mbajmë një konferencë për kombinimin e proceseve të zhvillimit, testimit dhe funksionimit, dhe nëse hyni në detaje, ju lutemi, nën cat.
Brenda qasjes DevOps, të gjitha pjesët e zhvillimit teknologjik të projektit janë të ndërthurura, ndodhin paralelisht dhe ndikojnë njëra-tjetrën. Me rëndësi të veçantë këtu është krijimi i proceseve të automatizuara të zhvillimit që mund të ndryshohen, simulohen dhe testohen në kohë reale. Kjo ju ndihmon t'i përgjigjeni menjëherë ndryshimeve në treg.
Në konferencë duam të tregojmë se si kjo qasje ndikon në zhvillimin e produktit. Si sigurohet besueshmëria dhe përshtatshmëria e sistemit për klientin. Si DevOps po ndryshon strukturën dhe qasjen e një kompanie në organizimin e procesit të saj të punës.
mbrapa skenave
Është e rëndësishme për ne që të dimë jo vetëm se çfarë po bëjnë kompani të ndryshme brenda kornizës së qasjes DevOps, por edhe të kuptojmë pse bëhet e gjithë kjo. Prandaj, ne ftuam jo vetëm ekspertë që t'i bashkohen Komitetit të Programit, por specialistë që shohin diskursin e DevOps nga pozicione të ndryshme:
- inxhinierë të lartë;
- zhvilluesit;
- drejtuesit e ekipit;
- CTO.
Nga njëra anë, kjo krijon vështirësi dhe konflikte kur diskutohen kërkesat për raporte. Nëse një inxhinier është i interesuar të analizojë një aksident të madh, atëherë është më e rëndësishme që një zhvillues të kuptojë se si të krijojë softuer që funksionon në retë dhe infrastruktura. Por duke rënë dakord, ne krijojmë një program që do të jetë i vlefshëm dhe interesant për të gjithë: nga inxhinierët tek CTO.
Qëllimi i konferencës sonë nuk është vetëm të zgjedhë raportet më të zhurmshme, por të paraqesë pamjen e përgjithshme: si funksionon qasja DevOps në praktikë, çfarë lloj rakete mund të hasni kur kaloni në procese të reja. Në të njëjtën kohë, ne ndërtojmë pjesën e përmbajtjes, duke zbritur nga problemi i biznesit në teknologji specifike.
Seksionet e konferencës do të mbeten të njëjta si në .
- Platforma e infrastrukturës.
- Infrastruktura si kod.
- Dorëzimi i vazhdueshëm.
- Komente
- Arkitekturë në DevOps, DevOps për CTO.
- Praktikat e SRE.
- Trajnim dhe menaxhim njohurish.
- Siguria, DevSecOps.
- Transformimi i DevOps.
Thirrje për dokumente: çfarë lloj raportesh po kërkojmë
Ne e ndamë me kusht audiencën e mundshme të konferencës në pesë grupe: inxhinierë, zhvillues, specialistë sigurie, drejtues ekipesh dhe CTO. Secili grup ka motivimin e tij për të ardhur në konferencë. Dhe, nëse shikoni DevOps nga këto pozicione, mund të kuptoni se si ta përqendroni temën tuaj dhe ku ta vendosni theksin.
Për inxhinierët, të cilët po krijojnë një platformë infrastrukturore, është e rëndësishme të kuptohen tendencat ekzistuese, për të kuptuar se cilat teknologji janë tani më të avancuara. Ata do të jenë të interesuar të mësojnë për përvojën e jetës reale në përdorimin e këtyre teknologjive dhe shkëmbimin e mendimeve. Një inxhinier do të jetë i lumtur të dëgjojë një raport që analizon disa aksidente të rënda, dhe ne, nga ana tjetër, do të përpiqemi të zgjedhim dhe korrigjojmë një raport të tillë.
Për zhvilluesit është e rëndësishme të kuptohet një koncept i tillë si aplikacioni vendas i cloud. Domethënë, si të zhvilloni softuer në mënyrë që të funksionojë në retë dhe infrastruktura të ndryshme. Zhvilluesi duhet të marrë vazhdimisht reagime nga softueri. Këtu duam të dëgjojmë raste se si kompanitë e ndërtojnë këtë proces, si të monitorojnë performancën e softuerit dhe si funksionon i gjithë procesi i dorëzimit.
Specialistët e sigurisë kibernetike Është e rëndësishme të kuptoni se si të vendosni procesin e sigurisë në mënyrë që të mos pengojë proceset e zhvillimit dhe ndryshimit brenda kompanisë. Temat rreth kërkesave që DevOps u vendos specialistëve të tillë do të jenë gjithashtu interesante.
Drejtuesit e ekipit duan të dinë, si funksionon procesi i dërgimit të vazhdueshëm në kompani të tjera. Çfarë rruge morën kompanitë për ta arritur këtë, si i ndërtuan proceset e zhvillimit dhe të sigurimit të cilësisë brenda DevOps. Drejtuesit e ekipeve janë gjithashtu të interesuar për Cloud native. Dhe gjithashtu pyetje rreth ndërveprimit brenda ekipit dhe midis ekipeve të zhvillimit dhe inxhinierisë.
Për CTO gjëja më e rëndësishme është të kuptojmë se si t'i lidhim të gjitha këto procese dhe t'i përshtatim ato me nevojat e biznesit. Ai sigurohet që aplikacioni të jetë i besueshëm si për biznesin ashtu edhe për klientin. Dhe këtu ju duhet të kuptoni se cilat teknologji do të funksionojnë për cilat detyra biznesi, si të ndërtoni të gjithë procesin, etj. CTO është gjithashtu përgjegjës për buxhetimin. Për shembull, ai duhet të kuptojë se sa para duhet të shpenzohen për rikualifikimin e specialistëve në mënyrë që ata të mund të punojnë në DevOps.
Nëse keni diçka për të thënë për këto çështje, mos heshtni, . Afati i fundit për Thirrjen për Dokumente është 20 gushti. Sa më herët të regjistroheni, aq më shumë kohë do t'ju duhet për të finalizuar raportin tuaj dhe për t'u përgatitur për prezantimin tuaj. Pra, mos vononi.
Epo, nëse nuk keni nevojë të flisni publikisht, thjesht dhe ejani në 30 shtator dhe 1 tetor për të komunikuar me kolegët. Ne premtojmë se do të jetë interesante dhe frymëzuese.
Si e shohim DevOps
Për të kuptuar saktësisht se çfarë nënkuptojmë me DevOps, unë rekomandoj të lexoni (ose të rilexoni) raportin tim "" Duke ecur nëpër valët e tregut, vura re se si ideja e DevOps po transformohej në kompani me madhësi të ndryshme: nga një startup i vogël në kompani shumëkombëshe. Raporti është ndërtuar mbi një sërë pyetjesh, duke iu përgjigjur atyre mund të kuptoni nëse kompania juaj po shkon drejt DevOps apo nëse ka probleme diku.
DevOps është një sistem kompleks, ai duhet të përfshijë:
- Produkt dixhital.
- Modulet e biznesit që zhvillojnë këtë produkt dixhital.
- Ekipet e produkteve që shkruajnë kodin.
- Praktikat e shpërndarjes së vazhdueshme.
- Platformat si shërbim.
- Infrastruktura si shërbim.
- Infrastruktura si kod.
- Praktika të veçanta për ruajtjen e besueshmërisë, të integruara në DevOps.
- Një praktikë reagimi që i përshkruan të gjitha.
Në fund të raportit ka një diagram që jep një ide të sistemit DevOps në kompani. Kjo do t'ju lejojë të shihni se cilat procese në kompaninë tuaj tashmë janë thjeshtuar dhe cilat janë ende për t'u ndërtuar.
Mund ta shikoni videon e raportit .
Dhe tani do të ketë një bonus: disa video nga RIT++ 2019, të cilat prekin çështjet më të përgjithshme të transformimit të DevOps.
Infrastruktura e kompanisë si produkt
Artyom Naumenko drejton ekipin DevOps në Skyeng dhe kujdeset për zhvillimin e infrastrukturës së kompanisë së tij. Ai tregoi se si infrastruktura ndikon në proceset e biznesit në SkyEng: si të llogaritet ROI për të, cilat metrika duhet të zgjidhen për llogaritjen dhe si të punohet për t'i përmirësuar ato.
Në rrugën drejt mikroshërbimeve
Kompania Nixys ofron mbështetje për projekte të ngarkuara në internet dhe sisteme të shpërndara. Drejtori teknik i saj, Boris Ershov, tregoi se si të përkthenin produktet softuerike, zhvillimi i të cilave filloi 5 vjet më parë (ose edhe më shumë), në një platformë moderne.
Si rregull, projekte të tilla janë një botë e veçantë ku ka qoshe kaq të errëta dhe të lashta të infrastrukturës që inxhinierët aktualë nuk dinë për to. Dhe qasjet ndaj arkitekturës dhe zhvillimit që u zgjodhën dikur janë të vjetruara dhe nuk mund t'i ofrojnë biznesit të njëjtin ritëm zhvillimi dhe lëshimi të versioneve të reja. Si rezultat, çdo lëshim i produktit kthehet në një aventurë të pabesueshme, ku diçka bie vazhdimisht, dhe në vendin më të papritur.
Menaxherët e projekteve të tilla në mënyrë të pashmangshme përballen me nevojën për të transformuar të gjitha proceset teknologjike. Në raportin e tij, Boris tha:
- si të zgjidhni arkitekturën e duhur për projektin dhe të rregulloni infrastrukturën;
- çfarë mjetesh duhet përdorur dhe cilat gracka hasen në rrugën e transformimit;
- çfarë të bëni më pas.
Automatizimi i lëshimeve ose si të dorëzohet shpejt dhe pa dhimbje
Alexander Korotkov është një zhvillues kryesor i sistemit CI/CD në CIAN. Ai foli për mjetet e automatizimit që bënë të mundur përmirësimin e cilësisë dhe zvogëlimin e kohës për dërgimin e kodit në prodhim me 5 herë. Por rezultate të tilla nuk mund të arriheshin vetëm me automatizim, kështu që Aleksandri gjithashtu i kushtoi vëmendje ndryshimeve në proceset e zhvillimit.
Si ju ndihmojnë aksidentet të mësoni?
Alexey Kirpichnikov ka zbatuar DevOps dhe infrastrukturë në SKB Kontur për 5 vjet. Gjatë tre viteve, afërsisht 1000 fakaps me shkallë të ndryshme epike ndodhën në shoqërinë e tij. Midis tyre, për shembull, 36% u shkaktuan nga nxjerrja e një lëshimi me cilësi të ulët në prodhim dhe 14% u shkaktuan nga puna e mirëmbajtjes së harduerit në qendrën e të dhënave.
Një arkiv raportesh (postmortem) që inxhinierët e kompanisë kanë ruajtur për disa vite me radhë, bën të mundur marrjen e një informacioni kaq të saktë për aksidentet. Pas vdekjes është shkruar nga inxhinieri në detyrë, i cili ishte i pari që iu përgjigj sinjalit të urgjencës dhe filloi të rregullonte gjithçka. Pse t'i mundoni inxhinierët që luftojnë natën me fytyrat duke shkruar raporte? Këto të dhëna ju lejojnë të shihni të gjithë pamjen dhe të lëvizni zhvillimin e infrastrukturës në drejtimin e duhur.
Në fjalimin e tij, Alexey tregoi se si të shkruani një postmortem vërtet të dobishëm dhe si të zbatoni praktikën e raporteve të tilla në një kompani të madhe. Nëse ju pëlqejnë historitë se si dikush ka ngacmuar, shikoni videon e performancës.
Ne e kuptojmë se vizioni juaj për DevOps mund të mos përputhet me vizionin tonë. Do të jetë interesante të dini se si e shihni transformimin e DevOps. Ndani përvojën dhe vizionin tuaj për këtë temë në komente.
Çfarë raportesh kemi pranuar tashmë në program?
Këtë javë Komiteti i Programit miratoi 4 raporte: mbi sigurinë, infrastrukturën dhe praktikat e SRE.
Ndoshta tema më e dhimbshme e transformimit të DevOps: si të sigurohemi që djemtë nga departamenti i sigurisë së informacionit të mos shkatërrojnë lidhjet e ndërtuara tashmë midis zhvillimit, funksionimit dhe administrimit. Disa kompani menaxhojnë pa një departament të sigurisë së informacionit. Si të sigurohet siguria e informacionit në këtë rast? Rreth saj Mona Arkhipova nga sudo.su. Nga raporti i saj mësojmë:
- çfarë duhet mbrojtur dhe nga kush;
- cilat janë proceset rutinë të sigurisë;
- si kryqëzohen proceset e TI-së dhe sigurisë së informacionit;
- çfarë është CIS CSC dhe si ta zbatojmë atë;
- si dhe me çfarë treguesish të kryhen kontrolle të rregullta të sigurisë së informacionit.
Raporti tjetër ka të bëjë me zhvillimin e infrastrukturës si kod. Ulni sasinë e rutinës manuale dhe mos e ktheni të gjithë projektin në kaos, a është e mundur kjo? Për këtë pyetje Maxim Kostrikin nga Ixtens. Kompania e tij përdor Terraform për të punuar me infrastrukturën AWS. Mjeti është i përshtatshëm, por pyetja është se si të shmangni krijimin e një blloku të madh kodi kur e përdorni atë. Mirëmbajtja e një trashëgimie të tillë do të bëhet gjithnjë e më e shtrenjtë çdo vit.
Maxim do të tregojë se si funksionojnë modelet e vendosjes së kodit, që synojnë thjeshtimin e automatizimit dhe zhvillimit.
Një tjetër do të dëgjojmë për infrastrukturën nga Vladimir Ryabov nga Playkey. Këtu do të flasim për platformën e infrastrukturës dhe do të mësojmë:
- si të kuptojmë nëse hapësira e ruajtjes po përdoret në mënyrë efektive;
- si disa qindra përdorues mund të marrin 10 TB përmbajtje nëse përdoren vetëm 20 TB hapësirë ruajtëse;
- si t'i kompresoni të dhënat 5 herë dhe t'i ofroni ato përdoruesve në kohë reale;
- si të sinkronizoni të dhënat në fluturim midis disa qendrave të të dhënave;
- si të eliminoni çdo ndikim të përdoruesve mbi njëri-tjetrin kur përdorni një makinë virtuale në mënyrë sekuenciale.
Sekreti i kësaj magjie është teknologjia ZFS për FreeBSD dhe pirunin e tij të freskët ZFS në Linux. Vladimir do të ndajë rastet nga Playkey.
Matvey Kukuy nga Amixr.IO gati me shembuj nga jeta , cfare ndodhi SRE dhe si ndihmon në ndërtimin e sistemeve të besueshme. Amixr.IO kalon incidentet e klientëve përmes backend-it të tij; dhjetëra ekipe në detyrë në mbarë botën kanë trajtuar tashmë 150 mijë raste. Në konferencë, Matvey do të ndajë statistikat dhe njohuritë që kompania e tij ka grumbulluar duke zgjidhur problemet e klientëve dhe duke analizuar dështimet.
Edhe një herë ju bëj thirrje të mos jeni të pangopur dhe të ndani përvojën tuaj si një samurai i DevOps. Shërbejeni për një raport, dhe ju dhe unë do të kemi 2,5 muaj për të përgatitur një fjalim të shkëlqyer. Nëse dëshironi të jeni dëgjues, në buletinin me përditësime të programit dhe mendoni seriozisht për rezervimin e biletave para kohe, sepse ato do të shtrenjtohen më afër datave të konferencës.
Burimi: www.habr.com