Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại.

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 5 trong 7 của chương Tư duy như một kiến trúc sư dữ liệu, chương đầu tiên của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Kiến trúc là nghệ thuật đánh đổi · Tiếp theo: Hiểu công cụ của bạn: Chín câu hỏi

Câu hỏi mô-đun này trả lời: Làm sao thiết kế cho yêu cầu hôm nay mà vẫn lên kế hoạch cho tăng trưởng và cho thất bại?

Một trong những sai lầm dễ mắc nhất trong kiến trúc là chỉ thiết kế cho những yêu cầu đang nằm trước mặt. Chúng ta có một dự án, một backlog và các yêu cầu. Chúng ta xây một thứ đáp ứng chúng. Nó chạy, và chúng ta tuyên bố chiến thắng. Sáu tháng sau, việc kinh doanh thay đổi, hoặc dữ liệu tăng lên, hoặc một đơn vị kinh doanh khác muốn dùng nó, hoặc chúng ta mua lại một công ty, hoặc một hệ thống mới cần tích hợp, hoặc có thứ gì đó hỏng mà không ai lên kế hoạch.

Không điều nào trong số đó nên làm một kiến trúc sư bất ngờ. Chúng ta không thể đoán trước mọi chuyện sẽ xảy ra, nhưng chúng ta có thể thiết kế với nhận thức rằng sẽ có chuyện xảy ra. Đó là lý do tôi nhìn kiến trúc qua ba lăng kính:

Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại.

Bạn cần cả ba.

Click to enlarge

Xây cho hôm nay

Kiến trúc bắt đầu từ vấn đề chúng ta thực sự có. Nghe thì hiển nhiên, nhưng kiến trúc sư có thể mắc sai lầm ngược với tư duy ngắn hạn: chúng ta có thể thiết kế quá mức. Nếu chúng ta mua lại mười hai công ty, có một tỷ khách hàng, mở rộng ra 40 quốc gia, và mọi hệ thống cần tích hợp thời gian thực thì sao? Có thể. Nhưng đó là những khả năng thực sự, hay chúng ta đang tự bịa ra vấn đề? Kiến trúc không phải là xây hệ thống tinh vi nhất chúng ta có thể tưởng tượng. Mà là xây hệ thống phù hợp.

Vì vậy hãy bắt đầu từ hôm nay: việc kinh doanh cần gì, khối lượng, người dùng và giao dịch thực tế, dữ liệu thay đổi thường xuyên đến đâu và phải di chuyển nhanh đến mức nào, ai cần truy cập, và dữ liệu đến từ đâu và đi đâu. Và quan trọng nhất: tại sao? Những câu trả lời đó cho chúng ta một thứ cụ thể để thiết kế.

Tìm những yêu cầu ngầm định

Những yêu cầu bạn nhận được chưa chắc đã là tất cả yêu cầu bạn có. Gần như luôn có những yêu cầu ngầm định.

Phía nghiệp vụ nói: “Chúng tôi cần dữ liệu khách hàng trong Salesforce.” Được thôi. Vậy thì phải có ai đó sở hữu dữ liệu đó và quyết định nó phải mới đến mức nào. Chúng ta cần biết điều gì xảy ra khi hệ thống nguồn ngừng hoạt động, làm sao để nhận ra khi đồng bộ thất bại, và bên nào thắng khi Salesforce và nguồn không khớp. Chúng ta cần một thời hạn lưu giữ, một mô hình truy cập, một quyết định về các trường nhạy cảm và một cách để sửa dữ liệu sai.

Không điều nào trong số đó có trong user story. Tất cả vẫn là kiến trúc. Một phần lớn của việc trở thành kiến trúc sư là học cách nhận ra những câu hỏi chưa ai đặt ra.

Hãy biết các con số của bạn

Tôi liên tục thúc kiến trúc sư định lượng. Đừng nói với tôi là có nhiều dữ liệu; hãy nói bao nhiêu. Mười nghìn, mười triệu, một trăm triệu, một tỷ? Đó là những kiến trúc rất khác nhau. Đừng nói tích hợp chạy thường xuyên: mỗi giờ, mỗi phút, một nghìn lần mỗi giây? Đừng nói chúng ta đang tăng trưởng nhanh. Nhanh đến mức nào?

Khi không có con số nào tốt hơn, mức cơ sở của tôi là tăng trưởng 30 phần trăm mỗi năm. Đó không phải là một dự báo; đó là một cách buộc phải suy nghĩ. Nếu ai đó nói hôm nay chúng ta có 10 triệu bản ghi, tôi không muốn cuộc thảo luận dừng ở 10 triệu. Với 30 phần trăm mỗi năm, năm sau chúng ta có khoảng 13 triệu, năm sau nữa 17 triệu, và năm tiếp theo khoảng 22 triệu. Giờ hãy bàn về thiết kế. Nếu phía nghiệp vụ nói 30 phần trăm là vô lý, tuyệt: hãy cho tôi con số thật. Mục đích là đưa tăng trưởng vào cuộc thảo luận kiến trúc.

