Các cuộc họp do triển khai chậm (2015)
(tidyfirst.substack.com)- Trong tình huống kỹ sư cảm thấy “không thể đưa code ra vì họp hành”, nguyên nhân thực sự có thể là overhead tổ chức do năng lực triển khai chậm tạo ra
- Chuck Rossi của Facebook cho rằng số lượng thay đổi mà một lần triển khai có thể gánh gần như là cố định; muốn tăng khối lượng thay đổi thì phải tăng số lần triển khai
- Facebook đã tăng tần suất triển khai mã PHP từ hằng tuần lên hằng ngày, rồi 3 lần mỗi ngày; chu kỳ triển khai ứng dụng di động cũng giảm từ 6 tuần xuống 4 tuần, rồi 2 tuần, và việc này chủ yếu do đội release engineering dẫn dắt
- Khi sản lượng thay đổi vượt quá giới hạn triển khai, số thay đổi trên mỗi lần triển khai không dễ tăng lên; thay vào đó overhead như họp, review, handoff tăng lên, và tổ chức thích nghi theo hướng làm giảm tổng khối lượng thay đổi
- Để đưa được nhiều thay đổi hơn đi qua, không chỉ giảm họp mà còn phải cải thiện chu kỳ triển khai, kiểm thử, giám sát, cách ly và quan hệ xã hội trong nhóm để tăng dung lượng triển khai
Họp có thể là kết quả, không phải nguyên nhân
- Lời phàn nàn phổ biến “vì họp quá nhiều nên không thể triển khai code” có thể đã đảo ngược quan hệ nhân quả
- Việc thêm hoặc bớt overhead tổ chức tương đối dễ, nhưng tăng năng lực triển khai code của tổ chức thì khó hơn
- Các cuộc họp và review có thể là kết quả của việc tổ chức thích nghi để hệ thống triển khai không bị quá tải
- Chuck Rossi quan sát tại Facebook rằng số thay đổi mà một lần triển khai có thể xử lý dường như là một con số cố định
- Nếu muốn nhiều thay đổi hơn thì cần nhiều lần triển khai hơn
- Triển khai mã PHP tăng từ hằng tuần lên hằng ngày, rồi 3 lần mỗi ngày
- Chu kỳ triển khai ứng dụng di động giảm từ 6 tuần xuống 4 tuần, rồi 2 tuần
- Cải tiến này chủ yếu do đội release engineering thúc đẩy
Nếu không tăng dung lượng triển khai, overhead sẽ phình ra
- “Số thay đổi trên mỗi lần triển khai” dường như là một chỉ số kém co giãn, không dễ tăng và chỉ cải thiện được khi có nỗ lực lớn
- Khi số thay đổi được tạo ra vượt quá giới hạn hiện tại, sẽ xuất hiện áp lực làm giảm tổng khối lượng thay đổi thay vì tăng số thay đổi trên mỗi lần triển khai
- Họp, review, handoff và các overhead khác tăng lên
- Theo thời gian, nhiệt huyết và tinh thần chủ động cũng có thể giảm
- Overhead tăng có thể tạo ra vòng phản hồi dương
- Ít việc được xử lý hơn
- Áp lực tăng lên
- Sai sót nhiều hơn
- Số thay đổi trên mỗi lần triển khai còn giảm nữa
- Overhead lại tăng
- Những nỗ lực cô lập chỉ nhằm giảm overhead có thể làm tăng áp lực và khiến overhead lại phình ra
- Để đưa được nhiều thay đổi hơn đi qua, cần mở rộng dung lượng triển khai ở “đầu xa của ống”
- Cách khó: rút ngắn chu kỳ triển khai và xử lý sự hỗn loạn kéo theo
- Cách khó hơn: tăng số thay đổi trên mỗi lần triển khai bằng kiểm thử tốt hơn, giám sát tốt hơn, cách ly tốt hơn giữa các thành phần và quan hệ xã hội tốt hơn trong nhóm
- Chỉ cố gắng giảm họp có thể dẫn đến “cuộc họp để bàn cách giảm họp”
- Có thể xem đây là một ví dụ về Thinkie nhân quả ngược, trong đó đặt ra một ý tưởng ban đầu trông có vẻ sai
2 bình luận
Ý kiến này thật hay
Các ý kiến trên Hacker News
Đáng tiếc là kết luận của bài viết này có vẻ hơi ngược. Việc cải thiện kiểm thử và các thuộc tính tổ chức để giảm rủi ro triển khai là quan trọng, nhưng không phải cách tiếp cận duy nhất có hiệu quả
Tác giả nói rằng số thay đổi trên mỗi lần triển khai là cố định và khó tăng lên, nhưng tôi cho rằng “Reversie Thinkie” ở đây thực ra là giảm số thay đổi trên mỗi lần triển khai. Lý do tồn tại các cuộc họp triển khai là rủi ro, và càng có nhiều thay đổi trong một lần triển khai thì khả năng đưa lỗi hoặc sự cố vận hành vào càng lớn. Nếu triển khai các thay đổi nhỏ một cách thường xuyên, ta có thể chuyển giao giá trị nhanh hơn và khiến thất bại nhỏ hơn
Nếu kết hợp thêm triển khai canary và phát hành dần dần, triển khai không còn là chuyện bật công tắc rồi hệ thống hỏng hay không hỏng, mà trở thành một thế giới nơi sự cố được biến thành suy giảm hiệu năng hoặc tác động có giới hạn. Cách tiếp cận này cũng được đề cập rất tốt trong nghiên cứu DORA[0], Accelerate[1], The Phoenix Project[2], và tiền thân tinh thần của nó là The Goal[3]
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
Cốt lõi là tổ chức đầu tư bao nhiêu thời gian và nguồn lực vào kiểm thử tự động. Các cuộc họp phát hành xuất hiện vì không có hạ tầng để xác minh trước/sau triển khai và không có hạ tầng để rollback các thay đổi thất bại, rồi sự thiếu hụt xác minh tự động được bù bằng các kiểm tra thủ công tạm thời. Nếu tổ chức QA thiếu năng lực kỹ thuật, họ sẽ thúc đẩy quy trình thủ công để tự bảo toàn
Tệ hơn nữa, việc phải đi qua những cuộc họp kiểu này đôi khi còn được đóng gói như một dấu hiệu của sự xuất sắc và best practice. Bởi người được thuê để giảm nhẹ vấn đề không có động lực để loại bỏ tận gốc vấn đề đó. Nếu lỗi lọt ra môi trường vận hành, nó trở thành “vấn đề do lập trình viên tạo ra mà QA không bắt được vì lý do này lý do kia”, nhưng nếu có kiểm thử tự động thì ngay cả việc bỏ sót ở bước PR cũng đã khó
Cuộc họp không sinh ra vì rủi ro; chúng sinh ra vì trong tổ chức có những vai trò cần rủi ro để có lý do tồn tại, trong khi lại thiếu kỹ thuật để giảm rủi ro đó. Nếu có thể tự động hóa các kiểm tra tối thiểu sau triển khai rằng thay đổi đã được chạy và hoạt động, đồng thời tự động rollback khi thất bại, thì cuộc họp sẽ không còn cần thiết
Tôi xem phần lớn những quy trình này là phản ứng hợp lý nhưng phi kỹ thuật để chịu đựng một tình huống tệ nhất có thể khi chưa có giải pháp căn cơ. Tuy vậy, chúng không hoàn toàn vô hại. Ở một số tổ chức, ngay cả với dự án mới hoặc dự án loại bỏ bất cập hiện có, người ra quyết định vẫn liên tục đưa quy trình lấy con người làm trung tâm ra làm giải pháp
Đó là vì thiếu trí tưởng tượng kỹ thuật hoặc bị mắc kẹt trong khung vấn đề hiện có, nên những người có trí tưởng tượng như vậy cần đứng ra nói rằng ở những nơi có thể, phải dùng thay đổi kỹ thuật để tối thiểu hóa quy trình con người. Không thể loại bỏ mọi quy trình con người bằng công nghệ, nhưng tôi không muốn bị dàn mỏng vào những thứ không cần thiết
Có thể ước tính rằng việc thay đổi hơn 2% toàn bộ quy trình trong một giai đoạn nào đó là “quá nhiều”, và giá trị này có thể điều chỉnh. Nó cũng sẽ khác nhau theo từng lĩnh vực, nên nhóm mã xử lý thanh toán và nhóm mã HR cần có các tiêu chuẩn khác nhau, và việc luân phiên phát hành hoặc luân phiên đội ngũ có thể là hợp lý
Kiểu như giai đoạn này đội này làm việc khó, rồi khi đã live thì lại chuyển họ về việc dễ hơn. Nguyên lý tương tự cũng áp dụng cho tấn công chiến hào, tiến quân cấp tiểu đoàn, và tác chiến hiệp đồng binh chủng
Tất nhiên đây là vấn đề quản lý, nhưng phần lớn có thể tự động hóa, và các tín hiệu đầu vào kiểu đội nào gần đây đã commit vào module nhạy cảm cũng hữu ích. Cuối cùng, góc nhìn này khiến sprint trong Agile/Scrum trở nên kỳ lạ. Ta biết không thể chạy nước rút hết cả một cuộc marathon, vậy phải chuẩn bị luân phiên các sprint như thế nào
Có thể dùng feature flag, nhưng như vậy sẽ tạo ra một “backlog các tính năng chưa được bật”. Cuối cùng thì tính năng thường được con người sử dụng, và con người cần được đào tạo về thay đổi
Ông ấy đã xử lý vấn đề flow, diễn giải các nguyên tắc của Toyota Production System, và áp dụng vật lý vào quy trình kinh doanh từ rất lâu trước khi ai đó viết The Phoenix Project. Tôi cũng thích The Phoenix Project, nhưng so với The Goal thì nó gần như chỉ là một bản phóng tác rẻ tiền để khiến dân IT khi đọc chuyện dây chuyền sản xuất không bỏ chạy với câu “tôi là PrOgrAmmEr nên công việc sáng tạo không thể tối ưu hóa như nhà máy được”
Vì vậy The Phoenix Project là hậu duệ tinh thần của The Goal, chứ không phải ngược lại
Đang cố giải thích khái niệm “khả năng đọc hiểu phần mềm”. Ý là cũng như ngày nay một công ty có thể vận hành bằng các câu tiếng Anh như tài liệu chính sách và email, doanh nghiệp cũng có thể được vận hành bằng code
Từ đó mới đi đến những kết luận kiểu “nếu GPU làm việc thì coder là nhà quản lý mới”, hoặc cần có bộ kiểm thử toàn công ty để tác động của thay đổi được rõ ràng. Có vẻ cũng liên quan trực tiếp đến bài viết rất hay này. Nếu mọi người ra quyết định không xem code, thay vì Jira hay kế hoạch dự án, là đối tượng hạng nhất trong quy trình thay đổi, thì nghĩa là họ không có khả năng đọc hiểu theo nghĩa phần mềm
Vấn đề “thảo luận với ban lãnh đạo phi kỹ thuật thế nào” thường xuất hiện, nhưng câu trả lời là không thể. Ban lãnh đạo đó phải thay đổi. Đây là một rào cản thế hệ khổng lồ mà 30 năm trước tôi đã nghĩ là vấn đề, nhưng từng ngây thơ cho rằng nó sẽ biến mất khi các coder trưởng thành. Nhưng vì không cần biết code để “vận hành” công ty, nên rất khó vượt qua cho đến khi việc không biết code trở thành điều đáng xấu hổ, giống như một tổng biên tập báo mà không biết viết
Cốt lõi không phải là SOP, kiểm thử hay họp hành, mà là cần những công ty có thể vận hành bằng một tập hợp khái niệm mới tự củng cố lẫn nhau, chẳng hạn hệ thống như một hình thức giao tiếp
Tuy vậy tôi không rõ vì sao lại gọi là “khả năng đọc hiểu”. Thuật ngữ autopoiesis của Maturana & Varela có vẻ gần với trọng tâm hơn, và Autopoietic Systems của Stafford Beer cũng có thể cung cấp nền tảng tri thức tốt
Nhưng đến một lúc nào đó, chẳng phải “doanh nghiệp” thuần phần mềm trông cũng giống SaaS thôi sao
Tổ chức sẽ chủ động ngăn cản các nỗ lực cải thiện triển khai. Họ nói với vẻ mặt nghiêm túc những câu như “không được để Jenkins gần môi trường production”, “không thể đưa live nếu không có QA”, “cần từng này thời gian để bảo đảm đủ chất lượng phần mềm”
Trong khi đó lỗi vận hành thì hàng triệu, còn sản phẩm hầu như không đáp ứng được yêu cầu người dùng. Rốt cuộc, trong hầu hết tổ chức, chiến đấu với quan liêu gần như là bất khả thi. Đặc biệt nếu bạn không thuộc 200 tầng quản lý tạo ra những cuộc họp kiểu này
Tôi muốn cho tất cả ra đi, chỉ giữ lại khoảng hai lập trình viên và designer, rồi để họ tự chiến đấu, không agile coach, product owner, scrum master hay product expert. Triển khai chậm là một vấn đề, nhưng không phải là bản thân vấn đề
Nếu bạn cứ liên tục rơi vào những nơi có vẻ không thể thay đổi, thì nên hỏi kỹ hơn phần này khi phỏng vấn. Ở các công ty nhỏ, tôi từng gặp nhiều nơi không có kiểu quan liêu điên rồ như mình không thích; còn hiện tại tôi ở một công ty lớn, nhưng nếu hành động nhất quán và thuyết phục thì nhiều thứ cũng chậm rãi đi đúng hướng
Cần hiểu rằng mọi việc mất thời gian, hiểu vì sao người ta đã tạo ra nó như vậy, rồi tìm lập luận thuyết phục để làm nó tốt hơn. Cũng có những nơi thật sự tệ, và đúng là không nên ở lại đó, nhưng tuyệt vọng thì không giúp được gì nhiều
Sẽ có rất nhiều thứ cần gỡ rối, nhưng thiên kiến của tôi nghiêng về lập luận này
Jenkins là Wordpress của giới phát triển phần mềm. Nó là một vòng lặp trạng thái khổng lồ chạy plugin mà không tách quyền. Cấp thông tin xác thực quản trị production cho một instance Jenkins có thể chẳng khác nào trao khóa root cho một người nào đó ở Romania đã viết một plugin chưa từng được audit. Việc mọi người có thể không muốn điều đó là hoàn toàn dễ hiểu
“Không thể đưa live nếu không có QA” cũng vậy. Nếu bạn triển khai lên production thứ chưa từng qua QA, vậy QA tồn tại để làm gì? Để sửa sau à? Nếu không trao quyền, QA sẽ không có cơ hội làm tốt công việc, cũng không có cơ hội tự hào về việc của mình
Với bất kỳ sáng kiến nào, ngay từ ngày đầu Jenkins đã nối tới production, thường là đi thẳng theo phát triển dựa trên trunk, và chất lượng là trách nhiệm của mọi developer. Ở cấp cá nhân đóng góp thì không có chuyện “chiến đấu với quan liêu”, nhưng khi đối tác bên ngoài và các bên liên quan dính dáng sâu, giữa các lãnh đạo đôi khi hẳn đã có những cuộc thảo luận gay gắt
Cách chỉ giữ lại lập trình viên và designer thì tôi thích, nhưng không mở rộng được. Cần có ít nhất một “owner”, “chuyên gia”, “manager” sản phẩm để xếp hàng ưu tiên của các bên liên quan. Vai trò này có thể là một “chiếc mũ” mà developer và designer thay phiên đội, nhưng có người đặc biệt giỏi kỹ năng này
Tôi cũng hiểu rằng nhiều tổ chức không vận hành như vậy. Khi thay đổi công ty theo hướng này, cách hữu ích từng là lập một nhóm thử nghiệm đơn lẻ dựa trên tình nguyện viên, tận tâm với các thực hành này, được quyền lực từ cấp trên bảo vệ nhưng không chỉ đạo. Tất nhiên đây là California
Chuyện hơi liên quan: tôi từng làm ở một nơi mà pipeline CI mất khoảng 25 phút, trong đó hơn 3000 bài test đơn vị/tích hợp ngốn 18 phút
Mỗi khi production có vấn đề, họ lại thêm test, và dĩ nhiên khi mọi thứ rối lên thì cần ít nhất 50 phút để khôi phục. Sau nhiều suy nghĩ, chúng tôi quyết định tập trung vào khôi phục, nới lỏng và đơn giản hóa một số test để đưa toàn bộ xuống dưới 5 phút, rồi dùng canary deployment thay vì rolling update
Với chúng tôi đó là một trải nghiệm thật sự mới mẻ, nhưng ở một khía cạnh nào đó cũng có cảm giác như là sai sai
Tất nhiên trong tốc độ triển khai đó có đủ thứ bị cuốn vào, nhưng gần như phần lớn đều là những yếu tố tốt
Hơi lạc đề một chút, nhưng vì sao CloudFormation lại chậm đến vậy?
Có trường hợp xóa một Lambda trong VPC và được kết nối với EFS; bản thân việc triển khai khá nhanh, nhưng CloudFormation mất khoảng 20 phút để dọn dẹp và kết thúc
Mỗi lần triển khai thay đổi trạng thái như một transaction, ở từng bước phải kiểm tra tiền điều kiện và hậu điều kiện. Để phát hành một nhóm thay đổi có dù chỉ chút phụ thuộc lẫn nhau, không còn cách nào khác ngoài triển khai từng thay đổi theo các bước tuần tự. Mỗi bước thực hiện nhiều network call để áp dụng thay đổi, xác thực và polling trạng thái; mỗi call mất khoảng 50–200ms và cộng dồn rất nhanh
Triển khai cùng một ứng dụng lên nhà cung cấp cloud khác bằng Terraform hoặc Ansible cũng cho kết quả tương tự. Nếu triển khai thủ công cùng thay đổi đó, việc đáng ra mất vài phút sẽ thành cực hình kéo dài cả ngày
Vấn đề lớn nhất của IaC là nó ở mức trừu tượng quá cao và làm quá nhiều việc bên trong, khiến có người không biết thay đổi nào thực sự được áp dụng hay nó đang làm gì. Rồi họ lại phàn nàn rằng nó mất nhiều thời gian
Tôi từng trải qua chuyện này trong công việc. Trước kỳ nghỉ Giáng sinh có một thay đổi lớn và mọi người rất lo sợ. Tổ chức phản ứng bằng cách tăng thêm test, tức tăng regression test và làm overhead lớn hơn
Điều này làm tăng rủi ro rằng thay đổi ở dev sẽ phá vỡ thay đổi trong branch của tôi. Không phải rủi ro conflict khi merge code, mà là rủi ro theo nghĩa một hệ thống thích nghi phức tạp. Để đối phó với rủi ro này, tôi tạo ra các cuộc họp, và khi công bố lịch dự án, tôi giải thích kỳ vọng với đồng nghiệp rằng nếu họ để lại comment về code style trong PR thì nó sẽ bị đẩy sang PR sau và cuối cùng sẽ bị bỏ qua
Thứ cần thiết là các bài test chi tiết hơn với mức cô lập tốt hơn giữa các component. Vấn đề là ban quản lý nhìn mọi thứ ở mức quá cao, và xem cuộc họp không phải là phương tiện mà là một mục tiêu có giá trị tự thân cần đạt được. Nhiều cuộc họp thì nghĩa là nhiều cộng tác, và như thế là tốt. Tôi muốn thấy lời khuyên về cách dẫn dắt thay đổi kỹ thuật cùng với ban quản lý không có nền tảng kỹ thuật
Bài liên quan: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - tháng 11/2015, 26 bình luận
Dùng microservice thì cũng có thể scale ngang tần suất triển khai
Với một ứng dụng monolithic gồm các module độc lập, bạn vẫn có thể triển khai nhiều không kém mà không cần microservice, đồng thời tránh được các nhược điểm lớn như độ phức tạp infrastructure/CI·CD hay việc biến các lời gọi hàm trong ứng dụng thành vấn đề giao tiếp hệ thống phân tán không ổn định. Cần chống lại độ phức tạp phụ trợ không cần thiết
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
Và bạn có thêm vấn đề mới thú vị: lập kế hoạch triển khai và đồng bộ hóa phát hành tính năng
Nếu không, bạn sẽ có đồng thời vấn đề dữ liệu phân tán và nhiều tầng phức tạp hơn, tức là nhiều cuộc họp hơn cả monolith
Trong monolith, có rủi ro rơi vào một mớ hỗn độn khổng lồ của SOLID, DRY và các thứ nhảm kiểu “clean code”, nơi không ai dám thay đổi gì vì sợ làm vỡ. Không phải bản thân các nguyên tắc hướng đối tượng bề ngoài là sai, nhưng chúng thường quá mơ hồ đến mức hầu như không ai áp dụng đúng được
Tôi luôn thấy buồn cười khi Uncle Bob mỗi lần bị chỉ trích lại gạt đi rằng “họ đã hiểu sai nguyên tắc”. Nếu nhiều người sai đến vậy, chẳng phải cũng có thể là nguyên tắc đó tệ sao? Microservice cũng không bảo vệ bạn khỏi governance kém; nó chỉ bộc lộ vấn đề dưới một hình thức khác. Việc tạo ra nhiều microservice rồi không ai biết một thay đổi sẽ ảnh hưởng thế nào đến service khác là điều rất dễ và tôi nghĩ khá phổ biến
Cuối cùng đây là vấn đề quản lý team, và theo kinh nghiệm thì đó là lĩnh vực ngành của chúng ta kém nhất. Có thể sẽ khá hơn khi thế hệ mới như “Team Topologies” đi vào thực tế, nhưng ngay cả khi thật sự kết thúc thì cũng phải mất hàng chục năm. Nếu tổ chức chỉ xem “IT” là trung tâm chi phí và không đặt yêu cầu theo cách có thể được đưa vào các quy trình best practice của công nghệ phần mềm, chuyện này thường vượt ra khỏi tầm tay của bộ phận số hóa
Một trong những lý do tôi thích Go như một ngôn ngữ đa dụng là vì nó đơn giản theo thiết kế, nên thường dẫn đến codebase dễ thay đổi. Tôi từng thấy vài ngân hàng trực tuyến và nền tảng quản lý thuê/bất động sản chuyển sang Go rồi tăng trưởng vì cuối cùng họ có thể thực sự giao được thứ doanh nghiệp cần. Trong khi đó, đối thủ bị mắc kẹt trong các codebase Java hoặc C# khó xử lý; may mắn lắm thì nửa năm ra được một tính năng đầy lỗi
Đây không phải vấn đề của bản thân Go, Java hay C#, mà là vì kiến trúc và thiết kế hướng đối tượng kiểu cũ quá dễ làm hỏng. Ở một nơi tôi từng làm, có hơn một nghìn interface C#, nhưng không interface nào được consume bởi từ hai class trở lên. Hàng chục nghìn interface đều nằm trong cùng một folder và namespace, và muốn tìm thứ cần thì chỉ biết cầu may. Bạn có thể làm như vậy bằng Go hay bất kỳ ngôn ngữ nào, nhưng nếu không ở trong văn hóa ngôn ngữ hướng đối tượng clean code cũ kỹ thì khả năng đó thấp hơn. Đặc biệt với C#, abstraction mặc định đã ăn quá sâu vào văn hóa đến mức không làm vậy còn khó hơn
Cá nhân tôi có một tình cảm bí mật với các tổ chức dùng Python. Họ luôn giao nhanh và code thì kinh khủng. Thật đáng yêu
Nhìn chung là đúng, nhưng cũng vì thế mà khá không liên quan
Tóm lại, chỉ hiệu năng phần mềm, và do đó là hiệu năng của con người, mới quan trọng. Quản lý rủi ro và chấp nhận rủi ro có thể đo bằng con số. Trong phần mềm, việc này đơn giản hơn nhiều so với các nghề khác, vì kỹ sư phần mềm chỉ có thể chấp nhận rủi ro trong các ràng buộc vận hành đã biết, còn mọi thứ khác đều bị hoãn lại
Nếu muốn nhanh hơn, trước hết phải tối đa hóa tần suất lặp của con người. Nếu bạn không thể lặp vì phải chờ quyền phê duyệt thì bạn đang bị chặn; nếu bạn phải chờ build hoặc chờ màn hình refresh thì bạn đang bị chậm lại. Điều này cũng có thể đo bằng con số
Nếu A có thể lặp nhanh hơn B 100 lần, độ chính xác trở thành thứ yếu. Vì B chậm nên phải tối đa hóa độ chính xác. A có sự linh hoạt cực lớn để học, thất bại và cải thiện nhằm trở nên vừa nhanh hơn vừa chính xác hơn
Một phần của việc lặp nhanh hơn đồng thời giảm rủi ro là tự động hóa kiểm thử nhanh. Nếu A có thể chạy hơn 90% test coverage trong thời gian 4 vòng lặp của con người, thì tự động hóa kiểm thử đó vẫn nhanh hơn 25 lần so với một vòng lặp của B, và rủi ro regression thấp hơn hơn 90%
Triển khai nhanh tạo ra war room ứng phó sự cố
Điều còn quan trọng hơn nhiều so với mức giảm đó là khi có vấn đề, tốc độ tìm ra nguyên nhân nhanh hơn hẳn. Vì số thay đổi bị rollback rất ít nên việc revert cũng an toàn và dễ dàng hơn nhiều. Không ai muốn revert lượng công việc của 3 tuần. Đó là hỗn loạn