Hình ảnh:
Chào mọi người! Chúng tôi là những kỹ sư tự động hóa từ công ty và chúng tôi hỗ trợ phát triển các sản phẩm của công ty: chúng tôi hỗ trợ toàn bộ quy trình lắp ráp từ cam kết một dòng mã của các nhà phát triển đến xuất bản thành phẩm và giấy phép trên các máy chủ cập nhật. Một cách không chính thức, chúng tôi được gọi là kỹ sư DevOps. Trong bài viết này, chúng tôi muốn nói về các giai đoạn công nghệ của quy trình sản xuất phần mềm, cách chúng ta nhìn nhận và phân loại chúng.
Từ tài liệu này, bạn sẽ tìm hiểu về sự phức tạp của việc phối hợp phát triển nhiều sản phẩm, bản đồ công nghệ là gì và nó giúp hợp lý hóa và nhân rộng các giải pháp như thế nào, các giai đoạn và bước chính của quy trình phát triển là gì, các lĩnh vực trách nhiệm như thế nào giữa DevOps và các nhóm trong công ty của chúng tôi.
Giới thiệu về Chaos và DevOps
Tóm lại, khái niệm DevOps bao gồm các công cụ và dịch vụ phát triển, cũng như các phương pháp và phương pháp hay nhất để sử dụng chúng. Hãy chọn ra toàn cầu Mục tiêu từ việc triển khai các ý tưởng DevOps trong công ty của chúng tôi: đây là việc giảm chi phí sản xuất và bảo trì sản phẩm một cách nhất quán về mặt định lượng (giờ nhân công hoặc giờ máy, CPU, RAM, Ổ đĩa, v.v.). Cách dễ nhất và rõ ràng nhất để giảm chi phí phát triển chung ở cấp độ toàn bộ công ty là giảm thiểu chi phí thực hiện các nhiệm vụ nối tiếp điển hình ở tất cả các công đoạn sản xuất. Nhưng những giai đoạn này là gì, làm thế nào để tách chúng ra khỏi quy trình chung, chúng bao gồm những bước nào?
Khi một công ty phát triển một sản phẩm, mọi thứ ít nhiều rõ ràng: thường có một lộ trình và kế hoạch phát triển chung. Nhưng phải làm gì khi dòng sản phẩm mở rộng và có nhiều sản phẩm hơn? Thoạt nhìn, chúng có các quy trình và dây chuyền lắp ráp tương tự nhau, và trò chơi “tìm điểm khác biệt X” trong nhật ký và tập lệnh bắt đầu. Nhưng nếu đã có hơn 5 dự án đang được phát triển tích cực và cần hỗ trợ cho một số phiên bản được phát triển trong vài năm thì sao? Chúng tôi muốn sử dụng lại số lượng giải pháp tối đa có thể có trong các quy trình sản phẩm hay chúng tôi sẵn sàng chi tiền cho một sự phát triển độc đáo cho từng giải pháp?
Làm cách nào để tìm sự cân bằng giữa tính duy nhất và giải pháp nối tiếp?
Những câu hỏi này bắt đầu xuất hiện trước mắt chúng tôi ngày càng thường xuyên hơn kể từ năm 2015. Số lượng sản phẩm tăng lên và chúng tôi đã cố gắng mở rộng bộ phận tự động hóa (DevOps) hỗ trợ các dây chuyền lắp ráp của các sản phẩm này ở mức tối thiểu. Đồng thời, chúng tôi muốn nhân rộng càng nhiều giải pháp càng tốt giữa các sản phẩm. Rốt cuộc, tại sao lại làm cùng một thứ trong mười sản phẩm theo những cách khác nhau?
Giám đốc phát triển: "Các bạn, bằng cách nào đó chúng ta có thể đánh giá những gì DevOps làm cho các sản phẩm không?"
Chúng tôi: “Chúng tôi không biết, chúng tôi không đặt câu hỏi như vậy, nhưng những chỉ số nào cần được xem xét?”
Giám đốc phát triển: "Ai biết! Nghĩ…"
Như trong bộ phim nổi tiếng đó: "Tôi đang ở khách sạn! .." - "Uh ... Bạn có thể chỉ đường cho tôi được không?" Sau khi suy ngẫm, chúng tôi đi đến kết luận rằng trước tiên chúng tôi cần quyết định về trạng thái cuối cùng của sản phẩm; điều này đã trở thành mục tiêu đầu tiên của chúng tôi.
Vì vậy, làm thế nào để bạn phân tích hàng chục sản phẩm với các nhóm khá lớn từ 10 đến 200 người và xác định các chỉ số có thể đo lường được khi sao chép các giải pháp?
1:0 nghiêng về Chaos hoặc DevOps trên bả vai
Chúng tôi bắt đầu với nỗ lực áp dụng các sơ đồ IDEF0 và các sơ đồ quy trình kinh doanh khác nhau từ chuỗi BPwin. Sự nhầm lẫn bắt đầu sau ô vuông thứ năm của giai đoạn tiếp theo của dự án tiếp theo và các ô vuông này cho mỗi dự án có thể được vẽ ở đuôi của một con trăn dài dưới hơn 50 bước. Tôi cảm thấy buồn và muốn hú lên với mặt trăng - nói chung nó không phù hợp.
Nhiệm vụ sản xuất điển hình
Mô hình hóa các quy trình sản xuất là một công việc rất phức tạp và tốn nhiều công sức: bạn cần thu thập, xử lý và phân tích rất nhiều dữ liệu từ các phòng ban và chuỗi sản xuất khác nhau. Bạn có thể đọc thêm về điều này trong bài viết "'.
Khi chúng tôi bắt đầu lập mô hình quy trình sản xuất của mình, chúng tôi đã có một mục tiêu cụ thể - truyền đạt tới mọi nhân viên tham gia phát triển sản phẩm của công ty chúng tôi và tới các nhà quản lý dự án:
- cách các sản phẩm và thành phần của chúng, bắt đầu từ cam kết của một dòng mã, tiếp cận khách hàng dưới dạng trình cài đặt và bản cập nhật,
- những nguồn lực nào được cung cấp cho từng giai đoạn sản xuất sản phẩm,
- những dịch vụ nào có liên quan ở mỗi giai đoạn,
- làm thế nào các lĩnh vực trách nhiệm cho từng giai đoạn được phân định,
- hợp đồng nào tồn tại ở đầu vào và đầu ra của từng giai đoạn.
Nhấp vào hình ảnh sẽ mở nó ở kích thước đầy đủ.
Công việc của chúng tôi trong công ty được chia thành nhiều lĩnh vực chức năng. Định hướng của cơ sở hạ tầng là tối ưu hóa hoạt động của tất cả các tài nguyên "sắt" của bộ phận, cũng như tự động hóa việc triển khai các máy ảo và môi trường trên chúng. Hướng giám sát cung cấp dịch vụ kiểm soát hiệu quả hoạt động 24/7; chúng tôi cũng cung cấp dịch vụ giám sát cho các nhà phát triển. Hướng quy trình công việc cung cấp cho các nhóm công cụ để quản lý quy trình phát triển và thử nghiệm, phân tích trạng thái của mã và nhận phân tích về các dự án. Và cuối cùng, hướng webdev cung cấp việc xuất bản các bản phát hành trên các máy chủ cập nhật GUS và FLUS, cũng như cấp phép cho các sản phẩm sử dụng dịch vụ LicenseLab. Để hỗ trợ quy trình sản xuất, chúng tôi thiết lập và duy trì nhiều dịch vụ hỗ trợ khác nhau dành cho nhà phát triển (bạn có thể nghe câu chuyện về một số trong số họ trên các cuộc gặp gỡ cũ: и). Chúng tôi cũng phát triển các công cụ tự động hóa nội bộ, bao gồm .
Trong năm năm qua, công việc của chúng tôi đã tích lũy được rất nhiều hoạt động cùng loại và thường lệ, và các nhà phát triển của chúng tôi từ các bộ phận khác chủ yếu đến từ cái gọi là nhiệm vụ điển hình, giải pháp được tự động hóa hoàn toàn hoặc một phần, không gây khó khăn cho người thực hiện và không yêu cầu khối lượng công việc đáng kể. Cùng với các lĩnh vực hàng đầu, chúng tôi đã phân tích các nhiệm vụ đó và có thể xác định các loại công việc riêng lẻ hoặc các bước sản xuất, các giai đoạn được chia thành các bước không thể chia nhỏ và một số giai đoạn cộng lại chuỗi quy trình sản xuất.
Ví dụ đơn giản nhất về dây chuyền công nghệ là các giai đoạn lắp ráp, triển khai và thử nghiệm từng sản phẩm của chúng ta trong công ty. Đổi lại, ví dụ, giai đoạn xây dựng bao gồm nhiều bước điển hình riêng biệt: tải xuống các nguồn từ GitLab, chuẩn bị các thư viện phụ thuộc và bên thứ 3, kiểm tra đơn vị và phân tích mã tĩnh, thực thi tập lệnh xây dựng trên GitLab CI, xuất bản các tạo phẩm trong kho lưu trữ trên Artifactory và tạo ghi chú phát hành thông qua công cụ ChangelogBuilder nội bộ của chúng tôi.
Bạn có thể đọc về các tác vụ DevOps điển hình trong các bài viết khác của chúng tôi trên Habré: ""Và"'.
Nhiều chuỗi sản xuất điển hình hình thành Quy trình sản xuất. Cách tiếp cận tiêu chuẩn để mô tả các quy trình là sử dụng các mô hình IDEF0 chức năng.
Một ví dụ về lập mô hình quy trình CI sản xuất
Chúng tôi đặc biệt chú ý đến việc phát triển các dự án tiêu chuẩn cho một hệ thống tích hợp liên tục. Điều này giúp đạt được sự thống nhất của các dự án, làm nổi bật cái gọi là phát hành kế hoạch xây dựng với các chương trình khuyến mãi.
Đây là cách nó hoạt động. Tất cả các dự án đều có vẻ điển hình: chúng bao gồm cấu hình của các tập hợp rơi vào kho lưu trữ ảnh chụp nhanh tại Artifactory, sau đó chúng được triển khai và thử nghiệm trên băng ghế thử nghiệm, sau đó được thăng cấp lên kho lưu trữ phát hành. Dịch vụ Artifactory là một điểm phân phối duy nhất cho tất cả các tạo phẩm tạo tác giữa các nhóm và các dịch vụ khác.
Nếu chúng tôi đơn giản hóa và khái quát hóa kế hoạch phát hành của mình, thì nó bao gồm các bước sau:
- lắp ráp sản phẩm đa nền tảng,
- triển khai đến băng ghế thử nghiệm,
- chạy thử nghiệm chức năng và các thử nghiệm khác,
- thúc đẩy các bản dựng đã thử nghiệm để phát hành kho lưu trữ tại Artifactory,
- xuất bản bản phát hành được xây dựng trên các máy chủ cập nhật,
- cung cấp các lắp ráp và cập nhật cho sản xuất,
- khởi chạy cài đặt và cập nhật sản phẩm.
Ví dụ: hãy xem xét mô hình công nghệ của sơ đồ phát hành điển hình này (sau đây gọi đơn giản là Mô hình) ở dạng mô hình IDEF0 chức năng. Nó phản ánh các giai đoạn chính của quy trình CI của chúng tôi. Các mô hình IDEF0 sử dụng cái gọi là ký hiệu ICOM (Đầu vào-Kiểm soát-Đầu ra-Cơ chế) để mô tả tài nguyên nào được sử dụng ở mỗi giai đoạn, dựa trên quy tắc và yêu cầu nào công việc được thực hiện, đầu ra là gì và cơ chế, dịch vụ hoặc con người nào thực hiện một giai đoạn cụ thể.
Nhấp vào hình ảnh sẽ mở nó ở kích thước đầy đủ.
Theo quy định, việc phân tách và mô tả chi tiết các quy trình trong các mô hình chức năng sẽ dễ dàng hơn. Nhưng khi số lượng các phần tử tăng lên, việc hiểu điều gì đó trong chúng ngày càng trở nên khó khăn hơn. Nhưng trong quá trình phát triển thực tế cũng có các giai đoạn phụ trợ: giám sát, chứng nhận sản phẩm, tự động hóa quy trình làm việc, v.v. Chính vì vấn đề mở rộng quy mô mà chúng tôi đã từ bỏ mô tả này.
sự ra đời của hy vọng
Trong một cuốn sách, chúng tôi bắt gặp những bản đồ cũ của Liên Xô mô tả các quy trình công nghệ (nhân tiện, những bản đồ này vẫn được sử dụng cho đến ngày nay tại nhiều doanh nghiệp nhà nước và trường đại học). Đợi đã, đợi đã, vì chúng ta cũng có một quy trình làm việc!.. Có các giai đoạn, kết quả, số liệu, yêu cầu, chỉ số, v.v.. Tại sao không thử áp dụng các lưu trình cho quy trình sản phẩm của chúng ta? Có một cảm giác: “Đây rồi! Chúng tôi đã tìm đúng chủ đề, đã đến lúc kéo nó thật tốt!
Trong một bảng đơn giản, chúng tôi quyết định ghi sản phẩm theo cột, giai đoạn công nghệ và quy trình sản phẩm theo hàng. Các mốc quan trọng là một cái gì đó lớn, chẳng hạn như một bước xây dựng sản phẩm. Và các bước là một cái gì đó nhỏ hơn và chi tiết hơn, chẳng hạn như bước tải mã nguồn xuống máy chủ xây dựng hoặc bước biên dịch mã.
Tại các giao điểm của các hàng và cột của bản đồ, chúng tôi đặt các trạng thái cho một giai đoạn và sản phẩm cụ thể. Đối với các trạng thái, một tập hợp các trạng thái đã được xác định:
- Không có thông tin - hoặc không phù hợp. Cần phân tích nhu cầu về một công đoạn trong sản phẩm. Hoặc là phân tích đã được thực hiện, nhưng giai đoạn này hiện không cần thiết hoặc không hợp lý về mặt kinh tế.
- hoãn lại - hoặc không liên quan vào lúc này. Một giai đoạn trong đường ống là cần thiết, nhưng không có lực lượng để thực hiện trong năm nay.
- Có kế hoạch. Giai đoạn được lên kế hoạch để thực hiện trong năm nay.
- nhận ra. Giai đoạn trong đường ống được thực hiện trong khối lượng yêu cầu.
Điền vào bảng bắt đầu dự án theo dự án. Đầu tiên, các giai đoạn và các bước của một dự án được phân loại và trạng thái của chúng được ghi lại. Sau đó, họ thực hiện dự án tiếp theo, sửa các trạng thái trong đó và thêm các giai đoạn và bước còn thiếu trong các dự án trước đó. Kết quả là, chúng tôi có các giai đoạn và bước của toàn bộ quy trình sản xuất cũng như trạng thái của chúng trong một dự án cụ thể. Hóa ra một cái gì đó tương tự như ma trận năng lực đường ống sản phẩm. Chúng tôi gọi một ma trận như vậy là bản đồ công nghệ.
Với sự trợ giúp của bản đồ công nghệ, chúng tôi phối hợp một cách hợp lý về mặt đo lường với các nhóm về kế hoạch làm việc trong năm và các mục tiêu mà chúng tôi muốn cùng nhau đạt được: chúng tôi thêm giai đoạn nào vào dự án trong năm nay và giai đoạn nào chúng tôi để lại sau. Ngoài ra, trong quá trình làm việc, chúng tôi có thể có những cải tiến ở những công đoạn mà chúng tôi đã hoàn thành chỉ đối với một sản phẩm. Sau đó, chúng tôi mở rộng bản đồ của mình và giới thiệu cải tiến này dưới dạng một giai đoạn hoặc một bước mới, sau đó chúng tôi phân tích cho từng sản phẩm và tìm ra tính khả thi của việc nhân rộng cải tiến.
Họ có thể phản đối chúng tôi: “Tất nhiên, tất cả đều tốt, chỉ là theo thời gian, số lượng các bước và giai đoạn sẽ trở nên quá lớn. Làm sao để?
Chúng tôi đã giới thiệu các mô tả tiêu chuẩn và khá đầy đủ về các yêu cầu cho từng giai đoạn và bước để mọi người trong công ty đều hiểu chúng theo cùng một cách. Theo thời gian, khi các cải tiến được đưa ra, một bước có thể được đưa vào một giai đoạn hoặc bước khác và sau đó chúng sẽ "sụp đổ". Đồng thời, tất cả các yêu cầu và sắc thái công nghệ phù hợp với yêu cầu của giai đoạn hoặc bước khái quát hóa.
Làm thế nào để đánh giá hiệu quả của các giải pháp nhân rộng? Chúng tôi sử dụng một cách tiếp cận cực kỳ đơn giản: chúng tôi quy chi phí vốn ban đầu để thực hiện một giai đoạn mới vào chi phí sản phẩm chung hàng năm, sau đó chia cho tất cả khi nhân rộng.
Các phần của quá trình phát triển đã được hiển thị dưới dạng các cột mốc và các bước trên bản đồ. Chúng tôi có thể tác động đến việc giảm giá thành sản phẩm thông qua việc áp dụng tự động hóa cho các công đoạn điển hình. Sau đó, chúng tôi xem xét các thay đổi về đặc điểm định tính, chỉ số định lượng và lợi nhuận mà các nhóm nhận được (tính theo số giờ làm việc hoặc số giờ máy tiết kiệm được).
Sơ đồ quy trình công nghệ sản xuất
Nếu chúng ta thực hiện tất cả các giai đoạn và bước của mình, mã hóa chúng bằng các thẻ và mở rộng chúng thành một chuỗi, thì nó sẽ trở nên rất dài và khó hiểu (chỉ là cái “đuôi trăn” mà chúng ta đã nói ở đầu bài viết) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Đây là các giai đoạn xây dựng sản phẩm [Build], triển khai chúng tới máy chủ thử nghiệm [Deploy], thử nghiệm [Test], thúc đẩy các bản dựng để phát hành kho lưu trữ dựa trên kết quả thử nghiệm [Promote], tạo và xuất bản giấy phép [License], xuất bản [ Xuất bản] trên máy chủ cập nhật GUS và phân phối tới máy chủ cập nhật FLUS, cài đặt và cập nhật các thành phần sản phẩm trên cơ sở hạ tầng của khách hàng bằng cách sử dụng Quản lý cấu hình sản phẩm [Cài đặt], cũng như thu thập phép đo từ xa [Telemetry] từ các sản phẩm đã cài đặt.
Ngoài chúng, có thể phân biệt các giai đoạn riêng biệt: giám sát trạng thái cơ sở hạ tầng [InfMonitoring], phiên bản mã nguồn [SourceCodeControl], chuẩn bị môi trường xây dựng [Chuẩn bị], quản lý dự án [Quy trình công việc], cung cấp cho các nhóm công cụ truyền thông [Giao tiếp], chứng nhận sản phẩm [ Chứng nhận] và đảm bảo tính tự túc của các quy trình CI [CISelfSufficiency] (ví dụ: tính độc lập của các hội đồng với Internet). Hàng chục bước trong quy trình của chúng tôi thậm chí sẽ không được xem xét vì chúng rất cụ thể.
Sẽ dễ hiểu và xem xét toàn bộ quy trình sản xuất hơn nhiều nếu nó được trình bày dưới dạng bản đồ công nghệ; đây là một bảng trong đó các giai đoạn sản xuất riêng lẻ và các bước phân tách của Mô hình được viết theo hàng và trong các cột mô tả về những gì được thực hiện ở từng giai đoạn hoặc bước. Trọng tâm chính được đặt vào các nguồn lực cung cấp cho từng giai đoạn và việc phân định các lĩnh vực trách nhiệm.
Bản đồ đối với chúng tôi là một loại phân loại. Nó phản ánh các bộ phận công nghệ lớn của việc sản xuất sản phẩm. Nhờ đó, nhóm tự động hóa của chúng tôi dễ dàng tương tác với các nhà phát triển hơn và cùng lập kế hoạch triển khai các giai đoạn tự động hóa, cũng như hiểu được chi phí lao động và tài nguyên (con người và phần cứng) sẽ cần cho việc này.
Trong công ty của chúng tôi, bản đồ được tạo tự động từ mẫu jinja dưới dạng tệp HTML thông thường, sau đó được tải lên máy chủ Trang GitLab. Có thể xem ảnh chụp màn hình với ví dụ về bản đồ được tạo đầy đủ .
Nhấp vào hình ảnh sẽ mở nó ở kích thước đầy đủ.
Tóm lại, bản đồ công nghệ là một bức tranh tổng quát về quy trình sản xuất, nó phản ánh các khối được phân loại rõ ràng với chức năng đặc trưng.
Cấu trúc của bản đồ đường đi của chúng tôi
Bản đồ bao gồm một số phần:
- Khu vực tiêu đề - đây là mô tả chung về bản đồ, các khái niệm cơ bản được giới thiệu, các tài nguyên và kết quả chính của quy trình sản xuất được xác định.
- Bảng điều khiển - tại đây bạn có thể kiểm soát việc hiển thị dữ liệu cho từng sản phẩm, cung cấp tóm tắt các giai đoạn đã triển khai và các bước nói chung cho tất cả các sản phẩm.
- Bản đồ công nghệ - mô tả dạng bảng về quy trình công nghệ. Trên bản đồ:
- tất cả các giai đoạn, các bước và mã của họ được đưa ra;
- mô tả ngắn gọn và đầy đủ về các giai đoạn được đưa ra;
- các tài nguyên đầu vào và dịch vụ được sử dụng ở mỗi giai đoạn được chỉ định;
- kết quả của từng giai đoạn và một bước riêng biệt được chỉ định;
- lĩnh vực trách nhiệm cho từng giai đoạn và bước được chỉ định;
- các tài nguyên kỹ thuật, chẳng hạn như ổ cứng (SSD), RAM, vCPU và số giờ cần thiết để hỗ trợ công việc ở giai đoạn này, cả ở thời điểm hiện tại - một thực tế và trong tương lai - một kế hoạch, đã được xác định;
- đối với từng sản phẩm phải chỉ ra công đoạn, bước công nghệ nào đã được thực hiện, dự kiến thực hiện, chưa thực hiện hoặc chưa thực hiện.
Ra quyết định dựa trên bản đồ công nghệ
Sau khi kiểm tra bản đồ, có thể thực hiện một số hành động - tùy thuộc vào vai trò của nhân viên trong công ty (người quản lý phát triển, người quản lý sản phẩm, nhà phát triển hoặc người thử nghiệm):
- hiểu những giai đoạn nào còn thiếu trong một sản phẩm hoặc dự án thực tế và đánh giá nhu cầu thực hiện chúng;
- phân định phạm vi trách nhiệm giữa một số bộ phận nếu các bộ phận đó làm việc ở các khâu khác nhau;
- thống nhất hợp đồng tại các lối vào, lối ra của các chặng;
- tích hợp giai đoạn công việc của bạn vào quá trình phát triển tổng thể;
- đánh giá chính xác hơn nhu cầu về nguồn lực cung cấp cho từng giai đoạn.
Tổng hợp tất cả những điều trên
Định tuyến linh hoạt, có thể mở rộng và dễ bảo trì. Việc phát triển và duy trì mô tả quy trình ở dạng này dễ dàng hơn nhiều so với mô hình IDEF0 học thuật nghiêm ngặt. Ngoài ra, mô tả dạng bảng đơn giản hơn, quen thuộc hơn và có cấu trúc tốt hơn so với mô hình chức năng.
Để triển khai kỹ thuật các bước, chúng tôi có một công cụ nội bộ đặc biệt CrossBuilder - một công cụ lớp giữa các hệ thống CI, dịch vụ và cơ sở hạ tầng. Nhà phát triển không cần phải cắt chiếc xe đạp của mình: trong hệ thống CI của chúng tôi, chỉ cần chạy một trong các tập lệnh (cái gọi là tác vụ) của công cụ CrossBuilder là đủ, công cụ này sẽ thực thi chính xác nó, có tính đến các tính năng của cơ sở hạ tầng của chúng tôi .
Kết quả
Bài báo hóa ra khá dài, nhưng điều này là không thể tránh khỏi khi mô tả mô hình hóa các quy trình phức tạp. Cuối cùng, tôi muốn sửa chữa ngắn gọn những ý chính của chúng tôi:
- Mục tiêu của việc triển khai các ý tưởng DevOps trong công ty của chúng tôi là giảm chi phí sản xuất và bảo trì các sản phẩm của công ty một cách nhất quán về mặt định lượng (giờ công hoặc giờ máy, vCPU, RAM, Ổ đĩa).
- Cách giảm chi phí phát triển chung là giảm thiểu chi phí thực hiện các công việc nối tiếp điển hình: các công đoạn, các bước của quy trình công nghệ.
- Nhiệm vụ điển hình là nhiệm vụ mà giải pháp của nó được tự động hóa hoàn toàn hoặc một phần, không gây khó khăn cho người thực hiện và không đòi hỏi chi phí lao động đáng kể.
- Quá trình sản xuất bao gồm các công đoạn, các công đoạn được chia thành các bước không thể chia cắt, là những công việc đặc trưng có quy mô và phạm vi khác nhau.
- Từ các nhiệm vụ điển hình khác nhau, chúng ta đã đi đến các chuỗi công nghệ phức tạp và các mô hình đa cấp của quy trình sản xuất, có thể được mô tả bằng mô hình IDEF0 chức năng hoặc bản đồ công nghệ đơn giản hơn.
- Bản đồ công nghệ là một biểu diễn dạng bảng của các giai đoạn và các bước của quy trình sản xuất. Điều quan trọng nhất: bản đồ cho phép bạn xem toàn bộ quá trình, theo từng phần lớn với khả năng trình bày chi tiết chúng.
- Dựa trên bản đồ công nghệ, có thể đánh giá nhu cầu giới thiệu các giai đoạn trong một sản phẩm cụ thể, phân định các lĩnh vực trách nhiệm, thỏa thuận hợp đồng ở đầu vào và đầu ra của các giai đoạn và đánh giá chính xác hơn nhu cầu về nguồn lực.
Trong các bài viết sau, chúng tôi sẽ mô tả chi tiết hơn những công cụ kỹ thuật nào được sử dụng để thực hiện các giai đoạn công nghệ nhất định trên bản đồ của chúng tôi.
Tác giả bài viết:
- — Trưởng bộ phận Tự động hóa (DevOps) tại Positive Technologies
- - Phó Trưởng phòng Tự động hóa (DevOps) tại Positive Technologies
Nguồn: www.habr.com