Trang này được dịch từ tiếng Anh.
Hỗ trợ và cộng đồng
Xây dựng hệ thống báo lỗi và theo dõi sự cố
Kliv là công cụ xây dựng ứng dụng AI. Mô tả cách khách hàng báo lỗi, cách đội của bạn phân loại và xử lý, và khi nào người báo lỗi sẽ được phản hồi, Kliv sẽ xây dựng hệ thống theo đúng quy trình đó.
Chỉ cần nhập ý tưởng của bạn vào ô văn bản và AI sẽ xây nó cho bạn
Kliv là gì?
Kliv không phải là một công cụ theo dõi lỗi có sẵn với quy trình cố định — đó là một AI xây dựng phần mềm cho bạn.
Bạn mô tả ứng dụng mình cần bằng ngôn ngữ của riêng mình, và Kliv sẽ xây dựng nó: dữ liệu, quy trình làm việc, giao diện, tích hợp, thông báo và quy tắc phân quyền. Kết quả bạn nhận được là một ứng dụng thật sự thuộc về bạn. Bạn có thể sử dụng nó, thay đổi sau này chỉ bằng cách yêu cầu, và vận hành nó trên tài khoản của riêng mình. Đây không phải là một mẫu có sẵn.
Trên trang này, ứng dụng đó là một hệ thống báo lỗi và theo dõi sự cố. Kliv xây dựng đủ loại ứng dụng web; đây chỉ là một ví dụ.
Vì sao nên xây dựng hệ thống theo dõi lỗi của riêng bạn?
Một công ty dịch vụ quản lý nhiều sản phẩm cho khách hàng thường có hai thế giới tách biệt: công cụ theo dõi nội bộ mà lập trình viên sử dụng, và hộp thư nơi khách hàng báo lỗi. Lỗi được gửi qua email, ảnh chụp màn hình bị thất lạc, báo cáo phải gõ lại, và khách hàng không biết khi nào bản sửa lỗi được phát hành.
Một hệ thống theo dõi dành cho khách hàng phải phù hợp với mức độ nghiêm trọng, quy trình phát hành và quy tắc bảo mật riêng của bạn. Khách hàng A không bao giờ được thấy báo cáo của khách hàng B. Kliv xây dựng khâu tiếp nhận, ranh giới giữa các khách hàng, phân loại, bàn giao cho lập trình viên và thông báo phát hành thành một quy trình duy nhất.
Hệ thống theo dõi lỗi nắm được những gì
Những dữ liệu này biến một hộp thư thành một hệ thống báo lỗi.
Báo cáo lỗi
Các bước tái hiện lỗi, môi trường, kết quả mong đợi, kết quả thực tế, ảnh chụp màn hình và video được thu thập qua một biểu mẫu đặt đúng các câu hỏi tiếp nhận của bạn.
Ranh giới giữa khách hàng
Mỗi báo cáo thuộc về một khách hàng và một sản phẩm cụ thể. Một khách hàng đã đăng nhập chỉ thấy báo cáo của sản phẩm mình, không thấy gì khác, được đảm bảo bởi các quy tắc phân quyền trên dữ liệu.
Mức độ nghiêm trọng và thời hạn
Một lỗi nghiêm trọng có thể kích hoạt đồng hồ phản hồi 4 giờ, trong khi một lỗi thẩm mỹ nhỏ có thể để dành cho bản phát hành tiếp theo. Thời hạn được tính dựa trên điều khoản dịch vụ của bạn ngay khi báo cáo được gửi.
Lỗi đã biết
Khi khách hàng gõ nội dung, tìm kiếm ngữ nghĩa có thể hiển thị các báo cáo tương tự cho sản phẩm đó: đã biết, đã sửa, hoặc thực sự mới. Các báo cáo trùng lặp được gộp lại mà không làm mất thông tin của bất kỳ người báo lỗi nào.
Bản phát hành
Các bản sửa lỗi được gắn vào một bản phát hành. Khi phiên bản 2.4.1 ra mắt, mọi lỗi trong bản phát hành đó có thể tự động đổi trạng thái và gửi email cho người báo lỗi.
Một ví dụ: Cổng hỗ trợ khách hàng của Linh
Đây là cách một công ty dịch vụ có thể sử dụng nó. Đây chỉ là một ví dụ — bạn sẽ mô tả khách hàng, sản phẩm, mức độ nghiêm trọng, công cụ và quy trình phát hành của riêng mình.
Khách hàng gửi báo cáo kèm bằng chứng
Một kế toán viên báo lỗi xuất hóa đơn từ cổng thông tin khách hàng của mình. Chị thêm các bước thực hiện, thông tin trình duyệt và một ảnh chụp màn hình. Biểu mẫu đã biết sản phẩm của chị, nên lỗi được gửi đúng chỗ.
Một lỗi trùng lặp được phát hiện sớm
Trước khi gửi, chị thấy một báo cáo tương tự từ một đồng nghiệp dùng chung sản phẩm. Chị thêm trường hợp của mình vào lỗi đó thay vì mở một báo cáo trùng.
Mức độ nghiêm trọng xác định đồng hồ phản hồi
Linh, trưởng nhóm phụ trách, đánh dấu lỗi này là nghiêm trọng vừa. Thời hạn phản hồi bắt đầu tính theo điều khoản dịch vụ của công ty, và báo cáo được đưa vào bảng làm việc của đội theo đúng các trạng thái họ đang dùng.
Lập trình viên vẫn làm việc trên công cụ của mình
Báo cáo tạo ra một issue trên Linear. Khi kỹ sư đóng issue đó, trạng thái được đồng bộ ngược về cổng thông tin khách hàng. Khách hàng và lập trình viên nhìn thấy cùng một sự thật trên hai công cụ khác nhau.
Người báo lỗi được biết khi lỗi được sửa xong
Bản sửa lỗi được phát hành trong phiên bản 2.4.1. Báo cáo chuyển sang trạng thái đã sửa, và kế toán viên nhận được email nêu rõ phiên bản trước khi chị kịp hỏi lại.
Mô tả ứng dụng bạn muốn xây dựng
Kliv xây dựng dựa trên mô tả của bạn, nên càng chi tiết thì phiên bản đầu tiên càng sát với ý bạn. Hãy nêu rõ ai gửi báo cáo, bạn thu thập bằng chứng gì, mức độ nghiêm trọng hoạt động ra sao, và bản sửa lỗi được phát hành như thế nào. Đây là ba ví dụ để bạn tham khảo:
Tiếp nhận lỗi từ khách hàng của công ty dịch vụ
Cổng khách hàng, thời hạn theo mức độ nghiêm trọng, tệp đính kèm và bản phát hành.
“Xây dựng hệ thống theo dõi lỗi cho công ty dịch vụ của chúng tôi. Mỗi khách hàng nên có một cổng thông tin chỉ giới hạn trong sản phẩm của họ, báo cáo nên bao gồm ảnh chụp màn hình và video quay màn hình, mức độ nghiêm trọng nên xác định thời hạn phản hồi là 4 giờ cho lỗi nghiêm trọng và 2 ngày làm việc cho lỗi nghiêm trọng vừa, và người báo lỗi nên nhận email khi bản sửa lỗi của họ được phát hành.”
Bảng theo dõi QA nội bộ
Bản build, đánh dấu lỗi tái phát và tổng hợp hằng ngày.
“Xây dựng một hệ thống theo dõi lỗi nội bộ nơi đội QA báo lỗi theo từng bản build cụ thể, các lỗi mở lại được đánh dấu là tái phát, lỗi nghiêm trọng gửi cảnh báo Slack ngay lập tức, và một bản tổng hợp hằng ngày về lỗi nghiêm trọng và nghiêm trọng vừa mới phát sinh được gửi đến kênh kỹ thuật lúc 9 giờ sáng.”
Kênh tiếp nhận phản hồi bản beta
Phản hồi được phân loại thành lỗi, ý tưởng và trùng lặp.
“Xây dựng một hệ thống tiếp nhận phản hồi bản beta nơi người dùng thử nghiệm gửi báo cáo kèm ảnh chụp màn hình, một người phân loại sắp xếp từng mục thành lỗi, ý tưởng tính năng, trùng lặp hoặc câu hỏi, và mỗi người thử nghiệm có thể xem trạng thái của những gì họ đã tự gửi.”
Tất cả kết hợp lại như thế nào
Ranh giới giữa khách hàng luôn được giữ vững. Tổ chức khách hàng và vai trò được xây dựng sẵn. Người báo lỗi chỉ thấy lỗi của sản phẩm mình, đội của bạn thấy toàn bộ, và ghi chú nội bộ luôn ở lại nội bộ.
Công cụ của lập trình viên có thể kết nối hai chiều. Báo cáo có thể tạo issue trên Linear hoặc GitHub, và việc đóng issue ở đó có thể cập nhật cổng thông tin. Lập trình viên vẫn làm việc trên công cụ quen thuộc trong khi khách hàng có một giao diện gọn gàng hơn.
Ranh giới có thể được kiểm thử. Một Scenario test có thể đăng nhập với vai một khách hàng và thử đọc báo cáo của khách hàng khác trên một bản sao cơ sở dữ liệu dùng một lần. Biên bản kiểm thử cho thấy điều gì đã bị từ chối trước khi phát hành.
Bản tổng hợp hằng tháng có thể tự chạy. Một tác vụ định kỳ có thể gửi email cho từng khách hàng với số liệu lỗi đã gửi, đã sửa, đang xử lý và thời gian phản hồi trung bình trong tháng.
Khi mô hình này hiệu quả, nhiều đội thường muốn áp dụng cách làm tương tự cho nhật ký thời gian và báo cáo tình trạng. Cách làm đó tiếp tục ở công cụ nội bộ.
Các câu hỏi thường gặp
Kliv chính xác là gì?
Kliv là một AI xây dựng ứng dụng web tùy chỉnh từ một mô tả. Đối với theo dõi lỗi, điều đó có thể bao gồm cổng thông tin khách hàng, biểu mẫu tiếp nhận, quy tắc mức độ nghiêm trọng, kết nối với công cụ của lập trình viên, bản phát hành và thông báo.
Tôi nhận được một ứng dụng thật, hay chỉ là một mẫu có sẵn?
Một ứng dụng thật. Kliv xây dựng quy trình làm việc, dữ liệu, giao diện, quy tắc phân quyền và tích hợp riêng cho trường hợp của bạn, không phải một lớp vỏ của một công cụ theo dõi lỗi chung chung.
Tôi có thể thay đổi nó sau khi đã xây dựng xong không?
Có. Bạn có thể yêu cầu thay đổi như thêm mức độ nghiêm trọng mới, vai trò khách hàng khác, thêm trường đính kèm, hoặc thay đổi quy trình phát hành.
Tại sao không cho khách hàng truy cập thẳng vào công cụ theo dõi lỗi nội bộ của chúng tôi?
Công cụ theo dõi nội bộ của bạn chứa chi tiết kỹ thuật và thông tin của nhiều khách hàng khác nhau. Một cổng thông tin riêng cho khách hàng mang lại đúng góc nhìn họ cần trong khi vẫn giữ nguyên quy trình nội bộ của bạn.
Khách hàng có thể thấy báo cáo của nhau không?
Không. Mỗi báo cáo gắn với tổ chức khách hàng ngay trên dòng dữ liệu, và các quy tắc phân quyền đảm bảo ranh giới đó ở mọi lần đọc dữ liệu.
Người báo lỗi có thể đính kèm những gì?
Ảnh chụp màn hình, video quay màn hình, tệp nhật ký và các bằng chứng khác. Tệp đính kèm dùng chung quy tắc phân quyền với báo cáo mà chúng thuộc về.
Chúng tôi có bắt buộc phải dùng Linear không?
Không. GitHub có thể hoạt động tương tự, hoặc đội của bạn có thể dùng bảng làm việc được xây dựng sẵn trong ứng dụng. Khâu tiếp nhận, ranh giới khách hàng và email phát hành không phụ thuộc vào Linear.
Hệ thống có thể phát hiện lỗi trùng lặp không?
Có. Các báo cáo tương tự cho cùng một sản phẩm có thể hiện ra ngay khi người báo lỗi đang gõ, và các báo cáo trùng lặp có thể được gộp lại mà không làm mất thông tin của bất kỳ người báo lỗi nào.
Người báo lỗi có thể được biết khi bản sửa lỗi được phát hành không?
Có. Bản sửa lỗi có thể được gắn vào bản phát hành, và việc phát hành có thể tự động cập nhật trạng thái lỗi và gửi email cho từng người báo lỗi.
Tôi có thể dùng tên miền riêng của mình không?
Có. Cổng thông tin có thể chạy trên tên miền riêng của bạn.
Tôi có thể chuyển khỏi Kliv sau này không?
Có. Mã nguồn ứng dụng được đồng bộ về kho Git riêng của bạn, và dữ liệu của bạn có thể được xuất ra.
Tôi có cần một công cụ quản trị riêng không?
Không. Hệ thống theo dõi lỗi tự nó là công cụ quản trị cho sản phẩm, khách hàng, báo cáo, bản phát hành, vai trò và cài đặt.
Được xây dựng bởi nhà sáng tạo
Khám phá điều có thể
Xem các ứng dụng thật được xây dựng với Kliv bởi nhà phát triển và nhà sáng tạo trên toàn thế giới
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Chấm dứt cảnh báo lỗi qua email
Hãy mô tả khách hàng, sản phẩm, câu hỏi tiếp nhận, thời hạn theo mức độ nghiêm trọng, công cụ của lập trình viên và quy trình phát hành của bạn càng chi tiết càng tốt. Kliv sẽ xây dựng hệ thống theo dõi lỗi với ranh giới đã được thiết lập sẵn.