يقدم الاتصال الداخلي محادثات المهندس

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

على مر السنين ، غطينا الكثير من موضوعات البودكاست الخاصة بنا. كل أسبوع ، نقدم لك نظرة ثاقبة في عالم إدارة المنتجات وتصميمها ودعمها وتسويقها باستخدام Inside Intercom ؛ استكشاف كيفية استخدام قادة الصناعة لتجربة العملاء لتنمية أعمالهم باستخدام Scale ؛ ويظهر لك عالم المؤسس المشارك لشركة Intercom Des Traynor و Intercom SVP للمنتج ، Paul Adams ، حيث يشاركون آخر أفكارهم حول كيفية بناء منتجات رائعة.

والآن عن شيء مختلف تماما. لأول مرة ، نطلق محادثات المهندس ، وهي عبارة عن بودكاست داخلي هنا في Intercom حول كل ما يتعلق بالهندسة. استضافه جيمي أوسلر سابقًا ، كبير مهندسي المنتجات في Intercom لأكثر من سبع سنوات ، الأمر متروك الآن لمهندس الأنظمة الرئيسي Brian Scanlan لالتقاط العصا ومواصلة المحادثات.

هذا الأسبوع ، إلى جانب جيمي وبريان ، سوف تسمع أيضًا من:

• مايك ستيوارت ، كبير المهندسين الرئيسيين سابقًا في Intercom
• باتريك أودهيرتي ، كبير مهندسي الأمن سابقًا في Intercom والآن مهندس في Oso
• المؤسس المشارك لشركة Intercom Ciaran Lee
• مينا بوليش ، كبير مستشاري Intercom لدعم البحث والتطوير

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

إذا كان لديك وقت قصير ، فإليك بعض النصائح السريعة:

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

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

حسام جيراغتي: مرحبًا بكم ، ومرحبًا بكم في Inside Intercom. أنا ليام جيراغتي. إذا كنت مستمعًا منتظمًا ، فستعرف أننا نجري مقابلات مع صناع وجهات فاعلة من عوالم إدارة المنتجات والتصميم والشركات الناشئة والتسويق. لدينا أيضًا ملفان بودكاست آخران - Intercom on Product ، حيث يناقش الشريك المؤسس لشركة Intercom Des Traynor والنائب الأول للرئيس لشركة Intercom ، Paul Adams ، أفكارهما الأخيرة حول كيفية إنشاء منتجات ناجحة على نطاق واسع وعلى نطاق من خلال Intercom - حيث نستكشف كيف تكون الأعمال التجارية دفع النمو من خلال العلاقات مع العملاء.

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

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

إزالة الغموض على طول الطريق

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

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

"لديك مساحة حل واسعة ... إنها عملية التخلص من ذلك استنادًا إلى الأدلة والقرارات والمكالمات"

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

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

"أنا أفكر في هذا كواحد من مقاطع الفيديو للكون والتي تنتقل من التكبير على طول الطريق إلى الأرض كنقطة في مجرة ​​وعلى طول الطريق من خلال المقياس البشري والمقياس الصغير"

جيمي أوسلر: لقد قمت بتضييق ذلك أيضًا. ربما يمكنك توضيح ذلك قليلاً.

ليام جيراغتي: يمتلك مايك طريقة رائعة لتصور عملية إزالة اللبس.

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

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

أن تكون واحدًا مع نماذج البيانات

ليام جيراغتي: لربط كل هذا بمثال ملموس ، يقدم جيمي هذا المثال.

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

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

لا يمكنك ابتكار خوارزمية مستقلة عن نموذج البيانات. وأعتقد أن الأمر نفسه ينطبق عندما تبدأ الحديث عن الأنظمة وميزات المنتج "

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

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

"لا أشعر بالراحة أبدًا للمضي قدمًا في التصميم الفني ما لم أفهم تمامًا نماذج البيانات"

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

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

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

مايك ستيوارت: أتمنى أن تكون محادثة رائعة يا جيمي ، وآمل أن نحصل على بعض المحتويات المفيدة هنا.

Jamie Osler: محتوى Hashtag.

الجانب المشرق من الانقطاع السيء للغاية

ليام جيراغتي: في وقت سابق من هذا العام ، إذا كنت من مستخدمي Facebook أو WhatsApp أو Instagram ، فلا شك أنك ستتذكر هذا الانقطاع في أكتوبر. كان أطول انقطاع عالمي لفيسبوك في تاريخه. كل ذلك يعود إلى تغيير خاطئ في التكوين من نهايتها. لذا ، فإن انقطاع التيار الكهربائي ليس ممتعًا لأي شخص. الشخص الذي يكرههم بشكل خاص هو مهندس أنظمة الاتصال الداخلي الرئيسي ، براين سكانلان.

بريان سكانلان: أكره انقطاع التيار الكهربائي ، ولهذا كرست حياتي المهنية لمكافحتها.

ليام جيراغتي: جلس برايان للدردشة مع جيمي بشأنهما في نوفمبر 2020.

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

Liam Geraghty: تذكر Brian بعض الانقطاعات الملحوظة في Intercom.

