Vì sao Zunavi ưu tiên On-Premise: Bản vẽ bán dẫn không rời khỏi tổ chức

Giả định được gắn sẵn trong hầu hết công cụ quản lý bản vẽ

Gần như mọi sản phẩm SaaS hiện đại cho quản lý tài liệu kỹ thuật đều được xây dựng ưu tiên cloud: đăng ký, file của bạn được đưa lên hạ tầng của họ, và “on-premise” — nếu có tồn tại — thường là một tùy chọn dành cho doanh nghiệp được gắn thêm sau, thường đắt đỏ và thường là trải nghiệm hạng hai. Với rất nhiều nhóm phần mềm, đó là một mặc định hoàn toàn hợp lý.

Đó là mặc định sai đối với nhóm khách hàng mà Zunavi được xây dựng cho. Các nhà sản xuất bán dẫn và sản xuất chính xác làm việc với những bản vẽ vốn dĩ mang tính bảo mật theo định nghĩa — “bán dẫn là bí mật” không phải là một ô cần đánh dấu tuân thủ đối với ngành này, đó là giả định khởi đầu. Một công cụ âm thầm yêu cầu bản vẽ phải đi qua máy chủ của bên thứ ba trước khi kỹ sư có thể xem được là điều loại bỏ hoàn toàn khả năng lựa chọn đối với một phần đáng kể của thị trường này, dù bộ tính năng có tốt đến đâu.

Biến On-Premise thành hình thức triển khai hạng nhất, không phải phương án dự phòng

Cách điều này thể hiện trong kiến trúc của Zunavi là một trường ngay trên bản ghi tenant: Tenant.deployment, có thể là ONPREM hoặc CLOUD. Đây không phải một luồng ngoại lệ được xử lý qua ticket hỗ trợ — đó là một giá trị hạng nhất mà phần còn lại của hệ thống được thiết kế xoay quanh. Các tenant on-premise mặc định tắt các năng lực phụ thuộc vào cloud, không phải vì họ bị hạn chế, mà vì tư thế mặc định cho một khối lượng công việc vốn dĩ mang tính bảo mật nên là “dữ liệu không rời khỏi tổ chức” trừ khi ai đó nói rõ điều ngược lại.

Phần “nói rõ điều ngược lại” đó quan trọng. Bất kỳ tính năng nào có nghĩa là gửi dữ liệu bản vẽ đến một dịch vụ bên ngoài đều nằm sau flag đồng thuận riêng của nó, tách biệt với hệ thống feature flag chung mà chúng tôi đã viết riêng. Bật một năng lực phụ thuộc cloud là một quyết định mà quản trị viên tenant phải chủ động đưa ra — nó không xảy ra ngầm chỉ vì một tính năng khác được bật vì lý do nào đó.

Lưu trữ: Mặc định là hệ thống file cục bộ, S3-compatible khi bạn yêu cầu

Lưu trữ file tuân theo cùng logic đó. Tầng lưu trữ của Zunavi được điều khiển bởi thiết lập STORAGE_DRIVER: mặc định là hệ thống file cục bộ, lưu trữ đối tượng tương thích S3 là một tùy chọn rõ ràng. Với một bản cài đặt on-premise, bản vẽ, file DXF/DWG/STEP, và thumbnail được tạo ra nằm trên hạ tầng mà nhà sản xuất đã kiểm soát sẵn — không có bucket ở một region họ không chọn, không có nhà cung cấp lưu trữ bên thứ ba được thêm vào đánh giá rủi ro nhà cung cấp theo mặc định. Lưu trữ đối tượng cloud vẫn có sẵn cho các đội muốn dùng — một cấu hình nhẹ hơn, môi trường demo, một xưởng nhỏ hơn không có hạ tầng máy chủ để quản lý — nhưng đó là tùy chọn tham gia (opt-in), không phải giả định nền tảng của kiến trúc.

“Bảo mật” không phải một tính từ mơ hồ trong ngành này

