Di chuyển VPS sang nhà cung cấp mới mà không gây downtime

Ba chiếc đồng hồ, và vì sao “zero downtime” là mục tiêu sai#

Nhà cung cấp cũ giữ lại những gì sau khi bạn rời đi#

Đồng hồ TTL bắt đầu chạy từ một tuần trước khi di chuyển#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

Chọn cấu hình cho máy mới, và những gì cần kiểm tra trước khi chốt#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

Từng bước một#

1. Hạ mọi TTL, nhiều ngày trước khi bạn định di chuyển

   Đây là bước đầu tiên vì nó là bước duy nhất có một khoảng thời gian chờ bắt buộc. Mọi thứ khác đều có thể làm xong trong một buổi chiều; riêng bước này thì không thể hối cho nhanh được, và bỏ qua nó chính là thứ biến một cuộc chuyển đổi năm phút thành một cuộc chuyển đổi hai ngày.

   Hãy đăng nhập vào nơi zone của bạn đang sống và đặt TTL thành 300 trên mọi bản ghi sẽ thay đổi: bản ghi A gốc, AAAA, www, mail, và bất cứ thứ gì khác đang trỏ tới một địa chỉ IP literal. Sau đó xác nhận lại từ bên ngoài, vì control panel và thực tế đôi khi không khớp nhau:

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   Con số đứng trước IN chính là TTL còn lại. Hãy truy vấn lại một phút sau đó: nó phải đang đếm ngược từ 300, chứ không phải từ một con số lớn hơn. Nếu nó vẫn đang đếm ngược từ 3600, giá trị cũ đang bị cache và bạn phải chờ nó hết hạn — đây chính xác là lý do vì sao việc này nên xảy ra vào ngày trừ bảy chứ không phải vào sáng ngày di chuyển.

   Hãy giữ TTL ở mức 300 trong suốt cuộc di chuyển và trong một tuần sau đó, để rollback của bạn cũng nhanh theo. Đặt nó về lại một mức hợp lý — 3600 là ổn — một khi máy cũ đã không còn nữa.

2. Kiểm kê máy chủ cũ trước khi sao chép bất cứ thứ gì

   Bạn không di chuyển một ổ đĩa, bạn đang di chuyển một hệ thống đang chạy sống, và những phần người ta hay quên không bao giờ nằm trong /var/www. Đó là cron job chạy vào ngày mùng bốn hàng tháng, quy tắc firewall được thêm vào trong lúc xử lý một sự cố, gói phần mềm được cài từ một repository bên thứ ba hai năm trước. Hãy chụp lại trạng thái của máy dưới dạng văn bản, rồi sao chép văn bản đó sang cùng mọi thứ khác:

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   Giờ hãy đọc listening.txt từng dòng một và giải trình cho mọi cổng. Tệp đó là câu trả lời dứt khoát cho câu hỏi “máy chủ này thực sự đang làm gì”, và câu trả lời đó thường xuyên gây bất ngờ — một metrics exporter, một bản staging bị bỏ quên, một cơ sở dữ liệu đang lắng nghe trên một giao diện công khai mà lẽ ra không bao giờ nên như vậy.

   Hãy viết danh sách loại trừ của bạn cùng lúc, để lượt đồng bộ đầu tiên không tốn cả giờ đồng hồ vào dữ liệu bạn không cần:

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   Lưu ý rằng các thư mục cơ sở dữ liệu bị loại trừ một cách có chủ đích. Chúng có bước riêng của mình, và sao chép chúng ở đây chính là sai lầm mà bước sáu tồn tại để ngăn chặn.

