Puhumme tietysti noin . Jos et mene yksityiskohtiin, niin järjestämme 30. ja 1. konferenssin kehitys-, testaus- ja käyttöprosessien yhdistämisestä, ja jos mennään yksityiskohtiin, niin olkaa hyvät, cat.
Osana DevOps-lähestymistapaa kaikki projektin teknologisen kehityksen osat kietoutuvat toisiinsa, tapahtuvat rinnakkain ja vaikuttavat toisiinsa. Tässä on erityisen tärkeää luoda automatisoituja kehitysprosesseja, joita voidaan muuttaa, simuloida ja testata reaaliajassa. Tämä auttaa sinua reagoimaan välittömästi markkinoiden muutoksiin.
Konferenssissa haluamme näyttää kuinka tämä lähestymistapa vaikuttaa tuotekehitykseen. Miten varmistetaan järjestelmän luotettavuus ja soveltuvuus asiakkaalle. Kuinka DevOps muuttaa yrityksen rakennetta ja lähestymistapaa työprosessin organisointiin.
kulissien takana
Meidän on tärkeää tietää paitsi mitä eri yritykset tekevät DevOps-lähestymistavan puitteissa, myös ymmärtää, miksi kaikki tämä tehdään. Siksi emme kutsuneet ohjelmakomiteaan vain asiantuntijoita, vaan asiantuntijoita, jotka näkevät DevOps-diskurssin eri paikoista:
- vanhempi insinöörit;
- kehittäjät;
- joukkueen johtajat;
- CTO.
Toisaalta tämä aiheuttaa vaikeuksia ja ristiriitoja raporttipyyntöjen käsittelyssä. Jos insinööri on kiinnostunut suuronnettomuuden analysoinnista, on tärkeämpää, että kehittäjä ymmärtää, kuinka luoda ohjelmistoja, jotka toimivat pilvissä ja infrastruktuureissa. Mutta sopimalla luomme ohjelman, joka on arvokas ja kiinnostava kaikille: insinööreistä teknologiajohtajaan.
Konferenssimme tavoitteena ei ole vain valita hype-raportteja, vaan esittää kokonaiskuva: miten DevOps-lähestymistapa toimii käytännössä, millaiseen rakeeseen voit törmätä siirtyessäsi uusiin prosesseihin. Samanaikaisesti rakennamme sisältöosan siirtymällä liiketoimintaongelmasta tiettyihin teknologioihin.
Konferenssiosastot pysyvät samoina kuin vuonna XNUMX .
- Infrastruktuurialusta.
- Infrastruktuuri koodina.
- Jatkuva toimitus.
- Palaute.
- Arkkitehtuuri DevOpsissa, DevOps CTO:lle.
- SRE-käytännöt.
- Koulutus ja tiedonhallinta.
- Turvallisuus, DevSecOps.
- DevOps-muunnos.
Call for Papers: millaisia raportteja etsimme
Jaoimme konferenssin potentiaalisen yleisön ehdollisesti viiteen ryhmään: insinöörit, kehittäjät, turvallisuusasiantuntijat, tiimin johtajat ja teknologiajohtaja. Jokaisella ryhmällä on oma motivaationsa tulla konferenssiin. Ja jos tarkastelet DevOpsia näistä paikoista, voit ymmärtää, miten voit keskittyä aiheeseen ja mihin painottaa.
Insinööreille, jotka luovat infrastruktuurialustaa, on tärkeää ymmärtää nykyiset trendit ja ymmärtää, mitkä tekniikat ovat nyt edistyneimpiä. He ovat kiinnostuneita oppimaan tosielämän kokemuksia näiden teknologioiden käytöstä ja vaihtamaan mielipiteitä. Insinööri kuuntelee mielellään jotain vakavaa onnettomuutta analysoivaa raporttia, ja me puolestaan yritämme valita ja hioa sellaisen raportin.
Kehittäjille on tärkeää ymmärtää sellainen käsite kuin natiivi pilvisovellus. Eli kuinka kehittää ohjelmistoja niin, että se toimii pilvissä ja erilaisissa infrastruktuureissa. Kehittäjän on saatava jatkuvasti palautetta ohjelmistosta. Täällä haluamme kuulla tapauksia siitä, kuinka yritykset rakentavat tätä prosessia, kuinka valvotaan ohjelmistojen suorituskykyä ja kuinka koko toimitusprosessi toimii.
Kyberturvallisuuden asiantuntijat On tärkeää ymmärtää, miten turvallisuusprosessi asetetaan niin, että se ei hidasta kehitys- ja muutosprosesseja yrityksen sisällä. Aiheet vaatimuksista, joita DevOps asettaa tällaisille asiantuntijoille, ovat myös mielenkiintoisia.
Ryhmän johtajat haluavat tietää, miten jatkuva toimitusprosessi toimii muissa yrityksissä. Mitä polkua yritykset kulkivat saavuttaakseen tämän, miten he rakensivat kehitys- ja laadunvarmistusprosesseja DevOpsissa. Myös tiiminjohtajat ovat kiinnostuneita Cloud-natiiviversiosta. Ja myös kysymyksiä vuorovaikutuksesta tiimin sisällä sekä kehitys- ja suunnittelutiimien välillä.
varten CTO Tärkeintä on selvittää, miten kaikki nämä prosessit yhdistetään ja mukautetaan liiketoiminnan tarpeisiin. Hän varmistaa, että sovellus on luotettava sekä yritykselle että asiakkaalle. Ja tässä sinun on ymmärrettävä, mitkä tekniikat toimivat missäkin liiketoimintatehtävissä, kuinka rakentaa koko prosessi jne. Teknologiajohtaja vastaa myös budjetoinnista. Hänen on esimerkiksi ymmärrettävä, kuinka paljon rahaa on käytettävä asiantuntijoiden uudelleenkoulutukseen, jotta he voivat työskennellä DevOpsissa.
Jos sinulla on jotain sanottavaa näistä asioista, älä ole hiljaa, . Haun määräaika on 20. elokuuta. Mitä aikaisemmin rekisteröidyt, sitä enemmän sinulla on aikaa viimeistellä raporttisi ja valmistautua esitykseen. Joten älä viivyttele.
No, jos sinulla ei ole tarvetta puhua julkisesti, vain ja tule 30. syyskuuta ja 1. lokakuuta kommunikoimaan kollegoiden kanssa. Lupaamme, että se on mielenkiintoinen ja inspiroiva.
Kuinka näemme DevOpsin
Ymmärtääksesi tarkalleen, mitä tarkoitamme DevOpsilla, suosittelen lukemaan (tai lukemaan uudelleen) raporttini." Kävellessäni markkinoiden aaltojen läpi huomasin kuinka DevOps-idea oli muuttumassa erikokoisissa yrityksissä: pienestä startupista monikansallisiin yrityksiin. Raportti rakentuu joukolle kysymyksiä, joihin vastaamalla ymmärrät, onko yrityksesi menossa kohti DevOpsia vai onko jossain ongelmia.
DevOps on monimutkainen järjestelmä, jonka tulee sisältää:
- Digitaalinen tuote.
- Liiketoimintamoduulit, jotka kehittävät tätä digitaalista tuotetta.
- Tuoteryhmät, jotka kirjoittavat koodia.
- Jatkuva toimituskäytäntö.
- Alustat palveluna.
- Infrastruktuuri palveluna.
- Infrastruktuuri koodina.
- Erilliset käytännöt luotettavuuden ylläpitämiseksi, sisäänrakennettu DevOpsiin.
- Palautekäytäntö, joka kuvaa kaiken.
Raportin lopussa on kaavio, joka antaa kuvan DevOps-järjestelmästä yrityksessä. Sen avulla näet, mitkä prosessit yrityksessäsi on jo virtaviivaistettu ja mitkä ovat vielä rakentamatta.
Voit katsoa raportin videon .
Ja nyt tulee bonus: useita RIT++ 2019 -videoita, jotka käsittelevät yleisimpiä DevOps-muutoksen kysymyksiä.
Yrityksen infrastruktuuri tuotteena
Artjom Naumenko johtaa DevOps-tiimiä Skyengissä ja huolehtii yrityksensä infrastruktuurin kehittämisestä. Hän kertoi, miten infrastruktuuri vaikuttaa liiketoimintaprosesseihin SkyEngillä: miten sille lasketaan ROI, mitä mittareita laskennassa kannattaa valita ja miten niitä parantaa.
Matkalla mikropalveluihin
Nixys-yritys tarjoaa tukea kiireisille verkkoprojekteille ja hajautetuille järjestelmille. Sen tekninen johtaja Boris Ershov kertoi, kuinka ohjelmistotuotteet, joiden kehitys alkoi 5 vuotta sitten (tai jopa enemmän), voidaan kääntää nykyaikaiselle alustalle.
Yleensä tällaiset projektit ovat erityinen maailma, jossa on niin synkkiä ja ikivanhoja infrastruktuurin kulmia, joita nykyiset insinöörit eivät tiedä niistä. Ja aikoinaan valitut lähestymistavat arkkitehtuuriin ja kehittämiseen ovat vanhentuneita eivätkä pysty tarjoamaan yrityksille samaa kehitystahtia ja uusien versioiden julkaisemista. Tämän seurauksena jokainen tuotejulkaisu muuttuu uskomattomaksi seikkailuksi, jossa jotain putoaa jatkuvasti ja mitä odottamattomimmassa paikassa.
Tällaisten hankkeiden johtajilla on väistämättä tarve muuttaa kaikkia teknisiä prosesseja. Raportissaan Boris sanoi:
- kuinka valita oikea arkkitehtuuri projektille ja saada infrastruktuuri kuntoon;
- mitä työkaluja käyttää ja mitä sudenkuoppia kohdataan muutoksen tiellä;
- mitä tehdä seuraavaksi.
Julkaisujen automatisointi tai nopea ja kivuton toimitus
Alexander Korotkov on johtava CI/CD-järjestelmän kehittäjä CIANissa. Hän puhui automaatiotyökaluista, joiden avulla oli mahdollista parantaa laatua ja lyhentää koodin tuotantoon kuluvaa aikaa viisinkertaiseksi. Mutta tällaisia tuloksia ei voitu saavuttaa pelkällä automaatiolla, joten Alexander kiinnitti huomiota myös kehitysprosessien muutoksiin.
Miten onnettomuudet auttavat sinua oppimaan?
Alexey Kirpichnikov on toteuttanut DevOpsia ja infrastruktuuria SKB Konturilla 5 vuoden ajan. Kolmen vuoden aikana hänen yrityksessään tapahtui noin 1000 36 eriasteista fakaapia. Niistä esimerkiksi 14 % johtui huonolaatuisen julkaisun ottamisesta tuotantoon ja XNUMX % konesalin laitteistohuoltotöistä.
Selvitysarkisto (post mortem), jota yrityksen insinöörit ovat ylläpitäneet useita vuosia peräkkäin, mahdollistaa näin tarkan tiedon saamisen onnettomuuksista. Post mortemin kirjoittaa päivystävä insinööri, joka reagoi ensimmäisenä hätämerkkiin ja alkoi korjata kaikkea. Miksi kiusata insinöörejä, jotka kamppailevat kasvojen kanssa yöllä kirjoittamalla raportteja? Näiden tietojen avulla voit nähdä kokonaisuuden ja siirtää infrastruktuurin kehittämistä oikeaan suuntaan.
Puheessaan Aleksei kertoi kuinka kirjoittaa todella hyödyllinen post mortem ja kuinka toteuttaa tällaisten raporttien käytäntö suuressa yrityksessä. Jos pidät tarinoista siitä, kuinka joku meni pilalle, katso video esityksestä.
Ymmärrämme, että visiosi DevOpsista ei välttämättä vastaa meidän visiotamme. On mielenkiintoista tietää, kuinka näet DevOps-muunnoksen. Jaa kokemuksesi ja näkemyksesi tästä aiheesta kommenteissa.
Mitä raportteja olemme jo hyväksyneet ohjelmaan?
Tällä viikolla ohjelmakomitea hyväksyi 4 raporttia: turvallisuudesta, infrastruktuurista ja SRE-käytännöistä.
DevOps-muutoksen ehkä tuskallisin aihe: kuinka varmistaa, että tietoturvaosaston tyypit eivät tuhoa jo rakennettuja yhteyksiä kehityksen, toiminnan ja hallinnon välillä. Jotkut yritykset pärjäävät ilman tietoturvaosastoa. Miten varmistetaan tietoturva tässä tapauksessa? Siitä Mona Arkhipova sudo.su:sta. Hänen raportistaan opimme:
- mitä on suojeltava ja keneltä;
- mitkä ovat rutiiniturvaprosessit;
- miten IT- ja tietoturvaprosessit kohtaavat;
- mikä on CIS CSC ja miten se toteutetaan;
- miten ja millä mittareilla tehdä säännöllisiä tietoturvatarkastuksia.
Seuraava raportti koskee infrastruktuurin kehittämistä koodina. Vähennä manuaalisten rutiinien määrää äläkä muuta koko projektia kaaokseksi, onko tämä mahdollista? Tähän kysymykseen Maxim Kostrikin Ixtensistä. Hänen yrityksensä käyttää terraform AWS-infrastruktuurin kanssa työskentelemiseen. Työkalu on kätevä, mutta kysymys on siitä, kuinka välttää valtavan koodilohkon luominen sitä käytettäessä. Tällaisen perinnön ylläpito tulee joka vuosi entistä kalliimmaksi.
Maxim näyttää, kuinka koodin sijoittelumallit toimivat, ja niiden tarkoituksena on yksinkertaistaa automaatiota ja kehitystä.
Toinen kuulemme infrastruktuurista Vladimir Ryabov Playkeystä. Täällä puhumme infrastruktuurialustasta ja opimme:
- kuinka ymmärtää, käytetäänkö tallennustilaa tehokkaasti;
- kuinka useat sadat käyttäjät voivat vastaanottaa 10 Tt sisältöä, jos käytetään vain 20 Tt tallennustilaa;
- kuinka pakata tiedot 5 kertaa ja tarjota se käyttäjille reaaliajassa;
- kuinka synkronoida tietoja lennossa useiden datakeskusten välillä;
- kuinka poistaa käyttäjien vaikutus toisiinsa käytettäessä yhtä virtuaalikonetta peräkkäin.
Tämän taikuuden salaisuus on tekniikka ZFS FreeBSD:lle ja sen tuore haarukka ZFS Linuxissa. Vladimir jakaa tapauksia Playkeystä.
Matvey Kukuy, Amixr.IO valmis esimerkkien kanssa elämästä , mitä SRE ja kuinka se auttaa luomaan luotettavia järjestelmiä. Amixr.IO välittää asiakastapaukset taustajärjestelmänsä kautta; kymmenet päivystävät tiimit ympäri maailmaa ovat jo käsitelleet 150 tuhatta tapausta. Konferenssissa Matvey jakaa tilastoja ja näkemyksiä, joita hänen yrityksensä on kertynyt ratkaisemalla asiakkaiden ongelmia ja analysoimalla epäonnistumisia.
Kehotan sinua jälleen kerran olemaan ahne ja jakamaan kokemuksesi DevOps-samuraina. Palvella raporttia varten, ja sinulla ja minulla on 2,5 kuukautta aikaa valmistella erinomainen puhe. Jos haluat olla kuuntelija, ohjelmapäivityksiä sisältävään uutiskirjeeseen ja harkitse vakavasti lippujen varaamista etukäteen, sillä ne tulevat kalliiksi lähempänä konferenssipäiviä.
Lähde: will.com