Tôi gọi đây là Số chữ số 0 của Steve (Steve’s Number of Zeros). Thêm một chữ số 0 có thể thay đổi hoàn toàn kiến trúc của bạn. Mười nghìn, một trăm nghìn, một triệu, mười triệu, một trăm triệu: tính năng không đổi, yêu cầu có thể không đổi, nhưng kiến trúc thì có thể đổi.

Bạn còn nhớ các lịch hẹn ở mô-đun 1? Hãy gắn con số thật vào chúng. Hơn 1.200 địa điểm, mỗi địa điểm 100 lịch hẹn một ngày, sáu ngày một tuần, khoảng 305 ngày một năm. Đó là hơn 36 triệu lịch hẹn trong năm đầu tiên. Mỗi lượt ghé tạo ra hai bản ghi, vậy là hơn 73 triệu bản ghi. Giờ giữ lịch sử năm năm, tăng 30 phần trăm mỗi năm, và con số vượt 650 triệu bản ghi. Cùng tính năng, cùng yêu cầu. Thêm vài chữ số 0, và một kiến trúc rất khác.

Lên kế hoạch cho ngày mai

Khi đã hiểu hôm nay, tôi nhìn về phía trước: điều gì có khả năng thay đổi một cách hợp lý? Khối lượng là một phần, nhưng ngày mai không chỉ là nhiều hơn. Nó cũng có thể là khác đi: thêm sản phẩm, đơn vị kinh doanh và quốc gia; những yêu cầu quyền riêng tư khác; kênh và tích hợp mới; một vụ sáp nhập hay mua lại; một chiến lược dữ liệu chủ hay nền tảng phân tích mới; một tác tử AI sử dụng thông tin vốn chỉ được thiết kế cho con người.

Đó là lý do tôi rất quan tâm đến việc kiến trúc có thể phát triển bằng cách bổ sung thay vì liên tục biến đổi hay không. Nếu doanh nghiệp thêm một sản phẩm, mô hình có tiếp nhận được không? Nếu một hệ thống khác cần dữ liệu, chúng ta có cung cấp nó một cách gọn gàng được không? Nếu khối lượng tăng vọt, chúng ta có chỗ để đi không? Nếu cơ cấu kinh doanh thay đổi, chúng ta có phải xé toạc mô hình dữ liệu không? Chúng ta không cố đoán tương lai một cách hoàn hảo. Chúng ta cố để không tự dồn mình vào góc.

Đừng xây ngày mai ngay hôm nay

Ở đây có một sự cân bằng. Lên kế hoạch cho ngày mai không có nghĩa là xây hệ thống của ngày mai ngay hôm nay. Nếu chúng ta có 100.000 bản ghi và có thể có 100 triệu trong năm năm nữa, điều đó không có nghĩa là xây ngay kiến trúc cho 100 triệu bản ghi. Nó có thể mang đến chi phí và độ phức tạp mà chúng ta chưa cần.

Câu hỏi tôi muốn được trả lời là: kiến trúc hôm nay có thể tiến hóa thành kiến trúc của ngày mai không? Nếu chúng ta có thể bắt đầu đơn giản với một lộ trình rõ ràng phía trước, điều đó thường tốt hơn trả giá cho độ phức tạp sớm nhiều năm. Mối nguy không phải là bắt đầu nhỏ. Mối nguy là bắt đầu ở một nơi không có đường nào để đi tiếp.

Lên kế hoạch cho thất bại

Giờ là phần không ai thích nói đến: mọi thứ đều có thể hỏng. Tôi chưa từng thiết kế một hệ thống nào mà mọi thành phần luôn sẵn sàng mãi mãi, mọi tích hợp đều thành công, mọi người dùng nhập dữ liệu hoàn hảo và mọi hệ thống bên ngoài hoạt động đúng như tài liệu mô tả. Vì vậy đừng thiết kế hệ thống đó.

Hãy hỏi cái gì có thể hỏng, rồi hỏi điều gì xảy ra khi nó hỏng. Một tích hợp bị quá thời gian chờ. Một API từ chối một yêu cầu. Một lần tải dữ liệu ban đêm xử lý 800.000 bản ghi và thất bại ở 200.000 bản ghi. Một hệ thống nguồn ngừng hoạt động. Một người dùng nhập dữ liệu không hợp lệ. Một mã định danh bên ngoài xuất hiện hai lần. Một hệ thống thượng nguồn đổi định dạng của một giá trị mà không đổi tên trường. Một quy trình thành công ở hệ thống này và thất bại ở hệ thống kia. Đây không phải là những trường hợp biên hiếm gặp. Đây là bộ mặt của môi trường production.

Thành công một phần vẫn là thất bại mà bạn cần hiểu

Thất bại một phần đặc biệt nguy hiểm trong kiến trúc dữ liệu. Hãy tưởng tượng di chuyển một triệu bản ghi, và tiến trình báo đã hoàn tất. Tuyệt. Nhưng có đủ một triệu bản ghi đến nơi, hay 999.997, và ba bản ghi nào bị thiếu? Có thể 200.000 bản ghi đã thất bại, một số được tạo hai lần, hoặc tất cả đã đến nơi nhưng một số trường chuyển đổi thất bại.

