{"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\/da\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Hvad er DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Definitionen af DevOps er meget komplekse, s\u00e5 man b\u00f8r starte diskussionen om det fra bunden hver gang. Bare p\u00e5 Habr er der tusindvis af publikationer om emnet. Men hvis du l\u00e6ser dette, ved du sikkert, hvad DevOps er. For jeg g\u00f8r ikke. Hej, jeg hedder Alexander Titov (@osminog<\/a><\/noindex><\/b>), og vi skal bare tale om DevOps, og jeg vil dele mine erfaringer.<\/p>\n

\"Hvad
\n
\nJeg har t\u00e6nkt meget over, hvordan jeg kan g\u00f8re min fort\u00e6lling nyttig, s\u00e5 der vil v\u00e6re mange sp\u00f8rgsm\u00e5l her - dem, jeg stiller mig selv, og dem, jeg stiller vores kunders virksomhed. Ved at besvare disse sp\u00f8rgsm\u00e5l bliver forst\u00e5elsen bedre. Jeg vil fort\u00e6lle, hvorfor DevOps er n\u00f8dvendigt fra mit synspunkt, hvad det er, igen fra min position, og hvordan man kan forst\u00e5, at man bev\u00e6ger sig mod DevOps, ogs\u00e5 fra min synsvinkel. Det sidste punkt vil komme gennem sp\u00f8rgsm\u00e5l. Ved at besvare dem for dig selv, kan du forst\u00e5, om din virksomhed bev\u00e6ger sig mod DevOps, eller om der er problemer.
\n<\/a><\/noindex>
\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\nEn tid arbejdede jeg p\u00e5 b\u00f8lgerne af fusioner og opk\u00f8b. F\u00f8rst arbejdede jeg i den lille startup Qik, som blev k\u00f8bt af det lidt st\u00f8rre firma Skype, som derefter blev opk\u00f8bt af det endnu st\u00f8rre firma Microsoft. P\u00e5 det tidspunkt fik jeg et indblik i, hvordan opfattelsen af DevOps forvandler sig i forskellige virksomhedsst\u00f8rrelser. Derefter blev jeg interesseret i at se p\u00e5 DevOps fra et markedsm\u00e6ssigt synspunkt, og vi organiserede sammen med kolleger virksomheden Ekspress 42. I seks \u00e5r har vi navigeret igennem markedsb\u00f8lgerne.<\/p>\n

Udover det er jeg en af arrang\u00f8rerne af DevOps Moscow-f\u00e6llesskabet og arrang\u00f8r af DevOps Days 2017, men jeg organiserede ikke 2018. Ekspress 42 arbejder med mange virksomheder. Vi udvikler DevOps der, ser p\u00e5, hvordan det sker, drager konklusioner, analyserer og fort\u00e6ller vores konklusioner til alle, underviser folk i DevOps-praksis. Generelt fremmer vi erfaring og ekspertise i denne henseende.<\/p>\n

Hvorfor DevOps<\/h2>\n

\nDet f\u00f8rste sp\u00f8rgsm\u00e5l, som alle altid stiller - hvorfor? Mange mener, at DevOps blot er automatisering eller noget lignende, der allerede har v\u00e6ret i hver virksomhed.<\/p>\n

- Vi havde Continuous Integration - det betyder, at der allerede var DevOps, og hvorfor er alt det her n\u00f8dvendigt? De derude underholder sig selv, mens de forstyrrer os i vores arbejde!<\/i><\/p>\n

Efter 9 \u00e5rs udvikling af f\u00e6llesskabet og metodologien er det allerede blevet klart, at det ikke kun er marketingglitter, men det er stadig ikke helt klart, hvad form\u00e5let egentlig er. Ligesom med ethvert v\u00e6rkt\u00f8j og proces har DevOps specifikke m\u00e5l, som det i sidste ende opn\u00e5r.<\/p>\n

Alt dette h\u00e6nger sammen med, at verden forandrer sig. Den bev\u00e6ger sig v\u00e6k fra en enterprise-tilgang, hvor virksomheder str\u00e6ber direkte efter dr\u00f8mmen, som vores storsl\u00e5ede klassiker fra Sankt Petersborg synger, fra punkt A til punkt B efter en bestemt strategi, med en struktur der er bygget til dette. <\/p>\n

\"Hvad
\n<\/p>\n

I princippet skal alting inden for IT bygges op omkring denne tilgang. Her bruges IT udelukkende til at automatisere processer.<\/p><\/blockquote>\n

\nAutomatisering \u00e6ndrer sig sj\u00e6ldent, fordi n\u00e5r en virksomhed k\u00f8rer p\u00e5 skinnerne - hvad skal der \u00e6ndres? Det virker - r\u00f8r ikke ved det. Nu \u00e6ndrer tilgange i verden sig, og den, der kaldes Agile, siger, at den endelige punkt B ikke kan ses med det samme.<\/p>\n

\"Hvad
\n
\nN\u00e5r en virksomhed bev\u00e6ger sig p\u00e5 markedet og arbejder med kunderne - unders\u00f8ger den konstant markedet og justerer sit slutpunkt B. Jo oftere virksomheden \u00e6ndrer sin retning, jo mere succesfuld bliver den til sidst, fordi den v\u00e6lger flere markedsseneste.<\/p>\n

Strategien demonstreres af en interessant virksomhed, som jeg for nylig blev opm\u00e6rksom p\u00e5. One Box Shave - en service til levering af barberblade og tilbeh\u00f8r via abonnement i en boks. De kan tilpasse deres 'boks' til forskellige kunder. Dette h\u00e5ndteres af bestemt software, der derefter sender ordren til en koreansk fabrik, der producerer varerne.<\/p>\n

Dette produkt blev k\u00f8bt af Unilever for 1 milliard dollars. Nu konkurrerer det med Gillette og har taget en betydelig del af markedet i USA. One Box Shave siger:<\/p>\n

\u2014 4 blade? Er du seri\u00f8s? Hvad skal du bruge det til - det forbedrer overhovedet ikke kvaliteten af barberingen. En specielt udvalgt creme, duft og en kvalitetsbarbermaskine med to blade l\u00f8ser langt flere problemer end disse dumme 4 blade fra Gillette! S\u00e5 snart n\u00e5r vi op p\u00e5 10?<\/i><\/p>\n

S\u00e5dan \u00e6ndrer verden sig. Unilever h\u00e6vder, at de har et fantastisk IT-system, der g\u00f8r det muligt. Resultatet ser ud som konceptet Time-to-market<\/b>, som mange allerede har talt om.<\/p>\n

\"Hvad
\n
\nBetydningen af Time-to-market handler ikke om, hvor ofte vi deployer. Man kan ofte deploye, men hvis release-cykluserne er lange, kan det give indtryk af, at virksomheden deployer hver uge, hvis man forskyder de tre m\u00e5neders release-cykluser uge for uge. Tidsrummet fra id\u00e9 til endelig implementering varer dog stadig 3 m\u00e5neder.<\/p>\n

Time-to-market handler om at minimere tiden fra id\u00e9 til endelig implementering.<\/p><\/blockquote>\n

\nI dette tilf\u00e6lde interagerer softwaren med markedet. Ligesom med One Box Shave, hvor kunden interagerer med hjemmesiden. De har ikke s\u00e6lgere \u2013 der er kun hjemmesiden, hvor bes\u00f8gende klikker og efterlader deres \u00f8nsker. Derfor skal der hele tiden v\u00e6re nye opdateringer p\u00e5 hjemmesiden, s\u00e5 den lever op til kundernes \u00f8nsker. For eksempel, i Sydkorea barberer man sig ikke p\u00e5 samme m\u00e5de som i Rusland, og de foretr\u00e6kker ikke duften af fyrretr\u00e6, men derimod for eksempel gulerod og vanilje.<\/p>\n

Da der er behov for hurtigt at \u00e6ndre indholdet p\u00e5 hjemmesiden, \u00e6ndres softwareudviklingen betydeligt. Gennem softwaren skal vi forst\u00e5, hvad kunden \u00f8nsker. Tidligere fik vi denne information gennem omveje, for eksempel via forretningsledelse. Derefter designede vi, indarbejdede kravene i IT-systemet, og alt virkede fint. Nu er det anderledes \u2013 softwaren designes af alle, der er involveret i processen, herunder ingeni\u00f8rer, fordi de gennem tekniske specifikationer l\u00e6rer, hvordan markedet fungerer, og ogs\u00e5 deler deres indsigter med forretningen.<\/p>\n

For eksempel i firmaet Qik, fandt vi pludselig ud af, at folk virkelig gerne ville uploade kontaktlister til serveren, og de udviklede en applikation til os. Oprindeligt havde vi faktisk ikke t\u00e6nkt p\u00e5 det. I en klassisk virksomhed ville man have besluttet, at det var en fejl, da det ikke var angivet i specifikationen, at det skulle fungere godt, og at det overhovedet var blevet implementeret i fuld hast. Man ville have deaktiveret funktionen og sagt: 'Det er ikke n\u00f8dvendigt, det vigtigste er, at den prim\u00e6re funktionalitet fungerer.' Men en teknologisk virksomhed ser det som en mulighed og begynder at \u00e6ndre softwaren i overensstemmelse hermed.<\/p>\n

\"Hvad
\n
\nI 1968 formulerede den kloge fyr Melvin Conway f\u00f8lgende id\u00e9.<\/p>\n

En organisation, der skaber et system, er begr\u00e6nset af designet, som afspejler kommunikationsstrukturen i denne organisation.<\/p><\/blockquote>\n

\nFor more details, to produce different types of systems, you also need to have a different type of communication structure within the company. If you have a top-down hierarchical communication structure, it will not allow you to create systems that can provide a very high Time-to-market.<\/p>\n

L\u00e6s om Conway's lov<\/a><\/noindex> you can via links<\/a><\/noindex>. It is important for understanding the culture or philosophy of DevOps, as the only thing that fundamentally changes in DevOps is precisely the communication structure between teams.<\/b>.<\/p>\n

From a process perspective, before DevOps, all stages: analytics, development, testing, operation, were linear.\"Hvad
\nIn the case of DevOps, all these processes happen simultaneously.<\/p>\n

\"Hvad
\n
\nTime-to-market can only be achieved this way. For people who worked in the old process, this looks somewhat science-fiction, and not great at all.<\/p>\n

So why is DevOps necessary?<\/h3>\n

\nFor the development of digital products<\/b>. If your company does not have a digital product, DevOps is not necessary\u2014this is very important.<\/p>\n

DevOps overcomes the speed limitations of the sequential software production model<\/b>. All processes occur simultaneously in it.<\/p>\n

Complexity increases.<\/b> When DevOps evangelists say that it will make it easier for you to release software\u2014it\u2019s nonsense.<\/p>\n

With DevOps, everything will only become more complicated.<\/p><\/blockquote>\n

\nAt the conference at the Avito booth, one could see what it means to deploy a Docker container\u2014it\u2019s an unreal task. The complexity becomes overwhelming; you have to juggle many balls simultaneously.<\/p>\n

DevOps completely changes the process and the organization within the company<\/b>\u00a0\u2014 or rather, it is not DevOps that changes, but the digital product. To adopt DevOps, you still need to completely change this process.<\/p>\n

Questions for the specialist<\/h3>\n

\nAnd what about you? Questions you can ask yourself while working in the company and developing as a specialist.<\/p>\n

Do you have a strategy for creating a digital product?<\/b> If yes\u2014great. This means your company is moving towards DevOps.<\/p>\n

Is your company already creating a digital product?<\/b> This means you can take it to the next level, dealing with more interesting matters\u2014from a DevOps perspective again. I am speaking only from this perspective.<\/p>\n

Is your company one of the market leaders in the niche with a digital product?<\/b> Spotify, Yandex, Uber - virksomheder, der er p\u00e5 toppen af den teknologiske udvikling lige nu.<\/p>\n

Stil dig selv disse sp\u00f8rgsm\u00e5l, og hvis alle svarene er negative, s\u00e5 er det m\u00e5ske bedst, at du ikke besk\u00e6ftiger dig med DevOps i denne virksomhed. Men hvis emnet DevOps virkelig interesserer dig, kan det v\u00e6re, at... du b\u00f8r overveje at skifte til en anden virksomhed? Hvis din virksomhed \u00f8nsker at bev\u00e6ge sig ind i DevOps, men du har svaret 'Nej' p\u00e5 alle sp\u00f8rgsm\u00e5lene, minder det om denne dejlige n\u00e6sehorn, der aldrig vil \u00e6ndre sig.<\/p>\n

\"Hvad
\n<\/p>\n

Organisation<\/h2>\n

\nSom jeg allerede har n\u00e6vnt, \u00e6ndrer organisationen i virksomheden sig if\u00f8lge Conway's lov. Jeg vil starte med, hvad der forhindrer DevOps i at tr\u00e6nge ind i virksomheden set fra et organisatorisk perspektiv.<\/p>\n

Problemet med 'silocentrering'<\/h3>\n

\nDet engelske ord 'Silo' er her oversat til russisk som '\u043a\u043e\u043b\u043e\u0434\u0435\u0446'. Problemet best\u00e5r i, at der ikke er nogen informationsudveksling mellem teamene.<\/b>Hver team graver dybere i deres ekspertise, uden at der dannes et f\u00e6lles kort, som man kan navigere efter.<\/p>\n

Det minder om en person, der lige er ankommet til Moskva og endnu ikke kan navigere efter metrokortet. Moskvanere kender som regel deres omr\u00e5de temmelig godt, men navigerer i hele Moskva efter metrokortet. N\u00e5r du ankommer til Moskva for f\u00f8rste gang, har du ikke denne f\u00e6rdighed, og du vil bare v\u00e6re desorienteret.<\/p>\n

DevOps foresl\u00e5r at overvinde dette \u00f8jeblik af desorientering og sammen bygge et f\u00e6lles interaktionskort for alle afdelinger.<\/p><\/blockquote>\n

\nTo faktorer hindrer dette.<\/p>\n

F\u00f8lge af virksomhedens ledelsessystem.<\/b> Det er bygget op af separate hierarkiske 'silot'. For eksempel er der bestemte KPI'er i virksomheder, der underst\u00f8tter dette system. P\u00e5 den anden side er der menneskets tanker, som har sv\u00e6rt ved at komme ud over deres ekspertise og orientere sig i hele systemet. Det er simpelthen ubehageligt. Forestil dig, at du er i Bangkok Lufthavn - det er hurtigt sv\u00e6rt at finde rundt. Det er ogs\u00e5 sv\u00e6rt at navigere i DevOps, og derfor siger folk, at de skal finde en guide for at komme dertil.<\/p>\n

Men det vigtigste er, at problemet med 'silocentrering' for en ingeni\u00f8r, der har f\u00e5et \u00e5nden fra DevOps, har l\u00e6st Fowler og en hel del andre b\u00f8ger, er, at 'silot' forhindrer en i at g\u00f8re '\u00e5benlyse' ting.<\/b>Vi samles ofte efter DevOps Moscow, taler med hinanden, og folk klager:<\/p>\n

\u2014 Vi ville bare starte CI, men det viste sig, at ledelsen ikke havde brug for det.<\/i><\/p>\n

Dette sker netop fordi\u00a0CI <\/b>og\u00a0Continuous Delivery process<\/b> ligger p\u00e5 gr\u00e6nsen af mange ekspertiser. Bare ved ikke at overvinde problemet med \u201ebr\u00f8nde\u201d p\u00e5 organisatorisk niveau, kan man ikke komme videre, uanset hvad man g\u00f8r, og hvor trist det end m\u00e5tte v\u00e6re.<\/p>\n

\"Hvad
\n
\nHver deltager i processen i virksomheden: backend- og frontend-udviklere, testere, DBA'er, drift, netv\u00e6rk, graver i deres egen retning, og ingen har kortl\u00e6gningen, undtagen lederen, der p\u00e5 en eller anden m\u00e5de overv\u00e5ger dem og styrer med metoden \u201edel og hersk\u201d.<\/p>\n

Folk k\u00e6mper for nogle stjerner eller flag, hver graver i sin egen ekspertise.<\/p><\/blockquote>\n

\nResultatet er, at n\u00e5r opgaven opst\u00e5r for at samle det hele og bygge en f\u00e6lles pipeline, og man ikke l\u00e6ngere beh\u00f8ver at k\u00e6mpe for stjerner og flag, opst\u00e5r sp\u00f8rgsm\u00e5let \u2013 hvad skal man s\u00e5 overhovedet g\u00f8re? Man skal finde en m\u00e5de at blive enige p\u00e5, men hvordan g\u00f8r man det? Ingen har l\u00e6rt os det i skolen. Vi er l\u00e6rte fra skolen: ottende klasse \u2013 wow! \u2013 i sammenligning med syvende klasse! Det er det samme her.<\/p>\n

Er det ogs\u00e5 s\u00e5dan i din virksomhed?<\/h3>\n

\nFor at tjekke dette kan man stille sig selv f\u00f8lgende sp\u00f8rgsm\u00e5l.<\/p>\n

Bruger holdene f\u00e6lles v\u00e6rkt\u00f8jer, bidrager de til \u00e6ndringer af disse f\u00e6lles v\u00e6rkt\u00f8jer?<\/p>\n

Hvor ofte omorganiseres teams \u2014 nogle specialister fra \u00e9t team g\u00e5r over til et andet team?<\/b> I DevOps-milj\u00f8et bliver dette normalt, fordi det nogle gange er sv\u00e6rt for en person at forst\u00e5, hvad et andet ekspertiseomr\u00e5de arbejder med. Han skifter til en anden afdeling, arbejder der i et par uger for at skabe sit eget kort over orientering og interaktion med denne afdeling.<\/p>\n

Kan man oprette et udvalg for \u00e6ndringer og \u00e6ndre noget? <\/b>Eller kr\u00e6ver det en st\u00e6rk h\u00e5nd fra den \u00f8verste ledelse og en ordre? For nylig skrev jeg p\u00e5 Facebook, hvordan en lidt kendt bank implementerer v\u00e6rkt\u00f8jer gennem ordrer: de skrev en ordre, implementerer i et \u00e5r, og ser, hvad der sker. Det er selvf\u00f8lgelig langt og trist.<\/p>\n

Hvor vigtigt er det for ledere at f\u00e5 personlige pr\u00e6stationer uafh\u00e6ngigt af virksomhedens pr\u00e6stationer? <\/b><\/p>\n

Hvis du besvarer disse sp\u00f8rgsm\u00e5l for dig selv, vil det blive mere klart, om du har et s\u00e5dant problem i virksomheden.<\/p>\n

Infrastruktur som kode<\/h2>\n

\nN\u00e5r dette problem er l\u00f8st, er den f\u00f8rste vigtige praksis, som det er sv\u00e6rt at komme videre i DevOps uden, dette infrastruktur som kode<\/b>. <\/p>\n

Ofte opfattes infrastruktur som kode s\u00e5ledes:<\/p>\n

\u2014 Lad os automatisere alt med bash, sm\u00f8re os ind i scripts, s\u00e5 administratorerne har mindre manuelt arbejde!<\/i><\/p>\n

Men det er ikke s\u00e5dan.<\/p>\n

Infrastruktur som kode indeb\u00e6rer, at du beskriver IT-systemet, som du arbejder med, i form af kode for konstant at forst\u00e5 dens tilstand.<\/p><\/blockquote>\n

\nSammen med andre teams laver du et kort i form af kode, som alle kan forst\u00e5, som man kan navigere efter. Uanset om det er lavet med Chef, Ansible, Salt, eller der anvendes YAML-filer i Kubernetes, g\u00f8r det ingen forskel.<\/p>\n

P\u00e5 konferencen fortalte en kollega fra 2GIS, hvordan de lavede deres interne l\u00f8sning til Kubernetes, der beskriver strukturen af enkelte systemer. For at beskrive 500 systemer havde de brug for et separat v\u00e6rkt\u00f8j, der genererede denne beskrivelse. N\u00e5r der er denne beskrivelse, kan enhver tjekke med hinanden, overv\u00e5ge \u00e6ndringer, hvordan man skal \u00e6ndre og forbedre den, hvad der mangler. <\/p>\n

I m\u00e5 indr\u00f8mme, at separate bash-scripts normalt ikke giver denne forst\u00e5else. I et af de virksomheder, hvor jeg arbejdede, var der endda en betegnelse \"write only\"-script \u2014 n\u00e5r scriptet er skrevet, er det ikke muligt at l\u00e6se det. Jeg tror, det er noget, I ogs\u00e5 kender til.<\/p>\n

Infrastruktur som kode er kode, der beskriver den aktuelle tilstand af infrastrukturen<\/b>. Denne kode arbejdes der sammen p\u00e5 af mange produkt-, infrastruktur- og serviceteams, og vigtigst af alt, alle skal forst\u00e5, hvordan denne kode overhovedet fungerer.<\/p>\n

Koden underst\u00f8ttes i henhold til bedste praksisser for arbejde med kode<\/b>: samarbejde om udvikling, code review, XP-programmering, testning, pull requests, CI for infrastrukturer af kode - alt dette er v\u00e6rdifuldt og kan bruges.<\/p>\n

Koden bliver et f\u00e6lles sprog for alle ingeni\u00f8rer.<\/p><\/blockquote>\n

\n\u00c6ndring af infrastrukturen i koden tager ikke meget tid<\/b>. Ja, der kan ogs\u00e5 v\u00e6re teknisk g\u00e6ld i infrastrukturskoden. Normalt st\u00e5r teams over for den efter et og et halvt \u00e5r efter, at de begyndte at implementere \"infrastruktur som kode\" i form af en bunke scripts eller endda Ansible, som de skriver som spaghetti-kode og endnu tilf\u00f8jer bash-scripts til b\u00e5let! <\/p>\n

Det er vigtigt<\/b>: hvis I ikke har pr\u00f8vet denne skrammel endnu, s\u00e5 husk, at Ansible er ikke bash<\/b>! L\u00e6s dokumentationen omhyggeligt, og s\u00e6t dig ind i, hvad der overhovedet st\u00e5r om dette.<\/p>\n

Infrastruktur som kode \u2013 det handler om at opdele infrastrukturkoden i separate lag.<\/p><\/blockquote>\n

\nVi i vores virksomhed skelner mellem 3 grundl\u00e6ggende lag, som er meget forst\u00e5elige og enkle, men der kan v\u00e6re flere. Du kan tage et kig p\u00e5 din infrastrukturkode og sp\u00f8rge, om dette kriterium er opfyldt. Hvis der ikke skelnes mellem lagene, b\u00f8r du finde tid til at refaktorisere lidt.
\n\"Hvad
\n
\nGrundlag<\/b>\u00a0\u2013 det handler om, hvordan OS, backups og andre lavniveau ting konfigureres, for eksempel, hvordan Kubernetes implementeres p\u00e5 et grundl\u00e6ggende niveau.<\/p>\n

Service niveau<\/b>\u00a0\u2013 det er de tjenester, du tilbyder udvikleren: logf\u00f8ring som en tjeneste, overv\u00e5gning som en tjeneste, database som en tjeneste, load balancer som en tjeneste, k\u00f8 som en tjeneste, Continuous Delivery som en tjeneste \u2013 en masse tjenester, som de enkelte teams kan levere til udviklingen. Alt dette skal beskrives i separate moduler i dit konfigurationsstyringssystem.<\/p>\n

Lag, hvor applikationer oprettes<\/b> og hvor det beskrives, hvordan de vil blive implementeret ovenp\u00e5 de to tidligere lag.<\/p>\n

Kontrolsp\u00f8rgsm\u00e5l<\/h3>\n

\nHar din virksomhed en f\u00e6lles infrastrukturelle repository? Overv\u00e5ger du den tekniske g\u00e6ld i infrastrukturen? Bruger du udviklingspraksis i det infrastrukturelle repository? Er din infrastruktur opdelte i lag? Du kan krydsreferere med diagrammet Base-service-APP. Hvor sv\u00e6rt er det at foretage en \u00e6ndring? <\/p>\n

Hvis du har oplevet, at \u00e6ndringer tog halvanden dag, betyder det, at du har opbygget teknisk g\u00e6ld, og det skal arbejdes med. Du har netop st\u00f8dt p\u00e5 problemer med teknisk g\u00e6ld i infrastrukturkoden. Jeg husker mange s\u00e5danne historier, hvor man skulle skrive halvdelen af infrastrukturkoden om for at \u00e6ndre noget CCTL, fordi kreativitet og \u00f8nsket om at automatisere alt har f\u00f8rt til, at alt er blevet for meget blandet sammen, alle h\u00e5ndtag er fjernet, og der skal refaktoreres.<\/p>\n

Kontinuerlig levering<\/h2>\n

\nLad os sammenligne debet med kredit. F\u00f8rst kommer en beskrivelse af infrastrukturen, som kan v\u00e6re ret grundl\u00e6ggende. Det er ikke n\u00f8dvendigt at beskrive alt i detaljer, men en grundl\u00e6ggende beskrivelse er p\u00e5kr\u00e6vet, s\u00e5 I kan arbejde med det. Ellers er det uklart, hvordan man forts\u00e6tter med at g\u00f8re kontinuerlig levering. Alle disse praksisser udspiller sig samtidig, n\u00e5r I kommer til DevOps, men I skal starte med at forst\u00e5, hvad I har, og hvordan I styrer det. Det er pr\u00e6cist praksis med infrastruktur som kode.<\/p>\n

N\u00e5r det er blevet klart, hvad I har, og hvordan I kan styre det, begynder I at finde ud af, hvordan udviklerens kode hurtigst muligt skal sendes til produktion. Jeg mener sammen med udvikleren \u2013 husk p\u00e5 problemet med \"br\u00f8nden\", alts\u00e5 at det ikke er enkeltpersoner, der finder p\u00e5 det, men et team.<\/p>\n

Da vi\u00a0s\u00e5 Ivan Evtukhovich<\/b> for den f\u00f8rste bog af Jez Humble<\/b> og et forfatterhold \u00abContinuous Delivery\u00bb<\/b>, som blev udgivet i 2009, overvejede vi l\u00e6nge, hvordan vi skulle overs\u00e6tte dens titel til russisk. Vi ville overs\u00e6tte det som \u00abLevering hele tiden\u00bb, men desv\u00e6rre oversatte vi det som \u00abKontinuerlig levering\u00bb. Jeg synes, at der er et eller andet russisk over vores navn, med en st\u00e6rk essens.<\/p>\n

Levering hele tiden betyder<\/h3>\n

\nAt koden, som ligger i produktarkivet, altid kan blive sendt til produktion<\/b>. Den kan muligvis ikke blive sendt, men den er altid klar til det. Som f\u00f8lge heraf skriver I altid kode med en sv\u00e6r at forklare f\u00f8lelse af en vis ubehag under halebenet. Dette ubehag opst\u00e5r ofte, n\u00e5r man ruller infrastrukturen ud. Denne f\u00f8lelse af ubehag b\u00f8r v\u00e6re til stede - den fremkalder mentale processer, som g\u00f8r, at man kan skrive koden lidt anderledes. Dette skal v\u00e6re fastlagt i reglerne inden for udviklingen.<\/p>\n

For at levere konstant er der behov for et artefaktformat, der fungerer p\u00e5 infrastrukturplatformen. <\/b>Hvis I smider affald af forskellig art ind p\u00e5 infrastrukturplatformen, bliver den ikke ensartet, den er sv\u00e6r at vedligeholde, og der opst\u00e5r teknisk g\u00e6ld. Artefaktformatet skal harmoniseres - det er ogs\u00e5 en kollektiv opgave: alle skal samles, t\u00e6nke og finde p\u00e5 dette format.<\/p>\n

Artefakten forbedres kontinuerlig og \u00e6ndrer sig under produktionsmilj\u00f8et, mens den bev\u00e6ger sig gennem leveringspipen. <\/b>N\u00e5r artefakten bev\u00e6ger sig gennem pipelinen, st\u00f8der den hele tiden p\u00e5 nogle ubehagelige situationer, der ligner dem, som artefakten, som du udgiver til produktion, oplever. Hvis en systemadministrator h\u00e5ndterer udgivelserne i klassisk udvikling, s\u00e5 sker det kontinuerligt i DevOps-processen: her bliver den koordineret med forskellige tests, der bliver sendt til et Kubernetes-kluster, som mere eller mindre ligner produktionen, og her vil der pludselig blive udf\u00f8rt belastningstests.<\/p>\n

Det minder om at spille Pac-Man \u2013 artefakten gennemg\u00e5r en slags historie. Det er vigtigt at kontrollere, om koden faktisk gennemg\u00e5r historien, og at den p\u00e5 en eller anden m\u00e5de er knyttet til din produktion. Historier fra produktion kan integreres i Continuous Delivery-processen: i situationen hvor noget bryder sammen, lad os programmere dette scenarie ind i systemet. Hver gang koden vil ogs\u00e5 gennemg\u00e5 dette scenarie, og du vil ikke st\u00f8de p\u00e5 dette problem n\u00e6ste gang. Du vil opdage det meget tidligere, end det n\u00e5r til din kunde.<\/p>\n

Forskellige distributionsstrategier. <\/b>For eksempel kan du bruge AB-test eller kanariefugle-distribution for at \"afpr\u00f8ve\" koden p\u00e5 forskellige kunder, s\u00e5 du kan f\u00e5 indblik i, hvordan koden fungerer, meget f\u00f8r den rulles ud til 100 millioner brugere.<\/p>\n

\"At levere kontinuerligt\" ser s\u00e5ledes ud.<\/p>\n

\"Hvad
\n<\/p>\n

Leveringsprocessen Dev, CI, Test, PreProd, Prod \u2013 er ikke et separat milj\u00f8, det er stadier eller stationer med brandsikre summer, som din artefakt bev\u00e6ger sig gennem.<\/p><\/blockquote>\n

\nHvis du har infrastrukturkode, der er beskrevet som Base Service APP, s\u00e5 hj\u00e6lper det med ikke at glemme alle scenarier.<\/b>, og ogs\u00e5 optage dem i form af kode for denne artefakt, fremme artefakten<\/b> og \u00e6ndre den undervejs.<\/p>\n

Sp\u00f8rgsm\u00e5l til selvkontrol<\/h3>\n

\nEr tiden fra beskrivelsen af \u200b\u200bfunktionen til udgivelsen til produktion i 95 % af tilf\u00e6ldene mindre end en uge? Forbedres artefaktens kvalitet p\u00e5 hvert trin i pipelinen? Er der en historie, som den gennemg\u00e5r? Bruger du forskellige distributionsstrategier?<\/p>\n

Hvis alle svar er ja, s\u00e5 er du virkelig fantastisk! Skriv svarene i kommentarerne - jeg vil v\u00e6re glad for det.<\/p>\n

Feedback<\/h3>\n

\nDette er den sv\u00e6reste praksis af alle. P\u00e5 DevOpsConf-konferencen var en kollega fra Infobip lidt forvirret i sine ord, mens han talte om det, fordi det virkelig er en meget kompleks praksis for, hvad man skal overv\u00e5ge overhovedet.<\/p>\n

\"Hvad
\n
\nFor eksempel, for l\u00e6nge siden, da jeg arbejdede i Qik, inds\u00e5 vi, at vi skulle overv\u00e5ge alt. Vi gjorde det, og i Zabbix havde vi 150.000 items, der blev overv\u00e5get kontinuerligt. Det var skr\u00e6mmende, og direkt\u00f8ren rystede p\u00e5 hovedet:<\/p>\n

\u2014 Fyre, hvad laver I med serveren?<\/i><\/p>\n

Men derefter skete der en h\u00e6ndelse, der viste, at det faktisk er en rigtig god strategi.<\/p>\n

En af tjenesterne begyndte konstant at falde. Oprindeligt faldt den ikke, hvilket er interessant, da der ikke blev tilf\u00f8jet nogen kode, fordi det var en grundl\u00e6ggende broker, der praktisk talt ikke havde nogen forretningsfunktionalitet \u2014 den sendte blot beskeder mellem de forskellige tjenester. Tjenesten havde ikke \u00e6ndret sig i 4 m\u00e5neder, og pludselig begyndte den at falde med fejlen \"Segmentation fault\".<\/p>\n

Vi var chokerede, \u00e5bnede vores grafer i Zabbix, og fandt ud af, at adf\u00e6rden for anmodningerne i API-tjenesten, der bruger denne broker, pludselig \u00e6ndrede sig for halvanden uge siden. Derefter s\u00e5 vi, at hyppigheden af sendingen af en bestemt type beskeder var \u00e6ndret. Efterf\u00f8lgende fandt vi ud af, at det var android-klienter, og vi spurgte:<\/p>\n

\u2014 Fyre, hvad skete der med jer for halvanden uge siden?<\/i><\/p>\n

Som svar h\u00f8rte vi en interessant historie om, at de havde redesignede UI. Det er usandsynligt, at nogen straks ville sige, at de \u00e6ndrede HTTP-biblioteket. For android-klienter er det som at skifte s\u00e6be i badev\u00e6relset \u2014 de kan simpelthen ikke huske det. I sidste ende, efter 40 minutters samtale, fandt vi ud af, at de faktisk havde \u00e6ndret HTTP-biblioteket, og at dets standardtider var blevet \u00e6ndret. Det f\u00f8rte til, at trafikadf\u00e6rden p\u00e5 API-serveren \u00e6ndrede sig, hvilket f\u00f8rte til den situation, der for\u00e5rsagede en race inde i brokeren, og den begyndte at falde.<\/p>\n

Uden dyb overv\u00e5gning er det overhovedet umuligt at opdage dette.<\/b>. Hvis der i organisationen ogs\u00e5 er et problem med \"br\u00f8nde\", hvor alle kaster ansvaret videre til hinanden, kan det leve i \u00e5revis. Du genstarter bare serveren, fordi det er umuligt at l\u00f8se problemet. N\u00e5r du overv\u00e5ger, sporer alle h\u00e6ndelser, du har, og bruger overv\u00e5gning som testning - skriver kode og angiver straks, hvordan den skal overv\u00e5ges, ogs\u00e5 i kodens form (vi har allerede infrastruktur som kode), bliver alt klart som dagen. Selv s\u00e5 komplekse problemer kan nemt f\u00f8lges.<\/p>\n

\"Hvad
\n<\/p>\n

Indsaml al information om, hvad der sker med artefakten p\u00e5 hver fase af leveringsprocessen - ikke i produktion.<\/p><\/blockquote>\n

\nUpload overv\u00e5gning til CI, og der vil allerede v\u00e6re synlige grundl\u00e6ggende ting. Derefter vil du se dem i Test, i PredProd og i belastningstestning. Indsaml information p\u00e5 alle faser, ikke kun metrics, statistik, men ogs\u00e5 logs: hvordan applikationen blev udrullet, anomalier - indsaml alt. <\/p>\n

Ellers bliver det sv\u00e6rt at finde ud af. Jeg har allerede sagt, at DevOps er st\u00f8rre kompleksitet. For at h\u00e5ndtere denne kompleksitet kr\u00e6ves der en ordentlig analyse.<\/b>.<\/p>\n

Selvkontrol sp\u00f8rgsm\u00e5l.<\/h3>\n

\nEr din overv\u00e5gning og logf\u00f8ring et udviklingsv\u00e6rkt\u00f8j for dig?<\/b> T\u00e6nker dine udviklere, inklusive dig, p\u00e5, hvordan koden skal overv\u00e5ges, n\u00e5r de skriver den?<\/p>\n

Finder du ud af problemer fra kunder? Forst\u00e5r du kunden bedre gennem overv\u00e5gning og logf\u00f8rsel?<\/b> Forst\u00e5r du systemet bedre gennem overv\u00e5gning og logf\u00f8rsel?<\/b> \u00c6ndrer du systemet bare fordi du har set, at trenden i systemet stiger, og forst\u00e5r, at om 3 uger vil alt falde sammen? <\/p>\n

N\u00e5r du har disse tre komponenter, kan du overveje, hvilken infrastruktural platform du har i din virksomhed.<\/p>\n

Infrastruktural platform. <\/h2>\n

\nDet handler ikke om, at det er en samling af adskilte v\u00e6rkt\u00f8jer, som findes i hver virksomhed.<\/p>\n

Essensen af den infrastrukturelle platform er, at alle teams bruger disse v\u00e6rkt\u00f8jer og udvikler dem sammen.<\/p><\/blockquote>\n

\nDet er klart, at der er adskilte teams, som er ansvarlige for udviklingen af s\u00e6rskilte dele af den infrastrukturelle platform. Men samtidig b\u00e6rer hvert ingeni\u00f8r ansvar for udviklingen, driftsikkerheden og fremme af den infrastrukturelle platform. P\u00e5 det interne niveau bliver det et f\u00e6lles v\u00e6rkt\u00f8j<\/b>. <\/p>\n

Alle teams udvikler infrastrukturplatformen og behandler den omhyggeligt som deres eget IDE<\/b>. I dit IDE installerer du forskellige plugins for at g\u00f8re det p\u00e6nt og hurtigt, og du tilpasser genvejstasterne. N\u00e5r du \u00e5bner Sublime, Atom eller Visual Studio Code, popper der kodefejl op, og du forst\u00e5r, at det er umuligt at arbejde; du bliver straks trist og l\u00f8ber for at reparere dit IDE.<\/p>\n

Behandl derfor din infrastrukturplatform p\u00e5 samme m\u00e5de. Hvis du forst\u00e5r, at der er noget galt med den, skal du indsende en anmodning, hvis du ikke kan reparere det selv. Men hvis det er noget simpelt, skal du rette det selv og sende pull requesten - folkene ser p\u00e5 det og tilf\u00f8jer. Det er en lidt anden tilgang til ingeni\u00f8rv\u00e6rkt\u00f8jet i udviklerens hoved.<\/p>\n

Infrastrukturplatformen sikrer overf\u00f8rsel af artefaktet fra udvikling til kunde med konstant forbedring af kvaliteten<\/b>. I IP'en er der programmeret en r\u00e6kke historier, der sker med koden i produktion. Gennem \u00e5rene er der blevet mange af disse historier, nogle af dem er unikke og relateret kun til dig - de kan ikke findes p\u00e5 internettet. <\/p>\n

P\u00e5 dette tidspunkt bliver infrastrukturplatformen din konkurrencefordel<\/b>, fordi der er indbygget ting, som ikke findes i konkurrentens v\u00e6rkt\u00f8j. Jo dybere din IP er, desto st\u00f8rre er din konkurrencefordel i forhold til Time-to-market. Her opst\u00e5r der problem ved vendor lock<\/b>: du kan tage en andens platform, men ved at bruge andres erfaring vil du ikke forst\u00e5, hvor relevant den er for dig. Ja, ikke alle virksomheder kan bygge en platform som Amazon. Det er en sv\u00e6r gr\u00e6nse, hvor en virksomheds erfaring er relevant for dens placering p\u00e5 markedet, og man m\u00e5 ikke give efter for vendor lock. Det er ogs\u00e5 vigtigt at overveje.<\/p>\n

Diagram<\/h3>\n

\nDette er den grundl\u00e6ggende struktur af infrastrukturplatformen, som vil hj\u00e6lpe dig med at etablere alle praksisser og processer i en DevOps-virksomhed.<\/p>\n

\"Hvad
\n
\nLad os se p\u00e5, hvad den best\u00e5r af.<\/p>\n

System til orkestrering af ressourcer<\/b>, som leverer CPU, hukommelse og disk til applikationer og andre tjenester. Oven p\u00e5 dette - tjenester af lavere niveau<\/b>: overv\u00e5gning, logging, CI\/CD-motor, artefaktholdere, infrastruktur som kode-systemer.<\/p>\n

Tjenester af h\u00f8jere 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. On top of this \u2014 a pipeline that constantly delivers modified code to your client<\/b>.<\/p>\n

You get information on how your software performs for the client, make changes, deliver the code again, get feedback \u2014 and thus continually develop both the infrastructure platform and your software.<\/p>\n

In the diagram, the delivery pipeline consists of many stages. But this is a conceptual diagram provided as an example \u2014 there's no need to replicate it exactly. The stages interact with services as services \u2014 each building block of the platform has its own story: how resources are allocated, how the application is launched, how it interacts with resources, is monitored, and evolves.<\/p>\n

It's important to understand that each part of the platform tells a story, and you should ask yourself \u2014 what story does this building block tell? Perhaps it should be discarded and replaced with a third-party service. For example, can we replace a block with Okmeter? Maybe those guys have already developed this expertise much more 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 the platform<\/h3>\n

\nIt\u2019s a complex communication process. When you have basic practices, you initiate communication among different engineers and specialists who develop requirements and standards, and continuously modify them for different tools and approaches. Here, the culture present in DevOps is crucial.<\/p>\n

\"Hvad
\nWith culture, everything is quite simple \u2014 it's collaboration and communication<\/b>, that is, the willingness to work collectively in the same field, the desire to master a single tool together. There\u2019s no rocket science here \u2014 it's all very straightforward, even trivial. For example, we all live in an apartment building and maintain its cleanliness \u2014 that\u2019s the level of culture.<\/p>\n

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

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

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

Disse sp\u00f8rgsm\u00e5l skal man konstant stille sig selv. Hvis noget kan udskilles til eksterne tjenester, skal det g\u00f8res. Hvis en ekstern tjeneste begynder at blokere din fremgang, s\u00e5 skal man opbygge et system internt.<\/p>\n

S\u00e5, DevOps...<\/h2>\n

\n\u2026 er et komplekst system, som skal indeholde:<\/p>\n