از برون سپاری تا توسعه (بخش اول)

سلام به همه، نام من سرگئی املیانچیک است. من رئیس شرکت Audit-Telecom، توسعه دهنده اصلی و نویسنده سیستم Veliam هستم. تصمیم گرفتم مقاله ای بنویسم که چگونه من و دوستم یک شرکت برون سپاری ایجاد کردیم، نرم افزاری برای خود نوشتیم و متعاقباً شروع به توزیع آن برای همه از طریق سیستم SaaS کردیم. در مورد اینکه من قاطعانه اعتقاد نداشتم که این امکان پذیر است. این مقاله نه تنها حاوی یک داستان، بلکه جزئیات فنی از نحوه ایجاد محصول Veliam نیز خواهد بود. از جمله برخی از قطعات کد منبع. بعداً به شما خواهم گفت که چه اشتباهاتی مرتکب شدیم و چگونه آنها را اصلاح کردیم. تردیدهایی وجود داشت که آیا چنین مقاله ای منتشر شود. اما فکر کردم بهتر است این کار را انجام دهم، بازخورد بگیرم و بهبود ببخشم تا اینکه مقاله را منتشر نکنم و به این فکر کنم که اگر چه اتفاقی می‌افتاد...

ماقبل تاریخ

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

ما نظارت داشتیم، اما صرفاً به دلیل علاقه آکادمیک می‌خواستم سعی کنم ساده‌ترین مورد خودم را بنویسم. ایده این بود: می‌خواستم روی وب باشد، تا بتوانم به راحتی بدون نصب هیچ کلاینت وارد شبکه شوم و از هر دستگاهی، از جمله یک دستگاه تلفن همراه از طریق Wi-Fi، ببینم چه اتفاقی در شبکه می‌افتد، و همچنین واقعاً می خواستم به سرعت بفهمم چه تجهیزاتی در اتاق وجود دارد که به "موپی" تبدیل شده است زیرا ... شرایط بسیار سختی برای زمان پاسخگویی به چنین مشکلاتی وجود داشت. در نتیجه، طرحی در ذهن من ایجاد شد تا یک صفحه وب ساده بنویسم که در آن یک پس‌زمینه jpeg با نمودار شبکه وجود دارد، خود دستگاه‌ها را با آدرس‌های IP آنها در این تصویر برش دهم و محتوای پویا را در بالای صفحه نمایش دهم. تصویر در مختصات مورد نیاز به صورت یک آدرس IP سبز یا قرمز چشمک زن. وظیفه تعیین شده است، بیایید شروع کنیم.

قبلا در دلفی، PHP، JS و خیلی سطحی C++ برنامه نویسی می کردم. من به خوبی می دانم که شبکه ها چگونه کار می کنند. VLAN، مسیریابی (OSPF، EIGRP، BGP)، NAT. این برای من کافی بود تا خودم یک نمونه اولیه نظارت اولیه بنویسم.

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

system(“ping -n 3 -w 100 {$ip_address}“); 

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

وقتی همه چیز درست شد، از نتیجه بسیار الهام گرفتم و فکر کردم که می توانم بیشتر به آن اضافه کنم (با توجه به دانش و توانایی هایم). اما من همیشه سیستم‌هایی با یک میلیون نمودار را دوست نداشتم، که در آن زمان فکر می‌کردم و هنوز هم فکر می‌کنم در بیشتر موارد غیرضروری هستند. من می خواستم فقط چیزی را در آنجا بگذارم که واقعاً در کارم به من کمک کند. این اصل برای توسعه ولیام تا به امروز اساسی است. علاوه بر این، متوجه شدم که اگر مجبور نباشم نظارت را باز نگه دارم و مشکلات را بدانم، و وقتی این اتفاق افتاد، صفحه را باز کنم و ببینم این گره شبکه مشکل ساز در کجا قرار دارد بسیار جالب خواهد بود و در مرحله بعد با آن چه کار کنم. . به نوعی من در آن زمان ایمیل را نخواندم، به سادگی از آن استفاده نکردم. در اینترنت متوجه شدم که درگاه های پیامکی وجود دارد که می توانید به آنها درخواست GET یا POST بفرستید و با متنی که من می نویسم به موبایل من پیامک می فرستند. بلافاصله متوجه شدم که واقعاً این را می خواهم. و شروع به مطالعه مستندات کردم. بعد از مدتی موفق شدم و اکنون پیامکی در مورد مشکلات شبکه در تلفن همراهم با نام "شیء افتاده" دریافت کردم. اگرچه این سیستم ابتدایی بود، اما توسط خودم نوشته شده بود و مهمترین چیزی که من را به توسعه آن ترغیب کرد این بود که یک برنامه کاربردی بود که واقعاً در کارم به من کمک کرد.

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

