از ابزار تا خودمختاری

در 1 سپتامبر 2026، آتولپریا شارما | CNCF Ambassador و Platform Engineering TCG Organizer

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

در مسیر دوم، platform از قبل راه‌اندازی شده است. golden path وجود دارد، developer portal و CLI هم در دسترس است و در بعضی موارد حتی AI agent هم به کار گرفته شده است. در نگاه اول، میزان adoption قابل قبول به نظر می‌رسد، اما تیم platform هنوز هم درخواست‌ها را به‌صورت دستی انجام می‌دهد و همین موضوع به گلوگاه اصلی برای هر چیزی خارج از مسیر از پیش‌ساخته تبدیل می‌شود؛ در حالی که همچنان این پرسش باقی می‌ماند که چرا “self-service” واقعاً بار کاری تیم را کم نکرده است.

این دو وضعیت در ظاهر متضاد هستند، اما در اصل یک مسئله مشترک را نشان می‌دهند: هیچ‌کدام نمی‌دانند مرحله بعدی interface platform آن‌ها چیست. تیم اول فکر می‌کند پاسخ، ساختن platform است. تیم دوم هم تصور می‌کند باید قابلیت‌های بیشتری به platform اضافه کند. هیچ‌کدام اشتباه نمی‌کنند؛ اما سؤال درست این نیست که «آیا platform داریم؟» سؤال درست این است که «developerها در عمل چگونه با چیزی که ساخته‌ایم تعامل می‌کنند؟»

این فاصله میان قابلیت‌هایی که وجود دارند و قابلیت‌هایی که واقعاً قابل self-service هستند، یک مشکل در interface maturity است. در این مطلب، به CNCF Platform Engineering Maturity Model نگاه می‌کنیم که چهار مرحله برای این مسیر تعریف می‌کند. هر مرحله را بررسی می‌کنیم، اما تمرکز اصلی‌مان روی interfaceها خواهد بود و توضیح می‌دهیم چرا بیشتر تیم‌ها بدون آن‌که متوجه شوند در Stage 2 متوقف می‌شوند و مسیر واقعی بعدی چیست. 🚀

Understanding The CNCF Platform Engineering Maturity Model

CNCF Platform Engineering Maturity Model پنج بُعد برای بلوغ platform engineering تعریف می‌کند: Investment، Adoption، Interfaces، Operations و Measurement. هرکدام به‌صورت مستقل امتیازدهی می‌شوند. یک سازمان به‌صورت کلی از کل مدل عبور نمی‌کند، بلکه هر بُعد را با سرعت و زمان‌بندی خودش پیش می‌برد. هر بُعد هم چهار سطح دارد: Provisional، Operational، Scalable و Optimizing.

این مدل یک framework تشخیصی است؛ یعنی به شما می‌گوید اکنون کجا ایستاده‌اید، اما نمی‌گوید چگونه به مرحله بعد برسید. ما در اینجا روی یکی از همین بُعدها تمرکز می‌کنیم: Interfaces؛ یعنی این‌که developerها دقیقاً چگونه با قابلیت‌های platform تعامل می‌کنند، از فرم‌ها و CLIها گرفته تا portalها و APIها، و چرا بیشتر تیم‌ها در Level 2 متوقف می‌شوند بدون آن‌که متوجه شوند.

The Four Stages of Interfaces Maturity

بُعد Interfaces در CNCF platform maturity model توضیح می‌دهد که developerها چگونه با قابلیت‌های platform ارتباط می‌گیرند و آن‌ها را مصرف می‌کنند. این بخش چهار سطح دارد و هر سطح نشان می‌دهد platform team تا چه اندازه هنوز باید در جریان کارها دخالت داشته باشد. ✨

Level 1: Custom Processes

Level 1 یعنی custom processes؛ مجموعه‌ای از فرایندهای متفاوت و ناسازگار که هیچ interface ثابتی ندارند. قابلیت‌ها از طریق درخواست‌های دستی provision می‌شوند، دانش از فردی به فرد دیگر منتقل می‌شود و معمولاً برای انجام هر کار، پشتیبانی عمیق از طرف ارائه‌دهنده capability لازم است.

در عمل، بیشتر تیم‌هایی که platform رسمی ندارند، عملاً همین‌جا هستند؛ حتی اگر خودشان چنین چیزی را نپذیرند. اسکریپت‌ها، runbookها و فرهنگ «از جسیکا بپرس، او می‌داند database را چطور راه‌اندازی کند» همگی نمونه‌هایی از Level 1 هستند. نبود یک platform با نام مشخص، به معنای نبودن یک stage نیست.

