work in progress gemerged
This commit is contained in:
@ -2,17 +2,17 @@
|
||||
\item Wat is jouw functie binnen KEMBIT en het Expert Team Networking?\\
|
||||
> Teamleider van het Expert Team Networking. Vertegenwoordigt het networking team tegenover KEMBIT.
|
||||
\item Wat zijn jouw specialisaties?\\
|
||||
> Powershell, Ansible, een beetje Python. Networking expert. Gebruiksvriendelijkheid en optimalisatie van bussiness processen.
|
||||
> Powershell, Ansible, een beetje Python. Networking expert. Gebruiksvriendelijkheid en optimalisatie van business processen.
|
||||
\item Zou je een beknopte omschrijving kunnen geven van de dienstverlening van het expertteam networking?\\
|
||||
> ETN biedt dienstverlening omtrent connectiviteit, network security, bedenken, bouwen, beheren.
|
||||
\item Wat voor een activiteiten zijn hiermee geassocieerd?\\
|
||||
> De algemene categorieen voor activiteiten zijn als volgt: facturatie, process, onderhoudsproces, securityproces, monitoringproces, backupproces, beheerproces.
|
||||
\item Van deze activiteiten, welke zijn in jouw mening het meest ingrijpend en/of het meest interesant om automatisering op toe te passen?\\
|
||||
> De meeste tijd gaat naar het voorbereiden van onderhoud. De tweede is security. Hier moet namelijk worden geinventariseerd welke apparaten beinvloed worden, hier gaat het bijvoorbeeld om de ios versie of bepaalde configuraties. De bestede tijd staat geregistreerd in topdesk voor beheer en security.
|
||||
> De algemene categorieën voor activiteiten zijn als volgt: facturatie, proces, onderhoudsproces, securityproces, monitoringproces, back-upproces, beheerproces.
|
||||
\item Van deze activiteiten, welke zijn in jouw mening het meest ingrijpend en/of het meest interessant om automatisering op toe te passen?\\
|
||||
> De meeste tijd gaat naar het voorbereiden van onderhoud. De tweede is security. Hier moet namelijk worden geïnventariseerd welke apparaten beïnvloed worden, hier gaat het bijvoorbeeld om de ios versie of bepaalde configuraties. De bestede tijd staat geregistreerd in topdesk voor beheer en security.
|
||||
\item Zijn er al oplossingen onderzocht en/of momenteel in gebruik om deze activiteiten te automatiseren?\\
|
||||
> We hebben een onderzoek gedaan naar het automatiseren van backups. Er is daarnaast een onderzoek gedaan naar automatiseringstools, hier is toen vastgesteld dat ansible zeer interessant is voor netwerkautomatisering dankzij de beschikbare ansible modules gericht op netwerkapparatuur.
|
||||
\item Wat zijn de bevindingen over deze oplossingen?\\
|
||||
> Deze onderzoeken zijn interessant maar hebben niet veel nieuwe informatie/inzichten kunnen bieden in het concept en mogelijkheden.
|
||||
\item Heb je een bepaald toekomstbeeld van de manier waarop ETN te werk gaat?\\
|
||||
> (1) ad-hoc werkzaamheden met een automatiseringstool. (2) basic settings globaal kunnen configureren. (3) standaard changes geautomatiseerd uitvoeren. (4) Self service bieden aan klanten. (5) langer termijn, CI/CD.
|
||||
> (1) ad-hocwerkzaamheden met een automatiseringstool. (2) basic settings globaal kunnen configureren. (3) standaard changes geautomatiseerd uitvoeren. (4) Selfservice bieden aan klanten. (5) langer termijn, CI/CD.
|
||||
\end{enumerate}
|
||||
@ -1,17 +1 @@
|
||||
\subsubsection*{Functie / rol}
|
||||
\begin{enumerate}
|
||||
\item Junior/medior/senior
|
||||
\item Specialisatie - Wireless/Routing/Switching/Firewall
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection*{Kennis \& ervaring}
|
||||
\begin{enumerate}
|
||||
\item Programmeren -
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection*{Opinie netwerk automatisering}
|
||||
\begin{enumerate}
|
||||
\item Maak je momenteel gebruik van automatisering voor het uitvoeren van jouw werkzaamheden?
|
||||
\item Zou je gebruik willen maken van automatisering voor het uitvoeren van jouw werkzaamheden?
|
||||
\item Waarom wel/niet?
|
||||
\end{enumerate}s
|
||||
TODO: Voeg notebook in?
|
||||
132
bibliography.bib
132
bibliography.bib
@ -1,43 +1,3 @@
|
||||
@article{einstein,
|
||||
author = "Albert Einstein",
|
||||
title = "{Zur Elektrodynamik bewegter K{\"o}rper}. ({German})
|
||||
[{On} the electrodynamics of moving bodies]",
|
||||
journal = "Annalen der Physik",
|
||||
volume = "322",
|
||||
number = "10",
|
||||
pages = "891--921",
|
||||
year = "1905",
|
||||
DOI = "http://dx.doi.org/10.1002/andp.19053221004",
|
||||
keywords = "physics"
|
||||
}
|
||||
|
||||
@book{dirac,
|
||||
title={The Principles of Quantum Mechanics},
|
||||
author={Paul Adrien Maurice Dirac},
|
||||
isbn={9780198520115},
|
||||
series={International series of monographs on physics},
|
||||
year={1981},
|
||||
publisher={Clarendon Press},
|
||||
keywords = {physics}
|
||||
}
|
||||
|
||||
@online{knuthwebsite,
|
||||
author = "Donald Knuth",
|
||||
title = "Knuth: Computers and Typesetting",
|
||||
url = "http://www-cs-faculty.stanford.edu/~uno/abcde.html",
|
||||
keywords = "latex,knuth"
|
||||
}
|
||||
|
||||
@inbook{knuth-fa,
|
||||
author = "Donald E. Knuth",
|
||||
title = "Fundamental Algorithms",
|
||||
publisher = "Addison-Wesley",
|
||||
year = "1973",
|
||||
chapter = "1.2",
|
||||
keywords = "knuth,programming"
|
||||
}
|
||||
|
||||
|
||||
@book{richards_fundamentals_2020,
|
||||
address = {Sebastopol, CA},
|
||||
edition = {First edition},
|
||||
@ -47,4 +7,94 @@
|
||||
publisher = {O'Reilly Media, Inc},
|
||||
author = {Richards, Mark},
|
||||
year = {2020},
|
||||
}
|
||||
}
|
||||
|
||||
@online{topdesk_asset_management,
|
||||
author = {TOPdesk},
|
||||
title = {Asset Management},
|
||||
year = 2022,
|
||||
url = {https://www.topdesk.com/nl/features/asset-management-software/ },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{topdesk_itsm,
|
||||
author = {TOPdesk},
|
||||
title = {IT Service Management},
|
||||
year = 2022,
|
||||
url = {https://www.topdesk.com/nl/itsm-software/ },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{superputty,
|
||||
author = {Jim Radford},
|
||||
title = {SuperPuTTY},
|
||||
year = 2022,
|
||||
url = {https://github.com/jimradford/superputty },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{openssh,
|
||||
author = {OpenSSH},
|
||||
title = {OpenSSH SSH Protocol Suite Features},
|
||||
year = 2022,
|
||||
url = {https://www.openssh.com/features.html },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{cattools,
|
||||
author = {Solarwinds},
|
||||
title = {Kiwi CatTools -- Network Automation and Configuration Management software},
|
||||
year = 2022,
|
||||
url = {https://www.kiwisyslog.com/kiwi-cattools },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{prtg,
|
||||
author = {Paessler},
|
||||
title = {PRTG Network Monitor},
|
||||
year = 2022,
|
||||
url = {https://www.paessler.com/prtg },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{ansible,
|
||||
author = {Red Hat},
|
||||
title = {Ansible},
|
||||
year = 2022,
|
||||
url = {https://www.ansible.com/ },
|
||||
urldate = {2022-05-02}
|
||||
}
|
||||
|
||||
@online{ansible_install_requirements,
|
||||
author = {Red Hat},
|
||||
title = {Ansible Installation Prerequisites},
|
||||
year = 2022,
|
||||
url = {https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#prerequisites },
|
||||
urldate = {2022-05-06}
|
||||
}
|
||||
|
||||
@article{shahin_continuous_2017,
|
||||
title = {Continuous {Integration}, {Delivery} and {Deployment}: {A} {Systematic} {Review} on {Approaches}, {Tools}, {Challenges} and {Practices}},
|
||||
volume = {5},
|
||||
issn = {2169-3536},
|
||||
shorttitle = {Continuous {Integration}, {Delivery} and {Deployment}},
|
||||
url = {http://ieeexplore.ieee.org/document/7884954/},
|
||||
doi = {10.1109/ACCESS.2017.2685629},
|
||||
abstract = {Continuous practices, i.e., continuous integration, delivery, and deployment, are the software development industry practices that enable organizations to frequently and reliably release new features and products. With the increasing interest in the literature on continuous practices, it is important to systematically review and synthesize the approaches, tools, challenges, and practices reported for adopting and implementing continuous practices. This paper aimed at systematically reviewing the state of the art of continuous practices to classify approaches and tools, identify challenges and practices in this regard, and identify the gaps for future research. We used the systematic literature review method for reviewing the peerreviewed papers on continuous practices published between 2004 and June 1, 2016. We applied the thematic analysis method for analyzing the data extracted from reviewing 69 papers selected using predefined criteria. We have identified 30 approaches and associated tools, which facilitate the implementation of continuous practices in the following ways: 1) reducing build and test time in continuous integration (CI); 2) increasing visibility and awareness on build and test results in CI; 3) supporting (semi-) automated continuous testing; 4) detecting violations, flaws, and faults in CI; 5) addressing security and scalability issues in deployment pipeline; and 6) improving dependability and reliability of deployment process. We have also determined a list of critical factors, such as testing (effort and time), team awareness and transparency, good design principles, customer, highly skilled and motivated team, application domain, and appropriate infrastructure that should be carefully considered when introducing continuous practices in a given organization. The majority of the reviewed papers were validation (34.7\%) and evaluation (36.2\%) research types. This paper also reveals that continuous practices have been successfully applied to both greenfield and maintenance projects. Continuous practices have become an important area of software engineering research and practice. While the reported approaches, tools, and practices are addressing a wide range of challenges, there are several challenges and gaps, which require future research work for improving the capturing and reporting of contextual information in the studies reporting different aspects of continuous practices; gaining a deep understanding of how software-intensive systems should be (re-) architected to support continuous practices; and addressing the lack of knowledge and tools for engineering processes of designing and running secure deployment pipelines.},
|
||||
language = {en},
|
||||
urldate = {2022-05-09},
|
||||
journal = {IEEE Access},
|
||||
author = {Shahin, Mojtaba and Ali Babar, Muhammad and Zhu, Liming},
|
||||
year = {2017},
|
||||
pages = {3909--3943},
|
||||
file = {Shahin et al. - 2017 - Continuous Integration, Delivery and Deployment A.pdf:/home/martijn/Zotero/storage/YVLT9AMI/Shahin et al. - 2017 - Continuous Integration, Delivery and Deployment A.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@online{cisco_netwerk_security,
|
||||
author = {Cisco},
|
||||
title = {Wat is netwerk security?},
|
||||
year = 2022,
|
||||
url = {https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#prerequisites },
|
||||
urldate = {2022-05-12}
|
||||
}
|
||||
|
||||
|
||||
@ -1 +1,3 @@
|
||||
\chapter{Inleiding}
|
||||
\chapter{Inleiding}
|
||||
|
||||
Dit document bevat de methodes, resultaten en conclusie van het onderzoek dat is uitgevoerd voor het Expert Team Networking van KEMBIT. Er is onderzoek gedaan naar knelpunten en mogelijkheden in het toepassen van netwerkautomatisering. En hoe netwerkautomatisering toegankelijk kan worden gemaakt voor de medewerkers van het Expert Team Networking.
|
||||
@ -1,7 +1,12 @@
|
||||
\chapter{Methode}
|
||||
|
||||
Om de onderzoeksvragen te beantwoorden zijn verschillende methodes gebruikt. De samenhang tussen deze methodes is te zien in afbeelding \ref{fig:onderzoeksopzet}. Ten eerste wordt een survey, data-analyse en interview verricht om informatie uit het applicatiedomein te verzamelen. Deze informatie wordt verwerkt en geanalyseerd, hier zullen de behoeftes van de opdrachtgever uit blijken. Het kan ook zijn dat gedurende het interview of survey directe eisen ter sprake komen, deze kunnen gelijk als eis worden opgenomen.
|
||||
|
||||
Daarnaast wordt een literatuurstudie verricht met name om verder te gaan op bestaand onderzoek en bekende oplossingen toepassen op het vervullen van vastgestelde problemen, eisen en mogelijkheden. Op basis hiervan wordt een ontwerp gemaakt van een technische oplossingen en deze wordt uitgewerkt in een Proof of Concept. Met het Proof of Concept kan vervolgens worden gereflecteerd op de eisen samen met de opdrachtgever of door field tests in het applicatiedomein. Dit kan leiden tot het aanpassen, herprioriteren of toevoegen van eisen.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\label{fig:onderzoeksopzet}
|
||||
\includegraphics[scale=0.7]{onderzoeksopzet.pdf}
|
||||
\caption{Onderzoeksopzet diagram}
|
||||
\end{figure}
|
||||
@ -13,7 +18,15 @@ KEMBIT maakt gebruikt van een IT-servicemanagement systeem, genaamd TOPDesk. Dit
|
||||
|
||||
De informatie in het IT-servicemanagement systeem kan dus worden gebruikt voor het beantwoorden van deelvragen 1 en 2 en daarmee inzichten krijgen in de beste plek in het proces om automatisering toe te passen.
|
||||
|
||||
De data-analyse is uitgevoerd met een interactief Python-notebook. In dit interactieve notebook is de code te zien waarmee de resulterende grafieken zijn gemaakt en kan zelfs worden aangepast en opnieuw uitgevoerd om andere inzichten te creeren (interactief). Door deze methode is de validiteit van de gemaakte grafieken goed te controleren.
|
||||
De data-analyse wordt uitgevoerd met een interactief Python-notebook. In dit interactieve notebook is de code te zien waarmee de resulterende grafieken zijn gemaakt en kan zelfs worden aangepast en opnieuw uitgevoerd om andere inzichten te creëren (interactief). Door deze methode is de validiteit van de gemaakte grafieken goed te controleren.
|
||||
|
||||
De data-analyse zal inzichten genereren over data die voldoet aan de volgende criteria:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Het ticket of wijziging is aangemaakt tussen de jaartallen 2020 en 2022.
|
||||
\item Het ticket of wijziging is afgerond.
|
||||
\item Het ticket of wijziging staat op de behandelaarsgroep van het Expert Team Networking.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\section{Interview}
|
||||
@ -37,9 +50,9 @@ De volgende onderwerpen zullen gedurende het interview behandeld worden, zie app
|
||||
|
||||
\section{Survey}
|
||||
|
||||
Het expertteam networking is de doelgroep voor de uiteindelijke oplossing, zij zullen de automatseringsoplossing moeten kunnen toepassen in hun eigen werkzaamheden. Om ervoor te zorgen dat de oplossing is afgestemd op deze eindgebruikers zal een survey worden uitgevoerd. Uit de survey zal moeten blijken onder andere het algemene kennisniveau is binnen automatisering en wat de verwachtingen, wensen en eisen zijn van het Expert Team Networking.
|
||||
Het Expert Team Networking is de doelgroep voor de uiteindelijke oplossing, zij zullen de automatiseringsoplossing moeten kunnen toepassen in hun eigen werkzaamheden. Om ervoor te zorgen dat de oplossing is afgestemd op deze eindgebruikers zal een survey worden uitgevoerd. Uit de survey zal moeten blijken onder andere wat het algemene kennisniveau is binnen automatisering en wat de verwachtingen, wensen en eisen zijn van het Expert Team Networking.
|
||||
|
||||
De resultaten van de survey moeten inzichten geven waarmee de onderzoeksvragen 4 \& 5 beantwoord kunnen worden. De volgende onderwerpen zullen behandeld worden in de survey (zie appendix \ref{appendix:survey} voor de exacte vragen):
|
||||
De resultaten van de survey moeten inzichten geven waarmee de onderzoeksvragen 4 \& 5 beantwoord kunnen worden. De volgende onderwerpen zullen behandeld worden in de survey:
|
||||
|
||||
\begin{itemize}
|
||||
\item Functie
|
||||
@ -65,10 +78,32 @@ Op de resultaten van het interview, survey en data-analyse zal een root cause an
|
||||
|
||||
In een literatuurstudie wordt gezocht naar nieuwe informatie (literatuur). Het doel van de literatuurstudie in dit onderzoek is het vinden van nieuwe manieren om de probleemstelling op te lossen (of met andere woorden; het realiseren van de requirements).
|
||||
|
||||
Gedurende de literatuurstudie worden verschllende zoekmethodes gehanteerd, namelijk:
|
||||
Gedurende de literatuurstudie worden verschillende zoekmethodes gehanteerd, namelijk:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textit{Sneeuwbalmethode} - Het doorzoeken op inhoudelijke resultaten van vorige zoekopdrachten.
|
||||
\item \textit{Parelgroeimethode} - Het doorzoeken op zoekresultaten (niet inhoudelijk, maar het gebruiken van nieuwe zoektermen op basis van zoekresultaten)
|
||||
\item \textit{Citatiezoeken} - Zoeken naar publicaties welke de gevonden publicatie citeerd. Op deze manier kunnen nieuwe publicaties over een vergelijkbaar onderwerp worden gevonden.
|
||||
\end{itemize}
|
||||
|
||||
Bij het uitvoeren van de literatuurstudie is gebruik gemaakt van de volgende zoekmachines: \href{https://www.google.nl/}{google.com} voor het vinden van documentatie, handleidingen en artikelen. En \href{https://bibliotheek.zuyd.nl/}{bibliotheek.zuyd.nl} voor het vinden van academische artikelen.
|
||||
|
||||
Voor het beoordelen van de resultaten zijn een aantal criteria aangehouden. Het doel van het aanhouden van deze criteria is alleen hoogwaardige correcte bronnen toelaten in het onderzoek.
|
||||
|
||||
\begin{enumerate}
|
||||
\item Het betreft een publicatie geschreven door een organisatie of auteur met bepaalde vastgestelde autoriteit op dat domein (bijvoorbeeld Red Hat over Ansible)
|
||||
\item Publicatie heeft 30+ citaties.
|
||||
\item Publicatie is Engels of Nederlandstalig.
|
||||
\end{enumerate}
|
||||
|
||||
De volgende zoektermen zijn gebruikt:
|
||||
|
||||
\begin{itemize}
|
||||
\item Software development best practices
|
||||
\item Ansible
|
||||
\item Networkautomation
|
||||
\item declarative and imperative
|
||||
\item CI/CD
|
||||
\item PRTG
|
||||
\item TOPdesk (Asset Management) (API)
|
||||
\end{itemize}
|
||||
@ -1,42 +1,5 @@
|
||||
\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}
|
||||
|
||||
@ -170,15 +133,17 @@ Er zijn vele tools welke automatisering bevorderen of volledig zijn geoptimalise
|
||||
|
||||
\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 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 officiele ondersteuning voor het automatiseren van netwerk gerelateerde taken waaronder configuratie.
|
||||
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 configureren.
|
||||
|
||||
\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}).
|
||||
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]
|
||||
@ -197,20 +162,54 @@ Met Ansible kunnen gebruikers de gewenste staat van hun infrastructuur vastlegge
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsubsection*{Werking}
|
||||
|
||||
\subsubsection*{Functionaliteit voor netwerkautomatie}
|
||||
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 geinstalleerd 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 definieren 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 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:
|
||||
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 vele vormen van uitbreiding. Hiermee kunnen verschillende aspecten van de tool worden uitgebreid. Met name modules en inventory plugins
|
||||
|
||||
\begin{enumerate}
|
||||
\item
|
||||
\end{enumerate}
|
||||
|
||||
\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}
|
||||
|
||||
|
||||
\section{Huidige situatie}
|
||||
@ -220,22 +219,18 @@ Ansible is zeer uitbreidbaar door het creeren van in Python geschreven modules w
|
||||
|
||||
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.
|
||||
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.
|
||||
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 geschreven om bepaalde functionaliteiten te bieden zoals
|
||||
|
||||
powershell
|
||||
cattools
|
||||
|
||||
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 backups te maken van productie netwerkapparatuur op een tijdschema.
|
||||
|
||||
|
||||
\subsection{Data management}
|
||||
@ -245,14 +240,14 @@ Gezien het belang van data is voor het mogelijk maken van automatiseren wordt te
|
||||
\begin{itemize}
|
||||
\item TOPDesk
|
||||
\item TOPDesk Asset Management
|
||||
\item PRTG
|
||||
\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 faciliteerd in het beheren van het ITIL proces door het bieden van een centraal systeem voor incidenten, changes en projecten.
|
||||
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 \cite{topdesk_itsm}.
|
||||
|
||||
Omdat TOPDesk als centraal punt dient in de dienstverling van KEMBIT kan het integreren hiermee mogelijkheden bieden voor automatisering waaronder:
|
||||
|
||||
@ -266,7 +261,7 @@ Omdat TOPDesk als centraal punt dient in de dienstverling van KEMBIT kan het int
|
||||
|
||||
\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.
|
||||
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).
|
||||
|
||||
@ -288,13 +283,14 @@ Het Expert Team Networking gebruikt Asset Management voor het opslaan van alle n
|
||||
\item UPS
|
||||
\end{enumerate}
|
||||
|
||||
Onderling zijn er relatief weinig verschillen in deze templates behalve de naam.
|
||||
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}&
|
||||
@ -337,13 +333,67 @@ Onderling zijn er relatief weinig verschillen in deze templates behalve de naam.
|
||||
|
||||
\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 per categorie (percentage)}
|
||||
\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
|
||||
@ -355,18 +405,10 @@ Onderling zijn er relatief weinig verschillen in deze templates behalve de naam.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[scale=0.6]{changes_tijd_gemiddeld_categorie.pdf}
|
||||
\caption{Gemiddelde bestede tijd per categorie (genormaliseerd)}
|
||||
\caption{Gemiddelde bestede tijd aan changes 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}
|
||||
@ -377,29 +419,132 @@ Onderling zijn er relatief weinig verschillen in deze templates behalve de naam.
|
||||
|
||||
\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}
|
||||
Dit hoofdstuk documenteert de processen binnen het Expert Team Networking.
|
||||
|
||||
|
||||
\section{Implementeren van netwerk automatisering}
|
||||
\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 geupgraded 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 werknemeners 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}
|
||||
|
||||
|
||||
|
||||
\section{Roadmap}
|
||||
\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 werzaamheden.
|
||||
|
||||
|
||||
@ -1,11 +1,117 @@
|
||||
\chapter{Conclusie}
|
||||
|
||||
Ten eerste kunnen de volgende primaire knelpunten worden gedefinieerd voor het implementeren van netwerkautomatisering in de praktijk:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Reeds gerealiseerde en op Powershell gebaseerde automatiseringen die niet volledig overdragen naar het implementeren van Ansible in de praktijk. Dit maakt investeringen in het realiseren van Ansible op de kortere termijn minder waardevol omdat deze functionaliteiten al mogelijk waren met de oude tools. Hiernaast zijn deze investeringen hoger omdat het nu in een nog relatief onbekende manier moet worden geimplementeerd.
|
||||
\item De reeds bestaande kennis over PowerShell in het netwerking team is niet of minder relevant bij het in gebruik nemen van Ansible. Dit presenteerd weer op de kortere termijn een extra drempel voor het in gebruik nemen van Ansible omdat het nu meer tijd kost om even effectief te zijn met de bestaande powershell tools en/of kennis.
|
||||
\item \label{knelpunt:am_useability} Een relatief complexe API van Asset Management (voornamelijk veroorzaakt door de meta-modeleer functionaliteit). Dit verhoogd de vereiste tijdsinvestering en minimale complexiteit om tools te maken die integreren met deze API
|
||||
\item Geen bestaande integraties met Asset Management. Terwijl het gebruik maken van deze API (direct of indirect) een vereiste is voor het toepassen van Ansible in productie netwerken voor het genereren van een ansible inventory. Dit in combinatie met punt \ref{knelpunt:am_useability} veroorzaakt dat het niet mogelijk is om Ansible te gebruiken en het een hoge upfront investering vereist om op te lossen.
|
||||
\item Asset Management lijkt nog niet volledig optimaal te worden ingezet aan de hand van de templates die grotendeels hetzelfde zijn. Hierdoor is er een grote kans dat de inventory plugin voor Ansible op korte termijn moet worden aangepast om eventuele herstructureringen in Asset Management te reflecteren.
|
||||
\end{enumerate}
|
||||
|
||||
\section{Bevindingen}
|
||||
|
||||
In dit hoofdstuk worden een aantal bevindingen beschreven die zijn getrokken uit het onderzoek. De bevindingen hebben te maken met het (succesvol) toepassen van netwerkautomatisering in de dagelijkse werkzaamheden van het Expert Team Network en probeert inzicht te geven in de huidige situatie.
|
||||
|
||||
|
||||
\subsection{Suboptimale inrichting van TOPdesk Asset Management}
|
||||
|
||||
Asset Management lijkt nog niet volledig optimaal te worden ingezet aan de hand van de templates die grotendeels hetzelfde zijn. Hierdoor is er een grote kans dat eventuele tooling die gebruik maakt van de Asset Management API moet worden aangepast wanneer de configuratie van de templates van Asset Management veranderd worden.
|
||||
|
||||
|
||||
\subsection{Geen bestaande integraties met TOPdesk (Asset Management)}
|
||||
|
||||
TOPdesk en TOPdesk Asset Management is een belangrijk onderdeel van de manier waarop het Expert Team Networking te werk gaat. Het ontbreken van bestaande integraties met Ansible maakt het minder gemakkelijk om Ansible in de dagelijkse werkzaamheden toe te passen.
|
||||
|
||||
Met name het ontbreken van een manier waarop een Ansible inventory kan worden gemaakt op basis van TOPdesk Asset Management zorgt ervoor dat Ansible niet gemakkelijk gebruikt kan worden in de dagelijkse werkzaamheden.
|
||||
|
||||
|
||||
\subsection{Gebruikersvriendelijkheid TOPdesk Asset Management}\label{knelpunt:am_useability}
|
||||
|
||||
Een relatief complexe API van Asset Management (voornamelijk veroorzaakt door de meta-modeleer functionaliteit). Dit verhoogd de vereiste tijdsinvestering en minimale complexiteit om tools te maken die integreren met deze API.
|
||||
|
||||
|
||||
\subsection{Bestaande tooling en kennis omtrent PowerShell}
|
||||
|
||||
De reeds bestaande kennis over PowerShell in het netwerking team is niet of minder relevant bij het in gebruik nemen van Ansible. Dit presenteert een drempel voor het in gebruik nemen van Ansible omdat het meer tijd kost om even effectief te zijn met de bestaande PowerShell tools en/of kennis.
|
||||
|
||||
Reeds gerealiseerde en op Powershell gebaseerde automatiseringen die niet volledig overdragen naar het implementeren van Ansible in de praktijk. Dit maakt investeringen in het realiseren van Ansible op de kortere termijn minder waardevol omdat deze functionaliteiten al mogelijk waren met de oude tools. Hiernaast zijn deze investeringen hoger omdat het nu in een nog relatief onbekende manier moet worden geimplementeerd.
|
||||
|
||||
|
||||
\section{Wensen en eisen}
|
||||
|
||||
Dit hoofdstuk documenteert de wensen en eisen die volgen uit het onderzoek en worden direct of indirect gesteld door de opdrachtgever aan het implementeren van automatisering. Die eisen zijn opgedeeld in functionele- (tabel \ref{tbl:requirements_functioneel}) en niet functionele eisen (tabel \ref{tbl:requirements_nietfunctioneel}).
|
||||
|
||||
|
||||
\newcounter{magicrownumbers}
|
||||
\newcommand\rownumber{\stepcounter{magicrownumbers}\arabic{magicrownumbers}}
|
||||
|
||||
\begin{table}[ht]
|
||||
|
||||
\caption{Functionele eisen}
|
||||
\label{tbl:requirements_functioneel}
|
||||
|
||||
\centering
|
||||
\begin{tabular}{l p{0.2\linewidth} p{0.5\linewidth} l }
|
||||
\toprule
|
||||
& \textbf{Naam}& \textbf{Omschrijving}& \textbf{Prioriteit}\\
|
||||
\midrule
|
||||
|
||||
\rownumber&
|
||||
Asset Management koppeling&
|
||||
De automatiseringstool moet de apparaten kunnen verkrijgen uit het TOPdesk Asset Management systeem.&
|
||||
Must\\
|
||||
|
||||
\rownumber&
|
||||
Toepassing beheer&
|
||||
De automatiseringstool kan worden gebruikt in beheerwerkzaamheden.&
|
||||
Must\\
|
||||
|
||||
\rownumber&
|
||||
TOPdesk incidenten koppeling&
|
||||
Het is mogelijk om via TOPdesk incidenten aan te maken en/of te wijzingen.&
|
||||
Could\\
|
||||
|
||||
\rownumber&
|
||||
TOPdesk changes koppeling&
|
||||
Het is mogelijk om via TOPdesk changes aan te maken en/of te wijzigen.&
|
||||
Could\\
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
|
||||
\end{table}
|
||||
|
||||
\begin{table}[ht]
|
||||
\caption{Niet-functionele eisen}
|
||||
\label{tbl:requirements_nietfunctioneel}
|
||||
\centering
|
||||
\begin{tabular}{l l p{0.5\linewidth} l }
|
||||
\toprule
|
||||
& \textbf{Naam}& \textbf{Omschrijving}& \textbf{Prioriteit}\\
|
||||
\midrule
|
||||
|
||||
\rownumber&
|
||||
Compatability&
|
||||
De automatiseringstool kan worden ingezet in de huidige beheeromgeving en kan werken met de apparatuur die wordt beheerd door het Expert Team Networking.&
|
||||
Must\\
|
||||
|
||||
\rownumber&
|
||||
Extensibility&
|
||||
De automatiseringstools kunnen worden uitgebreid met additionele functionaliteit.&
|
||||
Must\\
|
||||
|
||||
\rownumber&
|
||||
Usability&
|
||||
De automatiseringstools kunnen met minimale training en/of kennis gebruikt worden zodanig dat de doelstelling bereikt kan worden zoals gesteld door de eindgebruiker.&
|
||||
Must\\
|
||||
|
||||
\rownumber&
|
||||
Scalability&
|
||||
Het automatiseringssysteem kan worden ingezet op een grote hoeveelheid netwerkapparaten&
|
||||
Should\\
|
||||
|
||||
|
||||
\rownumber&
|
||||
Maintainability&
|
||||
De automatiseringstools kunnen worden onderhouden door het Networking Team.&
|
||||
Could\\
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
6
chapters/6 - discussie.tex
Normal file
6
chapters/6 - discussie.tex
Normal file
@ -0,0 +1,6 @@
|
||||
\chapter{Discussie}\label{chap_discussie}
|
||||
|
||||
|
||||
\section{Categorieën in de TOPdesk data analyse}\label{discussie_topdesk_categorie}
|
||||
|
||||
De categorie van TOPDesk incidenten en wijzigingen worden door de afdeling 'MSC' ingevuld en niet door het Expert Team Networking zelf. Dit houdt in dat de meeste incidenten worden ingedeeld onder 'internet' of 'wifi' omdat de melder deze twee meestal vernoemd bij een netwerkprobleem terwijl dit niet de oorzaak hoeft te zijn. Het Expert Team Networking maakt over het algemeen geen wijzigingen aan deze categorie. Hierdoor kan een tijdsanalyse uitsluitend gebaseerd op tijd geen volledig correcte representatie zijn van de daadwerkelijke tijdsverdeling van het Expert Team Networking.
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@ -128,7 +128,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.10.0"
|
||||
"version": "3.10.4"
|
||||
},
|
||||
"orig_nbformat": 4
|
||||
},
|
||||
|
||||
37
figures/src/continuous_practices.dot
Normal file
37
figures/src/continuous_practices.dot
Normal file
@ -0,0 +1,37 @@
|
||||
digraph G {
|
||||
|
||||
node [shape=box]
|
||||
rankdir="LR"
|
||||
compound=true
|
||||
|
||||
"Developers" -> "Repository" [label="Commit"]
|
||||
|
||||
subgraph cluster_0 {
|
||||
rankdir="TB"
|
||||
label = "Continuous Integration"
|
||||
"Build" -> "Test"
|
||||
}
|
||||
|
||||
subgraph cluster_1 {
|
||||
rankdir="TB"
|
||||
label = "Continuous Delivery"
|
||||
cd_at [label="Acceptance Test"]
|
||||
cd_prod [label="Production"]
|
||||
cd_at -> cd_prod [label="Manual"]
|
||||
}
|
||||
|
||||
subgraph cluster_2 {
|
||||
rankdir="TB"
|
||||
label = "Continuous Deployment"
|
||||
cde_at [label="Acceptance Test"]
|
||||
cde_prod [label="Production"]
|
||||
|
||||
cde_at -> cde_prod [label="Auto"]
|
||||
}
|
||||
|
||||
"Repository" -> "Build" [lhead=cluster_0]
|
||||
|
||||
"Test" -> cde_at [lhead=cluster_2 ltail=cluster_0]
|
||||
"Test" -> cd_at [lhead=cluster_1 ltail=cluster_0]
|
||||
|
||||
}
|
||||
4
figures/src/event_based_model.dot
Normal file
4
figures/src/event_based_model.dot
Normal file
@ -0,0 +1,4 @@
|
||||
digraph {
|
||||
"Initiating Event" -> "Event Channel"
|
||||
"Event Channel" -> "Event Processor"
|
||||
}
|
||||
@ -1,8 +1,8 @@
|
||||
digraph {
|
||||
node [shape=box]
|
||||
"Data-analyse" -> "Root Cause analyse"
|
||||
"Survey" -> "Root Cause analyse" [label="1"]
|
||||
"Survey" -> "Requirements" [label="2"]
|
||||
"Survey" -> "Root Cause analyse"
|
||||
"Survey" -> "Requirements"
|
||||
"Interview" -> "Root Cause analyse"
|
||||
"Interview" -> "Requirements"
|
||||
"Root Cause analyse" -> "Requirements"
|
||||
|
||||
17
figures/src/root_cause.dot
Normal file
17
figures/src/root_cause.dot
Normal file
@ -0,0 +1,17 @@
|
||||
digraph {
|
||||
node [shape=box]
|
||||
"Tijdsbesparing" -> "Automatisering"
|
||||
"Foutpreventie" -> "Automatisering"
|
||||
"Innovatie" -> "Automatisering"
|
||||
"Self Service Portal" -> "Automatisering"
|
||||
"Automatisering" -> "In gebruik nemen Ansible"
|
||||
"In gebruik nemen Ansible" -> "Lastig om te leren"
|
||||
// "Lastig om te leren" -> "ETN Networking Lab"
|
||||
// "Lastig om te leren" -> "ETN eigen knowledge base / documentatie"
|
||||
"In gebruik nemen Ansible" -> "Niet mogelijk met\nhuidige beheeromgeving"
|
||||
// "Niet mogelijk met huidige beheeromgeving" -> "Installeer WSL op beheerserver"
|
||||
// "Niet mogelijk met huidige beheeromgeving" -> "SSH proxy"
|
||||
"In gebruik nemen Ansible" -> "Geen integratie met\ngebruikte applicaties"
|
||||
// "Geen integratie met gebruikte applicaties" -> "TOPdesk"
|
||||
// "Geen integratie met gebruikte applicaties" -> "TOPdesk Asset Management"
|
||||
}
|
||||
7
main.tex
7
main.tex
@ -70,6 +70,9 @@ Martijn Remmen
|
||||
\usepackage[pdftex,
|
||||
pdfauthor={\auteur},
|
||||
pdftitle={\titel},
|
||||
colorlinks=true,
|
||||
linkcolor=black,
|
||||
citecolor=black,
|
||||
pdfsubject={\project}]{hyperref}
|
||||
|
||||
\titleformat{\chapter}[hang]
|
||||
@ -94,14 +97,12 @@ Martijn Remmen
|
||||
\input{chapters/3 - methode.tex}
|
||||
\input{chapters/4 - resultaten.tex}
|
||||
\input{chapters/5 - conclusie.tex}
|
||||
\input{chapters/6 - discussie.tex}
|
||||
|
||||
\appendix
|
||||
|
||||
\chapter{Interview Patrick Kuepers}\label{appendix:interview}
|
||||
\input{appendix/interview.tex}
|
||||
|
||||
\chapter{Survey Expert Team Networking}\label{appendix:survey}
|
||||
\input{appendix/survey.tex}
|
||||
|
||||
\printbibliography
|
||||
|
||||
|
||||
Reference in New Issue
Block a user