Những thực tiễn hoặc công cụ nào cho phép Triển khai Cơ sở dữ liệu liên tục?

Phân phối liên tục hoặc Triển khai liên tục cơ sở hạ tầng và mã tương đối đơn giản so với việc thử các cách tiếp cận tương tự cho cơ sở dữ liệu, cụ thể là RDBMS. Mã và cơ sở hạ tầng sẽ không thay đổi hoặc phát triển sau khi triển khai hoàn tất. Tuy nhiên, cơ sở dữ liệu sẽ có dữ liệu mới được thêm vào để tạo dữ liệu nếu không phải là lược đồ vốn có thể thay đổi thành phần.

Tôi biết rằng có những cách thực hành như chỉ thêm các đối tượng cơ sở dữ liệu, tức là bảng và cột, không bao giờ sửa đổi hoặc loại bỏ chúng - cách tiếp cận phụ thuộc hoàn toàn vào lược đồ cơ sở dữ liệu này có ưu điểm là đảm bảo rằng các lược đồ tương thích ngược với chi phí phức tạp hơn lược đồ.

Tương tự, có những sản phẩm như Flyway và Ready Roll hỗ trợ viết di chuyển được viết giữa các phiên bản của lược đồ.

Những thực tiễn và công cụ nào khác hiện đang tồn tại để cho phép triển khai liên tục các lược đồ cơ sở dữ liệu vào môi trường sản xuất trong đó tính toàn vẹn dữ liệu là mối quan tâm?

Pramod Sadalage và Scott Ambler đã viết một cuốn sách Tái cấu trúc cơ sở dữ liệu: Thiết kế cơ sở dữ liệu tiến hóa , là một mồi tuyệt vời vô cùng vững chắc cho chủ đề của DB trong nhóm / nhóm CD.

Những thách thức

Tôi biết rằng có các thực tiễn như chỉ thêm các đối tượng cơ sở dữ liệu, tức là các bảng và cột, không bao giờ sửa đổi hoặc xóa chúng

Tại một công ty tôi làm việc, một cửa sổ dữ liệu thô tương đương với khoảng 6 tháng và ăn hết 10 TB. Dữ liệu sau đó được xử lý thành định dạng RDBMS có giá 6 TB dữ liệu có thể sử dụng, chiếm khoảng 10 năm dữ liệu báo cáo. Vấn đề là ở quy mô, những loại thực hành này chỉ đơn giản là không thực tế. Lưu trữ là đắt tiền - có lẽ là chi phí tính toán lớn nhất. Điều này cung cấp một số thách thức thú vị:

1. Sao lưu - các plugin innodb rất tuyệt vời, nhưng thời gian sao lưu trên nhiều dữ liệu đó không thực tế
2. Thời gian khôi phục - đối với các bộ dữ liệu lớn - đặc biệt nếu bạn cần sao chép để bắt kịp sau khi khôi phục trở lại trạng thái hoạt động có thể mất vài ngày hoặc thậm chí vài tuần
3. Tạo / gieo các thể hiện mới - Thường thì công việc bạn có thể đang thực hiện trong dev / test liên quan đến các công việc ETL (Trích xuất, Chuyển đổi và Tải) trên tập dữ liệu của bạn. Chúng cần được xác nhận bằng cách sử dụng các đơn vị kiểm tra QA, nhưng điều này cần được thực hiện theo cách không phá hủy để dữ liệu sản xuất ban đầu được bảo tồn. Trong khi gặp thảm họa, bạn có thể sẵn sàng xử lý thời gian khôi phục lâu để hiểu rằng sao lưu là một chính sách bảo hiểm và mục đích là để tránh chúng, quy trình phát triển DevOps yêu cầu, về cơ bản, bạn có thể thực hiện khôi phục hoặc sao chép dữ liệu của bạn một cách thường xuyên (có thể nhiều lần trong ngày)
4. Dung lượng - Xoay quanh nhiều dữ liệu ở quy mô tôi vừa mô tả có thể rất chuyên sâu. Bạn không chỉ cần giải quyết các vấn đề được mô tả trong 1-3, mà bạn cần thực hiện theo cách không gây ra sự cố ngừng hoạt động hoặc làm chậm hiệu suất cho các hệ thống sản xuất của bạn.

Trong khi những cân nhắc ở trên có thể không phải là mối quan tâm ở quy mô nhỏ hơn, ở quy mô lớn hơn, những điều này trở thành vấn đề lớn. Điều này có nghĩa là điều cực kỳ quan trọng là bạn xác định các yêu cầu của mình và dự báo kích thước của tập dữ liệu của bạn.

