Một vài năm trước, nhiều tổ chức coi DevOps là một thử nghiệm đầy hứa hẹn hơn là một phương pháp tiếp cận chính thống trong phát triển phần mềm. Ngày nay, DevOps là một tập hợp các công cụ và phương pháp phát triển và triển khai mạnh mẽ và đã được chứng minh có thể đẩy nhanh quá trình phát hành sản phẩm mới và cải thiện năng suất. Quan trọng hơn, tác dụng của DevOps hướng đến mục tiêu tăng trưởng kinh doanh tổng thể và tăng lợi nhuận.
Đội dịch thú vị nhất từ , được biên soạn bởi các chuyên gia từ DevOps Research & Assessment (DORA). Nghiên cứu có sự tham gia của 31 chuyên gia từ khắp nơi trên thế giới. Hãy cùng xem ngành này đã thay đổi như thế nào vào năm 000 và làm thế nào các doanh nghiệp có thể cải thiện hiệu quả cung cấp phần mềm.
Quy mô công ty và ngành công nghiệp ảnh hưởng đến trạng thái DevOps như thế nào
Nghiên cứu không tìm thấy mối tương quan giữa hiệu suất DevOps và ngành của một tổ chức, ngoại trừ bán lẻ, nơi hiệu suất có tốt hơn một chút. Điều này đặc biệt đúng vì các nhà bán lẻ cần phản ứng nhanh với những biến động về nhu cầu và nhu cầu của khách hàng. Theo nghiên cứu, bất kỳ công ty nào, bao gồm cả khu vực tài chính và khu vực công, đều có thể đạt được trình độ DevOps cao.
Hiệu suất DevOps tại các công ty có hơn 5000 nhân viên thấp hơn so với các công ty có ít hơn 5000 nhân viên. Nhiều khả năng, điều này là do các tổ chức lớn có quy trình quy mô lớn hơn, kiểm soát chặt chẽ hơn và kiến trúc hệ thống CNTT phức tạp hơn, gây ra sự chậm trễ trong quá trình phát triển và triển khai mã. Đồng thời, các chuyên gia tin rằng quy mô của công ty không cản trở sự thành công trong việc xây dựng DevOps, chỉ là trong một số trường hợp, nó có thể đòi hỏi nhiều nỗ lực hơn.
Cách đánh giá mức độ DevOps trong một công ty
Các chuyên gia đã so sánh các quy trình DevOps với đánh giá chuẩn, chia những người tham gia khảo sát thành bốn nhóm với hiệu suất tốt nhất, tốt, trung bình và kém.
Báo cáo lấy bốn số liệu chính để đánh giá hiệu quả của DevOps: thời gian hoàn tất các thay đổi trong phát triển phần mềm, tần suất triển khai, tỷ lệ lỗi và thời gian khôi phục.
Bốn cấp độ của DevOps - đánh giá vị trí của công ty bạn:
Một số liệu để đánh giá hiệu quả cung cấp phần mềm cho các dịch vụ và ứng dụng cốt lõi của công ty
Các đội có thành tích tốt nhất
Các đội có thành tích tốt
Các đội có hiệu suất trung bình
Các đội có điểm thấp
Tần suất triển khai
Tần suất một công ty triển khai mã để sản xuất hoặc phát hành mã cho người dùng cuối.
Theo yêu cầu, nhiều lần triển khai mỗi ngày
Từ một lần một ngày đến một lần một tuần
Từ một lần một tuần đến một lần một tháng
Một tháng một lần/nhiều tháng
Thời gian để hoàn tất thay đổi
Phải mất bao lâu để chuyển từ thử nghiệm sang phần mềm hoạt động thành công trong sản xuất?
Trong vòng chưa đầy một ngày
Từ một ngày đến một tuần
Từ một tuần đến một tháng
Từ một tháng đến sáu tháng
Thời gian phục hồi dịch vụ
Phải mất bao lâu để khôi phục dịch vụ sau sự cố hoặc lỗi ảnh hưởng đến người dùng.
Ít hơn một giờ
Trong ngày
Trong một tuần
Từ một tuần đến một tháng
Tần suất lỗi trong quá trình thay đổi
Tỷ lệ phần trăm bản cập nhật hoặc bản phát hành mới gây ra tình trạng suy giảm dịch vụ và cần sửa lỗi là bao nhiêu?
Từ 0-15%
Từ 0-15%
Từ 0-15%
Từ 46-60%
Nghiên cứu phát hiện ra xu hướng sau: số lượng nhóm có mức hiệu suất cao tăng gần gấp ba lần, từ 7% tổng số người trả lời vào năm 2018 lên 20% vào năm 2019.
Phân bổ nhóm phát triển theo mức độ hiệu suất.
So với các nhóm trong nhóm có hiệu suất thấp, các nhóm DevOps có hiệu suất cao:
- Thực hiện triển khai mã nhiều hơn 208 lần.
- Giảm 106 lần thời gian triển khai mã.
- Tỷ lệ thất bại ít hơn 7 lần.
- Khôi phục hoạt động phần mềm sau sự cố nhanh hơn 2,604 lần.
Ngoài ra, các nhóm DevOps có hiệu suất cao có khả năng đạt hoặc vượt quá các chỉ số hiệu suất của tổ chức gấp đôi so với các nhóm có hiệu suất thấp.
Nhiều chuyên gia cho rằng không thể đạt được mục tiêu tăng tất cả các chỉ số cùng một lúc mà cần phải có sự thỏa hiệp. Vì vậy, một số người tin rằng việc tăng tốc độ triển khai bản phát hành có thể ảnh hưởng tiêu cực đến độ tin cậy của quy trình phân phối phần mềm và việc cung cấp dịch vụ. Tuy nhiên, nghiên cứu đã chỉ ra rằng tốc độ và tính nhất quán của kết quả không loại trừ lẫn nhau.
Tôi không thấy có gì đáng ngạc nhiên trong sự gia tăng số lượng các nhóm DevOps, điều đó là tự nhiên: triết lý DevOps hiện đang rất phổ biến và số lượng các công ty khởi nghiệp cũng đang tăng lên.
Nhưng theo tôi, các chuyên gia đã không chọn đúng các thông số để đánh giá hiệu quả của DevOps.
Đánh giá dựa trên tốc độ triển khai mã thì quả thực rất kỳ lạ. Điều này chỉ áp dụng cho các công ty khởi nghiệp, nơi thông số chính sẽ là tốc độ đưa sản phẩm ra thị trường và thường thì sản phẩm được phát hành dưới dạng thô. Trong những điều kiện như vậy, các cơ chế giúp đẩy nhanh quá trình phát triển và đưa vào sản xuất là rất quan trọng. Nhưng đối với phần mềm đã được thiết lập, chẳng hạn như phần mềm tài chính hoặc y tế, tham số tỷ lệ lỗi có thể không tồn tại - lỗi có thể không được chấp nhận.
Tương tự như vậy đối với thời gian phục hồi dịch vụ: đối với bất kỳ dịch vụ đã phát triển nào, thời gian này phải được đo bằng giây và đối với nhiều dịch vụ, thời gian ngừng hoạt động là không thể chấp nhận được, vì mục đích này, các công nghệ triển khai liền mạch đã được phát minh (ví dụ: xanh lá cây/xanh lam).
Ngoài ra, bạn không nên tập trung vào số lượng triển khai mã – điều này phụ thuộc vào nhu cầu và năng lực của nhóm phát triển. Nếu việc triển khai liên quan đến việc bổ sung chức năng mới thì đó là một chuyện, nhưng nếu nó liên quan đến việc sửa lỗi đã xảy ra trong các lần triển khai trước thì đó lại là một chuyện hoàn toàn khác.
Denis Romanenko, chuyên gia tự do Mail.ru Cloud Solutions
Làm thế nào để cải thiện quy trình DevOps
Báo cáo trình bày hai lĩnh vực có thể giúp cải thiện DevOps: tăng hiệu quả phát triển và cung cấp phần mềm và cải thiện năng suất của nhân viên.
Mỗi hướng đi đều bao gồm những thành phần riêng, bằng cách cải thiện chúng, bạn có thể đạt được mục tiêu mong muốn.
Theo báo cáo, chìa khóa của chuyển đổi số chính là văn hóa doanh nghiệp. Các nhóm DevOps có hiệu suất cao cần có văn hóa tin tưởng và an toàn về mặt tâm lý, ý thức về mục đích và mục tiêu rõ ràng. Môi trường này cho phép các thành viên trong nhóm đưa ra quyết định sáng suốt, bày tỏ ý kiến và sáng tạo hơn.
Công nghệ đám mây, phân phối liên tục, thử nghiệm phục hồi sau thảm họa và quản lý thay đổi cũng sẽ giúp cải thiện hiệu quả phát triển và cung cấp phần mềm. Năng suất có thể được cải thiện bằng cách đầu tư vào các công cụ dễ sử dụng, giảm nợ kỹ thuật (tức là giảm tỷ lệ mã kém hiệu quả và công nghệ lỗi thời), tổ chức cơ sở tri thức của công ty và tiếp cận các giải pháp bên ngoài.
Tôi nghĩ rằng phương pháp luận và hệ tư tưởng của DevOps chính xác là các quy trình này không phụ thuộc vào các điều kiện bên ngoài, chẳng hạn như đám mây hoặc phần cứng của riêng bạn. Bản thân đám mây chỉ là một công cụ; nó có thể hữu ích ở một số nơi, cản trở ở những nơi khác hoặc sẽ không được ưa chuộng.
Denis Romanenko, chuyên gia tự do Mail.ru Cloud Solutions
Dưới đây chúng ta sẽ xem xét một số thành phần giúp cải thiện hiệu quả của nhóm DevOps.
Công nghệ đám mây thúc đẩy thành công của DevOps
Vào năm 2019, ngày càng nhiều tổ chức lựa chọn các giải pháp đám mây giúp tăng đáng kể năng suất của nhóm DevOps.
Nhóm DevOps sử dụng cơ sở hạ tầng nào?
DORA phát hiện ra rằng 80% số người được hỏi đã đăng . Tuy nhiên, chỉ có 29% số người được hỏi đã triển khai tất cả năm đặc điểm cốt lõi của điện toán đám mây do Viện Tiêu chuẩn và Công nghệ Quốc gia đề ra - tiêu chuẩn quan trọng nhất để đánh giá giá trị của đám mây trong DevOps.
Đặc tính
Tỷ lệ phần trăm những người đã sử dụng
Tự phục vụ theo yêu cầu
Người tiêu dùng có thể tự động cung cấp tài nguyên máy tính
khi cần thiết, mà không cần sự tham gia của nhà cung cấp.
57%
(+ 11% kể từ năm 2018)
Truy cập rộng rãi vào mạng
Khả năng đám mây có sẵn trên nhiều nền tảng,
chẳng hạn như điện thoại di động, máy tính bảng, máy tính xách tay và máy trạm.
60%
(+ 14% kể từ năm 2018)
Nguồn tài nguyên
Tài nguyên của nhà cung cấp được tập hợp vào mô hình nhiều bên thuê, trong đó tài nguyên vật lý và ảo được phân bổ động theo nhu cầu.
58%
(+ 15% kể từ năm 2018)
Khả năng mở rộng và tính đàn hồi
Tài nguyên có thể mở rộng theo chiều ngang hoặc chiều dọc theo nhu cầu, chúng hầu như không giới hạn và có thể được cung cấp với bất kỳ số lượng nào vào bất kỳ lúc nào.
58%
(+135 kể từ năm 2018)
minh bạch
Hệ thống đám mây tự động giám sát, tối ưu hóa và báo cáo việc sử dụng tài nguyên dựa trên loại dịch vụ: lưu trữ và xử lý dữ liệu, khối lượng lưu lượng,
tài khoản người dùng đang hoạt động.
62%
(+ 14% kể từ năm 2018)
Nền tảng dưới dạng dịch vụ (PaaS) đang ngày càng chuyển sang mô hình triển khai lấy container làm trung tâm. Nền tảng đám mây giúp triển khai phần mềm dễ dàng, do đó các nhóm chỉ cần lo chạy mã ứng dụng. Việc mở rộng quy mô, lập kế hoạch nguồn lực, quản lý và bảo trì cơ sở hạ tầng cũng đang chuyển sang phía nhà cung cấp.
Đối với các nhà cung cấp dịch vụ đám mây, tiêu chuẩn chung là cung cấp nhiều dịch vụ khác nhau: mạng máy ảo, quản lý danh tính và truy cập (IAM), lưu trữ và cơ sở dữ liệu, máy học, Internet vạn vật (IoT), giải pháp container, giải pháp bảo mật và người khác.
Khách hàng của nhà cung cấp dịch vụ đám mây chỉ trả tiền cho các tài nguyên họ sử dụng, điều này mang lại sự minh bạch về chi phí, không giống như các trung tâm dữ liệu truyền thống, nơi thông tin về chi phí phát triển rất khó hoặc không thể có được. Những người trả lời từ các công ty đáp ứng các đặc điểm của đám mây được liệt kê ở trên có khả năng ước tính chi phí chạy phần mềm cao hơn 2,6 lần, khả năng hiểu được ứng dụng nào tiêu tốn nhiều tài nguyên nhất cao hơn 2 lần và khả năng tuân thủ ngân sách CNTT cao hơn 1,65 lần.
Đôi khi việc thuê một chuyên gia có năng lực và sử dụng năng lực chuyên dụng trong trung tâm dữ liệu lại có lợi hơn là trả tiền cho đám mây. Lựa chọn nào tốt hơn phụ thuộc vào hồ sơ và quy mô của công ty, khả năng cung cấp đội ngũ chuyên gia CNTT và chuyên môn của công ty. Ví dụ, điện toán đám mây rất tiện lợi khi khởi nghiệp kinh doanh hoặc nếu công ty không có bộ phận CNTT riêng. Khi mở rộng quy mô, việc duy trì toàn bộ hoặc một phần cơ sở hạ tầng tại chỗ có thể tiết kiệm chi phí hơn.
Denis Romanenko, chuyên gia tự do Mail.ru Cloud Solutions
Thực hành kỹ thuật DevOps
Nhiều tổ chức muốn triển khai DevOps đang tìm kiếm một bộ hướng dẫn hoặc phương pháp hay nhất. Tuy nhiên, không có hai công ty nào giống hệt nhau, do đó, việc lựa chọn phương pháp nào phụ thuộc vào tình trạng hiện tại và mục tiêu của doanh nghiệp.
Tuy nhiên, có những lĩnh vực chung có thể giúp cải thiện hiệu quả DevOps: một số được phát triển ở cấp độ nhóm, trong khi những lĩnh vực khác đòi hỏi nỗ lực ở cấp độ tổ chức.
Những lĩnh vực tăng trưởng nào được nhấn mạnh cho các nhóm DevOps vào năm 2019:
Không có tổ chức cấp
- kiến trúc kết hợp lỏng lẻo
- thực hiện các thay đổi
- hỗ trợ mã
Ở cấp độ đội
- tích hợp liên tục
- tự động hóa thử nghiệm
- tự động triển khai
- giám sát
- đường ống phát triển
Ở cấp độ nhóm và tổ chức
- sử dụng dịch vụ đám mây
- thử nghiệm phục hồi thảm họa
Nghiên cứu đã xác nhận tác động tích cực của kiến trúc lỏng lẻo đối với hiệu quả DevOps.
Kiến trúc lỏng lẻo là khi các nhóm có thể độc lập kiểm tra, triển khai và thay đổi hệ thống theo yêu cầu, không phụ thuộc vào các nhóm khác, không cần hỗ trợ, tài nguyên, phê duyệt bổ sung và ít phản hồi hơn. Điều này giúp công việc hiệu quả hơn nhưng đòi hỏi trình độ tổ chức và quản lý cao.
Cách tiếp cận này chỉ khả thi đối với các công ty khởi nghiệp và có một số lưu ý. Tình hình có thể khác ở các công ty khác. Ví dụ điển hình: ngân hàng/công nghệ tài chính. Chỉ có thể sử dụng các giải pháp độc quyền ở đó, nhưng các hoạt động DevOps sẽ được áp dụng.
Denis Romanenko, chuyên gia tự do Mail.ru Cloud Solutions
Các nhóm DevOps thành công tự động hóa mọi thứ
cho phép bạn đưa các dịch vụ và ứng dụng vào sản xuất với chi phí và rủi ro thấp hơn, đồng thời duy trì các bản phát hành phù hợp với mục tiêu của tổ chức.
CI/CD thành công cũng có nghĩa là các nhóm có thể đẩy các thay đổi vào sản xuất theo yêu cầu, nhận được phản hồi ngay lập tức về chất lượng triển khai và có thể nhanh chóng hành động để cải thiện chu kỳ triển khai tiếp theo.
Báo cáo cho thấy các nhóm DevOps thành công đầu tư vào nhiều quy trình, hoạt động và công cụ hỗ trợ khác nhau:
- 92% sử dụng công cụ lắp ráp tự động;
- 87% sử dụng các bài kiểm tra đơn vị tự động;
- 57% mở rộng tự động hóa sang thử nghiệm chấp nhận;
- 72% tự động triển khai để thử nghiệm môi trường, 69% thực hiện tương tự cho triển khai sản xuất;
- 69% tích hợp chatbot vào quy trình triển khai của họ;
- 57% tích hợp với các công cụ giám sát.
Điều quan trọng là phải lựa chọn đúng công cụ và công nghệ
Khi xây dựng các hệ thống phức tạp và quản lý cơ sở hạ tầng quan trọng cho doanh nghiệp, điều quan trọng là phải lựa chọn công nghệ:
- dễ sử dụng khi mới kết nối cũng như khi hoạt động liên tục;
- giúp bạn đạt được mục tiêu của mình.
Báo cáo đã xem xét các công cụ được sử dụng để triển khai phần mềm thông qua CI/CD và các công cụ tự động hóa thử nghiệm—các công nghệ nền tảng của DevOps.
Các nhóm DevOps sử dụng những công nghệ nào:
Công nghệ
Các đội có điểm thấp
Các đội có hiệu suất trung bình
Các đội có thành tích tốt
Các đội có hiệu suất cao
Sự kết hợp giữa các sản phẩm độc quyền, mã nguồn mở và sản phẩm đóng hộp thương mại
30%
34%
32%
33%
Hầu hết là các giải pháp đóng hộp mã nguồn mở và được tùy chỉnh cao
17%
8%
7%
10%
Hầu hết là các giải pháp mã nguồn mở và đóng hộp với một chút tùy chỉnh
14%
21%
18%
20%
Trước hết, các giải pháp thương mại đóng hộp
8%
12%
8%
4%
Phát triển nội bộ và giải pháp độc quyền cho công ty
20%
6%
5%
6%
Trước hết, mã nguồn mở với khả năng tùy chỉnh mạnh mẽ
6%
7%
5%
12%
Chủ yếu là mã nguồn mở với một chút tùy chỉnh
5%
12%
24%
15%
Tính khả dụng của công cụ có tác động đáng kể đến khả năng tối đa hóa giá trị của nhóm công nghệ mà họ lựa chọn: các kỹ sư sử dụng công nghệ dễ sử dụng có khả năng tham gia vào các nhóm có hiệu suất cao cao hơn 1,5 lần.
Bảng này cho tôi cảm giác rằng để trở thành một nhóm DevOps thành công, bạn cần phải đi theo xu hướng chứ không phải là một thách thức kỹ thuật.
Một chuyên gia có năng lực sẽ lựa chọn công cụ phù hợp với nhiệm vụ chứ không phải ngược lại. Luôn có nhiều công cụ và cách tiếp cận để giải quyết mọi vấn đề. Công cụ cụ thể được xác định bởi: các chi tiết cụ thể của nhiệm vụ; mức độ quen thuộc của nhân viên với công cụ (mức ngưỡng đầu vào cao đến mức nào nếu công cụ mới); thành phần tài chính, nếu có.
Denis Romanenko, chuyên gia tự do Mail.ru Cloud Solutions
Аварийное восстановление
Mọi tổ chức phụ thuộc vào phần mềm phải có . Báo cáo cho biết các loại thử nghiệm khả năng phục hồi thảm họa mà các công ty khác nhau sử dụng.
Các công ty sử dụng loại thử nghiệm nào để phục hồi sau thảm họa?
Loại thử nghiệm
Các đội có điểm thấp
Các đội có hiệu suất trung bình
Các đội có thành tích tốt
Các đội có hiệu suất cao
Trung bình
Các bài kiểm tra không liên quan đến hệ thống thực tế
35%
26%
27%
30%
28%
Chuyển đổi cơ sở hạ tầng (bao gồm cả trung tâm dữ liệu)
27%
43%
34%
38%
38%
Kiểm tra lỗi ứng dụng
25%
46%
41%
49%
43%
Mô phỏng các sự cố có sự gián đoạn của hệ thống thử nghiệm
18%
22%
23%
29%
23%
Mô phỏng các sự cố gây gián đoạn hệ thống hoạt động
18%
11%
12%
13%
12%
Tạo ra các hệ thống tự động hóa và phá vỡ
hệ thống sản xuất thường xuyên, liên tục
9%
8%
7%
9%
8%
Chỉ có 40% số người được hỏi thực hiện thử nghiệm phục hồi sau thảm họa hàng năm bằng một hoặc nhiều phương pháp được liệt kê. Đồng thời, các công ty thực hiện thử nghiệm phục hồi sau thảm họa sẽ có mức độ sẵn sàng dịch vụ cao hơn. Báo cáo cho thấy các nhóm DevOps có hiệu suất cao có khả năng kết hợp dữ liệu thử nghiệm phục hồi sau thảm họa vào quy trình phát triển và triển khai phần mềm của họ cao hơn 1.4 lần.
Điều quan trọng là phải đảm bảo rằng các nhóm DevOps có quyền truy cập vào thông tin
Duy trì hiệu suất làm việc của nhóm DevOps sẽ giúp đảm bảo tìm thấy thông tin dễ dàng để giải quyết vấn đề. Điều này đặc biệt đúng trong môi trường công nghệ ngày nay, bao gồm các hệ thống phức tạp.
Các nguồn thông tin đó có thể được chia thành hai nhóm:
- Nguồn nội bộ: tài liệu của công ty về việc tạo và hỗ trợ mã, cơ sở kiến thức của công ty, kho lưu trữ, v.v. Các nhóm DevOps sử dụng nguồn kiến thức nội bộ có năng suất cao hơn 1,73 lần.
- Nguồn lực bên ngoài: công cụ tìm kiếm và bổ sung ngăn xếp. Các nhóm DevOps thuê ngoài có năng suất cao hơn 1,67 lần. Công nghệ bên ngoài mang lại lợi thế lớn cho việc học tập và phát triển, đặc biệt là việc sử dụng các đám mây công cộng và các công cụ nguồn mở.
Điều quan trọng đối với các công ty là giảm nợ kỹ thuật
Nợ kỹ thuật bao gồm mã hoặc hệ thống có lỗi đã biết nhưng chưa được sửa; phạm vi kiểm tra không đủ; mã hoặc thiết kế chất lượng thấp; hiện vật không được sử dụng nhưng không bị loại bỏ; việc triển khai mà nhóm không thể hỗ trợ hiệu quả; công nghệ lạc hậu; tài liệu không đầy đủ hoặc lỗi thời.
Các chuyên gia đã phát hiện ra rằng nợ kỹ thuật ảnh hưởng tiêu cực đến hiệu quả của DevOps. Các nhóm có nợ kỹ thuật cao có năng suất kém hơn 1,6 lần. Các nhóm có hiệu suất cao có khả năng có nợ kỹ thuật thấp cao hơn 1,4 lần.
Những phát hiện chính từ Khảo sát tình hình DevOps
- Tỷ lệ các nhóm DevOps đạt điểm cao đã tăng gần gấp ba lần lên 20%. Điều này có nghĩa là các doanh nghiệp hiểu được tiềm năng của các hoạt động nhằm cải thiện việc phát triển và cung cấp phần mềm, và các công ty đang tích cực triển khai DevOps hơn trong bộ phận CNTT của mình.
- Cung cấp ứng dụng và dịch vụ nhanh chóng là cốt lõi của công nghệ và chuyển đổi hiệu suất tổ chức. Tốc độ và tính nhất quán của các bản phát hành làm tăng lợi nhuận và sự hài lòng của khách hàng.
- Công nghệ đám mây tiếp tục đóng vai trò then chốt để đạt được kết quả cao cho các nhóm DevOps. Sử dụng đám mây cho phép bạn tổ chức phân phối phần mềm ở tốc độ cần thiết, đảm bảo tính khả dụng, khả năng mở rộng và hiệu suất của cơ sở hạ tầng.
- Hiệu quả của nhóm DevOps có thể được cải thiện bằng cách chú ý đến năng suất của các thành viên trong nhóm, đảm bảo bầu không khí tâm lý thoải mái và sử dụng các công cụ thuận tiện.
- Việc tăng tốc độ triển khai bản phát hành, khi thực hiện đúng, sẽ không ảnh hưởng đến tính ổn định của các dịch vụ và ứng dụng của công ty.
Nguồn: www.habr.com
