Tại sao các dự án di chuyển phần mềm nhàm chán có thể là vũ khí bí mật của bạn

Khám phá quan điểm trái ngược này về cách đẩy nhanh hành trình trở thành nhà lãnh đạo/lập trình viên phần mềm dày dạn kinh nghiệm.

Trong 14 năm kinh nghiệm làm kỹ sư, tôi đã thấy nhiều người đưa ra quyết định nghề nghiệp dựa trên cơ hội làm việc trên một dịch vụ hoàn toàn mới. Không có gì sai với quyết định đó. Tuy nhiên, hôm nay chúng ta sẽ đưa ra một trường hợp mâu thuẫn là làm việc trên các dự án di chuyển nhàm chán. Điều mà tôi không nhận ra ngay từ đầu trong sự nghiệp của mình là hầu hết kiến thức phát triển phần mềm cơ bản của tôi đều đến từ các dự án là dự án di chuyển — ví dụ, di chuyển kho dữ liệu cơ bản sang một công nghệ đám mây khác hoặc loại bỏ một dịch vụ đơn khối để ủng hộ các dịch vụ vi mô mới, v.v.

Điều này là do việc di chuyển vốn đã khó khăn: bạn buộc phải đáp ứng, nếu không muốn nói là vượt quá, một rào cản hiện có về tính khả dụng, quy mô, độ trễ và trải nghiệm của khách hàng đã được nhiều kỹ sư xây dựng và hoàn thiện trong nhiều năm. Bạn sẽ không phải đối mặt với những hạn chế đó trên một hệ thống hoàn toàn mới vì bạn được tự do xác định chúng. Không chỉ vậy, bất kể bạn có kỹ lưỡng đến đâu với việc di chuyển, sẽ vẫn có những bộ xương ẩn trong tủ cần giải quyết khi bạn chuyển sang các phần mới của hệ thống (Hãy xem bài viết thú vị này về cách di chuyển Doordash từ Int sang BigInt cho một trường cơ sở dữ liệu gặp phải nhiều trở ngại).

Những dự án này buộc bạn phải suy nghĩ tỉ mỉ về phương pháp thử nghiệm, độ chính xác của kết quả từ các hệ thống mới, kế hoạch triển khai phần mềm, kế hoạch khôi phục phần mềm, v.v. để bạn không phải lúc nào cũng căng thẳng khi làm việc trên một hệ thống hoàn toàn mới vì không có khách hàng hiện tại nào mà bạn đang phục vụ. Phần nhàm chán nhất là khách hàng hiện tại không được phép biết rằng bạn thực sự đã thay thế một hệ thống cơ bản hoặc cơ sở mã mà họ không biết.

1. Nhưng bạn có thực sự cần phải di chuyển không?

Tôi thường thấy các kỹ sư mới muốn thử một công nghệ mới và thay thế một chức năng hiện có, hoặc ai đó muốn thực hiện một bản cải tiến hoàn chỉnh cho cơ sở mã. Nếu đây là một thay đổi có giới hạn (ví dụ, sử dụng một thư viện mã nguồn mở đã được kiểm tra kỹ lưỡng để thực hiện một hoạt động nhỏ trong dịch vụ, v.v.), tôi không bận tâm. Nhưng nếu đó là một thay đổi lớn về kiến trúc hoặc làm lại toàn bộ cơ sở mã, điều quan trọng là phải nhớ một nguyên lý kỹ thuật nổi tiếng "Tôn trọng những gì đã có trước". (Tôi thấy dòng tweet này buồn cười khi gọi mã cũ là mã huyền thoại.)

Quay trở lại vấn đề về các dự án di chuyển, luôn là khôn ngoan khi đánh giá xem bạn có thể khắc phục cùng một vấn đề với nỗ lực nhỏ hơn so với việc đại tu cơ sở mã hoặc kiến trúc hay không. Nhưng sự hấp dẫn của việc sử dụng công nghệ hoặc mẫu thiết kế mới luôn hấp dẫn, vậy chúng ta đánh giá quyết định này như thế nào? Sau đây là một số câu hỏi và cân nhắc để giúp bạn bắt đầu trước khi bắt đầu hành trình di chuyển:

1. Liệu doanh nghiệp (hoặc trải nghiệm của khách hàng) có bị ảnh hưởng tiêu cực hay sẽ bị ảnh hưởng trong tương lai nếu chúng ta không giải quyết vấn đề này và nhóm đã sử dụng hết mọi phương án để giải quyết mà không cần phải thực hiện dự án di chuyển lớn? Hãy chọn đánh giá từ một kỹ sư cao cấp khác không thuộc nhóm của bạn và người có thể đóng vai trò là người biện hộ cho quỷ dữ để kiểm tra áp lực lý luận của bạn. Một số ví dụ về biện minh có thể là cải thiện tính linh hoạt thêm 4 tháng phát triển cho mỗi lần ra mắt tính năng, sử dụng các ngăn xếp công nghệ khác nhau cho các dịch vụ khác nhau để cải thiện độ trễ p99 thêm 400ms, loại bỏ các nút thắt về khả năng mở rộng vượt quá X TPS, v.v. Luôn tìm kiếm sự bất đồng để phá vỡ sự thiên vị xác nhận của bạn trong những tình huống như vậy.

   
   

2. So sánh những nỗ lực để thực hiện di chuyển với những lợi ích mà nó mang lại, để bạn có thể ước tính thời gian cần thiết để bắt đầu gặt hái những lợi ích của dự án. Một ví dụ cá nhân mà tôi có thể chia sẻ như sau:

   • Nhóm của tôi sở hữu hai hệ thống riêng biệt phục vụ hai nhóm khách hàng khác nhau và mỗi lần ra mắt tính năng mới đều yêu cầu nhóm thực hiện các thay đổi tương tự nhưng không chính xác đối với các hệ thống riêng biệt này. Nhìn chung, sự trùng lặp dẫn đến nỗ lực bổ sung của 1 nhà phát triển mỗi tháng cho mỗi tính năng. Chúng tôi đã ra mắt khoảng 4 tính năng như vậy mỗi năm, dẫn đến 4 tháng dành cho nhà phát triển bị trùng lặp hoặc lãng phí công sức. Điều này gây khó chịu cho các kỹ sư. Một trong những kỹ sư đã đưa ra đề xuất kết hợp hai hệ thống này và ước tính nỗ lực là 24 tháng dành cho nhà phát triển. Sẽ mất 24 lần ra mắt tính năng và 6 năm (giả sử 4 tính năng ra mắt mỗi năm) để nhóm bắt đầu gặt hái những lợi ích của quá trình di chuyển. Chúng tôi đã không thực hiện quá trình di chuyển và chuyển sang phương pháp tiếp cận thay thế là sử dụng các thư viện dùng chung để giảm 50% nỗ lực trùng lặp và sau đó, chúng tôi đã ngừng sử dụng hệ thống sau 3 năm để chuyển sang dịch vụ khác.

     
     

3. Trong một số trường hợp, quá trình di chuyển là hướng dẫn từ trên xuống để đạt được mục tiêu rộng hơn (ví dụ: Amazon chuyển khỏi Oracle ), trong đó bạn vẫn có thể thực hiện phân tích nhưng không bắt buộc phải xin phê duyệt để tiếp tục dự án.

Khi bạn đã xác định được lý do chính đáng để thực hiện di chuyển và đã kiểm tra lý do với một số kỹ sư hoặc nhà lãnh đạo bên ngoài, thì đã đến lúc chuyển sang các bước tiếp theo.

2. Bố trí các yêu cầu chức năng và phi chức năng của một hệ thống

Điều này tương tự như những gì bạn sẽ làm khi chuẩn bị cho một cuộc phỏng vấn thiết kế hệ thống . Khi các yêu cầu chức năng và phi chức năng được nêu ra, điều khôn ngoan là hãy quên hệ thống hiện tại đi và nêu cách bạn sẽ xây dựng một hệ thống mới nếu không có ràng buộc nào.

