دعوای Devops و ITIL

دعوای Devops و ITIL

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

همانطور ممکن است اطلاع داشته باشید: Devops -DEVelopment و OPerationS یک فرهنگ، جنبش یا عمل است که بر همکاری و ارتباط هر دوی توسعه دهندگان نرم افزار و سایر متخصصان فناوری اطلاعات (IT) تکیه دارد و برای اتوماسیون سازی روند تحویل نرم افزار و تغییرات زیرساخت های فناوری، از آن یاد می شود در حالی که ITIL یک لغت نامه برای کتابخانه زیرساخت فناوری اطلاعات است که مجموعه ای از بهترین شیوه های مدیریت خدماتITSM در IT است که تمرکز بر تراز کردن خدمات فناوری اطلاعات (عملیات) همراه با نیازهای کسب و کار دارد.

ITIL تقریباً شناخته شده تر است زیرا قدیمی تر است در اینجا می خواهیم واژه ی Devops را به عنوان یک فلسفه جدید بنویسم که ابزارهای چابک توسعه نرم افزار را برای پیاده سازی آن در یک محیط زنده یا عملیاتی مرتبط می کند. Devops و ITIL هر دو محصولی از دوره ای است که در آن اختراع شده اند. ITIL در اواخر دهه ۸۰ در زمانی اتفاق افتاد که متوجه شد که وابستگی شدید و رو به رشد سازمانها در فناوری اطلاعات وجود دارد و ضروری است که لازم است تا شیوه های استاندارد برای مدیریت این رشد وجود داشته باشد. و از سوی دیگر Devops در سال ۲۰۰۸ و زمانی از روش آبشاری برای توسعه نرم افزار، محیط برنامه های بسیار برنامه ریزی شده و کنترل شده، استفاده می شد مطرح گردید.

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

Devops “گروه های چند رشته ای هستند که مسئولیت اولیه را برای تولید ارزش برای مشتری و اغلب سریعا و به طور مداوم برای بهبود مستمر خدماتی را ارایه می کنند.”

کسانی هستند که طرفدار استفاده از ITIL با DevOps هستند. اما بد نیست بدانید که جنبش DevOps کاملا با ITSM سازگار است. “ITIL و ITSM هنوز هم بهترین فرآیندهای کسب و کار هستند که عملیات IT را پایه گذاری می کنند و در واقع بسیاری از قابلیت های مورد نیاز برای عملیات IT جهت پشتیبانی از کارکرد DevOps را ارایه می کند.”ITIL با DevOps مخالف نیست، اما ITIL باید به شیوه های DevOps سازگار باشد تا به وضوح مشخص شود که حل مسائلی که بوجود می آیند را چگونه می توانید موثر واقع گردد.

در حالی که منتقدان می گویند در رویکرد پی در پی و برنامه ریزی شده ITIL نقدهایی وجود دارد، کیمار کارو، رئیس عملیات ITSM در Axelos، در خصوص صاحبان چارچوب ITIL می گوید: “فرایندها رویکرد نیاز عقلانیت مشترک را ارایه نمی کنند، پاسخی که برای اینکه کدامیک از این دو برای هدف و استفاده مناسب ترست را می توان در این پرسش مطرح کرد: “ساده ترین فرآیندی که من می توانم طراحی کنم تا نیازهای پشتیبانی را کنترل و در عین حال اطمینان حاصل شود که ارزش مشتری حفظ و ایجاد می شود چه فرایندی است!؟”

در نتیجه؛ می توان از تصویب شیوه های DevOps در ITIL در سازمان به عنوان تکامل یک رویه منظم بر اساس فرایندها به یک سیستم برای مقابله با چالش های زمان واقعی برای اجرای سریع خدمات فکر کنم. حال آن رویه منظم ITIL  باشد یا DevOps هر جور که پروسه ای ساده تر و سریعتر را به من القا کند همان بهترین انتخاب است یا اینکه ترکیبی از این دو! از فرآیندهای ITIL به عنوان نقطه شروع برای تجزیه و تحلیل مزایای بالقوه بهره گرفت در حالیکه پیاده سازی DevOps می توان تمرکز زیادی را به همراه داشته باشد. این می تواند نقاط دردناک و مشترکی باشد که می توان از طریق همکاری و اتوماسیون سازی، آن دو بیشتر بهره مند شد.

