Sự khác biệt giữa DevOps và Tự động hóa là gì?

Tôi thấy rằng bất cứ khi nào ai đó làm DevOps, chủ yếu là về tự động hóa những thứ như triển khai, v.v.

Nhưng tự động hóa kết thúc và DevOps bắt đầu từ đâu?

Một phần lớn của DevOps là làm cho nó có thể phát hành rất thường xuyên. Điều đó đi kèm với xây dựng tự động, thử nghiệm tự động, v.v. Bạn có thể nói rằng để đạt được mục tiêu của mình, DevOps cần sử dụng tự động hóa để có hiệu quả.

Đây là cách DevOps và tự động hóa có liên quan. DevOps không chỉ là tự động hóa, còn nhiều hơn thế. Ngược lại, tự động hóa không chỉ được sử dụng bởi "người DevOps". Rất nhiều tự động hóa đã diễn ra trong CNTT trước khi DevOps xuất hiện.

Vui lòng không xem xét sơ đồ trên để thể hiện tất cả những gì là DevOps hoặc tất cả điều này là tự động hóa. Nó là để giúp người đọc hình dung làm thế nào hai khái niệm có liên quan.

Tự động hóa là một thuộc tính quan trọng của DevOps, nhưng nó không phải là câu chuyện đầy đủ. Câu hỏi đại loại như "Sự khác biệt giữa đấm bốc thời gian và Scrum là gì?".

Bạn sẽ nghe DevOps gọi là "văn hóa", "phong trào", "phương pháp luận" và tất cả những thứ không thể đóng hộp đủ để bạn hiểu về nó, mặc dù những mô tả đó là chính xác. Tóm lại, DevOps nói về sự hợp lưu của các phương pháp, tự động hóa và ảo hóa Agile cho phép một vòng phản hồi mới trong việc quản lý / điều khiển / điều khiển dự án phần mềm.

Với tự động hóa tích cực, những thứ sử dụng mất nhiều thời gian và chịu lỗi của con người giờ đây sẽ xảy ra nhanh chóng và không có sự cố. Kết quả là, chúng ta có xu hướng làm chúng thường xuyên hơn. Một ví dụ chính về điều này là "triển khai vào sản xuất". Chúng tôi thường lưu các lô công việc lớn và triển khai chúng ngoài giờ chỉ trong trường hợp 'có gì đó không ổn'. Nhưng bây giờ chúng ta có thể triển khai các thay đổi nhiều lần trong ngày, theo cách mà khả năng "xảy ra sự cố" sẽ giảm đáng kể và theo cách mà tác động của một sự cố xảy ra sẽ nhỏ hơn rất nhiều khi nó xảy ra.

Khi chúng tôi có quy trình lặp lại này, chúng tôi bắt đầu xem nó như một "đường ống". Yêu cầu đi vào, mã triển khai vào sản xuất đi ra. Chúng tôi tự động hóa mọi thứ dọc theo đường ống này - thử nghiệm, tài liệu, sáp nhập, triển khai và nhiều thử nghiệm khác, v.v ... Bởi vì mọi người tập trung vào tự động hóa, họ không thấy "tâm lý đường ống" đã thúc đẩy nó. Đây là phương pháp quản lý - sự chú ý được trả cho đường ống - làm cho DevOps nhiều hơn Tự động hóa.

Khi chúng tôi có tính năng tự động hóa đó, các vòng phản hồi sẽ bắt đầu. Chúng tôi bắt đầu đo lường những thứ như thời gian chu kỳ để chúng tôi có thể tìm ra những điều mà trước đây chúng tôi đã cố gắng đoán bằng các ước tính. Những điều về kiến ​​trúc làm cho tự động hóa / phân phối liên tục khó có xu hướng được thay thế bằng các mẫu kiến ​​trúc thay thế giúp tự động hóa / phân phối liên tục dễ dàng hơn (một số ví dụ tuyệt vời về điều này được ghi lại trong cuốn sách 'Cơ sở dữ liệu tiến hóa'. 'Triển khai xanh / xanh' là một cách khác ).

