ما اخیراً پروژه کوچکی را برای پاکسازی نحوه ارتباط بخش‌هایی از سیستم‌هایمان در پشت صحنه در Buffer آغاز کرده‌ایم. برخی زمینه‌های سریع: ما از چیزی به نام SQS (سرویس صف ساده آمازون) استفاده می‌کنیم. این صف‌ها مانند اتاق‌های انتظار برای انجام وظایف عمل می‌کنند. یک قسمت از سیستم ما پیامی را ارسال می‌کند، و دیگری بعداً آن را دریافت می‌کند. فکر کنید مانند گذاشتن یادداشت برای یک همکار، زمانی که این داده‌ها را دریافت نمی‌کنید. نیازی نیست برای پاسخ منتظر بمانیم. پروژه ما انجام تعمیرات معمولی بود: ابزارهایی را که برای آزمایش صف‌ها به صورت محلی استفاده می‌کنیم و پیکربندی آن‌ها را تمیز می‌کنیم. اما در حالی که در حال نقشه‌برداری از صف‌هایی بودیم که واقعاً استفاده می‌کنیم، چیزی را پیدا کردیم که انتظارش را نداشتیم: هفت فرآیند مختلف پس‌زمینه (یا کار cron، که وظایف برنامه‌ریزی‌شده‌ای هستند که به طور خودکار برای پنج سال اجرا نمی‌شوند). مفید است. این است که چرا این مهم است، چگونه آنها را پیدا کردیم، و چه کاری انجام دادیم. من معتقدم که هزینه مالی در واقع کوچکترین بخش مشکل است. گاهی اوقات نیاز به به‌روزرسانی‌های امنیتی، اصلاحات سازگاری دارد، این امر منجر به صرف چرخه‌های تعمیر و نگهداری در مسیرهای کد می‌شود. به طور طبیعی در هر سیستمی با عمر طولانی اتفاق می افتد. یک ویژگی منسوخ می شود، اما کار پس زمینه ای که از آن پشتیبانی می کند، همچنان در حال اجرا است کل پایگاه داده برای روزهای تولد مطابق با تاریخ فعلی است و در طول یک Refactor در سال 2020، ما ابزار ایمیل تراکنشی خود را تغییر دادیم - این کارگر به مدت پنج سال دیگر به کار خود ادامه داد. جنبش (رویکردی محبوب که در آن شرکت‌ها کد خود را به بسیاری از سرویس‌های کوچک و مستقل تقسیم کردند) سال‌ها پیش. ما یکپارچه خود را به سرویس‌های جداگانه تقسیم کردیم که هر کدام دارای مخزن، خط لوله استقرار و زیرساخت خاص خود بود در یک مخزن چند سرویسی ادغام شده است. این سرویس ها هنوز به عنوان مرزهای منطقی وجود دارند. مشخص شد که این امر کشف را ممکن کرده است. در یک مخزن، می‌توانستیم تصویر کامل را ببینیم. ما می‌توانستیم صف‌هایی را با تولیدکنندگان پیدا کنیم، اما نتوانستیم به صف‌هایی اشاره کنیم.این کشف تقریباً اجتناب ناپذیر است. ما واقعاً چه کاری انجام دادیم هنگامی که فرآیندهای یتیم را شناسایی کردیم، باید تصمیم می گرفتیم که با آنها چه کنیم. در اینجا نحوه برخورد ما با آن آمده است. ابتدا، منشا هر کدام را دنبال کردیم. ما تاریخچه git و اسناد قدیمی را بررسی کردیم تا بفهمیم چرا هر کارگر در وهله اول ایجاد شده است. در بیشتر موارد، هدف اولیه واضح بود: انتقال داده‌ها یک‌باره، ویژگی‌ای که غروب می‌کرد، یک راه‌حل موقت که بیشتر از فایده‌اش بود. سپس تأیید کردیم که واقعاً استفاده نشده‌اند. قبل از حذف هر چیزی، ما ورود به سیستم را اضافه کردیم تا تأیید کنیم که این فرآیندها بی سر و صدا کار مهمی را که ما از دست داده بودیم انجام نمی دهند. چند روزی تحت نظر بودیم تا مطمئن شویم که اصلاً تماس نگرفته اند و آنها را به تدریج حذف کردیم. ما همه چیز را به یکباره حذف نکردیم. ما فرآیندها را یکی یکی حذف کردیم و مراقب عوارض جانبی غیرمنتظره بودیم. (خوشبختانه هیچ کدام وجود نداشت.) در نهایت، آنچه را که یاد گرفتیم مستند کردیم. ما یادداشت‌هایی را به اسناد داخلی خود درباره کارهایی که هر فرآیند در ابتدا انجام داده و دلیل حذف آن اضافه کرده‌ایم، بنابراین مهندسان آینده تعجب نکنند که آیا چیزی مهم از بین رفته است یا خیر. چه چیزی پس از پاکسازی تغییر کرده است. وقتی کسی می پرسد چه کارگرانی را اداره می کنیم؟ ما واقعاً می‌توانیم با اطمینان به این سؤال پاسخ دهیم. مکالمات داخلی نیز ساده‌تر شده‌اند. مهندسان جدید با فرآیندهای مرموز برخورد نمی کنند و نمی اندیشند که آیا زمینه را از دست داده اند یا خیر. پایگاه کد منعکس کننده کارهایی است که ما در واقع انجام می دهیم، نه کارهایی که پنج سال پیش انجام دادیم. با بازسازها به عنوان باستان شناسی و پیشگیری رفتار کنید. بزرگترین دستاورد من از این پروژه: هر احیاگر مهم فرصتی برای باستان شناسی است. هنگامی که شما عمیقاً در یک سیستم هستید، واقعاً درک می کنید که قطعات چگونه به هم متصل می شوند، در موقعیتی عالی قرار می گیرید که در مورد آنچه هنوز نیاز است سؤال کنید. آن صف از یک پروژه قدیمی؟ کارگری که کسی برای یک بار انتقال داده ایجاد کرده است؟ کار برنامه ریزی شده ای که به ویژگی ای اشاره می کند که هرگز درباره آن نشنیده اید؟ آنها ممکن است هنوز در حال اجرا باشند. این چیزی است که ما در روند آینده خود در حال ایجاد آن هستیم: در طول هر بازآفرینی، بپرسید: چه چیز دیگری این سیستم را لمس می کند که مدتی است به آن نگاه نکرده ایم؟ هنگام منسوخ کردن یک ویژگی، آن را تا انتها در فرآیندهای پس زمینه آن دنبال کنید، نه فقط کدهای روبروی کاربر. هنگامی که فردی تیم را ترک می کند، مواردی را که آنها در پس زمینه کدهای قدیمی ما مسئول هستند، مستند کنید. که هنوز به مخزن واحد منتقل نشده اند. همانطور که به تحکیم ادامه می دهیم، مطمئن هستیم که تعداد بیشتری از این آثار پنهان را پیدا خواهیم کرد. اما اکنون ما برای دستگیری آنها و جلوگیری از تشکیل کدهای جدید تنظیم شده‌ایم. وقتی همه کدهای شما در یک مکان زندگی می‌کنند، زیرساخت‌های یتیم جایی برای پنهان کردن ندارند.

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free