تفاوت ها! دعوا بر سر چیست!؟

به نظر می رسد که افراد به سختی تصمیم می گیرند که DevOpS ها اصلا دقیقا چه چیزهای هستند، و چقدر آن را با یک روش بسیار سازمان یافته مانند ITIL مقایسه می کند. برای پاسخگویی به سوالات بزرگ شما مجبور نیستید بین DevOps و ITIL یکی را انتخاب کنید؛ DevOps جایگزین ITIL یا بالعکس نیست؛ DevOps تمام مشکلات محیط ITIL را حل نخواهد کرد، DevOps با اجرای ITIL کامل نخواهد شد. اما ساختن فرایندهای IT خوب، کلید انعطاف پذیری است که در ادامه این بحث جذاب سعی داریم به آن بپردازیم:

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

ما به چند سناریوی معمولی که مردم را به درون دعوای ITIL وDevOps دعوت می کنیم و اینکه چگونه هر سیستم می تواند بهترین کمک را برای حل مشکل داشته باشد بنابراین پیش از اینکه آنها را مقایسه کنیم، ابتدا DevOps و ITIL را برای خود تعریف کنیم.

DevOps

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

اضافه کردن کمی ساختار به امور فردی هرگز آسیب جدی نمی زند، به ویژه هنگامی که برای فرآیندهای کسب و کار و دارایی های IT باشد.

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

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

ITIL

بر خلاف DevOps، چارچوب ITIL یک روش بسیار سازمان یافته است که برای افزایش کارایی و ارائه آمار برای عملیات IT طراحی شده است. ITIL یک نوع ITSM است و به طور عمده بر اساس پروتکل ها بر اجرای مدیریت و بهبود خدمات فناوری اطلاعات به کسب و کار و یا مشتری متمرکز است.

از آنجا که ITIL بسیار سازمان یافته است، بسیاری از اصطلاحات و مفاهیم خاصی وجود دارد که باید به طور موثر مورد استفاده قرار گیرد. از سال ۲۰۱۳، ITIL مالکیت فکری AXELOS بوده است، که مجوز ITIL را ارائه می دهد، گواهینامه ها را ارائه می دهد و چارچوب ITIL را به روز می کند. این به این معنا است که ITIL یک سیستم اختصاصی است که توسط یک شرکت خصوصی و سودآور اداره می شود، بلکه نه فلسفه بی نظیر و بی ادب مثل DevOps.

پیچیدگی و گستردگی ITIL باعث ایجاد سردرگمی برخی مدیران و کارشناسان فناوری اطلاعات می شود . حتی دقیقا نمی دانند که چرا که ITIL تنها کار می کند و همچنین اجرا می شود. این به معنای سرمایه گذاری قابل توجهی از زمان و پول برای ایجاد یک تیم ITIL است. ITIL قبل از DevOps پیش رفته است، بدیهی است حوزه هایی که ITIL پوشش می دهد هنوز برخی از نیازهای سازمان ها توسط DevOps برآورده نمی شود.

اجازه دهید چند سناریوی معمول را ببینیم و اینکه چگونه DevOps و ITIL می توانند به هم کمک کنند.

چند سناریو از دعوای بین ITIL و DevOps

“فرایند تحویل نرم افزار نیاز به تعمیرات اساسی دارد.”

مشکل: تقاضای بالا در تولید نرم افزار، نیازمند تغییرات سریع تر، رفع و ارایه به روز رسانی ها، و همچنین ادغام تست و QA در فرآیند توسعه است. روش های سنتی استقرار ما اجازه نمیدهد که ما به فعالیت تجاری خود ادامه دهیم.

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

ITIL: ITIL چارچوب بسیار خاصی برای ارائه نرم افزار دارد و بیشتر در مورد ادغام فرآیند تحویل به سایر فرآیندهای کسب و کار با تعریف ذینفعان و ایجاد پروتکل ها تمرکز می کند. این به خوبی خود می تواند سبب پوشش DevOps هم شود، زیرا در حالی که DevOps دارای اصول کلی است، ITIL دارای دستورالعمل های دقیق برای پیگیری است.

