04_Praxis.tex

\chapter{Entwurf eines Chatbots für eine CMDB} \label{Praxis}

Dieses Kapitel hat zum Ziel, die in \autoref{Validierung} erarbeiteten Anforderungen anhand eines rudimentären Chatbots, der an eine \textit{i-doit} \acs{CMDB} des Herstellers \textit{synetics} angebunden ist, umzusetzen oder deren mögliche Umsetzung zu beschreiben. Dabei wird zunächst die Umsetzung der Qualitätsanforderungen erläutert, da diese sich stärker auf die Systemarchitektur auswirken und die Grundlage für funktionale Anforderungen bilden.
\footcite[Vgl.][9]{Pohl_2015_Requirements}

Das Resultat dieses Kapitels, ein Errbot Plug-in, ist auf GitHub verfügbar.
\footcite[Vgl.][o. \pno]{Weiss_2019_GitHub}

\section{Qualitätsanforderungen}

Auch unter den Qualitätsanforderungen gibt es Abhängigkeiten, weshalb diese aufeinander aufbauend erläutert werden. Angefangen mit der Wahl des Ansatzes und Bot-Frameworks, sowie Gewährleistung von Plattform-Agnostik, Reaktivität und der Möglichkeit, weitere Schnittstellen anzubinden, hin zum Berechtigungskonzept, API-Einsatz und Formatierung des Outputs und schlussendlich zu Anforderungen ohne Abhängigkeiten. 


\subsection{Ansatz, Bot-Framework, Plattform-Agnostik, Schnittstellenanbindung}

Da sich das Bot-Framework \textit{Errbot} als Anforderung herausgebildet hat und es ein grundlegendes Element ist, wird es zuerst betrachtet.\\
Für die Installation von Errbot werden verschiedene Methoden angeboten: als System-Paket, systemweit mit dem Python Paketmanager \textit{pip} oder in einer virtuellen Python Umgebung, einem sogenannten \textit{virtualenv}. Da letztere Variante die präferierte ist, wird diese durchgeführt. Die Installation erfolgt wie in \autoref{venv} beschrieben.
\footcite[Vgl.][o. \pno]{errbot_2018_setup}

\begin{lstlisting}[language=bash, label=venv, caption=Virtualenv Einrichtung und Errbot Installation]
mkvirtualenv -p `which python3` errbot-ve
pip install errbot
\end{lstlisting}

Mit \textit{errbot -~-init} wird ein initiales Projekt angelegt, das bereits ein Beispiel Plug-in enthält. Die Struktur ist in \autoref{errbotstructure} ersichtlich. In der Datei \textit{config.py} werden Konfigurationen, wie das verwendete Backend, das Log File, die Bot Administratoren und die Bot Identität vorgenommen.
\footcite[Vgl.][o. \pno]{errbot_2018_setup}

\begin{lstlisting}[language=bash, label=errbotstructure, caption=Struktur eines Errbot Projektes]
config.py
data
plugins
    err-example
        example.plug
        example.py
\end{lstlisting}

Mit der Grundeinrichtung von Errbot kann die Anforderung \textit{Errbot} als erfüllt betrachtet werden. Für die \acs{CMDB} Anbindung wird ein eigenes Plug-in anhand des Beispiels \textit{err-example} angelegt. In der \textit{.plug} Datei werden Beschreibung und Kompatibilität (Python 2, 3, 2+) eingetragen und in der \textit{.py} die Kommandos, die vom Bot aufrufbar sind. Weitere Schnittstellen, z. B.~zu vCenter oder Monitoring können zukünftig per eigenem Plug-in realisiert und vom selben Bot bedient werden. Somit gilt die Anforderung der Schnittstellenanbindung als erfüllt. 
\footcite[Vgl.][o. \pno]{errbot_2018_plugin}


Errbot kann standardmäßig an die Backends XMPP, IRC, HipChat, Slack und Telegram angebunden werden. Außerdem können Backends von Drittanbietern, wie z. B. Cisco WebEx Teams angebunden werden. Diese wurden von Usern erstellt und nicht von errbotio selbst und können in der Konfiguration mit \textit{BOT\_EXTRA\_BACKEND\_DIR} unter Angabe des entsprechenden Ordners verwendet werden. In dieser Umsetzung wird Slack als Backend verwendet, dazu wird in der Konfiguration unter \textit{BOT\_IDENTITY} der Bot Token hinterlegt und die Proxy Konfiguration für die Verwendung im internen Firmennetz gesetzt. Durch die verschiedenen Backends kann ein Errbot Plug-in an eine Vielzahl von Chat Plattformen angebunden werden und die Anforderung der Plattform-Agnostik ist somit erfüllt.
\footcites[Vgl.][o. \pno]{errbot_2018_setup}[Vgl.][o. \pno]{errbot_2018_webex}

