\chapter{Resultaten}


\section{Introductie tot automatisering}

Automatiseren is het (gedeeltelijk) vervangen van menselijke handelingen door een programma. Dit programma verricht dezelfde handelingen (of komt in ieder geval tot hetzelfde resultaat) door gebruik te maken van diverse koppelingen (APIs) met andere systemen. Het doel van automatisering is het omzetten van data naar acties of andere data (afbeelding \ref{fig:automatiserinhighlevel}). Automatisering kan op deze manier worden gezien als een soort koppeling tussen allerlei systemen en/of applicaties.

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.7]{automatisering.pdf}
    \caption{High level automatisering}
    \label{fig:automatiserinhighlevel}
\end{figure}

Figuur \ref{fig:automatiserindecompositie} geeft een aantal eigenschappen weer die een 'automatisering' kan hebben. De \textbf{trigger} is verantwoordelijk voor het opstarten en/of activeren van de automatisering. Dit kan op verschillende manieren, namelijk: op een vaste tijd of tijdschema, handmatig door een persoon of door het optreden van een bepaalde gebeurtenis (bijvoorbeeld dat een server offline gaat of een nieuwe email die binnenkomt). Wanneer sprake is van een gebeurtenis als trigger spreekt men van event-driven.

Bij het uitvoeren is ook sprake van een bepaalde \textbf{context}. Deze context bevat informatie zoals bijvoorbeeld opgegeven parameters. Met deze parameters kan de werking van de automatisering worden beinvloed. Wanneer er sprake is van een event (in event-driven automatisering) is de inhoud van het event ook onderdeel van de context.

Tenslotte is er sprake van bepaalde \textbf{acties} die worden uitgevoerd. Afhankelijk van het doel van de automatisering kunnen deze acties sterk verschillen. Omdat de meeste vormen van automatisering echter tussen bestaande systemen afspelen is er bijna altijd sprake van vormen van data-extractie (het \textit{verkrijgen} van informatie uit een systeem), -transformatie (het \textit{omzetten} van data naar andere formaten) en -injectie (het \textit{opslaan of veranderen} van data in bestaande systemen). Bij data-extractie en -injectie wordt meestal gebruik gemaakt van een API (zie \ref{subsection:api})

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.7]{anatomie_automatisering.pdf}
    \caption{Decompositie automatisering}
    \label{fig:automatiserindecompositie}
\end{figure}


\subsection{Data en Data Management}

Data zijn vastgelegde feiten en kunnen betrekking hebben tot elk aspect binnen een business; Een IT-servicemanagement tool om incidenten in bij te houden, een centraal 'directory' systeem om accounts en contactgegevens bij te houden enzovoorts. Al deze data staat verspreid in meerdere verschillende software en formaten elk gespecialiseerd om deze te verwerken en/of op te slaan.

In elk domein zijn andere data relevant. Voor netwerkbeheer kunnen hoofdzakelijk de volgende categorieën worden gedefinieerd:

\begin{itemize}
    \item Apparatuur (CMDB)\\
        Gegevens met betrekking tot de apparatuur zoals de fabrikant, model, mogelijkheden enzovoorts.
    \item Netwerkconfiguratie\\
        De technische gegevens van een netwerk zoals IP-adressen, netwerken, poortconfiguraties enzovoorts.
    \item Klanten (CRM)\\
        Gegevens over klanten en locaties zoals contactgegevens en fysieke adressen.
    \item Service Management (ITSM)\\
        Een systeem waarin het proces met betrekking tot de dienstverlening in wordt bijgehouden (bijvoorbeeld incidenten en changes).
    \item Monitoring\\
        Gegevens over de operationele status van netwerken en de apparatuur die zich hierin bevind.
\end{itemize}

\subsection{Application Programming Interfaces}\label{subsection:api}

Een API kan vele vormen hebben en kenmerkt zich altijd als een manier om gebruik te maken van bestaande functionaliteit (waaronder het ophalen van gegevens). Er bestaan meerdere vormen van API's. Bijvoorbeeld softwarelibraries en Web APIs. Softwarelibaries zijn meestal kant-en-klare pakketten die te downloaden zijn om bepaalde (gespecialiseerde) functionaliteit te bieden voor een softwareontwikkelaar. Op deze manier hoeft een softwareontwikkelaar niet alles zelf te schrijven maar kan gebruik worden gemaakt van bestaande en geteste code.

Een Web API is een koppeling die gebruikt kan worden over een netwerk en data formaten zoals JSON of XML hanteert. Populaire Web API-standaarden zijn bijvoorbeeld REST en GraphQL. De voornaamste eigenschap van een web api is dat deze communicatie mogelijk maakt tussen verschillende programmeertalen, frameworks en externe systemen.


\subsection{Event-Driven}

Veel usecases zetten automatisering in om bepaalde acties uit te voeren naar aanleiding van een bepaalde gebeurtenis. Bijvoorbeeld een account aanmaken op het moment dat hier een verzoek voor binnenkomt. Of de configuratie van een apparaat wijzigen op het moment dat een aanpassing wordt gemaakt in een Configuration Management Database. Het asynchroon ontvangen en verwerken van deze gebeurtenissen is wat de term 'event-driven' betekent \cite{richards_fundamentals_2020}.


