استخدام Slack لمراقبة تطبيقك

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

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

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

مزيد من القراءة على SmashingMag:

• واجهات المحادثة: أين نحن اليوم؟ حيث نتجه؟
• تعاون الفريق وسد فجوات الكفاءة في التصميم سريع الاستجابة
• ما يجب أن تعرفه عن عملية تصميم التطبيق
• الانطلاق إلى السباقات: البدء في سباقات التصميم
  

قم بإعداد Slack

أولاً ، كان علينا الحصول على "عنوان URL للويب هوك" من Slack من أجل إرسال رسائل برمجيًا إلى قناة Slack الخاصة بنا.

الآن بعد أن أصبح لدينا عنوان URL للويب هوك ، فقد حان الوقت لدمج رسائل Slack في تطبيق Node.js الخاص بنا. للقيام بذلك ، وجدت وحدة Node.js سهلة الاستخدام تسمى node-slack.

أولاً ، قمنا بتثبيت الوحدة النمطية Node.js:

 npm install node-slack --save

الآن ، يمكننا إرسال رسائل Slack إلى القناة المفضلة لدينا ببضعة أسطر من التعليمات البرمجية.

 // dependency setup var Slack = require('node-slack'); var hook_url = 'hook_url_goes_here'; var slack = new Slack(hook_url); // send a test Slack message slack.send({ text: ':rocket: Nice job, I\'m all set up!', channel: '#test', username: 'MyApp Bot' });

(يمكنك العثور على حزم تكامل Slack مماثلة لـ Ruby و Python وأي لغة أخرى تقريبًا.)

عند تنفيذه ، أنتج هذا الرمز الرسالة التالية في قناة #test Slack الخاصة بنا:

الكود أعلاه ضئيل ، لكنه خاص بـ Slack API ووحدة node-slack. لم أرغب في أن أقفل في أي خدمة مراسلة معينة ، لذلك قمت بإنشاء وظيفة الوحدة النمطية العامة Node.js لتنفيذ التعليمات البرمجية الخاصة بالخدمة:

 // Messenger.js // dependency setup var hook_url = my_hook_url; var Slack = require('node-slack'); var slack = new Slack(hook_url); module.exports = { sendMessage: function(message, channel, username) { if (!message){ console.log('Error: No message sent. You must define a message.') } else { // set defaults if username or channel is not passed in var channel = (typeof channel !== 'undefined') ? channel : "#general"; var username = (typeof username !== 'undefined') ? username : "MyApp"; // send the Slack message slack.send({ text: message, channel: channel, username: username }); return; } } };

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

 var messenger = require('./utilities/messenger'); messenger.sendMessage(':rocket: Nice job, I\'m all set up!', '#test');

الآن بعد أن تم إعداد الأساسيات ، أصبحنا مستعدين لبدء إرسال الرسائل من داخل التطبيق.

مسار التسجيلات

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

 messenger.sendMessage('New user registration! ' + user.email);

الآن ، عندما يقوم شخص ما بالتسجيل ، نتلقى هذه الرسالة:

حتى أنها الضربات! كانت هذه بداية جيدة ، وقد أعطتني هذا الشعور المُرضي بالخدمة ، لكنها جعلتني عطشانًا للمزيد.

الغوص بشكل أعمق

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

مراقبة الاستثناءات والأخطاء الفادحة في الواجهة الخلفية

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

 messenger.sendMessage(':x: Error While adding a new user ' + formData.email + ' to the DB. Registration aborted!' + error.code + ' ' + error.message);

لقد عرفنا الآن على الفور عندما فشلت عمليات التسجيل ، ولماذا فشلت ، والأهم من ذلك ، من فشلوا في:

كانت هناك جميع أنواع الأماكن المثيرة للاهتمام حيث يمكننا إرسال الرسائل (إلى حد كبير في أي مكان به رد اتصال خطأ). إحدى هذه الأماكن كانت وظيفة الخطأ الشاملة هذه:

 app.use(function(err, req, res, next) { var message = ':x: Generic Server Error! '+ err + '\n Request: \n' + req.protocol + '://' + req.get('host') + req.originalUrl + '\n' + JSON.stringify(req.headers) + 'Request Payload:\n' + JSON.stringify(req.body); messenger.sendMessage(message, '#server-errors'); res.status(err.status || 500); res.json({'error': true }); });

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

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

مراقبة المالية

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

مراقبة سلوك المستخدم على الواجهة الأمامية

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

مع وجود نقطة النهاية في مكانها ، يمكننا الآن إطلاق رسائل Slack باستدعاء $http.post بسيط:

 // send Slack notification from the front end var message = ":warning: Slack disconnected by " + $scope.user.username; $http.post('/endpoint', message);

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

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

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

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

مراقبة المهام المجدولة

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

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

قم بتطبيق هذا المفهوم على تطبيقك

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

لا تعامل جميع الإخطارات على قدم المساواة

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

لحسن الحظ ، لدى Slack حل رائع لهذه المشكلة: القنوات .

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

عند وضع هذه الفكرة موضع التنفيذ ، إليك كيفية قيام مؤسسة أكبر بتنظيم الإشعارات المستندة إلى المراقبة في Slack عبر القنوات:

# أخطاء الخادم الحرجة

• ماذا: أخطاء التسجيل ، أخطاء تسجيل الدخول ، أخطاء قراءة وكتابة قاعدة البيانات
• من: مسؤولو النظام ، DevOps ، CTO ، الرئيس التنفيذي ، المطورون
• إعدادات التنبيه: قم دائمًا بالإعلام على الهاتف أو سطح المكتب.

# أخطاء الخادم غير الحرجة

• ماذا: أخطاء 404 ، أخطاء الخادم الشاملة ، إلخ.
• من: DevOps والمطورون
• إعدادات التنبيه: اجعلها جريئة ولكن لا تقرع.

# المالية

• ماذا: معاملات الدفع ، المعاملات الفاشلة ، الترقيات ، تخفيض التصنيف ، البطاقات منتهية الصلاحية
• من: المدير المالي ، الرئيس التنفيذي
• إعدادات التنبيه: اجعلها تمطر.

# سلوك المستخدم

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

# تطبيق- احصائيات

• ماذا: نتائج المهام المجدولة والتدبير المنزلي وإحصاءات البريد الإلكتروني للمعاملات وعدد المستخدمين ومقاييس النمو
• من: المسوقون عبر البريد الإلكتروني ، ومسؤولو النظام ، وأي شخص مهتم
• إعدادات التنبيه: اجعلها جريئة ولكن لا تقرع.

خاتمة

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

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

في الختام ، إليك ملخص لفوائد استخدام الدردشة الجماعية لمراقبة تطبيقك:

اكتساب منظور جديد حول سلوك المستخدم والخادم

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

تفاعل بسرعة عندما تفشل الأشياء

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

تقديم خدمة عملاء استثنائية

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

اتصال الفريق بالتطبيق سيجعلك أكثر كفاءة

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

يمكن أن تتسع الإخطارات والقنوات مع تطبيقك

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

البحث قوي

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

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