Ich bin immer daran interessiert, wie IT-Teams an die Planung von Produktionsänderungen herangehen. Normalerweise verwenden wir Runbooks, um die wichtigsten Schritte einer Änderung sowie Backout-Pläne darzustellen. Ich bin gespannt, ob wir von anderen lernen können und wie man Runbooks am besten dokumentiert.
Antwort1
Ich bevorzuge Skripte mit Kommentaren und Ausdrucken.
Sie haben den doppelten Vorteil der Dokumentation und Automatisierung.
Bei einem ganzheitlicheren Ansatz gibt es jedoch normalerweise eine Menge Dinge zu verfolgen;
Skripts werden nur für Dinge verwendet, die in einer bestimmten Reihenfolge erledigt werden müssen.
Wenn viele Notizen erforderlich sind, bevorzuge ich ein lokal gehostetes Wiki (persönlichoderGruppe).
Es kann verwendet werden, um
- Verweisen Sie mit Links auf Ihre Tools und schreiben Sie kurze Notizen
- Kontakte und Eskalationshinweise auflisten
- Notfallmaßnahmen schlagwortartig dokumentieren
- Sicherungsorte und Wiederherstellungssequenzen
- Hosten Sie eine durchsuchbare Aufzeichnung regelmäßiger Anforderungen und Lösungen. So kommen die Leute zu Ihnen, nachdem sie das überprüft haben.
Achten Sie aber darauf, dass der Standort sicher ist, denn im Notfall sollten die Daten nicht unzugänglich sein.
Hier ist ein altesMicrosoft Technet SQL Server-RunbookSeite zum Erfassen allgemeiner Ideen.
Antwort2
Was ich mache:
Alle Serverkonfigurationen, die gegenüber der installierten Betriebssystem-Baseline geändert werden müssen, werden von Chef verwaltet und in Modulen (sogenannten Cookbooks) gespeichert, die dann über Git in der Versionskontrolle gespeichert werden.
Die meisten Konfigurationen wurden manuell auf einem Testsystem (oft ein VM-Image oder einfach eine EC2-Instanz) vorgenommen und dann wurde ein Konfigurationsrezept geschrieben, das alle verschiedenen Komponenten der Änderungen abdeckt. Der Workflow zum Aktualisieren der Umgebung läuft ungefähr so ab:
- Erstellen Sie im entsprechenden System ein Ticket, dass eine Änderung vorgenommen werden muss.
- Dokumentieren Sie alle Gründe und Umstände der Änderung.
- Bearbeiten Sie die Konfigurationsrezepte, Vorlagen, Dateien usw., die erforderlich sind, damit die Änderung auf dem oder den Zielsystemen erfolgt.
- Übernehmen Sie die Änderung im lokalen Repository und übertragen Sie sie auf den Master-Versionskontrollserver.
- Aktualisieren Sie das Ticket, damit die Änderungen einer Peer-Review unterzogen werden können.
- Änderungen werden unterzeichnet und auf dem Chef-Server bereitgestellt, damit dieser über die aktualisierten Bits informiert ist.
- Führen Sie Chef manuell auf Clients aus oder lassen Sie es automatisch laufen, je nach den Anforderungen der Änderung. (Ich würde es nicht auf mehr als einem halben Dutzend Systemen manuell ausführen.)
Der Betriebsmodus von Chef schlägt fehl, wenn beim Ausführen des Clients ein Problem auftritt, z. B. wenn ein Paket nicht vorhanden ist, eine Vorlagendatei nicht gefunden wird oder viele andere Probleme auftreten. Beheben Sie das Problem, dokumentieren Sie es im Ticket und führen Sie den Client erneut aus.
Die Person mit der geschäftlichen Anforderung für die Änderung überprüft, ob die Änderung erfolgreich war, und schließt das Ticket.
Chef-spezifisch, weil ich das verwende. Ersetzen Sie das entsprechende Tool für Ihre Umgebung, und wenn Sie kein Konfigurationsmanagement-Tool verwenden, müssen Sie sich etwas anderes anschauen, weil es den gesamten Prozess viel robuster und zuverlässiger macht. Ganz zu schweigen von der Skalierbarkeit.
Antwort3
Für wirklich kritische und sensible Änderungen habe ich normalerweise eine Textdatei mit den eigentlichen Befehlen, die ich verwenden werde, mit #Kommentaren, die erklären, was passiert. Auf diese Weise kann ich sie schnell in ein Terminal kopieren und einfügen.
Antwort4
Ich unterstütze die Grundidee hinter dem Beitrag von jtimberman, wobei Puppet mein bevorzugtes Tool ist.