تمرین قابلیت تغییر در ITIL4

تغییر و مدیریت پیکربندی

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

• یک تغییر باید وضعیت یک یا چند مورد پیکربندی (CI) در پایگاه داده مدیریت پیکربندی (CMDB) شما را تغییر دهد تعیین این مسئله به سوال دامنه CMDB شما پاسخ می‌دهد.
• تغییر CI فقط از طریق تغییر انجام می‌شود - در غیر این‌صورت، شما دارید یک تغییر غیرمجاز اجرا می‌کنید!
• اگر هنگام ایجاد یک تغییر قلم‌های پیکربندی مرتبط در CMDB نیستند، باید این قلم‌ها را نیز ایجاد کرده باشید. اگر آنها برای بالا بردن سابقه تغییر از اهمیت کافی برخوردار باشند، احتمالاً به اندازه کافی مهم هستند که بتوانند به عنوان CI ردیابی شوند.
• اگر یک CI را بدون تغییر، تغییر می‌دهید، شاید آنقدر بی‌اهمیت است که اصلاً نباید CI باشد. دقت کنید CI‌یا قلم پیکربندی یعنی هر موردی که روی سرویس‌های شما اثر گذارست بنابراین هر شی و هر چیزی CI‌ نیست! شما نباید CMDB ایجاد کنید که شامل اقلامی است که اصلاً در مدیریت تغییر بکار نمی‌آید! زیرا ایجاد و حفظ و نگهداری این نوع داده به زودی از رده خارج و بی‌معنی می‌شوند.
• اگر با مدیریت تغییر و پیکربندی ازدواج کنید، خود را با تیم بسیار قدرتمندی هماهنگ کرده‌اید.
• در هنگام ایجاد یک پایگاه از اقلام پیکربندی CMDB ابتدا بپرسید: "برای پیگیری بیشتر به چه اقلامی نیاز دارید؟ سه نوع برتر کدامند؟ "معمولاً پاسخ این دو پرسش: نرم‌افزارها، دیتابیس‌ها و سرورهاست. همین یعنی مشخص شدن دامنه CMDB اولیه‌ی شما!

داشتن این طرح ساده CMDB به ما امکان می‌دهد اثبات کنیم که فرایندهای مدیریت تغییر برای حفظ CMDB لازم است. بنابراین CI-هایی را باید ایجاد کنید که در فرایند مدیریت تغییر جایگاهی مشخص داشته باشند. چرخه‌ی حیات هر CI به تغییر وضعیت آن بر اساس مدیریت تغییر باز می‌گردد! پس پیوند محکم بین مدیریت تغییر و مدیریت پیکربندی را نادیده نگیرید.

DevSecOps چیست؟

DevSecOps یعنی یکپارچه‌سازی امنیت در عملیات توسعه. اختصاری از (توسعه، امنیت و عملیات) که از آن می‌توان برای انجام بررسی‌ها و کنترل‌های امنیتی خودکار و شفاف در کل چرخه‌ی حیات توسعه نرم‌افزار استفاده کرد تا این اطمینان حاصل گردد که DevOps فقط در مورد تیم‌های توسعه و عملیات نیست. اگر می‌خواهید از چابکی و پاسخگویی رویکرد DevOps نهایت استفاده را ببرید، امنیت IT نیز باید در چرخه‌ی کامل حیات نرم‌افزارها نقش یکپارچه‌ای را ایفا کنند.

پیوند مدیریت تغییر با DevSecOps

روش مدیریت تغییر نباید مانع جریان، بازخورد و یادگیری مداوم DevSecOps شود. بلکه باید با این فعالیتها ادغام و بهینه شود. آنچه DevSecOps انجام می‌دهد تعریف جدیدی از تغییر را ارائه می‌کند. به همین ترتیب، مدیریت تغییر باید دامنه تیم DevSecOps را مشخص کند. همکاری بین این دو ضروری است.

DevSecOps (که نیاز به ملاحظات امنیتی در اوایل و در طول چرخه‌ی حیات عملیات توسعه نرم‌افزاری را برجسته می‌کند) باید دارای یک جریان بسیار کارآمد باشد، جایی که به روزرسانی‌های سرویس به سرعت و با اطمینان ارائه می‌شوند. باید به طور مداوم از کارکنان و کاربران بازخورد بگیرد، تا به روزرسانی‌های آینده بهتر انجام شود.

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

مدیریت تغییر باید هرگونه مداخله غیرضروری انسان را خودکار کرده و از بین ببرد. همچنین باید روش‌های DevSecOps را برای بهبود اثربخشی و کارایی خود اتخاذ کند.

هدف از مدیریت تغییر، ترویج تغییرات در عین کاهش خطر است. بنابراین، لازم است که به توسعه فرایندها و ابزارهای DevSecOps محکم و قابل اعتماد کمک کند. از جمله آنچه می‌تواند و نمی‌تواند در محدوده نسخه‌های مکرر DevSecOps باشد. به یاد داشته باشید، چنین نسخه‌هایی مکرر و کم است. از این رو تأثیر هر نسخه باید کم و بسیار قابل کنترل باشد. خطر باید ذاتاً اندک باشد. این به یک هدف مشترک منجر می‌شود.

قابلیت DevSecOps به خودی خود به یک سرویس تبدیل می‌شود. به جای تغییر در سرویس نهایی، مسئولیت آن کاملاً در قلمرو تیم‌های DevSecOps است. سپس مدیریت تغییر برای کارهایی که خدمات DevSecOps ارائه می‌دهند نقش حاکمیت را بازی خواهد کرد. لابد می‌پرسید پس نقش هیات مشاورین تغییر چه می شود!؟

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

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

ادامه مطلب در صفحه بعد…