{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Wat is DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De definitie van DevOps is zeer complex, waardoor we elke keer opnieuw de discussie erover moeten aangaan. Alleen al op Habr zijn er duizenden publicaties over dit onderwerp. Maar als je dit leest, weet je waarschijnlijk wat DevOps is. Want ik niet. Hallo, mijn naam is Alexander Titov (@osminog<\/a><\/noindex><\/b>), en we gaan het gewoon even hebben over DevOps en ik zal mijn ervaringen delen.<\/p>\n

\"Wat
\n
\nIk heb lang nagedacht over hoe ik mijn verhaal nuttig kan maken, dus hier zullen veel vragen zijn - de vragen die ik mezelf stel en die ik aan de klanten van ons bedrijf stel. Door deze vragen te beantwoorden, wordt het begrip beter. Ik zal vertellen waarom DevOps nodig is vanuit mijn perspectief, wat het precies inhoudt, opnieuw vanuit mijn positie, en hoe je kunt begrijpen dat je op weg bent naar DevOps, wederom vanuit mijn gezichtspunt. Het laatste punt komt aan bod via vragen. Door deze zelf te beantwoorden, kun je begrijpen of jouw bedrijf op weg is naar DevOps of dat er ergens problemen zijn.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\nEen tijdje heb ik me vermaakt op de golven van fusies en overnames. Eerst werkte ik bij de kleine startup Qik, daarna werd het overgenomen door het iets grotere bedrijf Skype, dat vervolgens weer werd overgenomen door het nog grotere bedrijf Microsoft. Op dat moment kreeg ik inzicht in hoe de visie op DevOps transformeert in bedrijven van verschillende groottes. Hierna werd ik vanuit de marktperspectief steeds meer ge\u00efnteresseerd in DevOps, en samen met collega's hebben we het bedrijf Express 42 opgericht. Al 6 jaar navigeren we daarmee op de marktwaves.<\/p>\n

Bovendien ben ik een van de organisatoren van de community DevOps Moscow en organisator van DevOps-Days 2017, maar in 2018 heb ik dat niet georganiseerd. Express 42 werkt met veel bedrijven. We helpen daar DevOps op te zetten, kijken hoe het verloopt, trekken conclusies, analyseren, delen onze bevindingen met iedereen en leren mensen DevOps-praktijken. Kortom, we groeien op dit vlak in ervaring en expertise.<\/p>\n

Waarom DevOps<\/h2>\n

\nDe eerste vraag die iedereen overal en altijd achtervolgt - waarom? Veel mensen denken dat DevOps gewoon automatisering is of iets dergelijks, iets wat al in elk bedrijf aanwezig was.<\/p>\n

\u2018Wij hadden Continuous Integration - dat betekent dat er al DevOps was, en waarom hebben we al deze rommel nodig? Daar in het buitenland vermaken ze zich, terwijl ze ons hier alleen maar laten werken!\u2019<\/i><\/p>\n

Na 9 jaar van ontwikkeling van de gemeenschap en de methodologie is het al duidelijk dat dit geen marketingtrucjes zijn, maar er is nog steeds niet helemaal duidelijk waarom het nodig is. Zoals bij elke tool en elk proces heeft DevOps specifieke doelen die het uiteindelijk bereikt.<\/p>\n

Dit heeft te maken met het feit dat de wereld verandert. Het verlaat de enterprise-aanpak waarbij bedrijven meteen naar hun droom streven, zoals onze Sint-Petersburgse klassieker zong, van punt A naar punt B volgens een bepaalde strategie, met een specifieke structuur die daarvoor is opgezet. <\/p>\n

\"Wat
\n<\/p>\n

In principe zou alles in IT moeten zijn ingericht volgens deze aanpak. Hier wordt IT uitsluitend gebruikt voor het automatiseren van processen.<\/p><\/blockquote>\n

\nAutomatisering verandert vaak niet, omdat wanneer een bedrijf in een sleur zit \u2013 wat valt daar aan te passen? Het werkt \u2013 niet aanraken. Tegenwoordig veranderen de benaderingen in de wereld, en die welke de naam Agile dragen, geven aan dat het eindpunt B niet meteen zichtbaar is.<\/p>\n

\"Wat
\n
\nWanneer een bedrijf de markt opgaat en met de klant werkt, verkent het voortdurend de markt en verandert het eindpunt B. Namelijk, hoe vaker een bedrijf van richting verandert, hoe succesvoller het uiteindelijk is, omdat het meer marktniches kiest.<\/p>\n

Een interessante organisatie laat de strategie zien, waar ik onlangs over hoorde. One Box Shave is een abonnementsdienst voor het bezorgen van scheermesjes en scheerbenodigdheden in een doos. Ze kunnen hun 'doosje' aanpassen aan verschillende klanten. Dit wordt gedaan door specifieke software die vervolgens de bestelling naar een Koreaanse fabriek stuurt die het product produceert.<\/p>\n

Dit product werd gekocht door het bedrijf Unilever voor 1 miljard dollar. Het concurreert nu met Gillette en heeft een aanzienlijk marktaandeel van consumenten in de Amerikaanse markt afgesnoept. One Box Shave zegt:<\/p>\n

\u2014 4 mesjes? Serieus? Waarom zou je dat willen \u2013 dat verbetert de scheerkwaliteit totaal niet. Een speciaal geselecteerde cr\u00e8me, geur en een kwalitatief hoogstaand scheermes met twee mesjes zijn veel effectiever dan deze belachelijke 4 mesjes van Gillette! Gaan we zo snel naar 10?<\/i><\/p>\n

Zo verandert de wereld. Unilever zegt dat ze een geweldig IT-systeem hebben dat dit mogelijk maakt. Uiteindelijk lijkt het op een concept Time-to-market<\/b>, waarover al velen hebben gesproken.<\/p>\n

\"Wat
\n
\nDe betekenis van Time-to-market ligt niet in de frequentie van onze deployments. Het is vaak mogelijk om regelmatig te deployen, maar de releasecycli kunnen dan alsnog lang zijn. Als we drie maanden durende releasecycli op elkaar stapelen en deze met een week verschuiven, lijkt het alsof het bedrijf eenmaal per week deployst. De periode van idee tot uiteindelijke implementatie duurt echter 3 maanden.<\/p>\n

Time-to-market gaat over het minimaliseren van de tijd van idee tot uiteindelijke implementatie.<\/p><\/blockquote>\n

\nIn dit geval interacteert de software met de markt. Dit is vergelijkbaar met hoe One Box Shave met de klant interacteert via de website. Ze hebben geen verkopers; het is gewoon een site waar bezoekers klikken en hun wensen achterlaten. Daarom moet de website continu iets nieuws aanbieden en worden bijgewerkt in overeenstemming met deze wensen. Bijvoorbeeld, in Zuid-Korea scheren ze zich anders dan in Rusland, en ze houden niet van de geur van dennen, maar bijvoorbeeld van vanille wortel.<\/p>\n

Omdat de inhoud van de website snel moet veranderen, verandert de softwareontwikkeling aanzienlijk. Via de software moeten we ontdekken wat de klant wil. Vroeger ontdekten we dit via allerlei omwegen, bijvoorbeeld via business management. Dan ontwerp je, leg je de vereisten vast in het IT-systeem en alles was geweldig. Tegenwoordig is het anders; de software wordt ontworpen door iedereen die bij het proces betrokken is, inclusief engineers, omdat zij via technische specificaties leren hoe de markt werkt en hun inzichten ook met het bedrijf delen.<\/p>\n

Bijvoorbeeld, bij het bedrijf Qik kwamen we er plotseling achter dat mensen het geweldig vonden om contactlijsten op de server te uploaden, en zij hebben een applicatie voor ons ontwikkeld. Dit hadden we in eerste instantie niet overwogen. In een klassiek bedrijf zou iedereen denken dat dit een fout is, omdat het in de specificaties niet staat dat het goed moet werken en het in het algemeen ad hoc is gerealiseerd; ze zouden de functie uitschakelen en zeggen: 'Dat heeft niemand nodig, het belangrijkste is dat de basisfunctionaliteit werkt.' Een technologiebedrijf ziet hierin echter een kans en begint de software in overeenstemming daarmee te wijzigen.<\/p>\n

\"Wat
\n
\nIn 1968 formuleerde de vooruitziende Melvin Conway het volgende idee.<\/p>\n

Een organisatie die een systeem cre\u00ebert, wordt beperkt door het ontwerp dat de communicatiestructuur binnen die organisatie kopieert.<\/p><\/blockquote>\n

\nAls het gaat om het produceren van systemen van een ander type, moet er bovendien een andere communicatiestructuur binnen het bedrijf zijn. Als u een top-down hi\u00ebrarchische communicatiestructuur heeft, zal dit u niet in staat stellen systemen te ontwikkelen die een zeer hoge Time-to-market kunnen waarborgen.<\/p>\n

Lees meer over de wet van Conway<\/a><\/noindex> kan via de links<\/a><\/noindex>. Dit is belangrijk voor het begrijpen van de cultuur of filosofie van DevOps, omdat het enige dat fundamenteel verandert in DevOps de communicatiestructuur tussen teams is.<\/b>.<\/p>\n

Vanuit procesperspectief verliepen tot DevOps alle fasen: analyse, ontwikkeling, testen en exploitatie lineair.\"Wat
\nIn het geval van DevOps verlopen al deze processen gelijktijdig.<\/p>\n

\"Wat
\n
\nTime-to-market kan alleen zo worden gerealiseerd. Voor mensen die in het oude proces hebben gewerkt, lijkt dit enigszins buitenaards en in het algemeen niet zo geweldig.<\/p>\n

Waarom is DevOps nodig?<\/h3>\n

\nVoor de ontwikkeling van digitale producten<\/b>. Als uw bedrijf geen digitaal product heeft, is DevOps niet nodig \u2014 dit is heel belangrijk.<\/p>\n

DevOps overwint de snelheidsbeperkingen van een lineaire softwareproductiestructuur<\/b>. Alle processen gebeuren gelijktijdig.<\/p>\n

De complexiteit neemt toe.<\/b> Wanneer DevOps-evangelisten zeggen dat het makkelijker wordt om software uit te geven met DevOps, is dat onzin.<\/p>\n

Met DevOps wordt alles alleen maar complexer.<\/p><\/blockquote>\n

\nOp de conferentie bij de stand van Avito kon men zien wat het betekent om een Docker-container te deployen - een onmogelijke taak. De complexiteit wordt grensverleggend, je moet met veel ballen tegelijk jongleren.<\/p>\n

DevOps verandert het proces en de organisatie binnen het bedrijf volledig<\/b>\u00a0\u2014 eigenlijk verandert niet DevOps, maar het digitale product. Om DevOps te bereiken, moet dit proces uiteindelijk volledig veranderen.<\/p>\n

Vragen voor de specialist<\/h3>\n

\nEn hoe zit het met u? Vragen die u uzelf kunt stellen terwijl u werkt in het bedrijf en zichzelf ontwikkelt als specialist.<\/p>\n

Heeft u een strategie voor het cre\u00ebren van een digitaal product?<\/b> Als dat zo is, is dat al goed. Dit betekent dat uw bedrijf in de richting van DevOps beweegt.<\/p>\n

Heeft uw bedrijf al een digitaal product gecre\u00eberd?<\/b> Dit betekent dat u nog een stap hoger kunt komen, zich met interessantere zaken kunt bezighouden - vanuit het perspectief van DevOps opnieuw. Daarover spreek ik alleen.<\/p>\n

Is uw bedrijf een van de marktleiders in de niche met een digitaal product?<\/b> Spotify, Yandex, Uber - bedrijven die zich momenteel op de top van technologische vooruitgang bevinden.<\/p>\n

Stel jezelf deze vragen, en als alle antwoorden negatief zijn, is het misschien beter om geen DevOps in dit bedrijf na te streven. Maar als je echt ge\u00efnteresseerd bent in DevOps, moet je misschien naar een ander bedrijf overstappen? Als jouw bedrijf de stap naar DevOps wil maken, maar je hebt alle vragen met 'Nee' beantwoord, dan lijkt het op een prachtige neushoorn die nooit zal veranderen.<\/p>\n

\"Wat
\n<\/p>\n

Organisatie<\/h2>\n

\nZoals ik al zei, verandert de organisatie binnen het bedrijf volgens de wet van Conway. Laten we beginnen met wat DevOps daadwerkelijk belemmert om binnen het bedrijf door te dringen vanuit een organisatorisch perspectief.<\/p>\n

Het probleem van 'silo's'<\/h3>\n

\nHet Engelse woord 'Silo' is hier vertaald naar het Russisch als '\u043a\u043e\u043b\u043e\u0434\u0435\u0446'. De essentie van dit probleem is dat er geen informatie-uitwisseling tussen de teams is.<\/b>Elk team graaft zijn expertise dieper, zonder een gezamenlijke kaart te bouwen waarop men kan navigeren.<\/p>\n

Dit doet denken aan iemand die net in Moskou is aangekomen en nog niet weet hoe hij zich op de metrokaart moet ori\u00ebnteren. Moskouwenaren kennen meestal hun eigen buurt goed, en in heel Moskou ori\u00ebnteren ze zich op de metrokaart. Wanneer je voor het eerst in Moskou bent, heb je deze vaardigheid nog niet en voel je je gewoon gedesori\u00ebnteerd.<\/p>\n

DevOps biedt aan om deze fase van desori\u00ebntatie te doorlopen en samen met alle afdelingen een gezamenlijke kaart van interactie op te bouwen.<\/p><\/blockquote>\n

\nTwee factoren belemmeren dit.<\/p>\n

Het gevolg van het bedrijfssysteem van management.<\/b> Het is opgebouwd uit afzonderlijke hi\u00ebrarchische 'silo's'. Bijvoorbeeld, er zijn bepaalde KPI's in bedrijven die dit systeem ondersteunen. Aan de andere kant is er het brein van de persoon die het moeilijk vindt om buiten zijn expertise te komen en zich in het hele systeem te ori\u00ebnteren. Het is gewoon oncomfortabel. Stel je voor dat je op de luchthaven van Bangkok bent - daar is het moeilijk om je snel te ori\u00ebnteren. In DevOps is het ook moeilijk om je te ori\u00ebnteren, en daarom zeggen mensen dat ze een gids moeten vinden om daar te komen.<\/p>\n

Maar het belangrijkste probleem van 'silo's' voor een ingenieur die zich heeft verdiept in de geest van DevOps, die boeken van Fowler en vele anderen heeft gelezen, is dat 'silo's' het maken van 'evidente' zaken belemmeren.<\/b>We komen vaak bijeen na DevOps Moscow, praten met elkaar, en mensen klagen:<\/p>\n

\u2014 We wanted to start CI, but it turned out that management doesn\u2019t need it.<\/i><\/p>\n

This happens precisely because\u00a0CI <\/b>en\u00a0Continuous Delivery process<\/b> are at the intersection of many areas of expertise. Simply overcoming the 'well problem' at the organizational level won\u2019t allow you to move forward, no matter what you do and how sad it might be.<\/p>\n

\"Wat
\n
\nEvery participant in the process within the company: backend and frontend developers, testers, DBAs, operations, and networks, digs in their own direction, while no one has the overall perspective except for a manager who somehow oversees them and manages by means of 'divide and conquer.'<\/p>\n

People fight over some stars or flags, each one digging into their own expertise.<\/p><\/blockquote>\n

\nAs a result, when the task arises to combine all of this together and build a common pipeline, and there\u2019s no longer a need to fight for stars and flags, the question arises \u2014 what should we actually do? We need to find some way to agree, but how to do that was never taught to us in school. We have been taught since school: eighth grade \u2014 wow! \u2014 in comparison with seventh grade! It\u2019s the same here.<\/p>\n

Is it the same in your company?<\/h3>\n

\nTo check this, you can ask yourself the following questions.<\/p>\n

Do teams use common tools, do they contribute to changes in these common tools?<\/p>\n

Hoe vaak worden teams herschikt - verhuizen sommige specialisten van het ene team naar het andere?<\/b> In de DevOps-omgeving wordt dit normaal, omdat iemand soms gewoon niet kan begrijpen wat een ander expertisegebied doet. Hij verhuist naar een andere afdeling, werkt daar twee weken om voor zichzelf een ori\u00ebntatie- en interactiekaart met die afdeling te cre\u00ebren.<\/p>\n

Can a committee for change be created and something be changed? <\/b>Or does this require a strong hand from the top management and an order? Recently, I posted on Facebook about how one little-known bank implements tools through orders: they issued an order, are implementing it for a year, and monitoring what happens. This is, of course, slow and sad.<\/p>\n

How important is it for managers to achieve personal accomplishments regardless of the company\u2019s achievements? <\/b><\/p>\n

If you answer these questions for yourself, it will become clearer whether you have such a problem in your company.<\/p>\n

Infrastructuur als code<\/h2>\n

\nNadat dit probleem is opgelost, is de eerste belangrijke praktijk, zonder welke het moeilijk is om verder te komen in DevOps, de volgende: infrastructuur als code<\/b>. <\/p>\n

Meestal wordt infrastructuur als code zo ervaren:<\/p>\n

\u2014 Laten we alles automatiseren met bash, ons volstoppen met scripts, zodat de admin minder handmatige werkzaamheden heeft!<\/i><\/p>\n

Maar dat is niet zo.<\/p>\n

Infrastructuur als code betekent dat je het IT-systeem waar je mee werkt beschrijft in de vorm van code, zodat je altijd de staat ervan begrijpt.<\/p><\/blockquote>\n

\nSamen met andere teams maak je een kaart in de vorm van code die voor iedereen begrijpelijk is, waarmee je je kunt ori\u00ebnteren en navigeren. Het maakt niet uit met welke tool het is gedaan \u2014 Chef, Ansible, Salt, of dat YAML-bestanden in Kubernetes worden gebruikt \u2014 het doet er niet toe.<\/p>\n

Op de conferentie vertelde een collega van 2GIS hoe ze hun interne tool voor Kubernetes hebben gemaakt, die de opzet van afzonderlijke systemen beschrijft. Om 500 systemen te beschrijven, hadden ze een aparte tool nodig die deze beschrijving genereert. Wanneer deze beschrijving er is, kan iedereen met elkaar afstemmen, wijzigingen volgen, en verbeteren wat er ontbreekt. <\/p>\n

U moet toegeven dat losse bash-scripts deze duidelijkheid meestal niet bieden. In een van de bedrijven waar ik werkte, was er zelfs een naam voor een \"write-only\"-script \u2014 als het script is geschreven, is het niet meer te lezen. Ik denk dat dit u ook bekend voorkomt.<\/p>\n

Infrastructuur als code is code die de actuele staat van de infrastructuur beschrijft.<\/b>Aan deze code werkt een groot aantal product-, infrastructuur- en serviceteams samen, en het belangrijkste is dat ze allemaal moeten begrijpen hoe deze code eigenlijk werkt.<\/p>\n

De code wordt onderhouden volgens de beste praktijken voor code<\/b>: gezamenlijke ontwikkeling, code-review, XP-programmering, testen, pull requests, CI voor infrastructuurcode \u2014 dit alles is waardevol en kan worden gebruikt.<\/p>\n

Code wordt een gemeenschappelijke taal voor alle ingenieurs.<\/p><\/blockquote>\n

\nHet wijzigen van infrastructuur in code kost niet veel tijd.<\/b>Ja, ook in infrastructuurcode kan technische schuld aanwezig zijn. Gewoonlijk treffen teams dit ongeveer anderhalf jaar aan nadat ze zijn begonnen met het implementeren van 'infrastructuur als code' in de vorm van een hoop scripts of zelfs Ansible, dat ze schrijven als spaghetticode, en er ook nog bash-scripts aan toevoegen! <\/p>\n

Belangrijk<\/b>: als je deze troep nog niet hebt geprobeerd, onthoud dan dat Ansible is geen bash.<\/b>Lees de documentatie aandachtig, en bestudeer wat er over geschreven wordt.<\/p>\n

Infrastructure as Code is het opdelen van infrastructuurcode in afzonderlijke lagen.<\/p><\/blockquote>\n

\nBij ons in het bedrijf onderscheiden we 3 basislagen die heel duidelijk en eenvoudig zijn, maar er kunnen er meer zijn. Je kunt je infrastructuurcode bekijken en zeggen of je aan dit criterium voldoet of niet. Als er geen lagen zijn gedefinieerd, moet je tijd nemen om een beetje te refactoren.
\n\"Wat
\n
\nBasislaag<\/b>\u00a0is hoe het besturingssysteem, back-ups en andere low-level zaken worden ingesteld, zoals hoe Kubernetes op basaal niveau wordt uitgerold.<\/p>\n

Servicelaag<\/b>\u00a0zijn de diensten die je aan de ontwikkelaar aanbiedt: logging als een dienst, monitoring als een dienst, database als een dienst, load balancer als een dienst, queue als een dienst, Continuous Delivery als een dienst - een hoop diensten die afzonderlijke teams kunnen aanbieden aan de ontwikkeling. Dit alles moet in aparte modules in je configuratiebeheersysteem worden beschreven.<\/p>\n

Laag waar toepassingen worden gemaakt<\/b> en beschreven wordt hoe ze bovenop de twee vorige lagen worden uitgerold.<\/p>\n

Controlevragen<\/h3>\n

\nHeeft jouw bedrijf een gezamenlijke infrastructuurrepository? Houd je technische schuld in de infrastructuur in de gaten? Maak je gebruik van ontwikkelingspraktijken in de infrastructuurrepository? Is je infrastructuur in lagen verdeeld? Je kunt controleren met het schema Base-service-APP. Hoe moeilijk is het om een wijziging aan te brengen? <\/p>\n

Als je hebt ervaren dat het aanbrengen van wijzigingen anderhalve dag in beslag nam, betekent dit dat je technische schuld hebt en daar aan moet werken. Je bent precies tegen de obstakels van technische schuld in infrastructuurcode aangelopen. Ik herinner me veel van zulke verhalen, wanneer het veranderen van een bepaalde CCTL vereiste dat je de helft van de infrastructuurcode opnieuw moest schrijven, omdat creativiteit en de wens om alles te automatiseren ervoor hebben gezorgd dat alles verstopt zit, alle handmatige elementen zijn verwijderd, en de code moet worden gerefactoreerd.<\/p>\n

Continue levering<\/h2>\n

\nLaten we de debet met de krediet bij elkaar brengen. Eerst komt er een beschrijving van de infrastructuur, die vrij basaal kan zijn. Het is niet nodig om alles gedetailleerd te beschrijven, maar er is enige basisbeschrijving vereist zodat je hiermee kunt werken. Anders is het onduidelijk op welke basis je vervolgens continue levering kunt doen. Al deze praktijken worden tegelijkertijd ingezet wanneer je met DevOps aan de slag gaat, maar je moet beginnen met het begrijpen van wat je hebt en hoe je dit beheert. Dit is precies de praktijk van infrastructuur als code.<\/p>\n

Nadat duidelijk is geworden wat je hebt en hoe je dit beheert, begin je na te denken over hoe je de ontwikkelaarscode zo snel mogelijk naar productie kunt sturen. Ik bedoel samen met de ontwikkelaar - laten we de \u2018putten\u2019-problematiek onthouden, dus het zijn niet afzonderlijke mensen die dit bedenken, maar als team.<\/p>\n

Toen we\u00a0Vania Evtukhovich<\/b> de eerste boek zagen Jez Humbles<\/b> en de groep auteurs \"Continuous Delivery\"<\/b>, die in 2009 uitkwam, dachten we lang na over hoe we de titel naar het Nederlands konden vertalen. We wilden het vertalen als \"Constant leveren\", maar helaas vertaalden we het als \"Continue levering\". Het lijkt erop dat er iets typisch Nederlands in onze titel zit, met een zekere kracht.<\/p>\n

Constant leveren betekent<\/h3>\n

\nDe code die in de productrepository ligt, kan altijd naar productie worden gepusht.<\/b>Het kan misschien niet worden gepusht, maar het is er altijd klaar voor. Daarom schrijf je altijd code met een moeilijk te verklaren gevoel van onbehagen onderin je rug. Dit gevoel van onbehagen komt vaak op wanneer je infrastructuurcode uitrolt. Dit gevoel van onbehagen moet aanwezig zijn - het stimuleert de denkprocessen die je in staat stellen om code iets anders te schrijven. Dit moet worden vastgelegd in de regels binnen de ontwikkeling.<\/p>\n

Om continu te kunnen leveren, is er een artefact-formaat nodig dat door het infrastructuurplatform gaat. <\/b>Als je verschillende formaten 'afvalproducten' door het infrastructuurplatform gooit, wordt het niet ge\u00fcniformeerd, is het moeilijk te onderhouden, en ontstaat er technische schuld. Het artefactformaat moet op elkaar worden afgestemd - dit is ook een collectieve taak: iedereen moet samenkomen, samen brainstormen en dit formaat bedenken.<\/p>\n

Het artefact wordt continu verbeterd en verandert in de productieomgeving terwijl het door de leveringspijplijn gaat. <\/b>Wanneer het artefact door de pijplijn beweegt, komt het voortdurend in aanraking met ongemakkelijke zaken die lijken op wat er gebeurt met het artefact dat je in productie uitrolt. Als in klassieke ontwikkeling de systeembeheerder verantwoordelijk is voor de uitrol, dan gebeurt dit in het DevOps-proces voortdurend: hier zijn er wat tests gedaan, daar is het in een Kubernetes-cluster geplaatst, dat meer of minder lijkt op productie, en hier is plotseling lastige belastingstest uitgevoerd.<\/p>\n

Het doet enigszins denken aan het spel Pac-Man \u2013 het artefact doorloopt een soort verhaal. Het is belangrijk om te controleren of de code daadwerkelijk het verhaal doorloopt en dat het op de een of andere manier verband houdt met jouw productie. Verhalen uit de productie kunnen worden ge\u00efntegreerd in het Continuous Delivery-proces: het was zo, toen er iets fout ging, laten we dit scenario nu gewoon in het systeem programmeren. Telkens wanneer de code dit scenario doorloopt, zul je de volgende keer niet met dit probleem worden geconfronteerd. Je zult veel eerder op de hoogte zijn van het probleem dan dat het jouw klant bereikt.<\/p>\n

Verschillende deploymentstrategie\u00ebn. <\/b>Bijvoorbeeld, je gebruikt A\/B-testen of canary-deployments om op verschillende manieren de code bij verschillende klanten te \u2018testen\u2019, informatie te verzamelen over hoe de code presteert en veel eerder te weten te komen dan wanneer het naar 100 miljoen gebruikers wordt uitgerold.<\/p>\n

\u2018Continu leveren\u2019 ziet er als volgt uit.<\/p>\n

\"Wat
\n<\/p>\n

Het leveringsproces Dev, CI, Test, PreProd, Prod - dit is geen apart omgeving, dit zijn fasen of stations met onverbrandbare sommen, waar jouw artefact doorheen gaat.<\/p><\/blockquote>\n

\nAls je infrastructuurcode hebt die is beschreven als Base Service APP, dan helpt deze om geen enkele scenario's te vergeten.<\/b>, en deze ook als code voor dit artefact vast te leggen, om het artefact voort te brengen<\/b> en het onderweg aan te passen.<\/p>\n

Vragen voor zelfevaluatie<\/h3>\n

\nIs de tijd van beschrijving van een functie tot uitrol in productie in 95% van de gevallen minder dan een week? Verbeterd de kwaliteit van het artefact bij elke stap in de pijplijn? Is er een verhaal dat het doorloopt? Maak je gebruik van verschillende deploymentstrategie\u00ebn?<\/p>\n

Als al je antwoorden ja zijn, dan ben je echt geweldig! Schrijf je antwoorden in de opmerkingen \u2013 ik kijk ernaar uit.)<\/p>\n

