Tình trạng DevOps ở Nga 2020

Làm thế nào để hiểu trạng thái của một cái gì đó?

Bạn có thể dựa vào ý kiến ​​​​của mình, được hình thành từ nhiều nguồn thông tin khác nhau, chẳng hạn như các ấn phẩm trên trang web hoặc kinh nghiệm. Bạn có thể hỏi đồng nghiệp, người quen. Một lựa chọn khác là xem xét các chủ đề của hội nghị: ủy ban chương trình là những đại diện tích cực của ngành, vì vậy chúng tôi tin tưởng họ trong việc lựa chọn các chủ đề phù hợp. Một khu vực riêng biệt là nghiên cứu và báo cáo. Nhưng có một vấn đề. Nghiên cứu về tình trạng DevOps được tiến hành hàng năm trên thế giới, các báo cáo được công bố bởi các công ty nước ngoài và hầu như không có thông tin về DevOps của Nga.

Nhưng đã đến lúc một nghiên cứu như vậy được thực hiện, và hôm nay chúng ta sẽ nói về kết quả. Tình trạng DevOps ở Nga đã được các công ty cùng nhau nghiên cứu "chuyển phát nhanh 42"Và"Ontico“. Express 42 giúp các công ty công nghệ triển khai và phát triển các phương pháp cũng như công cụ DevOps và là một trong những công ty đầu tiên nói về DevOps ở Nga. Các tác giả của nghiên cứu, Igor Kurochkin và Vitaly Khabarov, đang tham gia phân tích và tư vấn tại Express 42, đồng thời có nền tảng kỹ thuật từ hoạt động và kinh nghiệm ở các công ty khác nhau. Trong 8 năm, các đồng nghiệp đã xem xét hàng chục công ty và dự án - từ công ty khởi nghiệp đến doanh nghiệp - với các vấn đề khác nhau, cũng như sự trưởng thành về văn hóa và kỹ thuật khác nhau.

Trong báo cáo của họ, Igor và Vitaly đã cho biết những vấn đề trong quá trình nghiên cứu, cách họ giải quyết chúng, cũng như nguyên tắc tiến hành nghiên cứu DevOps như thế nào và tại sao Express 42 lại quyết định tiến hành nghiên cứu của riêng mình. Báo cáo của họ có thể được xem đây.

Nghiên cứu DevOps

Cuộc trò chuyện được bắt đầu bởi Igor Kurochkin.

Chúng tôi thường hỏi khán giả tại các hội nghị DevOps, “Bạn đã đọc báo cáo trạng thái DevOps cho năm nay chưa?” Rất ít người giơ tay, và nghiên cứu của chúng tôi cho thấy chỉ có XNUMX/XNUMX người giơ tay. Nếu bạn chưa bao giờ thấy những báo cáo như vậy, hãy nói ngay rằng chúng đều rất giống nhau. Hầu hết thường có những cụm từ như: "So với năm ngoái ..."

Ở đây chúng tôi có vấn đề đầu tiên và sau đó là hai vấn đề nữa:

1. Chúng tôi không có dữ liệu cho năm ngoái. Tình trạng DevOps ở Nga không được ai quan tâm;
2. phương pháp luận. Chưa rõ cách kiểm định giả thuyết, cách xây dựng câu hỏi, cách phân tích, so sánh kết quả, tìm mối liên hệ;
3. Thuật ngữ. Tất cả các báo cáo đều bằng tiếng Anh, yêu cầu dịch thuật, một khung DevOps chung vẫn chưa được phát minh và mọi người đều tự nghĩ ra.

Hãy cùng xem các phân tích trạng thái DevOps đã được thực hiện như thế nào trên khắp thế giới.

Thông tin lịch sử

Nghiên cứu DevOps đã được tiến hành từ năm 2011. Puppet, nhà phát triển hệ thống quản lý cấu hình, là người đầu tiên thực hiện chúng. Vào thời điểm đó, nó là một trong những công cụ chính để mô tả cơ sở hạ tầng dưới dạng mã. Cho đến năm 2013, những nghiên cứu này chỉ đơn giản là khảo sát kín và không có báo cáo công khai.

Năm 2013, IT Revolution xuất hiện, nhà xuất bản của tất cả các cuốn sách lớn về DevOps. Cùng với Puppet, họ đã chuẩn bị ấn phẩm Trạng thái DevOps đầu tiên, trong đó 4 số liệu chính lần đầu tiên xuất hiện. Năm sau, ThoughtWorks, một công ty tư vấn nổi tiếng với các radar công nghệ thường xuyên về các công cụ và thực tiễn trong ngành, đã tham gia. Và vào năm 2015, một phần có phương pháp luận đã được thêm vào và nó đã trở nên rõ ràng về cách họ thực hiện phân tích.

