تشاريتي مايجورز، المدير التقني والمؤسس المشارك في Honeycomb – سلسلة المقابلات

تشاريتي هي مهندسة عمليات ومؤسس شركة بدأت بالصدفة في Honeycomb. قبل ذلك، عملت في Parse وFacebook وLinden Lab على البنية التحتية وأدوات المطورين، وبدت وكأنها دائمًا تصل إلى تشغيل قواعد البيانات. وهي المؤلف المشارك لكتاب هندسة الموثوقية لقواعد البيانات من O’Reilly، وتحب الحرية في التعبير، والبرمجيات الحرة، وويسكي المالت الاسكتلندي.

كنت مدير الهندسة الإنتاجية في فيسبوك (الآن ميتا) لمدة أكثر من 2 عام، ما هي بعض الإنجازات التي حققتها خلال هذه الفترة وما هي بعض النتائج الرئيسية التي استفدت منها من هذه التجربة؟

عملت على Parse، وهو خلفية ل تطبيقات الهاتف المحمول، نوعًا ما مثل Heroku لتطبيقات الهاتف المحمول. لم أكن مهتمًا بالعمل في شركة كبيرة، ولكننا تم الاستحواذ علينا من قبل فيسبوك. واحدة من النتائج الرئيسية التي توصلت إليها هي أن عمليات الاستحواذ صعبة للغاية، حتى في أفضل الظروف. النصيحة التي أ给ها دائمًا لمؤسسي الشركات الأخرى الآن هي هذه: إذا كنت ستتم الاستحواذ عليك، تأكد من أن لديك راعًا تنفيذيًا، وفكر جيدًا فيما إذا كنت تمتلك انسجامًا استراتيجيًا. استحوذ فيسبوك على Instagram قبل وقت قصير من الاستحواذ على Parse، وتمت عملية الاستحواذ على Instagram بسهولة نسبيًا، ولكنها كانت في النهاية ناجحة لأنهم كانوا يتمتعون بانسجام استراتيجي ومدافع قوي. (META )

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

هل يمكنك مشاركة قصة ولادة Honeycomb؟

بالتأكيد. من منظور معماري، كان Parse متقدمًا على وقته — كنا نستخدم خدمات صغيرة قبل أن تصبح خدمات صغيرة شائعة، وكنا نمتلك طبقة بيانات شاردة بشكل كبير، وكنا نمتلك الكثير من مشاكل التأجير المتعددة المعقدة. كان عملاؤنا مطورين، وكانوا يكتبون ويحملون شفرة وطلبات جديدة ذات جودة متغيرة — وكنا مجبرين على قبول كل ذلك وجعلها تعمل بطريقة ما.

كنا في طليعة التغييرات التي أصبحت شائعة لاحقًا. كان من المعتاد أن تكون معظم البنيات بسيطة، وستفشل بشكل متكرر بطرق متوقعة. كان لديك طبقة ويب، وتطبيق، وقاعدة بيانات، وغالبية التعقيد كانت مرتبطة بкод التطبيق. لذا كنت تكتب فحوصات مراقبة لمتابعة هذه الأعطال، وتنشيء لوحات تحكم ثابتة لمعلومات المراقبة والقياس.

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

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

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

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

كان ذلك مذهلًا. مصدر كبير من عدم اليقين والجهد والعملاء غير السعداء والصفحات في الساعة 2 صباحًا… اختفى. لم يكن حتى بعد أن غادرنا فيسبوك حتى أدركنا مدى تغييره الطريقة التي نتعامل بها مع البرمجيات. لم يكن من الممكن العودة إلى الأيام السيئة القديمة لمراقبة الاختبارات واللوحات.

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

لمن لا يعرف، ما هو بالضبط منصة المراقبة، وكيف تختلف عن المراقبة التقليدية والقياسات؟

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

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

أنت معروف باعتقادك أن المراقبة توفر مصدرًا وحيدًا للtruth في بيئات الهندسة. كيف يتكامل الذكاء الاصطناعي مع هذا الرؤية، وما هي الفوائد والتحديات في هذا السياق؟

المراقبة مثل وضع النظارات قبل أن تذهب إلى الطريق السريع. تطوير البرمجيات القائم على الاختبار (TDD) ثورة البرمجيات في أوائل العقد 2000، ولكن TDD كان يفقد الفعالية مع زيادة التعقيد في الأنظمة بدلاً من البرمجيات فقط. بشكل متزايد، إذا كنت تريد الحصول على الفوائد المرتبطة بالتطوير القائم على الاختبار، فعليك بالفعل تحقيق التكامل بين شفرتك وتنفيذ شيء مشابه للمراقبة القائمة على التطوير، أو ODD، حيث تقوم بتحقيق التكامل أثناء ذهابك، ثم تنشر بسرعة، ثم تنظر إلى شفرتك في الإنتاج من خلال عدسة التكامل الذي كتبته刚، وسؤال نفسك: “هل هي تفعل ما توقعته، وهل هناك شيء آخر يبدو… غريبًا؟”

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

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

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

