Dit gaan natuurlik oor . As jy nie in besonderhede ingaan nie, dan hou ons op 30 September en 1 Oktober 'n konferensie oor die kombinasie van die prosesse van ontwikkeling, toetsing en werking, en as jy in besonderhede ingaan, asseblief, onder kat.
Binne die DevOps-benadering is alle dele van die projek se tegnologiese ontwikkeling verweef, vind parallel plaas en beïnvloed mekaar. Van besondere belang hier is die skepping van geoutomatiseerde ontwikkelingsprosesse wat intyds verander, gesimuleer en getoets kan word. Dit help jou om onmiddellik op veranderinge in die mark te reageer.
By die konferensie wil ons wys hoe hierdie benadering produkontwikkeling beïnvloed. Hoe die betroubaarheid en aanpasbaarheid van die stelsel vir die kliënt verseker word. Hoe DevOps die struktuur en benadering van 'n maatskappy verander om sy werkproses te organiseer.
agter die skerms
Dit is vir ons belangrik om nie net te weet wat verskillende maatskappye doen binne die raamwerk van die DevOps-benadering nie, maar ook om te verstaan hoekom dit alles gedoen word. Daarom het ons nie net kundiges genooi om by die Programkomitee aan te sluit nie, maar spesialiste wat die DevOps-diskoers vanuit verskillende posisies sien:
- senior ingenieurs;
- ontwikkelaars;
- span lei;
- CTO.
Aan die een kant skep dit probleme en konflikte wanneer versoeke om verslae bespreek word. As 'n ingenieur daarin belangstel om 'n groot ongeluk te ontleed, dan is dit belangriker vir 'n ontwikkelaar om te verstaan hoe om sagteware te skep wat in wolke en infrastruktuur werk. Maar deur in te stem, skep ons 'n program wat vir almal waardevol en interessant sal wees: van ingenieurs tot CTO.
Die doel van ons konferensie is nie net om die meeste hype-verslae te kies nie, maar om die algehele prentjie voor te stel: hoe die DevOps-benadering in die praktyk werk, watter soort hark jy kan raakloop wanneer jy na nuwe prosesse beweeg. Terselfdertyd bou ons die inhoudsdeel, en gaan van die besigheidsprobleem af na spesifieke tegnologieë.
Die konferensie-afdelings sal dieselfde bly as in .
- Infrastruktuur platform.
- Infrastruktuur as kode.
- Deurlopende aflewering.
- Terugvoer.
- Argitektuur in DevOps, DevOps vir CTO.
- SRE-praktyke.
- Opleiding en kennisbestuur.
- Sekuriteit, DevSecOps.
- DevOps transformasie.
Call for Papers: watter soort verslae ons soek
Ons het die potensiële gehoor van die konferensie voorwaardelik in vyf groepe verdeel: ingenieurs, ontwikkelaars, sekuriteitspesialiste, spanleiers en CTO. Elke groep het sy eie motivering om na die konferensie te kom. En as jy vanuit hierdie posisies na DevOps kyk, kan jy verstaan hoe om jou onderwerp te fokus en waar om klem te lê.
Vir ingenieurs, wat 'n infrastruktuurplatform skep, is dit belangrik om die bestaande tendense te verstaan, om te verstaan watter tegnologie nou die mees gevorderde is. Hulle sal belangstel om te leer oor werklike ervaring in die gebruik van hierdie tegnologieë en om menings uit te ruil. 'n Ingenieur sal met graagte na 'n verslag luister wat een of ander hardcore ongeluk ontleed, en ons sal op ons beurt probeer om so 'n verslag te kies en te poets.
Vir ontwikkelaars dit is belangrik om so 'n konsep te verstaan soos wolk inheemse toepassing. Dit wil sê hoe om sagteware te ontwikkel sodat dit in wolke en verskeie infrastruktuur werk. Die ontwikkelaar moet voortdurend terugvoer van die sagteware ontvang. Hier wil ons gevalle hoor oor hoe maatskappye hierdie proses bou, hoe om sagtewareprestasie te monitor en hoe die hele afleweringsproses werk.
Kuberveiligheidspesialiste Dit is belangrik om te verstaan hoe om die sekuriteitsproses op te stel sodat dit nie die ontwikkelings- en veranderingsprosesse binne die maatskappy stuit nie. Onderwerpe oor die vereistes wat DevOps aan sulke spesialiste stel, sal ook interessant wees.
Spanleiers wil weet, hoe die deurlopende afleweringsproses in ander maatskappye werk. Watter pad het maatskappye geneem om dit te bereik, hoe het hulle ontwikkelings- en gehalteversekeringsprosesse binne DevOps gebou. Spanleiers stel ook belang in Cloud native. En ook vrae oor interaksie binne die span en tussen ontwikkeling- en ingenieurspanne.
Vir CTO die belangrikste ding is om uit te vind hoe om al hierdie prosesse te verbind en hulle aan te pas by besigheidsbehoeftes. Hy maak seker dat die toepassing betroubaar is vir beide die besigheid en die kliënt. En hier moet jy verstaan watter tegnologieë sal werk vir watter besigheidstake, hoe om die hele proses te bou, ens. Die CTO is ook verantwoordelik vir begroting. Hy moet byvoorbeeld verstaan hoeveel geld aan heropleiding van spesialiste bestee moet word sodat hulle in DevOps kan werk.
As jy iets oor hierdie sake te sê het, moenie stilbly nie, . Die sperdatum vir Call for Papers is 20 Augustus. Hoe vroeër jy registreer, hoe meer tyd sal jy hê om jou verslag te finaliseer en vir jou aanbieding voor te berei. So, moenie uitstel nie.
Wel, as jy nie 'n behoefte het om in die openbaar te praat nie, net en kom op 30 September en 1 Oktober om met kollegas te kommunikeer. Ons belowe dit sal interessant en inspirerend wees.
Hoe ons DevOps sien
Om presies te verstaan wat ons met DevOps bedoel, beveel ek aan om my verslag te lees (of weer te lees)." Terwyl ek deur die golwe van die mark gestap het, het ek opgemerk hoe die idee van DevOps besig was om te transformeer in maatskappye van verskillende groottes: van 'n klein begin tot multinasionale maatskappye. Die verslag is gebou op 'n reeks vrae, deur dit te beantwoord kan jy verstaan of jou maatskappy na DevOps beweeg en of daar iewers probleme is.
DevOps is 'n komplekse stelsel, dit moet die volgende insluit:
- Digitale produk.
- Besigheidsmodules wat hierdie digitale produk ontwikkel.
- Produkspanne wat kode skryf.
- Deurlopende afleweringspraktyke.
- Platforms as 'n diens.
- Infrastruktuur as 'n diens.
- Infrastruktuur as kode.
- Afsonderlike praktyke vir die handhawing van betroubaarheid, ingebou in DevOps.
- 'n Terugvoerpraktyk wat dit alles beskryf.
Aan die einde van die verslag is daar 'n diagram wat 'n idee gee van die DevOps-stelsel in die maatskappy. Dit sal jou toelaat om te sien watter prosesse in jou maatskappy reeds gestroomlyn is en watter nog gebou moet word.
Jy kan die video van die verslag kyk .
En nou sal daar 'n bonus wees: verskeie video's van RIT++ 2019, wat die mees algemene kwessies van DevOps-transformasie raak.
Maatskappy-infrastruktuur as 'n produk
Artyom Naumenko lei die DevOps-span by Skyeng en sorg vir die ontwikkeling van sy maatskappy se infrastruktuur. Hy het vertel hoe infrastruktuur sakeprosesse by SkyEng beïnvloed: hoe om ROI daarvoor te bereken, watter maatstawwe gekies moet word vir berekening en hoe om te werk om dit te verbeter.
Op pad na mikrodienste
Nixys-maatskappy bied ondersteuning vir besige webprojekte en verspreide stelsels. Sy tegniese direkteur, Boris Ershov, het vertel hoe om sagtewareprodukte, waarvan die ontwikkeling 5 jaar gelede (of selfs meer) begin is, na 'n moderne platform te vertaal.
As 'n reël is sulke projekte 'n spesiale wêreld waar daar sulke donker en ou hoeke van die infrastruktuur is dat huidige ingenieurs nie daarvan weet nie. En die benaderings tot argitektuur en ontwikkeling wat eens gekies is, is verouderd en kan nie dieselfde tempo van ontwikkeling en vrystelling van nuwe weergawes aan die onderneming bied nie. As gevolg hiervan, verander elke produkvrystelling in 'n ongelooflike avontuur, waar iets voortdurend afval, en op die mees onverwagte plek.
Bestuurders van sulke projekte het onvermydelik die behoefte om alle tegnologiese prosesse te transformeer. In sy verslag het Boris gesê:
- hoe om die regte argitektuur vir die projek te kies en die infrastruktuur in orde te bring;
- watter gereedskap om te gebruik en watter slaggate op die pad na transformasie teëgekom word;
- wat om volgende te doen.
Outomatisering van vrystellings of hoe om vinnig en pynloos af te lewer
Alexander Korotkov is 'n toonaangewende ontwikkelaar van die CI/CD-stelsel by CIAN. Hy het gepraat oor outomatiseringsinstrumente wat dit moontlik gemaak het om kwaliteit te verbeter en die tyd vir die aflewering van kode na produksie met 5 keer te verminder. Maar sulke resultate kon nie met outomatisering alleen bereik word nie, so Alexander het ook aandag gegee aan veranderinge in ontwikkelingsprosesse.
Hoe help ongelukke jou om te leer?
Alexey Kirpichnikov implementeer al 5 jaar DevOps en infrastruktuur by SKB Kontur. In die loop van drie jaar het ongeveer 1000 36 fakaps van verskillende grade van episiteit in sy geselskap voorgekom. Onder hulle is 14% byvoorbeeld veroorsaak deur die uitrol van 'n lae-gehalte vrystelling in produksie, en XNUMX% is veroorsaak deur hardeware instandhoudingswerk in die datasentrum.
’n Argief van verslae (nadoodse ondersoeke) wat die maatskappy se ingenieurs al etlike jare agtereenvolgens in stand hou, maak dit moontlik om sulke akkurate inligting oor ongelukke te bekom. Die nadoodse ondersoek word geskryf deur die ingenieur aan diens, wat die eerste was wat op die noodsein gereageer het en alles begin regmaak het. Hoekom pynig ingenieurs wat snags met facaps sukkel deur verslae te skryf? Hierdie data laat jou toe om die geheelbeeld te sien en infrastruktuurontwikkeling in die regte rigting te beweeg.
In sy toespraak het Alexey gedeel hoe om 'n werklik nuttige nadoodse ondersoek te skryf en hoe om die praktyk van sulke verslae in 'n groot maatskappy te implementeer. As jy van stories hou oor hoe iemand gemors het, kyk na die video van die optrede.
Ons verstaan dat jou visie van DevOps dalk nie met ons s'n ooreenstem nie. Dit sal interessant wees om te weet hoe jy DevOps-transformasie sien. Deel jou ervaring en visie van hierdie onderwerp in die kommentaar.
Watter verslae het ons reeds in die program aanvaar?
Hierdie week het die Programkomitee 4 verslae aanvaar: oor sekuriteit, infrastruktuur en SRE-praktyke.
Miskien die pynlikste onderwerp van DevOps-transformasie: hoe om seker te maak dat die ouens van die inligtingsekuriteitsafdeling nie die reeds geboude verbindings tussen ontwikkeling, bedryf en administrasie vernietig nie. Sommige maatskappye bestuur sonder 'n inligtingsekuriteitsafdeling. Hoe om inligtingsekuriteit in hierdie geval te verseker? Daaroor Mona Arkhipova van sudo.su. Uit haar verslag leer ons:
- wat beskerm moet word en van wie;
- wat is die roetine sekuriteitsprosesse;
- hoe IT- en inligtingsekuriteitsprosesse mekaar kruis;
- wat is CIS CSC en hoe om dit te implementeer;
- hoe en volgens watter aanwysers om gereelde inligtingsekuriteitskontroles uit te voer.
Die volgende verslag handel oor die ontwikkeling van infrastruktuur as kode. Verminder die hoeveelheid handroetine en verander nie die hele projek in chaos nie, is dit moontlik? Op hierdie vraag Maxim Kostrikin van Ixtens. Sy maatskappy gebruik terraform vir werk met AWS-infrastruktuur. Die instrument is gerieflik, maar die vraag is hoe om 'n groot blok kode te vermy wanneer jy dit gebruik. Die instandhouding van so 'n nalatenskap sal elke jaar duurder word.
Maxim sal wys hoe kodeplasingspatrone werk, wat daarop gemik is om outomatisering en ontwikkeling te vereenvoudig.
Nog een ons sal hoor oor infrastruktuur van Vladimir Ryabov van Playkey. Hier sal ons praat oor die infrastruktuurplatform, en ons sal leer:
- hoe om te verstaan of stoorspasie doeltreffend gebruik word;
- hoe etlike honderde gebruikers 10 TB se inhoud kan ontvang as slegs 20 TB se berging gebruik word;
- hoe om data 5 keer saam te druk en dit intyds aan gebruikers te verskaf;
- hoe om data te sinchroniseer tussen verskeie datasentrums;
- hoe om enige invloed van gebruikers op mekaar uit te skakel wanneer een virtuele masjien opeenvolgend gebruik word.
Die geheim van hierdie magie is tegnologie ZFS vir FreeBSD en sy vars vurk ZFS op Linux. Vladimir sal sake van Playkey deel.
Matvey Kukuy van Amixr.IO gereed met voorbeelde uit die lewe , wat het gebeur SRE en hoe dit help om betroubare stelsels te bou. Amixr.IO stuur kliëntvoorvalle deur sy agterkant; dosyne aan diens spanne regoor die wêreld het reeds 150 duisend sake hanteer. By die konferensie sal Matvey die statistieke en insigte deel wat sy maatskappy opgehoop het deur klanteprobleme op te los en mislukkings te ontleed.
Weereens moedig ek jou aan om nie gulsig te wees nie en jou ervaring as 'n DevOps-samurai te deel. Bedien vir 'n verslag, en ek en jy sal 2,5 maande hê om 'n uitstekende toespraak voor te berei. As jy 'n luisteraar wil wees, na die nuusbrief met programopdaterings en dink ernstig daaraan om kaartjies voor die tyd te bespreek, want dit sal nader aan die konferensiedatums duurder word.
Bron: will.com