البحث في الموقع

لقد توقف العالم بأسره في يوم 24 كانون الثاني/يناير 2014، ربما تتذكر ذلك اليوم المشؤوم في حال كنت واحدًا من بين ال 42 مليون شخصًا الذين تضرروا يومها. إنه اليوم الذي انهارت فيه خدمات غوغل بشكل مفاجئ Google crashed. حيث توقفت خدمات جيميل Gmail، غوغل درايف Google Drive، تقويم غوغل Google Calendar، بالإضافة إلى غوغل بلس +Google حوالي الساعة 11 مساءً بتوقيت المحيط الهادئ. لقد اضطرب العالم وحدثت موجة عارمة من التغريدات على تويتر التي تتحدث عن نهاية الزمان لمدة نصف ساعة أو على الأقل حتى تم إصلاح الخلل وعاد عملاق الويب للوقوف على قدميه من جديد. إن إمكانية حدوث انقطاعات خطيرة مثل هذه هي حقيقة مؤسفة بالنسبة للأعمال التجارية على الإنترنت. هناك العديد من الأجزاء التي توثر على بقاء موقعك الإلكتروني متوفرًا للزوار والتي بدورها قد تتوقف عن العمل أحيانًا. وكما هو الحال بالنسبة للكثير من الأشياء، فإن الأمر الأكثر أهمية من حدوث الخلل هي الآلية التي تتبعها لتصحيحه. وفي حال حدوث انقطاع خطير لمدة كافية في موقعك الإلكتروني فإن كتابة منشور بعد تصحيح الخلل هو من أفضل الطرق لإعادة الأمور إلى نصابها. ما هي تحديثات الانقطاع Outage Updates ولماذا يجب استخدامها؟ عادةً ما تدعى تحديثات الانقطاع postmortems وهي تقارير تقنية دقيقة وشاملة متاحة للجميع تتكلم عن حدث التوقف. وغالبًا ما تُنشر في صفحة الحالة status page. توفر تحديثات الانقطاع جدول زمني لبدء حدوث المشاكل في الموقع، بالإضافة إلى ما تم القيام به لإصلاح كل مشكلة. وإليك مجموعة من الأسباب التي توضح لماذا عليك أن توليها اهتمامك: تؤمّن فهمًا أفضل لفريق التطوير والتشغيل DevOps: إن إجراء تحديث انقطاع شامل يعطي فريق التطوير والتشغيل لديك معلومات أكثر عن أداء البنية التحتية لموقعك في ظروف معينة. من النادر أن يكون السبب الذي يجعل موقعك يتوقف عن العمل سببًا سطحيًا، إنه غالبًا ما يكون مزيجًا من عدة مشاكل متنوعة تؤدي إلى توقف الموقع. لذلك إن إجراء تحقيق شامل يعطيك المعرفة اللازمة للتعامل مع المشاكل المشابهة التي قد تحدث في المستقبل ومنع حدوثها في نهاية المطاف. إعادة بناء ثقة العملاء: عندما يتوقف موقعك أو تطبيقك لفترة طويلة من الوقت، سيفقد عملاءك قدرًا من ثقتهم بامتلاك فريقك للمهارات التقنية اللازمة للحفاظ على كل شيء متاحًا ويعمل بشكل صحيح. وإذا اعتقد العملاء في مرحلة ما بأنك ستستمر في المعاناة من مشاكل التوقف فإنهم سيفكرون في الانتقال إلى أحد منافسيك. إن كتابة تحديث انقطاع جيد سيساعدك على إحياء ثقة العملاء التي فقدتها بسبب حدوث الانقطاع. الكتابة بشكل عام ليست أمرًا سهلًا، ولا يختلف الأمر بالنسبة لكتابة تحديثات الانقطاع، لكن هناك بعض الإرشادات التي يمكنك اتباعها لتكون تحديثات الانقطاع واضحة، متماسكة، ومفيدة. كتابة تحديث انقطاع ممتاز يقوم تحديث الانقطاع الجيد بثلاثة أشياء: الاعتذار عن التوقف الذي حصل، وإظهار معرفتك بما حدث بالضبط ولماذا حدث، بالإضافة إلى تقديم خطة تضمن ألا تتكرر نفس المشكلة مرة أخرى. الاعتذار من المحتمل أن يكون توقف موقعك قد أحبط عملاءك وبالتأكيد هم محقون في ذلك. لذلك اعتذر مباشرةً وأنت تعني ما تقول، فلا تقل مثلاً: "نحن نعتذر عن أي ضرر قد يكون حصل" ﻷنك هكذا تلقي باللوم على العملاء، كما أن الكلام المنافق يُكتشف على الفور. هنالك أشخاص يرغبون في الاستمرار بدعم شركتك، وهم يستحقون منك أن تكلمهم بلغة صادقة، موثوقة، وشخصية. إظهار فهمك للمشكلة الشيء التالي الذي يجب أن يقوم به تحديث الانقطاع هو إثبات معرفتك الكاملة لما حدث بالضبط ولماذا حدث. لأن التفسير المرتبك يضر سمعتك بطريقتين: يجعلك تظهر بمظهر غير الكفؤ، ويترك انطباعًا لدى عملائك بأنك شخص غير مبالي. لذلك عليك إيجاد طريقة لإيصال ما تود قوله بوضوح. تتوقف كمية التفاصيل التي يجب الحديث عنها في تحديثات الانقطاع على نوعية جمهورك. إذا كنت شركة تجارة إلكترونية فعليك الحذر بشكل خاص من عدم إغراق عملائك بالمصطلحات التقنية المربكة. أما إذا كان عملائك مطورون -بطريقة ما- فإنهم سيقدرون سماع أهم التفاصيل العملية لما حدث: تفاصيل مثل الرسوم البيانية، جدول زمني للأحداث، والخطوات المحددة التي اتخذتها لمعالجة المشكلة. ملاحظة جانبية: إذا كان سبب التوقف ناتج عن مزود خدمة الإنترنت الرئيسي upstream provider الذي تعتمد بنية موقعك التحتية عليه، فهذه ليست فرصة لإدانتهم وإعفاء نفسك من المسؤولية، لأنك اخترت استخدام خدمتهم وبناء تطبيقك بمثل هذه الطريقة التي أدت إلى حدوث نقطة الفشل هذه. إن اعترافك بأخطائك لا يتضمن أبدًا إلقاء اللوم على الآخرين. خطة لتجنب المشاكل المستقبلية يريد عملاءك معرفة ماذا ستفعل لضمان عدم تكرار هذه المشكلة مجددًا. هذه فرصة لتفصيل الإصلاحات، التعديلات، أو التحديثات التي تنوي القيام بها مع وضع جدول زمني لتنفيذها. وهناك فائدة ثانية لكتابة ذلك وهي أنك في هذه الحالة تكون عرضة للمساءلة عن التنفيذ الفعلي للإصلاحات التي وعدت بها. متى يتطلب الأمر كتابة تحديث انقطاع؟ هناك سؤال أسمعه كثيرًا: "ما هي الحوادث التي تتطلب تقديم تحديث انقطاع للعملاء؟". والجواب هو أن ذلك يعتمد على الظرف و نوع الخدمة. الخدمات الحرجة معرفة متى ولماذا تنشر تحديث انقطاع يعتمد على الخدمة التي تقدمها وعدد الأشخاص الذين يعتمدون عليك. يتوقع من خدمات مثل غوغل وAmazon Web Services أن تعمل بنسبة 100% من الوقت. إذا حدث انقطاع لدى AWS، فمن الممكن أن يصبح أولئك الذين يستعملون الخدمة غير متوفّرين نهائيًا لعملائهم. وفي هذه الحالة فإن أي مشكلة طفيفة أو انقطاع لمدة دقيتين يتطلب نشر تحديث انقطاع. نعود إلى مثال غوغل السابق، لقد انقطعت خدماتهم لمدة 30 دقيقة، مما دفع Ben Treynor نائب رئيس مهندسي غوغل إلى كتابة تحديث انقطاع رائع للأشخاص الذين تأثروا بما حدث. لقي الاعتذار استحسان الناس وكانوا ممتنين عمومًا لهذا التقرير المفصل. خدمات مهمة ولكنها ليست حرجة نحن نستعمل خدمة Wistia لاستضافة فيديوهاتنا التسويقية والمعرفية. ومن المهم توفرّ هذه الفيديوهات لمساعدة عملائنا، لكن تأثير انقطاع خدمة Wistia لا يشابه الوضع الخانق الذي ستكون به عند انقطاع خدمات AWS. إن خدمات مثل Wistia يجب أن تنشر تحديثات انقطاع بعد حدوث توقف لمدة 30 دقيقة أو أكثر. في كانون الأول/ديسمبر 2014 شهدت خدمة إدارة النطاقات DNSimple انقطاعًا طويلًا ناجمًا عن هجوم DDoS ضخم. حيث أصبح موقعهم-ومن ثم مواقع عملائهم- غير متوفرة لعدة ساعات متواصلة. لقد كانت هذه قضية كبيرة كما أن العديد من عملائهم كانوا غير قادرين كليًا على العمل في ذلك اليوم. لقد ترقب أولئك العملاء تقرير انقطاع من DNSimple يشرح بالتفصيل ماذا حدث بالضبط، ولماذا حدث، وماذا فعلوا حيال ذلك، وبالفعل نشرت DNSimple تحديث انقطاع. لقد قرأت أطنان من تحديثات الانقطاع بحكم عملي في خدمة statuspage.io ، ودائمًا ما أشير إلى هذا التحديث كمثال يحتذى به. الاعتذار. الخطوة الأولى لإصلاح الوضع هي الاعتذار، عليك أن تتحمل مسؤولية المشكلة. ولقد قام المدير التنفيذي Anthony Eden بعمل رائع بما يتعلق بهذه النقطة، فهو لم يلقي اللوم على أحد وتحمل المسؤولية منذ بداية المنشور-لم يتصرف هكذا لأنه درامي زيادة عن اللزوم، ولكن لأنه يقرّ بحاجة العديد من العملاء الذين خذلهم توقف DNSimple إلى الاعتراف بالخطأ. ماذا حدث ولماذا؟ إن DNSimple منتج تقني، والمنتجات التقنية لديها عملاء تقنيون، والعملاء التقنيون يتوقعون نشر تحديث انقطاع تقني. هنالك دائمًا خطر في تضمين تفاصيل زائدة في تحديثات الانقطاع، لكن معظم الناس لا يقلّلون من شأن ما يجب توضيحه. لقد قدّم تحديث الانقطاع هذا توضيحًا رائعًا حول ما حدث ولماذا. حيث تحدثوا عن حجم هجوم DDoS وكيف ولماذا لم تتمكن الأجهزة المتوفرة بين أيديهم من التعامل مع حركة مرور البيانات المتدفقة. نحن نعمل بجهد لتجنب حصول حوادث أخرى. لا يمكنك أبدًا (ولا يجب أن تقوم بذلك نهائيًا) ضمان عدم حدوث الانقطاع مرة أخرى. ما يمكنك القيام به على أية حال هو الحديث عن الخطوات التي اتخذتها لتجنب حدوث مشاكل مشابهة مرة أخرى. ولقد تحدث Anthony في هذه النقطة عن خدمات الطرف الثالث التي سيستخدمونها، كما تحدث بالتفصيل عن بعض ميزات يخططون لإضافتها والتي ستوفر طريقة للتغلب على المشاكل بالنسبة لعملائهم الذين سيتأثرون في حال حدوث أي هجوم DDoS مستقبلي. القيام بالعمل الصحيح حدوث الانقطاعات حقيقة محزنة بالنسبة للمشاريع التجارية على الإنترنت. وحتى أكثرنا خبرة قاسى من هذا الأمر، كما أنها قد تضر بسمعتنا. إن كتابة تحديث انقطاع جيد يساعد في تخفيف الآثار السلبية التي تترافق مع الانقطاعات الطويلة. إن عملائك يدعمونك، فلا تخذلهم. ترجمة وبتصرف للمقال How to Recover After Your Website Crashes لصاحبه Steve Klein.