\subsection{Declaratief en imperatief}

Imperatief en declaratief zijn programmeerconcepten die een bepaalde programmeerstijl (of 'schrijfstijl') inhouden. Bij het imperatief programmeren wordt beschreven \textit{hoe} tot een bepaald eindresultaat moet worden gekomen. Dit houd dus in het een voor een beschrijven van stappen en instructies om bijvoorbeeld een gebruikersaccount aan te maken. In afbeelding \ref{fig:imperatief_voorbeeld} wordt een voorbeeld gegeven van een imperatief geschreven routine voor het aanmaken van nieuwe gebruikers.

\begin{figure}[h]
\begin{lstlisting}[language=python]
    username = 'jdoe'
    password = 'hunter02'

    if userExists(username):
        user := getUser(username)
    else:
        user := createUser(username, password)

    if length(password) > 7 and
       contains(password, "!@#$%^&*()"):
       setUserPassword(user, password)
    else:
        print("Password not valid")
\end{lstlisting}
\caption{Voorbeeld imperatieve schrijfstijl}
\label{fig:imperatief_voorbeeld}
\end{figure}

Bij een declaratieve schrijfstijl wordt het eindresultaat beschreven (wat) in plaats van de manier om die te bereiken (hoe). Een declaratieve versie van het voorbeeld in figuur \ref{fig:imperatief_voorbeeld} zou simpelweg een lijst zijn met gebruikers en wachtwoorden, zoals in \ref{fig:declaratief_voorbeeld}.

\begin{figure}[h]
\begin{lstlisting}
    users:
    - username: jdoe
      password: hunter02
    - username: foo
      password: bar
\end{lstlisting}
\caption{Voorbeeld declaratieve schrijfstijl}
\label{fig:declaratief_voorbeeld}
\end{figure}

Een voordeel van een declaratieve schrijfstijl is dat deze beter te begrijpen is. Er hoeft alleen nagedacht te worden over wat het gewenste resultaat is en niet hoe deze bereikt kan worden. Wanneer automatisering wordt toegepast in een afdeling die niet gespecialiseerd is in het ontwikkelen en onderhouden van code is een abstractere programmeertaal een voordeel. 


\subsection{Use cases}

Er zijn vele usecases voor automatisering. Enkele veelvoorkomende categorieën zijn bijvoorbeeld configuratie management en event processing.


\subsubsection*{Configuratie management}

Bij \textbf{configuratie management} wordt het genereren en beheren van bepaalde configuraties geautomatiseerd. Deze configuraties kunnen bijvoorbeeld zijn voor bepaalde software zoals webservers, proxies of vpn's. Meestal in de vorm van een tekstbestand. Een configuratie kan een gestructureerde- of semigestructureerde syntax hebben. Bij een gestructureerd syntax worden bijvoorbeeld JSON, XML of INI gebruikt.

Bij een semigestructureerde syntax wordt geen gebruik gemaakt van een bepaald gestandaardiseerd formaat en lijkt deze meer op text. In deze text zit een vorm van structuur maar zal eerst 'geparsed' moeten worden om deze om te zetten in volledig gestructureerde data. Het produceren van een semigestructureerde data kan worden gedaan door 'templating', dit is een techniek waarbij programmatisch lappen text worden gegenereerd aan de hand van een gestructureerd dataformaat.


\subsubsection*{Event processing}

Bij event processing is het doel om bepaalde acties uit te voeren als reactie op een bepaalde gebeurtenis. Bijvoorbeeld een welkomstmail sturen op het moment dat een nieuwe gebruiker wordt aangemaakt in een CRM. Het realiseren van dit soort automatiseringen is grotendeels afhankelijk van de functionaliteiten van de applicatie waarin de gebeurtenis optreed. Deze applicatie zal in staat moeten zijn om een signaal af te geven op het moment dat een opgegeven gebeurtenis optreed.


\subsection{Eigenschappen van automatiseringstools}\label{subsec:eigenschappen_automatiseringstools}

Er zijn vele tools welke automatisering bevorderen of volledig zijn geoptimaliseerd voor een 'automatisering'-usecase. Dit houdt onder andere in dat de tools veel functionaliteiten bevatten voor het verwerken van data en het communiceren met systemen. Over het algemeen hebben automatiseringstools de volgende karakteristieken:

