> Cải tiến quy trình liên tục > Vòng đời phát triển phần mềm > ServiceNow DevOps > Mẫu dữ liệu

Mẫu dữ liệu vòng đời phát triển phần mềm

ServiceNow DevOps

Thuộc tính vòng đời phát triển phần mềm(18) Hoạt động trong vòng đời phát triển phần mềm(16) Hướng dẫn trích xuất dữ liệu(2)

Mẫu dữ liệu vòng đời phát triển phần mềm

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để tối ưu vòng đời phát triển phần mềm. Tài liệu nêu rõ các thuộc tính cần thu thập, hoạt động chính cần theo dõi và cách trích xuất dữ liệu từ ServiceNow DevOps. Dùng tài nguyên này để tạo event log phục vụ phân tích quy trình.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi
Hướng dẫn trích xuất dữ liệu từ ServiceNow DevOps

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính vòng đời phát triển phần mềm

Đây là các trường dữ liệu nên có trong event log để phân tích vòng đời phát triển phần mềm.

5 Bắt buộc 8 Nên có 5 Không bắt buộc

	Tên	Mô tả
	Hạng mục phát triển DevelopmentItem	Mã định danh duy nhất cho một đơn vị công việc, chẳng hạn tính năng, lỗi hoặc tác vụ, được theo dõi xuyên suốt vòng đời phát triển.
Mô tả Hạng mục phát triển là mã định danh chính cho từng trường hợp, đại diện cho một đơn vị công việc riêng biệt được theo dõi. Hạng mục này liên kết mọi hoạt động, từ lúc hình thành ý tưởng và lập kế hoạch đến phát triển, kiểm thử và triển khai. Trong phân tích process mining, thuộc tính này là nền tảng để dựng lại toàn bộ hành trình của từng hạng mục công việc. Thuộc tính giúp trực quan hóa luồng quy trình, tính tổng thời gian chu kỳ và xác định các biến thể quy trình của từng tính năng hoặc bản sửa lỗi. Mỗi sự kiện trong nhật ký phải gắn với một hạng mục phát triển để tạo bản đồ quy trình nhất quán. Vì sao điều này quan trọng Đây là mã định danh cốt lõi, kết nối mọi hoạt động phát triển liên quan thành một phiên bản quy trình duy nhất, giúp phân tích toàn bộ vòng đời của từng hạng mục công việc. Lấy dữ liệu ở đâu Mã định danh này thường là khóa chính trong các bảng quản lý story, lỗi hoặc tác vụ, chẳng hạn bảng 'rm_story', 'rm_bug' hoặc 'task' trong ServiceNow. Ví dụ STRY0010015BUG0034092TASK0050118
	Tên hoạt động ActivityName	Tên của sự kiện cụ thể trong vòng đời phát triển đã diễn ra, chẳng hạn 'Bắt đầu phát triển' hoặc 'Hoàn tất đánh giá mã'.
Mô tả Thuộc tính này ghi lại tên của từng cột mốc hoặc tác vụ đã hoàn thành trong vòng đời phát triển phần mềm. Các hoạt động này tạo thành những bước tuần tự của quy trình, từ lúc tạo hạng mục đến khi triển khai. Phân tích trình tự và tần suất của các hoạt động này là chức năng chính của process mining. Việc này giúp dựng bản đồ quy trình, phát hiện điểm nghẽn giữa các bước và làm rõ những biến thể quy trình không tuân thủ hoặc kém hiệu quả. Danh sách hoạt động đã xác định gồm các giai đoạn chính như thiết kế, phát triển, kiểm thử và triển khai. Vì sao điều này quan trọng Thuộc tính này xác định các bước trên bản đồ quy trình, giúp phân tích luồng quy trình, phát hiện điểm nghẽn và tìm ra sai lệch so với SDLC tiêu chuẩn. Lấy dữ liệu ở đâu Thông thường, thuộc tính này được xác định bằng cách ánh xạ thay đổi trạng thái, bản ghi sự kiện hoặc mục trong nhật ký kiểm tra vào danh sách tên hoạt động tiêu chuẩn. Ví dụ, khi trường 'state' chuyển sang 'In Progress', sự kiện có thể được ánh xạ thành 'Bắt đầu phát triển'. Ví dụ Bắt đầu phát triểnĐã commit mãHoàn tất kiểm thử QAĐã triển khai lên production
	Thời gian bắt đầu EventTime	Dấu thời gian chính xác cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra.
Mô tả Thuộc tính này ghi ngày giờ của từng hoạt động trong vòng đời phát triển. Đây là thông tin cần thiết để sắp xếp sự kiện theo thời gian và thực hiện mọi phân tích dựa trên thời lượng. Trong process mining, thời gian bắt đầu được dùng để tính khoảng thời gian giữa các hoạt động, xác định thời gian chờ và đo tổng thời gian chu kỳ của quy trình. Đây là thành phần quan trọng trong các bảng điều khiển phân tích hiệu suất, chẳng hạn SDLC End-to-End Cycle Time Analysis, và để tính KPI như Code Review Lead Time. Vì sao điều này quan trọng Dấu thời gian này cần thiết để sắp xếp sự kiện chính xác và tính mọi chỉ số hiệu suất, bao gồm thời gian chu kỳ, thời lượng và thời gian chờ. Lấy dữ liệu ở đâu Thường có trong các trường dấu thời gian do hệ thống tạo, như 'sys_updated_on' hoặc 'sys_created_on' trong nhật ký kiểm tra hoặc bảng tác vụ. Ví dụ 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
	Hệ thống nguồn SourceSystem	Xác định hệ thống cung cấp dữ liệu được trích xuất, trong trường hợp này là ServiceNow DevOps.
Mô tả Thuộc tính này cho biết hệ thống nguồn của dữ liệu sự kiện. Với quy trình này, giá trị luôn là 'ServiceNow DevOps'. Dù có vẻ là thông tin cố định, việc ghi rõ hệ thống nguồn rất quan trọng đối với quản trị dữ liệu và các môi trường gộp dữ liệu từ nhiều hệ thống, chẳng hạn Jira hoặc Azure DevOps. Thông tin này làm rõ nguồn gốc dữ liệu và giúp tìm nguyên nhân khi có vấn đề về chất lượng dữ liệu hoặc trích xuất. Vì sao điều này quan trọng Giúp truy xuất nguồn gốc dữ liệu và bảo đảm tính toàn vẹn của dữ liệu, đặc biệt khi tích hợp dữ liệu từ nhiều công cụ phát triển. Lấy dữ liệu ở đâu Đây là giá trị cố định cần được thêm vào trong quá trình trích xuất và chuyển đổi dữ liệu. Ví dụ ServiceNow DevOps
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất dữ liệu của nhật ký sự kiện này được làm mới từ hệ thống nguồn.
Mô tả Thuộc tính này ghi lại thời điểm bộ dữ liệu được trích xuất hoặc cập nhật gần nhất từ ServiceNow DevOps. Thuộc tính áp dụng cho toàn bộ bộ dữ liệu, không phải từng sự kiện riêng lẻ. Dấu thời gian này giúp bạn biết dữ liệu phân tích mới đến đâu. Thông tin cho người dùng biết các kết quả phân tích quy trình được cập nhật đến thời điểm nào và hỗ trợ lên lịch làm mới dữ liệu. Hiển thị thông tin này trên bảng điều khiển giúp người xem hiểu bối cảnh của các chỉ số và hình ảnh trực quan, để đưa ra quyết định dựa trên dữ liệu kịp thời. Vì sao điều này quan trọng Cho biết dữ liệu được cập nhật đến thời điểm nào, giúp người dùng hiểu mức độ mới của kết quả phân tích quy trình. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và thêm trong quá trình trích xuất dữ liệu, ghi lại thời điểm trích xuất được thực hiện. Ví dụ 2023-11-15T08:00:00Z
	Có làm lại IsRework	Cờ boolean có giá trị đúng nếu hoạt động thuộc một vòng lặp làm lại, chẳng hạn như quay lại bước phát triển sau khi kiểm thử.