راه حل: وجود DevOps برای این فرایند بسیار مهم است، در حالی که ITIL می تواند مناسب باشد اما لازم نیست. ITIL ، در این بخش می تواند بسیاری از نوآوری ها را برای DevOps به ارمغان می آورد.

IT یک” جعبه سیاه “برای بقیه کسب و کار است.”

مشکل: بیشتر کسب و کار فاقد چشم انداز در فرآیندهای فناوری اطلاعات خود هستند. فقدان معیارهای عینی، مؤثر، مانع از مدیریت و توسعه فناوری اطلاعات می شود چشم انداز همه چیز از بودجه به استراتژی. مدیران ارشد این کسب و کارها احساس ناخوشایندی در مورد فناوری اطلاعات مطرح می کنند، زیر احساس بی اعتمادی نسبت به فناوری اطلاعات یا مانند آن “ضروری نیست” و یا “پر هزینه است”) دارند.

: DevOps کمک می کند تا فناوری اطلاعات، بهتر با کسب و کار هماهنگ باشد، اما این بیشتر به عنوان یک اثر جانبی از سایر کارآیی ها است. به دست آوردن دید کلی در محیط فن آوری، اولین گام به سوی ادغام فناوری اطلاعات در کسب و کار است، و شیوه های DevOps به چشم انداز بالا، به ویژه با ابزاری خاص، ارائه می شود که نمای کلی از تنظیمات، و همچنین یک خلاصه اجرایی تجسم می کند.

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

راه حل: ITIL در اینجا مزیت برتر را دارد، زیرا دقیقا به این مسئله هدایت می شود، اما در عوض DevOps چندین آچار را نیز دارد که با ابزارهای دید و ورود به سیستم می توانند فرایندهای ITIL را عملی تر کنند. DevOps به خودی خود می تواند برای ایجاد یک تغییر فرهنگی موثر واقع می شود تا حرفه ای های IT را از نقش خود در کسب و کار آگاه تر کنند و بیشتر تصمیمات و انتخاب هایی که از چشم انداز دور را پوشش می دهد استفاده از ویژگی های دو می تواند به کاهش این مشکل کمک کند.

“متخصصین فناوری اطلاعات،در پروژه ها روحیه کمی دارند.”

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

DevOps: همراه با تحویل نرم افزار، شکستن سیلوهای IT یکی از نکات اصلی جنبش DevOps بود. هر کسی که در IT کار می کند، می داند که چطور یک سیلور دانش(انباردان دانش) می تواند چیزهایی را ایجاد کند. تمرین کنندگان DevOps اغلب از همدلی و وحدت کلمه استفاده می کنند، زیرا در حال مرتب کردن کفش های دیگران در کنار کفش شخصی و تلاش برای درک انتخاب هایی که ساخته شده، هستند، این همان کلید همکاری است. ابزارهایی مانند Slack یا هیئت مدیره Kanban می توانند به تیم های متصل و تجسم کار در حال پیشرفت کمک کنند.

ITIL: از لحاظ فنی ITIL هم می تواند به دانش سیلو نشده کمک کند؛ زیرا توصیه میکند تا همه از روش متداولی پیروی کنند تا همه چیز مستند شود. اما در عمل، ITIL ممکن است به هیچ وجه جلوی دانش سیلو شده را نگیرد و حتی می تواند سیلوهای اضافی مانند “فردی که در مورد ITIL می داند” ایجاد کند.

راه حل: اگر سیلوهای دانش، مشکل سازمان باشند، یک رویکرد DevOps ممکن است بهترین راه برای شکستن آنها باشد، زیرا بر جنبه های انسانی متمرکز است که به دلیل اینکه دانش به اشتراک گذاشته نشده است، به شدت تأثیر می گذارد. اما چارچوب ITIL، کمک می کند تا در حال حاضر مستندی را بین افراد یک بخش یا کاربران به اشتراک گذاشت که این مهم علاوه بر حفظ داده ها، می تواند به تنظیم پروتکل های بین واحدی کمک کند.

“تلاش برای تغییر، یک کابوس است.”

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