Level 2: Standard Tooling

CNCF در Level 2 از Standard Tooling صحبت می‌کند؛ یعنی interfaceهای استاندارد و یکپارچه برای provision و مشاهده قابلیت‌ها. در این مرحله، golden path و paved road تا حدی وجود دارند. مستندات و templateها هم آماده‌اند تا کاربران بتوانند بفهمند چه چیزی در دسترس است و چگونه آن را درخواست کنند.

بیشتر تیم‌هایی که می‌گویند «platform ساخته‌ایم» در واقع همین‌جا قرار دارند. این مرحله شبیه موفقیت است، چون نرخ adoption بهتر می‌شود، onboarding سریع‌تر پیش می‌رود و metricها در مسیر درست حرکت می‌کنند. اما هر چیزی که بیرون از مسیر paved باشد، همچنان به یک انسان از تیم platform نیاز دارد تا آن را اجرا کند. interface استاندارد شده، اما هنوز خودکفا نیست.

Level 3: Self-Service Solutions

Level 3 مربوط به self-service solutions است؛ جایی که کاربران واقعاً autonomy دارند و به support کمی از maintainers نیاز است. در این سطح، provisioning بسیاری از درخواست‌ها تنها با یک کلیک انجام می‌شود و platform team دیگر در جریان مستقیم کار نیست.

بیشتر کارهای روتین، نقطه شروع خوبی برای ورود به مسیر self-service هستند. نشانه این مرحله بیشتر رفتاری است تا صرفاً عددی. تیم‌ها برای درخواست‌های معمولی دیگر ticket ثبت نمی‌کنند و ابتدا به internal platform سر می‌زنند. engineerهای تازه‌وارد هم اولین تغییر مهم خود را ظرف چند روز انجام می‌دهند، نه چند هفته. واضح‌ترین نشانه را باید در backlog دید؛ سازمان‌هایی که به Level 3 می‌رسند گزارش می‌دهند که پس از اضافه‌کردن گزینه‌های self-service برای configuration، درخواست‌های exception حدود 40 تا 60 درصد کاهش یافته است.

در این مرحله، کار تیم platform از انجام درخواست‌های تکی به بهبود frameworkی تغییر می‌کند که آن درخواست‌ها را مدیریت می‌کند.

Level 4: Integrated Services

در Level 4 یا integrated services، قابلیت‌های platform به‌صورت شفاف در ابزارها و فرایندهایی که تیم‌ها از قبل استفاده می‌کنند ادغام می‌شوند. بعضی قابلیت‌ها به‌طور خودکار provision می‌شوند و interface تا زمانی که نیازی به بررسی عمیق‌تر نباشد، عملاً دیده نمی‌شود.

نشانه رسیدن به Level 4 این است که دیگر تقریباً کسی درباره platform صحبت نمی‌کند. developerها از لحاظ ذهنی دیگر درگیر infrastructure نیستند، چون همه‌چیز روی platform سوار شده است. وقتی سرویس جدیدی ایجاد می‌شود، monitoring، logging و security به‌صورت خودکار integrated می‌شوند و developer مجبور نیست برای تنظیم آن‌ها درگیر جزئیات شود. تیم security policyها را تعریف می‌کند و platform آن‌ها را بدون مذاکره با developer اعمال می‌کند. تیم observability هم قابلیت‌هایی می‌سازد که به‌طور خودکار یکپارچه می‌شوند. موفقیت تیم platform را می‌توان در این سنجید که چقدر به‌ندرت کسی از platform نام می‌برد. 🔧

Where Most Teams get Stuck

self-service یعنی developer بتواند بدون دخالت platform team آنچه را نیاز دارد دریافت کند. Standard tooling یعنی developer می‌تواند آنچه را platform team پیش‌بینی کرده است بگیرد و برای بقیه موارد هنوز platform team باید حاضر باشد. در Level 2 این دو ممکن است شبیه هم به نظر برسند، اما در مقیاس بالا کاملاً از هم جدا می‌شوند.

با توجه به تجربه کار با سازمان‌های مختلف در صنایع گوناگون، چند دلیل اصلی برای گیر کردن تیم‌ها وجود دارد. 🧭

Queue problem