system(“tracert -d -w 500 8.8.8.8”);

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

علاوه بر این، در کارهای روزمره مجبور بودم کراس کراسینگ انجام دهم. و من از رفتن به سوییچ های سیسکو خسته شدم تا ببینم از کدام رابط استفاده کنم. چقدر جالب است که روی یک شی در نظارت کلیک کنید و لیستی از رابط های آن را با توضیحات ببینید. این باعث صرفه جویی در وقت من می شد. علاوه بر این، در این طرح نیازی به اجرای Putty یا SecureCRT برای وارد کردن حساب ها و دستورات نخواهد بود. من فقط روی مانیتورینگ کلیک کردم، دیدم چه چیزی لازم است و رفتم تا کارم را انجام دهم. من شروع به جستجوی راه هایی برای تعامل با سوئیچ ها کردم. بلافاصله با 2 گزینه روبرو شدم: SNMP یا ورود به سوئیچ از طریق SSH، وارد کردن دستورات مورد نیاز و تجزیه نتیجه. من SNMP را به دلیل پیچیدگی اجرای آن رد کردم؛ برای به دست آوردن نتیجه بی تاب بودم. با SNMP، شما باید برای مدت طولانی در MIB حفاری کنید و بر اساس این داده ها، داده هایی را در مورد اینترفیس ها تولید کنید. تیم فوق العاده ای در سیسکو وجود دارد

show interface status

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

نظارت بر کانال مبتنی بر ردیابی در نهایت بهترین ایده نبود، زیرا... گاهی اوقات کار روی شبکه انجام می شد و ردیابی ممکن بود تغییر کند و نظارت شروع به فریاد زدن بر سر من کرد که مشکلی در کانال وجود دارد. اما بعد از صرف زمان زیادی برای تحلیل، متوجه شدم که همه کانال ها کار می کنند و نظارتم مرا فریب می دهد. در نتیجه، از همکارانم که سوئیچ‌های شکل‌دهنده کانال را مدیریت می‌کردند، خواستم که وقتی وضعیت دید همسایگان تغییر کرد، به سادگی syslog را برای من ارسال کنند. بر این اساس، بسیار ساده تر، سریع تر و دقیق تر از ردیابی بود. رویدادی مانند از دست دادن همسایه فرا رسیده است و من بلافاصله یک اعلان در مورد کانال را صادر می کنم.

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

ایجاد شرکت Audit-Telecom

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

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

در نهایت، ما توانستیم گزینه ای را پیدا کنیم که برای هر دوی ما مناسب باشد و کاری را که می دانیم انجام دهیم. در سال 2016 تصمیم گرفتیم یک شرکت فناوری اطلاعات ایجاد کنیم که به کسب و کارها در حل مشکلات فناوری اطلاعات کمک کند. این استقرار سیستم های فناوری اطلاعات (1C، سرور ترمینال، سرور پست و غیره)، نگهداری آنها، HelpDesk کلاسیک برای کاربران و مدیریت شبکه است.

