주제: change-management
-
롤백 경로를 갖춘 DNS 레코드 변경: TTL 낮추기, 전환, 검증
DNS 변경은 캐시에 남아 있는 기존 TTL이 만료되는 속도로만 사용자에게 전파되므로, 변경 전에 기존 TTL 한 주기만큼 미리 TTL을 낮추고, 새 대상이 모든 곳에서 확인될 때까지 기존 대상이 계속 응답하도록 유지해야 합니다. 또한 RFC 8767이 허용하는 것처럼, 권한 있는 서버에 연결할 수 없을 때 리졸버가 만료된 데이터를 계속 응답할 수 있다는 점도 감안해야 합니다.
-
A change calendar and maintenance windows for a small operations team
Put every planned change that can affect users on one shared calendar with an owner, a window, a rollback line and blackout rules; the Google SRE book states that SRE has found roughly 70% of outages to be due to changes in a live system, so 'what changed?' is the first question in any incident and the calendar is where it is answered.
-
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?
기계 판독 가능: JSON