DBA’larınızı Ölçme – veritabanimimari.com

Yazılarımı okuyanlar bazen bana veri tabanları ve veri tabanı yönetimi hakkında sorular soruyorlar, bunu memnuniyetle karşılıyorum. Ve bazen, basılı olarak özellikle ilgi çekici soruları yanıtlama fırsatını değerlendireceğim. Bana bir kereden fazla sorulan ilgi çekici bir soru şudur: “DBA grubunuzun ne kadar etkili olduğunu yönetmek için hangi metrikler ve ölçümler yararlıdır?”

Bu, yanıtlaması çok kolay bir soru değil çünkü iyi bir DBA, “her işin püf noktası” olmalıdır. Bununla, bir DBA’nın en etkili olabilmesi için birçok farklı görevde (veya ticarette) yetkin olması gerektiğini kastediyorum – ve bu “işlemlerin” her birinin başarıyı ölçmek için birden fazla ölçümü olabilir. Örneğin, bir okuyucu tarafından önerilen bir ölçüm, başarıyla işlenen SQL ifadelerinin sayısını ölçmekti. Ama “başarıyla” ne anlama geliyor? Bu, ifadenin doğru sonuçları verdiği anlamına mı geliyor yoksa makul bir süre içinde doğru sonuçları verdiği anlamına mı geliyor?

Ve “makul” bir zaman nedir? İki saniye? Bir dakika? Yarım saat? Hizmet seviyesi sözleşmeleri oluşturmadıysanız, DBA’yı yanıt süresi üzerinden ölçmek adil değildir. DBA, yerine getirilemeyecek bir görevle karşı karşıya kalmamak için makul hizmet düzeyi anlaşmalarının (maliyet ve yanıt süresi açısından) oluşturulmasına ve yönetilmesine katılmalıdır. (Bu köşenin Eylül 2022 sayısında “Hizmet Seviyesi Yönetiminin Önemi” konusunu ele aldım.)

Olay raporlarının sayısının ölçülmesi önerilen başka bir ölçümdü. Peki, yalnızca DBA’dan etkilenebilecek gerçek sorunlarla sınırlıysa bu sorun değil. DBA, DBMS’deki hatalardan (DBMS satıcısının neden olduğu) veya yönetimden veya aşırı hevesli bir geliştirme ekibinden gelen makul olmayan bir program tarafından kendisine zorlanan tasarım öğelerinden sorumlu tutulmamalıdır.

Kullanılabilirlik metriği kullanma fikrini seviyorum, ancak ortama ve kuruluşunuzun çalışma süresi gereksinimlerine göre ayarlanmalıdır. Başka bir deyişle, gerekli olan kullanılabilirlik nedir? Bir kez daha hizmet seviyesi anlaşmalarına geri dönelim. Ve DBMS, istenen kullanılabilirlik düzeyine ulaşmak için teknik altyapıyı sağlamazsa veya kuruluş bir üçüncü taraf satıcıdan veritabanı kullanılabilirlik çözümleri satın almazsa, DBA kullanılabilirliği sağlamadığı için sert bir şekilde yargılanmamalıdır. Elbette, kullanımdaki DBMS’yi satın alma kararı DBA’ya aitse sorumlu tutulabilir, ancak bu genellikle böyle değildir. Birçok DBA, DBMS seçildikten çok sonra getirilir.

Sorunlara verilen yanıtlara dayalı bir ölçüme ne dersiniz? Bu ölçüm, sorunun mutlaka çözüldüğü anlamına gelmez, ancak DBA’nın “şikayet eden” varlığa yanıt verdiği ve bir çözüm üzerinde çalıştığı anlamına gelir. Böyle bir ölçüm, veritabanı yönetimini bir hizmet veya yardım masası türü bir işlev olarak ele almaya yönelecektir. Ancak bunun DBA’ları ölçmek için çok dar bir ölçü olduğunu düşünüyorum. Ne de olsa, sorunlara yanıt vermekten çok daha fazlasını yapıyorlar.

Herhangi bir DBA değerlendirme metriği, DBA’nın çalıştığı ortamın anlaşılmasıyla geliştirilmelidir. Bu, aşağıdaki gibi şeylerin derinlemesine analizini gerektirir:

  • Desteklenmesi gereken uygulama sayısı;
  • Veritabanlarının sayısı ve bu veritabanlarının boyutu;
  • Şirket içi ve bulut veritabanı desteği;
  • Veritabanlarının kullanımı (OLTP, OLAP, web özellikli, analitik, AI, ad hoc, vb.);
  • Farklı DBMS’lerin ve satıcıların sayısı (yani Oracle, Db2, SQL Server, vb.);
  • Desteklenecek işletim sistemi platformlarının sayısı (Windows, UNIX, Linux, z/OS, vb.);
  • Standart olmayan DBMS kullanımlarından dolayı ERP uygulamaları için özel değerlendirme;
  • Kullanıcı sayısı ve eşzamanlı kullanıcı sayısı;
  • Yürürlükte olan veya planlanan hizmet seviyesi anlaşmalarının türü;
  • Çevik bir geliştirme ortamı olan DevOps’a katılma gereksinimi;
  • Kullanılabilirlik gerekli (7/24 veya daha az);
  • Veritabanı kapalı kalma süresinin iş üzerindeki etkisi ($$$);
  • Performans gereksinimleri (saniyenin altında veya daha uzun – SLA sorununa geri döner);
  • Uygulama türleri (görev açısından kritik ve görev açısından kritik olmayan); Ve
  • Değişiklik taleplerinin sıklığı.

Bu muhtemelen eksik bir listedir, ancak DBA’ların günlük olarak karşılaştığı karmaşıklığı ve zorlukları doğru bir şekilde göstermektedir.

Elbette DBA etkinliğini ölçmenin en iyi yolu, DBA’larınızın gerçekleştirdiği tüm görevlerin kalitesini değerlendirmektir. Ancak bu tür bir ölçümün birçok yönü öznel olacaktır. Bir DBA’nın kuruluşun verilerinin ve veritabanlarının yararlı, kullanılabilir, kullanılabilir ve doğru olmasını sağlamak için birçok görevi yerine getirdiğini unutmayın. Bu görevler arasında veri modelleme, mantıksal ve fiziksel veritabanı tasarımı, performans izleme ve ayarlama, kullanılabilirliği sağlama, güvenlik, yedekleme ve kurtarma yetkisi verme, veri bütünlüğünü sağlama ve gerçekten şirketin veritabanlarıyla arayüz oluşturan her şey yer alır. Bu görevleri öznel olmayan bir şekilde ölçmek için tutarlı bir ölçüm geliştirmek zordur.

İşi doğru bir şekilde yapmak için muhtemelen yukarıdakilerin hepsini ve daha fazlasını kapsayan karmaşık bir formül bulmanız gerekecek, bu yüzden muhtemelen adil, öznel olmayan, metrik tabanlı bir ölçüm programının bir araya getirildiğini hiç görmedim. DBA’lar için.

Böyle bir program uygularsanız, detayları ve bunun DBA grubu, yönetimi ve müşterileri/kullanıcıları tarafından nasıl kabul edildiğini duymak isterim.

Bir yanıt yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir