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 سریع در صورت بروز مشکل. مناسب برای ویژگی‌های بزرگ […]

یکی از ارگان‌های دولتی که بیش از ۲۰۰ کارمند فناوری اطلاعات و ۵۰۰۰ قلم دارایی در حوزه خدمات دارد با چالش‌های بزرگی دست و پنجه نرم‌ می‌کند. بخش IT این شرکت با انبوهی از تجهیزات و نرم‌افزارهای مختلف مواجه است که بسیاری از آنها به دلیل قدیمی بودن و عدم پشتیبانی، مشکلات متعددی را هم برای خودشان هم برای کاربران ایجاد کرده‌ اعم از: کاهش سرعت سیستم‌ها، قطع مکرر سرویس‌ها، افزایش سطح ریسک‌های امنیتی و هزینه‌های تعمیر بالا. کندی در ارایه خدمات و افزایش انبوه نارضایتی کاربران. هزینه واقعی فناوری‌های منسوخ و قدیمی این سازمان چقدر است؟ برای محاسبه‌ی هزینه‌ی واقعی فناوری‌های قدیمی در سازمانی با مشخصات ذکرشده (بیش از ۲۰۰ کارمند و ۵۰۰۰ دارایی IT)، می‌توان هزینه‌ها را به چند دسته‌ی اصلی تقسیم کرد. جدول زیر یک برآورد تقریبی و قابل تنظیم از این هزینه‌هاست: نوع هزینه شرح کوتاه برآورد سالانه (تومان) کاهش بهره‌وری کارکنان اتلاف زمان روزانه به‌علت کندی سیستم‌ها (۲۰۰ نفر × ۳۰ دقیقه × ۲۵۰ روز) × میانگین حقوق ساعتی ۷۵۰،۰۰۰،۰۰۰ افزایش هزینه‌های نگهداری قطعات یدکی، نیروی پشتیبانی بیشتر، مراجعه مکرر ۵۰۰،۰۰۰،۰۰۰ قطعی و اختلال در سرویس‌ها کاهش درآمد/خروجی یا افزایش نارضایتی در اثر قطعی سیستم‌ها ۳۵۰،۰۰۰،۰۰۰ ریسک‌های امنیتی احتمال نفوذ یا از دست رفتن اطلاعات + هزینه بازیابی یا جریمه‌ها ۶۰۰،۰۰۰،۰۰۰ عدم سازگاری با نرم‌افزارهای جدید هزینه دوباره‌کاری یا توسعه خاص برای سازگاری ۲۵۰،۰۰۰،۰۰۰ فرصت‌های از دست‌رفته ناتوانی در اجرای پروژه‌های تحول دیجیتال یا اتوماسیون ۴۰۰،۰۰۰،۰۰۰ جمع کل تخمینی سالانه: حدود ۲ میلیارد و ۸۵۰ میلیون تومان این ارقام قابل تنظیم بر اساس حقوق متوسط کارکنان، نرخ دستمزد پشتیبانی، و شدت خرابی سیستم‌ها هستند. برای دقت بیشتر، می‌توان از نرم‌افزارهای تحلیل هزینه کل مالکیت (TCO) استفاده کرد. با چنین رقم بالایی این سازمان چگونه می‌تواند آن را به حداقل برساند؟ برای پاسخ به این سناریو ابتدا باید چالش‌ها را از نزدیک ببینیم. پرسش‌ها و چالش‌های این سازمان: منحنی پیشرفت فناوری هر روز تندتر می‌شود. این روند بی‌تردید فرصت‌هایی به همراه دارد، اما چالش‌هایی نیز ایجاد می‌کند. یکی از پرسش‌های کلیدی برای سازمان‌هایی که نوآوری مستمر را در اولویت قرار داده‌اند این است: با فناوری‌های از رده خارج چه باید کرد؟ به‌عبارت‌دیگر، چگونه می‌توان از پیش تشخیص داد که دارایی‌های ما — و در نتیجه، کسب‌وکارمان — در معرض خطر قرار دارند؟ چه راهبردهایی می‌توان برای پیشگیری از مشکلات پیاده کرد؟ و چه ابزارهایی باید به کار گرفت تا یک قدم جلوتر بود؟ این نگرانی‌ها نه‌تنها قابل‌درک، بلکه کاملاً رایج‌اند. طبق «گزارش آمادگی شرکت Kyndryl»، ۶۴٪ از ۳۲۰۰ مدیر و تصمیم‌گیرنده مورد بررسی، نسبت به سیستم‌های قدیمی خود ابراز نگرانی کرده‌اند. در حالی که تقریباً همه شرکت‌کنندگان اعلام کرده‌اند نوسازی فناوری در سازمانشان اولویت دارد، ۴۴٪ از زیرساخت‌های حیاتی در آستانه پایان عمر خود هستند. این چیزها نگران‌کننده است، نه؟ نیازی نیست مدانت به شما بگوید که: این وضعیت خطرات بی‌شماری به‌دنبال دارد. اما همه چیز هم تیره و تار نیست. در این مقاله، نه‌تنها به بررسی مهم‌ترین ریسک‌های ناشی از استفاده از فناوری‌های قدیمی می‌پردازیم، بلکه راهکارهای مدیریت این وضعیت را از طریق یک استراتژی چرخه عمر فناوری اطلاعات نیز مرور خواهیم کرد. آماده‌اید؟ برویم سراغ اصل مطلب! فناوری از رده خارج چیست؟ فناوری از رده خارج به سیستم‌ها، نرم‌افزارها یا سخت‌افزارهایی اطلاق می‌شود که دیگر مطابق با استانداردهای روز یا قابل رقابت با جایگزین‌های مدرن نیستند. گرچه این ابزارها ممکن است هنوز کار کنند، اما معمولاً در عملکرد، امنیت و سازگاری دچار ضعف‌اند و سازمان‌ها را در پاسخ‌گویی به نیازهای سریع امروزی دچار مشکل می‌کنند. واقعیت این است که بسیاری از این فناوری‌های قدیمی (از جمله سیستم‌های میراثی یا Legacy) همچنان قادر به انجام وظایف خود هستند، اما نه بدون دردسر: کندی در هماهنگی با سیستم‌های جدید، کاهش بهره‌وری، و افزایش هزینه‌های نگهداری از […]