Automation as Code einführen: Ausweitung von Infrastructure as Code auf Policy as Code

Basierend auf der strategischen Grundlage von Infrastructure as Code (IaC) beginnen Unternehmen, diese Methoden zu nutzen, um IT-Prozesse in den verschiedenen Phasen des operativen Lifecycles zu automatisieren. So wie IaC die Entwicklung, Bereitstellung und Implementierung von Infrastrukturen standardisiert, können IT-Teams OaC (Ops as Code) einsetzen, um das Management und die Verwaltung von Systemen nach deren Implementierung zu kodifizieren. Dieser Ansatz kann dann zu Policy as Code (PaC) erweitert werden, um Governance-, Risiko- und Compliance-Prozesse für Anwendungen und Lösungen zu automatisieren.

Die Automatisierung zur schnelleren Bereitstellung und Verbesserung der Effizienz ist ein allgemeines Ziel für Anwendungs- und Infrastrukturteams, aber die meisten verlassen sich weiterhin auf manuelle Ansätze für Day-2-Operationen und Governance. Die Automatisierung kann in diesen Bereichen ebenso viele Vorteile bieten, aber ihre Nutzung zur Durchführung von Day-2-Prozessen erfordert auch, dass etablierte Teams neue Tools und Methoden erlernen. Ops as Code und Policy as Code vereinfachen diesen Kulturwandel, da sie die etablierte IaC-Strategie erweitern und es Unternehmen ermöglichen, ihr Know-how und die verwendeten Tools auf verschiedene Aufgaben anzuwenden.

Mithilfe der IaC-Methoden können Unternehmen OaC und PaC einsetzen, um bewährte Verfahren zu kodifizieren und Routineaufgaben für die einzelnen operativen Prozesse zu automatisieren, sodass eine durchgängige Automatisierung erreicht werden kann. Diese Automation as Code-Ansätze stellen sicher, dass Prozesse auf konsistente, skalierbare Weise ausgeführt werden, sodass Teams – mit minimalen manuellen Eingriffen – Anwendungen, Infrastrukturen und Workloads erstellen und verwalten können, die durchgehend konform sind.

Die Erstellung und Verwaltung von IT-Infrastrukturen wie Servern, Cloud-Instanzen, Betriebssystemen, Storage, Load Balancern und anderen Endpunkten war in der Vergangenheit ein zeitaufwendiger manueller Prozess. Da die Infrastruktur jedoch zunehmend containerisiert und auf verschiedenen Plattformen bereitgestellt wird – von Rechenzentren über Multi Clouds bis hin zu Edge-Standorten – wird ein Teil davon als Code bereitgestellt, insbesondere in der Cloud.

Beim Deployment als Code kann die Infrastruktur schneller gestartet werden, um die schnell wachsende Nachfrage und die Anforderungen an die Skalierbarkeit zu erfüllen. Dieser Vorteil hat auch zu einer höheren Komplexität und Dringlichkeit beim Management der Infrastruktur geführt, und Unternehmen müssen diese oft täglich bereitstellen, einrichten und wieder abbauen. Deshalb haben die IT-Teams IaC eingeführt, um diese Prozesse zu automatisieren.

Was beinhaltet der Infrastructure as Code (IaC)? 

Bei einem IaC-Ansatz wird die Infrastruktur durch automatisch ausgeführten Code definiert, bereitgestellt und verwaltet. Mit IaC werden Konfigurationsdateien erstellt, die Infrastruktur-Spezifikationen enthalten, wodurch die Bearbeitung und Verteilung korrekt konfigurierter Infrastruktur- und Cloud-Instanzen erleichtert wird. Durch die Kodifizierung und Dokumentation dieser Spezifikationen können Teams dank IaC undokumentierte Ad-hoc-Änderungen vermeiden und sicherstellen, dass stets die gleiche Umgebung zur Verfügung gestellt wird.