Golden pathها موارد رایجی را که تیم‌ها با آن روبه‌رو می‌شوند پوشش می‌دهند، اما edge caseها را نه. و در هر سازمانی که اندازه قابل‌توجهی داشته باشد، edge caseها در واقع edge case نیستند؛ آن‌ها 30 درصد کار را تشکیل می‌دهند. هر درخواستی که بیرون از golden path قرار بگیرد، مستقیماً روی میز platform team می‌نشیند و backlog را بزرگ‌تر می‌کند. تیمی که قرار بود از toil کم کند، خودش منبع آن می‌شود.

در یکی از گفت‌وگوها در یک platform engineering round table، با گروهی از یک سازمان retail صحبت کردم که برای Kubernetes deploymentها با استفاده از Helm charts و ArgoCD یک golden path ساخته بودند. ظرف شش ماه، 85 درصد تیم‌ها از آن استفاده می‌کردند. اما backlog تیم platform از صفر به 40 درخواست exception رسیده بود و 60 درصد زمان آن‌ها صرف رسیدگی به configurationهایی می‌شد که بیرون از golden path قرار داشتند.

Expertise problem

Platform teamها قابلیت‌هایی می‌سازند که در دامنه‌هایی عمومی‌سازی می‌شوند. اما یک streaming pipeline که توسط تیمی بدون expertise در streaming ساخته شده باشد، شاید کار کند؛ اما به خوبی سیستمی نخواهد بود که توسط تیمی ساخته شده که هر روز workloadهای streaming را اجرا می‌کند. این فاصله با گذشت زمان بیشتر می‌شود. تیم‌های تخصصی کم‌کم به platform برای نیازهای تخصصی اعتمادشان را از دست می‌دهند و شروع به ساخت راه‌حل‌های خودشان می‌کنند.

در تجربه‌ای دیگر با یک سازمان financial services، تیمی یک internal developer platform جامع با self-service برای provision زیرساخت ساخته بود؛ شامل مستندات، office hours و راهنماهای گسترده. تیم‌ها می‌توانستند از platform پیروی کنند، اما نمی‌توانستند آن را توسعه دهند. وابستگی میان Terraform modules، CI/CD pipelineها، monitoring integrationها و service mesh configurationها فقط در ذهن platform team وجود داشت. تیم‌های application هیچ mental model روشنی از نحوه تعامل این اجزا نداشتند. این فاصله به مرور بیشتر شد و تیم‌ها شروع کردند capabilityهای خودشان را بسازند.

Maintenance trap

ارائه قابلیت‌ها ساده‌ترین بخش کار است؛ نگهداری از آن‌ها بخشی است که معمولاً کسی برایش برنامه‌ریزی نمی‌کند. اگر در دو سال 30 capability منتشر شده باشد، یعنی با هر CVE باید 30 مورد patch شوند، با هر Kubernetes upgrade باید 30 چیز تست شوند و 30 سطح وجود دارد که ممکن است بی‌صدا دچار مشکل شوند. در نتیجه، تیم platform که برای ساختن نیرو گرفته بود، کم‌کم برای رسیدگی به patchها و updateها نیرو استخدام می‌کند.

در همکاری با یک سازمان e-commerce، آن‌ها shared Helm chartهایی ساخته بودند که پیچیدگی Kubernetes را abstract می‌کرد و deploymentها را به‌طور قابل‌توجهی سریع‌تر می‌ساخت. اما 18 ماه بعد، همان chartها پر شده بودند از APIهای deprecated، پارامترهای بدون استفاده، وابستگی به featureهای خاص cloud provider و فرضیات سخت‌کدشده درباره networking. تیم platform از به‌روزرسانی آن‌ها می‌ترسید، چون هر تغییر به تست هماهنگ در ده‌ها application نیاز داشت. تیم‌های application هم از custom کردن آن‌ها می‌ترسیدند، چون باید تبعاتش را خودشان می‌پذیرفتند. golden path تبدیل به legacy code‌ای شده بود که همه از آن استفاده می‌کردند، اما هیچ‌کس نمی‌خواست به آن دست بزند. 😅

Rigidity issue

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

راه‌حل‌های موقت مدام بیشتر می‌شوند و shadow infrastructure آرام‌آرام شکل می‌گیرد تا زمانی که یک‌باره با مشکل جدی روبه‌رو شود. در یکی از رویدادهای KubeCon + CloudNativeCon، با یک platform lead صحبت کردم که با یک سازمان healthcare کار کرده بود. آن‌ها استقرارهای Kubernetes، Istio، Prometheus و ArgoCD را استاندارد کرده بودند و golden path کاملاً بر همان stack تکیه داشت. اما وقتی یک تیم نیاز داشت یک application legacy را که در container اجرا نمی‌شد deploy کند، یا به database متفاوتی نیاز داشت، یا به …