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

خوشبختانه بنیاد سازندگان  ITIL 4 به اندازه کافی آزاد بودند تا بتوانند برخی از یادگیری‌های مهم جنبش DevOps را با چارچوب ITIL تطبیق دهند و از درگیری بیشتر بین توسعه‌دهندگان واحد نرم‌افزار و ارایه دهندگان خدمات جلوگیری کند. ITIL4  در حالی که بطور خطی تمام خصوصیات نسخه‌های قبلی را حفظ کرده، تلاش نموده تا جریان “برنامه‌ریزی، ساخت، اجرا” را در مفهوم چرخه‌ی سرویس خود قرار دهد و اینچنین شد که در نسخه ۴ به طور قابل توجهی این مدل را با یک مدل جریان ارزش تکرار شونده جایگزین کرد تا مباحث DevOps را نیز بخوبی پوشش ‌دهد. تغییر رویکرد از “فرایندها” به “تمرینات” و قرارگیری زنجیره‌ی ارزش خدمات شاید مهمترین تغییراتی باشد که در ITIL4 باید مورد توجه قرار گیرد این مهم که توسط Axelos برای واکاوی بیشتر بارها مورد بحث قرار گرفته به نوبه‌ی خود بطور قابل توجهی نیز مورد ستایش واقع شده. امروز توسعه‌دهندگان نرم‌افزار و حامیان DevOps نیز به این نتیجه رسیده‌اند که ITIL ورای رویکرد چرخه‌ی حیات خدمت است و بازآفرینی هر چیزی که منجر به خلق ارزش شود نیازمند این چارچوب محبوب است. لذا هواداران DevOps‌ باید بدانند که:  ITIL برای خدمات پشتیبانی نیست، ITIL دست و پا گیر نیست، ITIL بروکراسی ایجاد نمی‌کند و ITIL‌ برای تمام ارکان‌های فناوری اطلاعات و ارایه‌دهندگان خدمت در سراسر جهان است!

مهمترین ایرادی که حامیان DevOps به ITIL می‌گرفتند همین بروکراسی دست و پا گیر است بخصوص در مدیریت نشر و تغییر. بنابراین چیزی که در ITIL4 و اندکی پس از انتشار، نویسندگان آن را به چالش وا داشت تغییر نامگذاری فرایند مدیریت تغییر به تمرین “کنترل تغییر” بود و چالشی که پیش آمد: کلمه‌ی “کنترل” بود. بخصوص آنکه کافی بود که حامیان DevOps این کلمه را بشنوند! بار منفی نظارت و “کنترل” در ذهن آنها و البته تقریباً همه مشکل‌ساز خواهد بود. سیل انتقادات به واژه‌ی کنترل آنقدر زیاد شد که نه تنها DevOps-ها بلکه اغلب مدیران و تمرین‌کنندگان ITIL نیز بجای آنکه بر روی”کنترل میزان تغییرات”، به “کنترل تغییرات” یا “تیم‌های کنترل‌کننده” متمرکز شد‌ند همین باعث برداشت‌های نادرست و سوتفاهمات بسیاری شد زیرا حتی خود کلمه‌ی “کنترل” برای بسیاری از تیم‌های فناوری اطلاعات واژه‌ای سمی و استرس‌زاست پس از آن نویسندگان ITIL، پیشنهاداتی را مطرح کردند از جمله بازگشت به همان “مدیریت تغییر” اما در نهایت تصمیم گرفتند بجای استفاده از “کنترل تغییر” از “قابلیت تغییر” استفاده کنند.”مدیریت تغییر” یک پیام ظریف دارد که تمرکز آن بر مدیریت هر نوع تغییری است. از طرفی، کنترل تغییر به دنبال کنترل شرایط توسعه‌ی تغییرات سازگار با انتظارات مورد دلخواه سازمان از نتیجه‌ی تغییر است. به عبارت دیگر،  مدیریت تغییر بر نحوه‌ی تولید تغییرات – در جریان ارزش – نظارت و حاکمیت ایجاد می‌کند.  بنابراین در تاریخ ۳۱ اکتبر سال ۲۰۱۹، Axelos در مقاله‌ای آنلاین تأیید کرد که به‌روش ITIL 4 از فرایند مدیریت تغییر به عنوان “Change Enablement” “قابلیت تغییر” یاد می‌کند که این عبارت بهتری نسبت به کنترل تغییر است. “فعال‌سازی، توانمندی، قابلیت، عملکرد و…” نیز عباراتی است که می‌توان برای ترجمه‌ی آن در نظر گرفت اما بطور کل چون در این تمرین به بررسی اینکه “آیا این تغییر هست یا خیر!” پرداخته شده مفهوم قابلیت تغییر نمود دیگری پیدا کرده است. تردیدی نیست که مدیریت تغییر شهرت بسیار منفی در جامعه‌ی مخاطبین DevOps دارد. یکی از اهداف DevOps، معرفی و اجرای دفعات استقرار تغییرات است. بنابراین وجود فرایندی بنام مدیریت تغییر در ITIL به طور زیادی، فرکانس انتشار و تغییرات مکرر نرم‌افزار را کند می‌کند. به همین دلیل آنها بارها در کنفرانس‌ها برای زیر بار نرفتن تغییر در ITIL از “شکستن سد مدیریت تغییر” یاد می‌کنند. آنها باور دارند زمانی که نوآوری ایجاد می‌شود، مدیریت تغییر دستوری و کنترلی فقط یک محدودیت دست و پا گیر محسوب می‌شود. توسعه‌دهندگان نرم‌افزار و هوداران DevOps می‌گفتند که در عصر دیجیتال، فضای کسب و کار تغییر کرده و فناوری اطلاعات باید فرآیندهای خود را متناسب با آن تطبیق دهد. به همین دلیل وجود کلمات! مهم هستند. “کنترل” به خودی خود واژه‌ای سمی است زیرا، خواه ناخواه، حالت تداخل، نظارت و ممیزی را توصیف می‌کند و همیشه وجود “جلسات هیات مشاورین تغییر CAB” کلیشه‌ای را با چند نفر که دور یک میز نشسته‌اند را در ذهن متبادر می‌نماید. که در آن اظهارات جدی اما ناآگاهانه درباره‌ی یک تغییر را ارایه می‌کنند و جلسات CAB چیز خوب و اثرگذاری نیست جز اتلاف وقت!  به همین خاطر Axelos از واژه‌ی”قابلیت” برای توصیف عملکرد تغییر استفاده کرد: تا ضمن رفع حساسیت DevOps-ها، افزایش بیشتر قابلیت اطمینان و سرعت تغییرات را به رخ بکشد. این یعنی هدف از قابلیت تغییر، بررسی شرایط توسعه‌ی تغییرات سازگار با انتظارات مورد دلخواه سازمان از نتیجه‌ی تغییر است. به عبارتی قابلیت تغییر بر نحوه‌ی تولید تغییرات – در جریان ارزش – نظارت و حاکمیت ایجاد می‌کند. پس بنیاد AXELOS نام فرایند مدیریت تغییر را در ITIL 4 به  تمرین”قابلیت تغییر” تغییر نام داده است البته فقط صرفاً‌ تغییر نام نیست بلکه برای پیشبرد موفق‌تر تمریناتی شبیه این، اصول راهنمای بهتر و شفاف‌تری را ارایه کرده تا سازگارپذیر بودن و اجرایی شدن آن، بیشتر نمود پیدا بکند. فرایند مدیریت تغییر یا تمرین قابلیت تغییر از آن دست تمرینات شیرین است اما برعکس! به تلخی از آن یاد می‌شود مدیران و کارکنان فناوری نیز دلایل موجه خود را دارند و اکثراً این فرایند را به معنای واقعی بکار نمی‌گیرند.  چیزی که مرتباً از آنها می‌شنوم اینست که مدیریت تغییر:

  • خیلی دست و پا گیر است!
  • بدون تغییر هم، ارایه‌ی خدمات بخوبی انجام می‌شود!
  • بیش از حد افراد را درگیر بروکراسی اداری می‌کند.
  • اصلاً انعطاف‌پذیر نیست.
  • مدت زمان طولانی برای برنامه‌ریزی و مدیریت آن لازم است.
  • گرفتن تایید یا اجرای تغییرات سبب هدر رفت زمان بیشتر می‌شود.
  • بیشتر از آنکه برای اجرای تغییرات باشد برای جلوگیری از تغییرات طراحی شده است.

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

