Tạo trường hợp cho dịch vụ SQL Server thông thường

Đã có một số tranh cãi đang diễn ra trong cộng đồng SQL Server về sự khôn ngoan của việc cài đặt Gói dịch vụ (SP) và Cập nhật tích lũy (CU) cho SQL Server. Có một số vị trí cơ bản khác nhau mà các tổ chức thường có xu hướng đảm nhận chủ đề này, như được liệt kê bên dưới:

1. Tổ chức cài đặt các Gói dịch vụ và Cập nhật tích lũy một cách thường xuyên
2. Tổ chức cài đặt Gói dịch vụ, nhưng không cài đặt Bản cập nhật tích lũy
3. Tổ chức không cài đặt Gói dịch vụ hoặc Bản cập nhật tích lũy

Trường hợp đầu tiên là một tổ chức sẽ cố gắng duy trì tính cập nhật hợp lý với cả Gói dịch vụ SQL Server và Bản cập nhật tích lũy SQL Server bằng cách sử dụng quy trình triển khai và kiểm tra kỹ lưỡng. Đây là chính sách tốt nhất theo ý kiến ​​của tôi. Quan điểm của tôi là tổ chức của bạn được phục vụ tốt hơn nhiều bằng cách luôn cập nhật cả Gói dịch vụ và Cập nhật tích lũy (miễn là bạn có các quy trình thử nghiệm và triển khai cũng như cơ sở hạ tầng cần thiết để hỗ trợ chính sách đó).

Trường hợp thứ hai là một tổ chức sẽ (có thể sau một thời gian trì hoãn), cài đặt Gói dịch vụ SQL Server, nhưng họ sẽ không cài đặt Bản cập nhật tích lũy SQL Server vì bất kỳ lý do gì. Điều này không tốt bằng trường hợp đầu tiên, nhưng tốt hơn nhiều so với trường hợp thứ ba.

Trong trường hợp thứ ba, một số tổ chức không bao giờ cài đặt bất kỳ Gói dịch vụ SQL Server hoặc Bản cập nhật tích lũy SQL Server nào, vì bất kỳ lý do gì. Trong một số trường hợp, chúng thực sự ở trên bản phát hành ban đầu cho phiên bản sản xuất (RTM) của phiên bản SQL Server chính mà chúng đang chạy, trong suốt thời gian hoạt động của phiên bản này. Đây là chính sách ít được mong muốn nhất, vì một số lý do.

Microsoft có chính sách gỡ bỏ các nhánh mã (nhánh RTM hoặc nhánh Gói dịch vụ tiếp theo) cho một phiên bản SQL Server cụ thể khi nó đã cũ hai nhánh. Ví dụ:khi SQL Server 2008 R2 Gói Dịch vụ 2 được phát hành, nhánh RTM ban đầu (bất kể mức CU) đã bị gỡ bỏ và nó trở thành “gói dịch vụ không được hỗ trợ”. Điều này có nghĩa là sẽ không còn các bản cập nhật nóng hoặc Cập nhật tích lũy cho nhánh đó và bạn sẽ chỉ nhận được hỗ trợ khắc phục sự cố có giới hạn từ Microsoft CSS trong một trường hợp hỗ trợ cho đến khi bạn cài đặt gói dịch vụ được hỗ trợ trên phiên bản của mình.

Các lý do khiến việc bảo trì SQL Server bị trì hoãn

Trong một số trường hợp, một tổ chức có thể không biết về cách SQL Server thường được phục vụ với sự kết hợp của Gói dịch vụ, Bản cập nhật tích lũy và Bản vá lỗi nóng. Nhiều tổ chức có các chính sách cứng nhắc từ trên xuống về cách họ duy trì và dịch vụ các sản phẩm như SQL Server, điều này loại trừ việc cài đặt thường xuyên SP và / hoặc CU của quản trị viên cơ sở dữ liệu. Họ cũng có thể bị hạn chế phục vụ các phiên bản SQL Server của họ do thực tế là họ đang sử dụng cơ sở dữ liệu của bên thứ ba chỉ được nhà cung cấp hỗ trợ với phiên bản do nhà cung cấp chỉ định và các mức Gói dịch vụ của SQL Server.