Lý do để thực hiện bài tập này là rất nhiều thành viên nhóm hiện tại sẽ có thành kiến vô thức muốn xây dựng một hệ thống mới không khác nhiều so với hệ thống hiện tại, phá vỡ mục đích của việc di chuyển trong nhiều trường hợp. Hãy xem xét một ví dụ khác từ quá khứ của tôi:

• Chúng tôi đã quyết định chuyển khỏi cơ sở dữ liệu SQL tại chỗ do tình trạng tắc nghẽn về khả năng mở rộng và các vấn đề bảo trì. Nguyên nhân là do dịch vụ của chúng tôi đang sử dụng cơ sở dữ liệu SQL làm công cụ lập lịch để theo dõi các bản cập nhật liên quan đến hàng tồn kho. Chúng tôi đã chạy nhiều truy vấn phức tạp đối với cơ sở dữ liệu SQL mỗi giây, điều này rất lãng phí. Các kỹ sư của chúng tôi đã trình bày một thiết kế để thay thế cơ sở dữ liệu SQL của chúng tôi bằng cơ sở dữ liệu SQL trên nền tảng đám mây . Lý do đưa ra là SQL trên nền tảng đám mây có khả năng mở rộng hơn, nhưng thực tế là chúng tôi đang đẩy vấn đề phát sinh từ các mô hình xấu sang công nghệ đám mây. Chúng tôi nên sửa mô hình xấu thay vì đẩy vấn đề sang công nghệ đám mây. Một Kỹ sư chính đã chỉ đạo cách tiếp cận của chúng tôi để xây dựng Hệ thống theo sự kiện bằng cách sử dụng thông báo Pub/Sub và Hàng đợi phát trực tuyến (ví dụ: Kafka hoặc AWS Kinesis , v.v.) có khả năng mở rộng tốt hơn nhiều so với đề xuất ban đầu của chúng tôi.

Việc có sự tham gia của một người có nhiều kinh nghiệm hơn, người không làm việc trên các hệ thống hiện có đã dẫn dắt cuộc trò chuyện để xây dựng một hệ thống hoàn toàn khác có khả năng mở rộng hơn, thời gian thực và dễ bảo trì hơn. Tuy nhiên, điều này có thể không phải lúc nào cũng khả thi, nhưng sẽ không có hại gì nếu thử thực hiện bài tập này.

Nếu bạn đang thực hiện di chuyển giống hệt như chúng tôi đã đề xuất trước đây (tức là di chuyển SQL DB tại chỗ sang SQL DB đám mây), bạn có thể dễ dàng đáp ứng các yêu cầu không chức năng hơn. Tuy nhiên, nếu hệ thống cuối của bạn khác biệt đáng kể so với hệ thống hiện tại, ít nhất bạn nên cố gắng sửa lỗi mẫu chống được tích hợp sẵn trong hệ thống. Ví dụ: thay vì thăm dò để cập nhật thay đổi cho khóa trong cơ sở dữ liệu, bạn có thể xuất bản thông báo thay đổi bằng dịch vụ Pub/Sub cho người đăng ký.

Tuy nhiên, giống như mọi dự án trong hệ thống phân tán, việc di chuyển sẽ có sự đánh đổi khi nói đến các yêu cầu không chức năng và bạn sẽ cần phải lập kế hoạch cho việc này. Ví dụ, nếu có một dịch vụ monolith với khả năng sẵn sàng là 99,9% xử lý hai phép tính liên quan đến doanh nghiệp riêng biệt (ước tính ngày giao hàng và ước tính phí vận chuyển) và chúng tôi quyết định chia trách nhiệm này thành hai dịch vụ vi mô A (Dịch vụ ước tính ngày giao hàng) và B (Ước tính phí vận chuyển) mỗi dịch vụ có khả năng sẵn sàng là 99,9%, thì khả năng sẵn sàng chung của hệ thống sẽ trở thành:

P(A) * P (B) = 0,999 * 0,999 = khả năng sử dụng 99,8%

Việc tạo các dịch vụ vi mô từ một khối thống nhất đã làm giảm tính khả dụng từ 99,9% xuống 99,8%.

Luôn nhớ rằng, nếu bạn cần kết quả từ 'n' cuộc gọi dịch vụ (cuộc gọi dịch vụ tuần tự hoặc song song) để trả về phản hồi cho khách hàng, bạn phải nhân tính khả dụng riêng lẻ của từng dịch vụ trong 'n' dịch vụ để có được tính khả dụng cuối cùng của hệ thống.

Để đáp ứng hoặc vượt quá khả năng sử dụng ban đầu của hệ thống (tức là 99,9%), chúng ta sẽ cần phải nghĩ đến các kỹ thuật khác như lưu trữ đệm, thử lại, v.v. Nhưng mỗi tùy chọn này đều có nhược điểm riêng. Ví dụ, lưu trữ đệm, trong một số trường hợp, có thể có nghĩa là hệ thống của bạn phải có khả năng chịu được dữ liệu cũ; thử lại có thể gây ra sự chậm trễ và khiến hệ thống dễ bị bão thử lại, v.v.

Tuy nhiên, việc thực hiện bài tập này sẽ giúp bạn biết được liệu mình có đáp ứng được tiêu chuẩn hiện hành về các yêu cầu phi chức năng hay không hoặc liệu bạn có cần sự chấp thuận của lãnh đạo về các yêu cầu phi chức năng mới mà bạn muốn cung cấp cho khách hàng hay không.

3. Khách hàng có cần thực hiện hành động nào không?

Với một hệ thống mới, khách hàng của bạn sẽ áp dụng phiên bản máy khách mới của bạn. Với các dự án di chuyển, bạn có thể phải giải quyết vấn đề nếu tất cả khách hàng không thể di chuyển sang phiên bản máy khách mới (tức là, nghĩ đến khả năng tương thích ngược). Nếu tất cả khách hàng của bạn đều là nội bộ công ty hoặc bạn có khả năng áp dụng hạn chế bên ngoài công ty, bạn có thể làm việc với tất cả khách hàng của mình để chuyển họ sang phiên bản máy khách mới.

Trong những trường hợp khác, điều này đơn giản là không thể. Ví dụ, nếu bạn sở hữu một dịch vụ đám mây lớn được áp dụng rộng rãi trong ngành, bạn không thể buộc tất cả khách hàng chuyển sang phiên bản mới của máy khách. Điều này có thể gây ra nhiều trở ngại cũng như chi phí bảo trì cho nhóm và trong một số trường hợp, giải pháp là duy trì hai phiên bản hệ thống với hệ thống cũ hơn đang ở chế độ bảo trì (tức là không có khách hàng mới nào được thêm vào hệ thống này) và bạn cung cấp động lực cho những khách hàng cũ hơn chuyển sang phiên bản mới hơn của hệ thống vì nó mang lại nhiều lợi ích hơn cho khách hàng.

Tuy nhiên, nếu bạn gặp phải tình huống như liên kết tôi đã chia sẻ ở trên với Doordash, trong đó việc sử dụng Int làm kiểu dữ liệu của khóa chính sẽ gây tràn dữ liệu, bạn không còn cách nào khác ngoài việc buộc mọi người phải di chuyển.

4. Đã có những cuộc di cư tương tự nào được thực hiện chưa?

Khi xây dựng hệ thống mới, hầu hết các kỹ sư đều làm rất tốt công việc bao quát hầu hết mọi trường hợp sử dụng. Tuy nhiên, điều ngược lại xảy ra với việc di chuyển vì bạn đang xử lý một hệ thống đã được phát triển, vá lỗi và bảo trì bởi hàng chục, nếu không muốn nói là hàng trăm kỹ sư trước bạn. Ngay cả khi bạn muốn tìm hiểu về mọi trường hợp sử dụng, đường dẫn mã hoặc nút thắt cổ chai của hệ thống, thì cũng khó có thể hiểu hết toàn bộ dịch vụ.

