پشت‌صحنهٔ مهندسی پلتفرم: ساخت پلتفرم داخلی توسعه‌دهندگان (IDP) برای تیم‌های بک‌اند شما

هشت ماه پیش، تیم بک‌اند ۱۰ نفرهٔ ما داشت در تیکت‌ها غرق می‌شد:

«به یک محیط staging نیاز دارم.» «کسی می‌تواند به من دسترسی لاگ‌های production را بدهد؟» «چطور feature branch خودم را deploy کنم؟»

هر درخواست یعنی یک تیکت Jira، انتظار برای تیم پلتفرم، و یک context switch دیگر برای همهٔ افراد درگیر.

امروز همان مهندس‌ها از روی pull requestها محیط preview بالا می‌آورند، با یک دستور روی staging دیپلوی می‌کنند و از طریق یک پرتال سلف‌سرویس به لاگ‌ها دسترسی دارند. تیم پلتفرم از آتش‌نشانی دائمی به ساختن رسید. ما زمان آماده‌سازی (provisioning) محیط‌ها را از ۲–۳ روز به حدود ۱۱ دقیقه کاهش دادیم.

ساختن یک پلتفرم داخلی توسعه‌دهندگان (IDP) در عمل چنین شکلی دارد — نه نسخهٔ تبلیغاتی فروشنده‌ها، بلکه واقعیت پرچالش مسیرِ رسیدن به آن.

چرا IDPها بیش از پیش ضروری می‌شوند

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

فلسفهٔ وجودی آن کاهش بار شناختی و افزایش سرعت مهندسی است.

یک IDP خوب واقعاً چه شکلی است

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

۱. آماده‌سازی سلف‌سرویس محیط‌ها

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

# Developer runs: idp env:create --name=feature-payments --from=staging
name: feature-payments
source_env: staging
owner: alice@company.com
ttl: 7d
resources:
  namespace: feature-payments-alice
  database: pg-feature-payments
  redis: redis-feature-payments
  secrets: copied from staging vault

خودِ provisioning را ابزارهای زیرساختی انجام می‌دهند، اما توسعه‌دهندگان از طریق یک CLI یا پرتال ساده با آن تعامل می‌کنند.

۲. پایپ‌لاین‌های deployment به‌صورت کد

هر سرویس باید به یک شکل و با پایپ‌لاین‌های استانداردشده deploy شود.

# .idp/deploy.yaml in every repo
service:
  name: payments-api
  team: payments

deploy:
  strategy: canary
  canary:
    - weight: 10
      pause: 5m
    - weight: 50
      pause: 10m
    - weight: 100

  healthcheck:
    path: /health
    interval: 10s
    threshold: 3

  rollback:
    auto: true
    on_error_rate: ">1%"

توسعه‌دهندگان قصدشان را اعلام می‌کنند. پلتفرم، CI/CD، منطق rollout و سیاست‌ها را تولید می‌کند.

۳. مدیریت secretها و RBAC بدون تیکت

دسترسی به منابع production باید از قواعد مبتنی بر نقش پیروی کند، نه از تأییدهای دستی.

class SecretAccessService
{
    public function requestAccess(string $userId, string $secretPath, string $reason, int $duration)
    {
        if ($this->isServiceOwner($userId, $secretPath) ||
            $this->belongsToUserTeam($userId, $secretPath)) {
            return $this->grantAccess($userId, $secretPath, $duration);
        }

        return $this->createApprovalWorkflow($userId, $secretPath, $reason, $duration);
    }
}

بیشتر درخواست‌های دسترسی را می‌توان بر اساس متادیتای مالکیت و تیم، به‌صورت خودکار تأیید کرد.

۴. دسترسی به مشاهده‌پذیری (Observability)

توسعه‌دهندگان به لاگ‌ها، متریک‌ها و traceها نیاز دارند — محدود به همان چیزهایی که مالکش هستند.

teams:
  - name: payments
    members: [alice, bob, carol]
    views:
      dashboards:
        - payments-*
      logs:
        paths:
          - namespace=payments-*

اگر مالک سرویس باشید، داده‌هایش را می‌بینید. بدون نیاز به هیچ تیکتی.

۵. کاتالوگ سرویس‌ها با متادیتای مالکیت

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

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
spec:
  type: service
  owner: team-payments
  dependencies:
    - component: users-api
    - component: notifications-service

