Mes, žinoma, kalbame apie . Jei nesigilinsite į smulkmenas, tai rugsėjo 30 ir spalio 1 dienomis surengsime konferenciją apie kūrimo, testavimo ir eksploatavimo procesų derinimą, o jei gilinsitės į smulkmenas, prašau, po kat.
Taikant DevOps metodą, visos projekto technologinės plėtros dalys yra susipynusios, vyksta lygiagrečiai ir daro įtaką viena kitai. Čia ypač svarbu sukurti automatizuotus kūrimo procesus, kuriuos galima keisti, imituoti ir išbandyti realiu laiku. Tai padeda akimirksniu reaguoti į pokyčius rinkoje.
Konferencijoje norime parodyti, kaip šis požiūris įtakoja produkto kūrimą. Kaip užtikrinamas sistemos patikimumas ir pritaikomumas klientui. Kaip DevOps keičia įmonės struktūrą ir požiūrį į darbo proceso organizavimą.
Užkuliusiuose
Mums svarbu žinoti ne tik tai, ką įvairios įmonės veikia DevOps metodo rėmuose, bet ir suprasti, kodėl visa tai daroma. Todėl į Programos komitetą pakvietėme prisijungti ne tik ekspertus, bet ir specialistus, kurie mato DevOps diskursą iš skirtingų pozicijų:
- vyresnieji inžinieriai;
- kūrėjai;
- komandų vadovai;
- CTO.
Viena vertus, tai sukelia sunkumų ir konfliktų aptariant prašymus pateikti ataskaitas. Jei inžinierius domina didelės avarijos analizę, kūrėjui svarbiau suprasti, kaip sukurti programinę įrangą, kuri veiktų debesyse ir infrastruktūrose. Tačiau susitarę sukuriame programą, kuri bus vertinga ir įdomi visiems: nuo inžinierių iki CTO.
Mūsų konferencijos tikslas yra ne tik atrinkti labiausiai triukšmingus pranešimus, bet ir pateikti bendrą vaizdą: kaip DevOps metodas veikia praktiškai, į kokį grėblį galite pakliūti pereinant prie naujų procesų. Tuo pat metu kuriame turinio dalį, pereidami nuo verslo problemos prie konkrečių technologijų.
Konferencijos sekcijos išliks tokios pat kaip ir anksčiau .
- Infrastruktūros platforma.
- Infrastruktūra kaip kodas.
- Nuolatinis pristatymas.
- Atsiliepimai.
- „DevOps“ architektūra, „DevOps“, skirta CTO.
- SRE praktika.
- Mokymai ir žinių valdymas.
- Sauga, DevSecOps.
- „DevOps“ transformacija.
Kvietimas pateikti dokumentus: kokių ataskaitų ieškome
Potencialią konferencijos auditoriją sąlyginai suskirstėme į penkias grupes: inžinieriai, kūrėjai, saugos specialistai, komandų vadovai ir CTO. Kiekviena grupė turi savo motyvaciją atvykti į konferenciją. Ir jei pažvelgsite į „DevOps“ iš šių pozicijų, suprasite, kaip sutelkti dėmesį į temą ir kur sutelkti dėmesį.
Inžinieriams, kurie kuria infrastruktūros platformą, svarbu suprasti esamas tendencijas, suprasti, kurios technologijos dabar yra pažangiausios. Jiems bus įdomu sužinoti realią patirtį naudojant šias technologijas ir keistis nuomonėmis. Inžinierius mielai išklausys ataskaitą, kurioje analizuojama kokia nors sunki avarija, o mes, savo ruožtu, bandysime atrinkti ir nušlifuoti tokią ataskaitą.
Kūrėjams svarbu suprasti tokią sąvoką kaip vietinė debesies programa. Tai yra, kaip sukurti programinę įrangą, kad ji veiktų debesyse ir įvairiose infrastruktūrose. Kūrėjas turi nuolat gauti grįžtamąjį ryšį iš programinės įrangos. Čia norime išgirsti atvejų, kaip įmonės kuria šį procesą, kaip stebėti programinės įrangos veikimą ir kaip veikia visas pristatymo procesas.
Kibernetinio saugumo specialistai Svarbu suprasti, kaip nustatyti saugumo procesą, kad jis nestabdytų plėtros ir pokyčių procesų įmonėje. Įdomios bus ir temos apie DevOps keliamus reikalavimus tokiems specialistams.
Komandos vadovai nori žinoti, kaip vyksta nepertraukiamo pristatymo procesas kitose įmonėse. Kokiu keliu ėjo įmonės, kad tai pasiektų, kaip jos sukūrė DevOps plėtros ir kokybės užtikrinimo procesus. Komandos vadovai taip pat domisi „Cloud native“. Taip pat klausimai apie sąveiką komandoje ir tarp kūrimo ir inžinierių komandų.
Už CTO svarbiausia išsiaiškinti, kaip visus šiuos procesus susieti ir pritaikyti prie verslo poreikių. Jis užtikrina, kad programa būtų patikima tiek verslui, tiek klientui. Ir čia reikia suprasti, kurios technologijos tiks kokioms verslo užduotims, kaip sukurti visą procesą ir pan. CTO taip pat atsakingas už biudžeto sudarymą. Pavyzdžiui, jis turi suprasti, kiek pinigų reikia išleisti specialistų perkvalifikavimui, kad jie galėtų dirbti „DevOps“.
Jei turite ką pasakyti šiais klausimais, netylėkite, . Kvietimo pateikti dokumentus galutinis terminas yra rugpjūčio 20 d. Kuo anksčiau užsiregistruosite, tuo daugiau laiko turėsite užbaigti ataskaitą ir pasiruošti pristatymui. Taigi, nedelskite.
Na, jei jums nereikia viešai kalbėti, tiesiog ir atvykti rugsėjo 30 ir spalio 1 dienomis pabendrauti su kolegomis. Pažadame, kad bus įdomu ir įkvepianti.
Kaip matome „DevOps“.
Norėdami tiksliai suprasti, ką turime omenyje „DevOps“, rekomenduoju perskaityti (arba dar kartą perskaityti) mano ataskaitą.“ Vaikščiodamas per rinkos bangas stebėjau, kaip DevOps idėja transformavosi įvairaus dydžio įmonėse: nuo mažo startuolio iki tarptautinių įmonių. Ataskaita sudaryta iš daugybės klausimų, į kuriuos atsakę galite suprasti, ar jūsų įmonė juda DevOps link, ar kažkur yra problemų.
„DevOps“ yra sudėtinga sistema, joje turi būti:
- Skaitmeninis produktas.
- Verslo moduliai, kuriantys šį skaitmeninį produktą.
- Produktų komandos, kurios rašo kodą.
- Nuolatinio pristatymo praktika.
- Platformos kaip paslauga.
- Infrastruktūra kaip paslauga.
- Infrastruktūra kaip kodas.
- Atskiros praktikos patikimumui palaikyti, integruotos į „DevOps“.
- Visa tai apibūdinanti grįžtamojo ryšio praktika.
Ataskaitos pabaigoje yra diagrama, kuri suteikia idėją apie DevOps sistemą įmonėje. Tai leis jums pamatyti, kurie procesai jūsų įmonėje jau supaprastinti, o kurie dar turi būti sukurti.
Galite žiūrėti reportažo vaizdo įrašą .
O dabar bus premija: keli vaizdo įrašai iš RIT++ 2019, kuriuose paliečiamos bendriausios „DevOps“ transformacijos problemos.
Įmonės infrastruktūra kaip produktas
Artyom Naumenko vadovauja DevOps komandai Skyeng ir rūpinasi savo įmonės infrastruktūros plėtra. Jis papasakojo, kaip infrastruktūra veikia verslo procesus SkyEng: kaip apskaičiuoti jos investicijų grąžą, kokius rodiklius skaičiuoti ir kaip juos tobulinti.
Kelyje į mikroservisus
„Nixys“ įmonė teikia palaikymą užimtiems interneto projektams ir paskirstytoms sistemoms. Jos techninis direktorius Borisas Ershovas papasakojo, kaip programinės įrangos produktus, kurių kūrimas prasidėjo prieš 5 metus (ar net daugiau), į modernią platformą.
Paprastai tokie projektai yra ypatingas pasaulis, kuriame yra tokių tamsių ir senovinių infrastruktūros kampelių, apie kuriuos dabartiniai inžinieriai nežino. O kažkada pasirinktos architektūros ir plėtros požiūriai yra pasenę ir negali užtikrinti verslui tokio pat tempo plėtros ir naujų versijų išleidimo. Dėl to kiekvienas gaminio išleidimas virsta neįtikėtinu nuotykiu, kai nuolat kažkas nukrenta ir pačioje netikėčiausioje vietoje.
Tokių projektų vadovai neišvengiamai susiduria su būtinybe pertvarkyti visus technologinius procesus. Savo pranešime Borisas sakė:
- kaip pasirinkti tinkamą projekto architektūrą ir sutvarkyti infrastruktūrą;
- kokius įrankius naudoti ir su kokiais spąstais susiduriama transformacijos kelyje;
- ką daryti toliau.
Išleidimo automatizavimas arba kaip pristatyti greitai ir neskausmingai
Aleksandras Korotkovas yra pirmaujantis CI/CD sistemos kūrėjas CIAN. Jis kalbėjo apie automatizavimo įrankius, kurie leido pagerinti kokybę ir sutrumpinti kodo pristatymo į gamybą laiką 5 kartus. Tačiau vien automatizuojant tokių rezultatų nepavyko pasiekti, todėl Aleksandras atkreipė dėmesį ir į plėtros procesų pokyčius.
Kaip nelaimingi atsitikimai padeda mokytis?
Aleksejus Kirpichnikovas „SKB Kontur“ diegia „DevOps“ ir infrastruktūrą 5 metus. Per trejus metus jo įmonėje įvyko maždaug 1000 įvairaus laipsnio epiškumo fakapų. Pavyzdžiui, 36 % jų lėmė žemos kokybės versijos išleidimas į gamybą, o 14 % – dėl aparatinės įrangos priežiūros darbų duomenų centre.
Ataskaitų (pomirtinių) archyvas, kurį įmonės inžinieriai tvarko jau keletą metų iš eilės, leidžia gauti tokią tikslią informaciją apie avarijas. Pomirtinį rašo budintis inžinierius, kuris pirmasis sureagavo į avarinį signalą ir pradėjo viską taisyti. Kam kankinti inžinierius, kurie naktį kovoja su veideliais rašydami ataskaitas? Šie duomenys leidžia matyti visą vaizdą ir nukreipti infrastruktūros plėtrą tinkama linkme.
Savo kalboje Aleksejus pasidalijo, kaip parašyti tikrai naudingą postmortem ir kaip įgyvendinti tokių ataskaitų praktiką didelėje įmonėje. Jei jums patinka pasakojimai apie tai, kaip kažkas pasisuko, pažiūrėkite spektaklio vaizdo įrašą.
Suprantame, kad jūsų „DevOps“ vizija gali nesutapti su mūsų. Bus įdomu sužinoti, kaip matote „DevOps“ transformaciją. Pasidalinkite savo patirtimi ir vizija šia tema komentaruose.
Kokias ataskaitas jau priėmėme į programą?
Šią savaitę Programos komitetas priėmė 4 ataskaitas: apie saugumą, infrastruktūrą ir SRE praktiką.
Bene skaudžiausia „DevOps“ transformacijos tema: kaip užtikrinti, kad informacijos saugumo skyriaus vaikinai nesunaikintų jau nutiestų kūrimo, eksploatavimo ir administravimo sąsajų. Kai kurios įmonės išsilaiko be informacijos saugos skyriaus. Kaip tokiu atveju užtikrinti informacijos saugumą? Apie tai Mona Arkhipova iš sudo.su. Iš jos pranešimo sužinome:
- ką ir nuo ko reikia saugoti;
- kokie yra įprasti saugumo procesai;
- kaip susikerta IT ir informacijos saugumo procesai;
- kas yra CIS CSC ir kaip ją įgyvendinti;
- kaip ir pagal kokius rodiklius atlikti reguliarius informacijos saugumo patikrinimus.
Kita ataskaita susijusi su infrastruktūros, kaip kodo, plėtra. Sumažinkite rankinio darbo kasdienybę ir nepaverskite viso projekto chaosu, ar tai įmanoma? Į šį klausimą Maksimas Kostrikinas iš Ixtens. Jo įmonė naudoja Terraformas darbui su AWS infrastruktūra. Įrankis patogus, tačiau kyla klausimas, kaip naudojant jį nesudaryti didžiulio kodo bloko. Tokio palikimo išlaikymas kasmet brangs.
„Maxim“ parodys, kaip veikia kodo išdėstymo modeliai, kuriais siekiama supaprastinti automatizavimą ir plėtrą.
Kitas išgirsime apie infrastruktūrą Vladimiras Ryabovas iš „Playkey“.. Čia kalbėsime apie infrastruktūros platformą ir sužinosime:
- kaip suprasti, ar saugojimo vieta naudojama efektyviai;
- kaip keli šimtai vartotojų gali gauti 10 TB turinio, jei naudojama tik 20 TB saugyklos;
- kaip 5 kartus suspausti duomenis ir pateikti juos vartotojams realiu laiku;
- kaip sinchronizuoti duomenis tarp kelių duomenų centrų;
- kaip nuosekliai naudojant vieną virtualią mašiną pašalinti bet kokią vartotojų įtaką vienas kitam.
Šios magijos paslaptis yra technologijos ZFS, skirtas FreeBSD ir jo šviežia šakutė ZFS sistemoje „Linux“. Vladimiras dalinsis atvejais iš Playkey.
Matvey Kukuy iš Amixr.IO paruoštas su pavyzdžiais iš gyvenimo , kas nutiko SRE ir kaip tai padeda sukurti patikimas sistemas. „Amixr.IO“ perduoda klientų incidentus per savo užpakalinę programą, dešimtys budinčių komandų visame pasaulyje jau išnagrinėjo 150 tūkst. Konferencijoje Matvey pasidalins statistika ir įžvalgomis, kurias jo įmonė sukaupė spręsdama klientų problemas ir analizuodama gedimus.
Dar kartą raginu nebūti godiems ir dalintis savo, kaip DevOps samurajaus, patirtimi. Tarnauti už pranešimą, o jūs ir aš turėsime 2,5 mėnesio, kad paruoštume puikią kalbą. Jei nori būti klausytojas, naujienlaiškį su programos atnaujinimais ir rimtai pagalvokite apie bilietų rezervavimą iš anksto, nes artėjant konferencijos datoms jie brangs.
Šaltinis: www.habr.com