Vi taler selvfølgelig om . Hvis du ikke går i detaljer, så afholder vi den 30. september og 1. oktober en konference om at kombinere processerne med udvikling, test og drift, og hvis du går i detaljer, så venligst under kat.
Inden for DevOps-tilgangen er alle dele af projektets teknologiske udvikling flettet sammen, foregår parallelt og påvirker hinanden. Af særlig betydning her er skabelsen af automatiserede udviklingsprocesser, der kan ændres, simuleres og testes i realtid. Dette hjælper dig med at reagere øjeblikkeligt på ændringer i markedet.
På konferencen vil vi vise, hvordan denne tilgang påvirker produktudviklingen. Hvordan systemets pålidelighed og tilpasningsevne for klienten sikres. Hvordan DevOps ændrer strukturen og tilgangen til en virksomhed til at organisere sin arbejdsproces.
bag scenen
Det er vigtigt for os ikke kun at vide, hvad forskellige virksomheder gør inden for rammerne af DevOps-tilgangen, men også at forstå, hvorfor alt dette gøres. Derfor inviterede vi ikke kun eksperter til at deltage i programudvalget, men specialister, der ser DevOps-diskursen fra forskellige positioner:
- ledende ingeniører;
- udviklere;
- team ledere;
- CTO.
På den ene side skaber dette vanskeligheder og konflikter ved drøftelse af anmodninger om rapporter. Hvis en ingeniør er interesseret i at analysere en større ulykke, så er det vigtigere for en udvikler at forstå, hvordan man skaber software, der fungerer i skyer og infrastrukturer. Men ved at blive enige, skaber vi et program, der vil være værdifuldt og interessant for alle: fra ingeniører til CTO.
Målet med vores konference er ikke blot at udvælge de mest hype-rapporter, men at præsentere det overordnede billede: hvordan DevOps-tilgangen fungerer i praksis, hvilken slags rake du kan løbe ind i, når du går over til nye processer. Samtidig bygger vi indholdsdelen, og går ned fra forretningsproblemet til specifikke teknologier.
Konferenceafsnittene forbliver de samme som i .
- Infrastruktur platform.
- Infrastruktur som kode.
- Kontinuerlig levering.
- Feedback.
- Arkitektur i DevOps, DevOps for CTO.
- SRE praksis.
- Uddannelse og videnledelse.
- Sikkerhed, DevSecOps.
- DevOps transformation.
Call for Papers: Hvilken slags rapporter leder vi efter
Vi opdelte betinget det potentielle publikum på konferencen i fem grupper: ingeniører, udviklere, sikkerhedsspecialister, teamledere og CTO. Hver gruppe har sin egen motivation for at komme til konferencen. Og hvis du ser på DevOps fra disse positioner, kan du forstå, hvordan du fokuserer dit emne, og hvor du skal lægge vægt.
For ingeniører, der skaber en infrastrukturplatform, er det vigtigt at forstå de eksisterende tendenser, for at forstå, hvilke teknologier der nu er de mest avancerede. De vil være interesserede i at lære om virkelige erfaringer med at bruge disse teknologier og udveksle meninger. En ingeniør vil med glæde lytte til en rapport, der analyserer en eller anden alvorlig ulykke, og vi vil til gengæld forsøge at udvælge og polere en sådan rapport.
For udviklere det er vigtigt at forstå sådan et begreb som cloud native applikation. Altså hvordan man udvikler software, så det fungerer i skyer og diverse infrastrukturer. Udvikleren skal konstant modtage feedback fra softwaren. Her vil vi gerne høre cases om, hvordan virksomheder bygger denne proces, hvordan man overvåger softwareydelsen, og hvordan hele leveringsprocessen fungerer.
Cybersikkerhedsspecialister Det er vigtigt at forstå, hvordan man sætter sikkerhedsprocessen op, så den ikke stopper udviklings- og forandringsprocesserne i virksomheden. Emner om de krav, DevOps stiller til sådanne specialister, vil også være interessante.
Teamledere vil gerne vide det, hvordan den løbende leveringsproces fungerer i andre virksomheder. Hvilken vej tog virksomhederne for at opnå dette, hvordan byggede de udviklings- og kvalitetssikringsprocesser inden for DevOps. Teamledere er også interesserede i Cloud native. Og også spørgsmål om interaktion i teamet og mellem udviklings- og ingeniørteams.
for CTO det vigtigste er at finde ud af, hvordan man forbinder alle disse processer og tilpasser dem til virksomhedens behov. Han sørger for, at applikationen er pålidelig for både virksomheden og kunden. Og her skal du forstå, hvilke teknologier der vil fungere til hvilke forretningsopgaver, hvordan man bygger hele processen osv. CTO er også ansvarlig for budgettering. For eksempel skal han forstå, hvor mange penge der skal bruges på omskoling af specialister, så de kan arbejde i DevOps.
Hvis du har noget at sige om disse sager, skal du ikke tie stille, . Deadline for Call for Papers er den 20. august. Jo tidligere du tilmelder dig, jo mere tid har du til at færdiggøre din rapport og forberede din præsentation. Så tøv ikke.
Nå, hvis du ikke har et behov for at tale offentligt, bare og kom den 30. september og 1. oktober for at kommunikere med kollegerne. Vi lover, at det bliver interessant og inspirerende.
Sådan ser vi DevOps
For at forstå præcis, hvad vi mener med DevOps, anbefaler jeg at læse (eller genlæse) min rapport "" Da jeg gik gennem markedets bølger, observerede jeg, hvordan ideen om DevOps forvandlede sig i virksomheder i forskellige størrelser: fra en lille startup til multinationale virksomheder. Rapporten er bygget på en række spørgsmål, ved at besvare dem kan du forstå, om din virksomhed er på vej mod DevOps, eller om der er problemer et eller andet sted.
DevOps er et komplekst system, det skal indeholde:
- Digitalt produkt.
- Forretningsmoduler, der udvikler dette digitale produkt.
- Produktteams, der skriver kode.
- Løbende leveringspraksis.
- Platforme som en service.
- Infrastruktur som en service.
- Infrastruktur som kode.
- Separat praksis for opretholdelse af pålidelighed, indbygget i DevOps.
- En feedbackpraksis, der beskriver det hele.
I slutningen af rapporten er der et diagram, der giver en idé om DevOps-systemet i virksomheden. Det giver dig mulighed for at se, hvilke processer i din virksomhed, der allerede er blevet strømlinet, og hvilke der endnu skal bygges.
Du kan se videoen af rapporten .
Og nu vil der være en bonus: flere videoer fra RIT++ 2019, som berører de mest generelle spørgsmål om DevOps-transformation.
Virksomhedens infrastruktur som produkt
Artyom Naumenko leder DevOps-teamet hos Skyeng og tager sig af udviklingen af sit firmas infrastruktur. Han fortalte, hvordan infrastruktur påvirker forretningsprocesser hos SkyEng: hvordan man beregner ROI for det, hvilke målinger der skal vælges til beregning, og hvordan man arbejder for at forbedre dem.
På vej mod mikrotjenester
Nixys firma yder support til travle webprojekter og distribuerede systemer. Dets tekniske direktør, Boris Ershov, fortalte, hvordan man oversætter softwareprodukter, hvis udvikling begyndte for 5 år siden (eller endnu mere), til en moderne platform.
Som regel er sådanne projekter en speciel verden, hvor der er så mørke og gamle hjørner af infrastrukturen, at nuværende ingeniører ikke kender til dem. Og de tilgange til arkitektur og udvikling, der engang blev valgt, er forældede og kan ikke give forretningen det samme tempo i udviklingen og udgivelsen af nye versioner. Som et resultat bliver hver produktudgivelse til et utroligt eventyr, hvor noget konstant falder af, og på det mest uventede sted.
Ledere af sådanne projekter står uundgåeligt over for behovet for at transformere alle teknologiske processer. I sin rapport sagde Boris:
- hvordan man vælger den rigtige arkitektur til projektet og bringer infrastrukturen i orden;
- hvilke værktøjer der skal bruges, og hvilke faldgruber støder man på på vejen til transformation;
- hvad skal man så gøre.
Automatisering af udgivelser eller hvordan man leverer hurtigt og smertefrit
Alexander Korotkov er en førende udvikler af CI/CD-systemet hos CIAN. Han talte om automatiseringsværktøjer, der gjorde det muligt at forbedre kvaliteten og reducere tiden for levering af kode til produktionen med 5 gange. Men sådanne resultater kunne ikke opnås med automatisering alene, så Alexander var også opmærksom på ændringer i udviklingsprocesser.
Hvordan hjælper ulykker dig med at lære?
Alexey Kirpichnikov har implementeret DevOps og infrastruktur hos SKB Kontur i 5 år. I løbet af tre år forekom cirka 1000 fakaps af forskellig grad af episkhed i hans selskab. Blandt dem var for eksempel 36 % forårsaget af udrulning af en udgivelse af lav kvalitet i produktionen, og 14 % var forårsaget af hardwarevedligeholdelsesarbejde i datacentret.
Et arkiv af rapporter (post mortems), som virksomhedens ingeniører har opbevaret i flere år i træk, gør det muligt at få så præcise oplysninger om ulykker. Obduktionen er skrevet af den vagthavende ingeniør, som var den første til at reagere på nødsignalet og begyndte at ordne alt. Hvorfor plage ingeniører, der kæmper om natten med facader ved at skrive rapporter? Disse data giver dig mulighed for at se hele billedet og bevæge infrastrukturudviklingen i den rigtige retning.
I sin tale delte Alexey, hvordan man skriver en virkelig nyttig postmortem, og hvordan man implementerer praksis af sådanne rapporter i en stor virksomhed. Hvis du kan lide historier om, hvordan nogen har lavet noget, så se videoen af forestillingen.
Vi forstår, at din vision for DevOps muligvis ikke matcher vores. Det vil være interessant at vide, hvordan du ser DevOps-transformation. Del din oplevelse og vision om dette emne i kommentarerne.
Hvilke rapporter har vi allerede accepteret i programmet?
Programudvalget vedtog i denne uge 4 rapporter: om sikkerhed, infrastruktur og SRE-praksis.
Måske det mest smertefulde emne for DevOps-transformation: hvordan man sikrer sig, at fyrene fra informationssikkerhedsafdelingen ikke ødelægger de allerede opbyggede forbindelser mellem udvikling, drift og administration. Nogle virksomheder klarer sig uden en informationssikkerhedsafdeling. Hvordan sikrer man informationssikkerheden i dette tilfælde? Om det Mona Arkhipova fra sudo.su. Fra hendes rapport lærer vi:
- hvad skal beskyttes og fra hvem;
- hvad er de rutinemæssige sikkerhedsprocesser;
- hvordan IT- og informationssikkerhedsprocesser krydser hinanden;
- hvad er CIS CSC, og hvordan man implementerer det;
- hvordan og med hvilke indikatorer at udføre regelmæssige informationssikkerhedstjek.
Den næste rapport omhandler udvikling af infrastruktur som kode. Reducer mængden af manuel rutine og ikke gør hele projektet til kaos, er det muligt? Til dette spørgsmål Maxim Kostrikin fra Ixtens. Hans firma bruger terraform for at arbejde med AWS-infrastruktur. Værktøjet er praktisk, men spørgsmålet er, hvordan man undgår at skabe en enorm kodeblok, når man bruger det. Vedligeholdelse af en sådan arv vil blive dyrere og dyrere hvert år.
Maxim vil vise, hvordan kodeplaceringsmønstre fungerer, rettet mod at forenkle automatisering og udvikling.
En anden vi hører om infrastruktur fra Vladimir Ryabov fra Playkey. Her vil vi tale om infrastrukturplatformen, og vi vil lære:
- hvordan man forstår, om lagerplads bliver brugt effektivt;
- hvordan flere hundrede brugere kan modtage 10 TB indhold, hvis der kun bruges 20 TB lagerplads;
- hvordan man komprimerer data 5 gange og leverer det til brugerne i realtid;
- hvordan man synkroniserer data på farten mellem flere datacentre;
- hvordan man fjerner enhver indflydelse fra brugere på hinanden, når man bruger én virtuel maskine sekventielt.
Hemmeligheden bag denne magi er teknologi ZFS til FreeBSD og dens friske gaffel ZFS på Linux. Vladimir vil dele sager fra Playkey.
Matvey Kukuy fra Amixr.IO klar med eksempler fra livet , hvad er der sket SRE og hvordan det hjælper med at opbygge pålidelige systemer. Amixr.IO sender klienthændelser gennem sin backend; snesevis af vagthavende teams rundt om i verden har allerede behandlet 150 tusinde sager. På konferencen vil Matvey dele de statistikker og indsigter, som hans virksomhed har oparbejdet ved at løse kundeproblemer og analysere fejl.
Endnu en gang opfordrer jeg dig til ikke at være grådig og dele din oplevelse som DevOps-samurai. Tjene til en rapport, og du og jeg vil have 2,5 måned til at forberede en fremragende tale. Hvis du vil være en lytter, til nyhedsbrevet med programopdateringer og tænk seriøst over at bestille billetter før tid, for de bliver dyrere tættere på konferencedatoerne.
Kilde: www.habr.com