پذیرش۲۴ دارای ساختار سازمان ویژه ایست که کمی آن را با بقیه سازمانها متمایز می کند. در پذیرش۲۴، ما ساختار سنتی تیمهای فنی (تیم بکاند، فرانتاند، DevOps و …) را نداریم. در عوض، ساختاری مسطح داریم که در آن هر فرد، مسئول کامل یک بخش از محصول است؛ از طراحی و پیادهسازی تا نگهداری و پشتیبانی. این مدل، آزادی عمل بالایی ایجاد میکند، اما در عین حال اگر اصول مشترکی وجود نداشته باشد، بهسرعت منجر به آشفتگی و واگرایی میشود.
ساخت محصول در این ساختار نیازمند رعایت اصول ویژه ایی است. ما در این سند سعی کرده ایم این اصول را گرداوری کنیم. این سند، مجموعهای از اصول و استانداردهایی است که به ما کمک میکند:
- مستقل تصمیم بگیریم
- اما همراستا عمل کنیم
- سریع حرکت کنیم
- بدون اینکه کیفیت، امنیت و پایداری را قربانی کنیم
در پذیرش۲۴، هر سرویس یا بخش از محصول یک مالک مشخص دارد. مالک آن بخش طراحی میکند، پیادهسازی میکند، کیفیت را تضمین میکند و در زمان بروز مشکل، پاسخگو است!
ما به اصل سادهای پایبندیم: You build it, you run it یعنی اگر چیزی را میسازی، مسئول عملکرد آن در محیط واقعی هم هستی. این رویکرد باعث میشود تصمیمگیری سریعتر شود، مسئولیتپذیری واقعی شکل بگیرد و دانش سیستم در افراد متمرکز نشود بلکه «مالکانه» نگهداری شود. در این مدل، هیچ چیزی «مال همه» نیست.یا یک بخش مالک مشخص دارد، یا اساساً نباید شروع شود.
اصول ساخت و نگهداری محصول (Product Engineering)
۱.طراحی و مستندسازی
ما باور داریم که «تولید و ساخت بدون طراحی»، هزینه را فقط به آینده منتقل میکند.
هر تغییر مهم یا توسعه جدید باید دارای یک طراحی مکتوب باشد. این طراحی الزاماً طولانی یا رسمی نیست، اما باید به اندازهای شفاف باشد که مسئله را توضیح دهد، راهحل پیشنهادی را مشخص کند و trade-offها را روشن کند.
یک طراحی خوب باید به این سوالها پاسخ دهد:
- دقیقاً چه مشکلی را حل میکنیم؟
- چرا این راهحل را انتخاب کردهایم؟
- چه گزینههای دیگری وجود داشت و چرا رد شدند؟
- این تغییر چه تأثیری روی سایر بخشها دارد؟
باید بدانیم مستندسازی فقط برای «الان» نیست؛ برای زمانی است که چند ماه بعد، خودمان یا فرد دیگری بخواهد تصمیمهای گذشته را درک کند.
۲.اصول امنیت (Security)
امنیت یک feature نیست که بعداً اضافه شود؛ بخشی از طراحی اولیه سیستم است.
- Authentication (احراز هویت)
هر endpoint باید مشخص کند کاربر کیست و هیچ endpoint حساسی نباید بدون احراز هویت در دسترس باشد. این یعنی دسترسیها بهصورت پیشفرض بسته هستند و فقط در صورت نیاز باز میشوند
- Authorization (مجوزدهی)
بعد از اینکه فهمیدیم کاربر کیست، باید مشخص کنیم آیا این کاربر اجازه انجام این کار را دارد؟ این بخش معمولاً نادیده گرفته میشود، اما یکی از رایجترین منابع باگهای امنیتی است. در پذیرش۲۴ هیچ عملیاتی بدون بررسی مجوز انجام نمیشود و دسترسیها باید صریح و قابل ردگیری باشند.
- CORS
تنظیمات CORS باید دقیق و محدود باشد. استفاده از wildcard (*) در محیط production بهمعنای باز گذاشتن بیدلیل سیستم است، مگر اینکه دلیل مشخص و مستند برای آن وجود داشته باشد.
- Rate Limiting
هر سرویسی که در معرض استفاده عمومی است، باید محدودیت نرخ درخواست (Rate Limit) داشته باشد.این کار از سوءاستفاده جلوگیری میکند و از منابع سیستم در برابر فشار غیرعادی محافظت میکند. نبود rate limit، یک ضعف در طراحی محسوب میشود.
۳.ساختار مدیریت خطا (Error Handling)
یکی از مهمترین نشانههای بلوغ یک سیستم، نحوهی مدیریت خطاهاست. در پذیرش۲۴ هیچ خطایی نباید silent باشد و هیچ خطایی نباید بدون context برگردد.
تمام سرویسها باید از یک ساختار مشخص برای خطا پیروی کنند، بهطوری که status codeها استاندارد و قابل پیشبینی باشند، پیام خطا (message) قابل فهم باشد و یک error code مشخص برای پیگیری وجود داشته باشد. هدف این است که هم مصرفکننده API بداند چه اتفاقی افتاده هم تیم فنی بتواند سریعتر مشکل را ردیابی کند.
۴.اصول پایداری (Reliability & Resilience)
سیستمی که فقط در شرایط ایدهآل کار میکند، قابل اعتماد نیست.
- Failover و High Availability
سرویسهای حیاتی باید بهگونهای طراحی شوند که در صورت بروز خطا، از کار نیفتند یا با حداقل اختلال به کار ادامه دهند. وجود Single Point of Failure باید یا حذف شود، یا آگاهانه پذیرفته و مستند شود.
- Self-Healing
سیستم باید تا حد امکان بتواند خودش را بازیابی کند. این یعنی خطاهای موقت بهصورت خودکار retry شوند، سرویسها در صورت crash شدن، خودکار بالا بیایند و وابستگیها بهصورت resilient مدیریت شوند. هدف این است که سیستم برای هر خطا، به انسان وابسته نباشد
- Caching
کش یکی از قدرتمندترین ابزارها برای بهبود performance است، اما اگر بدون دقت استفاده شود، منبع inconsistency خواهد شد. در پذیرش۲۴ استفاده از cache باید آگاهانه باشد و هر cache باید TTL مشخص داشته باشد و استراتژی invalidation آن از قبل تعریف شده باشد.
هیچ کشی نباید «بیصاحب» باشد.
۵.اصول کنترل کیفیت (Quality & Operations)
کیفیت چیزی نیست که در انتهای کار اضافه شود بخشی از فرآیند ساخت است.
- تست (Testing)
هر feature باید به اندازه ریسک و پیچیدگی خود تست داشته باشد. حداقل انتظار این است که سناریوهای اصلی پوشش داده شده و مسیرهای خطا تست شوند. باید در نظر داشت هدف از تست فقط جلوگیری از باگ نیست بلکه کاهش ریسک تغییرات است.
- Rollout تدریجی
تغییرات مهم نباید بهصورت ناگهانی برای همه کاربران فعال شوند. ما ازfeature flag و rollout مرحلهای استفاده میکنیم تا بتوانیم ریسک را کنترل کنیم و در صورت بروز مشکل، سریع rollback کنیم.
- مانیتورینگ (Monitoring)
اگر نتوانیم وضعیت سیستم را ببینیم، نمیتوانیم آن را مدیریت کنیم. هر سرویس باید متریکهای کلیدی داشته باشد و وضعیتش قابل مشاهده باشد
- Alerting
الرت خوب، الرتی است که بهموقع هشدار دهد و قابل اقدام باشد. الرتی که صرفاً نویز ایجاد کند، بدتر از نداشتن alert است.
- Response Time
سرعت پاسخگویی، بخشی از تجربه کاربر است. هر سرویس باید انتظار مشخصی از latency داشته باشد و در صورت عبور از آن، قابل شناسایی باشد.
- Logging
لاگها فقط برای debug نیستند بلکه برای «فهمیدن رفتار سیستم در دنیای واقعی» هستند. لاگ خوب قابل جستجو است، context دارد (کاربر، درخواست، خطا) و به تصمیمگیری کمک میکند.
جمعبندی
در پذیرش۲۴، ما سعی نکردهایم همه چیز را استاندارد و محدود کنیم. در عوض، تلاش کردهایم روی چند اصل کلیدی به توافق برسیم. استقلال در تصمیمگیری، مسئولیتپذیری کامل و پایبندی به حداقل استانداردهای مشترک از این اصول به شمار می آیند. این اصول به ما کمک میکنند که سریع حرکت کنیم بدون اینکه کیفیت را قربانی کنیم و سیستمی بسازیم که در طول زمان قابل نگهداری و توسعه باشد.
در نهایت ما برای اینکه کار را برای شما کمی آسان تر کنیم از این مقاله یک چک لیست آماده کردیم که آن را می توانید از طریق این لینک دانلود کنید. یک نکته مهم (خیلی مهم) اینکه این چکلیست قرار نیست سرعت شما را کم کند یا تبدیل به کار اداری شود بلکه هدفش این است از انتقال مشکل به production جلوگیری کند.
باید بدانیم اگر جایی از چکلیست را عمداً رعایت نمیکنید کاملاً قابل قبول است اما باید آگاهانه و مستند باشد.