Di chuyển dữ liệu - nguy hiểm hay thiết yếu?

Bộ phận phát triển phần mềm của công ty tôi đang phải đối mặt với vấn đề di chuyển dữ liệu được coi là nguy hiểm tiềm tàng, đặc biệt là đối với các nhà quản lý của tôi.

Nền tảng là khách hàng của chúng tôi đang sử dụng một lượng lớn dữ liệu với chất lượng kém . Lý do cho điều này là chỉ một phần liên quan đến phần mềm của chúng tôi chất lượng, nhưng thay vào đó là lịch sử của dữ liệu: Hầu hết trong số họ đã được chuyển từ hệ thống tiền nhiệm , một số lỗi gây ra (chủ yếu là kinh doanh) mâu thuẫn trong hồ sơ dữ liệu hoặc misentries một cách tình cờ trên phía khách hàng (mà phần mềm của chúng tôi cho phép do lỗi).

Các đối số quan trọng nhất từ ​​các nhà quản lý của tôi là dữ liệu bị lỗi có thể biến thành dữ liệu thậm chí còn tồi tệ hơn , các rắc rối dữ liệu có thể đánh thức một số nhà quản lý tại khách hàng và một số quy trình về phía khách hàng có thể không hoạt động nữa vì quy trình của họ có phần thích nghi với hệ thống của chúng tôi.

Cá nhân, tôi coi việc di chuyển dữ liệu là một phần không thể thiếu trong quá trình phát triển phần mềm và việc di chuyển dữ liệu có thể được nhìn thấy đối với dữ liệu tái cấu trúc là mã. Tôi nghĩ rằng di chuyển dữ liệu là một điều cần thiết để tạo ra phần mềm phát triển . Nếu không có nó, chúng ta sẽ phải tạo ra phần mềm đau đớn, phần nào hoạt động xung quanh cấu trúc dữ liệu xấu.

Tôi đang hỏi bạn:

• Bạn nghĩ gì về việc di chuyển dữ liệu, đặc biệt là đối với các trường hợp thực tế và không chỉ từ quan điểm của một nhà phát triển?
• Bạn có bất kỳ lập luận chống lại ý kiến ​​quản lý của tôi?
• Làm thế nào để công ty của bạn đối phó với việc di chuyển dữ liệu và những khó khăn do chúng gây ra?
• Bất kỳ suy nghĩ thú vị khác thuộc về chủ đề này?

Di chuyển dữ liệu là bánh mì và bơ của tôi và làm sạch dữ liệu thực sự là một vấn đề cực kỳ quan trọng. Một chiến lược chúng tôi sử dụng để di chuyển 100% dữ liệu của khách hàng là các công cụ tiền di chuyển làm sạch dữ liệu không triệu chứng.

1. Điều này có nghĩa là phát triển hàng chục kiểm tra độ sạch dữ liệu (chủ yếu là các truy vấn sql).

2. Trao đổi các công cụ làm sạch với khách hàng (vì đó là dữ liệu của anh ấy, chúng tôi thiết kế các tiện ích vá lỗi, anh ấy xác nhận chúng và thực thi chúng).

3. Tinh chỉnh công cụ qua các lần lặp và đạt được càng sớm càng tốt chất lượng có thể đo được KPI.

4. Kiểm tra tính nhất quán dữ liệu sau khi di chuyển đã xảy ra. Điều này giúp đưa ra quyết định GO / NOGO vào D-Day.

Cuối cùng, di chuyển dữ liệu là một bài tập vô cùng có lợi phải diễn ra sau 3 đến 5 năm.

1. Nó cho phép tăng cường khả năng hỗ trợ kinh doanh của nền tảng.

2. Nó cho phép hợp lý hóa cơ sở dữ liệu.

3. Nó chuẩn bị nền tảng CNTT cho các công cụ kinh doanh thế hệ tiếp theo (ESB / EAI, Cổng thông tin, nền tảng Tự chăm sóc, báo cáo và khai thác dữ liệu, bạn đặt tên cho nó).