Xác định yêu cầu

Do đó, bạn cần xác định một số yêu cầu:

1. RTO - RTO hoặc Khôi phục mục tiêu thời gian để sao lưu là một trong những trình điều khiển quan trọng nhất của các giải pháp sao lưu cơ sở dữ liệu. Mặc dù, ban đầu nó có vẻ không liên quan đến hầu hết các vấn đề khác, nhưng nó trở nên cực kỳ phù hợp khi bạn hỏi "Điều gì sẽ xảy ra nếu tôi sử dụng giải pháp sao lưu của mình để tạo hoặc gieo các trường hợp mới?". Tôi sẽ trình bày một số kỹ thuật để làm như vậy trong phần tiếp theo.
2. RPO - RPO hoặc Mục tiêu điểm khôi phục để sao lưu xác định A) bạn có thể khôi phục bao xa (phút, giờ, ngày, tuần, tháng hoặc năm) B) Khoảng thời gian sao lưu ở các tầng khác nhau và C) bạn có thể khôi phục chi tiết như thế nào . Ví dụ: đối với cơ sở dữ liệu E-mail, Sao lưu mức tin nhắn - khôi phục một E-mail cụ thể - thường được tìm kiếm. Tương tự, bạn có thể thấy rằng dữ liệu trong một vài ngày là hoàn toàn vô dụng - vì vậy không có điểm nào khôi phục lại một năm.
3. Kích thước của tập dữ liệu của bạn - Điều này rất quan trọng vì đối với cơ sở dữ liệu 1 MB, RTO của bạn có thể đạt được với hầu hết các sản phẩm và giải pháp sao lưu. Tuy nhiên, đối với cơ sở dữ liệu 10TB, bạn sẽ thấy rằng bản sao lưu đầy đủ, cấp hàng cho băng LTO 3 có thể sẽ không đạt được RTO của bạn và có thể can thiệp vào RPO của bạn vì các bản sao lưu bắt đầu vượt quá cửa sổ sao lưu của bạn. Chính xác bạn không thể thực hiện một mysqldump trên bộ dữ liệu lớn này, nhưng có lẽ có thể thoát khỏi điều đó trên cơ sở dữ liệu 1MB.
4. Tính nhất quán của cơ sở dữ liệu - Điều cuối cùng tạo ra sự khác biệt lớn trong việc triển khai liên tục, độ tin cậy của trang web, khả năng mở rộng và tính khả dụng cao khi làm việc với các bảng dữ liệu là nhu cầu của bạn (hoặc thiếu) về tính nhất quán. Có ba loại cơ bản: tính nhất quán ngay lập tức, tính nhất quán trong thời gian (JIT) và tính nhất quán cuối cùng

Ngoài các cân nhắc chính ở trên, bạn cũng cần xem xét các yêu cầu cấp phép và hỗ trợ (nguồn mở hoặc nguồn đóng; hỗ trợ nhà, hỗ trợ bên thứ ba hoặc hỗ trợ nhà cung cấp) các yêu cầu ứng dụng / ngôn ngữ (các trình kết nối cho nhiều cơ sở dữ liệu có thể quan trọng; Ứng dụng của bạn được biên dịch? Bạn có quyền truy cập vào mã nguồn không? Bạn có thể biên dịch lại nó, hoặc nó được cung cấp bởi một nhà cung cấp? Hoặc nó chạy trên một ngôn ngữ được giải thích?) Các yêu cầu chính trị (Tổ chức của bạn chỉ tin tưởng vào Oracle? Họ có tin tưởng MySql không? Bạn cảm thấy thế nào về MariaDB hoặc Postgres?) Và công cụ cơ sở dữ liệu (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Và các yêu cầu lịch sử hoặc tương thích (chúng tôi đã sử dụng PL / SQL trong nhiều năm và một nửa mã của chúng tôi được tích hợp vào cỗ máy tiên tri! Làm thế nào chúng ta có thể chuyển sang MariaDB?!?)

Tất cả những điều này (đáng kể) tác động đến các công cụ có sẵn cho bạn.

Một số tùy chọn để quản lý dữ liệu trong nhà

Lưu ý: Dưới đây là không có cách nào đầy đủ và những người dùng SE khác nên đồng ý với các đề xuất bổ sung.

Với những cân nhắc chung chung, tôi sẽ cung cấp cho bạn một số kỹ thuật và công nghệ để giải quyết vấn đề trên. Trước tiên, hãy tự hỏi nếu bạn thực sự cần sử dụng RDBMS hoặc nếu dữ liệu không có cấu trúc với một cái gì đó như Hadoop, CouchDB hoặc thậm chí lưu trữ hướng đối tượng (một cái gì đó như swift) là một tùy chọn.

Thứ hai, xem xét xem xét một giải pháp dựa trên đám mây. Điều này gây ra một số vấn đề đau đầu này và để lại những vấn đề phức tạp cho những cá nhân có trình độ cao (và được trả tiền). Tuy nhiên, ở quy mô, bạn có thể thấy điều này thực sự ăn vào ngân sách của mình (các nhà cung cấp đám mây KHÔNG kiếm được lợi nhuận ở mức này và ở một quy mô nhất định, bạn chỉ có thể tự mình thuê các chuyên gia này), hoặc nếu bạn đang làm việc dưới sự bảo mật hoặc chính trị cụ thể các yêu cầu (đọc: chúng ta không thể làm đám mây) xem xét một NFS / FibreChannel Filer lai. Hầu hết các trình quay phim này, chẳng hạn như NetApp, Pure Storage và Tegile đều hỗ trợ kỹ thuật sao chép và sao chép dựa trên delta có thể rất thuận tiện cho A) lấy bản sao lưu, B) Khôi phục bản sao lưu và C) Tạo bản sao lưu mới.

