DBA'lar, Artık Rahiplik Yok

Not: Bu mühendislik yazısı DBA'mız Silvia Botros tarafından yazılmıştır ve ilk olarak Aralık 2016'da Sysadvent Blog'da yayınlanmıştır.

Şirketler, yıllardır Veritabanı Yöneticilerine sahip olmuş ve ihtiyaç duymuştur. Veri, bir işletmenin en önemli varlıklarından biridir. Bu, birçok işletmenin hızla ölçeklenebilmeleri gereken bir noktaya geldiklerinde, varlığın iyi yönetildiğinden, ürün ihtiyaçları için performans gösterdiğinden ve felaket durumunda geri yüklenebilir olduğundan emin olacak birine ihtiyaç duyduğu anlamına gelir.

Geleneksel anlamda, DBA'nın görevi, veriyi barındıran sunuculara erişimi olan tek kişi, yeni özellikler için yeni veritabanı kümesi oluşturacak kişi, yeni şemalar tasarlayacak kişi ve tek kişi olduğu anlamına gelir. Bir üretim ortamında veritabanıyla ilgili herhangi bir şey bozulduğunda iletişim kurulacak kişi.

DBA'ların geleneksel olarak benzersiz rolleri olduğundan, zamanları çok değerli olduğundan, günlük görevler bunaltıldığında büyük resmi düşünmek zorlaşıyor. DBA ülkesindeki her türlü operasyonel görev için bash gibi kırılgan araçlara başvurmak tipiktir. Temiz bir işletim sistemi kurulumundan yeni bir DB kurulumuna mı ihtiyacınız var? Yedeklemeleri almak, doğrulamak veya geri yüklemek? Bölümleri veya eski verileri döndürün mü? En sık kullandığınız araç bash komut dosyası olduğunda, her şey bir çivi gibi görünür. Pek çok okuyucunun bana bash'ın ne kadar güçlü olduğunu söylemek için tweetler hazırladığına eminim, ancak lütfen yorumunuzu gerekçemi değerlendirene kadar bekleyin.

