پشتیبانی و نگه‌داری نرم‌افزار بعد از تحویل دقیقاً شامل چه چیزی است؟

«پشتیبانی» در پیشنهادها اغلب یک ردیف کوتاه است، ولی پشت آن چند نوع کار با هزینه و مسئول متفاوت پنهان است. اگر دامنه را مکتوب نکنید، هر طرف چیزی دیگر فرض می‌کند: شما فکر می‌کنید «هر چه خراب شد رایگان درست می‌شود»، تیم سازنده فکر می‌کند «فقط خطاهای ثابت‌شده». این مقاله راهنمای فنی است و بندهای حقوقی (مسئولیت، جبران خسارت، جریمه) را باید با وکیل نهایی کنید.

چهار نوع کار پس از تحویل

استاندارد ISO/IEC/IEEE 14764:2022 دربارهٔ نگه‌داری نرم‌افزار، چهار نوع تغییر پس از تحویل را تعریف می‌کند (متن زیر از بخش پیش‌نمایش منتشرشدهٔ استاندارد خوانده شده است):

• اصلاحی (corrective): رفع مشکل‌های کشف‌شده پس از تحویل.
• تطبیقی (adaptive): قابل‌استفاده نگه‌داشتن نرم‌افزار در محیطی که تغییر می‌کند؛ نمونهٔ خود استاندارد ارتقای سیستم‌عامل است که برنامه‌ها را تحت تأثیر می‌گذارد.
• کمال‌بخش (perfective): بهبود برای کاربر و بهبود کارایی یا قابلیت نگه‌داری.
• پیشگیرانه (preventive): اصلاح خطاهای نهفته پیش از آنکه در سیستم زنده بروز کنند.

همین استاندارد دو مورد دیگر را هم جدا می‌شناسد: «افزودنی» (افزودن قابلیت) و «اضطراری» (تغییر برنامه‌ریزی‌نشده برای ادامهٔ کار سیستم تا زمان اصلاح قطعی). دربارهٔ افزودنی‌ها می‌گوید تغییرهای بزرگ‌تر می‌توانند توسعهٔ جدید باشند و میان تأمین‌کننده و دریافت‌کننده می‌شود دربارهٔ روش، منابع، توافق‌ها و سطح خدمت مذاکره کرد. این استاندارد جزئیات اجرای کار را مشخص نمی‌کند؛ چارچوب را می‌دهد، نه قرارداد آماده.

اشکال است یا قابلیت جدید؟

بیشترین اختلاف روی همین مرز است. پیشنهاد عملی نویسنده این است که برای هر درخواست دو پرسش را ثبت کنید: «رفتار فعلی با چه سندی (نیازمندی یا معیار پذیرش) مقایسه می‌شود؟» و «آیا خواستهٔ شما در آن سند بود؟». اگر معیارهای پذیرش تحویل به‌درستی مکتوب شده باشند، پاسخ این دو سؤال بیشتر اختلاف‌ها را روشن می‌کند؛ برای نوشتن آن‌ها آمادگی تولید نقطهٔ شروع خوبی است.

پایش و بکاپ: خدمت عملیاتی، نه «رفع اشکال»

پایش و بکاپ کارهای مداوم‌اند و باید جدا از رفع اشکال بند شوند. Google SRE در فصل پایش می‌گوید اگر فقط چهار شاخص را می‌توانید اندازه بگیرید، روی تأخیر، ترافیک، خطاها و اشباع تمرکز کنید. برای مفهوم کلی، Monitoring چیست؟ را ببینید. در بکاپ هم AWS در راهنمای Well-Architected می‌نویسد باید بازیابی به‌صورت دوره‌ای آزموده شود و ضدالگوها را فهرست می‌کند: فرض کردن اینکه بکاپ وجود دارد، یا فرض اینکه قابل‌بازیابی است و زمان و داده‌اش در حد RTO و RPO است. پس در قرارداد فقط «بکاپ می‌گیریم» ننویسید؛ تناوب، محل نگه‌داری، آزمون بازیابی و گزارش آن را هم بنویسید.

SLA دقیقاً چه چیزی است؟

در Google SRE، SLA یعنی قرارداد صریح یا ضمنی با کاربران که برای برآورده‌شدن یا نشدن SLOهایش پیامد دارد؛ پیامد معمولاً مالی است، مثل بازپرداخت یا جریمه. پس هر عددی که در متن «سطح خدمت» می‌آورید باید قابل‌اندازه‌گیری و قابل‌گزارش باشد و پیامدش مشخص باشد. هیچ عدد استاندارد جهانی را در این مقاله پیشنهاد نمی‌کنیم؛ بازه و درصد را باید با نیاز و بودجهٔ خودتان تعیین کنید.

جدول دامنهٔ پشتیبانی (الگوی پیشنهادی)

ستون «معمولاً» در این جدول توصیهٔ نویسنده است نه حکم استاندارد؛ هر پروژه تصمیم خودش را می‌گیرد، فقط باید مکتوب باشد.

پرسش‌هایی که پیش از امضا باید جواب بگیرید

1. درخواست پشتیبانی از چه کانالی و با چه اطلاعاتی ثبت می‌شود و رسید می‌گیرم؟
2. تفاوت اشکال و تغییر با چه سندی سنجیده می‌شود؟
3. کار اضطراری چه ساعت‌هایی پوشش داده می‌شود و اقدام موقت چیست؟
4. بکاپ کجا نگه‌داری می‌شود، چه کسی به آن دسترسی دارد و آخرین آزمون بازیابی چه زمانی بود؟
5. گزارش دوره‌ای شامل چه چیزهایی است؟
6. در پایان قرارداد، دانش و دسترسی‌ها چگونه منتقل می‌شوند؟

اگر می‌خواهید دامنهٔ پشتیبانی پروژهٔ خودتان را با یک تیم مرور کنید، می‌توانید توضیحی کوتاه در صفحهٔ شروع پروژه بفرستید؛ ارسال فرم تعهدی ایجاد نمی‌کند.

منابع و مراجع

• ISO/IEC/IEEE 14764:2022 — Software engineering — Software life cycle processes — Maintenance (نمونهٔ پیش‌نمایش) — ISO/IEC/IEEE (نمونهٔ منتشرشده در iTeh Standards)، ۲۰۲۲.
• Service Level Objectives (Chapter 4, Site Reliability Engineering) — Google SRE.
• Monitoring Distributed Systems (Chapter 6, Site Reliability Engineering) — Google SRE.
• REL09-BP04 Perform periodic recovery of the data to verify backup integrity and processes — AWS Well-Architected Framework.