\begin{enumerate}
    \item \textbf{Data-extractie en -injectie functionaliteit}\\
        Bevatten een uitgebreid assortiment aan functies waarmee gecommuniceerd kan worden met verschillende systemen en in verschillende datastructuren en protocollen.
    \item \textbf{Data transformatie functionaliteit}\\
        Bevatten een uitgebreid assortiment aan functies waarmee veelvoorkomende operaties kunnen worden uitgevoerd op data. Zoals filteren, sorteren en omzetten van datastructuren.
    \item \textbf{Declaratieve syntax}\\
        Hebben een manier om op een declaratieve manier de taak vast te leggen.
    \item \textbf{Uitbreidbaar}\\
        Kan worden uitgebreid wanneer er geen bestaande functionaliteit zijn om het gewenste resultaat te bereiken. Dit is belangrijk omdat elke business een andere omgeving heeft. Om een automatiseringstool tot volledige potentie te kunnen gebruiken moet deze maximaal geïntegreerd zijn in de omgeving van een business en het mogelijk maken om seamless met alle software en apparaten te kunnen integreren.
\end{enumerate}


\subsection{Ansible}

Ansible is een op Python gebaseerde tool waarmee zeer diverse soorten automatiseringen kunnen worden gerealiseerd dankzij een uitgebreid assortiment aan eenvoudig te gebruiken modules en een YAML gebaseerde "Domain Specific Language" \cite{ansible}.

Ansible is door KEMBIT als automatiseringstool naar keuze verkozen dankzij de flexibiliteit, uitbreidbaar, gebruiksvriendelijkheid en inzetbaarheid in haar huidige productieomgevingen. De tool is initïeel in gebruik genomen door het Expert Team Infrastructure, een ander team binnen KEMBIT gespecialiseerd in het beheren van servers.

Na evaluatie door het networking team wordt de tool als zeer potentieel beschouwd dankzij het uitgebreide assortiment aan netwerkmodules en officiële ondersteuning voor het automatiseren van netwerk gerelateerde taken waaronder configureren.

\subsubsection*{Declaratieve Domain Specific Language}

Met Ansible kunnen gebruikers de gewenste staat van hun infrastructuur vastleggen in een Domain Specific Language (afgekort 'DSL'). Een DSL is een benaming voor een programmeertaal die is geoptimaliseerd voor een bepaalde usecase.

Ansibles DSL is gebaseerd op YAML in combinatie met text templating door Jinja2. De doelstelling van deze DSL is om relatief gemakkelijk te kunnen schrijven, lezen en onderhouden zonder over uitgebreide programmeerervaring te beschikken. Daarnaast is het doel om alsnog zeer flexibel te zijn door onder andere het aanbieden van text templating functionaliteit waardoor het onder andere mogelijk is om gebruik te maken van bepaalde variabelen in text (zie regel 8 in figuur \ref{fig:playbook_voorbeeld}).

\begin{figure}[h]
\begin{lstlisting}[numbers=left]
- name: Configureer switches
  hosts: switches

  tasks:
  - name: motd banner
    cisco.ios.ios_banner:
      banner: motd
      text: "Dit is switch {{hostname}}"
      state: present
\end{lstlisting}
\caption{Voorbeeld van een Ansible playbook}
\label{fig:playbook_voorbeeld}
\end{figure}


\subsubsection*{Werking}

Ansible werkt op basis van een 'agentless' architectuur. Dit betekent dat er geen software nodig is op de apparatuur die beheerd wordt met Ansible. In het geval van het beheren van netwerkapparatuur is dit een vereiste. Dit komt doordat geen conventionele besturingssystemen worden uitgevoerd op deze apparaten maar een vrij minimalistisch besturingssysteem zonder de mogelijkheid om externe applicaties uit te voeren.

Bij het aansturen van een traditionele server met bijvoorbeeld Linux werkt Ansible door het overzetten van een Python script. Dit Python script wordt door Ansible zelf gegenereerd op basis van het playbook. Vervolgens wordt dit Python script uitgevoerd op het doelsysteem. Dit betekent wel dat Python hierop geïnstalleerd moet zijn.

Ansible heeft ook ondersteuning voor verschillende andere soorten van verbindingen in plaats van het overzetten van een script en het uitvoeren hiervan op het doelsysteem. Deze andere soorten verbindingen worden mogelijk gemaakt door 'connection plugins'. Dit zijn plugins die definiëren hoe Ansible kan communiceren met apparatuur en/of systemen. Omdat de meeste netwerkapparatuur in beheer door het Expert Team Networking (en netwerkapparatuur in het algemeen) geen ondersteuning biedt voor het uitvoeren van applicaties zoals Python zullen deze apparaten op een andere manier aangestuurd dienen te worden.

Om netwerkapparaten aan te sturen zijn verschillende andere mogelijkheden. Ansible biedt de volgende connection plugins voor netwerkapparatuur:

\begin{itemize}
    \item networkcli
    \item netconf
    \item napalm
    \item httpapi
\end{itemize}


\subsubsection*{Uitbreidbaarheid}

Ansible is zeer uitbreidbaar door het creëren van in Python geschreven modules waarmee bijna alle gewenste additionele koppelingen en/of functionaliteiten kunnen worden toegevoegd aan de automatiseringstools. Ansible kent vele vormen van uitbreiding. Hiermee kunnen verschillende aspecten van de tool worden uitgebreid. Met name modules en inventory plugins 


\subsection{Continuous Practices}