Ob das Plug-in regelbasiert oder KI-gestützt umgesetzt wird, ist allein dessen Autor überlassen. Das \acs{CMDB} Plug-in wird wie gefordert regelbasiert umgesetzt und die Anforderung kann als erfüllt angesehen werden. Im Detail schlägt sich dies in den funktionalen Anforderungen nieder.


\subsection{Berechtigungskonzept}
Errbot bietet die Möglichkeit, mit sogenannten \textit{Access controls} den Zugriff auf bestimmte Plug-ins oder Befehle zu beschränken. Dabei können Benutzer oder Räume explizit erlaubt oder verboten werden. Außerdem können Befehle in Räumen generell verboten werden (allowmuc), d.~h.~der Befehl kann dem Bot nur per Privatnachricht geschickt werden, was bei Befehlen mit langer Ausgabe sinnvoll sein kann.\\
Wie in \autoref{errbotacl} zu erkennen ist, wurde das \acs{CMDB} Modul nur im Channel \textit{cbottest} erlaubt und das \textit{render\_test} Kommando ist nur per privater Nachricht aufrufbar.
\footcite[Vgl.][o. \pno]{errbot_2018_config-template}

\newpage
\begin{lstlisting}[language=python, label=errbotacl, caption=Errbot Access controls]
ACCESS_CONTROLS = {'CMDB:*': {'allowrooms': ('#cbottest',)},
                   'render_test': {'allowmuc': False},
                  }
\end{lstlisting}

\subsection{Reaktivität}
Durch die Architektur ist in Errbot \textit{by-design} sichergestellt, dass er nur auf Nennungen und Befehle reagiert. Selbstständiges Erzeugen von Nachrichten ist nicht vorgesehen.
\footcite[Vgl.][o. \pno]{errbot_2018_mentions}

\subsection{API-Einsatz}
Mit dem Tool i-doit-cli können von der Kommandozeile aus verschiedene \acs{CMDB} Funktionen, wie lesen, schreiben oder suchen ausgeführt werden. Außerdem können individuelle API Aufrufe damit abgesetzt werden. Mit dem \textit{subprocess} Modul kann das Tool einfach in Python ausgeführt und die Ausgabe ausgewertet werden, dabei werden die Parameter \textit{--no-colors} und \textit{-y} genutzt, um nicht interaktiv zu arbeiten und keine Farben auszugeben. So werden mögliche Kompatibilitätsprobleme vermieden.
\footcite[Vgl.][o. \pno]{Heisig_2019_idoitcli}

\subsection{Formatierung des Outputs}
Die Ausgabe des i-doit-cli Tools besteht aus reinem Text. Zur besseren Lesbarkeit werden für verschiedene Ausgaben, wie die Liste der Suchergebnisse oder die Detailansicht Funktionen zur Formatierung angelegt (\autoref{formatter}).
Für die Suchergebnisse (searchformatter) wird die Ausgabe am doppelten Zeilenumbruch getrennt, um die Suchergebnisse zu separieren und dann die Bestandteile des Ergebnisses zu formatieren. Dem Namen des Objekts wird eine URL zu den Details in der \acs{CMDB} hinterlegt und der Ort wird in Klammern dahinter dargestellt.\\
Für die Detailanzeige eines Objekts (nonemptyformatter) werden nur Einträge angezeigt, die einen Inhalt haben. Ansonsten wird die Ausgabe nicht verändert.

\newpage
\begin{lstlisting}[language=python, label=formatter, caption=Funktionen zur Formatierung]
def searchformatter(objectliststring):
    """ format search result with links """
    if objectliststring.split('\n\n')[0] == '':
        return 'Keine Ergebnisse'
    itemlist = [i.split('\n') for i in objectliststring.split('\n\n')]  # get single lines for every search result item
    items = [{'name': i[0], 'place':i[1].replace('Source: ', ''), 'url': i[2].replace('Link: ', '')} for i in itemlist]  # save information to dict and remove description in text
    return '\n'.join(["```\n<{url}|{name}> ({place})\n```".format(**item) for item in items])


def nonemptyformatter(infostring):
    """ return only fields with content for show output """
    lines = infostring.split('\n')
    result = []
    for line in lines:
        if not line.endswith(': -'):
            result.append(line)
    return '\n'.join(result)