3. Triển khai máy chủ mới và tăng cường bảo mật cho nó trước khi nó chứa bất cứ thứ gì

   Đặt mua máy, chọn vị trí và nếu có thể hãy chọn đúng phiên bản hệ điều hành chính giống máy cũ. Vừa đổi nhà cung cấp vừa đổi từ Debian 12 sang Debian 13 trong cùng một thao tác nghĩa là khi có gì đó hỏng, bạn sẽ không biết thay đổi nào gây ra nó. Hãy di chuyển trước, nâng cấp sau.

   Trước khi bất cứ thứ gì nhạy cảm đặt chân lên nó, hãy cho máy trải qua lượt tăng cường bảo mật mười phút: SSH chỉ dùng khóa, tắt đăng nhập root, firewall mặc định chặn tất cả, tự động cập nhật bảo mật. Việc đó chỉ tốn mười phút ngay bây giờ, còn nếu để sau mới lắp vào một dịch vụ đang sống thì thực sự rất phiền toái.

   Sau đó, hãy tạo một khóa chỉ tồn tại cho riêng cuộc di chuyển này, trên máy chủ cũ, để việc thu hồi quyền truy cập di chuyển sau này không bao giờ đồng nghĩa với việc phải đụng vào tài khoản đăng nhập của chính bạn:

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   Đặt khóa công khai đó vào /root/.ssh/authorized_keys trên máy chủ mới, rồi xác nhận chiều di chuyển — cũ đẩy sang mới, để thông tin xác thực đó sống trên chiếc máy bạn sắp rời bỏ và chết theo cùng nó:

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   Cuối cùng, hãy đặt IP mới vào /etc/hosts của máy chủ cũ dưới một cái tên như newbox. Mọi lệnh tiếp theo sau đó sẽ ngắn gọn hơn, và hữu ích hơn nữa là khó trỏ nhầm vào sai máy lúc một giờ sáng.

4. Kiểm tra IP mới trước khi giao phó bất cứ thứ gì cho nó

   Giờ bạn đã có một địa chỉ chưa từng ai dùng cho dịch vụ của bạn trước đây, và đây là thời điểm cuối cùng mà việc phát hiện ra vấn đề với nó vẫn còn miễn phí. Ba lượt kiểm tra, năm phút:

   Blocklist. Hãy chạy địa chỉ đó qua các lượt kiểm tra đa-RBL — quy trình đầy đủ và cách đọc kết quả ở đây. Một lượt dính trên một danh sách chính sách như Spamhaus PBL là bình thường đối với một IP trung tâm dữ liệu và gần như không có ý nghĩa gì với traffic web. Một lượt dính trên SBL hoặc XBL mới là thật sự nghiêm trọng, và thời điểm để xử lý nó là ngay bây giờ, chứ không phải sau khi người dùng của bạn đã chuyển sang đó.

   Reverse DNS. Hãy kiểm tra xem địa chỉ đó hôm nay trả lời bằng gì:

   dig +short -x NEW_IP

   Nếu máy sẽ gửi mail, hãy yêu cầu bản ghi PTR bạn muốn và đảm bảo nó khớp với một hostname mà bản ghi A của hostname đó lại trỏ ngược về đúng IP này. Forward và reverse phải khớp nhau; một sự lệch pha còn tệ hơn cả một cái tên chung chung.

   Khả năng kết nối và tuyến đường. Hãy xác nhận các cổng bạn cần thực sự đang mở xuyên suốt từ đầu tới cuối, từ bên ngoài, thay vì mặc định cho rằng firewall của bạn là thứ duy nhất nằm trên đường đi:

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   Kết quả mtr là thứ đáng để giữ lại. Mất gói ở chặng cuối cùng mới quan trọng; mất gói ở một chặng trung gian thường chỉ là do một router hạ mức ưu tiên của ICMP và không có ý nghĩa gì cả. Nếu độ trễ từ khu vực người dùng của bạn tệ hơn đáng kể so với nhà cung cấp cũ, tốt hơn hết nên phát hiện ra điều đó ngay bây giờ, khi đổi ý vẫn chỉ tốn đúng một đơn hàng và không mất dữ liệu nào.

