Làm thế nào để xây dựng các bài tập thực hành thiết kế hệ thống nhằm đào tạo kỹ sư đánh giá các sự đánh đổi trong kiến ​​trúc hệ thống?

Một nhóm thiết kế dịch vụ đặt vé cho một lễ hội khu vực. Hệ thống xử lý tải trọng dự kiến ​​một cách suôn sẻ, và buổi đánh giá thiết kế kết thúc với sự đồng thuận. Sau đó, yêu cầu thay đổi: ban tổ chức giờ đây cam kết rằng việc bán vé phải tiếp tục hoạt động ngay cả khi một trung tâm dữ liệu ngừng hoạt động trong thời gian mở bán. Thiết kế cũ giờ đây có một điểm yếu duy nhất, và các kỹ sư đã thiết kế nó phải quyết định nên thay đổi điều gì, nên từ bỏ điều gì và làm thế nào để giải thích sự lựa chọn đó.

Đây là một kịch bản minh họa, không phải là một sự cố đã được ghi nhận. Đó là tình huống mà một bài tập thiết kế hệ thống (system design kata) được xây dựng để diễn tập: một thiết kế hoạt động tốt dưới một tập hợp các ràng buộc nhất định gặp phải một tập hợp ràng buộc mới, và các kỹ sư phải bảo vệ hoặc sửa đổi nó kèm theo lý do. Hướng dẫn này dành cho các trưởng nhóm hỗ trợ kỹ thuật và các nhà quản lý kỹ thuật. Nó bao gồm định nghĩa về bài tập thiết kế hệ thống, cách xây dựng một bài tập, cách thực hiện và chấm điểm, và khi nào việc đào tạo không còn là giải pháp nữa. Mỗi trường hợp và tiêu chí cần được một kỹ sư cấp cao xác nhận trước khi sử dụng.

Thiết kế hệ thống theo phương pháp Kata là gì?

Bài tập thiết kế hệ thống (system design kata) là một bài tập thiết kế ngắn, có giới hạn thời gian. Một nhóm nhỏ nhận được một vấn đề kinh doanh chỉ gồm một đoạn văn, phác thảo kiến ​​trúc, trình bày cho các thành viên khác và trả lời các câu hỏi khó. Những người nghiên cứu cũng gọi nó là bài tập kiến ​​trúc (architecture kata) hoặc bài tập thiết kế kiến ​​trúc (architectural kata). Hình thức này được Ted Neward khởi xướng như một hội thảo và được ghi chép lại, cùng với các quy tắc và vai trò của người điều hành, trên [tên trang web]. Trang katas kiến ​​trúc của Neal FordCâu hỏi thúc đẩy của Neward, được trích dẫn ở đó, là làm thế nào các tổ chức có thể đào tạo ra những kiến ​​trúc sư giỏi khi các kỹ sư chỉ có cơ hội thực hành thiết kế kiến ​​trúc chưa đến nửa tá lần trong suốt sự nghiệp. Một bài tập thực hành (kata) cung cấp cho họ thêm nhiều lần luyện tập mà không gây rủi ro cho quá trình sản xuất.

sự kiện nhanh chóng

1. Mô tả vấn đề về hiệu năng

Hãy bắt đầu với nhiệm vụ, chứ không phải chủ đề. Nhiệm vụ là bảo vệ một kiến ​​trúc trong điều kiện ràng buộc thay đổi. Trong công việc thực tế, điều này xảy ra trong các buổi đánh giá thiết kế, theo dõi sự cố và các cuộc họp lập kế hoạch khi một yêu cầu thay đổi: lưu lượng truy cập tăng, cam kết về tính khả dụng nghiêm ngặt hơn, quy tắc lưu trữ dữ liệu mới, ngân sách eo hẹp hơn.

