Maintainability — vận hành, đơn giản, tiến hoá

TL;DR: Phần lớn chi phí của một hệ dữ liệu không nằm ở lúc viết mà ở những năm bảo trì sau đó — sửa lỗi, vận hành, thêm tính năng, thích ứng yêu cầu mới. Maintainability đo mức "dễ sống chung" qua ba mặt: operability (đội vận hành làm việc dễ), simplicity (giảm phức tạp thừa để người mới hiểu hệ), và evolvability (đổi hệ mà không đập đi làm lại). Ba mặt là thước đo "mềm" — không có p99 để đo — nhưng quyết định hệ sống được bao lâu. Ở phần cuối bài, ta mổ cơ chế giúp evolvability chạy được trong hệ phân tán: schema evolution — thêm/đổi dữ liệu bằng số hiệu field sao cho node cũ và mới đọc được của nhau ngay giữa lúc rollout.

Reliability và scalability đo được bằng số. Maintainability thì không — nhưng nó quyết định hệ của bạn năm năm nữa còn dễ sửa hay đã thành "đống không ai dám đụng". Một hệ nhanh và tin cậy nhưng không ai hiểu nổi để thay đổi là một khoản nợ đang lớn dần.

Bài này khép lại bộ bốn thước đo: sau khi biết đo hệ chạy tốt tới đâu (reliability, scalability, tail latency), giờ hỏi sống với nó dễ tới đâu — và bạn sẽ tự chấm một hệ ở cuối bài.

1. Analogy — căn nhà dễ ở và dễ sửa

Hai căn nhà cùng đẹp lúc mới xây. Căn A: đường ống giấu sau tường liền, muốn sửa vòi phải đục tường; bảng điện không nhãn; mở rộng phải phá móng. Căn B: ống nước có cửa thăm, bảng điện dán nhãn từng cầu dao, chừa sẵn chỗ nối thêm phòng. Cả hai "chạy được" ngày đầu — nhưng qua mười năm sống và sửa, căn B rẻ hơn nhiều. Maintainability là thiết kế cho mười năm sau, không chỉ ngày bàn giao.

2. Operability — làm việc vận hành dễ

Operability là mức dễ dàng để đội vận hành giữ hệ chạy trơn: giám sát sức khoẻ, triển khai bản mới, chẩn đoán khi sự cố, làm việc lặp thành tự động. Một hệ operability tốt cho người vận hành nhìn thấy điều đang xảy ra (metric, log, trace — gồm cả p99 end-to-end ở bài trước) và tác động an toàn (rollback dễ, thao tác nguy hiểm khó gõ nhầm).

Đây là chỗ nối thẳng về bài reliability: fault con người là nguồn sự cố lớn nhất, và operability tốt chính là cách giảm nó — không phải bằng "bảo nhau cẩn thận" mà bằng công cụ khiến làm đúng thì dễ, làm sai thì khó (xác nhận trước lệnh xoá, deploy từng phần, tự động phát hiện bất thường).

3. Simplicity — phức tạp nào nên cắt, phức tạp nào phải giữ?

Có hai loại phức tạp. Essential — vốn thuộc bài toán (một hệ phân tán bản chất phải xử lý node chết, mạng trễ; không bỏ được). Accidental — sinh ra từ cách ta làm, không từ bài toán: trừu tượng rối, state rải khắp nơi, đặc biệt hoá lung tung, ghép nối chằng chịt.

Simplicity là cắt phần accidental để người mới đọc hiểu được hệ. Công cụ chính là abstraction tốt: giấu chi tiết thừa sau một giao diện sạch (như cách SQL giấu chi tiết storage engine). Lưu ý simplicity không phải "ít tính năng" — mà là "phức tạp không bị nhân lên vô cớ".

Nối về bài scalability: scale-out đổi lấy throughput bằng phức tạp phân tán — phần đó là essential (không tránh được nếu cần nhiều máy). Việc của simplicity là đừng chồng thêm phức tạp accidental lên trên nó, kẻo hệ thành bất khả bảo trì.