Mô tả Đây là thuộc tính được suy ra để xác định các hoạt động diễn ra sau khi quy trình quay lại một giai đoạn trước đó. Ví dụ, nếu hoạt động “Bắt đầu phát triển” diễn ra sau hoạt động “Hoàn tất kiểm thử QA” của cùng một hạng mục, hoạt động đó sẽ được đánh dấu là làm lại. Cờ này rất cần thiết để định lượng và trực quan hóa việc làm lại. Cờ hỗ trợ trực tiếp cho bảng điều khiển “Phân tích luồng làm lại và từ chối” và được dùng để tính KPI “Tỷ lệ làm lại sau kiểm thử”. Khi các sự kiện được đánh dấu, chuyên viên phân tích có thể dễ dàng lọc và phân tích tần suất, nguyên nhân cũng như tác động của việc làm lại đến tổng thời gian chu kỳ. Vì sao điều này quan trọng Cờ này giúp định lượng và phân tích việc làm lại, từ đó đo lường chất lượng quy trình và xác định nguyên nhân gốc rễ của công việc lặp lại. Lấy dữ liệu ở đâu Công cụ process mining tính thuộc tính này bằng cách phân tích thứ tự hoạt động trong từng trường hợp để phát hiện các bước quay ngược trong luồng quy trình. Ví dụ truefalse
	Loại hạng mục phát triển DevelopmentItemType	Phân loại hạng mục công việc, chẳng hạn như “Tính năng”, “Lỗi”, “Nợ kỹ thuật” hoặc “Tác vụ”.
Mô tả Thuộc tính này phân biệt các loại công việc khác nhau trong quy trình SDLC. Chẳng hạn, quy trình sửa lỗi nghiêm trọng có thể khác và nhanh hơn quy trình phát triển tính năng mới. Phân tích quy trình theo loại hạng mục công việc giúp bạn hiểu rõ hơn về hiệu suất. Cách phân đoạn này giúp trả lời những câu hỏi như: “Lỗi có tỷ lệ làm lại cao hơn tính năng mới không?” hoặc “Thời gian chu kỳ để giảm nợ kỹ thuật có hợp lý không?”. Nhờ đó, bạn có được góc nhìn sâu hơn so với việc xem mọi công việc như nhau. Vì sao điều này quan trọng Phân biệt các loại công việc như tính năng và lỗi, vốn có thể đi theo những luồng quy trình, mức độ ưu tiên và thời lượng dự kiến khác nhau. Lấy dữ liệu ở đâu Có thể xác định loại hạng mục từ bảng nguồn của bản ghi (ví dụ: “rm_story” và “rm_bug”) hoặc từ trường “type” trong bảng tác vụ dùng chung. Ví dụ Tính năngLỗiNhiệm vụNghiên cứu thử nghiệm
	Mô-đun/thành phần bị ảnh hưởng ModuleComponentAffected	Mô-đun phần mềm, ứng dụng hoặc thành phần cụ thể liên quan đến hạng mục phát triển.
Mô tả Thuộc tính này phân loại công việc phát triển theo phần của hệ thống chịu tác động. Đó có thể là một microservice, thành phần giao diện người dùng hoặc ứng dụng backend cụ thể. Phân đoạn quy trình theo mô-đun hoặc thành phần rất quan trọng để xác định điểm nghẽn ở từng khu vực. Bảng điều khiển “Thông tin điểm nghẽn theo thành phần” và KPI “Thời lượng trung bình mỗi giai đoạn theo thành phần” dùng thuộc tính này để xác định liệu một số phần của mã nguồn có thường đi kèm chu kỳ phát triển dài hơn, tỷ lệ làm lại cao hơn hoặc nhiều lần triển khai thất bại hơn hay không. Nhờ đó, bạn có thể tập trung cải tiến vào những nơi cần nhất. Vì sao điều này quan trọng Cho phép phân đoạn phân tích theo ứng dụng hoặc thành phần, giúp xác định điểm nghẽn hay vấn đề chất lượng ở những phần cụ thể của hệ thống. Lấy dữ liệu ở đâu Đây thường là trường tùy chỉnh hoặc tham chiếu đến Cơ sở dữ liệu quản lý cấu hình (CMDB), liên kết hạng mục công việc với bản ghi “cmdb_ci”. Tham khảo tài liệu ServiceNow DevOps. Ví dụ Dịch vụ thanh toánGiao diện người dùng xác thựcCơ sở dữ liệu báo cáoCổng API
	Mức độ ưu tiên DevelopmentItemPriority	Mức độ ưu tiên được gán cho hạng mục phát triển, chẳng hạn 'Cao', 'Trung bình' hoặc 'Thấp'.
Mô tả Thuộc tính này phân loại hạng mục phát triển theo mức độ cấp thiết đối với doanh nghiệp. Mức độ ưu tiên giúp đội ngũ tập trung vào các tác vụ quan trọng nhất và thường được dùng để quản lý SLA cũng như kỳ vọng của các bên liên quan. Trong process mining, mức độ ưu tiên là chiều phân tích quan trọng. Bạn có thể lọc bản đồ quy trình để xem các hạng mục ưu tiên cao có đi theo lộ trình nhanh hơn hoặc khác biệt hay không. Thuộc tính này cần thiết cho bảng điều khiển và KPI 'Thời gian bàn giao tính năng ưu tiên cao', giúp xác minh liệu các hạng mục quan trọng có thực sự được xử lý nhanh hơn hay không. Vì sao điều này quan trọng Cho phép lọc và so sánh quy trình theo từng mức độ ưu tiên, giúp xác minh liệu các hạng mục ưu tiên cao có được xử lý nhanh và hiệu quả hơn hay không. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn, thường có tên 'priority', trong các bảng liên quan đến tác vụ của ServiceNow. Ví dụ 1 - Quan trọng nhất2 - Cao3 - Trung bình4 - Thấp
	Nhà phát triển được giao AssignedDeveloper	Tên hoặc mã người dùng của nhà phát triển được giao hạng mục phát triển tại thời điểm hoạt động diễn ra.
Mô tả Thuộc tính này xác định người chịu trách nhiệm thực hiện một tác vụ hoặc hoạt động cụ thể. Giá trị có thể thay đổi khi hạng mục phát triển chuyển qua các giai đoạn và đội ngũ khác nhau. Thuộc tính này rất quan trọng để phân tích việc phân bổ tài nguyên, khối lượng công việc và các lần bàn giao. Thuộc tính hỗ trợ trực tiếp cho bảng điều khiển 'Khối lượng công việc và bàn giao giữa các nhà phát triển' và KPI 'Số lượng hoạt động trên mỗi nhà phát triển'. Theo dõi thay đổi ở trường này giúp đo thời gian bàn giao và phát hiện điểm nghẽn trong phối hợp giữa các nhà phát triển hoặc giữa đội phát triển và đội QA. Vì sao điều này quan trọng Thông tin này cần thiết để phân tích theo tài nguyên, bao gồm phân bổ khối lượng công việc, hiệu quả bàn giao và các kiểu hiệu suất riêng của từng đội. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong trường 'assigned_to' của các bảng liên quan đến tác vụ trong ServiceNow. Ví dụ David MillerAnna WilliamsJames Brown
	Nhóm được giao AssignmentGroup	Nhóm chịu trách nhiệm về hạng mục phát triển tại thời điểm diễn ra hoạt động.