Feedback<\/h3>\n

\nDit is de moeilijkste praktijk van allemaal. Tijdens de DevOpsConf vertelde een collega van Infobip erover en hij had het er een beetje moeilijk mee, omdat het echt een zeer complexe praktijk is die inhoudt dat je vrijwel alles moet monitoren!<\/p>\n

\"Wat
\n
\nBijvoorbeeld, lang geleden, toen ik bij Qik werkte, realiseerden we ons dat we eigenlijk alles moesten monitoren. We hebben dat gedaan en in Zabbix hadden we 150.000 items die continu werden gemonitord. Dat was beangstigend, de technische directeur draaide met zijn vinger bij zijn slaap:<\/p>\n

\u2014 Jongens, waarom mishandelen jullie de server met iets onduidelijks?<\/i><\/p>\n

Maar toen gebeurde er iets dat bewees dat dit echt een geweldige strategie was.<\/p>\n

Een van de diensten begon voortdurend uit te vallen. Aanvankelijk viel hij niet uit, wat interessant is, er werd geen code toegevoegd, omdat dit een basis broker was met vrijwel geen bedrijfsfunctionaliteit - hij verwerkte eenvoudigweg berichten tussen verschillende diensten. De dienst was vier maanden lang onveranderd, en toen begon hij plotseling uit te vallen met de foutmelding 'Segmentation fault'.<\/p>\n

