Computerhaus Quickborn

5 Tipps gegen Deployment-Desaster​

Das Deployment-Debakel fest im Blick…?Gorodenkoff | shutterstock.com Diverse Devops-Teams in Unternehmen setzen inzwischen auf fortschrittliche CI/CD Pipelines, Infrastructure as Code und andere Automatisierungsinitiativen, um ihre Deployment-Frequenz nach oben zu treiben. Damit steigt potenziell jedoch auch die Fehlerquote, was insbesondere bei geschäftskritischen Anwendungen verheerende Auswirkungen haben kann. Wie verheerend, bewies zuletzt der Sicherheitsanbieter Crowdstrike, der mit einem Deployment-Debakel für Schlagzeilen sorgte, das unter anderem auch empfindliche finanzielle Einbußen für das Unternehmen zur Folge hatte. Vor diesem Hintergrund ist es möglicherweise sinnvoll, Ihre Deployment-Strategie auf den Prüfstand zu stellen. Dieser Artikel unterstützt Sie dabei, Antworten auf folgende Fragen zu finden: Wann sind häufige Releases zu riskant? Wie können Devops-Teams die Risiken richtig bewerten, um Deployment-Fehlschlägen vorzubeugen? 1. Anforderungen und Risiken evaluieren Nicht alle Releases, Funktionen und agilen User Stories sind mit den gleichen Bereitstellungsrisiken verbunden. Viele Unternehmen greifen deshalb inzwischen auf automatisiert erstellte Deployment-Risiko-Scores zu, um zu ermitteln, wie viel Testing- und Review-Arbeit vor dem Release noch erforderlich ist. Dabei einen Ansatz auf Machine-Learning-Basis zu verfolgen, lohnt sich vor allem für Organisationen, die in hoher Frequenz bereitstellen, wie David Brooks, SVP of Evangelism beim Devops-Spezialisten Copado erklärt: “KI kann dabei unterstützen, User Stories auszuwerten, um Unklarheiten, versteckte Abhängigkeiten und Auswirkungen sowie Überschneidungen mit der Arbeit anderer Entwickler zu identifizieren.“ Im Rahmen traditioneller Release-Management-Strategien sind Deployments Teil der internen Kommunikations- und Risikomanagement-Frameworks, wobei größere Upgrades, kleinere Verbesserungen und System-Upgrades charakterisiert werden. Anschließend definieren Devops-Entscheider Deployment-Richtlinien, die Anforderungen an die Risikominderung sowie Automatisierungsregeln auf der Grundlage von Release-Typen. Ein datengetriebener Ansatz charakterisiert hingegen Releases und berechnet Risiko-Scores auf der Grundlage vieler verschiedener, anderer Variablen – beispielsweise der Anzahl der betroffenen Benutzer, der Testabdeckung des betroffenen Codes und Messungen der Abhängigkeitskomplexität. Organisationen können Feedback-Schleifen implementieren, um Risikobewertungen auf der Grundlage der tatsächlichen geschäftlichen Auswirkungen von Releases zu kalibrieren, indem sie Ausfälle, Performance-Probleme, Sicherheitsvorfälle und das Feedback von Endbenutzern erfassen. 2. Security in die Dev Experience einbetten Nach dem Deployment mit Security-Problemen konfrontiert zu werden, birgt diverse Risiken. Deswegen setzen nicht wenige Devops-Teams auf einen „Shift Left“-Security-Ansatz. Dieser beinhaltet einen Mix aus Richtlinien, Kontrollen, Automatisierungen und Tools – vor allem jedoch ein Entwickler-Mindset, bei dem Security eine tragende Rolle spielt.   „Für eine funktionierende, moderne Devops-Praxis ist es absolut essenziell, Sicherheits- und Qualitätskontrollen so früh wie möglich in den Softwareentwicklungszyklus zu integrieren“, unterstreicht Christopher Hendrich, stellvertretender CTO beim Cloud-Lösungsanbieter SADA. Er fügt hinzu: „Eine Plattform für Developer aufzubauen, die Automatisierung, KI-Services und klares Feedback darüber liefert, wie Sicherheitslücken zu beseitigen sind, trägt dazu bei, Security-Mindset und Entwickleraufgaben unter einen Nenner zu bringen.“ Folgende Best Practices sollten Devops-Teams in Betracht ziehen, um das Risiko für Deployment-Katastrophen zu minimieren: Sicherheitsstandards für Softwareentwickler auf der Grundlage von Richtlinien und Frameworks wie OWASP Security Fundamentals, NIST Secure Software Development Framework oder ISO 27034 entwickeln. Risikomanagement im Rahmen der agilen Softwareentwicklung etablieren, indem technische Schulden reduziert werden und komplexe User Stories möglichst früh in Sprint- und Release-Zyklen entstehen. Sicherheitsrisiken im Entwicklungsprozess adressieren. Security Testing in CI/CD-Pipelines verankern. 3. Continuous-Deployment-Voraussetzungen schaffen Viele Entwicklungsteams setzen darauf, den Weg zur Produktion möglichst umfassend zu automatisieren. Allerdings sind nicht alle Dev-Organisationen wirklich bereit für einen Continuous-Deployment-Ansatz. Die vermeintlich simple Zielsetzung, CI/CD in Produktionsumgebungen zu implementieren, kann in exzessive Deployment-Desaster münden, wenn es an den entsprechenden Sicherheitsmaßnahmen mangelt – insbesondere mit Blick auf zunehmend komplexe Applikations- und Microservices-Architekturen. „Die Softwareentwicklung ist ein komplexer Prozess, der mit der Zeit immer schwieriger wird, wenn sich die Funktionalität der Software verändert oder sie altert“, erklärt Melissa McKay, Head of Developer Relations beim Plattformanbieter JFrog. Die Managerin ergänzt: “Ein mehrschichtiger, Ende-zu-Ende-Ansatz ist inzwischen unerlässlich, um sicherzustellen, dass Sicherheit und Qualität von der ersten Paketkuratierung bis zum Runtime Monitoring Priorität haben.“ Devops-Teams, die Continuous Deployment für geschäftskritische, umfangreiche Anwendungen implementieren möchten, sollten auf folgende Best Practices zurückgreifen: Continuous Testing mit hoher Testabdeckung, umfassenden Testdaten und auf Endbenutzer-Personas ausgerichtet umsetzen (inklusive synthetischer Daten und GenAI-Testfunktionen, um Fehler im Produktionscode aufzuspüren). Feature Flags einsetzen, damit Entwicklungsteams experimentelle Funktionen steuern können, die mit einer bestimmten Gruppe von Endbenutzern konfiguriert und getestet werden. Auf Canary-Release-Strategien setzen, um die Bereitstellung mehrerer Versionen einer Anwendung oder eines Services zu unterstützen. 4. Observability, Monitoring und AIOps optimieren In Observability, Application Monitoring und AIOps zu investieren, ist entscheidend, um den Business Impact und die Mean Time to Recovery (MTTR) bei größeren Sicherheitsvorfällen zu optimieren.   „Sämtliche Devops-Deployment-Katastrophen lassen sich letztlich auf einen Mangel an angemessener Kommunikation oder Sichtbarkeit zurückführen“, konstatiert Madhu Kochar, VP of Product Development bei IBM Automation, und fährt fort: „Man kann nicht reparieren, was man nicht sieht, und genau deshalb ist Observability insbesondere in Zusammenhang mit intelligenter Automatisierung von entscheidender Bedeutung, um bekannte Fehler zu beheben und Einblicke in Systeme oder Anwendungen zu erhalten. Das ermöglicht einen unterbrechungsfreien Feedback-Loop und realisiert effiziente und performante Deployments, in deren Rahmen Probleme erkannt werden, bevor sie sich auf die Endbenutzer auswirken.“ Unternehmen, die Microservices-Architekturen einsetzen, in mehreren Clouds bereitstellen und mit vielen Systemen von Drittanbietern verbunden sind, sollten auf AIOps-Lösungen zurückgreifen, um die Ursachen von Incidents ermitteln und automatisiert bearbeiten zu können. 5. Incident Playbook erstellen Tritt ein größerer Incident auf, können IT-Organisationen mit einem operativen Playbook besser darauf reagieren – und entsprechend kommunizieren. Das kann das schlimmste Szenario in einem solchen Fall verhindern. Nämlich, dass von den Technikern bis zu den Führungskräften keiner wirklich weiß, was zu tun ist. Das würde alles nur verzögern, zu weiteren Fehlern beitragen und das Stresslevel weiter nach oben treiben. Deshalb bereiten sich die meisten Unternehmen mit einem ITSM-Playbook auf geschäftskritische Produktionsprobleme vor. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

