Vi pratar om DevOps på ett begripligt språk

Är det svårt att förstå huvudpoängen när man pratar om DevOps? Vi har samlat för dig levande analogier, slående formuleringar och råd från experter som hjälper även icke-specialister att komma till saken. I slutet är bonusen Red Hat-anställdas egna DevOps.

Termen DevOps har sitt ursprung för 10 år sedan och har gått från en Twitter-hashtag till en kraftfull kulturell rörelse i IT-världen, en sann filosofi som uppmuntrar utvecklare att få saker gjorda snabbare, experimentera och iterera framåt. DevOps har blivit oupplösligt kopplat till konceptet digital transformation. Men som ofta händer med IT-terminologi har DevOps under de senaste tio åren skaffat sig många definitioner, tolkningar och missuppfattningar om sig själv.

Därför kan du ofta höra frågor om DevOps som, är det samma sak som agilt? Eller är detta någon speciell metod? Eller är det bara ytterligare en synonym för ordet "samverkan"?

DevOps innehåller många olika koncept (kontinuerlig leverans, kontinuerlig integration, automation, etc.), så att dela ner det som är viktigt kan vara utmanande, speciellt när du brinner för ämnet. Men den här färdigheten är väldigt användbar, oavsett om du försöker förmedla dina idéer till dina överordnade eller bara berättar för någon från din familj eller vänner om ditt arbete. Låt oss därför lägga undan de terminologiska nyanserna av DevOps för nu och fokusera på helheten.

Vad är DevOps: 6 definitioner och analogier

Vi bad experter att förklara essensen av DevOps så enkelt och kortfattat som möjligt så att dess värde blir tydligt för läsare med alla tekniska kunskaper. Baserat på resultaten av dessa samtal har vi valt ut de mest slående analogierna och slående formuleringarna som hjälper dig att bygga upp din berättelse om DevOps.

1. DevOps är en kulturell rörelse

"DevOps är en kulturell rörelse där båda parter (mjukvaruutvecklare och IT-systemdriftsspecialister) inser att programvara inte ger verkliga fördelar förrän någon börjar använda den: kunder, kunder, anställda, inte poängen", säger Eveline Oehrlich, senior research analytiker vid DevOps Institute. "Därför säkerställer båda dessa parter gemensamt snabb och högkvalitativ leverans av mjukvara."

2. DevOps handlar om att stärka utvecklare.

"DevOps ger utvecklare möjlighet att äga applikationer, köra dem och hantera leveranser från början till slut."

"Typiskt talas DevOps som ett sätt att påskynda leveransen av applikationer till produktion genom att bygga och implementera automatiserade processer", säger Jai Schniepp, chef för DevOps-plattformar på försäkringsbolaget Liberty Mutual. "Men för mig är det en mycket mer grundläggande sak." DevOps ger utvecklare möjlighet att äga applikationer eller specifika programvaror, köra dem och hantera deras leverans från början till slut. DevOps eliminerar ansvarsförvirring och vägleder alla inblandade i att skapa en automatiserad, utvecklardriven infrastruktur.”

3. DevOps handlar om samarbete för att skapa och leverera applikationer.

"Enkelt uttryckt är DevOps ett förhållningssätt till mjukvaruproduktion och leverans där alla arbetar tillsammans", säger Gur Staf, VD och chef för digital affärsautomation på BMC.

4. DevOps är en pipeline

"Montering av transportör är endast möjlig om alla delar passar ihop."

"Jag skulle jämföra DevOps med en bilmonteringslinje", fortsätter Gur Staff. – Tanken är att designa och tillverka alla delar i förväg så att de sedan kan monteras ihop utan individuell justering. Montering av transportör är endast möjlig om alla delar passar ihop. De som designar och bygger en motor måste fundera på hur den ska monteras på karossen eller ramen. De som gör bromsarna måste tänka på hjulen osv. Detsamma borde vara sant med mjukvara.

En utvecklare som skapar affärslogik eller ett användargränssnitt måste tänka på databasen som lagrar kundinformation, säkerhetsåtgärderna för att skydda användardata och hur allt detta kommer att fungera när tjänsten börjar betjäna en stor användarpublik, kanske till och med mångmiljoner dollar. ."

”Att få människor att samarbeta och tänka på de delar av jobbet som andra gör, snarare än att enbart fokusera på sina egna uppgifter, är det största hindret att övervinna. Om du kan göra detta har du en utmärkt chans till digital transformation”, tillägger Gur Staff.