We waren in shock, openden onze grafieken in Zabbix en het bleek dat anderhalve week geleden het gedrag van de verzoeken in de API-service die deze broker gebruikt, aanzienlijk was veranderd. Vervolgens zagen we dat de frequentie van het verzenden van een bepaald type berichten was veranderd. Daarna ontdekte we dat dit android-klanten betreft. We vroegen:<\/p>\n

\u2014 Jongens, wat is er anderhalve week geleden bij jullie gebeurd?<\/i><\/p>\n

We hoorden een interessant verhaal over dat ze de UI hadden opnieuw ontworpen. Weinig mensen zouden meteen zeggen dat ze de HTTP-bibliotheek hebben veranderd. Voor android-klanten is dat net zoiets als het verwisselen van zeep in de badkamer - ze herinneren het zich gewoon niet. Uiteindelijk, na 40 minuten praten, ontdekten we dat ze inderdaad de HTTP-bibliotheek hebben gewijzigd, en dat de standaardtimings waren veranderd. Dit leidde ertoe dat het gedrag van het verkeer op de API-server veranderde, wat de situatie veroorzaakte die leidde tot een raceconditie binnen de broker, waardoor hij begon uit te vallen.<\/p>\n

Zonder diepgaande monitoring is het eigenlijk onmogelijk om dit te ontdekken.<\/b>. Als er echter binnen de organisatie nog een probleem is met \"putten\", waarbij iedereen naar elkaar wijst, kan dit jaren aanhouden. Je herstart de server gewoon omdat het probleem niet kan worden opgelost. Wanneer je alles monitort, bijhoudt, en al je gebeurtenissen volgt, en monitoring als testen gebruikt \u2014 je schrijft de code en geeft meteen aan hoe deze moet worden gemonitord, ook in de vorm van code (we hebben al infrastructuur als code), wordt alles duidelijk als een open boek. Zelfs zulke complexe problemen zijn gemakkelijk te volgen.<\/p>\n