Nhiều tổ chức cũng có thể hiểu được nỗi sợ “phá vỡ” một phiên bản SQL Server hoặc một ứng dụng phụ thuộc vào phiên bản đó. Họ cũng có thể thiếu thời gian và tài nguyên để thực hiện kiểm tra hệ thống và ứng dụng ở mức độ thích hợp sau khi cài đặt phiên bản SQL Server cập nhật trên một phiên bản trong môi trường kiểm tra. Trong một số trường hợp, họ có thể không có môi trường thử nghiệm chuyên dụng (đây là một vấn đề chính, riêng biệt).

Một số tổ chức có thể không có giải pháp khả dụng cao đang hoạt động (chẳng hạn như phân cụm dự phòng truyền thống, phản chiếu cơ sở dữ liệu hoặc các nhóm khả dụng) trong môi trường Sản xuất của họ, vì vậy họ do dự nhiều hơn trong việc thực hiện bất kỳ loại dịch vụ nào có thể gây ra máy chủ cơ sở dữ liệu khởi động lại và gây ra tình trạng ngừng hoạt động tương đối lâu. Họ thực sự có thể có sẵn một giải pháp có tính khả dụng cao, nhưng họ hiếm khi kiểm tra nó khi sản xuất bị lỗi và họ có thể ít tin tưởng hơn vào hoạt động và độ tin cậy của nó.

Những lý do nên thường xuyên bảo trì SQL Server

Sau khi liệt kê một số lý do phổ biến tại sao các tổ chức có thể chọn không sử dụng SQL Server thường xuyên, đã đến lúc giải quyết một số đối số này. Đầu tiên, sự thiếu hiểu biết về cách SQL Server thường được Microsoft cung cấp dịch vụ không thực sự là một lời bào chữa hợp lệ nữa. Microsoft có Blog dịch vụ phát hành SQL, nơi họ công bố cả Gói dịch vụ và Cập nhật tích lũy cho SQL Server. Matthias Bernt đã giải thích chiến lược bảo dưỡng chung cho SQL Server trong bài đăng của anh ấy:Một cách tiếp cận đã thay đổi đối với Gói dịch vụ, với thông tin chi tiết hơn về cách tiếp cận mô hình cung cấp dịch vụ gia tăng của SQL Server có sẵn trong bài viết cơ sở kiến ​​thức Micosoft này.

Phiên bản cô đọng của mô hình cung cấp dịch vụ là các sự cố SQL Server riêng lẻ được khắc phục bằng các bản sửa lỗi nóng. Bạn phải liên hệ với Microsoft CSS và mở trường hợp hỗ trợ để có quyền truy cập vào một hotfix riêng lẻ (trừ khi nó là một hotfix liên quan đến bảo mật, được đẩy ra bởi Microsoft Update). Tùy thuộc vào mức độ hỗ trợ trả phí của bạn với Microsoft, đây có thể là một quá trình tương đối tẻ nhạt và tốn thời gian. Ngoài ra còn có một vấn đề mà hầu hết khách hàng SQL Server thậm chí rất khó nhận biết được các bản sửa lỗi hiện có chưa được phát hành như một phần của Bản cập nhật tích lũy SQL Server. Điều này có nghĩa là hầu hết khách hàng không có khả năng nhận và triển khai các hotfix riêng lẻ một cách thường xuyên.

Cập nhật tích lũy là bản tổng hợp của một số hotfix (thường từ khoảng 10-50 hotfix) được phát hành tám tuần một lần. Các bản cập nhật tích lũy này thực sự là tích lũy (như tên của nó), vì vậy bạn sẽ nhận được tất cả các bản sửa lỗi đã phát hành trước đó cho phiên bản và nhánh của bạn (RTM, SP1, SP2, v.v.) của mã khi bạn cài đặt bản cập nhật tích lũy. Điều này có nghĩa là tuyên bố chung về các tổ chức “chỉ áp dụng Cập nhật tích lũy để khắc phục các vấn đề cụ thể mà họ đang gặp phải” thực sự không có giá trị đặc biệt trong cuộc sống thực.