Continuous practices zoals continuous integration, delivery en deployment zijn praktijken in de software development sector die ervoor zorgen dat met hoge kwaliteit, regelmaat en betrouwbaarheid nieuwe features en producten kunnen worden uitgebracht \cite{shahin_continuous_2017}.

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.55]{continuous_practices.pdf}
    \caption{Relatie tussen continuous integration, delivery en deployment \cite{shahin_continuous_2017}}
\end{figure}


\textbf{Continuous Integration (CI)} betekent het geautomatiseerd uitvoeren van tests op een codebase nadat hier een wijziging heeft plaatsgevonden. Dit motiveert om regelmatig aanpassingen te maken en publiceren. \cite{shahin_continuous_2017}

De voornaamste redenen voor het toepassen van continuous integration zijn als volgt:

\begin{itemize}
    \item Verminderen van \textit{build en test tijden} bij het ontwikkelen en onderhouden van een actieve codebase \cite{shahin_continuous_2017}.
    \item Vergroten van de \textit{zichtbaarheid en bekendheid} van testresultaten door deze centraal inzichtelijk te maken \cite{shahin_continuous_2017}.
\end{itemize}

In de context van netwerkbeheer kan dat betekenen om netwerkconfiguraties te controleren op bijvoorbeeld security of correctheid wanneer deze worden aangepast in een gecentraliseerde repository.

\textbf{Continuous DElivery (CDE)} betekent om op een geautomatiseerde manier nadat de continuous integration tests volledig zijn doorstaan de nieuwe release naar een testomgeving wordt gepubliceerd en vervolgens handmatig naar een productieomgeving. \cite{shahin_continuous_2017}

\textbf{Continuous Deployment (CD)} gaat een stap verder en publiceert changes structureel en geautomatiseerd naar een productieomgeving. Het gebruik van CD impliceert ook het gebruik van CDE. Alleen is de finale stap van het publiceren naar een productieomgeving niet meer handmatig maar automatisch. \cite{shahin_continuous_2017}


\subsection{Ansible AWX}

Ansible AWX is een applicatie die op een server geïnstalleerd moet worden en een webinterface biedt waarmee Ansible taken kunnen worden gestart en gepland. AWX biedt ook een API waarmee onder andere taken kunnen worden gestart, de status kan worden gecontroleerd en de resultaten kunnen worden opgehaald. Op deze manier biedt AWX een centraal automatieplatform gebaseerd op Ansible \cite{ansible_awx}.

AWX is met name interessant omdat dit CI/CD mogelijk maakt omdat het een API beschikbaar stelt. Hierdoor kunnen andere applicaties bepaalde taken starten door een API call te doen.


\section{Huidige situatie}\label{section:huidige_situatie}

Dit hoofdstuk beschrijft de huidige manier van netwerkbeheer, werkwijze en omgeving waarin het Expert Team Networking zich bevind om te identificeren waar de mogelijkheden en potentiele verbeteringen zijn ten opzichte van netwerkautomatisering.


\subsection{Beheeromgeving}

Het Expert Team Networking beheert een groot aantal netwerkapparaten verspreid over verschillende fysieke locaties en klanten. Om deze apparaten gecentraliseerd te kunnen beheren wordt gebruik gemaakt van virtuele machine die verbonden is met alle locaties door tunnels. Door in te loggen op deze server kan alle apparatuur worden bereikt ondanks deze verschillende fysieke locaties staan en zonder daar naartoe te hoeven gaan om toegang te krijgen tot deze apparatuur.

Op de virtuele machine voorzien van Windows Server wordt met name gebruik gemaakt van 'SuperPuTTY', dit is een opensource tool geoptimaliseerd om een groot aantal apparaten te beheren \cite{superputty}. Dit doet het door meerdere openstaande beheerverbindingen als tabbladen weer te geven en aan de zijkant een paneel met een overzicht van alle netwerkapparatuur te presenteren. Hierdoor kan een beheerverbinding worden opgezet door op het gewenste apparaat te klikken. Het overzicht van alle netwerkapparatuur wordt gegenereerd door een koppeling met TOPDesk Asset Management, een CMDB waar het Expert Team Networking gegevens opslaat over de netwerkapparaten.

Onder 'beheerverbinding' is in dit geval sprake van SSH (secure shell). Dit is een veelzijdig protocol voor het uitwisselen van versleutelde gegevens. In het geval van beheerwerkzaamheden wordt het gebruikt voor het overzetten van commando's en de output van deze commando's. SSH is de primaire manier om verbinding te maken met een netwerkapparaat en deze te configureren of commando's uit te voeren voor bijvoorbeeld troubleshooting.

Naast het bieden van toegang tot een shell maakt SSH nog veel meer mogelijk zoals het (veilig) overzetten van bestanden en het tunnelen van netwerkverkeer \cite{openssh}.


\subsection{Bestaande automatiseringen}

Het Expert Team Networking heeft al enkele tools in gebruik die gedeeltelijke automatisering mogelijk maken. Zoals vernoemd in het vorige hoofdstuk is de koppeling tussen TOPDesk Asset Management en SuperPuTTY een voorbeeld van een relatief kleine maar waardevolle automatisering.