\"Wat
\n<\/p>\n

Verzamel alle informatie over wat er gebeurt met het artefact in elke fase van het leveringsproces \u2014 niet in productie.<\/p><\/blockquote>\n

\nLaad monitoring naar CI, en daar zullen al enkele basiszaken zichtbaar zijn. Vervolgens zie je ze ook in Test, en in PredProd, en tijdens de belastingstest. Verzamelen van informatie in alle fasen, niet alleen metrics, statistieken, maar ook logs: hoe de applicatie werd uitgerold, anomalie\u00ebn \u2014 verzamel alles. <\/p>\n

Anders wordt het moeilijk om te begrijpen. Ik heb al gezegd dat DevOps een grotere complexiteit is. Om met deze complexiteit om te gaan, heb je goede analytics nodig.<\/b>.<\/p>\n

Vragen voor zelfreflectie<\/h3>\n

\nIs jouw monitoring en logging een ontwikkelingsmiddel voor jou?<\/b> Denken jouw ontwikkelaars, en jijzelf ook, na over hoe de code moet worden gemonitord wanneer ze deze schrijven?<\/p>\n

Kom je problemen te weten van klanten? Begrijp je de klant beter via monitoring en logging?<\/b> Begrijp je het systeem beter via monitoring en logging?<\/b> Verander je het systeem gewoon omdat je ziet dat de trend in het systeem stijgt en je begrijpt dat het over 3 weken allemaal zal instorten? <\/p>\n

