# Patching ohne monatliche Verhandlungen · Stilla > Jeden Monat das gleiche Prozedere: E-Mails über den Zeitpunkt, an dem Server neu gestartet werden dürfen. URL: https://stilla.eywo.digital/de/blog/patching-without-monthly-negotiation/ Language: de Last updated: 2026-10-25 [← Zurück zum Blog](https://stilla.eywo.digital/de/blog/) Sicherheit16\. Juli 2026Aktualisiert 25\. Oktober 20263 Min. LesezeitEywo-Team # Patching ohne monatliche Verhandlungen Jeden Monat das gleiche Prozedere: E-Mails über den Zeitpunkt, an dem Server neu gestartet werden dürfen. Eine Patch-Vereinbarung mit dem Service Owner verwandelt eine wiederkehrende Verhandlung in eine Dauerrichtlinie. Anbieter veröffentlichen ihre Fixes, das Sicherheitsteam erinnert alle an die Fristen und der Betrieb beginnt, die Service Owner per E-Mail zu kontaktieren. Wann können die Anwendungserver neu gestartet werden? Ist Dienstagabend in Ordnung oder muss es bis zum Wochenende warten? Was ist mit dem System, das letztes Mal länger als erwartet brauchte, um wieder hochzufahren? Die Antworten kommen spät, einige gar nicht. Am Ende wird ein Teil der Systeme gepatcht und der Rest wird auf „nächsten Monat“ verschoben. Dieser Zyklus wiederholt sich jeden Monat und kostet Energie auf beiden Seiten. Administratoren sind frustriert, dass sie die Arbeit, für die sie verantwortlich sind, nicht erledigen können. Service Owner fühlen, dass der Betrieb immer wieder etwas von ihnen verlangt. Und die Sicherheit beobachtet, wie der Rückstau von aufgeschobenen Fixes wächst. ## Warum dieselbe Frage immer wieder kommt Oft sehen wir, dass Patching als eine Reihe von Einzelereignissen durchgeführt wird. Jeden Monat bringt eine neue Serverliste, eine neue Reihe von Ausfallanfragen und eine neue Runde von Genehmigungen. Doch die meisten Antworten ändern sich nicht von Monat zu Monat: Der Service hat immer noch dieselben Geschäftszeiten, dieselbe Redundanz und denselben Besitzer. Das Problem ist also nicht, dass die Leute nicht bereit sind, zuzustimmen. Das Problem ist, dass die Vereinbarung nie schriftlich festgehalten wird und im nächsten Monat alle wieder von vorne beginnen. Weitere Schwächen kommen hinzu: - Es ist unklar, wer für einen Service entscheidet, daher wird die Anfrage zwischen mehreren Personen hin- und hergegeben, - Server werden einzeln von einer Liste gepatcht, nicht nach Service und dessen Abhängigkeiten, - redundante Knoten werden manchmal gleichzeitig neu gestartet, weil nur wenige Leute wissen, dass sie redundant sind, - ein kritischer Fix wartet in derselben Warteschlange wie ein routinemäßiges monatliches Update. ## Wie man es angeht Anstatt jeden Monat zu verhandeln, ist es besser, eine einmalige Vereinbarung mit dem Service Owner zu treffen, die gültig bleibt, bis jemand sie bewusst ändert. Die Vereinbarung regelt, wann Patching stattfinden darf, ob Patching innerhalb dieses Fensters vorab genehmigt ist und wie redundante Knoten behandelt werden. Die monatliche Planung hört dann auf, eine Frage von „Dürfen wir?“ zu sein, und wird einfach zu „Was kommt als Nächstes?“. Das zweite Prinzip ist, den Routineweg vom dringenden Weg zu trennen. Eine kritische Schwachstelle sollte nicht bis zum nächsten regulären Fenster warten, aber auch nicht den Service Owner vollständig umgehen. ## Wie Stilla es handhabt Stilla führt eine **Patch-Vereinbarung** zwischen Betrieb und Service Owner ein. Sie umfasst: - **ein stehendes Fenster** – eine regelmäßige Zeit, in der der Service gepatcht werden darf, - **vorab genehmigtes Patching innerhalb des Fensters** – Änderungen, die von der Vereinbarung abgedeckt sind, benötigen keine neue Ausfallgenehmigung jeden Monat, - **rollierende Patching von redundanten Knoten** – Knoten in einer Redundanzgruppe werden nacheinander gepatcht, damit der Service verfügbar bleibt, - **ein beschleunigter Modus für kritische Probleme** – ein kürzerer Weg für schwere Schwachstellen, der im Voraus von beiden Seiten vereinbart wird. Ein vorgeschlagener Patch-Vertrag landet in der einzigen „Zu genehmigenden“ Warteschlange des Service Owners, neben Änderungsausfällen und Anfragen. Eine Regel definiert, wer der Besitzer ist; wenn ein Service keinen Besitzer hat, entscheidet der Change-Manager. Eine Ablehnung kommt immer mit einem Grund, damit der Betrieb weiß, was anzupassen ist. Patch-Vereinbarungen fließen in einen **wellenbasierten Patching-Plan** ein. Server werden nach ihren Services und Fenstern in Wellen gruppiert, und der Plan generiert die entsprechenden Änderungen in einem Schritt. Diese Änderungen durchlaufen dieselben Prüfungen wie jede andere Änderung im System: Auswirkungen auf Services, Wartungsfenster, Einfrierungen und Kollisionen. Das Dashboard für Schwachstellen und Behebung zeigt dann, wie die Arbeit voranschreitet. ## Einmal zustimmen, jeden Monat ruhig schlafen Patching muss keine monatliche Verhandlung sein. Sobald vereinbart ist, wann und wie ein Service gepatcht wird, können Administratoren nach einem Plan arbeiten, Service Owner wissen, was sie erwarten können, und die Sicherheit kann sehen, dass Fixes tatsächlich in die Produktion gelangen. Das Gespräch mit dem Service Owner findet gelegentlich statt und dreht sich um das, was wichtig ist, nicht dieselbe Frage jeden Monat. Patch-Vereinbarungen, wellenbasierte Patching-Pläne und das Behebungsdashboard sind in der Business-Edition enthalten. **Stilla Business** Für Betriebsabläufe, die Monitoring, Sicherheit und Anbieter verbinden möchten. [Editionen vergleichen →](https://stilla.eywo.digital/de/editions/) ## Weitere Artikel [Sicherheit·23\. Juli 2026 ### Vom Auffinden einer Schwachstelle bis hin zu einer Produktionsänderung Der Scanner findet Tausende von Problemen, aber die Behebung in der Produktion ist immer noch manuelle Arbeit. Wie können Schwachstellen mit Servern, Diensten und Änderungen verknüpft werden, damit die wichtigen zuerst behoben werden? Business3 Min. Lesezeit](https://stilla.eywo.digital/de/blog/from-vulnerability-to-change/)[CMDB·25\. Oktober 2026 ### Das virtuelle Netzwerk in der CMDB: von der Portgruppe bis zum Leaf-Switch Zwischen einer virtuellen Maschine und dem physischen Netzwerk liegt eine Schicht, die die meisten CMDBs nicht sehen – virtuelle Switches, Port Groups und Host-Uplinks. Doch genau hier wird entschieden, welche Business-Services eine Netzwerk-Änderung berührt. Standard3 Min. Lesezeit](https://stilla.eywo.digital/de/blog/virtual-network-in-the-cmdb/)[Governance·25\. Oktober 2026 ### NIS2 und DORA: Was der IT-Betrieb nachweisen können muss Beide Vorschriften stellen dieselbe Frage: Wissen Sie, welche Services ein Ausfall trifft, wer dafür verantwortlich ist und was sich wann geändert hat? Ohne eine zuverlässige Abhängigkeitskarte müssen die Antworten oft unter Zeitdruck manuell zusammengestellt werden. Standard2 Min. Lesezeit](https://stilla.eywo.digital/de/blog/nis2-dora-evidence/)