4. Evolvability — thiết kế cho cái sẽ thay đổi

Yêu cầu luôn đổi: tính năng mới, quy mô mới, luật mới. Evolvability (còn gọi extensibility, modifiability) là mức dễ để thay đổi hệ khi điều đó xảy ra. Nó không phải một kỹ thuật đơn lẻ mà là hệ quả của hai mặt kia cộng thiết kế có ranh giới: module tách bạch, hợp đồng rõ ràng giữa các phần, và dữ liệu tiến hoá được — thêm/đổi field mà không phá dữ liệu cũ hay client cũ.

Ở hệ phân tán, evolvability đặc biệt khó vì không thể nâng cấp mọi node cùng lúc: trong lúc rollout, phiên bản cũ và mới cùng chạy và phải hiểu dữ liệu của nhau. Nói cách khác, hệ cần hai chiều tương thích:

• Tương thích ngược (backward): code mới đọc được dữ liệu cũ. Thường dễ — bản mới biết mọi field cũ.
• Tương thích xuôi (forward): code cũ đọc được dữ liệu mới. Khó hơn — bản cũ phải bỏ qua thứ nó chưa biết.

flowchart LR
  NEW["Node MOI<br/>ghi record v2"] -->|"forward: node cu doc duoc?"| OLD["Node CU<br/>chi biet v1"]
  OLD -->|"backward: node moi doc duoc?"| NEW

Vậy cơ chế nào cho hai chiều tương thích đó chạy được? Đó là nội dung mục sau — phần "đào sâu" thực sự của bài.

5. Cơ chế bên dưới — schema evolution giữ tương thích thế nào

Câu hỏi cụ thể: làm sao thêm một field vào dữ liệu mà không phá node cũ đang chạy song song? Một cách phổ biến — dùng trong Protocol Buffers và Thrift — là định danh field bằng SỐ HIỆU (tag number), không bằng tên hay vị trí. (Avro đạt tương thích bằng cơ chế khác: khớp schema bên đọc với schema bên ghi theo tên field. Ở đây ta lấy mô hình số hiệu làm ví dụ vì nó trực quan nhất.)

Mỗi field trong record có một số hiệu cố định. Khi đọc, bộ giải mã dò theo số hiệu, không theo thứ tự xuất hiện:

// v1 record (node cu ghi ra)
1: user_id = 42
2: name    = "An"

// v2 record (node moi ghi ra) — them field, so hieu MOI
1: user_id = 42
2: name    = "An"
3: email   = "[email protected]"   // tag 3, danh dau optional

Hai chiều tương thích rơi ra tự nhiên từ quy tắc này:

• Forward (node cũ đọc record v2): node cũ chỉ biết tag 1 và 2. Gặp tag 3 lạ, nó bỏ qua (skip) đoạn byte đó và đọc tiếp — không crash, chỉ không dùng email.
• Backward (node mới đọc record v1): node mới tìm tag 3 nhưng record cũ không có → dùng giá trị mặc định (rỗng) cho email. Vẫn chạy.

Điều kiện để cơ chế này đứng vững, gói trong ba luật:

1. Thêm field → phải gán số hiệu MỚI và để optional (hoặc có default). Không tái dùng số hiệu đã bỏ.
2. Không đổi số hiệu của field đang tồn tại.
3. Không siết một field vốn có thể vắng thành bắt buộc (node cũ có thể ghi record không có field đó).

Lần theo cơ chế: node cũ dò tìm tag 2 để lấy name — record v2 giờ không còn tag 2 (đã thành 5) → node cũ coi như name thiếu, dùng default (rỗng). Đồng thời nó gặp tag 5 lạ → bỏ qua. Kết quả: name biến mất với mọi node cũ, dù chuỗi ký tự "An" vẫn nằm nguyên trong record. Đây chính là lý do luật 2 tồn tại: số hiệu là "danh tính" của field trong hệ phân tán — đổi nó là đổi danh tính, không phải đổi nhãn. Một thao tác nhìn như vô hại (đổi số cho gọn) đủ làm rơi dữ liệu âm thầm giữa lúc rollout.

