كيف يساعدنا التحفظ التقني على التوسع بشكل أسرع وأفضل

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

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

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

هذه هي المقالة السادسة في سلسلة تستكشف مبادئ منتجاتنا . هنا ، يناقش وحيد مبدأنا الهندسي "كن متحفظًا تقنيًا".

هناك العديد من الفوائد طويلة المدى للمحافظة التقنية

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

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

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

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

لقد قمنا بحل مشكلة العميل بشكل أسرع

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

حققنا أقصى استفادة من وقت الفريق

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

" نظرًا لأن مجموعة التقنيات لدينا صغيرة نسبيًا ، فإن التحسينات تحدث بانتظام"

ضاعفنا قيمة التحسينات المستمرة

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

المزيد من الفرق لديها المزيد من المدخلات

يعني استخدام التقنيات الشائعة أن المزيد من المهندسين والفرق يشعرون بالثقة والقدرة على العمل معهم. لقد رأينا تحسينات متكررة على منتج التقارير من فرق عبر الشركة بدلاً من فريق واحد يمتلك جزءًا معينًا من النظام.

تذكر أن المبادئ ليست قواعد ، إنها إرشادات

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

"المحافظة الفنية تعني تفضيل تقنية موجودة بالفعل في مجموعتك - ولكن فقط إذا كانت الخيار الأفضل"

يعني التحفظ التقني تفضيل تقنية موجودة بالفعل في مجموعتك - ولكن فقط إذا كانت الخيار الأفضل. في بعض الحالات ، قد لا تكون التكنولوجيا الحالية مناسبة. إذا لم تستطع الإجابة عن الأسئلة التالية ، فقد نبحث عن المزيد ونقيم البدائل:

• هل تسمح الأداة الجديدة لنشاطك التجاري بالتوسع بشكل أكثر فاعلية؟
• هل يسمح لفريقك أو مؤسستك بالتحرك بشكل أسرع وتقديم القيمة بشكل أسرع؟
• هل يحل مشكلة العميل التي لا يمكن حلها باستخدام أدواتك الحالية؟

إذا أجبت بـ "نعم" على أي من هؤلاء ، فقد يكون من المفيد التفكير في تقديم تلك الأداة الجديدة. في Intercom ، كان هناك مثال حديث أجاب بـ "نعم" على جميع الأسئلة الثلاثة.

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

كنا نتوسع بشكل أسرع مما يسمح به مخزن البيانات لدينا

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

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

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

كانت تقنيتنا تبطئ فريقنا

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

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

"عدم التشدد في الرأي بشأن التحفظ التقني مكننا من استبدال التكنولوجيا بنفقات عامة كبيرة وقدرات محدودة"

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

كنا قساة بشأن المتطلبات

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

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

"عند التفكير في استبدال تقنية ما ، لا تعتبر أنك ستستخدم التكنولوجيا الجديدة بنفس الطريقة أمرًا مسلمًا به"

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

اجعل مبادئك تعمل لصالح عملك ، وليس العكس

يعد التحفظ التقني أداة رائعة للسماح لفرقك بالتركيز على ما هو مهم - حل مشكلات العملاء وتقديم قيمة دون إنفاق موارد ثمينة على الإجابة على الأسئلة التي تم الإجابة عليها بالفعل.

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

هل أنت مهتم بالانضمام إلى فريق هندسة Intercom؟ اكتشف المزيد وشاهد أدوارنا المفتوحة هنا.