صادقانه بگویم، در زمان ایجاد شرکت، من 99,9٪ به آن اعتقاد نداشتم. اما پاول به نحوی توانست من را به تلاش وادار کند و با نگاه کردن به آینده، معلوم شد که حق با اوست. من و پاول هر کدام 300 روبل تراشه کردیم، یک LLC جدید "Audit-Telecom" ثبت کردیم، یک دفتر کوچک اجاره کردیم، کارت های ویزیت جالب درست کردیم، خوب، به طور کلی، احتمالاً مانند اکثر تاجران بی تجربه و تازه کار، و شروع به جستجوی مشتریان کردیم. یافتن مشتری داستان کاملا متفاوتی است. شاید اگر کسی علاقه مند باشد، یک مقاله جداگانه به عنوان بخشی از وبلاگ شرکتی بنویسیم. تماس های سرد، آگهی ها و غیره این هیچ نتیجه ای نداشت. همانطور که اکنون از بسیاری از داستان‌های مربوط به تجارت می‌خوانم، به هر طریقی، خیلی به شانس بستگی دارد. ما خوش شانس بودیم. و به معنای واقعی کلمه چند هفته پس از ایجاد شرکت ، برادرم ولادیمیر به ما نزدیک شد که اولین مشتری را برای ما آورد. من شما را با جزئیات کار با مشتریان خسته نمی کنم، این چیزی نیست که مقاله در مورد آن است، فقط می گویم که ما برای ممیزی رفتیم، مناطق بحرانی را شناسایی کردیم و این مناطق خراب شد در حالی که تصمیم گیری در مورد اینکه آیا باید انجام شود یا خیر. به عنوان برون سپاری به صورت مستمر با ما همکاری کنید. پس از این، بلافاصله تصمیم مثبت گرفته شد.

سپس، عمدتاً از طریق دهان به دهان از طریق دوستان، سایر شرکت های خدماتی شروع به ظهور کردند. Helpdesk در یک سیستم بود. اتصالات به تجهیزات شبکه و سرورها متفاوت یا بهتر است بگوییم متفاوت است. برخی از افراد میانبرها را ذخیره کردند، برخی دیگر از دفترچه آدرس RDP استفاده کردند. مانیتورینگ یک سیستم جداگانه دیگر است. برای یک تیم کار در سیستم های متفاوت بسیار ناخوشایند است. اطلاعات مهم از بین می رود. خوب، برای مثال، سرور ترمینال مشتری در دسترس نیست. درخواست های کاربران این مشتری بلافاصله دریافت می شود. متخصص پشتیبانی درخواستی را باز می کند (از طریق تلفن دریافت شد). اگر اتفاقات و درخواست‌ها در یک سیستم ثبت می‌شد، متخصص پشتیبانی فوراً مشکل کاربر را می‌بیند و در مورد آن به او می‌گوید و همزمان به شی مورد نیاز برای بررسی وضعیت متصل می‌شد. همه از وضعیت تاکتیکی آگاه هستند و هماهنگ کار می کنند. ما سیستمی پیدا نکردیم که همه اینها با هم ترکیب شوند. مشخص شد که زمان آن رسیده که محصول خودمان را بسازیم.

کار بر روی سیستم مانیتورینگ خود را ادامه دهید

واضح بود که سیستمی که قبلا نوشته شده بود برای کارهای فعلی کاملاً نامناسب است. نه از نظر کارایی و نه از نظر کیفیت. و تصمیم گرفته شد که سیستم را از ابتدا بنویسیم. از نظر گرافیکی باید کاملاً متفاوت به نظر می رسید. این باید یک سیستم سلسله مراتبی باشد تا بتوان به سرعت و به راحتی شی مناسب را برای مشتری مناسب باز کرد. این طرح مانند نسخه اول در مورد فعلی کاملاً توجیه نشده بود، زیرا مشتریان متفاوت هستند و اصلاً مهم نبود که تجهیزات در کدام محل قرار دارد. این قبلاً به اسناد منتقل شده است.

بنابراین وظایف عبارتند از:

1. ساختار سلسله مراتبی؛
2. نوعی قسمت سرور که می تواند به صورت ماشین مجازی در محل مشتری قرار گیرد تا معیارهای مورد نیاز ما را جمع آوری کند و به سرور مرکزی ارسال کند که همه اینها را خلاصه می کند و به ما نشان می دهد.
3. هشدارها آنهایی که نمی توان از دست داد، زیرا ... در آن زمان امکان نداشت کسی بنشیند و فقط به مانیتور نگاه کند.
4. سیستم برنامه. مشتریانی ظاهر شدند که ما نه تنها تجهیزات سرور و شبکه، بلکه ایستگاه های کاری را نیز برای آنها سرویس می کردیم.
5. امکان اتصال سریع به سرورها و تجهیزات از سیستم.

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

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

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