4. Nó tổ chức lại các luồng dữ liệu DIY giữa các nền tảng đã tích lũy qua nhiều năm theo cách "tạm thời" nhanh chóng và bẩn thỉu để thực hiện "các yêu cầu khẩn cấp".

5. Trên hết, nó trao quyền cho đội ngũ sản xuất CNTT, những người hiểu rõ hơn về nền tảng của họ và thúc đẩy thái độ 'có thể làm'. Những loại lợi ích này rất khó đo lường nhưng khi bạn biết nhiều khách hàng, sự cân nhắc này trở nên rõ ràng. Các công ty trốn tránh di cư vẫn ở trong các lớp sau, những người táo bạo dẫn đầu gói.

Nó giống như khi tầng hầm ngôi nhà của bạn trở nên bừa bộn với gỗ. Một buổi sáng, bạn phải lấy mọi thứ ra và chỉ đặt lại những thứ bạn cần và vứt phần còn lại đi. Sau đó, bạn có thể sử dụng lại tầng hầm của mình ;-)

Một cân nhắc cơ bản khác là ngày nay, sự mong đợi của khách hàng luôn luôn thay đổi, vì trong "khách hàng luôn đòi hỏi khắt khe hơn". Vì vậy, sẽ luôn có một tỷ lệ đáng kể của các đối thủ cạnh tranh của một công ty nhất định về việc tìm kiếm những xu hướng mới này với mục đích rõ ràng là tăng thị phần của họ. Cách họ sẽ làm là bằng cách điều chỉnh việc cung cấp của họ để theo kịp xu hướng hoặc thậm chí thúc đẩy các xu hướng, và điều đó đòi hỏi phải tái cấu trúc kinh doanh liên tục. Nếu nền tảng CNTT của bạn quá cứng nhắc, đó sẽ là lực cản cho khả năng của bạn để phối ngẫu hoặc đi trước các xu hướng thị trường về phía bạn và cuối cùng là duy trì thị phần của riêng bạn. Nói cách khác, trong một thị trường chuyển động quán tính là một công thức cho sự không liên quan.

Ngược lại, việc di chuyển dữ liệu sang một hệ thống mới hơn sẽ tạo ra một công cụ năng suất hiện đại và linh hoạt hơn, tạo ra những công nghệ mới nhất, hấp dẫn hơn cho nhân viên và điều này sẽ góp phần hỗ trợ hoặc thậm chí dẫn dắt quá trình đổi mới nội bộ của công ty , do đó đảm bảo hoặc tăng thị phần tương đối của nó.

Các cân nhắc ở trên thực sự chỉ trả lời được một nửa câu hỏi trong tiêu đề "Di chuyển dữ liệu - nguy hiểm hoặc thiết yếu". Có Di chuyển dữ liệu là điều cần thiết, nhưng chúng cũng nguy hiểm? Trên tài khoản này, nhiều thứ trong CNTT rất nguy hiểm. Theo định nghĩa, bất cứ điều gì mà cổ phần cao là nguy hiểm; đặc biệt là nếu bạn không coi trọng vấn đề. Nhưng đây thực sự là mô hình phổ biến nhất trong CNTT. Không lấy trung tâm dữ liệu hoặc tính sẵn sàng cao hoặc khả năng chịu thiên tai nghiêm trọng là nguy hiểm.
Điều đó có nghĩa là các công ty ngày nay nên từ chối các trụ cột của bối cảnh Công nghệ thông tin ngày nay? Chắc chắn là không!

Để nói lên quan điểm của bạn, bạn có thể lập luận rằng "Bay là nguy hiểm nếu bạn không sử dụng máy bay được chế tạo bởi các chuyên gia". Điều này cũng tương tự đối với Di chuyển dữ liệu. Khi được thực hiện và tiến hành bởi các chuyên gia, nó không nguy hiểm hơn việc bay trong một chiếc máy bay được thiết kế tốt và vận hành tốt. Và ROI có cùng tỷ lệ so với các phương tiện giao thông trên mặt đất.
Khi được giao phó cho các chuyên gia, hầu hết các cuộc di cư đều được kiểm soát thành công và tỷ lệ thất bại + từ bỏ là cực kỳ thấp.

Các nhà quản lý của bạn nên được dẫn dắt để tự hỏi "Trong khi hầu hết các công ty trải qua các dự án Di chuyển dữ liệu thành công thì điều gì sẽ khiến công ty chúng tôi trở nên khác biệt đến nỗi thay vào đó sẽ gặp phải một thất bại?

Alain đã đưa ra câu trả lời tuyệt vời về tầm quan trọng của việc làm sạch dữ liệu cho dự án di chuyển dữ liệu thành công và lý do đằng sau việc thực hiện di chuyển dữ liệu. Tôi chỉ muốn nhắm mục tiêu cụ thể mối quan tâm của bạn có.

Theo tôi không phải là vấn đề có nên thực hiện di chuyển dữ liệu hay không, đó là khi nào nên thực hiện. Người quản lý của bạn có quan điểm hoàn toàn hợp lệ nói rằng dữ liệu của bạn không chỉ là của bạn nữa và khách hàng cuối cùng đã xây dựng các quy trình của họ xung quanh nó. Tuy nhiên , trạng thái này sẽ không thay đổi trong tương lai . Sớm hay muộn chất lượng dữ liệu kém sẽ trở thành yếu tố không thể tránh khỏi làm chậm hoạt động kinh doanh của bạn và bạn sẽ bị buộc phải di chuyển. Làm điều này dưới áp lực và với thời hạn chặt chẽ có thể dẫn đến các quyết định dưới mức tối ưu. Bên cạnh đó, hãy nghĩ về chuyên môn mà bạn có bây giờ và sẽ có trong 2-3 năm nữa. Điều gì xảy ra nếu những người hiểu dữ liệu của bạn sẽ rời khỏi công ty? Bạn có chắc chắn rằng tài liệu bạn có là đầy đủ?

Có thể thực hiện di chuyển bây giờ là không cần thiết nhưng người quản lý của bạn ít nhất cần phải có tầm nhìn khi nào việc di chuyển chính xác sẽ được thực hiện.

Tôi đã làm việc cho một công ty bảo hiểm và tham gia vào việc di chuyển dữ liệu cho hệ thống cốt lõi. Vâng, có tổng cộng 4 lần. Vì vậy, đây là ý kiến ​​của tôi:

Trong trường hợp của tôi, di chuyển dữ liệu là bắt buộc, vì theo quy định, chúng tôi phải giữ dữ liệu ít nhất 10 năm và chúng tôi không thể đủ khả năng hỗ trợ hệ thống kép trong dài hạn. Lý do khác là người dùng mong đợi họ có thể tiếp tục công việc của họ với ứng dụng mới. Nếu họ không thể tìm thấy mục họ làm việc, ứng dụng của bạn rất tệ và thậm chí còn tệ hơn khi dữ liệu không chính xác.

Chà, di chuyển dữ liệu là một con quái vật khủng khiếp và nó là có thật, vì vậy hãy đối mặt với nó. Đó là rủi ro nhưng có thể được giảm thiểu bằng cách giải quyết nó sớm hơn và cẩn thận. Theo hướng dẫn, có bốn quy trình lớn cần được xem xét khi di chuyển dữ liệu:

1. Ánh xạ dữ liệu. Bản đồ của chủ (và sự kết hợp của chúng) với hệ thống mới
2. Dọn dẹp dữ liệu. Bản đồ ngoại lệ trong dữ liệu, nghĩa là dữ liệu có sự kết hợp được coi là không hợp lệ trên hệ thống mới. Nếu có thể, hãy thỏa thuận với doanh nghiệp để loại trừ dữ liệu không có cách nào được ánh xạ và có khả năng phá vỡ hệ thống mới và chuẩn bị cách giải quyết
3. Di chuyển dữ liệu thực tế. Có nhiều chiến lược để thực hiện di chuyển dữ liệu. Ví dụ: vụ nổ lớn, gia tăng
4. Báo cáo hợp nhất. Cả hai hệ thống nên chạy song song, làm thế nào để tạo báo cáo chính xác và nhất quán

Sự kiện với kế hoạch cẩn thận, shit xảy ra! Một lực lượng đặc nhiệm nên sẵn sàng đối phó với các vấn đề liên quan đến di cư.

1) Bạn nghĩ gì về việc di chuyển dữ liệu, đặc biệt là đối với các trường hợp thực tế và không chỉ từ quan điểm của nhà phát triển?:

Di cư là một phần thiết yếu của phát triển hệ thống. Nếu bạn thay thế một phần hoặc toàn bộ hệ thống cũ, di chuyển là một thực tế của cuộc sống cho dù quản lý có muốn hay không. Nếu dữ liệu hiện tại là xấu, nó sẽ phản ánh xấu trên hệ thống mới của bạn. Vì vậy, điều quan trọng là phải có một chiến lược di cư tốt.

2) Bạn có bất kỳ lập luận chống lại ý kiến ​​quản lý của tôi?

Vâng, di cư là rủi ro, nhưng nó cũng là một thực tế của cuộc sống, vì vậy hãy đối phó với nó. Và đối phó với nó càng sớm càng tốt.

3) Làm thế nào để công ty của bạn đối phó với việc di chuyển dữ liệu và những khó khăn do chúng gây ra?

Công ty của tôi có - với sự thành công ngày càng tăng liên quan đến những người quản lý tích cực trong quá trình di chuyển. Chúng tôi xem xét dữ liệu hiện có một cách tốt nhất có thể trong các bước đầu tiên của dự án và khuyến khích khách hàng cải thiện chất lượng dữ liệu trước khi chúng tôi bắt đầu di chuyển. Đôi khi chúng ta thực sự đòi hỏi nó.

4: Bất kỳ suy nghĩ thú vị nào khác thuộc về chủ đề này

Lời khuyên của tôi là phân chia quá trình di chuyển theo hai bước: Chuyển đổi và làm sạch dữ liệu. Chuyển đổi khá đơn giản - vấn đề ánh xạ các đối tượng hệ thống cũ sang hệ thống mới. Mặt khác, việc làm sạch dữ liệu có thể là một việc rất khó khăn (như đã đề cập ở trên). Thu hút khách hàng tham gia càng nhiều càng tốt và bắt đầu quá trình càng sớm càng tốt. Hãy nhớ rằng dữ liệu xấu sẽ phản ánh xấu trên hệ thống mới của bạn - đôi khi hoàn toàn không có lý do. Khi một hệ thống mới không hoạt động, khách hàng sẽ hiếm khi đổ lỗi cho dữ liệu dường như chỉ hoạt động tốt trong hệ thống cũ.

Nếu dữ liệu bạn dự định di chuyển hiện đang xấu, thì nó cần được sửa cho dù bạn có thực hiện di chuyển hay không. Dữ liệu xấu = dữ liệu vô dụng.

Di cư là rủi ro, đó là sự thật. Nhưng mỗi dự án CNTT lớn cũng vậy. Có nhiều cách để giảm thiểu rủi ro và chúng chắc chắn nên được lên kế hoạch trước trong một cuộc di cư.

Đầu tiên, bạn phải luôn có cách quay trở lại hệ thống như bây giờ. Việc di chuyển thứ hai nên được thực hiện trên các máy chủ thử nghiệm được thiết lập chỉ dành cho việc di chuyển. Thật ngu ngốc khi thực hiện di chuyển mà không có khả năng kiểm tra nó trước. Thứ ba, tất cả các mã cho việc di chuyển phải nằm trong kiểm soát nguồn.

Thứ tư, bạn cần các yêu cầu và kế hoạch kiểm tra trước khi bắt đầu di chuyển. Bạn cần biết rằng nếu bạn có 1.293.687 hồ sơ trong hệ thống cũ, thì bạn có cùng một bản mới hoặc bạn biết họ đã đi đâu (có lẽ là một bảng ngoại lệ). Nếu bạn đang chuẩn hóa một sơ đồ không chuẩn hóa, bạn cần tính toán số lượng bản ghi bạn nên kết thúc trước khi bạn bắt đầu và sau đó kiểm tra xem. Bạn cần tài liệu chỉ định ánh xạ từ hệ thống này sang hệ thống khác là gì. Điều này sẽ giúp người QA của bạn kiểm tra xem dữ liệu đã đến đúng nơi chưa.