Als je deze drie componenten hebt, kun je nadenken over wat voor infrastructuurplatform je bedrijf heeft.<\/p>\n

Infrastructuurplatform <\/h2>\n

\nHet gaat er niet om dat dit een verzameling van losstaande tools is die in elk bedrijf aanwezig zijn.<\/p>\n

De essentie van een infrastructuurplatform is dat alle teams deze tools gezamenlijk gebruiken en ontwikkelen.<\/p><\/blockquote>\n

\nHet is duidelijk dat er aparte teams zijn die verantwoordelijk zijn voor de ontwikkeling van afzonderlijke delen van het infrastructuurplatform. Maar de verantwoordelijkheid voor de ontwikkeling, werking en promotie van het infrastructuurplatform ligt bij elke engineer. Op intern niveau wordt dit een algemeen hulpmiddel.<\/b>. <\/p>\n

Alle teams ontwikkelen het infrastructuursysteem en behandelen het als hun eigen IDE.<\/b>. In uw IDE installeert u verschillende plugins om alles mooi en snel te maken en stelt u sneltoetsen in. Wanneer u Sublime, Atom of Visual Studio Code opent, worden u er fouten in de code weergegeven en begrijpt u dat het onmogelijk is om te werken, u voelt zich meteen verdrietig en rent om uw IDE te repareren.<\/p>\n