Ví dụ:nếu bạn đang chạy bản dựng RTM của SQL Server 2012 Gói Dịch vụ 1 (11.0.3000) và bạn quyết định cài đặt SQL Server 2012 Gói Dịch vụ 1 Cập nhật Tích lũy 3 (11.0.3349) vì nó bao gồm một hotfix cho một vấn đề mà bạn thực sự gặp phải, bạn sẽ thực sự nhận được tất cả các hotfix cho SP1 CU1, SP1 CU2 và SP1 CU3, số lượng lên tới hơn 100 hotfix.

Như Microsoft tuyên bố về Bản cập nhật tích lũy:“Vì các bản dựng được tích lũy nên mỗi bản sửa lỗi mới chứa tất cả các bản sửa lỗi nóng và tất cả các bản sửa lỗi bảo mật được bao gồm trong bản phát hành bản sửa lỗi SQL Server 2012 SP 1 trước đó. Chúng tôi khuyên bạn nên xem xét áp dụng bản sửa lỗi gần đây nhất có chứa hotfix này. ” Về cơ bản, điều này có nghĩa là nếu bạn phát hiện ra một vấn đề cụ thể, có liên quan đã được khắc phục trong CU trước đó, bạn nên tiếp tục và triển khai CU có liên quan mới nhất trên hệ thống (cũng sẽ bao gồm hotfix đó).

Một lập luận mà tôi thường nghe về lý do tại sao các tổ chức không triển khai Cập nhật tích lũy là "chúng không được kiểm tra hồi quy hoàn toàn giống như Gói dịch vụ, vì vậy chúng tôi không triển khai chúng." Có một số giá trị trong quan điểm này, nhưng cũng có một quan niệm sai lầm phổ biến rằng Cập nhật tích lũy chỉ là đơn vị được thử nghiệm, không có bất kỳ thử nghiệm hồi quy nào. Đây không phải là trường hợp.

Tài liệu của Microsoft về Bản cập nhật tích lũy chỉ ra rằng vì họ “áp dụng thử nghiệm hồi quy gia tăng trong suốt chu kỳ phát triển, sau đó là 2 tuần thử nghiệm tập trung trong thời hạn phát hành 8 tuần, nên các quy trình đảm bảo chất lượng liên quan đến CU vượt quá quy trình của các hotfix riêng lẻ.” Điều này có nghĩa là bạn thực sự chịu ít rủi ro hơn bằng cách triển khai CU đã được kiểm tra hồi quy tăng dần và cũng đã có hai tuần kiểm tra tập trung so với khi bạn triển khai một hotfix chỉ được kiểm tra đơn vị.

Trong sáu đến bảy năm qua, cá nhân tôi đã triển khai rất nhiều Bản cập nhật tích lũy và Gói dịch vụ trên một số lượng lớn hệ thống chạy SQL Server 2005 đến SQL Server 2012 và tôi vẫn chưa gặp phải bất kỳ sự cố lớn nào. Tôi cũng chưa nghe thấy bất kỳ vấn đề phổ biến nào khi thực hiện loại công việc này được báo cáo trên blog, trên Twitter, v.v. Có thể là tôi (và mọi người tôi biết) vừa gặp may, hoặc có lẽ Cập nhật tích lũy và Gói dịch vụ không hoàn toàn rủi ro như một số người tin tưởng (miễn là bạn kiểm tra và triển khai chúng đúng cách).

Tầm quan trọng của kế hoạch kiểm tra và triển khai

Trừ khi bạn không bao giờ có kế hoạch thực hiện bất kỳ loại bảo trì máy chủ hoặc cập nhật ứng dụng nào cho vòng đời của hệ thống của mình (có vẻ như là một đề xuất khó xảy ra), bạn thực sự cần phát triển một số loại quy trình và kế hoạch thử nghiệm và triển khai mà bạn sẽ tuân theo như một phần thực hiện bất kỳ loại thay đổi nào đối với máy chủ.

