Gần đây tôi đã tham dự DevOpsForum 2019 do Logrocon tổ chức. Tại hội nghị này, những người tham gia đã nỗ lực tìm kiếm các giải pháp và công cụ mới để tương tác hiệu quả giữa các chuyên gia kinh doanh và phát triển và dịch vụ công nghệ thông tin.
Hội nghị đã thành công tốt đẹp: thực sự có rất nhiều báo cáo hữu ích, hình thức trình bày thú vị và nhiều trao đổi với các diễn giả. Và điều đặc biệt quan trọng là không ai cố gắng bán cho tôi bất cứ thứ gì, điều mà gần đây các diễn giả tại các hội nghị lớn đã mắc phải.
Đoạn trích từ bài phát biểu của Raiffeisenbank, Alfastrakhovanie, kinh nghiệm của Mango Telecom trong việc triển khai tự động hóa và các chi tiết khác trong quá trình cắt giảm.
Tên tôi là Yana, tôi làm người thử nghiệm, tôi làm công việc tự động hóa cũng như DevOps và tôi thích đi dự các hội nghị và buổi gặp mặt. Trong hai năm qua, tôi đã tham dự các hội nghị của Oleg Bunin (HighLoad++, TeamLead Conf), các sự kiện Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Trước hết tôi xin lưu ý đến chương trình hội nghị. Tôi ít quan tâm đến nội dung của bản báo cáo mà quan tâm nhiều hơn đến diễn giả. Ngay cả khi báo cáo rất công nghệ và thú vị, thực tế không phải là bạn có thể áp dụng một số phương pháp hay nhất từ báo cáo vào công ty của mình. Và sau đó bạn cần một loa.
Ánh sáng cuối đường ống tại Raiffeisenbank
Thông thường, tôi săn lùng những diễn giả bên lề mà tôi quan tâm. Tại DevOpsForum 2019, diễn giả từ Raiffeisenbank, Mikhail Bizhan, đã thu hút sự quan tâm của tôi. Trong bài phát biểu của mình, anh ấy đã nói về cách họ đang dần dần thu hút các nhóm của mình gắn bó với DevOps, lý do tại sao họ cần nó và cách bán ý tưởng chuyển đổi DevOps sang kinh doanh. Chà, nói chung, tôi đã nói về cách nhìn thấy ánh sáng ở cuối đường ống.
Mikhail Bizhan, giám đốc tự động hóa tại Raiffeisenbank
Bây giờ họ không có “DevOps” trong công ty của mình. Tức là anh ấy làm việc, nhưng không phải ở tất cả các đội. Khi triển khai DevOps, họ dựa vào sự sẵn sàng của các nhóm, cả về mặt kỹ sư cụ thể cũng như về nhu cầu của sản phẩm cũng như mức độ trưởng thành của nền tảng mà sản phẩm này được xây dựng trên đó. Misha đã chỉ cách giải thích cho doanh nghiệp tại sao cần có DevOps.
Phân khúc ngân hàng có một số động lực tăng trưởng: chi phí dịch vụ và mở rộng cơ sở khách hàng. Tăng chi phí dịch vụ không phải là động lực tốt, nhưng việc tăng lượng khách hàng thì ngược lại. Nếu đối thủ cạnh tranh tung ra một sản phẩm hấp dẫn một cách khách quan, tất cả khách hàng sẽ đến đó, rồi theo thời gian thị trường sẽ ổn định lại. Vì vậy, việc giới thiệu sản phẩm mới ra thị trường và tốc độ giới thiệu sản phẩm mới là điều mà các ngân hàng chú trọng hàng đầu. Đây chính xác là mục đích của DevOps và các doanh nghiệp hiểu điều này.
Lưu ý quan trọng tiếp theo: DevOps không phải lúc nào cũng giảm thời gian tiếp thị. DevOps không thể hoạt động một mình, nó chỉ là một phần của quá trình tạo ra và đưa sản phẩm ra thị trường từ giai đoạn phát triển đến sản xuất (từ code đến khách hàng). Nhưng mọi thứ trước mã không liên quan trực tiếp đến DevOps. Nghĩa là, các nhà tiếp thị có thể nghiên cứu thị trường trong nhiều năm và dành cả cuộc đời để theo kịp các đối thủ cạnh tranh. Cần phải nhanh chóng hiểu những gì khách hàng cần và lập kế hoạch triển khai tính năng này hoặc tính năng kia - thường đây là điều không đủ để DevOps hoạt động và công ty đạt được mục tiêu của mình. Vì vậy, trước hết Raiffeisenbank đã thống nhất với doanh nghiệp rằng cần phải học cách sử dụng DevOps. Tự động hóa vì mục đích tự động hóa sẽ không giúp ích nhiều trong cuộc chiến giành khách hàng mới.
Nhìn chung, Misha tin rằng DevOps cần được triển khai nhưng một cách khôn ngoan. Và chúng ta phải chuẩn bị cho thực tế là khi bắt đầu chuyển đổi, năng suất của nhóm sẽ giảm, họ sẽ kiếm được ít tiền hơn, nhưng sau đó điều đó sẽ hợp lý.
Tự động hóa thử nghiệm tại Mango Telecom
Một báo cáo thú vị khác đối với tôi với tư cách là người thử nghiệm được đưa ra bởi Egor Maslov từ Mango Telecom. Bài thuyết trình có tên “Tự động hóa toàn bộ chu trình thử nghiệm trong nhóm SCRUM”. Egor tin rằng DevOps được tạo riêng cho SCRUM, nhưng đồng thời, việc đưa DevOps vào nhóm SCRUM cũng khá rắc rối. Điều này xảy ra vì nhóm SCRUM luôn chạy đi đâu đó, không có thời gian để bị phân tâm bởi những đổi mới và xây dựng lại quy trình. Vấn đề còn nằm ở chỗ SCRUM không liên quan đến việc tách các nhóm phụ trong nhóm (nhóm thử nghiệm, nhóm phát triển, v.v.). Ngoài ra, để tự động hóa một quy trình hiện có, cần có tài liệu và trong SCRUM, hầu hết thường không có tài liệu nào hoàn toàn - “sản phẩm quan trọng hơn một số loại văn bản”.
Sau khi chuyển sang SCRUM, người thử nghiệm bắt đầu tham khảo ý kiến của các nhà phát triển về cách thử nghiệm các tính năng. Dần dần, khối lượng chức năng tăng lên, không có tài liệu và họ bắt đầu phát hiện ra rất nhiều lỗi trong chức năng không được kiểm tra và nói chung không còn rõ ai đã kiểm tra nó và khi nào. Tóm lại - sự nhầm lẫn và bỏ trống. Chúng tôi quyết định chuyển sang thử nghiệm tự động hóa. Nhưng ngay cả sau đó vẫn có một thất bại hoàn toàn. Họ thuê các chuyên gia tự động hóa bên ngoài, những người viết trên một chồng dữ liệu mà những người thử nghiệm nội bộ không biết. Tất nhiên, khuôn khổ dành cho các cuộc kiểm tra tự động đã hoạt động nhưng sau khi những người đăng việc rời đi, nó vẫn tồn tại trong hai tuần. Tiếp theo là nỗ lực giới thiệu tính năng tự kiểm tra thứ hai. Nó bắt đầu với thực tế là mọi thứ cần phải được tự mình xây dựng trong công ty (vector phù hợp: xây dựng kiến thức chuyên môn trong nội bộ), trong khuôn khổ SCRUM và tạo tài liệu trong quá trình này. Ngăn xếp dành cho tự động hóa phải bằng ngăn xếp của sản phẩm (ở đây tôi đang thêm nó, đừng kiểm tra dự án JavaScript của bạn với bất kỳ thứ gì khác). Vào cuối giai đoạn chạy nước rút, họ đã thực hiện một bản demo về cách hoạt động của quá trình tự động kiểm tra với cả nhóm (hữu ích). Do đó, sự tham gia của tất cả các thành viên trong nhóm vào quá trình tự động hóa đã tăng lên, cũng như sự tin tưởng vào các cuộc kiểm tra tự động và khả năng kiểm tra tự động này chắc chắn sẽ được sử dụng (và sẽ không được nhận xét trong một tháng do liên tục xảy ra lỗi).
Nhân tiện, tại DevOpsForum 2019 đã có một micrô mở - một định dạng bài phát biểu đã được biết đến từ lâu và theo ý kiến của tôi. Bạn dạo quanh như thế này, nghe báo cáo và sau đó quyết định rằng tại hội nghị nên thảo luận về một chủ đề hoặc vấn đề nhất định, chia sẻ kinh nghiệm liên quan trong việc giải quyết vấn đề.
Tôi cũng nhận thấy rằng ban tổ chức đã thực hiện một loạt các báo cáo ngắn. Mỗi báo cáo kéo dài không quá 10 phút, tiếp theo là các câu hỏi. Bằng cách này, bạn có thể đề cập đến nhiều chủ đề cùng một lúc và đặt câu hỏi cho những diễn giả mà bạn quan tâm.
Giữa các buổi thuyết trình, tôi đi vòng quanh gian hàng của các đối tác trong hội nghị và lấy trộm/giành được rất nhiều thứ. Ơ, tôi thích tờ rơi này!
Các vấn đề bàn tròn và DevOps với giám đốc phát triển tại Alfastrakhovanie
Đối với tôi, điều thú vị nhất của DevOpsForum 2019 là phiên họp toàn thể kéo dài một giờ với các chuyên gia DevOps. Bốn người tham gia phiên được mời xem xét DevOps từ các góc độ khác nhau: Anton Isanin (Alfastrakhovanie, giám đốc phát triển), Nailya Zamashkina (Fintech Lab, giám đốc điều hành), Oleg Egorkin (Rostelecom, huấn luyện viên Agile) và Anton Martyanov (chuyên gia độc lập, nhìn vào DevOps dưới góc độ kinh doanh).
Các chuyên gia ngồi xuống gần mọi người hơn và sau đó mọi chuyện bắt đầu xảy ra: trong suốt một giờ, những người tham gia là khán giả đặt câu hỏi và các chuyên gia sẽ bắt đầu phần rap. Đôi khi có những cuộc tranh luận thực sự. Các câu hỏi rất khác nhau, chẳng hạn như: có cần kỹ sư DevOps không, tại sao họ không thể được đào tạo thành quản trị viên hệ thống, DevOps có nên được cung cấp cho mọi người không, giá trị của nó là gì, v.v.
Sau đó, tôi đã nói chuyện riêng với Anton Isanin. Chúng tôi đã thảo luận về sự cần thiết phải đưa văn hóa DevOps đến mọi nhà và tiết lộ mặt tối của quá trình chuyển đổi DevOps.
Hãy tưởng tượng rằng mọi người cùng nhau quyết định rằng DevOps là cần thiết cho cả sản phẩm, doanh nghiệp và nhóm. Hãy đi thực hiện nó. Mọi thứ đã làm ra. Chúng tôi thở ra. DevOps đã đưa chúng tôi đến gần hơn với khách hàng, giờ đây chúng tôi có thể nhanh chóng thực hiện mọi mong muốn của khách hàng. Kết quả là, chúng tôi có một bộ phận Vận hành lớn với các quy định và yêu cầu nghiêm ngặt, đồng thời bộ phận này liên tục tìm ra các khiếm khuyết trong sản phẩm và tạo ra hàng loạt yêu cầu. Hơn nữa, tất cả các lỗi đều được gán trạng thái “khẩn cấp”, ngay cả khi khách hàng bất ngờ muốn tô màu nút màu vàng thay vì màu xanh lá cây. Dự án đang phát triển, số lượng bản phát hành ngày càng tăng và theo đó là số lượng lỗi và sự hiểu lầm của khách hàng về chức năng mới. Ops thuê thêm 10 người để theo kịp việc báo cáo các lỗi và bộ phận phát triển thuê thêm 15 người để theo kịp việc đóng chúng. Và thay vì giới thiệu các tính năng mới, nhóm làm việc với vô số SD, đồng thời giải thích chức năng cho người dùng và hỗ trợ. Kết quả là cả Vận hành và phát triển đều hoạt động nhưng khách hàng và doanh nghiệp không hài lòng: các tính năng mới bị kẹt. Hóa ra DevOps dường như có tồn tại nhưng dường như không tồn tại.
Về nhu cầu triển khai DevOps, Anton nêu rõ rằng điều này phụ thuộc trực tiếp vào quy mô của doanh nghiệp. Nếu việc phục vụ một khách hàng mỗi năm mang lại cho công ty một tỷ USD thì DevOps là không cần thiết (miễn là bạn không cần triển khai các thay đổi mới cho khách hàng này thường xuyên). Tất cả mọi thứ được bao phủ trong sô cô la. Nhưng nếu doanh nghiệp phát triển và xuất hiện nhiều khách hàng hơn thì bạn cần phải tuân thủ. Theo quy định, ban đầu không có Ops thú vị nào trong công ty. Đầu tiên, chúng tôi cắt sản phẩm và chỉ sau đó chúng tôi mới hiểu rằng để sản phẩm hoạt động, chúng tôi cần theo dõi các máy chủ và giám sát nguồn cung cấp. Đó là lúc Ops ra đời. Vẫn phải hiểu rằng Ops, với tư cách là một bộ phận riêng biệt, sẽ bắt đầu đặt ra một loạt rào cản cho sự phát triển và tất cả việc giao hàng sẽ bắt đầu bị đình trệ. Có nghĩa là, trong trường hợp này, văn hóa DevOps đã phù hợp, nhưng chúng ta không được quên mặt tối của nó.
Nguồn: www.habr.com