Bạn cần xác định cách xử lý dữ liệu xấu hiện tại. Những gì có thể được làm sạch, những gì có thể cần một giá trị trong trường bắt buộc có nội dung 'Không xác định', những gì cần được đưa ra một bảng ngoại lệ, những gì cần một sự can thiệp thủ công của một nhóm người dùng (quyết định xem hai người này có thực sự là một bản sao hay không Có hai bác sĩ trong thực tế đó có cùng tên chẳng hạn và nếu đó là bản sao mà dữ liệu sẽ chọn khi hai bản ghi khác nhau, v.v.).

Chìa khóa để di chuyển thành công là lập kế hoạch. Tôi đã thấy rằng việc lập kế hoạch (bao gồm viết các trường hợp kiểm thử và kiểm tra đơn vị) thường mất nhiều thời gian hơn so với phát triển thực tế.

Chìa khóa tiếp theo để di chuyển dữ liệu thành công là QA. Đây không phải là một dự án để ném vào đội QA một ngày trước khi ra mắt. Đây không phải là một dự án để khởi động khi QA nói có vấn đề.

Một chìa khóa khác để di chuyển thành công là triển khai phần lớn dữ liệu và kiểm tra nó trong khi hệ thống ban đầu vẫn đang chạy. Nếu bạn đang di chuyển nhiều hồ sơ, điều này có thể tốn thời gian và những thay đổi mới sẽ xảy ra. Vì vậy, quá trình của bạn phải có khả năng kéo các thay đổi dữ liệu sau khi quá trình di chuyển cũng bắt đầu. Ví dụ, SQL Server có một thứ gọi là Change Data Capture có thể giúp với điều này. Bạn có thể sao lưu hệ thống ban đầu và bật ghi dữ liệu thay đổi cùng một lúc. Sau đó, bạn có thể sắp xếp lại bản sao lưu vào máy chủ di chuyển của mình, kiểm tra di chuyển, lấy phần lớn dữ liệu được tải và sau đó bạn chỉ phải tải các bản ghi đã thay đổi. Khi bạn di chuyển các bản ghi cuối cùng, hãy tắt hệ thống nguồn cho đến khi quá trình di chuyển được thực hiện. Đây là một lý do để di chuyển phần lớn các hồ sơ trước thời hạn, vì vậy ứng dụng giảm thời gian ít nhất Chọn thời gian di chuyển của bạn thật tốt, đừng tắt hệ thống bảng lương vào ngày họ nên xử lý bảng lương hoặc gửi W2. Và làm điều đó trong giờ sử dụng thấp. Nếu bạn có nhiều khách hàng, bạn có thể xem xét việc di chuyển một khách hàng trước và đảm bảo tất cả đều tốt trước khi thực hiện các khách hàng khác. Việc khôi phục dữ liệu của một khách hàng dễ dàng hơn rất nhiều nếu có vấn đề. Nhưng kế hoạch này cẩn thận nếu bạn làm điều đó. s dữ liệu hơn 10000 nếu có vấn đề. Nhưng kế hoạch này cẩn thận nếu bạn làm điều đó. s dữ liệu hơn 10000 nếu có vấn đề. Nhưng kế hoạch này cẩn thận nếu bạn làm điều đó.

Nếu việc di chuyển liên quan đến giao diện người dùng mới, vui lòng yêu cầu người dùng thực tế sử dụng giao diện đó như một phần của thử nghiệm di chuyển. Sau đó đào tạo những người dùng khác trước khi bạn phát trực tiếp (nhưng chưa đầy một tuần trước khi bạn phát trực tiếp hoặc họ sẽ quên). Có những người dùng tham gia thử nghiệm giúp thiết kế chương trình đào tạo, họ biết họ có câu hỏi gì và mọi người cần biết theo thứ tự nào. Nhận đầu vào của họ, tạo một trường bắt buộc vì bạn nghĩ rằng nó sẽ không hữu ích nếu người dùng thường không có dữ liệu đó khi họ nhập vào hồ sơ. Họ sẽ chỉ đưa rác vào trường mới được yêu cầu vì họ không thể lấy dữ liệu theo cách khác.