Vào năm 2016, các tác giả của nghiên cứu đã thành lập công ty DORA (Nghiên cứu và Đánh giá DevOps) của riêng họ, đã xuất bản một báo cáo thường niên. Năm sau, DORA và Puppet phát hành báo cáo chung cuối cùng của họ.

Và rồi một điều thú vị bắt đầu:

Vào năm 2018, các công ty đã tách ra và hai báo cáo độc lập đã được phát hành: một báo cáo từ Puppet, báo cáo thứ hai từ DORA kết hợp với Google. DORA đã tiếp tục tận dụng phương pháp của mình với các số liệu chính, hồ sơ hiệu suất và thực tiễn kỹ thuật tác động đến các số liệu chính và hiệu suất toàn công ty. Và Puppet đã đưa ra cách tiếp cận của riêng mình với mô tả về quy trình và sự phát triển của DevOps. Nhưng câu chuyện vẫn chưa bén rễ, vào năm 2019, Puppet đã từ bỏ phương pháp này và phát hành một phiên bản báo cáo mới, trong đó liệt kê các phương pháp chính và cách chúng ảnh hưởng đến DevOps theo quan điểm của họ. Sau đó, một sự kiện khác đã xảy ra: Google đã mua DORA và họ cùng nhau phát hành một báo cáo khác. Bạn có thể đã nhìn thấy anh ta.

Năm nay, mọi thứ trở nên phức tạp. Con rối được biết là đã đưa ra cuộc khảo sát của riêng mình. Họ đã làm điều đó sớm hơn chúng tôi một tuần và nó đã kết thúc. Chúng tôi đã tham gia và xem xét những chủ đề mà họ quan tâm. Bây giờ Puppet đang tiến hành phân tích và chuẩn bị xuất bản báo cáo.

Nhưng vẫn chưa có thông báo nào từ DORA và Google. Vào tháng XNUMX, khi cuộc khảo sát thường bắt đầu, có thông tin cho rằng Nicole Forsgren, một trong những người sáng lập DORA, đã chuyển sang một công ty khác. Do đó, chúng tôi cho rằng sẽ không có nghiên cứu và báo cáo nào từ DORA trong năm nay.

Mọi thứ ở Nga thế nào?

Chúng tôi chưa thực hiện nghiên cứu DevOps. Chúng tôi đã nói chuyện tại các hội nghị, kể lại những phát hiện của người khác và Raiffeisenbank đã dịch "Trạng thái DevOps" cho năm 2019 (bạn có thể tìm thấy thông báo của họ trên Habré), cảm ơn họ rất nhiều. Và đó là tất cả.

Do đó, chúng tôi đã tiến hành nghiên cứu của riêng mình ở Nga bằng cách sử dụng các phương pháp và phát hiện của DORA. Chúng tôi đã sử dụng báo cáo của các đồng nghiệp từ Raiffeisenbank cho nghiên cứu của mình, bao gồm cả việc đồng bộ hóa thuật ngữ và dịch thuật. Và các câu hỏi liên quan đến ngành được lấy từ các báo cáo của DORA và bảng câu hỏi Múa rối năm nay.

Quá trình nghiên cứu

Báo cáo chỉ là phần cuối cùng. Toàn bộ quá trình nghiên cứu bao gồm bốn bước chính:

Trong giai đoạn chuẩn bị, chúng tôi đã phỏng vấn các chuyên gia trong ngành và chuẩn bị một danh sách các giả thuyết. Trên cơ sở của họ, các câu hỏi đã được biên soạn và một cuộc khảo sát đã được đưa ra trong cả tháng Tám. Sau đó, chúng tôi tự phân tích và chuẩn bị báo cáo. Đối với DORA, quá trình này mất 6 tháng. Chúng tôi đã gặp nhau trong vòng 3 tháng và bây giờ chúng tôi hiểu rằng chúng tôi hầu như không có đủ thời gian: chỉ bằng cách thực hiện phân tích, bạn mới hiểu mình cần đặt câu hỏi gì.

Những người tham gia

Tất cả các báo cáo nước ngoài bắt đầu với một bức chân dung của những người tham gia, và hầu hết trong số họ không đến từ Nga. Tỷ lệ người Nga được hỏi dao động từ 5 đến 1% từ năm này sang năm khác và điều này không cho phép đưa ra bất kỳ kết luận nào.

Bản đồ từ báo cáo Tăng tốc trạng thái DevOps 2019:

Trong nghiên cứu của chúng tôi, chúng tôi đã phỏng vấn được 889 người - con số này khá nhiều (DORA thăm dò khoảng một nghìn người hàng năm trong các báo cáo của mình) và ở đây chúng tôi đã đạt được mục tiêu:

Đúng vậy, không phải tất cả những người tham gia của chúng tôi đều về đích: tỷ lệ hoàn thành hóa ra chỉ bằng một nửa. Nhưng ngay cả điều này cũng đủ để lấy một mẫu đại diện và tiến hành phân tích. DORA không tiết lộ tỷ lệ lấp đầy trong các báo cáo của mình, vì vậy không có so sánh ở đây.

Các ngành và vị trí

Những người trả lời của chúng tôi đại diện cho một tá ngành công nghiệp. Một nửa làm việc trong công nghệ thông tin. Tiếp theo là các dịch vụ tài chính, thương mại, viễn thông và các dịch vụ khác. Trong số các vị trí có các chuyên gia (nhà phát triển, người thử nghiệm, kỹ sư vận hành) và cán bộ quản lý (trưởng nhóm, nhóm, khu vực, giám đốc):

Một trong hai người làm việc cho một công ty cỡ trung bình. Mỗi người thứ ba làm việc trong các công ty lớn. Hầu hết làm việc theo nhóm lên đến 9 người. Một cách riêng biệt, chúng tôi đã hỏi về các hoạt động chính và phần lớn bằng cách nào đó liên quan đến hoạt động và khoảng 40% tham gia vào quá trình phát triển:

Vì vậy, chúng tôi đã thu thập thông tin để so sánh và phân tích đại diện của các ngành, công ty, nhóm khác nhau. Đồng nghiệp của tôi Vitaly Khabarov sẽ kể về phân tích.

Phân tích và so sánh

Vitaly Khabarov: Rất cảm ơn tất cả những người tham gia đã hoàn thành khảo sát của chúng tôi, điền vào bảng câu hỏi và cung cấp cho chúng tôi dữ liệu để phân tích và kiểm tra thêm các giả thuyết của chúng tôi. Và nhờ có khách hàng và khách hàng của chúng tôi, chúng tôi có nhiều kinh nghiệm đã giúp xác định các mối quan tâm của ngành và hình thành các giả thuyết mà chúng tôi đã thử nghiệm trong nghiên cứu của mình.

Thật không may, bạn không thể một mặt lấy danh sách các câu hỏi và mặt khác là dữ liệu, bằng cách nào đó so sánh chúng, nói: “Vâng, mọi thứ hoạt động như vậy, chúng tôi đã đúng” và giải tán. Không, phương pháp và phương pháp thống kê là cần thiết để chắc chắn rằng chúng tôi không nhầm lẫn và kết luận của chúng tôi là đáng tin cậy. Sau đó, chúng tôi có thể xây dựng công việc tiếp theo của mình dựa trên những dữ liệu này:

Số liệu chính

Chúng tôi lấy phương pháp DORA làm cơ sở, mà họ đã mô tả chi tiết trong cuốn sách “Tăng tốc trạng thái của DevOps”. Chúng tôi đã kiểm tra xem các chỉ số chính có phù hợp với thị trường Nga hay không, liệu chúng có thể được sử dụng theo cách mà DORA sử dụng để trả lời câu hỏi: “Ngành công nghiệp ở Nga tương ứng với ngành công nghiệp nước ngoài như thế nào?”

Các số liệu chính:

1. Tần suất triển khai. Tần suất một phiên bản mới của ứng dụng được triển khai vào môi trường sản xuất (các thay đổi theo kế hoạch, ngoại trừ các bản sửa lỗi và ứng phó sự cố)?
2. Thời gian giao hàng. Thời gian trung bình giữa việc thực hiện thay đổi (viết chức năng dưới dạng mã) và triển khai thay đổi vào môi trường sản xuất là bao nhiêu?
3. Thời gian hồi phục. Mất trung bình bao lâu để khôi phục một ứng dụng về môi trường sản xuất sau khi xảy ra sự cố, xuống cấp dịch vụ hoặc phát hiện ra lỗi ảnh hưởng đến người dùng ứng dụng?
4. Thay đổi không thành công. Bao nhiêu phần trăm triển khai trong môi trường sản xuất dẫn đến sự cố hoặc xuống cấp ứng dụng và yêu cầu khắc phục (khôi phục các thay đổi, phát triển hotfix hoặc bản vá lỗi)?

DORA trong nghiên cứu của mình đã tìm thấy mối liên hệ giữa các số liệu này và hiệu suất của tổ chức. Chúng tôi cũng kiểm tra nó trong nghiên cứu của chúng tôi.

Nhưng để đảm bảo rằng bốn chỉ số chính có thể ảnh hưởng đến điều gì đó, bạn cần hiểu - chúng có liên quan đến nhau theo cách nào đó không? DORA đã trả lời khẳng định với một cảnh báo: mối quan hệ giữa các thay đổi không thành công (Tỷ lệ thay đổi thất bại) và ba số liệu khác yếu hơn một chút. Chúng tôi có cùng một bức tranh. Nếu thời gian phân phối, tần suất triển khai và thời gian khôi phục tương quan với nhau (chúng tôi đã thiết lập mối tương quan này thông qua tương quan Pearson và thông qua thang đo Chaddock), thì không có mối tương quan chặt chẽ như vậy với những thay đổi không thành công.

