پروژه‌ها

مسئله

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

نقش من

بنیان‌گذار و تنها مهندس پروژه: API، مدل داده و مایگریشن‌ها، فرانت‌اندها، سایدکار Go، استک پروداکشن Compose، CI و مانیتورینگ.

رویکرد

• CI روی هر پوش: بیلد قفل‌شدهٔ Node، تست‌های واحد Python، سایدکار Go، اعتبارسنجی Compose، تست‌های end-to-end مرورگر، اسکن امنیتی مخزن و اسکن Trivy برای هر ایمیج.
• جاب‌های یکپارچگی روی TimescaleDB و Redis واقعی اجرا می‌شوند: مایگریشن‌ها باید idempotent و دارای checksum باشند و جابه‌جایی lease بین رپلیکاهای API تست می‌شود.
• وابستگی‌های Python از روی lock فایل‌های دارای hash نصب و با pip-audit بررسی می‌شوند.

امنیت و پایداری

• بررسی readiness علاوه بر زنده‌بودن پروسه، سلامت دیتابیس، Redis و قیمت‌ها را هم می‌سنجد. پورت 8000 API فقط داخلی است.
• قوانین هشدار Prometheus: از دسترس خارج‌شدن API، قیمت ناموجود یا منقضی، توقف به‌روزرسانی، نرخ خطای منابع، dead letterها، صف عقب‌افتادهٔ ذخیره‌سازی و حافظهٔ Redis.
• ورکرهای خارجی قیمت، رکوردهایی را که می‌فرستند امضا می‌کنند؛ سایدکار فید هیچ دسترسی به دیتابیس یا پنل مدیریت ندارد.
• پنل مدیریت کوکی نشست جدا، محافظت CSRF، بررسی مجوز، احراز هویت مجدد و TOTP MFA دارد.

نتیجه

• نسخهٔ 2.8.1 پیش از استقرار از هر ۱۵ جاب CI عبور کرد و ایمیج نهایی API هیچ آسیب‌پذیری HIGH یا CRITICAL نداشت.
• سند وضعیت پروژه شواهد تاریخ‌دار نگه می‌دارد و صریحاً می‌گوید چه چیزی اثبات نشده؛ مثلاً ادعای «بدون قطعی» نمی‌کند.

مسئله

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

نقش من

هم‌بنیان‌گذار و مهندس ارشد: اپلیکیشن، راه‌اندازی PostgreSQL، توپولوژی Compose، لبهٔ Nginx، اسکریپت‌های استقرار و ران‌بوک عملیات.

رویکرد

• فعال‌بودن قابلیت‌ها از مانیفستی می‌آید که با کلید Ed25519 امضا شده و کلید خصوصی آن هرگز از دست صاحب پلتفرم خارج نمی‌شود. اگر مانیفست نباشد، دست‌کاری شده باشد یا امضای ناشناس داشته باشد، پروداکشن اجرا نمی‌شود.
• چهار کاربر PostgreSQL با دسترسی‌های جدا: راه‌انداز، مالک مایگریشن، اپلیکیشن در حال اجرا و یک نقش فقط‌خواندنی برای بکاپ. جاب‌های یک‌باره (db-bootstrap → migrate → db-finalize) پیش از اجرای وب، دسترسی‌های دقیق را اعمال می‌کنند.
• ایمیج‌ها با digest نوع sha256 ارجاع داده می‌شوند و از کامیت تگ‌دار ساخته می‌شوند، نه از فایل‌های در حال ویرایش.

امنیت و پایداری

• deploy.sh ارتقای نیمه‌کاره را نمی‌پذیرد: بکاپ، مایگریشن، به‌روزرسانی دسترسی‌ها و بارگذاری مجدد Nginx به ترتیبی ثابت اجرا می‌شوند و با --rollback به ایمیج قبلی برمی‌گردد.
• حالت write-stop در Nginx هنگام نگهداری، درخواست‌های POST/PUT/PATCH/DELETE را رد می‌کند و خواندن همچنان کار می‌کند.
• بکاپ‌ها checksum دارند و در کانتینری ایزوله و بدون شبکه بازیابی می‌شوند؛ بکاپ فقط وقتی معتبر است که بازیابی شده باشد.
• کانتینرها فقط‌خواندنی، بدون هیچ capability و با no-new-privileges اجرا می‌شوند.

نتیجه

• نسخه‌های تگ‌دار با changelog برای هرکدام (نسخهٔ 2.40.55 در اکتبر ۲۰۲۶)؛ مخزن حدود ۳٬۵۱۰ تست خودکار دارد.
• یک ران‌بوک واحد، نصب اولیه، به‌روزرسانی، بکاپ و بازیابی، بازگشت نسخه و واکنش به حادثه را پوشش می‌دهد.