Behandel uw infrastructuursysteem op dezelfde manier. Als u merkt dat er iets mis is, laat dan een aanvraag achter als u het zelf niet kunt oplossen. Maar als het iets eenvoudigs is, corrigeer het dan zelf en dien een pull request in; de mensen bekijken het en voegen het toe. Dit is een iets andere benadering van de engineeringtools in het hoofd van de ontwikkelaar.<\/p>\n

Het infrastructuursysteem zorgt voor de overdracht van artefacten van ontwikkeling naar de klant met een constante kwaliteitsverbetering.<\/b>. In het IS zijn sets van verhalen geprogrammeerd die zich met de code in productie voordoen. Door de jarenlange ontwikkeling zijn er vele verhalen ontstaan, sommige zijn uniek en specifiek voor u en kunnen niet gegoogeld worden. <\/p>\n

Op dat moment wordt het infrastructuursysteem uw concurrentievoordeel.<\/b>, omdat daarin is ingebouwd wat er niet in het hulpmiddel van de concurrent is. Hoe dieper uw IS, hoe groter uw concurrentievoordeel in termen van time-to-market. Hier komt de vendor lock-probleem<\/b>: u kunt een extern platform gebruiken, maar door het gebruik van iemands ervaring begrijpt u niet hoe relevant deze voor u is. Ja, niet elke onderneming kan een platform zoals Amazon bouwen. Dit is een delicate grens waar de ervaring van een bedrijf relevant is voor zijn positie op de markt, en vendor lock hier niet toegestaan is. Het is belangrijk om hier ook over na te denken.<\/p>\n

