مفهوم Platform Engineering و نقش تیمهای Enabling در موفقیت تیمهای محصول.
آیا تیمهای شما با چرخهای مربع کار میکنند؟
تصور کنید یک تیم توسعه محصول میخواهد یک ویژگی جدید را منتشر کند، اما باید ابتدا سرور بخرد، دیتابیس تنظیم کند، شبکه را پیکربندی کند و اجازه دسترسی بگیرد، ابزارهایی برای مانیتورینگ ستاپ کند، لایبرریهای مورد نیاز برای observability و traceability را بنویسید، لایبرریهایی برای ورژنینگ و مایگریشن دیتابیس توسعه دهد و بسیار کارهای مشابه دیگر. در عمل این لیست بسیار طولانی خواهد بود. تسکهای این لیست برای اینکه سیستم شما آماده محیط عملیاتی شود نیز حیاتی است.
اما روی دیگر این داستان در اینجا این است که تیم توسعه بخش اعظمی از زمان و انرژی و هزینه خود را صرف کارهای زیرساختی میکند، بدون اینکه بتواند ارزش قابل لمس کسبوکاری ایجاد کند. این عملا بدین معنی است که تیم بجای تمرکز بر پیادهسازی محصول، بر پیادهسازی لیست تسکهای مشغول است که به Non-Functional Requirements(NFRs) معروف هستند(به شخصه اطلاق NFR به این موارد رو نمیپسندم.) نکتهی مهم دیگر در اینجا این است که تسکهای این لیست دانش و تجربهی متفاوتتری از دانش برنامهنویسی و توسعه نرمافزار را میطلبد. دانش و تجربهای که توسعهدهندگان غالبا به ندرت دارا میباشند.
اینجاست که مفهوم Enabling Teams (تیمهای توانمندساز) وارد میشود. هدف این تیمها این نیست که کار را برای تیمهای محصول و حتی تیمهای توسعه انجام دهند، بلکه این است که ابزارهایی بسازند که تیمهای توسعهی محصول بتوانند بر روی پیادهسازی محصول تمرکز کنند.
گذار از DevOps سنتی به Platform Engineering
بصورت کلاسیک و در مدلهای قدیمی، DevOps اغلب به معنای یک تیم ایزوله از افرادی بود که عمده فعالیت آنها حل و فصل تیکتهای عملیات که توسط پشتیبانی و تیم توسعه صادر میشد، میبود.
این رویکرد به تیمسازی چالشهای بزرگی در راه چابک سازی سازمانها ایجاد کرده است. هر چند فرهنگ DevOps بیشتر تلاشی بود جهت شکستن و از بین بردن دیوار بین تیمهای توسعه و عملیات/پشتیبانی، اما در عمل به دلیل برداشت غلط از آن، عملا چالش موجود را بزرگرتر کرد.
در عمل تیمهای DevOps تشکیل شدند از تیمهای جداگانهای که در اتاق جداگانه خود شروع به virtualization و dockerization سیستمها و برپایی چرخههای CI-CD میکنند. هر چقدر افراد و تیمهای بیشتری دخیل در چرخهی value stream در یک سازمان شوند، بدین معنا است که در عمل شما دارای گلوگاههای زیادی در چرخه خلق ارزش برای مشتری نهایی خود هستید. گلوگاههایی که حداقل هزینهی زمانی و هماهنگی بسیاری را به سازمان تحمیل میکنند، و اغلب مواقع هم به عنوان سرعتگیر چابکی در سازمان هستند. این چرخه معیوب بخصوص وقتی تشدید میشود که یک تیم با عنوان DevOps مسئولیت ارائه خدمت به چندین تیم توسعه محصول میشوند.
در مدلهای مدرنتر و این روزها، ما Platform Engineering را داریم. تیم پلتفرم، یک Internal Developer Platform (IDP) میسازد. این پلتفرم مانند یک “خودرو” است؛ توسعهدهنده فقط باید بداند چگونه رانندگی کند، نیازی نیست بداند موتور چگونه ساخته شده است.
تیم Platform Engineering
این تیم نقش اساسی در توانا (enable) کردن تیمهای توسعه محصول بازی میکنند. در تیم توپولوژی به این تیمهای تیمهای توانمند کُن(enabler team) هم گفته میشود. تیم platform engineering وظیفه توسعه و نگهداری زیر ساخت و پتلفرم مورد نیاز برای انتشار یک یا چند محصول را بر عهده دارد.
همین امر ایجاب میکند که این تیم در تعامل مستقیم با تیمهای محصول عمل کند. در عمل تیم مهندسی پلتفرم در یک سازمان، نه فقط مالک یکسری چرخه انتشار یا داکرایز کردن سرویسهاست. برعکس این تیم هم یک محصول تولید میکند. محصولی که بصورت مستقیم در سازمان و توسط سایر تیمهای توسعه کسبوکار مورد استفاده قرار میگیرد.
مفهوم مسیر طلایی(Golden Path)
یکی از مهمترین خروجیهای یک تیم Enabling، ایجاد Golden Path است. بدون حضور تیمهای enabling از جمله تیم پلتفرم، تیم تمامی مسیرهای توسعه و انتشار محصول از جمله تنظیم Cloud، CI/CD و Monitoring را دستی انجام دهد (پر از خطا و کند). اما با داشتن تیم پلتفرم، یک مسیر طلایی برای انتشار محصول در اختیار هر تیم توسعه قرار میگیرد. توسعهدهنده با اجرای یک دستور ساده یا استفاده از یک قالب (Template)، تمام زیرساختهای لازم را به صورت خودکار، استاندارد و امن دریافت/برپا میکند.
مثال خیلی ساده
وضعیت سازمان بدون حضور تیم Enabling:
- توسعهدهنده در سیستم تیکتینگ مینویسد: لطفاً یک محیط Staging برای سرویس جدید من بسازید.
- تیم عملیات ۳ روز بعد پاسخ میدهد: دیتابیس انتخاب نکردید، دوباره درخواست بدهید. بهمین راحتی!
بهبود وضعیت با حضور تیم Enabling و تیم مهندسی پلتفرم:
- توسعهدهنده به پنل پلتفرم داخلی میرود، روی گزینه `Create New Service` کلیک میکند، نوع دیتابیس را انتخاب میکند و کل زیرساخت (از کانتینر گرفته تا مانیتورینگ و CI/CD) در عرض ۵ دقیقه به صورت خودکار آماده میشود.
تیمهای Enabling، تیمهای خدمتگزار (Servant Teams) هستند. این تیمها با کاهش Cognitive Load (بار شناختی) توسعهدهندگان، اجازه میدهند مهندسان بر روی چیزی تمرکز کنند که در آن استاد هستند: حل مسائل بیزنس از طریق کدنویسی.
[…] Agile 4 ساعت گذشته […]