Mô tả Thuộc tính này xác định nhóm được giao xử lý hạng mục công việc, chẳng hạn như “Nhóm phát triển frontend”, “Nhóm dịch vụ backend” hoặc “Nhóm QA”. Khi hạng mục tiến triển, công việc thường được chuyển giữa các nhóm được giao khác nhau. Theo dõi nhóm được giao là điều cần thiết để hiểu sự phối hợp giữa các nhóm chức năng và các lần bàn giao. Thuộc tính này giúp xác định những chậm trễ mang tính hệ thống khi công việc chuyển từ nhóm này sang nhóm khác. Bạn cũng có thể dùng thuộc tính này để phân tích hiệu suất, khối lượng công việc của từng nhóm và xác định nhóm nào đang tạo điểm nghẽn trong toàn bộ luồng. Vì sao điều này quan trọng Theo dõi nhóm chịu trách nhiệm xử lý công việc, giúp phân tích hiệu suất nhóm, cân bằng khối lượng công việc và hiệu quả bàn giao giữa các nhóm. Lấy dữ liệu ở đâu Thông tin này được lưu trong trường “assignment_group”, một trường tiêu chuẩn trong các bảng liên quan đến tác vụ của ServiceNow. Ví dụ Kỹ thuật nền tảngNhóm ứng dụng di độngĐảm bảo chất lượngDevOps
	Thời gian chu kỳ của hạng mục phát triển DevelopmentItemCycleTime	Tổng thời gian từ khi tạo hạng mục phát triển đến khi đóng hoặc triển khai xong.
Mô tả Đây là chỉ số được tính để thể hiện tổng thời lượng từ đầu đến cuối của một hạng mục phát triển. Chỉ số này được tính bằng cách lấy dấu thời gian của hoạt động đầu tiên trừ cho dấu thời gian của hoạt động cuối cùng trong từng trường hợp. Đây là KPI hiệu suất chính của toàn bộ quy trình SDLC và hỗ trợ trực tiếp cho KPI “Thời gian chu kỳ SDLC trung bình”. Chỉ số này cho biết tổng quan về tốc độ và hiệu quả của quy trình. Phân tích chỉ số theo thời gian và theo các khía cạnh như mức độ ưu tiên hoặc nhóm giúp bạn theo dõi tác động của các sáng kiến cải tiến quy trình. Vì sao điều này quan trọng Thể hiện tổng thời lượng từ đầu đến cuối của một hạng mục công việc. Đây là chỉ số quan trọng để đo lường hiệu quả và tốc độ chung của quy trình. Lấy dữ liệu ở đâu Đây không phải là trường trong hệ thống nguồn. Công cụ process mining tính chỉ số này bằng cách lấy StartTime lớn nhất trừ StartTime nhỏ nhất cho từng CaseId. Ví dụ 15 ngày 4 giờ3 ngày 12 giờ32 ngày 8 giờ
	Trạng thái hạng mục phát triển DevelopmentItemState	Trạng thái của hạng mục phát triển tại thời điểm diễn ra sự kiện, chẳng hạn như “Đang mở”, “Đang thực hiện” hoặc “Đã đóng”.
Mô tả Thuộc tính này thể hiện trạng thái chính thức của hạng mục phát triển trong ServiceNow. Hoạt động là các bước được suy ra từ quy trình, còn trạng thái cho biết giai đoạn chính thức trong workflow của hệ thống. Trạng thái thường là dữ liệu nguồn để suy ra các hoạt động. Bạn có thể dùng thuộc tính này để kiểm tra dữ liệu và tạo góc nhìn tổng quan, đơn giản hơn về quy trình. Chẳng hạn, phân tích thời gian ở từng trạng thái sẽ cho thấy điểm nghẽn theo một cách khác với việc phân tích thời gian giữa các hoạt động. Thuộc tính này cũng giúp xác định hạng mục bị đình trệ hoặc đã được xử lý. Vì sao điều này quan trọng Cho biết trạng thái chính thức của hạng mục công việc trong hệ thống. Đây thường là dữ liệu nguồn để suy ra hoạt động, đồng thời có thể dùng để kiểm tra dữ liệu và phân tích trạng thái ở mức tổng quan. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn, thường có tên “state” hoặc “stage”, trong các bảng liên quan đến tác vụ của ServiceNow. Ví dụ Đang chờĐang thực hiệnSẵn sàng kiểm thửĐã đóng, hoàn tất
	ID commit CommitId	Mã định danh duy nhất của commit mã nguồn liên quan đến công việc phát triển.
Mô tả Thuộc tính này liên kết trực tiếp hạng mục phát triển với thay đổi mã cụ thể trong kho mã nguồn như Git. Hệ thống ghi nhận thuộc tính này khi hoạt động “Đã commit mã” diễn ra. Trong process mining, ID commit bổ sung dữ liệu kỹ thuật vào phân tích quy trình. Thuộc tính này giúp chuyên viên phân tích truy ngược một lần triển khai có vấn đề về đúng thay đổi mã gây ra sự cố, hoặc đối chiếu độ phức tạp của mã với thời gian chu kỳ phát triển. Nhờ đó, bạn có thể phân tích nguyên nhân gốc rễ ở mức kỹ thuật chi tiết hơn. Vì sao điều này quan trọng Liên kết sự kiện quy trình với một thay đổi mã cụ thể, giúp phân tích nguyên nhân gốc rễ sâu hơn bằng cách đối chiếu chỉ số quy trình với chi tiết ở cấp mã nguồn. Lấy dữ liệu ở đâu ServiceNow DevOps ghi nhận thông tin này thông qua các tích hợp với hệ thống quản lý mã nguồn như Git hoặc SVN. Dữ liệu nằm trong các bảng liên quan được liên kết với hạng mục phát triển. Ví dụ a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
	Lý do làm lại ReworkReason	Phân loại hoặc mô tả lý do hạng mục phát triển phải làm lại sau khi kiểm thử.
Mô tả Khi một hạng mục không đạt QA hoặc UAT, thuộc tính này ghi lại lý do. Đó có thể là một nhóm lỗi cụ thể, yêu cầu bị hiểu sai hoặc vấn đề về môi trường. Thông tin này cung cấp bối cảnh quan trọng cho bảng điều khiển “Phân tích luồng làm lại và từ chối”. Thay vì chỉ biết có việc làm lại, chuyên viên phân tích còn hiểu được nguyên nhân. Nhờ đó, bạn có thể cải tiến đúng trọng tâm, chẳng hạn như làm rõ yêu cầu, tăng cường kiểm thử đơn vị hoặc ổn định môi trường kiểm thử để giảm tỷ lệ làm lại. Vì sao điều này quan trọng Cho biết nguyên nhân làm lại, giúp bạn cải tiến quy trình có trọng tâm để nâng cao chất lượng và giảm các vòng lặp làm lại. Lấy dữ liệu ở đâu Thông tin này có thể được ghi trong trường “close_notes” khi kiểm thử thất bại hoặc trong trường tùy chỉnh riêng “rework_reason”. Tham khảo tài liệu ServiceNow DevOps. Ví dụ Hiểu sai yêu cầuLỗi hồi quyKhông đạt kiểm thử hiệu năngVấn đề về UI/UX
	Phiên bản phát hành dự kiến PlannedReleaseVersion	Bản phát hành hoặc phiên bản phần mềm dự kiến sẽ bàn giao hạng mục phát triển.