Die Automatisierung der Infrastruktur mit IaC bedeutet, dass Entwicklungsteams die Infrastrukturkomponenten nicht immer manuell bereitstellen und verwalten müssen, wenn sie eine Anwendung entwickeln oder ein Deployment durchführen – wodurch sich die Geschwindigkeit und Konsistenz drastisch verbessern und gleichzeitig menschliche Fehler und Ausfallzeiten reduziert werden können. Dieser Ansatz ermöglicht es Unternehmen auch, Best Practices in den Automatisierungscode einzubauen, sodass die Ausführung der einzelnen Aufgaben auf dem gemeinsamen Know-how der Teams basiert.

Zum Guide über das Automatisieren von Infrastruktur-Workloads

Ausweitung der IaC-Strategie

IaC stellte für die meisten Organisationen eine große Herausforderung dar, da die Entwicklung neuer Tools und die Einführung neuer Arbeitsweisen Zeit in Anspruch nahm. Doch die Teams erhielten auch den Freiraum, ihre Schwerpunkte flexibler zu setzen und agiler auf Probleme zu reagieren. Inzwischen können viele Automatisierungs-Tools IaC unterstützen und IT Teams nutzen die vielen Vorteile, die dieser kulturelle Wandel mit sich bringt.

Durch die Nutzung etablierter Methoden und Tools, die für IaC entwickelt wurden, beginnen IT-Teams, einen „Automation as Code“-Ansatz für Prozesse zu verfolgen, die über die Bereitstellung, Konfiguration und Anwendungsimplementierung hinausgehen und den gesamten operativen Lifecycle umfassen. Es gibt keine einheitliche Definition für den operativen Lifecycle, aber er wird üblicherweise in die folgenden „Days“ unterteilt:

• Day 0: Design. Festlegen der Konstruktionen für Build, Konfiguration und Provisionierung der Infrastruktur 
• Day 1: Deployment. Installieren, Einrichten und Konfigurieren der Infrastruktur
• Day 2: Verwaltung. Managen, Verwalten und Aktualisieren von Systemen im Zusammenhang mit der bereitgestellten Infrastruktur

IaC bietet eine konsistente Methode für den Aufbau und die Provisionierung von Infrastrukturen an Day 0 und Day 1, während Ops as Code diesen Ansatz auf Day-2-Operationen wie Managen, Verwalten, und Aktualisieren von Systemen ausweitet – und zwar so lange, bis die Anwendung oder der Service deprovisioniert werden muss.

Day-2-Aufgaben – wie das Monitoring der Systemfunktionalität, die Installation von Upgrades und die Fehlerbehebung – wurden bisher üblicherweise manuell durchgeführt. Wenn ein Server oder eine Anwendung ausfällt, erhalten IT-Teams möglicherweise eine Ticket-Warnung, aber das ist nur ein Symptom, das untersucht werden muss. Eine Person muss dann das Problem evaluieren, d. h. sie könnte sich bei der physischen Box anmelden, die Ursache ermitteln und weitere IT-Sachverständige hinzuziehen, um den Fehler zu beheben. Letztendlich werden derartige Situationen gelöst, aber der Prozess braucht Zeit, besonders wenn man ihn mit dem Umfang der gesamten Unternehmensaktivitäten sieht.

Hinzu kommt, dass die Komplexität der Day-2-Operationen ebenso zugenommen hat wie die der Day-0- und Day-1-Infrastrukturaufgaben, und dennoch wird die Automatisierung für die Day-2-Herausforderungen nicht in großem Umfang genutzt. Viele Unternehmen haben IaC eingeführt, um Day-0- und Day-1-Prozesse zu automatisieren, aber nun kann derselbe Ansatz auch auf Abläufe angewandt werden, die in Rechenzentren, Cloud-Umgebungen und Edge-Implementierungen durchgeführt werden. So lassen sich technologische Auswüchse eindämmen und Ressourcen freisetzen.

Was bedeutet Ops as Code (OaC)?  

Ops as Code (OaC) ist eine natürliche Weiterentwicklung von IaC. Es geht darum, das geballte Wissen der Infrastruktur- und Betriebsteams zu nutzen – die gesamten Erfahrungen, die sie bei der Problemlösung gewonnen haben – und es durch Automatisierung zu kodifizieren. Dies bedeutet, dass das operative Wissen zu einer zugänglichen Ressource wird und nicht nur in einzelnen Teams vorhanden ist.