"أتذكر أنني كنت أريد أن أمرض في سلة المهملات عندما أدركت أن Elasticsearch كان فارغًا. كنت مثل ، "أوه ، هذا سيء للغاية"

بريان سكانلان: من أكثر حالات الانقطاع عن العمل صدمةً التي تعرضت لها ، على الرغم من أنني لم أكن موجودًا بالفعل أثناء الانقطاع ، كان انقطاع Elasticsearch الكبير في يناير 2019.

ليام جيراغتي: كان هناك شخص ما كان هناك باتريك أودهيرتي ، كبير مهندسي الأمن هنا في ذلك الوقت.

باتريك أودهيرتي: أتذكر أنني أردت أن أمرض في سلة المهملات عندما أدركت أن Elasticsearch كان فارغًا. كنت مثل ، "أوه ، هذا سيء للغاية."

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

جيمي أوسلر: بين المشروبات؟

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

"في تلك المرحلة ، عندما تم تطبيق التهيئة ، كانت قد دمرت تمامًا شبكتنا أو أوقفتها عن الاتصال بالإنترنت"

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

جيمي أوسلر: أعني ، هذا سيء ، أليس كذلك؟ هذا ليس جيدا.

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

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

ولكن لسوء الحظ ، في هذه الأثناء ، بدأت عمليات أتمتة أخرى. هذه المرة ، كانت بعض الأتمتة مملوكة لشركة AWS. نستخدم هذه التقنية المسماة OpsWorks ، وهي نسخة مُدارة من Chef ، لإدارة مضيفي Elasticsearch لدينا. كانت تحتوي على هذه الوظيفة التي تسمى الإصلاح التلقائي المضمنة التي قمنا بتمكينها افتراضيًا في التكوين على مستوى المضيف. وإذا كان المضيفون لا يمكن الاتصال بهم من خلال الواجهة الخلفية لـ OpsWorks ، فإن نظام سير العمل في OpsWorks سيحاول معالجة المضيف المعني تلقائيًا لأنه اكتشف حدوث خطأ ما هناك. نظام التشغيل معطل ، ربما نفدت الذاكرة - حدث شيء سيء ، لذلك دعونا نحاول إصلاحه. لذلك ، قررت طائرة التحكم OpsWorks هذه إصلاح بنيتنا التحتية بالكامل عن طريق استبدال المضيفين.

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

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

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

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

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

بريان سكانلان: لقد حصلت أيضًا على حديث داخلي من هذا القبيل. أيضًا ، لم أكن في الحادث لأنني كنت في الحانة بمناسبة عيد ميلادي. كان عظيما. كانت الحادثة المثالية.

بسرعة الضوء

ليام جيراغتي: في ديسمبر 2020 ، في عيد الميلاد وأنا متأكد من أننا لن ننسى أبدًا ، انضم المؤسس المشارك لشركة Intercom ، كياران لي ، إلى جيمي للتحدث عن السرعة ولماذا يهتم كيران بالتحرك بسرعة.

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

هناك شيء واحد أحبه حقًا من Stripe ، وهي شركة رائعة أتطلع إليها ، وهو منشور مدونة رائع بواسطة Patrick McKenzie حيث وصف أنهم عيّنوا إيقاع التشغيل الافتراضي للتشغيل. يتخلفون عن التحرك بسرعة غير مريحة ، ويسألون دائمًا عما إذا كان بإمكاننا فعل الشيء بشكل أسرع هذا الأسبوع بدلاً من ستة أشهر من الآن. وأنا فقط أحب ذلك شخصيًا. لقد خدمنا هذا النوع من المواقف بشكل جيد حقًا. وأعتقد أنه من الممتع التفكير دائمًا. هل يمكنك الذهاب بشكل أسرع؟

"إنه لأمر رائع أن نصل إلى توفر مائة بالمائة في ربع عام ، ولكن ربما ينبغي أن نسأل أنفسنا ،" مرحبًا ، ألا نتحمل مخاطر كافية؟ "

جيمي أوسلر: إذا جعلت العمل بسرعة أمرًا بالغ الأهمية لشركتك ، وكان ذلك شيئًا تفعله طوال الوقت ، فإنك تميل إلى التقليل من الانهيار.

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

حيث يأتي القانون

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

"نحن هنا نسير بخطى ثابتة مع الشركة وجميع عملائنا للوصول إلى حيث نحتاج إلى الذهاب بمسؤولية دون إبطاء أي شخص"

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

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

"أولويتي الأولى هي مساعدة البحث والتطوير على فهم أنني لست هنا لعرقلة التقدم المذهل الذي نحققه"

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

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

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

ليام جيراغتي: شكري لجيمي أوسلر ، الذي أنشأ Engineer Chats ، ومضيفه الجديد Brian Scanlan ، وإلى جميع الضيوف اليوم الذين تفضلوا بوضع محادثاتهم الداخلية في الخارج. إذا كنت قد استمتعت ببرنامج اليوم ، فلماذا لا تترك لنا تعليقًا أو تعطينا صيحة على وسائل التواصل الاجتماعي. نحن نحب أن نرى ونسمع ما تعتقده. هذا هو كل شيء لهذا اليوم. سنعود الأسبوع المقبل بحلقة أخرى من Inside Intercom.