تأسیس ۲۰۰۸ · نسخهٔ دیجیتال · 19 ژوئن 2026

SMB IT Journal

منبع فناوری اطلاعات برای کسب‌وکارهای کوچک

فارسی
بهترین روش‌ها

انتخاب نسخه‌های نرم‌افزار برای استقرار

چیزی که اغلب در محافل فناوری اطلاعات مورد بحث قرار می‌گیرد «کدام نسخه از نرم‌افزار باید نصب شود» است. این می‌تواند برای یک پایگاه داده، یک برنامه، فریمور یا، احتمالاً اغلب، سیستم‌های عامل اعمال شود، و با پایان قریب‌الوقوع پشتیبانی از Windows XP این موضوع به اوج خود رسیده است.

به‌طور مؤثر دو طرف برای این بحث وجود دارد. یک طرف بر این باور است که همیشه باید از جدیدترین و به‌اصطلاح بهترین نرم‌افزار استفاده شود. طرف دیگر معتقد است که نرم‌افزار باید بالغ شود و رویکرد «منتظر بمانیم و ببینیم» را اتخاذ می‌کند یا حتی هر نسخه را به‌عنوان یک محصول متفاوت و نه یک پیوستار توسعه در نظر می‌گیرد.

هر دو رویکرد مزایایی دارند و هیچ‌کدام نباید کاملاً بدون دیگری وجود داشته باشد. به‌روزرسانی کورکورانه نرم‌افزار بی‌ملاحظه عاقلانه نیست و اجتناب از وصله‌ها و به‌روزرسانی‌ها بدون دلیل هم عاقلانه نیست. توجه دقیق به عوامل و همدلی با فرآیند توسعه نرم‌افزار در هنگام تصمیم‌گیری مهم است.

اول، دو سناریوی کاملاً متفاوت وجود دارد که باید بررسی شوند. یکی به‌روزرسانی نرم‌افزار فعلی موجود است. فرض بر این است که وضعیت فعلی «کار می‌کند» با احتمال قابل قبول که «کار کردن» ممکن است شامل یک آسیب‌پذیری امنیتی کشف‌شده باشد که نیاز به به‌روزرسانی برای بستن آن دارد. سناریوی دیگر یک استقرار جدید است که در آن هیچ‌چیزی وجود ندارد و ما از صفر شروع می‌کنیم.

بیایید با حالت دوم شروع کنیم، زیرا ارائه راهنمایی در آن بسیار آسان‌تر است.

در مورد استقرارهای جدید نرم‌افزار (یا سیستم‌های عامل جدید)، همیشه از نسخه فعلی و جدیدترین نرم‌افزار استفاده کنید مگر اینکه محدودیت فناوری شناخته‌شده‌ای وجود داشته باشد که از آن جلوگیری کند — مانند باگ‌های شناخته‌شده یا ناسازگاری‌های نرم‌افزاری.

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

توسعه نرم‌افزار تقریباً یک پیوستار است. فرآیندهای توسعه معمولی نرم‌افزار جدید را بر پایه نرم‌افزار قدیمی می‌سازند، هم مستقیماً (با ایجاد به‌روزرسانی‌ها به یک پایگاه کد موجود) و هم به‌طور غیرمستقیم (با بازسازی بر اساس دانش کسب‌شده از ساختن نسخه قبلی نرم‌افزار). ایده این است که هر نسخه بعدی از نرم‌افزار از نسخه قبلی آن برتر است. البته این تضمینی نیست، مفاهیمی مانند خطاهای رگرسیون و توسعه بد وجود دارد، اما به‌طور کلی، نرم‌افزار با گذر زمان بهتر می‌شود — به‌ویژه وقتی از نرم‌افزار درجه سازمانی استفاده شده در کسب‌وکارها و تحت توسعه فعال صحبت می‌کنیم. نرم‌افزار جدید نه تنها مرحله بعدی نرم‌افزار قدیمی است، بلکه در تقریباً همه موارد، وضعیت فعلی وصله‌ها، رفع باگ‌ها، به‌روزرسانی‌ها و در صورت لزوم تغییرات در رویکرد یا تکنیک را نشان می‌دهد. نرم‌افزار جدید که از فروشگاه‌های با کیفیت می‌آید، تقریباً به‌طور انحصاری از نرم‌افزار قدیمی بهتر است. نرم‌افزار تکامل می‌یابد و بالغ می‌شود.

