Redactie - 20 maart 2015

Automatisering vs. Eliminatie

De Cloud is ontwikkeld om toegankelijkheid en betrouwbaarheid te bieden. Meer dan ooit maken bedrijven gebruik van de Cloud om samen te werken met klanten. Maar wat gebeurt er als een bug in het systeem zit?

In het verleden hebben IT leiders en teams geautomatiseerde systemen ontwikkeld voor het identificeren, troubleshooten en oplossen van een probleem nadat het heeft plaats gevonden. Na verloop van tijd realiseerden we ons dat automatiseringsproblemen de korte, maar niet de lange termijn problemen oplost. Een lange termijn oplossing, wat de beschikbaarheid van het systeem verzekert en de kosten onder controle houdt, blijft uit. Voortborduren op een geautomatiseerd pad is onhoudbaar. Het is tijd dat de IT-gemeenschap een nieuwe weg vindt.

Innovatie van DevOps (Development en Operations) moet niet gezocht worden in automatisering, maar in eliminatie. Organisaties moeten de eliminatie vs. automatisering strategie begrijpen en de wortels van softwareproblemen zien te identificeren. Het is belangrijk om content ontwikkelen door echte voorbeelden te geven van hoe een benadering gebaseerd op eliminatie klanten kan helpen. De capaciteit wordt verhoogd, downtime wordt vrijwel geëlimineerd en de onderhoudskosten voor software worden verminderd. En dit alles zonder de noodzaak voor teams van IT-mensen.

De fundamentele filosofie waarmee DevOps zich ontwikkelde als paradigma is om deze kloof te overbruggen en zich niet alleen te richten op automatisering als belangrijkste ingrediënt van Continuous Improvement. Ten eerste moeten we het perspectief van dit paradigma (DevOps) zien te begrijpen. Ten tweede moet er een waardering zijn voor het groter gehaal in elke individuele spaak die hierbij betrokken is.

In het toepassen van het principe “Eliminate”- “Simplify”- “Automate” (ESA), heeft de primaire focus altijd gelegen op Production (P) environments. Hierbij wordt gestreefd naar het aantrekken van maximale investeringen en verbeteringen. Door de stappen te traceren en een relatie te vestigen met de bron (Development / Source Code) en op elk stap het ESA principe toe te passen voordat we daadwerkelijk actie ondernemen, kunnen wij daadwerkelijk operationele efficiënte bereiken. Automatiseer nooit iets dat niet kan worden vereenvoudigd, en vereenvoudig nooit iets dat in de eerste plaats kan worden geëlimineerd. Bij Infrastructure en Application is er een vuistregel bij de analyse van de historische informatie over de prestaties van het IT-landschap: kijk naar elk proces of alarm of incident en vraag of dit volledig kan worden geëlimineerd. Zo ja, hoe elimineren we het dan? Zo niet, hoe kunnen we het dan vereenvoudigen? Zodra je de weg van vereenvoudiging hebt gevonden, vraag je dan af of het geautomatiseerd kan worden.

De ideale omstandigheden zijn als 80% van de activiteiten worden aangepakt op Tier 1, 16% worden aangepakt op Tier 2 en 4% worden aangepakt op Tier 3. Dit impliceert dat de operationele kosten voorspelbare en onder controle zijn. De meeste bedrijven investeren om dit resultaat te bereiken. Dat resultaat houdt nog steeds in dat als er een gebeurtenis plaatsvindt, we met de beste oplossing komen die in de snelst mogelijke tijd toegepast kan worden. Het merendeel van deze beleggingsopbrengsten zijn gemeten op basis van de Kosten Per Incident, hoeveel incidenten opgelost werden in welke tier en de notionele vermijdingskosten.

Automatisering richt zich op de ontwikkeling en het gebruik van besturingssystemen om menselijke behoeften te verminderen en deze (herhaalde) incidenten / problemen met minimale of nul fouttolerantie aan te pakken. De aanbeveling is om alle ruwe data te analyseren (uit alle bronnen) en verkennende of voorspellende analytics te maken die kunnen helpen bij het identificeren van de kandidaten voor eliminatie. Dit zal helpen in a) Healthy Operations dat PACE houdt (Performance, Availability, Capacity managed Efficiently) met het bedrijfsleven, b) het verminderen van interventie en fouten proactief elimineren, c) het verhogen van algemene prestaties (Time to Act), d) het verbeteren van de beschikbaarheid (niet alleen in de productie, maar bij verschillende omgevingen) en de omgeving actueel houden, e) het kunnen omgaan met de omvang, maar ook dynamisch blijven – vooral omdat huidige systemen zowel horizontaal als verticaal schaalbaar moeten zijn en, het belangrijkste, f) het voldoen aan de vereiste control framework.
Elke taak die je elimineert brengt je een stap dichter bij waar je wilt zijn.

Over de auteur:
Koushik Ramani, in zijn rol als hoofd van IMS consulting bij Mindtree, houdt zich bezig met het identificeren van de juiste IT-infrastructuur oplossing voor wereldwijde klanten. Hij is actief betrokken bij diverse technische gemeenschappen en heeft zich gespecialiseerd in virtualisatie, cloud computing, infrastructuur transformatie en optimization services.

Wil jij dagelijkse updates?

Schrijf je dan in voor onze nieuwsbrief!