دعوای 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 می تواند به شما و سازمان کمک کند.

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