Ein Teilbereich der IT-Infrastruktur eines bekannten Beratungsunternehmens setzt sich aus rund 25 Linux-Systemen zusammen. Die Installation von Patches auf diesen Systemen erfolgt manuell und dezentral per Kommandozeile. Der Auftraggeber beabsichtigt für die Linux-Systeme eine Patch-Management-Lösung einzusetzen, um die Verteilung von Patches zentral durchzuführen und zu steuern. Im Rahmen dieser Arbeit wurden zwei Patch-Management-Konzepte für Linux-Systeme erarbeitet, welche auf den Anforderungen des Auftraggebers aufbauen.

Zu Beginn wurden die Anforderungen mit den relevanten Interessensgruppen iterativ erarbeitet und in Form von User-Storys festgehalten. Eine Internetrecherche kombiniert mit der Top-down-Methode führte zu potenziellen Varianten. Die Varianten wurden anhand der User-Storys systematisch gefiltert und die verbliebenen Varianten mittels einer Kosten-Wirksamkeits-Analyse beurteilt. Basierend auf den Ergebnissen wurde eine Empfehlung der zu konzipierenden Lösungen erarbeitet. Der Auftraggeber stimmte der Empfehlung zur Konzeption von Azure Update Management und JetPatch zu.

Azure Update Management basiert auf einem cloudbasierten Ansatz und JetPatch setzt auf eine lokale Installation mit einer CentOS Appliance. JetPatch bringt funktionale Vorteile bei der automatisierten Patch-Verteilung und -Deinstallation mit sich. Ein mehrstufiges Verteilen oder Deinstallieren derselben Patches in derselben Version ist stets sichergestellt. Azure Update Management überzeugt hingegen durch umfangreichere Berichterstellungsmöglichkeiten und unterstützt die «Microsoft-first-Strategie» des Auftraggebers vollumfänglich. Die Betriebskosten für JetPatch fallen in jedem Fall höher aus, sofern die Speicherplatznutzung von Azure Update Management weniger als 2 GB pro Endgerät und Monat beträgt. Der Proof of Concept zeigte, dass die Endgeräte nur rund 200 MB an Speicherplatz pro Monat benötigen. Der Autor empfiehlt die Lösung Azure Update Management in einem nächsten Schritt mit Endgeräten der Entwicklungs- und Testumgebung zu pilotieren. Der funktionale Nachteil beim mehrstufigen Verteilen von Patches lässt sich durch den Einsatz eines lokalen Repository-Servers innerhalb eines Folgeprojektes komplett eliminieren.