{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps og Kaos: Softwarelevering i en decentraliseret verden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Grundl\u00e6gger og direkt\u00f8r for \u00abOtomato Software\u00bb, en af initiativtagerne og instrukt\u00f8rerne til den f\u00f8rste DevOps-certificering i Israel, Anton Weiss, talte sidste \u00e5r DevOpsDays Moskva<\/a><\/noindex> om kaosteori og hovedprincipperne i kaosingeni\u00f8rkunst, samt forklarede, hvordan den ideelle DevOps-organisation i fremtiden ser ud.<\/p>\n

Vi har forberedt en tekstversion af pr\u00e6sentationen. <\/p>\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nGodmorgen! <\/p>\n

DevOpsDays i Moskva for andet \u00e5r i tr\u00e6k, jeg er for anden gang p\u00e5 denne scene, mange af jer er for anden gang i denne sal. Hvad betyder det? Det betyder, at DevOps-bev\u00e6gelsen i Rusland vokser, multipliceres, og vigtigst af alt, det betyder, at det er tid til at tale om, hvad DevOps egentlig er i 2018. <\/p>\n

H\u00e6v h\u00e5nden, hvis du mener, at DevOps i 2018 allerede er et erhverv? Der er nogle. Er der DevOps-ingeni\u00f8rer her, som har \u00abDevOps-ingeni\u00f8r\u00bb i deres jobbeskrivelse? Er der DevOps-managere til stede? Ingen. DevOps-arkitekter? Ogs\u00e5 ingen. Det er for lidt. S\u00e5 virkelig er der ingen, der har skrevet, at de er DevOps-ingeni\u00f8rer?<\/p>\n

S\u00e5 de fleste af jer mener, at det er et antipattern? At der ikke burde eksistere et s\u00e5dant erhverv? Vi kan t\u00e6nke, hvad vi vil, men mens vi t\u00e6nker, bev\u00e6ger industrien sig fremad under lyden af DevOps-nummeret.<\/p>\n

Hvem har h\u00f8rt om det nye emne, som hedder DevDevOps? Det er en ny metode, der sikrer effektivt samarbejde mellem udviklere og DevOps-teams. Og det er faktisk ikke s\u00e5 nyt. Hvis man d\u00f8mmer ud fra Twitter, s\u00e5 begyndte man allerede at tale om det for 4 \u00e5r siden. Og interessen vokser stadig, hvilket betyder, at der er et problem. Problemet skal l\u00f8ses.<\/p>\n

\"DevOps
\n
\nVi er kreative mennesker, vi giver os ikke s\u00e5 let. Vi siger: DevOps er ikke et tilstr\u00e6kkeligt d\u00e6kkende ord, der mangler mange interessante elementer. S\u00e5 vi g\u00e5r ind i vores hemmelige laboratorier og begynder at skabe nysgerrige mutationer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nLogikken er klar, ikke? Vi har et leveringssystem, der ikke fungerer, vores systemer er ustabile og brugerne er utilfredse, vi kan ikke f\u00e5 software ude til tiden, vi holder os ikke inden for budgettet. Hvordan l\u00f8ser vi alt dette? Vi finder p\u00e5 et nyt ord! Det vil slutte p\u00e5 \u00abOps\u00bb, og s\u00e5 er problemet l\u00f8st.<\/p>\n

S\u00e5dan kalder jeg denne tilgang \u2014 \u00abOps, og problemet er l\u00f8st\u00bb.<\/p>\n

Alt dette bliver sekund\u00e6rt, hvis vi minder os selv om, hvorfor vi overhovedet fandt p\u00e5 det hele. Vi fandt p\u00e5 hele dette DevOps for at g\u00f8re leveringen af software og vores eget arbejde i denne proces s\u00e5 gnidningsl\u00f8st, smertefrit, effektivt og vigtigst af alt, behageligt som muligt. <\/p>\n

DevOps voksede ud af smerte. Og vi er tr\u00e6tte af at lide. For at f\u00e5 det til at ske, bygger vi p\u00e5 tidl\u00f8se praksisser: effektivt samarbejde, flow-praksisser og vigtigst af alt, systemisk t\u00e6nkning, fordi uden det fungerer ingen DevOps.<\/p>\n

Hvad er et system?<\/b><\/h3>\n

\nOg n\u00e5r vi nu taler om systemisk t\u00e6nkning, lad os minde os selv om, hvad et system er.<\/p>\n

\"DevOps
\n
\nHvis du er en revolutionerende hacker, er systemet entydigt det onde. Det er en skygge, der h\u00e6nger over dig og tvinger dig til at g\u00f8re ting, du ikke \u00f8nsker at g\u00f8re. <\/p>\n

\"DevOps
\n
\nSet fra systemisk t\u00e6nkning er et system en helhed best\u00e5ende af dele. I denne forstand er hver enkelt af os et system. De organisationer, vi arbejder i, er systemer. Og det, vi bygger sammen, kaldes netop et system.<\/p>\n

Alt dette er en del af et stort socioteknologisk system. Og f\u00f8rst n\u00e5r vi forst\u00e5r, hvordan dette socioteknologiske system arbejder sammen, kan vi virkelig optimere noget i denne henseende. <\/p>\n

Set fra systemisk t\u00e6nkning har systemet forskellige interessante egenskaber. For det f\u00f8rste best\u00e5r det af dele, hvilket betyder, at dets adf\u00e6rd afh\u00e6nger af adf\u00e6rden hos delene. Samtidig er alle delene gensidigt afh\u00e6ngige. Det viser sig, at jo flere dele et system har, desto sv\u00e6rere er det at forst\u00e5 eller forudsige dets adf\u00e6rd. <\/p>\n

Set fra adf\u00e6rdens synspunkt er der endnu en interessant kendsgerning. Et system kan g\u00f8re noget, som ingen af dets enkelte dele kan g\u00f8re. <\/p>\n

Som Dr. Russell Ackoff (en af grundl\u00e6ggerne af systemisk t\u00e6nkning) sagde, er det relativt let at bevise ved hj\u00e6lp af et tankeeksperiment. For eksempel, hvem i rummet kan skrive kode? Mange h\u00e6nder, og det er normalt, fordi det er et af de grundl\u00e6ggende krav til vores profession. Du kan skrive, men kan dine h\u00e6nder adskilt fra dig selv skrive kode? Der er folk, der vil sige: \u00abDet er ikke mine h\u00e6nder, der skriver kode, det er min hjerne, der skriver kode\u00bb. Og kan hjernen adskilt fra dig selv skrive kode? Sandsynligvis ikke. <\/p>\n

Hjernen er en fantastisk maskine, og vi ved ikke engang 10% om, hvordan den fungerer, men den kan ikke fungere isoleret fra det system, som vores krop er. Det er let at bevise: \u00e5bn din kraniumkasse, tag hjernen ud og l\u00e6g den foran en computer og lad den pr\u00f8ve at skrive noget simpelt. \"Hello, world\" i Python, for eksempel.<\/p>\n

Hvis systemet kan udf\u00f8re noget, som ingen af dets dele hver for sig kan, s\u00e5 betyder det, at dets adf\u00e6rd ikke fastl\u00e6gges af adf\u00e6rden i dets dele. Hvad fastl\u00e6gger det s\u00e5? Det fastl\u00e6gges af interaktionerne mellem disse dele. Jo flere dele der er, desto mere komplekse er interaktionerne, og desto sv\u00e6rere er det at forst\u00e5 og forudsige systemets adf\u00e6rd. Dette g\u00f8r et s\u00e5dant system kaotisk, fordi selv den mindste, usynlige \u00e6ndring i en af systemets dele kan f\u00f8re til helt uforudsigelige resultater. <\/p>\n

Denne f\u00f8lsomhed over for de indledende betingelser blev f\u00f8rste gang opdaget og unders\u00f8gt af den amerikanske meteorolog Ed Lorenz. Senere blev den kendt som \"sommerfugleeffekten\" og f\u00f8rte til udviklingen af en videnskabelig bev\u00e6gelse kaldet \"kaosteori\". Denne teori blev en af de grundl\u00e6ggende paradigmeskift i 20. \u00e5rhundrede.<\/p>\n

Kaosteori<\/b><\/h3>\n

\nMennesker, der studerer kaos, kalder sig selv kaosologer.<\/p>\n

\"DevOps
\n
\n\u00c5rsagen til denne pr\u00e6sentation er, at jeg, i mit arbejde med komplekse distribuerede systemer og store internationale organisationer, p\u00e5 et tidspunkt inds\u00e5, at dette er, hvem jeg f\u00f8ler mig som. Jeg er kaosolog. Det er s\u00e5dan en snedig m\u00e5de at sige: \"Jeg forst\u00e5r ikke, hvad der sker her, og jeg ved ikke, hvad jeg skal g\u00f8re ved det.\" <\/p>\n

Jeg tror, mange af jer ogs\u00e5 ofte f\u00f8ler s\u00e5dan, s\u00e5 I er ogs\u00e5 kaosologer. Jeg inviterer jer til kaosologernes gildet. De systemer, som vi, k\u00e6re kollegaer kaosologer, vil studere, kaldes \"komplekse adaptive systemer\". <\/p>\n

Hvad er tilpasningsevne? Tilpasningsevne betyder, at den individuelle og kollektive adf\u00e6rd af dele i et s\u00e5dant tilpasset system \u00e6ndrer sig og selvorganiserer sig som reaktion p\u00e5 h\u00e6ndelser eller k\u00e6der af mikro-h\u00e6ndelser i systemet. Med andre ord tilpasser systemet sig \u00e6ndringer gennem selvorganisering. Og denne evne til selvorganisering er baseret p\u00e5 frivilligt, helt decentraliseret samarbejde mellem frie autonome agenter.<\/p>\n

En anden interessant egenskab ved s\u00e5danne systemer er, at de er frit skalerbare. Dette burde uden tvivl interessere os som kaosm\u00e6nd og -ingeni\u00f8rer. S\u00e5 hvis vi har sagt, at opf\u00f8relsen af et komplekst system bestemmes af samspillet mellem dets dele, hvad b\u00f8r vi s\u00e5 v\u00e6re interesserede i? Samspillet. <\/p>\n

Der er to interessante konklusioner.
\n \"DevOps
\n
\nFor det f\u00f8rste forst\u00e5r vi, at et komplekst system ikke kan forenkles ved at forenkle dets dele. For det andet er den eneste m\u00e5de at forenkle et komplekst system p\u00e5 ved at forenkle interaktionerne mellem dets dele. <\/p>\n

Hvordan interagerer vi? Vi er alle dele af et stort informationssystem, der kaldes det menneskelige samfund. Vi interagerer gennem et f\u00e6lles sprog, hvis vi har det, hvis vi finder det.<\/p>\n

\"DevOps
\n
\nMen sproget i sig selv er et komplekst adaptivt system. Derfor, for at interagere mere effektivt og enkelt, er vi n\u00f8dt til at skabe nogle protokoller. Det vil sige en sekvens af symboler og handlinger, der g\u00f8r informationsudvekslingen mellem os enklere, mere forudsigelig, mere forst\u00e5elig.<\/p>\n

Jeg vil sige, at tendenserne til kompleksitet, tilpasningsevne, decentralisering og kaos kan spores overalt. B\u00e5de i de systemer, vi bygger, og i de systemer, vi er en del af.<\/p>\n

Og for ikke at v\u00e6re substansl\u00f8s, lad os se p\u00e5, hvordan de systemer, vi skaber, \u00e6ndrer sig.<\/p>\n

\"DevOps
\n
\nJeg ved, at du har ventet p\u00e5 dette ord. Vi er til DevOps-konferencen, i dag vil dette ord blive n\u00e6vnt et sted omkring hundrede tusinde gange og derefter komme til at hjems\u00f8ge os om natten.<\/p>\n

Mikrotjenester er den f\u00f8rste softwarearkitektur, der opstod som reaktion p\u00e5 DevOps-praksis, og den er designet til at g\u00f8re vores systemer mere fleksible, mere skalerbare og muligg\u00f8re kontinuerlig levering. Hvordan g\u00f8r den det? Ved at reducere omfanget af tjenester, begr\u00e6nse gr\u00e6nserne for de problemer, som disse tjenester h\u00e5ndterer, og forkorte leveringstiden. Det vil sige, at vi mindsker og forenkler dele af systemet, \u00f8ger deres antal, og dermed \u00f8ges kompleksiteten af interaktionerne mellem disse dele, hvilket skaber nye problemer, som vi skal l\u00f8se.<\/p>\n

\"DevOps
\n
\nMikrotjenester er ikke enden; mikrotjenester er faktisk i g\u00e5rsdagens dag, fordi Serverless er p\u00e5 vej. Alle servere er br\u00e6ndt, der er ingen servere, ingen operativsystemer, kun ren eksekverbar kode. Konfigurationer er adskilt, tilstande er adskilte, alt styres af begivenheder. Sk\u00f8nhed, renhed, stilhed, ingen begivenheder, intet sker, fuldst\u00e6ndig orden. <\/p>\n

Hvor er kompleksiteten? Komplexiteten ligger \u00e5benlyst i interaktionerne. Hvor meget kan en funktion g\u00f8re alene? Hvordan interagerer den med andre funktioner? Meddelelsesk\u00f8er, databaser, belastningsfordelere. Hvordan genskaber man en begivenhed, n\u00e5r der opst\u00e5r en fejl? Mange sp\u00f8rgsm\u00e5l og f\u00e5 svar.<\/p>\n

Mikrotjenester og Serverless er alt det, som vi, computerhipstere, kalder Cloud Native. Det handler alt sammen om skyen. Men skyen er i sin kerne ogs\u00e5 begr\u00e6nset n\u00e5r det kommer til skalerbarhed. Vi er vant til at t\u00e6nke p\u00e5 den som et distribueret system. Men hvor bor serverne fra cloududbydere? I datacentre. Det vil sige, at vi her har en form for centraliseret, meget begr\u00e6nset, distribueret model.<\/p>\n

I dag forst\u00e5r vi, at Internet of Things ikke kun er h\u00f8je ord; if\u00f8lge beskedne forudsigelser vil vi i de n\u00e6ste fem til ti \u00e5r se milliarder af enheder, der er tilsluttet internettet. En enorm m\u00e6ngde nyttige og unyttige data, der vil str\u00f8mme ind i skyen og blive sendt ud fra skyen. <\/p>\n

Skyen vil ikke kunne klare det, derfor taler vi i stigende grad om det, der kaldes \"edge computing\". Eller som jeg ogs\u00e5 kan lide den vidunderlige definition \"fog computing\". Det har en mystisk romantik og mystik over sig.<\/p>\n

\"DevOps
\n
\nT\u00e5gecomputing. Det handler om, at skyer er centraliserede samlinger af vand, damp, is og sten. T\u00e5ge er derimod vanddr\u00e5ber, der er spredt omkring os i atmosf\u00e6ren. <\/p>\n

I den t\u00e5gede paradigm udf\u00f8res st\u00f8rstedelen af arbejdet af disse dr\u00e5ber ganske autonomt eller i samarbejde med andre dr\u00e5ber. De henvender sig kun til skyen, n\u00e5r det virkelig br\u00e6nder p\u00e5. <\/p>\n

Det vil sige, at vi igen taler om decentralisering, autonomi, og mange af jer forst\u00e5r sikkert allerede, hvor dette f\u00f8rer hen, for man kan ikke tale om decentralisering uden at n\u00e6vne blockchain. <\/p>\n

\"DevOps
\n
\nDer er dem, der tror p\u00e5 det; det er dem, der har investeret i kryptovaluta. Der er dem, der tror, men som er bange, som for eksempel mig. Og s\u00e5 er der dem, der ikke tror. Man kan forholde sig forskelligt til det. Der er teknologi, en ny og uklar ting, der er problemer. Som enhver ny teknologi rejser den flere sp\u00f8rgsm\u00e5l, end den giver svar. <\/p>\n

Hype omkring blockchain er forst\u00e5elig. Selvom man ser bort fra guldfeberen, s\u00e5 giver teknologien i sig selv fantastiske l\u00f8fter om en lys fremtid: mere frihed, mere autonomi, globalt distribueret tillid. Hvad er der ikke at \u00f8nske? <\/p>\n

Derfor begynder flere og flere ingeni\u00f8rer verden over at udvikle decentrale applikationer. Og det er en kraft, der ikke kan ignoreres blot ved at sige: \"Aaa, blockchain er bare en d\u00e5rligt implementeret distribueret database.\" Eller som skeptikere elsker at sige: \"Der er ingen reelle anvendelser for blockchain.\" Hvis man t\u00e6nker over det, s\u00e5 sagde de samme ting for 150 \u00e5r siden om elektricitet. Og de havde endda delvist ret, for det, elektricitet muligg\u00f8r i dag, var slet ikke muligt i det 19. \u00e5rhundrede.<\/p>\n

Forresten, hvem ved, hvilket logo der er p\u00e5 sk\u00e6rmen? Det er Hyperledger. Det er et projekt, der udvikles under The Linux Foundations' vinger, og det omfatter et s\u00e6t blockchain-teknologier. Det er virkelig kraften i vores open source-community.<\/p>\n

Kaosingeni\u00f8rarbejde<\/b><\/h3>\n

\n\"DevOps
\n
\nS\u00e5 systemet, som vi udvikler, bliver mere og mere komplekst, mere chaotisk og mere adaptivt. Netflix er pionerer inden for mikrotjenestearkitektur. De var en af de f\u00f8rste, der forstod dette, og de udviklede et s\u00e6t v\u00e6rkt\u00f8jer, som de kaldte Simian Army, hvoraf den mest kendte er Chaos Monkey<\/a><\/noindex>. Den definerede det, der blev kendt som \u00abprincipper for kaosingeni\u00f8rkunst\u00bb<\/a><\/noindex>.<\/p>\n

Forresten, mens vi arbejdede p\u00e5 pr\u00e6sentationen, oversatte vi endda denne tekst til russisk, s\u00e5 kig forbi linket<\/a><\/noindex>, l\u00e6s, kommenter, kritiser.<\/p>\n

Kort sagt beskriver principperne for kaosingeni\u00f8rkunst f\u00f8lgende. Komplekse distribuerede systemer er i sin natur uforudsigelige, og de indeholder i sin essens fejl. Fejl er uundg\u00e5elige, og det betyder, at vi skal acceptere disse fejl og arbejde med disse systemer helt anderledes. <\/p>\n

Vi skal fors\u00f8ge at introducere disse fejl i vores produktionssystemer for at teste vores systemers tilpasningsevne, deres evne til selvorganisering og overlevelse. <\/p>\n

Og det \u00e6ndrer alt. Ikke kun hvordan vi bringer systemet i produktion, men ogs\u00e5 hvordan vi udvikler dem, hvordan vi tester dem. Der er ingen stabiliseringsproces, ingen frysing af koden, tv\u00e6rtimod er der en konstant proces med destabilisering. Vi fors\u00f8ger at dr\u00e6be systemet og se, at det forts\u00e6tter med at overleve.<\/p>\n

Distributed System Integration Protocols<\/b><\/h3>\n

\n\"DevOps
\n
\nDette kr\u00e6ver, at vores systemer ogs\u00e5 \u00e6ndrer sig p\u00e5 en eller anden m\u00e5de. For at de kan blive mere robuste, har de brug for nye interaktionsprotokoller mellem deres dele. S\u00e5 disse dele kan indg\u00e5 aftaler og n\u00e5 til en eller anden form for selvorganisering. Der opst\u00e5r alle mulige nye v\u00e6rkt\u00f8jer, nye protokoller, som jeg kalder \"protokoller for interaktion mellem distribuerede systemer\".<\/p>\n

\"DevOps
\n
\nHvad taler jeg om? For det f\u00f8rste projektet Opentracing<\/a><\/noindex>. Et fors\u00f8g p\u00e5 at skabe en f\u00e6lles protokol for distribueret sporing, som er et uundg\u00e5eligt redskab til fejlfinding af komplekse distribuerede systemer.<\/p>\n

\"DevOps
\n
\nNext is Open Policy Agent<\/a><\/noindex>. Vi siger, at vi ikke kan forudsige, hvad der vil ske med systemet, s\u00e5 vi skal \u00f8ge dets observabilitet. Opentracing tilh\u00f8rer en familie af v\u00e6rkt\u00f8jer, der giver observabilitet til vores systemer. Men vi har brug for observabilitet for at bestemme, om systemet opf\u00f8rer sig som forventet eller ej. Hvordan kan vi bestemme det forventede adf\u00e6rd? Ved at definere en slags politik, et s\u00e6t regler i det. Projektet Open Policy Agent besk\u00e6ftiger sig med at definere dette regels\u00e6t over et bredt spektrum: fra adgang til placering af ressourcer.<\/p>\n

\"DevOps
\n
\nSom vi sagde, bliver vores systemer mere og mere h\u00e6ndelsesorienterede. Serverless er et fremragende eksempel p\u00e5 h\u00e6ndelsesorienterede systemer. For at vi kan overf\u00f8re h\u00e6ndelser mellem systemer og spore dem, har vi brug for et f\u00e6lles sprog, en f\u00e6lles protokol for, hvordan vi taler om h\u00e6ndelser, og hvordan vi overbringer dem til hinanden. Det tager et projekt med navnet Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nDen kontinuerlige str\u00f8m af \u00e6ndringer, der vasker over vores systemer og konstant destabiliserer dem, er en kontinuerlig str\u00f8m af softwareartefakter. For at vi kan opretholde denne konstante str\u00f8m af \u00e6ndringer, har vi brug for en f\u00e6lles protokol, som vi kan bruge til at tale om, hvad en softwareartefakt er, hvordan den er blevet verificeret, og hvilken verifikation den har gennemg\u00e5et. Det tager et projekt med navnet Grafeas<\/a><\/noindex>. Alts\u00e5, en f\u00e6lles protokol for metadata om softwareartefakter.<\/p>\n

\"DevOps
\n
\nOg endelig, hvis vi \u00f8nsker, at vores systemer skal v\u00e6re helt selvst\u00e6ndige, adaptive og selvorganiserende, skal vi give dem ret til selvidentifikation. Projektet med navnet spiffe<\/a><\/noindex> er netop det, det besk\u00e6ftiger sig med. Det er ogs\u00e5 et projekt under Cloud Native Computing Foundation.<\/p>\n

Alle disse projekter er unge, de har alle brug for vores k\u00e6rlighed, vores test. Det er alt sammen open source, vores testning, vores implementering. De viser os, hvilken retning teknologien bev\u00e6ger sig i. <\/p>\n

Men DevOps har aldrig prim\u00e6rt handlet om teknologi, det har altid v\u00e6ret om samarbejde mellem mennesker. Og derfor, hvis vi \u00f8nsker, at de systemer, vi udvikler, skal \u00e6ndre sig, s\u00e5 m\u00e5 vi \u00e6ndre os selv. Faktisk \u00e6ndrer vi os allerede, vi har ikke rigtig noget valg. <\/p>\n

\"DevOps
\n
\nDer er en fantastisk bog<\/a><\/noindex> britisk forfatter ved navn Rachel Botsman, som skriver om tillidens evolution gennem menneskehedens historie. Hun siger, at tillid oprindeligt i primitive samfund var lokal, alts\u00e5 vi stolede kun p\u00e5 dem, vi kendte personligt. <\/p>\n

Derefter kom der en meget lang periode \u2014 en m\u00f8rk tid, hvor tillid blev centraliseret, hvor vi begyndte at stole p\u00e5 mennesker, vi ikke kender, baseret p\u00e5 det faktum, at vi tilh\u00f8rer samme sociale eller statslige institution.<\/p>\n

Og her er, hvad vi ser i vores moderne verden: tillid bliver mere og mere distribueret og decentraliseret, og den er baseret p\u00e5 friheden af informationsstr\u00f8mme og tilg\u00e6ngeligheden af information. <\/p>\n

Hvis man t\u00e6nker over det, s\u00e5 er det netop denne tilg\u00e6ngelighed, som muligg\u00f8r denne tillid, som vi skaber sammen. Det betyder, at m\u00e5den, vi samarbejder p\u00e5, og m\u00e5den, vi g\u00f8r det p\u00e5, skal \u00e6ndres, fordi centraliserede, hierarkiske IT-organisationer fra den gamle skole holder op med at fungere. De begynder at udd\u00f8. <\/p>\n

Grundlaget for DevOps-organisationer<\/b><\/h3>\n

\nDen ideelle DevOps-organisation i fremtiden er et decentraliseret, adaptivt system best\u00e5ende af autonome teams, hvor hvert team best\u00e5r af autonome individer. Disse teams er spredt over hele verden og samarbejder effektivt gennem asynkron kommunikation og meget transparente informationsudvekslingsprotokoller. Meget smukt, ikke? En meget smuk fremtid.<\/p>\n

Selvf\u00f8lgelig er alt dette umuligt uden kulturelle \u00e6ndringer. Vi skal have transformationelt lederskab, personlig ansvarlighed, indre motivation.<\/p>\n

\"DevOps
\n
\nDette er fundamentet for DevOps-organisationer: informationsgennemsigtighed, asynkrone kommunikationer, transformationelt lederskab, decentralisering. <\/p>\n

Udbr\u00e6ndthed<\/b><\/h3>\n

\nDe systemer, som vi er en del af, og dem, vi bygger, bliver mere og mere kaotiske, og det er sv\u00e6rt for os mennesker at finde fred med denne tanke, sv\u00e6rt at give slip p\u00e5 illusionen om kontrol. Vi fors\u00f8ger at forts\u00e6tte med at kontrollere dem, og det f\u00f8rer ofte til udbr\u00e6ndthed. Jeg siger dette ud fra egen erfaring, jeg har ogs\u00e5 lidt, ogs\u00e5 blevet rammet af uventede nedbrud i produktionen.<\/p>\n

\"DevOps
\n
\nUdbr\u00e6ndthed sker, n\u00e5r vi fors\u00f8ger at kontrollere det, der i sin natur ikke kan kontrolleres. N\u00e5r vi bliver udbr\u00e6ndte, mister alt mening, fordi vi mister lysten til at lave noget nyt, vi g\u00e5r i en forsvarsposition og begynder at beskytte det, vi har. <\/p>\n

Ingeni\u00f8ryrket, som jeg ofte elsker at minde mig selv om, er i f\u00f8rste r\u00e6kke et kreativt erhverv. Hvis vi mister lysten til at skabe noget, s\u00e5 bliver vi til aske, bliver til sod. Folk br\u00e6nder ud, hele organisationer br\u00e6nder ud.<\/p>\n

Efter min mening er det kun ved at acceptere den skabende kraft af kaos, kun ved at opbygge samarbejde p\u00e5 dets principper, at vi kan undg\u00e5 at miste det gode, vi har i vores profession. <\/p>\n

Det \u00f8nsker jeg for jer: at elske jeres arbejde, at elske det, vi laver. Denne verden lever af information, og vi har f\u00e5et \u00e6ren af at n\u00e6re den. S\u00e5 lad os studere kaos, blive kaosologer, bringe v\u00e6rdi, skabe noget nyt, og n\u00e5r problemerne dukker op, som vi allerede har fundet ud af, er uundg\u00e5elige, s\u00e5 siger vi bare \"Ops!\", og problemet er l\u00f8st. <\/p>\n

Hvad med Chaos Monkey?<\/b><\/p>\n

I virkeligheden er alle disse v\u00e6rkt\u00f8jer meget unge. Netflix udviklede ogs\u00e5 v\u00e6rkt\u00f8jer til deres egne behov. Byg v\u00e6rkt\u00f8jer til dig selv. L\u00e6s principperne for kaosingeni\u00f8rarbejde og f\u00f8lg disse principper, i stedet for at lede efter andre v\u00e6rkt\u00f8jer, som nogen andre allerede har bygget. <\/p>\n

Pr\u00f8v at forst\u00e5, hvordan dine systemer g\u00e5r i stykker, og begynd at \u00f8del\u00e6gge dem og se, hvordan de klarer slagene. Det er det, der kommer f\u00f8rst. V\u00e6rkt\u00f8jer kan du finde. Der er mange projekter. <\/p>\n

Jeg forstod ikke helt det punkt, du n\u00e6vnte, hvor du sagde, at systemet ikke kan forsimples ved at forsimple dets komponenter, og s\u00e5 gik du straks videre til mikrotjenester, som netop simplificerer systemet ved at forsimple selve komponenterne og g\u00f8re interaktionerne mere komplekse. Det er i virkeligheden to dele, der modsiger hinanden. <\/b><\/p>\n

Helt korrekt, mikrotjenester er en meget modstridende emne overhovedet. I virkeligheden \u00f8ger simplificeringen af dele fleksibiliteten. Hvad giver mikrotjenester os? De giver os fleksibilitet og hastighed, men de giver os bestemt ikke enkelhed. De \u00f8ger kompleksiteten.<\/p>\n

S\u00e5 i DevOps-filosofien er mikrotjenester ikke s\u00e5 stor en velsignelse?<\/b><\/p>\n

Enhver velsignelse har en bagside. Der er en velsignelse: det \u00f8ger fleksibiliteten, giver os mulighed for at foretage \u00e6ndringer hurtigere, men det \u00f8ger kompleksiteten og dermed skr\u00f8beligheden af hele systemet. <\/p>\n

Ligger der stadig mere fokus p\u00e5 at forenkle interaktioner eller p\u00e5 at forenkle dele?<\/b> <\/p>\n

Fokus kommer uden tvivl p\u00e5 at forenkle interaktionen, for hvis vi ser p\u00e5 det ud fra, hvordan vi arbejder sammen, s\u00e5 skal vi f\u00f8rst og fremmest fokusere p\u00e5 at forenkle interaktionerne og ikke p\u00e5 at forenkle arbejdet for hver enkelt af os. For at forenkle arbejdet er at g\u00f8re os til robotter. Det fungerer fint i McDonald's, n\u00e5r du har f\u00e5et at vide: her skal du l\u00e6gge burgeren, her skal du h\u00e6lde saucen p\u00e5. Men det fungerer slet ikke i vores kreative arbejde.<\/p>\n

Er det sandt, at alt, hvad du har fortalt, lever i en verden uden konkurrence, og at kaosset der er s\u00e5 venligt, og der ikke er mods\u00e6tninger i dette kaos, ingen \u00f8nsker at spise eller dr\u00e6be hinanden? Hvordan skal konkurrence og DevOps eksistere?<\/b><\/p>\n

Det afh\u00e6nger af, hvilken type konkurrence vi taler om. Konkurrence p\u00e5 arbejdspladsen eller konkurrence mellem virksomheder? <\/p>\n

Konkurrence mellem de tjenester, der eksisterer, fordi tjenester ikke blot er flere virksomheder. Vi skaber en ny type informationsmilj\u00f8, og intet milj\u00f8 kan eksistere uden konkurrence. Der er konkurrence overalt.<\/b><\/p>\n

Tag for eksempel Netflix som en rollemodel. Hvorfor kom de op med dette? Fordi de var n\u00f8dt til at v\u00e6re konkurrencedygtige. Denne fleksibilitet og hastighed er netop det konkurrencem\u00e6ssige krav; det tilf\u00f8jer kaotiske elementer til vores systemer. S\u00e5 kaos er ikke noget, vi bevidst skaber, fordi vi \u00f8nsker det; det er noget, der opst\u00e5r, fordi verden kr\u00e6ver det. Vi m\u00e5 simpelthen tilpasse os. Og kaos er netop resultatet af konkurrencen.<\/p>\n

Betyder det, at kaos er en mangel p\u00e5 m\u00e5l, som det ser ud? Eller m\u00e5ske de m\u00e5l, vi ikke \u00f8nsker at se? Vi befinder os i vores eget hus og forst\u00e5r ikke andres m\u00e5l. Konkurrence opst\u00e5r faktisk, fordi vi har klare m\u00e5l og ved, hvor vi er p\u00e5 vej hen til hvert enkelt tidspunkt. Dette er, efter min mening, essensen af DevOps.<\/b><\/p>\n

Det er ogs\u00e5 en synsvinkel. Jeg mener, at vi alle har det samme m\u00e5l: at overleve og g\u00f8re det med
\nst\u00f8rst muligt forn\u00f8jelse. Den konkurrencem\u00e6ssige m\u00e5l for enhver organisation er den samme. Overlevelse foreg\u00e5r ofte i en konkurrence, og der er ikke meget, vi kan g\u00f8re ved det.<\/p>\n

I \u00e5r finder konferencen DevOpsDays Moskva<\/a><\/noindex> sted den 7. december i \"Teknopolis\". Vi modtager ans\u00f8gninger til foredrag indtil den 11. november. Skriv til<\/a><\/noindex> os, hvis du \u00f8nsker at deltage som taler.<\/p>\n

Registreringen for deltagere er \u00e5ben, billetten koster 7000 rubler. Kom og v\u00e6r med! \n<\/p><\/blockquote>\n

Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps og Kaos: Softwarelevering i en decentraliseret verden | ProHoster","description":"Grundl\u00e6gger og direkt\u00f8r for \u00abOtomato Software\u00bb, en af initiativtagerne og instrukt\u00f8rerne til den f\u00f8rste DevOps-certificering i Israel, Anton Weiss, talte sidste \u00e5r","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/39219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}