Mô tả Thuộc tính này liên kết hạng mục phát triển với một bản phát hành đã lên kế hoạch cụ thể, chẳng hạn như “Phiên bản 2.3” hoặc “Bản phát hành quý 4 năm 2023”. Đây là yếu tố quan trọng trong quản lý dự án và lập kế hoạch phát hành. Trong process mining, thuộc tính này rất cần thiết cho bảng điều khiển “Theo dõi mức độ tuân thủ kế hoạch phát hành”. Bằng cách so sánh ngày hoàn tất thực tế với ngày phát hành dự kiến, các nhóm có thể đo lường mức độ đúng tiến độ, xác định hạng mục có nguy cơ lỡ đợt phát hành và phân tích nguyên nhân chậm trễ. Thuộc tính này kết nối trực tiếp quy trình phát triển ở cấp độ chi tiết với mục tiêu kinh doanh ở cấp độ tổng quan. Vì sao điều này quan trọng Liên kết công việc phát triển với từng bản phát hành cụ thể, giúp phân tích mức độ đúng tiến độ và tác động của chậm trễ quy trình đến lịch phát hành. Lấy dữ liệu ở đâu Thông tin này thường được lưu trong trường “release” hoặc “planned_release”, thường tham chiếu đến bảng quản lý bản phát hành trong ServiceNow. Tham khảo tài liệu ServiceNow DevOps. Ví dụ v3.4.1Bản phát hành quý 1 năm 2024Đưa Project Phoenix vào vận hành
	Thời gian kết thúc EventEndTime	Dấu thời gian chính xác cho biết thời điểm một hoạt động hoàn tất. Với sự kiện diễn ra tức thời, thời gian này trùng với thời gian bắt đầu.
Mô tả Thuộc tính này ghi ngày giờ hoàn tất của từng hoạt động trong vòng đời phát triển. Thuộc tính đặc biệt hữu ích với những hoạt động có thời lượng đo được, chẳng hạn 'Hoàn tất đánh giá mã' hoặc 'Kiểm thử QA'. Trong process mining, có cả thời gian bắt đầu và kết thúc giúp tính chính xác thời gian xử lý hoạt động, tách biệt với thời gian chờ giữa các hoạt động. Nhờ đó, bạn có thể xác định chậm trễ đến từ tác vụ kéo dài hay thời gian chờ tài nguyên. Với sự kiện diễn ra tức thời như 'Kích hoạt bản dựng', thời gian kết thúc có thể trùng với thời gian bắt đầu. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý hoạt động, qua đó phân biệt thời gian làm việc với thời gian chờ. Lấy dữ liệu ở đâu Có thể cần suy ra giá trị này. Bạn có thể dùng dấu thời gian bắt đầu của hoạt động tiếp theo hoặc lấy từ một trường 'end date' riêng nếu hệ thống nguồn có trường này. Ví dụ 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
	Trạng thái triển khai DeploymentStatus	Cho biết kết quả của một hoạt động triển khai, thường là “Thành công” hoặc “Thất bại”.
Mô tả Thuộc tính này ghi lại kết quả triển khai vào một môi trường cụ thể. Đây là thông tin quan trọng để hiểu độ tin cậy và tính ổn định của quy trình phát hành. Thuộc tính này cần thiết cho bảng điều khiển “Xu hướng triển khai thành công và thất bại” và KPI “Tỷ lệ triển khai thất bại”. Phân tích tần suất và xu hướng triển khai thất bại giúp tổ chức xác định vấn đề tiềm ẩn trong kiểm thử, hạ tầng hoặc phối hợp phát hành. Từ đó, các nhóm có thể tập trung cải thiện chất lượng và độ tin cậy khi bàn giao phần mềm. Vì sao điều này quan trọng Đo trực tiếp mức độ thành công của hoạt động triển khai. Đây là dữ liệu quan trọng để tính tỷ lệ triển khai thất bại và phân tích độ ổn định của quy trình phát hành. Lấy dữ liệu ở đâu Trạng thái này thường được ghi trong các tác vụ theo dõi triển khai hoặc bản ghi thực thi pipeline CI/CD tích hợp với ServiceNow DevOps. Ví dụ Thành côngThất bạiHoàn tất nhưng có cảnh báo

Bắt buộc Nên có Không bắt buộc

Hoạt động trong vòng đời phát triển phần mềm

Đây là các bước và mốc chính cần ghi lại trong event log để khám phá và tối ưu quy trình chính xác.

7 Nên có 9 Không bắt buộc

	Hoạt động	Mô tả
	Bắt đầu phát triển	Hoạt động này đánh dấu thời điểm nhà phát triển bắt tay viết mã hoặc triển khai hạng mục phát triển. Thông thường, sự kiện được suy ra khi trạng thái của hạng mục chuyển sang 'In Progress', 'Development' hoặc 'Coding'.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu giai đoạn bắt đầu tạo ra giá trị. Cột mốc này cần thiết để đo thời gian xử lý của nhà phát triển và thời gian chu kỳ đánh giá mã. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian cập nhật trường 'State' trên bản ghi hạng mục phát triển, chẳng hạn Story [rm_story], sang 'In Progress' hoặc trạng thái tương đương. Thu thập Dựa trên dấu thời gian chuyển trạng thái sang 'In Progress' hoặc giá trị tương tự. Loại sự kiện inferred
	Đã triển khai lên production	Sự kiện này đánh dấu việc triển khai lên môi trường production hoàn tất thành công. ServiceNow DevOps ghi nhận rõ ràng sự kiện khi công cụ CI/CD báo pipeline chạy thành công.
Vì sao điều này quan trọng Đây là điểm kết thúc thành công chính của quy trình SDLC. Sự kiện này hoàn tất luồng giá trị và cần thiết để tính tổng thời gian chu kỳ. Lấy dữ liệu ở đâu Lấy từ trường 'completion_status' của bản ghi Pipeline Execution [sn_devops_pipeline_execution] hoặc Stage Execution Run liên quan. Trạng thái 'Success' tại thời điểm kết thúc đánh dấu sự kiện này. Thu thập Được ghi nhận khi pipeline triển khai production hoàn tất thành công. Loại sự kiện explicit
	Hoàn tất đánh giá mã	Hoạt động này cho biết việc đánh giá mã giữa các đồng nghiệp đã hoàn tất, thường gắn với yêu cầu pull hoặc merge. Sự kiện có thể được ghi nhận trực tiếp qua tích hợp DevOps hoặc suy ra từ thay đổi trạng thái của các bản ghi liên quan.
