Hệ thống quản lí trường học, bài toán chưa bao giờ chỉ là công nghệ
Nhiều người nghĩ hệ thống quản lý trường học chỉ là nơi quản lý học sinh, lớp, điểm danh hay học phí. Tôi cũng từng nghĩ vậy, cho đến khi tham gia một dự án EdTech thực tế cho một chuỗi trường nhiều cơ sở, số lượng người dùng lớn và nghiệp vụ thay đổi liên tục.
Lúc đó tôi mới thấy: cái khó nhất không nằm ở công nghệ. Nó nằm ở cách nghiệp vụ vận hành theo nhiều tầng, các quy tắc tích luỹ theo thời gian và liên tục thay đổi mỗi ngày.
Đến một lúc nào đó, bạn sẽ nhận ra đây không còn là một ứng dụng mà là một hệ sinh thái vận hành
Khi nhắc tới phần mềm quản lý trường học, phản xạ phổ biến là nghĩ đến một ứng dụng quản trị: có danh sách, có form nhập liệu, có báo cáo. Nhưng khi bắt tay vào dự án thực tế, tôi nhận ra cách nhìn này không còn phù hợp.
Trong bối cảnh EdTech, bài toán không dừng ở một ứng dụng đơn lẻ mà là một hệ sinh thái gồm nhiều thành phần chạy song song, dùng chung dữ liệu và phụ thuộc lẫn nhau. Vì vậy, một thay đổi nhỏ ở một điểm có thể kéo theo nhiều phần khác bị ảnh hưởng, kể cả những chỗ tưởng như không liên quan.
Hệ thống này phục vụ một chuỗi khoảng 20 cơ sở với hơn 100.000 người dùng, nhưng độ khó không nằm ở quy mô đó. Nó nằm ở việc một nền tảng phải đồng thời phục vụ nhiều nhóm với cách vận hành hoàn toàn khác nhau: phụ huynh, học sinh, giáo viên và đội ngũ vận hành.
Độ khó thực sự bắt đầu khi dữ liệu và nghiệp vụ phải đi qua nhiều hệ thống
Hãy hình dung một tình huống đơn giản: một phụ huynh đăng ký nhập học cho con.
Thông tin ban đầu được tạo ở hệ tuyển sinh, nơi ghi nhận hồ sơ và theo dõi quá trình ghi danh. Khi học sinh được nhận, dữ liệu đó được chuyển sang hệ quản lý của nhà trường để bắt đầu theo dõi học tập. Đồng thời, thông tin học phí được đẩy sang hệ tài chính để tạo công nợ và theo dõi thu chi. Khi phụ huynh thanh toán, hệ thống thanh toán cập nhật lại trạng thái cho hệ tài chính, và từ đó ảnh hưởng ngược trở lại các chức năng mà học sinh được phép sử dụng.
Trong suốt quá trình đó, phụ huynh chỉ cần đăng nhập một lần, nhưng phía sau là nhiều hệ thống đang cùng phối hợp để xử lý từng bước.
Nhìn từ bên ngoài, mọi thứ có vẻ liền mạch. Nhưng phía sau, dữ liệu liên tục được truyền qua nhiều hệ thống khác nhau, và mỗi bước xử lý đều phụ thuộc vào trạng thái của bước trước đó.
Chính vì vậy, đây không còn là bài toán của một ứng dụng đơn lẻ mà là thiết kế cách nhiều hệ thống phối hợp với nhau mà không làm sai lệch trạng thái.
Cái khó nhất thường không nằm ở công nghệ, mà nằm ở nghiệp vụ luôn chuyển động
Công nghệ quen thuộc không khiến bài toán trở nên dễ hơn
Nếu chỉ nhìn vào công nghệ, đây không phải là một dự án đặc biệt khó.
Bộ công nghệ khá quen thuộc: PHP/Laravel, ReactJS, React Native, MySQL, không có gì quá mới và cũng không phải kiểu kiến trúc phức tạp.
Nhưng độ khó của dự án không nằm ở đó mà nằm ở nghiệp vụ.
Nghiệp vụ trong EdTech có nhiều tầng và thay đổi liên tục theo trường, theo chương trình, theo năm học. Thậm chí, có những quy tắc chỉ tồn tại theo cách người vận hành quen làm nhưng lại không được ghi lại trong bất kỳ tài liệu nào.
Chỉ khi tất cả những điều đó được đưa vào một hệ thống chung, phần khó nhất mới thực sự lộ ra.
Thứ quyết định khả năng mở rộng không phải framework mà là cách bạn mô hình hoá nghiệp vụ
Với những hệ thống như vậy, công nghệ chỉ là phần bên ngoài của hệ thống. Phần quyết định khả năng mở rộng nằm ở cách nghiệp vụ được mô hình hoá và cách hệ thống phản ứng với thay đổi.
Nếu nghiệp vụ không được thiết kế rõ ràng ngay từ đầu, mỗi lần thay đổi sẽ kéo theo việc chắp vá logic ở nhiều chỗ và hệ thống sẽ dần trở nên rối.
Nếu chỉ nhìn phần mềm trường học như một công cụ để nhập liệu, lưu trữ thông tin và kết nối dữ liệu giữa các hệ thống, bạn rất dễ đánh giá sai độ khó của bài toán này.
Nếu nhìn học sinh như một record dữ liệu, bạn gần như chắc chắn sẽ thiết kế sai hệ thống
Dữ liệu chỉ là phần nhìn thấy được, trạng thái vận hành mới là phần lõi
Một trong những điểm khiến tôi thay đổi cách nhìn rõ nhất là cách hệ thống cần hiểu về học sinh.
Trong hệ thống này, học sinh không chỉ là một dòng dữ liệu trong bảng. Học sinh là một thực thể có trạng thái và một vòng đời rõ ràng.
Một học sinh có thể đi qua nhiều trạng thái: chờ ghi danh, chờ hoàn thiện hồ sơ, trúng tuyển, chờ nhập học, đang học, bảo lưu, chờ chuyển trường. Những trạng thái này không phải để hiển thị cho có. Chúng quyết định học sinh được phép làm gì, bị hạn chế gì, và ảnh hưởng trực tiếp đến việc đăng ký dịch vụ, thanh toán cũng như cách thông tin hiển thị cho phụ huynh.
Không làm rõ trạng thái và cách chuyển trạng thái, hệ thống sẽ càng sửa càng rối
Trong thiết kế hệ thống, có một khái niệm gọi là máy trạng thái (state machine), tức là định nghĩa rõ một đối tượng có những trạng thái nào và được phép chuyển giữa các trạng thái đó ra sao.
> State machine (Máy trạng thái) là một mô hình thiết kế trong khoa học máy tính dùng để quản lý quá trình vận hành của một hệ thống, trong đó hệ thống chỉ có thể ở một trạng thái hữu hạn tại một thời điểm. Nó chuyển đổi từ trạng thái này sang trạng thái khác (transition) dựa trên các sự kiện đầu vào (input) và điều kiện kích hoạt, giúp logic ứng dụng rõ ràng, dễ bảo trì và mở rộng.
Trong EdTech, đây gần như là phần lõi của nghiệp vụ.
Có những tình huống một học sinh có thể mang nhiều trạng thái cùng lúc ở các cơ sở khác nhau. Nếu vẫn tiếp cận theo kiểu có form thì lưu, có bảng thì cập nhật, thiết kế sẽ sai ngay từ đầu.
Nếu phần trạng thái này không được làm rõ, hệ thống rất dễ phát sinh lỗi khó tái hiện, các xử lý chồng chéo lên nhau và càng sửa càng rối vì không còn ranh giới rõ giữa quy tắc gốc và những phần được bổ sung về sau.
Khi mở rộng ra nhiều cơ sở, bài toán không còn là đồng bộ dữ liệu nữa
Mỗi trường gần như là một cách vận hành riêng, dù cùng sử dụng một hệ thống
Ban đầu, đội của tôi cũng có một giả định khá tự nhiên: các trường trong cùng một hệ thống sẽ tương đối giống nhau, cùng lắm chỉ khác vài trường dữ liệu hoặc lệch quy trình một chút.
Nhưng thực tế không như vậy. Chỉ riêng sự khác biệt giữa trường mầm non và trường phổ thông đã khiến quy trình lệch nhau ở nhiều điểm: từ cách đăng ký dịch vụ, nội dung biểu mẫu cho tới điều kiện hợp lệ. Khi mở rộng ra nhiều cơ sở và nhiều chương trình, những khác biệt nhỏ này bắt đầu tích luỹ lại và trở thành một bài toán thiết kế thực sự.
Validation không chỉ là kiểm tra dữ liệu đúng hay sai, mà là kiểm tra đúng theo cách vận hành
> Validation (thẩm định/xác nhận giá trị sử dụng) là quá trình kiểm tra, đánh giá để đảm bảo một sản phẩm, quy trình hoặc hệ thống đáp ứng đúng nhu cầu, mục đích sử dụng thực tế của người dùng cuối cùng. Nó giải quyết câu hỏi “chúng ta đã tạo ra sản phẩm phù hợp chưa?”
Trong bối cảnh này, validation không chỉ dừng ở việc dữ liệu có rỗng hay đúng định dạng. Nó phải phản ánh đúng cách hệ thống vận hành ngoài thực tế.
Một dữ liệu hợp lệ hay không có thể phụ thuộc vào trường, khối, chương trình, năm học và trạng thái của học sinh.
Có những quy tắc đúng ở trường A nhưng lại không đúng ở trường B. Có những quy tắc áp dụng năm nay, nhưng sang năm thay đổi chính sách là phải điều chỉnh. Khi đó, vấn đề không còn là viết đúng một bộ luật, mà là thiết kế hệ thống sao cho chịu được sự thay đổi và khác biệt đó.
Giữ phần lõi ổn định khi mỗi nơi vận hành một kiểu mới là bài toán khó nhất
Khi nói tới phần lõi, tôi đang nói tới nơi chứa logic chung quan trọng nhất của hệ thống. Nếu phần này chứa quá nhiều trường hợp đặc biệt không theo quy tắc chung, hệ thống sẽ dần trở nên khó thay đổi: thêm mới khó, chỉnh sửa khó, và chỉ cần thay đổi một chỗ có thể ảnh hưởng đến nhiều chỗ khác.
Vì vậy, với các hệ thống phục vụ nhiều trường, vấn đề không chỉ là tách dữ liệu. Phần khó hơn nhiều là quản trị sự khác nhau trong nghiệp vụ giữa các trường mà vẫn giữ được phần lõi đủ sạch và đủ ổn định.
Có những hệ thống vừa nặng nghiệp vụ, vừa chịu tải cao vào những thời điểm rất bình thường
Áp lực của hệ thống không chỉ đến từ những tình huống hiếm. Phần lớn áp lực lại xuất hiện vào những thời điểm rất quen thuộc trong quá trình vận hành hàng ngày.
Trong EdTech, thời điểm tải cao nhất thường rơi vào những khung giờ cố định như 8 giờ sáng khi giáo viên điểm danh đồng loạt, hoặc đầu năm học khi phụ huynh cùng lúc đăng ký dịch vụ.
Một thao tác nhìn từ bên ngoài có thể chỉ là nhập dữ liệu rồi bấm lưu nhưng phía sau lại là cả một chuỗi xử lý: kiểm tra trạng thái học sinh, xác định biểu mẫu phù hợp theo từng trường, cấp lớp và loại chương trình học, kiểm tra thông tin theo đúng quy định, rồi ghi nhận dữ liệu theo từng năm học.
Đây là loại bài toán vừa nặng xử lý vừa chịu tải cao cùng lúc. Nếu chỉ tối ưu hiệu năng mà không hiểu nghiệp vụ sẽ rất dễ tối ưu sai chỗ. Nhưng nếu chỉ tập trung làm đúng nghiệp vụ mà bỏ qua tải, hệ thống sẽ gặp vấn đề đúng vào những thời điểm không được phép sai.
Thứ khó nhất không phải là viết code mà là hiểu đúng cái hệ thống đang phải phục vụ
Khi bắt đầu dự án, cái khó nhất với đội của tôi không phải là viết API hay dựng giao diện. Cái khó là hiểu được bức tranh tổng thể của hệ thống, lần ra quan hệ dữ liệu và nắm được logic đang nằm rải rác ở nhiều nơi.
Trong nhiều trường hợp, đội phải lần ngược từ hệ thống đang chạy: đọc code, hỏi nhiều bên và tự kiểm thử, rồi mới ghép lại được một bức tranh tương đối hoàn chỉnh.
Đó là quá trình đi từ việc hệ thống đang làm gì, về lại câu hỏi gốc: nghiệp vụ thật sự là gì, đâu là quy tắc lõi và đâu chỉ là những phần được bổ sung thêm theo thời gian.
Những hệ thống khó nhất là hệ thống có nghiệp vụ phức tạp và liên tục biến động
Sau một thời gian làm dự án, tôi rút ra một điều khá rõ: Những hệ thống khó nhất không phải vì công nghệ phức tạp, mà vì cách vận hành bên trong nhiều tầng và liên tục thay đổi.
Trong EdTech, nghiệp vụ liên quan đến nhiều bên, quy trình thay đổi theo thời gian và mỗi đơn vị lại vận hành theo cách riêng. Phần mềm chỉ là nơi thể hiện tất cả những điều đó. Nếu không kiểm soát được sự thay đổi ở nghiệp vụ, hệ thống sẽ dần trở nên khó mở rộng và chỉnh sửa về sau.
Những gì tôi chia sẻ ở trên mới chỉ là phần cơ bản của bài toán. Trên thực tế, dự án còn trở nên khó hơn nhiều khi yêu cầu thay đổi liên tục, không có người chịu trách nhiệm rõ ràng cho sản phẩm hoặc đội phát triển phải bắt đầu làm khi chưa thực sự hiểu nghiệp vụ. Và đây cũng là lúc dự án bắt đầu đi chệch hướng, dù phần công nghệ ban đầu có được làm tốt đến đâu.
Ở bài tiếp theo, tôi sẽ kể về một sai lầm mà đội của tôi gặp phải rất sớm: bắt đầu phát triển khi chưa thực sự hiểu nghiệp vụ. Nếu bạn từng làm các hệ thống phục vụ nhiều đơn vị, nhiều bên liên quan hoặc nghiệp vụ phức tạp, có lẽ bạn sẽ thấy điều này khá quen.
Cùng theo dõi BiPlus để đón chờ các bài viết tiếp theo nhé!
Về tác giả
Loi Le – BU Director
Tôi là một Technical Leader với hơn 12 năm kinh nghiệm trong phát triển backend, chuyên sâu về các hệ thống xây dựng trên nền tảng Java, trải dài trong các lĩnh vực FinTech, thương mại điện tử và viễn thông. Tôi đã dẫn dắt nhiều team kỹ sư trong việc thiết kế và triển khai các hệ thống có khả năng mở rộng cao, hiệu năng tốt, đồng thời phối hợp chặt chẽ với các bộ phận liên chức năng và đối tác bên ngoài.
Thế mạnh cốt lõi của tôi bao gồm thiết kế hệ thống và kiến trúc microservices, tối ưu hiệu năng và thiết kế cơ sở dữ liệu, cũng như xây dựng và vận hành các hệ thống phân tán sử dụng các công nghệ như Kafka, Redis và các nền tảng tương tự.
Hiện tại, tôi đang tập trung phát triển theo hướng Solution Architect, với mục tiêu thiết kế các hệ thống end-to-end cân bằng giữa nhu cầu kinh doanh, khả năng mở rộng và tính dễ bảo trì trong dài hạn.
Tôi cũng thường xuyên chia sẻ những góc nhìn và bài học rút ra từ các dự án thực tế. Rất sẵn lòng kết nối và trao đổi về system design, architecture hoặc engineering leadership. Let’s connect!