Nhiều kỹ sư có thể vẽ ra một bản thiết kế kiến ​​trúc hợp lý. Nhưng ít người có thể nói được họ sẽ đánh đổi điều gì khi hai mục tiêu xung đột và bằng chứng nào sẽ thay đổi quyết định của họ. Kỹ năng thứ hai đó chính là điều mà bài tập kata hướng đến.

Hãy viết một câu mô tả hiệu suất ngắn gọn và nhờ quản lý kỹ thuật kiểm tra: "Với một kiến ​​trúc hệ thống và một ràng buộc đã thay đổi, kỹ sư nêu rõ vấn đề, đề xuất thay đổi, nêu rõ sự đánh đổi và cho biết những gì họ vẫn chưa biết."

2. Chẩn đoán những thiếu sót về kiến ​​thức và bối cảnh.

Trước khi xây dựng bất cứ thứ gì, hãy so sánh nhiệm vụ đó với những gì chương trình của bạn đang thực hành và đánh giá hiện nay.

1. Việc luyện tập có sử dụng nhiệm vụ thực tế không? Nếu việc đào tạo chỉ dạy các mô hình riêng lẻ và việc đánh giá là một bài kiểm tra trắc nghiệm, thì sẽ chẳng ai thực hành việc bảo vệ một lựa chọn của mình cả.
2. Yêu cầu về khả năng nhận thức là gì? Trong thang phân loại Bloom sửa đổi, việc so sánh các lựa chọn với các ràng buộc nằm ở cấp độ phân tích và đánh giá, và việc đề xuất một thiết kế sửa đổi nằm ở cấp độ sáng tạo. Hướng dẫn của chúng tôi về Phù hợp các hoạt động học tập với Phân loại Bloom. Hướng dẫn cách lựa chọn hoạt động phù hợp với trình độ đó.
3. Liệu có yếu tố nào khác ngoài kỹ năng đang cản trở? Hãy kiểm tra xem các kỹ sư có đủ thời gian để thiết kế không, liệu có ai chịu trách nhiệm về các quyết định kiến ​​trúc hay không và liệu các yêu cầu đã được ghi chép lại chưa. Nếu quyết định được đưa ra bởi người ngoài nhóm, thì không có bài tập nào có thể thay đổi được khả năng của nhóm. Hãy chuyển những nguyên nhân đó cho những người có thể giải quyết chúng.

3. Chuẩn bị và thực hành thiết kế

Hãy giao nhiệm vụ riêng biệt cho từng giai đoạn.

Sự chuẩn bị. Kiểm tra các điều kiện tiên quyết bằng một bài kiểm tra chẩn đoán ngắn: thuật ngữ mà nhóm của bạn sử dụng (khả năng sẵn sàng, tính nhất quán, độ trễ, chi phí), các khối kiến ​​thức cơ bản mà họ cần biết và mẫu đánh giá thiết kế của riêng bạn. Tự học theo tốc độ riêng phù hợp với giai đoạn này, và việc kiểm tra kiến ​​thức chỉ nhằm xác nhận các điều kiện tiên quyết.

Thực hành. Thực hiện bài tập lập trình (kata) theo đúng định dạng được mô tả trên trang web của Neal Ford. Sau khi các nhóm được thành lập, bài tập sẽ diễn ra qua ba giai đoạn: giai đoạn thảo luận, nơi các nhóm cùng nhau xây dựng sản phẩm; giai đoạn đánh giá ngang hàng, nơi mỗi nhóm trình bày và trả lời các câu hỏi; và giai đoạn bỏ phiếu, nơi các thành viên khác đưa ra ý kiến ​​tán thành ("xuất sắc"), ý kiến ​​trung bình ("thiếu sót một vài điểm") hoặc ý kiến ​​phản đối ("thiếu sót nghiêm trọng"). Một số quy tắc đáng được áp dụng trực tiếp: các nhóm có thể đưa ra giả định về công nghệ chưa quen thuộc nhưng phải nêu rõ chúng, và không được giả định rằng họ có thể tuyển dụng một nhóm toàn những người giỏi nhất.

