406 lines
22 KiB
TeX
406 lines
22 KiB
TeX
\chapter{Resultaten}
|
|
|
|
\begin{itemize}
|
|
\item Wat is automatisering
|
|
\begin{itemize}
|
|
\item Toelichting belang data (management)
|
|
\end{itemize}
|
|
\item Huidige situatie
|
|
\begin{itemize}
|
|
\item Data management
|
|
\item Processen
|
|
\item Resultaten Data analyse en relatie processen
|
|
\item Kennis \& ervaring (interview en survey)
|
|
\item Toekomstbeeld
|
|
\item Kansen
|
|
\end{itemize}
|
|
\item Mogelijkheden automatiseren (mooie marketing)
|
|
\begin{itemize}
|
|
\item Keuze maken voor ansible
|
|
\item Werking toelichten
|
|
\end{itemize}
|
|
\item Hoe implementeer je automatisering binnen business
|
|
\begin{itemize}
|
|
\item Toelichting tool
|
|
\begin{itemize}
|
|
\item Modules
|
|
\item Inventory
|
|
\end{itemize}
|
|
\item Roadmap voor opdrachtgever
|
|
\begin{itemize}
|
|
\item Dynamic inventory (poc)
|
|
\item Integratie(s) binnen business
|
|
\item Lab omgeving
|
|
\item Cultuurchange
|
|
\item Bedrijfsdocumentatie
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
|
|
\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-servicemanagent 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 categorieen 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 dienstverling 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 paketten 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 hanteerd. 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 onderouden van code is een abstractere programmeertaal een voordeel.
|
|
|
|
|
|
\subsection{Use cases}
|
|
|
|
Er zijn vele usecases voor automatisering. Enkele veelvoorkomende categorieen 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{Tools}
|
|
|
|
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 automatietools de volgende karakteristieken:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Data-extractie en -injectie functionaliteit}\\
|
|
Bevatten een uitgebreid assortiment aan functies waarmee gecomuniceerd 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 automatietool tot volledige potentie te kunnen gebruiken moet deze maximaal geintegreerd 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".
|
|
|
|
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 officiele ondersteuning voor het automatiseren van netwerk gerelateerde taken waaronder configuratie.
|
|
|
|
\subsubsection*{Declaratieve Domain Specific Language}
|
|
|
|
Met Ansible kunnen gebruikers de gewenste staat van hun infrastructuur vastleggen in een Domain Specific Language (afgekort 'DSL'). Deze 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*{Functionaliteit voor netwerkautomatie}
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection*{Uitbreidbaarheid}
|
|
|
|
Ansible is zeer uitbreidbaar door het creeren van in Python geschreven modules waarmee bijna alle gewenste additionele koppelingen en/of functionaliteiten kunnen worden toegevoegd aan de automatietool. Ansible kent de volgende vormen van uitbreidbaarheid:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
\end{enumerate}
|
|
|
|
|
|
\section{Huidige situatie}
|
|
|
|
|
|
\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 wordt met name gerbruik gemaakt van 'SuperPuTTY', dit is een opensource tool geoptimaliseerd om een groot aantal apparaten te beheren. 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.
|
|
|
|
|
|
\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 geschreven om bepaalde functionaliteiten te bieden zoals
|
|
|
|
powershell
|
|
cattools
|
|
|
|
|
|
|
|
\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
|
|
\end{itemize}
|
|
|
|
|
|
|
|
\subsubsection{Topdesk}
|
|
|
|
Topdesk is een IT-servicemanagent tool die wordt gebruikt door KEMBIT in het uitvoeren van hun werkzaamheden. TOPDesk faciliteerd in het beheren van het ITIL proces door het bieden van een centraal systeem voor incidenten, changes en projecten.
|
|
|
|
Omdat TOPDesk als centraal punt dient in de dienstverling 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.
|
|
|
|
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.
|
|
|
|
\newcommand{\gray}{\cellcolor{lightgray}}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\caption{Templates met dezelfde eigenschappen (aangegeven met een '+')}
|
|
\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}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[scale=0.6]{changes_tijd_categorie.pdf}
|
|
\caption{Totaal bestede tijd per categorie (percentage)}
|
|
\label{fig:changes_tijd_categorie}
|
|
\end{figure}
|
|
|
|
|
|
\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 per categorie (genormaliseerd)}
|
|
\label{fig:changes_tijd_gemiddeld_categorie}
|
|
\end{figure}
|
|
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[scale=0.8]{changes_tijd_categorie_tijd.pdf}
|
|
\caption{Gespendeerde tijd per categorie over de periode 2020 t/m 2022 (genormaliseerd)}
|
|
\label{fig:changes_tijd_categorie_tijd}
|
|
\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}
|
|
|
|
\textbf{TODO}
|
|
\begin{enumerate}
|
|
\item Intro van werkzaamheden
|
|
\item Kort overzicht van processen
|
|
\end{enumerate}
|
|
|
|
\begin{itemize}
|
|
\item Facturatieproces
|
|
\item Onderhoudsproces
|
|
\item Securityproces
|
|
\item Monitoringsproces
|
|
\item Backupproces
|
|
\item Beheerproces
|
|
\end{itemize}
|
|
|
|
|
|
\section{Implementeren van netwerk automatisering}
|
|
|
|
|
|
|
|
\section{Roadmap}
|
|
|
|
|
|
|
|
|
|
|