5. DevOps är den rätta kombinationen av människor, processer och automation

Jayne Groll, verkställande direktör för DevOps Institute, erbjöd en bra analogi för att förklara DevOps. Med hennes ord, "DevOps är som ett recept med tre huvudkategorier av ingredienser: människor, process och automation. De flesta av dessa ingredienser kan hämtas från andra områden och källor: Lean, Agile, SRE, CI/CD, ITIL, ledarskap, kultur, verktyg. Hemligheten med DevOps, som alla bra recept, är hur man får rätt proportioner och mix av dessa ingredienser för att öka hastigheten och effektiviteten i att skapa och släppa applikationer.”

6. DevOps är när programmerare arbetar som ett Formel 1-team

"Loppet är inte planerat från start till mål, utan tvärtom från mål till start."

"När jag pratar om vad jag kan förvänta mig av ett DevOps-initiativ, tänker jag på ett racingteam från NASCAR eller Formel 1 som ett exempel", säger Chris Short, senior manager för molnplattformsmarknadsföring på Red Hat och utgivare av DevOps' nyhetsbrev. – Ledaren för ett sådant lag har ett mål: att ta högsta möjliga plats i slutet av loppet, med hänsyn till de resurser som finns tillgängliga för laget och de utmaningar som drabbade det. I det här fallet är loppet inte planerat från start till mål, utan tvärtom från mål till start. Först sätts ett ambitiöst mål, och sedan bestäms sätt att uppnå det. Sedan bryts de upp i deluppgifter och delegeras till teammedlemmar.”

“Teamet tillbringar hela veckan innan loppet med att fullända depåstoppet. Han tränar styrketräning och konditionsträning för att hålla sig i form inför en ansträngande tävlingsdag. Tränar på att samarbeta för att lösa eventuella problem som kan uppstå under loppet. På samma sätt bör utvecklingsteamet träna upp förmågan att släppa nya versioner ofta. Har man sådan kompetens och ett väl fungerande säkerhetssystem sker lanseringen av nya versioner i produktion också oftare. I denna världsbild innebär ökad hastighet ökad säkerhet”, säger Short.

"Det handlar inte om att göra "rätt"", tillägger Short, "det handlar om att eliminera så många saker som möjligt som står i vägen för det önskade resultatet. Samarbeta och anpassa utifrån den feedback du får i realtid. Var beredd på avvikelser och arbeta för att förbättra kvaliteten för att minimera deras inverkan på framsteg mot ditt mål. Det här är vad som väntar oss i DevOps-världen.”

Hur man skalar DevOps: 10 tips från experter

Det är bara det att DevOps och mass DevOps är helt olika saker. Vi kommer att berätta hur du övervinner barriärer på vägen från den första till den andra.

För många organisationer börjar resan till DevOps enkelt och trevligt. Små passionerade team skapas, gamla processer ersätts med nya och de första framgångarna låter inte vänta på sig.

Tyvärr, det här är bara en falsk glitter, en illusion av framsteg, säger Ben Grinnell, vd och chef för digitalt på konsultföretaget North Highland. Tidiga vinster är förvisso uppmuntrande, men de hjälper inte till att uppnå det slutliga målet med utbredd användning av DevOps i hela organisationen.

Det är lätt att se att resultatet är en uppdelningskultur mellan "oss" och "dem".

"Ofta startar organisationer dessa banbrytande projekt med tanke på att de kommer att bana väg för vanliga DevOps, utan att överväga om andra kommer att kunna eller vilja följa den vägen", förklarar Ben Grinnell. – Team för att genomföra sådana projekt rekryteras vanligtvis från självsäkra "varangier" som redan har gjort något liknande på andra ställen, men som är nya i din organisation. Samtidigt uppmuntras de att bryta och förstöra de regler som förblir bindande för alla andra. Det är lätt att se att resultatet är en kultur av "oss" och "dem" som hämmar överföringen av kunskap och färdigheter."

"Och det här kulturella problemet är bara en av anledningarna till att DevOps är svårt att skala. DevOps-teamen står inför ökade tekniska utmaningar som är typiska för snabbväxande IT-first-företag”, säger Steve Newman, grundare och styrelseordförande för Scalyr.