Vì sao điều này quan trọng Đây là bước kiểm soát chất lượng quan trọng. Phân tích thời lượng giúp phát hiện điểm nghẽn trong quy trình đánh giá, vốn thường gây chậm trễ cho SDLC. Lấy dữ liệu ở đâu Có thể ghi nhận từ sự kiện 'Merged' hoặc 'Completed' của bản ghi Pull Request trong tích hợp Git của ServiceNow, hoặc suy ra khi trạng thái hạng mục phát triển chuyển sang 'Code Review Complete'. Thu thập Được ghi nhận khi Pull Request liên kết với hạng mục công việc được merge. Loại sự kiện explicit
	Hoàn tất kiểm thử QA	Cho biết đội QA đã hoàn tất kiểm thử hạng mục phát triển. Sự kiện này thường được suy ra khi trạng thái hạng mục rời giai đoạn kiểm thử và chuyển sang trạng thái như 'Ready for UAT' hoặc 'Done'.
Vì sao điều này quan trọng Cột mốc này đánh dấu việc hoàn tất một bước kiểm soát chất lượng quan trọng. Đây là điều kiện cần trước các giai đoạn tiếp theo như kiểm thử chấp nhận người dùng hoặc chuẩn bị phát hành. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian chuyển trạng thái từ trạng thái kiểm thử, chẳng hạn 'In QA', sang trạng thái sau kiểm thử, chẳng hạn 'Ready for UAT' hoặc 'Resolved'. Thu thập Dựa trên dấu thời gian chuyển trạng thái từ 'Testing' sang trạng thái tiếp theo. Loại sự kiện inferred
	Tạo hạng mục phát triển	Hoạt động này đánh dấu thời điểm tạo một hạng mục phát triển mới trong ServiceNow, chẳng hạn như story, lỗi hoặc epic. Sự kiện này thường được ghi nhận rõ ràng khi một bản ghi mới được thêm vào bảng liên quan, chẳng hạn bảng Story [rm_story].
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của quy trình SDLC. Sự kiện này giúp đo tổng thời gian chu kỳ từ đầu đến cuối và theo dõi yêu cầu ban đầu được tiếp nhận. Lấy dữ liệu ở đâu Sự kiện được ghi trong bảng sys_audit hoặc sys_history_line khi tạo bản ghi trong bảng liên quan đến phát triển, chẳng hạn Story [rm_story], Epic [rm_epic] hoặc Defect [rm_defect]. Dấu thời gian tạo thường nằm ngay trên bản ghi. Thu thập Lấy từ dấu thời gian tạo bản ghi của hạng mục phát triển. Loại sự kiện explicit
	Triển khai thất bại	Cho biết lần triển khai hạng mục phát triển lên production không thành công. ServiceNow DevOps ghi nhận rõ ràng sự kiện này khi pipeline CI/CD báo lỗi.
Vì sao điều này quan trọng Đây là điểm kết thúc do lỗi quan trọng. Phân tích tần suất và nguyên nhân giúp cải thiện độ ổn định của các đợt phát hành và giảm tỷ lệ triển khai thất bại. Lấy dữ liệu ở đâu Lấy từ trường 'completion_status' của bản ghi Pipeline Execution [sn_devops_pipeline_execution]. Trạng thái 'Failed' tại thời điểm kết thúc đánh dấu sự kiện này. Thu thập Được ghi nhận khi pipeline triển khai production báo trạng thái thất bại. Loại sự kiện explicit
	UAT được phê duyệt	Cho biết các bên liên quan của doanh nghiệp đã chính thức phê duyệt hạng mục phát triển sau khi kiểm thử chấp nhận người dùng hoàn tất. Đây là cột mốc quan trọng, được suy ra từ thay đổi trạng thái, chẳng hạn từ 'In UAT' sang 'Ready for Release' hoặc 'Approved'.
Vì sao điều này quan trọng Đây là bước phê duyệt cuối cùng của doanh nghiệp trước khi hạng mục được phép triển khai lên môi trường production. Đây là điểm kiểm tra quan trọng về chất lượng và quản trị. Lấy dữ liệu ở đâu Suy ra từ lần chuyển trạng thái trên bản ghi hạng mục phát triển cho biết UAT đã hoàn tất thành công. Sự kiện được ghi trong lịch sử hoạt động của hạng mục. Thu thập Suy ra từ lần chuyển trạng thái từ 'UAT' sang trạng thái đã phê duyệt hoặc sẵn sàng phát hành. Loại sự kiện inferred
	Bắt đầu kiểm thử QA	Đánh dấu thời điểm bắt đầu giai đoạn kiểm thử đảm bảo chất lượng chính thức. Hầu như luôn có thể suy ra sự kiện này khi trạng thái hạng mục phát triển chuyển sang giá trị như 'In QA', 'Testing' hoặc 'Ready for Test'.
Vì sao điều này quan trọng Hoạt động này đánh dấu thời điểm bàn giao từ đội ngũ phát triển sang đội QA. Nhờ đó, bạn có thể đo thời lượng kiểm thử và phát hiện điểm nghẽn về năng lực kiểm thử. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian cập nhật trường 'State' trên bản ghi hạng mục phát triển, chẳng hạn Story hoặc Defect, sang trạng thái dành riêng cho QA. Thu thập Dựa trên dấu thời gian chuyển trạng thái sang 'Testing' hoặc trạng thái tương đương. Loại sự kiện inferred
	Bắt đầu thiết kế	Đây là giai đoạn xây dựng thiết kế kỹ thuật hoặc kiến trúc giải pháp cho hạng mục phát triển. Thông thường, giai đoạn này được suy ra từ trường trạng thái trên bản ghi hạng mục phát triển khi trường chuyển sang giá trị như 'Design' hoặc 'Solutioning'.
Vì sao điều này quan trọng Phân tích thời lượng giai đoạn thiết kế giúp phát hiện điểm nghẽn khi chuyển yêu cầu thành giải pháp và lập kế hoạch trước khi bắt đầu phát triển. Lấy dữ liệu ở đâu Suy ra từ các lần chuyển trạng thái trên bản ghi hạng mục phát triển, chẳng hạn Story [rm_story]. Tìm các thay đổi ở trường 'State' hoặc trường 'Stage' tùy chỉnh sang giá trị liên quan đến thiết kế. Thu thập Suy ra từ thay đổi trạng thái sang 'Design' hoặc trạng thái tương tự. Loại sự kiện inferred
	Bắt đầu triển khai lên production	Hoạt động này đánh dấu thời điểm bắt đầu pipeline triển khai lên môi trường production. ServiceNow DevOps ghi nhận rõ ràng sự kiện khi giai đoạn production của pipeline CI/CD bắt đầu chạy.
Vì sao điều này quan trọng Đây là thời điểm bắt đầu giai đoạn cuối cùng, thường cũng là giai đoạn quan trọng nhất của vòng đời. Theo dõi bước này giúp phân tích thời lượng triển khai và tìm cơ hội tự động hóa. Lấy dữ liệu ở đâu Được ghi rõ trong bảng Stage Execution Run [sn_devops_stage_execution], lọc theo các giai đoạn liên quan đến môi trường production. Thu thập Lấy từ thời điểm bắt đầu giai đoạn triển khai production trong một Pipeline Execution. Loại sự kiện explicit
	Bắt đầu UAT	Đánh dấu thời điểm bắt đầu kiểm thử chấp nhận người dùng, trong đó các bên liên quan của doanh nghiệp xác nhận chức năng. Sự kiện này được suy ra khi trạng thái chuyển sang 'UAT', 'In UAT' hoặc 'User Acceptance Testing'.