Về nguyên tắc, hầu hết những người được hỏi có xu hướng trả lời rằng họ gặp một số ít sự cố trong sản xuất. Mặc dù sau này chúng ta sẽ thấy rằng vẫn có sự khác biệt đáng kể giữa các nhóm người trả lời về những thay đổi không thành công, nhưng chúng ta chưa thể sử dụng thước đo này cho sự phân chia này.

Chúng tôi cho rằng điều này là do (như đã xảy ra trong quá trình phân tích và giao tiếp với một số khách hàng của chúng tôi) có một chút khác biệt trong nhận thức về những gì được coi là sự cố. Nếu chúng tôi quản lý để khôi phục hiệu suất dịch vụ của mình trong thời gian kỹ thuật, đây có thể được coi là một sự cố không? Có lẽ là không, bởi vì chúng tôi đã sửa mọi thứ, chúng tôi rất tuyệt. Chúng tôi có thể coi đó là một sự cố nếu chúng tôi phải cuộn lại ứng dụng của mình 10 lần ở chế độ bình thường, quen thuộc đối với chúng tôi không? Có vẻ như không. Do đó, câu hỏi về mối quan hệ của những thay đổi không thành công với các số liệu khác vẫn còn bỏ ngỏ. Chúng tôi sẽ tinh chỉnh nó hơn nữa.

Điều quan trọng ở đây là chúng tôi đã tìm thấy mối tương quan đáng kể giữa thời gian phân phối, thời gian khôi phục và tần suất triển khai. Do đó, chúng tôi đã sử dụng ba số liệu này để phân chia thêm những người trả lời thành các nhóm hiệu suất.

Bao nhiêu để treo bằng gam?

Chúng tôi đã sử dụng phân tích cụm phân cấp:

• Chúng tôi phân phối người trả lời trên một không gian n chiều, trong đó tọa độ của mỗi người trả lời là câu trả lời cho câu hỏi của họ.
• Mỗi người trả lời được khai báo là một cụm nhỏ.
• Chúng tôi kết hợp hai cụm gần nhau nhất thành một cụm lớn hơn.
• Chúng tôi tìm cặp cụm tiếp theo và kết hợp chúng thành một cụm lớn hơn.

Đây là cách chúng tôi nhóm tất cả những người trả lời vào số cụm mà chúng tôi cần. Với sự trợ giúp của dendrogram (một cây kết nối giữa các cụm), chúng ta thấy khoảng cách giữa hai cụm lân cận. Tất cả những gì còn lại đối với chúng tôi là đặt một giới hạn khoảng cách nhất định giữa các cụm này và nói: "Hai nhóm này khá dễ phân biệt với nhau vì khoảng cách giữa chúng là rất lớn."

Nhưng có một vấn đề tiềm ẩn ở đây: chúng tôi không có hạn chế về số lượng cụm - chúng tôi có thể nhận được 2, 3, 4, 10 cụm. Và ý tưởng đầu tiên là - tại sao không chia tất cả những người trả lời của chúng tôi thành 4 nhóm, như DORA đã làm. Nhưng chúng tôi nhận thấy rằng sự khác biệt giữa các nhóm này trở nên không đáng kể và chúng tôi không thể chắc chắn rằng người trả lời thực sự thuộc về nhóm của mình chứ không phải nhóm lân cận. Chúng tôi chưa thể chia thị trường Nga thành bốn nhóm. Do đó, chúng tôi đã giải quyết trên ba cấu hình mà giữa chúng có sự khác biệt có ý nghĩa thống kê:

Tiếp theo, chúng tôi xác định hồ sơ theo cụm: chúng tôi lấy giá trị trung bình cho từng chỉ số cho từng nhóm và biên soạn một bảng hồ sơ hiệu suất. Trên thực tế, chúng tôi có hồ sơ hiệu suất của người tham gia trung bình trong mỗi nhóm. Chúng tôi đã xác định ba hồ sơ hiệu quả: Thấp, Trung bình, Cao:

Tại đây, chúng tôi đã xác nhận giả thuyết của mình rằng 4 chỉ số chính phù hợp để xác định hồ sơ hiệu suất và chúng hoạt động ở cả thị trường phương Tây và Nga. Có sự khác biệt giữa các nhóm và có ý nghĩa thống kê. Tôi nhấn mạnh rằng có sự khác biệt đáng kể giữa các hồ sơ hiệu suất xét về chỉ số thay đổi không thành công xét về mức trung bình, mặc dù ban đầu chúng tôi không chia người trả lời theo thông số này.