“Tác vụ hoàn tất” không giống với dữ liệu đúng. Một kiến trúc sư dữ liệu nghĩ về đối soát: làm sao chúng ta biết điều gì lẽ ra phải xảy ra, điều gì thực sự đã xảy ra, và khác biệt giữa chúng? Và chúng ta làm gì với điều đó?

Đây là điều tôi làm khi các hệ thống trở nên phức tạp. Các bản ghi đi từ A sang B, từ trái sang phải. Rồi B gửi lại một thứ: một xác nhận cho mỗi bản ghi nó đã nhận và lưu. Giờ A có thể so sánh những gì nó đã gửi với những gì đã được xác nhận. Nếu bản ghi nào cũng có xác nhận, lần chạy thành công. Nếu thiếu xác nhận nào, lần chạy chưa thành công, bất kể trạng thái tác vụ nói gì, và chúng ta biết chính xác cần xử lý những bản ghi nào: thử lại, chuyển cho một người, hoặc phát cảnh báo.

Click to enlarge

Thất bại một cách êm ái

Khi thất bại xảy ra, tôi muốn biết hệ thống làm gì tiếp theo: nó có thử lại không, tự động hay không; điều gì xảy ra nếu cùng một giao dịch được xử lý hai lần; các bản ghi thất bại đi đâu, và các bản ghi tốt có tiếp tục chảy qua một bản ghi hỏng không; ai được cảnh báo, với thông tin gì, và họ chạy lại phần thất bại thế nào; và người dùng biết có gì đó sai bằng cách nào.

Và quan trọng nhất: chúng ta có thể phục hồi mà không làm vấn đề tệ hơn không? Một chiến lược thử lại tạo ra dữ liệu trùng lặp thì chẳng phải là một chiến lược phục hồi tử tế. Kiến trúc tốt giả định sẽ có thất bại và cho chúng ta một đường quay về.

Giám sát những gì quan trọng

Lên kế hoạch cho thất bại mà không có giám sát thì chưa thực sự là lên kế hoạch. Nếu một tích hợp thất bại lúc 2 giờ sáng và không ai nhận ra cho đến khi một khách hàng gọi điện ba ngày sau, chúng ta không có một kiến trúc vận hành. Chúng ta chỉ có hy vọng.

Hãy quyết định điều gì cần quan sát được: tiến trình có chạy không, mất bao lâu, bao nhiêu bản ghi đã được xử lý, bao nhiêu thành công và thất bại? Khối lượng có bỗng nhiên khác bình thường không? Hàng đợi tồn có đang tăng, lỗi có đang tăng không? Kiến trúc không kết thúc khi việc triển khai thành công. Ngày mai sẽ có người phải vận hành hệ thống này, và đó là một phần của thiết kế.

Hãy nghĩ theo cả ba hướng

Hãy tiếp tục áp dụng ba lăng kính trong suốt phần còn lại của khóa học. Khi thiết kế một mô hình dữ liệu: nó có chạy hôm nay không, có phát triển được ngày mai không, và điều gì xảy ra khi dữ liệu sai hoặc thiếu? Một tích hợp: nó có di chuyển được dữ liệu hôm nay không, có xử lý được khối lượng và hệ thống của ngày mai không, và điều gì xảy ra khi một bên ngừng hoạt động? Khối lượng dữ liệu lớn: hôm nay chúng ta có gì, các con số đang đi về đâu, và chúng ta phục hồi thế nào khi một thao tác lớn chỉ thành công một phần?

Công nghệ thay đổi theo từng chương. Các câu hỏi thì không.

Kiến trúc tồn tại xuyên thời gian

Một lập trình viên đôi khi có thể nhìn một yêu cầu và hỏi: “Cái này có chạy không?” Kiến trúc sư phải hỏi nhiều hơn: nó có chạy hôm nay không, ngày mai nó còn chạy không, và điều gì xảy ra khi nó hoàn toàn không chạy? Ba câu hỏi đó đưa chúng ta vượt ra ngoài việc triển khai và đi vào vòng đời của hệ thống.

Bạn sẽ không đoán trước được mọi yêu cầu tương lai hay ngăn chặn được mọi thất bại. Đó không phải là mục tiêu. Mục tiêu là xây một thứ phù hợp với những gì chúng ta biết hôm nay, để lại cho mình chỗ để đi tiếp ngày mai, và có kế hoạch cho lúc thực tế không chiều theo ý mình.

Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại. Chúng ta sẽ dùng ba lăng kính này hết lần này đến lần khác.

Kiến trúc sư quyết định gì ở đây

• Khối lượng và mức tăng trưởng thực tế là bao nhiêu, và con số nào sẽ làm thay đổi thiết kế.
• Những yêu cầu ngầm định nào phía nghiệp vụ chưa nói ra.
• Thiết kế hôm nay có thể tiến hóa thành thiết kế của ngày mai thế nào, mà không xây hệ thống của ngày mai ngay hôm nay.
• Điều gì xảy ra khi có sự cố: phục hồi, đối soát và giám sát.