Tại thời điểm này, tôi cần lưu ý rằng tôi không phải là chuyên gia sao lưu và lưu trữ, vì vậy có một số phần của vấn đề này mà tôi chưa bao giờ có thể giải quyết được trước khi tôi chuyển sang các vấn đề khác (và đồng cỏ xanh hơn).

Nhưng điều đó đang được nói, những sản phẩm này cho phép bạn chụp ảnh vi sai bên dưới cơ sở dữ liệu của bạn. Bạn sẽ cần phải viết ra một "bảng khóa có khóa đọc" đầy đủ trên một trong các trường hợp cơ sở dữ liệu của bạn (nên sử dụng nô lệ chỉ đọc) và bỏ vị trí binlog hoặc GTID của bạn, nhưng với những trình quay này, bạn sẽ có thể để sử dụng các snaps này để tạo các phiên bản mới của cơ sở dữ liệu của bạn. Bạn sẽ muốn đặt binlog trên một phân vùng riêng biệt và chỉ đặt dữ liệu cơ sở dữ liệu của bạn trên các phân vùng này. Khi bạn thực hiện, bạn sẽ có thể sao chép các phân vùng này (trên NetApps, đây được gọi là " FlexClone "

Điều này là do đối với mỗi khối đọc, bộ lọc phải xác định xem dữ liệu có nằm trong ảnh chụp nhanh gốc hoặc trong vùng đồng bằng không. Đối với khối lượng / cửa hàng có nhiều ảnh chụp nhanh, điều này có thể cần phải được kiểm tra nhiều lần. Bạn có thể khắc phục điều này bằng cách làm mới dữ liệu (nghĩa là loại bỏ ảnh chụp nhanh của bạn và sao chép lại định kỳ - điều này có thể xảy ra một cách tự nhiên và hữu cơ cho một môi trường triển khai liên tục tốt) Hoặc bằng cách chia nhỏ âm lượng (được gọi là "Chia tách Flex" trong thuật ngữ NetApp ) sẽ mất một chút thời gian để giải quyết vĩnh viễn các vùng đồng bằng và tạo ra một khối lượng hoàn toàn mới và riêng biệt.

Các bản sao delta này có thêm lợi ích là giảm yêu cầu lưu trữ tổng thể của bạn - bạn có thể sinh ra một số bản sao hoặc dữ liệu cơ sở dữ liệu sản xuất của mình để thực hiện phát triển, kiểm tra và xác thực. Nếu bạn chỉ giữ một bản sao của tập dữ liệu lớn của bạn cộng với các đồng bằng nhỏ (có khả năng là), bạn sẽ giảm chi phí lưu trữ và dấu chân tổng thể.

Thủ thuật duy nhất ở đây là điều này có thể không tạo thành một giải pháp sao lưu đầy đủ vì "bản sao lưu" vẫn còn trên trình quay của bạn. Để làm điều này, bạn có thể cần sử dụng một cái gì đó mà NetApp gọi là Snap Mirror sẽ phản chiếu dữ liệu (sử dụng công nghệ kiểu rsync) giữa các trình quay phim và thậm chí các trung tâm dữ liệu hoặc sử dụng một số loại giải pháp sao lưu tích hợp có thể sao lưu vào một trong các ảnh chụp nhanh delta của bạn hoặc một flex-clone.

Tuy nhiên, điều này có một lỗ hổng lớn: Tất cả dữ liệu của bạn - dev, test và prod vẫn đang sử dụng I / O trên cùng một bộ lưu trữ và đầu lưu trữ. Để giải quyết vấn đề này, hãy xem xét việc tạo một cá thể cơ sở dữ liệu nô lệ trên trình quay thứ hai có thể là điểm gieo mầm cho bạn Kiểm tra và / hoặc trình ghi dev, hoặc xem xét sử dụng bộ điều khiển phân phối tải / bộ điều chỉnh tải cho lớp ứng dụng của bạn để phản ánh các yêu cầu sản xuất vào thử nghiệm (và / hoặc dev) môi trường (s). Điều này có thêm lợi ích của việc ném lưu lượng truy cập dự phòng vào môi trường QA / Test của bạn trước khi quảng bá đến sản xuất cho các vấn đề có thể không được chú ý ngay lập tức. Sau đó, bạn có thể kiểm tra nhật ký của mình để tìm lỗi dựa trên lưu lượng sản xuất và hành vi người dùng.

Điều này sau đó sẽ cho phép bạn sử dụng một vài tập lệnh để lập trình và phá hủy toàn bộ bộ dữ liệu (và lớn) để sử dụng với các phương pháp triển khai liên tục.

Khả năng mở rộng và tính sẵn sàng cao

Trong khi bạn hỏi về việc triển khai liên tục, DevOps được coi là không chỉ triển khai liên tục - vì vậy tôi sẽ đưa vào một số bit về sự dư thừa, khả năng mở rộng và tính sẵn sàng cao.

Tôi đã đề cập, JIT, tính nhất quán ngay lập tức và cuối cùng. Đây là nơi mà các công cụ RDBMS đa dạng xuất hiện. Tính nhất quán cuối cùng tương đối dễ dàng bằng cách cấu hình sao chép không đồng bộ tròn. Tuy nhiên, điều này có thể gây ra một số xung đột * (nếu lớp ứng dụng của bạn cập nhật dữ liệu ở một bên của cụm và ở phía bên kia của cụm trước khi sao chép hoàn tất thì sao?) Để xem xét cụm sao Galera sẽ bắt buộc sao chép đồng bộ, nhưng gây ra các vấn đề về khả năng mở rộng (làm thế nào bạn sẽ sao chép vào trang web Phục hồi thảm họa hoặc cân bằng tải theo địa lý mà không phát sinh độ trễ đáng kể do độ trễ di chuyển ở lớp mạng?) Bạn cũng có thể xem liệu bạn có thể sao chép đồng bộ trong trung tâm dữ liệu và sao chép không đồng bộ giữa các trang web không, nhưng điều này có vẻ tồi tệ nhất của cả hai thế giới.

Tuy nhiên, thông thường, hầu hết các poeple không cần sao chép hoàn toàn đồng bộ - điều này thường chỉ cần thiết cho các môi trường viết cao rất cụ thể (và kỳ lạ), trong đó cần có nhiều bậc thầy với shending bảng. Hầu hết các ứng dụng có thể xử lý tính nhất quán Chỉ trong thời gian bằng proxy cơ sở dữ liệu. Ví dụ, ScaleArc sẽ theo dõi trạng thái sao chép và theo dõi nơi ghi vừa đi (để gửi các yêu cầu đọc không cần thiết cho đến khi sao chép bắt kịp) để cung cấp tính nhất quán đúng lúc và sự xuất hiệntính nhất quán của cơ sở dữ liệu. ScaleArc tương thích với Postgres, MySQL, MariaDB, Oracle và MSSQL và có thể sử dụng các biểu thức thông thường để phân đoạn / phân vùng cơ sở dữ liệu của bạn cho các ứng dụng không thể sử dụng khóa shard. Nó cũng có API REST mạnh mẽ để phần mềm quản lý cấu hình của bạn tương tác - và nhóm hỗ trợ của họ rất nổi bật

Tương tự, bạn có thể muốn xem xét một giải pháp thay thế miễn phí, MaxScale được phát triển bởi nhóm MariaDB cho MariaDB. Tuy nhiên, nó thiếu GUI và một số tính năng lưu trữ của ScaleArc.

Cuối cùng, cấu trúc MySQL (và cụm MySQL chỉ trong RAM - nếu bạn có đủ khả năng cung cấp nhiều RAM đó) là những tiềm năng khác - đặc biệt là với proxy mới của MySQL. Điều này có thể cung cấp khả năng mở rộng và dự phòng cho môi trường của bạn.

Postgres và Oracle sẽ có các tính năng sao chép và shending bạn cần, nhưng ScaleArc sẽ kết hợp tốt nếu bạn cần proxy.

Cuối cùng, tất cả các mẫu này bổ sung vào một môi trường rất linh hoạt phù hợp để triển khai và phát triển liên tục nếu bạn không thể đơn giản sử dụng môi trường dựa trên đám mây và để nhà cung cấp đám mây của bạn giải quyết các vấn đề trên cho bạn.

Chúng tôi sử dụng Flyway tại nơi làm việc để quản lý các lược đồ Postgres trong ứng dụng và Trụ cột để quản lý các lược đồ Cassandra. Chúng tôi đã tìm thấy nó tốt nhất nếu ứng dụng quản lý lược đồ riêng của mình.

Chúng tôi đã có một trải nghiệm khủng khiếp khi có các lược đồ quản lý ansible trước khi các ứng dụng quản lý các lược đồ của riêng họ.

Tôi muốn tranh luận một công cụ sẽ không thực sự giúp ích trừ khi bạn chuyển trách nhiệm lược đồ sang nhóm ứng dụng.

Chúng tôi sử dụng chất lỏng hoặc đường bay tại nơi làm việc, nơi nhóm ứng dụng chịu trách nhiệm tạo ra các thay đổi.

Cùng với điều này, bạn có thể tránh một cách hoàn toàn phụ gia.
Mỗi ứng dụng được yêu cầu phải tương thích với phiên bản tiền lệ của nó, khi phải thực hiện thay đổi lược đồ, thì ứng dụng sẽ tích hợp một cột mới trong lược đồ, ghi vào đó và vẫn đọc và ghi từ / đến cột trước đó (cho phép phiên bản trước vẫn có cùng dữ liệu).
Phiên bản tiếp theo của ứng dụng được phép dừng cập nhật cột cũ và chỉ phiên bản thứ ba mới được phép xóa cột hiện không được sử dụng.

Rõ ràng, sao lưu thường xuyên là cần thiết trong trường hợp xảy ra sự cố.
Một tập hợp con dữ liệu thích hợp có khả năng tạo ra các vấn đề trong các thử nghiệm tích hợp để tránh chúng trong sản xuất cũng là một ý tưởng tốt. Trường hợp lý tưởng có được một tập hợp con ẩn danh của dữ liệu sản xuất.

Chúng tôi sử dụng chất lỏng trong công việc của mình và tôi sẽ nói rất nhiều về nó. Nó cũng được sử dụng bởi công cụ QA của chúng tôi QASymphony .

Chúng tôi đang sử dụng nó để chống lại cơ sở dữ liệu MSSQL và Oracle trong nội bộ và QASymphony sử dụng / đã sử dụng nó với cả hai trường hợp postgres + mysql.

Để trả lời câu hỏi này trong bối cảnh môi trường máy tính lớn và cụ thể cho cơ sở dữ liệu DB2®, thường có 2 lựa chọn thay thế thường được sử dụng (không rẻ ...) để chọn:

• Quản trị đối tượng cho DB2® , từ BMC. Dưới đây là một số chi tiết về nó (trích dẫn từ trang được liên kết):

  Thực hiện các thay đổi đối với các đối tượng trong cơ sở dữ liệu của bạn, hoặc thậm chí chỉ thực hiện các tác vụ quản trị thông thường, có thể rất khó khăn, rủi ro. Có hàng tá nhiệm vụ cần theo dõi và một bước sai lầm có thể có tác động tai hại đến tính khả dụng và tính toàn vẹn dữ liệu. Bạn có thể cắt giảm cả nỗ lực và rủi ro với Quản trị đối tượng BMC cho DB2 11, một bộ công cụ để giúp bạn:

  • Giảm thời gian cần thiết để quản trị các môi trường DB2 phức tạp và khác biệt.
  • Tự động hóa các tác vụ thông thường trong suốt vòng đời ứng dụng để cải thiện tính toàn vẹn.
  • Cải thiện năng suất với điều hướng danh mục DB2 đơn giản và quản lý thay đổi.
  • Tăng cường khả năng sẵn sàng của ứng dụng bằng cách thực hiện các thay đổi và bảo trì với thời gian ngừng hoạt động tối thiểu.

• Công cụ quản trị DB2 cho z / OS , từ IBM.

  Nó đơn giản hóa các nhiệm vụ phức tạp liên quan đến việc quản lý các đối tượng và lược đồ DB2 một cách an toàn trong suốt vòng đời của ứng dụng với tác động ít nhất có thể đến tính khả dụng.

  • Cho phép người dùng điều hướng danh mục DB2 nhanh chóng và dễ dàng
  • Xây dựng và thực thi các câu lệnh SQL động mà không biết cú pháp SQL chính xác
  • Quản lý và theo dõi các thay đổi được thực hiện đối với các định nghĩa đối tượng DB2 giải quyết bất kỳ xung đột tiềm năng nào trước khi thực hiện
  • Giúp xây dựng các lệnh DB2 để thực thi đối với cơ sở dữ liệu và bảng
  • Cho phép người dùng tạo, thay đổi, di chuyển, thả và đảo ngược các đối tượng DB2
  • Xây dựng và thực thi các công việc tiện ích, cho phép người dùng tận dụng LISTDEFs và TEMPLATE để tăng năng suất

Tích hợp với các công cụ SCM

Cách đây một thời gian, tôi đã bị một khách hàng thách thức thực sự "tích hợp" thay thế BMC trong vòng đời SCM của họ (được quản lý bởi SERENA ChangeMan ZMF ). Ý tưởng đằng sau sự tích hợp đó là " Hãy xem nhóm DBA DB2 của chúng tôi (làm công cụ với DDL) như một trường hợp đặc biệt của nhóm phát triển, vô tình sử dụng một trình soạn thảo kỳ lạ (công cụ BMC) để tạo mã (DDL) để được di chuyển ".

Về thách thức duy nhất (nhưng thực tế !) Về việc tích hợp này là cũng tạo điều kiện cho "khả năng khởi động lại", một trong những lợi ích chính của công cụ DBA đó:

• Khả năng khởi động lại có nghĩa là khi công cụ DBA này đang thực hiện công việc của mình (thông qua các công việc đôi khi chạy dài, theo tính chất của công việc cần hoàn thành), những điều bất ngờ có thể xảy ra (bế tắc, mất thời gian, v.v.).

• Nếu bất kỳ điều nào trong số đó xảy ra và bạn không muốn khởi động lại từ bản sao lưu của mình (trước khi bạn bắt đầu), thì công cụ DBA mong bạn khởi động lại từ điểm (kiểm tra) từ đó mọi thứ bắt đầu sai (và từ đâu bạn muốn mọi thứ được thực hiện lại).

• Vẫn tốt hơn (hay tôi nên nói "thậm chí tệ hơn"?), Nếu một người mới sử dụng công cụ DBA không thực sự biết cách khởi động lại từ điểm kiểm tra đó và chỉ cần thử lại (từ đầu), thì công cụ DBA sẽ đơn giản thất bại với một số loại lỗi người dùng. Và điều này với một dấu hiệu với nội dung như " Cho đến khi bạn cho tôi biết bạn muốn tôi tiến hành như thế nào sau điểm thất bại cuối cùng của tôi, tôi từ chối làm bất cứ điều gì (để không làm mọi thứ trở nên tồi tệ hơn) ".

• Cuối cùng, manh mối thực sự để thực hiện khả năng khởi động lại này trong công cụ SCM đang được sử dụng, cũng yêu cầu công cụ SCM phải được điều chỉnh. Trên thực tế để cho phép nó được sử dụng để khởi động lại các quy trình SCM không thành công (thường liên quan đến việc giao hàng đến môi trường thử nghiệm / prod đích) ... thay vì chỉ gửi lại quy trình SCM thất bại (đó là cách mà các công cụ SCM đó phục hồi từ các tình huống như vậy ).

Phần thưởng: sau khi tích hợp SCM của phương án BMC hoàn tất, khách hàng đã quyết định thay đổi công cụ DBA của họ thành công cụ thay thế IBM. Và mặc dù cả hai lựa chọn thay thế đều không thực sự giống nhau, nhưng tác động của nó đối với việc tích hợp SCM là khá nhỏ: chỉ đơn giản là vấn đề thay thế (trong một số tùy chỉnh SCM có thể sử dụng lại) một số cuộc gọi tới BMC bằng các cuộc gọi tương đương với IBM thay thế ... mà (sử dụng thuật ngữ DevOps) đã được triển khai bằng các tính năng cờ / tính năng-toggles .