“Bán dẫn là bí mật” không phải ngôn ngữ marketing được mượn để biện minh cho một lựa chọn kiến trúc — nó mô tả một thực tế pháp lý mà các kỹ sư bán dẫn đang thực sự vận hành theo. Theo quy định kiểm soát xuất khẩu của Hoa Kỳ, một “deemed export” (xuất khẩu ngầm định) xảy ra khi dữ liệu kỹ thuật bị kiểm soát — bao gồm rõ ràng thông tin thiết kế bán dẫn và bí quyết sản xuất — được chia sẻ với một công dân nước ngoài, ngay cả khi việc đó diễn ra trong chính tòa nhà của công ty xuất khẩu; điều này được xử lý giống như việc vận chuyển vật lý hàng hóa bị kiểm soát ra nước ngoài, và các công ty được kỳ vọng phải triển khai kiểm soát truy cập và quy trình sàng lọc tương ứng (Kharon, về tuân thủ kiểm soát xuất khẩu AI và bán dẫn). Các nhà lập pháp thậm chí đã đề xuất hạn chế hoàn toàn quyền truy cập cloud từ xa vào các thiết kế chip bị kiểm soát xuất khẩu, coi việc truyền qua cloud như một điểm kiểm soát (Kharon). Các checklist bảo mật được viết riêng để đánh giá công cụ cloud PDM trong các ngành bị quản lý chặt hiện yêu cầu người mua xác minh audit log, quyền truy cập, hành vi chia sẻ ra bên ngoài, và — quan trọng nhất — yêu cầu làm rõ điều gì nhà cung cấp bảo vệ theo mặc định so với điều gì khách hàng phải tự cấu hình (CAD Rooms, checklist đánh giá bảo mật cloud PDM). Trong bối cảnh đó, “mặc định là cloud, on-premise nếu bạn yêu cầu tử tế” không chỉ là một sự lệch pha về sở thích UX — đó là một kiến trúc đặt gánh nặng tuân thủ lên đúng nhóm khách hàng ít có khả năng chấp nhận sai sót nhất.

Ngay cả hàng đợi công việc cũng tôn trọng ràng buộc này

Đây là chi tiết dễ bị bỏ qua nhưng nói lên nhiều nhất về mức độ nghiêm túc của “ưu tiên on-premise”: xử lý công việc nền của Zunavi — trích xuất OCR, tạo thumbnail, chuyển đổi file CAD, embedding cho tìm kiếm tương đồng — mặc định dùng một hàng đợi dựa trên PostgreSQL, sử dụng FOR UPDATE SKIP LOCKED để lấy job đồng thời an toàn, thay vì yêu cầu Redis ngay từ đầu. Redis có sẵn như một tùy chọn cho các đội chạy dưới tải nặng hơn, nhưng nó không phải phụ thuộc bắt buộc cho một bản cài đặt on-premise tối thiểu.

Điều đó có thể nghe như một chi tiết triển khai nhỏ, nhưng nó thay đổi những gì “cài đặt Zunavi trên máy chủ của chính chúng ta” thực sự đòi hỏi. Mỗi dịch vụ bắt buộc bổ sung là một hạ tầng khác mà đội IT của khách hàng on-premise phải cấp phát, vá lỗi, và biện minh trước bộ phận rà soát bảo mật. Một nền tảng quản lý bản vẽ chỉ cần PostgreSQL và không gì khác để chạy workflow cốt lõi là một câu “đồng ý” dễ dàng hơn về cơ bản đối với một nhà sản xuất có tư thế bảo mật coi mọi dịch vụ mới là thứ cần bị chất vấn.

Vì sao SaaS ưu tiên cloud là một sự lệch pha mang tính cấu trúc ở đây

Không có điều nào trong số này là phê phán kiến trúc ưu tiên cloud nói chung — với một phạm vi rất lớn phần mềm, đó là quyết định đúng đắn, và Zunavi cũng hỗ trợ triển khai CLOUD như một chế độ thực sự, được hỗ trợ đầy đủ cho các đội muốn dùng nó. Sự lệch pha ở đây rất cụ thể: một công cụ coi “file của bạn nằm trên máy chủ của chúng tôi” là một giả định cố định, với on-premise là một tier doanh nghiệp gắn thêm sau, đang tối ưu hóa cho một mô hình triển khai mà một phần đáng kể của ngành bán dẫn và sản xuất chính xác không thể mặc định sử dụng. Xây dựng on-premise như chế độ triển khai mặc định — không phải một đường xuống cấp, không phải một SKU đặc biệt — nghĩa là kiến trúc phải thực sự hỗ trợ nó một cách gọn gàng ngay từ đầu: lưu trữ cục bộ không phải là một lớp tương thích tạm bợ, hàng đợi công việc không giả định rằng một instance Redis được quản lý chỉ cách một cú click, và các tính năng cloud vẫn nằm sau sự đồng thuận, không phải sự tiện lợi.

Cách các nhà cung cấp PDM lâu đời nhìn nhận vấn đề này

