Skip to main content خانه خدمات پروژهها پشتیبانی تماس جستوجو
ساختار صفحه، تصاویر و اجزای تعاملی در حال بارگذاری هستند.
تماس واتساپ شروع پروژه
پشتیبانی نرم افزار اختصاصی؛ راهنمای کامل | آرکوتک
اشتراکگذاری مقاله خانه / مجله / نرم افزار اختصاصی نرم افزار اختصاصی پشتیبانی نرم افزار اختصاصی؛ بعد از تحویل چه خدماتی لازم است؟ پشتیبانی نرم افزار اختصاصی بعد از انتشار شامل رفع خطا، مانیتورینگ، بکاپ، امنیت، بهینهسازی و توسعه نسخههای بعدی است. در این راهنما یک مدل پشتیبانی حرفهای را بررسی میکنیم.
A
تیم تحریریه آرکوتک تحریریه مهندسی محصول
۵ شهریور ۱۴۰۵ · ۱۱ دقیقه مطالعه
پشتیبانی نرم افزار اختصاصی و نگهداری و توسعه سیستم بعد از انتشار خلاصه اجرایی پشتیبانی نرم افزار اختصاصی بعد از انتشار شامل رفع خطا، مانیتورینگ، بکاپ، امنیت، بهینهسازی و توسعه نسخههای بعدی است. در این راهنما یک مدل پشتیبانی حرفهای را بررسی میکنیم.
# پشتیبانی نرم افزار اختصاصی؛ بعد از تحویل چه خدماتی لازم است؟
پشتیبانی نرم افزار اختصاصی از زمانی اهمیت واقعی پیدا میکند که کاربران وارد سیستم شوند و نرم افزار در محیط واقعی کسبوکار مورد استفاده قرار بگیرد.
انتشار نسخه اول پایان پروژه نیست.
در بسیاری از محصولات، Launch در واقع شروع مرحلهای جدید است؛ مرحلهای که در آن داده واقعی، رفتار کاربران، مشکلات عملکردی، نیازهای جدید و شرایط زیرساخت مشخص میشوند.
ممکن است بعد از انتشار نیاز باشد:
یک خطا برطرف شود. سرعت یک گزارش افزایش پیدا کند. فضای سرور توسعه داده شود. Backup بررسی شود. Dependencyها بهروزرسانی شوند. Workflow جدیدی اضافه شود. تعداد کاربران افزایش پیدا کند. Integration جدیدی ایجاد شود. به همین دلیل هنگام سفارش یک سیستم، فقط نحوه ساخت آن مهم نیست؛ باید بدانیم بعد از تحویل چه کسی مسئول نگهداری و توسعه خواهد بود.
در این راهنما بررسی میکنیم پشتیبانی نرم افزار اختصاصی شامل چه خدماتی است و یک مدل Support حرفهای چگونه طراحی میشود.
چرا نرم افزار بعد از تحویل به پشتیبانی نیاز دارد؟ نرم افزار یک محصول ثابت نیست.
محیط اطراف آن دائماً تغییر میکند.
برای مثال:
مرورگرها Update میشوند. سیستمعاملها تغییر میکنند. APIهای خارجی تغییر میکنند. حجم دیتابیس افزایش پیدا میکند. تعداد کاربران بیشتر میشود. نیازهای کسبوکار تغییر میکنند. Libraryهای جدید منتشر میشوند. مسائل امنیتی جدید کشف میشوند. بنابراین نرم افزاری که چند سال هیچ نگهداریای دریافت نکند، ممکن است بهمرور از نظر عملکرد، امنیت و سازگاری دچار مشکل شود.
تفاوت پشتیبانی با توسعه چیست؟ این تفاوت باید از ابتدا مشخص باشد.
پشتیبانی معمولاً شامل نگهداری عملکردی سیستم موجود است.
برای مثال:
رفع Bug بررسی Error مانیتورینگ Backup بررسی زیرساخت بهروزرسانی امنیتی توسعه به معنی اضافهکردن قابلیت یا رفتار جدید است.
مثلاً:
«سیستم پیامک خراب شده است.»
ممکن است Support محسوب شود.
اما:
«میخواهیم علاوه بر پیامک، سیستم WhatsApp نیز اضافه شود.»
یک Feature جدید است.
مرز این دو باید در قرارداد طراحی نرم افزار اختصاصی شفاف تعریف شود.
مطالعه بعدی
مقالههای مرتبط گام بعدی ایده بعدی را به یک محصول قابل رشد تبدیل کنیم از تعریف مسئله تا طراحی، توسعه و رشد؛ مسیر فنی پروژه را شفاف شروع کنید.
شروع گفتوگو ←
۱. رفع Bug یکی از اصلیترین خدمات پشتیبانی، رفع خطاهای نرم افزار است.
حتی با Testing دقیق، بعضی مشکلات فقط در شرایط واقعی ظاهر میشوند.
ترکیب خاصی از دادهها مرورگر خاص حجم بالای اطلاعات رفتار غیرمنتظره کاربر اختلال API خارجی یک تیم Support حرفهای باید فرایند مشخصی برای:
ثبت مشکل بررسی اولویتبندی رفع تست انتشار اصلاح
تفاوت Bug با درخواست تغییر فرض کنید طبق Scope کاربر باید بتواند فایل PDF بارگذاری کند اما Upload کار نمیکند.
اما اگر کارفرما بعداً بخواهد:
«امکان ویرایش PDF داخل سیستم هم اضافه شود.»
تفکیک این دو موضوع برای مدیریت هزینه و انتظار کارفرما ضروری است.
۲. Monitoring یکی از مهمترین بخشهای پشتیبانی نرم افزار اختصاصی ، مانیتورینگ است.
در یک سیستم حرفهای بهتر است تیم فنی قبل از تماس کاربران متوجه بعضی مشکلات شود.
Monitoring میتواند مواردی مانند:
در دسترس بودن سیستم Error Rate CPU Memory Disk Database Response Time برای سامانههای حساس، Alert نیز میتواند تعریف شود تا مشکل مهم سریعتر بررسی شود.
۳. Error Tracking بعضی Errorها ممکن است فقط برای یک کاربر یا یک سناریوی خاص رخ دهند.
اگر سیستم Error Tracking مناسبی داشته باشد، تیم فنی میتواند اطلاعات لازم برای بررسی خطا را دریافت کند.
کدام Endpoint؟ چه زمانی؟ چه Errorی؟ کدام نسخه؟ چه Stack Traceی؟ این اطلاعات زمان تشخیص مشکل را کاهش میدهند.
۴. Backup پشتیبانی حرفهای بدون Backup کامل نیست.
Database فایلهای کاربران تنظیمات Configurationهای مهم اما فقط گرفتن Backup کافی نیست.
Backup چند وقت یک بار گرفته میشود؟ کجا ذخیره میشود؟ چند نسخه نگهداری میشود؟ چه کسی به آن دسترسی دارد؟ چگونه Restore میشود؟
تست بازیابی Backup ممکن است Backup سالها گرفته شود اما در زمان نیاز مشخص شود فایل خراب است یا فرایند Restore مشکل دارد.
به همین دلیل در سیستمهای مهم، بازیابی نیز باید در دورههای مناسب بررسی شود.
۵. نگهداری امنیتی یکی دیگر از بخشهای مهم Support، امنیت است.
نرم افزار ممکن است در طول زمان نیازمند:
Update Dependency تغییر Configuration اصلاح Permission بررسی Credential تمدید Certificate رفع آسیبپذیری
۶. بهروزرسانی Dependencyها Frameworkها و Packageهایی که در پروژه استفاده شدهاند، در طول زمان نسخههای جدید منتشر میکنند.
اما Update کورکورانه نیز تصمیم درستی نیست.
هر تغییر باید بررسی و تست شود.
Breaking Change داشته باشد. رفتار سیستم را تغییر دهد. با Package دیگری ناسازگار باشد. بنابراین Dependency Management باید کنترلشده انجام شود.
۷. نگهداری زیرساخت پشتیبانی فقط مربوط به Code نیست.
Server و Infrastructure نیز نیازمند نگهداری هستند.
سیستمعامل Update شود. فضای Disk افزایش پیدا کند. SSL تمدید شود. منابع سرور افزایش پیدا کنند. Logهای قدیمی مدیریت شوند. Database Tune شود. اگر Hosting توسط تیم دیگری مدیریت میشود، مسئولیتها باید کاملاً مشخص باشند.
نرم افزاری که در روز اول سریع است ممکن است بعد از دو سال کند شود.
دیتابیس بزرگتر شده است. کاربران بیشتر شدهاند. گزارشهای بیشتری ساخته شدهاند. فایلها افزایش پیدا کردهاند. Featureهای جدید اضافه شدهاند. بنابراین بخشی از نگهداری میتواند شامل Performance Optimization باشد.
Dashboard دیر Load میشود. Search کند شده است. گزارش چند دقیقه زمان میبرد. API Response کند است. CPU دائماً درگیر است. در این حالت باید علت اصلی شناسایی شود.
راهحل الزاماً خرید سرور بزرگتر نیست.
گاهی Query، Cache یا معماری یک بخش نیاز به بهینهسازی دارد.
۹. Database Maintenance دیتابیس معمولاً با گذشت زمان رشد میکند.
ممکن است میلیونها رکورد، فایل یا Log در سیستم ایجاد شوند.
نگهداری دیتابیس میتواند شامل:
بررسی Queryهای کند Index Storage Archive Backup Data Integrity طراحی مناسب دیتابیس از ابتدا هزینه این مرحله را کاهش میدهد، اما نگهداری همچنان ضروری است.
۱۰. نگهداری Integrationها درگاه پرداخت SMS حسابداری CRM ERP Email Map AI این سرویسها ممکن است API، محدودیت یا روش Authentication خود را تغییر دهند.
بنابراین بخشی از Support میتواند شامل نگهداری Integrationها باشد.
اگر سرویس خارجی قطع شود چه؟ معماری خوب باید تا حد امکان رفتار مناسبی در زمان اختلال سرویس خارجی داشته باشد.
مثلاً اگر سرویس پیامک قطع شود، نباید کل عملیات اصلی سیستم متوقف شود مگر اینکه واقعاً وابسته به آن باشد.
۱۱. مدیریت Logها Logها برای Debug و Monitoring مفید هستند، اما اگر بدون مدیریت ذخیره شوند ممکن است:
فضای Disk را پر کنند. پیدا کردن اطلاعات را سخت کنند. اطلاعات غیرضروری نگهداری کنند. بنابراین باید سیاست مناسبی برای:
سطح Log مدت نگهداری Archive حذف
۱۲. پشتیبانی کاربران در بعضی پروژهها Support فقط فنی نیست.
ممکن است کاربران نیز درباره روش استفاده از سیستم سؤال داشته باشند.
بسته به قرارداد، خدمات میتوانند شامل:
راهنمای استفاده پاسخ به سؤال آموزش مستندات ویدیو در سیستمهای سازمانی بهتر است یک نفر از سمت کارفرما بهعنوان Admin یا Super User آموزش کاملتری دریافت کند.
۱۳. مدیریت درخواستهای جدید کاربران پس از مدتی استفاده معمولاً پیشنهادهای جدیدی ارائه میکنند.
«این فیلتر را اضافه کنیم.» «این گزارش را لازم داریم.» «این مرحله خودکار شود.» «نسخه موبایل بسازیم.» بهتر است تمام این درخواستها فوراً وارد Development نشوند.
ثبت شوند. ارزش آنها بررسی شود. اولویتبندی شوند. هزینه و زمان تخمین زده شود. وارد Roadmap شوند. این روش باعث میشود محصول بر اساس نیاز واقعی رشد کند.
۱۴. توسعه نسخههای بعدی بسیاری از نرم افزارهای موفق نسخه اول نسبتاً محدودی دارند.
سپس بر اساس تجربه کاربران توسعه پیدا میکنند.
نسخه ۱
نسخه ۲
نسخه ۳
نسخه ۴
نسخه ۵ این مدل میتواند نسبت به ساخت تمام قابلیتها در نسخه اول، ریسک پروژه را کاهش دهد.
ارتباط پشتیبانی با مقیاسپذیری ممکن است نرم افزار در ابتدا ۵۰ کاربر داشته باشد و بعد از چند سال به ۵۰۰۰ کاربر برسد.
در این مسیر ممکن است نیاز باشد:
سرور تغییر کند. Cache اضافه شود. Storage جدا شود. Queue توسعه پیدا کند. Database Scale شود. بنابراین Support فقط حفظ وضعیت فعلی نیست؛ گاهی آمادهکردن سیستم برای رشد نیز هست.
SLA چیست؟ برای نرم افزارهای مهم میتوان Service Level Agreement تعریف کرد.
SLA مشخص میکند برای انواع مختلف مشکل چه سطح خدماتی ارائه میشود.
Critical کل سیستم از دسترس خارج شده است.
High یک قابلیت اصلی کار نمیکند.
Medium یک قابلیت فرعی مشکل دارد.
Low مشکل ظاهری یا درخواست کماهمیت.
هر سطح میتواند زمان پاسخ و بررسی متفاوتی داشته باشد.
Response Time با Resolution Time فرق دارد Response Time یعنی تیم در چه مدتی بررسی مسئله را شروع میکند.
Resolution Time یعنی چه زمانی مشکل کاملاً برطرف میشود.
بعضی مشکلات پیچیده ممکن است سریع بررسی شوند اما رفع نهایی آنها زمان بیشتری نیاز داشته باشد.
این تفاوت بهتر است در قرارداد Support روشن باشد.
مدلهای رایج پشتیبانی نرم افزار
پشتیبانی دورهای قرارداد ماهانه، سهماهه یا سالانه برای نگهداری سیستم.
این مدل برای نرم افزارهای فعال مناسب است.
پشتیبانی بر اساس ساعت تعداد مشخصی ساعت Development یا Support در ماه در نظر گرفته میشود.
پشتیبانی موردی هر درخواست جداگانه بررسی و قیمتگذاری میشود.
این روش برای سیستمهایی که تغییر و استفاده کمی دارند میتواند مناسب باشد.
انتخاب مدل به میزان اهمیت و فعالیت نرم افزار بستگی دارد.
نرم افزار حیاتی چه نوع پشتیبانی نیاز دارد؟ فروش را متوقف میکند. عملیات شرکت را مختل میکند. مشتریان را تحت تأثیر قرار میدهد. باید سطح Support بالاتری داشته باشد.
در چنین سیستمهایی ممکن است مواردی مانند:
Monitoring مداوم Backup قویتر Alert Response Time مشخص Redundancy اهمیت بیشتری داشته باشند.
Cost of Downtime هنگام بررسی هزینه Support فقط مبلغ قرارداد پشتیبانی را نبینید.
باید هزینه توقف نرم افزار را نیز محاسبه کنید.
فرض کنید یک فروشگاه آنلاین یا سامانه عملیاتی برای ۶ ساعت از دسترس خارج شود.
ممکن است هزینه آن بسیار بیشتر از هزینه سالانه Monitoring مناسب باشد.
آیا تیم سازنده باید پشتیبانی را انجام دهد؟ نه الزاماً، اما معمولاً در دوره اولیه مزایایی دارد.
تیمی که نرم افزار را ساخته:
معماری را میشناسد. Codebase را میشناسد. تصمیمهای فنی را میداند. Database را میشناسد. بنابراین معمولاً انتقال Support به تیم جدید نیازمند Documentation و Handover مناسب است.
اگر بخواهیم تیم پشتیبانی را عوض کنیم چه؟ این امکان باید از ابتدا در معماری پروژه وجود داشته باشد.
تحویل سورس Repository مستندات دسترسی سرور Credentialها Database Documentation وابستگی پروژه به یک فرد یا تیم خاص را کاهش میدهند.
Documentation چه نقشی در پشتیبانی دارد؟ مستندات مناسب میتوانند زمان بررسی مشکلات و ورود توسعهدهندگان جدید را کاهش دهند.
برای پروژههای بزرگ ممکن است شامل:
Architecture API Database Deployment Environment Integration Admin Guide هر پروژه به سطح متفاوتی از Documentation نیاز دارد.
هزینه پشتیبانی نرم افزار اختصاصی چگونه تعیین میشود؟ قیمت Support میتواند به عوامل مختلفی وابسته باشد:
اندازه سیستم تعداد کاربران اهمیت Availability حجم زیرساخت تعداد Integrationها سطح Monitoring SLA ساعات پشتیبانی حجم تغییرات
چه چیزی باید داخل قرارداد پشتیبانی باشد؟ مواردی که بهتر است مشخص شوند:
مدت قرارداد ساعات Support کانال ارتباطی Response Time محدوده خدمات Bug Definition Feature Definition Backup Responsibility Hosting Responsibility Monitoring هزینه Feature جدید شرایط تمدید شفافیت این موارد از اختلاف بعدی جلوگیری میکند.
چه زمانی باید نرم افزار را بازنویسی کنیم؟ همه مشکلات با Maintenance حل نمیشوند.
گاهی سیستم آنقدر قدیمی یا معماری آن محدود شده است که ادامه اصلاحات هزینه زیادی ایجاد میکند.
افزودن هر Feature بسیار دشوار است. سیستم دائماً خراب میشود. Dependencyها دیگر قابل Update نیستند. Performance بسیار ضعیف شده است. تکنولوژی اصلی دیگر پشتیبانی نمیشود. اما Rewrite تصمیم بسیار مهمی است و نباید فقط به دلیل «قدیمی بودن کد» انجام شود.
ابتدا باید هزینه نگهداری سیستم فعلی با هزینه و ریسک بازنویسی مقایسه شود.
پشتیبانی چگونه به رشد محصول کمک میکند؟ Support فقط «تعمیر نرم افزار» نیست.
اطلاعاتی که در دوره استفاده جمعآوری میشوند میتوانند مشخص کنند:
کاربران کجا مشکل دارند. کدام Feature بیشتر استفاده میشود. چه Workflowی کند است. چه گزارشی لازم است. کدام Automation ارزش بیشتری دارد. به همین دلیل پشتیبانی خوب میتواند ورودی مهمی برای Roadmap محصول باشد.
رویکرد آرکوتک برای پشتیبانی نرم افزار اختصاصی در آرکوتک، پشتیبانی باید متناسب با اهمیت واقعی هر سیستم طراحی شود.
یک نرم افزار کوچک داخلی ممکن است به مدل سادهتری نیاز داشته باشد، در حالی که یک پلتفرم عملیاتی یا محصول آنلاین میتواند به:
Monitoring Backup Security Update Error Tracking Performance Review توسعه مستمر هدف این است که نرم افزار بعد از Launch به یک سیستم رهاشده تبدیل نشود و مسیر نگهداری و توسعه آن از ابتدا مشخص باشد.
جمعبندی پشتیبانی نرم افزار اختصاصی بخش مهمی از چرخه عمر یک محصول است.
بعد از انتشار، نرم افزار ممکن است به:
رفع خطا Monitoring Backup Security Update Infrastructure Maintenance Performance Optimization Integration Maintenance توسعه نسخههای جدید بنابراین هنگام سفارش نرم افزار فقط سؤال نکنید:
«چه زمانی پروژه تحویل میشود؟»
بلکه سؤال مهمتر این است:
«بعد از تحویل، این سیستم چگونه نگهداری و توسعه پیدا میکند؟»
اگر نرم افزار قرار است برای سالها بخشی از زیرساخت کسبوکار شما باشد، مسیر پشتیبانی باید از همان ابتدای طراحی نرم افزار اختصاصی مشخص شود.
سوالات متداول
پشتیبانی نرم افزار اختصاصی شامل چه خدماتی است؟ بسته به قرارداد میتواند شامل رفع Bug، Monitoring، Backup، نگهداری امنیتی، بهینهسازی Performance و بررسی زیرساخت باشد.
توسعه قابلیت جدید جزو پشتیبانی است؟ معمولاً Feature جدید جدا از رفع Bug و نگهداری سیستم محسوب میشود، مگر اینکه قرارداد مدل دیگری تعریف کرده باشد.
نرم افزار تا چه مدت به پشتیبانی نیاز دارد؟ تا زمانی که نرم افزار در حال استفاده است، نوعی نگهداری فنی لازم خواهد بود؛ سطح آن بر اساس اهمیت سیستم متفاوت است.
SLA در پشتیبانی نرم افزار چیست؟ SLA سطح خدمات، دستهبندی مشکلات و زمان پاسخ مورد انتظار برای هر نوع Incident را مشخص میکند.
آیا میتوان تیم پشتیبانی را بعداً تغییر داد؟ بله؛ به شرط اینکه سورس، مستندات، دسترسیهای زیرساخت و اطلاعات فنی پروژه به شکل مناسبی در اختیار مالک سیستم باشند.
#پشتیبانی نرم افزار اختصاصی #نگهداری نرم افزار #پشتیبانی نرم افزار #توسعه نرم افزار اختصاصی #مانیتورینگ نرم افزار #نگهداری وب اپلیکیشن #آرکوتک
A
درباره نویسنده تیم تحریریه آرکوتک تحریریه مهندسی محصول؛ تولید محتوای روشن، فنی و قابل استفاده برای تصمیمهای واقعی کسبوکار.
آخرین بازبینی: ۵ شهریور ۱۴۰۵
03