<\/a><\/noindex>DevOps omvat veel verschillende concepten (continue levering, continue integratie, automatisering, enzovoort), waardoor het moeilijk kan zijn om de kern eruit te halen, vooral als je betrokken bent bij het onderwerp. Dit vermogen is echter zeer nuttig, of je nu je idee\u00ebn aan je leidinggevenden wilt overbrengen of gewoon over je werk vertelt aan familie of vrienden. Laten we daarom de terminologische nuances van DevOps voorlopig opzijzetten en ons concentreren op het algemene plaatje.<\/p>\n
Wat is DevOps: 6 definities en analogie\u00ebn<\/h3>\n \nWe hebben experts gevraagd om de essentie van DevOps zo eenvoudig en kort mogelijk uit te leggen, zodat de waarde ervan duidelijk wordt voor lezers met elk niveau van technische kennis. Op basis van deze gesprekken hebben we de meest levendige analogie\u00ebn en krachtige formuleringen geselecteerd, die je helpen jouw verhaal over DevOps te vertellen.<\/p>\n
1. DevOps is een culturele beweging<\/h4>\n \n\u201cDevOps is een culturele beweging waarbij beide partijen (softwareontwikkelaars en IT-systeembeheerders) erkennen dat software geen echte waarde heeft totdat iemand het begint te gebruiken: klanten, cli\u00ebnten, medewerkers, wat ertoe doet \u2013 zegt Eveline Oehrlich, senior analist-onderzoeker bij het DevOps Institute. \u2013 Daarom zorgen beide partijen samen voor snelle en kwalitatieve softwarelevering.\u201d<\/p>\n
2. DevOps is wat ontwikkelaars empowerment geeft<\/h4>\n \n\u00abDevOps geeft ontwikkelaars de macht om applicaties te bezitten, deze te lanceren en het leveren ervan van begin tot eind te beheren\u00bb<\/b><\/p>\n
\u00abGewoonlijk wordt DevOps gezien als een manier om de levering van applicaties naar productie te versnellen door geautomatiseerde processen op te zetten en toe te passen\u00bb, zegt Jai Schniepp, directeur van DevOps-platforms bij verzekeringsmaatschappij Liberty Mutual. \u00abMaar voor mij is het iets veel fundamentelers. DevOps geeft ontwikkelaars de macht om applicaties of specifieke delen van software te bezitten, deze te lanceren en het leveren ervan van begin tot eind te beheren. DevOps elimineert verwarring rond verantwoordelijkheden en leidt alle betrokkenen naar het cre\u00ebren van een geautomatiseerde en door ontwikkelaars beheerde infrastructuur\u00bb.<\/p>\n
3. DevOps is samenwerking bij het cre\u00ebren en leveren van applicaties<\/h4>\n \n\u00abIn eenvoudige bewoordingen, DevOps is een benadering van softwareproductie en -levering waarbij iedereen samenwerkt\u00bb, merkt Gur Staf op, president en hoofd van de digitale businessautomatisering bij BMC.<\/p>\n
4. DevOps is een productieproces<\/h4>\n \n\u00abProductie in een proces is alleen mogelijk als alle onderdelen op elkaar aansluiten\u00bb.<\/b><\/p>\n
\u00abIk zou DevOps vergelijken met een assemblagelijn voor auto's\u00bb, gaat Gur Staf verder. \u00abHet idee is om alles van tevoren te ontwerpen en te maken zodat de onderdelen later zonder aanpassing kunnen worden samengevoegd. Productie in een proces is alleen mogelijk als alle onderdelen op elkaar aansluiten. Degenen die de motor ontwerpen en maken, moeten nadenken over hoe deze aan de carrosserie of het frame kan worden bevestigd. Degenen die de remmen maken, moeten rekening houden met de wielen, en zo verder. Evenzo moet het bij software zijn.\u00bb <\/p>\n
Een ontwikkelaar die zakelijke logica of een gebruikersinterface maakt, moet nadenken over de database die klantgegevens opslaat, over de beveiligingsmaatregelen voor het beschermen van gebruikersgegevens, en over hoe dit allemaal zal werken wanneer de service een groot publiek bedient, mogelijk zelfs miljoenen gebruikers\u00bb.<\/p>\n
\u00abMensen laten samenwerken en na te denken over de delen van het werk die door anderen worden uitgevoerd, in plaats van zich alleen te concentreren op hun eigen taken \u2013 dat is het grootste obstakel dat overwonnen moet worden. Als dat lukt, krijgt u uitstekende kansen voor digitale transformatie\u00bb, voegt Gur Staf toe.<\/p>\n
5. DevOps is de juiste combinatie van mensen, processen en automatisering<\/h4>\n \nJayne Groll, uitvoerend directeur van het DevOps Institute, gaf een uitstekende analogie om DevOps uit te leggen. Volgens haar is \u00abDevOps net als een kookrecept, waarbij drie hoofdcategorie\u00ebn van ingredi\u00ebnten komen kijken: mensen, processen en automatisering. Het merendeel van deze ingredi\u00ebnten kan uit andere gebieden en bronnen worden gehaald: Lean, Agile, SRE, CI\/CD, ITIL, leiderschap, cultuur, tools. Het geheim van DevOps, net als van elk goed recept, is hoe je de verhoudingen goed selecteert en deze ingredi\u00ebnten mengt om de snelheid en effectiviteit van het cre\u00ebren en uitbrengen van applicaties te verhogen\u00bb.<\/p>\n
6. DevOps is wanneer programmeurs als een Formule 1-team werken<\/h4>\n \n\u00abDe race wordt niet van start naar finish gepland, maar andersom, van finish naar start\u00bb.<\/b><\/p>\n
\u00abAls ik spreek over wat te verwachten van een DevOps-initiatief, geef ik het voorbeeld van een NASCAR- of Formule 1-raceteam\u00bb, zegt Chris Short, Chief Marketing Manager van Red Hats cloudplatforms en uitgever van de nieuwsbrief DevOps\u2019ish. \u00abHet doel van de leider van zo\u2019n team is om het hoogst mogelijke resultaat te behalen met de beschikbare middelen en uitdagingen waar het team mee te maken heeft. Daarbij wordt de race niet van start naar finish gepland, maar andersom, van finish naar start. Eerst wordt er een ambitieuze doelstelling gesteld, waarna de wegen naar die doelstelling worden gedefinieerd. Daarna worden deze opgedeeld in sub-taken en gedelegeerd aan teamleden\u00bb.<\/p>\n
\u00abGedurende de hele week voor de race perfectioneert het team de pitstop. Ze doen kracht- en cardiotraining om in vorm te zijn op de zware racedag. Ze trainen gezamenlijk om problemen op te lossen die zich tijdens de race kunnen voordoen. Evenzo moet het ontwikkelingsteam hun vaardigheden in het frequent uitbrengen van nieuwe versies trainen. Met deze vaardigheden en een goed beveiligingssysteem kunnen nieuwe versies ook sneller in productie worden gebracht. In dit wereldbeeld betekent een toename van snelheid een toename van veiligheid\u00bb, zegt Short.<\/p>\n
\u00abHet gaat er niet om de 'juiste dingen' te doen, - voegt Short toe, - maar om zoveel mogelijk dingen te elimineren die de weg naar het gewenste resultaat blokkeren. Werk samen en pas je aan op basis van de feedback die je in real-time ontvangt. Wees voorbereid op anomalie\u00ebn en werk aan kwaliteitsverbetering om hun impact op de vooruitgang naar je doel te minimaliseren. Dit is precies wat ons te wachten staat in de wereld van DevOps\u00bb.<\/p>\n
Hoe DevOps te schalen: 10 tips van experts<\/h3>\n \nGewone DevOps en massale DevOps zijn absoluut verschillende zaken. We zullen uitleggen hoe je de barri\u00e8res kunt overwinnen om van het eerste naar het tweede te gaan.<\/b><\/p>\n
Voor veel organisaties begint de weg naar DevOps gemakkelijk en plezierig. Kleine gepassioneerde teams worden gevormd, oude processen worden vervangen door nieuwe, en de eerste successen laten niet op zich wachten.<\/p>\n
Helaas is het slechts een schijnbare glans, een illusie van vooruitgang, zoals Ben Grinnell, managing director en hoofd digitale technologie bij het adviesbureau North Highland, zegt. Vroege overwinningen zijn natuurlijk bemoedigend, maar helpen niet om het uiteindelijke doel te bereiken, namelijk grootschalig gebruik van DevOps binnen de organisatie.<\/p>\n
Het is gemakkelijk te zien dat er daardoor een cultuur van splitsing ontstaat tussen 'wij' en 'zij'.<\/b><\/p>\n
\"Vaak starten organisaties met dit soort pioniersprojecten in de veronderstelling dat ze de weg zullen banen voor grootschalige DevOps, zonder zich af te vragen of anderen ook werkelijk deze weg willen bewandelen,\" legt Ben Grinnell uit. \"Teams voor de uitvoering van dergelijke projecten worden meestal samengesteld uit zelfverzekerde 'buitenlanders' die iets dergelijks elders hebben gedaan, maar nieuw zijn binnen uw organisatie. Ze worden aangemoedigd om de regels te breken en af te breken die voor iedereen verplicht blijven. Het is makkelijk te zien dat er zo een cultuur van scheiding ontstaat tussen 'wij' en 'zij', wat de overdracht van kennis en vaardigheden belemmert.\"<\/p>\n
\u201eEn dit culturele probleem is slechts een van de redenen waarom het moeilijk is om DevOps op te schalen. DevOps-teams worden geconfronteerd met een toename van puur technische complexiteit, kenmerkend voor snelgroeiende bedrijven die inzetten op IT-technologie\u00ebn,\" zegt Steve Newman, oprichter en voorzitter van Scalyr.<\/p>\n
\u201eIn de moderne wereld veranderen diensten onmiddellijk zodra de noodzaak zich aandient. Constant nieuwe functies implementeren is natuurlijk geweldig, maar het co\u00f6rdineren van dit proces en het oplossen van problemen is een echte hoofdpijn,\" voegt Steve Newman eraan toe. \u201eIn zeer snelgroeiende organisaties strijden ingenieurs in cross-functionele teams om de mogelijkheid te behouden om wijzigingen te volgen en de cascade-effecten ervan op het niveau van afhankelijkheden te begrijpen. Bovendien zijn ingenieurs absoluut niet blij wanneer ze deze mogelijkheid verliezen, wat het voor hen moeilijker maakt om de essentie van opkomende problemen te begrijpen.\"<\/p>\n
Hoe overwin je de hierboven beschreven moeilijkheden en ga je over op grootschalig gebruik van DevOps binnen een groot bedrijf? Experts adviseren geduld te hebben, zelfs als uw uiteindelijke doel is om de softwareontwikkelingscyclus en bedrijfsprocessen te versnellen.<\/b><\/p>\n1. Vergeet niet dat veranderingen in de cultuur tijd nodig hebben<\/h4>\n
\nJayne Groll, uitvoerend directeur van het DevOps Institute:<\/b> Naar mijn mening moet de uitbreiding van DevOps net zo geleidelijk en iteratief zijn als agile ontwikkeling (en evenzeer de cultuur betreffen). In Agile en DevOps ligt de focus op kleine teams. Maar naarmate het aantal en de integratie van deze teams toeneemt, krijgen we steeds meer mensen die nieuwe werkmethoden toepassen, wat leidt tot een ingrijpende culturele transformatie.<\/p>\n2. Besteed voldoende tijd aan planning en platformkeuze<\/h4>\n
\nEran Kinsbruner, hoofd technische evangelist bij Perfecto:<\/b> Om schaalbaarheid te laten werken, moeten DevOps-teams in het begin leren traditionele processen, tools en vaardigheden te combineren, en vervolgens elke afzonderlijke fase van DevOps langzaam opbouwen en stabiliseren. Alles begint met zorgvuldige planning van gebruikersverhalen en waardestromen, waarna de fase van softwareontwikkeling en versiebeheer volgt met behulp van trunk-based development of andere methoden die het beste zijn voor het takken en samenvoegen van code.<\/p>\n
Daarna volgt de fase van integratie en testen, waar al een schaalbaar platform voor automatisering vereist is. Hier is het belangrijk voor DevOps-teams om het juiste platform te kiezen dat aansluit bij hun vaardigheidsniveau en de uiteindelijke doelstellingen van het project. <\/p>\n
De volgende fase is de implementatie in de productieomgeving, die volledig geautomatiseerd moet zijn met behulp van orkestratie- en container tools. Het is belangrijk om virtualiseerde omgevingen te hebben in alle fasen van DevOps (simulator van de productieomgeving, kwaliteitscontrole omgeving, en de productieomgeving zelf) en altijd alleen de meest recente gegevens voor tests te gebruiken om actuele inzichten te krijgen. De analyse moet intelligent zijn en in staat om big data te verwerken met snelle en effectieve feedback.<\/p>\n
3. Verwijder de verantwoordelijkheid van schuldgevoelens<\/h4>\n \nGordon Haff, evangelist bij RedHat:<\/b> \u00abHet cre\u00ebren van een systeem en een sfeer die experimenten toestaan en aanmoedigen, maakt het mogelijk om de zogenaamde succesvolle mislukkingen in agile softwareontwikkeling te realiseren. Dit betekent niet dat niemand meer verantwoordelijk is voor mislukkingen. In feite wordt het aanwijzen van een verantwoordelijke zelfs gemakkelijker, aangezien \u2018verantwoordelijk zijn\u2019 niet langer betekent \u2018de schuldige zijn\u2019. Met andere woorden, de essentie van verantwoordelijkheid verandert kwalitatief. Hierbij worden vier factoren uiterst belangrijk: de omvang van de mislukking, de benaderingen, de productieprocessen en de prikkels\u00bb. (Meer over deze factoren is te lezen in het artikel van Gordon Haff \u2018DevOps lessons: 4 aspects of healthy experiments\u2019.)<\/p>\n4. Ruim de weg vrij<\/h4>\n
\nBen Grinnell, managing director en hoofd digitale technologie\u00ebn bij het adviesbureau North Highland:<\/b> \u00abOm schaling te bereiken, raad ik aan om samen met de pioniersprojecten een programma voor \u2018het vrijmaken van de weg\u2019 te lanceren. Het doel van dit programma is om het afval op te ruimen dat achterblijft bij de pioniers van DevOps, zoals verouderde regels en andere soortgelijke zaken, zodat de weg naar voren vrij blijft\u00bb.<\/p>\n
\u00abGeef mensen organisatorische ondersteuning en geef een impuls via communicatie die ver buiten de groep van pioniers reikt, door de successen van nieuwe werkmethodes breed te vieren. Train de mensen die betrokken zijn bij de volgende golf van DevOps-projecten en die nerveus zijn omdat ze DevOps voor het eerst gebruiken. En onthoud dat deze mensen sterk verschillen van de pioniers\u00bb.<\/p>\n
5. Maak de tools toegankelijker<\/h4>\n \nSteve Newman, oprichter en voorzitter van Scalyr:<\/b> \u00abTools moeten niet verborgen zijn voor mensen en ze moeten relatief eenvoudig zijn om te leren voor iedereen die bereid is daar tijd in te investeren. Als de mogelijkheid om logs op te vragen alleen beschikbaar is voor drie mensen die \u2018gecertificeerd\u2019 zijn om met een bepaalde tool te werken, hebt u altijd maximaal drie mensen die het probleem kunnen begrijpen, zelfs als u een zeer grote computingomgeving heeft. Met andere woorden, hier ontstaat een bottleneck die ernstige (zakelijke) gevolgen kan hebben\u00bb.<\/p>\n6. Cre\u00eber ideale omstandigheden voor teams<\/h4>\n
\nTom Clark, hoofd Common Platform bij ITV:<\/b> \u00abJe hebt de vrijheid om alles te doen, maar niet alles tegelijk. Stel daarom grote doelen, begin klein en ga vooruit met snelle iteraties. Na verloop van tijd bouw je een reputatie op als team dat het goed doet, zodat anderen ook willen gebruikmaken van jouw methoden. En jaag niet op het cre\u00ebren van een hooggepresteerd team. Zorg in plaats daarvan voor ideale werkomstandigheden en de effectiviteit komt vanzelf\u00bb.<\/p>\n7. Vergeet de wet van Conway en kanban-borden niet<\/h4>\n
\nLogan Daigle, directeur softwarelevering en DevOps-strategie bij CollabNetVersionOne:<\/b> \u00abHet is belangrijk om de gevolgen van de wet van Conway te begrijpen. In mijn vrije vertaling zegt deze wet dat de producten die we cre\u00ebren en de processen die we gebruiken, inclusief DevOps, op dezelfde manier zijn ingericht als onze organisatie\u00bb.<\/p>\n
\u00abAls een organisatie hoog fragmentarisch is en het management tijdens het plannen, cre\u00ebren en uitbrengen van software meerdere keren van handen verandert, zal het effect van opschaling nul of van korte duur zijn. Maar als de organisatie cross-functionele teams vormt rond producten die met een marktgerichte financiering zijn opgezet, dan groeit de kans op succes aanzienlijk\u00bb.<\/p>\n
\u00abEen ander belangrijk aspect van opschalen is om alle werkprocessen (WIP, work in progress) op kanban-borden weer te geven. Wanneer er in een organisatie een plek is waar mensen dit kunnen zien, stimuleert dat de samenwerking enorm, wat een positieve invloed heeft op het opschalen\u00bb.<\/p>\n
8. Zoek naar oude littekens<\/h4>\n \nManuel Pais, DevOps-consultant en co-auteur van het boek 'Team Topologies':<\/b> \u00abHet toepassen van DevOps-praktijken buiten de daadwerkelijke Dev en Ops en proberen deze toe te passen op andere functies kan zeker niet de optimale benadering worden genoemd. Dit zal zeker enige effecten hebben (bijvoorbeeld door handmatige controle te automatiseren), maar je kunt veel meer bereiken door te beginnen met het begrijpen van de leveringsprocessen en feedback\u00bb.<\/p>\n
Als er in het IT-systeem van een organisatie oude littekens zijn \u2013 procedures en beheersmechanismen die zijn ingevoerd naar aanleiding van eerdere incidenten, maar die hun relevantie hebben verloren (door veranderingen in producten, technologie of processen) \u2013 dan moeten deze zonder twijfel worden verwijderd of gladgestreken, en mogen geen ineffectieve of overbodige processen geautomatiseerd worden.<\/p>\n
9. Cre\u00eber geen varianten van DevOps<\/h4>\n \nAntony Edwards, directeur productie bij Eggplant:<\/b> \u201eDevOps is een zeer vage term, waardoor elk team zijn eigen variant van DevOps heeft. Niets is erger dan wanneer er binnen een organisatie 20 verschillende variaties van DevOps ontstaan die niet goed samenwerken. Het is niet acceptabel dat elk van de drie ontwikkelteams zijn eigen unieke interface heeft tussen ontwikkeling en productbeheer. Evenmin mogen producten hun eigen unieke verwachtingen hebben wat betreft feedbackverwerking bij de overgang naar een gesimuleerde productieomgeving. Anders zul je DevOps nooit kunnen opschalen.\u201d<\/p>\n10. Predik de waarde van DevOps voor het bedrijfsleven<\/h4>\n
\nSteve Newman, oprichter en voorzitter van Scalyr:<\/b> \u201eWerk aan het erkennen van de waarde van DevOps. Leer en schaam je niet om te vertellen over de voordelen van wat je doet. DevOps bespaart ongelooflijk veel tijd en geld (denk maar eens: minder uitvaltijd, kortere gemiddelde herstelperiode), en DevOps-teams moeten onvermoeibaar de belangrijkheid van deze initiatieven voor het succes van het bedrijf benadrukken (en prediken). Zo kun je je kring van aanhangers uitbreiden en de invloed van DevOps binnen de organisatie versterken.\u201d<\/p>\nBONUS<\/h3>\n
\nOp Red Hat Forum Rusland<\/a><\/noindex> Op 13 september komt onze eigen DevOps \u2013 ja, bij Red Hat, als softwareproducent, hebben we onze eigen DevOps-teams en praktijken.<\/b><\/p>\nOnze engineer Mark Birger, die interne automatiseringsdiensten ontwikkelt voor andere teams in de hele organisatie, vertelt in gewoon Nederlands zijn eigen verhaal \u2013 hoe het DevOps-team van Red Hat applicaties migreerde van virtuele omgevingen beheerd door Ansible naar een volledig containerformaat op het OpenShift-platform.<\/p>\n
Maar dat is nog niet alles:<\/b><\/p>\n
Nadat organisaties hun werkbelastingen naar containers hebben overgebracht, functioneren traditionele methoden voor applicatiemonitoring mogelijk niet meer. In dit tweede rapport zullen we onze motivatie voor het veranderen van onze registratiemethoden uitleggen en de voortgang tonen die ons naar moderne technieken voor logging en monitoring heeft geleid.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0440\u0443\u0434\u043d\u043e \u0443\u043b\u043e\u0432\u0438\u0442\u044c \u0433\u043b\u0430\u0432\u043d\u043e\u0435, \u0433\u043e\u0432\u043e\u0440\u044f \u043e DevOps? \u041c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u044f\u0440\u043a\u0438\u0435 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0438, \u0443\u0434\u0430\u0440\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0443\u043b\u0438\u0440\u043e\u0432\u043a\u0438 \u0438 \u0441\u043e\u0432\u0435\u0442\u044b \u043e\u0442 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0434\u043e\u0439\u0442\u0438 \u0434\u043e \u0441\u0443\u0442\u0438 \u0434\u0430\u0436\u0435 \u043d\u0435\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430\u043c. \u0412 \u043a\u043e\u043d\u0446\u0435 \u0431\u043e\u043d\u0443\u0441 \u2013 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 DevOps \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u043e\u0432 Red Hat. \u0422\u0435\u0440\u043c\u0438\u043d DevOps \u0432\u043e\u0437\u043d\u0438\u043a 10 \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u0438 \u043f\u0440\u043e\u0448\u0435\u043b \u043f\u0443\u0442\u044c \u043e\u0442 \u0445\u044d\u0448\u0442\u0435\u0433\u0430 \u0432 \u0422\u0432\u0438\u0442\u0442\u0435\u0440\u0435 \u0434\u043e \u043c\u043e\u0449\u043d\u043e\u0433\u043e \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043d\u043e\u0433\u043e \u0434\u0432\u0438\u0436\u0435\u043d\u0438\u044f \u0432 \u043c\u0438\u0440\u0435 \u0418\u0422, \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-37551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"We](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")