Vi snakker selvfølgelig om . Hvis du ikke går inn på detaljer, vil vi 30. september og 1. oktober holde en konferanse om å kombinere prosessene med utvikling, testing og drift, og hvis du går inn i detaljer, vær så snill, under kat.
Innenfor DevOps-tilnærmingen er alle deler av prosjektets teknologiske utvikling sammenvevd, skjer parallelt og påvirker hverandre. Spesielt viktig her er å lage automatiserte utviklingsprosesser som kan endres, simuleres og testes i sanntid. Dette hjelper deg å reagere umiddelbart på endringer i markedet.
På konferansen ønsker vi å vise hvordan denne tilnærmingen påvirker produktutviklingen. Hvordan systemets pålitelighet og tilpasningsevne for oppdragsgiver sikres. Hvordan DevOps endrer strukturen og tilnærmingen til et selskap for å organisere arbeidsprosessen.
Bak scenen
Det er viktig for oss å vite ikke bare hva ulike selskaper gjør innenfor rammen av DevOps-tilnærmingen, men også å forstå hvorfor alt dette gjøres. Derfor inviterte vi ikke bare eksperter til å bli med i programkomiteen, men spesialister som ser DevOps-diskursen fra forskjellige posisjoner:
- senior ingeniører;
- utviklere;
- lagledere;
- CTO.
På den ene siden skaper dette vanskeligheter og konflikter ved drøftelse av forespørsler om rapporter. Hvis en ingeniør er interessert i å analysere en storulykke, er det viktigere for en utvikler å forstå hvordan man lager programvare som fungerer i skyer og infrastrukturer. Men ved å bli enige, lager vi et program som vil være verdifullt og interessant for alle: fra ingeniører til CTO.
Målet med konferansen vår er ikke bare å velge ut flest hype-rapporter, men å presentere det overordnede bildet: hvordan DevOps-tilnærmingen fungerer i praksis, hva slags rake du kan støte på når du går over til nye prosesser. Samtidig bygger vi innholdsdelen, og går ned fra forretningsproblemet til spesifikke teknologier.
Konferansedelene vil forbli de samme som i .
- Infrastrukturplattform.
- Infrastruktur som kode.
- Kontinuerlig levering.
- Tilbakemelding.
- Arkitektur i DevOps, DevOps for CTO.
- SRE praktiserer.
- Opplæring og kunnskapsledelse.
- Sikkerhet, DevSecOps.
- DevOps-transformasjon.
Call for Papers: hva slags rapporter vi ser etter
Vi delte betinget det potensielle publikummet til konferansen inn i fem grupper: ingeniører, utviklere, sikkerhetsspesialister, teamledere og CTO. Hver gruppe har sin egen motivasjon for å komme på konferansen. Og hvis du ser på DevOps fra disse stillingene, kan du forstå hvordan du kan fokusere emnet ditt og hvor du skal legge vekt.
For ingeniører, som lager en infrastrukturplattform, er det viktig å forstå de eksisterende trendene, for å forstå hvilke teknologier som nå er mest avanserte. De vil være interessert i å lære om virkelige erfaringer med å bruke disse teknologiene og utveksle meninger. En ingeniør vil gjerne lytte til en rapport som analyserer en hardcore-ulykke, og vi vil på sin side prøve å velge og polere en slik rapport.
For utviklere det er viktig å forstå et slikt konsept som skybasert applikasjon. Det vil si hvordan utvikle programvare slik at den fungerer i skyer og ulike infrastrukturer. Utvikleren må hele tiden motta tilbakemelding fra programvaren. Her ønsker vi å høre case om hvordan bedrifter bygger denne prosessen, hvordan overvåke programvareytelse, og hvordan hele leveringsprosessen fungerer.
Spesialister på nettsikkerhet Det er viktig å forstå hvordan man legger opp sikkerhetsprosessen slik at den ikke stopper utviklings- og endringsprosessene innad i bedriften. Temaer om kravene som DevOps stiller til slike spesialister vil også være interessante.
Teamledere vil viteHvordan den kontinuerlige leveringsprosessen fungerer i andre selskaper. Hvilken vei tok bedriftene for å oppnå dette, hvordan bygget de utviklings- og kvalitetssikringsprosesser innenfor DevOps. Teamledere er også interessert i Cloud native. Og også spørsmål om samhandling innad i teamet og mellom utviklings- og ingeniørteam.
For CTO det viktigste er å finne ut hvordan du kobler alle disse prosessene og justerer dem til forretningsbehov. Han sørger for at applikasjonen er pålitelig for både virksomheten og kunden. Og her må du forstå hvilke teknologier som vil fungere for hvilke forretningsoppgaver, hvordan bygge hele prosessen osv. CTO er også ansvarlig for budsjettering. Han må for eksempel forstå hvor mye penger som må brukes på omskolering av spesialister slik at de kan jobbe i DevOps.
Hvis du har noe å si om disse sakene, ikke vær stille, . Fristen for Call for Papers er 20. august. Jo tidligere du registrerer deg, jo mer tid vil du ha til å ferdigstille rapporten og forberede presentasjonen. Så ikke utsett.
Vel, hvis du ikke har behov for å snakke offentlig, bare og kom 30. september og 1. oktober for å kommunisere med kollegaer. Vi lover at det blir interessant og inspirerende.
Hvordan vi ser på DevOps
For å forstå nøyaktig hva vi mener med DevOps, anbefaler jeg å lese (eller lese på nytt) rapporten min "" Når jeg gikk gjennom markedets bølger, observerte jeg hvordan ideen om DevOps forvandlet seg til selskaper i forskjellige størrelser: fra en liten oppstart til multinasjonale selskaper. Rapporten er bygget på en rekke spørsmål, ved å svare på dem kan du forstå om din bedrift går mot DevOps eller om det er problemer et sted.
DevOps er et komplekst system, det må inneholde:
- Digitalt produkt.
- Bedriftsmoduler som utvikler dette digitale produktet.
- Produktteam som skriver kode.
- Kontinuerlig leveringspraksis.
- Plattformer som en tjeneste.
- Infrastruktur som en tjeneste.
- Infrastruktur som kode.
- Separate praksiser for å opprettholde pålitelighet, innebygd i DevOps.
- En tilbakemeldingspraksis som beskriver det hele.
På slutten av rapporten er det et diagram som gir en idé om DevOps-systemet i selskapet. Det vil tillate deg å se hvilke prosesser i bedriften din som allerede er strømlinjeformet og hvilke som ennå ikke skal bygges.
Du kan se videoen av rapporten .
Og nå kommer det en bonus: flere videoer fra RIT++ 2019, som berører de mest generelle problemene med DevOps-transformasjon.
Bedriftsinfrastruktur som produkt
Artyom Naumenko leder DevOps-teamet på Skyeng og tar seg av utviklingen av selskapets infrastruktur. Han fortalte hvordan infrastruktur påvirker forretningsprosesser hos SkyEng: hvordan beregne ROI for det, hvilke beregninger som bør velges for beregning og hvordan man jobber for å forbedre dem.
På vei til mikrotjenester
Nixys-selskapet gir støtte for travle nettprosjekter og distribuerte systemer. Dens tekniske direktør, Boris Ershov, fortalte hvordan man oversetter programvareprodukter, utviklingen av disse begynte for 5 år siden (eller enda mer), til en moderne plattform.
Som regel er slike prosjekter en spesiell verden der det er så mørke og eldgamle hjørner av infrastrukturen at nåværende ingeniører ikke vet om dem. Og tilnærmingene til arkitektur og utvikling som en gang ble valgt, er utdaterte og kan ikke gi virksomheten samme tempo i utvikling og utgivelse av nye versjoner. Som et resultat blir hver produktutgivelse til et utrolig eventyr, der noe stadig faller av, og på det mest uventede stedet.
Ledere av slike prosjekter står uunngåelig overfor behovet for å transformere alle teknologiske prosesser. I sin rapport sa Boris:
- hvordan velge riktig arkitektur for prosjektet og sette infrastrukturen i orden;
- hvilke verktøy som skal brukes og hvilke fallgruver man møter på veien til transformasjon;
- hva du skal gjøre videre.
Automatisering av utgivelser eller hvordan levere raskt og smertefritt
Alexander Korotkov er en ledende utvikler av CI/CD-systemet hos CIAN. Han snakket om automatiseringsverktøy som gjorde det mulig å forbedre kvaliteten og redusere tiden for levering av kode til produksjonen med 5 ganger. Men slike resultater kunne ikke oppnås med automatisering alene, så Alexander tok også hensyn til endringer i utviklingsprosesser.
Hvordan hjelper ulykker deg med å lære?
Alexey Kirpichnikov har implementert DevOps og infrastruktur hos SKB Kontur i 5 år. I løpet av tre år skjedde det omtrent 1000 fakaps av ulik grad av episkhet i selskapet hans. Blant dem var for eksempel 36 % forårsaket av utrulling av en utgivelse av lav kvalitet i produksjon, og 14 % var forårsaket av vedlikeholdsarbeid av maskinvare i datasenteret.
Et arkiv av rapporter (post mortem) som selskapets ingeniører har vedlikeholdt flere år på rad, gjør det mulig å få så nøyaktig informasjon om ulykker. Obduksjonen er skrevet av vakthavende ingeniør, som var den første som svarte på nødsignalet og begynte å fikse alt. Hvorfor plage ingeniører som sliter om natten med facaps ved å skrive rapporter? Disse dataene lar deg se hele bildet og flytte infrastrukturutviklingen i riktig retning.
I talen sin delte Alexey hvordan man skriver en virkelig nyttig postmortem og hvordan man implementerer praksisen med slike rapporter i et stort selskap. Hvis du liker historier om hvordan noen har skrudd til, se videoen av forestillingen.
Vi forstår at din visjon om DevOps kanskje ikke samsvarer med vår. Det vil være interessant å vite hvordan du ser på DevOps-transformasjonen. Del din erfaring og visjon om dette emnet i kommentarene.
Hvilke rapporter har vi allerede akseptert i programmet?
Denne uken vedtok programkomiteen 4 rapporter: om sikkerhet, infrastruktur og SRE-praksis.
Kanskje det mest smertefulle temaet for DevOps-transformasjon: hvordan sikre at gutta fra informasjonssikkerhetsavdelingen ikke ødelegger de allerede bygde forbindelsene mellom utvikling, drift og administrasjon. Noen selskaper klarer seg uten informasjonssikkerhetsavdeling. Hvordan sikre informasjonssikkerhet i dette tilfellet? Om det Mona Arkhipova fra sudo.su. Fra rapporten hennes lærer vi:
- hva som må beskyttes og fra hvem;
- hva er de rutinemessige sikkerhetsprosessene;
- hvordan IT- og informasjonssikkerhetsprosesser krysser hverandre;
- hva er CIS CSC og hvordan implementere det;
- hvordan og etter hvilke indikatorer for å gjennomføre regelmessige informasjonssikkerhetskontroller.
Den neste rapporten gjelder utvikling av infrastruktur som kode. Reduser mengden manuell rutine og ikke gjør hele prosjektet til kaos, er dette mulig? Til dette spørsmålet Maxim Kostrikin fra Ixtens. Selskapet hans bruker terra for å jobbe med AWS-infrastruktur. Verktøyet er praktisk, men spørsmålet er hvordan du unngår å lage en stor kodeblokk når du bruker det. Vedlikehold av en slik arv vil bli dyrere og dyrere for hvert år.
Maxim vil vise hvordan kodeplasseringsmønstre fungerer, rettet mot å forenkle automatisering og utvikling.
En annen vi skal høre om infrastruktur fra Vladimir Ryabov fra Playkey. Her skal vi snakke om infrastrukturplattformen, og vi vil lære:
- hvordan å forstå om lagringsplass blir brukt effektivt;
- hvordan flere hundre brukere kan motta 10 TB innhold hvis bare 20 TB lagringsplass brukes;
- hvordan komprimere data 5 ganger og gi dem til brukere i sanntid;
- hvordan synkronisere data på farten mellom flere datasentre;
- hvordan eliminere enhver påvirkning fra brukere på hverandre når du bruker én virtuell maskin sekvensielt.
Hemmeligheten bak denne magien er teknologi ZFS for FreeBSD og dens ferske gaffel ZFS på Linux. Vladimir vil dele saker fra Playkey.
Matvey Kukuy fra Amixr.IO klar med eksempler fra livet , hva har skjedd SRE og hvordan det bidrar til å bygge pålitelige systemer. Amixr.IO sender klienthendelser gjennom sin backend; dusinvis av vakthold rundt om i verden har allerede behandlet 150 tusen saker. På konferansen vil Matvey dele statistikken og innsikten som selskapet hans har akkumulert ved å løse kundeproblemer og analysere feil.
Nok en gang oppfordrer jeg deg til å ikke være grådig og dele opplevelsen din som en DevOps-samurai. Tjene for en rapport, og du og jeg vil ha 2,5 måneder på å forberede en utmerket tale. Hvis du vil være en lytter, til nyhetsbrevet med programoppdateringer og tenk seriøst på å bestille billetter på forhånd, fordi de vil bli dyrere nærmere konferansedatoene.
Kilde: www.habr.com