Hãy xem những gì không đúng với dữ liệu hiện tại, bạn có thể thêm khóa ngoại, ràng buộc, kích hoạt, quy tắc kinh doanh trong ứng dụng, giá trị mặc định, v.v ... để tránh điều này trở nên tồi tệ trong tương lai không? Khi bạn xóa dữ liệu xấu, bạn cũng cần tạo một cách để tránh dữ liệu xấu tương tự đó xuất hiện trong tương lai. Phân tích lý do tại sao dữ liệu xấu được xử lý và sửa các thiết kế lỗ hổng.

Di chuyển dữ liệu là một điều cần thiết. Không có di chuyển dữ liệu, bạn thường không thể đi tiếp. Nhiều hệ thống tôi đã làm việc với lịch sử yêu cầu chỉ có sẵn từ các hệ thống trước. Di cư là phương pháp thực tế duy nhất để làm điều này. Chất lượng dữ liệu thường là một vấn đề. Nói chung, điều này nên được xử lý trong hệ thống trước. Điều này có thể yêu cầu thay đổi dữ liệu để lấy lại chất lượng.

Các hệ thống khác mà tôi đã làm việc phụ thuộc vào dữ liệu từ các hệ thống khác. Đây là một vấn đề khác nhau nhưng có ý nghĩa. Trong một số trường hợp, dữ liệu có thể được thay thế hoàn toàn. Các trường hợp khác có thể được xử lý tốt hơn bằng cách hợp nhất các thay đổi có trong dữ liệu mới vào tập hợp hiện có. Các loại di chuyển này phải bao gồm kiểm tra tính hợp lệ cho nguồn cấp dữ liệu đến.

Khả năng xác nhận và làm sạch dữ liệu hiện có có thể là một tính năng quan trọng của một hệ thống. Điều này là độc lập với di cư. Thường có các cơ chế để sửa đổi dữ liệu nằm ngoài sự kiểm soát của hệ thống. Điều này có thể khiến dữ liệu trở nên không hợp lệ. Các vấn đề dữ liệu khác là do lỗi trong ứng dụng. Chạy các thói quen xác nhận định kỳ có thể giúp xác định vấn đề và cho phép dữ liệu được làm sạch trước khi đến lúc di chuyển. Như đã lưu ý làm sạch dữ liệu sớm có thể làm cho việc di chuyển dễ dàng hơn.

Một số xác nhận là nhạy cảm về thời gian và không nên được áp dụng cho dữ liệu chưa được sửa đổi. Điều này là phổ biến với các giá trị được mã hóa, trong đó các mã đã bị loại bỏ. Có thể thay đổi các trường khác trong bản ghi mà không gây ra lỗi xác thực. Điều này có thể làm cho xác thực cập nhật phức tạp hơn vì nó cần xác định trường nào đã thay đổi trước khi xác thực. Xác nhận trường chéo cũng có thể phức tạp hơn. Khả năng coi một số hồ sơ là chỉ đọc có thể giúp ích trong trường hợp này vì việc xác nhận có thể tránh được.

Trên một hệ thống tôi làm việc, hệ thống mới đã bị khách hàng từ chối một phần. Họ từ chối cho phép các mô-đun nhập dữ liệu mới được sử dụng. Tuy nhiên, họ muốn xử lý hàng loạt từ hệ thống mới. Giải pháp là di chuyển dữ liệu hàng đêm trước khi chạy hàng loạt.

Đó là một điều ác cần thiết. Tôi đã ở cả hai đầu và đây là một số vấn đề khác gây ra vấn đề.