Zo zijn verschillende PowerShell tools gemaakt om bepaalde functionaliteiten te bieden zoals het uitvoeren van een commando op een groter aantal netwerkapparaten tegelijkertijd. Hiernaast wordt gebruik gemaakt van Kiwi CatTools \cite{cattools}, een tool die wordt gebruikt om back-ups te maken van productie netwerkapparatuur op een tijdschema.


\subsection{Data management}

Gezien het belang van data is voor het mogelijk maken van automatiseren wordt ten eerste inzichtelijk gemaakt welke data er al opgeslagen wordt, in welk systeem en welke koppelingen deze systemen beschikbaar stellen.

\begin{itemize}
    \item TOPDesk
    \item TOPDesk Asset Management
    \item PRTG \cite{prtg}
\end{itemize}



\subsubsection{Topdesk}

Topdesk is een IT-servicemanagent tool die wordt gebruikt door KEMBIT in het uitvoeren van hun werkzaamheden. TOPDesk faciliteert in het beheren van het ITIL proces door het bieden van een centraal systeem voor incidenten, changes en projecten \cite{topdesk_itsm}.

Omdat TOPDesk als centraal punt dient in de dienstverlening van KEMBIT kan het integreren hiermee mogelijkheden bieden voor automatisering waaronder:

\begin{itemize}
    \item Automatisch bijwerken van incidenten.
    \item Incidenten/changes als trigger (aanmaken, afhandelen enzovoorts) voor event-driven automatiseringen.
    \item Geautomatiseerd aanmaken van incidenten (bijvoorbeeld wanneer een apparaat offline gaat).
\end{itemize}



\subsubsection{Topdesk Asset Management}

Topdesk Asset Management is een module voor Topdesk die CMDB-functionaliteit toevoegd. Een 'configuration management database' is een systeem die wordt gebruikt voor het opslaan van informatie over hardware en software 'assets'. Dit is handig voor verschillende redenen bijvoorbeeld het bijhouden van bepaalde werkzaamheden die zijn uitgevoerd op een bepaald apparaat zoals reparaties \cite{topdesk_asset_management}.

Een bedrijf kan elk soort apparaat in een CMDB willen opnemen, afhankelijk van het type bedrijf. Voor elk soort apparaat kunnen andere eigenschappen relevant zijn om op te nemen in het CMDB. Bij een server misschien hoeveel memory of harde schijven deze heeft. Maar bij een monitor misschien de resolutie of ondersteunde inputs (vga, hdmi enzovoorts).

Het bijzondere aan TOPDesk Asset Management is dat zelf velden kunnen worden gedefinieerd die een soort apparaat heeft. Dit soort functionaliteit noemt men 'meta-modeleren', Asset Management biedt een model (soorten velden en relaties) waarmee modellen kunnen worden gedefinieerd (zoals monitors, servers of netwerkapparatuur). De gemaakte modellen noemt TOPDesk Asset Management een 'template'. Zo kan dus een template worden gemaakt voor een monitor die de velden 'merk' en 'resolutie' heeft. Of een template voor een server die de velden 'geheugen capaciteit' en 'aantal harde schijven' heeft.

Het Expert Team Networking gebruikt Asset Management voor het opslaan van alle netwerkapparatuur die wordt beheerd en heeft hier zelf templates voor gedefinieerd. De volgende templates zijn gemaakt:

\begin{enumerate}
    \item Switch 8 Poorten
    \item Switch 12 Poorten
    \item Switch 24 Poorten
    \item Switch 48 Poorten
    \item Switch Core
    \item Switch Distributie
    \item Wireless Access Point
    \item Wireless LAN Controller
    \item Firewall
    \item Router
    \item UPS
\end{enumerate}

Onderling zijn er relatief weinig verschillen in deze templates behalve de naam, dit is te zien in tabel \ref{tbl:template_verschil}. 

\newcommand{\gray}{\cellcolor{lightgray}}

\begin{table}[h]
    \centering
    \caption{Templates met dezelfde eigenschappen (aangegeven met een '+')}
    \label{tbl:template_verschil}
    \begin{tabular}{r | r | r | r | r | r | r | r | r | r | r | r |}

        & \rotatebox[origin=l]{90}{Switch 8 Poorten}&
        \rotatebox[origin=l]{90}{Switch 12 Poorten}&
        \rotatebox[origin=l]{90}{Switch 24 Poorten}&
        \rotatebox[origin=l]{90}{Switch 48 Poorten}&
        \rotatebox[origin=l]{90}{Switch Core}&
        \rotatebox[origin=l]{90}{Switch Distributie}&
        \rotatebox[origin=l]{90}{Wireless Access Point}&
        \rotatebox[origin=l]{90}{Wireless LAN Controller}&
        \rotatebox[origin=l]{90}{Firewall}&
        \rotatebox[origin=l]{90}{Router}&
        \rotatebox[origin=l]{90}{UPS}\\

        \hline
        Switch 8 Poorten& \gray  & + & + & + & + & + & & + & + & & + \\
        \hline
        Switch 12 Poorten& \gray & \gray & + & + & + & + &  & + & + & & + \\
        \hline
        Switch 24 Poorten& \gray & \gray & \gray & + & + & + & & + & + & & + \\
        \hline
        Switch 48 Poorten& \gray & \gray & \gray & \gray & + & + & & + & + & & + \\
        \hline
        Switch Core& \gray & \gray & \gray & \gray & \gray & + & & + & + & & + \\
        \hline
        Switch Distributie& \gray & \gray & \gray & \gray & \gray & \gray & & + & + & & + \\
        \hline
        Wireless Access Point& \gray & \gray & \gray & \gray & \gray & \gray & \gray & & & & \\
        \hline
        Wireless LAN Controller& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & + &  & +\\
        \hline
        Firewall& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & & + \\
        \hline
        Router& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \\
        \hline
    \end{tabular}
