Compare commits
3 Commits
e85d867a62
...
v2.0
| Author | SHA1 | Date | |
|---|---|---|---|
| 4ea946f281 | |||
| 54bf25221d | |||
| 0e30a781e6 |
@ -103,4 +103,40 @@
|
||||
year = 2022,
|
||||
url = {https://github.com/ansible/awx},
|
||||
urldate = {2022-06-08}
|
||||
}
|
||||
|
||||
@article{khan_critical_2022,
|
||||
title = {Critical {Challenges} to {Adopt} {DevOps} {Culture} in {Software} {Organizations}: {A} {Systematic} {Review}},
|
||||
volume = {10},
|
||||
issn = {2169-3536},
|
||||
shorttitle = {Critical {Challenges} to {Adopt} {DevOps} {Culture} in {Software} {Organizations}},
|
||||
url = {https://ieeexplore.ieee.org/document/9690862/},
|
||||
doi = {10.1109/ACCESS.2022.3145970},
|
||||
abstract = {DevOps is a set of practices and a cultural movement that aims to break down barriers between development and operation teams to improve collaboration and communication. Different organizations have embraced DevOps principles due to the massive potential, such as a much shorter time to production, increased reliability and stability. However, despite the widespread adoption of DevOps and its infrastructure, there is a lack of understanding and literature on the key concepts, practices, tools, and challenges associated with implementing DevOps strategies. The main goal of this research paper is to explore and discuss challenges related to DevOps culture and practices. Moreover, it describes how DevOps works in an organization, provides a detailed explanation of DevOps, and investigates the cultural challenges that organizations face when implementing DevOps. The proposed paper reveals ten critical challenges that need to be addressed in adopting the DevOps culture. The challenges are further analyzed on the basis of the various continents. According to the findings, the following critical challenges are considered during the implementation of a DevOps culture: lack of collaboration and communication, Lack of skill and knowledge, complicated infrastructure, Lack of management, Lack of DevOps approach, and trust confidence problems.},
|
||||
language = {en},
|
||||
urldate = {2022-05-13},
|
||||
journal = {IEEE Access},
|
||||
author = {Khan, Muhammad Shoaib and Khan, Abudul Wahid and Khan, Faheem and Khan, Muhammad Adnan and Whangbo, Taeg Keun},
|
||||
year = {2022},
|
||||
pages = {14339--14349},
|
||||
}
|
||||
|
||||
@inproceedings{jabbari_what_2016,
|
||||
address = {Edinburgh Scotland UK},
|
||||
title = {What is {DevOps}?: {A} {Systematic} {Mapping} {Study} on {Definitions} and {Practices}},
|
||||
isbn = {978-1-4503-4134-9},
|
||||
shorttitle = {What is {DevOps}?},
|
||||
url = {https://dl.acm.org/doi/10.1145/2962695.2962707},
|
||||
doi = {10.1145/2962695.2962707},
|
||||
abstract = {Objective:This study aims to characterize DevOps by exploring central components of DevOps definitions reported in the literature, specifying practices explicitly proposed for DevOps and investigating the similarities and differences between DevOps and other existing methods in software engineering.
|
||||
Method: A systematic mapping study was conducted that used six electronic databases: IEEE, ACM, Inspec, Scopus, Wiley Online Library and Web of Science.
|
||||
Result: 44 studies have been selected that report a definition of DevOps, 15 studies explicitly stating DevOps practices, and 15 studies stating how DevOps is related to other existing methods. Papers in some cases stated a combination of a definition, practices, and relations to other methods, the total number of primary studies was 49.
|
||||
Conclusion: We proposed a definition for DevOps which may overcome inconsistencies over the various existing definitions of individual research studies. In addition, the practices explicitly proposed for DevOps have been presented as well as the relation to other software development methods.},
|
||||
language = {en},
|
||||
urldate = {2022-06-11},
|
||||
publisher = {ACM},
|
||||
author = {Jabbari, Ramtin and bin Ali, Nauman and Petersen, Kai and Tanveer, Binish},
|
||||
month = may,
|
||||
year = {2016},
|
||||
pages = {1--11},
|
||||
}
|
||||
@ -3,17 +3,22 @@
|
||||
|
||||
\shortversion{v=1.0, date=2022-05-16, changes=Initiële versie}
|
||||
|
||||
\begin{version}
|
||||
\begin{version}[v=2.0, date=2022-06-15]
|
||||
|
||||
\added
|
||||
\item Conclusie
|
||||
\item Adviezen in hoofdstuk onder de conclusie
|
||||
\item Inleiding voor \ref{section:huidige_situatie}
|
||||
\item Kort stuk over Ansible AWX toegevoegd
|
||||
\item Stuk over DevOps
|
||||
\item Nadelen van Ansible
|
||||
|
||||
\changed
|
||||
\item \textit{jvdb feedback} - Onzekere verwoording 'lijkt' anders verwoord in \ref{bevinding:suboptimale_inrichting_van_topdesk_asset_management}
|
||||
\item Titel veranderd van \ref{subsec:eigenschappen_automatiseringstools} van "tools"
|
||||
\item Diverse zaken toegelicht
|
||||
\item Conclusie geschreven
|
||||
\item Discussie geschreven
|
||||
|
||||
\misc
|
||||
\item Verschillende typfouten verbeterd
|
||||
|
||||
@ -135,7 +135,7 @@ Er zijn vele tools welke automatisering bevorderen of volledig zijn geoptimalise
|
||||
|
||||
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.
|
||||
Ansible is door KEMBIT als automatiseringstool naar keuze verkozen dankzij de flexibiliteit, uitbreidbaar, gebruiksvriendelijkheid en inzetbaarheid in haar huidige productieomgevingen. De tool is initieel 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.
|
||||
|
||||
@ -182,12 +182,37 @@ Om netwerkapparaten aan te sturen zijn verschillende andere mogelijkheden. Ansib
|
||||
|
||||
\subsubsection*{Uitbreidbaarheid}
|
||||
|
||||
Ansible is zeer uitbreidbaar door het creëren van in Python geschreven modules waarmee bijna alle gewenste additionele koppelingen en/of functionaliteiten kunnen worden toegevoegd aan de automatiseringstools. Ansible kent vele vormen van uitbreiding. Hiermee kunnen verschillende aspecten van de tool worden uitgebreid. Met name modules en inventory plugins
|
||||
Ansible is zeer uitbreidbaar door het creëren van in Python geschreven modules waarmee bijna alle gewenste additionele koppelingen en/of functionaliteiten kunnen worden toegevoegd aan de automatiseringstools. Ansible kent vele vormen van uitbreiding. Hiermee kunnen verschillende aspecten van de tool worden uitgebreid. Met name modules en inventory plugins.
|
||||
|
||||
|
||||
\subsubsection*{Nadelen}
|
||||
|
||||
Het gebruikmaken van tools zoals Ansible heeft ook enkele nadelen of zaken om rekening mee te houden. Deze zijn als volgt:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{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 \textbf{Lastig testen.} Het kan lastig zijn om de gemaakte automatisering met Ansible te testen. Dit komt doordat Ansible gemaakt is om acties uit te voeren op productiesystemen en dat de uitgevoerde acties ook afhankelijk zijn van de configuraties van deze systemen. Zonder een testomgeving die een accurate nabootsing is van de productieomgeving is de enige optie om een playbook te testen door de \lstinline{-k} parameter te gebruiker. Deze parameter zorgt ervoor dat Ansible alle veranderingen die de tool zou maken weergeeft aan de gebruiker zonder deze daadwerkelijk te maken.
|
||||
\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 en code.
|
||||
|
||||
Het woord 'DevOps' is een combinatie van de woorden 'development' en 'operations'. Met development wordt het ontwikkelen, testen en onderhouden van software bedoelt door een team die hierin is gespecialiseerd. Het beheren van servers, applicaties en netwerken zijn daarentegen voorbeelden van taken die behoren tot teams of afdelingen die hierin gespecialiseerd zijn, naar deze teams wordt ook wel verwezen met 'operations'.
|
||||
|
||||
Beide teams zijn gespecialiseerd in hun eigen domein. Bij het implementeren van praktijken zoals CI/CD of de wens voor automatisering in het beheren van servers, applicaties of netwerken komt echter overlap in de vereiste vaardigheden, kennis en tooling.
|
||||
|
||||
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.
|
||||
|
||||
Het succesvol automatiseren van taken betekent gebruik kunnen maken van tools, werkwijzes en technieken uit de software development sector. De kennis om dit te doen is over het algemeen niet aanwezig in het team. Dit komt doordat het team gespecialiseerd is in het beheren van netwerkinfrastructuur, niet het ontwikkelen van software. Door het opzetten van een samenwerking met het interne software development team van KEMBIT kan deze benodigde kennis worden binnengehaald in het team.
|
||||
|
||||
|
||||
\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}.
|
||||
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}. Deze praktijken worden regelmatig geassocieerd met DevOps doordat deze praktijken vergelijkbare doelstellingen hebben, het versnellen en automatiseren van ontwikkelcyclus.
|
||||
|
||||
KEMBIT kan deze praktijken ook gebruiken bij het ontwikkelen van automatiseringen en tools. Dit zorgt ervoor dat de ontwikkeling van deze tools sneller en betrouwbaarder wordt.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
@ -218,6 +243,8 @@ Ansible AWX is een applicatie die op een server geïnstalleerd moet worden en ee
|
||||
|
||||
AWX is met name interessant omdat dit CI/CD mogelijk maakt omdat het een API beschikbaar stelt. Hierdoor kunnen andere applicaties bepaalde taken starten door een API call te doen.
|
||||
|
||||
KEMBIT heeft zelf een server geïnstalleerd met AWX en beschikbaar gesteld voor de teams binnen het bedrijf. Op deze manier kan de functionaliteit die de applicatie biedt worden benut voor het (grootschalig) automatiseren van diverse taken met Ansible.
|
||||
|
||||
|
||||
\section{Huidige situatie}\label{section:huidige_situatie}
|
||||
|
||||
@ -239,20 +266,15 @@ Naast het bieden van toegang tot een shell maakt SSH nog veel meer mogelijk zoal
|
||||
|
||||
Het Expert Team Networking heeft al enkele tools in gebruik die gedeeltelijke automatisering mogelijk maken. Zoals vernoemd in het vorige hoofdstuk is de koppeling tussen TOPDesk Asset Management en SuperPuTTY een voorbeeld van een relatief kleine maar waardevolle automatisering.
|
||||
|
||||
Zo zijn verschillende PowerShell tools gemaakt om bepaalde functionaliteiten te bieden zoals het uitvoeren van een commando op een groter aantal netwerkapparaten tegelijkertijd. Hiernaast wordt gebruik gemaakt van Kiwi CatTools \cite{cattools}, een tool die wordt gebruikt om back-ups te maken van productie netwerkapparatuur op een tijdschema.
|
||||
Zo zijn verschillende PowerShell tools gemaakt om bepaalde functionaliteiten te bieden zoals het uitvoeren van een commando op een groter aantal netwerkapparaten tegelijkertijd. Ook wordt PowerShell gebruikt voor het automatiseren van diverse kleine taken in het team.
|
||||
|
||||
Ook wordt gebruik gemaakt van Kiwi CatTools \cite{cattools}, een tool die wordt gebruikt om back-ups te maken van productie netwerkapparatuur op een tijdschema. Deze tool biedt echter een zeer gelimiteerd aantal mogelijkheden en moet alsnog handmatig geconfigureerd worden.
|
||||
|
||||
|
||||
\subsection{Data management}
|
||||
|
||||
Gezien het belang van data is voor het mogelijk maken van automatiseren wordt ten eerste inzichtelijk gemaakt welke data er al opgeslagen wordt, in welk systeem en welke koppelingen deze systemen beschikbaar stellen.
|
||||
|
||||
\begin{itemize}
|
||||
\item TOPDesk
|
||||
\item TOPDesk Asset Management
|
||||
\item PRTG \cite{prtg}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsubsection{Topdesk}
|
||||
|
||||
@ -344,53 +366,55 @@ Onderling zijn er relatief weinig verschillen in deze templates behalve de naam,
|
||||
|
||||
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}.
|
||||
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. Deze gespendeerde tijd wordt in het bedrijf zorgvuldig bijgehouden. De categorieën die in TOPdesk aangemaakt zijn zijn te zien in \ref{tbl:categorieen_topdesk}
|
||||
|
||||
Binnen KEMBIT zijn de categorieën aangemaakt zoals te zien in de volgende tabel:
|
||||
\begin{table}[h]
|
||||
\caption{Categorieën die gebruikt worden door KEMBIT in TOPdesk}
|
||||
\label{tbl:categorieen_topdesk}
|
||||
\begin{tabular}{p{0.2\linewidth} p{0.6\linewidth}}
|
||||
\toprule
|
||||
\textbf{Categorie} & \textbf{Omschrijving}\\
|
||||
\midrule
|
||||
|
||||
\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.\\
|
||||
|
||||
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).\\
|
||||
|
||||
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).\\
|
||||
|
||||
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.\\
|
||||
|
||||
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.\\
|
||||
|
||||
Switch&
|
||||
Het incident of wijziging heeft betrekking tot het apparaat type switch.\\
|
||||
VPN&
|
||||
Het incident of wijziging heeft betrekking tot bepaalde netwerktunnels.\\
|
||||
|
||||
VPN&
|
||||
Het incident of wijziging heeft betrekking tot bepaalde netwerktunnels.\\
|
||||
Bekabeling&
|
||||
Het incident of wijziging heeft betrekking tot netwerkbekabeling.\\
|
||||
|
||||
Bekabeling&
|
||||
Het incident of wijziging heeft betrekking tot netwerkbekabeling.\\
|
||||
SAN / NAS&
|
||||
Het incident of wijziging heeft betrekking tot opslagapparatuur op een netwerk.\\
|
||||
|
||||
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)\\
|
||||
|
||||
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.\\
|
||||
|
||||
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).\\
|
||||
|
||||
Overig&
|
||||
Alle overige incident(en) en/of wijziging(en).\\
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\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 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. Helaas bieden de categorieën van de geanalyseerde tickets en incidenten weinig inzicht in de exacte taak die is uitgevoerd. Hierdoor is het lastig vast te stellen of het toepassen van automatisering op binnen een bepaalde categorie een aanzienlijke tijdsbesparing.
|
||||
|
||||
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.
|
||||
|
||||
@ -414,14 +438,14 @@ In figuur \ref{fig:changes_aantal_categorie} is het aantal changes per categorie
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[scale=0.6]{changes_tijd_gemiddeld_categorie.pdf}
|
||||
\caption{Gemiddelde bestede tijd aan changes per categorie (genormaliseerd)}
|
||||
\caption{Gemiddelde bestede tijd aan changes per categorie (percentage)}
|
||||
\label{fig:changes_tijd_gemiddeld_categorie}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[scale=0.6]{incidenten_tijd_categorie.pdf}
|
||||
\caption{Gemiddelde bestede tijd per categorie (genormaliseerd)}
|
||||
\caption{Gemiddelde bestede tijd per categorie (percentage)}
|
||||
\label{fig:incidenten_tijd_gemiddeld_categorie}
|
||||
\end{figure}
|
||||
|
||||
@ -545,15 +569,20 @@ In dit hoofdstuk wordt een analyse toegepast op de resultaten om vast te stellen
|
||||
|
||||
\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.
|
||||
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. 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{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}
|
||||
|
||||
|
||||
\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.
|
||||
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. Geen gebruik kunnen maken van Ansible op de beheerserver zorgt ervoor dat de tool zeer lastig te gebruiken is voor het team. De reden dat dit nog niet gerealiseerd is is dat het team naar uitsluitend naar AWX kijkt voor het gebruikmaken van Ansible.
|
||||
|
||||
|
||||
\subsection{Geen integratie met gebruikte applicaties}
|
||||
|
||||
Ansible heeft geen bestaande modules en/of plugins om gebruik te kunnen maken van TOPdesk en TOPdesk Asset Management. Dit maakt het minder makkelijk om Ansible te gebruiken, zeker in de dagelijkse werkzaamheden.
|
||||
Ansible heeft geen bestaande modules en/of plugins om gebruik te kunnen maken van TOPdesk en TOPdesk Asset Management. Dit maakt het minder makkelijk om Ansible te gebruiken, zeker in de dagelijkse werkzaamheden. Met name het handmatig moeten samenstellen van een inventory voordat de tool gebruikt kan worden is een taak die veel tijd in beslag neemt en hierdoor een grote reden is dat de tool nog niet gebruikt wordt in de praktijk.
|
||||
|
||||
|
||||
@ -1,5 +1,23 @@
|
||||
\chapter{Conclusie}
|
||||
|
||||
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, hiermee kunnen zij middels een grafische interface en zonder tussenkomen van KEMBIT wijzigingen aanbrengen aan de netwerken van de klant.
|
||||
|
||||
Op dit moment bevindt 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. Dit wordt met name veroorzaakt door de lage adoptie van automatisering door 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 engineers van het Expert Team Networking.
|
||||
|
||||
Gedurende het onderzoek is vastgesteld dat het team nog geen gebruik maakt van Ansible op de beheerserver. Dit zorgt ervoor dat de tool lastig is om te adopteren door de werknemers in hun dagelijkse werkzaamheden. Daarom wordt geadviseerd om het mogelijk te maken om Ansible te gebruiken op de beheerserver van het team.
|
||||
|
||||
Daarnaast is vastgesteld dat de tool niet voldoende is geïntegreerd met andere software die wordt gebruikt door het team. Met name een manier om automatisch informatie over alle apparatuur te verzamelen en te verwerken tot een lijst die ingelezen kan worden door Ansible bestaat nog niet. Dit veroorzaakt dat het gebruik van de tool nog niet toegankelijk is voor het team en lastig toe te passen in de praktijk.
|
||||
|
||||
In dit project is een ontwerp gemaakt voor een Ansible Inventory Plugin waarmee op een geautomatiseerde manier de informatie kan worden opgehaald en verwerkt tot een inventory. De plugin geeft het team een gebruiksvriendelijke manier om informatie in TOPdesk Asset Management te gebruiken in Ansible als een inventory.
|
||||
|
||||
Bij het adopteren van dit soort tools is de tool zelf niet voldoende. Het komt ook neer op het aannemen van een andere werkwijze, een meer gecentreerd rond devops principes. Devops is een set aan principes waarbij developers en operators samenwerken (of dezelfde personen zijn) om een product of service te realiseren door het gebruik van automatisering.
|
||||
|
||||
Development praktijken, tools en mindsets zijn relevant bij het succesvol toepassen van automatisering. Dit onderzoek adviseert de opdrachtgever om hierin te investeren. Bijvoorbeeld door samen te werken en kennis te delen samen met het software development team van KEMBIT.
|
||||
|
||||
Het onderzoek is afgerond met concrete adviezen waarop de opdrachtgever kan acteren om de adoptie van automatie te stimuleren. Daarnaast presenteert het Proof of Concept een effectieve manier om de tools toegankelijker te maken voor het Expert Team Networking. Het onderzoek heeft daarmee de doelstelling behaald.
|
||||
|
||||
|
||||
|
||||
\section{Bevindingen}
|
||||
@ -7,9 +25,33 @@
|
||||
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}
|
||||
\subsection{AWX in plaats van Ansible}
|
||||
|
||||
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.
|
||||
KEMBIT heeft een AWX-server ingericht met als primaire doelstelling om Ansible toegankelijker te maken voor de teams. Wanneer de teams iets met Ansible willen doen, bedoelt men AWX. Helaas is het ontwikkelen van nieuwe playbooks niet gemakkelijk door uitsluitend gebruik te maken van AWX. Dit komt met name door de volgende redenen:
|
||||
|
||||
\begin{itemize}
|
||||
\item Om AWX te gebruiken moet de gebruiker bekend zijn met git, een versiebeheer systeem. De meeste network engineers hebben hier geen ervaring mee en maakt het lastiger om met AWX te werken.
|
||||
\item AWX is niet gebruikersvriendelijk voor het ontwikkelen van een nieuw playbook. Dit komt omdat de gebruiker aanpassingen aan het playbook moet doen, vervolgens deze aanpassing moet pushen naar git, refreshen in AWX en het aangepaste playbook opnieuw moet uitvoeren. Dit maakt het een stuk lastiger om een nieuw playbook te maken.
|
||||
\item AWX biedt geen debugging mogelijkheden zoals het inzien van bepaalde variabelen. Dit zorgt ervoor dat de engineer niet duidelijk weet wat er fout is gegaan indien het playbook faalt.
|
||||
\end{itemize}
|
||||
|
||||
Dit resulteert erin dat de engineers van het team niet snel een playbook kunnen maken of een eenvoudige kleine taak automatiseren met Ansible.
|
||||
|
||||
|
||||
\subsection{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.
|
||||
|
||||
Doordat Ansible niet geïnstalleerd is het niet toegankelijk voor het team om gebruik te maken van Ansible in de dagelijkse werkzaamheden en hierdoor effectieve netwerkautomatisering toe te kunnen passen.
|
||||
|
||||
|
||||
\subsection{Suboptimale inrichting van TOPdesk Asset Management}\label{bevinding:suboptimale_inrichting_van_topdesk_asset_management}
|
||||
|
||||
De tools TOPdesk Asset Management wordt door het Expert Team Networking gebruikt om informatie over fysieke netwerkapparaten in te bewaren. Met de tool kunnen zelf apparaat types (ook wel 'templates') worden gemaakt met hun eigen velden.
|
||||
|
||||
Tijdens het onderzoek is vastgesteld dat de tool zeer veel identieke templates bevat. In de namen van de templates zit informatie die ook als veld opgenomen had kunnen worden. Bijvoorbeeld "Switch 8 Poorten" en "Switch 24 Poorten". Daarnaast zijn ook meerdere templates
|
||||
|
||||
Asset Management wordt niet optimaal ingezet door een suboptimale inrichting van de tool. Dit blijkt door de vele 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)}
|
||||
@ -21,97 +63,12 @@ Met name het ontbreken van een manier waarop een Ansible inventory kan worden ge
|
||||
|
||||
\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.
|
||||
De API van TOPdesk Asset Management is niet gemakkelijk te gebruiken. Dit komt doordat in de tool zelf velden kunnen worden gemaakt. Het is niet eenvoudig om de waardes van deze velden uit de response van de API te halen. In de meeste gevallen zijn hier meerdere verzoeken voor nodig.
|
||||
|
||||
Dit zorgt ervoor dat het niet gemakkelijk is om integraties te realiseren met de tool en verhoogt de complexiteit van de code waarmee de integratie wordt gerealiseerd. Dit zorgt ervoor dat medewerkers niet snel tools zullen bouwen die de API gebruiken doordat dit zoveel tijd kost.
|
||||
|
||||
|
||||
\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.
|
||||
Het team heeft in het verleden bestaande automatisering gerealiseerd met name gebaseerd op PowerShell. Deze tools worden nog steeds ontwikkeld en gebruikt door het team. Hoewel deze PowerShell kennis niet volledig overdraagt naar het gebruik van Ansible betekent het dat het team wel de voordelen ziet van het gebruik van een dergelijke tool. Daarnaast betekent het dat het team in staat is om code te produceren.
|
||||
|
||||
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}
|
||||
|
||||
@ -1,5 +1,15 @@
|
||||
\chapter{Discussie}\label{chap_discussie}
|
||||
|
||||
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 andere nieuwe activiteit ontstaat door het verkrijgen van nieuwe inzichten of het hanteren van een andere aanpak.
|
||||
|
||||
Dit komt ook door de Agile methode waarmee het project is uitgevoerd. De iteratieve aanpak van deze methode is goed bevallen en zorgt voor flexibiliteit en houdt rekening met het feit dat gedurende het project nieuwe activiteiten kunnen ontstaan. Een nadeel aan de methode is dat het lastiger is om te garanderen dat deadlines behaald worden van tevoren. Dit heeft dan ook geleid tot een hogere werkdruk tegen het einde van het project.
|
||||
|
||||
Uiteindelijk heeft de afwijkende planning gezorgd voor een vertraging die is ingehaald binnen een korte periode. Dit is ingehaald door langer door te werken per dag en de weekenden. Over het algemeen is de Agile methode goed bevallen gezien de iteratieve en flexibele eigenschappen, maar moet in de toekomst meer rekening gehouden worden met het behalen van deadlines door duidelijkere milestones te zetten.
|
||||
|
||||
Bijna alle uitgevoerde methodes hebben een positief effect gehad op de uitvoer van het project en uiteindelijk waardevolle resultaten opgeleverd waarop de adviezen zijn gebaseerd. Met name de survey heeft waardevolle inzichten opgeleverd in de ervaringen van het team.
|
||||
|
||||
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. Daarnaast heeft het Proof of Concept van de Ansible plugin bewezen dat de toegevoegde integratie en functionaliteit waardevol is voor de werknemers en Ansible toegankelijker maakt voor het team.
|
||||
|
||||
|
||||
\section{Categorieën in de TOPdesk data analyse}\label{discussie_topdesk_categorie}
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user