يتفاعل جميع مطوري 1C بشكل أو بآخر مع خدمات تكنولوجيا المعلومات وبشكل مباشر مع مسؤولي النظام. لكن ليس هذا التفاعل دائمًا بسلاسة. أود أن أخبركم ببعض القصص المضحكة حول هذا الموضوع.
قناة اتصال عالية السرعة
معظم عملائنا من المقتنيات الكبيرة مع أقسام تكنولوجيا المعلومات الكبيرة الخاصة بهم. وللحصول على نسخ احتياطية من infobases ، كقاعدة عامة ، المتخصصين العميل مسؤولة. ولكن هناك منظمات صغيرة نسبيا. خاصة بالنسبة لهم ، لدينا خدمة نعتني بها بجميع المشكلات المتعلقة بنسخة احتياطية لكل 1C. حول مثل هذه الشركة سوف تناقش في هذه القصة.
لقد جاء عميل جديد لدعم 1C ، وكان من ضمن أشياء أخرى ، العقد الذي ينص على أننا مسؤولون عن النسخ الاحتياطية ، على الرغم من أن لديهم مسؤول النظام الخاص بهم على الموظفين. قاعدة بيانات خادم العميل ، مثل DBMS - MS SQL. وضع قياسي إلى حد ما ، ولكن لا يزال هناك تحذير واحد: القاعدة الرئيسية كانت كبيرة جدًا ، ولكن في نفس الوقت كانت الزيادة الشهرية صغيرة جدًا. أي أن قاعدة البيانات تحتوي على الكثير من البيانات التاريخية. بالنظر إلى هذه الخصوصية ، قمت بإعداد خطط صيانة احتياطية على النحو التالي: في أول يوم سبت من كل شهر ، تم عمل نسخة احتياطية كاملة ، وكان وزنها جيدًا ، ثم تم إنشاء نسخة تفاضلية كل ليلة - حجم صغير نسبيًا وسجل معاملة كل ساعة. علاوة على ذلك ، تم أيضًا تحميل نُسخ كاملة وتفضيلية ، ليس فقط لأنها تم نسخها إلى مورد شبكة ، إلى خادم FTP الخاص بنا. هذا مطلب إلزامي لتقديم هذه الخدمة.
تم تكوين كل هذا بنجاح ، ووضعه موضع التنفيذ وعمله بشكل عام دون فشل.
ولكن بعد بضعة أشهر ، تغير مسؤول النظام في هذه المؤسسة. بدأ مسؤول النظام الجديد في إعادة بناء البنية التحتية لتكنولوجيا المعلومات للشركة تدريجياً وفقًا للاتجاهات الحديثة. على وجه الخصوص ، ظهرت المحاكاة الافتراضية ، وأرفف الأقراص ، والوصول كان مغلقًا في كل مكان وكل شيء ، وما إلى ذلك ، وهو أمر لا يمكن إلا أن يفرح في الحالة العامة. لكن الأمر لم يسير دائمًا بشكل سلس معه ، فغالبًا ما كانت هناك مشاكل في أداء 1C ، والتي تسببت في بعض الخلاف وسوء الفهم بدعمنا. أيضا ، تجدر الإشارة إلى أن علاقاتنا معه تطورت عموما بشكل بارد جدا وتوترت إلى حد ما ، مما زاد من درجة التوتر في حالة وجود أي مشاكل.
ولكن في صباح أحد الأيام اتضح أن خادم هذا العميل غير متوفر. اتصلت بمسؤول النظام لمعرفة ما حدث وتلقى شيئًا مثل "لقد تعطل خادمنا ، فنحن نعمل عليه ، الأمر لا يرجع إليك". حسنا ، هذا يعمل. وبالتالي فإن الوضع تحت السيطرة. بعد الغداء ، أعد الاتصال مرة أخرى ، بصوت المسؤول ، بدلاً من الغضب ، أشعر بالفعل بالتعب واللامبالاة. محاولة توضيح ما حدث ، وهل يمكننا المساعدة بطريقة أو بأخرى؟ كشفت المحادثة ما يلي:
انتقل الخادم إلى نظام تخزين جديد مع غارة تجميعها للتو. ولكن حدث خطأ ما وبعد بضعة أيام انهارت هذه الغارة بسلام. إما أن وحدة التحكم قد أحرقت ، أو حدث شيء ما على الأقراص ، لا أتذكر بالضبط ، ولكن تم فقد جميع المعلومات بشكل لا يمكن إصلاحه. والشيء الرئيسي هو أن مورد الشبكة مع النسخ الاحتياطي أيضا في عملية أي ترحيل كان على نفس مجموعة القرص. وهذا هو ، على حد سواء فقدت القاعدة الإنتاجية نفسها وجميع النسخ الاحتياطية لها. وماذا تفعل الآن ليست واضحة.
بهدوء ، أقول. لدينا احتياطية ليلة الخاص بك. الجواب هو الصمت ، الذي أدركت به أنني أنقذت حياة شخص ما. نبدأ في مناقشة كيفية نقل هذه النسخة إلى خادم جديد تم نشره للتو. ولكن هنا نشأت مشكلة.
تذكر ، قلت أن النسخ الاحتياطي الكامل كان كبيرا جدا؟ لقد فعلت ذلك لسبب مرة واحدة في الشهر يوم السبت. والحقيقة هي أن الشركة كانت عبارة عن مصنع صغير ، يقع خارج المدينة ، وكان الإنترنت الذي يمتلكونه جيدًا جدًا. بحلول صباح يوم الاثنين ، أي خلال عطلة نهاية الأسبوع ، كانت هذه النسخة مع الحزن في نصف الوقت للتحميل إلى خادم FTP لدينا. ولكن لم يكن هناك طريقة للانتظار لمدة يوم أو يومين حتى يتم التحميل في الاتجاه المعاكس. بعد عدة محاولات فاشلة لسحب الملف ، أخرج المسؤول القرص الصلب المباشر من الخادم الجديد ، وعثر على سيارة مع سائق في مكان ما وسارع بسرعة إلى مكتبنا ، لأننا ما زلنا في نفس المدينة.
بينما كنا نقف في غرفة الخادم وننتظر نسخ الملفات ، التقينا أولاً ، إذا جاز التعبير ، "حي" ، شربنا فنجان قهوة ، وتحدثنا في مكان غير رسمي. تعاطفت مع حزنه وأرسلته بمسمار كامل من النسخ الاحتياطية ، في عجلة من أمرنا لاستعادة العمل المتوقف للشركة.
بعد ذلك ، تم حل جميع طلباتنا إلى قسم تكنولوجيا المعلومات بسرعة كبيرة ولم تكن هناك خلافات أخرى.
اتصل بمسؤول النظام الخاص بك
مرة واحدة ، مع عميل واحد ، لفترة طويلة جدًا لم أستطع نشر 1C للوصول إلى الويب من خلال IIS. يبدو أن هذه مهمة عادية ، لكنها لم تنفد. مسؤولو النظام المحلي متصلة ، حاول إعدادات مختلفة وملفات التكوين. 1C على شبكة الإنترنت عادة لم ترغب في العمل في أي. كان هناك خطأ ما في سياسات أمان المجال ، أو في جدار الحماية المحلي المتطور ، أو ماذا بحق الجحيم. في التكرار Nth ، يسقط المسؤول رابطًا لي بالكلمات:
- حاول مرة أخرى مع هذه التعليمات. كل شيء مفصل جدا هناك. إذا لم ينجح الأمر ، فاكتب إلى مؤلف هذا الموقع ، وربما سيساعد.
"لا ،" أقول ، "لن يساعد ذلك".
- لماذا؟
- أنا مؤلف هذا الموقع ... (
نتيجة لذلك ، أطلقوا Apache دون أي مشاكل. IIS لا يمكن أن يفوز.
على مستوى أعمق
كان لدينا عميل - شركة تصنيع صغيرة. كان لديهم خادم ، مثل غريبة "الكلاسيكية" 3 في 1: خادم المحطة الطرفية + خادم التطبيق + خادم قاعدة البيانات. لقد عملوا في بعض التكوينات الصناعية استنادًا إلى مشغلات البداية ، وكان هناك حوالي 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 الكتلة على الجهاز الفعلي ، خادم قاعدة البيانات في نفس المكان في واحد الظاهري.
حسناً ، هل سيكون نوع من مكتب شراشكين. لذلك لا. شركة معروفة ، من المحتمل أن تعرف منتجاتها وشاهدتها في الإدارات ذات الصلة بكل أنواع Ribbons و Auchanov.
القرص الصلب عطلة الجدول
اشترت شركة قابضة كبيرة لديها خطط طموحة
للسيطرة على العالم مرة أخرى شركة صغيرة بهدف دمجها في شركتها الضخمة. في جميع أقسام هذا الحجز ، يعمل المستخدمون في قواعد بياناتهم ، ولكن بتكوين مماثل. وهكذا بدأنا مشروعًا صغيرًا لتضمين وحدة جديدة في هذا النظام.
بادئ ذي بدء ، من الضروري نشر قواعد القتال والاختبار. تلقى المطور البيانات الخاصة بالاتصال ، ويقوم بتسجيل الدخول إلى الخادم ، ويشاهد MS SQL المثبت ، والخادم 1C ، ويرى محركي أقراص منطقيين: محرك أقراص سعة 250 جيجابايت ومحرك أقراص سعة 1 تيرابايت. حسنًا ، "C" هو نظام ، "D" للبيانات ، يقرر المطور منطقياً وينشر جميع قواعد البيانات هناك. قمت حتى بإعداد خطط الصيانة ، بما في ذلك النسخ الاحتياطية ، فقط في حالة (على الرغم من أننا لسنا مسؤولين عن هذا). أخذت النسخ الاحتياطية الحقيقية تتشكل هنا على "D". في المستقبل ، تم التخطيط لإعادة تكوين بالفعل على بعض موارد شبكة منفصلة.
تم إطلاق المشروع ، وأجرى الاستشاريون تدريباً على كيفية العمل في النظام الجديد ، وتم نقل بقايا الطعام ، وتم إجراء بعض التحسينات على النقاط الصغيرة وبدأ المستخدمون العمل بالفعل في قاعدة المعلومات الجديدة.
كل شيء سار على ما يرام حتى صباح أحد أيام الاثنين تم اكتشاف أن محرك قاعدة البيانات قد اختفى. لا يوجد ببساطة حرف "D" على الخادم وهذا كل شيء.
كشف المزيد من التحقيقات عن هذا: في الواقع ، كان هذا "الخادم" هو الكمبيوتر العامل لمسؤول النظام المحلي. صحيح ، كان نظام التشغيل الخادم لا يزال على ذلك. تم إدخال قرص USB شخصي لهذا المسؤول في الخادم. وذهب المسؤول في إجازة أخذ معه برغي خاص به ، بهدف ضخ الأفلام عليه على الطريق.
الحمد لله ، لم يتمكن من حذف ملفات قاعدة البيانات وتمكن من استعادة قاعدة البيانات العاملة.
من الجدير بالذكر أن الجميع ، بشكل عام ، كانوا راضين عن أداء النظام الموجود على محرك USB. لا أحد يشكو من أي عمل غير مرضية ل 1 C. في وقت لاحق بالفعل ، بدأ المشروع الضخم في الانتظار لنقل جميع قواعد بيانات المعلومات إلى منصة مركزية واحدة مع خوادم فائقة ، وتخزينها لمليون روبل ، وبرامج Hypervisor متطورة وفرامل 1C لا تُطاق في جميع الفروع.
لكن هذه قصة مختلفة تماما ...
PS انظر أيضا: