عامل الوقت - توقيت تنفيذ الأوامر والعمل والاتفاقيات - مهم في الأعمال. يتوقع العملاء والشركاء تعاونًا مستغرقًا للوقت يمكن التنبؤ به. في الأعمال التقليدية ، يتأثر هذا بعمل الموظفين ، وتصرفات الموردين ، والموقع الجغرافي للشركة ، وحالة المعدات ، وأكثر من ذلك بكثير. تحديد موقع والتحكم في كل هذا مهمة صعبة.
أوضح إلى حد ما ، كل شيء في مجال تكنولوجيا المعلومات. يمكن أتمتة جزء كبير من العمليات وتوكيله إلى برنامج أو برنامج نصي. والأفضل من ذلك ، إذا تم تنفيذ المنتج كخدمة ويب - فإن الدرس الرئيسي هو دعم توفر المنتج وتطويره.
أحد المنتجات الرئيسية لشركتنا هو خدمة الويب. بدأ كل شيء بتنفيذ فكرة شخصين ، ثم نمت الشركة: PM (وهو أيضًا مبرمج ويب) ، مبرمج قاعدة بيانات ، مسؤول نظام (مع خبرة مطور قليلة) ، مختبِر ، واثنين آخرين من المشاركين في المبيعات وكبار المسئولين الاقتصاديين. يتم تنفيذ النظام كواجهة ويب وقاعدة بيانات ذات صلة. ينطوي استخدام الخدمة على إيداع وسحب الأموال المخزنة "بعملة افتراضية". للأمان ، يتم نشر خادم الويب وقاعدة البيانات على خوادمهما.
نظرًا لأن الخدمة مرتبطة بالمال ، فإن مستوى ثقة المستخدم في النظام مهم. بادئ ذي بدء ، إنها مسألة أمنية وحماية النظام من القرصنة. ومع ذلك ، يصعب على العميل العادي (خاصةً غير الضليع في تعقيدات تقنية المعلومات والبروتوكولات الآمنة والتشفير) تقييم مستوى أمان النظام. في حالة عدم حدوث موقف سلبي (القرصنة) ، يكون العمل غير مرئي.
تكون إمكانية وصول النظام أكثر وضوحًا للعميل: إذا نقل المستخدم مبلغًا معينًا إلى الحساب الظاهري ، ثم لم يتمكن من تسجيل الدخول إلى الموقع عدة مرات ، فستقوض مصداقية النظام ويفقد العميل على الأرجح (عدة مرات في الحال - ينتشر السلبي بسرعة). ومن غير المرجح أن يعود المستخدمون المشاركون بصعوبة كبيرة ، والذين يواجهون خطأ بدلاً من الصفحة الرئيسية للموقع.
فهم جدية هذا لم يأت على الفور. في البداية ، كان عدد المستخدمين صغيراً ، وكانت سعة الخادم والقناة وفيرة ، وبالتالي كانت "الأعطال" نادرة. بالإضافة إلى ذلك ، غالبًا ما تم اختبار الوظيفة وتحسينها في البداية من أجل التحسين ، وكان المطور نفسه مسؤولًا عن مراقبة الخوادم المرتبطة بالخدمة أثناء ساعات العمل. كان عدد المستخدمين خلال ساعات العمل صغيرًا نسبيًا - فقد كان العملاء من مناطق زمنية أخرى غائبين عملياً.
تدريجيا ، تم الانتهاء من الجزء الرئيسي من الخدمة. أصبحت التحسينات صغيرة ، وبالتالي تحول الاهتمام الرئيسي للمطورين إلى مشروع آخر. تم تفويض مسؤولية التحكم في النظام إلى مسؤول النظام ، بالإضافة إلى مسؤولياته الأخرى. تم إرسال الإخطارات إلى البريد الإلكتروني والرسائل النصية القصيرة إلى المسؤول في حالة تعطل الخادم. مثل هذه التدابير في ذلك الوقت بدت كافية.
بدأ المنتج يكتسب زخماً وزاد عدد المستخدمين. نشأت أفكار جديدة ، تم تنفيذ بعضها على الفور ، وتم تأجيل بعضها للمستقبل. تمت ترجمة الخدمة إلى لغات أخرى ودخلت أسواقًا تدريجية ، مما أدى ، في جملة أمور ، إلى زيادة عدد المستخدمين في الليل. كان حجم الخادم ينمو تدريجياً ، على الرغم من أنه لا يزال بعيدًا عن الحد الفني للحديد.
بمجرد أن جاء الهدوء إلى نهايته. في ليلة الجمعة إلى السبت ، بدأ المستخدمون يواجهون مشاكل في الوصول إلى الصفحة الرئيسية للموقع ، فقد واجهوا خطأً في كثير من الأحيان 503. كانت المشكلة بسيطة ، ولكن كما ينبغي ، لم يكن المسؤول متاحًا ليلة الجمعة ، وبالتالي ظلت الرسائل القصيرة غير مقروءة. ومع ذلك ، تم حل المشكلة غير مؤلمة نسبيا. تلقى المطور أيضًا رسالة نصية قصيرة ، وتمكّن من الوصول إلى المسؤول وتنبيهه ، وبعد 3 ساعات تم حل المشكلة. مجموع "التوقف" كان 5 ساعات.
يوم الاثنين ، كان هناك استخلاص لما حدث. أظهر تحليل بيانات حركة المرور في الموقع صورة غير سارة - في يوم الجمعة "المثير للمشاكل" ، انخفضت حركة المرور بمقدار الثلث مقارنة بالعام الماضي ، ولكن الانخفاضات الكبيرة يومي السبت والأحد كانت أكثر سوءًا ، على الرغم من عدم وجود مشاكل فنية في هذه الأيام ، انخفضت حركة المرور بنسبة 15٪.
وهذا يعزز فهم الحاجة إلى مراقبة على مدار الساعة. من وجهة نظر البرنامج ، اخترنا
Zabbix ، الذي كان سيتم تثبيته وتكوينه من قبل مسؤول النظام. استغرق الأمر حوالي أسبوع - بقية المهام لم تذهب إلى أي مكان ، وقد تم كل شيء بالتوازي. كان هناك سؤال تنظيمي - من سيراقب بالضبط؟
في البداية ، كان علي اتخاذ هذا القرار - أي تغيير ساعات العمل للموظفين الحاليين (لأولئك الذين فهموا ذلك - أي مسؤول النظام والمطور) بحيث يتحكم شخص واحد على الخادم ليلاً.
كان هذا قرارًا قسريًا ولم يدم طويلًا. أولاً ، لا يزال عمل شخصين لا يوفر تحكمًا على مدار الساعة - فهناك ثغرات في الوقت المحتمل للفشل فيه أيضًا. ثانياً ، قلة من الناس يحبون العمل في الليل ، ونما عدم الرضا ، علاوة على ذلك ، فإن إلهاء المبرمج أوقف التطوير نفسه تقريبًا. لذلك ، بعد أسبوع تركوا الفكرة وبدأوا في التفكير أكثر.
تعيين موظفين إضافيين لمراقبةبالطبع ، هذا القرار هو الأكثر حسمًا - السيطرة المستمرة على الأشخاص المختارين تعطي نتيجة جيدة. ولكن العمل في هذا الوضع يتطلب البحث عن 3 مسؤولي نظام آخرين. علاوة على ذلك ، يجب أن يكونوا مؤهلين بدرجة كافية لحل المشكلات ، ولكن معظم وقتهم سيضيع على أي حال - الشركة صغيرة ، وهناك عدد قليل من الخوادم ، ولن يكون هناك شيء تقريبًا لشغلها. بالإضافة إلى ذلك ، يحتاج الكثير من الناس أيضًا إلى السيطرة عليهم ، الأمر الذي سيكون بمثابة صداع إضافي.
كلا الخيارين لم تنجح. لم يكن من الممكن تركيز الجهود والوسائل عليها. لكن الحاجة للرصد لم تختف. هذه واحدة من مشكلات النمو - هناك حاجة لا يمكن تحقيقها بمفردنا. كحل ، وصلنا إلى الاستعانة بمصادر خارجية.
خلال الفترة الانتقالية ، نشأت الشكوك ، وأهمها هو سلامة وسرية المعلومات التي تصبح متاحة لشخص آخر وجودة الخدمة ، أليس من الأسوأ ، على العكس؟ لكنها مسألة إيجاد منفذ مسؤول وتوقيع NDA.
لذلك ، انتقلنا ، من الجانب الفني لم يكن الأمر صعبًا. بعد شهر ، قررنا التحقق من سير الأمور - عن طريق التحقق من السجلات على الخوادم. نحن راضون عن النتائج - خلال هذا الشهر ، كانت هناك ثلاث حالات فشل خطيرة قد تؤدي إلى "إعادة" الخادم مرة أخرى ، لكن الشركاء حلوا المشكلات في غضون نصف ساعة. علاوة على ذلك ، حدثت جميع حالات الفشل في الفترة الفاصلة من واحدة في الصباح إلى أربعة في الصباح - وهو نمو جغرافي تدريجي للمنتج المتأثر.
لقد تغير عمل مسؤول النظام لدينا وأصبح أكثر راحة. دون أن يصرف الانتباه ، ركز على DevOps. ركزنا جهودنا والتنمية تسارع. اتضح أنه تم إدراك ما تم تأجيله لفترة طويلة ، وذلك بفضل
شريكنا .