Velocity هو مؤتمر مخصص للأنظمة الموزعة. يتم تنظيمه من قبل O'Reilly ، ويقام ثلاث مرات في السنة: مرة في كاليفورنيا ، ومرة في نيويورك ومرة في أوروبا (والمدينة تتغير كل عام).
في عام 2018 ، كان المؤتمر في لندن من 30 أكتوبر إلى 2 نوفمبر. يقع المكتب الرئيسي ل Badoo ، لذلك كان لدي ولزملائي سببان للذهاب إلى Velocity.
تبين أن جهازها أكثر تعقيدًا إلى حد ما من الجهاز الذي صادفته في المؤتمرات الروسية. بالإضافة إلى اليومين المعتادين من العروض التقديمية ، كان هناك يومان آخران من التدريب ، والذي يمكن إجراؤه بالكامل ، جزئيًا أو لا. معًا ، يتحول هذا إلى مهمة جادة لاختيار نوع التذكرة التي تحتاجها.
في هذه المراجعة ، سأتحدث عن تلك التقارير والفصول الرئيسية التي أتذكرها. أرفق روابط لمواد إضافية لبعض التقارير. جزئيا ، هذه المواد التي أشار إليها المؤلفون ، وجزئيا مواد لمزيد من الدراسة ، وجدت نفسي.
الانطباع العام للمؤتمر: أداء المؤلفين جيدًا جدًا (والجلسات الرئيسية هي عرض كامل مع المتحدثين الذين يقدمون الموسيقى ويذهبون إلى المسرح) ، ولكن في نفس الوقت صادفت بعض التقارير التي كانت عميقة من وجهة نظر فنية.
أهم موضوع في هذا المؤتمر هو Kubernetes ، والذي يتم ذكره في كل تقرير ثان تقريبًا.
العمل مع الشبكات الاجتماعية مبني بشكل جيد للغاية: في حساب تويتر الرسمي خلال المؤتمر كان هناك الكثير من التغريدات التشغيلية مع التقارير. هذا سمح بإلقاء نظرة سريعة على ما كان يحدث في غرف أخرى.
دروس الماجستير
كان 31 أكتوبر هو اليوم الذي لم تكن فيه تقارير ، ولكن كان هناك ست أو ثماني فصول رئيسية لمدة ثلاث ساعات من الوقت الخالص لكل منها ، وكان يجب اختيار اثنين منها.
ملاحظة: في الأصل ، يطلق عليهم البرنامج التعليمي ، ولكن يبدو لي أنه من الصحيح ترجمتها على أنها "فصل دراسي".
معسكر تدريبي هندسة الفوضى
تقديم: آنا مدينا ، مهندس في Gremlin | الوصف
تم تخصيص ورشة العمل لتقديم هندسة الفوضى. أخبرت أنا بطلاقة ما هي ، وما هي الفوائد التي تجلبها ، وأوضحت كيف يمكن استخدامها ، وما هي البرامج التي يمكن أن تساعد وكيف تبدأ في استخدامها في الشركة.
بشكل عام ، كانت هذه مقدمة جيدة للمبتدئين ، لكني لم يعجبني حقًا الجزء العملي ، وهو نشر تطبيق ويب تجريبي في مجموعة من العديد من الأجهزة باستخدام Kubernetes ومراقبة الشد من DataDog إليه. كانت المشكلة الرئيسية هي أننا قضينا ما يقرب من نصف وقت الفصل الرئيسي في هذا الأمر وكان من الضروري فقط اللعب مع النصوص التي تحاكي مشاكل مختلفة في المجموعة لمدة 5-10 دقائق وإلقاء نظرة على التغييرات في الرسوم البيانية.
يبدو لي أنه من أجل نفس التأثير كان كافياً لمنح الوصول إلى DataDog المهيأ مسبقًا و / أو لتوضيح كل شيء من المشهد ، ويجب قضاء هذه المرة ، على سبيل المثال ، في مراجعة أكثر تفصيلاً وأمثلة على استخدام نفس قرد الفوضى ، الذي تم الحديث عنه للتو حرفياً بضع عبارات.
المثير للاهتمام: في هذا المؤتمر ، غالباً ما ذكر المتحدثون مصطلح "نصف قطر الانفجار" ، الذي لم أره من قبل. لقد حددوا الجزء من النظام الذي يتأثر عند حدوث مشكلة معينة.
مواد إضافية:
بناء البنية التحتية التطورية
تقديم: كيف موريس ، مستشار البنية التحتية ومؤلف البنية التحتية كرمز | الوصف
يمكن تقليل النقاط الرئيسية للفصل الرئيسي إلى شيئين:
- تتغير الأنظمة طوال الوقت ، لذلك من الطبيعي أن تتغير البنية التحتية أيضًا ؛
- بمجرد تغيير البنية التحتية ، فأنت بحاجة إلى التأكد من أنها بسيطة وآمنة ، ولا يمكن تحقيق ذلك إلا عن طريق الأتمتة.
تم تخصيص الجزء الرئيسي من قصته على وجه التحديد لأتمتة تغييرات البنية التحتية والحلول الممكنة لهذه المشكلة واختبار التغييرات. لست خبيرًا في هذا الموضوع ، ولكن بدا لي أنه كان يتحدث بثقة وتفصيل (وسريع جدًا).
النقطة الرئيسية التي أتذكرها من هذه الفئة الرئيسية هي التوصية لتعظيم التمييز بين البيئات (الإنتاج ، التدريج ، إلخ) من الشفرة إلى متغيرات البيئة. سيقلل هذا من احتمال حدوث أخطاء في البنية التحتية عند تغيير البيئة ويجعلها أكثر قابلية للاختبار.
التقارير
1 و 2 نوفمبر كانت أيام التقارير. تم تقسيمهم إلى كتلتين رئيسيتين: سلسلة من ثلاثة أو أربعة تقارير رئيسية قصيرة ذهبت في تيار واحد في الصباح (وبالنسبة لهم قاعة كبيرة مجمعة من اثنين أصغر) وتقارير مواضيعية أطول في خمسة تدفقات استمرت بقية اليوم . خلال النهار كانت هناك عدة فترات توقف كبيرة بين التقارير ، عندما كان من الممكن التجول في المعرض مع مواقف شركاء المؤتمر.
تطور Runtastic Backend
Simon Lasselsberger (Runtastic GmbH) | الوصف والشرائح
أحد التقارير القليلة التي لم يصرح فيها المؤلف فقط بكيفية القيام بشيء ما ، بل أظهر تفاصيل عن مشروع معين وما حدث له.
في البداية ، كان لدى Runtastic قاعدة بيانات Percona Server مشتركة وموحد مع رمز يخدم تطبيقات الهاتف المحمول وموقع. ثم بدأوا في الكتابة في كاساندرا (لا أتذكر سبب وجودها) ذلك الجزء من البيانات الذي كانت فيه القيمة الرئيسية للتخزين كافية. تدريجيا ، أصبحت قاعدة البيانات منتفخة ، وأضافوا MongoDB ، حيث بدأوا في كتابة البيانات من معظم الخدمات. بمرور الوقت ، جعلوا مستوى عامًا يخدم الطلبات من كل من تطبيقات الويب والجوال (شيء مثل تطبيقنا ، كما أفهمه).
تم تخصيص معظم التقرير للتنقل بين مراكز البيانات. في البداية احتفظوا بالخادم في Hetzner ، والذي اعتبر بعد مرور بعض الوقت غير مستقر بشكل كاف وتم ترحيل البيانات إلى T-Systems. بعد بضع سنوات ، واجهوا نقصًا في المساحة بالفعل وانتقلوا مرة أخرى إلى Linz AG. الجزء الأكثر إثارة للاهتمام هنا هو ترحيل البيانات. بدأوا في نسخ البيانات التي استمرت عدة أشهر. لم يستطيعوا الانتظار كثيرا بسبب نفدت المساحة ، ولم يتمكنوا من إضافتها ، لذلك قاموا بالتراجع في الكود ، الذي حاول قراءة البيانات من مركز البيانات القديم إذا لم يكن في المركز الجديد.
في المستقبل ، يخططون لتقسيم البيانات إلى عدة مراكز بيانات منفصلة (قال سيمون عدة مرات أن هذا ضروري لروسيا والصين) وتقسيم قواعد البيانات بشكل صارم عن طريق خدمات منفصلة (الآن يتم استخدام مجموعة مشتركة لجميع الخدمات).
نهج مثير للاهتمام لتصميم الوحدات في النظام ، والذي ذكر عنه سايمون عرضًا: العمارة السداسية .
السماح بتطبيق مدفوع بالتساوي من قبل المستخدمين أو البرامج أو الاختبارات التلقائية أو البرامج النصية المجمعة ، وأن يتم تطويره واختباره بمعزل عن أجهزة وقواعد بيانات وقت التشغيل المحتملة.
اليستير كوكبيرن
مواد إضافية:
مراقبة المقاييس المخصصة ؛ أو ، كيف تعلمت العزف أولاً وطرح الأسئلة لاحقًا
ماكسيم بيتازوني (SignalFx) | الوصف والعرض
تم تخصيص القصة لجمع المقاييس اللازمة لفهم التطبيق. كانت الرسالة الرئيسية هي أن مقاييس RED المعتادة (التقييم والأخطاء والمدة) ليست كافية تمامًا ، وإلى جانبها ، تحتاج إلى جمع الآخرين على الفور مما سيساعد على فهم ما يحدث داخل التطبيق.
الخلاصة ، اقترح المؤلف جمع العدادات والموقتات لبعض الإجراءات المهمة في النظام (وبالتأكيد عدادات الفشل) ، وبناء الرسوم البيانية والرسوم البيانية للتوزيع منها ، وتحديد نموذج تلوي لمقاييس المستخدم (بحيث يكون للمقاييس المختلفة نفس مجموعة المعلمات المطلوبة وتسمى نفس المعاني في كل مكان).
من الصعب إعادة سرد التفاصيل بالكلمات ، سيكون من الأسهل رؤية التفاصيل والأمثلة في العرض التقديمي ، يوجد رابط في صفحة التقرير على موقع المؤتمر على الإنترنت.
مواد إضافية:
كيف يغير الخادم إدارة قسم تكنولوجيا المعلومات
مختبرات بول جونستون (Roundabout Labs) | الوصف والعرض
قدم المؤلف نفسه على أنه CTO وبيئي ، قال إن الخادم ليس حلًا تكنولوجيًا ، ولكنه حل تجاري ("لا تدفع شيئًا إذا لم يتم استخدامه"). ثم وصف أفضل الممارسات للعمل مع الخوادم ، وما هي الكفاءات اللازمة للعمل معها وكيف تؤثر على اختيار الموظفين الجدد والعمل مع الموظفين الحاليين.
اللحظة الرئيسية لـ "التأثير على قسم تكنولوجيا المعلومات" الذي تذكرته هو تحول الكفاءات اللازمة من مجرد كتابة التعليمات البرمجية إلى العمل مع البنية التحتية وأتمتتها ("هندسة" أكثر "من" تطوير "). كل شيء آخر كان عاديًا جدًا (تحتاج إلى تنفيذ باستمرار مراجعة التعليمات البرمجية ، لتوثيق تدفقات البيانات والأحداث المتاحة للاستخدام في النظام ، للتواصل أكثر والتعلم بسرعة) ، ولكن لسبب ما عزاها المؤلف إلى ميزات بدون خادم.
بشكل عام ، بدا التقرير مختلطًا بعض الشيء. يمكن أن يعزى العديد من الأشياء التي تحدث عنها المتحدث إلى أي نظام معقد لا يتناسب تمامًا مع الرأس.
مواد إضافية:
لا داعي للذعر! كيف تتأقلم الآن مع مسؤوليتك عن الإنتاج
إيوان فينلي (فاينانشيال تايمز) | الوصف والعرض
تقرير حول كيفية التعامل مع حوادث الإنتاج إذا حدث خطأ ما الآن. تم تقسيم النقاط الرئيسية إلى أجزاء حسب الوقت.
قبل الحادث:
- تمييز التنبيهات حسب الأهمية - ربما يستطيع البعض الانتظار ، ولا تحتاج إلى التعامل معها بشكل عاجل ؛
- إعداد خطة لتحليل الحوادث مقدمًا والحفاظ على الوثائق محدثة ؛
- إجراء التمارين - كسر شيء ومعرفة ما يحدث (ويعرف أيضًا باسم هندسة الفوضى) ؛
- إنشاء مكان واحد حيث تتجمع جميع المعلومات حول التغييرات والمشكلات.
خلال الحادث:
- من الطبيعي أنك لا تعرف كل شيء - جذب الآخرين إذا لزم الأمر ؛
- إنشاء مكان واحد للتواصل بين الأشخاص الذين يعملون على حل الحادث ؛
- ابحث عن أبسط الحلول التي ستعيد الإنتاج إلى حالة العمل ، ولا تحاول حل المشكلة تمامًا.
بعد الحادث:
- اكتشف لماذا نشأت المشكلة وماذا علمتك ؛
- من المهم كتابة تقرير عن هذا ("تقرير الحادث") ؛
- تحديد ما يمكن تحسينه وتخطيط إجراءات محددة.
في النهاية ، روى إيوان قصة مضحكة عن الحادثة في الفاينانشيال تايمز ، نشأت بسبب تعديل قاعدة الإنتاج (تسمى برود ) عن طريق الخطأ بدلاً من مرحلة ما قبل الإنتاج ( برود ) ، ونصحت بتجنب مثل هذه الأسماء المماثلة.
التعلم من شبكة الحياة (Keynote)
كلير جانيش (BiomimicrySASA) | الوصف
لقد تأخرت عن هذا التقرير ، ولكن على تويتر تحدثوا جيدًا عنه. أنت بحاجة لمعرفة ما إذا كانت تأتي عبر.
يمكن مشاهدة مقطع فيديو به جزء من الخطاب على موقع المؤتمر .
جين ادامز (اثنان من استثمارات سيجما) | الوصف
تقرير فلسفي حول الموضوع "هل يمكننا الوثوق بخوارزميات صنع القرار." كان الاستنتاج العام هو لا: الخوارزمية يمكنها تحسين مقاييس معينة ، ولكن في نفس الوقت تؤثر بشكل خطير على ما يصعب قياسه أو يقع خارج هذه المقاييس (كمثال ، كان هناك تمييز في الخوارزمية لتوظيف الموظفين في أمازون ، مما أثر سلبًا على الثقافة في الشركة وأجبر على التخلي عن هذه الخوارزمية).
حرية Kubernetes (Keynote)
كريس نوفا | الوصف
من هناك تذكرت فكرتين:
- المرونة ليست الحرية ، بل الفوضى.
- التعقيد في حد ذاته ليس مشكلة إذا كان يحمل أي قيمة (في الأصل كان يطلق عليه "التعقيد الضروري") ، والذي يتجاوز تكلفة هذا التعقيد.
كان التقرير فلسفيًا تمامًا ، لذلك ، من ناحية ، لم أستطع الحصول على الكثير منه ، ولكن من ناحية أخرى ، ما خرجت به ينطبق ليس فقط على Kubernetes.
ما الذي يتغير عندما نذهب دون اتصال بالإنترنت أولاً؟ (الكلمة الرئيسية)
مارتن كليبمان (جامعة كامبريدج) ، مؤلف تصميم تطبيقات كثيفة البيانات | الوصف
يتألف التقرير من جزأين منطقيين: في الأول ، تحدث مارتن عن مشكلة مزامنة البيانات فيما بينها ، والتي يمكن أن تختلف في عدة مصادر بشكل مستقل عن بعضها البعض ، وفي الثاني ، تحدث عن الحلول والخوارزميات الممكنة التي يمكن استخدامها لهذا ( التحول التشغيلي ، OT ، ونوع البيانات المنسوخة الخالية من التعارض ، CRDT)) واقترحت حلها - مكتبة الدمج الآلي لحل مثل هذه المشاكل.
مواد إضافية:
دليل مبرمج لتأمين الاتصالات
المتحدث: ليز رايس | الوصف والشرائح
تم عقد التقرير في شكل جلسة ترميز مباشر ، وفيه أظهرت ليز كيفية عمل HTTPS ، وما هي الأخطاء التي يمكن أن تحدث عند العمل مع اتصالات آمنة وكيفية حلها. لم يكن هناك أعماق كبيرة ، لكن المظاهرة نفسها كانت جيدة للغاية.
الأكثر فائدة: شريحة بها الأخطاء الرئيسية ( تعرف أيضًا بتقرير ليز في مؤتمر آخر ):
مواد إضافية:
كل ما تريد معرفته عن المونوريبوس لكنك تخشى أن تسأل
سيمون ستيوارت (مشروع السيلينيوم) | الوصف
الأطروحة الرئيسية للتقرير هي أنه في monorepo من الأسهل بكثير إدارة التبعيات في الكود ، وهذا يغطي جميع مزايا المستودعات الفردية. وطعن في حقيقة أن Google و Microsoft يخزنان البيانات في مستودع واحد (بحجم 86 تيرابايت و 300 غيغابايت ، على التوالي) ، ويستخدم مستودع Facebook (54 ملفًا) "خارج الزئبق".
الغرفة "انفجرت" بعد السؤال "من لديه مستودعات في الشركة أكثر من الموظفين؟"
اندلعت الحجة "مع وجود مستودع كبير للعمل ببطء" على النحو التالي:
- لست مضطرًا إلى نقل سجل التغييرات بالكامل إلى الجهاز المحلي: استخدم استنساخ الظل والسداد المتناثر ؛
- لا يتعين عليك استخدام جميع الملفات من المستودع: تنظيم التسلسل الهرمي للملفات والعمل فقط مع الدليل الضروري ، واستبعاد كل شيء آخر.
مواد إضافية:
بناء نظام معالجة دفق في الوقت الحقيقي الموزع
ايمي بويل (بقايا جديدة) | الوصف والعرض
قصة جيدة حول العمل مع تدفق البيانات من مهندس من NewRelic (حيث من الواضح أن لديهم الكثير من الخبرة في العمل مع هذه البيانات). قالت إيمي إنها تعمل مع دفق البيانات ، وكيف يمكن تجميعها ، وما الذي يمكن عمله بالبيانات المتخلفة ، وكيف يمكن لدفقات الأحداث المتقطعة وكيفية إعادة توازنها في حالة فشل المعالج ، وما يجب مراقبته ، وما إلى ذلك.
كان التقرير يحتوي على الكثير من المواد ، ولن أحاول إعادة بيعه ، ولكن أوصي فقط بمشاهدة العرض التقديمي نفسه (إنه موجود بالفعل على موقع المؤتمر).
هندسة التلفزيون
ديفيد بكهورست (بي بي سي) ، روس ويلسون (بي بي سي) | الوصف
كان معظم الحديث عن الواجهة الأمامية لهيئة الإذاعة البريطانية. يمتلك الرجال تلفزيونًا تفاعليًا والعديد من أجهزة التلفاز والأجهزة الأخرى (أجهزة الكمبيوتر والهواتف والأجهزة اللوحية) التي يجب أن تعمل عليها. تحتاج إلى العمل مع أجهزة مختلفة بطرق مختلفة تمامًا ، لذلك توصلوا إلى لغتهم الخاصة المستندة إلى JSON لوصف الواجهات وترجمتها إلى ما يمكن لجهاز معين فهمه.
الاستنتاج الرئيسي بالنسبة لي هو أنه مقارنة بأفراد التلفزيون ، لا تواجه تطبيقات الهاتف المحمول مشاكل مع العملاء القدامى.