نتایج اغلب نادرست بودند و تکمیل اسکن ها زمان زیادی می برد. من به طور کامل پینگ را فراموش کردم، از طریق fping انجام شد:

system("fping -r 3 -t 100 {$this->ip}");

این نیز موازی نبود و بنابراین روند بسیار طولانی بود. بعداً، کل لیست آدرس های IP مورد نیاز برای تأیید به یکباره به fping ارسال شد و ما یک لیست آماده از کسانی که پاسخ دادند دریافت کردیم. برخلاف ما، fping قادر به موازی سازی فرآیندها بود.

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

نحوه کار لینک های منبع در Veliam

اتصالات از راه دور

این چیزی است که در عمل در نسخه فعلی Veliam به نظر می رسد

یکی از کارها اتصال سریع و راحت به سرورهایی بود که قبلاً تعداد زیادی از آنها (بیش از صدها) وجود داشت و مرتب کردن میلیون ها میانبر RDP از پیش ذخیره شده بسیار ناخوشایند بود. ابزار لازم بود. نرم افزاری در اینترنت وجود دارد که چیزی شبیه به دفترچه آدرس برای چنین اتصالات RDP است، اما آنها با سیستم مانیتورینگ یکپارچه نیستند و حساب ها را نمی توان ذخیره کرد. هر بار وارد کردن حساب‌ها برای کلاینت‌های مختلف، وقتی ده‌ها بار در روز به سرورهای مختلف متصل می‌شوید، جهنم محض است. با SSH، اوضاع کمی بهتر است؛ نرم افزارهای خوب زیادی وجود دارد که به شما امکان می دهد چنین اتصالاتی را در پوشه ها سازماندهی کنید و حساب ها را از آنها به خاطر بسپارید. اما 2 مشکل وجود دارد. اولین مورد این است که ما یک برنامه واحد برای اتصالات RDP و SSH پیدا نکردیم. مورد دوم این است که اگر در مقطعی در رایانه خود نباشم و نیاز به اتصال سریع داشته باشم یا فقط سیستم را مجدداً نصب کردم، باید به مستندات بروم تا حساب این مشتری را بررسی کنم. ناخوشایند و اتلاف وقت است.

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

با در نظر گرفتن این واقعیت که مشتری در سیستم ما یک مرورگر بود که به منابع محلی رایانه دسترسی ندارد، برای اینکه به سادگی برنامه مورد نیاز خود را با دستوری راه اندازی کنیم، اختراع شد که همه چیز را از طریق "ویندوز" انجام دهد. طرح url سفارشی». اینگونه است که یک "پلاگین" خاص برای سیستم ما ظاهر شد که به سادگی شامل Putty و Remote Desktop Plus بود و در حین نصب، به سادگی طرح URI را در ویندوز ثبت کرد. حالا وقتی می‌خواستیم از طریق RDP یا SSH به یک شی متصل شویم، روی سیستم خود روی این عمل کلیک کردیم و Custom URI کار کرد. mstsc.exe استاندارد ساخته شده در ویندوز یا بتونه، که بخشی از "افزونه" بود، راه اندازی شد. من کلمه افزونه را در نقل قول قرار دادم زیرا این یک افزونه مرورگر به معنای کلاسیک نیست.

حداقل این چیزی بود. دفترچه آدرس مناسب علاوه بر این، در مورد Putty، همه چیز به طور کلی خوب بود؛ می توان به آن اتصالات IP، ورود به سیستم و رمز عبور را به عنوان پارامترهای ورودی داد. آن ها ما قبلاً با یک کلیک بدون وارد کردن رمز عبور به سرورهای لینوکس در شبکه خود متصل شده ایم. اما با RDP به این سادگی نیست. mstsc استاندارد نمی تواند اعتبارنامه ها را به عنوان پارامتر ارائه کند. Remote Desktop Plus به کمک آمد. او اجازه داد که این اتفاق بیفتد. اکنون می توانیم بدون آن کار کنیم، اما برای مدت طولانی این یک دستیار وفادار در سیستم ما بود. با سایت های HTTP(S) همه چیز ساده است، چنین اشیایی به سادگی در مرورگر باز می شوند و بس. راحت و کاربردی. اما این خوشحالی فقط در شبکه داخلی بود.

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

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

