خدمات قدیمی در زیرساخت شما

سلام! نام من پاشا چرنیاک است، من یک توسعه دهنده پیشرو در QIWI هستم و امروز می خواهم در مورد چیزهای اجتناب ناپذیر صحبت کنم. درباره Legacy

بیایید با این سوال شروع کنیم: سرویس Legacy چیست؟ آیا یک سرویس قدیمی سرویسی است که توسعه دهنده یک هفته/ماه/سال به آن دست نزده است؟ یا سرویسی است که توسط یک برنامه نویس کم تجربه مثلاً توسط شما نوشته شده است اما یک سال پیش؟ و اکنون شما باحال تر و با تجربه تر هستید. یا سرویس Legacy سرویسی است که تصمیم گرفته اید دیگر هرگز آن را انجام ندهید و به آرامی جایگزینی برای آن آماده می کنید؟ در هر صورت رها کردن چنین سرویسی و به روز نشدن آن بمب ساعتی است که ممکن است بعداً منفجر شود.

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

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

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

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

با گذشت زمان، روش‌های جدیدی شروع به اعمال کردند، به عنوان مثال، مهاجرت به Kubernetes، انواع چک‌استایل، نقاط باگ، ktlint، وجود لاگ‌ها در کیبانا، سرویس‌های کشف خودکار به‌جای تعیین مستقیم آدرس‌ها و موارد مفید دیگر. و در همه جا جدول ما به ما اجازه داد تا ارتباط خدمات خود را حفظ کنیم. برای ما، این یک نوع چک لیست است که می گوید این سرویس می تواند این کار را انجام دهد، اما هنوز این کار را نمی کند. اما ما ادامه دادیم و متوجه شدیم که اطلاعاتی در مورد خدمات خود نداریم، که نظارت می کنیم، منابع خدمات در کجا قرار دارند. مکان‌هایی که وظایف اسمبلی در TeamCity راه‌اندازی می‌شوند، نحوه استقرار آن‌ها، جایی که منابع تست‌های end2end ذخیره می‌شوند، عکس‌هایی از جلسات مراقبت درباره معماری، درباره تصمیم‌های گرفته شده. در حالت ایده آل، من دوست دارم همه این اطلاعات در جایی قرار بگیرند و در صورت نیاز در دسترس باشند. بنابراین علامت ما نقطه شروع جستجوی اطلاعات شد.

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

چگونه اتفاق می افتد

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

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

موضوع این است که در حال حاضر مشتری نداریم که این سرویس را بر عهده بگیرد. چه الزامات تجاری داشت، این سرویس باید چه کار کند؟ و این سرویس کاملاً در فرآیندهای تجاری شما ادغام شده است.

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

از کجا شروع کنم؟

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

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

چه کاری انجام دهید

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

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

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

در نتیجه، می‌خواهم طرحی ارائه کنم که با خدمات Legacy چه کار کنم.

بازنویسی میراث از ابتدا ایده بدی است
به طور جدی، حتی لازم نیست به آن فکر کنید. واضح است که من آن را دوست دارم، و مزایایی هم دارد، اما معمولاً هیچ کس، از جمله خودتان، به آن نیاز ندارد.

فهرست راهنما
کدهای منبع برنامه های خود را پیدا کنید، یک کتاب مرجع تهیه کنید که نشان دهد کجاست و چگونه کار می کند، شرحی از پروژه را در آنجا وارد کنید (مشروط readme.md) تا به سرعت بفهمید که گزارش ها و معیارها در کجا قرار دارند. توسعه‌دهنده‌ای که بعد از شما با این موضوع برخورد می‌کند فقط از شما تشکر می‌کند.

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

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

با میراث خود چه می کنید؟

• ٪۱۰۰من دارم از اول بازنویسی می کنم، درست تر است 12

• ٪۱۰۰تقریبا مثل شما20

• ٪۱۰۰ما میراث نداریم، ما عالی هستیم4

• ٪۱۰۰من در نظرات می نویسم 2

38 کاربر رای دادند. 20 کاربر رای ممتنع دادند.

منبع: www.habr.com