بیشتر کارفرماها برای ساخت محصول بودجه دقیق دارند، اما برای نگهداری آن فقط یک عدد ماهانه حدسی. نتیجه معمولاً یکی از دو حالت است: یا نگهداری اصلاً انجام نمی‌شود تا روزی که یک بهروزرسانی امنیتی، قطعی یا کندی ناگهانی هزینه چندبرابری می‌سازد، یا قرارداد پشتیبانی مبهمی بسته می‌شود که معلوم نیست دقیقاً چه چیزی را پوشش می‌دهد. این مقاله روشی است برای اینکه هزینه نگهداری پروژه Laravel و بودجه ریسک فنی را از اجزای واقعی‌اش بسازید، نه از یک درصد ثابت.
برآورد هزینه ساخت را در مقاله هزینه طراحی و توسعه پروژه Laravel توضیح داده‌ام. اینجا درباره بعد از انتشار صحبت می‌کنیم.
نگهداری دقیقاً یعنی چه؟
«پشتیبانی» در قراردادها معمولاً همه چیز و هیچ چیز است. بهتر است کار بعد از انتشار را به چهار دسته جدا تقسیم کنید، چون هر کدام رفتار هزینه‌ای متفاوتی دارند:
| دسته | نمونه | رفتار هزینه |
|---|---|---|
| نگهداری الزامی | بهروزرسانی امنیتی PHP، Laravel و پکیج‌ها، تمدید گواهی، پشتیبان‌گیری و آزمایش بازیابی | تقریباً ثابت و قابل پیش‌بینی؛ اگر عقب بیفتد انباشته می‌شود |
| عملیات | پایش خطا و کندی، پاسخ به قطعی، رسیدگی به صف‌های گیرکرده، فضای دیسک | بیشتر ثابت، با جهش‌های گاه‌به‌گاه |
| اصلاح | رفع باگ، سازگاری با تغییر سرویس‌های بیرونی، رفع کندی ناشی از رشد داده | نامنظم؛ به کیفیت کد و رشد محصول وابسته است |
| توسعه | قابلیت جدید و تغییر رفتار محصول | تصمیم کسب‌وکار؛ جزو نگهداری حساب نکنید |
اشتباه رایج این است که دسته چهارم در بودجه نگهداری قاطی می‌شود. بعد هر ماه قابلیتهای جدید جای به‌روزرسانی‌های امنیتی را میگیرند و «نگهداری» عملاً انجام نمی‌شود.
بخش ثابت: کارهایی که تقویم دارند
این‌ها را می‌شود از قبل در تقویم گذاشت:
- چرخه نسخه‌های Laravel و PHP. هر نسخه اصلی Laravel مدت مشخصی رفع باگ و رفع امنیتی دریافت می‌کند و هر نسخه PHP هم پایان پشتیبانی دارد. برنامه ارتقا را از روز انتشار بنویسید. ارتقای منظم از یک نسخه به نسخه بعد کار کوچکی است؛ پریدن از سه نسخه عقب‌تر، خودش یک پروژه است.
- بهروزرسانی ماهانه وابستگی‌ها.
composer outdatedوcomposer auditرا به‌طور منظم اجرا کنید. با تست خودکار، بهروزرسانی ماهانه معمولاً چند ساعت کار است. - آزمایش بازیابی پشتیبان. پشتیبانی که هیچ‌وقت بازیابی نشده، فرض است، نه پشتیبان. هر سه ماه یک بار روی محیط جدا بازیابی کنید و زمانش را ثبت کنید.
- مرور دسترسی‌ها. حساب‌های افرادی که از تیم رفته‌اند، کلیدهای API قدیمی و دسترسی‌های سرور.
بخش متغیر: بودجه ریسک
کارهای دسته اصلاح را نمی‌شود دقیق پیش‌بینی کرد، اما می‌شود اندازه‌شان را تخمین زد. به‌جای یک عدد ثابت، یک «بودجه ریسک» تعریف کنید که اندازه‌اش از عوامل زیر می‌آید. هر عامل را از ۱ (ریسک کم) تا ۳ (ریسک زیاد) امتیاز دهید:
| عامل | امتیاز ۱ | امتیاز ۳ |
|---|---|---|
| پوشش تست بخش‌های حیاتی | پرداخت، احراز هویت و جریان اصلی تست خودکار دارند | تست وجود ندارد |
| سرویس‌های بیرونی | یک یا دو سرویس پایدار | چند سرویس، بعضی بدون مستندات یا ناپایدار |
| رشد داده و ترافیک | ثابت یا آرام | چند برابر شدن در سال |
| فاصله از نسخه پشتیبانی‌شده | روی نسخه فعلی | پشتیبانی امنیتی تمام شده |
| دانش پروژه | مستندات و چند نفر که کد را می‌شناسند | فقط یک نفر، یا هیچ‌کس |
| حساسیت کسب‌وکار | قطعی چند ساعته قابل تحمل است | هر دقیقه قطعی درآمد یا اعتبار را از بین می‌برد |
مجموع امتیاز بین ۶ و ۱۸ است و می‌تواند سطح بودجه را تعیین کند:
- ۶ تا ۸ (ریسک کم): بودجه اصلاح کوچکی کافی است؛ بیشتر هزینه همان بخش ثابت است.
- ۹ تا ۱۳ (ریسک متوسط): بودجه اصلاح را هم‌اندازه بخش ثابت در نظر بگیرید و بخش استفاده‌نشده را به کاهش ریسک اختصاص دهید.
- ۱۴ تا ۱۸ (ریسک زیاد): قبل از تعیین بودجه ماهانه، یک پروژه کوتاه کاهش ریسک لازم است: ارتقای نسخه، تست بخش‌های حیاتی، مستندسازی. بدون آن، هر عدد ماهانه‌ای که انتخاب کنید یا کم است یا با یک حادثه تمام می‌شود.
عددها را به ساعت تبدیل کنید، نه مستقیم به پول. ساعت قابل پیگیری است؛ آخر هر ماه می‌بینید چند ساعت مصرف شد و برای چه.
بودجه استفاده‌نشده را دور نریزید
ماهی که حادثه‌ای پیش نیامده، فرصت است، نه صرفه‌جویی. ساعت‌های استفاده‌نشده بودجه ریسک را صرف کاری کنید که امتیاز جدول بالا را پایین بیاورد: یک تست برای جریان پرداخت، حذف یک پکیج بلااستفاده، مستندسازی یک بخش که فقط یک نفر می‌شناسد، یا اضافه‌کردن هشدار برای صفی که قبلاً گیر کرده بود. این‌طور هزینه نگهداری در طول زمان کم می‌شود، نه زیاد.
نشانه‌هایی که بودجه کم است
- به‌روزرسانی‌های امنیتی ماه‌ها عقب افتاده‌اند چون «کار مهم‌تری» بود.
- هر تغییر کوچک، باگ در جای دیگری می‌سازد و کسی جرئت تغییر بخش‌های قدیمی را ندارد.
- قطعی را اول کاربران گزارش می‌کنند، نه سیستم هشدار.
- زمان پاسخ صفحه‌ها با رشد داده به‌تدریج بالا رفته و کسی اندازه‌اش نگرفته است.
اگر دو مورد از این‌ها درباره پروژه شما صدق می‌کند، بدهی فنی در حال انباشته شدن است. راه شناخت دقیقش را در مقاله ممیزی کد Laravel و بدهی فنی نوشته‌ام.
قرارداد نگهداری چه چیزی را باید مشخص کند
- فهرست کارهای ثابت و تناوبشان: بهروزرسانی ماهانه، آزمایش بازیابی فصلی، برنامه ارتقای نسخه.
- تعداد ساعت بودجه اصلاح و اینکه ساعت استفاده‌نشده چطور مصرف می‌شود.
- زمان پاسخ برای سطوح مختلف حادثه: قطعی کامل، قابلیت حیاتی خراب، باگ معمولی.
- اینکه توسعه قابلیت جدید جدا قیمتگذاری می‌شود.
- گزارش ماهانه: چه کاری انجام شد، چند ساعت، و امتیاز ریسک چطور تغییر کرد.
- مالکیت دسترسی‌ها: سرور، دامنه، مخزن و سرویس‌های بیرونی به نام کارفرما.
مثال محاسبه ساعت
یک فروشگاه اینترنتی متوسط با Laravel، درگاه پرداخت، سرویس پیامک و پنل ادمین را فرض کنید. امتیازها: تست ۲، سرویس‌های بیرونی ۲، رشد ۲، نسخه ۱، دانش ۲، حساسیت ۳. مجموع ۱۲، یعنی ریسک متوسط. اگر بخش ثابت (به‌روزرسانی‌ها، پایش، پشتیبان) ماهانه حدود ۸ ساعت برآورد شود، بودجه اصلاح هم حدود ۸ ساعت در نظر گرفته می‌شود: مجموعاً ۱۶ ساعت در ماه، با این شرط که ساعت‌های اصلاحِ مصرف‌نشده صرف بالا بردن پوشش تست شود تا امتیاز تست در چند ماه به ۱ برسد. این عددها برای نشان دادن روش است؛ برای پروژه شما باید از بررسی واقعی کد و زیرساخت بیاید.
جمع‌بندی
هزینه نگهداری از دو بخش ساخته می‌شود: کارهای ثابتی که تقویم دارند و بودجه ریسکی که اندازه‌اش به کیفیت و شرایط پروژه بستگی دارد. جدا کردن این دو از توسعه قابلیت جدید، و خرج کردن بودجه ریسک استفاده‌نشده روی کاهش ریسک، نگهداری را از یک هزینه مبهم به سرمایه‌گذاری قابل اندازه‌گیری تبدیل می‌کند.
اگر می‌خواهید وضعیت پروژه Laravel شما برای تعیین بودجه نگهداری واقعی بررسی شود، یا قرارداد نگهداری با دامنه و گزارش شفاف لازم دارید، از طریق خدمت توسعه اختصاصی PHP و Laravel با من در تماس باشید.
پرسش‌های متداول
آیا توسعه قابلیت جدید باید جزو قرارداد نگهداری باشد؟
بهتر است جدا قیمتگذاری شود. در غیر این صورت قابلیتهای جدید جای بهروزرسانی امنیتی و کاهش ریسک را میگیرند.
هر چند وقت یک بار باید پشتیبان را آزمایش کرد؟
حداقل هر سه ماه یک بار روی محیط جدا بازیابی کنید و زمان بازیابی را ثبت کنید؛ پشتیبان آزمایش‌نشده قابل اتکا نیست.