Schema<\/h3>\n

\nDit is het basisschema van het infrastructuursysteem dat u helpt om alle praktijken en processen in een DevOps-bedrijf op te zetten.<\/p>\n

\"Wat
\n
\nLaten we bekijken waaruit het bestaat.<\/p>\n

Een systeem voor het orkestreren van bronnen<\/b>, dat CPU, geheugen en schijven aan applicaties en andere diensten levert. Daarbovenop zijn er laagniveau-diensten<\/b>: monitoring, logging, CI\/CD-engine, artefactopslag, infrastructuur als code systemen.<\/p>\n

Diensten op een hoger niveau.<\/b>: database as a service, queues as a service, Load Balance as a service, image resizing as a service, Big Data factory as a service. Above this \u2014 a pipeline that continuously delivers modified code to your client<\/b>.<\/p>\n

You receive information about how your software is performing for the client, make changes, deliver this code again, receive feedback \u2014 and this continuously develops both the infrastructure platform and your software.<\/p>\n

In the diagram, the delivery pipeline consists of multiple stages. But this is a fundamental diagram, provided for example \u2014 it should not be replicated exactly. The stages interact with services as services \u2014 each component of the platform carries its own story: how resources are allocated, how the application starts, interacts with resources, is monitored, and changes.<\/p>\n

