داستان های توسعه دهنده 1C: مدیر

همه توسعه دهندگان 1C به یک روش یا روشی دیگر با خدمات فناوری اطلاعات و مستقیماً با مدیران سیستم تعامل نزدیک دارند. اما این تعامل همیشه هموار پیش نمی رود. من می خواهم چند داستان خنده دار در این مورد برای شما تعریف کنم.

کانال ارتباطی پرسرعت

اکثر مشتریان ما هلدینگ های بزرگی هستند که بخش های بزرگ فناوری اطلاعات خود را دارند. و متخصصان مشتری معمولاً مسئول نسخه‌های پشتیبان از پایگاه‌های اطلاعاتی هستند. اما سازمان های نسبتا کوچکی نیز وجود دارند. به خصوص برای آنها، ما سرویسی داریم که طبق آن تمام مسائل مربوط به پشتیبان گیری از همه چیز 1C را بر عهده می گیریم. این شرکتی است که در این داستان درباره آن صحبت خواهیم کرد.

یک کلاینت جدید برای پشتیبانی از 1C آمد و، در میان چیزهای دیگر، قرارداد شامل یک بند بود که ما مسئول پشتیبان‌گیری هستیم، اگرچه آنها مدیر سیستم خود را در کارکنان داشتند. پایگاه داده مشتری-سرور، MS SQL به عنوان یک DBMS. یک وضعیت نسبتاً استاندارد، اما هنوز یک تفاوت وجود داشت: پایه اصلی بسیار بزرگ بود، اما افزایش ماهانه بسیار ناچیز بود. یعنی پایگاه داده حاوی داده های تاریخی زیادی بود. با در نظر گرفتن این ویژگی، من برنامه های نگهداری نسخه پشتیبان را به شرح زیر تنظیم کردم: در اولین شنبه هر ماه یک نسخه پشتیبان کامل تهیه می شد، بسیار سنگین بود، سپس هر شب یک کپی دیفرانسیل تهیه می شد - حجم نسبتاً کم و یک کپی گزارش تراکنش هر ساعت علاوه بر این، نسخه‌های کامل و دیفرانسیل نه تنها در یک منبع شبکه کپی شدند، بلکه علاوه بر آن در سرور FTP ما نیز آپلود شدند. این یک الزام اجباری در هنگام ارائه این خدمات است.

همه اینها با موفقیت پیکربندی شد، به بهره برداری رسید و به طور کلی بدون شکست کار کرد.

اما چند ماه بعد مدیر سیستم در این سازمان تغییر کرد. مدیر سیستم جدید شروع به بازسازی تدریجی زیرساخت فناوری اطلاعات شرکت مطابق با روندهای مدرن کرد. به طور خاص، مجازی سازی ظاهر شد، قفسه های دیسک، دسترسی به همه جا و همه چیز مسدود شد، و غیره، که در حالت کلی، البته، نمی تواند شادی کند. اما همه چیز برای او همیشه هموار پیش نمی رفت. همچنین لازم به ذکر است که رابطه ما با او به طور کلی کاملا سرد و تا حدودی تیره بود که در صورت بروز مشکل تنها بر میزان تنش افزوده می شد.

اما یک روز صبح معلوم شد که سرور این مشتری در دسترس نیست. من با مدیر سیستم تماس گرفتم تا بفهمم چه اتفاقی افتاده است و به عنوان پاسخ چیزی مانند "سرور ما خراب شده است، ما در حال کار بر روی آن هستیم، به شما بستگی ندارد." خوب، خوب است که آنها کار می کنند. یعنی اوضاع تحت کنترل است. بعد از ناهار، دوباره تماس می‌گیرم و به جای عصبانیت، از قبل می‌توانم احساس خستگی و بی‌تفاوتی در صدای ادمین کنم. من سعی می کنم بفهمم چه اتفاقی افتاده است و آیا کاری وجود دارد که بتوانیم کمک کنیم؟ در نتیجه گفتگو موارد زیر مشخص شد:

او سرور را با یک حمله جدید مونتاژ شده به یک سیستم ذخیره سازی جدید منتقل کرد. اما مشکلی پیش آمد و چند روز بعد این حمله با خیال راحت از بین رفت. اینکه آیا کنترلر سوخته یا اتفاقی برای دیسک ها افتاده است، دقیقاً به یاد ندارم، اما تمام اطلاعات به طور غیرقابل برگشتی از بین رفت. و نکته اصلی این بود که منبع شبکه با پشتیبان گیری نیز در طول مهاجرت های مختلف به همان آرایه دیسک ختم شد. یعنی هم خود پایگاه داده تولیدی و هم تمام نسخه های پشتیبان آن از بین رفتند. و معلوم نیست الان چه باید کرد.

آروم باش میگم ما پشتیبان شبانه شما را داریم. در پاسخ، سکوتی حاکم شد و با آن متوجه شدم که به تازگی جان یک مرد را نجات داده ام. ما شروع به بحث در مورد چگونگی انتقال این کپی به یک سرور جدید و تازه مستقر می کنیم. اما اینجا هم مشکلی پیش آمد.

یادتان هست که گفتم بک آپ کامل بسیار بزرگ است؟ بیخود نبود که شنبه ها ماهی یک بار این کار را می کردم. واقعیت این است که این شرکت یک کارخانه کوچک بود که در خارج از شهر قرار داشت و اینترنت آنها بسیار خوب بود. تا صبح دوشنبه، یعنی در آخر هفته، این نسخه به سختی توانست در سرور FTP ما آپلود شود. اما راهی وجود نداشت که یکی دو روز صبر کرد تا در جهت مخالف بارگیری شود. بعد از چندین بار تلاش ناموفق برای انتقال فایل، مدیر هارد دیسک را مستقیماً از سرور جدید خارج کرد، در جایی ماشینی با راننده پیدا کرد و سریع به دفتر ما هجوم آورد، خوشبختانه ما هنوز در همان شهر هستیم.

در حالی که آنها در اتاق سرور ما ایستاده بودند و منتظر بودند تا فایل ها کپی شوند، ما برای اولین بار، به اصطلاح، "شخصی" ملاقات کردیم، یک فنجان قهوه نوشیدیم و در یک محیط غیررسمی صحبت کردیم. من با اندوه او همدردی کردم و او را با یک پیچ کامل پشتیبان فرستادم و با عجله کار متوقف شده شرکت را بازگرداندم.

متعاقباً تمام درخواست‌های ما به بخش فناوری اطلاعات خیلی سریع برطرف شد و دیگر هیچ اختلافی پیش نیامد.

با سرپرست سیستم خود تماس بگیرید

یک بار، برای مدت بسیار طولانی، نمی توانستم 1C را برای دسترسی به وب از طریق IIS برای یک مشتری منتشر کنم. به نظر یک کار معمولی بود، اما هیچ راهی برای اجرای همه چیز وجود نداشت. مدیران سیستم محلی درگیر شدند و تنظیمات و فایل های پیکربندی مختلف را امتحان کردند. 1C در وب معمولاً به هیچ وجه نمی خواست کار کند. مشکلی وجود داشت، یا با سیاست های امنیتی دامنه، یا با فایروال پیچیده محلی، یا خدا می داند چه چیز دیگری. در تکرار نهم، ادمین لینکی با این عبارت برای من ارسال می کند:

- با استفاده از این دستورالعمل ها دوباره امتحان کنید. همه چیز در آنجا با جزئیات کامل توضیح داده شده است. اگر کار نکرد، برای نویسنده این سایت بنویسید، شاید بتواند کمک کند.
من می گویم: "نه، این کمکی نمی کند."
- چرا؟
— من نویسنده این سایت هستم... (

در نتیجه بدون هیچ مشکلی آن را روی آپاچی راه اندازی کردیم. IIS هرگز شکست نخورد.

یک سطح عمیق تر

ما یک مشتری داشتیم - یک شرکت تولیدی کوچک. آنها یک سرور داشتند، یک نوع "کلاسیک" 3 در 1: سرور ترمینال + سرور برنامه + سرور پایگاه داده. آنها در برخی از پیکربندی های صنعتی بر اساس SCP کار می کردند، حدود 15-20 کاربر وجود داشت، عملکرد سیستم، در اصل، برای همه مناسب بود.

با گذشت زمان، همه چیز کم و بیش ثابت کار می کرد. اما پس از آن اروپا تحریم هایی را علیه روسیه اعمال کرد که در نتیجه روس ها شروع به خرید محصولات عمدتاً داخلی کردند و تجارت این شرکت به شدت بالا رفت. تعداد کاربران به 50-60 نفر افزایش یافت، شعبه جدیدی افتتاح شد و جریان اسناد به همین نسبت افزایش یافت. و اکنون سرور فعلی دیگر نمی تواند با افزایش شدید بار مقابله کند و 1C همانطور که می گویند شروع به "کاهش سرعت" کرد. در ساعات اوج مصرف، اسناد برای چند دقیقه پردازش می‌شد، خطاهای مسدود کردن رخ می‌داد، باز کردن فرم‌ها زمان زیادی طول می‌کشید و کل دسته خدمات مرتبط دیگر. مدیر سیستم محلی تمام مشکلات را برطرف کرد و گفت: "این 1C شماست، شما متوجه خواهید شد." ما بارها پیشنهاد انجام ممیزی عملکرد سیستم را داده‌ایم، اما هرگز به خود ممیزی نرسید. مشتری به سادگی توصیه هایی در مورد چگونگی رفع مشکلات خواست.

خوب، من نشستم و نامه ای نسبتاً طولانی در مورد نیاز به جداسازی نقش های سرور ترمینال و سرور برنامه با DBMS نوشتم (که در اصل قبلاً بارها گفته ایم). من در مورد DFSS در سرورهای ترمینال، در مورد حافظه مشترک نوشتم، پیوندهایی به منابع معتبر ارائه کردم، و حتی برخی از گزینه‌ها را برای تجهیزات پیشنهاد کردم. این نامه به دست صاحبان قدرت در شرکت رسید، با قطعنامه "اجرا" به بخش فناوری اطلاعات بازگشت و یخ به طور کلی شکست.

پس از مدتی، ادمین آدرس IP سرور جدید و اعتبارنامه ورود به سیستم را برای من ارسال می کند. او می‌گوید که مؤلفه‌های سرور MS SQL و 1C در آنجا مستقر شده‌اند و پایگاه‌های داده باید منتقل شوند، اما در حال حاضر فقط به سرور DBMS، زیرا برخی مشکلات با کلیدهای 1C به وجود آمده است.

من وارد شدم، در واقع، همه سرویس ها در حال اجرا بودند، سرور خیلی قوی نبود، اما خوب، فکر می کنم از هیچی بهتر است. من فعلاً پایگاه های داده را منتقل می کنم تا به نحوی سرور فعلی را راحت کنم. من تمام نقل و انتقالات را در زمان توافق شده تکمیل کردم، اما وضعیت تغییر نکرد - هنوز هم همان مشکلات عملکردی. عجیب است، البته، خوب، بیایید پایگاه های داده را در کلاستر 1C ثبت کنیم و خواهیم دید.

چندین روز می گذرد، کلیدها منتقل نشده اند. من تعجب می کنم که مشکل چیست، همه چیز به نظر ساده است - آن را از یک سرور خارج کنید، آن را به دیگری وصل کنید، درایور را نصب کنید و کارتان تمام شد. ادمین با سر و صدا کردن و گفتن چیزی در مورد ارسال پورت، سرور مجازی و غیره پاسخ می دهد.

هوم... سرور مجازی؟ به نظر می رسد که هرگز مجازی سازی وجود نداشته است و هرگز وجود نداشته است ... من یک مشکل نسبتاً شناخته شده را به یاد می آورم که عدم امکان ارسال کلید سرور 1C به ماشین مجازی در Hyper-V در ویندوز سرور 2008 است. و اینجا برخی از سوء ظن ها در من شکل می گیرد ...

من مدیر سرور را باز می کنم - نقش ها - یک نقش جدید ظاهر شده است - Hyper-V. من به مدیر Hyper-V می روم، یک ماشین مجازی را می بینم، وصل می شوم ... و در واقع ... سرور پایگاه داده جدید ما ...

پس چی؟ دستورات مسئولین و توصیه های من انجام شده، نقش ها تفکیک شده است. کار می تواند بسته شود.

پس از مدتی، بحران اکنون رخ داد، شعبه جدید باید بسته می شد، بار کاهش می یافت و عملکرد سیستم کم و بیش قابل تحمل شد.

خوب، البته، آنها نتوانستند کلید سرور را به ماشین مجازی فوروارد کنند. در نتیجه، همه چیز به همان شکل باقی ماند: سرور ترمینال + خوشه 1C در یک ماشین فیزیکی، سرور پایگاه داده در آنجا در یک مجازی.

و اگر این یک نوع دفتر شاراشکین بود خوب بود. پس نه. شرکتی سرشناس که احتمالا محصولاتش را می شناسید و در دپارتمان های مربوطه تمامی لنتاها و آچان ها دیده اید.

برنامه تعطیلات هارد دیسک

یک هلدینگ بزرگ با برنامه های بلندپروازانه برای تصاحب جهان، بار دیگر یک شرکت کوچک را با هدف گنجاندن آن در شرکت بزرگ خود خریداری کرد. در تمام بخش‌های این هلدینگ، کاربران در پایگاه داده‌های خود، اما با پیکربندی یکسان، کار می‌کنند. و بنابراین ما یک پروژه کوچک را برای گنجاندن یک واحد جدید در این سیستم آغاز کردیم.

اول از همه، لازم است که پایگاه های تولید و آزمایش را مستقر کنیم. توسعه دهنده داده های اتصال را دریافت کرده، وارد سرور می شود، MS SQL را نصب می کند، سرور 1C را می بیند، 2 درایو منطقی را می بیند: درایو "C" با ظرفیت 250 گیگابایت و درایو "D" با ظرفیت 1 ترابایت. خوب، "C" سیستم است، "D" برای داده است، توسعه دهنده به طور منطقی تصمیم می گیرد و همه پایگاه های داده را در آنجا مستقر می کند. من حتی برنامه‌های تعمیر و نگهداری، از جمله پشتیبان‌گیری را برای هر موردی تنظیم می‌کنم (حتی اگر ما مسئولیتی در این مورد نداریم). درست است، پشتیبان گیری در اینجا به "D" اضافه شد. در آینده، برنامه ریزی شده بود که آن را در یک منبع شبکه جداگانه پیکربندی کنید.

پروژه شروع شد، مشاوران آموزش هایی را در مورد نحوه کار در سیستم جدید ارائه کردند، باقیمانده ها منتقل شدند، برخی بهبودهای جزئی انجام شد و کاربران شروع به کار در پایگاه اطلاعاتی جدید کردند.

همه چیز خوب پیش می رفت تا اینکه یک روز دوشنبه صبح متوجه شد که دیسک پایگاه داده گم شده است. به سادگی "D" روی سرور وجود ندارد و بس.

تحقیقات بیشتر این را نشان داد: این "سرور" در واقع رایانه کاری یک مدیر سیستم محلی بود. درست است، هنوز یک سیستم عامل سرور داشت. درایو USB شخصی این مدیر به سرور وصل شد. و به این ترتیب مدیر به تعطیلات رفت و پیچ خود را با خود برد و هدفش این بود که فیلم‌ها را برای سفر به داخل آن ببرد.

خدا را شکر، او موفق به حذف فایل های پایگاه داده نشد و موفق شد پایگاه داده تولیدی را بازیابی کند.

شایان ذکر است که همه به طور کلی از عملکرد سیستم واقع در درایو USB راضی بودند. هیچ کس از عملکرد نامطلوب 1C شکایت نکرد. تنها بعداً بود که هلدینگ یک پروژه بزرگ را برای انتقال همه پایگاه‌های اطلاعاتی به یک سایت متمرکز با سرورهای فوق‌العاده، سیستم‌های ذخیره‌سازی یک میلیون روبلی، هایپروایزرهای پیچیده و ترمزهای غیرقابل تحمل 1C در همه شاخه‌ها آغاز کرد.

اما این یک داستان کاملا متفاوت است ...

منبع: www.habr.com