DevOps: یکی از بزرگترین مشکلات مدیریت تغییر ساختار یافته، این است که این فرآیند می تواند افراد را گول بزند و گاهی حتی هدف را. تغییراتی که از دست رد می شوند، شایع تر می شوند و راه هایی که برای تأیید آنها به دست می آیند، باریک و شلوغ می شوند، و وجود این تنگنا در یک فرآیند، ساده سازی و اجرای فوری را با مشکلات بیشتری مواجه می کند، اصول DevOps می تواند کمک کند: تا همکاری، مشارکت رو در رو، همدلی را توسعه داد تا سریعتر تغییرات اجرا شود: این چیزهای کاملا ساده، می توانند یک فرایند مدیریت تغییر محدود را به یک فعالیت مؤثر تبدیل کنند.

: ITIL یکی از محبوب ترین فرآیندهای مدیریت موجود در تغییر را ارایه می کند و اگر مشکل این است که شما در حال حاضر راه خوبی برای مدیریت تغییر ندارید، ITIL دقیقا همان چیزی است که به دنبال آن هستید. از آنجا که تغییر می تواند بسیار متضاد باشد، داشتن یک پروتکل کتبی در مورد چگونگی استفاده از آن، استرس را کاهش می دهد و افراد ابتدا آنرا ارزیابی می کنند که آیا نظرات متضادند یا خیر؟ و تا زمان تایید اجرا، تغییر پیاده سازی نمی شود.

راه حل: ITIL دارای چارچوب است، DevOps به شما یادآوری می کند که افراد واقعی درگیر هستند. اگر مدیریت تغییر، مشکل بزرگی است، به یاد داشته باشید ابزارها و چارچوب ها برای حل آن کافی نیست: افرادی که درگیر آن هستند هنوز باید چارچوب را بخرند و از چارچوب استفاده کنند و از ابزارهایی برای بهبود واقعی استفاده کنند. به همین دلیل با شفاف سازی بیشتر و ملاقات های رو در رو، مدیریت تغییر با ITIL یک کابوس هولناک نیست.

“من در حال تلاش برای حل یک مشکل هستم اما دقیقا نمی دانم این ابزارها چه کمکی به من می کنند فقط در مورد DevOps / ITIL چیزهایی شنیدم”!

مشکل: شما در مورد DevOps، ITIL و دیگر سیستم هایی که بخش های فناوری اطلاعات را تحریک می کنند، و یا حداقل در حال پا گرفتن در دنیای تکنولوژی است را بسیار شنیده اید، و می خواهید بدانید که چگونه یک یا چند تا از آنها می تواند به محیط شما کمک کند.

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

نتیجه نهایی

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

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

تعجب نکنید که آیا فرایندهای شما کار می کنند یا نه! فقط ابتدا آنها را تجسم کنید!

نوشته : هادی احمدی

#MedaNet #ServiceDesk #ITIL #ITSM #ITAM #ITOM #Manageengine #Zoho #Webtick #Agile

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

حل معادله *

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

[…] دعوای DevOps و ITIL را از اینجا بخوانید […]

trackback

[…] هدف اصلی تیم‌های DevOps ایجاد تعداد بالای نسخه‌های تولیدی قابل اعتماد که همواره روندی افزایشی در پی دارد و جلسه CAB اغلب به عنوان پادزهر این امر تلقی می‌شود، که بسیار مناسب هم هست و جلوی تولید و تغییرات ناخواسته را می‌گیرد اما گاهاً فرایند بررسی و تصویب تغییر در تولید یک روند دشوار و زمانبری ایجاد می‌کند و ممکن است کسب اجازه‌ی تغییر پس از صرف‌کردن زمان زیاد در جلسات، حدود یک یا دو هفته زمان نیاز داشته باشد. همین موضوع سبب ناراحتی تولیدکنندگان DevOps‌ می‌شود، که از نظر آنها فرایند تایید در کمیته CAB تا حدی ناعادلانه است. دلایل آنها نیز گاها درست است. خوشبختانه، ITSM در طی سالیان متمادی تفکر خود را متحول کرده و تلاش زیادی برای تطبیق نیازهای DevOps با ITIL انجام داده. به عنوان مثال: داشتن بررسی CAB برای هر درخواست تغییر، کارآمد نیست و قطعاً منطقی هم نیست. دعوای DevOps و ITIL را از لینک زیر بخوانید. […]

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