این ایده به وجود آمد تا مطمئن شوم که وقتی روی شی مورد نیاز خود در سیستم کلیک می کنم، سرور مانیتورینگ مرکزی با دانستن حساب های SSH همه مشتریان Mikrotik، به مورد مورد نظر متصل می شود و یک قانون فوروارد به هاست مورد نظر ایجاد می کند. پورت مورد نیاز در اینجا چند نکته وجود دارد. راه حل جهانی نیست - فقط برای Mikrotik کار می کند، زیرا دستور دستور برای همه روترها متفاوت است. همچنین، پس از آن، چنین ارسال‌هایی باید به نحوی حذف می‌شد و بخش سرور سیستم ما اساساً نمی‌توانست به هیچ وجه پیگیری کند که آیا جلسه RDP خود را تمام کرده بودم یا خیر. خوب، چنین ارسال یک سوراخ برای مشتری است. اما ما جهانی را دنبال نکردیم، زیرا ... این محصول فقط در داخل شرکت ما مورد استفاده قرار گرفت و هیچ فکری برای انتشار آن برای عموم وجود نداشت.

هر کدام از مشکلات به روش خود حل شد. هنگامی که قانون ایجاد شد، این ارسال فقط برای یک آدرس IP خارجی خاص (که از آن اتصال اولیه شد) در دسترس بود. بنابراین از یک حفره امنیتی جلوگیری شد. اما با هر یک از این اتصالات، یک قانون Mikrotik به صفحه NAT اضافه شد و پاک نشد. و همه می دانند که هرچه قوانین بیشتری وجود داشته باشد، پردازنده روتر بیشتر بارگذاری می شود. و در کل نمیتونستم قبول کنم که یه روز برم یه میکروتیک و صدها قانون مرده و بیهوده وجود داشته باشه.

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

اتفاقاً اینجاست:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

مطمئناً می شد زیباتر، سریعتر و غیره ساخت، اما کار کرد، میکروتیک را لود نکرد و عالی کار کرد. در نهایت توانستیم تنها با یک کلیک به سرورها و تجهیزات شبکه مشتریان متصل شویم. بدون باز کردن VPN یا وارد کردن رمز عبور. کار کردن با این سیستم واقعاً راحت شده است. زمان سرویس کاهش یافت و همه ما به جای اتصال به اشیاء ضروری، زمان خود را صرف کار کردیم.

پشتیبان گیری میکروتیک

ما پشتیبان گیری از همه Mikrotik را به FTP پیکربندی کردیم. و در کل همه چیز خوب بود. اما زمانی که نیاز به تهیه نسخه پشتیبان داشتید، باید این FTP را باز کرده و در آنجا جستجو می‌کردید. ما سیستمی داریم که در آن همه روترها متصل هستند؛ می توانیم از طریق SSH با دستگاه ها ارتباط برقرار کنیم. فکر کردم چرا ما آن را طوری نمی کنیم که خود سیستم روزانه از همه میکروتیک بک آپ بگیرد. و شروع به اجرای آن کرد. ما متصل شدیم، یک نسخه پشتیبان تهیه کردیم و آن را به ذخیره سازی بردیم.

کد اسکریپت در PHP برای تهیه نسخه پشتیبان از میکروتیک:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

پشتیبان گیری به دو صورت - باینری و پیکربندی متنی گرفته می شود. باینری به بازیابی سریع پیکربندی مورد نیاز کمک می کند، و متن یک به شما امکان می دهد بفهمید در صورت تعویض اجباری تجهیزات و آپلود باینری در آن، چه کاری باید انجام شود. در نتیجه، یک قابلیت راحت دیگر در سیستم به دست آوردیم. علاوه بر این، هنگام اضافه کردن Mikrotik جدید، نیازی به پیکربندی چیزی نبود، من به سادگی شی را به سیستم اضافه کردم و از طریق SSH برای آن یک حساب تنظیم کردم. سپس خود سیستم به تهیه نسخه پشتیبان پرداخت. نسخه فعلی SaaS Veliam هنوز این قابلیت را ندارد، اما به زودی آن را پورت خواهیم کرد.

