kostenvermindering, grotere betrouwbaarheid en een beter reactievermogen in de totale IT-levenscyclus
Terug naar af…
Na een project van enkele maanden was het eindelijk zo ver. De nieuwe versie van de webapplicatie kon uitgerold worden. Er waren webservices gebouwd voor de berekeningen, zodat straks ook andere applicaties hiervan gebruik konden maken.
Alles was getest; het beheerhandboek was klaar en alle lichten stonden op groen. De installatie verliep ook zonder problemen en de volgende ochtend werden de eerste gebruikers van de nieuwe applicatie voor premieberekening verwacht. De eerste geluiden waren ook zeer positief. Het project was namelijk in goed overleg met deze gebruikers opgezet en uitgevoerd.
Na een paar dagen begonnen de klachten binnen te druppelen. Naarmate er meer mensen gebruik gingen maken van de applicatie traden er spontaan fouten op in de berekening. Sommige afwijkingen waren niet zo groot om direct opgemerkt te worden, maar anderen waren overduidelijk. Ook de snelheid van de applicatie nam steeds verder af.
De helpdesk kon helaas niet zo veel met de klachten. Misschien wist de applicatiebeheerder wat meer. Die was tenslotte functioneel beter op de hoogte. Volgens hem was het een technisch probleem, dus werd systeembeheer ingeschakeld. De belasting van de server was op momenten wel wat hoger, maar kwam zeker niet tot 100%. Het netwerk evenmin. Tijd om de applicatieontwikkelaars in te schakelen. Die hadden op verschillende plekken loggingfunctionaliteit ingebouwd om eventuele problemen wat makkelijker te traceren. De logs lieten wel zien dat er af en toe excepties in de applicatie optraden, maar het was niet duidelijk of dat foute berekeningen tot gevolg had. Performanceproblemen waren eigenlijk helemaal niet te traceren. Het eventlog, de logs van de webserver, tracelogs en functionele logbestanden werden naast elkaar gelegd, maar door de hoeveelheid gebruikers was het lastig om bepaalde gebeurtenissen aan elkaar te relateren.
Voorlopig werd dan ook besloten om terug te gaan naar de oude applicatie, en eerst te zien wat er nu eigenlijk fout ging.
De uitdaging
Het bovenstaande scenario is niet geheel denkbeeldig. Applicaties, zeker in gedistribueerde omgevingen, met afhankelijkheden zowel in hardware als software maken het beheer van de gehele lifecycle steeds complexer. Bovendien moeten organisaties, willen ze concurrerend zijn, tegen steeds lagere kosten meer functionaliteit via hun IT infrastructuur kunnen aanbieden.
In dit kader zit het IT management in een lastige, of nee, uitdagende positie. Om vernieuwing te kunnen aanbieden maakt men gebruik van methoden en technieken die herbruikbaarheid, rapid application development en service oriëntatie mogelijk maken. Maar dat levert wel complexiteit, afhankelijkheden en security issues op die goed gemanaged moeten worden. Onderzoek van Gartner wijst uit dat er tijdens en na de uitrol van applicaties nog heel was mis kan gaan, ondanks een uitgebreide testperiode.
figuur 1 Wat gebeurt er bij de uitrol?
De aard van gedistribueerde systemen en de daarbij behorende onderlinge afhankelijkheden tussen software en hardware hebben geleid tot een grotere complexiteit. Hoewel veel problemen zich eerder voordoen bij grotere bedrijven, krijgen kleine en middelgrote ondernemingen ook met een aantal van deze zaken te maken naarmate hun IT-infrastructuur complexer wordt.
Dynamic Systems Initiative
Om deze uitdaging het hoofd te bieden introduceerde Microsoft in 2003 het Dynamic Systems Initiative (DSI). Het resultaat van dit initiatief moet bedrijven de mogelijkheid bieden eenvoudiger en meer geautomatiseerd gedistribueerde systemen ontwerpen, implementeren en beheren. Het uiteindelijke doel is kostenvermindering in de totale IT-levenscyclus.
Stap 1: ontwerp
Dit kan bereikt worden door een verbinding tot stand te brengen die loopt van het ontwerp van het systeem via de besturing van het systeem naar de eindgebruikers die met het systeem werken. Met deze feedback-lus die de volledige levenscyclus van een systeem beslaat, kunnen IT-infrastructuren constant worden verbeterd met software. In het ontwerp van deze systemen moet de praktijk als belangrijkste uitgangspunt worden genomen en geldt het beheer ervan als een van de belangrijkste elementen van het onderliggende platform.
Om de communicatie tussen de ontwikkelaars en de beheerafdeling mogelijk te maken zet Microsoft in op het System Definition Model (SDM). Het System Definition Model is een gelaagd model dat de structuur van applicatiesystemen, de applicatiehosting-omgeving, het netwerk en besturingssysteem en de hardware voorstelt. De distributed designers in Visual Studio 2005 Team System leggen zich toe op de bovenste twee lagen van dat model, de applicatielaag en de applicatiehosting-laag. De eerste laag maakt het voor de ontwikkelaar mogelijk om de structuur en het gedrag van applicatiesystemen te beschrijven waarna het ontwerp kan worden gesynchroniseerd met de code. De applicatiehosting-laag laat de infrastructuur architect een model van de hosting omgeving beschrijven. Door matching van deze twee lagen worden mogelijkheden en knelpunten sneller zichtbaar.
Stap 2: Monitoring
Alhoewel het juiste ontwerp van een applicatie infrastructuur een hoop produktieproblemen kan voorkomen, blijft monitoring essentieel. Microsoft Operations Manager (MOM) 2005 voorziet duidelijk in deze monitoring behoefte.
In MOM zitten allerlei voorzieningen voor uitgebreid gebeurtenissenbeheer, proactieve controle en waarschuwingen, rapportage en trendanalyse, en systeem- en toepassingsspecifieke kennis waarmee Windows-omgevingen beter kunnen worden beheerd.
Microsoft investeert veel in research en ontwikkeling van software en probeert parners ertoe te brengen end-to-end oplossingen op te nemen in hulpmiddelen voor het ontwikkelen van toepassingen, besturingssystemen, toepassingen, hardware en beheerprogramma's. MOM 2005 is uitbreidbaar met een veelheid van Management Packs waarmee specifieke hard- en software kan worden gemonitored. De serverprodukten van Microsoft zelf worden inmiddels niet meer geleverd zonder een dergelijk eigen Management Pack.
Het .NET Management Pack
Maar hoe zit het met maatwerk applicaties, zoals de eerder beschreven applicatie voor premieberekening? Dergelijke applicaties worden zelden vergezeld van een eigen Management Pack en toch is het van belang om de status van zo’n applicatie te monitoren. Niet alleen dat, wanneer er iets misgaat in de applicatie is het voor een zo kort mogelijke oplostijd van belang om te weten waar het fout is gegaan. Één van de partners van Microsoft, AVIcode, heeft daarom een Management Pack (MP) ontwikkeld dat bedoeld is voor ieder maatwerkapplicatie die gebruik maakt van het .NET Framework.
Dit .NET MP bestaat uit een agent, in de vorm van een Windows Service, die op de applicatieserver wordt geplaatst en een reporting engine die in samenwerking met MOM waarschuwingen over fouten en performanceproblemen in de applicatie registreert en analyseert. Het gebruik ervan biedt voordelen voor zowel de applicatieontwikkelaars, de testers, en de beheerafdelingen.
Service Level Agreements
Het .NET MP legt de basis voor Service Level Agreements. Enerzijds doordat van een applicatie kan wordt vastgesteld of deze fouten bevat, en zo ja, of deze fouten te wijten zijn aan gebrekkige infrastructuur of gebrekkige applicatiecode. Anderzijds omdat de performance van een applicatie exact te bepalen is aan de hand van het werkelijk gebruik ervan.
In veel gevallen wordt de performance van applicaties gemeten aan de hand van een reeks geschedulede aanvragen die met een bepaald interval worden afgevuurd op de applicatie. De gemiddelde responstijd moet binnen de in de SLA gestelde limieten vallen. Dat heeft echter drie nadelen.
- dergelijke monitoring is enkel van toepassing op webapplicaties en webservices. Voor client-applicaties zal dus een andere methode verzonnen moeten worden of is in het geheel niet mogelijk.
- niet de werkelijke, door gebruikers ervaren, performance wordt gemeten, maar een afgeleide hiervan. Er wordt verondersteld dat de performance binnen het interval gelijk is geweest. Daarbij is het lastig vast te stellen wat de imact van de beschikbare netwerkbandbreedte is op de gemeten performance.
- wanneer de gemeten performance boven de gestelde limiet komt, is niet direct bekend wat de oorzaak is (geweest) van deze overschreiding. Telkens moet de afweging gemaakt worden of hier sprake is van een, in ITIL-termen, incident of een probleem en zal nadere, soms tijdrovende, analyse moeten plaatsvinden.
figuur 2 SLA rapportages bieden inzicht in de dienstverlening
Het .NET Management Pack lost dit op door het feitelijk gebruik van de applicatie te monitoren. De monitoring agent wandelt als het ware mee met de gebruiker, zonder de applicatie overigens te belasten. Zodoende wordt exact vastgesteld hoe lang een webpagina er over doet om geleverd te worden, zonder last te hebben van slechte netwerkbandbreedte. Bovendien kan deze agent ook de duur van applicatiecode in clientapplicaties meten. Wanneer de duur van deze applicatiecode een in de SLA gestelde grenswaarde overstijgt worden alle relevante gegevens verzameld om vast te stellen wat de oorzaak van deze performanceverslechtering is.
Applicatie-onafhankelijk
Niet in alle gevallen heeft de beheerafdeling invloed op de mate waarin de ontwikkelaar logging en tracing toevoegt om probleemanalyse mogelijk te maken.
Om te kunnen profiteren van het .NET MP zijn de beheer- en testafdelingen niet afhankelijk van de ontwikkelaar. Dat wil zeggen dat de ontwikkelaar niet bijzondere maatregelen hoeft te nemen om monitoring van zijn applicatie mogelijk te maken. Dat scheelt tijd die de ontwikkelaar kan besteden aan het robuuster maken van de applicatie of het toevoegen van extra functionaleit.
De informatie die geleverd wordt wanneer een fout of performanceprobleem optreedt is daarbij vaak zo volledig dat een ontwikkelaar aan de hand van deze informatie direct kan vaststellen hoe het kan worden opgelost.
Monitoring van (applicatie-)services in plaats van infrastructuuronderdelen
We zien ook een trend waarbij de monitoring van een IT infrastructuur langzamerhand verschuift van onderdelen de IT omgeving zoals netwerkapparatuur, beschikbaarheid van servers, en belasting van de processor, naar de applicatie zelf. Het heeft immers weinig zin om te constateren dat een server nog prima te bereiken is, terwijl de applicatie is gecrashed. Een SLA wordt veelal op een applicatie afgegeven en niet op de infrastructuur waarop deze applicatie is geïnstalleerd.
figuur 3 de status van applicatieservices is vaak de kern van SLA afspraken
Met het .NET MP wordt daarom de status van een applicatie in de gaten gehouden. Zodra een fout of performanceissue optreedt, verandert deze status in de Operator Console van MOM. Zodoende kan men taken toewijzen aan de bij deze applicatie betrokken partijen. Ook kan hiermee gerapporteerd worden over de beschikbaarheid en performance van de applicatie.
Oplossingsvermogen
De kwaliteit van een IT afdeling in haar geheel wordt vaak gemeten aan de hand van het vermogen een flexibele doch robuste infrastructuur aan te bieden. In dit kader is het van belang om bij het optreden van verstoringen in deze infrastructuur snel en adequaat te kunnen optreden. Met het .NET MP is men in staat om direct naar de oorzaak van een opgetreden fout te wijzen. Dit wordt bereikt op verschillende manieren.
Zo wordt de eerste keer dat een fout optreedt direct vastgelegd. Het is niet zo dat de beheerafdeling na klachten of incidenten monitoring moet worden “aanzetten” en men moet wachten tot het probleem zich weer voordoet. Daarnaast wordt alleen die informatie verzameld die relevant is voor de opgetreden fout. Het is zodoende niet nodig om naar de spreekwoordelijke speld in een hooiberg te zoeken in de berg aan informatie die de verschillende logbestanden leveren.
figuur 4 gedetailleerde foutinformatie laat direct zien wat de oorzaak is
Dat neemt overigens niet weg dat er in het oplossen van sommige problemen geen behoefte meer is aan zogenaamde profilers. In die zin stelt het .NET MP de diagnose, en is soms een pleister voldoende. Sommige problemen zijn echter dusdanig complex dat voor de operatie is een chirurg nodig is.
Conclusies
DSI wordt door Microsoft ingevuld met de nieuwe mogelijkheden van Visual Studio 2005 en MOM 2005. Het .NET Management Pack maakt de cirkel compleet door standaard monitoring en foutinformatie voor maatwerk applicaties te rapporteren. Had de inzet van DSI-gerelateerde technologieën als het System Defnition Model en het .NET MP de problemen zoals in de inleiding werden genoemd kunnen voorkomen? Wellicht niet, want automatisering is voor een belangrijk deel nog steeds mensenwerk. Maar door de toepassing ervan was de oplostijd op zijn minst verkort en waren de belangrijkste problemen al voor de uitrol aan het licht gekomen.
In dit geval bleek de applicatie niet goed opgewassen tegen gelijktijdig gebruik waardoor bestanden en databaserecords gelocked werden.
Meer informatie