Lưu ý rằng tôi có thể cung cấp mô tả này mà không cần nói về Jenkins, Check, Puppet, Ansible, Vagrant, AWS hoặc bất kỳ công cụ nào khác hỗ trợ nó. Đây là những gì chúng tôi muốn nói bởi các từ thông dụng cấp độ lớn hơn như "phương pháp luận". Cuối cùng, bất kỳ bộ công cụ nào cũng có thể được thay thế ... Những gì chúng tôi còn lại là các nguyên tắc quản lý cốt lõi được kích hoạt bởi tự động hóa và tập trung vào đường ống dẫn.

DevOps thực sự là một sự thay đổi văn hóa - nó nhằm mục đích phá vỡ các rào cản truyền thống giữa hoạt động và phát triển (và thực sự cũng với QA và phần còn lại của doanh nghiệp!). Ý tưởng là thay vì có các 'silo' phòng ban, bạn có thể làm việc trực tiếp với các nhóm khác để hoàn thành công việc nhanh hơn và hiệu quả hơn.

Đó là tất cả về việc loại bỏ các ràng buộc và quy trình hợp lý hóa. Tự động hóa đi vào điều này rất nhiều bởi vì có các quy trình lặp lại giúp loại bỏ các ràng buộc. Ví dụ: nếu ai đó từ ops phải thực hiện quy trình phát hành thủ công để đưa mã ra môi trường, có một vài điều có thể cản trở - một là phải có ai đó tự do triển khai, và hai, có ít sự tin tưởng hơn trong quá trình phát hành vì công việc thủ công dễ bị lỗi.

DevOps bao gồm tự động hóa nhưng đó chỉ là một phần của nó. DevOps là một thay đổi văn hóa để phá vỡ các silo giữa các bộ phận khác nhau của tổ chức để cung cấp một luồng giá trị hoàn chỉnh. Cung cấp một nền văn hóa nơi kinh doanh, phát triển, đảm bảo chất lượng, cơ sở hạ tầng, bảo mật, hoạt động, vv tất cả cùng làm việc để cung cấp giá trị cho ai đã từng là người dùng cuối. DevOps không phải là một công cụ, bạn không thể mua nó, bạn phải thay đổi văn hóa của mình.

Tự động hóa là một phần quan trọng của DevOps ở chỗ nó cho phép tốc độ phân phối với chất lượng. Tự động hóa cho quá trình triển khai là một trong những lĩnh vực mà nhiều người tập trung đầu tiên vì đây là một trong những cách tốt nhất để nhanh chóng đạt được giá trị và mang lại lợi tức đầu tư cao thông qua việc không chỉ giảm thời gian triển khai mà còn chuẩn hóa quy trình và loại bỏ lỗi.

Tôi muốn thêm 2 xu:
1) Tự động hóa : Thứ
     mà ngày nay chúng ta phải hướng tới. Nó đã trở nên cần thiết hơn trong đó cách ưa thích sẽ là tự động hóa các mảnh, nếu không phải là toàn bộ quá trình. Cách tiếp cận này cho phép người dùng (nhà phát triển) linh hoạt sử dụng một bước cố định cùng với khả năng tùy chỉnh khi cần thiết.
     Ưu điểm trong phương pháp này là chúng ta có thể tự động hóa các phần mà chúng ta muốn trong khi quy trình riêng lẻ có thể được liên kết với nhau bởi nhà phát triển. Các bước tự động hóa càng chi tiết hóa, họ càng kiểm soát tốt hơn.
     Ngoài ra, có nhiều công cụ để tự động hóa trong các không gian như tự động hóa robot, tự động hóa SOP (cho ngành dịch vụ), tự động hóa báo cáo (như Splunk), v.v.
2) DevOps:
     Với tình trạng chất lượng phân phối và tính kịp thời đang được mong đợi ngoài thế giới hiện tại, cần phải mở rộng tự động hóa quy trình phân phối phần mềm. Để kích hoạt điều này và cung cấp giá trị cho khách hàng một cách nhanh nhất có thể, DevOps không phụ thuộc nhiều vào các công cụ tự động hóa.
     Ưu điểm của phương pháp này là, các bước riêng lẻ có thể được tự động hóa để mang lại sự nhất quán trong toàn doanh nghiệp trong khi việc điều phối tổng thể có thể được sửa đổi để phù hợp với quy trình cần thiết của dự án đó.
     Các công cụ tự động hóa riêng lẻ (theo cách nào đó) như Chef để triển khai, Docker qua Dockerfile, Maven để xây dựng, v.v. có thể được liên kết với nhau có thể thông qua Jenkins để cung cấp giải pháp cần thiết đồng thời giảm thời gian cần thiết để thực hiện hoặc sử dụng .
