Het gaat natuurlijk om . Als u niet op details ingaat, dan zullen we op 30 september en 1 oktober een conferentie houden over het combineren van de processen van ontwikkeling, testen en gebruik, en als u op details ingaat, alstublieft, onder cat.
Binnen de DevOps-aanpak zijn alle onderdelen van de technologische ontwikkeling van het project met elkaar verweven, vinden parallel plaats en beïnvloeden elkaar. Van bijzonder belang hierbij is het creëren van geautomatiseerde ontwikkelingsprocessen die in realtime kunnen worden gewijzigd, gesimuleerd en getest. Hierdoor kunt u direct reageren op veranderingen in de markt.
Op de conferentie willen we laten zien hoe deze aanpak de productontwikkeling beïnvloedt. Hoe de betrouwbaarheid en aanpasbaarheid van het systeem voor de klant wordt gewaarborgd. Hoe DevOps de structuur en aanpak van een bedrijf verandert bij het organiseren van zijn werkprocessen.
Achter de schermen
Het is voor ons belangrijk om niet alleen te weten wat verschillende bedrijven doen in het kader van de DevOps-aanpak, maar ook om te begrijpen waarom dit allemaal wordt gedaan. Daarom hebben we niet alleen experts uitgenodigd om deel uit te maken van de Programmacommissie, maar specialisten die het DevOps-discours vanuit verschillende posities bekijken:
- hogere ingenieurs;
- ontwikkelaars;
- teamleiders;
- CTO.
Enerzijds levert dit moeilijkheden en conflicten op bij de bespreking van rapportageverzoeken. Als een ingenieur geïnteresseerd is in het analyseren van een zwaar ongeval, is het belangrijker dat een ontwikkelaar begrijpt hoe hij software moet maken die in clouds en infrastructuren werkt. Maar door het eens te worden, creëren we een programma dat voor iedereen waardevol en interessant zal zijn: van engineers tot CTO.
Het doel van onze conferentie is niet alleen om de meeste hype-rapporten te selecteren, maar om het totaalbeeld te presenteren: hoe de DevOps-aanpak in de praktijk werkt, wat voor soort rake je kunt tegenkomen bij de overstap naar nieuwe processen. Tegelijkertijd bouwen we aan het inhoudsgedeelte, van het bedrijfsprobleem tot specifieke technologieën.
De conferentieonderdelen blijven hetzelfde als in .
- Infrastructuurplatform.
- Infrastructuur als code.
- Continue levering.
- Feedback.
- Architectuur in DevOps, DevOps voor CTO.
- SRE-praktijken.
- Opleiding en kennismanagement.
- Beveiliging, DevSecOps.
- DevOps-transformatie.
Call for Papers: naar wat voor soort rapporten zijn we op zoek?
We hebben het potentiële publiek van de conferentie voorwaardelijk in vijf groepen verdeeld: engineers, ontwikkelaars, beveiligingsspecialisten, teamleiders en CTO. Elke groep heeft zijn eigen motivatie om naar de conferentie te komen. En als u vanuit deze posities naar DevOps kijkt, begrijpt u hoe u zich op uw onderwerp moet concentreren en waar u de nadruk moet leggen.
Voor ingenieurs, die een infrastructuurplatform creëren, is het belangrijk om de bestaande trends te begrijpen, om te begrijpen welke technologieën nu het meest geavanceerd zijn. Ze zullen geïnteresseerd zijn in het leren over praktijkervaring met het gebruik van deze technologieën en het uitwisselen van meningen. Een ingenieur zal graag luisteren naar een rapport waarin een hardcore ongeval wordt geanalyseerd, en wij zullen op onze beurt proberen zo'n rapport te selecteren en op te poetsen.
Voor ontwikkelaars het is belangrijk om een dergelijk concept te begrijpen als cloud-native applicatie. Dat wil zeggen, hoe je software kunt ontwikkelen zodat deze in de cloud en in verschillende infrastructuren werkt. De ontwikkelaar moet voortdurend feedback ontvangen van de software. Hier willen we cases horen over hoe bedrijven dit proces bouwen, hoe ze de prestaties van software kunnen monitoren en hoe het hele leveringsproces werkt.
Specialisten op het gebied van cyberbeveiliging Het is belangrijk om te begrijpen hoe u het beveiligingsproces zo kunt inrichten dat het de ontwikkelings- en veranderingsprocessen binnen het bedrijf niet vertraagt. Ook onderwerpen over de eisen die DevOps aan zulke specialisten stelt zijn interessant.
Teamleiders willen het weten, hoe het continue leveringsproces bij andere bedrijven werkt. Welk pad hebben bedrijven gevolgd om dit te bereiken, hoe hebben ze ontwikkelings- en kwaliteitsborgingsprocessen binnen DevOps opgebouwd. Teamleiders zijn ook geïnteresseerd in Cloud native. En ook vragen over de interactie binnen het team en tussen ontwikkel- en engineeringteams.
Voor CTO het belangrijkste is om erachter te komen hoe je al deze processen met elkaar kunt verbinden en ze kunt aanpassen aan de bedrijfsbehoeften. Hij zorgt ervoor dat de applicatie betrouwbaar is voor zowel de business als de klant. En hier moet u begrijpen welke technologieën zullen werken voor welke zakelijke taken, hoe u het hele proces kunt bouwen, enz. De CTO is ook verantwoordelijk voor de budgettering. Hij moet bijvoorbeeld begrijpen hoeveel geld er moet worden uitgegeven aan het omscholen van specialisten, zodat zij in DevOps kunnen werken.
Als u iets over deze zaken te zeggen heeft, zwijg dan niet, . De deadline voor Call for Papers is 20 augustus. Hoe eerder u zich inschrijft, hoe meer tijd u heeft om uw rapport af te ronden en uw presentatie voor te bereiden. Wacht dus niet langer.
Nou ja, als je geen behoefte hebt om in het openbaar te spreken, gewoon en kom op 30 september en 1 oktober om te communiceren met collega’s. We beloven dat het interessant en inspirerend zal zijn.
Hoe wij DevOps zien
Om precies te begrijpen wat we met DevOps bedoelen, raad ik aan mijn rapport te lezen (of te herlezen) “" Terwijl ik door de golven van de markt liep, zag ik hoe het idee van DevOps transformeerde in bedrijven van verschillende grootte: van een kleine startup tot multinationale bedrijven. Het rapport is opgebouwd rond een reeks vragen, door deze te beantwoorden krijgt u inzicht of uw bedrijf richting DevOps beweegt of dat er ergens problemen zijn.
DevOps is een complex systeem en moet het volgende omvatten:
- Digitaal product.
- Bedrijfsmodules die dit digitale product ontwikkelen.
- Productteams die code schrijven.
- Continuous Delivery-praktijken.
- Platformen als een service.
- Infrastructuur als een service.
- Infrastructuur als code.
- Afzonderlijke praktijken voor het behouden van de betrouwbaarheid, ingebouwd in DevOps.
- Een feedbackpraktijk die alles beschrijft.
Aan het einde van het rapport staat een diagram dat een idee geeft van het DevOps-systeem in het bedrijf. Hiermee kunt u zien welke processen in uw bedrijf al zijn gestroomlijnd en welke nog moeten worden opgebouwd.
U kunt de video van het rapport bekijken .
En nu komt er een bonus: verschillende video's van RIT++ 2019, die ingaan op de meest algemene kwesties van DevOps-transformatie.
Bedrijfsinfrastructuur als product
Artyom Naumenko leidt het DevOps-team bij Skyeng en zorgt voor de ontwikkeling van de infrastructuur van zijn bedrijf. Hij vertelde hoe de infrastructuur de bedrijfsprocessen bij SkyEng beïnvloedt: hoe je de ROI ervoor kunt berekenen, welke maatstaven je voor de berekening moet kiezen en hoe je deze kunt verbeteren.
Op weg naar microservices
Het bedrijf Nixys biedt ondersteuning voor drukke webprojecten en gedistribueerde systemen. De technisch directeur, Boris Ershov, vertelde hoe softwareproducten, waarvan de ontwikkeling 5 jaar geleden (of zelfs meer) begon, naar een modern platform moesten worden vertaald.
In de regel zijn dergelijke projecten een bijzondere wereld waar zulke donkere en oude hoeken van de infrastructuur zijn dat de huidige ingenieurs er niets van weten. En de benaderingen van architectuur en ontwikkeling waar ooit voor werd gekozen, zijn verouderd en kunnen het bedrijf niet hetzelfde tempo van ontwikkeling en release van nieuwe versies bieden. Het resultaat is dat elke productrelease verandert in een ongelooflijk avontuur, waarbij er voortdurend iets misgaat, en wel op de meest onverwachte plek.
Managers van dergelijke projecten worden onvermijdelijk geconfronteerd met de noodzaak om alle technologische processen te transformeren. In zijn rapport zei Boris:
- hoe je de juiste architectuur voor het project kiest en de infrastructuur op orde brengt;
- welke instrumenten je moet gebruiken en welke valkuilen je tegenkomt op het pad naar transformatie;
- wat nu te doen.
Automatisering van releases of hoe u snel en pijnloos kunt leveren
Alexander Korotkov is een toonaangevende ontwikkelaar van het CI/CD-systeem bij CIAN. Hij sprak over automatiseringstools die het mogelijk maakten om de kwaliteit te verbeteren en de tijd voor het leveren van code aan productie met een factor vijf te verkorten. Maar dergelijke resultaten konden niet alleen met automatisering worden bereikt, dus besteedde Alexander ook aandacht aan veranderingen in ontwikkelingsprocessen.
Hoe helpen ongelukken je bij het leren?
Alexey Kirpichnikov implementeert al 5 jaar DevOps en infrastructuur bij SKB Kontur. In de loop van drie jaar vonden in zijn gezelschap ongeveer 1000 fakaps van verschillende mate van epischheid plaats. Daarvan werd bijvoorbeeld 36% veroorzaakt door het uitrollen van een release van lage kwaliteit naar productie, en 14% door hardware-onderhoudswerkzaamheden in het datacenter.
Een archief van rapporten (post-mortems) dat de ingenieurs van het bedrijf al meerdere jaren op rij bijhouden, maakt het mogelijk zulke nauwkeurige informatie over ongevallen te verkrijgen. Het autopsierapport is geschreven door de dienstdoende ingenieur, die als eerste op het noodsignaal reageerde en alles begon te repareren. Waarom ingenieurs kwellen die 's nachts met facaps worstelen door rapporten te schrijven? Met deze gegevens kunt u het hele plaatje zien en de ontwikkeling van de infrastructuur in de goede richting sturen.
In zijn toespraak vertelde Alexey hoe je een echt nuttig postmortem kunt schrijven en hoe je de praktijk van dergelijke rapporten in een groot bedrijf kunt implementeren. Als je van verhalen houdt over hoe iemand het verprutste, bekijk dan de video van het optreden.
Wij begrijpen dat uw visie op DevOps mogelijk niet overeenkomt met de onze. Het zal interessant zijn om te weten hoe jij de DevOps-transformatie ziet. Deel uw ervaring en visie op dit onderwerp in de reacties.
Welke rapporten hebben we al geaccepteerd in het programma?
Deze week heeft de Programmacommissie 4 rapporten aangenomen: over veiligheid, infrastructuur en SRE-praktijken.
Misschien wel het pijnlijkste onderwerp van de DevOps-transformatie: hoe zorg je ervoor dat de jongens van de informatiebeveiligingsafdeling de reeds opgebouwde verbindingen tussen ontwikkeling, exploitatie en beheer niet vernietigen. Sommige bedrijven doen het zonder een afdeling informatiebeveiliging. Hoe kan in dit geval de informatiebeveiliging worden gewaarborgd? Over het Mona Arkhipova van sudo.su. Uit haar rapport leren we:
- wat moet worden beschermd en tegen wie;
- wat zijn de routinematige beveiligingsprocessen;
- hoe IT- en informatiebeveiligingsprocessen elkaar kruisen;
- wat is CIS CSC en hoe implementeer je dit;
- hoe en aan de hand van welke indicatoren regelmatig informatiebeveiligingscontroles moeten worden uitgevoerd.
Het volgende rapport gaat over de ontwikkeling van infrastructuur als code. De hoeveelheid handmatige routine verminderen en het hele project niet in chaos veranderen, is dit mogelijk? Op deze vraag Maxim Kostrikin van Ixtens. Zijn bedrijf gebruikt Terraform voor het werken met AWS-infrastructuur. De tool is handig, maar de vraag is hoe je kunt voorkomen dat je bij het gebruik ervan een enorm codeblok creëert. Het onderhoud van een dergelijk erfgoed zal elk jaar duurder worden.
Maxim zal laten zien hoe codeplaatsingspatronen werken, gericht op het vereenvoudigen van automatisering en ontwikkeling.
Een ander we zullen horen over de infrastructuur van Vladimir Ryabov van Playkey. Hier zullen we het hebben over het infrastructuurplatform en zullen we leren:
- hoe u kunt begrijpen of opslagruimte effectief wordt gebruikt;
- hoe honderden gebruikers 10 TB aan inhoud kunnen ontvangen als er slechts 20 TB opslagruimte wordt gebruikt;
- hoe gegevens vijf keer kunnen worden gecomprimeerd en in realtime aan gebruikers kunnen worden aangeboden;
- hoe u gegevens on-the-fly kunt synchroniseren tussen verschillende datacenters;
- hoe u elke invloed van gebruikers op elkaar kunt elimineren bij het opeenvolgend gebruik van één virtuele machine.
Het geheim van deze magie is technologie ZFS voor FreeBSD en zijn verse vork ZFS op Linux. Vladimir zal cases van Playkey delen.
Matvey Kukuy van Amixr.IO klaar met voorbeelden uit het leven , wat SRE en hoe het helpt bij het bouwen van betrouwbare systemen. Amixr.IO geeft klantincidenten door via de backend; tientallen dienstdoende teams over de hele wereld hebben al 150 gevallen afgehandeld. Op de conferentie zal Matvey de statistieken en inzichten delen die zijn bedrijf heeft verzameld door het oplossen van klantproblemen en het analyseren van mislukkingen.
Ik verzoek u nogmaals dringend om niet hebzuchtig te zijn en uw ervaringen als DevOps-samoerai te delen. Dienen voor een rapport, en u en ik hebben 2,5 maand de tijd om een uitstekende toespraak voor te bereiden. Als je een luisteraar wilt zijn, naar de nieuwsbrief met programma-updates en serieus nadenken over het vooraf boeken van tickets, omdat deze dichter bij de conferentiedata duurder zullen worden.
Bron: www.habr.com