قيل الكثير عن مزايا العمل في شركة بقالة ، ومن الصعب أن تكون أصليًا هنا. ولكن بعيدًا عن كل شخص يعرف كيف يحافظ على "صحة" المنتج وما يمكن القيام به في شركة أغذية ، إلى جانب تطوير الوظائف. سنخبرك بكيفية تشغيل المنتج في Juno ، وكيف يشارك قسم العمليات والمتخصصون الفنيون في ذلك.
نحن لا نعلن أن طريقنا هو الصحيح ، فنحن نحاول باستمرار ونرتكب الأخطاء ونحاول أن نتعلم من أخطائنا. نأمل أن تكون تجربتنا مفيدة لك.
عنا: Juno هي خدمة للاختباء بالركوب تعمل في السوق الأمريكية وجزء من مجموعة شركات Gett.
يكتب Juno الشفرة بلغات Go و Swift و Kotlin و Python و React.js كجزء من فرق التطبيقات المتنقلة ، Backend ، Frontend ، Data Science ، Technical Operation Support ، مما يخلق خدمة أصبحت جزءًا من الحياة اليومية لعشرات الآلاف من السائقين ومئات الآلاف من المقيمين الجدد يورك.
ما هي إدارة المنتج كل شيء
دعونا نفهم عملية العمل في Juno ونحاول تحليلها إلى الأجزاء المكونة لها.
لقد حددنا ثلاثة مكونات رئيسية لأنفسنا:
- مكتب العمليات
- المقاييس والرصد
- التحقيق في الحوادث
الغرض من تشغيل المنتج هو الاستجابة في الوقت المناسب للمشكلات والتغيرات الناشئة ، بغض النظر عن طبيعتها.
للقيام بذلك ، تحتاج إلى:
- تحديد مؤشرات صحة النظام
- افهم كيف تؤثر التغييرات داخل النظام على المقاييس
- فهم كيف تؤثر تغييرات السوق على الأداء
- افهم متى ينمو التغيير إلى مشكلة
مع هذا النهج ، تستند قرارات العمل على البيانات. يعمل فريق التشغيل لدينا في نيويورك ، حيث لا تتوفر خدمة Juno حاليًا إلا للمقيمين في هذه المدينة.
تبدو قائمة المهام اليومية للفريق كما يلي:
- تتبع التغييرات التنظيمية واستجب لها بسرعة. تشمل التغييرات الشائعة ظهور طريق رسوم مرور جديدة ونقل منطقة انتظار للسائقين في المطار. بمجرد أن نتلقى معلومات حول مثل هذه الأحداث ، يغادر الموظف المكان لتحديث الخريطة بشكل صحيح وتحليل قائمة المشاكل المحتملة. عندما يقوم فريق التطوير بتحديث الخريطة على الخوادم ، يقوم الموظف باختبار التغييرات في "الظروف الميدانية" والتأكد من أنها تعمل بشكل صحيح.
- إجراء البحوث "الميدانية". عندما أطلقنا الخدمة في نيويورك ، كانت الخطة تتمثل في تعيين عدد معين من السائقين للتشغيل المستقر للخدمة في أي منطقة من المدينة. لهذا السبب ، لمدة شهرين ، سافر السائقون الذين انضموا إلينا أولاً بدون ركاب ولم يتلقوا سوى رحلات من مختبري بيتا من حين لآخر. لم تكن هذه الرحلات كافية لجمع المعلومات اللازمة. ثم قررنا إرسال فريق التشغيل إلى "الحقول" لتقييم جودة الخدمة ومعرفة شكاوى السائقين حول التطبيق. تبين أن هذا النهج مفيد ونحن نستخدمه باستمرار عند إصدار تغييرات كبيرة أو لاختبار الفرضيات.
- أخبار "أجندة الأحداث" - قائمة الأحداث والعطلات وأحداث الطقس التي يمكن أن تؤثر على كمية ونوعية الرحلات. هذا يساعد على فهم وتوقع التغييرات في المؤشرات الرئيسية (على سبيل المثال ، عدد الرحلات أو عدد السائقين عبر الإنترنت) التي لا تكون واضحة لفريق التطوير من مينسك. يمكن أن تكون بعض الأحداث googled (الظروف الجوية ، ونهائيات SuperBowl ، وسباق الماراثون ، وسباق الدراجات ، وما إلى ذلك) ، ولكن هناك بعض الأحداث الأكثر صعوبة. على سبيل المثال ، في السنة الأولى من العمل ، كان مفاجأة لنا أن رمضان يؤثر بشكل كبير على عدد السائقين الراغبين في قبول الطلب. الحقيقة هي أنه في الولايات المتحدة الأمريكية ، يعمل العديد من المسلمين كسائقين ، ولا يذهبون للعمل في عطلة. من الصعب أن تأخذ في الاعتبار مثل هذه الحقيقة أثناء وجوده في مينسك.
- تتبع التغيير في مقاييس الأعمال. في الشهر الثالث بعد إطلاق Juno والنمو السريع في عدد الرحلات ، وجدنا أنه لم يكن هناك ما يكفي من السائقين عبر الإنترنت ، مما أثر على وقت تسليم السيارة ورغبة الركاب في السفر معنا. اتضح أن أحد المنافسين أطلق حملة تضمن للسائقين زيادة مدفوعات الرحلات في ساعات الذروة الصباحية والمسائية. تم نقل المعلومات بسرعة إلى مينسك ، وفي وقت قصير أتيحت لنا الفرصة أيضًا لتقديم مثل هذه الشروط. ساعدتنا هذه الخطوة على استعادة السائقين ومواصلة النمو.
المقاييس والرصد
في Juno ، تحتوي جميع الفرق على مقاييس ، اتفقنا على تقسيمها إلى:
- مقاييس الأعمال.
- المقاييس الفنية.
مقاييس الأعمال عبارة عن سلسلة من المؤشرات التي تقيس "صحة" المنتج. نحن نقسمها بشكل مشروط إلى قسمين:
- عبر الإنترنت من الواضح أن عدد السائقين والركاب عبر الإنترنت ، وعدد الرحلات حسب الحالة. أقل وضوحًا هو عدد المستخدمين الجدد ، والتحويل من الشاشة بالسعر الأولي للرحلة إلى حجز رحلة ، ومتوسط وقت الانتظار لسيارة في منطقة معينة ، وسرعة الطابور في المطار ، وما إلى ذلك.
- بلا إنترنت لا يمكن الحصول على جميع المعلومات ومعالجتها بسرعة في الوقت الفعلي ، وهي ليست ضرورية دائمًا. عندما نخطط للترقيات للسائقين أو الميزات الجديدة ، نحن مهتمون بالاتجاهات طويلة المدى أو ردود فعل المستخدم لتجربة A / B ، سواء كانت تصميمًا جديدًا أو وظيفة جديدة أو خصمًا إضافيًا.
لإنشاء تقارير تحليلية بناءً على المقاييس التي تم جمعها ، نستخدم Tableau. بالنسبة لهذه التقارير ، نحن مسؤولون عن فريق ذكاء الأعمال (BI). إنهم يعملون في مكتب تل أبيب بجوار فريق البقالة. يعمل كلا الفريقين عن كثب مع الزملاء في نيويورك ، مما يسمح للمحللين القائم على BI بتقييم نجاح الإجراءات المتخذة ، وصياغة فرضيات للتحقق في "المجالات" وتعديل خطة تطوير المنتج.
من ناحية أخرى ، هناك عدد من المقاييس التقنية التي تؤثر بطريقة أو بأخرى على النظام ككل.
المقاييس التقنية هي سلسلة من المؤشرات التي تشير إلى التشغيل الخالي من الأخطاء للمكونات الفردية ، والتي يتم على أساسها استنتاج حول تشغيل النظام ككل. فهي تُظهر مقدار الوقت الذي تستغرقه المكالمات بين الخدمات ، ومقدار الذاكرة التي تستهلكها ، وما إذا كانت هناك أي أخطاء فادحة عند نقل الرسائل بينها. هناك العديد من هذه المقاييس في جونو. إنها زائدة إلى حد ما ، ولكن في المواقف الحرجة يساعد على العثور بسرعة على سبب المشكلة. يساعدنا تتبع المقاييس التقنية واستخدامها في:
- لوحة القيادة - تعرض علامات حيوية مهمة للنظام. يقوم كل فريق تطوير بتجميع مجموعة المقاييس الخاصة به التي تساعدهم على فهم كيفية تأثير تغيير معين على الخدمات الصغيرة الموكلة إليهم. لذلك ، على سبيل المثال ، يراقب فريق واحد المقاييس المتعلقة بدفع المال للسائقين ومدفوعات الركاب ، وينظر الآخر إلى المقياس المسؤول عن وقت البحث عن السائق أو عدد الإحداثيات التي تم استلامها.
- سجلات نقوم بتسجيل الأحداث من الأجهزة المحمولة والخدمات الصغيرة الخلفية. في عام 2017 ، احتلوا 400-500 جيجا بايت في الأسبوع ، وبحلول عام 2018 تضاعف هذا الرقم. نحن مهتمون بالأحداث التالية: مكالمات الخدمات الصغرى إلى مصادر خارجية للمعلومات ، والخدمات الصغرى الأخرى ، والطلبات المستلمة والمرسلة للعملاء ، وجميع أنواع الأخطاء (التجارية والتقنية). تجدر الإشارة إلى أن المعلومات مجهولة المصدر: لا يتم تسجيل البيانات الشخصية ، مثل كلمات المرور والمعلومات المصرفية.
لمراقبة الأداء ، نستخدم Grafana و Prometheus. عند تطوير خدمة جديدة أو إضافة وظيفة جديدة ، يضيف المطورون المقاييس اللازمة للخدمة ، ثم يقوم كل فريق بإعداد تنبيهات لنفسه.
بفضل التنبيهات المخصصة ، يقوم فريق الدعم الفني بإجراء تحليل أولي وتصعيد المشكلة إلى التطوير أو إلى فرق العمل لمزيد من الحل.
إذا كانت المشكلة ذات طبيعة فنية وتهدد التشغيل العادي للخدمة ، يقوم فريق الدعم الفني بإنشاء حادث إنتاج. بفضل العملية التلقائية ، يتم إخطار أصحاب المصلحة على الفور ، بما في ذلك فريق دعم العملاء (خدمة العملاء المعروفة أيضًا باسم Helpdesk aka L1 support) ، الذي يستعد لتدفق محتمل للمكالمات.
التحقيق في الحوادث
مع مرور الوقت ، توصلنا إلى استنتاج مفاده أنه بعد كل حادث خطير ، يحدث نوع من "استخلاص المعلومات". نحن نجري تغييرات على العمليات التي تساعدنا على تجنب أو التعامل بشكل أفضل مع الأحداث المماثلة في المستقبل.
تساعد العناصر المذكورة أعلاه: المقاييس ولوحات المعلومات والتنبيه والسجلات على فهم ما حدث. تجتمع الفرق معًا ، وتحلل التغييرات في المؤشرات الفنية ومؤشرات العمل ، وتأخذ الأخطاء في الاعتبار وتستخلص الدروس لأنفسهم.
علينا أن نتعامل مع حوادث الإنتاج ، وكذلك مع أي حالة أخرى حيث يستحيل الإجابة بسرعة على "ما حدث". وهنا يساعد فريق الدعم الفني (دعم TechSupport المعروف باسم L2).
ما هي المشاكل التي يتم حلها في الدعم الفني؟ ويعتقد أن هذا عمل ممل ، كما هو الحال في سلسلة IT Crowd ، حيث يقوم ثلاثة من المهووسين في الطابق السفلي بما يقولون: "حاول إيقاف تشغيل الكمبيوتر وتشغيله". في الواقع ، تثور أسئلة معقدة ومثيرة للجدل.
يتم تنظيم المستوى الأول من الدعم (خدمة العملاء) على أساس مبدأ "اتبع الشمس" (اتبع الشمس). مع هذا النهج ، يمكن دعم المستخدم على مدار الساعة بدون نوبات ليلية. في العصور الأوروبية ، يوجد مكتب في تل أبيب ، وفي الساعات الأمريكية - في بورتلاند. تتمثل مهمة هذا الفريق في الاستماع وفهم "ألم" السائق أو الراكب ، والتهدئة ، والمساعدة إذا أمكن. الأشخاص الذين يعملون هناك مسؤولون عن الأسئلة المتعلقة بتشغيل الخدمة. في الوقت نفسه ، الفريق ليس "تقنيًا" ، وبمجرد أن تأتي اللحظة التي يكون فيها من الضروري التعمق أكثر في الفروق الدقيقة الفنية ، يتم إعادة توجيه الطلب إلى فريق الدعم الفني. يعمل هذا الفريق في مينسك وهو جزء من مركز التطوير. يحل الرجال المشاكل التقنية حصريًا ولا يتواصلون مع السائقين والركاب مباشرة. مهمة الفريق: التحقيق في الحوادث وأتمتة العمليات.
في حالة وقوع حادث إنتاج ، تكون مهمة فريق الدعم الفني على النحو التالي: تم العثور على خطأ أو حدث فشل أثناء النشر ، ولاحظنا مشكلة ، وقمنا بإصلاحها ، ولكننا ما زلنا بحاجة إلى معرفة كيفية تأثيرها على النظام وما يجب استعادته من وجهة نظر إدارة المنتج:
- هل البيانات تالفة أم أنها تنتهك سلامتها؟
- كيف أثر هذا الحادث على المستخدمين؟
- هل يتأثر جميع المستخدمين؟
- ما يمكن إصلاحه؟
الأسئلة بسيطة ، ولكن للإجابة عنها ، عليك أن تفهم جيدًا كيف يعمل النظام وكيف تغير سلوكه أثناء الحادث. عند الإجابة على السؤال ، يجدر النظر في عملية النشر الجارية ، مثل احتمال تغير شيء ما في كل دقيقة.
كمثال ، عندما كانت هناك حاجة إلى الدعم الفني للمنتج ليعمل بشكل صحيح ، ضع في اعتبارك الحالة "لم أقم برحلة". أخذ السائق راكبًا آخر وقام برحلة لا يرغب راكبنا في دفع ثمنها. في هذه الحالة ، من الضروري التمييز بين طلب مشروع ومحاولة الاحتيال عندما يحاول المستخدم عدم دفع مقابل الخدمات المقدمة.
إذا وصل الطلب بشكل متكرر ، فسيتم تشغيله تلقائيًا بواسطة فريق الدعم الفني ويتم تقديمه إلى فريق دعم المستخدم في شكل تطبيق ويب. يتيح لك هذا النهج تقليل الوقت الذي تستغرقه معالجة طلب المستخدم وليس "تضخيم" فريق الدعم الفني. ومع ذلك ، شاغر مهندس الدعم الفني مفتوح دائمًا لنا ، حيث ينمو الرجال وينتقلون إلى فرق تطوير أخرى.
جميع الطرق تؤدي إلى روما
وصف تفصيلي لعمل فريق الدعم الفني في إطار هذه المقالة ليس من قبيل الصدفة. حدث أن أصبحت مكانًا تتدفق فيه المعلومات من جميع المصادر. تقلل نقطة اتصال واحدة من عدد المترجمين ، وبالتالي تقلل من عدد التشوهات.
هذا لا يعني أن فريق الدعم الفني هو الرابط الرئيسي في إدارة منتج العملية ، لأن شركة المنتج هي كائن حي: جميع الأعضاء مهمة وضرورية. من المستحيل اختيار ما هو أكثر أهمية بالنسبة للشخص - الدماغ أو القلب أو الرئتين أو الدورة الدموية. فقط التطوير والتفاعل المتناغم لجميع الأجهزة يضمن الأداء الصحي للجسم أو شركة تكنولوجيا المعلومات.
الصحة لك ومنتجاتك!