Definitionen af DevOps er meget kompleks, så vi er nødt til at starte diskussionen om det forfra hver gang. Der er tusinde publikationer om dette emne alene på Habré. Men hvis du læser dette, ved du sikkert, hvad DevOps er. For det er jeg ikke. Hej mit navn er Alexander Titov (@), og vi taler lige om DevOps, og jeg deler min erfaring.
Jeg har længe tænkt på, hvordan jeg kan gøre min historie nyttig, så der vil være mange spørgsmål her - dem, jeg stiller mig selv, og dem, som jeg stiller vores virksomheds kunder. Ved at besvare disse spørgsmål bliver forståelsen bedre. Jeg vil fortælle dig, hvorfor DevOps er nødvendig fra mit synspunkt, hvad det er, igen fra mit synspunkt, og hvordan du forstår, at du bevæger dig mod DevOps igen fra mit synspunkt. Det sidste punkt vil være gennem spørgsmål. Ved at besvare dem for dig selv, kan du forstå, om din virksomhed er på vej mod DevOps, eller om der er problemer på en eller anden måde.
På et tidspunkt red jeg på bølgerne af fusioner og opkøb. Først arbejdede jeg for en lille startup kaldet Qik, derefter blev den købt af et lidt større firma kaldet Skype, som så blev købt af et lidt større firma kaldet Microsoft. I det øjeblik begyndte jeg at se, hvordan ideen om DevOps forvandlede sig i virksomheder i forskellige størrelser. Herefter blev jeg interesseret i at se på DevOps fra et markedssynspunkt, og mine kolleger og jeg grundlagde virksomheden Express 42. I 6 år nu har vi bevæget os langs markedets bølger.
Jeg er blandt andet en af arrangørerne af DevOps Moskva-fællesskabet og arrangør af DevOps-Days 2017, men jeg organiserede ikke 2018. Express 42 arbejder med mange virksomheder. Vi dyrker DevOps der, ser, hvordan det sker, drager konklusioner, analyserer, fortæller alle vores konklusioner og træner folk i DevOps-praksis. Generelt gør vi vores bedste for at øge vores erfaring og ekspertise i denne henseende.
Hvorfor DevOps
Det første spørgsmål, der hjemsøger alle og altid er - hvorfor? Mange mennesker tror, at DevOps bare er automatisering eller en lignende ting, som enhver virksomhed allerede havde.
— Vi havde Kontinuerlig Integration - det betyder, at vi allerede havde DevOps, og hvorfor er alle disse ting nødvendige? De hygger sig i udlandet, men de forhindrer os i at arbejde!
Over 9 års udvikling af fællesskabet og metoden er det allerede blevet klart, at dette stadig ikke er markedsføringsglitter, men det er stadig ikke helt klart, hvorfor det er nødvendigt. Som ethvert værktøj og enhver proces har DevOps specifikke mål, som den i sidste ende opnår.
Alt dette skyldes, at verden er under forandring. Han bevæger sig væk fra enterprise-tilgangen, når virksomheder bevæger sig direkte mod en drøm, som vores Sankt Petersborg-klassiker sang, fra punkt A til punkt B efter en bestemt strategi, med en bestemt struktur bygget til dette.
I princippet skal alt i IT bygges efter denne tilgang. Her bruges IT udelukkende til at automatisere processer.
Automatiseringen ændrer sig ikke ofte, for når en virksomhed går ned i et stærkt trængt hjulspor, hvad er der så at ændre på? Det virker – rør det ikke. Nu ændrer tilgange i verden sig, og den kaldet Agile antyder, at endepunkt B ikke umiddelbart er synligt.
Når en virksomhed går gennem markedet, arbejder med en kunde, udforsker den konstant markedet og ændrer slutpunkt B. Desuden, jo oftere virksomheden ændrer retning, jo mere succesfuld er den i sidste ende, fordi den vælger mere marked nicher.
Strategien demonstreres af en interessant virksomhed, som jeg for nylig lærte om. One Box Shave er en abonnementsleveringstjeneste for barbermaskiner og barberingstilbehør i en æske. De ved, hvordan de tilpasser deres "boks" til forskellige kunder. Dette gøres af en bestemt software, som så sender ordren til den koreanske fabrik, der producerer varerne.
Dette produkt blev købt af Unilever for $1 mia. Det konkurrerer nu med Gillette og har fjernet en betydelig andel af forbrugerne på det amerikanske marked. One Box Shave siger:
- 4 knive? Er du seriøs? Hvorfor har du brug for dette - det forbedrer ikke kvaliteten af barberingen. En specielt udvalgt creme, duft og en højkvalitets barbermaskine med to blade løser meget flere problemer end de dumme 4 Gillette blade! Kommer vi snart til 10?
Sådan ændrer verden sig. Unilever hævder, at de har et fedt it-system, der giver dig mulighed for dette. I sidste ende ligner det et koncept Time-to-market, som ingen allerede har talt om.
Pointen med Time-to-market er ikke, hvor ofte vi implementerer. Du kan ofte implementere, men udgivelsescyklusserne vil være lange. Hvis tre-måneders udgivelsescyklusser er overlejret på hinanden, og flytter dem med en uge, viser det sig, at virksomheden ser ud til at implementere en gang om ugen. Og fra idéen til den endelige implementering går der 3 måneder.
Time-to-market handler om at minimere tiden fra idé til endelig implementering.
I dette tilfælde interagerer software med markedet. Dette er, hvordan One Box Shave-webstedet interagerer med klienten. De har ikke sælgere – blot en hjemmeside, hvor besøgende klikker og efterlader ønsker. Derfor skal der løbende lægges nyt på siden og opdateres efter ønsker. For eksempel i Sydkorea barberer de sig anderledes end i Rusland, og de kan lide duften ikke af fyrretræ, men for eksempel af gulerødder og vanilje.
Da det er nødvendigt hurtigt at ændre indholdet på siden, ændrer softwareudvikling sig meget. Gennem software skal vi finde ud af, hvad kunden ønsker. Tidligere har vi lært dette gennem nogle rundveje, for eksempel gennem virksomhedsledelse. Så designede vi det, satte kravene ind i it-systemet, og alt var fedt. Nu er det anderledes - software er designet af alle, der er involveret i processen, inklusive ingeniører, fordi de gennem tekniske specifikationer lærer, hvordan markedet fungerer og deler også deres indsigt med virksomheden.
For eksempel lærte vi pludselig hos Qik, at folk virkelig kunne lide at uploade kontaktlister til serveren, og de forsynede os med en applikation. I starten tænkte vi ikke over det. I et klassisk firma ville alle have besluttet, at dette var en fejl, da specifikationerne ikke sagde, at det skulle fungere godt og generelt var implementeret på knæet, ville de have slået funktionen fra og sagt: "Ingen har brug for dette, det vigtigste er, at hovedfunktionaliteten fungerer.” . Og teknologivirksomheden ser dette som en mulighed og begynder at ændre softwaren i overensstemmelse hermed.
I 1968 formulerede en visionær fyr, Melvin Conway, følgende idé.
Den organisation, der skaber systemet, er begrænset af et design, der replikerer organisationens kommunikationsstruktur.
Mere detaljeret, for at producere systemer af en anden type, skal du også have en kommunikationsstruktur i en virksomhed af en anden type. Hvis din kommunikationsstruktur er top-hierarkisk, så vil dette ikke tillade dig at skabe systemer, der kan give en meget høj Time-to-Market-indikator.
ære man kan . Det er vigtigt for at forstå DevOps-kulturen eller -filosofien, fordi det eneste, der fundamentalt ændrer sig i DevOps, er strukturen i kommunikationen mellem teams.
Fra et processynspunkt, før DevOps, var alle stadier: analyse, udvikling, test, drift lineære.
I tilfælde af DevOps foregår alle disse processer samtidigt.
Time-to-market er den eneste måde, det kan gøres på. For folk, der arbejdede i den gamle proces, ser dette noget kosmisk ud og generelt halvdårligt.
Så hvorfor har du brug for DevOps?
Til digital produktudvikling. Hvis din virksomhed ikke har et digitalt produkt, er DevOps ikke nødvendigt – det er meget vigtigt.
DevOps overvinder hastighedsbegrænsningerne ved sekventiel softwareproduktion. I den foregår alle processer samtidigt.
Sværhedsgraden stiger. Når DevOps-evangelister fortæller dig, at det vil gøre det nemmere for dig at frigive software, er det noget vrøvl.
Med DevOps bliver tingene kun mere komplicerede.
På konferencen på Avito-standen kunne man se, hvordan det var at installere en Docker-container – en urealistisk opgave. Kompleksiteten bliver uoverkommelig; du skal jonglere med mange bolde på samme tid.
DevOps ændrer fuldstændig processen og organisationen i virksomheden — mere præcist er det ikke DevOps, der ændrer sig, men det digitale produkt. For at komme til DevOps skal du stadig ændre denne proces fuldstændigt.
Spørgsmål til en specialist
Hvad har du? Spørgsmål, som du kan stille dig selv, mens du arbejder i en virksomhed og udvikler dig som specialist.
Har du en strategi for at skabe et digitalt produkt? Hvis der er, er det allerede godt. Det betyder, at din virksomhed er på vej mod DevOps.
Er din virksomhed allerede ved at skabe et digitalt produkt? Det betyder, at du kan stige endnu et niveau højere og gøre tingene mere interessant – igen fra et DevOps-synspunkt. Jeg taler kun fra dette synspunkt.
Er din virksomhed en af markedslederne inden for den digitale produktniche? Spotify, Yandex, Uber er virksomheder, der er på toppen af teknologiske fremskridt nu.
Stil dig selv disse spørgsmål, og hvis alle svarene er nej, så burde du måske ikke lave DevOps hos denne virksomhed. Hvis emnet DevOps virkelig er interessant for dig, burde du måske... flytte til en anden virksomhed? Hvis din virksomhed ønsker at gå ind i DevOps, men du svarede "Nej" til alle spørgsmålene, så er det ligesom det smukke næsehorn, der aldrig vil ændre sig.
Organisation
Som sagt ændres organisationen af en virksomhed ifølge Conways lov. Jeg starter med, hvad der forhindrer DevOps i at trænge ind i virksomheden fra et organisatorisk synspunkt.
Problemet med "brønde"
Det engelske ord "Silo" er her oversat til russisk som "godt". Pointen med dette problem er det der er ingen udveksling af information mellem teams. Hvert hold graver dybt i deres ekspertise uden at bygge et fælles kort til at navigere.
På nogle måder minder dette mig om en person, der lige er ankommet til Moskva og endnu ikke ved, hvordan man navigerer på metrokortet. Moskovitter kender normalt deres område meget godt, og i hele Moskva kan de navigere ved hjælp af metrokortet. Når du kommer til Moskva for første gang, har du ikke denne evne, og du er bare desorienteret.
DevOps foreslår at komme igennem dette øjeblik af desorientering, og at alle afdelinger arbejder sammen om at opbygge et fælles interaktionskort.
To faktorer forhindrer dette.
Konsekvens af virksomhedens ledelsessystem. Den er bygget i separate hierarkiske "brønde". For eksempel er der visse KPI'er i virksomheder, der understøtter dette system. På den anden side er hjernen hos en person, der har svært ved at gå ud over grænserne for deres ekspertise og navigere i hele systemet, i vejen. Det er bare ubehageligt. Forestil dig, at du er i Bangkok lufthavn - du finder ikke hurtigt rundt. DevOps er også svært at navigere i, og det er derfor folk siger, at du skal finde en guide for at komme dertil.
Men det vigtigste er, at problemet med "brønde" for en ingeniør, der er gennemsyret af DevOps-ånden, har læst Fowler og en masse andre bøger, kommer til udtryk i, at "brønde" tillader dig ikke at gøre "indlysende" ting. Vi mødes ofte efter DevOps Moskva, taler med hinanden, og folk klager:
- Vi ville bare lancere CI, men det viste sig, at ledelsen ikke havde brug for det.
Dette sker netop pga CI и Kontinuerlig leveringsproces er på grænsen til mange undersøgelser. Simpelthen uden at overvinde problemet med "brønde" på det organisatoriske niveau, vil du ikke være i stand til at komme videre, uanset hvad du gør og uanset hvor trist det er.
Hver deltager i processen i virksomheden: backend- og frontend-udviklere, test, DBA, drift, netværk, graver i deres egen retning, og ingen har et fælles kort undtagen lederen, som på en eller anden måde overvåger dem og administrerer dem ved hjælp af "opdelingen" og erobre” metode.
Folk kæmper for nogle stjerner eller flag, alle graver efter deres ekspertise.
Som et resultat, når opgaven opstår med at forbinde alt dette sammen og bygge en fælles pipeline, og der ikke længere er behov for at kæmpe om stjerner og flag, opstår spørgsmålet - hvad skal man så gøre? Vi skal på en eller anden måde nå til enighed, men ingen har lært os, hvordan man gør det her i skolen. Vi er blevet undervist siden skolen: ottende klasse - wow! - sammenlignet med syvende klasse! Det er det samme her.
Er det det samme i din virksomhed?
For at kontrollere dette kan du stille dig selv følgende spørgsmål.
Bruger teams fælles værktøjer og bidrager til ændringer af disse fælles værktøjer?
Hvor ofte omorganiseres teams – nogle specialister fra et team flytter til et andet team? Det er i et DevOps-miljø, at dette bliver normalt, for nogle gange kan en person simpelthen ikke forstå, hvad et andet ekspertiseområde laver. Han flytter til en anden afdeling, arbejder der i to uger for at skabe sig et kort over orientering og interaktion med denne afdeling.
Er det muligt at danne et forandringsudvalg og ændre tingene? Eller kræver det den stærke hånd fra den højeste ledelse og retning? Jeg skrev for nylig på Facebook, hvordan en lidet kendt bank implementerer værktøjer gennem ordrer: vi skriver en ordre, vi implementerer den i et år og ser, hvad der sker. Dette er selvfølgelig langt og trist.
Hvor vigtigt er det for ledere at modtage personlige resultater uden at tage hensyn til virksomhedens resultater?
Svarer du selv på disse spørgsmål, bliver det tydeligere, om du har et sådant problem i din virksomhed.
Infrastruktur som kode
Efter dette problem er bestået, er den første vigtige praksis, uden hvilken det er svært at komme videre i DevOps infrastruktur som kode.
Oftest opfattes infrastruktur som kode som følger:
— Lad os automatisere alt i bash, dække os selv med scripts, så administratorer har mindre manuelt arbejde!
Men det er ikke sandt.
Infrastruktur som kode betyder, at man beskriver det IT-system man arbejder med i form af kode for hele tiden at forstå dets tilstand.
Sammen med andre teams laver I et kort i form af kode, som alle kan forstå og kan navigere og navigere. Det er lige meget, hvad det er lavet på - Chef, Ansible, Salt eller brug af YAML-filer i Kubernetes - der er ingen forskel.
På konferencen fortalte en kollega fra 2GIS, hvordan de lavede deres egen interne ting til Kubernetes, som beskriver opbygningen af individuelle systemer. For at beskrive 500 systemer havde de brug for et separat værktøj, der genererer denne beskrivelse. Når der er denne beskrivelse, kan alle tjekke med hinanden, overvåge ændringer, hvordan man ændrer det og forbedrer det, hvad der mangler.
Enig, individuelle bash-scripts giver normalt ikke denne forståelse. I en af de virksomheder, hvor jeg arbejdede, var der endda et navn for "skriv kun" manuskript - når manuskriptet er skrevet, men det ikke længere er muligt at læse det. Det tror jeg også er bekendt for dig.
Infrastruktur som kode er kode, der beskriver den aktuelle tilstand af infrastrukturen. Mange produkt-, infrastruktur- og serviceteams arbejder sammen om denne kode, og vigtigst af alt skal de alle forstå, hvordan denne kode rent faktisk fungerer.
Kodekset vedligeholdes i overensstemmelse med bedste kodekspraksis: fælles udvikling, kodegennemgang, XP-programmering, test, pull requests, CI til kodeinfrastrukturer - alt dette er velegnet og kan bruges.
Kode bliver et fælles sprog for alle ingeniører.
Ændring af infrastruktur i kode tager ikke meget tid. Ja, infrastrukturkode kan også have teknisk gæld. Normalt støder teams på det halvandet år efter, at de begyndte at implementere "infrastruktur som kode" i form af en masse scripts eller endda Ansible, som de skriver som spaghetti-kode, og de kaster også bash-scripts ind i blandingen!
Det er vigtigt: Hvis du ikke har prøvet disse ting endnu, så husk det Ansible er ikke bash! Læs dokumentationen grundigt, studer hvad de skriver om den.
Infrastruktur som kode er adskillelsen af infrastrukturkode i separate lag.
I vores virksomhed skelner vi mellem 3 grundlag, som er meget klare og enkle, men der kan være flere af dem. Du kan se på din infrastrukturkode og fortælle, om du har denne tilstand eller ej. Hvis ingen lag er fremhævet, så skal du tage dig tid og revurdere lidt.
Baselag - sådan er OS, sikkerhedskopier og andre lavniveau-ting konfigureret, for eksempel hvordan Kubernetes er installeret på basisniveau.
Serviceniveau - disse er de tjenester, du leverer til udvikleren: logning som en tjeneste, overvågning som en tjeneste, database som en tjeneste, balancer som en tjeneste, kø som en tjeneste, Kontinuerlig levering som en tjeneste - en masse tjenester, som individuelle teams kan bidrage til udvikling. Alt dette skal beskrives i separate moduler i dit konfigurationsstyringssystem.
Laget, hvor applikationerne laves og beskriver, hvordan de vil udfolde sig oven på de to foregående lag.
Kontrolspørgsmål
Har din virksomhed et fælles infrastrukturlager? Styrer du teknisk gæld i din infrastruktur? Bruger du udviklingspraksis i et infrastrukturlager? Er din infrastruktur skåret op i lag? Du kan tjekke Base-service-APP-diagrammet. Hvor svært er det at lave en forandring?
Har du oplevet, at det tog halvanden dag at lave ændringer, betyder det, at du har teknisk gæld og skal arbejde med det. Du er lige faldet over en teknisk gældsoptagelse i din infrastrukturkode. Jeg husker mange sådanne historier, når man for at ændre noget CCTL skal omskrive halvdelen af infrastrukturkoden, fordi kreativitet og ønsket om at automatisere alt førte til, at alt er tæret overalt, alle håndtag er blevet fjernet, og det er nødvendigt at refaktorere.
Kontinuerlig levering
Lad os sammenligne debet med kredit. Først kommer en beskrivelse af infrastrukturen, som kan være ret basal. Du behøver ikke at beskrive alt i detaljer, men der kræves en grundlæggende beskrivelse, så du kan arbejde med det. Ellers er det ikke klart, hvad man skal gøre med kontinuerlig levering. Alle disse praksisser udfolder sig samtidigt, når du kommer til DevOps, men det starter med at forstå, hvad du har, og hvordan du administrerer det. Dette er netop praksis med infrastruktur som kode.
Når det bliver klart, at du har det, og hvordan du administrerer det, begynder du at finde ud af, hvordan du sender udviklerkoden til produktion så hurtigt som muligt. Jeg mener sammen med udvikleren - vi husker problemet med "brønde", det vil sige, det er ikke individuelle mennesker, der kommer med dette, men et team.
Når vi er med Vanya Evtukhovich så den første bog Jez Humble og grupper af forfattere "Kontinuerlig levering", som blev udgivet i 2009, tænkte vi længe på, hvordan vi skulle oversætte dens titel til russisk. De ønskede at oversætte det til "Konstant levering", men desværre blev det oversat til "Kontinuerlig levering". Det forekommer mig, at der er noget russisk i vores navn, med pres.
Konstant levering betyder
Kode, der er i produktlageret, kan altid downloades til produktion. Han er måske ikke deflateret, men han er altid klar til det. Derfor skriver du altid kode med en svær at forklare følelse af angst under halebenet. Det dukker ofte op, når du udruller infrastrukturkode. Denne følelse af en vis angst burde være til stede – den udløser hjerneprocesser, der gør, at du kan skrive kode lidt anderledes. Dette bør registreres i reglerne inden for udviklingen.
For at kunne levere konsekvent har du brug for et artefaktformat, der kører på tværs af en infrastrukturplatform. Hvis du smider "livspild" af forskellige formater hen over en infrastrukturplatform, så bliver det samlet, det er svært at vedligeholde, og problemet med teknisk gæld opstår. Artefaktens format skal tilpasses - dette er også en kollektiv opgave: Vi skal alle sammen, rasle i vores hjerner og finde på dette format.
Artefaktet forbedres løbende og ændres, så det passer til produktionsmiljøet, når det bevæger sig gennem leveringspipelinen. Når en artefakt bevæger sig langs rørledningen, støder den konstant på nogle ubekvemme ting for den, som ligner det, som artefakten, du sætter i produktionen, støder på. Hvis dette i klassisk udvikling udføres af en systemadministrator, der udfører udrulningen, så sker det i DevOps-processen hele tiden: her testede de det med nogle tests, her smed de det ind i en Kubernetes-klynge, som er mere eller mindre ens. til produktion, så begyndte de pludselig at teste belastningen.
Dette minder lidt om Pac-Man-spillet - artefaktet går igennem en form for historie. Samtidig er det vigtigt at kontrollere, om koden rent faktisk går igennem historien, og om den på en eller anden måde er relateret til din produktion. Historier fra produktionen kan trækkes ind i Continuous Delivery-processen: det var sådan, da noget faldt, lad os nu bare programmere dette scenarie inde i systemet. Hver gang vil koden også gennemgå dette scenarie, og du vil ikke støde på dette problem næste gang. Du vil lære om det meget tidligere, end det når din klient.
Forskellige implementeringsstrategier. For eksempel bruger du AB-test eller kanarie-implementeringer til at teste koden forskelligt på forskellige klienter, få information om hvordan koden fungerer og meget tidligere, end når den er rullet ud til 100 millioner brugere.
"Konsekvent leverer" ser sådan ud.
Leveringsprocessen Dev, CI, Test, PreProd, Prod er ikke et separat miljø, disse er stadier eller stationer med brandsikre summer, som din artefakt passerer igennem.
Hvis du har infrastrukturkode, der er beskrevet som Base Service APP, så hjælper det glem ikke alle scripts, og skriv dem ned som kode for denne artefakt, fremme artefakter og ændre det, mens du går.
Selvtest spørgsmål
Tiden fra funktionsbeskrivelse til frigivelse i produktion er i 95 % af tilfældene mindre end en uge? Bliver kvaliteten af artefakten forbedret i hvert trin af rørledningen? Er der en historie, den går igennem? Bruger du forskellige implementeringsstrategier?
Hvis alle svarene er ja, så er du utrolig sej! Skriv dine svar i kommentarerne - jeg bliver glad).
Kontakt os
Dette er den sværeste praksis af alle. På DevOpsConf-konferencen var en kollega fra Infobip, der talte om det, lidt forvirret i sine ord, fordi dette virkelig er en meget kompleks praksis omkring det faktum, at du skal overvåge alt!
For eksempel for lang tid siden, da jeg arbejdede hos Qik, og vi indså, at vi skulle overvåge alt. Det gjorde vi, og vi har nu 150 varer i Zabbix, som konstant overvåges. Det var skræmmende, den tekniske direktør vred fingeren i tindingen:
- Gutter, hvorfor voldtager I serveren med noget uklart?
Men så skete der en hændelse, der viste, at dette virkelig er en meget cool strategi.
En af tjenesterne begyndte at gå ned konstant. I starten gik den ikke ned, hvilket er interessant, koden blev ikke tilføjet der, fordi det var en grundlæggende mægler, som praktisk talt ikke havde nogen forretningsfunktionalitet - den sendte simpelthen beskeder mellem individuelle tjenester. Tjenesten ændrede sig ikke i 4 måneder, og pludselig begyndte den at gå ned med fejlen "Segmenteringsfejl".
Vi var chokerede, åbnede vores diagrammer i Zabbix, og det viste sig, at for halvanden uge siden ændrede adfærden for anmodninger i API-tjenesten, som denne mægler bruger, sig meget. Dernæst så vi, at hyppigheden af at sende en bestemt type besked var ændret. Senere fandt vi ud af, at det var Android-klienter. Vi spurgte:
– Gutter, hvad skete der med jer for halvanden uge siden?
Som svar hørte vi en interessant historie om, hvordan de havde redesignet brugergrænsefladen. Det er usandsynligt, at nogen straks vil sige, at de har ændret HTTP-biblioteket. For Android-klienter er det som at skifte sæbe på badeværelset - de kan bare ikke huske det. Som et resultat, efter 40 minutters samtale, fandt vi ud af, at de havde ændret HTTP-biblioteket, og dets standardtidspunkter var ændret. Dette førte til, at trafikadfærden på API-serveren ændrede sig, hvilket førte til en situation, der forårsagede et kapløb i mægleren, og det begyndte at gå ned.
Uden dyb overvågning er det generelt umuligt at åbne denne. Hvis organisationen stadig har problemet med "brønde", når alle smider penge efter hinanden, kan dette leve i årevis. Du genstarter simpelthen serveren, fordi det er umuligt at løse problemet. Når du overvåger, sporer, sporer alle de hændelser, du har, og bruger overvågning som test - skriver kode og med det samme angiver, hvordan den skal overvåges, også i form af kode (vi har allerede infrastrukturen som kode), bliver alt klart, hvordan på håndfladen. Selv sådanne komplekse problemer spores let.
Indsaml al information om, hvad der sker med artefakten på hvert trin af leveringsprocessen - ikke i produktionen.
Upload overvågningen til CI, og nogle grundlæggende ting vil allerede være synlige der. Senere vil du se dem i Test, PredProd og belastningstest. Indsaml information på alle stadier, ikke kun målinger, statistikker, men også logfiler: hvordan applikationen rullede ud, uregelmæssigheder - saml alt.
Ellers bliver det svært at finde ud af det. Jeg har allerede sagt, at DevOps er mere kompleks. For at klare denne kompleksitet skal du have normale analyser.
Spørgsmål til selvkontrol
Er din overvågning og logning udviklingsværktøjet noget for dig? Når du skriver kode, tænker dine udviklere, inklusive dig, over, hvordan man overvåger den?
Hører du om problemer fra kunder? Forstår du kunden bedre fra overvågning og logning? Forstår du systemet bedre fra overvågning og logning? Ændrer du systemet, blot fordi du så, at tendensen i systemet vokser, og du forstår, at om yderligere 3 uger vil alt dø?
Når du har disse tre komponenter, kan du tænke over, hvilken slags infrastrukturplatform du har i din virksomhed.
Infrastruktur platform
Pointen er ikke, at det er et sæt forskellige værktøjer, som enhver virksomhed har.
Pointen med en infrastrukturplatform er, at alle teams bruger disse værktøjer og udvikler dem sammen.
Det er klart, at der er separate teams, der er ansvarlige for udviklingen af individuelle dele af infrastrukturplatformen. Men samtidig bærer enhver ingeniør ansvar for udvikling, ydeevne og promovering af infrastrukturplatformen. På det indre plan bliver det et fælles værktøj.
Alle teams udvikler infrastrukturplatformen og behandler den med omhu som deres egen IDE. I din IDE installerer du forskellige plugins for at gøre alting pænt og hurtigt, og konfigurerer genvejstaster. Når du åbner Sublime, Atom eller Visual Studio Code, strømmer kodefejl ind, og du indser, at det overhovedet er umuligt at arbejde, du føler dig straks trist, og du løber for at reparere din IDE.
Behandl din infrastrukturplatform på samme måde. Hvis du forstår, at der er noget galt med det, så læg en anmodning, hvis du ikke selv kan rette det. Hvis der er noget simpelt, rediger det selv, send en pull-anmodning, fyrene vil overveje det og tilføje det. Dette er en lidt anderledes tilgang til tekniske værktøjer i udviklerens hoved.
Infrastrukturplatformen sikrer overførsel af artefakten fra udvikling til klienten med løbende kvalitetsforbedring. IP'en er programmeret med et sæt historier, der sker med koden i produktionen. Gennem årenes udvikling er der mange af disse historier, nogle af dem er unikke og relaterer sig kun til dig - de kan ikke Googles.
På dette tidspunkt bliver infrastrukturplatformen din konkurrencefordel, fordi den har noget indbygget, som ikke er i konkurrentens værktøj. Jo dybere din IP, jo større er din konkurrencefordel i forhold til Time-to-market. Vises her leverandørlås problem: Du kan tage en andens platform, men ved at bruge en andens erfaring, vil du ikke forstå, hvor relevant det er for dig. Ja, ikke alle virksomheder kan bygge en platform som Amazon. Det er en svær linje, hvor virksomhedens erfaring er relevant for dens position på markedet, og du kan ikke bruge en leverandørlås der. Dette er også vigtigt at tænke over.
Ordningen
Dette er et grundlæggende diagram over en infrastrukturplatform, der hjælper dig med at opsætte al praksis og processer i en DevOps-virksomhed.
Lad os se på, hvad det består af.
Ressource orkestreringssystem, som leverer CPU, hukommelse, disk til applikationer og andre tjenester. Oven i købet - tjenester på lavt niveau: overvågning, logning, CI/CD Engine, artefaktlagring, infrastruktur som systemkode.
Tjenester på højere niveau: database som en service, køer som en service, Load Balance som en service, billedstørrelse som en service, Big Data fabrik som en service. Oven i købet - pipeline, der leverer konstant ændret kode til din klient.
Du modtager information om, hvordan din software fungerer for klienten, ændrer den, leverer denne kode igen, modtager information - og så udvikler du hele tiden både infrastrukturplatformen og din software.
I diagrammet består leveringsrørledningen af mange trin. Men dette er et skematisk diagram, der er givet som et eksempel - det er ikke nødvendigt at gentage det én efter én. Stadier interagerer med tjenester, som om de var tjenester - hver klods på platformen bærer sin egen historie: hvordan ressourcer allokeres, hvordan applikationen lanceres, arbejder med ressourcer, overvåges og ændres.
Det er vigtigt at forstå, at hver del af platformen rummer en historie, og spørg dig selv, hvilken historie denne klods bærer, måske skal den smides ud og erstattes med en tredjepartstjeneste. Er det for eksempel muligt at installere Okmeter i stedet for en mursten? Måske har fyrene allerede udviklet denne ekspertise meget mere, end vi har. Men måske ikke – måske har vi en unik ekspertise, vi skal installere Prometheus og udvikle den yderligere.
Oprettelse af platformen
Dette er en kompleks kommunikationsproces. Når du har grundlæggende praksis, starter du kommunikation mellem forskellige ingeniører og specialister, der udvikler krav og standarder, og ændrer dem konstant til forskellige værktøjer og tilgange. Den kultur, vi har i DevOps, er vigtig her.
Med kultur er alt meget enkelt - det handler om samarbejde og kommunikation, det vil sige ønsket om at arbejde i et fælles felt med hinanden, ønsket om at bruge ét instrument sammen. Der er ingen raketvidenskab her - alt er meget enkelt, banalt. For eksempel bor vi alle i entréen og holder den ren – sådan et kulturniveau.
Hvad har du?
Igen, spørgsmål, du kan stille dig selv.
Er infrastrukturplatformen dedikeret? Hvem er ansvarlig for dens udvikling? Forstår du de konkurrencemæssige fordele ved din infrastrukturplatform?
Du skal konstant stille dig selv disse spørgsmål. Hvis noget kan overføres til tredjepartstjenester, skal det overføres; hvis en tredjepartstjeneste begynder at blokere din bevægelse, skal du bygge et system i dig selv.
Så DevOps...
... dette er et komplekst system, det skal have:
- Digitalt produkt.
- Forretningsmoduler, der udvikler dette digitale produkt.
- Produktteams, der skriver kode.
- Løbende leveringspraksis.
- Platforme som en service.
- Infrastruktur som en service.
- Infrastruktur som kode.
- Separat praksis for opretholdelse af pålidelighed, indbygget i DevOps.
- En feedbackpraksis, der beskriver det hele.
Du kan bruge dette diagram og fremhæve i det, hvad du allerede har i din virksomhed i en eller anden form: er det udviklet eller stadig skal udvikles.
Det er overstået om et par uger . som en del af RIT++. Kom til konferencen, hvor du finder mange fede rapporter om kontinuerlig levering, infrastruktur som kode og DevOps transformation. , sidste prisdeadline er 20. maj
Kilde: www.habr.com