”I den moderna världen förändras tjänsterna så fort behovet uppstår. Det är fantastiskt att ständigt implementera och implementera nya funktioner, men att koordinera denna process och eliminera problem som uppstår är en riktig huvudvärk, tillägger Steve Newman. – I mycket snabbväxande organisationer kämpar ingenjörer i tvärfunktionella team för att upprätthålla synlighet i förändring och de kaskadeffekter på beroendenivå som det skapar. Dessutom är ingenjörer inte nöjda när de berövas denna möjlighet och som ett resultat blir det svårare för dem att förstå kärnan i de problem som uppstår.”

Hur kan man övervinna de ovan beskrivna utmaningarna och gå över till massantagande av DevOps i en stor organisation? Experter uppmanar till tålamod, även om ditt slutmål är att påskynda din mjukvaruutvecklingscykel och affärsprocesser.

1. Kom ihåg att kulturförändring tar tid.

Jayne Groll, verkställande direktör, DevOps Institute: "Enligt min mening bör expansionen av DevOps vara lika stegvis och iterativ som agil utveckling (och lika beröra kultur). Agile och DevOps betonar små team. Men när dessa team växer i antal och integration, slutar vi med att fler människor anammar nya sätt att arbeta, och som ett resultat blir det en massiv kulturell omvandling.”

2. Lägg tillräckligt med tid på att planera och välja en plattform

Eran Kinsbruner, ledande teknisk evangelist på Perfecto: "För att skalningen ska fungera måste DevOps-team först lära sig att kombinera traditionella processer, verktyg och färdigheter, och sedan långsamt vårda och stabilisera varje enskild fas av DevOps. Det hela börjar med noggrann planering av användarberättelser och värdeströmmar, följt av att skriva mjukvara och versionskontroll med trunkbaserad utveckling eller andra metoder som är bäst lämpade för förgrening och sammanslagning av kod.”

”Sedan kommer integrations- och teststadiet, där det redan krävs en skalbar plattform för automatisering. Det är här det är viktigt för DevOps-teamen att välja rätt plattform som passar deras kompetensnivå och slutmålen för projektet.

Nästa fas är distribution till produktion och detta bör vara helt automatiserat med hjälp av orkestreringsverktyg och containrar. Det är viktigt att ha virtualiserade miljöer i alla stadier av DevOps (produktionssimulator, QA-miljö och faktisk produktionsmiljö) och alltid använda endast de senaste data för tester för att få relevanta slutsatser. Analytics måste vara smart och kapabel att bearbeta big data med snabb och handlingsbar feedback."

3. Ta bort skulden från ansvar.

Gordon Haff, RedHat-evangelist: "Att skapa ett system och en atmosfär som tillåter och uppmuntrar experimentering möjliggör vad som kallas framgångsrika misslyckanden inom agil mjukvaruutveckling. Det betyder inte att ingen annan är ansvarig för misslyckanden. Faktum är att det blir ännu lättare att identifiera vem som är ansvarig, eftersom "att vara ansvarig" inte längre betyder "orsaka en olycka." Det vill säga att essensen av ansvar förändras kvalitativt. Fyra faktorer blir kritiska: omfattningen av störningar, tillvägagångssätt, produktionsprocesser och incitament.” (Du kan läsa mer om dessa faktorer i Gordon Huffs artikel "DevOps-lektioner: 4 aspekter av hälsosamma experiment.")

4. Rensa vägen framåt

Ben Grinnell, vd och chef för digitalt på konsultföretaget North Highland: ”För att uppnå skala rekommenderar jag att man lanserar ett program för att röja vägar tillsammans med banbrytande projekt. Målet med det här programmet är att rensa upp skräpet som DevOps-pionjärerna lämnar efter sig, som föråldrade regler och sånt, så att vägen framåt förblir fri."

"Ge människor organisatoriskt stöd och fart genom kommunikation som går långt utöver pionjärgruppen genom att brett fira framgångarna med nya sätt att arbeta. Coacha personer som är involverade i nästa våg av DevOps-projekt och är nervösa över att använda DevOps för första gången. Och kom ihåg att dessa människor skiljer sig mycket från pionjärerna.”

5. Demokratisera verktyg

Steve Newman, grundare och ordförande för Scalyr: ”Verktyg ska inte döljas för människor och de ska vara relativt lätta att lära sig för alla som vill lägga ner tid. Om möjligheten att fråga loggar är begränsad till tre personer "certifierade" att använda ett verktyg, kommer du alltid att ha maximalt tre personer tillgängliga för att hantera problemet, även om du har en mycket stor datormiljö. Det finns med andra ord en flaskhals här som kan leda till allvarliga (affärsmässiga) konsekvenser.”