Kế hoạch này có thể bắt đầu tương đối đơn giản, nhưng nó sẽ trở nên phức tạp và hoàn thiện hơn khi bạn trở nên có kinh nghiệm hơn với việc thường xuyên bảo dưỡng các phiên bản SQL Server của mình và áp dụng các bài học bạn học được với mỗi lần triển khai. Tốt nhất, bạn nên thực hiện theo kế hoạch này bất cứ khi nào bạn thực hiện thay đổi đối với hệ thống, nhưng điều đó có thể không thực hiện được trong mọi trường hợp.

Dưới đây là một số bước và thử nghiệm ban đầu cần có trong loại kế hoạch này.

1. Cài đặt CU trên máy ảo thử nghiệm
   1. CU có cài đặt mà không gặp bất kỳ sự cố hoặc lỗi nào không?
   2. Quá trình cài đặt CU có yêu cầu khởi động lại hệ thống không?
   3. Tất cả các dịch vụ SQL Server liên quan có khởi động lại sau khi cài đặt không?
   4. SQL Server có hoạt động bình thường sau khi cài đặt không?
2. Cài đặt CU trên một số hệ thống phát triển
   1. CU có cài đặt mà không gặp bất kỳ sự cố hoặc lỗi nào không?
   2. SQL Server có hoạt động bình thường trong quá trình sử dụng bình thường hàng ngày không?
   3. Các ứng dụng của bạn có hoạt động bình thường trong quá trình thử nghiệm đơn vị không?
3. Cài đặt CU trong môi trường tích hợp hoặc QA được chia sẻ
   1. Bạn có tuân theo một kế hoạch triển khai cụ thể và danh sách kiểm tra để cài đặt không?
   2. Tất cả các ứng dụng sử dụng SQL Server có vượt qua kiểm tra khói không?
   3. Tất cả các ứng dụng có vượt qua bất kỳ kiểm tra tự động nào mà bạn có sẵn không?
   4. Tất cả các ứng dụng có vượt qua kiểm tra chức năng thủ công chi tiết hơn không?
4. Cài đặt CU trong môi trường Sản xuất của bạn
   1. Sử dụng chiến lược nâng cấp luân phiên nếu có thể
   2. Sử dụng danh sách kiểm tra chi tiết, từng bước trong quá trình triển khai
   3. Cập nhật danh sách kiểm tra của bạn với các mục đã bỏ lỡ và bài học kinh nghiệm

Kết luận

Điều tôi hy vọng đạt được ở đây là thu hút nhiều chuyên gia cơ sở dữ liệu hơn bắt đầu hướng tới tư duy mà họ thực sự muốn thường xuyên duy trì các phiên bản SQL Server của mình, thay vì do dự hoặc sợ hãi khi làm điều đó. Điều này có thể liên quan đến một lượng lớn công việc bổ sung trong thời gian đầu, vì bạn có thể phải thuyết phục những người khác trong tổ chức của bạn thực hiện các kế hoạch của bạn. Bạn có thể phải thúc đẩy các bộ phận khác của tổ chức phát triển các kế hoạch kiểm tra tốt hơn và bạn sẽ phải xây dựng một danh sách kiểm tra việc thực hiện. Bạn cũng sẽ phải được doanh nghiệp ủy quyền cho thời gian bảo trì (thời gian này sẽ tương đối ngắn với các bản nâng cấp luân phiên), vì vậy bạn thực sự có thể nhận được các bản cập nhật được triển khai trên hệ thống Sản xuất của mình một cách thường xuyên.

Đổi lại với công việc làm thêm này, bạn sẽ có một hệ thống được bảo trì tốt hơn và ít gặp sự cố hơn trong tương lai. Bạn sẽ ở trong một cấu hình được hỗ trợ đầy đủ từ Microsoft và bạn sẽ tự tin hơn vào (các) công nghệ có tính khả dụng cao của mình, vì bạn sẽ thực sự sử dụng chúng một cách thường xuyên. Bạn cũng sẽ có được kinh nghiệm quý báu khi lập kế hoạch và thực hiện tất cả những điều này để cải thiện kỹ năng khắc phục sự cố của bạn trong tương lai.