


RESAN
Vår strävan är att förenkla och leda vägen till ett effektivt och värdeskapande datacenter. Därför har vi utifrån vår erfarenhet tagit fram en modell för hur ni steg för steg tar er till ett automatiserat datacenter med självbetjäning. För varje steg har vi tagit fram länkar, webbinarier och tips som lotsar er framåt. Enjoy!
Mål med denna utvecklingsfas
-
Att förstå hur snabbt grundläggande kunskap inom automation kan förenkla vardagen för din verksamhet
-
Att förstå fördelarna med att låta ett system för Source of truth-ligga till grund för såväl automation som dokumentation
-
Möjligheterna som erbjuds via molnleverantörernas samt de befintliga tekniska plattformarnas olika API:er ska vara utredda
-
Personalen ska vara ivrig att börja implementera arbetsflöden och lösningar baserat på vad man lärt sig
Resurser
-
Exempel på hur Ansible kan användas för att skapa en ny VM i vSphere
-
Bloggpost om AWS och Terraform
-
Sebastian visar hur man kan managera ett modernt datacenter
-
Introduktion på DevNet om kod och API:er
-
Hur man kan administrera Cisco Nexus-switchar genom API
Ytterligare information
-
Introduktion till Docker
-
Genomgång av DCIM/IPAM-systemet Netbox
-
Installera Netbox såhär
-
Kolla hur Terraform kan användas ihop med Netbox via denna providern
"Hur kan jag hjälpa våra utvecklare när deras containers inte når våra on prem-system?"

Rickard Östman har jobbar mycket med olika typer av automationslösningar, både i datahallen och i molnet. Han hjälper gärna till med idéer om vart ni bör fokusera för att så snabbt som möjligt kunna skörda resultat.
Mål med denna utvecklingsfas
-
Att ha beslutat vilket som är det föredragna automationsverktyget för er organisation, samt vad det erbjuder för möjligheter (och begränsningar)
-
Senior personal ska utan problem kunna överblicka processer och kunna utvärdera om en uppgift är avancerad eller enkel att automatisera, i.e. att kunna hitta low hanging fruit.
-
Personalen ska vara bekväm med att hämta information ifrån tillgängliga datakällor, och kunna använda denna information som underlag i enklare, automatiserade uppgifter
-
Personalen ska instinktivt börja fundera på om det finns ett enklare och effektivare sätt att sköta sina arbetsuppgifter
-
Resurser
-
Introduktion till GIT, vilket är oumbärlig kunskap för alla som behöver göra någon form av versionshantering av exempelvis konfiguration eller källkod
-
Hank från Cisco berättar om hur CI/CD kan användas för att managera nätutrustning
-
Hur man kan låta Ansible generera konfigurationsfiler baserat på data ifrån Netbox
-
Infrastructure as Code sammanfattat av The OpenSource show.
Ytterligare information
-
Introduktion till Docker Compose
-
Förteckning över utbudet av Ansible-moduler
Miradot finns alltid tillgängliga att ta dig vidare. Vi erbjuder tjänsten Kickstart för att snabbt komma igång, tillsammans med en rad andra tjänster.
"Utvecklarna får ofta vänta på nya brandväggsregleroch vid varenda lansering blir det jättebråttom"