تصاویری از ظاهر آن در سیستم داخلی

انتقال به ذخیره سازی پایگاه داده عادی

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

Helpdesk - HelpDesk

بد نیست به نحوه تشکیل HelpDesk اشاره کنیم. این داستان کاملاً متفاوت است، زیرا ... در Veliam این سومین نسخه کاملاً جدید است که با تمام نسخه های قبلی متفاوت است. اکنون این یک سیستم ساده، شهودی و بدون زنگ و سوت غیر ضروری، با قابلیت ادغام با یک دامنه، و همچنین امکان دسترسی به نمایه کاربری یکسان از هر کجا با استفاده از پیوند از یک ایمیل است. و مهمتر از همه، اتصال به متقاضی از طریق VNC از هر نقطه (در خانه یا دفتر) به طور مستقیم از برنامه بدون VPN یا پورت فوروارد امکان پذیر است. من به شما خواهم گفت که چگونه به این موضوع رسیدیم، قبلاً چه اتفاقی افتاد و چه تصمیمات وحشتناکی گرفته شد.

ما از طریق TeamViewer معروف به کاربران متصل شدیم. همه رایانه‌هایی که به کاربرانشان سرویس می‌دهیم تلویزیون نصب کرده‌اند. اولین کاری که ما اشتباه کردیم و متعاقباً آن را حذف کردیم، پیوند دادن هر کلاینت HD به سخت افزار بود. چگونه کاربر برای گذاشتن درخواست وارد سیستم HD شد؟ علاوه بر تلویزیون، همه یک ابزار ویژه روی رایانه‌هایشان نصب کرده بودند که به زبان Lazarus نوشته شده بود (بسیاری از مردم اینجا چشمانشان را می‌چرخانند، و شاید حتی به گوگل سر بزنند که چیست، اما بهترین زبان کامپایل شده ای که من می‌شناختم دلفی بود، و Lazarus تقریباً است. همان چیز، فقط رایگان). به طور کلی، کاربر یک فایل دسته ای ویژه راه اندازی کرد که این ابزار را راه اندازی کرد، که به نوبه خود HWID سیستم را خواند و پس از آن مرورگر راه اندازی شد و مجوز انجام شد. چرا این کار انجام شد؟ در برخی از شرکت ها تعداد کاربران سرویس دهی شده به صورت جداگانه محاسبه می شود و قیمت خدمات برای هر ماه بر اساس تعداد افراد محاسبه می شود. شما می گویید این قابل درک است، اما چرا به سخت افزار گره خورده است؟ خیلی ساده است، برخی از افراد به خانه آمدند و از لپ تاپ خانه خود درخواستی به سبک "همه چیز را برای من زیبا کن" ارائه کردند. این ابزار علاوه بر خواندن سیستم HWID، شناسه Teamviewer فعلی را از رجیستری بیرون کشید و به ما نیز منتقل کرد. Teamviewer یک API برای ادغام دارد. و ما این ادغام را انجام دادیم. اما یک شکار وجود داشت. از طریق این APIها، اتصال به رایانه کاربر زمانی که وی به صراحت این جلسه را شروع نمی کند غیرممکن است و پس از تلاش برای اتصال به آن، باید روی «تأیید» نیز کلیک کند. در آن زمان برای ما منطقی به نظر می رسید که هیچ کس نباید بدون درخواست کاربر وصل شود و از آنجایی که شخص در رایانه است، جلسه را آغاز می کند و به درخواست اتصال از راه دور پاسخ مثبت می دهد. همه چیز اشتباه شد. متقاضیان فراموش کرده بودند که شروع جلسه را فشار دهند و مجبور شدند این را در یک مکالمه تلفنی به آنها بگویند. این زمان تلف شد و در هر دو طرف این روند ناامیدکننده بود. علاوه بر این، برای چنین لحظاتی که یک شخص درخواستی را ترک می کند، اصلا غیر معمول نیست، اما فقط زمانی که برای ناهار ترک می کند مجاز به اتصال است. چون مشکل بحرانی نیست و نمی خواهد روند کارش قطع شود. بر این اساس، او هیچ دکمه ای را برای اجازه اتصال فشار نخواهد داد. به این ترتیب عملکردهای اضافی هنگام ورود به HelpDesk ظاهر شد - خواندن شناسه Teamviwer. ما رمز عبور دائمی که هنگام نصب Teamviwer استفاده می شد را می دانستیم. به طور دقیق تر، فقط سیستم آن را می دانست، زیرا در نصب کننده و در سیستم ما ساخته شده بود. بر این اساس، یک دکمه اتصال از برنامه با کلیک روی آن وجود داشت که نیازی به انتظار نبود، اما بلافاصله Teamviewer باز شد و اتصال رخ داد. در نتیجه، دو نوع اتصال ممکن وجود داشت. از طریق API رسمی Teamviewer و API خودساخته ما. در کمال تعجب ، آنها تقریباً بلافاصله استفاده از اولین را متوقف کردند ، اگرچه دستورالعمل استفاده از آن فقط در موارد خاص و زمانی که خود کاربر مجوز می دهد وجود داشت. با این حال، اکنون به من امنیت بدهید. اما معلوم شد که متقاضیان به این نیاز ندارند. همه آنها با اتصال به آنها بدون دکمه تأیید کاملاً خوب هستند.