OaC ist der Prozess der Standardisierung, Kodifizierung und Systematisierung des operativen Wissens von Teams von Day-2-Operationen. Zur Einführung von OaC sollten Organisationen folgende Schritte unternehmen: 

• Standardisieren einer gemeinsamen Codebasis zur Verwendung in der gesamten Organisation, um die operative Konsistenz zu verbessern
• Kodifizieren des operativen Wissens und Integrieren bewährter Verfahren in automatisierte Prozesse 
• Systematisieren unterschiedlicher Tools und Prozesse in einem integrierten End-to-End-Ansatz

Die Methoden von Day 2 werden in Code umgewandelt – in Code, der automatisch ausgeführt werden kann, wenn die Systeme zunehmend intelligenter, komplexer und mehr voneinander abhängig werden.

Wie bei sämtlichen Automatisierungsanwendungen ist Ops as Code nicht dazu gedacht, Menschen zu ersetzen – es ermöglicht den Teams, mühsame, manuelle Aufgaben zu minimieren und sich stattdessen auf zukunftsweisende Projekte zu konzentrieren. Durch die Kombination des Team-Knowhows in gemeinsamen Ansätzen unterstützt OaC auch die Zusammenarbeit über verschiedene Betriebsmodelle und Teamstrukturen hinweg.

Die Ausweitung von IaC- und OaC-Methoden auf die Governance kann IT-Teams von aufgeblähten, anforderungsbasierten Prozessen befreien, insbesondere wenn es um die Durchsetzung von Richtlinien geht – Regeln, Bedingungen oder Anweisungen, die sicherstellen sollen, dass der Betrieb die Compliance-Anforderungen, Best Practices und Unternehmensrichtlinien einhält. 

Sobald Infrastruktur und Betrieb als Code definiert und gemanagt werden, können Sicherheits- und Compliance-Teams dieselben Strategien verwenden, um Richtlinien auf diesen Code anzuwenden und das Management der Governance zu standardisieren – mit einem Policy as Code-Ansatz.

Automatisierung garantiert nicht von Anfang an Konformität und Governance. Deswegen müssen Richtlinien konsequent durchgesetzt werden, um sicherzustellen, dass IaC und OaC in den einzelnen Phasen des operativen Lifecycles korrekt angewendet werden. Zu den gängigen Governance-Methoden gehören üblicherweise: 

• Erstellen von Workflows mit Genehmigungen, die es Einzelpersonen erschweren, Ad-hoc-Lösungen zu liefern
• Implementieren restriktiver Sicherheitsberechtigungen durch Role-Based Access Control (RBAC) oder Attribute-Based Access Control (ABAC), um zu kontrollieren, wer welche Technologien auf bestimmte Weise, unter bestimmten Bedingungen oder mit bestimmten Merkmalen ändern darf

Diese manuellen Verfahren können fehleranfällig und zeitaufwendig sein. Policy as Code versucht, diese Prozesse zu automatisieren. Beispielsweise kann die Automatisierung so eingerichtet werden, dass IT-Mitarbeitende daran gehindert werden, eine Cloud-Instanz zu erstellen, die nicht den Unternehmensstandards entspricht – oder sie daran hindern, Code bereitzustellen, der nicht den Compliance-Vorgaben entspricht. RBAC und ABAC sind nach wie vor notwendig, aber PaC ermöglicht einen granulareren und automatisierten Prozess zu schaffen, der bestimmt, waswann getan werden kann.

Was bedeutet Policy as Code (PoC)?

Policy as Code (PaC) verfolgt ähnliche Strategien wie IaC und OaC und automatisiert den Konformitätsprozess, indem es Richtlinien und Sicherheitsanforderungen in den Code schreibt, wodurch Standards in praktisch jeden Prozess integriert und dieselben Regeln in nahezu allen Teams konsequent durchgesetzt werden können. Durch das Definieren, Aktualisieren, Freigeben und Durchsetzen von Richtlinien mithilfe von Code zentralisiert PaC die Governance und erleichtert die effiziente Anwendung von Richtlinien auf die verschiedenen IT-Aktionen auf dokumentierte und konsistente Weise.