5. Sao chép hệ thống tệp bằng rsync — và chạy dry-run trước

   Giờ là lượt truyền tải khối lượng lớn. Hãy làm việc đó theo hai lượt: một bản sao chép đầy đủ đầu tiên vài ngày trước, mất bao lâu cũng được, rồi tới các lượt delta ngắn sau đó chỉ chuyển những gì đã thay đổi. Luôn dry-run trước — kết quả in ra là một danh sách chính xác những gì sắp xảy ra, và chỉ cần đọc nó một lần đã cứu được nhiều cuộc di chuyển hơn bất kỳ thói quen nào khác ở đây.

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   Sau đó chạy đúng lệnh đó nhưng bỏ --dry-run. Lặp lại việc này cho từng thư mục quan trọng: /etc một cách chọn lọc chứ không phải toàn bộ, /home, /srv, /opt, và bất cứ nơi nào ứng dụng của bạn thực sự lưu các tệp tải lên.

   Các flag này đều xứng đáng có mặt. -a giữ nguyên quyền, chủ sở hữu, timestamp và symlink; -H giữ lại hard link; -A và -X mang theo ACL và extended attribute, đúng thứ thư mục uploads của bạn cần nếu có ai từng đặt chúng; -x ngăn rsync đi lạc sang các filesystem khác đã được mount. --numeric-ids là cái mà người ta hay bỏ sót và sau đó phải hối tiếc: nếu thiếu nó, rsync ánh xạ quyền sở hữu theo tên, và nếu www-data có UID khác nhau trên hai máy, mọi tệp sẽ đến nơi với chủ sở hữu sai theo một cách rất phiền phức để gỡ ra sau đó.

   Hai lời cảnh báo. Sao chép toàn bộ /etc lên một hệ thống đang chạy sẽ ghi đè cấu hình mạng, fstab và các SSH host key của máy mới — chỉ sao chép đúng phần cấu hình bạn cần, không phải cả thư mục. Và chỉ dùng --delete cho lượt cuối cùng mà thôi: nó đúng đắn khi cần làm cho máy mới khớp chính xác với máy cũ, nhưng lại có tính phá hủy nếu bạn đã tạo sẵn thứ gì đó ở phía đích.

   Khi lượt đầy đủ đầu tiên hoàn tất, hãy so sánh hai phía để biết chắc nó đã làm đúng như bạn nghĩ:

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. Di chuyển cơ sở dữ liệu bằng một bản dump, không bao giờ bằng sao chép tệp trực tiếp

   Đây là bước quyết định xem cuộc di chuyển của bạn sẽ nhàm chán hay đáng nhớ. Thư mục dữ liệu của một cơ sở dữ liệu chỉ nhất quán khi máy chủ đã dừng. Sao chép nó khi đang chạy sống và bạn sẽ có được một tập tệp trông có vẻ ổn, truyền tải cũng ổn, nhưng khi khôi phục lại thành một cơ sở dữ liệu hỏng một cách âm thầm và vĩnh viễn — thường không hề báo lỗi cho tới nhiều tuần sau đó.

   Hãy dump nó cho đúng cách. Với MySQL hoặc MariaDB, --single-transaction chính là thứ cho bạn một bản chụp nhất quán mà không phải khóa toàn bộ:

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   Với PostgreSQL, định dạng tùy chỉnh (custom format) rất đáng dùng — nó nén được, và cho phép bạn khôi phục chọn lọc nếu cần:

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   Chuyển nó sang máy mới và khôi phục:

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   Sau đó hãy xác minh, vì “khôi phục xong” và “dữ liệu đã có ở đó” là hai khẳng định khác nhau. Hãy so sánh số dòng trên các bảng quan trọng, ở cả hai phía:

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   Có hai thứ hay ẩn mình trong các bản dump: bộ ký tự và collation, đây chính là nguồn gốc của các ký tự có dấu bị lỗi phông — nếu cơ sở dữ liệu cũ đang dùng utf8 thay vì utf8mb4, hãy chủ động quyết định xem liệu cuộc di chuyển này có phải cũng là thời điểm để sửa luôn điều đó không; và người dùng cùng quyền hạn của cơ sở dữ liệu, thứ mà mysqldump --databases không hề bao gồm. Hãy tạo lại tường minh user và mật khẩu của ứng dụng trên máy mới, rồi nhớ rằng chuỗi kết nối trong cấu hình của bạn cũng cần phải khớp theo.

   Nếu ứng dụng của bạn dùng SQLite, tệp đó chính là cơ sở dữ liệu và quy tắc tương tự vẫn áp dụng — đừng sao chép nó khi đang chạy sống. Hãy dùng sqlite3 app.db ".backup /root/mig/app.db", lệnh này lấy một bản sao nhất quán một cách an toàn.