تغییر به multithreading در لینوکس

مسئله سرعت بخشیدن به عبور یک اسکنر شبکه برای باز بودن لیست از پیش تعیین شده پورت ها و پینگ ساده اشیاء شبکه مدت هاست که مطرح شده است. در اینجا، البته، اولین راه حلی که به ذهن می رسد، چند رشته ای است. از آنجایی که زمان اصلی صرف شده در پینگ در انتظار بازگشت بسته است، و پینگ بعدی نمی تواند تا زمانی که بسته قبلی بازگردانده شود شروع شود، در شرکت هایی که حتی 20+ سرور به اضافه تجهیزات شبکه داشتند، این قبلاً بسیار کند کار می کرد. نکته این است که یک بسته ممکن است ناپدید شود، اما بلافاصله به مدیر سیستم در مورد آن اطلاع ندهید. او به سادگی پذیرش چنین هرزنامه ها را خیلی سریع متوقف می کند. این بدان معنی است که قبل از نتیجه گیری در مورد عدم دسترسی، باید هر شی را بیش از یک بار پینگ کنید. بدون پرداختن به جزئیات زیاد، لازم است آن را موازی سازی کنید زیرا اگر این کار انجام نشود، به احتمال زیاد مدیر سیستم در مورد مشکل از مشتری و نه از سیستم نظارت مطلع خواهد شد.

خود PHP از multithreading خارج از جعبه پشتیبانی نمی کند. با قابلیت چند پردازش، می توانید فورک کنید. اما، در واقع، من قبلاً یک مکانیسم نظرسنجی نوشته شده بود و می خواستم آن را طوری بسازم که یک بار تمام گره های مورد نیاز خود را از پایگاه داده بشمارم، همه چیز را یکباره پینگ کنم، منتظر پاسخ از هر یک باشم و فقط پس از آن بلافاصله بنویسم. داده. این باعث صرفه جویی در تعداد درخواست های خواندن می شود. Multithreading کاملاً با این ایده مطابقت دارد. برای PHP یک ماژول PThreads وجود دارد که به شما امکان می دهد چند رشته ای واقعی را انجام دهید، اگرچه برای تنظیم آن روی PHP 7.2 مقدار زیادی سرهم بندی لازم بود، اما این کار انجام شد. اسکن پورت و پینگ اکنون سریع است. و به جای اینکه مثلاً 15 ثانیه در هر دور زودتر انجام شود، این روند 2 ثانیه به طول انجامید. نتیجه خوبی بود.