Thêm ràng buộc thay đổi. Bài tập kata tiêu chuẩn đưa ra một vấn đề cố định. Để rèn luyện kỹ năng trong hướng dẫn này, hãy thêm một thẻ thứ hai ở giữa bài: một ràng buộc thay đổi mà nhóm phải nắm bắt. Đây là lựa chọn thiết kế của chúng tôi, không phải là một phần của quy tắc gốc, vì vậy hãy thử nghiệm trước.

Phản hồi. Hãy liên kết phản hồi với các quyết định, chứ không phải với tổng điểm. "Bạn đã chuyển đến hai khu vực, nhưng không nói rõ điều gì xảy ra với đơn hàng được đặt trong quá trình chuyển đổi" sẽ hữu ích hơn là "3 trên 5".

Nhập liệu trực tiếp hay xem xét không đồng bộ? Việc thảo luận trực tiếp mang lại hiệu quả cao nhất khi lựa chọn không rõ ràng và các kỹ sư học hỏi từ đồng nghiệp cấp cao hơn bằng cách giải thích lý do tại sao họ nên giữ nguyên quan điểm đó. Việc xem xét không đồng bộ là đủ để so sánh lý lẽ bằng văn bản với một ví dụ có chú thích.

4. Hãy cùng nhau tìm hiểu một ví dụ thực tế.

Ví dụ minh họa. Kỹ sư cấp cao nên thẩm định trường hợp và tiêu chí trả lời trước khi sử dụng.

Trường hợp. Một lễ hội khu vực bán được 20,000 vé trong một cuối tuần, với phần lớn vé được bán trong mười phút đầu tiên. Bản tóm tắt ban đầu yêu cầu một dịch vụ đặt vé có thể xử lý được lượng truy cập cao điểm đó. Thiết kế: một tầng web, một cơ sở dữ liệu, và một cuộc gọi đến nhà cung cấp thanh toán khi thanh toán hoàn tất.

Ràng buộc đã thay đổi. Đến giữa chừng, ban tổ chức bổ sung thêm: việc bán vé phải tiếp tục nếu một trung tâm dữ liệu ngừng hoạt động, và không được phép bán hai vé cùng lúc.

Lần thử đầu tiên. "Thêm một trung tâm dữ liệu thứ hai và sao chép cơ sở dữ liệu." Nhóm đã sử dụng một giải pháp quen thuộc, nhưng chưa cho biết điều gì sẽ xảy ra với quy tắc không bán hàng trùng lặp khi hai địa điểm không thể giao tiếp với nhau.

Phản hồi và thử lại. Người điều phối yêu cầu nhóm nêu tên hai mục tiêu đang mâu thuẫn và mục tiêu nào họ sẽ bảo vệ trong trường hợp mạng lưới bị chia tách. Sau đó, họ được yêu cầu chọn một mục tiêu và mô tả trải nghiệm của khách hàng.

Một nỗ lực mạnh mẽ hơn. "Chúng tôi sẽ bảo vệ quy tắc không bán vé hai lần. Trong trường hợp chia tách trang web, chỉ trang web chính bán vé và trang web còn lại hiển thị trang chờ. Chúng tôi chấp nhận số lượng vé có sẵn thấp hơn trong thời gian ngắn để tránh bán cùng một chỗ ngồi hai lần. Chúng tôi giả định rằng việc chia tách trang web là hiếm và ngắn, và chúng tôi muốn ban tổ chức xác nhận rằng việc hiển thị trang chờ là chấp nhận được. Nếu họ cần cả hai trang web đều bán vé, chúng tôi sẽ phân bổ các khối chỗ ngồi riêng biệt cho mỗi trang web trước, với chi phí là một số chỗ ngồi không bán được." Lưu ý rằng câu trả lời này nêu rõ xung đột, chọn một phía, nêu rõ chi phí và chỉ ra những gì nó không biết.

Tại sao mỗi câu trả lời lại có thể chấp nhận được hoặc chưa đầy đủ. Hãy đánh giá từng phương án dựa trên các tiêu chí đã được phê duyệt, chứ không phải dựa trên kiến ​​trúc mà người đánh giá ưa thích. Phương án đầu tiên chỉ nêu tên một thành phần mà không đề cập đến sự đánh đổi. Phương án tốt hơn thì cụ thể hơn, nêu rõ các giả định và đưa ra một giải pháp thay thế kèm theo giá cả.

5. Đánh giá năng lực và lập kế hoạch chuyển giao

Bằng chứng về năng lực thể hiện qua việc xử lý một trường hợp mới mà kỹ sư chưa từng gặp. Chấm điểm dựa trên khả năng cân nhắc giữa các yếu tố và phản ứng trước một ràng buộc mới. Một bảng tiêu chí đơn giản sử dụng thang điểm từ 0 đến 2 cho mỗi tiêu chí:

Thang điểm: 0 là không có hoặc không được hỗ trợ, 1 là một phần với những thiếu sót liên quan, và 2 là đầy đủ và được chứng minh dựa trên các tiêu chí đã thống nhất. Xác định riêng các lỗi nghiêm trọng, chẳng hạn như bỏ qua yêu cầu về an toàn hoặc bảo vệ dữ liệu đã nêu, để điểm tổng thể không che giấu được lỗi đó. Bảng đánh giá này chỉ là đề xuất, không phải là tiêu chuẩn sẵn sàng đã được xác nhận: hãy điều chỉnh nó với người quản lý kỹ thuật và thử nghiệm thí điểm. Hướng dẫn của chúng tôi về... Thiết kế bài tập tương tác với phản hồi hữu ích Nội dung này hướng dẫn cách viết phản hồi liên quan đến các quyết định.

Chuyển giao kế hoạch một cách có chủ đích. Sau bài tập kata, hãy yêu cầu mỗi kỹ sư đưa ra một quyết định thiết kế thực tế để xem xét và áp dụng các câu hỏi tương tự. Việc xem xét khách quan một sự cố trong quá khứ cũng là một cầu nối tốt dẫn đến công việc thực tế; xem hướng dẫn của chúng tôi về tiến hành đánh giá sự cố không đổ lỗi.

Trong trường hợp phương thức giao hàng tương tác giúp ích

Các định dạng tương tác rất hữu ích khi mọi người cần cam kết trước khi nhìn thấy nhóm. Trong một phiên kata trực tiếp, người điều phối có thể hiển thị ràng buộc đã thay đổi, yêu cầu mỗi thành viên nhóm nhập ra sự đánh đổi mà họ sẽ thực hiện và lý do, sau đó tiết lộ kết quả trước khi bắt đầu thảo luận. Việc bỏ phiếu đồng nghiệp ở cuối định dạng gốc rất dễ thực hiện theo cùng một cách. Trường hợp tương tự có thể được thực hiện theo hình thức tự học để chuẩn bị hoặc cho các kỹ sư vắng mặt trong phiên. AhaSlides hỗ trợ học tập tương tác và chuyển đổi giữa hình thức trực tiếp và tự học. Đây là một công cụ trình bày và học tập, không phải là nơi để vẽ hoặc chạy kiến ​​trúc, vì vậy hãy giữ sơ đồ trên bảng trắng hoặc trong công cụ thiết kế của bạn. Kiểm tra bất kỳ chức năng soạn thảo, phản hồi hoặc báo cáo cụ thể nào bạn dự định sử dụng so với quy trình làm việc của riêng bạn. Để được hướng dẫn về việc lựa chọn định dạng, hãy xem bài viết của chúng tôi về Khi nào nên sử dụng phương pháp học tập thích ứng, tương tác và trực tiếp?.

Đo lường những gì đã thay đổi

Hãy quyết định trước những yếu tố nào sẽ chứng minh các kỹ sư có thể bảo vệ kiến ​​trúc hệ thống trong điều kiện thay đổi. So sánh lý luận về sự đánh đổi trong một trường hợp chưa từng thấy với dữ liệu cơ sở được thu thập trước khi chương trình bắt đầu. Xác định đối tượng tham gia, mẫu số và thời gian. Nếu kết quả được cải thiện, hãy xem xét những thay đổi khác trong cùng kỳ, chẳng hạn như mẫu đánh giá thiết kế mới, thay đổi nhân sự hoặc sự cố nào đó gây chú ý, trước khi ghi nhận công lao của khóa đào tạo.

Những ràng buộc có thể vẫn còn

• Chuyên gia thiết kế. Nếu cả đội không đưa ra quyết định, việc luyện tập sẽ có hiệu quả hạn chế.
• Thời gian. Một bài tập lập trình (kata) chỉ mất vài giờ; thiết kế thực tế cần nhiều tuần và liên quan đến dữ liệu mà một bài tập lập trình không thể cung cấp.
• Phạm vi bao phủ vụ việc. Một trường hợp cụ thể thể hiện một vài sự đánh đổi. Điểm số không phản ánh chính xác khả năng đánh giá của một kỹ sư nói chung.
• Sự phức tạp. Độ phức tạp cao hơn không nhất thiết là một kiến ​​trúc tốt hơn, vì vậy đừng ưu tiên những kiến ​​trúc có nhiều thành phần nhất.
• Chuyển khoản. Việc thể hiện tốt trong một buổi hội thảo không giống với việc thể hiện tốt trong một buổi đánh giá căng thẳng, vì vậy hãy kiểm tra hiệu suất sau khi hoàn thành bài tập, trong bối cảnh thực tế.

Hãy nêu rõ những vấn đề này với nhà tài trợ từ sớm và lên kế hoạch khắc phục riêng biệt. Một bài tập lập trình (kata) giúp cải thiện khả năng giải thích và bảo vệ luận điểm của kỹ sư. Tuy nhiên, nó không tạo ra thẩm quyền hay thời gian cần thiết.

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

Thiết kế hệ thống theo phương pháp Kata là gì?

Một bài tập thiết kế ngắn gọn, có giới hạn thời gian, trong đó một nhóm nhỏ phác thảo kiến ​​trúc cho một vấn đề kinh doanh, trình bày cho các thành viên khác và trả lời các câu hỏi mang tính thách thức. Nó cũng được gọi là architecture kata.

Một nhóm nên có bao nhiêu người?

Hình thức ban đầu sử dụng các nhóm nhỏ từ 3 đến 5 người, thường là một trong 4 đến 10 nhóm trong một phòng. Hãy sử dụng các nhóm đủ nhỏ để mọi người đều có thể phát biểu.

Làm thế nào để đánh giá một bài tập thiết kế hệ thống (system design kata)?

Đưa ra một trường hợp mới và lý luận về sự đánh đổi giữa các tiêu chí, cũng như phản hồi đối với sự thay đổi về ràng buộc so với các tiêu chí đã được thống nhất. Ý kiến ​​đánh giá của đồng nghiệp là phản hồi hữu ích nhưng bản thân nó không phải là điểm số.

Bắt đầu từ đâu

Hãy chọn một quyết định thiết kế thường xuyên xuất hiện trong tổ chức của bạn và viết một đoạn văn ngắn giải thích về nó. Thêm một ràng buộc đã thay đổi, nhờ quản lý kỹ thuật xác nhận trường hợp và các tiêu chí trả lời, đồng thời soạn thảo một bảng đánh giá ba tiêu chí với danh sách các lỗi nghiêm trọng. Thử nghiệm với một nhóm trước khi triển khai rộng rãi.

Để xem cách một bài tập thực hành (kata) có thể được triển khai trực tiếp với nhóm của bạn và được tái sử dụng theo tốc độ riêng sau đó, hãy khám phá AhaSlides.