Sau đó, câu hỏi đặt ra: làm thế nào để sử dụng tất cả những thứ này?

Cách sử dụng

Nếu chúng tôi lấy bất kỳ nhóm nào, 4 số liệu chính và áp dụng nó vào bảng, thì trong 85% trường hợp, chúng tôi sẽ không nhận được kết quả khớp hoàn chỉnh - đây chỉ là một người tham gia trung bình chứ không phải thực tế. Tất cả chúng ta (và mọi đội) hơi khác nhau.

Chúng tôi đã kiểm tra: chúng tôi đã chọn những người trả lời và hồ sơ hiệu suất của DORA, đồng thời xem xét có bao nhiêu người trả lời phù hợp với hồ sơ này hoặc hồ sơ kia. Chúng tôi thấy rằng chỉ có 16% số người được hỏi chắc chắn rơi vào một trong các hồ sơ. Tất cả phần còn lại nằm rải rác ở đâu đó ở giữa:

Điều này có nghĩa là hồ sơ hiệu quả có phạm vi hạn chế. Để hiểu bạn đang ở đâu trong phép tính gần đúng đầu tiên, bạn có thể sử dụng bảng này: “Ồ, có vẻ như chúng ta đang ở gần mức Trung bình hoặc Cao hơn!” Nếu bạn hiểu nơi để đi tiếp theo, điều này có thể là đủ. Nhưng nếu mục tiêu của bạn là không đổi, cải tiến liên tục và bạn muốn biết chính xác hơn về nơi phát triển và những việc cần làm, thì cần có thêm vốn. Chúng tôi gọi chúng là máy tính:

• Máy tính DORA
• Calculator Express 42* (đang phát triển)
• Phát triển riêng (bạn có thể tạo máy tính nội bộ của riêng mình).

Chúng cần thiết để làm gì? Hiểu:

• Nhóm trong tổ chức của chúng tôi có đáp ứng các tiêu chuẩn của chúng tôi không?
• Nếu không, chúng ta có thể giúp nó, tăng tốc nó trong khuôn khổ chuyên môn mà công ty chúng ta có không?
• Nếu vậy, chúng ta có thể làm tốt hơn nữa không?

Bạn cũng có thể sử dụng chúng để thu thập số liệu thống kê trong công ty:

• Chúng ta có những đội nào?
• Chia đội thành các hồ sơ;
• Hãy xem: Ồ, các lệnh này hoạt động kém hiệu quả (chúng không rút ra được một chút), nhưng chúng rất tuyệt: chúng triển khai hàng ngày, không có lỗi, chúng có thời gian hoàn thành chưa đến một giờ.

Và sau đó, bạn có thể phát hiện ra rằng trong công ty của chúng tôi có chuyên môn và công cụ cần thiết cho những nhóm chưa đạt tiêu chuẩn.

Hoặc, nếu bạn hiểu rằng bạn cảm thấy tuyệt vời khi ở trong công ty, bạn giỏi hơn nhiều người, thì bạn có thể nhìn rộng hơn một chút. Đây chỉ là ngành công nghiệp của Nga: chúng ta có thể có được chuyên môn cần thiết trong ngành công nghiệp của Nga để tăng tốc bản thân không? Máy tính Express 42 sẽ trợ giúp ở đây (nó đang được phát triển). Nếu bạn đã phát triển nhanh hơn thị trường Nga, thì hãy xem Máy tính DORA và ra thị trường thế giới.

Khỏe. Và nếu bạn thuộc nhóm Elit trên máy tính DORA, bạn nên làm gì? Không có giải pháp tốt ở đây. Bạn rất có thể đang dẫn đầu ngành, đồng thời có thể tăng tốc và độ tin cậy hơn nữa thông qua R&D nội bộ và sử dụng nhiều nguồn lực hơn.

Hãy chuyển sang phần ngọt ngào nhất - so sánh.

So sánh

Ban đầu chúng tôi muốn so sánh ngành công nghiệp Nga với ngành công nghiệp phương Tây. Nếu so sánh trực tiếp, chúng tôi thấy rằng chúng tôi có ít cấu hình hơn và chúng trộn lẫn với nhau hơn một chút, đường viền mờ hơn một chút:

Những người biểu diễn Ưu tú của chúng tôi bị ẩn trong số những Người biểu diễn cao, nhưng họ ở đó - đây là những người ưu tú, kỳ lân đã đạt đến những tầm cao đáng kể. Ở Nga, sự khác biệt giữa cấu hình Ưu tú và cấu hình Cao vẫn chưa đủ đáng kể. Chúng tôi nghĩ rằng trong tương lai sự tách biệt này sẽ xảy ra do sự gia tăng văn hóa kỹ thuật, chất lượng thực hiện các hoạt động kỹ thuật và chuyên môn trong các công ty.