Bütün bunlar bir DBA olarak iş tanımınıza benziyor mu? İş tanımı, sunucuları yükseltme, yedekleme oluşturma ve test etme ve izleme hakkında ayrıntılı bilgi veriyor mu? Tipik DBA iş ilanlarının çoğu, 'birden çok' veritabanı sunucusunu yapılandırmanız ve kurmanız gerektiğini (çünkü beklenti DBA'ların bunları el işi yapmasıdır) ve veritabanı yönetim görevlerini (el yapımı) komut dosyalarıyla otomatikleştirmeniz gerektiğini söylemenizi sağlayacaktır.

Bu, büyüyen, hızlı tempolu bir organizasyonda genellikle tek kişilik bir ekip için gerçekten ölçeklenebilir bir yaklaşım mı?

İşinizin yedekleme yapmak ve yönetmek, veritabanları oluşturmak ve yönetmek veya sorguları optimize etmek olmadığını savunmak için buradayım. Tüm bunları işinizin süresi içinde yapacaksınız, ancak asıl hedef işletmenizin verilerini erişilebilir ve ölçeklenebilir hale getirmektir. Bu, yalnızca mevcut ürünü işletmek için değil, aynı zamanda yeni özellikler oluşturmak ve müşterilere değer sağlamak için de geçerlidir.

Niye ya

Sormak isteyebilirsiniz, neden bunlardan herhangi birini yapayım? DBA rolünü geleneksel olarak yürütmeye devam etmek için bir argüman var: iş güvenliği, değil mi? Günümüzde birçok teknoloji kuruluşu aşağıdakilerden birini veya birkaçını yapmaktadır:

• Birçok küçük takımdan oluşurlar.
• Bir veya birkaç büyük hizmet yerine birçok mikro hizmet oluşturarak özellik sağlarlar.
• Özelliklerin dağıtımını hızlandırmak için çevik metodolojileri benimsiyorlar
• Operasyonları ve mühendisliği tek bir liderlik altında birleştiriyorlar
• Operasyon mühendislerini, tasarım sürecinde mümkün olan en erken aşamada geliştiricilere dahil ederler.
• Operasyonlar içindeki bir DBA silosu, operasyon ekibinin kendi yığınındaki üretim sorunlarının hatalarını ayıklamaya yardımcı olmak için daha az yetkiye sahip olduğu, bazen yardım almadan sorunları yanıtlayamadığı ve düzeltemediği ve açıkçası, mühendislik ekipleriyle daha yakın ve daha erken işbirlikleri talep etme konusunda daha az güvenilir olduğu anlamına gelir. Tech Ops'ta vaaz ettiklerini uygulamak.

Peki, bu siloyu çökertmek ve diğer kişilerin hata ayıklamasını kolaylaştırmak, veritabanı katmanını ölçeklendirmeye yardımcı olmak ve mühendislere ölçeklenebilen hizmetler tasarlamaları için yetki vermek için ne yapılabilir? Gelecek vaat eden mağazaların çoğunda en fazla bir şirket içi DBA bulunur. Tek bir DBA, tüm tasarım toplantılarında 'var' olabilir, her şema değişikliğini onaylayabilir ve genişleyen, sürekli büyüyen bir veritabanı ayak izi için çağrıda bulunabilir mi?

DBA'lar artık kapı bekçisi veya sihirbaz olamaz. Bir DBA, bir kuruluştaki mühendisler için bir bilgi ve uzmanlık kaynağı olabilir ve olmalıdır. Dağıtım ekiplerine yalnızca özellikler sunmalarına değil, aynı zamanda onları veritabanından korkmamaları için ölçeklendiren ve güçlendiren ürünler sunmalarına da yardımcı olmalıdır. Ancak bir DBA, günlük veri katmanını yönetme işini yaparken bunu nasıl başarabilir? DBA olarak kendinizi mükemmelliğe hazırlamanın birkaç yolu vardır.

Konfigürasyon yönetimi

Bu çok önemli. DBA'lar, veritabanı kurulumu için bash gibi eski okul araçlarını tercih etme eğilimindedir. Buna daha önce değindim ve bash'ın kendisini kullanmaya karşı hiçbir şeyim yok. Aslında çok kullanırım. Ancak küme kurulumu için doğru araç değildir. Özellikle operasyonların geri kalanı, mimarinin geri kalanını yönetmek için Bash kullanmıyorsa. Operasyon mühendislerinin de Bash'i bildiği doğrudur, ancak altyapının geri kalanını Chef veya Puppet gibi bir araçla yönetiyorlarsa ve veritabanları çoğunlukla DBA tarafından yazılmış el yapımı komut dosyalarıyla yönetiliyorsa, onların sağlamasını engellemiş olursunuz. acil bir değişiklik gerektiğinde yardım.

Dahası, mühendislik ekiplerinin kendi kendine hizmet etmelerine ve yeni 'foo' özelliği için ihtiyaç duydukları yeni kümelerin oluşturulmasına sahip olmalarına yardımcı olmak zorlaşıyor. İşi tamamlamak için 'engelleyici' olursunuz. Şirketinizdeki konfigürasyon yönetimine aşina olmak da iki yönlü bir avantajdır. Altyapının nasıl yönetildiğini öğrendikçe, ekibin standartlarını öğrenir, yığına daha fazla aşina olursunuz ve nihai olarak ürün ölçeğini etkileyen değişiklikler üzerinde işbirliği yapabilirsiniz.

Mühendislik organizasyonunun ürün ve altyapısına bir bütün olarak uyum sağlayan bir DBA çok değerlidir.

Runbook'lar

Bu teknik olarak yazmanız gereken belgelerin bir alt kümesidir, ancak deneyimlerime göre ayrı ayrı belirtilmesi gerektiğini düşündüğümden çok daha yararlı olduğu kanıtlanmıştır. Runbook dediğimde, özellikle DBA OLMAYAN bir kitle için yazılmış bir belge söylüyorum. DBA'lar olarak karşılaşabileceğimiz, hata ayıklaması ve çözmesi kolay olan birçok üretim veritabanı sorunu vardır. Bu kas hafızasını hafife alma eğilimindeyiz ve 'bana sayfayı gönder' ve 'işleri hallederiz' kalıbına düşüyoruz.

Operasyon ekibiniz, tek DBA olduğunuz yerde benimki gibiyse, bu, DB ile ilgili bir etkinlik sayfalarında muhtemelen ekipteki ilk savunma hattı olduğu anlamına gelir. İlk hata ayıklamanın, veri toplamanın nasıl yapılacağına ilişkin bazı basit belgeler, operasyon ekibinin geri kalanının veritabanı katmanı konusunda rahat olmasını ve onu nasıl izleyip hata ayıkladığımızı daha iyi bilmesini sağlamada uzun bir yol kat edebilir. Bu olay yine de DBA'nın çağrılmasıyla sonuçlansa bile, yavaş ama emin adımlarla, runbook herkesin edindiği bilgileri ekleyebileceği bir yer haline gelir.

Ek olarak, çağrı cihazına giden sayfa açıklamalarına ilgili runbook bölümüne bir bağlantı (bağlantıları kullanın!) ekliyorum. Bu, başlamak için bir yer bulmak için sabah 3'te bir veritabanı ana bilgisayarı tarafından çağrılan biri için inanılmaz derecede yararlıdır. Bunlar küçük görünebilir, ancak deneyimlerime göre, gerektiğinde veritabanı katmanı üzerinde çalışan operasyon ekibim için zihinsel engelleri aşmada uzun bir yol kat ettiler.

Kişisel bir tercih olarak, bunları şef yemek kitabı depolarımda indirim belgeleri olarak yazıyorum. Bu, sorunsuz bir şekilde bir çekme talebi, gözden geçirme ve birleştirme modeline girer ve veritabanlarının yemek kitapları modelinin ayrılmaz bir parçası haline gelir. Mühendislik ekipleri kendilerininkini oluşturmaya başladıkça, yeni veritabanı kümeleri her yere yayıldıkça runbook'lar tanıdık bir şablon haline gelir.

görünürlük

Terminal ekranlarımızı seviyoruz. Biz onları seviyoruz. MySQL arazisindeki en popüler araçlar hala doğrudan db ana bilgisayarlarında yaşayan ve bunlar ve bunların nasıl kullanılacağı hakkında önceden bilgi sahibi olmayı gerektiren terminal araçlarıdır. Innotop ve MySQL kabuğu gibi şeylerden bahsediyorum. Bunlar iyi ve yine de faydalıdır ancak DBA'lar için yaratılmıştır. “Şu anda replikasyon gecikmesi var mı?” gibi sorulara kapıcı olmak istemiyorsanız. Herhangi bir küme sağlığını şimdi ve geçmişte, kullanılabilir ve tüm ekip üyeleri için kolay sindirilebilir hale getirmek için daha iyi araçlara sahip olmanız gerekir. Bu arenada birkaç örneğim var:

Orkestratör

Bu yükü birincilden uzağa yaymak için okuma kopyaları kullanıyoruz; bu, gecikmenin belirli bir eşiğe ulaştığında, bunun bir müşteri destek olayı olduğu anlamına gelir. Şirketteki herkesin herhangi bir zamanda herhangi bir kümede gecikme yaşayıp yaşamadığını, o kümedeki sunucuların neler olduğunu ve ana bilgisayarlardan herhangi birinin çöküp çökmediğini bilmesini kolaylaştırmak önemlidir. Orchestrator, kümeleri ve sağlıklarını bir tarayıcı penceresi uzağınızda görselleştirmeyi sağladığı için bu açıdan harika bir araçtır.

Grafana/Grafit

DB katmanı için metriklerin aynı yerde yaşaması gerekir, metrikler altyapının geri kalanı için geçerlidir. Ekibin bu metrikleri yan yana koyabilmesi önemlidir. Ayrıca, herhangi bir DB kümesi için geçmiş ölçümleri görmenin kolay bir yolunun olması önemlidir. Yıllar boyunca yazdığınız kaktüsler veya müninler veya zanaatkar şablonlar için kişisel bir tercihiniz olsa da, sorunları araştırmak için kullandığınız metrikler diğer altyapı metrikleriyle aynı yerde değilse, bu sizin için bir engel oluşturur. diğer meşgul mühendisler – ve sizin aletlerinizi başka bir yerde kullanılanlara göre kullanmaya daha az meyilli olacaklardır. Grafit, modern altyapı ekiplerinde ölçümleri almak için yaygın olarak kullanılmaktadır ve Grafana, ölçümler ve analitik için yaygın olarak kullanılan bir gösterge panosudur.

Sorgu performansı

Kritik kümelerdeki sorgularımızı izlemek için VividCortex kullanıyoruz ve bu makale ücretli bir hizmetin reklamı olmayı amaçlamasa da, konuşlandırmaların ve kod değişikliklerinin çalışan sorgular üzerindeki etkisini ve kod değişikliklerini inceleme yeteneğini yapmanız gerektiğini söyleyeceğim. performans, günlüklere özel erişime ve bunları manuel olarak sıkıştırmaya ihtiyaç duymayan bir şeyi sorgulayın. VividCortex bir olasılık değilse (gerçi gerçekten harikalar!), Diğer ürünler ve açık kaynak araçları sadece yavaş günlüğü bile yakalayabilir ve DBA olmayanların incelemesi için okunması kolay bir web sayfasına koyabilir ve kodlarının etkisini görün. Buradaki önemli nokta, verileri görmenin yollarını sağlarsanız, mühendislerin bu verileri kullanacak ve işleri verimli tutmak için ellerinden gelenin en iyisini yapacaklarıdır. Ancak bu erişimi sağlamak sizin işinizin bir parçasıdır ve özel bir DBA numarası değildir.

Çağrı cihazı yorgunluğuyla savaşın

Birçok kuruluş, yığın tasarımlarında çok erken bir zorunluluk olarak veritabanı katmanı ölçeklendirmeyi dahil etmez ve yapmamalıdırlar. Bir şirketin ilk günlerinde, henüz kimse API kullanmıyorsa API çağrılarını nasıl kısacağınız konusunda endişelenmemelisiniz. Ancak birkaç yıl sonra, ürünün çekiş kazandığı ve bir avuç müşteri tarafından birkaç bin satırlık bir masaya isabet eden API çağrısının şimdi milyonlarca satırlık bir tablo ve birkaç müşteri olduğunu düşünmek uygun olur. sizin saat diliminizde her sabah saat 6'da bu API'yi dolduran cron işleri oluşturdunuz.

Altyapıyı korumak için herhangi bir ürünün uygulama katmanını değiştirmek çok fazla çalışma gerektirir ve bu arada, sahte veritabanı etkinliğinin çağrı cihazı yorgunluğuna neden olmasına izin vermek hem siz hem de operasyon organizasyonunun geri kalanı için büyük bir tehlikedir. Bir veritabanı ana bilgisayarının planlanmamış hacim nedeniyle büyük kesinti süresi yaşamasını önlemek için çabucak kullanılabilecek pt-kill gibi araçlara aşina olun. Bu aracın kullanımını bilin ve eylemi ve etkisini hisse sahibi mühendislik ekibine iletin, ancak doğrudan değiştiremeyeceğiniz bir şeyin acısını emmeye çalışmak sağlıksızdır ve mühendislik ekiplerine yardım etmenin nihayetinde faydalı olmayacaktır. 'Büyüyen ağrılarla nasıl başa çıkacağınızı öğrenin.

Operasyon ekibinin geri kalanına kıyasla bir DBA'nın çalışmasının rolüne özgü birçok yolu vardır, ancak bu, kimsenin yaklaşamayacağı büyülü bir rahiplik olması gerektiği anlamına gelmez. Bu adımlar, işinizi şeffaf hale getirmede uzun bir yol kat eder, ancak en önemlisi, işinize altın bir veritabanı sunucusunun bekçisi olarak değil, tavsiyelerde bulunabilecek ve birlikte çalıştığınız mühendislerin büyümesine ve daha fazlasını sağlamanıza yardımcı olabilecek bir konu uzmanı olarak yaklaşmaktır. yedeklemelerden ve sorgu ayarlamadan daha fazla iş için değer (ancak bunlar da eğlencelidir!).

Bana birçok şey öğretmeye devam eden Sendgrid'deki harika operasyon ekibine ve bu yazının başlığını oluşturan Charity Majors'a özel teşekkürler. Ve burada DBA'lar hakkında daha fazla gönderiye göz atın.