DBAs ، كهنوت لا أكثر

ملاحظة: تمت كتابة هذا المنشور الهندسي بواسطة DBA ، Silvia Botros وظهر في الأصل على مدونة Sysadvent في ديسمبر 2016.

الشركات لديها وتحتاج إلى مديري قواعد البيانات لسنوات. البيانات هي أحد أهم أصول الأعمال. هذا يعني أن العديد من الشركات ، بمجرد أن تنمو إلى النقطة التي يجب أن تكون قادرة على التوسع بسرعة ، تحتاج إلى شخص ما للتأكد من أن الأصول تدار بشكل جيد ، وتعمل على تلبية احتياجات المنتج ، ومتاحة للاستعادة في حالة وقوع كوارث.

بالمعنى التقليدي ، تعني وظيفة DBA أنها الشخص الوحيد الذي لديه حق الوصول إلى الخوادم التي تستضيف البيانات ، والشخص الذي يقوم بإنشاء مجموعة قواعد بيانات جديدة للميزات الجديدة ، والشخص الذي يقوم بتصميم مخططات جديدة ، والشخص الوحيد شخص للاتصال به عند حدوث أي خلل في قاعدة البيانات في بيئة الإنتاج.

نظرًا لأن مديري قواعد البيانات لديهم مثل هذه الأدوار الفريدة من نوعها تقليديًا ، فإن وقتهم أعلى من سعره ، يصبح من الصعب التفكير في الصورة الكبيرة عندما تطغى المهام اليومية على المهام. من المعتاد اللجوء إلى أدوات هشة مثل bash لجميع أنواع المهام التشغيلية في DBA land. هل تحتاج إلى إعداد قاعدة بيانات جديد من تثبيت نظام تشغيل نظيف؟ أخذ ، التحقق من صحة ، أو استعادة النسخ الاحتياطية؟ تدوير الأقسام أو البيانات التي لا معنى لها؟ عندما تكون أداتك الأكثر استخدامًا هي البرمجة النصية bash ، فإن كل شيء يبدو وكأنه مسمار. أنا متأكد من أن العديد من القراء يستعدون للتغريدات ليخبروني بمدى قوة bash ، لكن من فضلك استمر في التعليق حتى بعد تقييم تفكيري.

هل كل هذا يبدو وكأنه وصف وظيفي ك DBA؟ هل يتحدث الوصف الوظيفي بالتفصيل عن ترقية الخوادم وإنشاء النسخ الاحتياطية واختبارها والمراقبة؟ ستتأكد معظم إعلانات وظائف DBA النموذجية من القول بأنه يجب عليك تكوين وإعداد خوادم قاعدة بيانات "متعددة" (لأن المتوقع هو أن يقوم مسؤولو قواعد البيانات بصنعها يدويًا) ، وأتمتة مهام إدارة قواعد البيانات باستخدام البرامج النصية (المصنوعة يدويًا).

هل هذا حقًا نهج قابل للتطوير لما يكون غالبًا فريقًا واحدًا في مؤسسة سريعة النمو؟

أنا هنا لأجادل بأن وظيفتك ليست أداء وإدارة النسخ الاحتياطية ، أو إنشاء قواعد البيانات وإدارتها ، أو تحسين الاستعلامات. ستفعل كل هذه الأشياء في فترة وظيفتك ولكن الهدف الأساسي هو جعل بيانات عملك قابلة للوصول وقابلة للتطوير. لا يقتصر هذا على الشركة فقط لتشغيل المنتج الحالي ولكن أيضًا لبناء ميزات جديدة وتقديم قيمة للعملاء.

لماذا

قد ترغب في أن تسأل ، لماذا أفعل أيًا من هذا؟ هناك حجة لمواصلة تنفيذ دور DBA تقليديا: الأمن الوظيفي ، أليس كذلك؟ تقوم العديد من المؤسسات التقنية في الوقت الحاضر بواحد أو أكثر مما يلي:

• تم تشكيلهم من العديد من الفرق الصغيرة
• أنها توفر ميزة من خلال إنشاء العديد من الخدمات الصغيرة بدلاً من واحدة أو بضع خدمات أكبر
• يعتمدون منهجيات رشيقة لتسريع تسليم الميزات
• إنهم يجمعون بين العمليات والهندسة تحت قيادة واحدة
• يقومون بتضمين مهندسي العمليات مع المطورين في أقرب وقت ممكن في عملية التصميم
• إن صومعة DBA داخل العمليات تعني أن فريق العمليات أقل قدرة على المساعدة في تصحيح مشكلات الإنتاج في مجموعته الخاصة ، وفي بعض الأحيان يكون غير قادر على الاستجابة وإصلاح المشكلات دون مساعدة ، وبصراحة أقل مصداقية في المطالبة بتعاون أقرب وأقدم مع فرق الهندسة إذا لم يكونوا كذلك لا يمارسون ما يعظون به داخل Tech Ops.

