Zurich setzt ServiceNow_® Update Sets 5X schneller ein mit xtype.

Über das Unternehmen

Zurich ist ein führender Mehrsparten-Versicherer, der seine Kunden in globalen und lokalen Märkten betreut. Mit rund 56.000 Mitarbeitern bietet sie eine breite Palette von Sach- und Unfall- sowie Lebensversicherungsprodukten und -dienstleistungen in mehr als 210 Ländern und Territorien an. Zu den Kunden von Zurich gehören Privatpersonen, Kleinunternehmen, mittlere und grosse Firmen sowie multinationale Konzerne.

Geschäftliche Herausforderung

Zurich folgte bei der Organisation ihrer ITSM-Entwicklungsbemühungen den DevOps- und Agile-Branchentrends. Im Laufe der Zeit nahm das Klonen jedoch immer mehr Stunden in Anspruch, so dass die Klone an Wochenenden ausgeführt werden mussten. Das Klonen an Wochenenden bedeutete, dass die Administratoren an den Wochenenden arbeiten mussten, um die Entwicklungsarbeit vor dem Klonen in die geklonten Sub-Prod-Instanzen zu importieren - ein Aufwand, der ebenfalls viele Arbeitsstunden in Anspruch nahm. Darüber hinaus erzeugte die Anzahl der Entwickler, die ServiceNow Code schrieben, ein Arbeitsvolumen, das den Vergleich von Änderungen zwischen den Instanzen zur Vorbereitung von Code-Pushs zu mühsam und zeitaufwändig machte. Kurz gesagt, ein erheblicher Prozentsatz der Zeit von Entwicklern und Administratoren wurde für die Überprüfung und Vorbereitung von Deployments aufgewendet, anstatt Code zu schreiben.

Verkürzung der Entwicklungsvorlaufzeit

Während der Sperrzeiten für das Klonen können die Entwickler keine Aktualisierungen programmieren. Diese Tatsache stellte früher keine Herausforderung dar, da das Klonen während unproduktiver Zeiten wie Wochenenden oder Abenden durchgeführt wurde. Da das Klonen jedoch mehr als 20 Stunden (mit steigender Tendenz) in Anspruch nimmt, wurde Druck ausgeübt, um die Vorlaufzeit zu verkürzen, die erforderlich ist, um neu gefertigte Klone für Entwickler bereitzustellen.

Verkürzung der Einführungszeit

Die Vorbereitung von Produktionsimplementierungen ist zeitaufwändig. Zurich verbrachte Tage damit, Kalkulationstabellen zu überprüfen und Update-Sets in mehreren Browser-Tabs über ihre Sub-Prod-Instanzen hinweg manuell zu inspizieren. Selbst mit dieser Liebe zum Detail war es immer noch schwierig, die Anzahl und Reihenfolge der Update-Sets, Skripte usw. in der Pre-Prod-Instanz genau zu bestimmen, die für die Prod-Instanz bereit waren.

Misserfolgsquote bei Änderungen verbessern

Zurich wollte die Anzahl von Konflikten nach der Bereitstellung reduzieren, die durch nicht synchronisierte Instanzen in Silos entstehen.

Privilegierten Zugang einschränken

Da so viele Entwickler parallel Aktualisierungen programmieren, wurden den Entwicklern erhöhte Berechtigungen gewährt, damit sie ihre Aktualisierungssätze in die Pre-Prod-Instanzen übertragen konnten. Obwohl dies in der Branche eine gängige Praxis ist und das Risiko bekannt ist, führt dies dennoch zu einer Ausweitung der Privilegien, was nicht dem Ideal einer bewährten Zugriffsverwaltungspraxis entspricht.