DevOps có tương thích với ITIL không?

Trong sự nghiệp của mình, tôi vừa là nhà phát triển phần mềm vừa là người thực hành ITIL trong vai trò hoạt động. Do đó, DevOps là một tiến bộ tự nhiên đối với tôi.
Tuy nhiên, tôi luôn phải vật lộn với ngôn ngữ chuyên môn cao mà ITIL giới thiệu và làm cho "Nhà phát triển thân thiện" đủ để không bị tắt hoàn toàn đối với các nhà phát triển.

ITIL là một khung quản lý dịch vụ CNTT được quốc tế công nhận, đã được phát triển hơn 30 năm như một tập hợp thực hành có lợi ích đã được chứng minh đối với sự ổn định và trưởng thành hoạt động của một tổ chức.

DevOps có thực sự tương thích với ITIL hay về bản chất, chúng ta cần lấy tinh thần của ITIL và "dịch" nó sang ngôn ngữ được các nhóm phát triển hiểu rõ hơn:

• Quản lý sự cố & sự cố → Lỗi sản xuất, lỗi hoặc sự cố
• Quản lý thay đổi và phát hành → Giao hàng liên tục
• Quản lý sự kiện → Ghi nhật ký, từ xa, thiết bị và cảnh báo

Theo tôi, văn hóa DevOps đi kèm với sự thay đổi về phương pháp đối với việc quản lý quy trình Agile .
ITIL chủ yếu nhắm vào một hình thức rõ ràng về quy trình và kết quả và do đó thích nghi hơn với mô hình Thác nước .

Điều này không có nghĩa là ITIL không tương thích với Devops, nhưng thường thì đây sẽ là hai quá trình riêng biệt với các mốc thời gian khác nhau. Ý tôi là việc bao gồm một sản phẩm mới trong tham chiếu ITIL thường sẽ bị trì hoãn cho đến khi sản phẩm / ứng dụng được phát hành trong một thời gian, trong đó những cạm bẫy ban đầu và một số tài liệu cần thiết để tích hợp ITIL đã được thực hiện và điều chỉnh sau khi sản phẩm được " trực tiếp".

Một trong những điều trong ITIL là Thiết kế dịch vụ, được giả định là được xác định trước bất kỳ nhiệm vụ phát triển nào, một quy trình nhanh sẽ / có thể xem xét thiết kế trong mỗi lần lặp, phá vỡ tính hình thức cần thiết trong quy trình ITIL.

Mục tiêu chính của ITIL là, như bạn đã nói, để cung cấp một khung để đảm bảo không có gì bị bỏ qua giữa giai đoạn thiết kế / thụ thai và bảo trì (Build / Run). Trong một nền văn hóa sùng đạo, toàn đội chịu trách nhiệm về tất cả các giai đoạn về lâu dài, do đó tại sao chủ nghĩa hình thức bị cắt giảm.

Điều đó không có nghĩa là chúng ta phải quên ITIL, các nguyên tắc cốt lõi là hoàn toàn tốt và theo tôi, nên được sử dụng như một danh sách kiểm tra để xây dựng các hồ sơ tồn đọng ban đầu của sản phẩm. Chỉ là tuân theo nguyên tắc ITIL với tất cả các hình thức của nó đi ngược lại mục tiêu giảm thị trường của phát triển phần mềm lặp lại nhanh chóng và đôi khi thậm chí không thể áp dụng được vì có ít sự truyền tải thông tin cần thiết giữa các nhóm, vì các nhiệm vụ được thực hiện bởi cùng một nhóm .

Tôi đã được chứng nhận ITIL (mặc dù đã được một thời gian.) Tôi đồng ý với Tensibai: ITIL và DevOps không tương thích , nhưng điều đó không nhất thiết làm cho họ trở thành những người bạn tuyệt vời.

Có thể đưa ra lập luận rằng các quy trình trong ITIL phải xảy ra theo một cách nào đó, đặc biệt là đối với các tổ chức lớn hơn. Tích hợp thành công các thực tiễn DevOps, nơi ITIL đã được thực hành, đòi hỏi phải lập kế hoạch, giao tiếp và thực hiện cẩn thận. Sau đó, một lần nữa, điều đó đúng với bất kỳ Chuyển đổi DevOps nào.

Để chuyển đổi "trường xanh" trong đó không có ITIL hoặc DevOps, tôi sẽ tạo ra một sự kết hợp của cả hai bằng cách sử dụng thuật ngữ "ánh xạ" như bạn đã mô tả. Miễn là mọi người trong tổ chức ở trên cùng một trang, sử dụng cùng một ngôn ngữ, ITIL và DevOps có thể thêm giá trị khi kết hợp.

Tôi thích những câu trả lời do IT Skeptic cung cấp trong một tập của DevOpsCafe.org Nếu tôi nhớ chính xác, dòng suy nghĩ của anh ấy là nếu bạn thực sự hiểu ITIL, có rất ít xung đột. Hầu hết các hướng dẫn của ITIL đều rất chung chung và các xung đột chủ yếu là giữa một số triển khai ITIL, không phải đằng sau thông số kỹ thuật thực tế.