از همان نسخه‌های ابتدایی چارچوب کتابخانه‌ی زیرساخت فناوری اطلاعات، ITIL، همواره مدیریت تغییر را در اصول راهنمای خود گنجانده و از موضع خود هم در هیچ ویرایشی کوتاه نیامده زیرا موکداً می‌گوید که هدف از مدیریت تغییر:” به حداکثر رساندن نرخ تعداد تغییرات در حال اجراست در حالی که خطرات آنرا نیز کاهش می‌دهید.”

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

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

برای عملی‌کردن موفق این تمرین و تمکین کارکنان به استفاده‌ی بهینه از آن، نسخه جدید ITIL4 با ارایه‌ی اصول راهنمای مشترک برای تمامی تمرینات، یک روش خوب برای مدیریت تغییر منعکس کرده که بشرح زیر است:

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

تمامی موارد فوق کاملاً شبیه اصول راهنمای ITIL4 برای همه‌ی تمرینات است! این یعنی هر تمرین در این چارچوب جدید می‌بایست اصول فوق را رعایت کرده باشید تا اثربخشی و ارزشمندی هدف هر تمرین نمایان گردد.

مدیریت تغییر برای توسعه چابک

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

مدیریت تغییر در مورد مدیریت تأثیرات اجرای تغییرات به‌روشی کنترل شده است. در هر صورت تغییراتی که بصورت چابک اجرا می‌شوند باید موارد زیر را در نظر داشته باشید:

  • منابع مورد نیاز برای پیاده‌سازی تغییر کدامند؟
  • ملاحظات امنیتی تغییر را در نظر گرفته‌اید؟
  • زمان اجرای تغییر چه هنگامی است؟
  • چه مولفه‌ها و عوامل خارجی روی تاثیرات تغییر اثر گذار هستند؟

چابک‌سازی تغییر

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

در بحث هفت R مهم برای مدیریت تغییر اصول اولیه را برای شروع یک فرایند مدیریت تغییر پیشتر عنوان کردم.

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

از نظر فناوری اطلاعات، عوامل موثر در اجرای هر تغییری: توسعه‌دهندگان نرم‌افزارها، مدیران زیرساخت، عملیات، شبکه، امنیت، تجارت و حتی مشتریان خدمات تجاری هستند و روند مدیریت تغییر باید متناسب با نیازهای آنها رشد کند و به بلوغ برسد پس به یاد داشته باشیم که هدف ITIL همسوکردن خدمات فناوری اطلاعات با نیازهای تجاری است بنابراین لازم است سرویس مدیریت تغییر با نیازهای کاربران (توسعه‌دهندگان خدمات) هماهنگ باشد نه آنکه عملی خودسرانه و استبدادی باشد با این ذهنیت از دام یک رویه‌ی بوروکراتیک که ارزش زیادی ندارد، به‌سادگی می‌توان جلوگیری کرد.

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

چه چیزی تغییر است چه چیزی نیست!؟

گفتیم که توسعه‌دهندگان و کاربران با تغییرات میانه‌ی خوبی ندارند و آنرا بروکراسی دست و پا گیر قلمداد می‌کنند یکی از مهمترین دلایل این برداشت عدم تفکیک درست نوع اقدام برای نامیدن آن بعنوان تغییر است پیش از انجام هر اقدامی، این سوال کلیدی را پاسخ دهید:” آیا این، تغییر است یا نه؟” هر چیزی را در لوای تغییر فرو نبرید با این کار باز هم جبهه‌ی مقاومت افراد را خواهید دید. دامنه‌ی مدیریت تغییر باید روشن باشد. به نظرم، تعریف دقیق یک تغییر یعنی:”افزودن، اصلاح یا حذف هر چیزی که می‌تواند تأثیر مستقیم یا غیرمستقیم بر خدمات داشته باشد.” بنابراین این تعریف برای هر اقدامی قابل تفسیر نیست.

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

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

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

نمونه‌هایی که تغییر محسوب می‌شوند:

  • اجرای کد جدید در یک نرم‌افزار سازمانی
  • اصلاح زیرساخت شبکه
  • تغییر سرویس رسیدگی به درخواست‌های مشتریان.
  • ارتقای نرم‌افزار اتوماسیون اداری به نسخه‌ی بالاتر