Wenn Richtlinien als Code definiert sind, können sie nahtlos auf die Infrastruktur angewendet werden, wenn diese aktiviert und bereitgestellt wird. Dies gilt auch für den Betrieb, wenn automatisierte Aufgaben ausgeführt werden, um einen Standardansatz durchzusetzen, unabhängig davon, wo oder wann die Automatisierung stattfindet. Wenn beispielsweise eine Person eine Automatisierung ausführt, um ein Problem auf einem bestimmten Host zu beheben, können die in jeder Aktion kodierten Richtlinien verhindern, dass diese Person etwas tut, was gegen die Regeln des Teams verstößt.

PaC stimmt auch die technischen Umgebungen und Ressourcen auf die vereinbarten Standards ab. So können Teams beispielsweise mit PaC sicherstellen, dass sensible Computerressourcen keinen direkten Zugang zum Internet haben – was möglicherweise gegen Sicherheitsrichtlinien verstößt – oder ihre Service-Ports auf HTTPS und SSH beschränken.

Da die KI zu einem Multiplikator für die Skalierbarkeit zahlreicher Systeme wird, geht sie in der IT über das hinaus, was Menschen allein erreichen und kontrollieren können. Wenn Teams einen KI-Service wie Red Hat® Ansible® Lightspeed mit IBM watsonx Code Assistant zur beschleunigten Automatisierungsentwicklung nutzen, können sie Richtlinien in den Code schreiben und von Anfang an Governance in das Lernmodell integrieren. Sobald das KI-Tool beispielsweise Richtlinien in sein Lernmodell integriert hat, können Content Creators einen Code schreiben, der die vorgeschriebenen Compliance-Anforderungen automatisch einhält.

Die automatisierte Governance mit PaC stellt sicher, dass die KI-gesteuerte Verwaltung transformative Effizienzen bieten kann und gleichzeitig die erwartete Kontrolle beibehält, sodass das, was für die IT-Teams getan wird, bereits in die Compliance integriert ist.

Vereinfacht gesagt, ist jede Art von Automation as Code Transformation vor allem eine kulturelle Herausforderung. Mit den Erfahrungen, die bei der Automatisierung von IaC gewonnen wurden, können IT-Teams dieselben Methoden und Tools nutzen, um einen effizienteren, anpassungsfähigeren Ansatz für den Betrieb während des gesamten Entwicklungs-Lifecycles zu verfolgen.

Die Implementierung von DevOps brachte den Unternehmen eine Vielfalt von Vorteilen, aber auch Probleme, wobei die weitreichenden Bemühungen gezeigt haben, dass ein kultureller Wandel in einem solchen Ausmaß möglich ist. Bei der Automatisierung geht es immer darum, die Art und Weise zu ändern, wie Aufgaben ausgeführt werden. Die Einführung einer einheitlichen Automation as Code-Strategie erfordert jedoch, dass Unternehmen die Zusammenarbeit von Teams durch die gemeinsame Nutzung von Praktiken in den einzelnen Betriebsphasen verändern. IaC, OaC und PaC stehen im Mittelpunkt dieser Bemühungen.

Zur Unterstützung des kulturellen Wandels zu Automation as Code-Strategien sollten Teams:

• Wie bei der Software-Entwicklung denkenVerwenden Sie Git oder andere Repositories und pflegen Sie gleichzeitig eine moderne Entwicklungs- und Deployment-Kultur in den verschiedenen Bereichen des Unternehmens.
• Eine Mentalität von Automation-First entwickeln Wenn Sie ein neues Projekt haben oder etwas entwickeln wollen, entwickeln Sie es nicht einfach, sondern überlegen Sie zuerst, wie Sie es automatisieren können. Beginnen Sie mit einfacheren Automatisierungsprojekten und bauen Sie diese dann aus. 
• Zunächst mit den Fähigkeiten und Erfahrungen der einzelnen Personen beginnen. Schließen Sie Kompetenzlücken und nutzen Sie das gesammelte Wissen aller Mitarbeitenden Ihres Unternehmens für die Automatisierung, damit Inhalte und Fachwissen teamübergreifend genutzt werden können.

