Definitionen av DevOps är mycket komplex, så vi måste börja diskussionen om det igen varje gång. Det finns tusen publikationer om detta ämne bara på Habré. Men om du läser detta vet du förmodligen vad DevOps är. För det är jag inte. Hej mitt namn är Alexander Titov (@), och vi ska bara prata om DevOps och jag delar med mig av min erfarenhet.
Jag har länge funderat på hur jag ska göra min berättelse användbar, så det kommer att finnas många frågor här - de som jag ställer till mig själv och de som jag ställer till vårt företags kunder. Genom att svara på dessa frågor blir förståelsen bättre. Jag kommer att berätta varför DevOps behövs ur min synvinkel, vad det är, igen, ur min synvinkel, och hur man förstår att du går mot DevOps igen ur min synvinkel. Den sista punkten kommer att vara genom frågor. Genom att själv svara på dem kan du förstå om ditt företag går mot DevOps eller om det finns problem på något sätt.
En gång red jag på vågorna av fusioner och förvärv. Först jobbade jag för en liten startup som heter Qik, sedan köptes den av ett lite större företag som heter Skype, som sedan köptes av ett lite större företag som heter Microsoft. I det ögonblicket började jag se hur idén om DevOps förändrades i företag av olika storlekar. Efter det blev jag intresserad av att titta på DevOps ur marknadssynpunkt och jag och mina kollegor grundade företaget Express 42. Sedan 6 år tillbaka har vi rört oss längs marknadens vågor.
Jag är bland annat en av arrangörerna av DevOps Moskva-gemenskapen och arrangören av DevOps-Days 2017, men jag organiserade inte 2018. Express 42 arbetar med många företag. Vi odlar DevOps där, ser hur det händer, drar slutsatser, analyserar, berättar våra slutsatser för alla och utbildar människor i DevOps-praxis. I allmänhet gör vi vårt bästa för att öka vår erfarenhet och expertis i detta avseende.
Varför DevOps
Den första frågan som förföljer alla och alltid är - varför? Många tror att DevOps bara är automatisering eller något liknande som alla företag redan hade.
— Vi hade kontinuerlig integration – det betyder att vi redan hade DevOps, och varför behövs allt det här? De har roligt utomlands, men de hindrar oss från att jobba!
Under 9 års utveckling av communityn och metodiken har det redan blivit tydligt att detta fortfarande inte är marknadsföringsglitter, men det är fortfarande inte helt klart varför det behövs. Som alla verktyg och processer har DevOps specifika mål som den i slutändan uppnår.
Allt detta beror på att världen förändras. Han går bort från företagsinriktningen, när företag går rakt mot en dröm, som vår S:t Petersburg-klassiker sjöng, från punkt A till punkt B enligt en viss strategi, med en viss struktur byggd för detta.
Allt inom IT ska i princip byggas enligt detta synsätt. Här används IT uteslutande för att automatisera processer.
Automatisering förändras inte ofta, för när ett företag går ner i ett vältrampat spår, vad finns det att ändra på? Det fungerar – rör det inte. Nu förändras tillvägagångssätten i världen, och den som kallas Agile antyder att slutpunkt B inte är omedelbart synlig.
När ett företag går igenom marknaden, arbetar med en kund, utforskar det hela tiden marknaden och ändrar slutpunkt B. Dessutom, ju oftare företaget ändrar riktning, desto mer framgångsrikt är det i slutändan, eftersom det väljer mer marknad nischer.
Strategin demonstreras av ett intressant företag som jag nyligen lärde mig om. One Box Shave är en prenumerationsleveranstjänst för rakhyvlar och raktillbehör i en låda. De vet hur man anpassar sin "låda" för olika kunder. Detta görs av en viss mjukvara, som sedan skickar beställningen till den koreanska fabriken som producerar produkten.
Denna produkt köptes av Unilever för 1 miljard dollar. Den konkurrerar nu med Gillette och har tagit bort en betydande andel av konsumenterna på den amerikanska marknaden. One Box Shave säger:
— 4 blad? Är du verkligen? Varför behöver du detta - det förbättrar inte kvaliteten på rakningen. En speciellt utvald kräm, doft och en högkvalitativ rakhyvel med två blad löser mycket fler problem än de där dumma 4 Gillette-bladen! Kommer vi till 10 snart?
Det är så världen förändras. Unilever hävdar att de har ett coolt IT-system som låter dig göra detta. I slutändan ser det ut som ett koncept Tid till marknaden, som ingen redan har pratat om.
Poängen med Time-to-market är inte hur ofta vi distribuerar. Du kan ofta distribuera, men utgivningscyklerna kommer att vara långa. Om tre månader långa utgivningscykler läggs över varandra och flyttar dem med en vecka, visar det sig att företaget tycks distribuera en gång i veckan. Och från idén till det slutliga genomförandet tar det 3 månader.
Time-to-market handlar om att minimera tiden från idé till slutgiltigt genomförande.
I det här fallet interagerar programvara med marknaden. Så här interagerar One Box Shave-webbplatsen med klienten. De har inga säljare – bara en webbplats där besökarna klickar och lämnar önskemål. Följaktligen måste något nytt ständigt läggas ut på sajten och uppdateras i enlighet med önskemål. Till exempel i Sydkorea rakar de sig annorlunda än i Ryssland, och de gillar doften inte av tall, utan till exempel av morötter och vanilj.
Eftersom det är nödvändigt att snabbt ändra innehållet på webbplatsen förändras mjukvaruutvecklingen kraftigt. Genom mjukvara måste vi ta reda på vad kunden vill ha. Tidigare har vi lärt oss detta genom några omvägar, till exempel genom företagsledning. Sedan designade vi det, satte kraven i IT-systemet och allt var coolt. Nu är det annorlunda – mjukvara är designad av alla som är involverade i processen, inklusive ingenjörer, för genom tekniska specifikationer lär de sig hur marknaden fungerar och delar även sina insikter med verksamheten.
Till exempel på Qik fick vi plötsligt veta att folk verkligen gillade att ladda upp kontaktlistor till servern, och de försåg oss med en applikation. Till en början tänkte vi inte på det. I ett klassiskt företag skulle alla ha bestämt sig för att detta var en bugg, eftersom specen inte sa att det skulle fungera bra och generellt implementerades på knäet, skulle de ha stängt av funktionen och sagt: "Ingen behöver det här, det viktigaste är att huvudfunktionaliteten fungerar.” . Och teknikföretaget ser detta som en möjlighet och börjar ändra mjukvaran i enlighet med detta.
1968 formulerade en visionär kille, Melvin Conway, följande idé.
Organisationen som skapar systemet är begränsad av en design som replikerar organisationens kommunikationsstruktur.
Närmare bestämt måste man för att få fram system av annan typ också ha en kommunikationsstruktur inom ett företag av en annan typ. Om din kommunikationsstruktur är topphierarkisk, kommer detta inte att tillåta dig att skapa system som kan ge en mycket hög Time-to-Market-indikator.
ära kan man . Det är viktigt för att förstå DevOps-kulturen eller -filosofin eftersom det enda som i grunden förändras i DevOps är strukturen för kommunikation mellan team.
Ur processsynpunkt, innan DevOps, var alla steg: analys, utveckling, testning, drift linjära.
När det gäller DevOps sker alla dessa processer samtidigt.
Time-to-market är det enda sättet det kan göras. För människor som arbetade i den gamla processen ser detta något kosmiskt ut, och generellt så som så.
Så varför behöver du DevOps?
För digital produktutveckling. Om ditt företag inte har en digital produkt behövs inte DevOps – det är väldigt viktigt.
DevOps övervinner hastighetsbegränsningarna för sekventiell mjukvaruproduktion. I den sker alla processer samtidigt.
Svårigheten ökar. När DevOps-evangelister berättar att det kommer att göra det lättare för dig att släppa mjukvara är detta nonsens.
Med DevOps kommer saker bara att bli mer komplicerade.
På konferensen i Avitos monter kunde man se hur det var att distribuera en Docker-container – en orealistisk uppgift. Komplexiteten blir oöverkomlig, du måste jonglera med många bollar samtidigt.
DevOps förändrar hela processen och organisationen i företaget — närmare bestämt är det inte DevOps som förändras, utan den digitala produkten. För att komma till DevOps måste du fortfarande helt ändra den här processen.
Frågor till en specialist
Vad har du? Frågor som du kan ställa dig själv när du arbetar på ett företag och utvecklas som specialist.
Har du en strategi för att skapa en digital produkt? Om det finns är det redan bra. Detta innebär att ditt företag går mot DevOps.
Skapar ditt företag redan en digital produkt? Det betyder att du kan ta dig ytterligare en nivå högre och göra saker mer intressant – igen ur DevOps synvinkel. Jag talar bara ur denna synvinkel.
Är ditt företag ett av marknadsledarna inom den digitala produktnischen? Spotify, Yandex, Uber är företag som är på toppen av tekniska framsteg nu.
Ställ dig själv dessa frågor, och om alla svar är nej, så kanske du inte borde göra DevOps på det här företaget. Om ämnet DevOps verkligen är intressant för dig, kanske... du borde flytta till ett annat företag? Om ditt företag vill gå in i DevOps, men du svarade "Nej" på alla frågor, då är det som den där vackra noshörningen som aldrig kommer att förändras.
Organisation
Som sagt, enligt Conways lag förändras organisationen av ett företag. Jag börjar med vad som hindrar DevOps från att tränga in i företaget ur organisatorisk synvinkel.
Problemet med "brunnar"
Det engelska ordet "Silo" översätts här till ryska som "väl". Poängen med detta problem är att det sker inget informationsutbyte mellan team. Varje team gräver djupt i sin expertis, utan att bygga en gemensam karta för att navigera.
På något sätt påminner detta mig om en person som precis har anlänt till Moskva och ännu inte vet hur man navigerar på tunnelbanekartan. Muskoviter känner vanligtvis sitt område mycket väl, och i hela Moskva kan de navigera med hjälp av tunnelbanekartan. När du kommer till Moskva för första gången har du inte den här färdigheten, och du är bara desorienterad.
DevOps föreslår att ta sig igenom detta ögonblick av desorientering och att alla avdelningar arbetar tillsammans för att bygga en gemensam interaktionskarta.
Två faktorer hindrar detta.
Konsekvens av företagsledningssystemet. Den är byggd i separata hierarkiska "brunnar". Till exempel finns det vissa nyckeltal i företag som stödjer detta system. Å andra sidan kommer hjärnan hos en person som har svårt att gå utanför gränserna för sin expertis och navigera i hela systemet i vägen. Det är bara obehagligt. Föreställ dig att du är på Bangkoks flygplats - du kommer inte att hitta runt snabbt. DevOps är också svårt att navigera, och det är därför folk säger att du måste hitta en guide för att komma dit.
Men det viktigaste är att problemet med "brunnar" för en ingenjör som är genomsyrad av DevOps anda, har läst Fowler och en massa andra böcker, uttrycks i det faktum att "brunnar" tillåter dig inte att göra "uppenbara" saker. Vi träffas ofta efter DevOps Moskva, pratar med varandra och folk klagar:
— Vi ville bara lansera CI, men det visade sig att ledningen inte behövde det.
Detta händer just därför CI и Kontinuerlig leveransprocess är på gränsen till många undersökningar. Helt enkelt utan att övervinna problemet med "brunnar" på organisationsnivå kommer du inte att kunna gå vidare, oavsett vad du gör och hur sorgligt det än är.
Varje deltagare i processen i företaget: backend- och frontend-utvecklare, testning, DBA, drift, nätverk, gräver i sin egen riktning, och ingen har en gemensam karta förutom chefen, som på något sätt övervakar dem och hanterar dem med hjälp av "uppdelningen och erövra”-metoden.
Folk slåss om några stjärnor eller flaggor, alla gräver på sin expertis.
Som ett resultat, när uppgiften uppstår att koppla ihop allt detta och bygga en gemensam pipeline, och det inte längre finns något behov av att slåss om stjärnor och flaggor, uppstår frågan - vad ska man göra egentligen? Vi måste komma överens på något sätt, men ingen lärde oss hur man gör det här i skolan. Vi har fått lära oss sedan skolan: åttonde klass - wow! – jämfört med sjuan! Det är samma sak här.
Är det samma i ditt företag?
För att kontrollera detta kan du ställa dig själv följande frågor.
Använder teamen gemensamma verktyg och bidrar de till förändringar av dessa gemensamma verktyg?
Hur ofta omorganiseras team – vissa specialister från ett team flyttar till ett annat team? Det är i en DevOps-miljö som detta blir normalt, för ibland kan en person helt enkelt inte förstå vad ett annat expertområde gör. Han flyttar till en annan avdelning, jobbar där i två veckor för att själv skapa en karta över orientering och interaktion med denna avdelning.
Går det att bilda en förändringskommitté och ändra saker? Eller kräver det den högsta ledningens och ledningens starka hand? Jag skrev nyligen på Facebook hur en föga känd bank implementerar verktyg genom order: vi skriver en order, vi implementerar den under ett år och ser vad som händer. Detta är naturligtvis långt och sorgligt.
Hur viktigt är det för chefer att få personliga prestationer utan att ta hänsyn till företagets prestationer?
Om du själv svarar på dessa frågor blir det tydligare om du har ett sådant problem i ditt företag.
Infrastruktur som kod
Efter att detta problem har passerats är den första viktiga övningen, utan vilken det är svårt att komma vidare i DevOps infrastruktur som kod.
Oftast uppfattas infrastruktur som kod enligt följande:
— Låt oss automatisera allt i bash, täcka oss med skript så att administratörer har mindre manuellt arbete!
Men det är inte sant.
Infrastruktur som kod innebär att man beskriver det IT-system man arbetar med i form av kod för att hela tiden förstå dess tillstånd.
Tillsammans med andra team skapar ni en karta i form av kod som alla kan förstå och kan navigera och navigera. Det spelar ingen roll vad det görs på – Chef, Ansible, Salt eller att använda YAML-filer i Kubernetes – det är ingen skillnad.
På konferensen berättade en kollega från 2GIS hur de gjorde sin egen interna grej för Kubernetes, som beskriver strukturen i enskilda system. För att beskriva 500 system behövde de ett separat verktyg som genererar denna beskrivning. När det finns den här beskrivningen kan alla kolla med varandra, övervaka förändringar, hur man ändrar den och förbättrar den, vad som saknas.
Håller med, individuella bash-skript ger vanligtvis inte denna förståelse. I ett av företagen där jag jobbade fanns det till och med ett namn för "skrivbara" manus - när manuset är skrivet, men det inte längre går att läsa det. Jag tror att detta är bekant för dig också.
Infrastruktur som kod är kod som beskriver infrastrukturens nuvarande tillstånd. Många produkt-, infrastruktur- och serviceteam arbetar tillsammans med den här koden, och viktigast av allt behöver de alla förstå hur den här koden faktiskt fungerar.
Koden upprätthålls enligt bästa praxis: gemensam utveckling, kodgranskning, XP-programmering, testning, pull-förfrågningar, CI för kodinfrastrukturer - allt detta är lämpligt och kan användas.
Kod blir ett gemensamt språk för alla ingenjörer.
Att ändra infrastruktur i kod tar inte mycket tid. Ja, infrastrukturkod kan också ha tekniska skulder. Vanligtvis stöter team på det ett och ett halvt år efter att de började implementera "infrastruktur som kod" i form av ett gäng skript eller till och med Ansible, som de skriver som spagettikod, och de kastar också bash-skript i mixen!
Det är viktigt: Om du inte har provat det här än, kom ihåg det Ansible är inte bash! Läs dokumentationen noggrant, studera vad de skriver om den.
Infrastruktur som kod är uppdelningen av infrastrukturkod i separata lager.
I vårt företag skiljer vi 3 grundläggande lager, som är mycket tydliga och enkla, men det kan finnas fler av dem. Du kan titta på din infrastrukturkod och se om du har detta tillstånd eller inte. Om inga lager är markerade måste du ta lite tid och refaktorera lite.
baslager - så här är OS, säkerhetskopior och andra lågnivåsaker konfigurerade, till exempel hur Kubernetes distribueras på grundnivå.
Servicenivå - det här är tjänsterna som du tillhandahåller utvecklaren: loggning som tjänst, övervakning som tjänst, databas som tjänst, balansering som tjänst, kö som tjänst, Kontinuerlig leverans som tjänst - ett gäng tjänster som enskilda team kan bidra till utveckling. Allt detta måste beskrivas i separata moduler i ditt konfigurationshanteringssystem.
Lagret där applikationer görs och beskriver hur de kommer att utvecklas ovanpå de två föregående lagren.
Kontrollfrågor
Har ditt företag ett gemensamt infrastrukturförråd? Hanterar du tekniska skulder i din infrastruktur? Använder du utvecklingsmetoder i ett infrastrukturförråd? Är din infrastruktur uppdelad i lager? Du kan kontrollera Base-service-APP-diagrammet. Hur svårt är det att göra en förändring?
Om du har upplevt att det tog en och en halv dag att göra ändringar betyder det att du har tekniska skulder och behöver jobba med det. Du snubblade precis över en teknisk skuldraka i din infrastrukturkod. Jag minns många sådana historier när du, för att ändra en del CCTL, måste skriva om hälften av infrastrukturkoden, eftersom kreativitet och viljan att automatisera allt ledde till det faktum att allt är korroderat överallt, alla handtag har tagits bort, och det är nödvändigt att refaktorera.
Kontinuerlig leverans
Låt oss jämföra debet med kredit. Först kommer en beskrivning av infrastrukturen, som kan vara ganska grundläggande. Du behöver inte beskriva allt i detalj, men det krävs en viss grundläggande beskrivning så att du kan arbeta med det. Annars är det inte klart vad man ska göra med kontinuerlig leverans härnäst. Alla dessa metoder utvecklas samtidigt när du kommer till DevOps, men det börjar med att förstå vad du har och hur du hanterar det. Detta är precis praxis för infrastruktur som kod.
När det står klart att du har det och hur du hanterar det, börjar du ta reda på hur du skickar utvecklarkoden till produktion så snabbt som möjligt. Jag menar tillsammans med utvecklaren - vi kommer ihåg problemet med "brunnar", det vill säga att det inte är enskilda personer som kommer på detta, utan ett team.
När vi är med Vanya Evtukhovich såg första boken Jez Humble och grupper av författare "Kontinuerlig leverans", som släpptes 2009, funderade vi länge på hur vi skulle översätta dess titel till ryska. De ville översätta det som "Ständigt leverera", men tyvärr översattes det som "Kontinuerlig leverans". Det verkar för mig att det finns något ryskt i vårt namn, med press.
Ständigt leverera betyder
Kod som finns i produktförrådet kan alltid laddas ner till produktion. Han kanske inte är tömd, men han är alltid redo för det. Följaktligen skriver du alltid kod med en svårförklarlig känsla av viss oro under svanskotan. Det dyker ofta upp när du rullar ut infrastrukturkod. Den här känslan av viss ångest borde finnas – den sätter igång hjärnprocesser som gör att du kan skriva kod lite annorlunda. Detta bör antecknas i reglerna inom utvecklingen.
För att leverera konsekvent behöver du ett artefaktformat som körs över en infrastrukturplattform. Om du kastar "livsavfall" av olika format över en infrastrukturplattform, blir den enhetlig, den är svår att underhålla och problemet med tekniska skulder uppstår. Artefaktens format måste anpassas - detta är också en kollektiv uppgift: vi måste alla samlas, prassla våra hjärnor och komma på detta format.
Artefakten förbättras kontinuerligt och ändras för att passa produktionsmiljön när den rör sig genom leveranspipelinen. När en artefakt rör sig längs pipelinen, stöter den ständigt på några obekväma saker för den, som liknar vad artefakten som du sätter i produktion stöter på. Om detta i klassisk utveckling görs av en systemadministratör som gör utrullningen, så händer detta hela tiden i DevOps-processen: här testade de det med några tester, här kastade de in det i ett Kubernetes-kluster, som är mer eller mindre liknande till produktion, så började de plötsligt lasttesta .
Det här påminner en del om Pac-Man-spelet – artefakten går igenom någon slags historia. Samtidigt är det viktigt att kontrollera om koden faktiskt går igenom berättelsen och om den på något sätt är relaterad till din produktion. Berättelser från produktionen kan dras in i processen för kontinuerlig leverans: det var så här när något föll, låt oss nu bara programmera detta scenario inuti systemet. Varje gång kommer koden att gå igenom detta scenario också, och du kommer inte att stöta på det här problemet nästa gång. Du kommer att lära dig om det mycket tidigare än det når din kund.
Olika implementeringsstrategier. Till exempel använder du AB-testning eller kanariefågel för att testa koden olika på olika klienter, få information om hur koden fungerar och mycket tidigare än när den rullas ut till 100 miljoner användare.
"Konsekvent leverera" ser ut så här.
Leveransprocessen Dev, CI, Test, PreProd, Prod är inte en separat miljö, det här är etapper eller stationer med brandsäkra summor som din artefakt passerar genom.
Om du har infrastrukturkod som beskrivs som Base Service APP så hjälper det glöm inte alla manus, och skriv ner dem som kod för denna artefakt, främja artefakter och ändra det allt eftersom.
Självtestfrågor
Tiden från funktionsbeskrivning till lansering i produktion är i 95 % av fallen mindre än en vecka? Förbättras kvaliteten på artefakten i varje steg av pipelinen? Finns det en historia som den går igenom? Använder du olika distributionsstrategier?
Om alla svar är ja, då är du otroligt cool! Skriv dina svar i kommentarerna - jag blir glad).
Kontakta oss
Detta är den svåraste praktiken av alla. På DevOpsConf-konferensen var en kollega från Infobip, som pratade om det, lite förvirrad i sina ord, eftersom detta verkligen är en mycket komplex praxis om det faktum att du måste övervaka allt!
Till exempel för länge sedan, när jag jobbade på Qik och vi insåg att vi behövde övervaka allt. Vi gjorde detta, och vi har nu 150 000 artiklar i Zabbix, som ständigt övervakas. Det var läskigt, den tekniska chefen vred fingret mot tinningen:
- Killar, varför våldtar ni servern med något oklart?
Men så inträffade en incident som visade att det här verkligen är en väldigt cool strategi.
En av tjänsterna började krascha hela tiden. Inledningsvis kraschade den inte, vilket är intressant, koden lades inte till där, eftersom det var en grundläggande mäklare, som praktiskt taget inte hade någon affärsfunktionalitet - den skickade helt enkelt meddelanden mellan enskilda tjänster. Tjänsten ändrades inte på 4 månader och plötsligt började den krascha med felet "Segmenteringsfel".
Vi blev chockade, öppnade våra diagram i Zabbix och det visade sig att för en och en halv vecka sedan förändrades beteendet för förfrågningar i API-tjänsten som denna mäklare använder kraftigt. Därefter såg vi att frekvensen för att skicka en viss typ av meddelanden hade ändrats. Senare fick vi reda på att det var android-klienter. Vi frågade:
— Killar, vad hände med er för en och en halv vecka sedan?
Som svar fick vi höra en intressant historia om hur de hade gjort om gränssnittet. Det är osannolikt att någon omedelbart kommer att säga att de ändrade HTTP-biblioteket. För Android-klienter är det som att byta tvål i badrummet - de kommer bara inte ihåg. Som ett resultat, efter 40 minuters konversation, fick vi reda på att de hade ändrat HTTP-biblioteket och att dess standardtider hade ändrats. Detta ledde till att trafikbeteendet på API-servern ändrades, vilket ledde till en situation som orsakade ett lopp inom mäklaren och den började krascha.
Utan djup övervakning är det i allmänhet omöjligt att öppna detta. Om organisationen fortfarande har problemet med ”brunnar”, när alla kastar pengar på varandra, kan detta leva vidare i åratal. Du startar helt enkelt om servern eftersom det är omöjligt att lösa problemet. När du övervakar, spårar, spårar alla händelser som du har, och använder övervakning som test - skriv kod och omedelbart anger hur den ska övervakas, även i form av kod (vi har redan infrastrukturen som kod), blir allt tydligt hur på handflatan. Även sådana komplexa problem kan lätt spåras.
Samla all information om vad som händer med artefakten i varje skede av leveransprocessen - inte i produktionen.
Ladda upp övervakningen till CI, och några grundläggande saker kommer redan att synas där. Senare kommer du att se dem i Test, PredProd och belastningstestning. Samla information i alla skeden, inte bara mätvärden, statistik, utan också loggar: hur applikationen rullade ut, anomalier - samla in allt.
Annars blir det svårt att ta reda på det. Jag har redan sagt att DevOps är mer komplext. För att klara av denna komplexitet måste du ha normal analys.
Frågor för självkontroll
Är din övervakning och loggning utvecklingsverktyget för dig? När du skriver kod, tänker dina utvecklare, inklusive du, på hur de ska övervaka den?
Hör du om problem från kunder? Förstår du klienten bättre av övervakning och loggning? Förstår du systemet bättre av övervakning och loggning? Byter du system bara för att du såg att trenden i systemet växer och du förstår att om ytterligare 3 veckor dör allt?
När du väl har dessa tre komponenter kan du fundera på vilken typ av infrastrukturplattform du har i ditt företag.
Infrastrukturplattform
Poängen är inte att det är en uppsättning olika verktyg som varje företag har.
Poängen med en infrastrukturplattform är att alla team använder dessa verktyg och utvecklar dem tillsammans.
Det är tydligt att det finns separata team som ansvarar för utvecklingen av enskilda delar av infrastrukturplattformen. Men samtidigt bär varje ingenjör ansvar för utveckling, prestanda och marknadsföring av infrastrukturplattformen. På ett internt plan blir det ett vanligt verktyg.
Alla team utvecklar infrastrukturplattformen och behandlar den med omsorg som sin egen IDE. I din IDE installerar du olika plugins för att göra allt snyggt och snabbt, och konfigurerar snabbtangenter. När du öppnar Sublime, Atom eller Visual Studio Code, strömmar kodfel in och du inser att det är omöjligt att fungera alls, du känner dig direkt ledsen och du springer för att fixa din IDE.
Behandla din infrastrukturplattform på samma sätt. Om du förstår att det är något fel på det, lämna en förfrågan om du inte kan fixa det själv. Om det är något enkelt, redigera det själv, skicka en pull-förfrågan, killarna kommer att överväga det och lägga till det. Detta är ett lite annorlunda förhållningssätt till ingenjörsverktyg i utvecklarens huvud.
Infrastrukturplattformen säkerställer överföringen av artefakten från utveckling till klienten med kontinuerlig förbättring av kvaliteten. IP:n är programmerad med en uppsättning historier som händer med koden i produktionen. Under åren av utveckling har det funnits många av dessa berättelser, några av dem är unika och relaterar bara till dig – de går inte att googla.
Vid denna tidpunkt blir infrastrukturplattformen din konkurrensfördel, eftersom det har något inbyggt i sig som inte finns i konkurrentens verktyg. Ju djupare din IP är, desto större är din konkurrensfördel när det gäller Time-to-market. Visas här problem med leverantörslås: Du kan ta någon annans plattform, men med hjälp av någon annans erfarenhet kommer du inte att förstå hur relevant det är för dig. Ja, inte alla företag kan bygga en plattform som Amazon. Detta är en svår linje där företagets erfarenhet är relevant för dess position på marknaden, och du kan inte använda ett leverantörslås där. Detta är också viktigt att tänka på.
Schemat
Detta är ett grundläggande diagram över en infrastrukturplattform som hjälper dig att ställa in alla metoder och processer i ett DevOps-företag.
Låt oss titta på vad den består av.
Resursorkestreringssystem, som tillhandahåller CPU, minne, disk till applikationer och andra tjänster. Dessutom - tjänster på låg nivå: övervakning, loggning, CI/CD Engine, artefaktlagring, infrastruktur som systemkod.
Tjänster på högre nivå: databas som en tjänst, köer som en tjänst, Lastbalans som en tjänst, bildstorleksändring som en tjänst, Big Data factory as a service. Dessutom - pipeline som levererar ständigt modifierad kod till din klient.
Du får information om hur din mjukvara fungerar för kunden, ändrar den, anger denna kod igen, får information – och så utvecklar du hela tiden både infrastrukturplattformen och din mjukvara.
I diagrammet består leveranspipelinen av många steg. Men detta är ett schematiskt diagram som ges som ett exempel - du behöver inte upprepa det en efter en. Stadier interagerar med tjänster som om de vore tjänster – varje sten på plattformen bär sin egen historia: hur resurser allokeras, hur applikationen lanseras, arbetar med resurser, övervakas och ändras.
Det är viktigt att förstå att varje del av plattformen har en historia, och fråga dig själv vilken historia den här tegelstenen bär på, kanske ska den slängas och ersättas med en tredjepartstjänst. Är det till exempel möjligt att installera Okmeter istället för en tegelsten? Kanske har killarna redan utvecklat denna expertis mycket mer än vi. Men kanske inte – kanske har vi unik kompetens, vi behöver installera Prometheus och utveckla den vidare.
Skapandet av plattformen
Detta är en komplex kommunikationsprocess. När du har grundläggande praktiker startar du kommunikation mellan olika ingenjörer och specialister som utvecklar krav och standarder, och ständigt ändrar dem till olika verktyg och tillvägagångssätt. Kulturen som vi har i DevOps är viktig här.
Med kultur är allt väldigt enkelt - det handlar om samarbete och kommunikation, det vill säga viljan att arbeta inom ett gemensamt område med varandra, önskan att använda ett instrument tillsammans. Det finns ingen raketvetenskap här - allt är väldigt enkelt, banalt. Vi bor till exempel alla i entrén och håller rent – en sådan kulturnivå.
Vad har du?
Återigen, frågor du kan ställa dig själv.
Är infrastrukturplattformen dedikerad? Vem är ansvarig för dess utveckling? Förstår du konkurrensfördelarna med din infrastrukturplattform?
Du måste hela tiden ställa dig dessa frågor. Om något kan överföras till tredjepartstjänster bör det överföras, om en tredjepartstjänst börjar blockera din rörelse måste du bygga ett system inom dig själv.
Så, DevOps...
... detta är ett komplext system, det måste ha:
- Digital produkt.
- Affärsmoduler som utvecklar denna digitala produkt.
- Produktteam som skriver kod.
- Kontinuerlig leveranspraxis.
- Plattformar som en tjänst.
- Infrastruktur som en tjänst.
- Infrastruktur som kod.
- Separata metoder för att upprätthålla tillförlitlighet, inbyggd i DevOps.
- En feedbackpraxis som beskriver det hela.
Du kan använda det här diagrammet och markera i det vad du redan har i ditt företag i någon form: har det utvecklats eller fortfarande behöver utvecklas.
Det är över om ett par veckor . som en del av RIT++. Kom till konferensen där du hittar många coola rapporter om kontinuerlig leverans, infrastruktur som kod och DevOps-transformation. , sista prisdeadline är 20 maj
Källa: will.com