Nếu chuyển sang so sánh trực tiếp trong ngành công nghiệp Nga, chúng ta có thể thấy rằng các nhóm Cao cấp tốt hơn về mọi mặt. Chúng tôi cũng xác nhận giả thuyết của mình rằng có mối quan hệ giữa các số liệu này và hiệu quả hoạt động của tổ chức: Các nhóm nổi tiếng có nhiều khả năng không chỉ đạt được mục tiêu mà còn vượt xa chúng.
Hãy trở thành những đội có thành tích cao và không dừng lại ở đó:

Nhưng năm nay thật đặc biệt và chúng tôi quyết định kiểm tra xem các công ty đang hoạt động như thế nào trong đại dịch: Các nhóm nổi tiếng đang hoạt động tốt hơn và cảm thấy tốt hơn nhiều so với mức trung bình của ngành:

• Khả năng phát hành sản phẩm mới cao gấp 1,5-2 lần,
• Tăng gấp 2 lần khả năng cải thiện độ tin cậy và/hoặc hiệu suất của cơ sở hạ tầng ứng dụng.

Đó là, những năng lực mà họ đã có giúp họ phát triển nhanh hơn, tung ra sản phẩm mới, sửa đổi sản phẩm hiện có, từ đó chinh phục thị trường mới và người dùng mới:

Điều gì khác đã giúp đội của chúng tôi?

thực hành kỹ thuật

Tôi sẽ cho bạn biết về những phát hiện quan trọng đối với từng phương pháp mà chúng tôi đã thử nghiệm. Có lẽ điều gì đó khác đã giúp các nhóm, nhưng chúng ta đang nói về DevOps. Và trong DevOps, chúng tôi nhận thấy sự khác biệt giữa các nhóm có hồ sơ khác nhau.

Nền tảng như một dịch vụ

Chúng tôi không tìm thấy mối quan hệ đáng kể giữa tuổi nền tảng và hồ sơ nhóm: Các nền tảng xuất hiện gần như cùng lúc cho cả Nhóm thấp và Nhóm cao. Nhưng về sau, trung bình, nền tảng này cung cấp nhiều dịch vụ hơn và nhiều giao diện lập trình hơn để điều khiển thông qua mã chương trình. Và các nhóm nền tảng có nhiều khả năng giúp các nhà phát triển và nhóm của họ sử dụng nền tảng, giải quyết các vấn đề và sự cố liên quan đến nền tảng của họ thường xuyên hơn, đồng thời giáo dục các nhóm khác.

Cơ sở hạ tầng dưới dạng mã

Mọi thứ đều khá chuẩn ở đây. Chúng tôi đã tìm thấy mối quan hệ giữa việc tự động hóa công việc của mã cơ sở hạ tầng và lượng thông tin được lưu trữ bên trong kho lưu trữ cơ sở hạ tầng. Các lệnh Cấu hình cao lưu trữ thêm thông tin trong kho lưu trữ: đây là cấu hình cơ sở hạ tầng, đường dẫn CI / CD, cài đặt môi trường và tham số bản dựng. Chúng lưu trữ thông tin này thường xuyên hơn, hoạt động tốt hơn với mã cơ sở hạ tầng và tự động hóa nhiều quy trình và tác vụ hơn để làm việc với mã cơ sở hạ tầng.

Thật thú vị, chúng tôi không thấy sự khác biệt đáng kể trong các thử nghiệm cơ sở hạ tầng. Tôi cho rằng điều này là do các nhóm có cấu hình cao nói chung có nhiều thử nghiệm tự động hơn. Có lẽ họ không nên bị phân tâm bởi các bài kiểm tra cơ sở hạ tầng, mà thay vào đó là những bài kiểm tra mà họ kiểm tra các ứng dụng và nhờ chúng, họ đã thấy những gì và nơi chúng bị hỏng.

Tích hợp và phân phối

Phần nhàm chán nhất, bởi vì chúng tôi đã xác nhận rằng bạn càng có nhiều tự động hóa, bạn càng làm việc với mã tốt hơn, bạn càng có nhiều khả năng đạt được kết quả tốt hơn.

kiến trúc

Chúng tôi muốn xem microservice ảnh hưởng đến hiệu suất như thế nào. Trên thực tế, họ không làm như vậy vì việc sử dụng microservice không liên quan đến việc tăng các chỉ số hiệu suất. Microservices được sử dụng cho cả lệnh Cấu hình cao và Lệnh cấu hình thấp.

Nhưng điều quan trọng là đối với các Nhóm cao, việc chuyển đổi sang kiến ​​trúc vi dịch vụ cho phép họ phát triển và triển khai các dịch vụ của mình một cách độc lập. Nếu kiến ​​trúc cho phép các nhà phát triển hành động một cách tự chủ mà không cần đợi ai đó bên ngoài nhóm, thì đây là năng lực chính để tăng tốc độ. Trong trường hợp này, microservices sẽ giúp ích. Và chỉ việc thực hiện của họ không đóng một vai trò lớn.