\end{table}



\subsection{Analyse tijdsbesteding}

Om inzicht te krijgen in de huidige verdeling van tijd per werkzaamheden is een analyse gemaakt van afgeronde tickets en changes door het Expert Team Networking in de periode 2020 tot 2022. Alle grafieken presenteren genormaliseerde waardes (percentages) in plaats van daadwerkelijke tijdseenheden.

Incidenten en Changes in TOPDesk kennen een hoofd- en subcategorie. Deze categorieën kunnen zelf worden aangemaakt door de beheerder aan de hand van de context waarin het systeem wordt gebruikt. Vervolgens kan per incident en/of wijziging een categorie worden geselecteerd. De analyses zijn gemaakt op basis van de ingevulde categorie en gespendeerde tijd per incident en wijziging. Houd rekening met het discussiepunt omtrent het gebruik van de TOPdesk categorieën toegelicht in hoofdstuk \ref{discussie_topdesk_categorie}.

Binnen KEMBIT zijn de categorieën aangemaakt zoals te zien in de volgende tabel:

\begin{tabular}{p{0.2\linewidth} p{0.6\linewidth}}
    \toprule
    \textbf{Categorie} & \textbf{Omschrijving}\\
    \midrule

    Internet&
    Het ticket of wijziging heeft betrekking tot internet biedende functionaliteiten.\\

    Router / Modem&
    Het incident of wijziging heeft betrekking tot router(s) en/of modem(s).\\

    Firewall&
    Het incident of wijziging heeft betrekking tot firewall(s).\\

    Wifi&
    Het incident of wijziging heeft betrekking tot de werking of apparatuur gerelateerd aan het WiFi.\\

    Switch&
    Het incident of wijziging heeft betrekking tot het apparaat type switch.\\

    VPN&
    Het incident of wijziging heeft betrekking tot bepaalde netwerktunnels.\\

    Bekabeling&
    Het incident of wijziging heeft betrekking tot netwerkbekabeling.\\

    SAN / NAS&
    Het incident of wijziging heeft betrekking tot opslagapparatuur op een netwerk.\\

    Appliance&
    Het incident of wijziging heeft betrekking tot een appliance (meestal een virtuele machine)\\

    UPS&
    Het incident of wijziging heeft betrekking tot Uninteruptable Power Supply. Een apparaat welke andere netwerkapparatuur voorziet van energie in het geval van een stroomstoring.\\

    Overig&
    Alle overige incident(en) en/of wijziging(en).\\

    \bottomrule
    
\end{tabular}

In de context van dit project is het met name relevant om het type changes/incidenten te analyseren waar potentieel automatisering bij kan worden toegepast om een beeld te krijgen van de hoeveelheid tijd die kan worden bespaard. Automatisering is met name interessant om toe te passen bij werkzaamheden wanneer een groter aantal apparaten moet worden geconfigureerd of bepaalde informatie van moet worden verkregen. 

In afbeelding \ref{fig:changes_tijd_categorie} is de totale verdeling van gespendeerde tijd te zien per categorie. Uit deze grafiek blijkt dat de meeste tijd wordt besteed aan de 'overige' en 'internet' categorieën. 

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.6]{changes_tijd_categorie.pdf}
    \caption{Totaal bestede tijd aan changes per categorie (percentage)}
    \label{fig:changes_tijd_categorie}
\end{figure}

In figuur \ref{fig:changes_aantal_categorie} is het aantal changes per categorie te zien. Hieruit is af te leiden dat changes met betrekking tot 'Router / Modem' het meest voorkomen maar gemiddeld minder tijd in beslag nemen dan changes die behoren tot de 'Overig' en 'Internet' categorieën.


\begin{figure}[h]
    \centering
    \includegraphics[scale=0.6]{changes_aantal_categorie.pdf}
    \caption{Aantal changes per categorie (percentage)}
    \label{fig:changes_aantal_categorie}
\end{figure}

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.6]{changes_tijd_gemiddeld_categorie.pdf}
    \caption{Gemiddelde bestede tijd aan changes per categorie (genormaliseerd)}
    \label{fig:changes_tijd_gemiddeld_categorie}