Johan Radivoj berättar gärna om hur populära tekniker som t.ex. Github Actions kan förenkla utrullningen av er applikation samtidigt som ert nät kan se till att rätt säkerhetspolicy används och att zero-trust kan upprätthållas utan kompromisser.
Mål med denna utvecklingsfas
-
Personalen ska vara fullständigt införstådda med varför man inte längre kan genomföra vissa förändringar manuellt, eftersom delar av konfigurationen nu helt och hållet ägs av automatiserade system
-
Personalen ska jobba mer strukturerat vid change, t.ex att en gemensam pipeline ska exekvera ett automationsverktyg först efter att en ändring granskats av en kollega
-
Utvecklarna ska bli tillräckligt bekanta med infrastrukturen för att veta exakt hur deras applikation ska deployas för att på bästa sätt kunna dra nytta av den infrastruktur och övervaknings som finns på plats
Resurser
-
Sebastian visar hur ett CI-flöde kan låta icke teknisk personal göra förändringar i ett datacenter
-
AWS-exempel över hur man kan integrera en Slack-kanal i en deployment pipeline för t.ex peer reviews
-
Exempel på hur pyATS kan användas för att säkerställa att en förändring i nätet verkligen genomfördes på det sätt det var tänkt
Ytterligare information
-
Demo över hur kubernetes kan samverka med ACI
-
Cisco Devnets ACI+Kubernetes-sandbox
Hjälp?
Miradot hjälper gärna till med utbildning för att låta er personal känna sig trygg de förändringar som ett moderniserade arbetssätt kan komma att innebära.
"Ibland kraschar vår applikation i produktion trots att utvecklarna kört sina tester"

Det är inte sällsynt att sättet utvecklarna testar sin kod behöver förändras i samband med att man flyttar in i molnet. Johan Radivoj berättar gärna hur man ska gå tillväga för att sätta upp en enkel och effektiv CI/CD-pipeline som förenklar utvecklarnas liv samtidigt som den hjälper dem att t.ex förhålla sig till de riktlinjer som gäller i er säkerhets-policy.
"Mina enkla uppgifter har blivit jättesvåra!"

