Természetesen arról beszélünk . Ha nem menne bele a részletekbe, akkor szeptember 30-án és október 1-jén konferenciát tartunk a fejlesztési, tesztelési és üzemeltetési folyamatok összekapcsolásáról, ha pedig részletezi, kérem, a kat.
A DevOps megközelítésen belül a projekt technológiai fejlesztésének minden része összefonódik, párhuzamosan zajlik és befolyásolja egymást. Itt különösen fontos az automatizált fejlesztési folyamatok létrehozása, amelyek valós időben változtathatók, szimulálhatók és tesztelhetők. Ez segít abban, hogy azonnal reagáljon a piaci változásokra.
A konferencián szeretnénk bemutatni, hogy ez a megközelítés hogyan befolyásolja a termékfejlesztést. Hogyan biztosítható a rendszer megbízhatósága és adaptálhatósága az ügyfél számára. Hogyan változtatja meg a DevOps egy vállalat szerkezetét és megközelítését a munkafolyamatok megszervezéséhez.
a színfalak mögött
Fontos, hogy ne csak azt tudjuk, mit csinálnak a különböző cégek a DevOps megközelítés keretein belül, hanem azt is, hogy megértsük, miért történik mindez. Ezért nem csak szakértőket hívtunk meg a Programbizottságba, hanem olyan szakembereket, akik különböző pozíciókból látják a DevOps diskurzust:
- vezető mérnökök;
- fejlesztők;
- csapatvezetők;
- CTO.
Ez egyrészt nehézségeket és konfliktusokat okoz a jelentéskérések megvitatása során. Ha egy mérnököt érdekel egy súlyos baleset elemzése, akkor fontosabb, hogy a fejlesztő megértse, hogyan hozhat létre felhőben és infrastruktúrákban működő szoftvert. Ám a megegyezéssel egy olyan programot hozunk létre, amely mindenki számára értékes és érdekes lesz: a mérnököktől a műszaki igazgatókig.
Konferenciánk célja nem pusztán a legfelkapottabb riportok kiválasztása, hanem az összkép bemutatása: hogyan működik a DevOps megközelítés a gyakorlatban, milyen rake-ba ütközhet az új folyamatokra való átálláskor. Ugyanakkor a tartalmi részt is felépítjük, az üzleti problémától lefelé haladva a konkrét technológiákig.
A konferencia szekciói változatlanok maradnak .
- Infrastruktúra platform.
- Az infrastruktúra kódként.
- Folyamatos szállítás.
- Visszacsatolás.
- Építészet a DevOps-ban, DevOps a CTO-ban.
- SRE gyakorlatok.
- Képzés és tudásmenedzsment.
- Biztonság, DevSecOps.
- DevOps átalakítás.
Felhívás papírokért: milyen jelentéseket várunk
A konferencia potenciális közönségét feltételesen öt csoportra osztottuk: mérnökök, fejlesztők, biztonsági szakemberek, csapatvezetők és CTO. Minden csoportnak megvan a maga motivációja, hogy eljöjjön a konferenciára. És ha ezekből a pozíciókból nézi a DevOps-ot, megértheti, hogyan kell összpontosítania a témára, és hová kell helyeznie a hangsúlyt.
Mérnökök számára, akik infrastrukturális platformot hoznak létre, fontos megérteni a meglévő trendeket, megérteni, mely technológiák a legfejlettebbek. Érdekelni fogja őket, hogy megismerjék e technológiák használatának valós tapasztalatait, és véleményt cseréljenek. Egy mérnök szívesen meghallgat egy súlyos balesetet elemző jelentést, mi pedig megpróbáljuk kiválasztani és csiszolni egy ilyen jelentést.
A fejlesztőknek fontos megérteni egy ilyen fogalmat, mint felhő natív alkalmazás. Vagyis hogyan kell szoftvert fejleszteni úgy, hogy az működjön felhőben és különféle infrastruktúrákban. A fejlesztőnek folyamatosan visszajelzést kell kapnia a szoftvertől. Itt szeretnénk hallani eseteket arról, hogy a vállalatok hogyan építik fel ezt a folyamatot, hogyan lehet nyomon követni a szoftverek teljesítményét, és hogyan működik a teljes szállítási folyamat.
Kiberbiztonsági szakemberek Fontos megérteni, hogyan állítsuk be a biztonsági folyamatot úgy, hogy az ne akadályozza meg a vállalaton belüli fejlesztési és változási folyamatokat. Érdekesek lesznek a DevOps által az ilyen szakemberekkel szemben támasztott követelményekről szóló témák is.
A csapatvezetők tudni akarják, hogyan működik a folyamatos szállítási folyamat más cégeknél. Milyen utat jártak be a cégek ennek elérése érdekében, hogyan építettek ki fejlesztési és minőségbiztosítási folyamatokat a DevOps-on belül. A csapatvezetők is érdeklődnek a Cloud natív iránt. És kérdések a csapaton belüli, valamint a fejlesztői és mérnöki csapatok közötti interakcióról.
mert CTO a legfontosabb dolog az, hogy kitaláljuk, hogyan kapcsoljuk össze ezeket a folyamatokat, és igazítsuk az üzleti igényekhez. Gondoskodik arról, hogy az alkalmazás megbízható legyen a vállalkozás és az ügyfél számára egyaránt. És itt meg kell értened, hogy mely technológiák milyen üzleti feladatoknál működnek, hogyan építsd fel a teljes folyamatot stb. A CTO a költségvetés tervezéséért is felelős. Például meg kell értenie, mennyi pénzt kell költeni a szakemberek átképzésére, hogy a DevOps-ban dolgozhassanak.
Ha van valami mondanivalója ezekkel kapcsolatban, ne maradjon csendben, . A Pályázati Felhívás határideje augusztus 20. Minél korábban regisztrál, annál több ideje lesz a beszámoló véglegesítésére és az előadásra való felkészülésre. Szóval ne késlekedj.
Nos, ha nincs szüksége nyilvánosan beszélni, csak és szeptember 30-án és október 1-jén jöjjön el kommunikálni a kollégákkal. Ígérjük, érdekes és inspiráló lesz.
Hogyan látjuk a DevOps-ot
Ahhoz, hogy pontosan megértsük, mit értünk DevOps alatt, azt javaslom, hogy olvassa el (vagy olvassa el újra) a jelentésemet." A piac hullámain sétálva megfigyeltem, hogyan alakul át a DevOps ötlete a különböző méretű cégekben: egy kis startuptól a multinacionális cégekig. A riport egy sor kérdésre épül, ezek megválaszolásával érthető, hogy a céged a DevOps felé halad, vagy vannak-e problémák valahol.
A DevOps egy összetett rendszer, amelynek tartalmaznia kell:
- Digitális termék.
- Üzleti modulok, amelyek ezt a digitális terméket fejlesztik.
- Termékcsoportok, amelyek kódot írnak.
- Folyamatos szállítási gyakorlatok.
- Platformok, mint szolgáltatás.
- Az infrastruktúra mint szolgáltatás.
- Az infrastruktúra kódként.
- Külön gyakorlatok a megbízhatóság fenntartására, beépítve a DevOps-ba.
- Egy visszacsatolási gyakorlat, amely mindent leír.
A jelentés végén van egy diagram, amely képet ad a vállalat DevOps rendszeréről. Lehetővé teszi, hogy megtekinthesse, mely folyamatokat sikerült már korszerűsíteni a vállalatában, és melyeket kell még kiépíteni.
A riportról készült videót megtekintheti .
És most lesz egy bónusz: több videó a RIT++ 2019-ből, amelyek a DevOps átalakítás legáltalánosabb kérdéseit érintik.
A vállalati infrastruktúra mint termék
Artyom Naumenko a Skyeng DevOps csapatát vezeti, és gondoskodik cége infrastruktúrájának fejlesztéséről. Elmondta, hogyan befolyásolja az infrastruktúra az üzleti folyamatokat a SkyEngnél: hogyan kell kiszámítani a ROI-t, milyen mérőszámokat kell kiválasztani a számításhoz, és hogyan kell javítani ezeken.
Úton a mikroszolgáltatások felé
A Nixys cég támogatást nyújt elfoglalt webes projektekhez és elosztott rendszerekhez. Műszaki igazgatója, Boris Ershov elmondta, hogyan lehet modern platformra fordítani a szoftvertermékeket, amelyek fejlesztése 5 éve (vagy még régebben) kezdődött.
Az ilyen projektek általában egy különleges világot alkotnak, ahol az infrastruktúra olyan sötét és ősi szegletei vannak, amelyeket a jelenlegi mérnökök nem tudnak róluk. Az építészet és fejlesztés egykor választott megközelítései pedig elavultak, és nem tudják biztosítani a vállalkozás számára ugyanolyan ütemű fejlesztést és új verziók kiadását. Ennek eredményeként minden termékmegjelenés egy hihetetlen kalandmá válik, ahol folyamatosan leesik valami, és a legváratlanabb helyen.
Az ilyen projektek menedzserei elkerülhetetlenül szembesülnek az összes technológiai folyamat átalakításának igényével. Boris a jelentésében azt mondta:
- hogyan válasszuk ki a megfelelő architektúrát a projekthez és hogyan tegyük rendbe az infrastruktúrát;
- milyen eszközöket kell használni, és milyen buktatókkal találkozhatunk az átalakulás útján;
- mi legyen a következő.
A kibocsátások automatizálása vagy a gyors és fájdalommentes szállítás
Alexander Korotkov a CI/CD rendszer egyik vezető fejlesztője a CIAN-nál. Szólt az automatizálási eszközökről, amelyek lehetővé tették a minőség javítását és a kód gyártásba való eljuttatásának 5-szörösére való csökkentését. De ilyen eredményeket nem lehetett elérni pusztán automatizálással, ezért Alexander odafigyelt a fejlesztési folyamatok változásaira is.
Hogyan segítik a balesetek a tanulást?
Alexey Kirpichnikov 5 éve implementálja a DevOps-t és az infrastruktúrát az SKB Konturnál. Három év alatt megközelítőleg 1000 különböző fokú epikus fakap fordult elő társaságában. Közülük például 36%-ot egy rossz minőségű kiadás gyártásba helyezése okozta, 14%-ot pedig az adatközpontban végzett hardverkarbantartási munkák okoztak.
A cég mérnökei által évek óta folyamatosan karbantartott jelentések archívuma (post mortem) lehetővé teszi, hogy ilyen pontos információkat szerezzenek a balesetekről. Az utólagos leletet az ügyeletes mérnök írja, aki elsőként reagált a vészjelzésre, és elkezdett mindent megjavítani. Miért kínozzuk riportírással azokat a mérnököket, akik éjszaka a facatokkal küszködnek? Ezek az adatok lehetővé teszik a teljes kép megtekintését és az infrastruktúra fejlesztésének megfelelő irányba történő elmozdítását.
Beszédében Alexey megosztotta, hogyan lehet valóban hasznos postmortem-et írni, és hogyan lehet megvalósítani az ilyen jelentések gyakorlatát egy nagy cégnél. Ha szereted a történeteket arról, hogyan rontott el valaki, nézd meg az előadásról készült videót.
Megértjük, hogy az Ön DevOps-ról alkotott elképzelése nem egyezik a miénkkel. Érdekes lesz tudni, hogyan látja a DevOps átalakulását. Ossza meg tapasztalatait és elképzeléseit erről a témáról a megjegyzésekben.
Milyen jelentéseket fogadtunk már be a programba?
Ezen a héten a Programbizottság 4 jelentést fogadott el: a biztonságról, az infrastruktúráról és az SRE gyakorlatokról.
A DevOps átalakítás talán legfájdalmasabb témája: hogyan lehet elérni, hogy az információbiztonsági osztály srácai ne rombolják le a fejlesztés, az üzemeltetés és az adminisztráció között már kiépített kapcsolatokat. Egyes cégek információbiztonsági osztály nélkül működnek. Hogyan biztosítható ebben az esetben az információbiztonság? Erről Mona Arkhipova a sudo.su webhelyről. Beszámolójából megtudjuk:
- mit kell védeni és kitől;
- melyek a rutin biztonsági folyamatok;
- hogyan keresztezik egymást az IT és az információbiztonsági folyamatok;
- mi az a CIS CSC és hogyan kell megvalósítani;
- hogyan és milyen mutatók alapján végezzen rendszeres információbiztonsági ellenőrzéseket.
A következő jelentés az infrastruktúra fejlesztésével, mint kóddal foglalkozik. Csökkentse a kézi rutin mennyiségét, és ne tegye az egész projektet káoszba, lehetséges ez? Erre a kérdésre Maxim Kostrikin az Ixtenstől. Cége használja Terraform az AWS infrastruktúrával való munkához. Az eszköz kényelmes, de a kérdés az, hogyan lehet elkerülni, hogy használata során hatalmas kódblokk keletkezzen. Egy ilyen örökség fenntartása évről évre egyre drágább lesz.
A Maxim bemutatja, hogyan működnek a kódelhelyezési minták, amelyek célja az automatizálás és a fejlesztés egyszerűsítése.
Egy másik az infrastruktúráról fogunk hallani Vladimir Ryabov a Playkey-től. Itt az infrastrukturális platformról fogunk beszélni, és megtanuljuk:
- hogyan lehet megérteni, hogy a tárhelyet hatékonyan használják-e fel;
- hány száz felhasználó kaphat 10 TB tartalmat, ha csak 20 TB tárhelyet használnak;
- hogyan lehet ötször tömöríteni az adatokat, és valós időben eljuttatni a felhasználókhoz;
- hogyan lehet az adatokat menet közben szinkronizálni több adatközpont között;
- hogyan lehet kiküszöbölni a felhasználók egymásra gyakorolt hatását egy virtuális gép szekvenciális használata során.
Ennek a varázslatnak a titka a technológia ZFS FreeBSD-hez és a friss villája ZFS Linuxon. Vladimir megosztja a Playkey eseteit.
Matvey Kukuy az Amixr.IO-tól készen áll az életből vett példákkal , mit SRE és hogyan segít megbízható rendszerek felépítésében. Az Amixr.IO a kliens-incidenseket a háttérrendszerén keresztül viszi át, a világ több tucat ügyeletes csapata már 150 ezer esettel foglalkozott. A konferencián Matvey megosztja azokat a statisztikákat és meglátásait, amelyeket cége az ügyfelek problémáinak megoldása és a hibák elemzése során halmozott fel.
Még egyszer arra kérlek, hogy ne légy kapzsi, és oszd meg tapasztalataidat DevOps szamurájként. Szolgál egy jelentésre, és Önnek és nekem 2,5 hónapunk lesz egy kiváló beszéd elkészítésére. Ha hallgató akarsz lenni, a programfrissítéseket tartalmazó hírlevélre, és komolyan gondolja át a jegyek előzetes lefoglalását, mert a konferencia időpontjaihoz közeledve drágulnak.
Forrás: will.com