\end{figure}

\begin{figure}[h]
    \centering
    \includegraphics[scale=0.6]{incidenten_tijd_categorie.pdf}
    \caption{Gemiddelde bestede tijd per categorie (genormaliseerd)}
    \label{fig:incidenten_tijd_gemiddeld_categorie}
\end{figure}


\subsection{Processen en werkwijze}

Dit hoofdstuk documenteert de processen binnen het Expert Team Networking.


\subsubsection*{Back-upproces}

Binnen het back-upproces valt back-ups maken van gegevens die op netwerkcomponenten staan. Dit betreft voornamelijk de configuratie van het apparaat. Op deze manier kan, wanneer het apparaat uitvalt, snel een vervangend apparaat worden geconfigureerd op basis van de back-up.

Daarnaast is van de back-ups ook af te leiden wat veranderd is sinds de vorige back-up.

Voor dit proces wordt momenteel de tool Kiwi CatTools \cite{cattools} gebruikt. Deze tool wordt uitgevoerd vanaf de beheerserver op een vast tijdschema.


\subsubsection*{Beheerproces}

Het beheerproces bestaat uit diverse taken om de netwerkdiensten mogelijk te kunnen maken. Zoals het afhandelen van incidenten, defecte apparatuur vervangen of opsturen voor reparaties.


\subsubsection*{Facturatieproces}

Klanten die netwerkdiensten afnemen bij KEMBIT betalen maandelijks op basis van de hoeveelheid en type apparaten die het Expert Team Networking in beheer heeft voor deze klant.

Op basis van TOPdesk Asset Management wordt een rapportage gegenereerd. Deze rapportage bevat alle apparatuur inclusief type en tot welke klant deze behoort en wordt door de financiële afdeling binnen KEMBIT gebruikt om een factuur te maken.


\subsubsection*{Monitoringsproces}

Het Expert Team Networking verricht monitoring op de werking en operationele status van alle netwerkapparatuur. Op deze manier kunnen storingen worden gedetecteerd direct wanneer deze voorkomen.

Het Expert Team Networking maakt gebruik van de monitoringsoftware PRTG \cite{prtg} om inzicht te krijgen in de operationele status van netwerken.


\subsubsection*{Onderhoudsproces}

Het Expert Team Networking zorgt ervoor dat alle apparaten voorzien zijn van software-updates. Dit is van belang omdat oudere softwareversies kwetsbaarheden kunnen bevatten die mogelijk het netwerk minder veilig kunnen maken.

Het uitvoeren van dit proces begint bij het selecteren van welke apparaten worden meegenomen en naar welke softwareversie deze apparaten geüpgraded worden. Met het selecteren van een nieuwe softwareversie moet ook rekening gehouden worden met eventuele bekende bugs in deze nieuwe softwareversie. Indien een nieuwere softwareversie wordt gevonden met reeds bekende bugs die geen of weinig invloed hebben op de manier waarop de apparatuur gebruikt wordt kan het onderhoud voorbereid worden.

Het onderhoud voorbereiden betekent het overzetten van de nieuwe software naar de apparatuur. Vervolgens kan het onderhoud uitgevoerd worden in het geplande onderhoudsvenster door de apparatuur te rebooten en de nieuwe softwareversie actief te maken.


\subsubsection*{Securityproces}

Kwetsbaarheden in netwerkinfrastructuur kunnen een mogelijke aanvaller toegang geven tot gevoelige systemen en/of informatie. Binnen het securityproces valt het monitoren en reageren op securityincidenten. Dit wordt onder andere gedaan door security adviezen van het nationaal cyber security centrum te evalueren en indien nodig hier actie op te ondernemen.

Naast het opvolgen van security adviezen wordt gedurende de designfase van netwerkinfrastructuur ook rekening gehouden met networksecurity gerelateerde principes om het design zo veilig mogelijk te maken. Dit kan bijvoorbeeld worden gedaan door het toepassen van netwerksegmentering, toegangscontrole en firewalling \cite{cisco_netwerk_security}.


\section{Visie en wensen}

KEMBIT en het Expert Team Networking willen in de toekomst meer werkzaamheden uitvoeren met automatiseringstools, dit blijkt uit de survey afgenomen van het Expert Team Networking en het interview met opdrachtgever Patrick Kuepers.

In afbeelding \ref{fig:survey_pie_meer_automatisering_mening} is te zien dat het Expert Team Networking gelooft dat automatisering een positief effect heeft op de kwaliteit en tijdigheid van hun dagelijkse werkzaamheden. Daarnaast blijkt uit het antwoord dat medewerkers graag meer gebruik willen maken van automatiseringstools. Als reden wordt voornamelijk voor tijdsbesparing gekozen (afbeedling \ref{fig:suvey_survey_waarom_automatiseren}).

