DBA, Tidak Ada Imamat Lagi

Catatan: Posting teknik ini ditulis oleh DBA kami, Silvia Botros dan awalnya muncul di Blog Sysadvent pada Desember 2016.

Perusahaan telah dan membutuhkan Administrator Basis Data selama bertahun-tahun. Data adalah salah satu aset bisnis yang paling penting. Itu berarti banyak bisnis, begitu mereka tumbuh ke titik di mana mereka harus dapat berkembang pesat, membutuhkan seseorang untuk memastikan bahwa aset dikelola dengan baik, berkinerja untuk kebutuhan produk, dan tersedia untuk dipulihkan jika terjadi bencana.

Dalam pengertian tradisional, pekerjaan DBA berarti dia adalah satu-satunya orang yang memiliki akses ke server yang meng-host data, orang yang masuk untuk membuat cluster database baru untuk fitur baru, orang yang merancang skema baru, dan satu-satunya orang yang harus dihubungi ketika ada sesuatu yang terkait database rusak di lingkungan produksi.

Karena DBA secara tradisional memiliki peran unik seperti itu, waktu mereka sangat mahal, menjadi lebih sulit untuk memikirkan gambaran besar ketika tugas sehari-hari membanjiri. Biasanya menggunakan alat rapuh seperti bash untuk semua jenis tugas operasional di lahan DBA. Perlu pengaturan DB baru dari instalasi OS yang bersih? Ambil, validasi, atau pulihkan cadangan? Putar partisi atau data basi? Ketika alat Anda yang paling umum digunakan adalah skrip bash, semuanya tampak seperti paku. Saya yakin banyak pembaca sedang mempersiapkan tweet untuk memberi tahu saya betapa kuatnya bash, tetapi tolong tahan komentar Anda sampai setelah mengevaluasi alasan saya.

Apakah semua ini terdengar seperti deskripsi pekerjaan Anda sebagai DBA? Apakah deskripsi pekerjaan berbicara secara rinci tentang meningkatkan server, membuat dan menguji cadangan, dan memantau? Posting pekerjaan DBA yang paling umum akan memastikan untuk mengatakan bahwa Anda harus mengonfigurasi dan menyiapkan server basis data 'banyak' (karena harapannya adalah bahwa DBA membuatnya), dan mengotomatiskan tugas manajemen basis data dengan skrip (kerajinan tangan).

Apakah itu benar-benar pendekatan yang terukur untuk apa yang sering kali merupakan tim satu dalam organisasi yang berkembang pesat?

Saya di sini untuk menyatakan bahwa tugas Anda bukanlah melakukan dan mengelola pencadangan, membuat dan mengelola basis data, atau mengoptimalkan kueri. Anda akan melakukan semua hal ini dalam rentang pekerjaan Anda, tetapi tujuan utamanya adalah membuat data bisnis Anda dapat diakses dan terukur. Ini bukan hanya untuk bisnis menjalankan produk saat ini tetapi juga untuk membangun fitur baru dan memberikan nilai kepada pelanggan.

Mengapa

Anda mungkin ingin bertanya, mengapa saya melakukan semua ini? Ada argumen untuk melanjutkan menjalankan peran DBA secara tradisional: keamanan kerja, bukan? Banyak organisasi teknologi saat ini melakukan satu atau beberapa hal berikut:

• Mereka dibentuk dari banyak tim yang lebih kecil
• Mereka menyediakan fitur dengan membuat banyak layanan mikro menggantikan satu atau beberapa layanan yang lebih besar
• Mereka mengadopsi metodologi tangkas untuk mempercepat pengiriman fitur
• Mereka menggabungkan operasi dan rekayasa di bawah satu kepemimpinan
• Mereka menanamkan insinyur operasi dengan pengembang sedini mungkin dalam proses desain
• Silo DBA dalam operasi berarti tim operasi kurang diberdayakan untuk membantu men-debug masalah produksi di tumpukannya sendiri, terkadang tidak dapat merespons dan memperbaiki masalah tanpa bantuan, dan sejujurnya kurang kredibel dalam menuntut kolaborasi yang lebih dekat dan lebih awal dengan tim teknik jika memang demikian. tidak mempraktekkan apa yang mereka khotbahkan di dalam Tech Ops.

Jadi apa yang dapat dilakukan untuk memecahkan silo itu dan mempermudah orang lain untuk melakukan debug, membantu menskalakan lapisan basis data, dan memberdayakan para insinyur untuk merancang layanan yang dapat diskalakan? Sebagian besar toko baru memiliki paling banyak satu DBA internal. Bisakah satu DBA 'hadir' di semua rapat desain, menyetujui setiap perubahan skema, dan siap siaga untuk jejak basis data yang luas dan terus berkembang?

DBA tidak bisa lagi menjadi penjaga gerbang atau penyihir. DBA dapat dan harus menjadi sumber pengetahuan dan keahlian bagi para insinyur dalam suatu organisasi. Dia harus membantu tim pengiriman tidak hanya memberikan fitur, tetapi juga untuk memberikan produk yang berskala dan memberdayakan mereka untuk tidak takut pada database. Tapi bagaimana DBA bisa mencapai itu sambil melakukan pekerjaan sehari-hari mengelola lapisan data? Ada beberapa cara Anda, DBA, dapat mempersiapkan diri untuk keunggulan.

