Inleiding Veel organisaties zijn bezig met de implementatie van de in dit artikel genoemde methoden en technieken voor software-ontwikkeling en operationeel systeembeheer. Dit artikel geeft een korte beschrijving van die methoden en technieken om daarna een beeld te schetsen en een inschatting te geven van de mogelijke effecten hiervan met het oog op het verkorten op IT Disaster Recovery doorlooptijden. Agile Agile vormt min of meer een reactie op conventionele meer geformaliseerde software-ontwikkelmethoden. Agile wil de snelheid en creativiteit van het ontwikkelingsproces vergroten door de afstand tussen ontwikkelaars en testers te verkleinen. Software wordt ontwikkeld in korte iteraties, met veel directe mondelinge onderlinge communicatie. Targets en resultaten worden direct na elke iteratie gemeten en iedere korte iteratie moet resulteren in een werkend nieuw product. Creartiviteit en kwaliteit in de teamsamenwerking, klanttevrredenheid, de goede werking van de software en snel inspelen op veranderingen staan centraal, formaliteit en planmatigheid zijn daaraan ondergeschikt. Scrum Scrum is een manier om Agile software development te implementeren, namelijk in de vorm van een zelforganiserende ontwikkelorganisatie met compacte multidisciplinaire Scrum Teams, bestaande uit een Product Owner, Ontwikkelteam en Scrum Master. De Scrum teams leveren in een vaste timebox of Sprint (vaak een kalendermaand) iteratief, incrementele producten op. De voorgang ten opzichte van het Sprint doel wordt in dagelijkse scrums voorbesproken en tegelijkertijd ook bewaakt. De resultaten worden in Sprint reviews beoordeeld. Nieuwe kleine releases worden met Continuous Integration en Continuous Delivery processen heel snel van de ontwikkelomgeving via System Integration Test omgeving en User Acceptance Test omgeving naar de Production omgeving overgebracht, vaak via een geautomatiseerde gang zonder menselijke tussenkomst. De kans op fouten wordt waar mogelijk beperkt door eveneens geautomatiseerde tests. DevOps DevOps is een samenvoeging van de term 'developer' en 'system operator'. In traditionele Software Delivery Life Cycle was vaak sprake van silo s tussen: 1. Developers 2. Build Engineers 3. Quality Managers 4. System Integration Testers 5. User Acceptance Testers 6. Operators BCPI 2017 2
In een DevOps benadering werken deze disciplines samen in holistische teams met veel intern overleg en communicatie en met deling op grote schaal van kennis, informatie en vaardigheden. Optimalisatiedoelstellingen binnen de traditionele silo s zijn niet langer dominant. Performance doelstellingen voor de samenwerkende DevOPs organisatie als geheel komen daarvoor in de plaats. De samenwerkende teams ervaren de verbreding van verantwoordelijkheden en deling van kennis in de DevOPs organisatie vaak als erg motivereend en bevrijdend. Ontwikkelaars en beheerders leren van elkaar, delen kennis en gegevens, werken aan hetzelfde doel. Dit kan, er van uitgaande dat alle rollen binnen de DevOps omgeving een gelijkwaardige maturity level in de Lifecycle hebben bereikt, tijdverlies in de ontwikkel lifecycle aanzienlijk beperken. Doordat niet langer in traditionele IT functiescheidingen wordt gewerkt maar rollen en deskundigheden worden gecombineerd in personen wordt de efficiency bevorderd en wordt de kwaliteit en de slagkracht van de IT organisatie als geheel vaak vergroot. Virtualisatie Door virtualisatie kunnen verschillende werkomgevingen (servers, applicaties, besturingssystemen, netwerkomgevingen) logisch op onderliggende fysieke hardware worden geconfigureerd met naar keuze shared of dedicated allocatie van storage, geheugenruimte, bandbreedte en processorcapaciteit. Virtualisatie kan kostenvoordelen realiseren in de vorm van lager energieverbruik en lagere afschrijvingen, lagere beheerkosten, snellere oplossingen van storingen en vervangingen van hardware en kan betere testvoorzieningen bieden, bijvoorbeeld door gebruik te maken van configuratiesnapshots die de oude status snel kunnen herstellen. IaaS - Infrastructure as a Service Infrastructure as a Service (IaaS) combineert virtualisatie en cloud computing, waardoor infrastructuur virtueel, en vaak op basis van daadwerkelijk gebruik, kan worden aangeboden en afgenomen. IaaS omgevingen beschikken veelal over krachtige en overzichtelijke beheeromgevingen van waaruit de storage, netwerken en servers integraal kunnen worden beheerd. Door die geïntegreerde beheeropzet kunnen kennis en vaardigheden in relatie tot (het herstel van) storage, netwerken en servers worden geconcentreerd en overzichtelijker worden gedocumenteerd. De beheertools voor gevirtualiseerde omgevingen bieden veelal ook krachtige functies voor het groeperen en automatiseren van operationele beheerprocessen, van het security management, van performance management, van capacity management, et cetera, maar ook van recovery management. BCPI 2017 3
Effect van Agile en Scrum op IT Disaster Recovery doorlooptijden System Integration Tests en User Acceptance Tests vormen vaak de langst durende taken in recovery trajecten. Deze kunnen soms wel 40-50 % van de totale recovery tijd beslaan. Het effect van Agile en Scrum zal zich manifesteren in een mogelijke verkorting van deze technische en functionele tests, omdat die tests in Agile en Scrum omgevingen door de geoptimaliseerde, incrementele, iteratieve ontwikkeling veel frequenter worden uitgevoerd. Hierdoor is vaak een grotere routine opgebouwd in de planning en uitvoering van die tests en worden tests ook vaak met geprogrammeerde tests en overzichtelijke testsets ondersteund. Deze routinematige of geautomatiseerde tests die als onderdeel van Continuous Delivery worden gebruikt om nieuw opgeleverde programmatuur te testen kunnen, eventueel in aangepaste vorm, vaak worden hergebruikt bij het testen na recovery operaties, terwijl testers bovendien vaak ook meer ervaring kunnen inbrengen. Effect van DevOps op IT Disaster Recovery doorlooptijden In organisaties die DevOps hanteren voor Software Lifecycle Management kan de hersteloperatie nog verder in omvang en complexiteit afnemen doordat de traditionele scheiding tussen Developers, Enigneers, QA, Integration Testers, User Acceptance Testers en Operators geheel of gedeeltelijk is verdwenen. Door de bundeling van kennis en vaardigheden van ontwikkelaars en beheerders worden minder teams met meer deskundigheid betrokken bij de hersteloperatie en tests. De hersteloperatie wordt overzichtelijker, met minder detailtaken, minder teams en minder noodzakelijke communicatie-momenten. In een DevOps benadering zijn alle traditionele IT-vaardigheden gelijkwaardig. Incidenten bleken vaak juist hun oorsprong te hebben in de begrenzing van specialismen en vaardigheden, met als gevolg dat door extra communicatielagen tussen de traditionele IT silo s ook de probleemoplossingen vaak langer duurden. In DevOps teams kunnen medewerkers op enig moment een rol van developer hebben, vervolgens een rol van tester en tenslotte ook een rol van systeembeheerder aannemen. Ontwikkelaars die in relatie tot hun programmatuur meerdere rollen vervullen krijgen meer begrip van mogelijke aandachtspunten in de beheeromgeving en zijn daardoor meestal in staat om betere programmatuur op te leveren en eventuele problemen in de goede werking beter en sneller te analyseren en op te lossen. Dit hogere oplossende vermogen van de DevOps organisatie zal zich normaal gesproken ook vertalen naar een kortere doorlooptijd tijdens recovery operaties. Organisaties die DevOps op goede wijze hebben doorgevoerd zullen merken dat probleemoplossingen korter duren en dat het aantal incidenten in de beheerorganisatie aanzienlijk beperkt wordt. BCPI 2017 4
Effect van Virtualisatie & IaaS op IT Disaster Recovery doorlooptijden Ook ontwikkelingen op het niveau van de virtualisatielaag kunnen de recovery tijden verkorten en recovery acties vereenvoudigen. In een vérgaand gevirtualiseerde configuratie in een IaaS omgeving zal de hersteloperatie normaal gesproken overzichtelijker worden door de integratie van beheertools en doordat de traditionele scheiding tussen kennisgebieden Storage Management, Network Management, Server Management door kennisintegratie geheel of gedeeltelijk verdwijnt. Omdat gevirtualiseerde omgevingen vaak over eigen krachtige management tools beschikken, kunnen recovery taken vaak ook worden gegroepeerd en geautomatiseerd. Herstel van groepen van servers en andere IT componenten kan met scripts worden voorbereid welke bovendien vaak ook door simulaties kunnen worden getest. Door de automatisering van recovery taken kan de afhankelijkheid van individuele personen worden teruggedrongen en kunnen hersteltaken vaak sneller en soms zelfs zonder menselijke tussenkomst - worden afgerond. Afzonderlijke virtuele servers kunnen bovendien als snapshots worden gekopieerd naar storage of andere servers, servers hoeven niet from scratch te worden opgebouwd en ingericht. Virtuele servers kunnen gegroepeerd in scripts worden hersteld, gestuurd door Business Prioriteit en Technische Prioriteit. RTO s of BIA classificaties als Platinum, Gold, Silver en Bronze zullen vaak in de gescripte groeperingen van items terug te zien zijn. De grote kunst is om Business Impact Analyses voor verschillende schadescenario s met verschillende impacts elkaar te integreren en te vertalen naar deze logische groeperingen en te scripten herstelvolgordes van te herstellen servers, te herstellen IT services en IT component groepen. En om die herstellijsten te omgeven met business noodporcedures en crisis management taken. Business Continuity Management en IT Disaster Recovery Planning tools zoals BCPI R6 helpen de Business Continuity Managers en IT Service Continuity Managers om de Plan-Do-Check-Act cyclus altijd gesloten te houden. BCPI 2017 5
Samenvatting Samengevat kunnen alle genoemde methoden en technieken een positieve bijdrage leveren aan de verkorting van IT Disaster Recovery doorlooptijden. In een testsituatie zien gemiddelde doorlooptijden er zonder eventuele fouten- ongeveer als volgt uit: Initiatie, Go besluit 5 % Afsluiten en veiligstellen van productieomgevingen 15-20 % Technisch herstel productieomgeving op uitwijkconfiguratie 20-25 % System Integration Testing / User Acceptance Testing 30-45 % Afronding & Nazorg 5 % Organisaties die Agile, Scrum & DevOps doorvoeren mogen verwachten dat de recovery organisatie overzichtelijker wordt. Er zullen immers minder teams betrokken zijn, die vanwege de iteratieve opzet van Software Lifcycle Development beter geoefend zijn in het opbrengen en herstellen van werkomgevingen en met bredere deskundigheid, bredere vaardigheden en krachtiger testtools deze taken met minder kans op fouten sneller tot een goed einde kunnen brengen. Haalbare besparingen van 30-50% in testtijd, ofwel 10 tot ruim 20 % in totale recovery doorlooptijd zijn niet ireëel. Een haalbare relatieve verkorting van de totale hersteltijd met 20 % bij een test of meer bij echte calamiteiten (waarbij direct met de uitwijkoperatie wordt gestart) is uiteraard aanzienlijk. Ook van Virtualisatie en IaaS mag extra tijdswinst worden verwacht. Deze zal echter vaak iets lager uitvallen omdat het techisch herstel als zondanig vaak al minder tijd vergt dan technische en functionele tests. Ook zal hier relatief minder tijdsbesparing haalbaar zijn omdat infrastructurele IT services vaak door netwerk-, server- en database clusteringen al optimiaal geconfigureerd en/of redundant uitgevoerd zijn. De besparingen in doorlooptijd als gevolg van Virutalisatie komen met name tot uitdrukking in het gescript activeren van security, control & monitoring servers, database servers, applicatie servers, web servers en webservices gegroepeerd op volgorde van Technische prioriteit, Business Prioriteit of BIV classificaties. Een optimale scripting kan het herstel zeer bespoedigen, zij het dat in uitwijkconfiguraties de hardware capaciteit vaak een bottle neck vormen in de doorlooptijd van gescript opbrengen van servers. Indicatieve haalbare besparingen door optimale scripting bedragen 30-40% van de technische hersteltijd of ca. 10% van de doorlooptijd in test situaties of meer in echte calamiteiten. De uitdaging van Business Continutiy Managers en IT Disaster Recovery Managers is hier om met hun Business Continuity Management en IT Disaster Recovery Planning tools veranderingen in business requirements tijdig en als onderdeel van het change management te vertalen naar aanpassingen in recovery scripts. BCPI 2017 6
Conclusie Indicatieve haalbare besparing in recovery doorlooptijd kan 30 % of meer bedragen Een optimale scripting van het herstel van virtuele servers in groepen kan een indicatieve besparing van 30-40% van de technische hersteltijd of in test situaties ca. 10% van de totale recovery doorlooptijd opleveren. Organisaties die Agile, Scrum & DevOps doorvoeren kunnen hiervan ook aanzienlijke besparingen verwachten van 30-50% in testtijd, ofwel 10 tot ruim 20 % in totale recovery doorlooptijd. Met name de mogelijke besparingen door invoering van Agile, Scrum en DevOps zijn dus aanzienlijk. Bij echte calamiteiten zal de relatieve tijdsbesparing van deze ontwikkelingen waarschijnlijk groter zijn omdat dan niet eerst de productieomgeving wordt veiliggesteld en er eerder met herstel zal worden gestart. Tijdens echte calamiteiten zou de indicatieve maximale besparing van deze ontwikkelingen in recovery doorlooptijd mogelijk zelfs ca. 30 % kunnen bedragen. Een belangrijk bijkomend voordeel van Agile, Scrum en Devops is dat Recovery Runbooks overzichtelijker kunnen worden met grotere herstelblokken en minder taak- en teamwissels in het recovey pad en dus minder tussenkomst van Disaster Recovery Managers. Een belangrijk bijkomend voordeel van virtualisatie en IaaS is gelegen in het feit dat deze de recovery operatie overzichtelijker kunnen maken, kunnen stroomlijnen en automatiseren, vooraf kunnen worden getest en de organisatie hierdoor minder afhankellijk maken van individuele personen. Alle methoden en technieken kunnen bijdragen aan complexiteitsreductie en costs of operations verlagen. Meer informatie Meer informatie over de BCPI Methodiek en de BCPI R6 Tooling voor Business Continuity Planning, IT Disaster Recovery Planning en IT Disaster Recovery Management: BCPI Telefoon +31(0)294230405 E-mail info@bcpi.eu Website BCPI 2017 7