Stel de gebruiker centraal bij IT-beschikbaarheid

Gepubliceerd: Donderdag 4 februari 2010
Auteur: Andrew Barnes

Als werknemers, klanten of partners geen of moeilijk toegang hebben tot een toepassing, verstoort dat een proces, hetgeen weer resulteert in een stagnering van productiviteit of zelfs van de business. Toch worden IT-infrastructuren vandaag de dag nog heel vaak op componentniveau beheerd, waarbij factoren als het netwerk of de server separaat gemonitord worden.

Bij beschikbaarheid van IT draait het uiteindelijk om de gebruiker van een applicatie of dienst. Daar wordt in de praktijk nog wel eens aan voorbij gegaan. Als de werknemer, klant of partner geen toegang heeft tot een toepassing of deze zeer traag werkt, verstoort dat een proces, hetgeen weer resulteert in een stagnering van productiviteit of zelfs van de business. Toch worden IT-infrastructuren vandaag de dag nog heel vaak op componentniveau beheerd, waarbij factoren als het netwerk of de server separaat gemonitord worden. Dit zegt niks over de beschikbaarheid of de prestaties van een applicatie of over de data die over een netwerk gaat. Als een server in de lucht is, betekent dit niet automatisch dat de applicatie het ook doet.

Tegelijkertijd neemt het belang van beschikbaarheid van IT-services voor bedrijfsprocessen toe. Kijk bijvoorbeeld eens naar e-mail-diensten. IT-afdelingen van bedrijven krijgen gemiddelde twee calls per week van werknemers dat hun e-mail down is of dat ze er wegens andere redenen niet bij kunnen. Omdat er op componentniveau wordt beheerd, kost het analyseren van de oorzaak vaak enige tijd en leidt het probleem tot omzetderving vanwege verminderde productiviteit of gemiste klantorders. Hierbij moet worden aangetekend dat e-mail slechts één – kritische – applicatie is.

De afhankelijkheid tussen bedrijven wordt steeds groter evenals het goed functioneren van processen die zwaar leunen op IT. Door de toenemende applicatie-integratie via SOA of EDA (event driven architectures) zal het belang van ‘end-to-end’ controle over steeds meer applicaties – of nauwkeuriger gesteld services - toenemen. Beheer van de verschillende onderdelen in een IT-architectuur volstaat dan in geen geval meer om te beoordelen of de applicatie zelf naar tevredenheid van de gebruiker functioneert. Beheer zal applicatiecentrisch moeten worden benaderd om de werkelijke ‘availability’ te kunnen beoordelen.

Deze beschikbaarheid bestaat uit twee onderdelen:

1. High availability (HA), dat zich richt op het minimaliseren van de ongeplande downtime. High availability bestaat op haar beurt uit foutvoorkoming, snel herstel, integriteit en applicatie performance management.

2. Continuous Operations (CO) met als focus anticiperen op geplande downtime wegens bijvoorbeeld migraties of vervanging van hardware.

Continuous availability (CA) ontstaat wanneer een organisatie zijn IT zo heeft ingericht dat geplande en ongeplande downtime volledig uitgebannen zijn. Monitoring is een kardinaal punt in het nastreven hiervan. Voordat een bedrijf hiermee aan de slag gaat, is het essentieel om te bepalen welke applicaties echt missiekritisch zijn middels een classificatiesysteem. Lang niet alle applicaties zijn echt onmisbaar. Generiek gezien verdienen vrijwel alle toepassingen die interactie hebben met klanten en/of met partners het predicaat kritisch, wat betekent dat ze maximaal twee uur achtereen offline mogen zijn en dat alle data opgeslagen moet worden – zelfs wanneer de toepassing zelf niet beschikbaar is. Applicaties van deze categorie vereisen een ‘veerkrachtige’ architectuur, bestaand uit een lokale IT-infrastructuur en één op afstand (DR). Verder zouden de volgende stappen gevolgd moeten worden om continuous availability te bereiken:

1. Ontwikkel en formaliseer een beschikbaarheidstrategie.

2. Ontwikkel een robuuste applicatiearchitectuur met inbegrip van verandermanagement en van incidentmanagement.

3. Reduceer de complexiteit waar mogelijk.

4. Breidt de IT-beheerprocesen uit naar service level management; dat moet end-to-end gebeuren vanaf de eerste opstart van een applicatie tot en met de uitfasering. Vanuit het operations center zal de geplande downtime, restart, migratie en failover gemonitord, vastgelegd en geanalyseerd moeten worden.

5. Automatiseer waar mogelijk; voer dit eerst in bij processen voor geplande downtime om te kunnen beoordelen hoe het bij ongeplande downtime zal lopen.

6. Neem de vereisten voor beschikbaarheid en disaster recovery mee in de projectontwerpfase om de flexibiliteit verder te vergroten.

7. Test vaak en doe een goede productievalidatie.

Met name het terugdringen van ongeplande downtime is voor veel bedrijven een grote uitdaging. Een goede procedure voor Disaster Recovery (DR) – rampenherstel – is dan ook vaak een zeer kostenintensieve en tijdrovende aangelegenheid, die niet meteen zijn toegevoegde waarde bewijst. Toch onderkennen steeds meer bedrijven (profit en non-profit) het belang en evalueren ze hun behoeften om snel weer de schikking te hebben tot hun belangrijkste IT-bronnen na een calamiteit. DR kent drie gradaties. Het basisniveau is dat van IT-project; er wordt één keer een investering gedaan om bij wijze van ‘best effort’ zo snel mogelijk weer de beschikbaarheid te hebben over de belangrijkste IT-middelen na een ongeplande uitval. Daarboven bestaat DR als onderdeel van de continuity management-strategie van een organisatie. Om serieus met rampenherstel bezig te zijn, moet een organisatie tenminste op dit niveau te zitten; het houdt in dat er geïnvesteerd is in de middelen en in de procedures en dat regelmatig getest wordt of deze nog voldoen. De hoogste graad voorziet in Disaster Recovery als geïntegreerd proces, waarbij vanaf de ontwikkeling van een applicatie rekening wordt gehouden met de beschikbaarheid voor het bedrijfsproces dat de software ondersteunt.

Hierbij tot slot nog drie tips om uitval van systemen voor te zijn:

1. Bescherm je applicatiebeschikbaarheid door redundantie in te bouwen en het ecosysteem rond de applicatie consequent te monitoren. Neem daarin de vereenvoudiging en de toepasbaarheid van ‘maintenance’/ onderhoud aan de betreffende kritische applicaties mee. Deze moet zonder uitgevoerd kunnen worden gedurende de normale werkdag.

2. Stel beheer van de missiekritische services centraal en niet de IT-infrastructuur.

3. Deel geen architectuur voor CA-bescherming over verschillende applicaties. Dan is het niet nodig om te standaardiseren op een bepaald type hardware. Deze hardwareonafhankelijkheid kun je ook invullen door virtualisatie toe te passen. Virtualisatie maakt het mogelijk dat je niet hoeft te migreren naar een volledig nieuwe omgeving om continuous availability mogelijk te maken.

Andrew Barnes is senior vice president corporate development bij Neverfail

Reacties

Nieuwsbrief

Blijf altijd op de hoogte van het laatste ICT-nieuws