همین داده‌هاست که مسیردهی on-call، تحلیل اثر (impact analysis) و آنبوردینگ را ممکن می‌کند.

ساختن یا خریدن: یک ارزیابی صادقانه

چه زمانی بسازید

• بیش از ۵۰۰ مهندس دارید
• زیرساخت‌تان سفارشی یا legacy است
• کنترل کامل بر تجربهٔ توسعه‌دهندگان می‌خواهید

چه زمانی بخرید یا سراغ متن‌باز بروید

• بین ۵۰ تا ۲۰۰ مهندس دارید
• روی زیرساخت ابری استاندارد هستید
• راه‌حل ۸۰ درصدی برایتان کافی است
• باید سریع حرکت کنید

بلوک‌های سازندهٔ رایج:

• Backstage (پرتال و کاتالوگ)
• Crossplane یا Terraform (زیرساخت)
• Argo CD / Rollouts (استقرار و deployment)
• OPA (حفاظ‌های policy)

رویکردی فازبندی‌شده برای ساخت IDP

فاز ۱: کشف (هفته‌های ۱–۴)

• با توسعه‌دهندگان مصاحبه کنید
• صف‌های تیکت را ممیزی کنید
• جریان‌های provisioning و deployment را ترسیم کنید

همین کار مشخص می‌کند درد واقعی کجاست.

فاز ۲: پایه‌های سلف‌سرویس (هفته‌های ۵–۱۲)

این‌ها را خودکار کنید:

• آماده‌سازی (provisioning) محیط‌ها
• پایپ‌لاین‌های deployment
• دسترسی به secretها و لاگ‌ها

فاز ۳: مسیرهای طلایی (هفته‌های ۱۳–۲۰)

قالب‌ها و scaffolding آماده کنید تا توسعه‌دهندگان به‌صورت پیش‌فرض با بهترین شیوه‌ها شروع کنند.

فاز ۴: مشاهده‌پذیری و هزینه (هفته‌های ۲۱–۳۲)

نسبت به این موارد دید و شفافیت فراهم کنید:

• لاگ‌ها، متریک‌ها و traceها
• روند deploymentها
• میزان استفاده از محیط‌ها
• تخصیص هزینه

شکست‌های رایج و راه‌های پرهیز از آن‌ها

❌ اول پرتال ساختن

UI بدون اتوماسیون به هیچ دردی نمی‌خورد. اول API و CLI را بسازید.

❌ بی‌توجهی به پذیرش (Adoption)

گردش‌کارهای قدیمی را منسوخ (deprecate) کنید. رصد کنید چه کسانی هنوز از آن‌ها استفاده می‌کنند و به مهاجرت‌شان کمک کنید.

❌ حفره‌های امنیتی در سلف‌سرویس

از روز اول سیاست‌ها را اعمال کنید. سلف‌سرویس باید همراه با حفاظ (guardrail) باشد.

سنجش موفقیت

| متریک | قبل | بعد | | --------------------------------------- | ------------------ | ------------------ | | زمان آماده‌سازی محیط | ۲–۳ روز | حدود ۱۱ دقیقه | | بسامد deployment | حدود ۲ بار در هفته | حدود ۸ بار در هفته | | حجم تیکت‌های زیرساختی | حدود ۱۲۰ در ماه | حدود ۱۸ در ماه | | زمان تا اولین deploy (نیروی تازه‌استخدام) | حدود ۵ روز | حدود ۴ ساعت |

این بهبودها بازتاب دستاوردهایی واقعی در بهره‌وری توسعه‌دهندگان و قابلیت اطمینان سیستم‌اند.

جمع‌بندی

پلتفرم داخلی توسعه‌دهندگان یک پروژه نیست — یک قابلیت مستمر است.

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

1. دردهای واقعی توسعه‌دهندگان
2. خودکارسازی گردش‌کارهای فرسایشی و پرتکرار
3. استانداردسازی محیط‌ها و deploymentها
4. فراهم‌کردن واسط‌های سلف‌سرویس
5. برخورد با پلتفرم به‌عنوان محصولی برای توسعه‌دهندگان

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

این یادداشت ترجمهٔ فارسی نوشتهٔ خودم است — نسخهٔ اصلی (انگلیسی) در dev.to