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

چرخه‌ی حیات نرم‌افزار در ITIL4: از جرقه تا فاجعه! در این مقاله کاربردی می‌خوانید: هر نرم‌افزاری، با یک ایده شروع می‌شود. تصور کنید در سازمان ما، بخش منابع انسانی نیاز به یک سامانه‌ی ارزیابی عملکرد دارد. من بعنوان مدیر خدمات فناوری اطلاعات، این نیاز را دریافت می‌کنم. حالا، مسیر چرخه حیات آغاز می‌شود. این را حال به کسب‌وکار تعمیم دهید فرض کنید نیازی را شناسایی کرده‌اید یا مشتری از شما چیزی خواسته. چطور شروع کنیم؟ 1. ایده‌پردازی تا طراحی – Engage + Plan در مرحله‌ی نخست، نیاز کسب‌وکار را مستند می‌کنیم (فرایند Engage). سپس، در چارچوب ITIL 4 با کمک Plan، یک برنامه‌ی دقیق شامل منابع، بودجه، ریسک‌ها و نقاط عطف آماده می‌سازیم. طراحی اولیه نرم‌افزار (High-Level Design) حاصل همین مرحله است. 2. ساخت، تست و انتقال – Design & Transition + Build در این مرحله با همکاری تیم توسعه و تست، محصول ساخته می‌شود و فرایند Design and Transition وارد فاز عملیاتی می‌گردد. اینجاست که اهمیت DevOps یا Agile به کمکمان می‌آید. با استفاده از Continuous Integration/Deployment، استقرار اولیه (Pilot) انجام و در محیط محدود بررسی می‌شود. 3. اجرا و پشتیبانی – Deliver & Support نرم‌افزار وارد فاز بهره‌برداری می‌شود. کاربران از آن استفاده می‌کنند و ما، با کمک فرایند Incident Management، پشتیبانی مستمر ارائه می‌دهیم. هر مشکل به‌سرعت ثبت، اولویت‌بندی و رفع می‌شود. 4. ارزیابی ارزش – Improve چند ماه بعد، با داده‌های واقعی، ROI را محاسبه می‌کنیم. آیا زمان صرفه‌جویی شد؟ هزینه‌ها کاهش یافت؟ رضایت کاربران بالا رفت؟ اگر پاسخ مثبت است، پس به هدف رسیده‌ایم. در غیر این‌صورت، وارد چرخه‌ی Continual Improvement می‌شویم. فرایندهای کلیدی در چرخه‌ی حیات نرم‌افزار (بر اساس ITIL 4):

Canary Release یا «انتشار قناری‌وار» یک روش تدریجی برای ارائه نسخه جدید نرم‌افزار است که ابتدا فقط برای درصد کمی از کاربران فعال می‌شود. این نام از سنت استفاده از قناری در معادن گرفته شده که برای شناسایی زودهنگام خطرات به کار می‌رفت. در این روش، تیم توسعه نسخه جدید را در محیط production مستقر می‌کند ولی ترافیک فقط بخش کوچکی از کاربران (مثلاً ۵٪) به آن هدایت می‌شود. اگر مشکلی گزارش نشود، درصد کاربران افزایش یافته و در نهایت کل سیستم به نسخه جدید منتقل می‌شود. این کار به تیم‌ها کمک می‌کند ریسک تغییرات را کاهش دهند و سریع‌تر به اشکالات احتمالی واکنش نشان دهند. Canary Release معمولاً با ابزارهایی مثل Kubernetes، Istio یا AWS CodeDeploy پیاده‌سازی می‌شود. این تکنیک در تیم‌های DevOps، SRE و ITIL 4 بسیار محبوب است چون انتشار کنترل‌شده و مطمئنی را فراهم می‌سازد. جزییات بیشتر…

Feature Toggle یا “کلید ویژگی” یک تکنیک در توسعه نرم‌افزار است که به کمک آن می‌توان فعال یا غیرفعال بودن یک قابلیت را بدون نیاز به تغییر در کد یا استقرار مجدد کنترل کرد. این روش معمولاً از طریق تنظیمات پیکربندی یا داشبوردهای مدیریتی انجام می‌شود و به تیم‌ها امکان می‌دهد ویژگی‌ها را به‌صورت تدریجی، هدفمند یا حتی آزمایشی منتشر کنند. توسعه‌دهندگان می‌توانند یک ویژگی را در کد پیاده‌سازی کنند ولی آن را فقط برای کاربران خاصی فعال نمایند. این کار در مدیریت ریسک، آزمایش A/B و پاسخ سریع به مشکلات بسیار مفید است. Feature Toggle به‌ویژه در محیط‌های Agile و DevOps برای جداسازی فاز استقرار و انتشار کاربرد دارد. با آن می‌توان حتی ویژگی ناقص یا ناتمام را در production مستقر کرد، بدون اینکه برای کاربران قابل مشاهده باشد. ابزارهایی مانند LaunchDarkly یا Unleash به‌طور گسترده از این رویکرد پشتیبانی می‌کنند. جزییات بیشتر…