\end{lstlisting}


\subsection{Charakter}
Um die Professionalität sicherzustellen, werden nur die angeforderten Informationen ohne Umschweife ausgegeben. Wenn eine Ausgabe von Text nötig ist, geschieht dies jedoch mit Humor und Lockerheit. Wird z. B.~ein benötigter Parameter vergessen, antwortet der Bot mit \textit{Was soll ich denn damit anfangen? :man-facepalming: Da musst du schon mehr eingeben ...}. Bei einem Fehler entgegnet der Bot \textit{Da ist wohl was schief gelaufen:} und gibt anschließend die technische Fehlermeldung aus. Wenn eine Suche nichts zurückliefert, wird hingegen recht sachlich mit \textit{Keine Ergebnisse} geantwortet. 

\subsection{Avatar}
Avatar und Name eines Bots werden beim Slack Backend bei der Erstellung des Bot Users vergeben und können nicht für ein Errbot Plug-in vorgegeben werden. Der erhaltene Bot Token wird in der Errbot Konfiguration hinterlegt. Jedes Unternehmen, das eine Errbot Instanz installiert, um das \acs{CMDB} Plug-in zu nutzen, kann also selbst entscheiden, welcher Avatar genutzt werden soll. Für das IVZ wird daher die Maus aus der Sendung mit der Maus genutzt. 
\footcite[Vgl.][o. \pno]{Slack_2019_Bots}

\subsection{Nachvollziehbarkeit} \label{Nachvollziehbarkeit}
Da die schreibenden Funktionen, also Serverplanung, Statuswechsel und Logbuch als Funktionsuser vorgenommen werden, muss zusätzlich vermerkt werden, wer diese initiiert hat. Dazu bietet sich die Funktion \textit{idoitcli log} an, mit der ein Eintrag für ein Objekt im Logbuch hinzugefügt werden kann (\autoref{descupdate}). 

\begin{lstlisting}[language=bash, label=descupdate, caption=Hinzufügen eines Logbuch Eintrages]
idoitcli log mylittleserver -m "created by username via Errbot"
\end{lstlisting}

\subsection{Vermeidung Fehlbedienung}
Um Fehlbedienung zu vermeiden, sollte für kritische Kommandos wie Löschung oder Archivierung eine Bestätigung erfolgen, nachdem der Nutzer gefragt wurde, ob seine Daten korrekt sind. Dazu ist es nötig, die Parameter des initialen Aufrufs zwischenzuspeichern, um sie im Falle der Bestätigung weiter verarbeiten zu können und bei einem Abbruch zu verwerfen. Errbot bietet die Möglichkeit, solche Variablen persistent, auch über einen Neustart hinaus, zu speichern. So können die offenen Änderungen pro User vermerkt werden.\\
Nach der Abfrage müsste dann vom gleichen User der Befehl \textit{!yes} zur Bestätigung oder \textit{!no} zum Abbruch folgen. Im Rahmen dieser Arbeit ist keine Funktion vorgesehen, die eine solche Prüfung benötigt, ein möglicher Dialog bei der Archivierung eines Objekts könnte aber so aussehen, wie in \autoref{delconfirm}. 
\footcite[Vgl.][o. \pno]{errbot_2018_persistence}

\begin{lstlisting}[language=python, label=delconfirm, caption=Nachfrage bei der Archivierung von Objekten]
Benutzer: !archive mylittleserver
Bot: Soll "mylittleserver" wirklich archiviert werden?
Benutzer: !yes
\end{lstlisting}

\subsection{Herstellerkonsolidierung}
Um doppelte Herstellernamen zu vermeiden, kann entweder vor dem Anlegen eines neuen Objekts eine Suche nach dem Namen erfolgen oder es kann nach der Eingabe des Namens automatisch auf Ähnlichkeit zu anderen Namen geprüft werden.
In der ersten Version des \acs{CMDB} Chatbots wird auf die Ähnlichkeitsprüfung verzichtet, da dies auch mit einer zuvor getätigten Suche sichergestellt werden kann. Es muss zudem definiert werden, welche Ähnlichkeiten geprüft werden sollen (Beginn, Ende) und welche Hersteller trotz fehlender Ähnlichkeit im Namen zusammengefasst werden sollen (Umbenennung, Zusammenschluss).

\subsection{Arbeitsüberwachung}
%\footcite[Vgl.][o. \pno]{Zigon_Performance}
Bei der Entwicklung des Plug-ins werden keine Funktionen umgesetzt, mit denen sich Aktivität und Leistung automatisiert personenbezogen messen lassen. 

