Runbooks, was sind sie, und warum brauche ich sie?

Kurz gesagt, ein Runbook ist ein detaillierter Satz von Anweisungen, die IT-Administratoren, Systemadministratoren, Techniker und DevOps-Techniker (und viele andere, je nach Runbook-Inhalt) durch routinemäßige und kritische Verfahren führen können, die für die Verwaltung oder Problembehandlung von Systemen, Anwendungen oder Infrastrukturen erforderlich sind.

Wenn Sie Ihre Runbooks an Ort und Stelle haben und weit verbreitet sind, können Sie in einem kritischen Moment Bearbeitungszeit sparen und Verzögerungen im Allgemeinen gering halten.

Haben Sie ein Problem mit dem Microservice-Pod?

Überprüfen Sie möglicherweise das Runbook auf dieses Problem, um festzustellen, ob es bereits behoben wurde. Müssen Sie einem Benutzer Zugriff auf ein System oder Tool gewähren, wissen aber nicht, wer das Element verwaltet?

Wie erhalten Sie diese Ressourcen für Ihre Teammitglieder?

Ein Runbook, das gut dokumentiert und gut verteilt ist, ist in diesen Fällen hilfreich.

So habe ich im Allgemeinen Runbooks für das aktuelle Projekt entwickelt, an dem ich gearbeitet habe. Es kam eine Zeit und ein Raum, in dem ein Bedürfnis nicht erfüllt wurde. Es gab viele Fragen zur Erledigung einer Vielzahl von Aufgaben, wobei die Antworten über viele Abteilungen zwischen verschiedenen Mitgliedern des Teams verstreut waren.

Die Informationen sind da, sie sind nur nicht dokumentiert und werden vor allem nicht geteilt, was große blinde Flecken innerhalb eines Unternehmens hinterlässt, um sich selbst durch geringe Ausgaben und hohe Renditen effektiv zu verwalten.

Vorantreiben der Runbookerstellung durch Identifizieren von Fragen

Der Prozess begann mit der Identifizierung der Fragen:

• Welche Anwendungen, Systeme, Tools sind innerhalb des Unternehmens verfügbar?

  • Sauce Labs, Bitrise, DataDog, AWS, Human, Lucid, Figma, etc.

• Wer ist der Eigentümer/Sponsor der einzelnen Tools und Systeme?

  • Administratoren

• Wer innerhalb der Org. Zugang hat und zu welchen Systemen, und sollten sie Zugang haben?

  • Verwaltete Systeme / Berechtigungen

Die Identifizierung der oben genannten Fragen half mir, die Arbeit darzulegen, die aus meiner eigenen Perspektive erforderlich war. Es begann damit, herauszufinden, wer von dem wusste, was wir innerhalb der Organisation zur Verfügung hatten. Ich selbst hatte Zugang zu einigen Systemen und Tools, die benötigt wurden, aber ich hatte keine Ahnung, wie viele es gab.

Die Suche nach dem Verantwortlichen innerhalb des Unternehmens, der den meisten Zugriff auf die meisten Systeme und Tools hatte, beschleunigte den Prozess erheblich. Nachdem ich verstanden hatte, welche Ressourcen ich untersuchen musste, konnte ich herausfinden, wer tatsächlich Zugriff hatte und welche Berechtigungen er für bestimmte Tools hatte. Ich konnte auch Personen identifizieren, die vielleicht diesen Zugang haben sollten und es nicht getan haben.

Mit diesem Prozess ging auch eine Überprüfung und der Wunsch einher, festzulegen, was Benutzer für ihre Berechtigungen erhalten, wenn sie zu einem System hinzugefügt werden. Die richtige Dimensionierung trug auch dazu bei, dass die Sicherheitsprobleme verschärft wurden. Personen, die zuvor den "Gott"-Modus oder Administratorrechte aktiviert hatten, wurden in verwandtere Rollen versetzt, die ihren Berechtigungsanforderungen entsprachen.

Dies wird zweifellos auch innerhalb einer Organisation zu Unruhe führen, da die Rechte für die Benutzer abgeschwächt werden. Das Ziel besteht darin, die geringste Berechtigungsstufe mit dem richtigen Bereich für die Anforderungen der Endbenutzer zugewiesen zu haben. Darüber hinaus ist es ein Wunsch und kein Bedürfnis.

Wenn Sie Ihre Systeme gut bereitstellen, mit klar definierten Rollen und Berechtigungen sowie den zugehörigen Runbooks, werden viele Aspekte des täglichen Betriebs und langfristiger Belange erheblich verbessert.

Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns

Podcast-Episoden & Blogbeiträge