فراتر از کیفیت خود نرم‌افزار، مفهوم سرمایه‌گذاری در آینده وجود دارد. نرم‌افزار چیزی نیست که بتوان برای همیشه روی قفسه گذاشت. باید تا حدی به‌روز بماند یا کار کردن را متوقف می‌کند زیرا پلتفرمی که روی آن اجرا می‌شود تغییر می‌کند، برخی مصنوعات جدید به نور می‌رسند، حفره‌های امنیتی کشف می‌شوند یا نیازها تغییر می‌کنند. نصب نرم‌افزار قدیمی به این معنی است که سرمایه‌گذاری در گذشته است، سرمایه‌گذاری در نصب، یادگیری، استفاده و پشتیبانی از فناوری قدیمی. به این «بدهی فنی» می‌گویند. این فناوری قدیمی ممکن است سال‌ها یا حتی دهه‌ها دوام بیاورد، اما نرم‌افزار قدیمی با گذر زمان ارزش خود را از دست می‌دهد و پشتیبانی از آن هم برای فروشندگان، اگر ادامه دهند، و هم برای کاربران نهایی که باید از آن پشتیبانی کنند، هزینه‌بر‌تر می‌شود.

مفهوم مشابه بدهی فنی برای فروشندگان نرم‌افزار مورد نظر نیز اعمال می‌شود. هزینه بسیار زیادی برای ایجاد نرم‌افزار و به‌ویژه برای نگهداری نسخه‌های متعدد آن نرم‌افزار وجود دارد. فروشندگان نرم‌افزار انگیزه زیادی برای کاهش پشتیبانی از نسخه‌های قدیمی دارند تا منابع را بر روی انتشارهای جاری نرم‌افزار متمرکز کنند (این دلیل اصلی است که چرا استقرارهای SaaS بسیار محبوب هستند؛ فروشنده نسخه‌های موجود را کنترل می‌کند و می‌تواند نسخه‌های قدیمی را از طریق به‌روزرسانی‌ها حذف کند). اگر مشتریان نیاز به پشتیبانی از نسخه‌های قدیمی داشته باشند، هزینه باید جایی جذب شود و اغلب هم در تأثیر مالی بر تمام مشتریان و هم در کاهش تمرکز بر محصول جدید جذب می‌شود زیرا تیم‌های توسعه باید برای پشتیبانی از وصله‌گذاری نسخه‌های قدیمی و همچنین توسعه جدید تقسیم شوند. هرچه تلاش بیشتری برای نسخه‌های قدیمی صرف شود، تلاش کمتری می‌تواند برای بهبودهای جدید صورت گیرد.

در چارچوب آنچه گفتم، مهم است که در مورد بلوغ کد صحبت کنیم. اغلب بلوغ کد به‌عنوان دلیلی برای استقرار «کد قدیمی» ذکر می‌شود، اما فکر می‌کنم این یک سوءتفاهم IT از فرآیندهای توسعه نرم‌افزار است. اگر به یک خط کد منتشرشده فکر کنیم، فقط به این دلیل که منتشر شده و در حال استفاده است، واقعاً آن را بالغ‌تر نمی‌کند. کد در طبیعت تغییر نمی‌کند، فقط آنجا می‌نشیند. بلوغ آن در روزی که منتشر می‌شود «قفل» می‌شود. اگر وصله شود، آنگاه بله، پس از انتشار «بالغ» می‌شود. نسخه‌های بعدی همان نرم‌افزار، بر اساس همان پایگاه کد اما به‌روزتر، واقعاً کد «بالغ‌تر» است زیرا بیشتر مورد بررسی، به‌روزرسانی، آزمایش و غیره قرار گرفته است نسبت به انتشار اولیه همان کد.

این برخلاف انتظار است، مثلاً در مورد یک ماشین که هر انتشار چیز تازه‌ای با فرصت‌های جدید برای مشکلات مکانیکی و نگرانی‌های قابلیت اطمینان متفاوت است — که انتظار چند سال فرصت می‌دهد تا ببینید چه مشکلات قابلیت اطمینانی آشکار می‌شود. نرم‌افزار این‌گونه نیست. بنابراین مفهوم خواستن نرم‌افزار بالغ‌تر شما را به استقرار «جدیدترین و بهترین» به‌جای «آزموده و مطمئن» سوق می‌دهد.

اگر به شماره نسخه‌های نرم‌افزار مانند سن فکر کنیم، این موضوع روشن می‌شود. Linux 3.1 از نظر بلوغ نرم‌افزاری بسیار قدیمی‌تر از Linux 2.4 است. یک دهه توسعه اضافی دارد.

بیایید از یک مثال دنیای واقعی که امروز بسیار مرتبط است استفاده کنیم. شما در یک فروشگاه هستید که می‌خواهید اولین سرور(های) خود را نصب کنید. Windows Server 2012 R2 تازه منتشر شده است. آیا باید Windows Server 2008، ‏2008 R2 (2010)، Server 2012 یا Server 2012 R2 (اواخر ۲۰۱۳) را نصب کنید؟