Vì sao điều này quan trọng Giai đoạn này rất quan trọng để bảo đảm tính năng được phát triển đáp ứng yêu cầu kinh doanh. Phân tích thời lượng có thể giúp phát hiện vấn đề về mức độ tham gia của người dùng hoặc sự không khớp giữa yêu cầu và sản phẩm. Lấy dữ liệu ở đâu Suy ra từ lần chuyển trạng thái trên bản ghi hạng mục phát triển. Cách này yêu cầu mô hình trạng thái của khách hàng có trạng thái UAT riêng. Thu thập Suy ra từ lần chuyển trạng thái sang trạng thái 'UAT'. Loại sự kiện inferred
	Chuẩn bị phát hành	Hoạt động này cho biết hạng mục phát triển đã vượt qua tất cả bước kiểm soát chất lượng và được đưa vào một bản phát hành cụ thể. Có thể suy ra sự kiện này khi hạng mục được liên kết với bản ghi Release hoặc trạng thái chuyển sang 'Ready for Deployment'.
Vì sao điều này quan trọng Bước này cho biết hạng mục đã hoàn tất về mặt kỹ thuật và chức năng. Thời gian ở trạng thái này có thể là thời gian chờ đến đợt triển khai theo lịch. Lấy dữ liệu ở đâu Suy ra khi trường 'State' chuyển sang 'Ready for Release' hoặc bằng cách theo dõi thời điểm trường 'Release' trên bản ghi hạng mục phát triển được điền hoặc cập nhật. Thu thập Suy ra từ thay đổi trạng thái hoặc việc liên kết với bản ghi Release. Loại sự kiện inferred
	Đã commit mã	Đây là lúc nhà phát triển commit mã vào kho của hệ thống quản lý phiên bản được liên kết với hạng mục phát triển. ServiceNow DevOps ghi nhận rõ ràng các sự kiện này từ công cụ SCM tích hợp như Git hoặc GitHub.
Vì sao điều này quan trọng Theo dõi các lần commit giúp bạn thấy rõ tiến độ và tần suất hoạt động phát triển. Việc này cũng giúp liên kết thay đổi mã cụ thể với hạng mục phát triển tương ứng. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong bảng Commits [sn_devops_commit] của ServiceNow DevOps. Bảng này nhận dữ liệu từ webhook của hệ thống quản lý mã nguồn đã tích hợp. Thu thập Được ghi nhận khi nhận webhook commit từ công cụ SCM. Loại sự kiện explicit
	Hủy hạng mục phát triển	Đây là trường hợp hạng mục phát triển kết thúc trước khi hoàn tất. Trạng thái kết thúc thay thế này thường được suy ra khi trạng thái hạng mục chuyển thành 'Cancelled' hoặc 'Closed Incomplete'.
Vì sao điều này quan trọng Theo dõi các trường hợp hủy giúp phát hiện công sức bị lãng phí và hiểu lý do thay đổi phạm vi hoặc thứ tự ưu tiên. Nhờ đó, bạn có cái nhìn đầy đủ hơn về mọi kết quả có thể xảy ra trong quy trình. Lấy dữ liệu ở đâu Suy ra từ dấu thời gian cập nhật trường 'State' trên bản ghi hạng mục phát triển sang trạng thái kết thúc nhưng chưa hoàn tất, chẳng hạn 'Cancelled'. Thu thập Suy ra từ lần chuyển trạng thái sang 'Cancelled' hoặc trạng thái kết thúc tương đương. Loại sự kiện inferred
	Kích hoạt bản dựng	Sự kiện này đánh dấu thời điểm bắt đầu bản dựng trong pipeline CI/CD, thường do một lần commit mã kích hoạt. ServiceNow DevOps ghi nhận đây là lần thực thi pipeline và liên kết với các hạng mục phát triển khởi tạo sự kiện.
Vì sao điều này quan trọng Hoạt động này kết nối giai đoạn phát triển với kiểm thử hoặc triển khai tự động. Phân tích khoảng thời gian từ lúc commit đến khi bắt đầu bản dựng có thể giúp phát hiện chậm trễ trong quy trình CI/CD. Lấy dữ liệu ở đâu Sự kiện được ghi rõ trong bảng Pipeline Execution [sn_devops_pipeline_execution] khi bản dựng bắt đầu trong công cụ CI/CD tích hợp, chẳng hạn Jenkins hoặc Azure DevOps. Thu thập Lấy từ thời điểm bắt đầu của bản ghi trong bảng Pipeline Execution. Loại sự kiện explicit
	Phát hiện việc cần làm lại	Cho biết đã phát hiện vấn đề trong quá trình kiểm thử và cần chuyển hạng mục trở lại giai đoạn phát triển. Sự kiện này được suy ra khi quy trình chuyển ngược về giai đoạn trước, chẳng hạn trạng thái đổi từ 'In QA' về 'In Progress'.
Vì sao điều này quan trọng Theo dõi việc làm lại là điều cần thiết để hiểu các vấn đề về chất lượng và điểm kém hiệu quả trong quy trình. Hoạt động này xảy ra thường xuyên cho thấy có vấn đề trong khâu phát triển hoặc yêu cầu chưa rõ ràng. Lấy dữ liệu ở đâu Suy ra bằng cách phân tích lịch sử trường 'State' trong bảng sys_audit hoặc sys_history_line. Trạng thái chuyển từ giai đoạn sau, chẳng hạn 'Testing', về giai đoạn trước, chẳng hạn 'In Progress', cho thấy công việc cần làm lại. Thu thập Suy ra từ lần chuyển trạng thái ngược, ví dụ 'Testing' -> 'In Progress'. Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ ServiceNow DevOps

Các bước