Manajemen konfigurasi

Ini adalah hal yang sangat penting. DBA cenderung lebih memilih alat sekolah lama seperti bash untuk pengaturan basis data. Saya menyinggung ini sebelumnya dan saya tidak menentang penggunaan bash itu sendiri. Saya sering menggunakannya, sebenarnya. Tapi itu bukan alat yang tepat untuk pengaturan cluster. Terutama jika operasi lainnya TIDAK menggunakan Bash untuk mengelola arsitektur lainnya. Memang benar bahwa insinyur operasi tahu Bash juga, tetapi jika mereka mengelola sisa infrastruktur dengan alat seperti Chef atau Wayang dan database sebagian besar dikelola oleh skrip buatan tangan yang ditulis oleh DBA, Anda memaksakan penghalang bagi mereka untuk menyediakan membantu ketika perubahan mendesak diperlukan.

Lebih dari itu, menjadi lebih sulit untuk membantu tim teknik untuk melayani diri sendiri dan memiliki pembuatan cluster baru yang mereka butuhkan untuk fitur baru `foo.` Anda menjadi 'pemblokir' untuk menyelesaikan pekerjaan. Mengenal manajemen konfigurasi di perusahaan Anda juga merupakan manfaat dua arah. Saat Anda terbiasa dengan bagaimana infrastruktur dikelola, Anda mengenal standar tim, lebih mengenal tumpukan, dan mampu berkolaborasi pada perubahan yang pada akhirnya memengaruhi skala produk.

Seorang DBA yang disetel ke dalam produk dan infrastruktur organisasi teknik secara keseluruhan sangat berharga.

Runbook

Ini secara teknis adalah bagian dari dokumentasi yang harus Anda tulis, tetapi dalam pengalaman saya telah terbukti jauh lebih berguna sehingga saya merasa itu harus ditunjukkan secara terpisah. Ketika saya mengatakan runbook, saya secara khusus mengatakan dokumen yang ditulis untuk audiens yang BUKAN DBA. Ada banyak masalah DB produksi yang mungkin kami temui sebagai DBA yang mudah untuk kami debug dan selesaikan. Kita cenderung meremehkan memori otot itu dan kita jatuh dalam pola 'kirimkan saja halamannya' dan kita 'urusi semuanya'.

Jika tim operasi Anda seperti saya di mana Anda adalah satu-satunya DBA, itu mungkin berarti orang lain di tim adalah garis pertahanan pertama ketika halaman acara terkait DB. Beberapa dokumentasi sederhana tentang cara melakukan debugging awal, pengumpulan data, dapat membantu tim operasi lainnya merasa nyaman dengan lapisan basis data dan lebih terbiasa dengan cara kami memantau dan men-debugnya. Sekalipun peristiwa itu masih menghasilkan paging DBA, perlahan tapi pasti, runbook menjadi tempat bagi semua orang untuk menambah pengetahuan yang diperoleh.

Selain itu, saya menambahkan tautan ke bagian runbook terkait (gunakan jangkar!) ke deskripsi halaman yang menuju ke pager. Ini sangat membantu bagi seseorang yang di-page oleh host basis data pada pukul 3 pagi untuk menemukan tempat untuk memulai. Hal-hal ini mungkin tampak kecil, tetapi menurut pengalaman saya, hal-hal ini telah berhasil memecahkan hambatan mental bagi tim operasi saya yang bekerja pada lapisan basis data bila diperlukan.

Sebagai preferensi pribadi, saya menulis ini sebagai dokumen penurunan harga di dalam repositori buku masak koki saya. Ini masuk dengan mulus ke dalam pola permintaan tarik, tinjauan dan penggabungan, dan itu menjadi bagian integral dari pola buku masak database. Saat tim teknik mulai membuat sendiri, runbook menjadi template yang sudah dikenal saat kluster database baru bermunculan di semua tempat.

Visibilitas

Kami menyukai layar terminal kami. Kami mencintai mereka. Alat yang paling populer di tanah MySQL masih alat terminal yang hidup langsung di host db dan yang membutuhkan pengetahuan sebelumnya tentang mereka dan bagaimana menggunakannya. Saya berbicara tentang hal-hal seperti innotop dan shell MySQL. Ini bagus dan masih membantu tetapi dibuat untuk DBA. Jika Anda tidak ingin menjadi penjaga gerbang untuk pertanyaan seperti “apakah ada jeda replikasi saat ini?” Anda perlu memiliki alat yang lebih baik untuk membuat kesehatan cluster, sekarang dan secara historis, tersedia dan mudah dicerna untuk semua anggota tim. Saya punya beberapa contoh di arena ini:

Pemimpin orkestra

