Có project bắt đầu từ một proposal, có project là một lần thay platform, một bài toán monitoring hay một migration. Mình giữ lại ở đây những case có đủ câu chuyện để nhìn lại: lúc đó bài toán là gì, team đã cân nhắc điều gì, khi triển khai kiểm tra ra sao và sau cùng còn điều gì đáng nhớ.
Project migration toàn bộ hệ thống SAP HANA từ On-Prem lên AWS, nhìn từ phía Infrastructure/Network: dependency, connectivity, security boundary, cutover và service validation.
Một bài toán tưởng như chỉ cần host vài file HTML, nhưng cuối cùng lại dẫn tới những quyết định về content ownership, deployment, private delivery, corporate identity và access control.
Bài toán ban đầu là di chuyển hạ tầng lên external Data Center. Sau khi xem kỹ workload, TCO, Proxmox/PBS, network, physical move và cách vận hành về sau, phương án cuối cùng lại khác với proposal ban đầu.
PA-3050 → PA-3410, Active/Active, AWS VPN ownership, GlobalProtect Pre-logon, UAT và rollback. Cặp firewall xanh chưa đồng nghĩa traffic phía sau đã chạy đúng.
Từ những dashboard có rất nhiều panel, mình dần chuyển sang các câu hỏi đơn giản hơn: alert này có cần hành động không, baseline bình thường là gì và khi có incident team mất bao lâu để hiểu chuyện gì đang xảy ra.
Góc nhìn Consultant cho team triển khai về Identity, pilot, coexistence mail flow, Drive/SharePoint mapping, user communication và 30 ngày đối chiếu sau Go-live.
Workload, dependency và traffic nào là phần không được phép mất khi thay đổi?
Rollback hoặc restore path có đủ rõ để team không phải nghĩ lại từ đầu trong maintenance window?
Device healthy là một tín hiệu; service phía sau có hoạt động đúng mới là phần cần xác nhận tiếp.
Monitoring, support, access và những việc Day-2 cần đủ rõ để thay đổi không kết thúc ngay khi đóng Change Request.
Lifecycle, high availability, migration và những việc cần chuẩn bị trước khi hệ thống thật sự gặp failure.
CPU/RAM còn dư nhưng EOS/EOL, spare part, supportability và đường recovery có thể đã trở thành bài toán khác.
Hai node chưa nói được nhiều nếu team chưa từng failover và kiểm tra service phía sau có tiếp tục chạy.
Dependency mapping, FDD, UAT, rollback và những việc cần xong trước maintenance window.
Backup success, restore test, rollback và runbook — những thứ chỉ biết đủ hay không khi thật sự phải phục hồi service.
WAN multi-site, secure access và cách kiểm tra traffic thật sau thay đổi.
Dual WAN, DMVPN, OSPF và lý do tunnel UP vẫn chưa nói được application có dùng được hay không.
Một engineer cần xem log, inspect container và restart service thì thực sự cần quyền gì — và quyền nào không cần cấp.
Dashboard, baseline, alert noise và cách đối chiếu khi Monitoring không khớp với thực tế.
Một lần Capacity Assessment dẫn tới câu hỏi: dashboard đang phản ánh hệ thống, hay chỉ phản ánh chính phép đo của mình?
Có những thay đổi chỉ cần một runbook tốt rồi khép lại. Những case ở đây là những chuyện mình thấy đáng ghi lại vì trong lúc làm đã có một quyết định, một tình huống hoặc một bài học mà sau này mình vẫn còn dùng lại.
Xem tất cả Engineering Notes →