Tìm hiểu mô hình trạng thái: Trước khi tạo báo cáo, ghi lại các giá trị cụ thể trong trường trạng thái của mục phát triển (ví dụ: trong bảng Story [rm_story] hoặc Defect [rm_defect]) tương ứng với các hoạt động cần thiết. Chẳng hạn, trạng thái 'In Progress' có thể ánh xạ thành hoạt động 'Development Started'.
Mở phần tạo báo cáo: Đăng nhập vào ServiceNow. Trong Filter navigator, vào Reports > View / Run rồi nhấp nút Create a report.
Tạo báo cáo ghi nhận thay đổi trạng thái: Tạo báo cáo đầu tiên để ghi nhận các hoạt động dựa trên trạng thái. Cấu hình như sau:
- Tên báo cáo: ProcessMind - State Change Events
- Loại nguồn: Table
- Bảng: Audit [sys_audit]
- Loại: List
- Cấu hình cột: Thêm Document key, Created on, Table name, Field name, Old value và New value.
- Bộ lọc: Đặt Table name là một trong các bảng mục phát triển của bạn (ví dụ: Story) và Field name là trường trạng thái (ví dụ: State). Thêm bộ lọc ngày cho trường Created on để chọn khoảng thời gian mong muốn.
Tạo báo cáo ghi nhận việc tạo mục: Tạo báo cáo mới cho sự kiện tạo ban đầu.
- Tên báo cáo: ProcessMind - Item Creation Events
- Loại nguồn: Table
- Bảng: Story [rm_story] (hoặc bảng mục phát triển chính của bạn)
- Loại: List
- Cấu hình cột: Thêm các cột thuộc tính cần thiết như Number, Created on, Assigned to, Priority, State, v.v.
- Bộ lọc: Áp dụng bộ lọc ngày cho trường Created on.
Tạo báo cáo ghi nhận lần commit mã: Tạo báo cáo cho các sự kiện DevOps cụ thể liên quan đến commit.
- Tên báo cáo: ProcessMind - Commit Events
- Loại nguồn: Table
- Bảng: Commit [sn_devops_commit]
- Loại: List
- Cấu hình cột: Thêm các cột như Work item, Commit time, Author, v.v.
- Bộ lọc: Áp dụng bộ lọc ngày cho trường Commit time.
Tạo báo cáo cho bản dựng và triển khai: Lặp lại các bước trên cho bảng Build [sn_devops_build] và Deployment [sn_devops_deployment]. Các bảng này chứa bản ghi cho hoạt động Build Triggered, Deployment to Production Started, Deployed to Production và Deployment Failed.
Xuất tất cả báo cáo: Chạy từng báo cáo đã tạo. Trong mỗi báo cáo, nhấp biểu tượng menu (ba dấu chấm hoặc mũi tên xuống), rồi chọn Export > CSV hoặc Export > Excel. Lưu tất cả tệp.
Gộp và chuyển đổi dữ liệu: Mở các tệp đã xuất bằng phần mềm bảng tính hoặc công cụ chuẩn bị dữ liệu. Gộp dữ liệu từ tất cả tệp vào một trang tính. Tạo các cột nhật ký sự kiện cần thiết (DevelopmentItem, ActivityName, EventTime, v.v.) và ánh xạ dữ liệu từ các cột nguồn. Ví dụ, ánh xạ Document key từ báo cáo kiểm tra và Number từ báo cáo Story vào cột DevelopmentItem.
Ánh xạ tên hoạt động: Tạo cột ActivityName bằng cách chuyển đổi dữ liệu nguồn. Với báo cáo thay đổi trạng thái, dùng mô hình trạng thái đã ghi lại để ánh xạ các giá trị New value sang tên hoạt động (ví dụ: ánh xạ trạng thái 'Testing' thành 'QA Testing Started'). Với các báo cáo khác, gán một tên hoạt động cố định cho từng dòng (ví dụ: mọi dòng từ tệp xuất commit đều thành 'Code Committed').
Hoàn tất và lưu: Thêm các cột SourceSystem và LastDataUpdate với giá trị cố định cho mọi dòng. Đảm bảo tất cả dấu thời gian dùng cùng một định dạng. Lưu tệp đã gộp thành một tệp CSV để tải lên ProcessMind.

Cấu hình

Các bảng cần thiết: Các bảng chính cần trích xuất gồm Audit [sys_audit] để lấy sự kiện suy ra, các bảng mục phát triển cụ thể của bạn (ví dụ: Story [rm_story], Defect [rm_defect]) và các bảng ServiceNow DevOps cốt lõi: Commit [sn_devops_commit], Build [sn_devops_build] và Deployment [sn_devops_deployment].
Bộ lọc chính: Bộ lọc quan trọng nhất là khoảng ngày. Hãy áp dụng nhất quán cho mọi báo cáo trên một trường dấu thời gian như Created on, Commit time hoặc Thời điểm bắt đầu. Với báo cáo sys_audit, cần lọc theo Table name (ví dụ: rm_story) và Field name (ví dụ: state) để chỉ lấy những thay đổi trạng thái liên quan.
Khoảng thời gian nên lấy: Nên trích xuất dữ liệu trong 3 đến 6 tháng để có tập dữ liệu đại diện mà không gây ảnh hưởng đến hiệu suất. Với hệ thống lớn, hãy cân nhắc lấy dữ liệu theo từng tháng.
Xác định mô hình trạng thái: Bạn cần hiểu rõ mô hình trạng thái của các mục công việc trong tổ chức. Đây là điều kiện cần để ánh xạ chính xác các giá trị trạng thái trong bảng sys_audit sang hoạt động nghiệp vụ tương ứng, chẳng hạn như 'QA Testing Started' hoặc 'UAT Approved'.
Điều kiện tiên quyết: Người trích xuất dữ liệu cần có vai trò report_user hoặc quyền tương đương để tạo và chạy báo cáo. Họ cũng cần quyền đọc các bảng DevOps và phát triển ứng dụng nêu trên. Plugin ServiceNow DevOps phải được cài đặt và tích hợp với các công cụ SCM và CI/CD của bạn.

Truy vấn mẫu sql

/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/

---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
  - Number                    (maps to DevelopmentItem)
  - sys_created_on            (maps to EventTime)
  - 'Development Item Created' (create a formula or static column for ActivityName)
  - Assigned to               (maps to AssignedDeveloper)
  - Priority                  (maps to DevelopmentItemPriority)
  - State                     (maps to DevelopmentItemState)
  - cmdb_ci                   (maps to ModuleComponentAffected)
  - Type                      (maps to DevelopmentItemType)
  - Assignment group          (maps to AssignmentGroup)
Filters:
  - sys_created_on ON Last 6 months

