Berichte aus der PraxisBereiten Sie Ihre Patchrichtlinie vor

Mark D. Scott

Ich arbeitete neulich mit einem Kunden zusammen, als wir auf ein interessantes Service Pack-Problem stießen. Das IT-Team beschloss, SP2 auf seine SQL Server-Produktionsserver anzuwenden. Die Teammitglieder taten das, was von einem verantwortlichen Team erwartet wird: Sie wendeten das Service Pack auf die Server in der Testumgebung an, um zu gewährleisten, dass die Anwendungen, die SQL Server verwendeten, nicht beeinträchtigt wurden. Alles schien im Test gut zu laufen. Sie benachrichtigten jeden in der Organisation und setzten einen Termin fest, zu dem der Patch auf die Server angewendet werden sollte.

In der Produktion lief alles einwandfrei. Sie fuhren damit fort, die Patches an die Server in der Planungs-, Test- und schließlich in der Entwicklungsabteilung zu verteilen. Eine Bereitstellung wie aus dem Bilderbuch. Bis einer der Entwickler versuchte, sein Reporting Services-Projekt zu öffnen. Plötzlich hatte er unzählige eigenartige kleine Probleme. Berichte wurden geöffnet, aber Teile davon waren nicht verfügbar. Ein anderer Entwickler öffnete eine Analysis Services-Datenbank. Kein Problem. Bis er versuchte, die Registerkarte „Berechnete Elemente“ zu öffnen. Etwas war garantiert beeinträchtigt worden.

Wie Sie vielleicht schon erraten haben, lag das Problem daran, dass zwar die Server das Service Pack erhalten hatten, aber nicht die Entwickler. Da die SQL Server-Clienttools, die auf den Desktops installiert wurden, als Teil der Desktopbereitstellung und nicht der Serverbereitstellung angesehen wurden, wurden sie bei der Aktualisierung nicht berücksichtigt. Das Verteilen des Service Packs an die Entwickler erforderte eine neue Runde, in der die Verteilung getestet und eingerichtet wurde. (Ganz zu schweigen davon, dass nicht alle Entwickler außer Gefecht gesetzt wurden, was hieß, dass einige bereits ein nicht in der Richtlinie enthaltenes Service Pack auf ihren Desktop angewendet hatten. Aber das ist ein Artikel für sich.)

Während dieses Durcheinander geklärt wurde, kam die Wartung auf einigen der analytischen Anwendungen, die vom Unternehmen verwendet wurden, zum Stillstand. Durch dieses Ereignis wurde deutlich, wie inkonsistent und unklar die Richtlinie zu Service Packs war. Es offenbarte zudem einige Probleme in der Kommunikation zwischen Abteilungen. Die Verteilung von Service Packs ist sehr wichtig, weil es für mehr Sicherheit in der Ökosphäre sorgt.

Einige Organisationen sträuben sich gegen die Anwendung von Service Packs, da sie den Streit und die Verwirrung im Zuge der Softwareverteilung mehr fürchten als die Sicherheitsrisiken, die durch das Service Pack vermindert werden können. Andere Organisationen haben gar keine Richtlinien, was einzelnen Benutzern und Systemadministratoren die Entscheidung überlässt, ob sie Patches ignorieren oder anwenden. Das führt zu Albträumen bei der Wartung, wenn Patches zwar auf einem Server, aber nicht auf einem anderen vorhanden sind. Einige sind vollständig geschützt, während andere denselben Zustand wie bei der Installation aufweisen.

Die meisten großen und/oder erfahreneren IT-Organisationen haben die Infrastrukturoptimierungsmodelle gelesen und erkennen, dass sie das Einrichten von Richtlinien und das Implementieren von Verfahren proaktiv angehen sollten, damit es nicht zu solchen Szenarios kommt. Sie wissen, dass sie einen Großteil dieser Probleme automatisieren und diese Art von Ausrutschern verhindern können. Am Ende bleibt jedoch die Tatsache, dass Menschen verstehen müssen, dass ihre Handlungen Auswirkungen auf andere Personen und Abteilungen haben und dass sie miteinander kommunizieren müssen.

Es ist einfach, die Möglichkeiten zu bedenken, wie sich ein Service Pack auf Ihre Domäne auswirken wird, all die Dinge zu berücksichtigen, die Ihre Systeme tangieren, und so Problemen vorzubeugen. Es ist schwieriger, die Überlegungen zu erweitern und zu bedenken, welche Auswirkungen die Änderung außerhalb Ihres Bereichs haben wird. Manchmal sind wir in unserem Denken so begrenzt wie die Anwendungen, die wir verwalten.

Die gute Nachricht ist die, dass dieses Ereignis relativ problemlos korrigiert wurde. Die Organisation verfügte über ein ausgereiftes Modell. Nachdem das Problem erkannt worden war (in einem gewissen Durcheinander, weil es nur deshalb aufgetreten war, weil die Entwickler sich an die Regeln gehalten hatten), wurde der Patch schnell (und automatisch) verteilt. Ein gutes Maß an klarer Kommunikation und ein gut entworfenes System waren behilflich, um das Problem mit minimaler Ausfallzeit oder Unterbrechung zu beheben.

Es scheint, die Antwort liegt darin, dass wir unserer Infrastruktur und uns selbst, die Gelegenheit geben müssen zu reifen. Eine effektive Service Pack-Richtlinie betrifft Verfahren, Produkte und Personen.

Mark D. Scott ist ein leitender Berater bei Microsoft Consulting Services. Er arbeitet eng mit Kunden zusammen, um sie bei der Entwicklung und Erstellung umfangreicher datenorientierter Anwendungen zu unterstützen. Mark D. Scott ist unter granddaddy2002@msn.com oder mascott@microsoft.com zu erreichen.