نمونه‌هایی که تغییر محسوب نمی‌شوند:

  • راه‌اندازی مجدد سرور برای بازیابی در یک حادثه
  • بازنشانی گذرواژه
  • بازکردن یا بستن پورت‌های سوییچ
  • تغییر رمز ادمین سرورها

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

دامنه‌ی تغییر

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

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

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

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

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

ملاحظات یکسانی برای هر پروژه‌ی بزرگ باید در نظر گرفته شود تا اطمینان حاصل شود که دامنه و تأثیر کامل تغییر درک شده است. اگر با هر تغییری به عنوان یک پروژه‌ی کوچک رفتار کنید احتمال اینکه چیزهایی را از دست بدهید کمتر است.

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

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

  • یک تغییر باید وضعیت یک یا چند مورد پیکربندی (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 است تا کار تیم‌های امنیتی را زودتر و دیرتر تلفیق کند.

امنیت DevOps داخلی است!

چه از “DevOps” یاد کنیم چه آنرا “DevSecOps” بنامیم، در هر حال امنیت به عنوان بخشی جدایی‌ناپذیر از کل چرخه‌ی حیات هر برنامه‌ای است که باید در نظر داشت و بدون امنیت، اقدامات سریع تیم تولید محکوم به فناست. DevSecOps در مورد امنیت داخلی است، نه امنیتی که به عنوان یک محیط پیرامون نرم‌افزارها و داده‌ها عمل می‌کند. تا حدی، DevSecOps بر ضرورت دعوت از تیم‌های امنیتی در ابتدای ابتکارات DevOps برای ایجاد امنیت اطلاعات و تنظیم برنامه‌ای برای اتوماسیون امنیتی تأکید می‌کند . این همچنین لزوم کمک به برنامه‌نویسان را برای کد نویسی با در نظر داشتن نکات امنیتی تأکید می‌کند. واقعاً امنیت داخلی به چه صورت است؟ برای مبتدیان، یک استراتژی خوب DevSecOps تعیین تحمل ریسک و انجام تجزیه و تحلیل ریسک / سود است. چه مقدار از کنترل‌های امنیتی در یک برنامه خاص لازم است؟ سرعت در بازار برای برنامه‌های مختلف چقدر مهم است؟ خودکار کردن کارهای مکرر برای DevSecOps کلیدی است، زیرا انجام کنترل‌های امنیتی دستی در خط تولید ممکن است بسیار دست و پاگیر باشد.

نتیجه‌گیری:

قابلیت تغییر یک تمرین ضروری برای بهبود مستمر در ارایه‌ی خدمات فناوری اطلاعات و یکی از حلقه‌های طلایی زنجیره‌ی ارزش خدمات است. با ساده‌سازی، اتوماسیون‌سازی برای تسریع در اجرا، تعیین دامنه و ارتباط منسجم با CI-ها می‌توان بر چالش‌های آن فائق آمد و نظرات DevOps-ها را نیز به این تمرین مهم جلب کرد.

هادی احمدی

مدانت
مدانت
شرکت‌ مدانت از برندهای محبوب فناوری‌ اطلاعات و ارتباطات در حوزه‌ی آموزش، پیاده‌سازی و عرضه ابزار ITIL، تجارت آنلاین، تحول دیجیتال و ارایه‌‌کننده‌ی محصولات مدیریتی تحت‌وب در ایران است. این مقاله‌ی آموزشی منحصراً مربوط به مدانت بوده و برای نخستین بار توسط این شرکت برای شما تولید و منتشر شده.
0 0 رای ها
امتیازدهی به مقاله
اشتراک در
اطلاع از
guest

حل معادله *

4 نظرات
قدیمی‌ترین
تازه‌ترین بیشترین رأی
بازخورد (Feedback) های اینلاین
مشاهده همه دیدگاه ها
trackback

[…] تمرین قابلیت/کنترل تغییر […]

trackback

[…] تمرین قابلیت/کنترل تغییر […]

trackback

[…] صفر تا صد قابلیت تغییر […]

error: نیازی به کپی نیست همه چیز در دیدرس شماست
4
0
افکار شما را دوست داریم، لطفا نظر دهید.x