Mluvíme samozřejmě o . Pokud nepůjdete do detailů, tak 30. září a 1. října uspořádáme konferenci o spojení procesů vývoje, testování a provozu, a pokud půjdete do detailů, tak prosím pod kat.
V rámci přístupu DevOps se všechny části technologického vývoje projektu prolínají, vyskytují se paralelně a vzájemně se ovlivňují. Zvláště důležité je zde vytváření automatizovaných vývojových procesů, které lze měnit, simulovat a testovat v reálném čase. To vám pomůže okamžitě reagovat na změny na trhu.
Na konferenci chceme ukázat, jak tento přístup ovlivňuje vývoj produktů. Jak je zajištěna spolehlivost a adaptabilita systému pro klienta. Jak DevOps mění strukturu a přístup společnosti k organizaci jejího pracovního procesu.
v zákulisí
Je pro nás důležité nejen vědět, co různé společnosti v rámci přístupu DevOps dělají, ale také pochopit, proč se to všechno dělá. Proto jsme do programového výboru pozvali nejen odborníky, ale také specialisty, kteří diskurz DevOps vidí z různých pozic:
- vedoucí inženýři;
- vývojáři;
- vedení týmu;
- CTO.
Na jedné straně to vytváří potíže a konflikty při projednávání žádostí o zprávy. Pokud má inženýr zájem analyzovat závažnou nehodu, pak je pro vývojáře důležitější, aby pochopil, jak vytvořit software, který funguje v cloudu a infrastruktuře. Ale tím, že se dohodneme, vytvoříme program, který bude hodnotný a zajímavý pro všechny: od inženýrů po CTO.
Cílem naší konference není jen vybrat ty nejvíce hype reporty, ale představit celkový obrázek: jak DevOps přístup funguje v praxi, na jaké rake můžete narazit při přechodu na nové procesy. Zároveň budujeme obsahovou část, od obchodního problému až ke konkrétním technologiím.
Sekce konference zůstanou stejné jako v .
- Infrastrukturní platforma.
- Infrastruktura jako kód.
- Průběžné doručování.
- Zpětná vazba.
- Architektura v DevOps, DevOps pro CTO.
- SRE praktiky.
- Školení a řízení znalostí.
- Zabezpečení, DevSecOps.
- Transformace DevOps.
Call for Papers: jaké zprávy hledáme
Potenciální publikum konference jsme podmíněně rozdělili do pěti skupin: inženýři, vývojáři, bezpečnostní specialisté, vedoucí týmů a CTO. Každá skupina má svou vlastní motivaci přijít na konferenci. A pokud se na DevOps podíváte z těchto pozic, můžete pochopit, jak zaměřit své téma a kam klást důraz.
pro inženýry, kteří vytvářejí platformu infrastruktury, je důležité porozumět stávajícím trendům, pochopit, které technologie jsou nyní nejpokročilejší. Budou mít zájem dozvědět se o reálných zkušenostech s používáním těchto technologií a vyměňovat si názory. Inženýr si rád poslechne zprávu analyzující nějakou tvrdou nehodu a my se zase pokusíme takovou zprávu vybrat a vypilovat.
Pro vývojáře je důležité pochopit takový koncept jako cloudová nativní aplikace. Tedy jak vyvíjet software tak, aby fungoval v cloudech a různých infrastrukturách. Vývojář potřebuje neustále dostávat zpětnou vazbu od softwaru. Zde chceme slyšet případy o tom, jak společnosti budují tento proces, jak monitorovat výkon softwaru a jak funguje celý proces dodání.
Specialisté na kybernetickou bezpečnost Je důležité porozumět tomu, jak nastavit bezpečnostní proces, aby nebrzdil vývoj a změny procesů v rámci firmy. Zajímavá budou i témata o požadavcích, které DevOps na takové specialisty klade.
Vedoucí týmu chtějí vědět, jak funguje kontinuální proces dodávek v jiných společnostech. Jakou cestu podnikly, aby toho dosáhly, jak vybudovaly procesy vývoje a zajišťování kvality v rámci DevOps. Vedoucí týmů se také zajímá o nativní cloud. A také otázky týkající se interakce uvnitř týmu a mezi vývojovými a inženýrskými týmy.
pro ČTÚ nejdůležitější je přijít na to, jak všechny tyto procesy propojit a přizpůsobit potřebám podniku. Dbá na to, aby byla aplikace spolehlivá jak pro firmu, tak pro klienta. A zde musíte pochopit, které technologie budou fungovat pro které obchodní úkoly, jak postavit celý proces atd. ČTÚ je také zodpovědný za rozpočtování. Musí například pochopit, kolik peněz je třeba vynaložit na rekvalifikaci specialistů, aby mohli pracovat v DevOps.
Máte-li k těmto záležitostem co říci, nemlčte, . Uzávěrka výzvy k předkládání příspěvků je 20. srpna. Čím dříve se zaregistrujete, tím více času budete mít na dokončení zprávy a přípravu na prezentaci. Takže neotálejte.
No, pokud nemáte potřebu mluvit veřejně, stačí a přijďte 30. září a 1. října komunikovat s kolegy. Slibujeme, že to bude zajímavé a inspirativní.
Jak vidíme DevOps
Abyste přesně pochopili, co máme na mysli pod pojmem DevOps, doporučuji si přečíst (nebo znovu přečíst) mou zprávu “" Při procházce vlnami trhu jsem pozoroval, jak se myšlenka DevOps transformovala v různých velkých společnostech: od malého startupu po nadnárodní společnosti. Zpráva je postavena na sérii otázek, jejichž zodpovězením můžete pochopit, zda se vaše společnost posouvá směrem k DevOps nebo zda jsou někde problémy.
DevOps je komplexní systém, který musí obsahovat:
- Digitální produkt.
- Obchodní moduly, které vyvíjejí tento digitální produkt.
- Produktové týmy, které píší kód.
- Postupy průběžného doručování.
- Platformy jako služba.
- Infrastruktura jako služba.
- Infrastruktura jako kód.
- Samostatné postupy pro zachování spolehlivosti zabudované do DevOps.
- Zpětná vazba, která to všechno popisuje.
Na konci zprávy je schéma, které poskytuje představu o systému DevOps ve společnosti. Umožní vám vidět, které procesy ve vaší společnosti již byly zefektivněny a které teprve budou vybudovány.
Na video reportáže se můžete podívat .
A teď bude bonus: několik videí z RIT++ 2019, která se dotýkají nejobecnějších problémů transformace DevOps.
Firemní infrastruktura jako produkt
Arťom Naumenko vede tým DevOps ve Skyengu a stará se o rozvoj infrastruktury své společnosti. Řekl, jak infrastruktura ovlivňuje obchodní procesy ve SkyEng: jak pro ni vypočítat ROI, jaké metriky by měly být zvoleny pro výpočet a jak pracovat na jejich zlepšení.
Na cestě k mikroslužbám
Společnost Nixys poskytuje podporu pro vytížené webové projekty a distribuované systémy. Její technický ředitel Boris Ershov řekl, jak převést softwarové produkty, jejichž vývoj začal před 5 lety (nebo i více), na moderní platformu.
Takové projekty jsou zpravidla zvláštním světem, kde jsou tak temná a prastará zákoutí infrastruktury, že o nich současní inženýři nevědí. A přístupy k architektuře a vývoji, které byly kdysi zvoleny, jsou zastaralé a nemohou zajistit podniku stejné tempo vývoje a vydávání nových verzí. Výsledkem je, že každé vydání produktu se promění v neuvěřitelné dobrodružství, kde neustále něco padá a na tom nejneočekávanějším místě.
Manažeři takových projektů nevyhnutelně čelí potřebě transformace všech technologických procesů. Boris ve své zprávě řekl:
- jak vybrat správnou architekturu projektu a dát do pořádku infrastrukturu;
- jaké nástroje použít a jaká úskalí narážejí na cestě k transformaci;
- co dělat dál.
Automatizace výdejů aneb jak dodávat rychle a bezbolestně
Alexander Korotkov je předním vývojářem systému CI/CD ve společnosti CIAN. Hovořil o automatizačních nástrojích, které umožnily zlepšit kvalitu a pětkrát zkrátit dobu dodání kódu do výroby. Ale takových výsledků nebylo možné dosáhnout pouze automatizací, a tak Alexander věnoval pozornost i změnám ve vývojových procesech.
Jak vám nehody pomáhají učit se?
Alexey Kirpichnikov implementuje DevOps a infrastrukturu ve společnosti SKB Kontur již 5 let. Během tří let se v jeho společnosti vyskytlo přibližně 1000 fakapů různého stupně epičnosti. Mezi nimi bylo například 36 % způsobeno uvedením nekvalitního vydání do výroby a 14 % bylo způsobeno údržbou hardwaru v datovém centru.
Takto přesné informace o nehodách umožňuje získat archiv zpráv (post mortem), který inženýři společnosti vedou několik let po sobě. Pitvu píše konající inženýr, který jako první zareagoval na nouzový signál a začal vše opravovat. Proč mučit inženýry, kteří v noci bojují s facapy psaním zpráv? Tato data vám umožní vidět celý obrázek a posunout vývoj infrastruktury správným směrem.
Alexey se ve svém projevu podělil o to, jak napsat skutečně užitečnou pitvu a jak zavést praxi takových zpráv ve velké společnosti. Pokud máte rádi historky o tom, jak to někdo podělal, podívejte se na video z představení.
Chápeme, že vaše vize DevOps se nemusí shodovat s naší. Bude zajímavé vědět, jak vidíte transformaci DevOps. Podělte se o své zkušenosti a představy o tomto tématu v komentářích.
Jaké zprávy jsme již do programu přijali?
Tento týden programový výbor přijal 4 zprávy: o bezpečnosti, infrastruktuře a postupech SRE.
Snad nejbolestivější téma transformace DevOps: jak zajistit, aby kluci z oddělení informační bezpečnosti nezničili již vybudovaná propojení mezi vývojem, provozem a správou. Některé společnosti fungují bez oddělení bezpečnosti informací. Jak v tomto případě zajistit bezpečnost informací? O tom Mona Arkhipova ze sudo.su. Z její zprávy se dozvídáme:
- co je třeba chránit a před kým;
- jaké jsou běžné bezpečnostní procesy;
- jak se prolínají procesy IT a informační bezpečnosti;
- co je CIS CSC a jak jej implementovat;
- jak a podle jakých ukazatelů provádět pravidelné kontroly bezpečnosti informací.
Další zpráva se týká rozvoje infrastruktury jako kódu. Snižte množství ruční rutiny a neproměňte celý projekt v chaos, je to možné? Na tuto otázku Maxim Kostrikin z Ixtens. Jeho společnost používá Terraform pro práci s infrastrukturou AWS. Nástroj je pohodlný, ale otázkou je, jak se při jeho používání vyhnout vytváření obrovského bloku kódu. Údržba takového dědictví bude rok od roku dražší.
Maxim ukáže, jak fungují vzory umístění kódu, zaměřené na zjednodušení automatizace a vývoje.
Ještě jeden uslyšíme o infrastruktuře od Vladimir Ryabov z Playkey. Zde budeme hovořit o platformě infrastruktury a naučíme se:
- jak pochopit, zda je úložný prostor využíván efektivně;
- jak může několik stovek uživatelů přijímat 10 TB obsahu, pokud je použito pouze 20 TB úložiště;
- jak 5x komprimovat data a poskytovat je uživatelům v reálném čase;
- jak synchronizovat data za chodu mezi několika datovými centry;
- jak eliminovat jakýkoli vliv uživatelů na sebe při postupném používání jednoho virtuálního stroje.
Tajemstvím této magie je technologie ZFS pro FreeBSD a jeho čerstvou vidličku ZFS na Linuxu. Vladimir se podělí o případy z Playkey.
Matvey Kukuy z Amixr.IO připraven s příklady ze života , co SRE a jak pomáhá budovat spolehlivé systémy. Amixr.IO prochází klientské incidenty přes svůj backend, desítky týmů ve službě po celém světě již řešily 150 tisíc případů. Na konferenci se Matvey podělí o statistiky a poznatky, které jeho společnost nashromáždila při řešení problémů zákazníků a analýze selhání.
Ještě jednou vás žádám, abyste nebyli chamtiví a podělili se o své zkušenosti samuraje DevOps. Sloužit za zprávu a vy i já budeme mít 2,5 měsíce na přípravu vynikajícího projevu. Pokud chcete být posluchačem, do newsletteru s aktualizacemi programu a vážně uvažujte o rezervaci vstupenek s předstihem, protože blíže k datům konference se prodraží.
Zdroj: www.habr.com