إنّ أفضل شيء يفعله مدير مُنتج ما هو أن يقرّر أين تنتهي حدود مُنتجه، وأين تبدأ مهمّة مُنتج آخر. لا يستحق التطبيق كلفة الإنشاء أو التّسجيل، ناهيك عن سعر الشراء الحقيقي إذا كان الأثر الذي يُحدثه صغيرًا. وبالمثل إذا كان الأثر الذي يحدثه كبيرًا جدًّا فسيصطدم مع البرامج الموجودة مسبقًا أو تدفّق العمل workflow الذي اعتاد عليه المستخدمون بالفعل. إنّها معضلة المُنتج المعتدل، يجب عليك أن تجد المُنتج المناسب فحسب. مثال: تطبيق تعقب الوقت Time trackingيعتبر تعقّب الوقت، كحد أدنى مطلق (أي في صورته القاعدية)، مجرّد جمع قائمة من الأرقام، وإذا كان هذا هو أقصى ما يقدّمه التّطبيق فسيكون عديم الفائدة. حيث أنّ مستندات جوجل أو اكسل تقوم بهذه المهمة بالفعل. وسندرك عند هذه النّقطة أنّ البساطة مبالغ فيها، وأنّه ليس هنالك ما يمكن إضافته لتحسين التّطبيق، لا مجموعة من الخطوط، ولا خصائص HTML5 ولا المؤثّرات الصّوتيّة. وكحد أعلى، يمكن أن يشتمل تعقّب الوقت على إدارة المشاريع، الميزانيّات، المتعاقدين، قوائم الحسابات، تعقّب وصولات الاستلام، ورصد الموظّفين. إنّ التّطبيقات التي تتضمن العديد من المهام تتجاوز حدودها لتتخطاها إلى أراضي مُنتجات أخرى يعتمد عليها المُستخدم بالفعل (كـ Xero، Ballpark، Basecamp، إلخ.) إنّ المُنتجات توجد لحل المشاكل التي تحدث في تدفّق العمل، وتمتلك نقطة بداية ونقطة نهاية في ذلك التدفّق. ولكي تعرف مواقع هذه النقاط يجب أن تفهم تدفّق العمل بالكامل. لنلقي نظرة على تدفّق العمل لفريق يقوم بطلب وجبات الغداء كل يوم. إذا كنت تقوم ببناء تطبيق يساعد الفريق على طلب وجبات الغداء كل يوم، يمكن أن يكون تدفّق العمل كالتالي: يجوع أحدهم.يقوم أحدهم بإخبار بقية أفراد الفريق.تتم المناقشة حول الخروج لتناول الطعام أم القيام بالطلب.تتم مناقشة أخرى حول المكان الذي يُطلب منه.يتم تمرير قائمة بأماكن مختلفة بين الجميع.يتم التّوصل إلى قرار ما بسرعة.يُعيّن شخص ما لجمع طلبات الجميع.يقوم ذلك الشخص بالطلب.يقوم ذلك الشخص بإخبار الجميع عن وقت التسليم وكلفة الطلب.الوقت يمضي.يصل الطعام، ويؤكل.يتحقق الشخص الذي قام بالطلب من الأشخاص الذي دفعوا والذين لم يدفعوا مقابل الوجبة.تتم التّسوية المالية، أو أنّها تؤجل إلى الغد.سيتحدّث بعضهم عن الوجبة في فيس بوك أو تويتر، وبعضهم يقوم بنشر الصور على إنستجرام، وآخرون يقيمونها على Yelp.يعود الجميع إلى العمل.بإمكانك عندما تفهم تدفّق العمل بالكامل أن تركّز على المجموعة الجزئية الأكثر إشكالًا التي يحلّها مُنتجك، أو بدلًا من ذلك، التركيز على الجزء الذي بإمكانك جعله أكثر متعة وإثارة للاهتمام. هنالك مقال للمطّور Don Dodge بعنوان "هل مُنتجك عبارة عن فيتامين أم مسكّن ألم" والذي يناقش فيه الفرق بين الخيارين. من أين يجب أن تبدأ؟إنّ الخطوة الأولى لمُنتجك يجب أن تتحدّد عندما تستطيع إضافة قيمة. بالنسبة للمثال أعلاه، ربّما تكون هذه هي الخطوة الرابعة. يمكن في البدايات المبكّرة أن تقوم ببناء مُنتجات للدردشة أو البريد الإلكتروني، ونادرًا ما تكون البداية فكرة جيّدة. من الأمثلة الواقعية على ذلك تطبيق TripIt. يقوم هذا التطبيق بتقديم الحلول لإدارة الرحلات. يمكن أن تكون خطوة البداية لهذا التطبيق هي البحث عن الرحلات، لكنّ TripIt لم يستطع إضافة قيمة في هذه الحالة. إنّ أوّل مرحلة يمكنهم إضافة قيمة عندها هي بعد أن يتم الحجز. قام TripIt بإضافة حل رائع وذلك بفهم تدفّق العمل بالكامل. إنّ آخر أمر يمكن أن يحدث قبل أن يستطيع TripIt إضافة قيمة هو أن "يفتح المستخدم رسالة تأكيد الحجز"؛ هذه هي المرحلة الأولى التي يستطيع فيها TripIt إضافة قيمة لكي يبدأ مع تلك الرسالة ويقوم بالاستيراد من هناك. وبالمثل، يبدأ إنستجرام عن طريق استيراد شبكات التواصل الاجتماعي الخاصة بك، أو يبدأ تطبيق تعقّب الوقت عن طريق استيراد المشاريع من Basecamp. إنّ واجهات التّطبيقات الجيّدة وميزات الاستيراد تساعد المستخدمين على الاستمتاع ببداية سهلة التّشغيل. أين يجب أن تتوقف؟ يجب أن تقوم ميزانيّتك، سواءً كانت ميزانية الوقت أو المال، بحد نطاق المُنتج من دون تحديده (أي من دون تحديد/تعريف نطاق المُنتج) . يجب أن تحدّد الميزانية الكبيرة كيفية حل المشكلة وليس عدد المشاكل التي تعالجها، حيث أنّه من شبه المستحيل أن تحاول معالجة تدفّق العمل بأكمله من البداية حتّى النهاية ولجميع فئات المستخدمين. يجب أن يتوّقف مُنتجك عندما: تسعى وراءه شركات رائدة ومعروفة في السوق (مثل PayPal، IMDB، Expedia) وأنت لست على استعداد للمنافسة.تنتهي المرحلة التالية من المنتج بالعديد من الطرق المختلفة باستخدامه من قبل العديد من الفئات المختلفة من المستخدمين. مثلًا، محاولة معالجة الرواتب في تطبيق تعقّب الوقت قد تكون صعبة أو معقّدة.تشتمل المرحلة التالية على مستخدمين نهائيين end users مختلفين عن المستخدمين في المراحل السابقة، مثلًا المدراء، المحاسبين، إلخ.يصل إلى مرحلة لا تستطيع فيها تقديم أي قيمة.حدد وألغ الخطوات عديمة المعنى إذا انتهى المستخدم من استخدام تطبيقك وكانت الخطوة التالية التي سيقوم بها هي تنزيل ملف لإرساله إلى عبر البريد الإلكتروني، فإن هذه خطوة عديمة المعنى. إذا كان المستخدم سيقوم بتصدير بياناته الماليّة كملف CSV ومن ثم يقوم بتحميله وتحويله إلى ملف XLS ثمّ إرساله عبر البريد الإلكتروني إلى المحاسب، فهذه الخطوة عديمة المعنى أيضًا. وإذا تم الانتهاء من مشروع، ثم يتم تنزيل جميع الملّفات، تحويلها إلى ملفات مضغوطة ثم إرسالها إلى العميل للأرشفة، فهذه خطوة عديمة المعنى أيضًا. غالبًا ما يكون البريد الإلكتروني مصدرًا للخطوات عديمة المعنى التي نادرًا ما تحمل معلومات كافية ("قام شخص ما بنشر تعليق")، أو أنّها لا تحيل إلى إجراءات بديهيّة (التأكيد، التأشير كـ "محلول"، إلخ). وبشكل عام، يجب أن تتكون لديك صورة واضحة عن الخطوة التي يجب إزالتها في الحالة التي يقوم في المستخدم بالنقر خلال سلسلة من الخطوات دون أخذ فكرة معيّنة أو اتخاذ قرار معيّن على طول المسار. الخطوات المستقبليةحاول دائمًا أن تكمل النواقص وتسد الثغرات في المُنتج قبل توسيعه. إنّ الانتقال من البرامج الجاهزة إلى برامج الاشتراك subscription هو بمثابة مكافأة للمُنتجات الموثوقة والكاملة، وليس المُنتجات مُفرطة الخصائص والمليئة بالأخطاء. إنّ توسيع المُنتج ليقوم بحل مشاكل أكبر يمكن أن يعود بفوائد كبيرة، لكن لا يمكن لذلك أن يحدث إلّا إذا كان الأساس راسخًا. فإذا كان مُنتجك الأساسي ليس شاملًا، ستؤدي إضافة ميزات إضافية إلى جعل الأمور أسوء. كثيرًا ما يُكتب هذه الأيام حول تحري البساطة، لكن هناك التباس في الأمر؛ حيث أنّ هنالك فرق أساسي بين تبسيط المُنتج وعمل مُنتج بسيط. إنّ تبسيط المُنتج يؤكّد على إزالة جميع التعقيدات غير الضّرورية لكي يستطيع كل المستخدمين حل مشاكلهم بأكبر كفاءة ممكنة. أمّا عمل مُنتج بسيط يعني التركيز على مجال معين واختيار أصغر المجموعات الجزئية من تدفّق العمل حيث يمكن للمُنتج أن يقدم قيمة. ولذلك ينطوي المُنتج الفعّال القاعدي MVP على خطر تصنيفه كحلّ جزئي أو نقطي point solution، أو حتّى أسوء من ذلك؛ اعتباره "خاصيّة وليس مُنتج". لذلك يجب أن تراعي "أين ترسم الخط" عندما تقوم ببناء مُنتج بسيط. ترجمة -وبتصرّف- للمقال Where to Draw the Line لصاحبه: Des Traynor. حقوق الصورة البارزة: Designed by Freepik.