Mặc dù các giải pháp PaaS (Nền tảng là dịch vụ) không thể thay đổi cách các cá nhân và nhóm tương tác nhưng chúng thường đóng vai trò là chất xúc tác cho sự thay đổi của tổ chức nhằm đáp ứng sự linh hoạt ngày càng tăng của CNTT.
Trên thực tế, lợi tức đầu tư tối đa vào PaaS thường chỉ có thể đạt được nếu vai trò, trách nhiệm (nhiệm vụ) và mối quan hệ của tổ chức được thay đổi. May mắn thay, các giải pháp PaaS như OpenShift Container Platform đủ linh hoạt để cho phép mỗi tổ chức CNTT xác định tốc độ và quy mô thay đổi liên quan đến những người liên quan và các quy trình diễn ra.
Ở giai đoạn đầu tiên của quá trình container hóa doanh nghiệp, ưu tiên chính là triển khai nền tảng container như một hệ thống triển khai ứng dụng mới. Tại thời điểm này, các tổ chức gắn các công việc quen thuộc với các vai trò quen thuộc để đáp ứng các yêu cầu tiêu chuẩn từ nhóm phát triển về các vấn đề như hệ thống lưu trữ, môi trường triển khai, v.v. Ở các giai đoạn tiếp theo của quá trình container hóa, chúng ta đã nói về tự động hóa hoặc cung cấp khả năng tự phục vụ cho các nhà phát triển nhằm giảm bớt gánh nặng cho quản trị viên hệ thống và nâng cao quyền tự chủ cũng như khả năng phản hồi của nhà phát triển. Đây là cách một tổ chức bắt đầu hướng tới DevOps. Ở giai đoạn cuối cùng của quá trình container hóa, doanh nghiệp tiến đến một mô hình DevOps chuẩn, thuần túy hơn, trong đó nhiều nhiệm vụ và công việc trước đó nằm dưới sự kiểm soát của các nhóm đa chức năng được nhóm lại không phải theo nền tảng hoặc công nghệ mà từ quan điểm quan điểm đảm bảo hoạt động của các ứng dụng hoặc dịch vụ ứng dụng.
Trong bài đăng này, chúng tôi sẽ cung cấp hướng dẫn về cách thực hiện những thay đổi cần thiết về mặt tổ chức và vai trò CNTT truyền thống đang thay đổi như thế nào khi áp dụng công nghệ container trong doanh nghiệp.
Liên kết công việc mới với vai trò cũ
Ở dạng cơ bản và ban đầu, mô hình tổ chức PaaS được thiết kế để phân bổ tài nguyên CNTT cho các ứng dụng một cách linh hoạt và nhanh chóng hơn dưới dạng môi trường chạy. Mặc dù điều này mang lại một số lợi thế cho các quản trị viên hệ thống, nhưng các nhà phát triển thường không nhận được bất kỳ lợi ích đáng kể hoặc khả năng mới nào, vì ở giai đoạn này, doanh nghiệp có thể dễ dàng không cần đến tự động hóa, tự phục vụ hoặc cải thiện đáng kể quy trình triển khai. Mặc dù tác động tối thiểu đến các quy trình phát triển ở giai đoạn này, PaaS vẫn làm tăng tính linh hoạt của hệ thống CNTT, cho phép các quản trị viên phục vụ tốt hơn các yêu cầu của nhà phát triển. Ví dụ, trước đây việc tạo môi trường phát triển từ một số thành phần khác nhau đòi hỏi nhiều thao tác phức tạp hơn. máy ảo Trong khi việc tạo và triển khai các ổ lưu trữ có thể mất nhiều ngày hoặc thậm chí nhiều tuần, đòi hỏi sự tham gia của nhiều quản trị viên khác nhau, thì trong PaaS, mọi thứ được thực hiện nhanh hơn nhiều và chỉ bởi một quản trị viên. Nói cách khác, các nhóm phát triển vẫn gửi yêu cầu như trước, nhưng công việc thực hiện chúng giờ đây được tiến hành theo một mô hình mới.
Hướng tới một tổ chức DevOps
Bằng cách khởi chạy PaaS và chuyển đổi các chuyên gia vận hành CNTT cũng như nhà phát triển ứng dụng sang PaaS, tổ chức có thể tiếp tục triển khai phương pháp DevOps, trong đó bao gồm các nguyên tắc cơ bản sau:
- Chia nhỏ công việc thành các bước nhỏnhận được phản hồi sớm, giảm thiểu rủi ro và tránh tình trạng tê liệt phân tích;
- Tự động hóa đủ các hoạt độngtránh tạo trở ngại, ách tắc trong quá trình triển khai ứng dụng;
- Chia sẻ kiến thức – chìa khóa để xây dựng niềm tin;
- Thường xuyên thanh toán các khoản nợ kỹ thuật, phân bổ thời gian nhất định trong mỗi chu trình làm việc để cải tiến hệ thống.
Trong giai đoạn thứ hai của việc áp dụng công nghệ container, các nhóm phát triển đương nhiên bắt đầu nhìn thấy cơ hội cải tiến và doanh nghiệp hướng tới mô hình DevOps truyền thống hơn. Cơ chế gửi và thực hiện các yêu cầu dịch vụ truyền thống hiện được coi là nút thắt cổ chai, vì vậy tổ chức đang tìm cách tự động hóa các hành động lặp đi lặp lại và cung cấp khả năng tự phục vụ cho các nhà phát triển. Hơn nữa, khả năng của nhà phát triển trong một ứng dụng nhất định được xác định bởi nỗ lực chung của các chuyên gia CNTT vận hành nền tảng và những người chịu trách nhiệm phân phối ứng dụng. Nói cách khác, quản trị viên hệ thống, những người thực hiện các hành động theo yêu cầu của nhà phát triển, đang được thay thế bởi hai loại nhân viên nêu trên, những người chịu trách nhiệm mô tả và áp dụng các chính sách quản lý chính xác những gì nhà phát triển được phép tự làm. Quy trình tự động giúp đảm bảo tuân thủ các yêu cầu cụ thể và phối hợp hành động khi tình huống nằm ngoài phạm vi của các chính sách hiện có.
Chuyển sang một lịch trình lặp đi lặp lại, trong đó môi trường CNTT và mô hình vận hành trải qua những thay đổi lặp đi lặp lại theo thời gian, là một cột mốc quan trọng để đạt được một doanh nghiệp DevOps trưởng thành. Mức độ áp dụng phương pháp DevOps phụ thuộc vào khả năng chấp nhận thay đổi của từng tổ chức và những thay đổi nào mang lại nhiều lợi ích nhất. Ví dụ: nếu nhu cầu tạo môi trường hoặc ứng dụng mới xảy ra không thường xuyên thì việc tối ưu hóa các hoạt động tương ứng sẽ ít quan trọng hơn việc tăng cường quyền kiểm soát của nhà phát triển đối với vòng đời ứng dụng.
Những thách thức mới nảy sinh trong các tổ chức CNTT khi chuyển sang OpenShift
Trong phần này, chúng ta sẽ xem xét các vai trò và nhiệm vụ mà các tổ chức đã áp dụng OpenShift thường sử dụng để tăng tốc độ tự động hóa và tự phục vụ bằng công nghệ và PaaS.
Bảng bên dưới liệt kê các nhiệm vụ cấp cao nhất tồn tại trong bất kỳ tổ chức nào đã triển khai OpenShift, cùng với các ví dụ về các công việc và kỹ năng liên quan. Không nên nhầm lẫn danh sách nhiệm vụ này với cấu trúc phân chia công việc hoặc cấu trúc nhóm mà là một tập hợp các nhiệm vụ phải được hoàn thành bởi những người chịu trách nhiệm hỗ trợ (các) môi trường CNTT để triển khai thành công nền tảng container. Trên thực tế, chúng tôi sẽ chỉ ra thêm rằng việc giới thiệu các công nghệ container tạo tiền đề cho việc hình thành chiến lược DevOps trưởng thành hơn trong doanh nghiệp, từ đó làm tăng mức độ chức năng chéo của các nhóm và giảm rủi ro về chuyên môn hóa hẹp ở cấp độ nhóm. trình độ của cá nhân và tập thể.
Bảng 1. Định nghĩa tác vụ OpenShift
nhiệm vụ
Kỹ năng cần thiết
Tự động hóa và cung cấp cơ sở hạ tầng CNTT
Làm:
- Thiết kế và xây dựng giải pháp phần cứng
- Tổ chức và hỗ trợ tự động hóa thiết lập ban đầu
- Thiết kế và tự động hóa VM và chuẩn bị máy chủ
- Thiết kế và triển khai trung tâm dữ liệu
- Quản trị hệ thống Linux
- Kịch bản tự động hóa
- Kiến thức về hệ thống lưu trữ
- Kiến thức về thiết kế và triển khai mạng
- Безопасность
Cài đặt và quản lý nền tảng OpenShift
Làm:
- Thực hiện cài đặt cụm
- Quản lý dịch vụ cơ sở hạ tầng
- Quản lý mở rộng quy mô nền tảng
- Xác thực và ủy quyền cấp nền tảng
- Quản trị hệ thống Linux
- Kiến thức về công nghệ mạng
- Tập lệnh tự động hóa (Ansible)
- Kiến thức về hệ thống lưu trữ
- Kiến thức về công nghệ và kiến trúc container
- Kiến thức về kiến trúc Kubernetes và OpenShift
- Bảo mật nền tảng
- Giám sát tích hợp
Quản lý việc chuẩn bị môi trường khách hàng (cung cấp đối tượng thuê), cách ly năng lực CNTT
Làm:
- Tạo người dùng và nhóm trong nền tảng
- Thiết kế và quản lý hạn ngạch
- Thiết kế và triển khai RBAC
- Kiến thức về kiến trúc Kubernetes và OpenShift
- Kiến thức về công nghệ và kiến trúc container
- Kịch bản tự động hóa
- Kiến thức tốt về dự án, chỉ tiêu, phân công vai trò và làm việc với người lập kế hoạch
Xây dựng và quản lý hình ảnh cơ sở
Làm:
- Phát triển quy trình sửa đổi hình ảnh
- Phát triển hình ảnh dựa trên tiêu chuẩn
- Quản trị hệ thống Linux
- Kịch bản tự động hóa
- Định cấu hình các thành phần ứng dụng thời gian chạy và phần mềm trung gian
- Kiến thức về kiến trúc container
- Khung xây dựng ứng dụng
- Kiến thức tốt về hình ảnh, dòng hình ảnh và các mẫu
Thiết kế và quản lý quy trình triển khai
Làm:
- Thiết kế và tài liệu về tiêu chuẩn băng tải
- Phát triển các hướng dẫn và mẫu nhanh chóng
- Đào tạo nhà phát triển
- Quản lý mã nguồn
- Thiết kế và triển khai ứng dụng
- Kịch bản tự động hóa
- Kiểm tra tự động
- Kiểm tra chất lượng mã
- Kiến thức về kiến trúc container
- Kiến thức về cơ sở hạ tầng bất biến
- Bảo mật – quản lý quyền truy cập vào các giai đoạn của quy trình, phê duyệt quy trình công việc, v.v.
- Kiến thức tốt về các mẫu OpenShift, cấu hình xây dựng thành phần, cấu hình triển khai, dịch vụ, tuyến đường, sơ đồ cấu hình
Phát triển ứng dụng và thử nghiệm
Làm:
- Mã hóa ứng dụng
- Phát triển các bài kiểm tra tự động
- Xử lý các lỗi kiểm thử trong quá trình triển khai
- Xử lý lỗi ứng dụng
- Kiểm tra sự chấp nhận của người dùng
- Thiết kế và triển khai ứng dụng
- Kiểm tra tự động
- Quản lý mã nguồn
- Giám sát ứng dụng
- Kiến thức về kiến trúc ứng dụng gốc trên nền tảng đám mây
Giám sát hoạt động và quản lý ứng dụng
Làm:
- Thiết kế ứng dụng trong bối cảnh hiệu suất
- Giám sát ứng dụng trong thời gian chạy
- Chia tỷ lệ ứng dụng (hoặc tự động chia tỷ lệ)
- Quản lý tính sẵn có của ứng dụng
- Yêu cầu hạn ngạch và giới hạn quản lý tài nguyên
- Kiểm tra hiệu suất và năng lực CNTT
- Thiết kế và triển khai hiệu suất ứng dụng
- Giám sát hiệu suất ứng dụng
- Kiểm tra hiệu suất và tải
Kiểm tra sự chấp nhận của người dùng
Làm:
- Kiểm tra giao diện người dùng (thiết kế và trải nghiệm người dùng)
- Phát triển các bài kiểm tra tự động
- Thiết kế và thử nghiệm giao diện người dùng
- Mẫu thử nghiệm tự động
- Khung kiểm tra
- Mẫu thiết kế ứng dụng
Các vai trò mới phát sinh trong tổ chức CNTT khi di chuyển sang OpenShift
Khi chúng tôi chuyển sang mô hình tổ chức lấy DevOps làm trung tâm, mức độ chuyên môn hóa vai trò có xu hướng giảm xuống và số lượng các nhóm và vai trò đa chức năng lần lượt tăng lên để tối đa hóa hiệu quả cộng tác. Dưới đây là những gì chúng tôi nghĩ rằng danh sách các vị trí chủ chốt trong một tổ chức CNTT sử dụng OpenShift trông như sau:
- Kỹ sư vận hành ứng dụng HOẶC Kỹ sư độ tin cậy của trang web. Trước đây, vị trí này có thể được gọi là “Quản trị viên máy chủ ứng dụng”.
- Nhà phát triển ứng dụng/Nhà phát triển phần mềm/Kỹ sư phần mềm.
- Quản trị viên cụm máy chủ/nền tảng ứng dụng. Trước đây, vai trò này có thể được gọi là "Quản trị viên hệ thống" hoặc "Quản trị viên". Linux-các nền tảng".
- Người quản lý phát hành/Kỹ sư xây dựng.
Ma trận vai trò và nhiệm vụ RACI
Cuối cùng, chúng ta chuyển sang so sánh các vị trí và nhiệm vụ đã thảo luận ở trên để đưa ra ý tưởng chung về cấu trúc của một tổ chức triển khai DevOps trên nền tảng OpenShift sẽ như thế nào. Ban đầu, các vai trò sau đây có thể được thực hiện bởi các nhánh khác nhau của cơ cấu tổ chức truyền thống cũ. Nhưng theo thời gian, quá trình hợp nhất diễn ra và các nhóm mới được xây dựng dựa trên các ứng dụng đảm nhận hầu hết hoặc thậm chí tất cả các nhiệm vụ được liệt kê bên dưới.
nhiệm vụ
Vai trò
Kỹ sư vận hành ứng dụng / Kỹ sư độ tin cậy của trang web
Nhà phát triển ứng dụng / Nhà phát triển phần mềm / Kỹ sư phần mềm
Quản trị viên nền tảng cụm/ứng dụng
Giám đốc phát hành phần mềm/Kỹ sư lắp ráp
Tự động hóa và cung cấp cơ sở hạ tầng CNTT
I
I
R / A
C
Cài đặt và quản lý nền tảng OpenShift
C
I
R / A
C
Thiết kế và quản lý quy trình triển khai
C
C
I
R / A
Quản lý việc cung cấp, cách ly và năng lực CNTT của đối tượng thuê
C
I
R / A
I
Xây dựng và quản lý hình ảnh cơ sở
R
C
R / A
C
Phát triển ứng dụng và thử nghiệm
C
R / A
I
I
Giám sát hoạt động và quản lý ứng dụng
R / A
C
C
I
Kiểm tra sự chấp nhận của người dùng
C
R
I
I
Các quy ước trong ma trận RACI
Nguồn:
- Chịu trách nhiệm – Người thực hiện là người làm những gì cần thiết để hoàn thành nhiệm vụ.
- Có trách nhiệm – Chịu trách nhiệm – nhân viên chịu trách nhiệm cuối cùng về việc thực hiện chính xác và triệt để một nhiệm vụ hoặc đạt được kết quả; và cũng là người duy nhất có thể ủy thác công việc cho người biểu diễn.
- Tư vấn – Nhà tư vấn – thường đây là những chuyên gia về chủ đề cần tìm kiếm lời khuyên; Giao tiếp hai chiều được duy trì với họ.
- Thông báo – Được thông báo – những người được thông báo về các sự kiện (và đôi khi chỉ khi hoàn thành một nhiệm vụ hoặc đạt được kết quả); họ nhận được thông tin một cách đơn phương.
Cách các nhóm làm việc cùng nhau trong tổ chức DevOps
Việc thu thập tài nguyên truyền thống thường bao gồm một chu kỳ yêu cầu tài nguyên, sau đó được thực hiện bởi nhiều nhóm. Cuối cùng, tất cả các nguồn lực cần thiết sẽ được phân bổ và xác nhận bởi bên yêu cầu. Thông thường, các quy trình này được thực hiện thủ công một phần hoặc toàn bộ và yêu cầu các nhóm tương tác thường xuyên và nhiều lần để xử lý thành công từng yêu cầu.
Hình 1. Tổ chức CNTT truyền thống
Sơ đồ trên minh họa mối quan hệ điển hình giữa các nhóm trong một tổ chức CNTT truyền thống. Trong kế hoạch này, một số nhóm liên hệ với các nhóm khác để yêu cầu thực hiện công việc cần thiết, sử dụng các phương tiện liên lạc ít nhiều chính thức, chẳng hạn như hệ thống vé hoặc email. Những yêu cầu này sau đó sẽ được xếp thành hàng đợi và chờ đợi ở cánh, thời gian chờ đợi lâu thường dẫn đến mối quan hệ giữa các nhóm trở nên xấu đi hoặc thậm chí trở nên trầm trọng hơn. Thêm vào sự căng thẳng là thực tế là các thành viên của các nhóm khác nhau hiếm khi gặp nhau trực tiếp và có xu hướng chỉ chia sẻ những thông tin cần thiết tối thiểu.
Hình 2: Tổ chức CNTT DevOps
Sơ đồ này cho thấy cách hoạt động cộng tác trong tổ chức DevOps. Ở đây, các nhóm tương tự trong sơ đồ trước đã loại bỏ các hoạt động liên lạc không hiệu quả nhằm củng cố các hầm chứa và thay thế chúng bằng các liên hệ cá nhân, từ đó tạo ra các kênh tương tác liên tục giữa các nhóm. Các kênh này thúc đẩy bộ kỹ năng kết hợp giúp nhân viên hiểu rõ hơn và hình dung rõ hơn về nhu cầu, thách thức và cơ hội của nhóm mà họ đại diện. Các nhóm trao quyền cho nhau để hoàn thành công việc thông qua các cổng tự phục vụ tự động, thay vì xử lý thủ công các yêu cầu thay đổi của người khác như trường hợp trước đây. Và nhờ có các kênh tương tác, các hệ thống tự phục vụ này có thể nhanh chóng thích ứng với nhu cầu của các nhóm mà chúng được thiết kế. Để đạt được sự hiểu biết và chia sẻ kiến thức lớn hơn trong tổ chức, các thành viên trong nhóm luân phiên vai trò theo định kỳ để tích lũy kinh nghiệm tương tác với các nhóm khác nhau và hiểu rõ hơn về bức tranh toàn cảnh về hệ thống CNTT mà họ hỗ trợ, từ đó tăng mức độ chức năng chéo và tính hữu ích của họ.
Tổng hợp
Trong bài đăng này, chúng tôi đã thảo luận về cách áp dụng các giải pháp PaaS có thể đưa một tổ chức hướng tới DevOps, thay đổi các vai trò và nhiệm vụ truyền thống như một phần của quy trình. Đó là lý do tại sao chúng tôi đã liệt kê những thách thức CNTT chính mà tổ chức phải đối mặt khi chuyển sang OpenShift, cũng như các kỹ năng cần thiết để hoàn thành chúng. Chúng tôi cũng cung cấp một nhóm vai trò tổ chức cốt lõi phát sinh khi xây dựng các nhóm DevOps đa chức năng và ma trận RACI liên kết các vai trò mới với nhiệm vụ mới. Cuối cùng, chúng tôi đã thảo luận về cách nền tảng OpenShift và phương pháp DevOps liên quan của nó có thể thay đổi cơ cấu tổ chức của các tổ chức khi họ chuyển từ hệ thống phân cấp và phiếu yêu cầu truyền thống sang các nhóm đa chức năng với mức độ giao tiếp cá nhân cao hơn.
Nguồn: www.habr.com
