Hovoríme, samozrejme, o . Ak nepôjdete do detailov, tak 30. septembra a 1. októbra usporiadame konferenciu o spájaní procesov vývoja, testovania a prevádzky a ak pôjdete do detailov, tak prosím pod kat.
V rámci prístupu DevOps sa všetky časti technologického vývoja projektu prelínajú, vyskytujú sa paralelne a navzájom sa ovplyvňujú. Osobitný význam tu má vytváranie automatizovaných vývojových procesov, ktoré je možné meniť, simulovať a testovať v reálnom čase. To vám pomôže okamžite reagovať na zmeny na trhu.
Na konferencii chceme ukázať, ako tento prístup ovplyvňuje vývoj produktov. Ako je zabezpečená spoľahlivosť a prispôsobivosť systému pre klienta. Ako DevOps mení štruktúru a prístup spoločnosti k organizácii pracovného procesu.
v zákulisí
Je pre nás dôležité nielen vedieť, čo robia rôzne spoločnosti v rámci prístupu DevOps, ale aj pochopiť, prečo sa to všetko robí. Preto sme do programového výboru pozvali nielen odborníkov, ale aj špecialistov, ktorí vidia diskurz DevOps z rôznych pozícií:
- starší inžinieri;
- vývojári;
- vedúci tímov;
- CTO.
Na jednej strane to spôsobuje ťažkosti a konflikty pri prerokúvaní žiadostí o správy. Ak má inžinier záujem analyzovať veľkú nehodu, potom je pre vývojára dôležitejšie pochopiť, ako vytvoriť softvér, ktorý funguje v cloude a infraštruktúre. Ale ak sa dohodneme, vytvoríme program, ktorý bude hodnotný a zaujímavý pre každého: od inžinierov po CTO.
Cieľom našej konferencie nie je len vybrať tie najviac hype reporty, ale predstaviť celkový obraz: ako funguje prístup DevOps v praxi, na aký rake môžete naraziť pri prechode na nové procesy. Zároveň budujeme obsahovú časť, pričom ideme od obchodného problému až po konkrétne technológie.
Sekcie konferencie zostanú rovnaké ako v .
- Platforma infraštruktúry.
- Infraštruktúra ako kód.
- Nepretržité doručovanie.
- Spätná väzba.
- Architektúra v DevOps, DevOps pre CTO.
- SRE praktiky.
- Školenie a manažment znalostí.
- Bezpečnosť, DevSecOps.
- Transformácia DevOps.
Call for Papers: aký druh správ hľadáme
Potenciálne publikum konferencie sme podmienečne rozdelili do piatich skupín: inžinieri, vývojári, bezpečnostní špecialisti, vedúci tímov a CTO. Každá skupina má svoju motiváciu prísť na konferenciu. A ak sa na DevOps pozriete z týchto pozícií, môžete pochopiť, ako zamerať svoju tému a kam klásť dôraz.
Pre inžinierov, ktorí vytvárajú platformu infraštruktúry, je dôležité porozumieť existujúcim trendom, pochopiť, ktoré technológie sú teraz najpokročilejšie. Budú mať záujem dozvedieť sa o reálnych skúsenostiach s používaním týchto technológií a vymieňať si názory. Inžinier si rád vypočuje správu analyzujúcu nejakú tvrdú nehodu a my sa zase pokúsime vybrať a vylepšiť takúto správu.
Pre vývojárov je dôležité pochopiť taký pojem ako cloudová natívna aplikácia. Teda ako vyvíjať softvér tak, aby fungoval v cloudoch a rôznych infraštruktúrach. Vývojár musí neustále dostávať spätnú väzbu od softvéru. Tu chceme počuť prípady o tom, ako spoločnosti budujú tento proces, ako monitorovať výkon softvéru a ako funguje celý proces dodávky.
Špecialisti na kybernetickú bezpečnosť Je dôležité pochopiť, ako nastaviť bezpečnostný proces tak, aby nezabrzdil vývoj a zmeny procesov v rámci firmy. Zaujímavé budú aj témy o požiadavkách, ktoré DevOps kladie na takýchto špecialistov.
Vedúci tímu chcú vedieť, ako funguje nepretržitý proces doručovania v iných spoločnostiach. Akú cestu podnikli, aby to dosiahli, ako vybudovali procesy vývoja a zabezpečenia kvality v rámci DevOps. Vedúci tímov sa tiež zaujímajú o cloudové natívne. A tiež otázky týkajúce sa interakcie v rámci tímu a medzi vývojovými a inžinierskymi tímami.
pre CTO najdôležitejšie je prísť na to, ako všetky tieto procesy prepojiť a prispôsobiť potrebám podniku. Dbá na to, aby bola aplikácia spoľahlivá pre biznis aj klienta. A tu musíte pochopiť, ktoré technológie budú fungovať pre ktoré obchodné úlohy, ako vybudovať celý proces atď. CTO je zodpovedný aj za rozpočtovanie. Musí napríklad pochopiť, koľko peňazí treba minúť na rekvalifikáciu špecialistov, aby mohli pracovať v DevOps.
Ak máte čo povedať k týmto veciam, nemlčte, . Uzávierka výzvy na predkladanie príspevkov je 20. augusta. Čím skôr sa zaregistrujete, tým viac času budete mať na dokončenie správy a prípravu na prezentáciu. Takže neotáľajte.
No, ak nemáte potrebu hovoriť verejne, stačí a príďte 30. septembra a 1. októbra komunikovať s kolegami. Sľubujeme, že to bude zaujímavé a inšpiratívne.
Ako vidíme DevOps
Aby ste presne pochopili, čo máme na mysli pod pojmom DevOps, odporúčam prečítať (alebo znova prečítať) moju správu “" Prechádzal som sa vlnami trhu a pozoroval som, ako sa myšlienka DevOps transformovala v rôznych veľkých spoločnostiach: od malého startupu až po nadnárodné spoločnosti. Správa je postavená na sérii otázok, ich zodpovedaním môžete pochopiť, či vaša spoločnosť smeruje k DevOps alebo či sú niekde problémy.
DevOps je komplexný systém, ktorý musí obsahovať:
- Digitálny produkt.
- Obchodné moduly, ktoré vyvíjajú tento digitálny produkt.
- Produktové tímy, ktoré píšu kód.
- Postupy nepretržitého doručovania.
- Platformy ako služba.
- Infraštruktúra ako služba.
- Infraštruktúra ako kód.
- Samostatné postupy na udržanie spoľahlivosti zabudované do DevOps.
- Prax spätnej väzby, ktorá to všetko popisuje.
Na konci správy je schéma, ktorá poskytuje predstavu o systéme DevOps v spoločnosti. Umožní vám vidieť, ktoré procesy vo vašej spoločnosti už boli zefektívňované a ktoré ešte len treba vybudovať.
Môžete si pozrieť video z reportáže .
A teraz bude bonus: niekoľko videí z RIT++ 2019, ktoré sa dotýkajú najvšeobecnejších problémov transformácie DevOps.
Firemná infraštruktúra ako produkt
Arťom Naumenko vedie tím DevOps v Skyeng a stará sa o rozvoj infraštruktúry svojej spoločnosti. Povedal, ako infraštruktúra ovplyvňuje obchodné procesy v SkyEng: ako pre ňu vypočítať ROI, aké metriky by sa mali zvoliť na výpočet a ako pracovať na ich zlepšení.
Na ceste k mikroslužbám
Spoločnosť Nixys poskytuje podporu pre vyťažené webové projekty a distribuované systémy. Jeho technický riaditeľ Boris Ershov povedal, ako preložiť softvérové produkty, ktorých vývoj sa začal pred 5 rokmi (alebo aj viac), na modernú platformu.
Takéto projekty sú spravidla zvláštnym svetom, kde sú také temné a starodávne zákutia infraštruktúry, že o nich súčasní inžinieri nevedia. A prístupy k architektúre a vývoju, ktoré boli kedysi zvolené, sú zastarané a nedokážu poskytnúť podniku rovnaké tempo vývoja a vydávania nových verzií. Výsledkom je, že každé vydanie produktu sa zmení na neuveriteľné dobrodružstvo, kde neustále niečo odpadáva a na tom najneočakávanejšom mieste.
Manažéri takýchto projektov nevyhnutne čelia potrebe transformovať všetky technologické procesy. Boris vo svojej správe uviedol:
- ako zvoliť správnu architektúru projektu a dať do poriadku infraštruktúru;
- aké nástroje použiť a aké úskalia sa stretávajú na ceste k transformácii;
- čo urobiť ďalej.
Automatizácia výdajov alebo ako rýchlo a bezbolestne dodať
Alexander Korotkov je popredný vývojár CI/CD systému v CIAN. Hovoril o automatizačných nástrojoch, ktoré umožnili zlepšiť kvalitu a päťnásobne skrátiť čas na dodanie kódu do výroby. Ale takéto výsledky nebolo možné dosiahnuť len automatizáciou, preto Alexander venoval pozornosť aj zmenám vo vývojových procesoch.
Ako vám nehody pomáhajú učiť sa?
Alexey Kirpichnikov implementuje DevOps a infraštruktúru v SKB Kontur už 5 rokov. V priebehu troch rokov sa v jeho spoločnosti vyskytlo približne 1000 fakapov rôzneho stupňa epickosti. Spomedzi nich bolo napríklad 36 % spôsobených uvedením nekvalitného vydania do produkcie a 14 % bolo spôsobených údržbou hardvéru v dátovom centre.
Takto presné informácie o nehodách umožňuje získať archív správ (post mortem), ktorý inžinieri spoločnosti vedú už niekoľko rokov po sebe. Pitvu píše službukonajúci inžinier, ktorý ako prvý zareagoval na núdzový signál a začal všetko opravovať. Prečo trápiť inžinierov, ktorí v noci zápasia s facapmi, písaním správ? Tieto údaje vám umožňujú vidieť celkový obraz a posunúť vývoj infraštruktúry správnym smerom.
Vo svojom prejave sa Alexey podelil o to, ako napísať skutočne užitočnú pitvu a ako implementovať prax takýchto správ vo veľkej spoločnosti. Ak máte radi príbehy o tom, ako to niekto pokazil, pozrite si video z predstavenia.
Chápeme, že vaša vízia DevOps sa nemusí zhodovať s našou. Bude zaujímavé vedieť, ako vidíte transformáciu DevOps. Podeľte sa o svoje skúsenosti a víziu tejto témy v komentároch.
Aké správy sme už do programu prijali?
Tento týždeň programový výbor prijal 4 správy: o bezpečnosti, infraštruktúre a postupoch SRE.
Azda najbolestivejšia téma transformácie DevOps: ako zabezpečiť, aby chalani z oddelenia informačnej bezpečnosti nezničili už vybudované prepojenia medzi vývojom, prevádzkou a administratívou. Niektoré spoločnosti fungujú bez oddelenia informačnej bezpečnosti. Ako v tomto prípade zabezpečiť informačnú bezpečnosť? O tom Mona Arkhipova zo sudo.su. Z jej správy sa dozvedáme:
- čo je potrebné chrániť a pred kým;
- aké sú bežné bezpečnostné procesy;
- ako sa prelínajú procesy IT a informačnej bezpečnosti;
- čo je CIS CSC a ako ho implementovať;
- ako a akými ukazovateľmi vykonávať pravidelné kontroly informačnej bezpečnosti.
Ďalšia správa sa týka rozvoja infraštruktúry ako kódu. Znížte množstvo manuálnej rutiny a nepremeňte celý projekt na chaos, je to možné? Na túto otázku Maxim Kostrikin z Ixtens. Jeho spoločnosť používa terraform pre prácu s infraštruktúrou AWS. Nástroj je pohodlný, no otázkou je, ako sa pri jeho používaní vyhnúť vytvoreniu obrovského bloku kódu. Údržba takéhoto dedičstva bude z roka na rok drahšia.
Maxim ukáže, ako fungujú vzory umiestňovania kódu, zamerané na zjednodušenie automatizácie a vývoja.
Ďalší budeme počuť o infraštruktúre od Vladimir Ryabov z Playkey. Tu budeme hovoriť o platforme infraštruktúry a naučíme sa:
- ako pochopiť, či sa úložný priestor využíva efektívne;
- ako môže niekoľko stoviek používateľov prijať 10 TB obsahu, ak sa použije iba 20 TB úložného priestoru;
- ako 5-krát komprimovať údaje a poskytnúť ich používateľom v reálnom čase;
- ako synchronizovať dáta za behu medzi niekoľkými dátovými centrami;
- ako eliminovať akýkoľvek vplyv používateľov na seba pri postupnom používaní jedného virtuálneho stroja.
Tajomstvom tejto mágie je technológia ZFS pre FreeBSD a jeho čerstvú vidličku ZFS v systéme Linux. Vladimír sa podelí o prípady z Playkey.
Matvey Kukuy z Amixr.IO pripravený s príkladmi zo života , čo sa stalo SRE a ako pomáha budovať spoľahlivé systémy. Amixr.IO prechádza klientskymi incidentmi cez svoj backend, desiatky tímov v službe po celom svete už riešili 150 tisíc prípadov. Na konferencii sa Matvey podelí o štatistiky a poznatky, ktoré jeho spoločnosť nazhromaždila pri riešení problémov zákazníkov a analýze zlyhaní.
Ešte raz vás vyzývam, aby ste neboli chamtiví a podelili sa o svoje skúsenosti ako samuraj DevOps. Podávajte za správu a vy a ja budeme mať 2,5 mesiaca na prípravu vynikajúceho prejavu. Ak chcete byť poslucháčom, do newsletteru s aktualizáciami programu a vážne premýšľajte o rezervácii vstupeniek v predstihu, pretože bližšie k termínom konferencie budú drahšie.
Zdroj: hab.com