Nhiều DBA ngày nay đang được yêu cầu đóng góp trong Văn hóa DevOps. Một DBA mà tôi biết đã kể cho tôi câu chuyện về một lần tái tổ chức gần đây mà công ty của anh ấy đã trải qua và khi họ gửi biểu đồ tổ chức mới, chức danh của anh ấy thực sự đã được đổi từ DBA thành kỹ sư DevOps. Anh ấy làm gì bây giờ khác với trước đây? Hóa ra là… Không nhiều. Hầu hết những gì anh ấy làm bây giờ vẫn vậy. Nhưng tủ của anh ấy hiện không có gì nổi bật đối với DevOps, vì vậy anh ấy đang rất coi trọng danh hiệu mới này.
Đây là sự thật - DBA luôn là một phần của DevOps. Đó là bởi vì hầu hết đã làm các nhiệm vụ Dev. Những việc như viết SQL, điều chỉnh hiệu suất SQL Server, thực hiện Phân tích đối tượng và báo cáo và họ đã thực hiện các tác vụ Ops như định cấu hình máy chủ, chạy sao lưu và khôi phục cũng như điều chỉnh hệ điều hành, mạng và lưu trữ.
Sự thay đổi chính là DevOps thường bắt các nhà phát triển ứng dụng chống lại các nhóm cơ sở hạ tầng về các vấn đề hiệu suất và ổn định. Nhà phát triển và Nhóm điều hành có các mức độ ưu tiên khác nhau đòi hỏi một hành động cân bằng tốt.
Có hai mặt của câu chuyện này. Nhà phát triển bên của ngôi nhà được đo lường về mức độ nhanh chóng và đáng tin cậy mà họ có thể nhận được những thay đổi trong sản xuất. Mục tiêu của họ là phát triển mã để thông số kỹ thuật càng nhanh càng tốt, đưa nó vào sản xuất và tiếp tục duy trì những thay đổi đó.
Hoạt động quan tâm đến việc đảm bảo rằng mọi thứ không bị vỡ khi bạn rời mắt khỏi chúng. Đó là về tất cả các nguyên tắc cơ bản giúp đèn luôn sáng và dữ liệu luôn hoạt động.
DBA có một vai trò lớn trong việc hợp nhất Dev và Ops. Trên thực tế, đó là cơ hội lớn cho các DBA phát triển vai trò mới nổi này của kỹ sư DevOps, bao gồm giám sát và tối ưu hóa hiệu suất máy chủ SQL.
Phần lớn DevOps dựa trên phương châm “Thất bại thường xuyên, thất bại nhanh chóng”. Thực hiện các thay đổi nhỏ, gia tăng và đẩy chúng vào sản xuất. Nếu chúng gây ra sự cố hoặc nếu chúng không hoàn toàn như những gì khách hàng mong muốn, hãy nhanh chóng khôi phục chúng, sửa chữa và nhanh chóng đưa chúng trở lại sản xuất.
Tuy nhiên, điều này tiềm ẩn những rủi ro thực sự…
Không phải lúc nào cũng dễ dàng hiểu được nguyên nhân gốc rễ của vấn đề về hiệu suất hoặc độ ổn định. Phải mất khá nhiều công sức để kết nối các điểm giữa một thay đổi mà ai đó đã thực hiện đối với ứng dụng hoặc cơ sở hạ tầng và tác động của nó đối với khối lượng công việc và hiệu suất của cơ sở dữ liệu.
Những khái niệm này hơi mới đối với DBA và nhiệm vụ gặp gỡ ở giữa để tham gia DevOps Culture có vẻ hơi quá sức. Nhưng, bạn phải bắt đầu từ đâu đó. Nhiều tổ chức đang áp dụng cách tiếp cận xem xét các vấn đề về hiệu suất máy chủ SQL từ một lăng kính khác và triển khai một phương pháp giám sát khác.
Điều gì sẽ xảy ra nếu bạn có khả năng hiển thị về tình trạng môi trường SQL Server của mình cần thiết để giải quyết các vấn đề về hiệu suất một cách chủ động… trước khi chúng ảnh hưởng nghiêm trọng đến doanh nghiệp của bạn? Điều gì sẽ xảy ra nếu bạn có thể nhanh chóng xác định sự suy giảm hiệu suất, xác định nguyên nhân và phân tích, điều chỉnh để ngăn chặn các vấn đề tương tự trong tương lai?
Ồ, và điều gì sẽ xảy ra nếu bạn có thể có tất cả những điều này trên cơ sở đăng ký? Không cần bổ sung phần cứng, không cần phần mềm, không tốn chi phí bảo trì và có thể truy cập nó từ mọi nơi, mọi lúc trên mọi thiết bị?
Với Spotlight Cloud, bạn có thể! Nó dễ dàng như Đăng ký. Đăng nhập. Giải quyết.
Bắt đầu với Spotlight Cloud để giám sát và chẩn đoán cơ sở dữ liệu được lưu trữ trên đám mây chưa từng có cho SQL Server. Nó giống như tự tạo cho mình một chương trình khuyến mãi ngay lập tức!