7. Khởi động stack và diễn tập nó phía sau một override bằng tệp hosts

   Máy chủ mới giờ đã có đủ tệp và dữ liệu. Hãy khởi động mọi thứ và kiểm thử nó dưới đúng hostname thật — trong khi phần còn lại của thế giới vẫn đang vui vẻ dùng máy cũ. Đây là mẹo giá trị nhất trong toàn bộ quy trình này và nó chỉ tốn đúng một dòng.

   Trên laptop của chính bạn, hãy thêm IP của máy chủ mới vào /etc/hosts (hoặc C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10   example.com www.example.com

   Trình duyệt của bạn giờ sẽ phân giải tên miền thật về máy chủ mới, còn của tất cả những người khác thì không. Mọi URL đều đúng, mọi cookie domain đều khớp, mọi đường dẫn redirect và callback đều hoạt động đúng như cách chúng sẽ hoạt động sau khi chuyển đổi — đây chính xác là điều mà việc kiểm thử trên một subdomain tạm như new.example.com không thể bắt được, vì phân nửa những gì hay hỏng trong một cuộc di chuyển đều phụ thuộc vào hostname.

   Để kiểm tra nhanh một lượt duy nhất mà không cần sửa gì cả, curl có thể làm y hệt việc đó ngay trên dòng lệnh:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   Hãy đi qua toàn bộ ứng dụng, không chỉ trang chủ: đăng nhập, gửi một biểu mẫu, tải lên một tệp, kích hoạt một mail reset mật khẩu, mở một trang admin, gọi tới endpoint mà một bên xử lý thanh toán vẫn gọi. Sau đó hãy đọc error log kể cả khi mọi thứ trông có vẻ ổn — các PHP extension bị thiếu, một file mode sai trên một thư mục cache, và một user cơ sở dữ liệu chưa tồn tại, tất cả đều hiện ra ở đó trước khi chúng hiện ra trên màn hình.

   Nhớ xóa dòng hosts đó đi sau khi xong việc. Ai cũng từng quên ít nhất một lần, rồi mất hai mươi phút tự hỏi vì sao rollback có vẻ như không hoạt động.

8. Đưa TLS vào hoạt động trên máy mới trước khi đổi bất cứ thứ gì

   Chứng chỉ gắn với tên miền, không gắn với địa chỉ IP, nên không có gì trong một cuộc di chuyển làm mất hiệu lực một chứng chỉ bạn đã có sẵn. Thứ bị hỏng là việc cấp mới: thử thách HTTP-01 thông thường yêu cầu Let's Encrypt lấy về một tệp qua cổng 80 tại đúng tên miền đang được chứng thực, mà tên miền đó vẫn đang trỏ vào máy chủ cũ. Bài toán con gà quả trứng đó chính là toàn bộ cái khó, và có ba lối ra sạch sẽ.

   Sao chép các chứng chỉ hiện có. Đơn giản nhất và thường là đúng đắn nhất. Khóa riêng tư và chuỗi chứng chỉ di chuyển như bất kỳ tệp nào khác:

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   Máy chủ mới có thể phục vụ TLS hợp lệ ngay lập tức, và việc gia hạn tự động hoạt động trở lại ngay khi DNS trỏ về nó. Hãy xác nhận timer đã được bật ở đó: systemctl list-timers | grep certbot.

   Dùng một thử thách DNS-01. Chứng minh quyền kiểm soát tên miền thông qua một bản ghi TXT thay vì một request HTTP, nên nó hoạt động được ngay cả từ một máy chủ mà chưa có gì trỏ tới cả. Lý tưởng nếu bạn muốn có một chứng chỉ thực sự độc lập trên máy mới trước khi chuyển đổi, và là lựa chọn duy nhất cho một wildcard.

   Cấp sau khi đổi bản ghi. Vẫn hợp lệ, nhưng nó để lại một khoảng trống nơi trang web đã sống trên IP mới mà chưa có chứng chỉ, và với bất cứ thứ gì dùng HSTS thì đó không phải một cảnh báo mà khách truy cập có thể click bỏ qua được. Chỉ hợp lý cho một tên miền hoàn toàn mới mà chưa ai từng ghé thăm.

   Dù bạn chọn cách nào, hãy xác minh trực tiếp trên IP mới trước khi chuyển đổi, dùng đúng mẹo --resolve như trên:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   Hãy kiểm tra ngày hết hạn và đảm bảo subject bao phủ mọi tên miền bạn phục vụ, kể cả www. Và nếu bạn dùng HSTS với một max-age dài, hãy coi chứng chỉ là thứ duy nhất bắt buộc phải đúng trước khi đổi bản ghi chứ không phải sau đó — header đó là một lời hứa bạn đã đưa ra từ trước với mọi khách truy cập quay lại.

9. Chuyển đổi: đóng băng ghi, đồng bộ delta cuối, đổi bản ghi

   Mười phút làm việc thực sự, và là phần duy nhất có đồng hồ đếm. Hãy làm việc này vào buổi sáng, theo múi giờ của chính bạn, vào một ngày bạn không bận việc gì khác. Không bao giờ vào thứ Sáu.

   Đóng băng. Đưa ứng dụng cũ vào chế độ bảo trì hoặc chỉ đọc. Dừng các worker, các consumer của hàng đợi và các cron job — bất cứ thứ gì ghi dữ liệu mà không cần trình duyệt gắn kèm. Từ đây trở đi, không có gì mới được ghi trên máy cũ nữa, và đó chính là điều khiến mọi thứ sau bước này an toàn:

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   Delta cuối cùng. Thêm một lượt rsync nữa, lần này có --delete để phía đích khớp chính xác, và thêm một lượt dump nữa. Vì lượt đầu tiên đã hoàn tất từ nhiều ngày trước, lượt này chỉ chuyển rất ít và mất vài giây:

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   Kiểm tra. So sánh số dòng ở cả hai phía, chạy thêm một lượt qua toàn bộ ứng dụng thông qua override bằng tệp hosts, rồi gỡ maintenance flag khỏi máy mới.

   Đổi bản ghi. Đổi bản ghi A sang IP mới. Đổi cả bản ghi AAAA nữa — đây là cách phổ biến nhất khiến một cuộc chuyển đổi chỉ thành công có nửa vời. Xác nhận từ một resolver mà bạn không kiểm soát:

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   Sau đó theo dõi cả hai máy. Traffic sẽ xuất hiện trên máy mới trong vòng một hai phút và nhạt dần khỏi máy cũ trong năm phút tiếp theo:

   tail -f /var/log/nginx/access.log        # on both, side by side

   Hãy để ứng dụng cũ ở chế độ bảo trì thay vì tắt hẳn nó đi. Một vị khách đến muộn chạm phải nó sẽ thấy một trang thông báo lịch sự thay vì một lỗi kết nối, và bạn vẫn giữ được máy đó sẵn sàng cho lượt rollback mà có lẽ bạn sẽ không cần dùng tới.

10. Theo dõi trong một tuần, rồi ngừng sử dụng đúng cách

    Cuộc di chuyển chưa hoàn tất khi DNS đã phân giải xong. Nó chỉ thực sự hoàn tất khi trọn một chu kỳ thanh toán và cron trôi qua mà không có bất ngờ nào.

    Trong vài giờ đầu, hãy theo dõi tỷ lệ lỗi thay vì uptime — một máy chủ hoàn toàn có thể đang “up” mà vẫn trả về lỗi 500 cho một phần ba số request:

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    Sau đó hãy rà qua một danh sách ngắn, vì đây mới là những thứ thực sự hay hỏng sau một cuộc di chuyển và không thứ nào trong số đó tự lên tiếng báo trước: các cron job và systemd timer đang chạy trên máy mới (systemctl list-timers đối chiếu với bản kiểm kê bạn đã lấy ở bước hai); mail gửi đi có đến nơi và không rơi vào spam; các bản sao lưu theo lịch có đang trỏ vào máy chủ mới thay vì vẫn lưu trữ máy cũ; bất kỳ bên thứ ba nào có địa chỉ IP của bạn trong một allowlist — một bên xử lý thanh toán, một API, firewall của một đối tác; và job hàng tháng chỉ tự chứng minh vào ngày mùng một.

    Hãy để máy chủ cũ tiếp tục chạy, ở chế độ bảo trì, không động vào, trong ít nhất một tuần. Đó là rollback và bản sao tham chiếu của bạn, và nó đáng giá hơn nhiều so với vài đô la phải trả cho nó. Sau đó hãy đóng nó lại theo đúng thứ tự: xoay vòng mọi bí mật mà nó từng có thể đọc được, lấy một bản lưu trữ đã mã hóa cuối cùng gửi tới một nơi thứ ba, ghi đè lên các thư mục ứng dụng và cơ sở dữ liệu, chạy quy trình hủy hoặc cài lại của nhà cung cấp, và chỉ khi đó mới hủy — sau khi đã kiểm tra ngày gia hạn, vì thêm một tháng bảo hiểm rollback thường là một cuộc đổi chác khôn ngoan hơn.

    Cuối cùng, hãy đặt TTL trở lại mức 3600 giờ khi bạn không còn cần khả năng đảo ngược trong năm phút nữa, và cập nhật bất kỳ tài liệu nào bạn đang lưu giữ với địa chỉ mới. Bạn của tương lai, vào một lúc 2 giờ sáng nào đó sau này, sẽ cực kỳ biết ơn vì runbook khớp đúng với máy chủ thật.

Mail không di chuyển theo cùng phần còn lại#

Rollback mà không khiến mọi thứ tệ hơn#

Ngừng sử dụng: xoay vòng, xóa sạch, xác minh, rồi hủy#

Một dòng thời gian thực sự hiệu quả#

Câu hỏi thường gặp#