6. Skapa idealiska förutsättningar för lagarbete

Tom Clark, chef för Common Platform på ITV: "Du kan göra vad som helst, men inte allt på en gång. Så sätt upp stora mål, börja i det små och gå framåt i snabba iterationer. Med tiden kommer du att utveckla ett rykte om att få saker gjorda, så andra kommer att vilja använda dina metoder också. Och oroa dig inte för att bygga ett mycket effektivt team. Ge i stället människor med idealiska arbetsförhållanden och effektivitet kommer att följa.”

7. Glöm inte Conway's Law och Kanban-brädorna

Logan Daigle, Director of Software Delivery and DevOps Strategy på CollabNetVersionOne: ”Det är viktigt att förstå konsekvenserna av Conways lag. I min lösa omskrivning säger denna lag att de produkter vi skapar och de processer vi använder för att göra det, inklusive DevOps, visar sig vara strukturerade på samma sätt som vår organisation.”

”Om det finns många silos i en organisation, och kontrollen byter ägare många gånger när man planerar, bygger och släpper mjukvara, blir effekten av skalningen noll eller kortlivad. Om en organisation bygger tvärfunktionella team kring produkter som finansieras med marknadsfokus ökar chanserna till framgång dramatiskt.”

"En annan viktig aspekt av skalning är att visa allt pågående arbete (WIP, workinprogress) på Kanban-kort. När en organisation har en plats där människor kan se dessa saker uppmuntrar det i hög grad samarbete, vilket har en positiv inverkan på skalningen.”

8. Leta efter gamla ärr

Manuel Pais, DevOps-konsult och medförfattare till Team Topologies: "Att ta DevOps-övningar bortom Dev och Ops själva och försöka tillämpa dem på andra funktioner är knappast ett optimalt tillvägagångssätt. Detta kommer säkert att ha en viss inverkan (till exempel genom att automatisera manuell kontroll), men mycket mer kan uppnås om vi börjar med att förstå leverans- och feedbackprocesserna.”

"Om det finns gamla ärr i en organisations IT-system - procedurer och hanteringsmekanismer som implementerades som ett resultat av tidigare incidenter, men som har förlorat sin relevans (på grund av förändringar i produkter, teknologier eller processer) - så måste de definitivt tas bort eller jämnas ut, snarare än att automatisera ineffektiva eller onödiga processer.”

9. Förädla inte DevOps-alternativ

Anthony Edwards, verksamhetschef på Aubergine: "DevOps är ett väldigt vagt begrepp, så varje team får sin egen version av DevOps. Och det finns inget värre när en organisation plötsligt har 20 varianter av DevOps som inte kommer särskilt bra överens. Det är omöjligt för vart och ett av de tre utvecklingsteamen att ha sitt eget, speciella gränssnitt mellan utveckling och produkthantering. Produkterna bör inte heller ha sina egna unika förväntningar på att hantera feedback när de överförs till en produktionssimulator. Annars kommer du aldrig att kunna skala DevOps.”

10. Predika affärsvärdet av DevOps

Steve Newman, grundare och ordförande för Scalyr: "Arbeta för att erkänna värdet av DevOps. Lär dig och prata gärna om fördelarna med det du gör. DevOps är en otrolig tids- och pengarsparare (tänk bara: mindre stilleståndstid, kortare medeltid till återhämtning), och DevOps-teamen måste outtröttligt betona (och predika) vikten av dessa initiativ för affärsframgång. På så sätt kan du utöka kretsen av anhängare och öka inflytandet från DevOps i organisationen.”

BONUS

På Red Hat Forum Ryssland Våra egna DevOps kommer den 13 september – ja, Red Hat, som mjukvarutillverkare, har sina egna DevOps-team och praktiker.

Vår ingenjör Mark Birger, som utvecklar interna automationstjänster för andra grupper i hela organisationen, kommer att berätta sin egen historia på ren ryska – hur Red Hat DevOps-teamet migrerade applikationer från Hat Virtualization virtuella miljöer som hanteras av Ansible till ett fullfjädrat containerformat på OpenShift-plattformen.

Men det är inte allt:

När organisationer väl har flyttat arbetsbelastningar till containrar kanske traditionella applikationsövervakningsmetoder inte fungerar. I det andra föredraget kommer vi att förklara vår motivation för att ändra sättet vi loggar på och visa fortsättningen på den väg som ledde oss till moderna loggning och övervakningsmetoder.

Källa: will.com