Làm cách nào để bán một khoản nợ kỹ thuật từ góc độ DevOps?

Người ta thường lập luận một cách kịch liệt và thảm hại rằng tốt hơn hết là không nên tạo ra nợ kỹ thuật. Vâng, tất nhiên là tốt hơn nếu không có nó. Nhưng hậu quả vẫn có thể được loại bỏ. Tôi gọi nợ kỹ thuật là tất cả các thay đổi và cải tiến, sửa đổi cơ sở hạ tầng và thay đổi quy trình, thay đổi trong cơ cấu nhóm nhằm loại bỏ các khoảng trống (được thực hiện một cách có ý thức hoặc không trong khuôn khổ ra mắt sản phẩm) và các tính năng gây trở ngại lớn theo thời gian. Và vì những điều đó không thể được khắc phục nếu không có sự hợp tác chắc chắn và tự tin của các bộ phận sản xuất và vận hành nên câu chuyện này trực tiếp nói về DevOps. Nợ kỹ thuật - Của ai? Nhưng trước tiên, gốc rễ của vấn đề - tại sao tôi lại nói về nợ kỹ thuật? Bởi vì tôi rất khó chịu khi doanh nghiệp không phân bổ thời gian cho việc đó. Sợi chỉ màu đỏ này xuyên suốt tất cả các báo cáo, cuộc gặp mặt và thông tin liên lạc giữa các nhà phát triển và hoạt động. Làm ăn tệ, dở, dở không phân bổ thời gian để làm việc với nợ kỹ thuật. Ngay cả một câu hỏi chính đáng cũng được đặt ra: "Họ không cần chất lượng chút nào sao?" Nhìn về phía trước, tôi sẽ nói: “Không ai cần chất lượng”. Nhưng tôi sẽ tiết lộ suy nghĩ này sau. Để phân tích tình huống này, hãy xem xét lý do tại sao doanh nghiệp lại làm điều này với chúng ta. Và để có câu trả lời, chúng ta cần nghĩ xem nợ kỹ thuật là của ai. Ai chịu trách nhiệm về nó? Sau nhiều năm tham gia, tôi nhận ra rằng chúng tôi giống như Frodo, người đã tặng mọi người một chiếc nhẫn. Nó giống như "Hãy giúp tôi mang gánh nặng này!" Chúng tôi đang chờ đợi các doanh nghiệp muốn (chính xác là muốn) chúng tôi giải quyết nợ kỹ thuật. Nhưng nguyên nhân sâu xa của sự hiểu lầm lẫn nhau của chúng ta với doanh nghiệp là nó sẽ không bao giờ muốn như vậy. Đối với chúng tôi, đó là một thách thức về mặt kỹ thuật, một cách để cải thiện sự xuất sắc của sản phẩm hoặc thậm chí là một cơ chế để tăng niềm tự hào về sản phẩm của chúng tôi. Nhưng đối với công việc kinh doanh, nó luôn là một mối phiền toái, một điều xấu xa (hoặc cần thiết) cần thiết mà bạn phải dành thời gian cho nó. Hãy tưởng tượng bạn lên một chiếc taxi và người tài xế hỏi: "Tôi có thể dừng ở tiệm rửa xe được không?" Doanh nghiệp trong tình huống này là khách hàng và nhà phát triển là tài xế taxi. Doanh nghiệp phẫn nộ: "Sao thế?! Tôi trả tiền thời gian đi lại, còn anh thì đi rửa xe!" Người tài xế taxi trả lời một cách hợp lý: "Bạn không muốn đi trên một chiếc xe sạch sẽ và thơm tho sao?" Người kinh doanh trả lời: "Ồ, tất nhiên rồi! Nhưng tôi đã mặc định mong đợi điều đó và tôi chưa sẵn sàng dừng lại ở tiệm rửa xe chỉ vì điều đó!" Đây là cách doanh nghiệp xử lý nợ kỹ thuật. Nó giống như một gợi ý nên ghé qua tiệm rửa xe. Tôi chọn danh mục phù hợp khi đặt taxi để có một salon sạch sẽ hoặc sang trọng. Ở khâu đặt hàng, tôi sẵn sàng đầu tư nhưng dừng lại ở tiệm rửa xe thì không. Bởi vì, như tôi đã nói trước đó, không ai muốn chất lượng. Nhưng nó được mong đợi theo mặc định. Đó là điều bắt buộc. Các doanh nghiệp không thể cam chịu không đến tiệm rửa xe, và các doanh nghiệp không thể đến đó để lãng phí thời gian của mình. Vậy ta phải làm sao? Một doanh nghiệp là một đầu máy xe lửa. Nó cần các tính năng, doanh số bán hàng và khách hàng. Không thể bán khoản nợ kỹ thuật cho một doanh nghiệp thông qua "Tôi muốn" và "Tôi ước". Nhưng có thể thúc đẩy kinh doanh theo cách khác. Trong quá trình hành trình của mình, tôi đã hình thành 3 loại động lực kinh doanh để “mua” nợ kỹ thuật: Sự thờ ơ "béo". Khi có một nhà đầu tư giàu có, CEO có đủ khả năng chi trả cho đội ngũ phát triển gồm những người lập dị kỳ quặc. Nó giống như, "Chà, hãy để họ làm điều đó! Điều quan trọng là hoàn thành sản phẩm và tinh thần đồng đội thật tuyệt vời, mọi thứ đều tuyệt vời và chúng tôi sẽ là văn phòng tốt nhất trên thế giới". Theo quan điểm của tôi, đó là một phong cách tự do tuyệt vời thường dẫn đến thảm họa vì nợ kỹ thuật đòi hỏi tính thực dụng. Khi chúng tôi không làm điều đó một cách thực tế, chúng tôi sẽ tạo ra một Leviathan với kiến trúc giả tạo. Nỗi sợ. Đây là một trong những mô hình hiệu quả, phổ biến và hiệu quả nhất đối với nợ kỹ thuật. Chúng ta có thể nói về loại "mong muốn" nào ở đây khi nó đáng sợ? Đó là khi có điều gì đó xảy ra như một khách hàng bỏ đi vì lỗi hoặc bị hack. Và tất cả là do chất lượng kém, phanh hoặc nguyên nhân khác. Nhưng bán thẳng thừng vì sợ hãi cũng là điều không tốt. Suy đoán với nỗi sợ hãi có tác dụng chống lại sự tin tưởng. Bạn cần bán hàng cẩn thận và trung thực nhất có thể. Lòng tin. Đó là khi doanh nghiệp cho bạn nhiều thời gian mà bạn cần để giải quyết nợ kỹ thuật. Niềm tin chỉ có tác dụng và được bảo tồn khi bạn cẩn thận chia nhỏ trong tổng số phần chia sẻ và thực dụng nhất có thể trong việc dành thời gian này. Nếu không, niềm tin sẽ bị phá hủy. Hơn nữa, nó không tích lũy. Một quá trình liên tục diễn ra theo từng đợt: niềm tin tăng lên rồi phai nhạt. Tiếp theo, tôi sẽ thảo luận về trải nghiệm của mình và những gì đang mang lại hiệu quả cho tôi cũng như đội ngũ tuyệt vời của tôi. Lỗ thỏ với khoản nợ kỹ thuật sâu đến mức nào? Khi gia nhập công ty mới cách đây 3 năm, tôi cần hiểu khoản nợ kỹ thuật này là bao nhiêu. Tôi biết nó tồn tại từ việc thống kê các yêu cầu, trong đó có yêu cầu từ doanh nghiệp, đối tác. Nói chung, tôi cần phải tìm ra những gì tôi đang giải quyết. Đây là bước đầu tiên bình thường và bắt buộc khi xử lý nợ kỹ thuật. Bạn không nên vội vàng làm điều đầu tiên bạn tìm thấy. Bạn nên phân tích tình hình một cách tổng thể. Dựa trên những gì tôi thấy lúc đó, tôi đã giả định rằng một trong những vấn đề cốt lõi là do sự ghép mã lớn. Bây giờ, tôi ít lôi kéo mọi người tham gia vào quá trình này hơn, nhưng trước đó, tôi đã tập hợp toàn bộ nhóm sản xuất để sửa những lớp mà chúng tôi muốn nhấn mạnh trong bộ ứng dụng của mình. Ứng dụng của chúng tôi có ít nhất 80 thành phần khác nhau (bản phân phối, không phải bản cài đặt). Sau khi tìm hiểu được tình hình thì phải xử lý. Giai đoạn 1. Nhóm ảo Quá thông minh, tôi nảy ra ý tưởng giả vờ như mọi người đều có thời gian và thành lập một nhóm ảo xung quanh từng thành phần. Nó giống như, "Các bạn, ai sẽ đảm nhận thành phần nào? Hãy đưa ra đề xuất của bạn về cách cải thiện nó." Nhưng để luôn tập trung, tất cả chúng tôi cùng nhau xây dựng các tiêu chí để tối ưu hóa giai đoạn đầu tiên: Khớp nối lỏng lẻo Khả năng mở rộng hiệu quả về chi phí Dễ dàng kết nối các nhà phát triển mới (nguyên tắc đơn giản và rõ ràng: chính xác những gì có thể được thực hiện trong thành phần này và những gì không thể, cộng với việc tách biệt mã mà mọi người không thể "chạm vào") Khả năng sử dụng API bên ngoài khi cần thiết Khả năng tiếp cận của ngăn xếp công nghệ được đề xuất Tối ưu hóa QuickWin trong các giải pháp hiện tại Dễ dàng theo dõi và khắc phục sự cố Kiểm toán + nguyên tắc về độ tinh khiết của giấy phép Nguyên tắc phiên bản và lỗi thời Tất nhiên, đây không phải là trọng tâm mà là một bộ tiêu chí cho hầu hết các khía cạnh của phát triển phần mềm. Toàn bộ danh sách có thể được thay thế bằng một cụm từ: "Sửa mọi thứ". Giai đoạn này kết thúc trong thất bại, theo nghĩa đơn giản là không có gì xảy ra. Chúng tôi đạt được rất ít tiến triển trong việc triển khai một số việc vì tôi đang cố gắng lên kế hoạch cho chúng thông qua một hồ sơ tồn đọng được chia sẻ. Các nhiệm vụ thật khó hiểu. Họ được đưa vào làm việc một cách thủ công. Tôi nhanh chóng nhận ra rằng điều đó thật khó khăn cho cả tôi và cả nhóm, cộng thêm những mâu thuẫn, tranh cãi ngày càng gia tăng. Vì vậy, tôi chuyển sang giai đoạn 2. Giai đoạn 2. Nợ kỹ thuật là của tôi Trong giai đoạn 1, tôi đã đồng ý với Giám đốc điều hành của công ty chúng tôi rằng chúng tôi sẽ đưa ra hạn ngạch tồn đọng. Chúng tôi sẽ chi 70% cho các vấn đề kinh doanh, 15% cho việc loại bỏ lỗi và 15% cho khoản nợ kỹ thuật. Thứ hai, ở giai đoạn trước, tôi nhận ra rằng nếu mọi người đều chịu trách nhiệm về một vấn đề thì không ai chịu trách nhiệm về vấn đề đó. Đây hoàn toàn không phải là một tuyên bố màu ngọc lam. Bản thân tôi không thích nó. Nhưng ngược lại đòi hỏi sự trưởng thành và tinh thần đồng đội rất cao. Đó là lý do tôi quyết định hình thành hệ thống lãnh đạo kỹ thuật. Nhưng tôi không chỉ bổ nhiệm một người làm trưởng nhóm kỹ thuật của một bộ phận. Tôi đặt ra những kỳ vọng của mình nhiều nhất có thể, xác định lộ trình phát triển của họ và yêu cầu họ chịu trách nhiệm về tình hình sản xuất. Các chuyên gia OPS sẽ không tỉnh táo nếu thành phần của bạn gặp trục trặc trong quá trình sản xuất. Chính bạn là người đang cố gắng giải quyết tình huống này. Và thế là chúng tôi khởi hành. Có những người lãnh đạo kỹ thuật (những người phụ trách) và hạn mức 15% cho nợ kỹ thuật (có thời gian). Nhưng thực tế cuối cùng trông như thế nào? Điều đầu tiên chúng tôi gặp phải là chúng tôi có FinTech, tuân thủ và phân chia nhiệm vụ, tức là tôi và nhà phát triển không có quyền truy cập vào sản xuất và theo định nghĩa thì không thể có được nó. Chưa hết, tôi còn nói: "Các bạn, các bạn phải chịu trách nhiệm về tình hình sản xuất!" Cung cấp cho mọi người nhật ký! Khi bạn giao trách nhiệm cho mọi người, hãy trao cho họ một công cụ trong tay. Và đó là điều đầu tiên chúng tôi làm với các chuyên gia OPS, cung cấp nhật ký cho các kỹ thuật viên để họ có thể xem nhật ký các thành phần của họ. Và chúng tôi đã có nỗ lực hợp tác thực sự - bước đầu tiên của chúng tôi hướng tới DevOps, nơi các hoạt động và hoạt động phát triển cùng phối hợp với nhau. Khai thác thiết lập chuyển nhật ký (Kibana, v.v.), trong khi quá trình phát triển phải đảm bảo rằng nhật ký không chứa thông tin nhạy cảm (dữ liệu cá nhân, v.v.). 5% được coi là may mắn... Thực tế là dù hạn ngạch 15% nhưng vẫn có một số khủng hoảng kinh doanh và tiêm thuốc khẩn cấp trong mỗi lần chạy nước rút vì “Đối tác cần ngay, nếu không sẽ bỏ đi!” Tất nhiên, khoản nợ kỹ thuật này trước tiên được đẩy ra khỏi sprint - kết quả là chúng tôi đã có những sprint với 0%. Cũng có những lần chạy nước rút với 15%, nhưng trung bình chúng tôi chỉ có 5-8% nợ kỹ thuật. Đây là một vấn đề lớn vì người lập trình không thể biết mình sẽ có bao nhiêu thời gian để thực hiện. Về phần mình, tôi đã cố gắng giúp đỡ tình trạng này bằng cách không mệt mỏi thả diều cho tất cả các đội. Chúng tôi đã học cách thu thập số liệu chi tiết cho mỗi lần chạy nước rút và tôi đã xem xét lần chạy nước rút ở cuối. Tấn công Sprint là khi hạn mức nợ kỹ thuật bị vi phạm một cách có hệ thống. Nếu không đạt được hạn ngạch trong một lần chạy nước rút, điều đó không có nghĩa là mọi thứ đều tệ. Thật vậy, có những tình huống khác nhau và bạn cần phải linh hoạt. Nhưng khi nó lặp lại một cách có hệ thống, tôi đã tập hợp các chuyên gia sản xuất lại, tranh luận và giải thích tầm quan trọng của nó và không thể chấp nhận được vì hạn ngạch đã được thống nhất. Công việc hàng ngày của tôi là di chuyển quy trình trong mô hình đó. Và nó đã thay đổi, nhưng bây giờ tôi tin rằng cách tiếp cận này có những thiếu sót đáng kể. Hạn chế của phương pháp tiếp cận Chủ sở hữu sản phẩm đã quen với việc tồn đọng là của họ và mọi nhiệm vụ đều do họ điều phối: "Hạn ngạch là tốt, nhưng chỉ có chúng tôi mới quyết định nhóm sẽ làm gì trong hạn ngạch nợ kỹ thuật này!" Và khi các nhà phát triển đưa ra các nhiệm vụ (hãy nhớ về khả năng kết nối mạnh mẽ) như tái cấu trúc, loại bỏ các bản mẫu, v.v., họ nhận được phản ứng hợp lý: "Cái gì?! Bản mẫu nào? Chúng ta đang nói về cái gì vậy?!" Kết quả là, các nhiệm vụ được thay thế bằng những nhiệm vụ có thể được gọi là nợ kỹ thuật nhưng có điều kiện mang lại lợi ích cho nhà cung cấp. Chính vì vậy tôi đã phải tỏ ra cứng rắn và nói: “Nợ kỹ thuật là của tôi! Và tôi khẳng định nó sẽ được tính vào khoản nợ kỹ thuật của từng nhóm sản phẩm trong hạn mức nợ kỹ thuật cho mỗi sprint”. Đó là cách chúng tôi đã sống. Dù chúng tôi sống và làm việc bình thường nhưng sự ngờ vực ngày càng lớn. Khi chúng ta làm điều gì đó mà không nói cho ai biết đó là gì và không dành thời gian cho công việc kinh doanh thì mọi người không rõ chúng ta mang lại kết quả gì. Vì số liệu thống kê về việc sử dụng hạn mức nợ kỹ thuật đang tăng vọt, chúng tôi phải đối mặt với thực tế là chúng tôi không thể thực hiện các dự án lớn. Ngoài ra, các dự án lớn thường đòi hỏi nhiều đội. Điều này cũng là không thể vì mỗi nhóm sản phẩm đều tập trung vào sản phẩm của mình và sống theo thực tế của nó. Không thể gắn chúng vào một chủ đề phức tạp. Ngoài ra, không ai đưa các hoạt động vào các lần chạy nước rút. Họ không có các cuộc chạy nước rút và tồn đọng như sản xuất. Họ ngập trong các nhiệm vụ sản xuất, nhưng điều đó không có trong kế hoạch tổng thể. Và khi quá trình phát triển đi kèm với một việc gì đó được thực hiện trong phạm vi khoản nợ kỹ thuật nhỏ đó để đưa vào sản xuất, nó có thể nằm trong yêu cầu của OPS trong một thời gian khá dài. Bởi vì họ thực sự không có thời gian, phải gánh thêm nhiều nhiệm vụ và bị ngăn cản làm việc. Nhưng bất chấp những mặt tiêu cực của cách tiếp cận này, chúng tôi đã đạt được khá nhiều điều. Chúng tôi đã đạt được gì với phương pháp này? Đầu tiên, chúng tôi đã xây dựng được khối lượng cơ bắp cho các bài kiểm tra tự động. Bằng cách thiết kế lại toàn bộ quy trình CI một cách đáng kể, chúng tôi đã biến nó thành một quy trình văn minh mà chúng tôi không hề xấu hổ. Thứ hai, chúng tôi đã triển khai thành công cuộc chiến chống mã spaghetti ở nhiều thành phần. Chúng tôi đã thực hiện mô-đun hóa và giảm bớt các bản soạn sẵn. Những nhiệm vụ này không thể được bán cho doanh nghiệp ngay cả khi sợ hãi. Nếu lỗ hổng công nghệ trong sản phẩm của bạn chứa đựng những vấn đề này và bạn cần khắc phục chúng (nếu có thì chúng cần phải được thực hiện trước), bạn thậm chí không cần phải cố gắng bán chúng. Việc này chỉ có thể thực hiện được thông qua mô hình “Nợ kỹ thuật - là của tôi”, chỉ thông qua hạn ngạch. Tôi đã chứng kiến nhiều nỗ lực và cố gắng làm khác đi trong giai đoạn đầu. Nó không thành công. Quả thực, làm việc ở chế độ này không thể kéo dài được lâu. Đó là một quyền hạn có giới hạn mà ban quản lý trao cho bạn, tin tưởng bạn với tư cách là CTO và trưởng nhóm. Giai đoạn 3. Dự án hợp pháp Sau đó, chúng tôi bắt đầu giai đoạn 3 - một dự án "hợp pháp" để xử lý nợ kỹ thuật. Giả định là chúng tôi đang loại bỏ hạn ngạch đã đóng, lập kế hoạch thông qua tồn đọng sản phẩm chung (tức là chủ sở hữu sản phẩm chấp nhận rằng các dự án này cần phải được thực hiện) và tiến tới bán hàng sạch sẽ. Để thực hiện được điều này, chúng tôi đã làm 2 việc: Tôi đã thu hẹp càng nhiều càng tốt phạm vi công việc mà chúng tôi bắt đầu thực hiện trong khuôn khổ dự án này. Tôi đã hình thành những kỳ vọng cụ thể về những gì chúng tôi sẽ đấu tranh trong quá trình sản xuất. Đó là sự bác bỏ hoàn toàn chủ nghĩa lý tưởng vì nhiệm vụ của chúng tôi phải thực tế nhất có thể, dễ hiểu và hữu ích cho dịch vụ theo quan điểm kinh doanh. Một điểm quan trọng là chúng ta có ảo tưởng nhất định rằng chúng ta đang cố gắng tính toán giá trị kinh doanh của nợ kỹ thuật, mặc dù điều này hiếm khi thực hiện được. Và nếu vẫn tính được thì chúng ta gặp ác mộng vì nợ kỹ thuật! Giá trị dương có tác dụng tốt hơn cho doanh nghiệp so với giá trị âm. Nếu bạn nói: “Khách hàng này sẽ rời đi. Anh ta mang về rất nhiều tiền”, thì cho đến khi anh ta rời đi, điều đó sẽ không có tác dụng. Đó không phải là giá trị kinh doanh. Hơn nữa, văn hóa làm việc với rủi ro vẫn chưa cao nên có quan điểm: “Không lỗ cho đến khi họ rời đi”. Cũng không cần thiết phải thể hiện giá trị kinh doanh. Nơi nào bạn có thể hiển thị nó, nhưng bạn có thể hiển thị giá trị công nghệ, chỉ có điều nó phải được tính toán. Hướng dẫn cách bán nợ kỹ thuật Đây là toàn bộ quy trình làm việc của giai đoạn này để bán nợ kỹ thuật. Chọn một lĩnh vực trọng tâm (Chỉ một) Vì đây là cách bán hàng thông qua nỗi sợ hãi nên hãy chọn lĩnh vực thực sự ảnh hưởng đến hoạt động kinh doanh của bạn. Các lĩnh vực có thể khác nhau: tính khả dụng, tốc độ làm lại, độ an toàn của các thử nghiệm và thử nghiệm A/B cũng như chi phí làm lại. Có một số lượng lớn các lĩnh vực và chủ đề. Trong trường hợp của tôi, tôi đã chọn khả năng tiếp cận vì nó nằm trong tầm quan tâm của doanh nghiệp và có một số tác động đến dịch vụ của chúng tôi. Điều quan trọng là không nên dàn trải bản thân và chỉ chọn một chủ đề. Thực hiện phân tích tích phân Tôi đã phân tích số liệu thống kê về tính khả dụng và sự cố trong năm và phân tích chi tiết tất cả các kết quả khám nghiệm tử thi cho tất cả các tình huống xảy ra trong suốt cả năm. Sau đó, tôi đã hình thành sự hiểu biết cấp cao nhất về những gì chúng tôi cần phải nỗ lực nhiều nhất có thể về mặt kỹ thuật, nhưng một lần nữa - một cách thực chất. Nguyên tắc đầu tiên về tính sẵn sàng không phải là cố gắng xây dựng một hệ thống luôn sẵn sàng mà phải sẵn sàng khi có sự cố xảy ra. Đó là điều chúng tôi phải đảm bảo. Vấn đề thứ hai và quy tắc cơ bản về tính khả dụng là thỏa thuận xuống cấp: điều gì đó chắc chắn sẽ xảy ra vào một ngày nào đó và bạn phải sẵn sàng duy trì dịch vụ của mình, có thể phải trả giá bằng việc từ bỏ một số chức năng mà bạn cung cấp. Thỏa thuận này phải được duy trì, kể cả ở cấp độ chương trình. Vấn đề thứ ba liên quan đến việc giám sát và quan sát. Đây là việc bản địa hóa nhanh chóng các nguồn sự cố và thời gian phát hiện phản ứng. Nếu bạn có nhiều bài kiểm tra không ổn định, bạn sẽ phải ngừng tin tưởng vào việc giám sát của mình. Nếu quá trình kiểm tra sản xuất của bạn có hướng dẫn về các phản ứng của bộ phận dịch vụ như "Nếu nó không tắt sau 5 phút, hãy gọi cho tôi" - thì bạn đang không theo dõi tình hình sản xuất. Bài kiểm tra phải rõ ràng nhất có thể: "Nó hiển thị - nghĩa là có vấn đề ở đâu đó, đi thôi!" Thực hiện phân tích từng thành phần Vì mục đích này, chúng tôi đã hình thành chính xác những gì chúng tôi sẽ làm cho từng hướng và thành phần. Ý của chúng tôi là chúng tôi sẽ kéo lưới dịch vụ vào đâu, chúng tôi sẽ bắt đầu giám sát như thế nào và dựa trên điều gì. Ở đây, chúng tôi đã liệt kê khoảng 15%, nhưng trên thực tế, có rất nhiều cải tiến về chương trình. Chúng tôi đã trình bày tất cả nhưng nó vẫn chưa thể bán được trên thị trường. Để ra ngoài và thể hiện nó một cách công khai ngay bây giờ, chúng tôi đã thực hiện những việc sau cho từng dự án trong giai đoạn này. Xây dựng các chỉ số định lượng, nội dung Chúng tôi rất sợ các chỉ số định lượng: làm thế nào chúng tôi có thể đo lường chất lượng công việc của các nhà phát triển bằng các chỉ số định lượng? Chúng ta có rất nhiều lập luận chống lại các chỉ số định lượng, nhưng chúng ta không nên đối đầu trực tiếp với chúng. Giá trị không nên chỉ được coi là giá trị kinh doanh. Ví dụ: chúng có thể được diễn đạt là "không quá X kết quả dương tính giả". Bạn có thể liệt kê một tập hợp các thành phần cụ thể đóng vai trò quan trọng trong việc cung cấp các bản phát hành chính thức hoặc khả năng đảm bảo khôi phục bản vá được đảm bảo. Tất nhiên, tính sẵn có tổng thể phải là một chỉ số định lượng. Đó là điều bắt buộc. Bảo vệ các dự án Với tập hợp các dự án thực tế này, các số liệu và kết quả chúng tôi cần đạt được càng rõ ràng càng tốt, tôi nói: "Các bạn, tôi cần một hạn mức nợ kỹ thuật. Tôi cần các bạn đưa những dự án này vào nhóm của mình để đẩy nhanh chúng để chúng đi vào quy hoạch tổng thể trên cơ sở đầy đủ pháp lý gắn liền với mục tiêu kinh doanh.” Chúng tôi đã lắng nghe, chúng tôi đã làm và nó đã thành công. Tôi nghĩ nó giống như video hướng dẫn cách vẽ một con cú: "Vẽ một hình bầu dục và hai dấu gạch ngang". Cuối cùng - phép thuật - bạn sẽ có được một con cú! Nhưng điều kỳ diệu là bạn phải hoàn thành toàn bộ dự án này và hoàn thành nó đến cùng. Không chỉ làm một số việc theo hướng này mà còn mang lại kết quả. Đó là, để đạt được các chỉ số định lượng đã nêu và hiển thị chúng. Vực thẳm này không thể nhảy được 95% thời gian. Nó phải được nhảy hoàn toàn. Ưu điểm của phương pháp tiếp cận Vì vậy, chúng tôi bắt đầu nhảy (qua vực thẳm). Chúng tôi đang làm điều đó thành công. Bây giờ, chúng tôi đang ở vòng thứ hai của dự án này. Tức là chúng tôi đã kéo nhóm dự án đầu tiên và thống nhất về nhóm dự án thứ hai. Điều gì đã thay đổi? Tăng niềm tin Niềm tin sẽ tăng lên mạnh mẽ thông qua sự cởi mở nếu chúng tôi hiển thị các số liệu thực tế, có thể định lượng được. Nhưng sự thật là việc bán nợ kỹ thuật xuất phát từ nỗi sợ hãi. Bước này không thể tránh được. Nhưng bạn cũng không cần phải sợ hãi hay xấu hổ về điều đó. Điều chính không phải là suy đoán về nỗi sợ hãi mà là thực sự phân tích nó, như tôi đã chỉ ra trong các giai đoạn khác nhau (phân tích tích phân, phân tích từng thành phần). Thực hiện các dự án lớn Vì đây hiện là những dự án được hợp pháp hóa nên chúng tôi có thể đồng bộ hóa giữa các nhóm và thực hiện những dự án thực sự lớn. Một số dự án được thực hiện tuần tự từ sprint này đến sprint khác. Chúng tôi được theo dõi thường xuyên (mỗi tuần một lần) trong dự án đó bởi thành phần của nhóm công nghệ và hiểu ai đang ở đâu (trong giai đoạn nào). Thông tin này càng công khai và minh bạch càng tốt. Tiến độ của các dự án và trạng thái hiện tại được công bố và có sẵn cho chủ sở hữu sản phẩm (và bất kỳ ai khác muốn xem nó). OPS'ers trong dự án Quan trọng nhất, chúng tôi nhận ra rằng chúng tôi có rất nhiều thứ cần thiết kế lại cơ sở hạ tầng và quy trình triển khai. OPS'ers rõ ràng đã được đưa vào dự án này. Trong suy nghĩ của tôi, đây là DevOps nhiều hơn Kubernetes và Docker khi OPS thảo luận với các nhà phát triển về cách thay đổi kiến trúc của một thành phần và các nhà phát triển thảo luận với OPS về cách tốt nhất để thay đổi cơ sở hạ tầng. Tại sao tôi không làm điều đó ngay lập tức? Ở đây chúng ta quay lại điều tôi đã nói ở cuối giai đoạn 2: trước đây nó sẽ không hoạt động. Bởi vì những gì chúng tôi đã làm trong Giai đoạn 2 (mã spaghetti mà chúng tôi đã thiết kế lại, việc xây dựng các bài kiểm tra cơ bản và thiết kế lại các quy trình CI) sẽ không thể bán cho doanh nghiệp về các số liệu có thể đo lường được. Tình huống đó không liên quan đến bất kỳ nỗi sợ hãi cụ thể nào và lập luận tiêu chuẩn của chúng tôi là "Chúng tôi mất nhiều thời gian để viết mã vì mã spaghetti" - không ai trong doanh nghiệp lắng nghe. Vì vậy, chúng tôi sẽ không thể thực hiện được cách tiếp cận đó. Theo quan điểm của tôi, nếu bạn có một nền tảng công nghệ đòi hỏi phải làm lại cơ sở hạ tầng sâu sắc như vậy thì bạn không thể tránh khỏi giai đoạn 2. Bạn phải cố gắng, nhưng bạn phải sẵn sàng không chỉ bay lượn như diều mà còn phải đóng cửa cửa hàng này đủ nhanh để không làm mất lòng tin của doanh nghiệp.