Quản lý phát hành & Triển khai IT – IT Release and Deployment Management

Nói một cách đơn giản, một bản phát hành (còn gọi là gói phát hành) là một tập hợp các thay đổi được ủy quyền cho một dịch vụ CNTT. Điều đó có nghĩa là một bản phát hành có thể bao gồm phần cứng và phần mềm, tài liệu, quy trình hoặc các thành phần khác cần thiết để thực hiện thành công thay đổi được phê duyệt cho các dịch vụ CNTT của bạn.

Hầu hết các tổ chức tuân theo ITIL đều tạo ra các chính sách phát hành , giúp xác định cách phát hành được đánh số, tần suất phát hành và thậm chí cách phát hành (ví dụ như thông qua triển khai theo giai đoạn so với triển khai lớn.

Là một phần của chính sách phát hành, ITIL khuyến khích tạo ra một hệ thống để phân loại các bản phát hành. Các danh mục thường bao gồm:

• Phát hành chính. Để đủ điều kiện là một bản phát hành chính, nó phải chứa phần cứng hoặc phần mềm mới. Một bản phát hành chính tương đương với việc giới thiệu chức năng hoàn toàn mới. Hãy nghĩ các bản phát hành cấp v1.0 và v2.0 – chúng là những cột mốc quan trọng.
• Các bản phát hành nhỏ tạo ra những cải tiến đáng kể cho chức năng hiện có, thường đóng gói một số bản sửa lỗi – và thường được đánh số v1.1, v1.2, v1.3, v.v.
• Phát hành khẩn cấp là chính xác những gì họ nghe như là một cái gì đó xấu cần chú ý càng sớm càng tốt, vì vậy bạn đang phát hành một bản sửa lỗi tạm thời – và có thể đánh số bản phát hành như 1.1.1, v1.1.2, v1.1.3, v.v.

Khi bạn thiết kế các bản phát hành của mình, bạn cũng sẽ có một số tùy chọn cho cách bạn dự định triển khai. Chính sách phát hành của bạn có thể hoặc không thể chỉ định cách tiếp cận nào, nhưng bất kể, bạn nên chú ý đến người dùng mà bạn đang triển khai và các hoạt động kinh doanh mà bản phát hành sẽ tác động để đảm bảo bạn có tác động mong muốn.

• Các bản phát hành Big bang được triển khai cho tất cả người dùng, tất cả cùng một lúc.
• Các bản phát hành theo từng giai đoạn có nhịp độ cao hơn – được triển khai trước tiên cho một tập hợp con của cơ sở người dùng rộng hơn, sau đó được triển khai dần dần cho người dùng bổ sung như là một phần của kế hoạch triển khai theo lịch trình.

Phát hành cũng có thể được kéo hoặc đẩy. Cách tiếp cận kéo có nghĩa là bản phát hành được đặt ở vị trí trung tâm nơi người dùng có thể tải xuống theo ý mình, trong khi phương pháp đẩy ngụ ý rằng bản phát hành sẽ được đẩy ra từ vị trí trung tâm cho mỗi người dùng.

Cuối cùng, ITIL đề nghị bạn chỉ định rõ ràng việc phát hành sẽ được triển khai tự động (tức là sử dụng phần mềm cài đặt, v.v.) hoặc thủ công.

Theo ITIL, các mục tiêu của Quản lý phát hành và triển khai là:

• Để tạo, kiểm tra, xác minh và triển khai các gói phát hành
• Để quản lý thay đổi tổ chức và các bên liên quan
• Để đảm bảo rằng các dịch vụ mới hoặc thay đổi có khả năng cung cấp tiện ích và bảo hành đã thỏa thuận
• Để ghi lại và quản lý các sai lệch, rủi ro và các vấn đề liên quan đến dịch vụ mới hoặc đã thay đổi và thực hiện hành động khắc phục cần thiết
• Để đảm bảo có sự chuyển giao kiến thức để cho phép khách hàng và người dùng tối ưu hóa việc sử dụng các dịch vụ hỗ trợ các hoạt động kinh doanh của họ

Phạm vi của Quản lý phát hành và triển khai bao gồm tất cả các mục cấu hình (CIs) được yêu cầu để thực hiện một bản phát hành, bao gồm:

• Tài sản ảo và vật lý
• Ứng dụng và phần mềm
• Đào tạo cho nhân viên và người dùng
• Tất cả các hợp đồng và thỏa thuận liên quan

Việc kiểm tra được thực hiện như một phần của Quy trình xác thực dịch vụ không được xem xét trong phạm vi và cũng không cho phép thay đổi.

Quản lý Phát hành và Triển khai được chia thành bốn giai đoạn riêng biệt, bắt đầu bằng việc lên kế hoạch kỹ lưỡng về những gì bạn sẽ phát hành và cách thức, và kết luận sau khi phát hành được triển khai và tiến hành đánh giá.

Giai đoạn 1: Lập kế hoạch
Kế hoạch phát hành và triển khai được cân nhắc kỹ lưỡng chỉ là một thành phần trong kế hoạch Chuyển đổi dịch vụ tổng thể của bạn – nhưng vấn đề là xác định rõ ràng một bộ hướng dẫn cho cả bản phát hành sẽ bao gồm và cách bạn sẽ triển khai nó vào sản xuất. Kế hoạch phát hành và triển khai sau đó được phê duyệt như là một phần của quy trình Quản lý thay đổi.

Khi bắt đầu giai đoạn phát hành và lập kế hoạch triển khai, quản lý thay đổi thường cho phép quy trình lập kế hoạch bắt đầu phát hành. Kế hoạch thường giải quyết:

1. Những thay đổi phát hành
2. Ai sẽ bị ảnh hưởng bởi việc phát hành
3. Rủi ro phát hành có thể có
4. Đối tượng phát hành (tức là những gì người dùng, khách hàng, tổ chức sẽ bị ảnh hưởng)
5. Một chuỗi phê duyệt rõ ràng, làm rõ những bên liên quan nào có thể cho phép yêu cầu thay đổi ở mọi giai đoạn phát hành
6. Quyền sở hữu, xác định nhóm chịu trách nhiệm cuối cùng cho việc phát hành.
7. Lịch trình và chiến lược triển khai

Việc xây dựng và thử nghiệm các kế hoạch cũng được xây dựng trong giai đoạn này là khá phổ biến, phác thảo rõ ràng hậu cần quan trọng như thông số kỹ thuật thiết kế, quy trình thử nghiệm, thời gian xây dựng và thử nghiệm, và thậm chí vượt qua / tiêu chí thất bại ở mỗi giai đoạn triển khai. Một triển khai thí điểm cũng có thể tùy chọn được lên kế hoạch tại thời điểm này.

Giai đoạn 2: Xây dựng và thử nghiệm phát hành
Một khi kế hoạch được thực hiện và được ban quản lý thay đổi phê duyệt, các nhóm chịu trách nhiệm phải xây dựng và kiểm tra bản phát hành, bao gồm cả phần mềm, tài liệu và bất kỳ yếu tố nào khác mà kế hoạch phát hành chỉ định.

Khi bắt đầu quá trình này, tài liệu thường được tạo để đảm bảo rằng các nhà phát triển sẽ có thể xây dựng gói phát hành chính xác và hiệu quả nhất có thể – và trong suốt quá trình xây dựng, nên lưu giữ các bản ghi chính xác để có thể lặp lại quy trình xây dựng, nếu nó trở nên cần thiết

Hầu hết các tổ chức thường tuân theo các quy trình nghiêm ngặt hoặc thậm chí cung cấp các mẫu tiêu chuẩn để xây dựng gói phát hành hoàn chỉnh. Đảm bảo bạn đang sử dụng và làm theo những điều này ở mỗi bước trên đường đi.

Việc kiểm tra diễn ra trong suốt quá trình – từ kiểm tra bất kỳ và tất cả các CIs đầu vào, đến kiểm tra và thử nghiệm các dịch vụ trước khi chúng được triển khai trực tiếp.

Một số điều cần nhớ trên đường đi:

• Tự động hóa là một cách tuyệt vời để xác định và khắc phục mọi sự cố với dịch vụ trước khi chúng được triển khai cho toàn bộ đối tượng dự định. Điều này có thể làm giảm đáng kể rủi ro.
• Một số nhóm cũng chọn tổ chức một buổi diễn tập, thực tế là tập luyện trực tiếp với càng nhiều dịch vụ càng tốt trước khi triển khai.

Giai đoạn 3: Triển khai
Trong giai đoạn này, gói phát hành được triển khai vào môi trường trực tiếp, bắt đầu khi quản lý thay đổi cho phép gói phát hành được triển khai vào môi trường đích. Giai đoạn triển khai kết thúc với việc chuyển giao cho các hoạt động dịch vụ và hỗ trợ ban đời.

Trước khi triển khai, ITIL khuyến khích khá nhiều kế hoạch và chuẩn bị nâng cao – xác nhận nhóm mục tiêu đã sẵn sàng để triển khai, xác định và cố gắng giảm thiểu mọi rủi ro hoặc gián đoạn tiềm năng và chỉ định thứ tự cách thức từng thành phần của bản phát hành sẽ được triển khai ( như tài sản tài chính, quy trình và tài liệu, phát hành dịch vụ thực tế, v.v.)

Khi một bản phát hành được triển khai, điều quan trọng là bạn xác minh rằng nó đang hoạt động đúng cho tất cả các bên liên quan – và khắc phục hoặc sao lưu bản phát hành khi cần nếu có vấn đề nghiêm trọng phát sinh.

Sau khi xác minh rằng bản phát hành hoạt động như kế hoạch, ITIL yêu cầu bạn chuyển dịch vụ mới hoặc đã thay đổi sang hoạt động dịch vụ theo hai giai đoạn. Đầu tiên, cần đưa ra thông báo chính thức rằng dịch vụ hiện đang hoạt động, sau đó là thông báo chính thức rằng dịch vụ đã hoạt động đầy đủ và SLA đang được thực thi đầy đủ.

Giai đoạn 4: Xem xét và kết thúc triển khai
Sau khi bản phát hành được triển khai, đã đến lúc xem xét và học hỏi từ toàn bộ quá trình. Phản hồi được thu thập và các đánh giá được thực hiện theo các mục tiêu hiệu suất – với kết quả được xem xét và thảo luận bởi tất cả những người liên quan.

Đánh giá phải cẩn thận và kỹ lưỡng, xác nhận rằng tất cả các yêu cầu chất lượng đã được đáp ứng, việc truyền đạt và đào tạo kiến thức đầy đủ đã được thực hiện và mọi lỗi đã biết, sửa chữa và thay đổi đã được ghi lại đầy đủ.

Việc triển khai không được coi là đã đóng lại hay hoàn thành cho đến khi hỗ trợ chính thức được chuyển sang hoạt động.