Govorimo seveda o . Če ne greste v podrobnosti, potem bomo 30. septembra in 1. oktobra organizirali konferenco o združevanju procesov razvoja, testiranja in delovanja, če pa greste v podrobnosti, prosim pod kat.
Znotraj pristopa DevOps se vsi deli tehnološkega razvoja projekta prepletajo, potekajo vzporedno in vplivajo drug na drugega. Pri tem je še posebej pomembna izdelava avtomatiziranih razvojnih procesov, ki jih je mogoče spreminjati, simulirati in testirati v realnem času. To vam pomaga, da se takoj odzovete na spremembe na trgu.
Na konferenci želimo pokazati, kako ta pristop vpliva na razvoj izdelkov. Kako je zagotovljena zanesljivost in prilagodljivost sistema naročniku. Kako DevOps spreminja strukturo in pristop podjetja k organizaciji delovnega procesa.
v zakulisju
Za nas je pomembno, da vemo ne samo, kaj različna podjetja počnejo v okviru pristopa DevOps, ampak tudi, da razumemo, zakaj je vse to namenjeno. Zato v programski odbor nismo povabili le strokovnjakov, temveč strokovnjake, ki na diskurz DevOps gledajo z različnih pozicij:
- višji inženirji;
- razvijalci;
- vodje ekip;
- CTO.
Po eni strani to ustvarja težave in konflikte pri razpravljanju o zahtevah za poročila. Če inženirja zanima analiza večje nesreče, je bolj pomembno, da razvijalec razume, kako ustvariti programsko opremo, ki deluje v oblakih in infrastrukturah. A z dogovorom ustvarimo program, ki bo dragocen in zanimiv vsem: od inženirjev do CTO.
Cilj naše konference ni samo izbrati najbolj hype poročila, ampak predstaviti celotno sliko: kako pristop DevOps deluje v praksi, na kakšne rake lahko naletite pri prehodu na nove procese. Hkrati pa gradimo vsebinski del, ki se spušča od poslovnega problema do specifičnih tehnologij.
Konferenčni sklopi bodo ostali enaki kot v .
- Infrastrukturna platforma.
- Infrastruktura kot koda.
- Neprekinjena dostava.
- Povratne informacije.
- Arhitektura v DevOps, DevOps za CTO.
- prakse SRE.
- Usposabljanje in upravljanje znanja.
- Varnost, DevSecOps.
- Preoblikovanje DevOps.
Razpis za prijavo: kakšna poročila iščemo
Potencialno občinstvo konference smo pogojno razdelili na pet skupin: inženirji, razvijalci, varnostni strokovnjaki, vodje ekip in tehnični direktor. Vsaka skupina ima svojo motivacijo za prihod na konferenco. In če na DevOps pogledate s teh položajev, lahko razumete, kako osredotočiti svojo temo in kje dati poudarek.
Za inženirje, ki ustvarjajo infrastrukturno platformo, je pomembno razumeti obstoječe trende, razumeti, katere tehnologije so zdaj najnaprednejše. Z zanimanjem bodo spoznali resnične izkušnje pri uporabi teh tehnologij in izmenjali mnenja. Inženir bo z veseljem prisluhnil poročilu, ki analizira kakšno hudo nesrečo, mi pa bomo poskušali izbrati in izpiliti takšno poročilo.
Za razvijalce pomembno je razumeti tak koncept kot izvorna aplikacija v oblaku. Se pravi, kako razviti programsko opremo, da bo delovala v oblakih in različnih infrastrukturah. Razvijalec mora nenehno prejemati povratne informacije od programske opreme. Tukaj želimo slišati primere o tem, kako podjetja gradijo ta proces, kako spremljati delovanje programske opreme in kako deluje celoten proces dostave.
Strokovnjaki za kibernetsko varnost Pomembno je razumeti, kako varnostni proces vzpostaviti tako, da ne zavira razvojnih procesov in procesov sprememb v podjetju. Zanimive bodo tudi teme o zahtevah, ki jih DevOps postavlja pred tovrstne strokovnjake.
Vodje ekip želijo vedeti, kako poteka neprekinjen proces dostave v drugih podjetjih. Kakšno pot so ubrala podjetja, da so to dosegla, kako so zgradila procese razvoja in zagotavljanja kakovosti znotraj DevOps. Vodje skupin se zanimajo tudi za Cloud Native. In tudi vprašanja o interakciji znotraj ekipe ter med razvojnimi in inženirskimi ekipami.
Za CTO najpomembneje pa je ugotoviti, kako vse te procese povezati in prilagoditi poslovnim potrebam. Skrbi, da je aplikacija zanesljiva tako za podjetje kot za stranko. In tukaj morate razumeti, katere tehnologije bodo delovale za katere poslovne naloge, kako zgraditi celoten proces itd. CTO je odgovoren tudi za proračun. Na primer, razumeti mora, koliko denarja je treba porabiti za preusposabljanje strokovnjakov, da lahko delajo v DevOps.
Če imate kaj povedati o teh zadevah, ne ostanite tiho, . Rok za oddajo razpisa je 20. avgust. Prej ko se registrirate, več časa boste imeli za dokončanje poročila in pripravo na predstavitev. Torej, ne odlašajte.
No, če nimate potrebe javno govoriti, samo in pridite 30. septembra in 1. oktobra, da komunicirate s kolegi. Obljubljamo, da bo zanimivo in navdihujoče.
Kako vidimo DevOps
Da bi natančno razumeli, kaj mislimo z DevOps, priporočam branje (ali ponovno branje) mojega poročila "" Ko sem se sprehajal po valovih trga, sem opazoval, kako se je ideja DevOps preoblikovala v podjetjih različnih velikosti: od majhnega startupa do multinacionalnih podjetij. Poročilo je zgrajeno na vrsti vprašanj, z odgovori nanje lahko razumete, ali se vaše podjetje usmerja v DevOps ali pa so nekje težave.
DevOps je kompleksen sistem, ki mora vključevati:
- Digitalni izdelek.
- Poslovni moduli, ki razvijajo ta digitalni izdelek.
- Produktne ekipe, ki pišejo kodo.
- Prakse neprekinjene dostave.
- Platforme kot storitev.
- Infrastruktura kot storitev.
- Infrastruktura kot koda.
- Ločene prakse za ohranjanje zanesljivosti, vgrajene v DevOps.
- Praksa povratnih informacij, ki opisuje vse.
Na koncu poročila je diagram, ki daje predstavo o sistemu DevOps v podjetju. Omogočil vam bo, da vidite, kateri procesi v vašem podjetju so že bili poenostavljeni in katere je treba še zgraditi.
Posnetek poročila si lahko ogledate .
In zdaj bo bonus: več videoposnetkov z RIT++ 2019, ki se dotikajo najsplošnejših vprašanj transformacije DevOps.
Infrastruktura podjetja kot produkt
Artyom Naumenko vodi ekipo DevOps pri Skyeng in skrbi za razvoj infrastrukture svojega podjetja. Povedal je, kako infrastruktura vpliva na poslovne procese v SkyEng: kako izračunati ROI zanjo, katere metrike je treba izbrati za izračun in kako jih izboljšati.
Na poti do mikrostoritev
Podjetje Nixys nudi podporo za obremenjene spletne projekte in porazdeljene sisteme. Njegov tehnični direktor Boris Ershov je povedal, kako prevesti programske izdelke, katerih razvoj se je začel pred 5 leti (ali celo več), na sodobno platformo.
Praviloma so takšni projekti poseben svet, kjer obstajajo tako temni in stari koti infrastrukture, da sedanji inženirji zanje ne vedo. Nekoč izbrani pristopi k arhitekturi in razvoju so zastareli in podjetju ne morejo zagotoviti enakega tempa razvoja in izdajanja novih različic. Posledično se vsaka izdaja izdelka spremeni v neverjetno pustolovščino, kjer nenehno nekaj odpade in na najbolj nepričakovanem mestu.
Vodje takih projektov se neizogibno soočajo s potrebo po preoblikovanju vseh tehnoloških procesov. Boris je v svojem poročilu povedal:
- kako izbrati pravo arhitekturo za projekt in urediti infrastrukturo;
- katera orodja uporabiti in na katere pasti naletimo na poti preobrazbe;
- kaj storiti naprej.
Avtomatizacija odpustov ali kako do hitre in neboleče dostave
Alexander Korotkov je vodilni razvijalec sistema CI/CD pri CIAN. Govoril je o orodjih za avtomatizacijo, ki so omogočila izboljšanje kakovosti in skrajšanje časa za dostavo kode v produkcijo za 5-krat. A takšnih rezultatov zgolj z avtomatizacijo ni bilo mogoče doseči, zato je Alexander pozoren tudi na spremembe v razvojnih procesih.
Kako vam nesreče pomagajo pri učenju?
Alexey Kirpichnikov že 5 let implementira DevOps in infrastrukturo v SKB Kontur. V njegovem podjetju se je v treh letih zgodilo približno 1000 fakapov različnih stopenj epičnosti. Med njimi jih je na primer 36 % povzročilo uvajanje nizkokakovostne izdaje v proizvodnjo, 14 % pa vzdrževanje strojne opreme v podatkovnem centru.
Tako točne podatke o nesrečah omogoča arhiv poročil (posmrtnih ostankov), ki jih inženirji podjetja vodijo že več let zapored. Obdukcijo piše dežurni inženir, ki se je prvi odzval na signal za nujno pomoč in začel vse popravljati. Zakaj bi inženirje, ki se ponoči borijo s facami, mučili s pisanjem poročil? Ti podatki vam omogočajo, da vidite celotno sliko in premaknete razvoj infrastrukture v pravo smer.
Alexey je v svojem govoru povedal, kako napisati resnično uporabno obsmrtno poročilo in kako izvajati prakso takšnih poročil v velikem podjetju. Če imate radi zgodbe o tem, kako je kdo zajebal, si oglejte video nastopa.
Zavedamo se, da se vaša vizija DevOps morda ne ujema z našo. Zanimivo bo vedeti, kako vidite transformacijo DevOps. Delite svoje izkušnje in vizijo te teme v komentarjih.
Katera poročila smo že sprejeli v program?
Ta teden je programski odbor sprejel 4 poročila: o varnosti, infrastrukturi in praksah SRE.
Morda najbolj boleča tema transformacije DevOps: kako poskrbeti, da fantje iz oddelka za informacijsko varnost ne porušijo že zgrajenih povezav med razvojem, delovanjem in administracijo. Nekatera podjetja se obnesejo brez oddelka za informacijsko varnost. Kako v tem primeru zagotoviti informacijsko varnost? O tem Mona Arkhipova iz sudo.su. Iz njenega poročila izvemo:
- kaj je treba varovati in pred kom;
- kakšni so rutinski varnostni procesi;
- kako se križajo procesi IT in informacijske varnosti;
- kaj je CIS CSC in kako ga implementirati;
- kako in po katerih indikatorjih izvajati redne preglede informacijske varnosti.
Naslednje poročilo se nanaša na razvoj infrastrukture kot kode. Zmanjšajte količino ročne rutine in ne spremenite celotnega projekta v kaos, je to mogoče? Na to vprašanje Maxim Kostrikin iz Ixtensa. Njegovo podjetje uporablja Terraform za delo z infrastrukturo AWS. Orodje je priročno, a vprašanje je, kako se pri njegovi uporabi izogniti ustvarjanju ogromnega bloka kode. Vzdrževanje takšne zapuščine bo vsako leto dražje.
Maxim bo pokazal, kako delujejo vzorci postavitve kode, namenjeni poenostavitvi avtomatizacije in razvoja.
drugega o infrastrukturi bomo slišali od Vladimir Ryabov iz Playkeya. Tukaj bomo govorili o infrastrukturni platformi in se naučili:
- kako razumeti, ali je prostor za shranjevanje učinkovito uporabljen;
- kako lahko več sto uporabnikov prejme 10 TB vsebine, če je uporabljenih le 20 TB prostora za shranjevanje;
- kako 5-krat stisniti podatke in jih posredovati uporabnikom v realnem času;
- kako sproti sinhronizirati podatke med več podatkovnimi centri;
- kako odpraviti vpliv uporabnikov drug na drugega pri zaporedni uporabi enega virtualnega stroja.
Skrivnost te čarovnije je tehnologija ZFS za FreeBSD in njegove sveže vilice ZFS v Linuxu. Vladimir bo delil etuije iz Playkeya.
Matvey Kukuy iz Amixr.IO pripravljen s primeri iz življenja , kaj se je zgodilo SRE in kako pomaga graditi zanesljive sisteme. Amixr.IO posreduje incidente strank skozi svoje zaledje; na desetine dežurnih ekip po vsem svetu je obravnavalo že 150 tisoč primerov. Na konferenci bo Matvey delil statistične podatke in spoznanja, ki jih je njegovo podjetje pridobilo z reševanjem težav strank in analizo napak.
Še enkrat vas pozivam, da ne boste pohlepni in delite svoje izkušnje samuraja DevOps. Postrezite za poročilo, midva pa bova imela 2,5 meseca časa, da pripraviva odličen govor. Če želite biti poslušalec, na glasilo z novostmi programa in resno razmislite o rezervaciji vstopnic pred časom, saj bodo bližje datumom konference dražje.
Vir: www.habr.com