SvĂ„rt att fĂ„nga det viktigaste nĂ€r man talar om DevOps? Vi har samlat tydliga analogier, slĂ„ende formuleringar och expertrĂ„d som hjĂ€lper Ă€ven icke-specialister att förstĂ„ kĂ€rnan. I slutet fĂ„r du en bonus â egna DevOps-erfarenheter frĂ„n Red Hats medarbetare.
Begreppet DevOps uppstod för 10 Är sedan och har gÄtt frÄn att vara en hashtag pÄ Twitter till en kraftfull kulturell rörelse inom IT, en sann filosofi som uppmuntrar utvecklare att snabbare uppnÄ resultat, experimentera och gÄ framÄt genom iterationer. DevOps har blivit oÄterkalleligt kopplad till begreppet digital transformation. Men som det ofta Àr med IT-terminologi har DevOps pÄ tio Är vuxit till en mÀngd definitioner, tolkningar och missförstÄnd.
DĂ€rför hör man ofta frĂ„gor om DevOps, som: Ă€r det samma som agile? Eller Ă€r det en speciell metod? Eller Ă€r det bara en synonym för âsamarbeteâ?
DevOps omfattar mÄnga olika koncept (kontinuerlig leverans, kontinuerlig integration, automatisering etc.), vilket gör det svÄrt att sÀrskilja det centrala, sÀrskilt nÀr man Àr passionerad om Àmnet. Men denna förmÄga Àr mycket anvÀndbar, oavsett om du försöker förmedla dina idéer till chefer eller bara berÀttar om ditt jobb för familj eller vÀnner. SÄ vi lÀgger bort de terminologiska nyanserna av DevOps för att fokusera pÄ den övergripande bilden.
Vad Àr DevOps: 6 definitioner och analogier
Vi bad experter att förklara essensen av DevOps sÄ enkelt och kort som möjligt, sÄ att dess vÀrde blir tydligt för lÀsare med olika teknisk bakgrund. Som resultat av dessa samtal har vi valt de mest slÄende analogierna och formuleringarna som hjÀlper dig att utforma din berÀttelse om DevOps.
1. DevOps â en kulturell rörelse
âDevOps Ă€r en kulturell rörelse dĂ€r bĂ„da sidor (programvaruutvecklare och IT-driftsspecialister) erkĂ€nner att mjukvara inte gör verklig nytta förrĂ€n nĂ„gon börjar anvĂ€nda den: kunder, klienter, anstĂ€llda, det spelar ingen rollâ, sĂ€ger Eveline Oehrlich, senior analytiker vid DevOps-institutet. âDĂ€rför sĂ€kerstĂ€ller bĂ„da sidor gemensamt en snabb och kvalitativ leverans av mjukvara.â
2. DevOps â det som ger makt till utvecklarna
âDevOps ger utvecklare befogenhet att Ă€ga applikationer, köra dem och hantera leveransen frĂ„n början till slutâ
âVanligtvis pratar man om DevOps som en metod för att pĂ„skynda leveransen av applikationer till produktion genom att bygga och implementera automatiserade processer, sĂ€ger Jai Schniepp, direktör för DevOps-plattformar pĂ„ försĂ€kringsbolaget Liberty Mutual. â Men för mig handlar det om nĂ„got mycket mer grundlĂ€ggande. DevOps ger utvecklare befogenhet att Ă€ga applikationer eller vissa delar av mjukvaran, köra dem och hantera leveransen frĂ„n början till slut. DevOps eliminerar förvirringen kring ansvar och leder alla deltagare i processen mot att skapa en automatiserad och utvecklarstyrd infrastruktur.â
3. DevOps Àr samarbete vid skapande och leverans av applikationer
âEnkelt uttryckt Ă€r DevOps en metod för produktion och leverans av mjukvara dĂ€r alla arbetar tillsammans,â pĂ„pekar Gur Staff, president och chef för affĂ€rsautomatisering pĂ„ BMC.
4. DevOps Àr en produktionslinje
âProduktionslinjeansamling Ă€r möjlig endast om alla delar passar ihop.â
âJag skulle jĂ€mföra DevOps med en sammansĂ€ttningslinje för bilar, fortsĂ€tter Gur Staff. â IdĂ©n Ă€r att i förvĂ€g designa och tillverka alla delar sĂ„ att de senare kan sĂ€ttas ihop utan individuell justering. SĂ„dana sammansĂ€ttningar Ă€r möjliga bara om alla delar passar ihop. De som designar och tillverkar motorn mĂ„ste tĂ€nka pĂ„ hur man fĂ€ster den vid karossen eller ramen. De som tillverkar bromsar mĂ„ste tĂ€nka pĂ„ hjulen, och sĂ„ vidare. PĂ„ samma sĂ€tt bör det vara med mjukvara.â
En utvecklare som skapar affĂ€rslogik eller anvĂ€ndargrĂ€nssnitt mĂ„ste tĂ€nka pĂ„ databasen som lagrar kundinformation, pĂ„ sĂ€kerhetsmedel för att skydda anvĂ€ndardata, samt hur allt detta kommer att fungera nĂ€r tjĂ€nsten börjar betjĂ€na en stor, kanske till och med mĂ„ngmiljonpublik.â
"Att fÄ mÀnniskor att samarbeta och tÀnka pÄ de delar av arbetet som utförs av andra, istÀllet för att enbart fokusera pÄ sina egna uppgifter, Àr det största hindret som mÄste övervinnas. Om detta lyckas har ni fantastiska möjligheter till digital transformation," tillÀgger Gur Staff.
5. DevOps Àr den rÀtta kombinationen av mÀnniskor, processer och automatisering
Jayne Groll, verkstÀllande direktör för DevOps Institute, föreslog en utmÀrkt analogi för att förklara DevOps. Enligt henne Àr "DevOps som ett matrecept, dÀr det finns tre huvudkategorier av ingredienser: mÀnniskor, processer och automatisering. De flesta av dessa ingredienser kan hÀmtas frÄn andra omrÄden och kÀllor: Lean, Agile, SRE, CI/CD, ITIL, ledarskap, kultur och verktyg. Hemligheten med DevOps, precis som med vilket bra recept som helst, ligger i hur man korrekt vÀljer proportioner och blandar dessa ingredienser för att öka hastigheten och effektiviteten i arbetet med att skapa och leverera applikationer."
6. DevOps Àr nÀr programmerare arbetar som ett Formel 1-team
"Racet planeras inte frÄn start till mÄl, utan tvÀrtom, frÄn mÄl till start."
"NĂ€r jag pratar om vad man kan förvĂ€nta av DevOps-initiativet, ger jag exemplet med ett NASCAR eller Formel 1-racingteam," sĂ€ger Chris Short, chef för marknadsföring av molnplattformar pĂ„ Red Hat och utgivare av nyhetsbrevet DevOpsâish. "Chefen för ett sĂ„dant team har ett mĂ„l: att nĂ„ den högsta möjliga placeringen baserat pĂ„ teamets resurser och de utmaningar de stĂ„r inför. Racet planeras istĂ€llet frĂ„n mĂ„l till start. Först sĂ€tts ett ambitiöst mĂ„l, och sedan bestĂ€ms vĂ€garna för att uppnĂ„ det. Efter det bryts de ner i deluppgifter och delegeras till teammedlemmarna."
«Hela veckan innan racet finslipar teamet pit-stopp. De trÀnar styrka och kondition för att vara i form under den utmattande racedagen. De övar pÄ samarbetet för att lösa eventuella problem som kan uppstÄ under racet. PÄ samma sÀtt bör utvecklarteamet trÀna sina fÀrdigheter för att slÀppa nya versioner frekvent. Med dessa fÀrdigheter och ett vÀl fungerande sÀkerhetssystem kan nya versioner ocksÄ slÀppas oftare i produktion. Inom detta synsÀtt innebÀr ökad hastighet ökad sÀkerhet,» sÀger Short.
«Det handlar inte om att göra 'rĂ€tt saker', â tillĂ€gger Short, â utan om att eliminera sĂ„ mĂ„nga hinder som möjligt för att nĂ„ önskat resultat. Samarbeta och anpassa er baserat pĂ„ den feedback ni fĂ„r i realtid. Var beredda pĂ„ avvikelser och arbeta för att höja kvaliteten, sĂ„ att ni minimerar deras pĂ„verkan pĂ„ mĂ„let. Det Ă€r precis detta som vĂ€ntar oss i DevOps-vĂ€rlden».
SÄ hÀr skalar du DevOps: 10 tips frÄn experterna
Enkel DevOps och massiv DevOps â det Ă€r helt olika saker. Vi kommer att berĂ€tta hur du övervinner hindren pĂ„ vĂ€gen frĂ„n det första till det andra.
För mÄnga organisationer börjar vÀgen 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 Àr detta bara en falsk glans, en illusion av framsteg, som Ben Grinnell, verkstÀllande direktör och chef för den digitala teknikavdelningen pÄ konsultföretaget North Highland, pÄpekar. Tidiga segrar ger visserligen hopp, men hjÀlper inte att nÄ det slutgiltiga mÄlet, nÀmligen massanvÀndning av DevOps i organisationen.
Det Àr lÀtt att se att en kultur av separation mellan 'vi' och 'de' formas som resultat.
"Ofta startar organisationer sÄdana pionjÀrprojekt, i tron att de banar vÀg för massanvÀndning av DevOps, utan att tÀnka pÄ om andra kan och vill följa efter, - förklarar Ben Grinnell. - Teamen som arbetar med dessa projekt rekryteras vanligtvis frÄn sjÀlvsÀkra "varjager" som har gjort nÄgot liknande pÄ andra stÀllen, men som Àr nya i er organisation. HÀr uppmuntras de att bryta och förstöra regler som Àr obligatoriska för alla andra. Det Àr lÀtt att se att det resulterar i en kultur av uppdelning i "vi" och "de", vilket hindrar överföring av kunskap och fÀrdigheter."
âDenna kulturella utmaning Ă€r bara en av anledningarna till att DevOps Ă€r svĂ„rt att skala. DevOps-team stĂ€lls inför en ökning av rent tekniska svĂ„righeter, typiska för snabbt vĂ€xande företag som har satsat pĂ„ IT-teknologier," sĂ€ger Steve Newman, grundare och styrelseordförande för Scalyr.
âI dagens vĂ€rld förĂ€ndras tjĂ€nster sĂ„ fort behovet uppstĂ„r. Det Ă€r sjĂ€lvklart fantastiskt att stĂ€ndigt implementera och lansera nya funktioner, men att koordinera denna process och lösa uppkomna problem Ă€r en riktig huvudvĂ€rk, - tillĂ€gger Steve Newman. - I mycket snabbt vĂ€xande organisationer kĂ€mpar ingenjörer i tvĂ€rfunktionella team för att behĂ„lla möjligheten att spĂ„ra förĂ€ndringar och de kaskadeffekter de medför pĂ„ nivĂ„er av beroenden. Dessutom Ă€r ingenjörer lĂ„ngt ifrĂ„n glada över att bli av med denna möjlighet, och som ett resultat har de svĂ„rare att förstĂ„ kĂ€rnan i de uppkomna problemen."
Hur kan vi övervinna de svÄrigheter som beskrivits ovan och gÄ mot massanvÀndning av DevOps i stora organisationer? Experter uppmanar till tÄlamod, Àven om ert slutmÄl Àr att snabba upp programvaruutvecklingscykeln och affÀrsprocesser.
1. Kom ihÄg att förÀndringar i kulturen tar tid
Jayne Groll, verkstÀllande direktör för DevOps Institute: Enligt min Äsikt bör DevOps-utvidgningen vara lika gradvis och iterativ som agil utveckling (och i lika stor utstrÀckning beröra kulturen). BÄde Agile och DevOps fokuserar pÄ smÄ team. Men nÀr antalet och integrationen av dessa team vÀxer fÄr vi fler personer som tillÀmpar nya arbetsmetoder, och som en följd av detta uppstÄr en storskalig kulturell transformation.
2. AvsÀtt tillrÀckligt med tid för planering och val av plattform
Eran Kinsbruner, teknik evangelist pÄ Perfecto: För att skalningen ska fungera mÄste DevOps-teamet först lÀra sig att kombinera traditionella processer, verktyg och fÀrdigheter, och sedan lÄngsamt odla varje enskild fas av DevOps och stabilisera den. Allt börjar med noggrant planering av anvÀndarhistorier (user story) och vÀrdeströmmar (value stream), varefter programvaruutveckling och versionskontroll följer med hjÀlp av trunk-baserad utveckling eller andra metoder som Àr mest lÀmpliga för blandning och sammanslagning av kod.
DÀrefter följer integrations- och testfasen, dÀr en skalbar plattform för automatisering krÀvs. HÀr Àr det viktigt för DevOps-team att vÀlja rÀtt plattform som passar deras kompetensnivÄ och slutmÄl för projektet.
NÀsta fas Àr distribution i produktionsmiljö, och den mÄste vara helt automatiserad med hjÀlp av orkestreringsverktyg och containrar. Det Àr viktigt att ha virtualiserade miljöer i alla DevOps-faser (simulering av produktionsmiljö, kvalitetssÀkringsmiljö och den faktiska produktionsmiljön) och alltid anvÀnda den senaste datan för tester för att fÄ aktuella insikter. Analytik mÄste vara smart och kunna hantera stora data med snabb och effektiv feedback.
3. Befria ansvar frÄn skuldens smak
Gordon Haff, evangelist pÄ RedHat: Att skapa ett system och en atmosfÀr som tillÄter och uppmuntrar experimenterande möjliggör sÄ kallade framgÄngsrika misslyckanden inom agile-programvaruutveckling. Det betyder inte att ingen hÄlls ansvarig för misslyckanden lÀngre. Faktum Àr att det blir Ànnu enklare att faststÀlla vem som bÀr ansvaret, eftersom "att vara ansvarig" inte lÀngre innebÀr "att bli syndabock". Det vill sÀga, essensen av ansvar förÀndras kvalitativt. Fyra faktorer blir dÀrmed extremt viktiga: omfattningen av misslyckandet, tillvÀgagÄngssÀtten, produktionsprocesserna och incitamenten. (Mer om dessa faktorer kan lÀsas i Gordon Huffs artikel "DevOps lessons: 4 aspects of healthy experiments").
4. Rensa vÀgen framÄt
Ben Grinnell, verkstÀllande direktör och chef för det digitala teknikomrÄdet pÄ rÄdgivningsföretaget North Highland: "För att uppnÄ skalbarhet rekommenderar jag att man tillsammans med banbrytande projekt lanserar ett program för "röjning av vÀgen". Syftet med detta program Àr att ta bort skrÀpet som stannar kvar efter DevOps-pionjÀrerna, som förÄldrade regler och liknande, sÄ att vÀgen framÄt förblir fri."
"Ge folk organisatoriskt stöd och ge en impuls genom kommunikation som strÀcker sig lÄngt bortom pionjÀrgruppen, och fira framgÄngarna med nya arbetssÀtt brett. Utbilda de mÀnniskor som Àr involverade i nÀsta vÄg av DevOps-projekt och som À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. Gör verktygen mer demokratiska
Steve Newman, grundare och styrelseordförande för Scalyr: "Verktygen ska inte gömmas undan för folk, och de bör vara relativt enkla att lÀra sig för alla som Àr villiga att spendera tid pÄ det. Om förmÄgan att begÀra loggar endast Àr tillgÀnglig för tre personer som Àr "certifierade" att arbeta med nÄgot verktyg, kommer du alltid att ha max tre personer som kan hantera det aktuella problemet, Àven om du har en mycket stor datormiljö. Med andra ord, hÀr uppstÄr en flaskhals som kan fÄ allvarliga affÀrsmÀssiga konsekvenser."
6. Skapa optimala arbetsvillkor för teamet
Tom Clark, chef för Common Platform pÄ ITV: «Du kan göra vad som helst, men inte allt pÄ en gÄng. SÀtt stora mÄl, börja smÄtt och gÄ framÄt med snabba iterationer. Med tiden kommer ni att bygga ett rykte som ett team som lyckas, vilket gör att andra ocksÄ vill anvÀnda era metoder. Jaga inte efter att bygga ett högpresterande team. IstÀllet, skapa de bÀsta förutsÀttningarna för mÀnniskor att arbeta, och effektiviteten kommer av sig sjÀlv».
7. Glöm inte Conwayâs lag och kanban-tavlor
Logan Daigle, chef för mjukvaruleverans och DevOps-strategi pĂ„ CollabNetVersionOne: «Det Ă€r viktigt att förstĂ„ konsekvenserna av Conwayâs lag. I min fria tolkning sĂ€ger detta lag att de produkter vi skapar och de processer vi anvĂ€nder, inklusive DevOps, blir strukturerade pĂ„ samma sĂ€tt som vĂ„r organisation».
«Om det finns hög grad av splittring i organisationen, och styrning över planering, skapande och lansering av mjukvara ofta byter hÀnder, sÄ kommer effekten av skalning att vara noll eller kortvarig. Om organisationen istÀllet formar tvÀrfunktionella team kring produkter som finansieras med marknadsfokus, ökar chanserna för framgÄng dramatiskt».
«En annan viktig aspekt av skalning Àr att visa allt arbete som pÄgÄr (WIP, work in progress) pÄ kanban-tavlor. NÀr det finns en plats i organisationen dÀr mÀnniskor kan se sÄdana saker, stimulerar det samarbetet kraftigt, vilket har en positiv inverkan pÄ skalning».
8. Leta efter gamla Àrr
Manuel Pais, DevOps-konsult och medförfattare till boken 'Team Topologies': «Att ta med sig DevOps-praktiker utanför Dev och Ops och försöka tillÀmpa dem pÄ andra funktioner kan knappast kallas en optimal strategi. Det kommer onekligen att ge vissa resultat (till exempel genom att automatisera manuell styrning), men man kan uppnÄ mycket mer genom att börja med att förstÄ leverans- och feedbackprocesserna».
"Om det finns gamla Ă€rr i en organisations IT-system â procedurer och styrmekanismer som implementerades efter tidigare incidenter men har blivit irrelevanta (pĂ„ grund av förĂ€ndringar i produkter, teknologier eller processer) â sĂ„ mĂ„ste de sjĂ€lvklart tas bort eller slĂ€tas ut, istĂ€llet för att automatisera ineffektiva eller onödiga processer."
9. Skapa inte flera versioner av DevOps
Antony Edwards, produktionsdirektör pÄ Eggplant: "DevOps Àr ett vÀldigt vagt begrepp, dÀrför utvecklar varje team sin egen variant av DevOps. Och det finns inget vÀrre Àn nÀr en organisation har 20 olika versioner av DevOps som inte fungerar bra tillsammans. Det gÄr inte att varje av de tre utvecklarteamsen har sitt eget, unika grÀnssnitt mellan utveckling och produktförvaltning. Och produkter kan inte ha sina egna, unika förvÀntningar kring hur feedback hanteras nÀr de flyttas till en simulerad produktionsmiljö. Annars kommer du aldrig att kunna skala upp DevOps."
10. Predika vÀrdet av DevOps för affÀren
Steve Newman, grundare och styrelseordförande för Scalyr: "Arbeta pÄ att erkÀnna vÀrdet av DevOps. LÀr dig och tveka inte att berÀtta om nyttan av det ni gör. DevOps sparar otroligt mycket tid och pengar (tÀnk bara pÄ: mindre stillestÄnd, kortare genomsnittlig ÄterstÀllningstid), och DevOps-team bör stÀndigt betona (och predika) vikten av dessa initiativ för företagets framgÄng. SÄ kommer ni att kunna utvidga kretsen av anhÀngare och öka DevOps pÄverkan inom organisationen."
BONUS
PĂ„ Den 13 september kommer vĂ„r egen DevOps â ja, Red Hat, som programvaruleverantör, har egna DevOps-team och metoder.
VĂ„r ingenjör Mark Birger, som arbetar med utvecklingen av interna automatiseringstjĂ€nster för andra grupper inom hela organisationen, kommer pĂ„ ren ryska att berĂ€tta sin egen historia â hur Red Hats DevOps-team migrerade applikationer frĂ„n virtuella miljöer i Hat Virtualization, kontrollerade av Ansible, till ett fullt containerformat pĂ„ plattformen OpenShift.
Men det Àr inte allt:
Efter att organisationer har flyttat sina arbetsbelastningar till containrar kan traditionella metoder för appövervakning misslyckas. I den andra rapporten förklarar vi vÄr motivation till att förÀndra sÀttet vi loggar pÄ och visar pÄ den fortsatta vÀgen som har lett oss till moderna metoder för loggning och övervakning.
KĂ€lla: habr.com
