Is het moeilijk om het belangrijkste punt te begrijpen als we het over DevOps hebben? We hebben voor u levendige analogieën, opvallende formuleringen en advies van experts verzameld die zelfs niet-specialisten zullen helpen ter zake te komen. Uiteindelijk is de bonus de eigen DevOps van Red Hat-medewerkers.
De term DevOps ontstond tien jaar geleden en is van een Twitter-hashtag uitgegroeid tot een krachtige culturele beweging in de IT-wereld, een echte filosofie die ontwikkelaars aanmoedigt om dingen sneller gedaan te krijgen, te experimenteren en vooruit te komen. DevOps is onlosmakelijk verbonden geraakt met het concept van digitale transformatie. Maar zoals vaak gebeurt met IT-terminologie, heeft DevOps de afgelopen tien jaar veel definities, interpretaties en misvattingen over zichzelf verworven.
Daarom hoor je vaak vragen over DevOps, zoals: is het hetzelfde als agile? Of is dit een speciale methodologie? Of is het gewoon een ander synoniem voor het woord ‘samenwerking’?
DevOps omvat veel verschillende concepten (continue levering, continue integratie, automatisering, enz.), dus het kan een uitdaging zijn om te destilleren wat belangrijk is, vooral als je gepassioneerd bent over het onderwerp. Deze vaardigheid is echter zeer nuttig, ongeacht of u uw ideeën aan uw superieuren probeert over te brengen of gewoon iemand uit uw familie of vrienden over uw werk vertelt. Laten we dus de terminologische nuances van DevOps voorlopig opzij zetten en ons concentreren op het grote geheel.
Wat is DevOps: 6 definities en analogieën
We 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 de resultaten van deze gesprekken hebben we de meest opvallende analogieën en opvallende formuleringen geselecteerd waarmee jij jouw verhaal over DevOps kunt opbouwen.
1. DevOps is een culturele beweging
“DevOps is een culturele beweging waarin beide partijen (softwareontwikkelaars en specialisten op het gebied van IT-systeembeheer) erkennen dat software pas echte voordelen oplevert als iemand het gaat gebruiken: klanten, klanten, werknemers, waar het niet om gaat”, zegt Eveline Oehrlich, senior onderzoeker. analist bij het DevOps Instituut. “Beide partijen zorgen daarom gezamenlijk voor een snelle en hoogwaardige oplevering van software.”
2. DevOps gaat over het empoweren van ontwikkelaars.
“DevOps stelt ontwikkelaars in staat om applicaties te bezitten, uit te voeren en de levering van begin tot eind te beheren.”
“Normaal gesproken wordt over DevOps gesproken als een manier om de levering van applicaties aan de productie te versnellen door geautomatiseerde processen te bouwen en te implementeren”, zegt Jai Schniepp, directeur van DevOps-platforms bij verzekeringsmaatschappij Liberty Mutual. “Maar voor mij is het veel fundamenteler.” DevOps stelt ontwikkelaars in staat om applicaties of specifieke stukjes software te bezitten, deze uit te voeren en de levering ervan van begin tot eind te beheren. DevOps elimineert verwarring over verantwoordelijkheid en begeleidt iedereen die betrokken is bij het creëren van een geautomatiseerde, door ontwikkelaars aangestuurde infrastructuur.”
3. DevOps gaat over samenwerking bij het maken en opleveren van applicaties.
“Simpel gezegd is DevOps een benadering van softwareproductie en -levering waarbij iedereen samenwerkt”, zegt Gur Staf, president en hoofd digitale bedrijfsautomatisering bij BMC.
4. DevOps is een pijplijn
“Conveyorassemblage is alleen mogelijk als alle onderdelen in elkaar passen.”
“Ik zou DevOps vergelijken met een assemblagelijn voor auto’s”, vervolgt Gur Staff. – Het idee is om alle onderdelen vooraf te ontwerpen en te maken, zodat ze vervolgens zonder individuele aanpassingen kunnen worden gemonteerd. Transportbandmontage is alleen mogelijk als alle onderdelen in elkaar passen. Degenen die een motor ontwerpen en bouwen, moeten overwegen hoe ze deze op de carrosserie of het frame moeten monteren. Degenen die de remmen maken, moeten aan de wielen denken, enzovoort. Hetzelfde zou met software moeten gelden.
Een ontwikkelaar die bedrijfslogica of een gebruikersinterface creëert, moet nadenken over de database waarin klantinformatie wordt opgeslagen, de beveiligingsmaatregelen om gebruikersgegevens te beschermen, en hoe dit allemaal zal werken wanneer de service een groot gebruikerspubliek van misschien zelfs miljoenen dollars gaat bedienen. ."
“Mensen laten samenwerken en nadenken over de delen van het werk die anderen doen, in plaats van zich uitsluitend op hun eigen taken te concentreren, is het grootste obstakel dat moet worden overwonnen. Als je dit kunt, heb je een uitstekende kans op digitale transformatie”, aldus Gur Staff.
5. DevOps is de juiste combinatie van mensen, processen en automatisering
Jayne Groll, uitvoerend directeur van het DevOps Institute, bood een geweldige analogie om DevOps uit te leggen. In haar woorden: “DevOps is als een recept met drie hoofdcategorieën ingrediënten: mensen, processen en automatisering. De meeste van deze ingrediënten kunnen uit andere gebieden en bronnen gehaald worden: Lean, Agile, SRE, CI/CD, ITIL, leiderschap, cultuur, tools. Het geheim van DevOps is, zoals elk goed recept, hoe je de juiste verhoudingen en mix van deze ingrediënten kunt krijgen om de snelheid en efficiëntie van het maken en vrijgeven van applicaties te verhogen.”
6. Bij DevOps werken programmeurs als een Formule 1-team
“De race is niet van start tot finish gepland, maar juist van finish tot start.”
“Als ik het heb over wat ik van een DevOps-initiatief kan verwachten, denk ik aan een NASCAR- of Formule 1-raceteam als voorbeeld”, zegt Chris Short, senior manager cloudplatformmarketing bij Red Hat en uitgever van de DevOps-nieuwsbrief. – De leider van zo’n team heeft één doel: aan het einde van de race een zo hoog mogelijke plaats innemen, rekening houdend met de middelen waarover het team beschikt en de uitdagingen die het tegenkomt. In dit geval wordt de race niet van start tot finish gepland, maar integendeel, van finish tot start. Eerst wordt een ambitieus doel gesteld en vervolgens worden manieren bepaald om dit te bereiken. Vervolgens worden ze opgesplitst in subtaken en gedelegeerd aan teamleden.”
“Het team is de hele week voor de race bezig met het perfectioneren van de pitstop. Hij doet krachttraining en cardio om in vorm te blijven voor een slopende racedag. Oefeningen die samenwerken om eventuele problemen op te lossen die zich tijdens de race kunnen voordoen. Op dezelfde manier moet het ontwikkelingsteam de vaardigheid trainen om regelmatig nieuwe versies uit te brengen. Als je over dergelijke vaardigheden en een goed functionerend beveiligingssysteem beschikt, gebeurt het ook vaker dat nieuwe versies in productie worden genomen. In dit wereldbeeld betekent hogere snelheid meer veiligheid”, zegt Short.
“Het gaat niet om het ‘juiste doen’”, voegt Short eraan toe, “het gaat om het elimineren van zoveel mogelijk dingen die het gewenste resultaat in de weg staan. Werk samen en pas je aan op basis van de feedback die je in realtime ontvangt. Wees voorbereid op afwijkingen en werk aan het verbeteren van de kwaliteit om de impact ervan op de voortgang richting uw doel te minimaliseren. Dit is wat ons te wachten staat in de wereld van DevOps.”
Hoe DevOps te schalen: 10 tips van experts
Het is alleen zo dat DevOps en massale DevOps totaal verschillende dingen zijn. We zullen u vertellen hoe u barrières kunt overwinnen op weg van de eerste naar de tweede.
Voor veel organisaties begint de reis naar DevOps gemakkelijk en prettig. Er ontstaan kleine, gepassioneerde teams, oude processen worden vervangen door nieuwe en de eerste successen laten niet lang op zich wachten.
Helaas, dit is slechts een valse glitter, een illusie van vooruitgang, zegt Ben Grinnell, algemeen directeur en hoofd digitaal bij adviesbureau North Highland. Vroege overwinningen zijn zeker bemoedigend, maar ze dragen niet bij aan het bereiken van het uiteindelijke doel van een brede adoptie van DevOps in de hele organisatie.
Het is gemakkelijk in te zien dat het resultaat een cultuur van verdeeldheid is tussen ‘wij’ en ‘zij’.
“Vaak lanceren organisaties deze baanbrekende projecten in de veronderstelling dat ze de weg zullen vrijmaken voor mainstream DevOps, zonder na te denken of anderen dat pad kunnen of willen volgen”, legt Ben Grinnell uit. – Teams voor de uitvoering van dergelijke projecten worden meestal gerekruteerd uit zelfverzekerde “Varangianen” die op andere plaatsen al iets soortgelijks hebben gedaan, maar nieuw zijn voor uw organisatie. Tegelijkertijd worden ze aangemoedigd om de regels die voor alle anderen bindend blijven, te overtreden en te vernietigen. Het is gemakkelijk in te zien dat het resultaat een cultuur van ‘wij’ en ‘zij’ is die de overdracht van kennis en vaardigheden belemmert.”
“En dit culturele probleem is slechts een van de redenen dat DevOps moeilijk schaalbaar is. DevOps-teams worden geconfronteerd met toenemende technische uitdagingen die typerend zijn voor snelgroeiende IT-first-bedrijven”, zegt Steve Newman, oprichter en voorzitter van Scalyr.
“In de moderne wereld veranderen diensten zodra de behoefte zich voordoet. Het is geweldig om voortdurend nieuwe functies te implementeren en te implementeren, maar het coördineren van dit proces en het elimineren van problemen die zich voordoen is een echte hoofdpijn, voegt Steve Newman toe. – In zeer snelgroeiende organisaties hebben ingenieurs in cross-functionele teams moeite om inzicht te behouden in de veranderingen en de trapsgewijze effecten die deze met zich meebrengen op afhankelijkheidsniveau. Bovendien zijn ingenieurs niet blij als hen deze kans wordt ontnomen, en als gevolg daarvan wordt het voor hen moeilijker om de essentie van de problemen die zich voordoen te begrijpen.”
Hoe kunnen we de hierboven beschreven uitdagingen overwinnen en overgaan tot massale adoptie van DevOps in een grote organisatie? Deskundigen dringen aan op geduld, zelfs als het uw uiteindelijke doel is om uw softwareontwikkelingscyclus en bedrijfsprocessen te versnellen.
1. Bedenk dat cultuurverandering tijd kost.
Jayne Groll, uitvoerend directeur, DevOps Instituut: “Naar mijn mening zou de uitbreiding van DevOps net zo incrementeel en iteratief moeten zijn als agile ontwikkeling (en evenzeer de cultuur raken). Agile en DevOps leggen de nadruk op kleine teams. Maar naarmate deze teams in aantal en integratie groeien, zullen steeds meer mensen nieuwe manieren van werken adopteren, met als resultaat een enorme culturele transformatie.”
2. Besteed voldoende tijd aan het plannen en kiezen van een platform
Eran Kinsbruner, hoofd technische evangelist bij Perfecto: “Om opschaling te laten werken, moeten DevOps-teams eerst leren traditionele processen, tools en vaardigheden te combineren, en vervolgens langzaam elke afzonderlijke fase van DevOps koesteren en stabiliseren. Het begint allemaal met een zorgvuldige planning van gebruikersverhalen en waardestromen, gevolgd door het schrijven van software en versiebeheer met behulp van trunk-gebaseerde ontwikkeling of andere benaderingen die het meest geschikt zijn voor het vertakken en samenvoegen van code.”
“Dan komt de integratie- en testfase, waarin al een schaalbaar platform voor automatisering nodig is. Dit is waar het belangrijk is voor DevOps-teams om het juiste platform te kiezen dat past bij hun vaardigheidsniveau en de einddoelen van het project.
De volgende fase is de implementatie in productie en dit moet volledig geautomatiseerd worden met behulp van orkestratietools en containers. Het is belangrijk om gevirtualiseerde omgevingen te hebben in alle stadia van DevOps (productiesimulator, QA-omgeving en daadwerkelijke productieomgeving) en altijd alleen de nieuwste gegevens te gebruiken voor tests om relevante conclusies te verkrijgen. Analytics moet slim zijn en in staat zijn om big data te verwerken met snelle en bruikbare feedback.”
3. Haal de schuld uit de verantwoordelijkheid.
Gordon Haff, RedHat-evangelist: “Het creëren van een systeem en een sfeer die experimenteren mogelijk maakt en aanmoedigt, maakt zogenaamde succesvolle mislukkingen in agile softwareontwikkeling mogelijk. Dit betekent niet dat niemand anders verantwoordelijk is voor mislukkingen. In feite wordt het nog eenvoudiger om te identificeren wie verantwoordelijk is, omdat ‘verantwoordelijk zijn’ niet langer betekent ‘een ongeluk veroorzaken’. Dat wil zeggen, de essentie van verantwoordelijkheid verandert kwalitatief. Vier factoren worden van cruciaal belang: de omvang van de verstoring, de aanpak, de productieprocessen en de prikkels.” (Je kunt meer over deze factoren lezen in Gordon Huffs artikel “DevOps-lessen: 4 aspecten van gezonde experimenten.”)
4. Maak het pad vrij
Ben Grinnell, algemeen directeur en hoofd digitaal bij adviesbureau North Highland: “Om schaalgrootte te bereiken, raad ik aan om samen met baanbrekende projecten een programma voor het vrijmaken van paden te lanceren. Het doel van dit programma is om de rommel op te ruimen die DevOps-pioniers achterlaten, zoals verouderde regels en dergelijke, zodat de weg vooruit vrij blijft.”
“Geef mensen organisatorische steun en momentum door middel van communicatie die veel verder gaat dan de pioniersgroep, door de successen van nieuwe manieren van werken breed te vieren. Coach mensen die betrokken zijn bij de volgende golf van DevOps-projecten en zenuwachtig zijn om DevOps voor het eerst te gebruiken. En vergeet niet dat deze mensen heel anders zijn dan de pioniers.”
5. Democratiseer instrumenten
Steve Newman, oprichter en voorzitter van Scalyr: “Hulpmiddelen mogen niet voor mensen verborgen blijven, en ze moeten relatief eenvoudig te leren zijn voor iedereen die er tijd in wil steken. Als de mogelijkheid om logboeken op te vragen beperkt is tot drie mensen die "gecertificeerd" zijn om een tool te gebruiken, heeft u altijd maximaal drie mensen beschikbaar om het probleem op te lossen, zelfs als u een zeer grote computeromgeving heeft. Er zit met andere woorden een knelpunt dat tot ernstige (bedrijfs)gevolgen kan leiden.”
6. Creëer ideale omstandigheden voor teamwerk
Tom Clark, hoofd van Common Platform bij ITV: “Je kunt alles doen, maar niet alles tegelijk. Stel dus grote doelen, begin klein en ga in snelle iteraties vooruit. Na verloop van tijd zul je een reputatie ontwikkelen dat je dingen voor elkaar krijgt, zodat anderen jouw methoden ook willen gebruiken. En maak je geen zorgen over het opbouwen van een zeer effectief team. Bied mensen in plaats daarvan ideale werkomstandigheden en efficiëntie zal volgen.”
7. Vergeet Conway's Law en Kanban-borden niet
Logan Daigle, directeur Software Delivery en DevOps Strategy bij CollabNetVersionOne: “Het is belangrijk om de gevolgen van de wet van Conway te begrijpen. In mijn losse parafrase stelt deze wet dat de producten die we maken en de processen die we daarbij gebruiken, inclusief DevOps, op dezelfde manier blijken te zijn gestructureerd als onze organisatie.”
“Als er veel silo’s in een organisatie zijn en de controle vaak van eigenaar wisselt bij het plannen, bouwen en uitbrengen van software, zal het effect van schaalvergroting nul zijn of van korte duur zijn. Als een organisatie cross-functionele teams bouwt rond producten die marktgericht worden gefinancierd, dan neemt de kans op succes dramatisch toe.”
“Een ander belangrijk aspect van schaling is het weergeven van al het onderhanden werk (WIP, work in progress) op Kanban-borden. Als een organisatie een plek heeft waar mensen deze dingen kunnen zien, stimuleert dat de samenwerking enorm, wat een positieve impact heeft op de schaalvergroting.”
8. Zoek naar oude littekens
Manuel Pais, DevOps-consultant en co-auteur van Team Topologies: “DevOps-praktijken verder brengen dan Dev en Ops zelf en proberen deze toe te passen op andere functies is nauwelijks een optimale aanpak. Dit zal zeker enige impact hebben (bijvoorbeeld door de handmatige controle te automatiseren), maar er kan veel meer bereikt worden als we beginnen met het begrijpen van de leverings- en feedbackprocessen.”
“Als er oude littekens zitten in het IT-systeem van een organisatie – procedures en managementmechanismen die zijn geïmplementeerd als gevolg van incidenten uit het verleden, maar hun relevantie hebben verloren (door veranderingen in producten, technologieën of processen) – dan moeten deze zeker worden verwijderd of gladgestreken, in plaats van inefficiënte of onnodige processen te automatiseren.”
9. Fok geen DevOps-opties
Anthony Edwards, operationeel directeur bij Aubergine: “DevOps is een heel vage term, waardoor elk team uiteindelijk zijn eigen versie van DevOps krijgt. En er is niets ergers als een organisatie plotseling twintig varianten van DevOps heeft die niet zo goed met elkaar overweg kunnen. Het is onmogelijk dat elk van de drie ontwikkelingsteams een eigen, speciale interface heeft tussen ontwikkeling en productbeheer. Ook mogen producten geen eigen unieke verwachtingen hebben ten aanzien van het omgaan met feedback wanneer ze worden overgebracht naar een productiesimulator. Anders kun je DevOps nooit opschalen.”
10. Predik de zakelijke waarde van DevOps
Steve Newman, oprichter en voorzitter van Scalyr: “Werk om de waarde van DevOps te erkennen. Leer en praat gerust over de voordelen van wat u doet. DevOps bespaart ongelooflijk veel tijd en geld (denk maar aan: minder downtime, kortere gemiddelde hersteltijd), en DevOps-teams moeten onvermoeibaar het belang van deze initiatieven voor zakelijk succes benadrukken (en prediken). Zo kun je de kring van aanhangers vergroten en de invloed van DevOps in de organisatie vergroten.”
BONUS
Op Onze eigen DevOps komt op 13 september - ja, Red Hat heeft als softwarefabrikant zijn eigen DevOps-teams en -praktijken.
Onze ingenieur Mark Birger, die interne automatiseringsdiensten ontwikkelt voor andere groepen binnen de organisatie, zal in puur Russisch zijn eigen verhaal vertellen - hoe het Red Hat DevOps-team applicaties migreerde van Hat Virtualization virtuele omgevingen beheerd door Ansible naar een volwaardig containerformaat op het OpenShift-platform.
Maar dat is niet alles:
Zodra organisaties de werklasten naar containers hebben verplaatst, werken traditionele methoden voor applicatiemonitoring mogelijk niet meer. In de tweede lezing zullen we onze motivatie voor het veranderen van de manier waarop we loggen uitleggen en de voortzetting laten zien van het pad dat ons naar moderne houtkap- en monitoringmethoden heeft geleid.
Bron: www.habr.com