\begin{figure}[h!]
    \centering
    \includegraphics[scale=0.7]{survey_pie_meer_automatisering_mening.pdf}
    \caption{Antwoord op de vraag over het meer gebruikmaken van automatisering in de dagelijkse werkzaamheden.}
    \label{fig:survey_pie_meer_automatisering_mening}
\end{figure}

\begin{figure}[h!]
    \centering
    \includegraphics[scale=0.7]{suvey_survey_waarom_automatiseren.pdf}
    \caption{Waarom medewerkers meer gebruik willen maken van automatiseringstools}
    \label{fig:suvey_survey_waarom_automatiseren}
\end{figure}

Wanneer gevraagd wordt waar de hoogste behoefte ligt aan automatisering wordt het meest gekozen voor beheer gerelateerde werkzaamheden. Dit is te zien in de grafiek in afbeelding \ref{fig:suvey_mening_toepassingsgebied_automatisering}.

\begin{figure}[h!]
    \centering
    \includegraphics[scale=0.7]{suvey_mening_toepassingsgebied_automatisering.pdf}
    \caption{Surveyvraag waar automatisering het meest waardevol is.}
    \label{fig:suvey_mening_toepassingsgebied_automatisering}
\end{figure}

In de surveyvraag in afbeelding \ref{fig:survey_leren_automatiseren} is gevraagd of werknemers van het Expert Team Networking het gemakkelijk vinden om te leren over hoe ze automatiseringen toe kunnen passen. Hier geeft ruim de helft van de werknemers aan dat dit niet gemakkelijk is.

\begin{figure}[h!]
    \centering
    \includegraphics[scale=0.7]{survey_leren_automatiseren.pdf}
    \caption{Is het gemakkelijk om te leren over automatiseren?}
    \label{fig:survey_leren_automatiseren}
\end{figure}



\subsection{Korte termijn}

Uit de survey en het interview blijkt dat medewerkers veel behoefte hebben aan het gebruikmaken van automatiseringstools met name voor werkzaamheden gerelateerd tot onderhoud. Met name een tool waarmee ad hoc commando's uitgevoerd kunnen worden op meerdere apparaten tegelijkertijd.


\subsection{Lange termijn}

Naast de wens om meer gebruik te maken van automatiseringstools in de dagelijkse werkzaamheden is er ook een visie om een selfservice oplossing te bieden aan klanten, namelijk een dashboard waarin klanten zelf interactief wijzigingen kunnen aanbrengen aan de werking van de netwerkinfrastructuur die wordt beheerd door het Expert Team Networking.

Naast het aanbieden van een self service portal is er een wens om CI/CD toe te passen. 'CI' staat voor continuous integration in betekent het geautomatiseerd uitvoeren van tests. In de context van netwerkbeheer kan dat betekenen om configuraties te controleren op bijvoorbeeld security of correctheid voordat deze worden toegepast.

'CD' staat voor continuous delivery en betekent het geautomatiseerd opzetten van een testomgeving gebaseerd op de huidige configuraties. Vervolgens bestaat ook nog continuous deployment, dit is het geautomatiseerd upgraden van een productieomgeving.

Met het toepassen van CI/CD wilt het Expert Team Networking een nieuwe manier van netwerkbeheer toepassen die meer gecentreerd is rond automatisering.


\section{Analyse}

In dit hoofdstuk wordt een analyse toegepast op de resultaten om vast te stellen wat de situatie is van het Expert Team Networking en waar de grootste kansen en problemen liggen bij het toepassen van netwerkautomatisering in de praktijk. Het is duidelijk dat het Expert Team Networking hoge verwachtingen heeft van het toepassen van automatiseringstools in de dagelijkse werkzaamheden, dit is gebleken uit de survey (afbeelding \ref{fig:survey_pie_meer_automatisering_mening}). De voornaamste redenen hiervoor zijn (1) het besparen van tijd, (2) gemak, (3) voorkomen van fouten die worden gemaakt bij repetitieve taken en (4) het bieden van een selfservice portal voor klanten.

\begin{figure}[h!]
    \centering
    \includegraphics[scale=0.7]{root_cause.pdf}
    \caption{Root Cause analyse}
    \label{fig:root_cause}
\end{figure}


\subsection{Lastig om te leren}

Zoals vastgesteld in afbeelding \ref{fig:survey_leren_automatiseren} vinden de meeste werknemers van het Expert Team Networking het lastig om te leren over het toepassen van netwerkautomatisering in hun dagelijkse werkzaamheden.


\subsection{Niet mogelijk in de huidige beheeromgeving}

Het is niet mogelijk om gebruik te maken van Ansible in de huidige beheeromgeving. Dit komt doordat Ansible alleen geïnstalleerd kan worden op unix-achtige besturingssystemen \cite{ansible_install_requirements} en een op Windows-gebaseerde beheerserver wordt gebruikt.


\subsection{Geen integratie met gebruikte applicaties}

Ansible heeft geen bestaande modules en/of plugins om gebruik te kunnen maken van TOPdesk en TOPdesk Asset Management. Dit maakt het minder makkelijk om Ansible te gebruiken, zeker in de dagelijkse werkzaamheden.

