Tôi đang tham gia một chủ đề gần đây trên cộng đồng OTN, nơi ai đó đặt câu hỏi về việc hạ cấp sau khi nâng cấp cơ sở dữ liệu. Một trong những câu trả lời đã hỏi có bao nhiêu người thực sự thực hành hạ cấp cơ sở dữ liệu. Tôi đã tạo cuộc thăm dò này để tìm hiểu.
Tôi rất ngạc nhiên khi tìm thấy một đóng góp cho chuỗi đó có nội dung:
Bây giờ người đăng đó không nói rõ điều đó, nhưng có vẻ như cá nhân đó đang nói rằng thực hành hạ cấp là một việc lãng phí thời gian bởi vì họ sẽ không bao giờ cần đến nó. Tôi sẽ cung cấp cho người đăng bài về lợi ích của sự nghi ngờ và rằng nhân viên Oracle này không thực sự nói điều này. Tôi không cố gắng chọn người này. Tôi sẽ để chủ đề này cho tôi cơ hội thảo luận về chủ đề từ một quan điểm chung chung hơn. (Cập nhật:người đăng bài nhắc tôi viết mục blog này đã quay lại chủ đề trong thời gian tôi viết bài này và đã nói, "không có ý ám chỉ rằng chúng ta không nên 'kiểm tra' việc hạ cấp.")
Trở lại tháng 7, tôi đã viết một bài đăng trên blog về The Data Guardian. Trong bài đăng trên blog đó, tôi đã nói:
DBA cần bảo vệ dữ liệu. Đó là công việc số 1. Công việc số 2 là dành cho DBA để cung cấp quyền truy cập hiệu quả và kịp thời vào dữ liệu. Có lợi gì khi có dữ liệu nếu những người cần truy cập vào nó không thể truy cập vào dữ liệu? Nếu những người đó có hiệu suất khủng khiếp khi tương tác với dữ liệu, thì họ cũng có thể không có quyền truy cập.
Với tư cách là DBA, chúng ta cần thực hiện quản lý rủi ro. Chúng ta cần xác định những rủi ro nào có thể trở thành hiện thực. Công việc của các DBA là đo lường những rủi ro đó và xác định hai kế hoạch hành động. Những bước nào có thể được thực hiện để tránh rủi ro đó trở thành hiện thực và tôi cần thực hiện những bước nào để giải quyết vấn đề khi rủi ro đó trở thành hiện thực?
Ngay cả một DBA cấp cơ sở cũng sẽ hiểu tầm quan trọng của các bản sao lưu. Sao lưu là một chiến lược quản lý rủi ro. Nếu dữ liệu bị mất, chúng tôi có thể khôi phục dữ liệu từ bản sao lưu. Và ngay cả một DBA cấp cơ sở cũng hiểu tầm quan trọng của việc có thể khôi phục từ bản sao lưu.
Trong chuỗi OTN này, tôi đã viết thế này:
Đối với tôi, đây là một dạng của Định luật Murphy. Tôi đã từng nói những điều tương tự trong quá khứ. Ý tưởng (và toàn bộ điểm của bài viết này) là nếu tôi không thực hiện các bước quản lý rủi ro thích hợp, thì tôi chỉ cầu thần linh biến rủi ro đó thành hiện thực. Nếu tôi từ chối điều chỉnh gương chiếu hậu của mình và sử dụng nó khi tôi đang lùi xe, thì đó là ngày tôi trở lại với một thứ gì đó. Nếu tôi từ chối buộc dây giày, thì đó là ngày tôi bước vào một chuyến đi. Ngày tôi từ chối đeo kính bảo vệ khi sử dụng powertool là ngày tôi bị thứ gì đó vào mắt. Ngày tôi đi biển và từ chối phơi nắng là ngày tôi trở về nhà với vết cháy nắng. Bạn có ý tưởng.
Một số độc giả có thể nghĩ rằng tôi điên và vũ trụ không có kế hoạch tổng thể này để làm khó tôi chỉ vì tôi tự mãn. Và tôi sẽ đồng ý. Vì vậy, tôi sẽ nói theo cách khác, nếu tôi không có kế hoạch giảm thiểu rủi ro, thì tôi đã không làm gì để ngăn điều đó trở thành hiện thực. Cơ hội để nó trở thành hiện thực không giảm vì tôi không hành động.
Có hai thành phần chính để quản lý rủi ro. 1) xác định xác suất xảy ra khoản mục rủi ro đó và 2) xác định tác động khi rủi ro đó xảy ra. Các mục có xác suất cao nhất của việc xảy ra được giảm thiểu đầu tiên. Điều này rất dễ dàng và là điều mà nhiều người làm việc về quản lý rủi ro thường làm. Họ đưa các hạng mục rủi ro vào một bảng tính và điền vào một số giá trị xác suất rủi ro đó xảy ra. Khi hoàn thành, họ sắp xếp trên cột xác suất và bắt đầu giảm thiểu rủi ro từ trên xuống. Nhiều chiến lược quản lý rủi ro vẽ một dòng ở đâu đó giữa danh sách và quyết định bất kỳ mục rủi ro nào bên dưới dòng đó có xác suất quá thấp mà chúng tôi sẽ không lo lắng về mục rủi ro đó. Chúng ta không thể giảm thiểu tất cả các rủi ro có thể xảy ra trong vũ trụ. Không có đủ thời gian để giải quyết tất cả. Vì vậy, chúng ta phải vẽ đường ở đâu đó.
Một trong những thất bại mà tôi luôn thấy là quản lý rủi ro không dành nhiều thời gian tập trung vào tác động nguy cơ đó trở thành hiện thực. Bảng tính cần bao gồm một cột tương tự cung cấp xếp hạng về tác động đối với doanh nghiệp đối với hạng mục rủi ro đó. Người quản lý rủi ro cũng cần sắp xếp bảng tính trên cột này. Bất kỳ hạng mục nào có ảnh hưởng lớn đều cần có các hoạt động giảm thiểu rủi ro ngay cả khi hạng mục đó có xác suất xảy ra thấp! Đáng buồn thay, có quá nhiều người trong lĩnh vực kinh doanh quản lý rủi ro không bao gồm bước đánh giá tác động rủi ro này. Một lần nữa, khi bảng tính được sắp xếp theo mức độ ảnh hưởng đến hoạt động kinh doanh, một đường thẳng sẽ được vẽ ở đâu đó.
Người ta có thể thấy rằng các hạng mục rủi ro với xác suất CAO có tác động THẤP hoặc thậm chí RẤT THẤP cho doanh nghiệp. Tôi thích bảng tính quản lý rủi ro bao gồm cột thứ ba là "xác suất x tác động". Cột này giúp hiểu mối quan hệ giữa hai thành phần rủi ro.
Hãy quay lại câu hỏi nâng cấp cơ sở dữ liệu đã tạo ra bài đăng trên blog này. Tôi nghĩ rằng tất cả mọi người đang đọc bài viết trên blog này nên đồng ý rằng việc nâng cấp cơ sở dữ liệu Oracle là một đề xuất mạo hiểm. Có rất nhiều điều khác nhau có thể xảy ra với việc nâng cấp cơ sở dữ liệu Oracle. Xác suất của lỗi nâng cấp là CAO. Các hạng mục giảm thiểu rủi ro thường bao gồm, nhưng không giới hạn, thực hành nâng cấp trên bản sao của sản xuất và sao lưu cơ sở dữ liệu trước khi quá trình nâng cấp bắt đầu. Tại sao chúng ta làm việc này? Chà tác động đối với doanh nghiệp là RẤT CAO. Nếu chúng tôi không thành công khi nâng cấp cơ sở dữ liệu sản xuất của mình, thì người dùng doanh nghiệp của chúng tôi không có quyền truy cập vào dữ liệu. Chúng tôi không phải là người bảo vệ dữ liệu tốt nếu chúng tôi không thể vượt qua thất bại này. Nếu chúng tôi thực hành nâng cấp đầy đủ trong môi trường phi sản xuất, chúng tôi có thể giảm xác suất của hạng mục rủi ro xuống TRUNG BÌNH. Nhưng trong tất cả các khả năng, chúng ta không thể giảm xác suất rủi ro cụ thể đó xuống THẤP. Đó là lý do tại sao chúng tôi thực hiện sao lưu trước khi bắt đầu nâng cấp. Sẽ vẫn gặp sự cố ngay cả khi chúng tôi đã cố gắng hết mức để giảm xác suất của hạng mục rủi ro đó, tác động cho doanh nghiệp vẫn còn RẤT CAO. Vì vậy, chiến lược khắc phục rủi ro của DBA là ghi lại vị trí và nguyên nhân khiến quá trình nâng cấp không thành công và khôi phục từ bản sao lưu. Cơ sở dữ liệu đang hoạt động và chúng tôi đã loại bỏ tác động cho doanh nghiệp. Sau đó, DBA quay lại bảng vẽ để xác định cách giải quyết những gì đã xảy ra. DBA đang cố gắng giảm xác suất vấn đề đó lại xảy ra khi họ quay lại vào một thời điểm sau đó để thực hiện lại quá trình nâng cấp.
Vì vậy, hãy quay trở lại nhận xét trong chuỗi OTN, nơi có vẻ như nói rằng thực hành hạ cấp cơ sở dữ liệu là không đáng để dành thời gian. Tôi không đồng ý. Và sự không đồng ý của tôi có liên quan đến mọi thứ liên quan đến tác động cho doanh nghiệp. Tôi đồng ý với nhận xét mà người đăng đã nói trong câu trả lời của họ.
Tôi đồng ý với điều đó 100%. Tại sao chúng tôi thực hiện “kiểm tra kỹ lưỡng” này? Tất cả là vì giảm thiểu rủi ro. Chúng tôi đang cố gắng giảm xác suất rằng việc nâng cấp sẽ gây ra hiệu suất kém hoặc khiến chức năng ứng dụng bị hỏng. Nhưng ngay cả khi người đăng đó nói, "Sẽ luôn có vấn đề xuất hiện trong quá trình sản xuất sau khi nâng cấp vì không thể kiểm tra 100% ứng dụng của bạn." Một lần nữa, tôi đồng ý 100% với những gì người đăng này đang nói ở đây. Nhưng còn về tác động cho doanh nghiệp? Tôi sẽ hoàn thành điều đó sau một phút, nhưng trước tiên tôi phải lạc đề một chút trong đoạn tiếp theo này…
Gần đây, tôi đã nâng cấp hệ thống sản xuất quan trọng từ 11.2.0.4 lên phiên bản 12.1.0.2. Ở nơi tôi làm việc, chúng tôi có nhiều thử nghiệm ứng dụng hơn tôi từng thấy trong các công việc khác của mình. Chúng tôi có đầy đủ nhóm QA thực hiện thử nghiệm cho chúng tôi. Chúng tôi thậm chí còn có một nhóm phụ trách các nỗ lực kiểm tra tự động của chúng tôi. Chúng tôi có các rô bốt tự động thực hiện mã ứng dụng của chúng tôi hàng đêm. Trên hết, chúng tôi có một quy trình tự động khác mà bất cứ khi nào mọi người đẩy các thay đổi mã sang Thử nghiệm hoặc Sản phẩm, quy trình này sẽ kiểm tra nhanh các đường dẫn mã quan trọng. Tôi đã nâng cấp các môi trường phát triển (hơn 15 trong số đó) lên 12.1.0.2 và sau đó đợi một tháng. Sau đó, tôi đã nâng cấp Thử nghiệm và đợi 3 tuần trước khi nâng cấp sản xuất. Đã tìm thấy và giải quyết các vấn đề trước khi chúng tôi nâng cấp sản xuất. Nhưng ngay cả sau tất cả những điều đó, tôi vẫn gặp vấn đề lớn khi quá trình sản xuất được nâng cấp. Bạn có thể truy cập các bài đăng trên blog của tôi vào giữa tháng 10 đến giữa tháng 12 để xem một số vấn đề đó. Tôi đã rất gần với việc hạ cấp cơ sở dữ liệu này nhưng thay vào đó, tôi đã cố gắng giải quyết các vấn đề. Bây giờ quay lại vấn đề tôi đã làm…
Sau khi nâng cấp xong, cơ sở dữ liệu sẽ được mở cho doanh nghiệp. Người dùng ứng dụng bây giờ được phép sử dụng ứng dụng. Điều gì xảy ra bên trong cơ sở dữ liệu tại thời điểm này? Giao dịch! Và giao dịch có nghĩa là thay đổi dữ liệu. Tại thời điểm DBA mở cơ sở dữ liệu cho doanh nghiệp sau khi nâng cấp hoàn tất, các thay đổi dữ liệu bắt đầu xảy ra. Sau tất cả, đó là toàn bộ điểm của cơ sở dữ liệu, phải không? Nắm bắt các thay đổi dữ liệu và cung cấp dữ liệu cho người dùng cuối của ứng dụng.
Vì vậy, điều gì sẽ xảy ra nếu bạn đang ở trong chiếc thuyền mà tôi đã ở vào Mùa thu năm ngoái với bản nâng cấp cơ sở dữ liệu của mình? Tôi đã đánh trúng những thứ mà chúng tôi không thấy trong phiên bản phi sản xuất, ngay cả sau tất cả các thử nghiệm của chúng tôi. Tác động cho doanh nghiệp là CAO. Tôi cần có thể giảm tác động này đến doanh nghiệp. Tôi đã có ba lựa chọn. 1) Khắc phục từng vấn đề một. 2) Khôi phục từ bản sao lưu tôi đã thực hiện trước khi nâng cấp để tôi có thể lấy lại cơ sở dữ liệu về phiên bản cũ. 3) Hạ cấp cơ sở dữ liệu và quay lại bảng vẽ. Tôi đã chọn tùy chọn đầu tiên. như tôi luôn làm trong suốt sự nghiệp của mình. Nhưng nếu điều đó không đủ thì sao? Có thể mất thời gian để giải quyết các vấn đề. Một số doanh nghiệp chỉ đơn giản là không thể dành được loại thời gian đó với tác động tiêu cực đó cho doanh nghiệp. Có bao nhiêu trang web đã bị bỏ rơi vì hiệu suất quá tệ hoặc mọi thứ không hoạt động chính xác? Và đối với phần lớn cơ sở dữ liệu sản xuất hiện có, tùy chọn 2 có một tác động rất khủng khiếp cho doanh nghiệp! Bạn sẽ mất các giao dịch sau khi nâng cấp hoàn tất! DBA sẽ không thể tiếp tục nâng cấp trong khi vẫn giữ cơ sở dữ liệu ở phiên bản cũ, vì vậy dữ liệu sẽ bị mất và đối với nhiều cơ sở dữ liệu sản xuất, điều này là không thể chấp nhận được. Doanh nghiệp có thể chịu được một giờ mất dữ liệu, nhưng có bao nhiêu người kích hoạt hành động này trong vòng một giờ sau khi nâng cấp? Trong tất cả các khả năng, hành động này sẽ được thực hiện vài ngày sau khi nâng cấp và tác động đối với doanh nghiệp đối với loại mất mát dữ liệu đó là trên RẤT CAO. Vì vậy, tùy chọn 3 là tùy chọn có tác động thấp nhất cho doanh nghiệp để giúp giải quyết bất kỳ tác động nào mà doanh nghiệp đang gặp phải sau khi nâng cấp.
Bạn có thể nói từ đoạn cuối rằng tôi cảm thấy rằng điều quan trọng đối với Oracle DBA là phải biết cách hạ cấp cơ sở dữ liệu của họ sau khi nâng cấp xong. Tôi sẽ thừa nhận rằng xác suất của DBA cần thực hiện hạ cấp là RẤT THẤP. Nhưng tác động của việc không hạ cấp có thể gây ra thảm họa cho doanh nghiệp. (Lại có hai từ đó). Vì xác suất thấp, tôi không hạ cấp thường xuyên mà do tác động không có khả năng hạ cấp là rất cao, tôi thực hành chúng một lần trong một thời gian.
Vì vậy, để kết thúc, tôi sẽ quay lại vấn đề Định luật Murphy một lần nữa. Vũ trụ không âm mưu chống lại tôi, nhưng với tư cách là Người bảo vệ dữ liệu, tôi cần thực hành các nguyên tắc quản lý rủi ro tốt. Điều đó có nghĩa là đánh giá xác suất và tác động của các hạng mục rủi ro do thay đổi của tôi áp đặt. Mặc dù vũ trụ và các vị thần có thể không làm cho Định luật Murphy hoặc những người anh em họ của nó thành công, nhưng tôi sẽ không ủng hộ bản thân bằng cách giảm thiểu các hạng mục rủi ro. Tôi không giảm xác suất một chút nào.
