In de hedendaagse connected business is netwerkinfrastructuur de levensader. Wat moeilijk voor te stellen is, is dat bedrijven jaar na jaar in een STIJGEND tempo catastrofale storingen in hun netwerk melden, net wanneer de meeste mensen zouden aannemen dat het belang van deze netwerken met de hoogste prioriteit in IT is aangepakt. Triest maar waar, elke dag vinden er ergens ter wereld grote netwerkstoringen plaats. Naarmate ondernemingen groter worden en hun hybride netwerken complexer en meer gedistribueerd worden, neemt het aantal storingen gestaag toe. Het resultaat: pak een willekeurige grote krant of bezoek een online nieuwsuitzending en u kunt er bijna zeker van zijn dat u voorpaginaverhalen ziet over servicestoringen ergens ter wereld.
Als er een netwerkstoring is, is het een race tegen de klok om alles weer werkend te krijgen. Er breekt paniek uit, gebruikers beginnen hun helpdesks te begraven in servicetickets en in sommige gevallen beginnen verslaggevers nieuwsartikelen te publiceren over wat er is gebeurd, wat interessant wordt voor aandeelhouders tijdens hun diner. Dit is natuurlijk geen prettige situatie. Feit is dat de meeste netwerkoperators en ingenieurs meer dan driekwart van hun professionele leven in deze chaotische race doorbrengen, waarbij ze problemen oplossen NADAT ze voorpaginanieuws zijn geworden.
Typische ondernemingen hebben honderden of duizenden applicaties die op elk moment in hun hybride netwerk draaien. Frontoffice en backoffice, productie, R&D, audio- en videostreaming, databasetoegang, internet en een hele reeks andere soorten toepassingen. En hoewel elk van deze applicaties in eerste instantie is ingezet om een specifiek serviceniveau te bieden dat het bedrijf nodig heeft, houden ontwerpers zelden rekening met de mogelijke impact op eerder geïnstalleerde applicaties als er nieuwe applicaties op hun plaats komen. De meeste applicaties worden geïnstalleerd alsof er geen andere beperkingen zijn opgelegd door de jaren van vorig werk. Om het bedrijf succesvol te laten zijn, moet elk van deze applicaties, nieuwe en oude, uiteindelijk werken op het niveau waarvoor ze zijn ontworpen. Uiteindelijk lijdt het succes van eerdere applicaties bijna altijd in de loop van de tijd, omdat glimmende nieuwe applicaties de aandacht trekken van de enterprise-architecten en operaties met minder aandacht of formele processen om ervoor te zorgen dat eerdere applicaties behouden blijven.
De heilige graal van netwerken is om te voorkomen dat potentiële problemen productienachtmerries worden. Klinkt eenvoudig, maar niet intuïtief voor de hand liggend hoe dat moet. Het antwoord is door proactief op zoek te gaan naar potentiële problemen en deze op te lossen voordat ze de productie beïnvloeden. Wanneer bijvoorbeeld twee netwerkapparaten zijn ingesteld in een vorm van taakverdeling en veerkrachtige configuratie, zou de proactieve benadering zijn om te bevestigen dat het paar apparaten altijd en continu identiek is geconfigureerd. Nogmaals, hoewel dit eenvoudig klinkt, beschikken de meeste ondernemingen simpelweg niet over de geautomatiseerde tools die nodig zijn om de spiegeling van dit paar en de duizenden andere paren continu te testen. En deze situatie met ontwerpnaleving wordt pijnlijk onthuld wanneer veerkracht zou moeten optreden, wat resulteert in een ramp omdat de twee apparaten GEEN spiegels van elkaar waren.
En in elk hybride netwerk gelden dezelfde soort verificatievereisten. Niet alleen gespiegelde paren, maar ook connectiviteitsprestaties, beveiligingszones, toegangscontrole, doorvoervereisten, enz. De lijst met netwerkgedrag dat proactief moet worden geverifieerd, kan gemakkelijk 100 keer zo groot zijn als het aantal apparaten in een complex hybride netwerk. Jarenlang brute force-beheer van al die apparaten beïnvloedt het gedrag van het netwerk, dat helaas op de slechtst mogelijke tijden wordt getest.
Het draait allemaal om schaalDoor te focussen op al het gewenste gedrag van het netwerk in plaats van op de low-level individuele apparaatstatus, kan een heel netwerk worden omschreven als duizenden netwerkintenties. Elke applicatie-architect en elk implementatieteam hoeft alleen maar hun unieke vereisten te beschrijven, die vervolgens worden gecombineerd met alle andere applicatievereisten om de lange lijst van netwerkgedragingen (intenties) voor het bedrijf te vormen. En door het testen van elk van deze gewenste intenties te automatiseren, kan het hele netwerk continu worden geverifieerd voordat er zich een productie-incident voordoet.
Naarmate elk netwerk groter wordt, worden operators en technici opgeslokt door te reageren op problemen die zich al hebben gemanifesteerd in aanzienlijke productieproblemen die onmiddellijke aandacht vereisen ("Brandoefeningen"). De situaties komen honderden of zelfs duizenden keren per maand voor in een groot netwerk, met gewenst gedrag (network intents) getest en geverifieerd moeten worden. Echter, als het aantal network intents gemakkelijk meer dan 100 keer het aantal apparaten kan overschrijden, is het niet haalbaar om al deze duizenden handmatig te verifiëren network intents. Proactieve op intentie gebaseerde ontwerpverificatie gebeurt gewoon niet en het resultaat: storingen.
Nu weet ik dat er heel veel dollars worden uitgegeven aan veerkrachtstrategieën en veel lezers zeggen misschien: "Ik heb geen enkele storingspunten of uitval". Laat me je verzekeren dat je dat doet, of je je er nu van bewust bent of niet. En hoewel het waar is dat totale storingen zeldzaam zijn, zijn "storingen" in moderne tijden minder binair en meer gradueel. Het perfecte netwerk kan mogelijk 100,000 transacties per minuut verwerken, terwijl een netwerk met een of ander defect onderdeel en veerkrachtige ontwerpen het aantal transacties kan terugbrengen tot 60,000. Of het perfecte netwerk kan kristalheldere spraakoproepen bieden, terwijl het getroffen netwerk een metaalachtige of schokkerige oproep kan bieden, met uitval van de stem. En om het probleem nog groter te maken, worden veel van dit soort gereduceerde scenario's niet gerapporteerd!
Veel bedrijven en IT-operators hebben jarenlang hun tenen gestoten bij automatiseringsprojecten, waarvoor doorgaans enorme bedragen of middelen nodig waren om weinig of geen resultaten te genereren. Mislukte IT-automatiseringsprojecten zijn overal. Dat is de reden waarom veel IT-leiders de kracht van automatisering voor het oplossen van NETWERK-problemen niet overwegen en grotendeels bestonden de tools die specifiek waren voor netwerken niet, totdat NetBrain. Veel operators blijven zich richten op het bruut oplossen van problemen "zoals het altijd al is gedaan". Voor veel IT-leiders lijkt een geautomatiseerde proactieve benadering van storingspreventie niet eens mogelijk. Maar het is…
Geschat wordt dat het merendeel van alle netwerkstoringen voorkomen had kunnen worden als er geautomatiseerde verificatie en voortdurende handhaving van de ontwerpconformiteit waren geweest. Door uw hybride netwerk te omschrijven als de verzameling van alle design intentAangezien alle gebruikte bedrijfstoepassingen nodig zijn, kunnen potentiële problemen worden verholpen lang voordat ze problemen veroorzaken. En hoewel dit soort nalevingsafdwinging op ondernemingsniveau nooit haalbaar is geweest wanneer het handmatig werd geprobeerd, de NetBrain oplossing verandert dit allemaal door deze proactieve verificatie en handhaving van gewenst gedrag op elke schaal te automatiseren.
NetBrain technologie doet dit voor duizenden klanten en kan u laten zien hoe u vandaag proactieve netwerkautomatisering kunt integreren. Voor meer informatie, neem vandaag nog contact met ons op.