It is important to understand that each part of the platform carries a story, and to ask yourself \u2014 what story does this component carry? Perhaps it should be discarded and replaced with a third-party service. For example, can we replace this component with Okmeter? Perhaps, they have developed this expertise much further than we have. But maybe not \u2014 perhaps we have unique expertise, and we need to implement Prometheus and develop it further.<\/p>\n

Creating a platform<\/h3>\n

\nThis is a complex communication process. When you have basic practices, you initiate communication between different engineers and specialists who develop requirements and standards, and constantly adapt them to various tools and approaches. Here, the culture present in DevOps is crucial.<\/p>\n

\"Wat
\nWith culture, everything is very simple \u2014 it\u2019s collaboration and communication<\/b>, meaning the willingness to work in the same field with each other, the desire to master one tool together. There is no rocket science here \u2014 everything is very straightforward, banal. For example, we all live in an apartment building and maintain its cleanliness \u2014 that level of culture.<\/p>\n

And what about you?<\/h3>\n

\nAgain, questions you can ask yourself.<\/p>\n

Is the infrastructure platform clearly defined? Who is responsible for its development? Do you understand the competitive advantages of your infrastructure platform?<\/p>\n

Deze vragen moet je jezelf constant stellen. Als je iets kunt uitbesteden aan externe diensten, dan moet je dat doen; als de externe dienst begint je voortgang te blokkeren, dan moet je een systeem intern opzetten.<\/p>\n

Dus, DevOps...<\/h2>\n

\n... is een complex systeem, dat moet bevatten:<\/p>\n