meerdere wijziginen
This commit is contained in:
@ -23,3 +23,7 @@ Of met `latexmk`:
|
||||
1. `git remote add upstream <template git uri>`
|
||||
2. `git fetch upstream`
|
||||
3. `git merge upstream/master`
|
||||
|
||||
## Commando's
|
||||
|
||||
* Aantal woorden per chapter/sectie/etc: `texcount -sum -merge -q -sub=section main.tex`
|
||||
@ -1,38 +1,27 @@
|
||||
@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"
|
||||
@article{remmen_pva,
|
||||
title = {Plan van Aanpak},
|
||||
language = {nl},
|
||||
author = {Remmen, Martijn},
|
||||
year = 2022,
|
||||
}
|
||||
|
||||
@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}
|
||||
@article{remmen_onderzoeksrapport,
|
||||
title = {Onderzoeksrapport},
|
||||
language = {nl},
|
||||
author = {Remmen, Martijn},
|
||||
year = 2022,
|
||||
}
|
||||
|
||||
@online{knuthwebsite,
|
||||
author = "Donald Knuth",
|
||||
title = "Knuth: Computers and Typesetting",
|
||||
url = "http://www-cs-faculty.stanford.edu/~uno/abcde.html",
|
||||
keywords = "latex,knuth"
|
||||
@article{remmen_advies,
|
||||
title = {Adviesrapport},
|
||||
language = {nl},
|
||||
author = {Remmen, Martijn},
|
||||
year = 2022,
|
||||
}
|
||||
|
||||
@inbook{knuth-fa,
|
||||
author = "Donald E. Knuth",
|
||||
title = "Fundamental Algorithms",
|
||||
publisher = "Addison-Wesley",
|
||||
year = "1973",
|
||||
chapter = "1.2",
|
||||
keywords = "knuth,programming"
|
||||
@article{remmen_ontwerp,
|
||||
title = {Ontwerp: Ansible TOPdesk Asset Management integratie},
|
||||
language = {nl},
|
||||
author = {Remmen, Martijn},
|
||||
year = 2022,
|
||||
}
|
||||
@ -1,16 +1,22 @@
|
||||
\section*{Introductie}
|
||||
|
||||
Het Expert Team Networking van KEMBIT Services verleent netwerkdiensten aan haar klanten waaronder ontwerp, beheer en onderhoud. De netwerken die worden beheerd zijn zeer divers en kunnen sterk verschillen in complexiteit en schaal.
|
||||
Het Expert Team Networking van KEMBIT Services verleent netwerkdiensten aan haar klanten. De netwerken die worden beheerd zijn zeer divers en kunnen sterk verschillen in complexiteit en schaal. Zo heeft het team netwerken in onder andere de zorgsector en grootschalige campusterreinen in beheer.
|
||||
|
||||
Het uitvoeren van beheerwerkzaamheden op een groot aantal netwerkapparaten kan onnodig veel tijd kosten door het uitvoeren van repetitieve taken. Het uitvoeren van dit soort taken is foutgevoelig en inefficiënt.
|
||||
|
||||
Deze bevindingen zijn de drijfveer van het Expert Team Networking om meer automatisering toe te passen in de dagelijkse werkzaamheden. Dit heeft in het verleden ertoe geleid om verschillende powershell scripts te maken die engineers ondersteunen in het (semi-) automatisch uitvoeren van beheerwerkzaamheden.
|
||||
% Het uitvoeren van beheerwerkzaamheden op een groot aantal netwerkapparaten kan onnodig veel tijd kosten door de beheersoverhead die optreed bij het verbinden en configureren van elk individueel apparaat . Het uitvoeren van dit soort taken is foutgevoelig en inefficiënt.
|
||||
|
||||
Deze bestaande automatisering is veel werk om te onderhouden en naarmate gewenste functionaliteiten toenemen en visie voor een selfservice portal ontstaat, wordt gezocht naar een nieuwe, efficiëntere manier om netwerkautomatisering te realiseren.
|
||||
% Het uitvoeren van beheerwerkzaamheden op een groot aantal netwerkapparaten kan onnodig veel tijd kosten door de beheersoverhead die optreed bij het verbinden met elk individueel apparaat en vervolgens configureren hiervan.
|
||||
|
||||
Om deze nieuwe manier van netwerkautomatisering mogelijk te maken wordt naar Ansible gekeken door het Expert Team Networking. Zo zijn diverse Proof of Concepts gerealiseerd die bepaalde functionaliteiten demonstreren. Ondanks de veelbelovende aard van Ansible wordt tot op vandaag nogsteeds geen gebruik gemaakt van Ansible door engineers van het Expert Team Networking.
|
||||
Deze bevindingen zijn de drijfveer van het Expert Team Networking om meer automatisering toe te passen in de dagelijkse werkzaamheden. Dit heeft in het verleden ertoe geleid om te experimenteren met het ontwikkelen en in gebruik nemen van diverse tools die engineers ondersteunen in het (semi-) automatisch uitvoeren van beheerwerkzaamheden.
|
||||
|
||||
De doelstelling van dit onderzoek is om KEMBIT te adviseren in de beste manier om netwerkautomatisering effectief toe te passen in de dagelijkse werkzaamheden. En eventuele zaken die het effectief toepassen van tools verhinderen.
|
||||
Het is veel werk om deze ontwikkelde tools te onderhouden. En naarmate gewenste functionaliteiten toenemen en visie voor een selfservice portal ontstaat, wordt gezocht naar een nieuwe, efficiëntere manier om netwerkautomatisering te realiseren.
|
||||
|
||||
%Om deze nieuwe manier van netwerkautomatisering mogelijk te maken wordt naar Ansible gekeken door het Expert Team Networking. Zo zijn diverse Proof of Concepts gerealiseerd die bepaalde functionaliteiten demonstreren. Ondanks de veelbelovende aard van Ansible wordt tot op vandaag nogsteeds geen gebruik gemaakt van Ansible door engineers van het Expert Team Networking.
|
||||
|
||||
Om deze nieuwe manier van netwerkbeheer mogelijk te maken wordt door het team verwacht dat het aannemen van nieuwe werkwijzes en technieken ervoor zorgen dat zij effectiever beheer uit kunnen voeren.
|
||||
|
||||
De doelstelling van dit onderzoek is om KEMBIT te adviseren in de beste manier om netwerkautomatisering effectief toe te passen in de dagelijkse werkzaamheden.
|
||||
|
||||
\begin{enumerate}
|
||||
\item Onderzoeken van mogelijkheden met betrekking tot netwerkautomatisering die relevant zijn voor het Expert Team Networking.
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
\section*{Theoretisch kader}
|
||||
|
||||
Het Expert Team Networking beheert honderden netwerkapparaten voor diverse klanten op een handmatige manier. Dit stimuleert het team om te zoeken naar technieken en werkwijzes om een efficiëntere manier van netwerkbeheer mogelijk te maken.
|
||||
|
||||
Er bestaan tools om op een (semi-) geautomatiseerde manier netwerkbeheer uit te voeren. Daarnaast bestaan er ook werkwijzes en principes die gebruikmaken van software development technieken om een nieuwe manier van beheer te verrichten. Deze technieken en werkwijzes zijn meer gecentreerd rond het gebruiken van automatisering en het produceren en onderhouden van code.
|
||||
|
||||
Het doel van dit onderzoek is om KEMBIT te voorzien van adviezen en inzichten waarmee automatisering in de werkwijze van het team kan worden opgenomen.
|
||||
|
||||
Het onderzoek heeft betrekking tot diverse tools en werkwijzes.
|
||||
De vraag is hoe KEMBIT haar eigen manier van netwerkbeheer kan innoveren door het gebruiken van tools en het aannemen van werkwijzes. Daarnaast welke werkwijzes en tools relevant zijn voor het bereiken van de gewenste innovaties in netwerkbeheer en hoe deze innovaties geïmplementeerd kunnen worden in de huidige werkwijzes van het team.
|
||||
|
||||
% Het theoretisch kader beschrijft de resultaten van een (quick) literatuurscan waarmee de uit te
|
||||
% voeren opdracht wordt geclassificeerd op basis van:
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
\section*{Methode}
|
||||
|
||||
In dit onderzoek is een survey, interview en data-analyse uitgevoerd. De resultaten van deze methodes worden verwerkt en geanalyseerd middels een root cause analysis. Bevindingen van de root cause analysis leiden tot inzichten in de situatie van het Expert Team Networking en hun eisen en wensen.
|
||||
In dit onderzoek is een survey, interview en data-analyse uitgevoerd om inzichten te krijgen in de wensen, visie en tijdsverdeling van het team \cite{remmen_onderzoeksrapport}. Deze resultaten worden verwerkt en geanalyseerd middels een root cause analysis. Bevindingen van de root cause analysis leiden tot inzichten in de situatie van het Expert Team Networking en hun eisen en wensen.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
@ -9,42 +9,11 @@ In dit onderzoek is een survey, interview en data-analyse uitgevoerd. De resulta
|
||||
\label{fig:onderzoeksmethodes}
|
||||
\end{figure}
|
||||
|
||||
Door het uitvoeren van een literatuurstudie worden bestaande praktijken, oplossingen en informatie verzameld waarmee bevindingen van de analyse kunnen worden onderbouwd of inzicht geven in mogelijke oplossingen. In het ontwerp worden deze mogelijkheden afgewogen op basis van de situatie, wensen en eisen van de opdachtgever. Vervolgens wordt een Proof of Concept gerealiseerd die een gedeelte van het ontwerp demonstreerd.
|
||||
Door het uitvoeren van een literatuurstudie worden bestaande praktijken, oplossingen en informatie verzameld waarmee bevindingen van de analyse kunnen worden onderbouwd of inzicht geven in mogelijke oplossingen. In het ontwerp worden deze mogelijkheden afgewogen op basis van de situatie, wensen en eisen van de opdachtgever \cite{remmen_ontwerp}. Vervolgens wordt een Proof of Concept gerealiseerd die een gedeelte van het ontwerp demonstreerd \cite{remmen_ontwerp}.
|
||||
|
||||
De samenhang van de onderzoeksmethodes is te zien in figuur \ref{fig:onderzoeksmethodes}
|
||||
|
||||
|
||||
\subsection*{Hevner Design Science Research}
|
||||
|
||||
Design Science research (afgekort \textit{'DSR'}) is een framework waarmee iteratief onderzoek kan worden uitgevoerd met als doel om een nieuwe dienst of product te creëren \cite{hevner2004dsr}. De doelstelling van het gebruiken van deze methode is een basis werkstructuur aan te houden die de combinatie tussen onderzoek en het produceren van producten en/of diensten benadrukt. Hierdoor wordt de uiteindelijke kwaliteit van het artifact verhoogd.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{plan-van-aanpak/figures/hevner-dsr-cycle.pdf}
|
||||
\caption{Design Science Research Cycles \cite{hevner2007three}}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection*{The Relevance Cycle}
|
||||
|
||||
De Relevance Cycle zet design research in gang met de omgeving van het probleem en/of vraagstelling. Deze omgeving geeft niet alleen requirements als input aan het project, maar ook acceptatie criteria voor de uiteindelijke resultaten. De output van de Relevance Cycle (artifacts) worden weer terug in deze omgeving geëvalueerd. Uit het resultaat van deze Cyclus moet blijken hoeveel verdere iteraties nodig zijn. Middels deze cyclus wordt gerarandeerd dat het geproduceerde artifact past bij de omgeving (probleemstelling/requirements).
|
||||
|
||||
\subsubsection*{The Rigor Cycle}
|
||||
|
||||
In de Rigor Cycle wordt informatie van een uitgebreid kennisnetwerk verzameld om te garanderen dat het project innovatief is (in tegenstelling tot routine). Deze informatie kan bestaan uit:
|
||||
|
||||
\begin{itemize}
|
||||
\item Reeds uitgevoerd onderzoek
|
||||
\item Ervaringen en expertise die de 'state of the art' definiëren in het toepassingsdomein van het onderzoek.
|
||||
\end{itemize}
|
||||
|
||||
Deze cyclus zorgt ervoor dat kennis, afkomstig van buiten het project, kan worden ingezet \textit{in} het project. Op deze manier wordt voorkomen dat gedurende het project het wiel opnieuw wordt uitgevonden
|
||||
|
||||
\subsubsection*{The Design Cycle}
|
||||
|
||||
De interne design cyclus is het hart van elk design science research project. Deze cyclus van onderzoeksactiviteiten itereert snel tussen het realiseren en evalueren van een artifact.
|
||||
|
||||
|
||||
|
||||
\subsection*{Survey}
|
||||
|
||||
De survey is afgenomen op de medewerkers van het Expert Team Networking met als doelstelling om een beeld te krijgen van de mening, ervaring, wensen en eisen over het toepassen van automatisering in hun dagelijkse werkzaamheden.
|
||||
@ -54,10 +23,6 @@ De survey is afgenomen op de medewerkers van het Expert Team Networking met als
|
||||
|
||||
Er is een data-analyse uitvoerd om inzichten te krijgen in de tijdsverdeling van het uitvoeren van de netwerkwerkzaamheden. Dit soort rapportages waren nog niet beschikbaar in het bedrijf. De inzichten die de data-analyse produceert wordt gebruikt om te bepalen waar het toepassen van automatisering het meest effectief is.
|
||||
|
||||
Om dit te doen zijn rapportages gemaakt van verschillende statistieken in het IT-servicemanagement systeem van KEMBIT genaamd TOPdesk.
|
||||
|
||||
Dit systeem wordt gebruikt voor het bijhouden van tickets, changes en projecten binnen het bedrijf. Hierdoor kunnen rapportages van gegevens in het systeem een indicatie geven van de tijdsverdeling tussen type incidenten en changes van het Expert Team Networking.
|
||||
|
||||
De analyses zijn uitgevoerd op changes en incidenten die zijn aangemaakt in een periode van twee jaar. Hierin worden items meegenomen van alle klanten en type werkzaamheden, zolang deze zijn afgehandeld door het Expert Team Networking.
|
||||
|
||||
|
||||
@ -83,4 +48,20 @@ Gedurende de literatuurstudie worden verschillende zoekmethodes gehanteerd, name
|
||||
|
||||
Het doel van een Root Cause Analyses is om het de oorzaak of oorzaken van een bepaald probleem te vinden. Deze methode wordt gebruikt in dit onderzoek om inzicht te krijgen in de oorzaken voor de lage adoptie van automatiseringstools door het Expert Team Networking.
|
||||
|
||||
Op de bevindingen van deze methode worden adviezen gegeven voor het adresseren van deze oorzaken en uiteindelijk het probleem (grotendeels) verhelpen.
|
||||
Op de bevindingen van deze methode worden adviezen gegeven voor het adresseren van deze oorzaken en uiteindelijk het probleem (grotendeels) verhelpen.
|
||||
|
||||
\subsection*{Hevner Design Science Research}
|
||||
|
||||
Design Science research (afgekort \textit{'DSR'}) is een framework waarmee iteratief onderzoek kan worden uitgevoerd met als doel om een nieuwe dienst of product te creëren \cite{hevner2004dsr} \cite{remmen_pva}. De doelstelling van het gebruiken van deze methode is een basis werkstructuur aan te houden die de combinatie tussen onderzoek en het produceren van producten en/of diensten benadrukt. Hierdoor wordt de uiteindelijke kwaliteit van het artifact verhoogd.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{figures/hevner-dsr-cycle.pdf}
|
||||
\caption{Design Science Research Cycles \cite{hevner2007three} \cite{remmen_pva}}
|
||||
\end{figure}
|
||||
|
||||
\textbf{The Relevance Cycle} De Relevance Cycle zet design research in gang met de omgeving van het probleem en/of vraagstelling. Deze omgeving geeft niet alleen requirements als input aan het project, maar ook acceptatie criteria voor de uiteindelijke resultaten. Onder deze methode vallen de uitgevoerde survey, interview en data-analyse.
|
||||
|
||||
\textbf{The Rigor Cycle} In de Rigor Cycle wordt informatie van een uitgebreid kennisnetwerk verzameld om te garanderen dat het project innovatief is (in tegenstelling tot routine). De literatuurstudie valt binnen deze cyclus
|
||||
|
||||
\textbf{The Design Cycle} De interne design cyclus is het hart van elk design science research project. Deze cyclus van onderzoeksactiviteiten itereert snel tussen het realiseren en evalueren van oplossingen voor de vastgestelde problemen en/of vraagstelling. In de context van dit project wordt in deze cyclus met name geanalyseerd, ontworpen en geadviseerd.
|
||||
@ -1,126 +1,52 @@
|
||||
\section*{Resultaten}
|
||||
|
||||
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.
|
||||
Dit hoofdstuk documenteert de resultaten van het onderzoek.
|
||||
|
||||
|
||||
\subsection*{Declaratief en imperatief}
|
||||
\subsection*{Visie en wensen}
|
||||
|
||||
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*{Eigenschappen van 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.
|
||||
|
||||
|
||||
\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}.
|
||||
KEMBIT en het Expert Team Networking willen meer werkzaamheden uitvoeren met automatiseringstools, dit blijkt uit de survey afgenomen van het Expert Team Networking en het interview met opdrachtgever.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[scale=0.5]{continuous_practices.pdf}
|
||||
\caption{Relatie tussen continuous integration, delivery en deployment \cite{shahin_continuous_2017}}
|
||||
\includegraphics[width=\linewidth]{survey_pie_meer_automatisering_mening.pdf}
|
||||
\caption{Antwoord op de vraag over het meer gebruikmaken van automatisering in de dagelijkse werkzaamheden \cite{remmen_onderzoeksrapport}.}
|
||||
\label{fig:survey_pie_meer_automatisering_mening}
|
||||
\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}
|
||||
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 (afbeelding \ref{fig:survey_waarom_automatiseren}).
|
||||
|
||||
De voornaamste redenen voor het toepassen van continuous integration zijn als volgt:
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{survey_waarom_automatiseren.pdf}
|
||||
\caption{Waarom medewerkers meer gebruik willen maken van automatiseringstools \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:survey_waarom_automatiseren}
|
||||
\end{figure}
|
||||
|
||||
\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 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 automatisering toe kunnen passen. Hier geeft ruim de helft van de werknemers aan dat dit niet gemakkelijk is.
|
||||
|
||||
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}
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
\subsection*{Huidige situatie}
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{survey_leren_automatiseren.pdf}
|
||||
\caption{Is het gemakkelijk om te leren over automatiseren? \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:survey_leren_automatiseren}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection*{Analyse tijdsbesteding}
|
||||
|
||||
Om te evalueren waar potentiele automatiseringen het meest effectief kunnen zijn is een analyse gemaakt van de tijdsbesteding van het Expert Team Networking. Hier wordt gezocht naar werkzaamheden die veel tijd in beslag nemen en met redelijke regelmaat worden uitgevoerd.
|
||||
Om te evalueren waar het toepassen van automatisering het meest effectief kan zijn is een analyse gemaakt van de tijdsbesteding van het Expert Team Networking. Hier wordt gezocht naar werkzaamheden die veel tijd in beslag nemen en met redelijke regelmaat worden uitgevoerd.
|
||||
|
||||
Om dit te doen zijn rapportages gemaakt van verschillende statistieken in het IT-servicemanagement systeem van KEMBIT genaamd TOPdesk.
|
||||
|
||||
Dit systeem wordt gebruikt voor het bijhouden van tickets, changes en projecten binnen het bedrijf. Hierdoor kunnen rapportages van gegevens in het systeem een indicatie geven van de tijdsverdeling tussen type incidenten en changes van het Expert Team Networking.
|
||||
|
||||
In afbeelding \ref{fig:changes_tijd_gemiddeld_categorie} is de totale verdeling van gemiddelde gespendeerde tijd te zien per categorie. Uit deze grafiek blijkt dat de meeste tijd wordt besteed aan changes die behoren tot de 'overige' en 'internet' categorieën.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{changes_tijd_gemiddeld_categorie.pdf}
|
||||
\caption{Gemiddelde bestede tijd aan changes per categorie (percentage)}
|
||||
\caption{Gemiddelde bestede tijd aan changes per categorie (percentage) \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:changes_tijd_gemiddeld_categorie}
|
||||
\end{figure}
|
||||
|
||||
@ -133,7 +59,7 @@ Afbeelding \ref{fig:changes_aantal_categorie} geeft het aantal changes weer per
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{changes_aantal_categorie.pdf}
|
||||
\caption{Aantal changes per categorie (percentage)}
|
||||
\caption{Aantal changes per categorie (percentage) \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:changes_aantal_categorie}
|
||||
\end{figure}
|
||||
|
||||
@ -142,7 +68,7 @@ In figuur \ref{fig:incidenten_tijd_gemiddeld_categorie} is de gemiddelde bestede
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{incidenten_tijd_gemiddeld_categorie.pdf}
|
||||
\caption{Gemiddelde bestede tijd aan incidenten per categorie (percentage)}
|
||||
\caption{Gemiddelde bestede tijd aan incidenten per categorie (percentage) \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:incidenten_tijd_gemiddeld_categorie}
|
||||
\end{figure}
|
||||
|
||||
@ -151,56 +77,117 @@ Hier valt op dat incidenten gerelateerd tot Uninteruptable Power Supplies ('UPS'
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{incidenten_aantal_categorie.pdf}
|
||||
\caption{Aantal incidenten per categorie (percentage)}
|
||||
\caption{Aantal incidenten per categorie (percentage) \cite{remmen_onderzoeksrapport}}
|
||||
\label{fig:incidenten_aantal_categorie}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection*{Visie en wensen}
|
||||
\subsection*{Ansible}
|
||||
|
||||
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.
|
||||
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} \cite{remmen_onderzoeksrapport}.
|
||||
|
||||
Ansible heeft de volgende voordelen voor het Expert Team Networking:
|
||||
|
||||
\begin{itemize}
|
||||
\item Een uitgebreid assortiment van modules en plugins specifiek voor het uitvoeren van geautomatiseerd netwerkbeheer.
|
||||
\item Een toegankelijke en minder complexe syntax voor het specificeren van gewenste configuraties.
|
||||
\item Modulair plugin systeem waarmee de functionaliteiten kunnen worden uitgebreid en koppelingen met andere applicaties in het bedrijf kunnen worden gerealiseerd.
|
||||
\item Automatiseringen gemaakt met Ansible kan worden gebruikt in CI/CD toepassingen door bijvoorbeeld AWX. Met deze software kan een bepaald playbook worden gestart op een tijdschema of vanuit een koppeling met een andere applicatie.
|
||||
\end{itemize}
|
||||
|
||||
Het succesvol gebruiken van Ansible in de praktijk heeft ook verschillende uitdagingen voor het team:
|
||||
|
||||
\begin{itemize}
|
||||
\item Geen general purpose tool. Ondanks de flexibiliteit die Ansible biedt is de tool niet geoptimaliseerd voor usecases anders dan configuration management. Het gebruiken van Ansible voor andere usecases kan limitaties van de syntax van de tool opzoeken. Dit kan de gemaakte automatisering moeilijk onderhoudbaar maken door de complexiteiten in de implementatie.
|
||||
\item Het kan lastig zijn om de gemaakte automatisering met Ansible te testen.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
% \subsection*{DevOps}
|
||||
|
||||
% DevOps is een term in de ICT waarmee verwezen wordt naar het hanteren van bepaalde werkwijzes bij het ontwikkelen en beheren van infrastructuur \cite{remmen_onderzoeksrapport}.
|
||||
|
||||
% Een van de belangrijkste principes van DevOps is de samenwerking en communicatie tussen software development en operationele teams \cite{jabbari_what_2016}. Het doel van deze samenwerking is een beroep te doen op elkaars ervaring en kennis over hun domein. Hiermee kunnen de teams elkaar helpen met het bereiken van hun doelen.
|
||||
|
||||
|
||||
% \subsection*{Continuous Practices}\label{subsec: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} \cite{remmen_onderzoeksrapport}. Deze praktijken kunnen ook door de opdrachtgever gebruikt worden. Hierdoor kan de gemaakte automatisering getest en automatisch ingezet worden. Dit maakt het gemakkelijk voor het team om wijzigingen aan te brengen en toe te passen in productie.
|
||||
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=\linewidth]{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}.
|
||||
|
||||
% \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*{Bevindingen}
|
||||
|
||||
Na analyse van de situatie van de opdrachtgever en mogelijkheden met betrekking tot het implementeren van netwerkautomatisering in de praktijk zijn verschillende zaken vastgesteld \cite{remmen_onderzoeksrapport}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{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}
|
||||
\includegraphics[width=\linewidth]{root_cause.pdf}
|
||||
\caption{Analyse van de situatie van de opdrachtgever met betrekking tot het implementeren van netwerkautomatisering.}
|
||||
\label{fig:root_cause}
|
||||
\end{figure}
|
||||
|
||||
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:survey_waarom_automatiseren}).
|
||||
\textbf{Ansible niet bruikbaar op de beheerserver.} Het Expert Team Networking voert beheer uit vanuit een centrale server. Deze server maakt gebruik van Windows waardoor Ansible niet zomaar geïnstalleerd kan worden. Dit zorgt ervoor dat het team Ansible niet kan gebruiken in productieomgevingen.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{survey_waarom_automatiseren.pdf}
|
||||
\caption{Waarom medewerkers meer gebruik willen maken van automatiseringstools}
|
||||
\label{fig:survey_waarom_automatiseren}
|
||||
\end{figure}
|
||||
\textbf{Geen 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.
|
||||
|
||||
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.
|
||||
\textbf{Lasting om te leren.} Het team ervaart dat het lastig is om te leren over hoe ze Ansible toe kunnen passen in de praktijk. De oorzaak hiervan is met name dat het team nog niet weet hoe de tool impact heeft op hun dagelijkse werkzaamheden. Daarnaast is het nog niet gemakkelijk genoeg om de tool simpelweg uit te proberen in de praktijk. Dit komt omdat binnen het bedrijf uitsluitend met AWX gewerkt wordt in plaats van de CLI tool. Dit maakt het lastiger voor het team om gebruik te maken van Ansible omdat he minder gemakkelijk is om nieuwe een nieuwe automatisering te ontwikkelen met AWX. Dit komt door de volgende redenen:
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{survey_leren_automatiseren.pdf}
|
||||
\caption{Is het gemakkelijk om te leren over automatiseren?}
|
||||
\label{fig:survey_leren_automatiseren}
|
||||
\end{figure}
|
||||
\begin{itemize}
|
||||
\item AWX voegt meer nieuwe concepten toe bovenop het gebruiken van Ansible. De gebruikers moeten leren over versiebeheer en moeten daarnaast de taak aanmaken en configureren in AWX. Dit vraagt om een hoge voorafgaande tijdsinvestering.
|
||||
\item Het is minder gemakkelijk om automatisering te ontwikkelen bij het gebruikmaken van AWX omdat de feedback loop een stuk minder direct is (commit maken > pushen > syncen in AWX > taak aanmaken in AWX > taak starten > output uitlezen) dan wanneer deze wordt ontwikkeld en uitgevoerd op de beheerserver.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section*{Ontwerp}
|
||||
\subsection*{Ontwerp}
|
||||
|
||||
Gedurende het onderzoek is vastgesteld dat het niet gemakkelijk is voor het Expert Team Networking om Ansible te kunnen gebruiken in de dagelijkse werkzaamheden. Een van de redenen hiervoor is het ontbreken van integraties tussen Ansible en andere applicaties die worden gebruikt door het team.
|
||||
|
||||
Dit ontwerp beschrijft een integratie tussen Ansible en TOPdesk Asset Management. Asset Management wordt door het team gebruikt om informatie over de hardware in op te slaan.
|
||||
Dit ontwerp beschrijft een integratie tussen Ansible en TOPdesk Asset Management \cite{remmen_ontwerp}. Asset Management wordt door het team gebruikt om informatie over de hardware in op te slaan.
|
||||
|
||||
De integratie moet het mogelijk maken om automatisch de informatie van Asset Management te verkrijgen en beschikbaar te maken binnen Ansible. Hierdoor hoeft deze informatie niet handmatig te worden ingevoerd. Dit kan namelijk zeer veel tijd in beslag nemen door de grote hoeveelheid aan apparatuur en eigenschappen.
|
||||
|
||||
Het systeem moet voldoen aan de volgende criteria:
|
||||
|
||||
\begin{itemize}
|
||||
\item De informatie over de apparatuur is afkomstig uit TOPdesk Asset Management. Dit is de centrale bron van alle informatie met betrekking tot hardware binnen KEMBIT.
|
||||
\item Actuele informatie. De gegevens die het systeem produceert moet gebaseerd zijn op de actuele informatie zoals beschikbaar is in Asset Management.
|
||||
\item Configureerbare velden. Het moet mogelijk zijn om de namen van velden op te geven die de werknemer nodig heeft voor gebruik in Ansible. Deze velden moeten dan ook worden opgehaald en verwerkt vanuit Asset Management.
|
||||
\item Het systeem moet met minimale training en uitleg zelfstandig gebruikt kunnen worden en dus zo eenvoudig mogelijk zijn om te gebruiken.
|
||||
\item De informatie over de apparatuur is afkomstig uit de centrale bron van alle informatie met betrekking tot hardware binnen KEMBIT.
|
||||
\item De informatie moet actueel zijn.
|
||||
\item Configureerbare velden. De werknemer kan opgeven welke velden moeten worden meegenomen.
|
||||
\item Gebruikers moeten binnen één werkdag kunnen leren werken met het systeem
|
||||
\item De implementatie van het systeem is zo eenvoudig mogelijk om het team niet te belasten met het onderhouden van een zeer complexe codebase.
|
||||
\end{itemize}
|
||||
|
||||
Deze criteria hebben tot de volgende ontwerpkeuzes geleid:
|
||||
|
||||
\begin{itemize}
|
||||
\item Het systeem wordt ontwikkeld als een Ansible Inventory Plugin. Dit zorgt ervoor dat er geen additionele software nodig is om gebruik te kunnen maken van het systeem.
|
||||
\item Maakt gebruik van de TOPdesk Asset Management REST API. Met deze API kunnen actuele gegevens worden opgehaald over de hardware.
|
||||
\end{itemize}
|
||||
|
||||
Het systeem is uitgewerkt tot een Proof of Concept om te testen of het ontwerp functioneel is. Deze moet voldoen aan de ontwerpcriteria die eerder zijn toegelicht. Uiteindelijk heeft het Proof of Concept vastgesteld dat het ontwerp mogelijk is en aan de ontwerpcriteria wordt voldaan.
|
||||
|
||||
|
||||
\subsection*{Adviezen}
|
||||
|
||||
Op basis van het uitgevoerde onderzoek worden diverse adviezen uitgebracht naar de opdrachtgever met betrekking tot de vervolgstappen om netwerkautomatisering te kunnen bevorderen in de dagelijkse werkzaamheden van het Expert Team Networking \cite{remmen_advies}.
|
||||
|
||||
|
||||
\textbf{Installeren van WSL op de beheerserver.} Dit maakt het mogelijk voor het team om Ansible in de dagelijkse werkzaamheden te gebruiken.
|
||||
|
||||
\textbf{Ontwikkelen van nieuwe playbooks met Ansible CLI.} Dit maakt het gemakkelijk voor het team om gebruik te maken van Ansible ten opzichte van AWX door de directere manier van het uitvoeren van playbooks.
|
||||
|
||||
\textbf{Investeren in developmentkennis.} Dit stelt het team in staat om nieuwe werkwijzes en technieken te ontwikkelen en gebruiken die automatisering stimuleren en de huidige werkwijze innoveren.
|
||||
|
||||
\textbf{Rekening houden met de kwaliteiten van Ansible.} Ansible is niet geschikt als general purpose scripttaal maar specifiek voor het automatiseren van configuration management. Bij het overwegen van het gebruik van Ansible moet worden nagedacht of het de juiste tool is voor de gewenste usecase.
|
||||
|
||||
|
||||
@ -1,3 +1,11 @@
|
||||
\section*{Discussie}
|
||||
|
||||
Het onderzoek en de vraag naar wat de beste manier is om netwerkautomatisering effectief toe te passen is lastig om te beantwoorden. Vooral wanneer alle
|
||||
Gedurende het onderzoek is regelmatig van de planning afgeweken. Dit komt met name door het feit dat het zeer lastig is om van tevoren in te schatten hoelang bepaalde activiteiten duren. Daarnaast is het regelmatig voorgekomen dat bij het uitwerken van een activiteit een nieuwe activiteit ontstaat door het verkrijgen van nieuwe inzichten of het hanteren van een andere aanpak.
|
||||
|
||||
Uiteindelijk heeft de afwijkende planning gezorgd voor een redelijke vertraging die is ingehaald binnen een korte periode.
|
||||
|
||||
Het was de bedoeling om het project volgens agile principes uit te voeren. De bedoeling hiermee was het snel opleveren van (tussen)resultaten waarmee samen met de opdrachtgever hierop gereflecteerd kan worden. Over het algemeen zijn deze (tussen)resultaten een stuk minder vaak opgeleverd kunnen worden dan gewild. Dit kan ervoor hebben gezorgd dat de opdrachtgever zich niet betrokken heeft gevoeld bij het project.
|
||||
|
||||
Alle uitgevoerde methodes hebben een positief effect gehad op de uitvoer van het project en uiteindelijk waardevolle resultaten opgeleverd waarop de adviezen zijn gebaseerd.
|
||||
|
||||
Dit onderzoek heeft een aantal concrete adviezen gegeven aan de opdrachtgever over de stappen die ondernomen kunnen worden om netwerkautomatisering in de praktijk te implementeren.
|
||||
@ -2,9 +2,9 @@
|
||||
|
||||
Het Expert Team Networking en KEMBIT hebben een visie voor een nieuwe manier om (netwerk)beheer uit te voeren die meer gecentreerd is rond automatie. Door deze visie zijn investeringen gemaakt in het realiseren van tooling en een selfservice portal voor klanten.
|
||||
|
||||
Op dit moment bevind KEMBIT zich in een lastige positie waarin de visie om te innoveren bestaat maar nog geen concrete vervolgstappen om dit te bereiekn. De bestaande tooling en portal functioneren, maar hebben gelimiteerde impact op de werkwijze van het team.
|
||||
Op dit moment bevind KEMBIT zich in een lastige positie waarin de visie om te innoveren bestaat, maar de vervolgstappen om dit te bereiken niet duidelijk zijn. De bestaande tooling en portal functioneren, maar hebben gelimiteerde impact op de werkwijze van het team.
|
||||
|
||||
Tools zoals Ansible bieden uitgebreide configuration management functionaliteiten voor het beheer van netwerkapparaten. En zijn daarnaast geoptimaliseerd voor gebruikersvriendelijkheid door het bieden van een minder complexe configuratie taal. Hierdoor zijn de tools geschikt voor de netwerkengineers van het Expert Team Networking.
|
||||
Tools zoals Ansible bieden uitgebreide configuration management functionaliteiten voor het beheer van netwerkapparaten. En zijn daarnaast geoptimaliseerd voor gebruikersvriendelijkheid door het bieden van een minder complexe configuratie taal. Hierdoor zijn de tools geschikt voor de engineers van het Expert Team Networking.
|
||||
|
||||
Gedurende het onderzoek is vastgesteld dat het nog niet mogelijk is om Ansible te gebruiken in de huidige beheeromgeving. Hierop wordt aan de opdrachtgever geadviseerd om WSL te installeren op de beheerserver. Hierdoor wordt het mogelijk om Ansible te installeren en hier gebruik van te maken door het team.
|
||||
|
||||
|
||||
@ -1 +1,36 @@
|
||||
\section*{Abstract}
|
||||
\section*{Abstract}
|
||||
|
||||
Het Expert Team Networking biedt netwerkdiensten en beheerd honderden netwerkapparaten voor diverse klanten op een handmatige manier. Dit leidt tot langdurige repetitieve taken en stimuleert het team om te zoeken naar technieken en werkwijzes om een efficiëntere manier van netwerkbeheer mogelijk te maken.
|
||||
|
||||
Het doel van dit onderzoek is om advies te geven over de beste manier waarmee het team effectief gebruik kan maken van netwerkautomatisering in de praktijk.
|
||||
|
||||
% De doelstelling van het onderzoek is de opdrachtgever adviseren in de vervolgstappen om netwerkbeheer efficiënter te maken door het gebruiken van deze technieken en werkwijzes die meer gecentreerd zijn rond automatie.
|
||||
|
||||
Om een beeld te krijgen van de wensen en visie van de opdrachtgever is een interview gehouden. Vervolgens is een survey afgenomen binnen het team om de ervaringen met de huidige manier van het uitvoeren van netwerkbeheer en wensen met betrekking tot automatietools in kaart te brengen. Een analyse is uitgevoerd op de tijdsbesteding van het team door gebruik te maken van gegevens uit het ticketsysteem.
|
||||
|
||||
Het onderzoek concludeert dat om effectief gebruik te maken van Ansible de tool geïntegreerd moet worden in de werkwijzes van het team zodat het zo gemakkelijk mogelijk is voor het team om hier gebruik van te maken. Om dit te bereiken wordt geadviseerd om integraties te realiseren tussen Ansible en TOPdesk Asset Management voor het automatisch ophalen van informatie over de netwerkapparatuur en deze te verwerken tot een lijst van apparatuur die vervolgens in Ansible gebruikt kan worden als inventory.
|
||||
|
||||
% Om dit te doen is onderzoek gedaan naar de wensen, visie en ervaringen van de opdrachtgever en engineers van het team door een interview en survey. Hieruit blijkt dat het team positief is over het gebruikmaken van automatietools in de dagelijkse werkzaamheden.
|
||||
|
||||
% Dit heeft ervoor gezorgd dat het team met tools zoals Ansible hebben geëxperimenteerd. Terwijl deze tool zeer geschikt is voor het team door de uitgebreide functionaliteit voor het automatiseren van configuration in netwerkbeheer en toegankelijke configuratie taal. Wordt deze nog niet gebruikt in de praktijk
|
||||
|
||||
% % Daarnaast blijkt dat team in het verleden tools in gebruik genomen en ontwikkeld met als doelstelling om deze wensen werkelijkheid te maken. Deze tools functioneren maar hebben beperkte impact op de werkwijze van het team en zijn veel werk om te onderhouden.
|
||||
|
||||
% Gedurende het onderzoek is een survey uitgevoerd met het team waaruit is gebleken dat
|
||||
|
||||
% Er is onderzoek gedaan naar het innoveren van de huidige manier van netwerkbeheer door het gebruiken van Ansible en aannemen van praktijken uit de softwaredevelopment sector.
|
||||
|
||||
% aanleiding,
|
||||
% doelstelling,
|
||||
% methode,
|
||||
% resultaten
|
||||
% conclusie
|
||||
|
||||
% etn voert beheer uit op veel apparaten.
|
||||
% Liedt tot het effectiever willen beheren van apparaten en het elimineren van repetitieve werkzaamheden.
|
||||
% Liedt tot het stimuleren van maken van veranderingen in de manier van netwerkbeheer
|
||||
% Heeft geleid tot realiseren van tools.
|
||||
% De tools zijn lastig te onderhouden en bieden nog niet alle gewenste functionaliteit.
|
||||
% Hierdoor heeft het team in het verleden getest met Ansible. Hier is vastgesteld dat de tool zeer toepasselijk is voor het uitvoeren van netwerkbeheer.
|
||||
% Ansible is echter nooit in gebruik genomen door het team. Tewijl het uitgebreide configuration management functionaliteiten biedt voor netwerkbeheer.
|
||||
% Dit komt door
|
||||
Reference in New Issue
Block a user