برای بسیاری از فروشگاه‌ها، این به نظر می‌رسد که درباره دو تا چهار محصول کاملاً متفاوت صحبت می‌کنیم که احتمالاً دلایل مختلفی برای انتخاب هر کدام دارند. این تا حد زیادی نادرست است. هر نسخه جدیدتر صرفاً یک ارتقاء، به‌روزرسانی، وصله و افزایش ویژگی نسبت به نسخه قبلی است. هر یک، به نوبه خود، پیشرفته‌تر و بالغ‌تر از قبلی است. هر نسخه جدید از کار انجام‌شده در انتشار اولیه پیشین خود و همچنین رفع باگ‌ها، وصله‌ها و اضافه‌شدن ویژگی‌های انجام‌شده در فاصله بین انتشار اولیه و انتشار جانشین بهره می‌برد. در واقع هر انتشار جدید یک «انتشار جزئی» از قبلی است. اگر به جای نام‌های بازاریابی، به شماره نسخه هسته نگاه کنیم، ممکن است معنا پیدا کند.

Windows Server 2008 برابر Windows NT 6.0 بود. Windows Server 2008 R2 برابر Windows NT 6.1 بود، آشکارا یک بازبینی جزئی یا حتی یک «وصله» از انتشار قبلی. Windows Server 2012 برابر Windows NT 6.2 بود و Windows Server 2012 R2 فعلی ما برابر Windows NT 6.3 است. اگر از شماره‌های نسخه به‌جای نام‌های بازاریابی استفاده کنیم، تقریباً دیوانه‌وار به نظر می‌رسد که عمداً یک نسخه قدیمی، کمتر بالغ، کمتر به‌روزرسانی‌شده و کمتر وصله‌شده را نصب کنیم. ما می‌خواهیم آخرین به‌روزرسانی‌ها، آخرین رفع باگ‌ها و آخرین مسائل امنیتی که مورد توجه قرار گرفته را داشته باشیم.

برای استقرارهای جدید نرم‌افزار، هرچه نرم‌افزار نصب‌شده جدیدتر باشد، فرصت بهتری برای بهره‌برداری از آخرین ویژگی‌ها و بیشترین زمان قبل از اینکه منسوخ شدن اجتناب‌ناپذیر تأثیر خود را بگذارد، فراهم است. تمام نرم‌افزارها کهنه می‌شوند پس نصب نرم‌افزار جدیدتر بهترین شانس را می‌دهد که آن نرم‌افزار برای طولانی‌ترین زمان ممکن دوام بیاورد. بهترین انعطاف‌پذیری را برای آینده ناشناخته فراهم می‌کند.

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

این ما را به سناریوی دیگری می‌رساند که در آن نرم‌افزار موجود را به‌روزرسانی می‌کنیم. البته این سناریو کاملاً متفاوت از یک نصب تازه است و عوامل بسیار بیشتری درگیر هستند.

یکی از بزرگ‌ترین عوامل برای اکثر شرایط مسئله مجوزدهی است. به‌روزرسانی منظم نرم‌افزار ممکن است هزینه‌های مجوزدهی را به همراه داشته باشد که باید در معادله مزایا و هزینه‌ها لحاظ شود. برخی محصولات، مانند اکثر نرم‌افزارهای متن‌باز، این هزینه را ندارند و می‌توانند به‌محض در دسترس بودن نسخه‌های جدید به‌روزرسانی شوند.

عامل واقعاً بزرگ دیگر در به‌روزرسانی نرم‌افزار هزینه تلاش انسانی برای به‌روزرسانی است — بر خلاف یک نصب تازه، که در آن تلاش نصب به‌طور مؤثر سربه‌سر بین نرم‌افزار قدیمی و جدید است. در واقع، نرم‌افزار جدید به دلیل پیشرفت‌ها و پیشرفت‌های فناوری تمایل دارد نصب آسان‌تری داشته باشد. حفظ یک نسخه واحد از نرم‌افزار به مدت یک دهه به این معنی است که منابعی در طول آن زمان به فرآیندهای ارتقاء اختصاص نیافتند. ارتقاء سالانه در طول آن زمان به این معنی است که منابع ده بار برای اجرای ارتقاءهای جداگانه استفاده شدند. این موجب می‌شود که به‌روزرسانی توجیه هزینه‌ای سخت‌تری داشته باشد. اما فراتر از تلاش خود فرآیند به‌روزرسانی، آموزش مستمر مورد نیاز برای کاربران نهایی که مجبور خواهند بود تغییرات بیشتر و بیشتری را از طریق ارتقاءهای مداوم تجربه کنند نیز وجود دارد.