در چارچوب ITIL 4، جداسازی استقرار (Deployment) از انتشار (Release) بخشی از تمرین‌های پیشرفته در دو حوزه‌ی Release Management و Deployment Management محسوب می‌شود. ITIL 4 تأکید دارد که انتشار یک تغییر برای کاربران نهایی نباید الزاماً همزمان با استقرار فنی آن باشد. این رویکرد، که با استفاده از ابزارهایی مانند feature toggles، blue-green deployment یا canary releases پشتیبانی می‌شود، امکان تحویل ارزش به‌صورت امن، کنترل‌شده و با ریسک کمتر را فراهم می‌کند. در ITIL 4، تمرکز بر مدیریت ارزش کسب‌وکار است، نه صرفاً تحویل تغییر، و این جداسازی دقیقاً همین هدف را محقق می‌کند. قبل از بررسی این جداسازی بیایید یک سناریو واقعی را بررسی کنیم. نجات پروژه فروشگاه آنلاین در یک جمعه سیاه سناریو: شرکت ایکس بعنوان مالک یک پلتفرم فروشگاهی بزرگ در کشور، تصمیم می‌گیرد یک فیچر پیشنهاد هوشمند را برای افزایش فروش محصولات خود فعال کند. ویژگی‌ها کاملاً تست شده‌اند، اما ریسک اصلی زمان انتشار است: جمعه سیاه، ساعت ۹ صبح. تیم مجبور است ویژگی جدیدی را در روز جمعه سیاه ارائه دهد. یک اشتباه کوچک در این روز می‌تواند میلیون‌ها تومان خسارت وارد کند. در اینجا، جدا کردن استقرار از انتشار راه‌حلی نجات‌بخش می‌شود. این یعنی شرکت ایکس به‌جای انتشار مستقیم تصمیم می‌گیرد: نتیجه:نه‌تنها سیستم بدون مشکل کار کرد، بلکه فروش آن روز ۲۷٪ افزایش یافت. مشتریان هم تجربه بهتری داشتند جدا کردن استقرار از انتشار باعث شد تیم بتواند بدون نگرانی از بروز خطا در زمان اوج ترافیک، کنترل کامل بر ویژگی جدید داشته باشد. این رویکرد نه فقط در جمعه سیاه، بلکه در هر به‌روزرسانی مهمی ضروری است. در جدول زیر، دو تکنیک مهم در جداسازی استقرار (Deployment) از انتشار (Release) در چارچوب ITIL 4 — یعنی Feature Toggle و Canary Release — به صورت مقایسه‌ای شرح داده شده‌اند: جدول مقایسه Feature Toggle و Canary Release تکنیک‌های Feature Toggle و Canary Release سابقه‌ای چندده‌ساله در مهندسی نرم‌افزار دارند، اما با گسترش متدلوژی‌های چابک (Agile) و DevOps، نقش آن‌ها در مدیریت تغییر و انتشار بسیار پررنگ‌تر شده است. Feature Toggle نخستین بار توسط توسعه‌دهندگان در شرکت‌هایی مثل Flickr و Facebook مورد استفاده قرار گرفت تا ویژگی‌هایی را در محیط production مستقر کنند اما تنها برای گروه خاصی از کاربران یا در شرایط خاص فعال نمایند. این روش به تیم‌ها اجازه می‌دهد بدون نیاز به بازاستقرار، ویژگی‌ها را روشن یا خاموش کرده و کنترل دقیق‌تری بر زمان و نحوه انتشار داشته باشند. از سوی دیگر، Canary Release الهام‌گرفته از روش‌های ایمنی در معادن (استفاده از قناری‌ها برای شناسایی گازهای سمی) است و اولین بار در مقیاس وسیع توسط Google و Netflix به‌کار گرفته شد. این تکنیک به تیم‌ها اجازه می‌دهد تا نسخه‌ی جدیدی از نرم‌افزار را ابتدا برای درصد محدودی از کاربران منتشر کرده و در صورت عدم مشاهده مشکل، آن را به کل کاربران گسترش دهند. هر دو روش امروز بخشی جدایی‌ناپذیر از استراتژی‌های مدرن انتشار در چارچوب‌هایی مانند ITIL 4، Site Reliability Engineering (SRE) و Continuous Delivery هستند. ویژگی / تکنیک Feature Toggle (کلید ویژگی) Canary Release (انتشار قناری‌وار) تعریف مکانیسمی در کد که به شما اجازه می‌دهد یک ویژگی را بدون تغییر در کد اصلی فعال یا غیرفعال کنید. نوعی انتشار تدریجی که ابتدا تنها برای درصد کمی از کاربران فعال می‌شود. هدف اصلی جدا کردن زمان استقرار از زمان فعال‌سازی ویژگی برای کاربران. شناسایی مشکلات احتمالی در مقیاس کوچک قبل از انتشار عمومی. نحوه اجرا از طریق پارامترهای پیکربندی یا ابزارهای third-party (مثلاً LaunchDarkly، Unleash). با تقسیم ترافیک به چند گروه و هدایت آن به نسخه جدید از نرم‌افزار در محیط production. مزیت کلیدی کنترل لحظه‌ای و سریع بر فعال‌سازی ویژگی‌ها بدون نیاز به استقرار مجدد. کاهش ریسک انتشار و امکان rollback سریع در صورت بروز مشکل. مناسب برای ویژگی‌های بزرگ […]