De definitie van DevOps is erg complex, waardoor we de discussie er elke keer opnieuw over moeten beginnen. Alleen al op Habré zijn er duizend publicaties over dit onderwerp. Maar als je dit leest, weet je waarschijnlijk wat DevOps is. Omdat ik het niet ben. Hallo mijn naam is Alexander Titov (@), en we praten alleen over DevOps en ik deel mijn ervaringen.
Ik heb er lang over nagedacht hoe ik mijn verhaal nuttig zou kunnen maken, dus er zullen hier veel vragen zijn - de vragen die ik mezelf stel en de vragen die ik aan de klanten van ons bedrijf stel. Door deze vragen te beantwoorden, wordt het begrip beter. Ik zal je vertellen waarom DevOps nodig is vanuit mijn standpunt, wat het is, nogmaals, vanuit mijn standpunt, en hoe je kunt begrijpen dat je vanuit mijn standpunt weer richting DevOps gaat. Het laatste punt zal bestaan uit vragen. Door ze zelf te beantwoorden, kunt u begrijpen of uw bedrijf op weg is naar DevOps of dat er op de een of andere manier problemen zijn.
Ooit zat ik op de golven van fusies en overnames. Eerst werkte ik voor een kleine startup genaamd Qik, daarna werd het gekocht door een iets groter bedrijf genaamd Skype, dat vervolgens werd gekocht door een iets groter bedrijf genaamd Microsoft. Op dat moment begon ik te zien hoe het idee van DevOps transformeerde in bedrijven van verschillende grootte. Daarna raakte ik geïnteresseerd om DevOps vanuit een marktperspectief te bekijken, en mijn collega's en ik hebben het bedrijf Express 42 opgericht. Al zes jaar lang bewegen we mee op de golven van de markt.
Ik ben onder andere een van de organisatoren van de DevOps Moskou-gemeenschap en de organisator van DevOps-Days 2017, maar ik heb 2018 niet georganiseerd. Express 42 werkt met veel bedrijven samen. We laten DevOps daar groeien, kijken hoe het gebeurt, trekken conclusies, analyseren, vertellen iedereen onze conclusies en trainen mensen in DevOps-praktijken. Over het algemeen doen wij ons best om onze ervaring en expertise op dit vlak te vergroten.
Waarom DevOps
De eerste vraag die iedereen en altijd achtervolgt is: waarom? Veel mensen denken dat DevOps slechts automatisering is of iets soortgelijks dat elk bedrijf al had.
— We hadden continue integratie - dit betekent dat we al DevOps hadden, en waarom zijn al deze dingen nodig? Ze hebben plezier in het buitenland, maar ze houden ons tegen om te werken!
Na 9 jaar ontwikkeling van de community en methodologie is het al duidelijk geworden dat dit nog steeds geen marketing-glitter is, maar het is nog steeds niet helemaal duidelijk waarom het nodig is. Zoals elk hulpmiddel en proces heeft DevOps specifieke doelen die uiteindelijk worden bereikt.
Dit alles is te wijten aan het feit dat de wereld verandert. Hij wijkt af van de ondernemingsaanpak, waarbij bedrijven rechtstreeks op weg zijn naar een droom, zoals onze klassieker uit St. Petersburg zong, van punt A naar punt B volgens een bepaalde strategie, met een bepaalde structuur die daarvoor is gebouwd.
In principe zou alles in de IT volgens deze aanpak moeten worden gebouwd. Hier wordt IT uitsluitend gebruikt om processen te automatiseren.
Automatisering verandert niet vaak, want wat valt er te veranderen als een bedrijf in de vastgeroeste sleur terechtkomt? Het werkt - raak het niet aan. Nu zijn de benaderingen in de wereld aan het veranderen, en de benadering die Agile wordt genoemd suggereert dat eindpunt B niet onmiddellijk zichtbaar is.
Wanneer een bedrijf de markt betreedt, met een klant samenwerkt, verkent het voortdurend de markt en verandert het eindpunt B. Bovendien, hoe vaker het bedrijf van richting verandert, des te succesvoller het uiteindelijk is, omdat het voor meer marktpartijen kiest. niches.
De strategie wordt gedemonstreerd door een interessant bedrijf waar ik onlangs over hoorde. One Box Shave is een abonnementsbezorgservice voor scheerapparaten en scheeraccessoires in een doos. Ze weten hoe ze hun “box” moeten aanpassen voor verschillende klanten. Dit gebeurt door een bepaalde software, die de bestelling vervolgens doorstuurt naar de Koreaanse fabriek die de goederen produceert.
Dit product werd door Unilever gekocht voor $ 1 miljard. Het concurreert nu met Gillette en heeft een aanzienlijk deel van de consumenten op de Amerikaanse markt weggenomen. One Box Shave zegt:
— 4 messen? Ben je serieus? Waarom heb je dit nodig - het verbetert de kwaliteit van het scheren niet. Een speciaal geselecteerde crème, geur en een kwalitatief hoogstaand scheermes met twee mesjes lossen veel meer problemen op dan die stomme 4 Gillette-mesjes! Gaan we binnenkort naar de 10?
Dit is hoe de wereld verandert. Unilever beweert dat ze een cool IT-systeem hebben waarmee je dit kunt doen. Uiteindelijk lijkt het een concept Time-to-market, waar nog niemand over heeft gesproken.
Het punt van Time-to-market is niet hoe vaak we inzetten. U kunt vaak implementeren, maar de releasecycli zullen lang zijn. Als releasecycli van drie maanden over elkaar heen worden gelegd en ze met een week worden verschoven, blijkt dat het bedrijf één keer per week lijkt te implementeren. En van het idee tot de uiteindelijke implementatie duurt het 3 maanden.
Time-to-market gaat over het minimaliseren van de tijd tussen idee en uiteindelijke implementatie.
In dit geval interageert software met de markt. Dit is hoe de One Box Shave-website communiceert met de klant. Ze hebben geen verkopers - alleen een website waar bezoekers klikken en wensen achterlaten. Daarom moet er voortdurend iets nieuws op de site worden geplaatst en naar wens worden bijgewerkt. In Zuid-Korea scheren ze bijvoorbeeld anders dan in Rusland, en ze houden niet van de geur van dennenbomen, maar bijvoorbeeld van wortels en vanille.
Omdat het nodig is om de inhoud van de site snel te veranderen, verandert de softwareontwikkeling enorm. Via software moeten we erachter komen wat de klant wil. Voorheen leerden we dit via een omslachtige manier, bijvoorbeeld via bedrijfsmanagement. Vervolgens hebben we het ontworpen, de vereisten in het IT-systeem gezet en alles was cool. Nu is het anders: software wordt ontworpen door iedereen die bij het proces betrokken is, inclusief ingenieurs, omdat ze via technische specificaties leren hoe de markt werkt en hun inzichten ook delen met de business.
Bij Qik kwamen we er bijvoorbeeld plotseling achter dat mensen het erg leuk vonden om contactlijsten naar de server te uploaden, en ze leverden ons een applicatie. Aanvankelijk dachten we er niet over na. In een klassiek bedrijf zou iedereen hebben besloten dat dit een bug was, aangezien de specificatie niet zei dat het geweldig zou moeten werken en over het algemeen op de knie was geïmplementeerd, zouden ze de functie hebben uitgeschakeld en gezegd: “Niemand heeft dit nodig, het allerbelangrijkste is dat de hoofdfunctionaliteit werkt.” . En het technologiebedrijf ziet dit als een kans en begint de software in overeenstemming hiermee te veranderen.
In 1968 formuleerde een visionair, Melvin Conway, het volgende idee.
De organisatie die het systeem creëert, wordt beperkt door een ontwerp dat de communicatiestructuur van die organisatie repliceert.
Meer gedetailleerd: om systemen van een ander type te produceren, moet je ook een communicatiestructuur hebben binnen een bedrijf van een ander type. Als uw communicatiestructuur top-hiërarchisch is, kunt u hierdoor geen systemen creëren die een zeer hoge Time-to-Market-indicator kunnen bieden.
Lezen men kan . Het is belangrijk om de DevOps-cultuur of -filosofie te begrijpen, omdat het enige dat fundamenteel verandert in DevOps is de structuur van de communicatie tussen teams.
Vanuit procesoogpunt waren vóór DevOps alle fasen: analyse, ontwikkeling, testen en bediening lineair.
In het geval van DevOps vinden al deze processen tegelijkertijd plaats.
Time-to-market is de enige manier waarop dit kan worden gedaan. Voor mensen die volgens het oude proces werkten, ziet dit er enigszins kosmisch uit, en over het algemeen ook zo.
Dus waarom heb je DevOps nodig?
Voor digitale productontwikkeling. Als uw bedrijf geen digitaal product heeft, is DevOps niet nodig; het is erg belangrijk.
DevOps overwint de snelheidsbeperkingen van sequentiële softwareproductie. Daarin vinden alle processen gelijktijdig plaats.
De moeilijkheidsgraad neemt toe. Als DevOps-evangelisten je vertellen dat het je gemakkelijker zal maken om software uit te brengen, is dat onzin.
Met DevOps worden de zaken alleen maar ingewikkelder.
Op de conferentie op de Avito-stand kon je zien hoe het was om een Docker-container in te zetten: een onrealistische taak. De complexiteit wordt onbetaalbaar; je moet met veel ballen tegelijk jongleren.
DevOps verandert het proces en de organisatie in het bedrijf compleet – preciezer gezegd: het is niet DevOps dat verandert, maar het digitale product. Om naar DevOps te komen, moet je dit proces nog helemaal omgooien.
Vragen voor een specialist
Wat heb je? Vragen die je jezelf kunt stellen terwijl je in een bedrijf werkt en je ontwikkelt als specialist.
Heeft u een strategie voor het creëren van een digitaal product? Als dat zo is, is dat al goed. Dit betekent dat jouw bedrijf richting DevOps beweegt.
Creëert uw bedrijf al een digitaal product? Dit betekent dat je weer een niveau hoger kunt komen en dingen interessanter kunt doen – wederom vanuit DevOps-oogpunt. Ik spreek alleen vanuit dit standpunt.
Is uw bedrijf een van de marktleiders in de digitale productniche? Spotify, Yandex en Uber zijn bedrijven die zich nu op het hoogtepunt van de technologische vooruitgang bevinden.
Stel jezelf deze vragen, en als alle antwoorden nee zijn, dan zou je misschien geen DevOps bij dit bedrijf moeten doen. Als het onderwerp DevOps u echt interesseert, moet u misschien naar een ander bedrijf verhuizen? Als jouw bedrijf aan DevOps wil beginnen, maar je hebt op alle vragen ‘Nee’ geantwoord, dan is het net als die prachtige neushoorn die nooit zal veranderen.
Organisatie
Zoals ik al zei, verandert volgens de wet van Conway de organisatie van een bedrijf. Ik zal beginnen met wat ervoor zorgt dat DevOps vanuit organisatorisch oogpunt binnen het bedrijf doordringt.
Het probleem van "putten"
Het Engelse woord "Silo" wordt hier in het Russisch vertaald als "goed". Het punt van dit probleem is dat Er vindt geen uitwisseling van informatie tussen teams plaats. Elk team graaft diep in zijn expertise, zonder een gemeenschappelijke kaart te bouwen om te navigeren.
In sommige opzichten doet dit me denken aan iemand die net in Moskou is aangekomen en nog niet weet hoe hij op de metrokaart moet navigeren. Moskovieten kennen hun gebied meestal heel goed, en door heel Moskou kunnen ze navigeren met behulp van de metrokaart. Als je voor de eerste keer naar Moskou komt, beschik je niet over deze vaardigheid en ben je gewoon gedesoriënteerd.
DevOps stelt voor om dit moment van desoriëntatie te doorstaan en alle afdelingen samen te laten werken om een gemeenschappelijke interactiekaart op te bouwen.
Twee factoren belemmeren dit.
Gevolg van het bedrijfsmanagementsysteem. Het is gebouwd in afzonderlijke hiërarchische “putten”. Er zijn bijvoorbeeld bepaalde KPI’s bij bedrijven die dit systeem ondersteunen. Aan de andere kant zitten de hersenen van iemand die het moeilijk vindt om de grenzen van zijn expertise te overschrijden en door het hele systeem te navigeren, in de weg. Het is gewoon ongemakkelijk. Stel je voor dat je op de luchthaven van Bangkok bent, je zult niet snel je weg vinden. DevOps is ook moeilijk te navigeren, en daarom zeggen mensen dat je een gids nodig hebt om daar te komen.
Maar het allerbelangrijkste is dat het probleem van ‘putten’ voor een ingenieur die doordrenkt is met de geest van DevOps, Fowler en een heleboel andere boeken heeft gelezen, tot uiting komt in het feit dat Met "putten" kun je geen "voor de hand liggende" dingen doen. We komen vaak samen na DevOps Moskou, praten met elkaar en mensen klagen:
— We wilden gewoon CI lanceren, maar het bleek dat het management dit niet nodig had.
Dit gebeurt juist omdat CI и Continu leveringsproces bevinden zich op de grens van veel examens. Zonder het probleem van de ‘putten’ op organisatorisch niveau te overwinnen, kun je eenvoudigweg niet vooruit, wat je ook doet en hoe triest het ook is.
Elke deelnemer aan het proces in het bedrijf: backend- en frontend-ontwikkelaars, testen, DBA, bediening, netwerk, graaft in zijn eigen richting, en niemand heeft een gemeenschappelijke kaart behalve de manager, die ze op de een of andere manier controleert en beheert met behulp van de “kloof en verover”-methode.
Mensen vechten voor een paar sterren of vlaggen, iedereen graaft zijn expertise op.
Als gevolg hiervan, wanneer de taak zich voordoet om dit allemaal met elkaar te verbinden en een gemeenschappelijke pijpleiding aan te leggen, en het niet langer nodig is om voor sterren en vlaggen te vechten, rijst de vraag: wat moet je eigenlijk doen? We moeten op de een of andere manier tot overeenstemming komen, maar niemand heeft ons op school geleerd hoe we dit moeten doen. We hebben sinds school geleerd: achtste klas - wauw! - vergeleken met de zevende klas! Het is hier hetzelfde.
Is dit binnen uw bedrijf hetzelfde?
Om dit te controleren kun je jezelf de volgende vragen stellen.
Gebruiken teams gemeenschappelijke tools en dragen ze bij aan veranderingen in die gemeenschappelijke tools?
Hoe vaak reorganiseren teams: sommige specialisten van het ene team verhuizen naar een ander team? Het is in een DevOps-omgeving dat dit normaal wordt, omdat iemand soms simpelweg niet kan begrijpen wat een ander vakgebied doet. Hij verhuist naar een andere afdeling, werkt daar twee weken om voor zichzelf een kaart van oriëntatie en interactie met deze afdeling te maken.
Is het mogelijk om een verandercommissie te vormen en dingen te veranderen? Of vereist het de sterke hand van het hoogste management en leiding? Ik schreef onlangs op Facebook hoe een weinig bekende bank tools implementeert door middel van orders: we schrijven een order, we voeren deze een jaar lang uit en kijken wat er gebeurt. Dit is natuurlijk lang en verdrietig.
Hoe belangrijk is het voor managers om persoonlijke prestaties te ontvangen zonder rekening te houden met de prestaties van het bedrijf?
Als u deze vragen voor uzelf beantwoordt, wordt het duidelijker of u in uw bedrijf een dergelijk probleem heeft.
Infrastructuur als code
Nadat dit probleem is gepasseerd, is de eerste belangrijke praktijk, zonder welke het moeilijk is om verder te komen in DevOps infrastructuur als code.
Meestal wordt infrastructuur als code als volgt opgevat:
— Laten we alles in bash automatiseren, onszelf bedekken met scripts zodat beheerders minder handmatig werk hebben!
Maar dat is niet waar.
Infrastructuur als code betekent dat je het IT-systeem waarmee je werkt beschrijft in de vorm van code, zodat je voortdurend inzicht krijgt in de staat ervan.
Samen met andere teams maak je een kaart in de vorm van code die iedereen kan begrijpen en kan navigeren en navigeren. Het maakt niet uit waar het op wordt gedaan – Chef, Ansible, Salt of het gebruik van YAML-bestanden in Kubernetes – er is geen verschil.
Op de conferentie vertelde een collega van 2GIS hoe ze voor Kubernetes hun eigen interne ding hadden gemaakt, dat de structuur van individuele systemen beschrijft. Om 500 systemen te beschrijven hadden ze een aparte tool nodig die deze beschrijving genereert. Als er deze beschrijving is, kan iedereen met elkaar overleggen, veranderingen monitoren, hoe deze te veranderen en te verbeteren, wat er ontbreekt.
Mee eens, individuele bash-scripts bieden dit inzicht meestal niet. In een van de bedrijven waar ik werkte, bestond er zelfs een naam voor 'alleen schrijven'-script - wanneer het script is geschreven, maar het niet langer mogelijk is om het te lezen. Ik denk dat dit jou ook bekend voorkomt.
Infrastructuur zoals code is code die de huidige staat van de infrastructuur beschrijft. Veel product-, infrastructuur- en serviceteams werken samen aan deze code, en het allerbelangrijkste: ze moeten allemaal begrijpen hoe deze code daadwerkelijk werkt.
De code wordt onderhouden volgens de beste codepraktijken: gezamenlijke ontwikkeling, code review, XP-programmeren, testen, pull-requests, CI voor code-infrastructuren - dit alles is geschikt en kan worden gebruikt.
Code wordt een gemeenschappelijke taal voor alle ingenieurs.
Het veranderen van de infrastructuur in code kost niet veel tijd. Ja, infrastructuurcode kan ook technische schulden hebben. Meestal komen teams ermee in aanraking anderhalf jaar nadat ze zijn begonnen met het implementeren van “infrastructuur als code” in de vorm van een aantal scripts of zelfs Ansible, die ze als spaghetticode schrijven, en ze gooien ook bash-scripts in de mix!
Het is belangrijk: Als je dit spul nog niet hebt geprobeerd, onthoud dat dan Ansible is geen bash! Lees de documentatie aandachtig, bestudeer wat ze erover schrijven.
Infrastructuur als code is de scheiding van infrastructuurcode in afzonderlijke lagen.
In ons bedrijf onderscheiden we 3 basislagen, die heel duidelijk en eenvoudig zijn, maar er kunnen er meer zijn. U kunt naar uw infrastructuurcode kijken en zien of u deze aandoening heeft of niet. Als er geen lagen zijn gemarkeerd, moet u even de tijd nemen en een beetje refactoren.
basislaag - dit is hoe het besturingssysteem, back-ups en andere zaken op laag niveau worden geconfigureerd, hoe Kubernetes bijvoorbeeld op het basisniveau wordt geïmplementeerd.
Service Level - dit zijn de services die u aan de ontwikkelaar levert: loggen als een service, monitoring als een service, database als een service, balancer als een service, wachtrij als een service, Continuous Delivery als een service - een reeks services die individuele teams gebruiken ontwikkeling kan bieden. Dit alles moet in aparte modules in uw configuratiemanagementsysteem worden beschreven.
De laag waar applicaties worden gemaakt en beschrijft hoe ze zich zullen ontvouwen bovenop de vorige twee lagen.
Controle vragen
Heeft uw bedrijf een gemeenschappelijke infrastructuurrepository? Beheert u technische schulden in uw infrastructuur? Maakt u gebruik van ontwikkelingspraktijken in een infrastructuurrepository? Is uw infrastructuur in lagen opgedeeld? U kunt het Base-service-APP-diagram bekijken. Hoe moeilijk is het om iets te veranderen?
Als je hebt ervaren dat het anderhalve dag duurde om wijzigingen door te voeren, betekent dit dat je een technische schuld hebt en daarmee aan de slag moet. U bent zojuist een technische schuldenlast in uw infrastructuurcode tegengekomen. Ik herinner me veel van dergelijke verhalen waarin je, om wat CCTL te veranderen, de helft van de infrastructuurcode moet herschrijven, omdat creativiteit en de wens om alles te automatiseren ertoe leidden dat alles overal gecorrodeerd was, alle handvatten waren verwijderd en het is noodzakelijk om te refactoreren.
Continue levering
Laten we debet met credit vergelijken. Eerst komt een beschrijving van de infrastructuur, die vrij eenvoudig kan zijn. U hoeft niet alles in detail te beschrijven, maar er is wel een basisbeschrijving nodig zodat u ermee kunt werken. Anders is het niet duidelijk wat er nu met continue levering moet gebeuren. Al deze praktijken ontvouwen zich tegelijkertijd wanneer u naar DevOps komt, maar het begint met begrijpen wat u heeft en hoe u dit kunt beheren. Dit is precies de praktijk van infrastructuur als code.
Zodra het duidelijk wordt dat je het hebt en hoe je het moet beheren, begin je erachter te komen hoe je de ontwikkelaarscode zo snel mogelijk naar productie kunt sturen. Ik bedoel samen met de ontwikkelaar - we herinneren ons het probleem van de "putten", dat wil zeggen dat het geen individuele mensen zijn die dit bedenken, maar een team.
Wanneer wij bij zijn Vanya Evtoekhovich heb het eerste boek gezien Jez Humble en groepen auteurs "Continu levering", dat in 2009 werd uitgebracht, hebben we lang nagedacht over hoe we de titel in het Russisch konden vertalen. Ze wilden het vertalen als “Constant leveren”, maar helaas werd het vertaald als “Continu leveren”. Het lijkt mij dat er iets Russisch in onze naam zit, met druk.
Voortdurend middelen leveren
Code die zich in de productrepository bevindt, kan altijd worden gedownload naar productie. Hij is misschien niet leeggelopen, maar hij is er altijd klaar voor. Dienovereenkomstig schrijf je altijd code met een moeilijk uit te leggen gevoel van enige angst onder je staartbeen. Het verschijnt vaak wanneer u infrastructuurcode uitrolt. Dit gevoel van enige angst zou aanwezig moeten zijn - het activeert hersenprocessen waardoor je code een beetje anders kunt schrijven. Dit dient vastgelegd te worden in de regels binnen de ontwikkeling.
Om consistent te kunnen leveren, hebt u een artefactformaat nodig dat over een infrastructuurplatform loopt. Als je ‘levensverspilling’ van verschillende formaten over een infrastructuurplatform gooit, wordt het verenigd, is het moeilijk te onderhouden en ontstaat het probleem van technische schulden. Het formaat van het artefact moet op één lijn worden gebracht - dit is ook een collectieve taak: we moeten allemaal bij elkaar komen, onze hersenen laten ritselen en met dit formaat komen.
Het artefact wordt voortdurend verbeterd en aangepast aan de productieomgeving terwijl het door de leveringspijplijn beweegt. Wanneer een artefact langs de pijplijn beweegt, komt het voortdurend een aantal ongemakkelijke dingen tegen, die vergelijkbaar zijn met wat het artefact tegenkomt dat je in productie brengt. Als dit bij de klassieke ontwikkeling wordt gedaan door een systeembeheerder die de uitrol doet, dan gebeurt dit in het DevOps-proces de hele tijd: hier hebben ze het getest met enkele tests, hier hebben ze het in een Kubernetes-cluster gegooid, dat min of meer vergelijkbaar is naar productie, en toen begonnen ze plotseling met het testen van de belasting.
Dit doet enigszins denken aan het Pac-Man-spel: het artefact doorloopt een soort verhaal. Tegelijkertijd is het belangrijk om te controleren of de code daadwerkelijk door het verhaal gaat en of deze op de een of andere manier verband houdt met jouw productie. Verhalen uit de productie kunnen naar het Continuous Delivery-proces worden gesleept: zo was het toen er iets viel, laten we dit scenario nu gewoon in het systeem programmeren. Elke keer dat de code dit scenario doorloopt, zult u dit probleem de volgende keer niet tegenkomen. U zult er veel eerder over te weten komen dan dat het uw klant bereikt.
Verschillende implementatiestrategieën. U gebruikt bijvoorbeeld AB-testen of canary-implementaties om de code op verschillende clients anders te testen, informatie te krijgen over hoe de code werkt, en veel eerder dan wanneer deze wordt uitgerold naar 100 miljoen gebruikers.
“Consistent leveren” ziet er als volgt uit.
Het opleveringsproces Dev, CI, Test, PreProd, Prod is geen aparte omgeving, dit zijn fasen of stations met vuurvaste sommen waar uw artefact doorheen gaat.
Als u een infrastructuurcode hebt die wordt beschreven als Base Service APP, dan helpt dit vergeet niet alle scripts, en schrijf ze op als code voor dit artefact, artefact bevorderen en verander het gaandeweg.
Zelftestvragen
Is de tijd tussen functiebeschrijving en release in productie in 95% van de gevallen minder dan een week? Verbetert de kwaliteit van het artefact in elke fase van de pijplijn? Is er een verhaal waar het doorheen gaat? Gebruikt u verschillende implementatiestrategieën?
Als alle antwoorden ja zijn, dan ben je ongelooflijk cool! Schrijf uw antwoorden in de reacties - ik zal blij zijn).
terugkoppeling
Dit is de moeilijkste oefening van allemaal. Op de DevOpsConf-conferentie was een collega van Infobip, die erover sprak, een beetje in de war in zijn woorden, omdat dit echt een heel complexe praktijk is over het feit dat je alles moet monitoren!
Bijvoorbeeld lang geleden, toen ik bij Qik werkte en we beseften dat we alles moesten monitoren. We hebben dit gedaan en we hebben nu 150 items in Zabbix, die voortdurend worden gecontroleerd. Het was eng, de technisch directeur draaide zijn vinger naar zijn slaap:
- Jongens, waarom verkrachten jullie de server met iets onduidelijks?
Maar toen deed zich een incident voor waaruit bleek dat dit echt een hele coole strategie is.
Een van de services begon voortdurend te crashen. Aanvankelijk crashte het niet, wat interessant is, de code werd daar niet toegevoegd, omdat het een basismakelaar was, die vrijwel geen zakelijke functionaliteit had - hij verzond eenvoudigweg berichten tussen individuele services. De service veranderde gedurende 4 maanden niet en begon plotseling te crashen met de fout 'Segmentatiefout'.
We waren geschokt, openden onze grafieken in Zabbix en het bleek dat anderhalve week geleden het gedrag van verzoeken in de API-service die deze makelaar gebruikt enorm veranderde. Vervolgens zagen we dat de frequentie waarmee een bepaald type bericht werd verzonden, was veranderd. Later kwamen we erachter dat dit Android-clients waren. We vroegen:
— Jongens, wat is er anderhalve week geleden met jullie gebeurd?
Als reactie daarop hoorden we een interessant verhaal over hoe ze de gebruikersinterface opnieuw hadden ontworpen. Het is onwaarschijnlijk dat iemand onmiddellijk zal zeggen dat hij de HTTP-bibliotheek heeft gewijzigd. Voor Android-clients is het alsof je zeep verwisselt in de badkamer: ze weten het gewoon niet meer. Als gevolg hiervan kwamen we er na 40 minuten gesprek achter dat ze de HTTP-bibliotheek hadden gewijzigd en dat de standaardtijden waren veranderd. Dit leidde ertoe dat het verkeersgedrag op de API-server veranderde, wat leidde tot een situatie die een race binnen de makelaar veroorzaakte en deze begon te crashen.
Zonder diepgaande monitoring is het over het algemeen onmogelijk om dit te openen. Als de organisatie nog steeds het probleem van ‘putten’ heeft, waarbij iedereen geld naar elkaar gooit, kan dit nog jaren voortbestaan. U herstart eenvoudigweg de server omdat het onmogelijk is om het probleem op te lossen. Wanneer je alle gebeurtenissen die je hebt monitort, trackt, volgt en monitoring als test gebruikt – code schrijft en meteen aangeeft hoe je deze moet monitoren, ook in de vorm van code (we hebben de infrastructuur al als code), wordt alles duidelijk hoe op de handpalm. Zelfs zulke complexe problemen kunnen gemakkelijk worden opgespoord.
Verzamel alle informatie over wat er met het artefact gebeurt in elke fase van het leveringsproces - niet tijdens de productie.
Upload de monitoring naar CI, en een aantal basiszaken zullen daar al zichtbaar zijn. Later zul je ze zien in Test-, PredProd- en belastingtests. Verzamel informatie in alle fasen, niet alleen statistieken, statistieken, maar ook logboeken: hoe de applicatie is uitgerold, afwijkingen - verzamel alles.
Anders zal het moeilijk zijn om erachter te komen. Ik zei al dat DevOps complexer is. Om met deze complexiteit om te gaan, heb je normale analyses nodig.
Vragen voor zelfbeheersing
Is uw monitoring en logging de ontwikkeltool voor u? Denken uw ontwikkelaars, inclusief u, bij het schrijven van code na over hoe zij deze kunnen monitoren?
Hoor je problemen van klanten? Begrijp jij de klant beter door te monitoren en te loggen? Begrijpt u het systeem beter door te monitoren en te loggen? Verander je het systeem simpelweg omdat je zag dat de trend in het systeem groeit en je begrijpt dat binnen nog eens 3 weken alles zal sterven?
Zodra u over deze drie componenten beschikt, kunt u nadenken over wat voor soort infrastructuurplatform u in uw bedrijf heeft.
Infrastructuurplatform
Het punt is niet dat elk bedrijf over een reeks uiteenlopende tools beschikt.
Het punt van een infrastructuurplatform is dat alle teams deze tools gebruiken en samen ontwikkelen.
Het is duidelijk dat er aparte teams zijn die verantwoordelijk zijn voor de ontwikkeling van individuele onderdelen van het infrastructuurplatform. Maar tegelijkertijd draagt elke ingenieur verantwoordelijkheid voor de ontwikkeling, prestaties en promotie van het infrastructuurplatform. Op intern niveau wordt het een gemeenschappelijk instrument.
Alle teams ontwikkelen het infrastructuurplatform en behandelen het met zorg als hun eigen IDE. In je IDE installeer je verschillende plugins om alles lekker snel te maken, en configureer je sneltoetsen. Wanneer je Sublime, Atom of Visual Studio Code opent, stromen de codefouten binnen en besef je dat het helemaal onmogelijk is om te werken, je voelt je meteen verdrietig en rent om je IDE te repareren.
Behandel uw infrastructuurplatform op dezelfde manier. Als u begrijpt dat er iets mis mee is, laat dan een verzoek achter als u het zelf niet kunt oplossen. Als er iets eenvoudigs is, bewerk het dan zelf, stuur een pull-verzoek, de jongens zullen het overwegen en toevoegen. Dit is een iets andere benadering van engineeringtools in het hoofd van de ontwikkelaar.
Het infrastructuurplatform zorgt voor de overdracht van het artefact van de ontwikkeling naar de klant, met voortdurende kwaliteitsverbetering. Het IP-adres is geprogrammeerd met een reeks verhalen die gebeuren met de code in productie. In de loop van de jaren van ontwikkeling zijn er veel van deze verhalen verschenen, sommige zijn uniek en hebben alleen betrekking op jou - ze kunnen niet worden gegoogled.
Op dit punt wordt het infrastructuurplatform uw concurrentievoordeel, omdat er iets in is ingebouwd dat niet in de tool van de concurrent zit. Hoe dieper uw IP, hoe groter uw concurrentievoordeel in termen van Time-to-market. Verschijnt hier Probleem met leveranciersvergrendeling: Je kunt het platform van iemand anders nemen, maar als je de ervaring van iemand anders gebruikt, zul je niet begrijpen hoe relevant dit voor jou is. Ja, niet elk bedrijf kan een platform als Amazon bouwen. Dit is een moeilijke lijn waarbij de ervaring van het bedrijf relevant is voor zijn positie in de markt, en je kunt daar geen leveranciersslot gebruiken. Ook dit is belangrijk om over na te denken.
Het schema
Dit is een basisdiagram van een infrastructuurplatform dat u zal helpen bij het opzetten van alle praktijken en processen in een DevOps-bedrijf.
Laten we eens kijken waar het uit bestaat.
Resource-orkestratiesysteem, dat CPU, geheugen, schijf levert aan applicaties en andere services. Bovendien - diensten op laag niveau: monitoring, logging, CI/CD Engine, opslag van artefacten, infrastructuur als systeemcode.
Diensten op een hoger niveau: database als een service, wachtrijen als een service, Load Balance als een service, afbeeldingsgrootte wijzigen als een service, Big Data-fabriek als een service. Bovendien - pijplijn die voortdurend gewijzigde code aan uw klant levert.
Je krijgt informatie over hoe jouw software werkt bij de klant, wijzigt deze, levert deze code opnieuw aan, krijgt informatie - en zo ontwikkel je voortdurend zowel het infrastructuurplatform als je software.
In het diagram bestaat de leveringspijplijn uit vele fasen. Maar dit is een schematisch diagram dat als voorbeeld wordt gegeven - het is niet nodig om het één voor één te herhalen. Fasen staan in wisselwerking met services alsof het services zijn; elke bouwsteen van het platform draagt zijn eigen verhaal met zich mee: hoe bronnen worden toegewezen, hoe de applicatie wordt gelanceerd, hoe deze met bronnen werkt, wordt gemonitord en verandert.
Het is belangrijk om te begrijpen dat elk onderdeel van het platform een verhaal met zich meedraagt, en jezelf af te vragen welk verhaal deze steen met zich meedraagt. Misschien moet hij worden weggegooid en vervangen door een service van derden. Is het bijvoorbeeld mogelijk om Okmeter te installeren in plaats van een steen? Misschien hebben de jongens deze expertise al veel meer ontwikkeld dan wij. Maar misschien ook niet - misschien hebben we unieke expertise, we moeten Prometheus installeren en verder ontwikkelen.
Oprichting van het platform
Dit is een complex communicatieproces. Als je basispraktijken hebt, begin je met de communicatie tussen verschillende ingenieurs en specialisten die eisen en normen ontwikkelen, en deze voortdurend veranderen in verschillende tools en benaderingen. De cultuur die we hebben in DevOps is hierbij belangrijk.
Met cultuur is alles heel eenvoudig - het gaat over samenwerking en communicatieDat wil zeggen, het verlangen om met elkaar op een gemeenschappelijk terrein te werken, het verlangen om samen één instrument te hanteren. Er is hier geen rocket science - alles is heel eenvoudig, banaal. We wonen bijvoorbeeld allemaal in de ingang en houden deze schoon - wat een cultuurniveau.
Wat heb je?
Nogmaals, vragen die je jezelf kunt stellen.
Is het infrastructuurplatform specifiek? Wie is verantwoordelijk voor de ontwikkeling ervan? Begrijpt u de concurrentievoordelen van uw infrastructuurplatform?
Deze vragen moet je jezelf voortdurend stellen. Als iets kan worden overgedragen aan diensten van derden, moet het worden overgedragen; als een dienst van derden uw beweging begint te blokkeren, moet u een systeem in uzelf bouwen.
DevOps dus...
... dit is een complex systeem, het moet het volgende hebben:
- Digitaal product.
- Bedrijfsmodules die dit digitale product ontwikkelen.
- Productteams die code schrijven.
- Continuous Delivery-praktijken.
- Platformen als een service.
- Infrastructuur als een service.
- Infrastructuur als code.
- Afzonderlijke praktijken voor het behouden van de betrouwbaarheid, ingebouwd in DevOps.
- Een feedbackpraktijk die alles beschrijft.
U kunt dit diagram gebruiken en daarin benadrukken wat u al in een of andere vorm in uw bedrijf heeft: is het ontwikkeld of moet het nog ontwikkeld worden.
Over een paar weken is het voorbij . als onderdeel van RIT++. Kom naar de conferentie, waar je veel toffe reportages vindt over Continuous Delivery, infrastructuur als code en DevOps-transformatie. , laatste prijsdeadline is 20 mei
Bron: www.habr.com