Utöver Miradots webinarserie finns även våra populära utbildningar. Johan Radivoj är specialist på CI/CD-strategier, och han hjälper gärna er personal att identifiera och övervinna eventuella lärotrösklar. Alla ska kunna åtnjuta lyxen av att ha en miljö som arbetar emot samma mål som ni själva!
Steg 2 - Redo för automation
Molnstrategin finns på plats och används. IT-avdelningen har insyn i hur resten av organisationen arbetar med molnet, och man nyttjar verktyg som Terraform och Ansible för att hantera molnresurser. Man har skapat kommunikation mellan det egna datacentret och molnet samt kommit överens om en modell för hur molntjänster och det egna datacentret skall samexistera. I det egna datacentret har man en uppfattning om vilka befintliga system som skulle kunna manageras via API:er. Man har börjat använda ett system för DCIM (Datacenter Infrastructure Manager) som kanske i dagsläget främst används för dokumentation, men systemet har API:er och kommer därför kunna stötta automationsverktyg med så kallad Source of truth-information.
Standardiseringsarbetet har påbörjats och nya installationer sker enligt en dokumenterad rutin. Molnleveranser sker snabbt men det egna datacentret präglas fortfarande av långsamma leveranser och reaktiv felsökning, och fortsätter därför att bromsa verksamheten.
Risker
-
Vissa leveranser går snabbare då de nu utförs med script, men då dessa typiskt körs direkt på personalens datorer finns risken att konflikter uppstår, och på grund av bristande spårbarhet kan sådana situationer utgöra ett hot mot driftsäkerheten
-
Fortsatta risk för mänskliga fel då de flesta leveranser fortfarande sker manuellt
Mognadsgrad
Låg. Säkerheten har förbättrats avsevärt genom ett tydligt ägandeskap av molninfrastruktur och ett standardiserat arbetssätt. Det har skapats ett fundament och en vision för hur man ska ta datacentret till nästa nivå, vilket kraftigt kommer underlätta den fortsatta utvecklingen emot en framtid där personalen fokusera mer på verksamhetsnytta än eldsläckning.
Steg 3 - Ett delvis automatiserat datacenter
Man har bekantat sig med nya verktyg och automatiserat ett antal tidskrävande och repetitiva uppgifter. Datacentret hanteras delvis via CLI/UI och med scripts/playbooks, men nu börjar även verktyg för CI/CD komma in i bilden.
Effektivare förändringar och snabbare leveranser börjar frigöra tid som istället investeras i att skapa affärsvärde genom att personalen kan lära sig mer om automation och DevOps. Man har nu kommit över en tröskel där personalen i större utsträckning kan iterera vidare över sina egna processer utan behov av extern kompetens. IT-avdelningen är till viss del fortfarande reaktiv, men innovation kommer nu från IT och utvecklarna i ett gemensamt forum.
Ett frö till en tjänstekatalog har såtts, där tjänster som t.ex Kubernetes-kluster erbjuds både on-prem och i molnet, och det finns en plan för hur legacy-system skall livscykelhanteras.
Spårbarhet och återställningar av tidigare konfiguration är fortfarande ett problem, men övervakning och dokumentation är nu en del av automationen. Teknisk personal har hittat inspiration och börjat experimentera med nya system och arbetssätt. Viss workload har migrerats ut till molnet men kan kommunicera med system on-prem. Säkerheten har höjts genom att standardiserade leveranser stärkt förståelsen för hur applikationerna hänger ihop, vilket har lett till att segmentering har kunnat påbörjas.
Risker
-
Delar av personalstyrkan kan känna att de tappar greppet om hur de nya processerna fungerar och halkar därmed efter i utvecklingen
-
Förändringar kan nu öka i omfattning då de automatiserade processerna möjliggör att de sker i snabbare takt än tidigare, och utan ordentlig testning så kan detta leda till störningar
-
Den manuella administration som fortfarande förekommer handlar ofta om de uppgifter som är svårast att automatisera, och utan tydlig spårbarhet kan sådana förändringar utgöra ett hot mot driftsäkerheten
Mognadsgrad
Medel. Nyttan med automation börjar visa sig för resten av verksamheten, som märker av snabbare leveranser och färre fel.
Steg 4 - Automatiserat datacenter
Samtlig utrustning i datacentret går att konfigurera programmatiskt och man har nu uppnått ett s.k. mjukvarudefinierat datacenter (SDDC). Man är bekväm med sitt automationstänk och tvärfunktionella grupper har skapats för att ytterligare vässa befintliga automationsflöden, samt hitta nya där behov finnes.
Förändringar sker uteslutande baserat på strukturerat underlag från en överenskommen source of truth, och utförs av CI/CD-pipelines. Detta i kombination med att förändringar genomgår en godkännandeprocess genom t.ex en Gitlabs Merge request medför att man får tydlig spårbarhet, vilket kraftigt underlättar felsökning vid en eventuell störning kopplad till en förändring. När man nu uppnått denna nivå av standardisering i processerna har det också blivit självklart att först låta förändringar rullat ut i bolagets testmiljö och där utföra tester innan förändringen genomförs i produktionsmiljön.
Alla leveranser är standardiserade och levereras felfritt och snabbt, både on-prem och i molnet. Produktägare är nöjda med hur snabbt och enkelt det går att lansera nya tjänster. Via intelligenta plattformar och system har man full visibilitet oavsett om det är en container on-prem eller en virtuell maskin i AWS. Segmenteringsarbetet är slutfört. Arbetslast kan både lastdelas till molnet för att hantera belastningstoppar eller för att hantera failover-scenarion. Arbetstid används i hög utsträckning till värdeskapande uppgifter som t.ex förbättra och utveckla tjänster, etablera feedback-loops och lyssna in vad verksamhetens olika förgreningar har för utmaningar för att i sin tur kunna adressera dessa.
Risker
-
Kapacitetsplanering blir svårare när konsumtionen blir lättare
Mognadsgrad
Hög. Man har en innovativ kultur med fokus på att leverera affärsvärde. Datacentret och IT-avdelningen är inte längre en flaskhals utan istället en pådrivande faktor i utvecklingen. Utvecklarna är nöjda och verksamheten ser IT som möjliggörare.
"Byggena tar jättelång tid och vi stöter på buggar lite väl ofta trots alla tester som körs.