لقد أثيرت مخاوف بشأن الديون الفنية المتزايدة بسبب ثورة الذكاء الاصطناعي. هل يمكنك توضيح أنواع الديون الفنية التي يمكن للذكاء الاصطناعي إدخالها وكيف تساعد Honeycomb في إدارة أو تقليل هذه الديون؟

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

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

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

كيف تستخدم Honeycomb الذكاء الاصطناعي لتحسين كفاءة وفعالية فرق الهندسة؟

مطورونا يستخدمون الذكاء الاصطناعي كثيرًا داخليًا، خاصة CoPilot. المطورون الأقل خبرة يبلغون عن استخدام ChatGPT كل يوم للاجابة على الأسئلة ومساعدتهم على فهم البرمجيات التي يبنيونها. المطورون الأكثر خبرة يقولون إنها رائعة لإنشاء برنامج سيء أو مزعج لكتابة، مثل ملف YAML كبير لملأه. كما أنها مفيدة لإنشاء شفرة في لغات لا تستخدمها عادة، أو من وثائق API.

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

هل يمكنك تقديم أمثلة عن كيفية تحسين ميزات مدعومة بالذكاء الاصطناعي مثل مساعد الاستفسار أو التكامل مع Slack التعاون بين الفرق؟

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

لذلك يسمح لنا مساعد الاستفسار بطرح الأسئلة باستخدام اللغة الطبيعية. مثل “ما هي النقاط البطيئة؟” أو “ماذا حدث بعد آخر نشر لي؟” وينشئ استفسارًا ويدخله. يجد معظم الناس صعوبة في تكوين استفسار جديد من الصفر، وسهولة في تعديل استفسار موجود، لذا يعطيك فرصة.

تعد Honeycomb بتحقيق حل أسرع للمشاكل. هل يمكنك وصف كيف يساعد دمج السجلات والقياسات والأثر في نوع بيانات موحد في تصحيح الأخطاء وحل المشاكل بشكل أسرع؟

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

تكون البيانات قيمة من السياق. كان الجيل السابق من الأدوات يعمل bằng إزالة كل السياق في وقت الكتابة؛ بمجرد أن تلقى السياق، لا يمكنك الحصول عليه مرة أخرى.

عندما تخزن هذه البيانات الغنية بالسياق، يمكنك فعل أشياء بها تشبه السحر. لدينا أداة تسمى BubbleUp، حيث يمكنك رسم دائرة حول أي شيء تعتقد أنه غريب أو قد يكون مثيرًا للاهتمام، ونحسب جميع الأبعاد داخل الدائرة مقابل الخارج، والأساس، وفرزها وفرقها. لذا فأنت تقول “هذه الدائرة غريبة” ونقول لك على الفور “إنها مختلفة بطرق xyz”. كثير من تصحيح الأخطاء ي归 إلى “هناك شيء أهتم به، ولكن لماذا أهتم به؟” عندما يمكنك تحديد على الفور أن هذا يختلف لأن هذه الطلبات تأتي من أجهزة Android، مع هذا المعرف المحدد، باستخدام هذا حزمة اللغة، في هذه المنطقة، مع هذا معرف التطبيق، مع حمولة كبيرة … الآن ربما تعرف بالفعل ما الخطأ ولماذا.

ليس فقط حول البيانات الموحدة، ولكن أيضًا حول كيفية التعامل مع بيانات الأهمية العالية بسهولة. الجيل السابق من الأدوات لا يستطيع التعامل مع بيانات غنية مثل هذه، وهو أمر غير معقول عندما تفكر فيه، لأن البيانات الغنية والأهمية العالية هي الأكثر قيمة وتعريفًا من بين جميع البيانات.

كيف يترجم تحسين المراقبة إلى نتائج تجارية أفضل؟

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

أين تري مستقبل المراقبة يتجه، خاصةً فيما يتعلق بتطورات الذكاء الاصطناعي؟

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

إنه حول ربط النقاط بين النتائج التجارية والأساليب التكنولوجية.

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

من منظور المراقبة، سنرى مستويات متزايدة من التعقيد في خط أنابيب البيانات — باستخدام التعلم الآلي والتقنيات العينة المتطورة لتحقيق توازن بين القيمة والتكلفة، للحفاظ على أكبر قدر ممكن من التفاصيل حول الأحداث النادرة والأحداث المهمة، وتخزين ملخصات الباقي بأرخص طريقة ممكنة.

موردي الذكاء الاصطناعي يطرحون مطالبات مثيرة للغاية حول كيف يمكنهم فهم برنامجك أفضل منك، أو كيف يمكنهم معالجة البيانات وتوجيه إجراءاتك. من كل ما رأيته، هذا حلم باهظ الثمن. الإيجابيات الكاذبة باهظة الثمن. لا يوجد بديل لفهم أنظمتك وبياناتك. يمكن للذكاء الاصطناعي مساعدة مهندسي البرمجيات في هذا! لكنه لا يمكن أن ي置ها محلها.

شكرًا على المقابلة الرائعة، القراء الذين يرغبون في التعلم أكثر يجب أن يزوروا Honeycomb.