---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
  - documentkey               (maps to DevelopmentItem)
  - sys_created_on            (maps to EventTime)
  - newvalue                  (maps to ActivityName, requires translation)
  - user                      (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
  - WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
  - WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
  - WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
  - WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
  - WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
  - WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
  - WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
  - WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
  - WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
  - tablename = 'rm_story'
  - fieldname = 'state'
  - sys_created_on ON Last 6 months

---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
  - work_item.number          (maps to DevelopmentItem)
  - commit_time               (maps to EventTime)
  - 'Code Committed'          (create a formula or static column for ActivityName)
  - author.name               (maps to AssignedDeveloper)
Filters:
  - commit_time ON Last 6 months

---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
  - work_item.number          (maps to DevelopmentItem)
  - start_time                (maps to EventTime)
  - 'Build Triggered'         (create a formula or static column for ActivityName)
Filters:
  - start_time ON Last 6 months

---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
  - work_item.number          (maps to DevelopmentItem)
  - start_time                (maps to EventTime for 'Started' activities)
  - end_time                  (maps to EventTime for 'Completed' or 'Failed' activities)
  - state                     (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
  - WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
  - WHEN state IS 'successful' THEN 'Deployed to Production'
  - WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
  - start_time ON Last 6 months
  - [Filter for production deployments based on your environment configuration]

---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
---

Các bước

Điều kiện cần: Đảm bảo bạn có quyền truy cập mạng vào phiên bản ServiceNow và được cấp tài khoản dịch vụ riêng có quyền đọc (các vai trò itil và sn_devops.viewer là điểm khởi đầu phù hợp). Tài khoản này cần truy cập được các bảng như rm_story, sys_audit và lược đồ sn_devops_*.
Cài ServiceNow ODBC Driver: Tải trình điều khiển ServiceNow ODBC phù hợp với hệ điều hành của bạn từ cổng hỗ trợ ServiceNow. Làm theo hướng dẫn cài đặt đi kèm.
Cấu hình DSN: Tạo System DSN (Data Source Name) mới trên máy sẽ chạy truy vấn. Trong ODBC Data Source Administrator, thêm trình điều khiển ServiceNow rồi cấu hình URL phiên bản (ví dụ: yourinstance.service-now.com), tên người dùng và mật khẩu.
Kết nối bằng ứng dụng SQL: Dùng công cụ SQL như DBeaver, Microsoft SQL Server Management Studio (thông qua linked server) hoặc ngôn ngữ lập trình như Python với thư viện ODBC để kết nối ServiceNow qua DSN đã cấu hình.
Xác định mô hình trạng thái: Trước khi chạy truy vấn, bạn cần xác định chính xác các giá trị tổ chức sử dụng cho trường state trong các bảng mục phát triển (ví dụ: rm_story, rm_defect). Truy vấn mẫu dùng các giá trị phổ biến như 'In Progress' hoặc 'In QA'. Hãy thay bằng giá trị cụ thể của bạn.
Tùy chỉnh truy vấn SQL: Sao chép truy vấn SQL được cung cấp vào ứng dụng. Sửa các giá trị giữ chỗ ở đầu truy vấn, bao gồm ngày bắt đầu trích xuất và các giá trị trạng thái tương ứng với hoạt động trong vòng đời phát triển của bạn.
Chạy truy vấn: Chạy toàn bộ truy vấn SQL trên cơ sở dữ liệu ServiceNow qua kết nối ODBC. Thời gian chạy có thể khá lâu, tùy vào khoảng ngày và lượng dữ liệu.
Kiểm tra dữ liệu: Khi truy vấn hoàn tất, kiểm tra nhanh tập dữ liệu trả về. Xem có đủ loại hoạt động không và các cột chính như DevelopmentItem, ActivityName, EventTime đã có dữ liệu như mong đợi chưa.
Xuất CSV: Xuất toàn bộ kết quả sang tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 và tiêu đề cột khớp với tên thuộc tính ProcessMind yêu cầu, chẳng hạn DevelopmentItem, ActivityName, EventTime.
Chuẩn bị tải lên: Đảm bảo tệp CSV cuối cùng không có dòng trống ở cuối. Định dạng ngày giờ trong EventTime và LastDataUpdate phải nhất quán và được ProcessMind hỗ trợ (ví dụ: YYYY-MM-DD HH:MM:SS).

Cấu hình

Điều kiện cần: Có quyền truy cập phiên bản ServiceNow đã bật mô-đun DevOps. Cần có tài khoản riêng với quyền đọc các bảng cần thiết. ServiceNow ODBC Driver phải được cài đặt và cấu hình trên máy khách.
Cấu hình ODBC Driver: Để kết nối, bạn cần URL phiên bản, tên người dùng và mật khẩu hoặc mã thông báo OAuth. Hãy kiểm tra kết nối DSN trước khi chạy các truy vấn phức tạp.
Lọc khoảng ngày: Truy vấn mẫu có giá trị giữ chỗ s.sys_created_on >= '2023-01-01' để giới hạn lượng dữ liệu trích xuất. Nên chọn một khoảng thời gian cụ thể, chẳng hạn 6 đến 12 tháng gần nhất, để thời gian chạy truy vấn ở mức hợp lý.
Tùy chỉnh mô hình trạng thái: Độ chính xác của các sự kiện suy ra từ truy vấn phụ thuộc hoàn toàn vào mô hình trạng thái. Bạn cần thay các giá trị giữ chỗ (ví dụ: [Your 'In Progress' State Value], [Your 'In QA' State Value]) bằng đúng giá trị trong cấu hình ServiceNow. Các giá trị này phân biệt chữ hoa và chữ thường.
Bảng mục công việc: Truy vấn được viết cho bảng Story (rm_story). Nếu tổ chức của bạn cũng dùng Defect (rm_defect), Enhancement (rm_enhancement) hoặc loại tác vụ khác, hãy thêm các bảng đó vào Common Table Expression (CTE) DevItems ban đầu bằng UNION ALL.
Hiệu năng: Truy vấn trực tiếp trên phiên bản ServiceNow đang vận hành có thể ảnh hưởng đến hiệu năng. Nên trích xuất lượng lớn dữ liệu ngoài giờ cao điểm. Với tập dữ liệu rất lớn, hãy cân nhắc trích xuất tăng dần dựa trên trường sys_updated_on.

Truy vấn mẫu sql

WITH DevItems AS (
  -- This CTE selects the base set of development items to analyze.
  -- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
  SELECT
    s.sys_id,
    s.number,
    s.sys_created_on,
    s.sys_updated_on,
    s.assigned_to,
    s.priority,
    s.state,
    s.cmdb_ci, -- Module/Component Affected
    s.sys_class_name, -- Development Item Type
    s.assignment_group,
    DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
  FROM rm_story s
  WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
  -- This CTE unnests the audit trail for state changes, which are used for inferred activities.
  SELECT
    a.documentkey AS item_sys_id,
    a.sys_created_on AS change_time,
    a.oldvalue,
    a.newvalue,
    -- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
    CASE a.oldvalue
      WHEN '1' THEN 1 -- Open
      WHEN '[Your 'Design' State Value]' THEN 2
      WHEN '[Your 'In Progress' State Value]' THEN 3
      WHEN '[Your 'In QA' State Value]' THEN 4
      WHEN '[Your 'In UAT' State Value]' THEN 5
      ELSE 0
    END AS old_state_order,
    CASE a.newvalue
      WHEN '1' THEN 1 -- Open
      WHEN '[Your 'Design' State Value]' THEN 2
      WHEN '[Your 'In Progress' State Value]' THEN 3
      WHEN '[Your 'In QA' State Value]' THEN 4
      WHEN '[Your 'In UAT' State Value]' THEN 5
      ELSE 0
    END AS new_state_order
  FROM sys_audit a
  WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
  i.number AS DevelopmentItem,
  'Development Item Created' AS ActivityName,
  i.sys_created_on AS EventTime,
  'ServiceNow DevOps' AS SourceSystem,
  GETDATE() AS LastDataUpdate,
  us.name AS AssignedDeveloper,
  i.priority AS DevelopmentItemPriority,
  i.state AS DevelopmentItemState,
  ci.name AS ModuleComponentAffected,
  i.sys_class_name AS DevelopmentItemType,
  grp.name AS AssignmentGroup,
  i.cycle_time_seconds AS DevelopmentItemCycleTime,
  CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id

UNION ALL

-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***

UNION ALL

-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***

UNION ALL

-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id

UNION ALL

-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id

UNION ALL

-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process

UNION ALL

-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***

UNION ALL

-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state

UNION ALL

-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***

UNION ALL

-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***

UNION ALL

-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***

UNION ALL

-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***

UNION ALL

-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***

UNION ALL

-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***

UNION ALL

-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***

UNION ALL

-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT) 
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id 
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value ***

Bắt đầu ngay?

Bắt đầu cải thiện vòng đời phát triển phần mềm ngay hôm nay. Dùng mẫu dữ liệu này để tìm ra những điểm kém hiệu quả khó nhận thấy và liên tục cải tiến quy trình.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Đừng chần chừ, tối ưu vòng đời phát triển phần mềm ngay hôm nay

Xác định điểm kém hiệu quả để rút ngắn thời gian chu kỳ SDLC từ 30% trở lên.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Bắt đầu tối ưu ngay hôm nay.

Mẫu dữ liệu vòng đời phát triển phần mềm

Mẫu dữ liệu vòng đời phát triển phần mềm

Thuộc tính vòng đời phát triển phần mềm

Hoạt động trong vòng đời phát triển phần mềm

Hướng dẫn trích xuất dữ liệu

Tạo báo cáo và xuất dữ liệu DevOps trong ServiceNow

Các bước

Cấu hình

Truy vấn mẫu sql

Dùng ServiceNow ODBC Driver và SQL để lấy dữ liệu vòng đời

Các bước

Cấu hình

Truy vấn mẫu sql

Bắt đầu ngay?

Đừng chần chừ, tối ưu vòng đời phát triển phần mềm ngay hôm nay