Đây là mặt "cơ chế" của evolvability: ranh giới module và hợp đồng rõ ràng cho code, còn schema evolution là hợp đồng rõ ràng cho dữ liệu — thứ giữ cho một hệ phân tán đổi được mà không cần dừng toàn bộ để nâng cấp đồng loạt.

6. Pitfall — tối ưu cái đo được, bỏ cái không đo được

❌ "He nhanh + tin cay la du" -> bo qua log/metric, abstraction roi, khong ai
   dam sua -> moi thay doi nho ton hang tuan + de gay su co (fault con nguoi)

❌ Nham simplicity = it tinh nang -> cat tinh nang can (essential complexity)
   thay vi cat phuc tap thua (accidental)

❌ Doi so hieu / bo required field khi len version moi -> node cu roi du lieu
   giua luc rollout (vi pham luat schema evolution)

7. Tự đánh giá — đến lượt bạn

Bạn đã có đủ khung. Trước khi xem gợi ý chấm, hãy tự phân tích tình huống sau qua ba mặt và tự quyết mặt nào cần vá trước — viết ra (trong đầu hoặc ra giấy) rồi mới mở đáp án.

Hệ đặt vé của một team nhỏ. Deploy thủ công mất 2 tiếng mỗi lần, không có rollback tự động, và ba tháng qua có hai sự cố do gõ nhầm lệnh lúc deploy đêm. Code khá gọn, ít abstraction thừa. Nhưng mỗi lần thêm một loại vé mới phải sửa 6 chỗ rải rác. Team muốn thêm field seat_class vào record vé, lo app mobile bản cũ (đang chạy trên máy người dùng) sẽ crash khi nhận dữ liệu mới.

8. 📚 Đào sâu — nguồn gốc & tài liệu

9. Liên hệ các bài khác

• Bài 01 — Reliability: operability tốt là cách chính giảm fault con người — nguồn sự cố lớn nhất; maintainability và reliability củng cố nhau.
• Bài 02 — Scalability: scale-out thêm phức tạp essential; simplicity giữ cho ta không chồng thêm phức tạp accidental lên đó.
• Bài 03 — Tail latency: quan sát được p99 end-to-end là một phần cụ thể của operability — không đo được thì không vận hành được.
• Module 2 — Nhân bản: với bốn thước đo trong tay, module sau bắt đầu phân tán thật — replication đánh đổi giữa reliability, scalability và độ phức tạp; và cùng dữ liệu trên nhiều node làm schema evolution càng thiết yếu.

10. Tóm tắt

• Phần lớn chi phí hệ nằm ở bảo trì (nhiều năm), không ở lúc viết — maintainability đáng đầu tư từ đầu.
• Operability: đội vận hành nhìn thấy (metric/log/trace) và tác động an toàn (rollback, thao tác khó gõ nhầm) — trực tiếp giảm fault con người.
• Simplicity: cắt phức tạp accidental (do cách làm) chứ không phải essential (bản chất bài toán); công cụ chính là abstraction tốt. Không đồng nghĩa "ít tính năng".
• Evolvability cần hai chiều tương thích (xuôi/ngược) vì cũ/mới cùng chạy lúc rollout.
• Cơ chế schema evolution: định danh field bằng số hiệu; thêm field optional → node cũ bỏ qua tag lạ (forward), node mới dùng default cho field thiếu (backward). Ba luật: gán số mới, không đổi số cũ, không biến optional thành required.
• Ba mặt là thước đo "mềm" (không có p99) nhưng quyết định hệ sống được bao lâu. Anti-pattern: dồn sức vào cái đo được, để maintainability thành nợ ẩn.

11. Tự kiểm tra

Bài tiếp theo: Module 1 — Tổng kết & cheat sheet