Nay cuối tuần đàm đạo chút về vấn đề Debt (nợ). Tết nhất đến nơi… Đi đâu cũng thấy tuần này là tuần để ra tết rồi làm.
Anh em hay nghe nói code nợ kỹ thuật, refactor không kịp là toang. Với một chút góc nhìn đã từng là Dev sang Sysadm rồi DevOps mình thấy là code debt nhiều khi còn dễ trả. Cái khó trả hơn khả năng lại là infrastructure debt vì nó ăn vào network, data, security, vận hành,… Và tới lúc vấn đề thì thường là ảnh hưởng đến cả công ty.
Code sai có thể rollback, patch, hotfix. Hạ tầng sai, đặc biệt là những thứ nền móng, thì nhiều khi chỉ có 2 đường:
- Sống chung với lũ và nỗi đau kéo dài
- Hoặc migrate, mà migrate là đốt tiền để mua lại sự bình thường
Mình chia sẻ góc nhìn qua vài cái use case để trà đá, chém gió và học hỏi với các bác…
1. Chọn sai CIDR cho VPC là món nợ cực khó trả nhưng không phải lúc nào cũng nghiêm trọng
Rất nhiều người chọn CIDR theo kiểu chắc đủ rồi triển: 10.0.0.0/16, chia subnet cho vui, xong vài năm sau công ty phình ra, peering transit VPN chằng chịt, IP bắt đầu thiếu, hoặc tệ hơn là đụng overlap với mạng khác.
Điểm quan trọng cần nhớ:
- Primary CIDR của VPC đã chọn là gần như không đổi lại cho đẹp được
- Nhiều trường hợp có thể cứu bằng cách gắn thêm secondary CIDR rồi tạo subnet mới trong dải mới
- Nhưng nếu kiến trúc subnet, routing, IPAM, overlap, hoặc kết nối cross network bị vỡ cấu trúc, thì cứu thành vá, và đôi khi vẫn phải dựng VPC mới rồi migrate cho sạch
Chọn sai CIDR không phải lúc nào cũng hỏng ngay, nhưng nó là món nợ cực khó trả. May thì mở rộng được, xui thì migrate 😀
2. Chọn sai Primary Key với DynamoDB hoặc Cassandra thì càng để lâu càng trả giá
Có những quyết định design nghe rất nhỏ mà hại hệ thống từ từ, trong đó nổi bật là partition key hoặc primary key.
Sai kiểu gì?
- Key không phân tán workload dẫn tới hot partition
- Access pattern thay đổi làm query tự hành xác
- Scale lên chỉ thấy bill tăng, performance không tăng tương ứng
Vấn đề ở đây là nhiều hệ NoSQL không cho bạn đổi key một cách tử tế sau khi đã có data.
Thực tế xử lý thường là:
- Thiết kế lại table hoặc data model
- Tạo bảng mới
- Dual write, backfill, cutover
- Và cầu cho đừng phát sinh edge case
Nói thẳng cho dễ hiểu mức độ sai key không phải không sửa được, nhưng sửa nó thường là làm lại bảng chứ không phải refactor nhẹ.
3. Terraform và IaC không phải cứ đụng là xóa tạo mới, nhưng nó phũ ở chỗ làm đúng y như plan
Có một hiểu lầm phổ biến: terraform chỉ giỏi tạo mới, sửa là hay thay thế resource. Chưa chuẩn.
Terraform làm được cả create lẫn update, nhưng:
- Có những thuộc tính provider đánh dấu immutable, đụng vào là replacement
- Trong plan sẽ hiện kiểu -/+ hoặc forces replacement
- Và nếu anh em apply mà không hiểu, production có thể bay rất hợp lý theo đúng plan
Nói cách khác: Terraform không ngu. Nó chỉ làm đúng những gì anh em bảo nó làm.
Bài học ở đây là:
- Đọc plan là kỹ năng sống còn
- Thấy -/+ trên resource critical là phải dừng, đọc, và thiết kế đường đi an toàn
- Đặt guardrail như prevent_destroy, deletion protection, approval cho change nguy hiểm
- Thiết kế rollout hoặc migration thay vì đập đi xây lại trong một lần apply
Terraform không làm hỏng prod. Người không đọc plan làm hỏng prod.
4. Restore vài TB dữ liệu có thể mất nhiều giờ và đó là lý do incident DB luôn đắt
Anh em có thể từng nghe con số kiểu restore 2TB mất 4 đến 6 tiếng. Con số cụ thể thì tùy hệ, tùy engine, tùy IOPS và network, tùy snapshot hoặc backup.
Nhưng ý quan trọng là restore dữ liệu lớn có thể mất nhiều giờ, thậm chí hơn, và trong thời gian đó business có thể đứng hình.
Nên nếu anh em chưa từng làm restore drill nghiêm túc, thì lúc sự cố xảy ra mới thấy:
- RTO RPO trên slide không giống RTO RPO ngoài đời
- Backup có đó không có nghĩa restore chạy được
- Runbook có đó không có nghĩa team làm nổi lúc 3 giờ sáng
5. ClickOps làm hệ thống drift, nhưng IaC viết ẩu cũng y chang
Mình không ghét ClickOps theo kiểu bấm nút là mất chất DevOps. Mình ghét vì nó khiến hệ thống:
- Không trace được ai đổi cái gì
- Drift khỏi cấu hình chuẩn
- Audit vào đụng đâu vỡ đó
Nhưng nói cho công bằng: IaC viết ẩu vẫn tạo ra security group mở 0.0.0.0/0, IAM full admin, bucket public như thường. Gốc vấn đề không phải bấm hay không bấm, mà là:
- Governance
- Review
- Guardrails
- Ownership
ClickOps chỉ làm drift dễ hơn, nhanh hơn, khó kiểm soát hơn.
Infrastructure Debt là loại nợ trả bằng migration, không trả bằng refactor nhẹ
Cái đáng sợ của infra debt là nó không nổ ngay. Nó âm ỉ, vẫn chạy mà, cho tới khi…
- Scale lên
- Compliance audit vào
- Tích hợp nhiều hệ
- Hoặc dính incident lớn
Rồi lúc đó anh em mới thấy: trả bằng tiền, bằng thời gian, bằng niềm tin, và bằng giấc ngủ.
3 việc thực tế để giảm Infrastructure Debt
- Ghi quyết định nền móng bằng ADR: CIDR, data model, account boundary, networking, identity
- Bắt buộc review plan và change cho thứ có blast radius cao, đặc biệt thấy -/+ là phải dừng đọc
- Làm restore drill và game day định kỳ: backup DR không test thì chỉ là niềm tin
Trà đá tâm sự với mọi người một chút, còn trải nghiệm thực tế mỗi người mỗi khác. Và đa phần chúng ta cũng phải trải nghiệm qua nhiều vấn đề rồi mới đúc kết và có những góc nhìn đa chiều. Còn có những bác ngay từ đầu đã tránh được ngay thì thực sự quá tốt.