Kami menggunakan replika baca untuk menyebarkan beban itu dari yang utama, yang berarti begitu kelambatan mencapai ambang tertentu, itu menjadi peristiwa dukungan pelanggan. Penting untuk memudahkan siapa pun di perusahaan untuk mengetahui pada waktu tertentu apakah ada klaster yang mengalami kelambatan, server apa di klaster itu, dan apakah ada host yang mati. Orchestrator adalah alat yang hebat dalam hal itu karena itu membuat visualisasi cluster dan kesehatannya menjadi jendela browser.

Grafana/Grafit

Metrik untuk lapisan DB harus berada di tempat yang sama dengan metrik untuk infrastruktur lainnya. Penting bagi tim untuk dapat menyandingkan metrik ini secara berdampingan. Dan penting untuk memiliki cara mudah untuk melihat metrik historis untuk setiap cluster DB. Meskipun Anda mungkin memiliki preferensi pribadi untuk kaktus atau munin, atau templat artisanal yang telah Anda tulis selama bertahun-tahun, jika metrik yang Anda gunakan untuk menyelidiki masalah tidak berada di tempat yang sama dengan metrik infrastruktur lainnya, metrik tersebut menjadi penghalang untuk insinyur sibuk lainnya–dan mereka akan cenderung tidak menggunakan perkakas Anda daripada yang digunakan di tempat lain. Grafit digunakan secara luas untuk menyerap metrik di tim infrastruktur modern, dan Grafana adalah front-end dasbor yang banyak digunakan untuk metrik dan analitik.

Kinerja kueri

Kami menggunakan VividCortex untuk melacak kueri kami pada kluster kritis dan sementara artikel ini tidak dimaksudkan sebagai iklan untuk layanan berbayar, saya akan mengatakan bahwa Anda perlu membuat kemampuan untuk memeriksa efek penerapan dan perubahan kode pada menjalankan kueri dan kinerja kueri sesuatu yang tidak memerlukan akses khusus ke log dan mengolahnya secara manual. Jika VividCortex bukan kemungkinan (walaupun, serius, mereka luar biasa!), Ada produk lain dan alat sumber terbuka yang dapat menangkap bahkan hanya log yang lambat dan meletakkannya di halaman web yang mudah dibaca untuk non-DBA untuk diperiksa dan melihat efek dari kode mereka. Poin penting di sini adalah jika Anda menyediakan sarana untuk melihat data, para insinyur akan menggunakan data itu dan melakukan yang terbaik untuk menjaga semuanya tetap efisien. Tapi itu adalah bagian dari tugas Anda untuk membuat akses itu tersedia dan bukan trik DBA khusus.

Melawan kelelahan pager

Banyak organisasi tidak menyertakan penskalaan lapisan basis data sebagai keharusan awal dalam desain tumpukan mereka—dan mereka seharusnya tidak melakukannya. Pada hari-hari awal perusahaan, Anda tidak perlu khawatir tentang bagaimana Anda akan membatasi panggilan API jika belum ada yang menggunakan API. Tapi itu tepat untuk mempertimbangkan beberapa tahun kemudian, ketika produk telah mendapatkan daya tarik, dan panggilan API yang mencapai tabel beberapa ribu baris oleh segelintir pelanggan sekarang menjadi tabel multi-juta baris, dan beberapa pelanggan telah membangun pekerjaan cron yang membanjiri API itu setiap pagi pukul 6 pagi di zona waktu Anda.

Dibutuhkan banyak pekerjaan untuk mengubah lapisan aplikasi produk apa pun untuk melindungi infrastruktur dan, untuk sementara, membiarkan aktivitas basis data palsu menyebabkan kelelahan pager adalah bahaya besar bagi Anda dan seluruh organisasi operasi. Kenali alat-alat seperti pt-kill yang dapat digunakan dengan mudah untuk mencegah host database mengalami downtime besar karena volume yang tidak direncanakan. Gunakan alat itu untuk diketahui dan komunikasikan tindakan dan efeknya kepada tim teknik pemegang saham tetapi tidak sehat untuk mencoba dan menyerap rasa sakit dari sesuatu yang tidak dapat Anda ubah secara langsung dan pada akhirnya tidak akan bermanfaat untuk membantu tim teknik ' belajar bagaimana menangani rasa sakit yang tumbuh.

Ada banyak cara pekerjaan DBA unik untuk perannya dibandingkan dengan tim operasi lainnya, tetapi itu tidak berarti itu harus menjadi imamat magis yang tidak dapat didekati oleh siapa pun. Langkah-langkah ini sangat membantu dalam membuat pekerjaan Anda transparan tetapi yang paling penting adalah mendekati pekerjaan Anda bukan sebagai penjaga gerbang ke taman emas tuan rumah basis data tetapi sebagai ahli materi pelajaran yang dapat memberikan saran dan membantu mengembangkan insinyur yang bekerja dengan Anda dan memberikan lebih banyak nilai bisnis daripada pencadangan dan penyetelan kueri (tetapi itu juga menyenangkan!).

Terima kasih khusus kepada tim operasi yang luar biasa di Sendgrid yang terus mengajari saya banyak hal, dan kepada Charity Majors karena telah membuat judul posting ini. Dan lihat lebih banyak posting tentang DBA di sini.