5 Tipps gegen Deployment-Desaster​ Das Deployment-Debakel fest im Blick…?Gorodenkoff | shutterstock.com Diverse Devops-Teams in Unternehmen setzen inzwischen auf fortschrittliche CI/CD Pipelines, Infrastructure as Code und andere Automatisierungsinitiativen, um ihre Deployment-Frequenz nach oben zu treiben. Damit steigt potenziell jedoch auch die Fehlerquote, was insbesondere bei geschäftskritischen Anwendungen verheerende Auswirkungen haben kann. Wie verheerend, bewies zuletzt der Sicherheitsanbieter Crowdstrike, der mit einem Deployment-Debakel für Schlagzeilen sorgte, das unter anderem auch empfindliche finanzielle Einbußen für das Unternehmen zur Folge hatte. Vor diesem Hintergrund ist es möglicherweise sinnvoll, Ihre Deployment-Strategie auf den Prüfstand zu stellen. Dieser Artikel unterstützt Sie dabei, Antworten auf folgende Fragen zu finden: Wann sind häufige Releases zu riskant? Wie können Devops-Teams die Risiken richtig bewerten, um Deployment-Fehlschlägen vorzubeugen? 1. Anforderungen und Risiken evaluieren Nicht alle Releases, Funktionen und agilen User Stories sind mit den gleichen Bereitstellungsrisiken verbunden. Viele Unternehmen greifen deshalb inzwischen auf automatisiert erstellte Deployment-Risiko-Scores zu, um zu ermitteln, wie viel Testing- und Review-Arbeit vor dem Release noch erforderlich ist. Dabei einen Ansatz auf Machine-Learning-Basis zu verfolgen, lohnt sich vor allem für Organisationen, die in hoher Frequenz bereitstellen, wie David Brooks, SVP of Evangelism beim Devops-Spezialisten Copado erklärt: “KI kann dabei unterstützen, User Stories auszuwerten, um Unklarheiten, versteckte Abhängigkeiten und Auswirkungen sowie Überschneidungen mit der Arbeit anderer Entwickler zu identifizieren.“ Im Rahmen traditioneller Release-Management-Strategien sind Deployments Teil der internen Kommunikations- und Risikomanagement-Frameworks, wobei größere Upgrades, kleinere Verbesserungen und System-Upgrades charakterisiert werden. Anschließend definieren Devops-Entscheider Deployment-Richtlinien, die Anforderungen an die Risikominderung sowie Automatisierungsregeln auf der Grundlage von Release-Typen. Ein datengetriebener Ansatz charakterisiert hingegen Releases und berechnet Risiko-Scores auf der Grundlage vieler verschiedener, anderer Variablen – beispielsweise der Anzahl der betroffenen Benutzer, der Testabdeckung des betroffenen Codes und Messungen der Abhängigkeitskomplexität. Organisationen können Feedback-Schleifen implementieren, um Risikobewertungen auf der Grundlage der tatsächlichen geschäftlichen Auswirkungen von Releases zu kalibrieren, indem sie Ausfälle, Performance-Probleme, Sicherheitsvorfälle und das Feedback von Endbenutzern erfassen. 2. Security in die Dev Experience einbetten Nach dem Deployment mit Security-Problemen konfrontiert zu werden, birgt diverse Risiken. Deswegen setzen nicht wenige Devops-Teams auf einen „Shift Left“-Security-Ansatz. Dieser beinhaltet einen Mix aus Richtlinien, Kontrollen, Automatisierungen und Tools – vor allem jedoch ein Entwickler-Mindset, bei dem Security eine tragende Rolle spielt.   „Für eine funktionierende, moderne Devops-Praxis ist es absolut essenziell, Sicherheits- und Qualitätskontrollen so früh wie möglich in den Softwareentwicklungszyklus zu integrieren“, unterstreicht Christopher Hendrich, stellvertretender CTO beim Cloud-Lösungsanbieter SADA. Er fügt hinzu: „Eine Plattform für Developer aufzubauen, die Automatisierung, KI-Services und klares Feedback darüber liefert, wie Sicherheitslücken zu beseitigen sind, trägt dazu bei, Security-Mindset und Entwickleraufgaben unter einen Nenner zu bringen.“ Folgende Best Practices sollten Devops-Teams in Betracht ziehen, um das Risiko für Deployment-Katastrophen zu minimieren: Sicherheitsstandards für Softwareentwickler auf der Grundlage von Richtlinien und Frameworks wie OWASP Security Fundamentals, NIST Secure Software Development Framework oder ISO 27034 entwickeln. Risikomanagement im Rahmen der agilen Softwareentwicklung etablieren, indem technische Schulden reduziert werden und komplexe User Stories möglichst früh in Sprint- und Release-Zyklen entstehen. Sicherheitsrisiken im Entwicklungsprozess adressieren. Security Testing in CI/CD-Pipelines verankern. 3. Continuous-Deployment-Voraussetzungen schaffen Viele Entwicklungsteams setzen darauf, den Weg zur Produktion möglichst umfassend zu automatisieren. Allerdings sind nicht alle Dev-Organisationen wirklich bereit für einen Continuous-Deployment-Ansatz. Die vermeintlich simple Zielsetzung, CI/CD in Produktionsumgebungen zu implementieren, kann in exzessive Deployment-Desaster münden, wenn es an den entsprechenden Sicherheitsmaßnahmen mangelt – insbesondere mit Blick auf zunehmend komplexe Applikations- und Microservices-Architekturen. „Die Softwareentwicklung ist ein komplexer Prozess, der mit der Zeit immer schwieriger wird, wenn sich die Funktionalität der Software verändert oder sie altert“, erklärt Melissa McKay, Head of Developer Relations beim Plattformanbieter JFrog. Die Managerin ergänzt: “Ein mehrschichtiger, Ende-zu-Ende-Ansatz ist inzwischen unerlässlich, um sicherzustellen, dass Sicherheit und Qualität von der ersten Paketkuratierung bis zum Runtime Monitoring Priorität haben.“ Devops-Teams, die Continuous Deployment für geschäftskritische, umfangreiche Anwendungen implementieren möchten, sollten auf folgende Best Practices zurückgreifen: Continuous Testing mit hoher Testabdeckung, umfassenden Testdaten und auf Endbenutzer-Personas ausgerichtet umsetzen (inklusive synthetischer Daten und GenAI-Testfunktionen, um Fehler im Produktionscode aufzuspüren). Feature Flags einsetzen, damit Entwicklungsteams experimentelle Funktionen steuern können, die mit einer bestimmten Gruppe von Endbenutzern konfiguriert und getestet werden. Auf Canary-Release-Strategien setzen, um die Bereitstellung mehrerer Versionen einer Anwendung oder eines Services zu unterstützen. 4. Observability, Monitoring und AIOps optimieren In Observability, Application Monitoring und AIOps zu investieren, ist entscheidend, um den Business Impact und die Mean Time to Recovery (MTTR) bei größeren Sicherheitsvorfällen zu optimieren.   „Sämtliche Devops-Deployment-Katastrophen lassen sich letztlich auf einen Mangel an angemessener Kommunikation oder Sichtbarkeit zurückführen“, konstatiert Madhu Kochar, VP of Product Development bei IBM Automation, und fährt fort: „Man kann nicht reparieren, was man nicht sieht, und genau deshalb ist Observability insbesondere in Zusammenhang mit intelligenter Automatisierung von entscheidender Bedeutung, um bekannte Fehler zu beheben und Einblicke in Systeme oder Anwendungen zu erhalten. Das ermöglicht einen unterbrechungsfreien Feedback-Loop und realisiert effiziente und performante Deployments, in deren Rahmen Probleme erkannt werden, bevor sie sich auf die Endbenutzer auswirken.“ Unternehmen, die Microservices-Architekturen einsetzen, in mehreren Clouds bereitstellen und mit vielen Systemen von Drittanbietern verbunden sind, sollten auf AIOps-Lösungen zurückgreifen, um die Ursachen von Incidents ermitteln und automatisiert bearbeiten zu können. 5. Incident Playbook erstellen Tritt ein größerer Incident auf, können IT-Organisationen mit einem operativen Playbook besser darauf reagieren – und entsprechend kommunizieren. Das kann das schlimmste Szenario in einem solchen Fall verhindern. Nämlich, dass von den Technikern bis zu den Führungskräften keiner wirklich weiß, was zu tun ist. Das würde alles nur verzögern, zu weiteren Fehlern beitragen und das Stresslevel weiter nach oben treiben. Deshalb bereiten sich die meisten Unternehmen mit einem ITSM-Playbook auf geschäftskritische Produktionsprobleme vor. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!

5 Tipps gegen Deployment-Desaster​

Das Deployment-Debakel fest im Blick…?Gorodenkoff | shutterstock.com Diverse Devops-Teams in Unternehmen setzen inzwischen auf fortschrittliche CI/CD Pipelines, Infrastructure as Code und andere Automatisierungsinitiativen, um ihre Deployment-Frequenz nach oben zu treiben. Damit steigt potenziell jedoch auch die Fehlerquote, was insbesondere bei geschäftskritischen Anwendungen verheerende Auswirkungen haben kann. Wie verheerend, bewies zuletzt der Sicherheitsanbieter Crowdstrike, der mit einem Deployment-Debakel für Schlagzeilen sorgte, das unter anderem auch empfindliche finanzielle Einbußen für das Unternehmen zur Folge hatte. Vor diesem Hintergrund ist es möglicherweise sinnvoll, Ihre Deployment-Strategie auf den Prüfstand zu stellen. Dieser Artikel unterstützt Sie dabei, Antworten auf folgende Fragen zu finden: Wann sind häufige Releases zu riskant? Wie können Devops-Teams die Risiken richtig bewerten, um Deployment-Fehlschlägen vorzubeugen? 1. Anforderungen und Risiken evaluieren Nicht alle Releases, Funktionen und agilen User Stories sind mit den gleichen Bereitstellungsrisiken verbunden. Viele Unternehmen greifen deshalb inzwischen auf automatisiert erstellte Deployment-Risiko-Scores zu, um zu ermitteln, wie viel Testing- und Review-Arbeit vor dem Release noch erforderlich ist. Dabei einen Ansatz auf Machine-Learning-Basis zu verfolgen, lohnt sich vor allem für Organisationen, die in hoher Frequenz bereitstellen, wie David Brooks, SVP of Evangelism beim Devops-Spezialisten Copado erklärt: “KI kann dabei unterstützen, User Stories auszuwerten, um Unklarheiten, versteckte Abhängigkeiten und Auswirkungen sowie Überschneidungen mit der Arbeit anderer Entwickler zu identifizieren.“ Im Rahmen traditioneller Release-Management-Strategien sind Deployments Teil der internen Kommunikations- und Risikomanagement-Frameworks, wobei größere Upgrades, kleinere Verbesserungen und System-Upgrades charakterisiert werden. Anschließend definieren Devops-Entscheider Deployment-Richtlinien, die Anforderungen an die Risikominderung sowie Automatisierungsregeln auf der Grundlage von Release-Typen. Ein datengetriebener Ansatz charakterisiert hingegen Releases und berechnet Risiko-Scores auf der Grundlage vieler verschiedener, anderer Variablen – beispielsweise der Anzahl der betroffenen Benutzer, der Testabdeckung des betroffenen Codes und Messungen der Abhängigkeitskomplexität. Organisationen können Feedback-Schleifen implementieren, um Risikobewertungen auf der Grundlage der tatsächlichen geschäftlichen Auswirkungen von Releases zu kalibrieren, indem sie Ausfälle, Performance-Probleme, Sicherheitsvorfälle und das Feedback von Endbenutzern erfassen. 2. Security in die Dev Experience einbetten Nach dem Deployment mit Security-Problemen konfrontiert zu werden, birgt diverse Risiken. Deswegen setzen nicht wenige Devops-Teams auf einen „Shift Left“-Security-Ansatz. Dieser beinhaltet einen Mix aus Richtlinien, Kontrollen, Automatisierungen und Tools – vor allem jedoch ein Entwickler-Mindset, bei dem Security eine tragende Rolle spielt.   „Für eine funktionierende, moderne Devops-Praxis ist es absolut essenziell, Sicherheits- und Qualitätskontrollen so früh wie möglich in den Softwareentwicklungszyklus zu integrieren“, unterstreicht Christopher Hendrich, stellvertretender CTO beim Cloud-Lösungsanbieter SADA. Er fügt hinzu: „Eine Plattform für Developer aufzubauen, die Automatisierung, KI-Services und klares Feedback darüber liefert, wie Sicherheitslücken zu beseitigen sind, trägt dazu bei, Security-Mindset und Entwickleraufgaben unter einen Nenner zu bringen.“ Folgende Best Practices sollten Devops-Teams in Betracht ziehen, um das Risiko für Deployment-Katastrophen zu minimieren: Sicherheitsstandards für Softwareentwickler auf der Grundlage von Richtlinien und Frameworks wie OWASP Security Fundamentals, NIST Secure Software Development Framework oder ISO 27034 entwickeln. Risikomanagement im Rahmen der agilen Softwareentwicklung etablieren, indem technische Schulden reduziert werden und komplexe User Stories möglichst früh in Sprint- und Release-Zyklen entstehen. Sicherheitsrisiken im Entwicklungsprozess adressieren. Security Testing in CI/CD-Pipelines verankern. 3. Continuous-Deployment-Voraussetzungen schaffen Viele Entwicklungsteams setzen darauf, den Weg zur Produktion möglichst umfassend zu automatisieren. Allerdings sind nicht alle Dev-Organisationen wirklich bereit für einen Continuous-Deployment-Ansatz. Die vermeintlich simple Zielsetzung, CI/CD in Produktionsumgebungen zu implementieren, kann in exzessive Deployment-Desaster münden, wenn es an den entsprechenden Sicherheitsmaßnahmen mangelt – insbesondere mit Blick auf zunehmend komplexe Applikations- und Microservices-Architekturen. „Die Softwareentwicklung ist ein komplexer Prozess, der mit der Zeit immer schwieriger wird, wenn sich die Funktionalität der Software verändert oder sie altert“, erklärt Melissa McKay, Head of Developer Relations beim Plattformanbieter JFrog. Die Managerin ergänzt: “Ein mehrschichtiger, Ende-zu-Ende-Ansatz ist inzwischen unerlässlich, um sicherzustellen, dass Sicherheit und Qualität von der ersten Paketkuratierung bis zum Runtime Monitoring Priorität haben.“ Devops-Teams, die Continuous Deployment für geschäftskritische, umfangreiche Anwendungen implementieren möchten, sollten auf folgende Best Practices zurückgreifen: Continuous Testing mit hoher Testabdeckung, umfassenden Testdaten und auf Endbenutzer-Personas ausgerichtet umsetzen (inklusive synthetischer Daten und GenAI-Testfunktionen, um Fehler im Produktionscode aufzuspüren). Feature Flags einsetzen, damit Entwicklungsteams experimentelle Funktionen steuern können, die mit einer bestimmten Gruppe von Endbenutzern konfiguriert und getestet werden. Auf Canary-Release-Strategien setzen, um die Bereitstellung mehrerer Versionen einer Anwendung oder eines Services zu unterstützen. 4. Observability, Monitoring und AIOps optimieren In Observability, Application Monitoring und AIOps zu investieren, ist entscheidend, um den Business Impact und die Mean Time to Recovery (MTTR) bei größeren Sicherheitsvorfällen zu optimieren.   „Sämtliche Devops-Deployment-Katastrophen lassen sich letztlich auf einen Mangel an angemessener Kommunikation oder Sichtbarkeit zurückführen“, konstatiert Madhu Kochar, VP of Product Development bei IBM Automation, und fährt fort: „Man kann nicht reparieren, was man nicht sieht, und genau deshalb ist Observability insbesondere in Zusammenhang mit intelligenter Automatisierung von entscheidender Bedeutung, um bekannte Fehler zu beheben und Einblicke in Systeme oder Anwendungen zu erhalten. Das ermöglicht einen unterbrechungsfreien Feedback-Loop und realisiert effiziente und performante Deployments, in deren Rahmen Probleme erkannt werden, bevor sie sich auf die Endbenutzer auswirken.“ Unternehmen, die Microservices-Architekturen einsetzen, in mehreren Clouds bereitstellen und mit vielen Systemen von Drittanbietern verbunden sind, sollten auf AIOps-Lösungen zurückgreifen, um die Ursachen von Incidents ermitteln und automatisiert bearbeiten zu können. 5. Incident Playbook erstellen Tritt ein größerer Incident auf, können IT-Organisationen mit einem operativen Playbook besser darauf reagieren – und entsprechend kommunizieren. Das kann das schlimmste Szenario in einem solchen Fall verhindern. Nämlich, dass von den Technikern bis zu den Führungskräften keiner wirklich weiß, was zu tun ist. Das würde alles nur verzögern, zu weiteren Fehlern beitragen und das Stresslevel weiter nach oben treiben. Deshalb bereiten sich die meisten Unternehmen mit einem ITSM-Playbook auf geschäftskritische Produktionsprobleme vor. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Nach oben scrollen