NetBrain oprichter en CEO Lingping Gao presenteerde zijn Think Tank-sessie 'Hidden Challenges of Network Automation in the SDN Age and Beyond' tijdens Cisco Live 2018 in Orlando. Dit bericht vat zijn presentatie samen.
Wat zijn onze grootste netwerkautomatiseringsuitdagingen voor netwerkautomatisering? ik heb het over vandaag real-world networking — geen uitdagingen in de toekomst. Ik heb het over onze huidige dagelijkse operationele workflows en taken: probleemoplossing, wijzigingsbeheer, beveiliging en documentatie in SDN, multi-cloud en hybride netwerken.
Er zijn twee fundamentele dingen die netwerkautomatisering uitdagend maken. De eerste is het netwerk zelf. Netwerken zijn tegenwoordig erg complex. We hebben net virtualisatie achter de rug, en toen kwamen softwaregedefinieerde netwerken zoals Cisco ACI en nu hebben we SD-WAN. Het tweede zijn onze tools en data. We gebruiken veel tools — ticketingsystemen zoals ServiceNow, 24×7 monitoringoplossingen, Splunk, SEIM en IDS, en zelfs APM. Elke tool doet zijn eigen werk, maar functioneert op een "eiland". We eindigen met veel datasilo's. Zoveel tools met een overvloed aan data betekenen dat het automatiseren van probleemoplossing of change management niet zo eenvoudig is.
Dat gezegd hebbende, er zijn 5 "verborgen" netwerkautomatiseringsuitdagingen voor dagelijkse praktische netwerkautomatisering die ik in de loop der jaren heb geleerd.
Wanneer mensen 'netwerkautomatisering' horen, hebben ze vaak een van twee reacties. Of ze zeggen: "Het is het niet waard", of ze denken: "Je probeert mijn baan af te pakken." In het eerste geval denken netbeheerders veel geld uit te geven zonder veel rendement op hun investering te krijgen. Ze willen niet nadenken over het kopen van nog een oplossing, tijd besteden aan het vinden van een nieuwe manier om dingen te doen of een ander script schrijven. Aan de andere kant horen sommige netwerkingenieurs - meestal de NOC-jongens van het eerste niveau - "baaneliminatie" als je het woord "automatisering" zegt.
Maar automatisering is de moeite waard en zal je baan niet wegnemen. Het zet de vergelijking op zijn kop: automatisering neemt de banen weg die het niet waard zijn. Automatisering kan en zal het werk van mensen niet elimineren. Maar het elimineert al het doodlopende werk dat niemand wil doen. Het maakt ieders tijd vrij om meer uitdagend werk aan te nemen.
In de huidige netwerken is scripting niet genoeg. Iedereen die een Python- of Java-script heeft geschreven, weet dat de grootste uitdaging voor netwerkautomatisering met scripts niet het schrijven ervan is. Het onderhoudt ze. Je hebt een keer een script geschreven, maar als het netwerk verandert, zit je vast met veel debuggen. En dat script delen met andere mensen is niet zo eenvoudig.
Zelfs vandaag de dag hoor je nog steeds veel over hoe netwerkjongens programmeurs moeten worden. Ik zie niet echt dat het een natuurlijke stap voor ons is om van netwerkingenieur naar ontwikkelaar te gaan - of een oplossing voor netwerkautomatisering.
Wat bedoelen we met "Wanneer moet je op de knop drukken"? Mensen denken dat we met automatisering het één keer moeten schrijven, het moeten uitbrengen en dat alles dan vanzelf zal gaan. Maar in de echte wereld werkt het niet zo. Iemand moet ergens dat stukje automatisering activeren – voor probleemoplossing, wijzigingsbeheer, beveiliging, wat dan ook. Als er midden in de nacht een storing is, wie gaat dan de automatisering starten die het probleem diagnosticeert? En wanneer? Vandaag de dag is dit een grote uitdaging voor netwerkautomatisering die we moeten oplossen.
We zijn hybride gaan. Of je het nu leuk vindt of niet, er komen meer ACI-, NSX- en andere SDN-datacenters aan. Er komt meer SD-WAN aan. Het traditionele netwerk waarmee we vertrouwd zijn, waar we ons net mee bezig hebben gehouden, volstaat niet meer. Voor de meeste automatisering in een traditioneel netwerk geldt: "schrijf het een keer, gebruik het een keer"? Dat is iets waar we vandaag de hele tijd mee te maken hebben. Je zou kunnen zeggen: "Oké, we scheiden de automatisering voor het traditionele netwerk van het nieuwe netwerk." Maar hoe zit het met de doorstroming van het verkeer? Als u traagheid ervaart bij het overstappen van uw traditionele netwerk naar uw SDN, hoe gaat u daar dan mee om? We moeten dus uitzoeken hoe we kunnen automatiseren binnen het hybride netwerk - hetzelfde met een multi-vendor netwerk.
We hebben al veel tools – of oplossingen. Maar elke tool spreekt zijn eigen taal; ze zijn hun eigen 'data-eiland'. U hebt een tool voor prestatiebewaking die niet praat met de tool voor gebeurtenisbeheer die niet praat met het inbraakdetectiesysteem, enzovoort. Alle belangrijke informatie die je nodig hebt – collectief – is van elkaar geïsoleerd in datasilo’s.
Dus hoe overwinnen we deze uitdagingen? We hebben geprobeerd de hardware te upgraden, de software te veranderen, de mensen te vervangen – dat is niet de oplossing. We hebben automatisering nodig die anders denkt. We hebben adaptieve automatisering nodig.
Het concept van adaptieve automatisering is niets nieuws. Op het gebied van werktuigbouwkunde is er een computer-aided design (CAD)-oplossing; de elektronica-industrie heeft EDA (elektronische ontwerpautomatisering); in netwerken is er iets soortgelijks: we noemen het Adaptive Automation. Het idee erachter is dat wanneer je een heleboel taken hebt die je moet uitvoeren in een complex netwerk en die verschillende data-eilanden moeten integreren, je twee dingen nodig hebt om het probleem op te lossen.
Een daarvan is een kaart. In CAD of EDA is het diagram (of de kaart) eigenlijk een gegevensmodel dat dingen in een visueel formaat abstraheert. Je hebt dus een kaart nodig om je taak te kunnen abstraheren. Met een kaart kunt u de omvang van je taak.
Het andere stukje van de puzzel is een runbook – geen script – waarmee u kunt organiseren wat u moet doen. De runbook stelt u in staat om de stappen van je taak.
Samen realiseert de kaart het idee om uw netwerk te documenteren, één enkel venster van uw netwerk te creëren en de runbook realiseert "just in time" automatisering en "één keer schrijven, overal uitvoeren".
Deze adaptieve automatisering pakt netwerkautomatisering taak voor stap, stap voor stap, aan voor de 5 bovenstaande uitdagingen. Laten we eens kijken naar een voorbeeld van hoe dit eruit zou zien.
Stel dat u een melding ontvangt in uw evenementenconsole, bijvoorbeeld een ticket in ServiceNow dat een app traag is. In het Adaptive Automation-framework is het eerste dat gebeurt dat "just in time"-automatisering wordt geactiveerd via API om een Dynamic Map van die traagheid. Dan een “niveau-0 diagnose” runbook komt automatisch in actie om prestatiegegevens, CLI-opdrachtgegevens of gegevens van uw prestatiebeheertool te verzamelen en de informatie aan het ServiceNow-ticket te koppelen. Dit gebeurt allemaal automatisch op het moment dat de gebeurtenis wordt gemaakt wanneer de traagheid wordt gedetecteerd - bijvoorbeeld midden in de nacht - zonder dat enige menselijke tussenkomst vereist is. (Daarom wordt het "niveau-0-diagnose" genoemd.) Dat is stap 1.
Stap 2: Als je 's ochtends op je werk aankomt, is er de ServiceNow die midden in de nacht is gemaakt. Nu voer je verschillende traagheidsprestaties of QoS-probleemoplossing uit runbooks. Deze Runbooks zijn gemaakt door uw senior netwerkingenieurs op basis van hun knowhow, zowel hun domeinkennis als inhoudelijke expertise. Indien nodig kan de technicus van niveau 1 het probleem vervolgens escaleren naar een technicus van niveau 2 of 3. Wanneer het ticket wordt geëscaleerd, wordt alles wat de technicus van niveau 1 heeft gedaan, vastgelegd in de runbook zodat de ingenieur van het volgende niveau het wiel niet opnieuw hoeft uit te vinden door dezelfde basisdiagnoses opnieuw uit te voeren. Om dieper op het probleem in te gaan, kunt u gebruikmaken van een enkele ruit om informatie van alle andere tools te bekijken (Splunk, logbestanden, 24×7 prestatiebewakingsoplossingen).
Zodra u het probleem heeft geïdentificeerd - en dit is wat ongeveer 80% van onze tijd voor het oplossen van problemen in beslag neemt - kunt u het probleem oplossen. Dingen oplossen is vrij eenvoudig: misschien de QoS-configuratie wijzigen, misschien verkeer omleiden. En je hebt een automatiseringstool die niet alleen de wijzigingen kan doorvoeren, maar ook automatisch de impact van die wijzigingen kan verifiëren. Dit is eigenlijk belangrijker dan het automatisch pushen van de wijzigingen.
Adaptieve automatisering stelt u vervolgens in staat proactief te controleren of dit probleem zich voordoet, zodat wanneer het weer opduikt (en dat zal waarschijnlijk gebeuren), u het onmiddellijk vastlegt zonder te wachten tot iemand een beslissing neemt over hoe u het moet aanpakken. De stappen van uw niveau 2 ingenieurstool kunnen worden gecodificeerd in een runbook die kan worden geactiveerd om automatisch te worden uitgevoerd in 24 × 7-uitvoering.