این ممکن است به‌روزرسانی نرم‌افزار را منفی جلوه دهد، اما این‌طور نیست. این صرفاً معادله‌ای است که هر طرف باید سنجیده شود. به‌روزرسانی‌های منظم اغلب به معنای تغییرات کوچک و تدریجی به‌جای جهش‌های بزرگ است که به کاربران نهایی امکان می‌دهد به‌طور طبیعی‌تر سازگار شوند. به‌روزرسانی‌های منظم به معنای آسان‌تر و قابل پیش‌بینی‌تر بودن فرآیندهای به‌روزرسانی است. به‌روزرسانی‌های منظم به معنای مدیریت همیشگی بدهی فنی و دسترسی سریع‌تر به مزایای نسخه‌های جدیدتر که ممکن است ویژگی‌ها، کارایی‌ها یا بهبودهای امنیتی باشند و اجازه می‌دهد که برای مدت طولانی‌تری مورد استفاده قرار گیرند، است.

اما از آنچه از دو سناریوی بالا آموختیم، یک نکته مهم دیگر نیز وجود دارد. وقتی تصمیم برای انجام یک به‌روزرسانی گرفته شد، سؤال اغلب «به کدام نسخه به‌روزرسانی کنیم؟» است. در واقع، هر به‌روزرسانی که بیشتر از یک فرآیند وصله‌گذاری استاندارد باشد، مثل یک تصمیم خرید «نرم‌افزار جدید» کوچک است و منطق اینکه چرا «همیشه» جدیدترین نسخه موجود را هنگام نصب تازه نصب می‌کنیم اینجا هم اعمال می‌شود. پس هنگام انجام یک به‌روزرسانی، تقریباً همیشه باید تا جایی که می‌توانیم به‌روزرسانی کنیم — امیدوارانه به نسخه فعلی.

برای اعمال مثال Microsoft مجدداً، می‌توانیم سازمانی را در نظر بگیریم که امروز Windows XP را مستقر کرده است. کسب‌وکار تصمیم می‌گیرد که در یک چرخه به‌روزرسانی به نسخه جدیدتر سرمایه‌گذاری کند، نه فقط وصله‌گذاری ادامه‌دار. چندین نسخه از پلتفرم دسکتاپ Windows وجود دارند که هنوز تحت پشتیبانی فعال Microsoft هستند. این‌ها شامل Windows Vista، Windows 7، Windows 8 و Windows 8.1 می‌شوند. به‌روزرسانی به یکی از نسخه‌های کمتر فعلی منجر به کمتر زمان قبل از پایان عمر آن نسخه می‌شود که ریسک سازمانی را افزایش می‌دهد، استفاده از نسخه‌های قدیمی‌تر به معنای ادامه سرمایه‌گذاری در فناوری‌های قبلاً قدیمی است که به معنای افزایش بدهی فنی و دسترسی کمتر به ویژگی‌های جدید است که ممکن است پس از در دسترس بودن مفید باشند. در این مثال خاص، نسخه‌های جدیدتر همچنین امن‌تر در نظر گرفته می‌شوند و منابع سخت‌افزاری کمتری نیاز دارند.

هر کسب‌وکاری باید تعادل مناسب را برای خود در چرخه‌های به‌روزرسانی نرم‌افزار موجود پیدا کند. هر کسب‌وکار و هر بسته نرم‌افزاری متفاوت است. نرم‌افزارهای سازمانی مانند Microsoft Windows، Microsoft Office یا یک پایگاه داده Oracle این مدل‌ها را به‌خوبی دنبال می‌کنند. پروژه‌های نرم‌افزاری کوچک و آن‌هایی که به طیف سفارشی نزدیک‌تر هستند ممکن است چرخه انتشار پویاتر و غیرقابل پیش‌بینی‌تری داشته باشند اما به‌طور کلی هنوز اکثر این قوانین را دنبال خواهند کرد. برای درک اینکه چگونه شما و فروشنده نرم‌افزارتان می‌توانید بهترین مشارکت را برای ارائه بیشترین ارزش به سازمان خود داشته باشید، همدلی با فرآیند توسعه نرم‌افزار را در نظر بگیرید و آن را با نیاز خود به کاهش بدهی فنی ترکیب کنید تا از سرمایه‌گذاری نرم‌افزاری خود به بهترین شکل ممکن برای سازمانتان بهره ببرید.

اما قوانین سرانگشتی نسبتاً آسان هستند:

هنگام استقرار جدید یا به‌روزرسانی، به جدیدترین نسخه منطقی از نرم‌افزار هدف بگیرید. از هر فرصت استقرار برای حذف بدهی فنی تا حد امکان استفاده کنید.

هنگامی که نرم‌افزار از قبل وجود دارد، عواملی مانند تلاش انسانی، هزینه‌های مجوزدهی، سازگاری محیطی و آزمایش سازگاری را در برابر مزایای ویژگی‌ها، عملکرد و بدهی فنی سبک‌وسنگین کنید.

برچسب‌خوردهsoftware

آگهی

SMB IT Journal — the IT resource for small business