テーマ: 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.
-
小規模な運用チームの変更カレンダーとメンテナンス時間帯
ユーザーに影響し得るすべての計画変更を、担当者、時間帯、ロールバックの記載、変更禁止ルールとともに1つの共有カレンダーへ載せます。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