4 مهندس، 7000 سرور و یک بیماری همه گیر جهانی

هی هابر! ترجمه مقاله را مورد توجه شما قرار می دهم "4 مهندس، 7000 سرور، و یک بیماری همه گیر جهانی" توسط ادیب داو.

اگر این تیتر باعث ایجاد لرز در ستون فقرات شما نمی شود، باید به پاراگراف بعدی بروید یا از صفحه ما که به شغل در شرکت - دوست داریم با هم صحبت کنیم.

چه کسی هستیم

ما تیمی متشکل از 4 پنگوئن هستیم که عاشق نوشتن کد و کار با سخت افزار هستیم. در اوقات فراغت خود، ما مسئول استقرار، نگهداری و راه اندازی ناوگانی از بیش از 7000 سرور فیزیکی با لینوکس هستیم که در 3 مرکز داده مختلف در سراسر ایالات متحده توزیع شده است.

ما همچنین این فرصت را داشتیم که این کار را در فاصله 10 کیلومتری از سایت‌ها، از راحتی دفتر خودمان، که در فاصله کوتاهی از ساحل در دریای مدیترانه قرار دارد، انجام دهیم.

مسائل مربوط به مقیاس

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

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

بر دامنه های خود مسلط شوید

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

اتخاذ این رویکرد به ما اجازه داد تا بسیاری از مشکلات را به درستی حل کنیم - با ایجاد ابزار و اتوماسیون.

نیاز به دامنه

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

• امکان سفارشی سازی نمای تنها فیلدهای مرتبط (ساده)
• APIهای باز (قابل توسعه)
• برای تیم ما شناخته شده است (فهمیده است)
• ادغام با گردش کار موجود ما (یکپارچه)

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

تابلوی کانبان در جیرا

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

دامنه چرخه عمر تجهیزات

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

• مدیریت ارتباطات با پرسنل میدانی، تجمیع کلیه اطلاعات؛
• به روز رسانی داده های "انبار" پس از هر کار تعمیر و نگهداری تجهیزات تکمیل شده و تایید شده.

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

تابلو کنترل تجهیزات انبار در گرافانا

برای دستگاه های سروری که تحت گارانتی هستند، از ابزار دیگری به نام Dispatcher استفاده می کنیم. او:

• گزارش های سیستم را جمع آوری می کند.
• گزارش هایی را در قالب مورد نیاز فروشنده ایجاد می کند.
• درخواستی از فروشنده از طریق API ایجاد می کند.
• شناسه برنامه را برای پیگیری بیشتر پیشرفت آن دریافت و ذخیره می کند.

هنگامی که ادعای ما پذیرفته شد (معمولاً در ساعات کاری)، قطعه یدکی به مرکز داده مناسب ارسال می شود و توسط کارکنان پذیرفته می شود.

خروجی کنسول جنکینز

دامنه ارتباطی

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

استفاده از یک رویکرد جدید همچنین نیازمند ابزارهای جدیدی بود که امکان تعامل راحت تر با پرسنل مرکز داده را فراهم می کرد. این ابزارها مورد نیاز بودند:

• سادگی؛
• خودمختاری؛
• بهره وری؛
• قابلیت اطمینان.

ما مجبور بودیم خود را از زنجیره کنار بگذاریم و کار را طوری ساختار دهیم که تکنسین ها بتوانند مستقیماً با تجهیزات سرور کار کنند. بدون دخالت ما و بدون اینکه به طور منظم همه این مسائل را در مورد حجم کاری، ساعات کاری، در دسترس بودن تجهیزات و غیره مطرح کنیم.

برای دستیابی به این هدف، ما iPads را در هر مرکز داده نصب کردیم. پس از اتصال به سرور، موارد زیر رخ می دهد:

• دستگاه تأیید می کند که این سرور واقعاً به کار نیاز دارد.
• برنامه های در حال اجرا بر روی سرور بسته می شوند (در صورت لزوم).
• مجموعه ای از دستورالعمل های کاری در کانال Slack ارسال شده است که مراحل مورد نیاز را توضیح می دهد.
• پس از اتمام کار، دستگاه صحت وضعیت نهایی سرور را بررسی می کند.
• در صورت لزوم برنامه ها را مجدداً راه اندازی می کند.

علاوه بر این، یک ربات Slack نیز برای کمک به تکنسین آماده کردیم. به لطف طیف گسترده ای از قابلیت ها (ما دائماً در حال گسترش عملکرد بودیم)، ربات کار آنها را آسان تر کرد و زندگی ما را بسیار آسان کرد. به این ترتیب ما بیشتر فرآیند تغییر کاربری و نگهداری سرورها را بهینه کردیم و خود را از گردش کار حذف کردیم.

iPad در یکی از مراکز داده ما

دامنه سخت افزاری

مقیاس پذیری قابل اعتماد زیرساخت مرکز داده ما نیاز به دید خوب در هر مؤلفه دارد، به عنوان مثال:

• تشخیص خرابی سخت افزار
• وضعیت سرور (فعال، میزبان، زامبی، و غیره)
• مصرف برق
• نسخه سیستم عامل
• تجزیه و تحلیل برای کل این تجارت

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

داشبورد انرژی در گرافانا

و سپس COVID-19 ظاهر شد ...

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

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

اما، همانطور که گفتیم، مدل ما قبلاً چنین فرض می کند:

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

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

به طور خلاصه می خواهم بگویم که رویکرد ما به کار در صنعت مرکز داده ثابت می کند که می توان اصول طراحی کد خوب را در مدیریت فیزیکی یک مرکز داده اعمال کرد. و شاید برای شما جالب باشد.

اصلی: tyts

منبع: www.habr.com