\subsection{Webinterface-Eingaben}
Die Bedienung der \acs{CMDB} per Chatbot bietet lediglich eine Ergänzung der Eingabemethoden. Das Webinterface der \acs{CMDB} kann weiterhin parallel genutzt werden.

\subsection{Hilfe}
Als Hilfe zu den verschiedenen Funktionen von Errbot wird standardmäßig die Dokumentation der hinterlegten Funktion (sogenannte \textit{docstrings}) ausgegeben. Die Hilfe lässt sich mit \textit{!help} aufrufen. Zur Erfüllung dieser Anforderung müssen also die Funktionen entsprechend dokumentiert werden.
\footcites[Vgl.][o. \pno]{errbot_2018_general}[Vgl.][o. \pno]{pep257}

\subsection{Vorhersage}
 Da es in der \acs{CMDB} keine entsprechende Funktion zur Vorhersage der Ressourcenauslastung gibt, kann auch kein ChatOps Interface dazu geschaffen werden.

%\subsection{Sprachassistenten}

\subsection{Standardanfragen}
Da im Rahmen der Experteninterviews Administratoren der \acs{CMDB} befragt wurden, welche Aufgaben bzw. funktionale Anforderungen ein Chatbot erledigen können soll, kann diese Anforderung als erfüllt betrachtet werden. 



\section{Funktionale Anforderungen}
Die Umsetzung oder geplante Umsetzung der funktionalen Anforderungen wird im Folgenden einzeln beschrieben. Wenn mehrere Anforderungen durch eine Funktion abgedeckt werden können, sind diese in einem Punkt zusammengefasst. Dabei wird darauf eingegangen, aus welchem Tool oder welcher Quelle die Informationen gewonnen werden, wie die Funktionen im Bot Plug-in umgesetzt sind und wie die Ausgabe erfolgt. Befehle sind dabei kursiv dargestellt und Parameter in spitzen Klammern. In den Code Listings wird das Beispielobjekt \textit{mylittleserver verwendet}.

\subsection{Suchfunktion}
Die Suche nach Objekten wird über die \textit{idoitcli search <Suchbegriff>} Funktion realisiert. Analog dazu wurde das Bot Kommando \textit{!cmdb search <Suchbegriff>} implementiert. Die Ausgabe wird dabei zur besseren Lesbarkeit formatiert (\autoref{cmdbsearch}). Bei leerem Suchstring erfolgt \textit{None} als Ausgabe. Die Funktion \textit{clirun} ist der Wrapper für das idoitcli binary.

\newpage
\begin{lstlisting}[language=python, label=cmdbsearch, caption=Suchfunktion]
def search(term):
    """ search for term """
    if term == '':
        return None
    search_cmd = 'search "{}"'.format(term)
    out = clirun(search_cmd)[1]
    return out
\end{lstlisting}


\subsection{Nächste freie IP}
Die Suche nach der nächsten freien IP wird mit der Funktion \textit{idoitcli nextip <Netz>} realisiert und ist mit \textit{!cmdb nextip <Netz>} abrufbar. Wenn ähnlich wie beim IVZ die ersten Adressen eines Netzes für Infrastruktur reserviert sein sollen, muss darauf geachtet werden, dass diese auch in der \acs{CMDB} 
entsprechend blockiert sind. Die \textit{nextip} Funktion gibt die erste Adresse aus, der kein Objekt zugewiesen ist (\autoref{nextip}).

\begin{lstlisting}[language=python, label=nextip, caption=Nächste freie IP]
@botcmd
def cmdb_nextip(self, msg, args):
    """ next free IP address """
    return cmdb.clirun('nextip', str(args))[1]
\end{lstlisting}


\subsection{Serverplanung}
Um Ort, Name und IP eines neuen Servers zu speichern, kann dieser mit i-doit-cli initial angelegt und mit den entsprechenden Informationen versehen werden (\autoref{planning}). Als Bot Kommando muss dafür entsprechend \textit{!cmdb server <Servername>, <Rack>, <IP>} verwendet werden. Nach der Erstellung folgt automatisch eine Suche nach dem neuen Objekt und Ausgabe auf dem Bildschirm, um den Erfolg überprüfen zu können.\\
Für virtuelle Maschinen wird entsprechend der Befehl \textit{!cmdb vm <Servername>, <IP>} verwendet, der keinen Standort Parameter benötigt und das Objekt in der Kategorie \textit{Virtual Server}, statt \textit{server} speichert.

