Devops eller dø!
0 likes1,706 views
Kontinuerlige Leveranser og DevOps er praksiser som lar virksomheter dytte idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Kvaliteten på det som leveres øker i takt med hyppigheten på leveransene. Tettere samarbeid mellom drift og utvikling bidrar til at alle trekker i samme retning. Det er forretning som bestemmer når noe skal ut i produksjon, ikke IT. Vi er vitne til et av de største paradigmeskiftene innen IT i vår tid. De som ikke transformerer sine IT-organisasjoner risikerer å bli etterlatt for å dø. Stein Inge vil i dette foredraget forklare hva DevOps og Kontinuerlige Leveranser innebærer og hvorfor det er så viktig å ikke bli sittende på gjerdet. Han vil også presentere egne erfaringer med å levere kontinuerlig.
Devops eller dø!
- 2. – Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014 “Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival.”
- 3. – Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014 “Those not transforming their IT organizations risk being left behind, missing out on one of the most disruptive and innovative periods in technology.”
- 4. - Gene Kim “IT is the factory floor of this century, and not just for manufacturing companies. IT is increasingly how all businesses acquire customers and deliver value to them.” IT er ikke lenger en tjeneste som støtter opp under forretning. IT er ansvarlige for hele virksomhetens suksess.
- 7. DevOps er ikke en stillingsbeskrivelse.
- 9. DevOps er ikke verktøy.
- 10. DevOps er …
- 11. - Barton George, Dell “…it is getting developers and operations folk to work closely together to benefit the business.”
- 12. Drift Utvikling Jeg vil ha stabilitet Jeg vil ha endring
- 13. Leveranse
- 15. , men så er det litt de andre tingene også…
- 16. - WhatIs.com “DevOps is the blending of tasks performed by a company's application development and systems operations teams.” Kryssfunksjonelle team betyr ikke at alle skal kunne gjøre alt. Drift krever en helt egen spisskompetanse. På samme måte som utvikling. Oppgavene flyter over i hverandre og alle er på samme team. Ingen overleveringer.
- 17. - Gene Kim “…the practices that enable fast flow of features into production, while preserving world-class availability, stability, security, etc.” Praksiser, verktøy og flinke folk som kan sørge for en taktfast og rask flyt av verdifull programvare til produksjon. Uten at det går ut over tilgjengelighet, stabilitet, sikkerhet osv. Da trenger du eksperter - Devopser. Og du trenger nye verktøy.
- 18. Hva er Kontinuerlige Leveranser? DevOps gjør det mulig å virkelig kunne levere kontinuerlig.
- 19. Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi. Første prinsippet i Smidigmanifestet. Hvorfor? Ikke bruke tid på ting som ikke gir. Vite at det vi lager er verdifullt for brukerne så fort som mulig. Kunne reagere på endringer i forutsetninger raskest mulig. Kunne tilfredsstille brukerne med ny funksjonalitet og endringer kontinuerlig. DevOps-bevegelsen, i tillegg til å levere kontinuerlig, skal opprettholde tilgjengelighet, stabilitet, sikkerhet, ytelse osv. i verdensklasse. Utvider fra å se på applikasjonene - til å se på hele systemet inkludert infrastruktur.
- 20. - Martin Fowler (http://martinfowler.com/bliki/ContinuousDelivery.html) “Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” Forretning skal kunne si at koden, akkurat slik den er nå, skal deployes til produksjon på et blunk - og ingen skal lee et øyelokk. Ingen panikk. Dagligdags. Gir også høyere kvalitet. Den eneste realistiske testingen skjer i produksjon.
- 21. Prodsettinger har vært ansett som risikable.
- 22. MANGE LINJER KODE LAAAAANG TID Fordi prodsetting er så risikofyllt gjør man det sjeldent og bruker masse tid på testing. Når det treffer produksjon skjer det som regel et eller annet, og det er vanskelig å finne ut av hva som er feilen. Når det er mye som er endret er det mye som kan gå galt.
- 23. KONTINUERLIGE LEVERANSER FÅ ENDRINGER Logisk konklusjon; lever oftere. Rulle ofte, og lite om gangen; mindre som kan gå galt. Lettere å lokalisere feil. Lett å rulle tilbake - eller frem som er å foretrekke (fiks, deploy på nytt). Får raskere verifisert at det vi lager faktisk er riktig ved å teste på reelle brukere. Lett å skifte kurs.
- 24. For tregt. For mye “greier”. Alt for mange “sikkerhetsmekanismer”. Sikrer ikke bedre enn å virkelig levere kontinuerlig.
- 25. Test Utv Kan ikke ha en egen testavdeling. Kan ikke overlevere det vi lagar til en annen avdeling og vente på at de skal bli ferdige med testinga. Test sjøl og på reeelle brukere. Myte at det ikke bør være de samme som har laget noe som skal teste dette noe. Du må vite hvordan noe er implementert for å teste det skikkelig.
- 26. “Developers carry beepers” Definition of DevOps Utvikleren prodsetter selv det han lager. Tar dermed større ansvar. Sørger for tilstrekkelig testing og at prodsetting vil fungere. Har ingen andre å skylde på.
- 27. Krav Konsept Analyse Design Test Drift Realisering Eksempel på prosjektmetodikk som er utbredt i bransjen. Prince II. Smidig er en liten del av gjennomføringsfasen. Gevinster realiseres ikke før etter at prosjektet er levert.
- 28. Kunde Brukere The holy trinity is not is not is not is TEAM is is DevOps-team Den moderne IT-organisasjonen er lettvekts. Brukerne skal bruke softwaren. Gi verdi for de. Men det er ikke de som skal tjene penger. Det er det kunden som skal. Bør være det viktigste i hele verden, så han deltar tett sammen med teamet. DevOps-teamet skal lage den fysiske softwaren. De skal ikke finne ut av hva som skal lages. Det er det brukerne som skal. Skal sikre at kunden tjener penger. Lynraske iterasjoner. Lage noe — teste på brukerne — bygge ut i bredden eller forkaste. Skalerer i store organisasjoner. Satelitter med autonome team.
- 29. «The State of DevOps Report», juni 2014. Det største og mest omfattende vitenskapelige DevOps-studiet så langt.
- 30. Demografi 9200+ Respondenter fra 110 land, på tvers av bransjer 9,200+ respondener fra 110 land, på tvers av alle bransjer.
- 31. Størrelse på bedriftene 27% av respondentene er fra virksomheter med 500 til 9999 ansatte Virksomheter i alle størrelser. - 27 % med 500 til 9,999 ansatte - Ikke bare de store WebOps sjappene som: Google, Amazon, Etsy, etc.
- 32. Størrelse på infrastrukturen 51% av respondentene sa de hadde < 500 Servers - Majoriteten har færre enn 500 servere. Største prosentandel har under 100. - Kun 13 % har mer enn 5,000 servere - DevOps er ikke bare for store websjapper. - Kombinert med bransjedekning sier det mye om hvilken ekspansjon dette har hatt.
- 33. Avdelinger 16% identifiserte seg som DevOps Avdeling - 30% av respondentene var fra drift. - 29% var fra utvikling. - 16% av respondentene var i en DevOps-avdeling(!).
- 34. Fjorårets rapport Mer smidige og robuste: • deployer kode 30 ganger oftere. • med 50 prosent færre feil.
- 35. Årets rapport Ting som betyr noe for businessen: • Lønnsomhet • Markedsandeler • Produktivitet Sammenhengen mellom: • Organisatorisk ytelse, • IT-ytelse og • DevOps-praksiser.
- 36. DevOps er Smidigere 30x 8000x hyppigere deployments raskere ledetid enn konkurrenten
- 37. DevOps er mer robust 2x 12x suksessrate ved endringer raskere mean time to recover (MTTR)
- 38. vekst i markedsverdi i løpet av 3 år 2x DevOps vinner større sannsynlighet for å overgå lønnsomhet, markedsandel og produktivitetsmål 50% Foreløpige funn tilsier at de har fått et 50% forsprang på konkurrentene over 3 år - basert på de virksomhetene som oppga navn på virksomheten og som var børsnotert. Færre enn 400 virksomheter av de 9200. Dette er noe de vil se nærmere på i neste års undersøkelse.
- 39. Toppindikatorer for IT Performance • Peer-review av produksjonsendringer (versus ekstern endringsakseptanse). • Versjonskontroll av alle produksjonsartefakter. • Proativ monitorering av produksjonsmiljøet. • Kultur med høy grad av tillit, og klima for læring. • Vinn-vinn-vinn mellom Dev, Ops og Sikkerhet. • Høy jobbtilfredshet.
- 40. Jobbtilfredshet er #1 forklaring på hvor bra en organisasjon gjør det!
- 41. Overaskende (?) funn • Versjonskontroll av miljøet er viktigere enn versjonskontroll av koden. • Å kunne statistikk har aldri vært så viktig. • Om du har en integrasjons- eller stabiliseringsfase har null påvirkning på IT performance. • Peer review er mer effektivt enn CAB. • DevOps-praksiser påvirker virksomhetens suksess. • Feilrate påvirker ikke IT performance lenger (!). • Å lage DevOps team og å gi folk DevOps-titler gir suksess i praksis. Versjonskontroll av miljøet er viktigere enn versjonskontroll av koden! Hypotese; flere konfigurerbare deler i plattformen. Statistikk på alt som skjer. Feedback på systemet som et hele. Peer review vil garantert øke throughput, men man kunne trodd at det ville forringe stabilitet. Not so. DevOps-praksiser og IT-performance påvirker hvordan hele organisasjonen yter. DevOps er ikke bare IT. Det er IT-praksis. Blir lagt merke til utenfor DevOps-communitien. Kan ikke risikere å ignorere det lenger. Feilrate påvirker ikke IT performance lenger. Teori; dagens infrastruktur er bygd for å holde seg oppe. Automatiserer tester og bruker chaos monkeys i produksjon. Hot-fikser teller ikke som ordentlige feil lenger? Å lage DevOps team og å gi folk DevOps-titler gir suksess i praksis.
- 42. DevOps i Norge - attention 600+ medlemmer 50/50 driftere og utviklere DevOps-track I tillegg veldig godt representert på andre konferanser. Oslo Puppet Meetup Docker Oslo Elasticsearch Oslo (Redpill Linpro) (Redhat Norway)
- 43. DevOps i Norge - utbredelse? ?
- 44. One-click deploy. Helt team. PO, Salg, Brukerdialog, Utvikling, drift. Utviklere har tilgang til produksjon. Verdi for forretningen viktigst. Kunden er involvert i det daglige arbeidet. Det viktigste kunden kan foreta seg.
- 45. • ≈ 11 utviklere fra BEKK • ≈ 10 salg, produkt, marked fra Posten • “Startup-ish” • Helt team • Selvorganisert og kryssfunksjonelt. • Har “kuttet alt smidig” • Pull not push • Prodsetter kontinuerlig (one click) • Nedetidsfri deploy • Automatiserer “alt” • Prodsetter uferdig funksjonalitet • Feature toggles • Velger teknologi selv • Open Source • “Løs arkitektur” (REST) • DevOps • Monitorering • Utviklere har beredskap • Infrastruktur som kode • Alt i versjonskontroll • Kontinuerlig integrasjon • Synlighet og transparens Er vi fremdeles Smidig? Ikke retrospekter. Ikke “tradisjonell Kanban” (ikke wip). “Ikke planlegging”. Ingen “story points”. Ingen timebokser. Ingen releaseplan. Ingen burndown. Ingen måling av “velocity” “Ingen” frister. Ingen Scrum Master. Tillater spesialisering. “Avslappede” brukerhistorier. Kontinuerlig forbedring! (Vite hva det betyr! Kan ikke lese deg til det.)
- 47. “Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival.” – Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014
- 48. TAKK FOR MEG! Stein Inge Morisbak Fagleder Kontinuerlige Leveranser og DevOps [email protected] @steinim http://open.bekk.no/