Tweet
GIỚI THIỆU MÔ HÌNH DEVOPS
DevOps là gì?Việc xác định DevOps là rất khó vì bản chất hơi mơ hồ từ những triết lý, mục tiêu và vai trò của nó trong vòng đời phát triển phần mềm.
Một vài đặc điểm chính của DevOps như:
- Thay đổi cách tiếp cận và tư duy làm việc
- Thay đổi văn hóa
- Nâng cao mức độ giao tiếp
- Tự động hóa mọi thứ
- Cung cấp phần mềm, sản phẩm và dịch vụ nhanh hơn
- Đòi hỏi sự cam kết ở tất cả các cấp độ
Phá vỡ các silo và cải thiện sự cộng tác
Một cách để làm sáng tỏ mô hình DevOps là nghiên cứu về các đặc điểm của những tổ chức đã áp dụng mô hình DevOps. Xem xét cách mà các tổ chức này làm thế nào để có được cấu trúc như vậy, cách họ sản xuất các ứng dụng mới, và cách họ cung cấp sản phẩm cũng như liên tục cải tiến sẽ rất hữu ích trong việc đi đến một định nghĩa rõ ràng.
Một số đặc điểm chính của các tổ chức này:
- Họ nắm bắt công nghệ mới
- Họ chấp nhận một văn hóa hợp tác
- Họ duy trì một mục tiêu chung được xác định rõ ràng giữa các nhóm
Điều quan trọng cần lưu ý đó là DevOps không phải là cái gì đó. DevOps không phải là phần cứng có thể mua được hoặc một phần mềm có thể được cài đặt. Mặc dù có những công cụ phần mềm thường được sử dụng trong văn hóa Devops đang chấp nhận điều đó: một nền văn hóa mới.
- Mô hình CALMS
DevOps sử dụng phương pháp lean và agile để hợp nhất bộ phận vận hành và phát triển, đồng thời cung cấp dịch vụ nhanh hơn, thường xuyên hơn và đúng hạn.
Nhiều công ty Web 2.0, chẳng hạn như Google, Netflix, Facebook và Amazon, đã chấp nhận văn hóa Devops và điều đó cho phép họ đẩy hàng chục hoặc thậm chí hàng trăm thay đổi chỉ sau một ngày. Sự thay đổi này cho phép các tổ chức cung cấp các sản phẩm và tính năng mới cho khách hàng của họ gần như theo đúng yêu cầu.
Các nguyên tắc hướng dẫn của những tổ chức này có thể được gói gọn trong từ viết tắt CALMS:
- Culture (Văn hóa): Tổ chức phải sẵn sàng thực hiện loại thay đổi này.
- Automation (Tự động hóa): Công nghệ này phải cho phép kiểm thử nhanh hơn và triển khai tính năng.
- Lean: Mục tiêu của triết lý quản lý là giảm thiểu mọi lãng phí.
- Measurement (Đo lường): Thông tin về các hoạt động đang diễn ra được chia sẻ trong thời gian thực.
- Sharing (Chia sẻ): Các hệ thống DevOps làm việc cùng nhau và có ý kiến khi mọi thứ diễn ra đúng hoặc sai.
- Phân Tích CALMS
Bảng sau đây phác thảo các đặc điểm chính của văn hóa, tự động hóa và các yếu tố lean của mô hình CALMS:
| Văn hóa | Tự động hóa | Lean | ||||
| Thói quen tốt | Tự động hóa Deploy | |||||
| 1. | Tin tưởng | 1. | Ansible | | Xác định sự lãng phí | |
| 2. | Tôn trọng | 2. | Chelf | |||
| | Liên tục học hỏi | |||||
| 3. | Hỗ trợ | 3. | Puppet | |||
| | Tập trung vào con người | |||||
| 4. | Hợp tác | 4. | Terraform | |||
| | Tối ưu hóa toàn bộ | |||||
| 5. | Không đổ lỗi, không | Tự động hóa xảy ra ở mọi | ||||
| có nạn nhân | nơi và giữa các nhóm | |||||
| 6. | Mục tiêu chung | |||||
| Phát triển quản lý | ||||||
Văn hóa được cho là khía cạnh quan trọng nhất của một tổ chức quan tâm đến việc triển khai cách tiếp cận agile và DevOps để phát triển phần mềm. Một văn hóa DevOps tín nhiệm và phát triển dựa trên những đặc điểm như sự tin tưởng và tôn trọng lẫn nhau giữa các đồng nghiệp, sự hỗ trợ, cộng tác và ý thức rằng không ai bị đổ lỗi khi có sự cố xảy ra. Những nét tiêu biểu này đi cùng với mục tiêu chung, mang lại cho những người làm việc cho các tổ chức DevOps sự tự do và động lực để đổi mới, thử nghiệm và cộng tác.
Tuy nhiên, loại hình văn hóa này đòi hỏi một luồng thông tin rất khác so với các cơ cấu tổ chức truyền thống hơn. Ví dụ, những người quản lý phải nắm bắt bầu không khí hợp tác chia sẻ thông tin và từ bỏ cách tiếp cận từ trên xuống để quản lý tổ chức.
Trong các tổ chức sử dụng phương pháp DevOps, các nhóm vận hành sẽ tham gia vào nhiều hơn. Kiến thức và công cụ thường chỉ được sử dụng trong phát triển phần mềm hoặc là các silo quản trị hệ thống sẽ được chia sẻ với tất cả các nhóm trong tổ chức.
Các công cụ tự động hóa như Ansible, Chef và Puppet không phải là mới, nhưng việc phá vỡ các silo và chia sẻ kiến thức mới là điều đáng nói. Ngày nay, các nhóm vận hành làm việc với các nhóm phát triển để sử dụng các kỹ thuật tự động hóa nhằm thúc đẩy các thay đổi thường xuyên qua đó giúp tổ chức phát triển vượt bậc. Trong môi trường DevOps, tự động hóa sẽ xuất hiện ở mọi nơi và giữa các nhóm.
Thuật ngữ Lean xuất phát từ Lean Manufacturing, ban đầu được phát triển bởi Toyota, một tập hợp các nguyên tắc để đạt được chất lượng, tốc độ và sự phù hợp với khách hàng. Mục đích chính của Lean là loại bỏ bất cứ thứ gì không tạo thêm giá trị và chỉ làm việc trên những gì thực sự cần thiết. Loại bỏ lãng phí có nghĩa là loại bỏ các cuộc họp, công việc và tài liệu vô ích, nhưng nó cũng đồng nghĩa với việc loại bỏ thời gian dành cho việc xây dựng những gì chưa biết hoặc cần thiết trong tương lai.
Phát triển phần mềm Lean cũng là để học hỏi. Bạn cần phải có cấu trúc công việc để đảm bảo rằng bạn không ngừng học hỏi nhưng cũng đồng thời mang lại giá trị cho hiện tại.
Tiếp theo, Lean quan tâm đến mọi người. Các ý tưởng Lean điển hình bao gồm việc đặt nhóm của bạn lên hàng đầu, phản hồi kịp thời, lắng nghe và xem xét ý kiến của mọi người. Thực tiễn này có nghĩa tất cả mọi người biết rằng thất bại là không sao, nhưng họ phải học hỏi từ những sai lầm của họ.
Cuối cùng, Lean nhấn mạnh vào cái gọi là “hệ thống”, cách mà nhóm hoạt động nói chung.
Bảng sau đây trình bày các đặc điểm chính của yếu tố đo lường và chia sẻ của mô hình văn hóa , tự động hóa, tinh gọn, đo lường, chia sẻ (CALMS)
John Wills, một người kỳ cựu trong ngành DevOps đã từng chia sẻ, “Nếu bạn không thể đo lường, bản không thể trở nên tốt hơn. Việc triển khai DevOps có thành công hay không dựa vào việc đo lường mọi thứ thường xuyên nhất có thể… số liệu về hiệu suất, số liệu quy trình và thậm chí cả số liệu về con người ”.
Các phép đo lường giúp bạn biết được những gì đang xảy ra trong thời gian thực và những gì đã xảy ra theo thời gian. Nhiều chỉ số có thể được thu thập và đo lường, bao gồm:
- Số lượng và tần suất phát hành phần mềm
- Khối lượng hao hụt
- Thời gian và chi phí cho mỗi lần phát hành
- Trung bình thời gian sửa chữa của mỗi lần hư hỏng (MTTR)
- Số lượng và tần suất mất điện và các vấn đề về hiệu suất
- Tác động đến doanh thu và lợi nhuận của sự cố ngừng hoạt động và các vấn đề về hiệu suất
- Số lượng và chi phí tài nguyên
- Các dòng code không liên quan
- Thu thập và quản lý các yêu cầu
- Phát triển Agile
- Phát hành và triển khai
- Unit test
- Kiểm tra sự tiếp nhận của người dùng
- Đảm bảo chất lượng
- Giám sát năng suất vận hành của ứng dụng
Có những yếu tố khác có thể khó định lượng hơn nhưng vẫn rất quan trọng để kiểm tra. Một số phép đo lường như sau:
- Thái độ đối với việc cải tiến liên tục
- Nỗi ám ảnh với các số liệu
- Thử nghiệm công nghệ
- Quyền tự chủ của nhóm
- Phần thưởng và cảm giác thành công
- Những trở ngại gây khó chịu về thứ bậc và chính trị
- Truyền cảm hứng và thúc đẩy sự sáng tạo
- Tổ chức các nhóm xung quanh dự án hơn là bộ kỹ năng
- Không ngừng bập bênh trên bờ vực của thất bại (theo cách tốt)
- Vị trí xung quanh nhu cầu kinh doanh
Ví dụ, Hubot là một công cụ giúp thực hiện điều này. Từ góc độ thay đổi tự động, Hubot là một bot trò chuyện mà Github đã phát triển và làm ra mã nguồn mở. Bằng cách sử dụng bot trò chuyện như Hubot, bạn có thể đảm bảo rằng mọi người đều nhìn thấy mọi thứ. Có thể tích hợp Hubot vào các nền tảng động như Cisco Jabber và Slack. Quy trình công việc chung có thể được tự động hóa để cho phép truy vấn thiết bị mạng, thực hiện thay đổi và các hành động khác từ cuộc trò chuyện nhóm. Vì mọi người trong nhóm đều thấy những gì đang xảy ra, giao tiếp được cải thiện và đó cũng là một cơ hội lớn để đào tạo kỹ sư mới và nhân viên mới.