meerdere aanpassingen
This commit is contained in:
@ -185,9 +185,19 @@ Om netwerkapparaten aan te sturen zijn verschillende andere mogelijkheden. Ansib
|
||||
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.
|
||||
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'.
|
||||
|
||||
@ -195,10 +205,14 @@ Beide teams zijn gespecialiseerd in hun eigen domein. Bij het implementeren van
|
||||
|
||||
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
|
||||
@ -229,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}
|
||||
|
||||
@ -250,7 +266,9 @@ 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}
|
||||
@ -348,9 +366,7 @@ 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}.
|
||||
|
||||
Binnen KEMBIT zijn de categorieën aangemaakt zoals te zien in tabel \ref{tbl:categorieen_topdesk}.
|
||||
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}
|
||||
|
||||
\begin{table}[h]
|
||||
\caption{Categorieën die gebruikt worden door KEMBIT in TOPdesk}
|
||||
@ -398,7 +414,7 @@ Binnen KEMBIT zijn de categorieën aangemaakt zoals te zien in tabel \ref{tbl:ca
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
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.
|
||||
|
||||
@ -422,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}
|
||||
|
||||
@ -553,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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user