Này Habr! Tôi trình bày với bạn chú ý bản dịch của bài báo của Steve Mezak.
Tùy thuộc vào quan điểm của bạn, DevOps sẽ kỷ niệm 2016 hoặc 70 năm thành lập trong năm nay. Năm XNUMX, báo cáo Trạng thái đám mây của RightScales lưu ý rằng XNUMX% SMB đang áp dụng các phương pháp DevOps. Mọi chỉ số tạo nên điểm số này đều tăng lên kể từ đó. Khi DevOps chuẩn bị bước vào thập kỷ thứ hai, sẽ thật tuyệt nếu bạn dạo một vòng về quá khứ và quay trở lại nguồn gốc của DevOps—và thậm chí cả nguồn gốc của chính cái tên này.
Trước 2007: Chuỗi sự kiện hoàn hảo
Trước năm 2007, một loạt hoàn cảnh cuối cùng đã sinh ra cái mà ngày nay gọi là DevOps.
Độ nghiêng đã được chứng minh là phương pháp thực hành tốt nhất. Còn được biết là Hệ thống sản xuất Toyota, Lean Manufacturing cố gắng tối ưu hóa các quy trình trên sàn sản xuất. (Nhân tiện, ban lãnh đạo Toyota ban đầu lấy cảm hứng từ các phương pháp dây chuyền lắp ráp ban đầu do Công ty Ford Motor giới thiệu). Cải tiến liên tục là câu thần chú cho sản xuất tinh gọn. Trong thực tế, các đường dẫn sau được đánh giá liên tục:
- Duy trì mức tồn kho nguyên vật liệu và thành phẩm ở mức tối thiểu. Sản xuất tinh gọn có nghĩa là lượng nguyên liệu thô tồn kho tối thiểu để sản xuất hàng hóa và lượng thành phẩm tối thiểu đang chờ được đặt hàng hoặc vận chuyển.
- Giảm thiểu hàng đợi đặt hàng. Lý tưởng nhất là nhận được lệnh ngay lập tức chuyển sang trạng thái hoàn thành. Thước đo quan trọng của sản xuất tinh gọn sẽ luôn là thời gian từ khi nhận đơn hàng đến khi giao hàng.
- Tối đa hóa hiệu quả của quá trình sản xuất. Tái thiết kế quy trình và tự động hóa cải tiến đang kết hợp để sản xuất hàng hóa nhanh nhất có thể. Mọi lĩnh vực sản xuất dọc theo toàn bộ quá trình (cắt, hàn, lắp ráp, thử nghiệm, v.v.) đều được đánh giá là không hiệu quả.
Trong thế giới CNTT, các phương pháp truyền thống của mô hình phát triển phần mềm thác nước đã nhường chỗ cho các phương pháp lặp lại nhanh như Agile. Tốc độ là lời kêu gọi tập hợp, ngay cả khi chất lượng đôi khi bị ảnh hưởng khi theo đuổi sự phát triển và triển khai nhanh chóng. Tương tự như vậy, điện toán đám mây, đặc biệt Cơ sở hạ tầng như một dịch vụ (IaaS) và Nền tảng-as-a-Dịch vụ (PaaS) đã chứng tỏ mình là giải pháp hoàn thiện trong quy trình và cơ sở hạ tầng CNTT.
Cuối cùng, các bộ công cụ gần đây đã bắt đầu xuất hiện cho Hội nhập liên tục (CI). Ý tưởng về các công cụ CI được Gradi Booch ra đời và trình bày vào năm 1991 trong Phương pháp Booch của ông.
2007-2008: Người Bỉ thất vọng
Nhà tư vấn người Bỉ, dự án Agile và giám đốc thực hành Patrick Debois đã chấp nhận lời mời từ Bộ chính phủ Bỉ để giúp di chuyển trung tâm dữ liệu. Đặc biệt, anh còn tham gia vào việc chứng nhận và kiểm tra mức độ sẵn sàng. Trách nhiệm của anh yêu cầu anh phải điều phối và xây dựng mối quan hệ giữa các nhóm phát triển phần mềm và các nhóm vận hành máy chủ, cơ sở dữ liệu và mạng. Sự thất vọng của anh với sự thiếu gắn kết và những bức tường ngăn cách phương pháp phát triển và vận hành khiến anh cay đắng. Mong muốn tiến bộ của Desbois đã sớm khiến anh phải hành động.
Tại hội nghị Agile năm 2008 ở Toronto, Andrew Schaefer đề xuất tổ chức một cuộc họp không chính thức được sắp xếp đặc biệt để thảo luận về chủ đề "Cơ sở hạ tầng linh hoạt"Và chỉ có một người đến thảo luận về chủ đề này: Patrick DeBois. Cuộc thảo luận và trao đổi ý tưởng của họ đã nâng cao khái niệm quản trị hệ thống Agile. Cùng năm đó, DeBois và Schaefer đã thành lập nhóm Quản trị viên hệ thống Agile khá thành công tại Google.
2009: Trường hợp hợp tác giữa Dev và Ops
Tại hội nghị O'Reilly Velocity, hai nhân viên của Flickr, Phó chủ tịch cấp cao về hoạt động kỹ thuật John Allspaw và CTO Paul Hammond, đã có bài thuyết trình nổi tiếng hiện nay "10 lần triển khai mỗi ngày: Cộng tác giữa nhà phát triển và vận hành tại Flickr".
Bài thuyết trình là một vở kịch, trong đó Allspaw và Hammond tái hiện các tương tác phức tạp giữa các đại diện Phát triển và Vận hành trong quá trình triển khai phần mềm, hoàn chỉnh với những lời chỉ trích và khiển trách dọc theo dòng chữ “Đó không phải là mã của tôi, mà là tất cả máy tính của bạn!” Bài trình bày của họ xác nhận rằng lựa chọn hợp lý duy nhất là các hoạt động triển khai và phát triển phần mềm phải liền mạch, minh bạch và được tích hợp đầy đủ. Theo thời gian, bài thuyết trình này đã trở thành huyền thoại và hiện được lịch sử coi là một cột mốc quan trọng khi ngành CNTT bắt đầu kêu gọi phương pháp mà ngày nay được gọi là DevOps.
2010: DevOps tại Hoa Kỳ
Với lượng người theo dõi ngày càng tăng, hội nghị DevOpsDays đã được tổ chức lần đầu tiên tại Hoa Kỳ ở Mountain View, California, ngay sau hội nghị Velocity hàng năm. Chuyển nhanh sang năm 2018 và có hơn 30 hội nghị DevOpsDays đã được lên lịch, trong đó có hàng chục hội nghị ở Hoa Kỳ.
2013: Dự án “Phượng Hoàng”
Đối với nhiều người trong chúng ta, một khoảnh khắc đáng chú ý khác trong lịch sử DevOps là việc xuất bản cuốn sách “Dự án Phượng hoàng” của Gene Kim, Kevin Behr và George Safford. Cuốn tiểu thuyết này kể về câu chuyện của một người quản lý CNTT rơi vào tình thế tuyệt vọng: anh ta được giao nhiệm vụ giải cứu một dự án thương mại điện tử quan trọng đã gặp trục trặc. Người cố vấn bí ẩn của người quản lý - một thành viên ban giám đốc đam mê các phương pháp sản xuất tinh gọn - gợi ý những cách mới để nhân vật chính suy nghĩ về CNTT và phát triển ứng dụng, đón đầu khái niệm DevOps. Nhân tiện, “Dự án Phoenix” đã truyền cảm hứng cho chúng tôi viết cuốn sách “Thuê ngoài hoặc nếu không…” về một câu chuyện kinh doanh tương tự, trong đó một Phó chủ tịch phần mềm sử dụng DevOps trong quá trình phát triển một sản phẩm thuê ngoài lớn mới.
DevOps cho tương lai
Thật đáng để mô tả DevOps như một cuộc hành trình, hoặc có lẽ là một khát vọng, hơn là một điểm đến cuối cùng. DevOps, giống như sản xuất tinh gọn, nỗ lực cải tiến liên tục, tăng năng suất và hiệu quả, thậm chí là triển khai liên tục. Các công cụ tự động hỗ trợ DevOps tiếp tục phát triển.
Đã đạt được nhiều thành tựu kể từ khi DevOps ra đời trong thập kỷ qua và chúng tôi kỳ vọng sẽ còn đạt được nhiều thành tựu hơn nữa trong năm 2018 và hơn thế nữa.
Nguồn: www.habr.com