Chúng tôi không phải người đầu tiên nhận ra sự phân tách này. Chính dòng sản phẩm của Autodesk minh họa điều đó: Vault vẫn là sản phẩm on-premise dành cho “các đội cam kết triển khai on-premise — vì yêu cầu về data residency, môi trường mạng air-gapped, hoặc quản trị CNTT” — trong khi sản phẩm PLM cloud mới hơn của Autodesk, Fusion Manage, hoàn toàn không có phiên bản on-premise (DemystifyingPLM, về sự chuyển dịch ưu tiên cloud của Autodesk; KETIV, về các tùy chọn triển khai Vault). Đó là hình ảnh thu nhỏ của khuôn mẫu toàn ngành: hỗ trợ on-premise có xu hướng nằm ở dòng sản phẩm cũ hơn, ít được đầu tư phát triển tích cực, trong khi đầu tư mới đổ vào các công cụ chỉ-cloud — đây chính xác là khoảng trống mà một nhà sản xuất bán dẫn cần cả công cụ hiện đại lẫn data residency sẽ rơi vào. Đây cũng là khoảng trống quan trọng hơn ở Nhật Bản so với những gì câu chuyện số hóa thường gợi ý: Sách trắng SME năm 2025 của METI (Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản) cho thấy 64,8% doanh nghiệp sản xuất vừa và nhỏ vẫn ở hai giai đoạn thấp nhất về mức độ trưởng thành số hóa, chỉ 3,2% đạt giai đoạn tiên tiến nhất — và bình luận ngành riêng biệt chỉ ra rằng các môi trường sản xuất đa dạng chủng loại, sản lượng thấp, nơi mỗi đơn hàng có bản vẽ và quy cách khác nhau, chính là nơi ngưỡng số hóa tăng vọt và các nỗ lực số hóa bị đình trệ (METI, Sách trắng SME 2025; The Worldfolio, về DX lấy bản vẽ làm trung tâm cho các SME sản xuất Nhật Bản). Một nền tảng nhắm vào thị trường này mà cũng đòi hỏi việc di chuyển lên cloud như một điều kiện tiên quyết đang buộc một xưởng phải giải quyết cùng lúc hai bài toán khó — số hóa, và chuyển lên cloud — trong khi mục tiêu ban đầu là làm cho bài toán đầu tiên trở nên khả thi khi đứng một mình.

Chi tiết đặc thù Nhật Bản mà các công cụ phương Tây thường bỏ lỡ

Có một vấn đề thầm lặng thứ hai về sự phù hợp thị trường mà các công cụ kỹ thuật phương Tây tổng quát thường gặp phải với nhóm khách hàng này: mã hóa ký tự và bản địa hóa. Rất nhiều dữ liệu bản vẽ trong môi trường sản xuất Nhật Bản — file xuất CAD cũ, file DXF cũ, văn bản trong khung tên — được mã hóa Shift-JIS thay vì UTF-8, và một trình xem giả định UTF-8 sẽ làm hỏng văn bản đó hoặc từ chối hiển thị hoàn toàn. Trình xem CAD của Zunavi được xây dựng dựa trên một trình xem đã được fork và vá cho tiếng Nhật, với hỗ trợ giải mã Shift-JIS và render font IPAexGothic tích hợp sẵn, để bản vẽ có khung tên và ghi chú tiếng Nhật hiển thị đúng thay vì hiện ký tự lỗi — một chi tiết nghe có vẻ nhỏ cho đến khi nó là lý do một công cụ thực sự không hoạt động được với những bản vẽ mà một xưởng đã sản xuất suốt hai mươi năm.

Tình hình hiện tại

Zunavi vẫn đang trong quá trình phát triển tích cực, và không có điều nào ở trên là tuyên bố rằng nền tảng đã được triển khai ở đâu đó ngày hôm nay — nó chưa được triển khai, và chúng tôi không đưa ra ngày phát hành cụ thể. Điều chúng tôi có thể nói một cách cụ thể là kiến trúc đang cam kết điều gì: on-premise là tư thế triển khai mặc định, không phải một ý nghĩ muộn màng dành cho doanh nghiệp, cho một ngành mà đó chính là toàn bộ vấn đề.

---

Liên quan: vì sao feature flag certain/optional của Zunavi quan trọng với dữ liệu kỹ thuật đáng tin cậy, vì sao chúng tôi xây dựng lại sổ đăng ký bản vẽ từ đầu, và bài giới thiệu gốc về Zunavi. Nếu triển khai on-premise cho dữ liệu kỹ thuật bảo mật là yêu cầu bạn đang phải giải quyết, chúng tôi rất muốn trao đổi thêm — [email protected].