Hy vọng điều này sẽ giúp thêm bất kỳ giá trị nào vào quá trình suy nghĩ mà bạn có thể đã có.

Chỉnh sửa: Quên thêm rằng tôi đã nói về Quy trình và Công cụ - 2 trong 3 khía cạnh trong DevOps. Như những người khác đã đề cập, khía cạnh thứ 3 và không kém phần quan trọng là Con người. Một trong những khác biệt chính mà tôi cho rằng giữa điều này và tự động hóa là mọi người có xu hướng hấp thụ tự động hóa thường xuyên hơn so với việc họ chống lại DevOps. Tôi cảm thấy rằng điều này là do bản chất của DevOps, trong đó tự động hóa thường liên quan đến việc làm cho mọi thứ dễ dàng hơn với họ, trong khi họ cảm thấy rằng DevOps đang thay đổi cách họ cảm thấy thoải mái.

Phong trào DevOps bao gồm bốn lĩnh vực chính được viết tắt là Expedia :

1. Văn hóa
2. Tự động hóa
3. Đo đạc
4. Chia sẻ

Đây là bài viết xác định ban đầu từ năm 2010.

Trong mỗi lĩnh vực có một số công cụ, quy trình và thực tiễn thường được chấp nhận, mặc dù chủ đề không được xác định rõ đối với Thực tiễn Tốt nhất, trong hầu hết các trường hợp, một số Thực tiễn Tốt phải tuân theo.

Tự động hóa tự nó là một chủ đề rộng hơn một chút, nhưng trong bối cảnh DevOps, nó chỉ là một tập hợp con của những gì đang được bảo hiểm. Hãy lưu ý rằng chúng tôi dẫn đầu với văn hóa, mặc dù nhiều học viên DevOps mới vào lĩnh vực này thường bỏ qua nó trong tình trạng nguy hiểm của riêng họ và bỏ qua trực tiếp để tự động hóa.

Tự động hóa và DevOps không liên quan. DevOps giống như kỹ thuật kết hợp trong đó các Nhà phát triển của một trang web hoặc dịch vụ là tất cả các Nhà khai thác của trang web hoặc dịch vụ đó. Tại sao cuốn tiểu thuyết này? Theo kinh nghiệm của tôi, điều đầu tiên mà nhóm Ops đã làm khi bất cứ điều gì thú vị hơn một cú đánh mạng xảy ra là gọi cho nhóm Dev. Tại sao họ làm điều đó? Bởi vì tất cả các nhóm Ops đã làm là theo dõi và giữ một danh sách các số điện thoại dev để gọi.

Lưu ý tôi đã không nói gì về tự động hóa.

Tự động hóa là về việc lặp lại thành công. Nếu tôi thực hiện các bước a, b và c và quy trình X luôn hoạt động, thì các bước a, b và c là những ứng cử viên tốt cho tự động hóa. Sau đó, tôi có thể sử dụng thời gian cho những gì từng là một quy trình thủ công để làm những việc giúp tôi kiếm được nhiều tiền hơn. Tự động hóa thành công khi nó đơn giản. Triển khai các bản phát hành mới, chạy các bài kiểm tra tích hợp, kiểm tra tốc độ, sao lưu dữ liệu, cân bằng tín dụng và ghi nợ, v.v ... đều là những ứng cử viên tuyệt vời cho tự động hóa bởi vì các bước được lặp đi lặp lại cho dù là người hay robot.

Lưu ý : Điều mới là Nhà phát triển cũng là nhà khai thác. Không có nhóm khác. Hợp tác trong trường hợp của tôi là rất hiếm. Nếu không có gì trong Hướng dẫn khắc phục sự cố (còn gọi là TSG) thì bạn được đảm bảo một cuộc gọi điện thoại. Theo kinh nghiệm của tôi, Ops là cuộc gọi đầu tiên trong trường hợp backhoe. Các vấn đề giữa các dịch vụ đã ra khỏi nhà xe của họ.