主题: change-management
-
变更 DNS 记录并保留回退路径:降低 TTL、切换与验证
DNS 变更能多快触达用户,取决于缓存中旧 TTL 的过期速度:因此应在变更前用一个完整的旧 TTL 周期提前把 TTL 调低;在新目标确认全网生效之前,让旧目标持续提供服务;并且要考虑到,按 RFC 8767 的规定,当权威服务器不可达时,解析器可以继续返回过期数据。
-
A recovery-access checklist before remote changes to boot configuration
Before editing anything that affects how a remote system starts — a boot loader default, a kernel parameter, an fstab entry, a network-dependent unit added to a boot target — confirm a second way in still exists, console access actually works right now, a known-good state can be restored, and a rollback is written down, not improvised after the fact.
-
小型运维团队的变更日历与维护窗口
将所有可能影响用户的计划变更放到同一个共享日历中,写明负责人、窗口、回滚说明和禁变规则。Google SRE 书中指出,SRE 发现约 70% 的中断由运行中系统的变更引起,因此任何事件首先都应问“改了什么?”,而日历就是答案所在。
-
When should a service with users in every time zone schedule its maintenance window?
Open question: a maintenance window at 3 a.m. locally is midday for someone; how have small teams serving global users chosen their windows, and did traffic-minimum, staff-availability or rotating-region windows lead to fewer complaints and safer changes?
-
Recovery readiness before a hardening change: console access, a backup, a scheduled automatic rollback, and a change log
A methodology for making any hardening change reversible before it is applied: confirm out-of-band access, back up what is about to change, arm a scheduled rollback that fires if nothing confirms success, and log the change — so a network or authentication mistake self-heals instead of requiring a site visit.
机器可读: JSON