Har du en pipeline som du tror skulle kunna fungera bättre och köras snabbare med hjälp av lite modernare tekniker? Vill du dessutom få en second opinion på hur ni tänkt genomföra era integrationstester? Perfekt. Skicka ett mail till Johan!
Mål med denna utvecklingsfas
-
Personalen ska börja känna att det är svårt att sysselsätta sig själv med leveransrelaterade arbetsuppgifter. Inte heller underhåll av infrastrukturen ska behöva särskilt mycket daglig översyn.
-
Personalen ska aktivt kunna samverka med bolagets utvecklare för att tillsammans kunna hitta nya värdeskapande tjänster och lösningar.
-
Man lägger arbete på att ännu bättre paketera och tillgängliggöra befintliga och nya tjänster, t.ex via en portal.
-
Kostnadsberäkningar börjar göras för varje tjänst och placering vilket gör att man fördelar arbetslast dit den fungerar bäst prestandamässigt och ekonomiskt.
Resurser
-
Introduktion till Scalr
Bolagets IT-infrastruktur är nu helt automatiserad, och utvecklarna äger genom sitt resursbehov allt ifrån virtuella resurser till fysiska servrar i datacentret. De vet exakt hur de ska gå tillväga för att livscykelhantera sina applikationer och låta allokera de resurser som behövs. De kan enkelt överblicka hur deras applikation mår och hur kommunikationen fungerar över infrastrukturens olika ingående domäner. Dokumentation och övervakning ingår, så att respektive applikationsägare får information om tjänsten skulle drabbas av en störning. Om applikationen inte längre nyttjas blir ägaren uppmärksammad om detta, och denne kan på egen hand återlämna de resurser som nyttjats.
Organisationens inköpare kan följa resursnyttjandet i såväl moln som det egna datacentret, och kan även göra prognoser över när nya investeringar behöver ske. IT-avdelningen kan nu fokusera på att utveckla värdeskapande tjänster för bolagets olika avdelningar, samt proaktivt utvärdera de nya tekniker som marknaden tyr sig till, i syftet att kontinuerligt kunna förbättra den egna verksamheten.
Risker
-
Tristess hos IT-avdelningen :)
Mognadsgrad
Väldigt hög.
Steg 5 - Självbetjäning
Nu då?
Vi vet att allt ovan inte stämmer in hos just er. Vi vet att det inte finns ett recept som fungerar för alla. Vi vet dock att alla behöver inspiration, riktlinjer och någonstans att vända sig om man kör fast. Därför tog vi fram denna modellen tillsammans med tjänster som på ett enkelt sätt fungerar som inspiration och ger ett förutsägbart sätt förvandla er vision till verklighet.
KICKSTART
SINGLE TASK
MIGRATION
PROJEKT
Steg 1 - Det klassiska datacentret
Datacentret präglas av tekniker som VLAN, fysiska brandväggar och virtualisering. Många av servrarna hanteras individuellt och det finns flera system med otydligt ägandeskap eller som högst en person i gruppen vet hur de fungerar. Eftersom utvecklingen och administrationen är manuell, tidskrävande och ineffektiv har utvecklarna börjat söka sig till molnet för att snabba upp sina leveranser, något som till synes har skett utan övergripande strategi. Dokumentationen stämmer inte alltid med verkligheten och övervakningen för nya tjänster och hårdvara missas ibland. IT-avdelningar tvingas ofta arbeta reaktivt och blir därmed oftare mottagare av önskemål än att de kommer med egna förslag på vad som bidrar till ökat affärsvärde.
Risker
-
Beroenden mot nyckelpersoner
-
Verksamheten bromsas av IT-avdelningen
-
Känsligt för mänskliga fel som orsakar nedtid
-
Okontrollerad och bristfällig säkerhet
-
Otåliga utvecklare börjar använda osanktionerade tjänster, som i sin tur leder till skugg-IT
Mognadsgrad
Låg. IT-avdelningen blir ofta en bromskloss på grund av manuellt arbete med mycket eldsläckning. Affärsmålen är inte synkroniserade med målen för IT-avdelningen, vilket gör budgetering och beslut svåra.