إذن ما الذي يمكن فعله لكسر هذه الصومعة وتسهيل الأمر على الأشخاص الآخرين لتصحيح الأخطاء ، والمساعدة في توسيع نطاق طبقة قاعدة البيانات ، وتمكين المهندسين من تصميم خدمات يمكن توسيع نطاقها؟ تمتلك معظم المتاجر الصاعدة DBA واحدًا على الأكثر. هل يمكن أن يكون مسؤول قاعدة البيانات "حاضرًا" في جميع اجتماعات التصميم ، ويوافق على كل تغيير في المخطط ، ويكون على أهبة الاستعداد للحصول على بصمة قاعدة بيانات مترامية الأطراف ومتنامية باستمرار؟

لم يعد بإمكان مسؤولي قواعد البيانات أن يكونوا حراس بوابات أو سحرة. يمكن ويجب أن يكون DBA مصدرًا للمعرفة والخبرة للمهندسين في المؤسسة. يجب أن تساعد فرق التوصيل ليس فقط على تقديم الميزات ، ولكن لتقديم منتجات بهذا الحجم وتمكينهم من عدم الخوف من قاعدة البيانات. ولكن كيف يمكن لـ DBA تحقيق ذلك أثناء القيام بالمهمة اليومية لإدارة طبقة البيانات؟ هناك عدد من الطرق التي يمكنك من خلالها ، بصفتك مسؤول قواعد البيانات ، إعداد نفسك للتميز.

إدارة التكوين

هذا مهم جدا يميل مسؤولو قواعد البيانات إلى تفضيل أدوات المدرسة القديمة مثل bash لإعداد قاعدة البيانات. لقد أشرت إلى هذا سابقًا وليس لدي أي شيء ضد استخدام باش نفسه. أنا أستخدمه كثيرًا في الواقع. لكنها ليست الأداة الصحيحة لإعداد الكتلة. خاصة إذا كانت بقية العمليات لا تستخدم Bash لإدارة بقية البنية. صحيح أن مهندسي العمليات يعرفون Bash أيضًا ، ولكن إذا كانوا يديرون بقية البنية التحتية باستخدام أداة مثل Chef أو Puppet وكانت قواعد البيانات تُدار في الغالب بواسطة نصوص يدوية مكتوبة بواسطة DBA ، فأنت تفرض عائقًا أمامهم لتقديم المساعدة عند الحاجة إلى تغيير عاجل.

أكثر من ذلك ، يصبح من الصعب مساعدة الفرق الهندسية على الخدمة الذاتية وامتلاك إنشاء المجموعات الجديدة التي يحتاجونها لميزة جديدة "foo". تصبح "مانعًا" لإكمال العمل. يعد التعرف على إدارة التكوين في شركتك أيضًا ميزة ثنائية الاتجاه. عندما تتعرف على كيفية إدارة البنية التحتية ، ستتعرف على معايير الفريق ، وتتعرف أكثر على المكدس ، وتكون قادرًا على التعاون في التغييرات التي تؤثر في النهاية على مقياس المنتج.

إن DBA الذي يتم ضبطه في منتج المؤسسة الهندسية والبنية التحتية ككل لا يقدر بثمن.

Runbooks

هذه من الناحية الفنية مجموعة فرعية من الوثائق التي يجب عليك كتابتها ، ولكن من واقع خبرتي أثبتت أنها مفيدة أكثر بكثير لدرجة أنني أشعر أنه يجب الإشارة إليها بشكل منفصل. عندما أقول كتب التشغيل ، فأنا أقول على وجه التحديد مستندًا مكتوبًا لجمهور ليس DBA. هناك الكثير من مشكلات قاعدة بيانات الإنتاج التي قد نواجهها بصفتنا مسئولي قواعد بيانات (DBA) والتي يسهل علينا تصحيحها وحلها. نميل إلى التقليل من أهمية ذاكرة العضلات ونقع في نمط "أرسل لي الصفحة فقط" و "نعتني بالأشياء".