Trong những trường hợp như vậy, điều đơn giản nhất cần làm là tìm kiếm bài học kinh nghiệm từ các nhóm, kỹ sư cao cấp, v.v. đã thực hiện các cuộc di cư tương tự về các quy trình bạn có thể tuân theo để che giấu điểm mù của mình. Nhiều công ty tuân theo quy trình thiết kế và đánh giá di cư ở cấp độ tổ chức rộng hơn. Hãy coi những bất đồng quan điểm như một phần thiêng liêng của quy trình để củng cố cách tiếp cận và sự hiểu biết của bạn. Các cuộc di cư đầy rẫy những bãi mìn có thể phát nổ theo những cách không ngờ tới.

Phần lớn các cuộc di cư thường thuộc một trong hai loại dưới đây hoặc kết hợp cả hai loại:

1. Di chuyển dịch vụ: Loại bỏ dịch vụ hiện có để chuyển sang kiến trúc mới, có thể bao gồm việc sử dụng một phần dịch vụ hiện tại và dịch vụ mới hoặc triển khai các dịch vụ siêu nhỏ mới để thay thế hệ thống hiện có.

   
   

2. Di chuyển kho dữ liệu: Loại bỏ kho dữ liệu hiện có và thay thế bằng kho dữ liệu mới hoặc sử dụng hệ thống theo sự kiện.

Ngay cả khi bạn không tìm thấy ví dụ di chuyển chính xác, bạn vẫn có thể rút ra những bài học rộng hơn cho các nhóm này. Theo kinh nghiệm cá nhân của tôi, di chuyển kho dữ liệu là khó nhất vì có những lo ngại về tính chính xác của dữ liệu bị ảnh hưởng do các vấn đề về tính nhất quán giữa kho dữ liệu cũ và mới. Ví dụ, người dùng có thể thấy phiên bản dữ liệu cũ hơn từ kho dữ liệu mới do sự chậm trễ trong quá trình truyền bá.

5. Chạy song song hệ thống cũ và mới

Chạy song song các hệ thống hiện có và mới trong khi chỉ phục vụ dữ liệu từ hệ thống hiện có cho phép bạn so sánh kết quả của cả hai hệ thống với các yêu cầu thực tế của khách hàng. Đây là bước hữu ích và mạnh mẽ nhất để so sánh và xác thực rằng hệ thống mới của bạn hoạt động chính xác.

Nhiều năm trước, tôi đã làm việc trên một dịch vụ di chuyển sang một ngăn xếp kỹ thuật mới. Bất cứ khi nào dịch vụ cũ của chúng tôi nhận được yêu cầu của khách hàng, chúng tôi sẽ thực hiện một cuộc gọi không đồng bộ song song đến dịch vụ mới của mình ở phần phụ trợ. Chúng tôi sẽ ghi lại kết quả dịch vụ hiện có và mới vào một vị trí S3. Sau đó, chúng tôi chạy một truy vấn AWS Athena vào cuối ngày để tìm ra bất kỳ sự khác biệt nào và xác định bất kỳ vấn đề nào với dịch vụ mới. Đó vẫn là một điều có thể dự đoán được so với một cuộc di chuyển khó khăn khác mà chúng tôi xử lý bằng kho dữ liệu.

Chúng tôi đang di chuyển một kho dữ liệu SQL cũ sang một kho dữ liệu NoSQL mới được điền từ một nguồn dữ liệu mới và đáng tin cậy hơn. Tuy nhiên, thời điểm các khóa cụ thể được cập nhật giữa các kho dữ liệu cũ và mới là không thể đoán trước, vì chúng đến từ hai hệ thống hoàn toàn khác nhau.