Automation as Code kann erfolgreich sein, wenn diese Philosophie in sämtlichen Teams verankert wird, von der Systementwicklung bis zur Systemverwaltung. Diese Ansätze gehen über die gelegentliche Automatisierung von Aufgaben in einigen wenigen Teams und die Hoffnung hinaus, dass alles kompatibel ist – sie geben Teams im gesamten Unternehmen eine gemeinsame Strategie und Disziplin, die sie gemeinsam gestalten können.

Zur Umsetzung dieser Strategie müssen die Teams auch über Ad-hoc-Lösungen hinausgehen, die nur für einige Use Cases und in einigen Teams funktionieren. IaC und DevOps können übermäßig komplex werden und technische Schulden verursachen, wenn Unternehmen mehrere Tools zur Steuerung des Prozesses verwenden. Mit einer einheitlichen Automatisierungsplattform kann dieselbe Automatisierungssprache, die für die Durchführung von Konfigurations-, Netzwerk-, Infrastruktur- oder Cloud-Aufgaben verwendet wird, auf operative Aufgaben in verschiedenen Bereichen ausgedehnt werden, sodass IT-Teams den gesamten End-to-End-Lifecycle verwalten können.

Red Hat Ansible Automation Platform umfasst die erforderlichen Tools, um eine unternehmensweite Automatisierung zu implementieren, einschließlich Event-Driven Ansible, Analytik, zusätzliche Sicherheit und ein breites IT-Ökosystem zertifizierter und validierter Inhalte, um neue Automatisierungsinitiativen zu starten. Sie verwendet YAML in menschenlesbarer Form, sodass Nutzende verschiedener Kompetenzstufen Automatisierungsinhalte in Ihrem Unternehmen gemeinsam nutzen, prüfen und verwalten können. 

Mit Ansible Automation Platform kann Ihr Unternehmen die Erfahrungen von Betriebs-, Infrastruktur- und Anwendungsteams in YAML-basierten Ansible Playbooks und Ansible Rulebooks kodifizieren. Playbooks und Rulebooks können verwendet werden, um bekannte Lösungsmuster in Automation as Code-Ansätze einzubauen, und Event-Driven Ansible kann diese Automatisierung für Sie auslösen, wenn ein bestimmtes Event eintritt.

Durch den Aufbau von Fachwissen in Playbooks und Rulebooks können Ihre Teams IT-Reaktionen automatisieren, um Konfigurationsabweichungen zu begrenzen, langfristige Wartungsprobleme zu minimieren und die durchschnittliche Zeit bis zur Problemlösung (MTTR) zu verbessern. Das modulare Design von Event-Driven Ansible ermöglicht Ihnen, IT-Prozesse zu automatisieren, wann und wo Sie sie benötigen, über Domains hinweg und für Use Cases in sämtlichen Phasen des operativen Lifecycles.

Mehr über Event-Driven Ansible erfahren

Red Hat Ansible Lightspeed mit IBM watsonx Code Assistant macht Automation as Code-Ansätze noch zugänglicher und unterstützt Sie beim Umwandeln von Fachwissen in zuverlässigen YAML-Code, der sich über Teams und Domains hinweg skalieren lässt. Nutzende können eine Aufgabenanfrage in natürlicher Sprache eingeben, und Ansible Lightspeed interagiert mit IBM watsonx Basismodellen, um Codeempfehlungen für die Erstellung von Ansible Playbooks zu generieren. Dieser Service kann Teammitgliedern unterschiedlicher Erfahrungsstufen zu mehr Produktivität, Effizienz und Genauigkeit verhelfen und eine einheitlichere Automatisierung in Ihrem Unternehmen fördern.

Red Hat bietet interaktive Labs in einer vorkonfigurierten Ansible Automation Platform-Umgebung. Nutzen Sie unsere Labs zum Experimentieren, und lernen Sie, wie Sie IT-Praktiken effizient erstellen, verwalten und skalieren – von der schnellen Entwicklung und Bereitstellung über vereinfachte Abläufe und Analysen bis hin zu konsistenten End-to-End-Benutzererlebnissen.