Làm thế nào mà chúng tôi phát hiện ra tất cả điều này?

Chúng tôi đã có một kế hoạch đầy tham vọng để nhân rộng hoàn toàn phương pháp DORA, nhưng lại thiếu nguồn lực. Nếu DORA sử dụng nhiều tài trợ và nghiên cứu của họ mất nửa năm, thì chúng tôi đã thực hiện nghiên cứu của mình trong một thời gian ngắn. Chúng tôi muốn xây dựng một mô hình DevOps như DORA đã làm và chúng tôi sẽ làm điều đó trong tương lai. Cho đến nay, chúng tôi đã giới hạn bản đồ nhiệt:

Chúng tôi đã xem xét sự phân bổ các phương pháp kỹ thuật giữa các nhóm trong mỗi hồ sơ và nhận thấy rằng các nhóm có cấu hình cao, trung bình, có nhiều khả năng sử dụng các phương pháp kỹ thuật hơn. Bạn có thể đọc thêm về tất cả điều này trong báo cáo.

Để thay đổi, hãy chuyển từ số liệu thống kê phức tạp sang số liệu thống kê đơn giản.

Những gì khác chúng tôi đã phát hiện ra?

Dụng cụ

Chúng tôi quan sát thấy rằng hầu hết các lệnh được sử dụng bởi hệ điều hành của gia đình Linux. Nhưng Windows vẫn đang là xu hướng - ít nhất một phần tư số người được hỏi của chúng tôi ghi nhận việc sử dụng một hoặc một phiên bản khác của nó. Có vẻ như thị trường có nhu cầu này. Do đó, bạn có thể phát triển những năng lực này và thuyết trình tại các hội nghị.

Trong số các nhà điều phối, không có gì bí mật đối với bất kỳ ai, Kubernetes dẫn đầu (52%). Trình điều phối dòng tiếp theo là Docker Swarm (khoảng 12%). Các hệ thống CI phổ biến nhất là Jenkins và GitLab. Hệ thống quản lý cấu hình phổ biến nhất là Ansible, tiếp theo là Shell yêu quý của chúng tôi.

Amazon hiện là nhà cung cấp dịch vụ lưu trữ đám mây hàng đầu. Tỷ lệ các đám mây của Nga đang tăng dần. Năm tới sẽ rất thú vị để xem các nhà cung cấp đám mây của Nga sẽ cảm thấy thế nào, liệu thị phần của họ có tăng lên hay không. Chúng là, chúng có thể được sử dụng, và điều đó thật tốt:

Tôi chuyển sàn cho Igor, người sẽ cung cấp thêm một số thống kê.

Phổ biến các thực hành

Igor Kurochkin: Riêng biệt, chúng tôi đã yêu cầu những người trả lời cho biết cách phân bổ các phương pháp kỹ thuật được xem xét trong công ty. Trong hầu hết các công ty, có một cách tiếp cận hỗn hợp, bao gồm một tập hợp các mẫu khác nhau và các dự án thí điểm rất phổ biến. Chúng tôi cũng thấy một sự khác biệt nhỏ giữa các hồ sơ. Các đại diện của Cấp cao thường sử dụng mô hình “Sáng kiến ​​từ bên dưới”, khi các nhóm chuyên gia nhỏ thay đổi quy trình làm việc, công cụ và chia sẻ các phương pháp thành công với các nhóm khác. Ở mức Trung bình, đây là một sáng kiến ​​cấp trên, ảnh hưởng đến toàn bộ công ty bằng cách tạo ra các cộng đồng và trung tâm xuất sắc:

Nhanh nhẹn và DevOps

Câu hỏi về mối liên hệ giữa Agile và DevOps thường được thảo luận trong ngành. Vấn đề này cũng được nêu ra trong Báo cáo trạng thái Agile cho năm 2019/2020, vì vậy chúng tôi quyết định so sánh cách các hoạt động Agile và DevOps được kết nối trong các công ty. Chúng tôi thấy rằng DevOps không có Agile là rất hiếm. Đối với một nửa số người được hỏi, sự phổ biến của Agile đã bắt đầu sớm hơn nhiều và khoảng 20% ​​quan sát thấy sự bắt đầu đồng thời và một trong những dấu hiệu của cấu hình Thấp sẽ là sự vắng mặt của các thực hành Agile và DevOps:

cấu trúc liên kết lệnh

Vào cuối năm ngoái, cuốn sách "cấu trúc liên kết nhóm”, đề xuất một khung mô tả các cấu trúc liên kết lệnh. Nó trở nên thú vị đối với chúng tôi liệu nó có thể áp dụng cho các công ty Nga hay không. Và chúng tôi đặt câu hỏi: “Bạn tìm thấy những mẫu nào?”.

Các nhóm cơ sở hạ tầng được quan sát thấy ở một nửa số người được hỏi, cũng như các nhóm riêng biệt để phát triển, thử nghiệm và vận hành. Các nhóm DevOps riêng biệt ghi nhận 45%, trong đó đại diện của Cao là phổ biến hơn. Tiếp theo là các nhóm đa chức năng, cũng phổ biến hơn ở Cấp cao. Các lệnh SRE riêng biệt xuất hiện trong cấu hình Cao, Trung bình và hiếm khi thấy trong cấu hình Thấp:

Tỷ lệ DevQaOps

Chúng tôi đã thấy câu hỏi này trên Facebook từ trưởng nhóm của nhóm nền tảng Skyeng - anh ấy quan tâm đến tỷ lệ nhà phát triển, người thử nghiệm và quản trị viên trong các công ty. Chúng tôi đã hỏi nó và xem xét các câu trả lời dựa trên hồ sơ: Các đại diện nổi tiếng có ít kỹ sư kiểm tra và vận hành hơn cho mỗi nhà phát triển:

Kế hoạch cho 2021 năm

Trong kế hoạch cho năm tiếp theo, người được hỏi lưu ý các hoạt động sau:

Tại đây, bạn có thể thấy điểm giao nhau với hội nghị DevOps Live 2020. Chúng tôi đã xem xét cẩn thận chương trình:

• Cơ sở hạ tầng như một sản phẩm
• chuyển đổi DevOps
• Phân phối các phương pháp DevOps
• DevSecOps
• Câu lạc bộ trường hợp và thảo luận

Nhưng thời gian trình bày của chúng tôi không đủ để trình bày hết các chủ đề. Bị bỏ lại phía sau hậu trường:

• Nền tảng là một dịch vụ và một sản phẩm;
• Cơ sở hạ tầng như mã, môi trường và đám mây;
• Tích hợp và phân phối liên tục;
• Ngành kiến ​​​​trúc;
• các mẫu DevSecOps;
• Nền tảng và các nhóm chức năng chéo.

Báo cáo chúng tôi có một số lượng lớn, 50 trang và bạn có thể xem chi tiết hơn.

Tổng hợp

Chúng tôi hy vọng rằng nghiên cứu và báo cáo của chúng tôi sẽ truyền cảm hứng cho bạn thử nghiệm các phương pháp tiếp cận mới để phát triển, thử nghiệm và vận hành, cũng như giúp bạn định hướng, so sánh bản thân với những người tham gia nghiên cứu khác và xác định các lĩnh vực mà bạn có thể cải thiện phương pháp tiếp cận của riêng mình.

Kết quả của nghiên cứu đầu tiên về tình trạng DevOps ở Nga:

• Các số liệu chính. Chúng tôi nhận thấy rằng các chỉ số chính (thời gian phân phối, tần suất triển khai, thời gian khôi phục và lỗi thay đổi) phù hợp để phân tích hiệu quả của các quy trình phát triển, thử nghiệm và vận hành.
• Cấu hình Cao, Trung bình, Thấp. Dựa trên dữ liệu thu thập được, chúng tôi có thể phân biệt các nhóm Cao, Trung bình, Thấp khác nhau về mặt thống kê với các đặc điểm khác biệt về số liệu, thực tiễn, quy trình và công cụ. Đại diện của Cấu hình cao thể hiện kết quả tốt hơn Cấu hình thấp. Họ có nhiều khả năng đạt được và vượt mục tiêu của họ.
• Các chỉ số, đại dịch và kế hoạch cho năm 2021. Một chỉ số đặc biệt trong năm nay là cách các công ty đối phó với đại dịch. Các đại diện cấp cao hoạt động tốt hơn, trải nghiệm sự tham gia của người dùng tăng lên và lý do chính dẫn đến thành công là các quy trình phát triển hiệu quả và văn hóa kỹ thuật mạnh mẽ.
• Thực hành DevOps, công cụ và sự phát triển của chúng. Các kế hoạch chính của các công ty trong năm tới bao gồm phát triển các công cụ và phương pháp DevOps, giới thiệu các phương pháp DevSecOps và những thay đổi trong cơ cấu tổ chức. Và việc triển khai và phát triển hiệu quả các phương pháp DevOps được thực hiện với sự trợ giúp của các dự án thí điểm, sự hình thành các cộng đồng và trung tâm xuất sắc, các sáng kiến ​​ở cấp trên và cấp dưới của công ty.

Chúng tôi rất muốn nghe phản hồi, câu chuyện, phản hồi của bạn. Chúng tôi cảm ơn tất cả những người đã tham gia nghiên cứu và mong đợi sự tham gia của bạn vào năm tới.

Nguồn: www.habr.com