Sau khi thử nhiều cách tiếp cận không thành công để so sánh dữ liệu giữa kho dữ liệu cũ và mới, chúng tôi đã làm việc với các nhóm thượng nguồn của mình để phát hành phiên bản cho khóa dữ liệu, do đó chúng tôi có thể thực hiện so sánh độ chính xác của dữ liệu cho một khóa nhất định bằng cách sử dụng các phiên bản giữa cả hai hệ thống. Đây là công việc bỏ đi, vì chúng tôi không cần phiên bản sau dự án, nhưng không có cách nào khác để xử lý việc này.

6. Hãy lường trước mọi chuyện có thể diễn ra không như mong đợi: Bạn có thể quay lại thế giới trước đây không?

Ngay cả sau khi chạy Bước 5, nơi bạn có thể so sánh chính xác kết quả của hệ thống cũ và mới một cách kỹ lưỡng, rất có thể bạn không bao giờ gặp phải một loại yêu cầu cụ thể nào đó từ một số khách hàng hiếm khi sử dụng hệ thống của bạn. Tôi đã mất ngủ khi làm việc trên một số dự án di chuyển này và nghĩ rằng, "Sẽ thế nào nếu mọi thứ diễn ra không ổn với hệ thống mới?"

Cách dễ nhất để giải quyết vấn đề này là tắt công tắc hệ thống mới nếu báo động của chúng tôi phát hiện ra điều gì đó bất ngờ hoặc chúng tôi kích hoạt thủ công để chuyển lưu lượng truy cập trở lại hệ thống cũ. Lưu ý, điều này không dễ như bạn nghĩ. Trong một số trường hợp, có thể không có cách nào để chuyển sang hệ thống cũ hơn nhưng việc có cần gạt này sẽ giảm bớt rất nhiều áp lực cho nhóm.

Đối với những trường hợp không thể thực hiện được điều này, điểm duy nhất bạn có thể tin cậy là thực hiện kỹ lưỡng bước 5. (Chạy song song các hệ thống cũ và mới). Sau đó là triển khai dần dần hệ thống mới. Bạn có thể xác định triển khai dần dần chậm bằng các kỹ thuật như di chuyển một tỷ lệ phần trăm nhỏ (1% tiếp theo là 5%, 10%, 25%, 50%, 100%) lưu lượng truy cập để được phục vụ bởi dịch vụ mới hoặc chọn lọc một số khách hàng để được phục vụ bởi dịch vụ mới mà bạn đang làm việc chặt chẽ trong quá trình di chuyển, v.v.

Điều quan trọng nữa là phải xem xét rộng rãi sổ tay hướng dẫn ứng phó sự cố để các nhà điều hành tuân theo nếu có sự cố xảy ra. Nếu mọi thứ đều không ổn, can thiệp thủ công có thể giúp ích cho các trường hợp ngoại lệ bị bỏ sót, nhưng điều này có thể nhanh chóng trở nên không thể quản lý được nếu số lượng khách hàng bị ảnh hưởng tăng lên hàng nghìn. Đây là lý do để dành đủ thời gian cho các giai đoạn được mô tả trong điểm 5 và 6.

Phần kết luận

Mặc dù làm việc trên các bản di chuyển không phải là cách duy nhất để mài giũa một số kỹ năng này, nhưng nó chắc chắn có thể đẩy nhanh quá trình học tập của bạn mà bạn có thể áp dụng cho các dự án trong tương lai của mình ngay cả khi điều đó có nghĩa là chúng là những sáng kiến hoàn toàn mới. Các dự án di chuyển ít hấp dẫn hơn nhưng là những dự án khiến tôi phải trải qua thử thách, đặc biệt là khi tôi cung cấp phản hồi về các tài liệu thiết kế hoặc các tài liệu kỹ thuật khác.

Vì vậy, nếu bạn có cơ hội làm việc trên một trong số chúng, hãy thử xem: bạn sẽ không thất vọng và sẽ có được kinh nghiệm học tập suốt đời mà hy vọng bạn có thể truyền đạt lại cho người khác để xây dựng một số hệ thống kiên cường .