1. Đặc biệt là trong doanh nghiệp, khi các đồng chí chuyển sang một hệ thống mới, họ muốn nó làm mọi thứ mà hệ thống cũ đã làm. Họ không xem lại thủ tục của họ. Họ choáng ngợp đến mức họ chỉ muốn tiếp tục làm mọi thứ theo cùng một cách. Điều này là an toàn cho họ.
2. Họ không dành thời gian để tìm hiểu hệ thống mới hoặc thuê những người có chuyên môn.
3. Họ muốn tùy chỉnh hệ thống mới thành chỗ ở số 1 hoặc để xử lý một số khía cạnh mới trong hoạt động kinh doanh của họ. Tùy chỉnh hệ thống X mới X Dữ liệu được chuyển đổi = Biến chứng phức tạp
4. Không đủ thời gian dành riêng cho thử nghiệm.
5. Khách hàng ghét chạy song song / làm việc hai lần. Không thể đổ lỗi cho người dùng vì họ không có thời gian để làm điều này vì tất cả các nhiệm vụ khác của họ được giữ nguyên.

Nếu người quản lý của bạn có thể biện minh cho việc mất doanh số bằng cách không chuyển đổi dữ liệu, hãy tiếp thêm sức mạnh cho họ. Nói với khách hàng của bạn rằng tất cả các chuyển đổi dữ liệu không thành công sẽ không hoạt động vì người khác sẽ luôn nói với họ điều đó sẽ xảy ra (Thường là đối thủ của bạn.).

Bạn nghĩ gì về việc di chuyển dữ liệu, đặc biệt là đối với các trường hợp thực tế và không chỉ từ quan điểm của một nhà phát triển?

phần mềm phải được nâng cấp thường xuyên. để đảm bảo di chuyển được lưu, bạn cần sao lưu và thử nghiệm.

Bạn có bất kỳ lập luận chống lại ý kiến ​​quản lý của tôi?

Anh ấy đúng rằng đó là rủi ro. nhưng bạn có thể điều chỉnh các kỹ thuật để làm cho nó ít rủi ro hơn.

Làm thế nào để công ty của bạn đối phó với việc di chuyển dữ liệu và những khó khăn do chúng gây ra?

chúng tôi có sao lưu hàng ngày, sao lưu gia tăng, sao lưu trước mỗi lần triển khai vào sản xuất. mà ít nhất cho phép bạn quay trở lại nếu có bất cứ điều gì xấu xảy ra.

chúng tôi có môi trường thử nghiệm, kiểm tra tự động và máy chủ xây dựng hàng ngày. cũng là một quy trình kiểm tra khói để đảm bảo các hoạt động và chức năng chính hoạt động tốt. Chúng tôi liên quan đến các nhà phát triển, QA và người dùng để kiểm tra bản dựng (có dữ liệu được di chuyển).

chúng tôi đang sử dụng ruby ​​trên đường ray, cung cấp phiên bản di chuyển dữ liệu, nâng cấp và khôi phục dữ liệu. mà làm cho cuộc sống của chúng ta dễ dàng hơn.

chúng tôi đang sử dụng capistrano để thực hiện cập nhật mã và di chuyển dữ liệu. giữ cho việc di chuyển tự động và đơn giản là một trong những điều quan trọng để đảm bảo hệ thống sản xuất hoạt động.

Bất kỳ suy nghĩ thú vị khác thuộc về chủ đề này?

Một mối quan tâm khác liên quan đến việc di chuyển dữ liệu với tôi là sự nhất quán của việc nâng cấp mã và di chuyển dữ liệu. trong trường hợp của tôi, một lần nữa, chúng tôi đang sử dụng các cách tự động để xử lý việc đó. và luôn sẵn sàng để quay trở lại.

thực hiện di chuyển dữ liệu theo cách thủ công có thể biến cơ sở dữ liệu thành trạng thái không xác định. và thật khó để so sánh phiên bản di chuyển dữ liệu giữa các môi trường máy chủ khác nhau.

hy vọng nó giúp.

Chúng tôi không lãng phí thời gian để cố gắng di chuyển dữ liệu từ các hệ thống cũ vì thời gian và đầu tư và rủi ro đều quá cao. Chúng tôi chỉ cần tiến lên phía trước với các hệ thống mới hơn và tích hợp khi cần thiết.

Mỗi doanh nghiệp đều có một số hình thức hệ thống kế thừa mà nó phải hỗ trợ và đó chỉ là chi phí kinh doanh bình thường.

Phần thưởng mà các nhà quản lý của bạn hy vọng nhận ra tốt hơn là cực kỳ cao với chi phí di chuyển.