إذا كان فريق العمليات الخاص بك يشبهني حيث تكون مسؤول قاعدة البيانات الوحيد ، فمن المحتمل أن يعني ذلك أن شخصًا آخر في الفريق هو خط الدفاع الأول عندما تكون صفحات الأحداث ذات الصلة بقاعدة بيانات. يمكن لبعض الوثائق البسيطة حول كيفية إجراء التصحيح الأولي ، وجمع البيانات ، أن تقطع شوطًا طويلاً في جعل بقية فريق العمليات مرتاحًا لطبقة قاعدة البيانات وأكثر دراية بكيفية مراقبتها وتصحيحها. حتى إذا كان هذا الحدث لا يزال يؤدي إلى ترحيل DBA ، ببطء ولكن بثبات ، يصبح كتاب التشغيل مكانًا للجميع لإضافة المعرفة المكتسبة.

بالإضافة إلى ذلك ، أقوم بإضافة ارتباط إلى قسم دليل التشغيل ذي الصلة (استخدم المراسي!) إلى أوصاف الصفحة التي تنتقل إلى جهاز النداء. هذا مفيد بشكل لا يصدق لشخص ما يتم ترحيله من قبل مضيف قاعدة البيانات في الساعة 3 صباحًا للعثور على مكان للبدء. قد تبدو هذه الأشياء صغيرة ، ولكن من واقع خبرتي ، فقد قطعت شوطًا طويلاً في كسر الحواجز الذهنية لفريق العمليات الذي يعمل على طبقة قاعدة البيانات عند الضرورة.

كتفضيل شخصي ، أكتب هذه المستندات كمستندات تخفيض السعر داخل مستودعات كتب الطهي الخاصة بي. يقع هذا بسلاسة في طلب السحب والمراجعة والدمج ، ويصبح جزءًا لا يتجزأ من نمط كتب الطبخ في قواعد البيانات. عندما تبدأ الفرق الهندسية في إنشاء كتيبات التشغيل الخاصة بهم ، تصبح كتيبات التشغيل نموذجًا مألوفًا مع ظهور مجموعات قواعد البيانات الجديدة في كل مكان.

الرؤية

نحن نحب شاشاتنا الطرفية. نحن نحبهم. أكثر الأدوات شيوعًا في MySQL land لا تزال أدوات طرفية تعيش مباشرة على مضيفي db والتي تحتاج إلى معرفة مسبقة بها وكيفية استخدامها. أنا أتحدث عن أشياء مثل innotop و MySQL shell. هذه جيدة ولا تزال مفيدة ولكن تم إنشاؤها لمسؤولي قواعد البيانات. إذا كنت لا تريد أن تكون حارس البوابة لأسئلة مثل "هل هناك تأخر في النسخ المتماثل الآن؟" أنت بحاجة إلى أدوات أفضل لجعل صحة أي مجموعة ، الآن وتاريخيًا ، متاحة وسهلة الاستيعاب لجميع أعضاء الفريق. لدي بعض الأمثلة في هذا المجال:

منسق

نستخدم نسخًا متماثلة للقراءة لنشر هذا التحميل بعيدًا عن الأساسي ، مما يعني أنه بمجرد وصول التأخير إلى حد معين ، يصبح حدثًا لدعم العملاء. من المهم أن تسهل على أي شخص في الشركة أن يعرف في أي وقت ما إذا كانت أي مجموعة تعاني من تأخر ، وما هي الخوادم في تلك المجموعة ، وما إذا كان أي من المضيفين قد تعطل. Orchestrator هي أداة رائعة في هذا الصدد لأنها تجعل تصور المجموعات وصحتها بمثابة نافذة متصفح بعيدًا.

جرافانا / الجرافيت

تحتاج مقاييس طبقة قاعدة البيانات إلى العيش في نفس المكان ، توجد مقاييس لبقية البنية التحتية. من المهم أن يتمكن الفريق من وضع هذه المقاييس جنبًا إلى جنب. ومن المهم أن يكون لديك طريقة سهلة لمشاهدة المقاييس التاريخية لأي مجموعة قواعد بيانات. بينما قد يكون لديك تفضيل شخصي لـ Cacti أو munin ، أو القوالب الحرفية التي كتبتها على مر السنين ، إذا لم تكن المقاييس التي تستخدمها للتحقيق في المشكلات في نفس المكان مثل باقي مقاييس البنية التحتية ، فإنها تضع حاجزًا لها المهندسين المشغولين الآخرين - وسيكونون أقل ميلًا لاستخدام أدواتك على تلك المستخدمة في مكان آخر. يستخدم الجرافيت على نطاق واسع لاستيعاب المقاييس في فرق البنية التحتية الحديثة ، وجرافانا هو واجهة أمامية تستخدم على نطاق واسع في لوحة القيادة للمقاييس والتحليلات.

