يتفاعل جميع مطوري 1C بطريقة أو بأخرى بشكل وثيق مع خدمات تكنولوجيا المعلومات ومباشرة مع مسؤولي النظام. لكن هذا التفاعل لا يسير دائمًا بسلاسة. أود أن أخبركم ببعض القصص المضحكة حول هذا الموضوع.
قناة اتصال عالية السرعة
معظم عملائنا عبارة عن ممتلكات كبيرة ولديهم أقسام تكنولوجيا معلومات كبيرة خاصة بهم. وعادة ما يكون متخصصو العملاء مسؤولين عن النسخ الاحتياطية لقواعد بيانات المعلومات. ولكن هناك أيضًا منظمات صغيرة نسبيًا. خاصة بالنسبة لهم، لدينا خدمة نتحمل من خلالها جميع المشكلات المتعلقة بالنسخ الاحتياطي لكل شيء 1C. هذه هي الشركة التي سنتحدث عنها في هذه القصة.
جاء عميل جديد لدعم 1C، ومن بين أمور أخرى، تضمن العقد بندًا ينص على أننا مسؤولون عن النسخ الاحتياطية، على الرغم من أن لديهم مسؤول النظام الخاص بهم ضمن طاقم العمل. قاعدة بيانات خادم العميل، MS SQL باعتبارها نظام إدارة قواعد البيانات. وضع قياسي إلى حد ما، ولكن لا يزال هناك فارق بسيط: كانت القاعدة الرئيسية كبيرة جدًا، لكن الزيادة الشهرية كانت صغيرة جدًا. أي أن قاعدة البيانات تحتوي على الكثير من البيانات التاريخية. مع أخذ هذه الميزة في الاعتبار، قمت بإعداد خطط صيانة النسخ الاحتياطي على النحو التالي: في أول يوم سبت من كل شهر، تم عمل نسخة احتياطية كاملة، وكانت ثقيلة جدًا، ثم تم عمل نسخة تفاضلية كل ليلة - حجم صغير نسبيًا، ونسخة من سجل المعاملات كل ساعة. علاوة على ذلك، لم يتم نسخ النسخ الكاملة والتفاضلية إلى مورد الشبكة فحسب، بل تم تحميلها أيضًا إلى خادم FTP الخاص بنا. وهذا مطلب إلزامي عند تقديم هذه الخدمة.
تم تكوين كل هذا بنجاح وتشغيله وعمل بشكل عام دون أعطال.
ولكن بعد بضعة أشهر، تغير مسؤول النظام في هذه المنظمة. بدأ مسؤول النظام الجديد في إعادة بناء البنية التحتية لتكنولوجيا المعلومات للشركة تدريجيًا وفقًا للاتجاهات الحديثة. على وجه الخصوص، ظهرت المحاكاة الافتراضية، وأرفف القرص، وتم حظر الوصول في كل مكان وكل شيء، وما إلى ذلك، والذي في الحالة العامة، بالطبع، لا يمكن إلا أن نفرح. لكن الأمور لم تكن تسير دائمًا بسلاسة بالنسبة له، فغالبًا ما كانت هناك مشاكل في أداء 1C، مما تسبب في بعض الخلافات وسوء الفهم مع دعمنا. كما تجدر الإشارة إلى أن علاقتنا به بشكل عام كانت باردة جدًا ومتوترة إلى حد ما، مما يزيد من درجة التوتر في حالة حدوث أي مشاكل.
ولكن في صباح أحد الأيام تبين أن خادم هذا العميل غير متاح. اتصلت بمسؤول النظام لمعرفة ما حدث وتلقيت إجابة مثل "لقد تعطل خادمنا، ونحن نعمل على حل المشكلة، وليس الأمر متروكًا لك". حسنًا، من الجيد أنهم يعملون. وهذا يعني أن الوضع تحت السيطرة. بعد الغداء، أتصل مرة أخرى، وبدلاً من الانزعاج، أستطيع أن أشعر بالفعل بالتعب واللامبالاة في صوت المسؤول. أحاول معرفة ما حدث وهل هناك أي شيء يمكننا القيام به للمساعدة؟ وبنتيجة الحوار ظهر ما يلي:
قام بنقل الخادم إلى نظام تخزين جديد من خلال غارة مجمعة حديثًا. ولكن حدث خطأ ما، وبعد بضعة أيام انهارت هذه الغارة بأمان. لا أتذكر بالضبط ما إذا كانت وحدة التحكم قد احترقت أو حدث شيء ما للأقراص، لكن جميع المعلومات فقدت بشكل لا رجعة فيه. والشيء الرئيسي هو أن مورد الشبكة الذي يحتوي على نسخ احتياطية انتهى به الأمر أيضًا على نفس مجموعة الأقراص أثناء عمليات الترحيل المختلفة. أي أنه تم فقد قاعدة البيانات الإنتاجية نفسها وجميع نسخها الاحتياطية. وليس من الواضح ما يجب فعله الآن.
أقول اهدأ. لدينا نسخة احتياطية ليلا الخاص بك. ردًا على ذلك، ساد صمت أدركت فيه أنني أنقذت للتو حياة رجل. نبدأ في مناقشة كيفية نقل هذه النسخة إلى خادم جديد تم نشره حديثًا. ولكن هنا أيضا نشأت مشكلة.
هل تتذكر عندما قلت أن النسخة الاحتياطية الكاملة كانت كبيرة جدًا؟ لم يكن من قبيل الصدفة أنني فعلت ذلك مرة واحدة في الشهر يوم السبت. الحقيقة هي أن الشركة كانت عبارة عن مصنع صغير يقع بعيدًا خارج المدينة وكان الإنترنت الخاص بها متوسطًا للغاية. بحلول صباح يوم الاثنين، أي خلال عطلة نهاية الأسبوع، بالكاد تمكنا من تحميل هذه النسخة إلى خادم FTP الخاص بنا. ولكن لم تكن هناك طريقة للانتظار يومًا أو يومين حتى يتم تحميله في الاتجاه المعاكس. بعد عدة محاولات فاشلة لنقل الملف، أخرج المسؤول القرص الصلب مباشرة من الخادم الجديد، وعثر على سيارة مع سائق في مكان ما وهرع بسرعة إلى مكتبنا، ولحسن الحظ أننا لا نزال في نفس المدينة.
وبينما كانوا يقفون في غرفة الخادم لدينا وينتظرون نسخ الملفات، التقينا لأول مرة، إذا جاز التعبير، "شخصيًا"، وشربنا فنجانًا من القهوة، وتحدثنا في إطار غير رسمي. لقد تعاطفت مع حزنه وأرسلته مرة أخرى مع مجموعة كاملة من النسخ الاحتياطية، واستعادة العمل المتوقف للشركة على عجل.
وبعد ذلك، تم حل جميع طلباتنا المقدمة إلى قسم تكنولوجيا المعلومات بسرعة كبيرة ولم تنشأ أي خلافات أخرى.
اتصل بمسؤول النظام الخاص بك
مرة واحدة، لفترة طويلة جدًا، لم أتمكن من نشر 1C للوصول إلى الويب عبر IIS لعميل واحد. بدت وكأنها مهمة عادية، ولكن لم تكن هناك طريقة لتشغيل كل شيء. انخرط مسؤولو النظام المحليون وجربوا إعدادات وملفات تكوين مختلفة. 1C على الويب عادةً لا يريد العمل بأي شكل من الأشكال. حدث خطأ ما، سواء في سياسات أمان المجال، أو في جدار الحماية المحلي المتطور، أو الله أعلم ماذا أيضًا. في التكرار Nth، يرسل لي المشرف رابطًا يحتوي على الكلمات:
- حاول مرة أخرى باستخدام هذه التعليمات. تم وصف كل شيء هناك بالتفصيل التام. إذا لم ينجح الأمر، فاكتب إلى مؤلف هذا الموقع، ربما يمكنه المساعدة.
أقول: "لا"، "لن يساعد".
- لماذا؟
— أنا مؤلف هذا الموقع... (
ونتيجة لذلك، قمنا بتشغيله على Apache دون أي مشاكل. لم يُهزم IIS أبدًا.
مستوى واحد أعمق
كان لدينا عميل - مؤسسة تصنيع صغيرة. كان لديهم خادم، نوع من "الكلاسيكي" 3 في 1: خادم طرفي + خادم تطبيقات + خادم قاعدة بيانات. لقد عملوا في بعض التكوينات الخاصة بالصناعة بناءً على UPP، وكان هناك حوالي 15-20 مستخدمًا، وكان أداء النظام، من حيث المبدأ، مناسبًا للجميع.
مع مرور الوقت، كل شيء يعمل بشكل أكثر أو أقل استقرارا. ولكن بعد ذلك فرضت أوروبا عقوبات على روسيا، ونتيجة لذلك بدأ الروس في شراء المنتجات المنتجة محليًا بشكل أساسي، وارتفعت أعمال هذه الشركة بشكل حاد. ارتفع عدد المستخدمين إلى 50-60 شخصًا، وتم افتتاح فرع جديد، وزاد تدفق المستندات وفقًا لذلك. والآن لم يعد الخادم الحالي قادرًا على التعامل مع الحمل المتزايد بشكل حاد، وبدأ 1C، كما يقولون، في "التباطؤ". خلال ساعات الذروة، تمت معالجة المستندات لعدة دقائق، وحدثت أخطاء في الحظر، واستغرق فتح النماذج وقتًا طويلاً، بالإضافة إلى المجموعة الأخرى من الخدمات ذات الصلة. تجاهل مسؤول النظام المحلي جميع المشكلات قائلاً: "هذا هو 1C الخاص بك، وسوف تكتشف ذلك." لقد اقترحنا مراراً وتكراراً إجراء تدقيق لأداء النظام، لكن الأمر لم يصل إلى التدقيق نفسه. طلب العميل ببساطة توصيات حول كيفية حل المشكلات.
حسنًا ، جلست وكتبت رسالة طويلة إلى حد ما حول الحاجة إلى فصل أدوار الخادم الطرفي وخادم التطبيقات مع نظام إدارة قواعد البيانات (وهو ما قلناه من حيث المبدأ عدة مرات من قبل). لقد كتبت عن DFSS على الخوادم الطرفية، وعن الذاكرة المشتركة، وقدمت روابط لمصادر موثوقة، بل واقترحت بعض الخيارات للمعدات. وصلت هذه الرسالة إلى من هم في السلطة في الشركة، ثم عادت إلى قسم تكنولوجيا المعلومات مع القرار "التنفيذ" وتم كسر الجمود بشكل عام.
وبعد مرور بعض الوقت، يرسل لي المسؤول عنوان IP الخاص بالخادم الجديد وبيانات اعتماد تسجيل الدخول. يقول أنه يتم نشر مكونات خادم MS SQL و1C هناك، ويجب نقل قواعد البيانات، ولكن في الوقت الحالي فقط إلى خادم DBMS، نظرًا لوجود بعض المشكلات مع مفاتيح 1C.
لقد جئت بالفعل، وكانت جميع الخدمات قيد التشغيل، ولم يكن الخادم قويًا جدًا، لكن حسنًا، أعتقد أن هذا أفضل من لا شيء. سأقوم بنقل قواعد البيانات في الوقت الحالي من أجل تخفيف الخادم الحالي بطريقة أو بأخرى. لقد أكملت جميع عمليات النقل في الوقت المتفق عليه، لكن الوضع لم يتغير - لا تزال نفس مشاكل الأداء. إنه أمر غريب بالطبع، فلنسجل قواعد البيانات في مجموعة 1C وسنرى.
مرت عدة أيام، ولم يتم نقل المفاتيح. أتساءل ما هي المشكلة، يبدو أن كل شيء بسيط - أخرجه من خادم واحد، وقم بتوصيله بخادم آخر، ثم قم بتثبيت برنامج التشغيل، وبذلك تكون قد انتهيت. يستجيب المسؤول من خلال إثارة القلق وقول شيء ما حول إعادة توجيه المنفذ، والخادم الظاهري، وما إلى ذلك.
حسنًا... الخادم الافتراضي؟ يبدو أنه لم يكن هناك أي محاكاة افتراضية على الإطلاق ولم يكن هناك أي شيء على الإطلاق... أتذكر مشكلة معروفة إلى حد ما تتمثل في استحالة إعادة توجيه مفتاح خادم 1C إلى جهاز افتراضي على Hyper-V في Windows Server 2008. وهنا بدأت بعض الشكوك تتشكل بداخلي..
أفتح مدير الخادم - الأدوار - ظهر دور جديد - Hyper-V. أذهب إلى مدير Hyper-V، وأرى جهازًا افتراضيًا واحدًا، وأتصل... وبالفعل... خادم قاعدة البيانات الجديد الخاص بنا...
وماذا في ذلك؟ لقد تم تنفيذ تعليمات السلطات وتوصياتي، وتم فصل الأدوار. يمكن إغلاق المهمة.
بعد مرور بعض الوقت، حدثت الأزمة الآن، وكان لا بد من إغلاق الفرع الجديد، وانخفض الحمل، وأصبح أداء النظام مقبولاً إلى حد ما.
حسنًا، بالطبع، لم يتمكنوا من إعادة توجيه مفتاح الخادم إلى الجهاز الظاهري. ونتيجة لذلك، تم ترك كل شيء كما هو: الخادم الطرفي + مجموعة 1C على جهاز فعلي، وخادم قاعدة البيانات هناك في جهاز افتراضي.
وسيكون من الرائع أن يكون هذا نوعًا من مكتب شاراشكين. لذا لا. شركة مشهورة ربما تعرف منتجاتها وشاهدتها في الأقسام ذات الصلة في جميع مناطق Lentas وAuchans.
جدول إجازة القرص الصلب
قامت شركة قابضة كبيرة ذات خطط طموحة للسيطرة على العالم بشراء شركة صغيرة مرة أخرى بهدف ضمها إلى شركتها الضخمة. في جميع أقسام هذه الملكية، يعمل المستخدمون في قواعد البيانات الخاصة بهم، ولكن بتكوين مماثل. وهكذا بدأنا مشروعًا صغيرًا لإدراج وحدة جديدة في هذا النظام.
بادئ ذي بدء، من الضروري نشر قواعد بيانات الإنتاج والاختبار. استلم المطور بيانات الاتصال، وقام بتسجيل الدخول إلى الخادم، وشاهد تثبيت MS SQL، وخادم 1C، وشاهد محركي أقراص منطقيين: محرك الأقراص "C" بسعة 2 جيجابايت ومحرك الأقراص "D" بسعة 250 تيرابايت. حسنًا، "C" هو النظام، و"D" مخصص للبيانات، ويقرر المطور بشكل منطقي وينشر جميع قواعد البيانات هناك. حتى أنني قمت بإعداد خطط الصيانة، بما في ذلك النسخ الاحتياطي، تحسبًا (على الرغم من أننا لسنا مسؤولين عن ذلك). صحيح، تمت إضافة النسخ الاحتياطية هنا إلى "D". في المستقبل، تم التخطيط لإعادة تكوينه لبعض موارد الشبكة المنفصلة.
بدأ المشروع، وقدم الاستشاريون التدريب على كيفية العمل في النظام الجديد، وتم نقل بقايا الطعام، وتم إجراء بعض التحسينات الطفيفة، وبدأ المستخدمون في العمل في قاعدة المعلومات الجديدة.
كان كل شيء يسير على ما يرام حتى صباح يوم الاثنين عندما تم اكتشاف أن قرص قاعدة البيانات مفقود. ببساطة لا يوجد "D" على الخادم وهذا كل شيء.
كشفت التحقيقات الإضافية عن هذا: كان هذا "الخادم" في الواقع كمبيوتر العمل الخاص بمسؤول النظام المحلي. صحيح أنه لا يزال لديه نظام تشغيل الخادم. تم توصيل محرك أقراص USB الشخصي لهذا المسؤول بالخادم. وهكذا ذهب المسؤول في إجازة، حاملاً معه المسمار الخاص به، بهدف ضخ الأفلام فيه خلال الرحلة.
والحمد لله أنه لم يتمكن من حذف ملفات قاعدة البيانات وتمكن من استعادة قاعدة البيانات المنتجة.
من الجدير بالذكر أن الجميع كانوا راضين عمومًا عن أداء النظام الموجود على محرك أقراص USB. لم يشتكي أحد من أي أداء غير مرض لـ 1C. في وقت لاحق فقط، بدأت الشركة القابضة مشروعًا ضخمًا لنقل جميع قواعد بيانات المعلومات إلى موقع مركزي واحد به خوادم فائقة، وأنظمة تخزين تزيد عن مليون روبل، وبرامج مراقبة متطورة ومكابح 1C لا تطاق في جميع الفروع.
لكن هذه قصة مختلفة تمامًا ...
المصدر: www.habr.com