Definisjonen av DevOps er veldig kompleks, så vi må starte diskusjonen om det på nytt hver gang. Det er tusen publikasjoner om dette emnet på Habré alene. Men hvis du leser dette, vet du sannsynligvis hva DevOps er. For det er jeg ikke. Hei mitt navn er Alexander Titov (@), og vi skal bare snakke om DevOps og jeg deler min erfaring.
Jeg har lenge tenkt på hvordan jeg skal gjøre historien min nyttig, så det vil være mange spørsmål her - de jeg stiller meg selv og de jeg stiller til våre kunder. Ved å svare på disse spørsmålene blir forståelsen bedre. Jeg vil fortelle deg hvorfor DevOps er nødvendig fra mitt synspunkt, hva det er, igjen, fra mitt synspunkt, og hvordan du forstår at du beveger deg mot DevOps igjen fra mitt synspunkt. Det siste punktet vil være gjennom spørsmål. Ved å svare på dem selv, kan du forstå om bedriften din beveger seg mot DevOps eller om det er problemer på en eller annen måte.
En gang red jeg på bølgene av fusjoner og oppkjøp. Først jobbet jeg for en liten startup som het Qik, så ble den kjøpt av et litt større selskap som heter Skype, som så ble kjøpt av et litt større selskap som heter Microsoft. I det øyeblikket begynte jeg å se hvordan ideen om DevOps forvandlet seg i selskaper i forskjellige størrelser. Etter det ble jeg interessert i å se på DevOps fra et markedssynspunkt, og kollegene mine og jeg grunnla selskapet Express 42. I 6 år nå har vi beveget oss langs markedets bølger.
Jeg er blant annet en av arrangørene av DevOps Moscow-fellesskapet og arrangøren av DevOps-Days 2017, men jeg arrangerte ikke 2018. Express 42 jobber med mange selskaper. Vi dyrker DevOps der, ser på hvordan det skjer, trekker konklusjoner, analyserer, forteller alle våre konklusjoner og trener folk i DevOps-praksis. Generelt gjør vi vårt beste for å øke vår erfaring og ekspertise i denne forbindelse.
Hvorfor DevOps
Det første spørsmålet som hjemsøker alle og alltid er - hvorfor? Mange tror at DevOps bare er automatisering eller en lignende ting som alle selskap allerede hadde.
— Vi hadde kontinuerlig integrasjon – dette betyr at vi allerede hadde DevOps, og hvorfor trengs alt dette? De har det gøy i utlandet, men de hindrer oss i å jobbe!
Over 9 år med utvikling av fellesskapet og metodikken har det allerede blitt klart at dette fortsatt ikke er markedsføringsglitter, men det er fortsatt ikke helt klart hvorfor det trengs. Som alle verktøy og prosesser har DevOps spesifikke mål som den til slutt oppnår.
Alt dette skyldes det faktum at verden er i endring. Han beveger seg bort fra enterprise-tilnærmingen, når selskaper beveger seg rett mot en drøm, som vår St. Petersburg-klassiker sang, fra punkt A til punkt B i henhold til en bestemt strategi, med en bestemt struktur bygget for dette.
I prinsippet skal alt innen IT bygges etter denne tilnærmingen. Her brukes IT utelukkende til å automatisere prosesser.
Automatisering endres ikke ofte, for når en bedrift går ned i et opptråkket spor, hva er det å endre? Det fungerer – ikke rør det. Nå er tilnærmingene i verden i endring, og den som heter Agile antyder at endepunkt B ikke er umiddelbart synlig.
Når et selskap går gjennom markedet, jobber med en klient, utforsker det hele tiden markedet og endrer endepunkt B. Dessuten, jo oftere selskapet endrer retning, jo mer vellykket er det til slutt, fordi det velger mer marked nisjer.
Strategien er demonstrert av et interessant selskap som jeg nylig lærte om. One Box Shave er en abonnementsleveringstjeneste for barberhøvler og barbertilbehør i boks. De vet hvordan de skal tilpasse "boksen" for forskjellige kunder. Dette gjøres av en bestemt programvare, som deretter sender bestillingen til den koreanske fabrikken som produserer varene.
Dette produktet ble kjøpt av Unilever for 1 milliard dollar. Den konkurrerer nå med Gillette og har tatt bort en betydelig andel av forbrukerne på det amerikanske markedet. One Box Shave sier:
— 4 kniver? Er du seriøst? Hvorfor trenger du dette - det forbedrer ikke kvaliteten på barberingen. En spesielt utvalgt krem, duft og en høykvalitets barberhøvel med to blader løser mye flere problemer enn de dumme 4 Gillette-bladene! Kommer vi til 10 snart?
Slik forandrer verden seg. Unilever hevder at de har et kult IT-system som lar deg gjøre dette. Til slutt ser det ut som et konsept Time-to-market, som ingen allerede har snakket om.
Poenget med Time-to-market er ikke hvor ofte vi distribuerer. Du kan ofte distribuere, men utgivelsessyklusene vil være lange. Hvis tre-måneders utgivelsessykluser legges over hverandre, og skifter dem med en uke, viser det seg at selskapet ser ut til å distribuere en gang i uken. Og fra idé til endelig implementering tar det 3 måneder.
Time-to-market handler om å minimere tiden fra idé til endelig implementering.
I dette tilfellet samhandler programvare med markedet. Dette er hvordan One Box Shave-nettstedet samhandler med klienten. De har ikke selgere – bare en nettside hvor besøkende klikker og legger igjen ønsker. Følgelig må noe nytt hele tiden legges ut på siden og oppdateres i henhold til ønsker. For eksempel, i Sør-Korea barberer de seg annerledes enn i Russland, og de liker duften ikke av furu, men for eksempel av gulrøtter og vanilje.
Siden det er nødvendig å raskt endre innholdet på nettstedet, endrer programvareutvikling seg mye. Gjennom programvare må vi finne ut hva kunden ønsker. Tidligere har vi lært dette gjennom noen rundkjøringer, for eksempel gjennom virksomhetsstyring. Så designet vi det, satte kravene inn i IT-systemet, og alt var kult. Nå er det annerledes – programvare er designet av alle som er involvert i prosessen, inkludert ingeniører, fordi de gjennom tekniske spesifikasjoner lærer hvordan markedet fungerer og deler også sin innsikt med virksomheten.
For eksempel, på Qik lærte vi plutselig at folk virkelig likte å laste opp kontaktlister til serveren, og de forsynte oss med en applikasjon. Til å begynne med tenkte vi ikke på det. I et klassisk selskap ville alle ha bestemt at dette var en feil, siden spesifikasjonen ikke sa at det skulle fungere bra og generelt ble implementert på kneet, ville de ha slått av funksjonen og sagt: "Ingen trenger dette, det viktigste er at hovedfunksjonaliteten fungerer.” . Og teknologiselskapet ser på dette som en mulighet og begynner å endre programvaren i samsvar med dette.
I 1968 formulerte en visjonær fyr, Melvin Conway, følgende idé.
Organisasjonen som skaper systemet er begrenset av et design som replikerer den organisasjonens kommunikasjonsstruktur.
Mer detaljert, for å produsere systemer av en annen type, må man også ha en kommunikasjonsstruktur i en bedrift av en annen type. Hvis kommunikasjonsstrukturen din er topp-hierarkisk, vil dette ikke tillate deg å lage systemer som kan gi en veldig høy Time-to-Market-indikator.
ære man kan . Det er viktig for å forstå DevOps-kulturen eller -filosofien fordi det eneste som fundamentalt endrer seg i DevOps er strukturen for kommunikasjon mellom team.
Fra et prosesssynspunkt, før DevOps, var alle stadier: analyse, utvikling, testing, drift lineære.
Når det gjelder DevOps, skjer alle disse prosessene samtidig.
Time-to-market er den eneste måten det kan gjøres på. For folk som jobbet i den gamle prosessen, ser dette noe kosmisk ut, og generelt så som så.
Så hvorfor trenger du DevOps?
For digital produktutvikling. Hvis din bedrift ikke har et digitalt produkt, er ikke DevOps nødvendig – det er veldig viktig.
DevOps overvinner hastighetsbegrensningene ved sekvensiell programvareproduksjon. I den foregår alle prosesser samtidig.
Vanskeligheten øker. Når DevOps-evangelister forteller deg at det vil gjøre det lettere for deg å gi ut programvare, er dette tull.
Med DevOps vil ting bare bli mer komplisert.
På konferansen på Avito-standen kunne du se hvordan det var å distribuere en Docker-container – en urealistisk oppgave. Kompleksiteten blir uoverkommelig, du må sjonglere med mange baller samtidig.
DevOps endrer prosessen og organiseringen i selskapet fullstendig — mer presist er det ikke DevOps som endrer seg, men det digitale produktet. For å komme til DevOps, må du fortsatt endre denne prosessen fullstendig.
Spørsmål til en spesialist
Hva har du? Spørsmål du kan stille deg selv mens du jobber i en bedrift og utvikler deg som spesialist.
Har du en strategi for å lage et digitalt produkt? Hvis det er det, er det allerede bra. Dette betyr at bedriften din beveger seg mot DevOps.
Lager din bedrift allerede et digitalt produkt? Dette betyr at du kan stige enda et nivå høyere og gjøre ting mer interessant – igjen fra et DevOps-synspunkt. Jeg snakker bare fra dette synspunktet.
Er din bedrift en av markedslederne innen den digitale produktnisjen? Spotify, Yandex, Uber er selskaper som er på toppen av teknologisk fremgang nå.
Still deg selv disse spørsmålene, og hvis alle svarene er nei, bør du kanskje ikke gjøre DevOps hos dette selskapet. Hvis temaet DevOps virkelig er interessant for deg, bør du kanskje flytte til et annet selskap? Hvis bedriften din ønsker å gå inn i DevOps, men du svarte «Nei» på alle spørsmålene, så er det som et vakkert neshorn som aldri vil endre seg.
Organisasjon
Som jeg sa, i henhold til Conways lov endres organiseringen av et selskap. Jeg starter med det som hindrer DevOps i å trenge inn i selskapet fra et organisatorisk synspunkt.
Problemet med "brønner"
Det engelske ordet "Silo" er her oversatt til russisk som "vel". Poenget med dette problemet er det det er ingen utveksling av informasjon mellom lag. Hvert team graver dypt i sin ekspertise, uten å bygge et felles kart for å navigere.
På noen måter minner dette meg om en person som nettopp har ankommet Moskva og ennå ikke vet hvordan man navigerer på metrokartet. Muskovitter kjenner vanligvis området sitt veldig godt, og i hele Moskva kan de navigere ved hjelp av metrokartet. Når du kommer til Moskva for første gang, har du ikke denne ferdigheten, og du er bare desorientert.
DevOps foreslår å komme seg gjennom dette øyeblikket av desorientering og at alle avdelinger jobber sammen for å bygge et felles interaksjonskart.
To faktorer hindrer dette.
Konsekvens av bedriftens styringssystem. Den er bygget i separate hierarkiske "brønner". For eksempel er det visse KPIer i selskaper som støtter dette systemet. På den annen side kommer hjernen til en person som synes det er vanskelig å gå utover ekspertisens grenser og navigere i hele systemet i veien. Det er bare ubehagelig. Tenk deg at du er på flyplassen i Bangkok - du vil ikke finne veien raskt rundt. DevOps er også vanskelig å navigere i, og det er derfor folk sier at du må finne en guide for å komme dit.
Men det viktigste er at problemet med "brønner" for en ingeniør som er gjennomsyret av DevOps-ånden, har lest Fowler og en haug med andre bøker, kommer til uttrykk i det faktum at "brønner" lar deg ikke gjøre "åpenbare" ting. Vi kommer ofte sammen etter DevOps Moskva, snakker med hverandre, og folk klager:
— Vi ville bare lansere CI, men det viste seg at ledelsen ikke trengte det.
Dette skjer nettopp fordi CI и Kontinuerlig leveringsprosess er på grensen til mange eksamener. Rett og slett uten å overvinne problemet med "brønner" på organisasjonsnivå, vil du ikke kunne komme deg videre, uansett hva du gjør og uansett hvor trist det er.
Hver deltaker i prosessen i selskapet: backend- og frontend-utviklere, testing, DBA, drift, nettverk, graver i sin egen retning, og ingen har et felles kart bortsett fra lederen, som på en eller annen måte overvåker dem og administrerer dem ved å bruke "divide" og erobre»-metoden.
Folk kjemper om noen stjerner eller flagg, alle graver ekspertisen sin.
Som et resultat, når oppgaven oppstår med å koble alt dette sammen og bygge en felles rørledning, og det ikke lenger er behov for å kjempe om stjerner og flagg, oppstår spørsmålet - hva skal man gjøre likevel? Vi må komme til enighet på en eller annen måte, men ingen har lært oss hvordan vi gjør dette på skolen. Vi har blitt undervist siden skolen: åttende klasse - wow! – sammenlignet med syvende klasse! Det er det samme her.
Er det det samme i din bedrift?
For å sjekke dette kan du stille deg selv følgende spørsmål.
Bruker team vanlige verktøy og bidrar til endringer i disse vanlige verktøyene?
Hvor ofte omorganiserer team – noen spesialister fra ett team flytter til et annet team? Det er i et DevOps-miljø dette blir normalt, fordi noen ganger kan en person rett og slett ikke forstå hva et annet ekspertiseområde gjør. Han flytter til en annen avdeling, jobber der i to uker for å lage selv et kart over orientering og samhandling med denne avdelingen.
Er det mulig å danne et endringsutvalg og endre ting? Eller krever det den sterke hånden til den høyeste ledelsen og retningen? Jeg skrev nylig på Facebook hvordan en lite kjent bank implementerer verktøy gjennom ordre: vi skriver en ordre, vi implementerer den i et år, og ser hva som skjer. Dette er selvfølgelig langt og trist.
Hvor viktig er det for ledere å motta personlige prestasjoner uten å ta hensyn til bedriftens prestasjoner?
Svarer du på disse spørsmålene for deg selv, vil det bli tydeligere om du har et slikt problem i din bedrift.
Infrastruktur som kode
Etter at dette problemet er bestått, er den første viktige praksisen, uten hvilken det er vanskelig å komme videre i DevOps infrastruktur som kode.
Oftest oppfattes infrastruktur som kode som følger:
— La oss automatisere alt i bash, dekke oss med skript slik at administratorer har mindre manuelt arbeid!
Men det er ikke sant.
Infrastruktur som kode betyr at man beskriver IT-systemet man jobber med i form av kode for hele tiden å forstå tilstanden.
Sammen med andre team lager du et kart i form av kode som alle kan forstå og kan navigere og navigere. Det spiller ingen rolle hva det er gjort på – Chef, Ansible, Salt eller bruk av YAML-filer i Kubernetes – det er ingen forskjell.
På konferansen fortalte en kollega fra 2GIS hvordan de laget sin egen interne greie for Kubernetes, som beskriver strukturen til individuelle systemer. For å beskrive 500 systemer trengte de et eget verktøy som genererer denne beskrivelsen. Når det er denne beskrivelsen kan alle sjekke med hverandre, overvåke endringer, hvordan endre det og forbedre det, hva som mangler.
Enig, individuelle bash-skript gir vanligvis ikke denne forståelsen. I et av selskapene der jeg jobbet, var det til og med et navn for "skrive bare" manus - når manuset er skrevet, men det er ikke lenger mulig å lese det. Jeg tror dette er kjent for deg også.
Infrastruktur som kode er kode som beskriver den nåværende tilstanden til infrastrukturen. Mange produkt-, infrastruktur- og serviceteam jobber sammen om denne koden, og viktigst av alt, de trenger alle å forstå hvordan denne koden faktisk fungerer.
Koden vedlikeholdes i henhold til beste praksis: felles utvikling, kodegjennomgang, XP-programmering, testing, pull requests, CI for kodeinfrastrukturer - alt dette er egnet og kan brukes.
Kode blir et felles språk for alle ingeniører.
Å endre infrastruktur i kode tar ikke mye tid. Ja, infrastrukturkode kan også ha teknisk gjeld. Vanligvis møter team det et og et halvt år etter at de begynte å implementere "infrastruktur som kode" i form av en haug med skript eller til og med Ansible, som de skriver som spaghettikode, og de kaster også bash-skript inn i blandingen!
Det er viktig: Hvis du ikke har prøvd disse tingene ennå, husk det Ansible er ikke bash! Les dokumentasjonen nøye, studer hva de skriver om den.
Infrastruktur som kode er separasjonen av infrastrukturkode i separate lag.
I vårt selskap skiller vi 3 grunnleggende lag, som er veldig klare og enkle, men det kan være flere av dem. Du kan se på infrastrukturkoden din og fortelle om du har denne tilstanden eller ikke. Hvis ingen lag er uthevet, må du ta deg tid og revidere litt.
grunnlag - dette er hvordan OS, sikkerhetskopier og andre lavnivå-ting er konfigurert, for eksempel hvordan Kubernetes er distribuert på basisnivå.
Service nivå - dette er tjenestene du leverer til utvikleren: logging som en tjeneste, overvåking som en tjeneste, database som en tjeneste, balansering som en tjeneste, kø som en tjeneste, Kontinuerlig levering som en tjeneste - en haug med tjenester som individuelle team kan bidra til utvikling. Alt dette må beskrives i separate moduler i ditt konfigurasjonsstyringssystem.
Laget der applikasjoner lages og beskriver hvordan de vil utfolde seg på toppen av de to foregående lagene.
Kontrollspørsmål
Har din bedrift et felles infrastrukturlager? Håndterer du teknisk gjeld i infrastrukturen din? Bruker du utviklingspraksis i et infrastrukturlager? Er infrastrukturen din delt opp i lag? Du kan sjekke Base-service-APP-diagrammet. Hvor vanskelig er det å gjøre en endring?
Har du opplevd at det tok halvannen dag å gjøre endringer, betyr det at du har teknisk gjeld og må jobbe med det. Du snublet nettopp over en teknisk gjeldsrake i infrastrukturkoden din. Jeg husker mange slike historier når du, for å endre noen CCTL, må skrive om halvparten av infrastrukturkoden, fordi kreativitet og ønsket om å automatisere alt førte til at alt er korrodert overalt, alle håndtakene er fjernet, og det er nødvendig å refaktorere.
Kontinuerlig levering
La oss sammenligne debet med kreditt. Først kommer en beskrivelse av infrastrukturen, som kan være ganske grunnleggende. Du trenger ikke å beskrive alt i detalj, men det kreves en grunnleggende beskrivelse slik at du kan jobbe med det. Ellers er det ikke klart hva man skal gjøre med kontinuerlig levering videre. Alle disse praksisene utspiller seg samtidig når du kommer til DevOps, men det starter med å forstå hva du har og hvordan du skal administrere det. Dette er nettopp praksisen med infrastruktur som kode.
Når det blir klart at du har det og hvordan du administrerer det, begynner du å finne ut hvordan du sender utviklerkoden til produksjon så raskt som mulig. Jeg mener sammen med utvikleren - vi husker problemet med "brønner", det vil si at det ikke er enkeltpersoner som kommer på dette, men et team.
Når vi er med Vanya Evtukhovich så den første boka Jez Humble og grupper av forfattere "Kontinuerlig levering", som ble utgitt i 2009, tenkte vi lenge på hvordan vi skulle oversette tittelen til russisk. De ønsket å oversette det som "Lever konstant", men dessverre ble det oversatt som "Kontinuerlig levering". Det virker på meg som det er noe russisk i navnet vårt, med press.
Stadig levere betyr
Kode som ligger i produktlageret kan alltid lastes ned til produksjon. Han er kanskje ikke deflatert, men han er alltid klar for det. Følgelig skriver du alltid kode med en vanskelig å forklare følelse av en viss angst under halebeinet. Det dukker ofte opp når du ruller ut infrastrukturkode. Denne følelsen av litt angst burde være tilstede – den setter i gang hjerneprosesser som lar deg skrive kode litt annerledes. Dette bør registreres i reglene innenfor utviklingen.
For å levere konsekvent, trenger du et artefaktformat som kjører på tvers av en infrastrukturplattform. Hvis du kaster "livsavfall" av forskjellige formater over en infrastrukturplattform, blir den enhetlig, den er vanskelig å vedlikeholde, og problemet med teknisk gjeld oppstår. Formatet til artefakten må justeres – dette er også en kollektiv oppgave: vi må alle komme sammen, rasle hjernen og komme opp med dette formatet.
Artefakten blir kontinuerlig forbedret og endres for å passe til produksjonsmiljøet når den beveger seg gjennom leveringsrørledningen. Når en artefakt beveger seg langs rørledningen, støter den hele tiden på noen upraktiske ting for den, som ligner på det artefakten du setter i produksjon møter. Hvis dette i klassisk utvikling gjøres av en systemadministrator som gjør utrullingen, så skjer dette hele tiden i DevOps-prosessen: her testet de det med noen tester, her kastet de det inn i en Kubernetes-klynge, som er mer eller mindre likt til produksjon, så begynte de plutselig å lastetesting .
Dette minner litt om Pac-Man-spillet – artefakten går gjennom en slags historie. Samtidig er det viktig å kontrollere om koden faktisk går gjennom historien og om den på en eller annen måte er relatert til produksjonen din. Historier fra produksjon kan dras inn i prosessen med kontinuerlig levering: det var slik da noe falt, la oss nå bare programmere dette scenariet inne i systemet. Hver gang vil koden også gå gjennom dette scenariet, og du vil ikke støte på dette problemet neste gang. Du vil finne ut om det mye tidligere enn det når kunden din.
Ulike distribusjonsstrategier. Du bruker for eksempel AB-testing eller kanarie-distribusjoner for å teste koden forskjellig på forskjellige klienter, få informasjon om hvordan koden fungerer, og mye tidligere enn når den rulles ut til 100 millioner brukere.
«Lever konsekvent» ser slik ut.
Leveringsprosessen Dev, CI, Test, PreProd, Prod er ikke et eget miljø, dette er etapper eller stasjoner med brannsikre summer som artefakten din passerer gjennom.
Hvis du har infrastrukturkode som er beskrevet som Base Service APP, hjelper det ikke glem alle skriptene, og skriv dem ned som kode for denne artefakten, fremme artefakter og endre det mens du går.
Selvtest spørsmål
Tiden fra funksjonsbeskrivelse til utgivelse i produksjon er i 95 % av tilfellene mindre enn en uke? Blir kvaliteten på artefakten bedre i hvert trinn av rørledningen? Er det en historie den går gjennom? Bruker du forskjellige distribusjonsstrategier?
Hvis alle svarene er ja, så er du utrolig kul! Skriv svarene dine i kommentarene - jeg blir glad).
Kontakt Oss
Dette er den vanskeligste praksisen av alle. På DevOpsConf-konferansen var en kollega fra Infobip, som snakket om det, litt forvirret i ordene sine, fordi dette egentlig er en veldig kompleks praksis om det faktum at du må overvåke alt!
For eksempel for lenge siden, da jeg jobbet i Qik og vi innså at vi måtte overvåke alt. Vi gjorde dette, og vi har nå 150 000 varer i Zabbix, som overvåkes kontinuerlig. Det var skummelt, teknisk direktør vred fingeren mot tinningen:
- Gutter, hvorfor voldtar dere serveren med noe uklart?
Men så skjedde det en hendelse som viste at dette virkelig er en veldig kul strategi.
En av tjenestene begynte å krasje hele tiden. I utgangspunktet krasjet den ikke, noe som er interessant, koden ble ikke lagt til der, fordi det var en grunnleggende megler, som praktisk talt ikke hadde noen forretningsfunksjonalitet - den sendte ganske enkelt meldinger mellom individuelle tjenester. Tjenesten endret seg ikke på 4 måneder, og plutselig begynte den å krasje med feilen "Segmenteringsfeil".
Vi ble sjokkert, åpnet diagrammene våre i Zabbix, og det viste seg at for en og en halv uke siden endret oppførselen til forespørsler i API-tjenesten som denne megleren bruker seg kraftig. Deretter så vi at frekvensen for å sende en bestemt type melding hadde endret seg. Senere fant vi ut at dette var android-klienter. Vi spurte:
– Gutter, hva skjedde med dere for halvannen uke siden?
Som svar hørte vi en interessant historie om hvordan de hadde redesignet brukergrensesnittet. Det er usannsynlig at noen umiddelbart vil si at de endret HTTP-biblioteket. For Android-klienter er det som å bytte såpe på badet - de husker det bare ikke. Som et resultat, etter 40 minutters samtale, fant vi ut at de hadde endret HTTP-biblioteket, og standardtidspunktene var endret. Dette førte til at trafikkatferden på API-serveren endret seg, noe som førte til en situasjon som forårsaket et løp i megleren, og det begynte å krasje.
Uten dyp overvåking er det generelt umulig å åpne denne. Hvis organisasjonen fortsatt har problemet med «brønner», når alle kaster penger på hverandre, kan dette leve i årevis. Du starter ganske enkelt serveren på nytt fordi det er umulig å løse problemet. Når du overvåker, sporer, sporer alle hendelsene du har, og bruker overvåking som testing - skriver kode og umiddelbart indikerer hvordan du skal overvåke den, også i form av kode (vi har allerede infrastrukturen som kode), blir alt klart hvordan på håndflaten. Selv slike komplekse problemer spores lett.
Samle all informasjon om hva som skjer med artefakten på hvert trinn av leveringsprosessen – ikke i produksjon.
Last opp overvåkingen til CI, og noen grunnleggende ting vil allerede være synlige der. Senere vil du se dem i Test, PredProd og lasttesting. Samle informasjon på alle stadier, ikke bare beregninger, statistikk, men også logger: hvordan applikasjonen rullet ut, anomalier - samle alt.
Ellers blir det vanskelig å finne ut av det. Jeg har allerede sagt at DevOps er mer komplekst. For å takle denne kompleksiteten, må du ha normal analyse.
Spørsmål for selvkontroll
Er din overvåking og logging utviklingsverktøyet for deg? Når du skriver kode, tenker utviklerne dine, inkludert deg, på hvordan de skal overvåke den?
Hører du om problemer fra kunder? Forstår du klienten bedre fra overvåking og logging? Forstår du systemet bedre fra overvåking og logging? Endrer du systemet rett og slett fordi du så at trenden i systemet vokser og du forstår at om 3 uker til vil alt dø?
Når du har disse tre komponentene, kan du tenke på hva slags infrastrukturplattform du har i din bedrift.
Infrastrukturplattform
Poenget er ikke at det er et sett med forskjellige verktøy som hver bedrift har.
Poenget med en infrastrukturplattform er at alle team bruker disse verktøyene og utvikler dem sammen.
Det er tydelig at det er egne team som er ansvarlige for utviklingen av individuelle deler av infrastrukturplattformen. Men samtidig har hver ingeniør ansvar for utvikling, ytelse og promotering av infrastrukturplattformen. På et internt nivå blir det et vanlig verktøy.
Alle team utvikler infrastrukturplattformen og behandler den med omhu som sin egen IDE. I din IDE installerer du forskjellige plugins for å gjøre alt fint og raskt, og konfigurerer hurtigtaster. Når du åpner Sublime, Atom eller Visual Studio Code, vises kodefeil der og du innser at det er umulig å jobbe i det hele tatt, du føler deg umiddelbart trist og løper for å fikse IDE.
Behandle infrastrukturplattformen din på samme måte. Hvis du forstår at det er noe galt med det, legg igjen en forespørsel hvis du ikke kan fikse det selv. Hvis det er noe enkelt, rediger det selv, send en pull-forespørsel, gutta vil vurdere det og legge det til. Dette er en litt annen tilnærming til ingeniørverktøy i utviklerens hode.
Infrastrukturplattformen sikrer overføring av artefakten fra utvikling til klient med kontinuerlig kvalitetsforbedring. IP-en er programmert med et sett med historier som skjer med koden i produksjon. Gjennom årene med utvikling er det mange av disse historiene, noen av dem er unike og relaterer seg bare til deg – de kan ikke Googles.
På dette tidspunktet blir infrastrukturplattformen ditt konkurransefortrinn, fordi den har noe innebygd som ikke er i konkurrentens verktøy. Jo dypere IP-adressen din er, desto større konkurransefortrinn når det gjelder Time-to-market. Vises her leverandørlåsproblem: Du kan ta andres plattform, men ved å bruke andres erfaring vil du ikke forstå hvor relevant det er for deg. Ja, ikke alle selskaper kan bygge en plattform som Amazon. Dette er en vanskelig linje der selskapets erfaring er relevant for dens posisjon i markedet, og du kan ikke bruke en leverandørlås der. Dette er også viktig å tenke på.
Ordningen
Dette er et grunnleggende diagram av en infrastrukturplattform som vil hjelpe deg med å sette opp all praksis og prosesser i et DevOps-selskap.
La oss se på hva den består av.
Ressursorkestreringssystem, som gir CPU, minne, disk til applikasjoner og andre tjenester. På toppen av dette - tjenester på lavt nivå: overvåking, logging, CI/CD-motor, artefaktlagring, infrastruktur som systemkode.
Tjenester på høyere nivå: database som en tjeneste, køer som en tjeneste, Load Balance som en tjeneste, bildestørrelse som en tjeneste, Big Data-fabrikk som en tjeneste. På toppen av dette - pipeline som leverer konstant modifisert kode til kunden din.
Du mottar informasjon om hvordan programvaren din fungerer for klienten, endrer den, oppgir denne koden igjen, mottar informasjon – og slik utvikler du hele tiden både infrastrukturplattformen og programvaren din.
I diagrammet består leveringsrørledningen av mange stadier. Men dette er et skjematisk diagram som er gitt som et eksempel - det er ikke nødvendig å gjenta det en etter en. Stadier samhandler med tjenester som om de var tjenester – hver kloss på plattformen har sin egen historie: hvordan ressurser tildeles, hvordan applikasjonen lanseres, arbeider med ressurser, overvåkes og endres.
Det er viktig å forstå at hver del av plattformen har en historie, og spør deg selv hvilken historie denne klossen bærer, kanskje den bør kastes og erstattes med en tredjepartstjeneste. Er det for eksempel mulig å installere Okmeter i stedet for en murstein? Kanskje har gutta allerede utviklet denne kompetansen mye mer enn vi har. Men kanskje ikke – kanskje har vi unik kompetanse, vi må installere Prometheus og utvikle den videre.
Opprettelse av plattformen
Dette er en kompleks kommunikasjonsprosess. Når du har grunnleggende praksis, starter du kommunikasjon mellom ulike ingeniører og spesialister som utvikler krav og standarder, og endrer dem hele tiden til ulike verktøy og tilnærminger. Kulturen vi har i DevOps er viktig her.
Med kultur er alt veldig enkelt - det handler om samarbeid og kommunikasjon, det vil si ønsket om å jobbe i et felles felt med hverandre, ønsket om å bruke ett instrument sammen. Det er ingen rakettvitenskap her - alt er veldig enkelt, banalt. For eksempel bor vi alle i inngangspartiet og holder det rent – et slikt kulturnivå.
Hva har du?
Igjen, spørsmål du kan stille deg selv.
Er infrastrukturplattformen dedikert? Hvem er ansvarlig for utviklingen? Forstår du konkurransefordelene til infrastrukturplattformen din?
Du må hele tiden stille deg selv disse spørsmålene. Hvis noe kan overføres til tredjepartstjenester, bør det overføres; hvis en tredjepartstjeneste begynner å blokkere bevegelsen din, må du bygge et system i deg selv.
Så, DevOps...
... dette er et komplekst system, det må ha:
- Digitalt produkt.
- Bedriftsmoduler som utvikler dette digitale produktet.
- Produktteam som skriver kode.
- Kontinuerlig leveringspraksis.
- Plattformer som en tjeneste.
- Infrastruktur som en tjeneste.
- Infrastruktur som kode.
- Separate praksiser for å opprettholde pålitelighet, innebygd i DevOps.
- En tilbakemeldingspraksis som beskriver det hele.
Du kan bruke dette diagrammet og fremheve det du allerede har i bedriften din i en eller annen form: har det utviklet seg eller fortsatt må utvikles.
Det går over om et par uker . som en del av RIT++. Kom på konferansen, hvor du finner mange kule rapporter om kontinuerlig levering, infrastruktur som kode og DevOps-transformasjon. , siste prisfrist er 20. mai
Kilde: www.habr.com