مشتریان شما انتظار دارند تا سرویس‌های با ارزش دریافت کنند. همچنین آنها انتظار دارند که این سرویس‌ها هیچ گونه خرابی نداشته باشند. این مساله، ایجاد، تست و تحویل نسخه را پس از طی فرآیند دقیقی که کیفیت را تضمین کرده و ریسک را به حداقل می‌رساند، ضروری می‌سازد.
مرحله مدیریت توسعه و نسخه در ITIL دقیقا برای این منظور طراحی شده است که شما اطمینان حاصل کنید نسخه های شما بطور مؤثر و کارامد در تولید مورد استفاده قرار می‌گیرد.
بر اساس ITIL، هدف فرآیند مدیریت توسعه و نسخه عبارتست از:
برنامه ریزی، زمانبندی و کنترل تهیه، تست و استقرار نسخه ها و ارائه قابلیت‌های جدید مورد نیاز توسط کسب و کار ضمن حفظ یکپارچگی سرویس‌های موجود.
نسخه (release) چیست؟
یک نسخه (پکیج نسخه هم نامیده می‌شود) به مجموعه ای از تغییرات مجاز صورت گرفته بر روی سرویس‌های فناوری اطلاعات گفته می‌شود. این به معنای آن است که یک نسخه می‌تواند شامل سخت افزار، نرم افزار، مستندات، فرآیندها یا سایر اجزایی که برای اجرای موفق تغییرات تایید شده بر روی سرویس‌های IT ضروری هستند، باشد.
اغلب سازمان‌هایی که از ITIL پشتیبانی می‌کنند، اقدام به تعریف سیاست‌هایی برای نسخه ها (release policies) کرده اند که به تعیین نحوه شماره گذاری نسخه ها، چگونگی انتشار آنها و حتی نحوه انتشار آنها کمک میکند.
ITIL در بخشی از سیاست‌های مربوط به انتشار نسخه، سازمانها را تشویق میکند تا سیستم هایی برای دسته بندی نسخه های خود ایجاد کنند. دسته بندی معمولا شامل موارد زیر است:
Major releases (نسخ اصلی): نسخه اصلی (major release) باید شامل نرم افزار یا سخت افزار جدید باشد.در اغلب موارد، یک major release معادل با معرفی قابلیت های کاملا جدید است.
Minor releases (نسخ فرعی یا Branch): عملکردهای موجود را بطور چشمگیری بهبود بخشیده و اغلب همراه با تعدای از اصلاحات تولید می‌شوند و اغلب بصورت v1.1, v1.2, v1.3 شماره گذاری می‌شوند.
Emergency releases: دقیقا همان چیزی هستند که بنظر می‌رسند. مسائل بدی که نیازمند توجه سریع بوده و در نتیجه شما باید نسخه اصلاحیه موقت، منتشر کنید. این نسخه ها بصورت 1.1.1، v1.1.2، v1.1.3 شماره گذاری می‌شوند.
همانطور که نسخه های خود را طراحی می‌کنید، برنامه ریزی های متعددی نیز می‌توانید در خصوص نحوه ارائه نسخ خود داشته باشید. سیاست‌های انتشار نسخه شما ممکن است مشخص کند که کدام رویکرد را انتخاب کنید (ممکن است مشخص نکند)، اما بدون در نظر گرفتن این موضوع، شما باید توجه دقیقی به کاربرانی که در حال ارائه نسخه به آنها هستید و نیز آن دسته از فعالیت های کسب و کاری که انتشار نسخه بر روی آنها تاثیر می گذارد، داشته باشید تا مطمئن شوید که تاثیر مورد نظر خود را گذاشته اید.
نسخه های (Big bang) به یکباره برای همه کاربران ارائه می‌شود.
نسخه های فازی (Phased approach releases) بیشتر بصورت مرحله ای هستند، بدین معنا که ابتدا نسخه برای گستره ای از کاربران ارائه شده و در صورتی که نسخه ارائه شده با مشکل مواجه نشد، گستره کاربران را به تدریج و بر اساس یک برنامه زمانبندی شده در هر مرحله افزایش داده تا در نهایت برای همه کاربران ارائه شود.
نسخه ها همچنن می‌توانند بصورت pulled یا pushed باشند. رویکرد pulled به این معناست که نسخه در یک مکان مرکزی قرار می‌گیرد و کاربران می‌توانند آن را دانلود کنند، در حالیکه رویکرد pushed دلالت بر این موضوع دارد که نسخه باید از مکان مرکزی برای هر یک از کاربران منتشر شود.
در نهایت، ITIL پیشنهاد می کند که نحوه انتشار نسخ خود را مشخص کنید. آیا می‌خواهید نسخه ها به صورت خودکار منتشر شوند یا بصورت دستی؟
اهداف مدیریت توسعه و نسخه
از دیدگاه ITIL اهداف مدیریت توسعه و نسخه عبارتند از:
- ایجاد، تست، تایید و ارائه نسخه ها
- مدیریت تغییر سازمان و ذینفعان
- اطمینان از اینکه سرویس‌های جدید (یا تغییر یافته) قادر به ارائه ضمانت و کارایی مورد توافق هستند
- ذخیره و مدیریت تغییرات، ریسک‌ها و مسائل مربوط به سرویس جدید (یا تغییر یافته) و انجام اقدامات اصلاحی لازم
- اطمینان از انتقال دانش کافی به مشتریان و کاربران در خصوص مصرف بهینه سرویس‌هایی که از فعالیت‌های کاری آنها پشتیبانی میکند
دامنه مدیریت توسعه و نسخه (Release and Deployment Management Scope)
دامنه مدیریت توسعه و نسخه شامل همه آیتم‌های پیکربندی که برای پیاده سازی یک نسخه لازم هستند، می‌باشد. این آیتم ها عبارتند از:
- دارایی های فیزیکی و مجازی
- نرم افزار و برنامه ها
- آموزش برای کاربران و کارکنان
- تمامی توافقات و قراردادها
تست که به عنوان بخشی از فرآیند تایید سرویس انجام می‌شود، در دامنه مدیریت توسعه و نسخه درنظر گرفته نمی‌شود و مجوز تغییر را نیز نمی‌دهد.
با نرم افزار ITSM دانا پرو
اولین قدم به سوی استقرار ITIL را محکم و با اطمینان بردارید.
فازهای اصلی مدیریت توسعه و نسخه
Release and Deployment Management به چهار فاز مختلف تقسیم می‌شود، ابتدا با یک برنامه ریزی دقیق در خصوص اینکه چه نسخه ای می‌خواهید منتشر کنید و چگونگی انجام آن شروع می‌شود و سپس نتیجه گیری بعد از انتشار نسخه و بازبینی بعد از اجرا انجام خواهد شد.
فاز 1: برنامه ریزی توسعه و نسخه
یک برنامه توسعه و نسخه با کیفیت تنها جزء کوچکی از برنامه کلی انتقال سرویس شما می‌باشد، اما نکته این است که بطور شفاف مجموعه ای از دستورالعمل‌ها برای آنچه که یک نسخه باید شامل شود و نیز چگونگی قرارگیری آن در تولید، تعریف شود. سپس برنامه توسعه و نسخه به عنوان بخشی از فرآیند مدیریت تغییر تایید می‌شود.
در ابتدای فاز برنامه ریزی توسعه و نسخه، مدیریت تغییر معمولا مجوز شروع انتشار نسخه را برای فرآیند برنامه ریزی صادر میکند. این برنامه به موارد زیر اشاره میکند:
نسخه شامل چه تغییراتی خواهد بود
انتشار نسخه بر چه کسی تاثیر خواهد داشت
انشتار نسخه چه ریسک هایی را در پی خواهد داشت
مخاطبان نسخه ( چه کاربران، مشتریان و سازمان‌هایی تحت تاثیر قرار خواهند گرفت)
زنجیره ای از تاییدیه ها، مشخص کردن اینکه چه ذینفعانی ممکن است مجوز درخواست تغییر در هر مرحله از انتشار نسخه را صادر کنند.
مالکیت، تعیین یک تیم که در نهایت مسئولیت انتشار را بر عهده دارند
تدوین استراتژی و زمانبندی استقرار
به ندرت پیش می آید که ایجاد و تست برنامه نیز در این مرحله انجام شود و اساسا فرآیندهای مهم و ضروری از جمله مشخصات طراحی، روال های تست، جدول زمانی برای ایجاد و تست و حتی معیارهای شکست یا قبولی هر مرحله از استقرار در این مرحله انجام می‌شود. همچنین ممکن است برنامه ریزی برای ارائه نسخه آزمایشی در این مرحله انجام شود.
فاز2: ایجاد و تست نسخه
هنگامیکه برنامه ریزی انجام می‌شود و مدیریت تغییر نیز آن را تایید میکند، تیم‌های مسئول باید نسخه را ایجاد کرده و مواردی از قبیل نرم افزار، مستندات و سایر موارد مشخص شده در برنامه انتشار نسخه را تست کنند.
در ابتدای این فرآیند، مستنداتی ایجاد می‌شود تا اطمینان حاصل شود که توسعه دهندگان می‌توانند نسخه ها را بصورت دقیق و کارآمد ایجاد کنند و در طول فرآیند ایجاد نیز میبایست سوابق بطور دقیق نگهداری شوند تا در صورت نیاز بتوان فرآیند ایجاد نسخه را تکرار کرد.
اکثر سازمانها به طور معمول روش‌های های سختگیرانه ای را دنبال کرده یا حتی قالب های استاندارد برای ساخت یک پکیج کامل نسخه ارائه می‌کنند. اطمینان حاصل کنید که در هر مرحله از این فرآیند، از این موارد استفاده کرده و آنها را رعایت می‌کنید.
عملیات تست در طول فرآیند انجام می‌شود، از تست همه خروجی های CIs گرفته تا تست و اجرای آزمایشی سرویس‌ها پیش از آنکه در محیط واقعی ارائه شوند.
چند نکته که باید در حین فرآیند بخاطر داشته باشید عبارتند از:
- ارائه نسخه آزمایشی یک روش بسیار عالی برای شناسایی و تصحیح هرگونه مشکلات در خصوص سرویس قبل از ارائه سرویس برای همه مخاطبان است.
- برخی تیم‌ها تصمیم به اجرای یک نسخه آزمایشی می‌گیرند، یعنی قبل از آنکه برای انتشار و تحویل سرویس زمانبندی انجام شود. در کمترین زمان ممکن و تا آنجا که امکان دارد، سرویس را امتحان می‌کنند.
فاز 3: استقرار
در این فاز، بسته های نسخه برای ارائه در محیط واقعی انتقال داده می‌شود. شروع این مرحله بدین صورت است که مدیریت تغییر، مجوز تحویل نسخه به محیط های هدف را صادر میکند. این فاز با ورود به مرحله اجرای سرویس و پشتیبانی اولیه تمام می‌شود.
ITIL پیشنهاد میکند که پیش از تحویل نسخه، برنامه ریزی و آماده سازی پیشرفته ای انجام شود؛ به عنوان نمونه، تایید آمادگی گروه هدف برای تحویل نسخه، شناسایی و تلاش برای کاهش هرگونه ریسک یا اختلالات بالقوه و مشخص کردن ترتیب ارائه componentهای نسخه (مانند دارایی های مالی، فرآیندها و اقلام، نسخه واقعی سرویس، و غیره).
موضوع بسیار مهم پس از انتشار نسخه آن است که شما تایید کنید نسخه برای همه ذینفعان به درستی کار می کند و در صورت بروز مشکلات جدی، باید مشکلات را برطرف کرده یا نسخه را مجددا منتشر نمایید.
پس از آنکه تایید شد نسخه طبق برنامه ریزی های انجام شده، کار میکند، ITIL شما را ملزم می‌دارد تا نسخه جدید (یا نسخه تغییر یافته) را طی دو مرحله، وارد فاز اجرا کنید. اولا باید یک اطلاعیه رسمی صادر شود که در حال حاضر که سرویس در محیط واقعی قرار گرفته است (در ابتدای مرحله پشتیبانی اولیه یا ELS)، و در نهایت اطلاعیه رسمی دیگری در خصوص اینکه سرویس‌ها به طور کامل عملیاتی شده است و SLA نیز بطور کامل در حال اجرا است.
فاز 4: بازبینی و خاتمه استقرار
پس از آنکه نسخه تحویل داده شد، زمان بازبینی و جمع آوری اطلاعات از کل فرآیند فرا می‌رسد. بازخوردها جمع آوری شده و ارزیابی ها بر اساس اهداف عملکرد و نتایجی که مورد بحث و بررسی قرار گرفته اند، انجام می‌شود.
بازبینی‌ها باید دقیق و کامل انجام شود. همچنین باید تایید شود که تمام الزامات کیفیت برآورده شده است، انتقال دانش و آموزش انجام شده است و هر خطای شناخته، اصلاحات و تغییرات بطور دقیق مستند شده است. علاوه بر این، change management باید یک بازبینی کامل پس از اجرا انجام دهد.
فرآیند استقرار هنگامی پایان می‌یابد که پشتیبانی بطور رسمی وارد عمل شود. با استفاده از یک نرم افزار مدیریت خدمات فناوری اطلاعات که بر پایه اصول ITIL طراحی شده است، مدیریت توسعه خود را بهینه سازی کنید.
