پرش به مطلب اصلی

پلتفرم داخلی، محصول است یا صف تیکت؟

· ۱۳ دقیقه مطالعه
مهدی مالوردی
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

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

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

همان‌جا بود که به نظرم رسید شاید ما پلتفرم نساخته‌ایم؛ فقط صف درخواست‌های زیرساخت را مرتب‌تر کرده‌ایم.

این روایت، ترکیبی از چند تجربه‌ی مشابه با Kubernetes، سامانه‌های داده و ابزارهای مشترک است و برای کنارگذاشتن جزئیات سازمانی ساده شده است.

صف درخواست‌های دستی در برابر مسیرهای روان خودخدمت از یک پلتفرم داخلی

مشخصات گفت‌وگو

عنوان: Beyond Backstage: Building Platforms That Scale
مهمانان: آجای چانکرامات (Ajay Chankramath) و نیک چنوث (Nic Cheneweth)
رسانه: GOTO Unscripted
صفحه‌ی گفت‌وگو: مشاهده در GOTO

چیزی که از این گفت‌وگو برایم ماند​

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

برداشت من از گفت‌وگو سه نکته بود:

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

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

چرا اول کار همه‌چیز منطقی به نظر می‌رسد؟​

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

من هنوز هم این منطق را درست می‌دانم. مسئله از جایی شروع می‌شود که «یک‌بار حل‌کردن» به «هر بار انجام‌دادن برای دیگران» تبدیل شود.

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

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

پلتفرم خوب پیچیدگی را حذف نمی‌کند؛ آن را جایی می‌برد که یک‌بار حل و بارها مصرف شود.

Team Topologies اسم دقیقی برای درد می‌گذارد​

وقتی دوباره بخش تیم پلتفرم در کتاب Team Topologies را خواندم، چیزی که برایم مهم‌تر شد خود ابزار نبود؛ مفهوم بار شناختی بود. تیم محصول قرار نیست هم‌زمان متخصص دامنه، Kubernetes، شبکه، امنیت، خط لوله و مشاهده‌پذیری باشد. پلتفرم باید بخشی از این بار را بردارد تا تیم بتواند روی نتیجه‌ای که برای کاربر می‌سازد تمرکز کند.

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

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

Team Topologies درباره‌ی نوع تعامل هم حرف خوبی دارد. اول کار ممکن است تیم پلتفرم و تیم محصول برای کشف نیاز نزدیک با هم کار کنند. اما این همکاری نباید به وضعیت دائمی استفاده از قابلیت تبدیل شود.

اگر استفاده‌ی روزمره از پلتفرم به همکاری دائمی با سازندگانش نیاز دارد، هنوز خدمت پلتفرمی بالغی نساخته‌ایم.

خودخدمت یا فقط فرم زیباتر؟​

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

من برای اینکه چیزی را خودخدمت بدانم، این سه سؤال را می‌پرسم:

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

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

سه مرحله‌ی عملیات دستی، پرتال درخواست و خودخدمت واقعی

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

تجربه‌ی گوگل؛ قاعده را داخل مسیر بگذار​

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

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

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

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

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

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

این داستان را در پلتفرم داده هم دیده‌ام​

در پلتفرم داده، تمرکز اولیه معمولاً منطقی است. دانش Kafka، Airflow، Spark، دریاچه‌ی داده و سیاست‌های دسترسی محدود است و یک تیم مرکزی باید پایه‌ها را بسازد.

مشکل وقتی شروع می‌شود که هر موضوع Kafka، جریان داده، اجرای Spark یا دسترسی تحلیلی برای همیشه به همان تیم وابسته بماند. تیم مرکزی کم‌کم هم مالک زیرساخت است، هم مجری درخواست، هم بازبین شِما و گاهی پاسخ‌گوی معنای داده‌ای که خودش تولید نکرده است.

واکنش طبیعی، اضافه‌کردن فرایند است: فرم دقیق‌تر، جلسه‌ی اولویت‌بندی و صف فوری. این‌ها آشفتگی را مرتب می‌کنند، اما ظرفیت سیستم را بالا نمی‌برند.

به نظرم باید به درخواست‌های تکراری مثل داده‌ی محصول نگاه کرد. اگر ساخت موضوع با یک الگوی مشخص بارها تکرار می‌شود، نامزد خودکارسازی است. اگر همه درباره‌ی سازگاری شِما سؤال دارند، بررسی باید داخل مسیر ثبت شِما باشد. اگر مالکیت داده مرتب گم می‌شود، مالک باید کنار خود دارایی ثبت شود.

اینجا تیم پلتفرم از «انجام‌دهنده‌ی همه‌چیز» به سازنده‌ی مسیر قابل اعتماد تبدیل می‌شود.

مشتری پلتفرم «همه‌ی توسعه‌دهندگان» نیست​

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

ذهنیت محصول برای من یعنی قبل از ساخت قابلیت این سؤال‌ها را جدی بگیرم:

  • دقیقاً کدام تیم این مشکل را دارد؟
  • امروز چطور حلش می‌کند و کجا بیشتر منتظر می‌ماند؟
  • مسئله چند بار تکرار شده است؟
  • استانداردسازی واقعاً بار شناختی را کم می‌کند یا فقط آزادی را می‌گیرد؟
  • از کجا می‌فهمیم تیم‌ها به مسیر ساخته‌شده اعتماد دارند؟

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

مسیر طلایی نباید حصار باشد​

«مسیر طلایی» قرار است راه پیشنهادی و پشتیبانی‌شده برای کار معمول باشد. تیمی که نیاز استاندارد دارد، بدون درگیرشدن با همه‌ی جزئیات از امنیت، استقرار و مشاهده‌پذیری مناسب بهره می‌برد.

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

قاعده‌ای که برایم معقول‌تر است:

مسیر استاندارد باید آسان‌ترین راه باشد، نه تنها راه.

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

Backstage پلتفرم نیست​

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

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

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

هر ابزار مشترکی متعلق به پلتفرم نیست​

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

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

تعداد قالب‌ها معیار موفقیت نیست​

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

من امروز بیشتر دنبال این نشانه‌ها می‌گردم:

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

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

پلتفرم هم می‌تواند همان گلوگاه قبلی باشد​

در نوشته‌ی «معمار یا گلوگاه؟» درباره‌ی کسی نوشتم که همه‌ی تصمیم‌ها از او عبور می‌کنند. تیم پلتفرم هم می‌تواند همان نقش را در مقیاس سازمان بگیرد: همه برای ابزار، استاندارد، دسترسی و استقرار منتظر یک تیم بمانند.

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

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

شاید اصلاً به تیم پلتفرم نیاز نداشته باشیم​

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

گاهی چند قالب خوب، مستندات روشن و مسئولیت مشترک زیرساخت کافی است. تیم پلتفرم وقتی توجیه دارد که تکرار، پیچیدگی و انتظار میان تیم‌ها به یک مسئله‌ی پایدار تبدیل شده باشد.

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

چیزی که باید دنبال کنیم​

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

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

خلاصه‌ی حرف

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

منابع

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است