أداء الاستعلام

نحن نستخدم VividCortex لتتبع استفساراتنا حول المجموعات الحرجة ، وبينما لا يُقصد من هذه المقالة أن تكون إعلانًا عن خدمة مدفوعة ، سأقول إنك بحاجة إلى جعل القدرة على فحص تأثير عمليات النشر وتغيير الكود على تشغيل الاستعلامات و أداء الاستعلام عن شيء لا يحتاج إلى وصول خاص إلى السجلات وطحنها يدويًا. إذا لم يكن VividCortex ممكنًا (على الرغم من أنها رائعة على محمل الجد!) ، فهناك منتجات أخرى وأدوات مفتوحة المصدر يمكنها التقاط السجل البطيء فقط ووضعه في صفحة ويب سهلة القراءة لغير مسؤولي قواعد البيانات لفحصها ونرى تأثير التعليمات البرمجية الخاصة بهم. النقطة المهمة هنا هي أنك إذا وفرت الوسائل لرؤية البيانات ، فسيستخدم المهندسون تلك البيانات ويبذلون قصارى جهدهم للحفاظ على كفاءة الأشياء. ولكن جعل هذا الوصول متاحًا جزء من وظيفتك وليس خدعة DBA خاصة.

حارب إجهاد جهاز النداء

لا تقوم الكثير من المؤسسات بتوسيع نطاق طبقة قاعدة البيانات باعتباره ضرورة مبكرة جدًا في تصميم المكدس الخاص بهم - ولا ينبغي عليهم ذلك. في الأيام الأولى للشركة ، لا داعي للقلق بشأن كيفية خنق مكالمات واجهة برمجة التطبيقات إذا لم يستخدم أحد واجهة برمجة التطبيقات حتى الآن. ولكن من المناسب التفكير بعد بضع سنوات ، عندما اكتسب المنتج قوة جذب ، واستدعاء واجهة برمجة التطبيقات الذي كان يضرب جدولًا من بضعة آلاف من الصفوف من قبل حفنة من العملاء أصبح الآن جدولًا يضم عدة ملايين من الصفوف ، واثنين من العملاء لقد أنشأوا وظائف كرون تغمر واجهة برمجة التطبيقات هذه كل صباح في الساعة 6 صباحًا في منطقتك الزمنية.

يتطلب الأمر الكثير من العمل لتغيير طبقة التطبيق لأي منتج لحماية البنية التحتية ، وفي غضون ذلك ، فإن السماح لنشاط قاعدة البيانات الزائف بالتسبب في إجهاد جهاز الاستدعاء يمثل خطرًا كبيرًا عليك وعلى بقية منظمة العمليات. تعرف على أدوات مثل pt-kill التي يمكن استخدامها بطريقة محكمة لمنع مضيف قاعدة البيانات من حدوث توقف كبير بسبب الحجم غير المخطط له. اجعل استخدام هذه الأداة معروفًا وقم بإيصال الإجراء وتأثيره إلى فريق الهندسة القابضة ، ولكن من غير الصحي محاولة امتصاص الألم من شيء لا يمكنك تغييره بشكل مباشر ولن يكون مفيدًا في النهاية لمساعدة فرق الهندسة تعلم كيفية التعامل مع آلام النمو.

هناك الكثير من الطرق التي يكون فيها عمل DBA فريدًا بالنسبة لدورها مقارنة ببقية فريق العمليات ، لكن هذا لا يعني أنه يجب أن يكون كهنوتًا سحريًا لا يمكن لأحد الاقتراب منه. تقطع هذه الخطوات شوطًا طويلاً في جعل عملك شفافًا ، ولكن الأهم من ذلك هو التعامل مع عملك ليس كحارس بوابة إلى حديقة ذهبية لمضيف قاعدة البيانات ولكن كخبير في الموضوع يمكنه تقديم المشورة والمساعدة في تنمية المهندسين الذين تعمل معهم وتقديم المزيد قيمة للأعمال من النسخ الاحتياطية وضبط الاستعلام (ولكن هذه ممتعة أيضًا!).

شكر خاص لفريق العمليات الرائع في Sendgrid الذين يواصلون تعليمي أشياء كثيرة ، وإلى Charity Majors لصياغة عنوان هذا المنشور. وتحقق من المزيد من المشاركات حول DBAs هنا.