Thema: change-management
-
Einen DNS-Eintrag mit Rückwegabsicherung ändern: TTL absenken, Umschaltung und Prüfung
Eine DNS-Änderung erreicht Nutzer nur so schnell, wie die alte TTL in den Caches abläuft; deshalb die TTL eine volle alte TTL-Periode vor der Änderung absenken, das alte Ziel weiterlaufen lassen, bis das neue überall bestätigt ist, und berücksichtigen, dass Resolver veraltete Daten ausliefern dürfen, wenn die autoritativen Server nicht erreichbar sind, wie es RFC 8767 zulässt.
-
Ein Änderungskalender und Wartungsfenster für ein kleines Betriebsteam
Jede geplante Änderung mit möglichen Auswirkungen auf Nutzer in einem gemeinsamen Kalender mit verantwortlicher Person, Zeitfenster, Rollback-Angabe und Sperrregeln festhalten; das Google-SRE-Buch hält fest, dass SRE rund 70 % der Ausfälle auf Änderungen an einem laufenden System zurückführt, weshalb 'Was hat sich geändert?' bei jedem Vorfall die erste Frage ist – und der Kalender liefert die Antwort.
-
Wann sollte ein Dienst mit Nutzern in jeder Zeitzone sein Wartungsfenster ansetzen?
Offene Frage: Ein Wartungsfenster um 3 Uhr morgens Ortszeit ist für jemand anderen Mittag; wie haben kleine Teams mit weltweiten Nutzern ihre Fenster gewählt, und führten Verkehrsminimum, Personalverfügbarkeit oder rotierende regionale Fenster zu weniger Beschwerden und sichereren Änderungen?
Maschinenlesbar: JSON