ممیزی سریع شرکت های جدید

عملکرد جمع آوری معیارهای مختلف و ویژگی های سخت افزاری چگونه به وجود آمد؟ ساده است. گاهی اوقات به ما دستور می دهند زیرساخت فعلی فناوری اطلاعات را ممیزی کنیم. خوب، برای سرعت بخشیدن به حسابرسی مشتری جدید، همین مورد ضروری است. ما به چیزی نیاز داشتیم که به ما اجازه دهد به یک شرکت متوسط ​​یا بزرگ بیاییم و به سرعت بفهمیم آنها چه دارند. به نظر من پینگ در شبکه داخلی فقط توسط کسانی که می خواهند زندگی خود را پیچیده کنند مسدود می شود و طبق تجربه ما تعداد کمی از آنها وجود دارد. اما چنین افرادی نیز وجود دارند. بر این اساس، با یک پینگ ساده می توانید به سرعت شبکه ها را برای وجود دستگاه ها اسکن کنید. سپس می‌توانیم آن‌ها را اضافه کنیم و پورت‌های باز مورد علاقه‌مان را اسکن کنیم. در واقع، این قابلیت از قبل وجود داشت؛ فقط لازم بود دستوری از سرور مرکزی به سرور برده اضافه شود تا شبکه های مشخص شده را اسکن کند و هر چیزی را که پیدا کرده است به لیست اضافه کند. فراموش کردم ذکر کنم، فرض بر این بود که ما قبلاً یک تصویر آماده با یک سیستم پیکربندی شده (سرور نظارت بر برده) داشتیم که می توانستیم به سادگی آن را در حین ممیزی از مشتری بیرون بیاوریم و آن را به ابر خود وصل کنیم.

اما نتیجه ممیزی معمولاً شامل مجموعه ای از اطلاعات مختلف است و یکی از آنها این است که چه نوع دستگاه هایی در شبکه هستند. اول از همه، ما به سرورهای ویندوز و ایستگاه های کاری ویندوز به عنوان بخشی از یک دامنه علاقه مند بودیم. از آنجایی که در شرکت های متوسط ​​و بزرگ عدم ​​وجود دامنه احتمالاً از این قاعده مستثنی است. برای صحبت کردن به یک زبان، میانگین، به نظر من، 100+ نفر است. لازم بود راهی برای جمع‌آوری داده‌ها از تمام ماشین‌ها و سرورهای ویندوز با دانستن IP و حساب سرپرست دامنه آنها، اما بدون نصب نرم‌افزار روی هر یک از آنها ارائه شود. رابط WMI به کمک می آید. Windows Management Instrumentation (WMI) در لغت به معنای ابزارهای مدیریت ویندوز است. WMI یکی از فناوری های اساسی برای مدیریت متمرکز و نظارت بر عملکرد بخش های مختلف زیرساخت رایانه ای است که بر روی پلت فرم ویندوز اجرا می شود. برگرفته از ویکی بعد، من مجبور شدم دوباره برای کامپایل wmic (این یک سرویس گیرنده WMI) برای Debian کار کنم. پس از آماده شدن همه چیز، تنها چیزی که باقی می ماند این بود که به سادگی گره های لازم را از طریق wmic برای اطلاعات لازم نظرسنجی کنید. از طریق WMI می توانید تقریباً هر اطلاعاتی را از رایانه ویندوزی دریافت کنید و علاوه بر این، می توانید رایانه را از طریق آن نیز کنترل کنید، مثلاً آن را برای راه اندازی مجدد ارسال کنید. به این ترتیب مجموعه اطلاعات مربوط به ایستگاه ها و سرورهای ویندوز در سیستم ما ظاهر شد. علاوه بر این، اطلاعات فعلی در مورد نشانگرهای بار فعلی سیستم وجود داشت. ما اغلب آنها را درخواست می کنیم، و اطلاعات مربوط به سخت افزار را کمتر. پس از این، ممیزی کمی لذت بخش تر شد.

تصمیم توزیع نرم افزار

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

بروزرسانی

قسمت دوم

منبع: www.habr.com