Vi pratar såklart om . Om du inte går in på detaljer kommer vi den 30 september och 1 oktober att hålla en konferens om att kombinera processerna för utveckling, testning och drift, och om du går in på detaljer, snälla, under kat.
Som en del av DevOps-ansatsen är alla delar av den tekniska utvecklingen av ett projekt sammanflätade, sker parallellt och påverkar varandra. Av särskild vikt här är skapandet av automatiserade utvecklingsprocesser som kan ändras, simuleras och testas i realtid. Detta hjälper dig att reagera omedelbart på förändringar på marknaden.
På konferensen vill vi visa hur detta synsätt påverkar produktutvecklingen. Hur tillförlitligheten och anpassningsförmågan hos systemet för kunden säkerställs. Hur DevOps förändrar ett företags struktur och tillvägagångssätt för att organisera sin arbetsprocess.
bakom kulisserna
Det är viktigt för oss att inte bara veta vad olika företag gör inom ramen för DevOps-ansatsen, utan också att förstå varför allt detta görs. Därför bjöd vi in inte bara experter att gå med i programkommittén, utan specialister som ser DevOps-diskursen från olika positioner:
- senior ingenjörer;
- utvecklare;
- teamledare;
- CTO.
Å ena sidan skapar detta svårigheter och konflikter när man diskuterar förfrågningar om anmälningar. Om en ingenjör är intresserad av att analysera en större olycka, då är det viktigare för en utvecklare att förstå hur man skapar mjukvara som fungerar i moln och infrastrukturer. Men genom att komma överens skapar vi ett program som kommer att vara värdefullt och intressant för alla: från ingenjörer till CTO.
Målet med vår konferens är inte bara att välja ut flest hyperapporter, utan att presentera den övergripande bilden: hur DevOps-metoden fungerar i praktiken, vilken typ av rake du kan stöta på när du går över till nya processer. Samtidigt bygger vi innehållsdelen och går ner från affärsproblem till specifika teknologier.
Konferenssektionerna kommer att förbli desamma som i .
- Infrastrukturplattform.
- Infrastruktur som kod.
- Kontinuerlig leverans.
- Kontakta oss.
- Arkitektur i DevOps, DevOps för CTO.
- SRE praxis.
- Utbildning och kunskapshantering.
- Säkerhet, DevSecOps.
- DevOps transformation.
Call for Papers: vilken typ av rapporter vi letar efter
Vi delade villkorligt in den potentiella publiken för konferensen i fem grupper: ingenjörer, utvecklare, säkerhetsspecialister, teamledare och CTO. Varje grupp har sin egen motivation att komma till konferensen. Och om du tittar på DevOps från dessa positioner kan du förstå hur du ska fokusera ditt ämne och var du ska lägga vikt.
För ingenjörer, som skapar en infrastrukturplattform är det viktigt att förstå de befintliga trenderna, att förstå vilka teknologier som nu är mest avancerade. De kommer att vara intresserade av att lära sig om verkliga erfarenheter av att använda dessa tekniker och utbyta åsikter. En ingenjör lyssnar gärna på en rapport som analyserar en hård kärnolycka, och vi kommer i sin tur att försöka välja ut och polera en sådan rapport.
För utvecklare det är viktigt att förstå ett sådant begrepp som molnbaserad applikation. Det vill säga hur man utvecklar mjukvara så att den fungerar i moln och olika infrastrukturer. Utvecklaren behöver ständigt få feedback från programvaran. Här vill vi höra case om hur företag bygger upp denna process, hur man övervakar mjukvarans prestanda och hur hela leveransprocessen fungerar.
Cybersäkerhetsspecialister Det är viktigt att förstå hur man lägger upp säkerhetsprocessen så att den inte stoppar utvecklings- och förändringsprocesserna inom företaget. Ämnen om de krav som DevOps ställer på sådana specialister kommer också att vara intressanta.
Teamledare vill veta, hur den kontinuerliga leveransprocessen fungerar i andra företag. Vilken väg tog företagen för att uppnå detta, hur byggde de utvecklings- och kvalitetssäkringsprocesser inom DevOps. Teamledare är också intresserade av Cloud native. Och även frågor om interaktion inom teamet och mellan utvecklings- och ingenjörsteam.
för CTO det viktigaste är att ta reda på hur man kopplar ihop alla dessa processer och anpassar dem till affärsbehov. Han ser till att applikationen är tillförlitlig för både verksamheten och kunden. Och här måste du förstå vilka teknologier som kommer att fungera för vilka affärsuppgifter, hur man bygger hela processen, etc. CTO ansvarar också för budgeteringen. Han måste till exempel förstå hur mycket pengar som behöver läggas på omskolning av specialister så att de kan arbeta i DevOps.
Om du har något att säga om dessa frågor, tiga inte, . Deadline för Call for Papers är den 20 augusti. Ju tidigare du registrerar dig, desto mer tid har du för att färdigställa din rapport och förbereda din presentation. Så, dröj inte.
Tja, om du inte har ett behov av att tala offentligt, bara och kom den 30 september och 1 oktober för att kommunicera med kollegor. Vi lovar att det kommer att bli intressant och inspirerande.
Hur vi ser på DevOps
För att förstå exakt vad vi menar med DevOps rekommenderar jag att du läser (eller läser om) min rapport "" När jag gick genom marknadens vågor observerade jag hur idén om DevOps förändrades i företag av olika storlekar: från en liten startup till multinationella företag. Rapporten bygger på en rad frågor, genom att svara på dem kan du förstå om ditt företag går mot DevOps eller om det finns problem någonstans.
DevOps är ett komplext system, det måste innehålla:
- Digital produkt.
- Affärsmoduler som utvecklar denna digitala produkt.
- Produktteam som skriver kod.
- Kontinuerlig leveranspraxis.
- Plattformar som en tjänst.
- Infrastruktur som en tjänst.
- Infrastruktur som kod.
- Separata metoder för att upprätthålla tillförlitlighet, inbyggd i DevOps.
- En feedbackpraxis som beskriver det hela.
I slutet av rapporten finns ett diagram som ger en uppfattning om DevOps-systemet i företaget. Det låter dig se vilka processer i ditt företag som redan har effektiviserats och vilka som ännu inte ska byggas.
Du kan se videon av rapporten .
Och nu kommer det att finnas en bonus: flera videor från RIT++ 2019, som berör de mest allmänna frågorna om DevOps-transformation.
Företagsinfrastruktur som produkt
Artyom Naumenko leder DevOps-teamet på Skyeng och tar hand om utvecklingen av sitt företags infrastruktur. Han berättade hur infrastruktur påverkar affärsprocesser på SkyEng: hur man beräknar ROI för det, vilka mätvärden som ska väljas för beräkning och hur man arbetar för att förbättra dem.
På väg mot mikrotjänster
Nixys företag tillhandahåller support för upptagna webbprojekt och distribuerade system. Dess tekniska chef, Boris Ershov, berättade hur man översätter mjukvaruprodukter, vars utveckling började för 5 år sedan (eller ännu mer), till en modern plattform.
Som regel är sådana projekt en speciell värld där det finns så mörka och gamla hörn av infrastrukturen att nuvarande ingenjörer inte känner till dem. Och tillvägagångssätten för arkitektur och utveckling som en gång valdes är föråldrade och kan inte ge verksamheten samma takt i utvecklingen och lanseringen av nya versioner. Som ett resultat förvandlas varje produktsläpp till ett otroligt äventyr, där något ständigt faller av, och på den mest oväntade platsen.
Chefer för sådana projekt står oundvikligen inför behovet av att omvandla alla tekniska processer. I sin rapport sa Boris:
- hur man väljer rätt arkitektur för projektet och gör ordning på infrastrukturen;
- vilka verktyg man ska använda och vilka fallgropar man stöter på på vägen till transformation;
- vad göra här näst.
Automatisering av releaser eller hur man levererar snabbt och smärtfritt
Alexander Korotkov är en ledande utvecklare av CI/CD-systemet på CIAN. Han talade om automationsverktyg som gjorde det möjligt att förbättra kvaliteten och minska tiden för leverans av kod till produktionen med 5 gånger. Men sådana resultat kunde inte uppnås med enbart automatisering, så Alexander uppmärksammade också förändringar i utvecklingsprocesser.
Hur hjälper olyckor dig att lära dig?
Alexey Kirpichnikov har implementerat DevOps och infrastruktur på SKB Kontur i 5 år. Under loppet av tre år inträffade ungefär 1000 36 fakaps av varierande grad av episkhet i hans företag. Bland dem orsakades till exempel 14 % av att en release av låg kvalitet lanserades i produktion, och XNUMX % orsakades av underhållsarbete på hårdvaran i datacentret.
Ett arkiv av rapporter (obduktioner) som företagets ingenjörer har fört flera år i rad gör det möjligt att få så korrekt information om olyckor. Obduktionen är skriven av vakthavande ingenjör, som var den första att svara på nödsignalen och började fixa allt. Varför plåga ingenjörer som kämpar på natten med facaps genom att skriva rapporter? Dessa data låter dig se hela bilden och flytta infrastrukturutvecklingen i rätt riktning.
I sitt tal delade Alexey hur man skriver en verkligt användbar postmortem och hur man implementerar praktiken av sådana rapporter i ett stort företag. Om du gillar berättelser om hur någon stökat till, se videon av föreställningen.
Vi förstår att din vision av DevOps kanske inte matchar vår. Det ska bli intressant att veta hur du ser på DevOps-transformationen. Dela din erfarenhet och vision av detta ämne i kommentarerna.
Vilka rapporter har vi redan accepterat i programmet?
Denna vecka antog programkommittén fyra rapporter: om säkerhet, infrastruktur och SRE-praxis.
Det kanske mest smärtsamma ämnet för DevOps transformation: hur man ser till att killarna från informationssäkerhetsavdelningen inte förstör de redan byggda kopplingarna mellan utveckling, drift och administration. Vissa företag klarar sig utan en informationssäkerhetsavdelning. Hur säkerställer man informationssäkerheten i detta fall? Om det Mona Arkhipova från sudo.su. Från hennes rapport lär vi oss:
- vad som behöver skyddas och från vem;
- vilka är de rutinmässiga säkerhetsprocesserna;
- hur IT- och informationssäkerhetsprocesser korsas;
- vad är CIS CSC och hur man implementerar det;
- hur och med vilka indikatorer man ska genomföra regelbundna informationssäkerhetskontroller.
Nästa rapport handlar om utvecklingen av infrastruktur som kod. Minska mängden manuell rutin och förvandla inte hela projektet till kaos, är detta möjligt? Till denna fråga Maxim Kostrikin från Ixtens. Hans företag använder Terraform för att arbeta med AWS-infrastruktur. Verktyget är bekvämt, men frågan är hur man undviker att skapa ett stort kodblock när man använder det. Underhållet av ett sådant arv kommer att bli dyrare och dyrare för varje år.
Maxim kommer att visa hur kodplaceringsmönster fungerar, som syftar till att förenkla automatisering och utveckling.
Annan vi kommer att höra om infrastruktur från Vladimir Ryabov från Playkey. Här kommer vi att prata om infrastrukturplattformen och vi kommer att lära oss:
- hur man förstår om lagringsutrymme används effektivt;
- hur flera hundra användare kan ta emot 10 TB innehåll om bara 20 TB lagringsutrymme används;
- hur man komprimerar data 5 gånger och ger dem till användare i realtid;
- hur man synkroniserar data i farten mellan flera datacenter;
- hur man eliminerar användarnas inflytande på varandra när man använder en virtuell maskin sekventiellt.
Hemligheten med denna magi är teknik ZFS för FreeBSD och dess färska gaffel ZFS på Linux. Vladimir kommer att dela fall från Playkey.
Matvey Kukuy från Amixr.IO redo med exempel från livet , vad har hänt SRE och hur det hjälper till att bygga tillförlitliga system. Amixr.IO skickar klientincidenter genom sin backend; dussintals jourhavande team runt om i världen har redan hanterat 150 tusen fall. På konferensen kommer Matvey att dela med sig av statistik och insikter som hans företag har samlat på sig genom att lösa kundproblem och analysera misslyckanden.
Än en gång uppmanar jag dig att inte vara girig och dela din erfarenhet som DevOps-samuraj. Tjäna för en rapport, och du och jag kommer att ha 2,5 månader på oss att förbereda ett utmärkt tal. Om du vill vara en lyssnare, till nyhetsbrevet med programuppdateringar och fundera allvarligt på att boka biljetter i förväg, eftersom de kommer att bli dyrare närmare konferensdatumen.
Källa: will.com