Tweet
GIỚI THIỆU MÔ HÌNH DEVOPS
TRIẾT LÝ DEVOPS
• Cần thiết cho một mô hình hoạt động mới
Trong những năm gần đây, một số xu hướng và đổi mới trong ngành đã thay đổi cách thức kinh doanh. Các doanh nghiệp đang dần chuyển đổi sang các hệ thống bao gồm tính cơ động, internet vạn vật và dịch vụ đám mây để đáp ứng nhu cầu của thị trường và đòi hỏi sự nhanh nhẹn, đơn giản, tốc độ và đổi mới để bắt kịp xu hướng hiện tại. Sự chuyển đổi này thường được gọi là chuyển đổi số, nó đòi hỏi các doanh nghiệp phải đưa vào những công cụ, văn hóa và quy trình mới để thay đổi cách mọi thứ đã được thực hiện lúc trước, đặc biệt là về cách mà bộ phận phát triển (developers) và bộ phận vận hành (operations) liên quan đến nhau
Tốc độ thay đổi và thích ứng với các yêu cầu mới của doanh nghiệp không còn đủ nhanh để có thể đáp ứng được kỳ vọng hiện tại của ngành. Để có thể đáp ứng nhu cầu chuyển đổi kỹ thuật số, các tổ chức đang khám phá DevOps và tìm hiểu cách nó có thể được áp dụng trong doanh nghiệp qua đó cho phép một trạng thái hoạt động nhanh hơn, an toàn và đáng tin cậy hơn.
- Làm sáng tỏ DevOps
Theo truyền thống, bộ phận phát triển phần mềm và bộ phận vận hành nằm trong các silo (ngăn chứa) riêng biệt. Các nhà phát triền phần mềm tập trung vào việc tạo ra các tính năng và cung cấp các ứng dụng một khối. Nhóm vận hành tập trung vào việc cho phép kết nối và đảm bảo một môi trường ổn định và đáng tin cậy để qua đó nhóm phát triển có thể mang lại giá trị. Các phương pháp DevOps phá vỡ các rào cản giữa việc phát triển phần mềm và vận hành triển khai (deploy) cũng như bảo trì phần mềm.
Lợi ích chính của việc đóng silo nhóm vận hành riêng và nhóm phát triển riêng đó là vì mỗi nhóm có thể chuyên môn hóa và sử dụng chuyên môn của mình để mang lại giá trị. Trước khi các doanh nghiệp bắt tay vào chuyển đổi số, cách tiếp cận này đã từng khá phổ biến và cho phép các doanh nghiệp bắt kịp xu hướng của ngành.
Giờ đây, việc số hóa đã gây trở ngại với các doanh nghiệp, bộ phận vận hành (IT Operations) không thể chỉ tập trung hoàn toàn vào kết nối mạng mà không chú trọng đến tự động hóa và văn hóa DevOps. Các ứng dụng không còn được phát hành đơn lẻ, vài năm một lần; giờ đây các ứng dụng liên tục có các bản phát hành mới, thêm các tính năng mới, và yêu cầu được cập nhật thường xuyên cho cơ sở hạ tầng, với kỳ vọng sẽ có sự thay đổi nhanh chóng.
- Dev và Ops: Vấn Đề Nan Giải
Đầu tiên, các nhà phát triển quan tâm đến việc viết phần mềm. Họ quan tâm đến APIs (Application Program-ming Interfaces), thư viện, và code. Phần mền họ viết phải có chất lượng cao và đáp ứng được kỳ vọng của khách hàng. Thành công được xác định dựa trên việc liệu phần mềm có chạy tốt như mong đợi hay không và liệu nó có được hoàn thành và giao đúng thời hạn hay không.
Bảng sau đây sẽ trình bày sự khác biệt giữa các nhà phát triển và nhân viên vận hành.
| Thế giới của các nhà phát triển | Thế giới của các nhân viên vận hành | ||||
| | Quan tâm đến | | Quan tâm đến | ||
| 1. | Viết phần mềm | 1. | Mọi thứ ổn định | ||
| 2. | Làm việc với code | 2. | Đạt tiêu chuẩn | ||
| 3. | APIs | 3. | Các template | ||
| 4. | Thư viện | 4. | Không bị làm phiền lúc 2 giờ sáng. | ||
| 5. | Sprints (Các phân đoạn lặp đi lặp | | Thành công | ||
| lại trong một dự án) | 1. | Phần mềm ổn định | |||
| | Thành công | 2. | Sao lưu và phục hồi công việc | ||
| 1. | Phần mềm hoạt động : Test cục bộ | 3. | Hệ thống hoạt động bên trong các ngưỡng xác định | ||
| và trên server | |||||
| 2. | Hoàn thành sprint | ||||
Mặt khác, bộ phận vận hành quan tâm đến các tiêu chuẩn và tính ổn định của phần mềm. Bộ phận vận hành có các cửa sổ quản lý thay đổi cố định cho việc triển khai phần mềm mới. Thành công cho các nhân viên vận hành được thể hiện bằng một môi trường ổn định và hữu dụng. Các yếu tố tác động và định nghĩa thành công rõ ràng là khác nhau đối với các nhà phát triển và nhân viên vận hành. Hơn nữa, khi doanh nghiệp tiếp tục thúc đẩy sự phát triển của các ứng dụng mới, các nhà phát triển tiếp tục viết phần mềm theo thời hạn nghiêm ngặt của họ, nhưng các nhân viên vận hành thường nhận thấy rằng rất khó để tung ra phần mềm mới do tồn đọng của các yêu cầu thay đổi.
Các nhà phát triển và nhân viên vận hành nhìn thế giới từ các khía cạnh khác nhau :
- Nhóm phát triển muốn phát hành phiên bản mới của ứng dụng và sản phẩm mới càng nhanh càng tốt.
- Nhóm vận hành muốn có một môi trường đáng tin cậy và ổn định.
Hình ảnh này cho thấy cách mà “bức tường của sự nhầm lẫn” tạo ra các silo tách biệt trong một tổ chức CNTT. Một trong những mục tiêu chính của Devops là phá vỡ các silo và tăng cường giao tiếp giữa các nhóm. Mục tiêu này là cực kỳ quan trọng đối với các tổ chức muốn triển khai (deploy) phần mềm và dịch phụ nhanh hơn, thường xuyên hơn
Vấn đề nằm ở chỗ, giai đoạn phát triển và vận hành thường nằm trong các bộ phận khác nhau, biệt lập của một tổ chức.
Một cách khác để hình dung ra vấn đề này là xem lịch làm việc của từng nhóm. Nếu tổ chức đang sử dụng Agile, các nhóm phát triển có khả năng hoàn thành các mốc quan trọng hai tuần một lần. Ngược lại, lịch của nhóm vận hành trong hình mô tả những lần mở thay đổi hiếm khi xảy ra. Do các yếu tố như giảm thiểu rủi ro, thời lượng thay đổi thực tế có thể được lên lịch vài tuần hoặc vài tháng kể từ khi triển khai.
Bộ phận phát triển đang cố gắng làm thỏa mãn doanh nghiệp thông qua các tính năng và phần mềm, và bộ phận vận hành thì đang cố gắng đáp ứng thông qua sự ổn định. Thử thách chính là để họ làm việc cùng nhau thành công.
Khi các nhóm phát triển và vận hành không làm việc cùng nhau, họ trở nên tách biệt với nhau và đôi khi là tách biệt với phần còn lại của tổ chức. Thói quen này tạo ra một môi trường không hiệu quả cho việc triển khai các ứng dụng mới.
Các phương pháp như thác nước (waterfall) có thể tạo ra các silo này. Khó khăn trong việc chia sẻ các nguồn lực của công ty đã được biết đến là nguyên nhân tạo ra rạn nứt giữa các nhóm hoặc do nhiều nguyên nhân khác như văn hóa đổ lỗi và thù địch. Các nhóm có xu hướng trở nên tách biệt hơn khi họ chỉ tập trung vào phần nhỏ của quá trình phát triển.
DevOps tìm cách phá vỡ các silo này để khôi phục giao tiếp và sự cộng tác giữa các nhóm. Với hy vọng là phương pháp này sẽ dẫn đến tăng hiệu suất và chất lượng cũng như chia sẻ thông tin hữu ích cho tất cả các nhóm, thay vì phân chia thành từng ngăn giống như cách mà các phương pháp truyền thống tạo ra.