\begin{lstlisting}[language=bash, label=planning, caption=Serverplanung mit i-doit-cli]
idoitcli save server/mylittleserver
idoitcli save server/mylittleserver/location -a location="myrack"
idoitcli save "server/mylittleserver/Host address" -a "IPv4 address"="192.168.0.2"
\end{lstlisting}

\subsection{Standortabfrage, IP-Adresse, Statusabfrage, Softwarestand, Netzinformationen, Kontaktperson}
Um Details zu einem Objekt anzuzeigen, können die jeweiligen Kategorien abgefragt werden. IP-Adresse und Netzinformationen aus \textit{Host address}, Standort in \textit{Location}, der Status in \textit{General}, die Kontaktperson in \textit{Contact assignment} und die Software in \textit{Applications} (\autoref{show}). Die Ausgabe der Details zu einem Objekt erfolgt nach Eingabe von \textit{!cmdb detail <Servername>} Die Informationen aus den Kategorien werden per formatter Funktion gefiltert und konsolidiert.

\begin{lstlisting}[language=bash, label=show, caption=Detailansicht eines Objekts mit i-doit-cli]
idoitcli read "mylittleserver/Host address"
idoitcli read "mylittleserver/Location"
idoitcli read "mylittleserver/General"
idoitcli read "mylittleserver/Contact assignment"
idoitcli read "mylittleserver/Applications"
\end{lstlisting}

\subsection{Bestandsprüfung, Standortreport, Ressourcenübersicht}
Um den Bestand von Objekten im Lager oder an einem Standort prüfen zu können werden in der i-doit \acs{CMDB} Reports verwendet, die vom Betreiber individuell gestaltet und jederzeit ausgeführt werden können. Die verwendeten Ressourcen eines Kunden oder einer Anwendung werden ebenfalls über Reports abgerufen.  Im i-doit-cli gibt es derzeit keine Funktion, um Reports abzurufen. Um diese Features umzusetzen, müsste entsprechend eine Erweiterung des i-doit-cli bei synetics beauftragt werden. Alternativ könnte auch betrachtet werden, ob es sich per individueller API Abfrage umsetzen lässt. Eine andere Möglichkeit ist der Einsatz der i-doit \textit{Console}, um per Cronjob die Reports täglich zu generieren und per Bot unter einer vordefinierten URL bei Anfrage herunterzuladen und in den Chat zu posten. Im Rahmen dieser Arbeit kann dieses Feature jedoch nicht umgesetzt werden.\\
Eine mögliche Syntax für diese Funktion könnte \textit{!cmdb report <Reportname>} sein. 
\footcites[Vgl.][o. \pno]{idoit_2019_report}[Vgl.][o. \pno]{idoit_2019_console}
%\todo{über i-doit Controller}
%\todo{Täglicher Export -> Abruf über Bot}

\subsection{Ressourcen}
Um die Ressourcenauslastung eines Geräts zu ermitteln, können die Kategorien \textit{Memory} und \textit{CPU} eines Objekts per \textit{idoitcli read <Servername>} abgefragt werden (\autoref{resources}). Im Bot Plug-in ist diese Funktion per \textit{!cmdb load <Servername>} abrufbar. 

\begin{lstlisting}[language=bash, label=resources, caption=Ressourcenauslastung eines Geräts]
idoitcli read mylittleserver/Memory
idoitcli read mylittleserver/CPU
\end{lstlisting}

\subsection{Statuswechsel}
Der Status eines Objekts lässt sich ändern, indem das entsprechende Attribut in der Kategorie \textit{General} mit der \textit{idoitcli save} Funktion gesetzt wird (\autoref{statechange}). Das Bot Kommando dazu lautet \textit{!cmdb setstate <Objektname> <Status>}.
\begin{lstlisting}[language=bash, label=statechange, caption=Statuswechsel eines Objekts]
idoitcli save "server/mylittleserver/General" -a "CMDB status"="scrapped"
\end{lstlisting}

\subsection{Logbuch}
Ein Logbucheintrag kann vorgenommen werden, indem die \textit{log} Funktion des i-doit-cli unter Nennung des Objektnamens aufgerufen wird (\autoref{logentry}). Analog dazu kann der Eintrag mit \textit{!cmdb log <Objektname> <Eintrag>} per Bot Kommando vorgenommen werden.
\begin{lstlisting}[language=bash, label=logentry, caption=Logbucheintag]
idoitcli log mylittleserver -m "Test"
\end{lstlisting}