https://virgool.io/feed/@babak_izadi من بابک ایزدی، مدیرعامل شرکت رایزن سامانه گستر و همچنین مشاور و مدرس حوزه چارچوبها و استانداردهای مدیریت IT مانند ITIL, DevOps, COBIT و ... هستم. fa 2026-06-18 17:23:30 https://files.virgool.io/upload/users/40451/avatar/5grzej.png?height=120&width=120 https://virgool.io/@babak_izadi https://virgool.io/@babak_izadi/%D9%85%D8%B3%D8%AA%D9%86%D8%AF-sla-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%D9%85%D8%AD%D8%AA%D9%88%D8%A7%DB%8C-%D8%A2%D9%86-%DA%86%D9%87-%DA%86%DB%8C%D8%B2%DB%8C-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A8%D8%A7%D8%B4%D8%AF-uqa7frbajufu مستند SLA یکی از شناخته‌شده‌ترین اسناد در حوزه مدیریت فناوری اطلاعات است. اگرچه این سند، یکی از چندین بهروش معرفی شده در چارچوب ITIL است اما عموم افراد بدون اینکه حتی اسمی از ITIL شنیده باشند و یا با آن آشنایی داشته باشند با واژه SLA برخورد داشته‌اند.واژه SLA مخفف شده عبارت Service Level Agreement یا همان توافقنامه سطح خدمت است. حال ممکن است برای شما این سوال پیش بیاید که سطح خدمت چه چیزی است که باید توافقنامه‌ای هم برای آن تنظیم شود. پاسخ ساده است، سطح خدمت به مجموعه‌ای از ویژگی‌های قابل اندازه‌گیری و موثر در ارائه یک خدمت گفته می‌شود. به عنوان مثال آیا زمانیکه یک خدمت فناوری اطلاعات به مشتری ارائه می‌شود، محدودیتی برای تعداد کاربرانی که قرار است بصورت همزمان به آن متصل شده و از آن استفاده کنند در نظر گرفته شده است یا خیر؟ اگر فرض کنیم که شما ارائه کننده این خدمت هستید، پیش فرضی برای این تعداد در نظر نگرفته‌اید؟ آیا از نظر زیرساخت و معماری، تفاوتی بین خدمتی که قرار است چهار، چهل، چهارصد یا چهار هزار کاربر همزمان داشته باشد وجود ندارد؟ بطور حتم جواب تمامی این پرسش‌ها مثبت است. هر ارائه‌کننده خدمت برای خود پیش‌‌فرضهایی را لحاظ کرده و در کنار تخصیص منابع متناسب با همان پیش‌فرضها، منابع، زیرساخت، طراحی و معماری خدمت را نیز بر همان اساس پایه‌گذاری کرده است.اما مسئله اصلی و یکی از کلیدی‌ترین مشکلات در طراحی و ارائه خدمات، عدم شفافیت در پیش‌فرضهایی این چنین است. ارائه‌کننده خدمت زیرساختی مناسب جهت ارائه آن به ۱۰ کاربر را به خدمت گرفته (چرا که بر اساس تجربیات و معیارهای خود همین تعداد برای نیاز مشتری کفایت خواهد کرد)، اما مشتری انتظار دارد که ۱۰۰۰ کاربر همزمان بدون مشکل از آن خدمت استفاده کنند. طبیعتا همین مسئله نقطه آغازین بروز مشکلات و درگیری‌های بین ارائه‌کننده و استفاده کننده خدمات است.چارچوب ITIL که در برگیرنده مجموعه متنوعی از بهروش‌های کاربردی در حوزه مدیریت خدمات فناوری اطلاعات است، توصیه می‌کند تا نیازمندی‌های مشتری در نقطه آغازین به درستی شناسایی شده و پس از شفاف‌سازی در رابطه با انتظارات مشتری و توانمندی‌های  ارائه کننده خدمت، توافقاتی بصورت مستند، بین این دو صورت پذیرد. این توافق مستند شده همان سند SLA و مورد بحث در این نوشته است.پس تا اینجا مشخص شد که این سند در برگیرنده مجموعه‌ای از توافقات در رابطه با یک یا چند خدمت ارائه شده توسط ارائه‌کننده خدمات است. اما اینکه این سند حاوی چه مواردی باشد بطور حتم متاثر از نوع خدمت و جنبه‌های پر اهمیت در رابطه با آن است. به عنوان مثال فعالیت‌هایی از جنس پشتیبانی، برای اغلب مشتریان و عموم خدمات پر اهمیت است و به عنوان مثال لازم است تا در SLA مستند شده باشد که آیا شما این خدمت را بصورت ۲۴ ساعته پشتیبانی می‌کنید یا تنها در ساعات اداری؟ مشتری با چه فاصله‌ای از زمان اعللم یک حادثه می‌تواند انتظار رفع آن‌را توسط شما داشته باشد؟ یا حتی موارد پایه‌ای‌تر! کانال‌های معتبر و توافق شده جهت برقراری ارتباط و گزارش یک حادثه توسط مشتری کدامند؟ آیا تماس تلفنی یک مسیر معتبر است؟نکته حائز اهمیت در گزینش اقلام اطلاعاتی مورد نظر جهت درج در این توافقنامه این است که اقلام از پیش تعریف شده‌ای جهت درج در این سند جز موارد عمومی و پایه‌ای وجود نخواهد داشت و تمامی این اقلام متناسب با نیاز مشتری و شرایط خدمت، شناسایی شده و پس از بررسی و مذاکره‌های لازم به عنوان یک توافق دو طرفه در مستند SLA ثبت می‌گردند. با این توضیح، به اهمیت بسیار بالای تعامل مستقیم بین ارائه‌کنندگان و استفاده‌کنندگان از خدمات پی خواهیم برد.در اغلب موردکاوی‌های انجام شده، مشاهده شده است که در صورت عدم شفاف‌سازی و توافقِ مستند در رابطه با مولفه‌های کلیدی مرتبط با هر خدمت، سمت ارائه‌کننده خدمت بیشتر تحت تاثیر قرار گرفته است. در این موارد مشاهده شده که ارائه‌کننده خدمت عمدتا بخاطر مسائلی چون حفظ اعتبار و جلوگیری از ضرر و زیان قابل توجه، به انجام مواردی مجبور شده که از نظر خود، هیچ تعهدی نسبت به آنها نداشته است.در پایان توجه داشته باشید که سند توافقنامه سطح خدمت، همانند تمامی توافقنامه‌ها و قراردادها حاوی بخش‌های عمومی نظیر موضوع توافق (همان خدمت مورد نظر) و اطلاعات طرف‌های مذاکره (ارائه‌کننده خدمت و استفاده‌کننده از آن)، تعهدات طرفین (دقت کنید که در اغلب موارد، لازم است تا استفاده‌کننده خدمت نیز مجموعه‌ای از تعهدات را برای استفاده از خدمت پذیرفته باشد) و موارد خاص که متناسب با نیاز طرفین ممکن است به این توافقنامه افزوده شود. توجه کنید که هیچگاه در تنظیم این سند چه در جایگاه ارائه‌کننده خدمت و چه در جایگاه استفاده‌کننده از خدمت، هیچ موردی را به عنوان یک پیش‌فرض ذهنی در نظر نگیرید و تمامی مواردی که لازم است را در سند درج کنید. به عنوان مثال اگر شما قرار است یک خدمت ابری را از یک ارائه‌کننده خدمت دریافت کنید، تهیه نسخه پشتیبان از زیرساخت و یا پایگاه‌داده ارائه شده را به عنوان پیش‌فرض لحاظ نکنید و چنانچه انتظار دارید تا ارائه‌کننده خدمت این مورد را هم لحاظ کند، حتما در مذاکرات به آنها بپردازید و در نهایت بر روی آن توافق کنید. و یا اگر شما در جایگاه ارائه‌کننده خدمت هستید و قرار نیست مسئولیتی در قبال تهیه نسخ پشتیبان داشته باشید، آن‌را حتما در این توافقنامه درج کنید.در آخر، اگر تصمیم دارید برای سازمانتان، سند SLA آماده و تنظیم کنید، تیم مشاوره مدیریت رایزن سامانه گستر آماده است تا در این مسیر کنار شما باشد و با در اختیار قراردادن دانش و تجارب خود، شما را در این مسیر یاری کند. در صورت تمایل می‌توانید با تیم مشاوره ما در تماس باشید. بابک ایزدی بابک ایزدی Sat, 14 Aug 2021 22:01:10 +0430 https://virgool.io/@babak_izadi/devops-%DA%86%DB%8C%D8%B3%D8%AA-ai4btp4t8fud بخش عمده‌ای از فضای فناوری اطلاعات در ایران، همانند سایر کشورهای جهان تحت تاثیر عبارات و کلمات دهان‌پرکنی است که به یک استاندارد، چارچوب و یا یک مفهوم تازه متولد شده اشاره دارد. نکته حائز اهمیت در این تاثیرپذیری طول عمر کوتاه آن و حرکت به سمت یک مفهوم و یا فناوری تازه از راه رسیده دیگر در مدت زمانی بسیار کوتاه است. بطور حتم بخش عمده‌ای از این تلاطم و این‌سو و آن‌سو رفتن‌ها ناشی از ذات فناوری اطلاعات و پویای بسیار شدید آن است؛ اما مشکل از آنجایی آغاز می‌شود که عمده شرکت‌ها و سازمان‌ها بدون درک صحیح و تحلیل مناسب در رابطه با ضرورت استفاده از یک استاندارد، چارچوب و یا مفهوم جدید، همراه با این موج‌های زودگذر به این‌سو و آن‌سو در حرکت هستند و منابع با ارزش خود را (زمان، پول، توان نیروی انسانی و …) بدون عایدی مناسبی در این مسیر هدر می‌دهند.واژه DevOps یکی از این واژه‌های نسبتا تازه وارد به فضای فناوری اطلاعات ایران است. واژه‌ای که عمده شناخت متخصصین فناوری اطلاعات از آن، به اینجا ختم می‌شود که ترکیبی از دو کلمه Development (توسعه) و Operation (عملیات) است. حال تصور کنید که با همین سطح از شناخت، پروژه‌های متعددی در سازمان‌های کوچک و بزرگ شکل‌گرفته و یا در حال شکل‌گیری است. هدف اصلی این نوشته کمک به ایجاد یک شناخت کلی نسبت به این جنبش در سطح دنیاست، تا شرکت‌ها و سازمان‌هایی که تمایل به سرمایه‌گذاری در این حوزه را دارند بتوانند با اشراف اطلاعاتی بیشتر و دید بازتری نسبت به این حوزه تصمیم‌گیری و برنامه‌ریزی کنند.واژه DevOps چیست؟همانطور که قبل‌تر اشاره شد واژه DevOps ترکیبی از دو کلمه Development و Operation است. اما برای درک بهتر ضرورت قرارگیری این دو کلمه در کنار هم و ایجاد یک ترکیب جدید، بهتر است تا موضوع را کمی ریشه‌ای تر بررسی کنیم. نکته کلیدی در رابطه با واژه DevOps این است که DevOps یک استاندارد، چارچوب، متدولوژی، عنوان شغلی و … نیست. بلکه یک رویکرد نوین نسبت به مدیریت فضای فناوری اطلاعات و چالش‌های موجود در آن است. رویکردی که میتوان آن را به عنوان یک جنبش با عمری بیشتر از ده سال و در راستای پاسخ به یک سوال ریشه‌ای طبقه‌بندی کرد: چگونه میتوانیم یک مجموعه فناوری اطلاعاتی با عملکردی برتر داشته باشیم؟ بطور مثال اگر تولید کننده نرم‌افزار هستیم، چگونه میتوانیم فواصل زمانی مابین ویرایش‌ها و نسخ نرم‌افزارهای تولیدشده‌مان را کوتاه کرده و انتشارهای بیشتری از محصولات‌مان ارائه کنیم؟ علیرغم اینکه پاسخ به این پرسش‌ها میتواند بسیار سخت و پیچیده به نظر بیاید، اما یک پاسخ بسیار ساده و منطقی نیز برای آن در دسترس است و آن پاسخ چیزی نیست جز: با اصلاح و حذف آن چیزهایی که مانع تحقق چنین شرایطی میشوند. به همین سادگی!چگونه میتوانیم یک مجموعه فناوری اطلاعاتی با عملکردی برتر داشته باشیم؟ با اصلاح و حذف آن چیزهایی که مانع تحقق چنین شرایطی میشوند. به همین سادگی!با این نوع نگاه به مسئله، هر سازمان اکنون می‌تواند متناسب با شرایط داخلی خود، DevOps را تعریف کرده و برای حرکت به سمت شرایط ایده‌آل برنامه‌ریزی کند.چگونه می‌توانیم سازمانی با عملکرد برتر داشته باشیم؟همانطور که در بخش قبل هم به این پرسش اشاره شد، پاسخ بسیار ساده است، می‌بایست عواملی که عکس این نتیجه را رقم میزنند شناسایی و از مسیر خود حذف کنیم. احتمالا اگر بخواهیم چنین مواردی را شناسایی کنیم با یک لیست بلند در هر سازمان مواجه خواهیم شد، اما در ادامه نگاهی مختصر به برخی از رایج‌ترین و موثرترین این عوامل خواهیم انداخت.ساختار سازمانیساختار سازمانی و نحوه تقسیم‌بندی وظایف افراد در سازمان همواره یکی از عوامل موثر در اتلاف زمان و کاهش بهره‌وری در سازمان محسوب می‌شود. در اغلب سازمان‌ها، افراد بر حسب تخصص و نوع فعالیت‌شان دسته‌بندی شده‌اند. به عنوان مثال در یک سازمان که تولید کننده سامانه‌های نرم‌افزاری‌ست افراد به این شکل و مطابق با گام‌های مورد نیاز تقسیم‌بندی شده‌اند: تیم تحلیل، تیم طراحی، تیم توسعه، تیم تست، تیم استقرار و …؛ که خود، یکی از عوامل ریشه‌ای مشکل مورد بررسی است. برای درک بهتر مشکل، تصور کنید که مدت زمان انجام هر یک از فعالیت‌ها (نظیر تحلیل، طراحی و …) پنج روز است و در مجموع هم، همان پنج فعالیتی که قبل‌تر به عنوان اسامی تیم‌ها ذکر شد برای تولید و ارائه یک سامانه نرم افزاری مورد نیاز است. با این اطلاعات، فکر میکنید مدت زمان مورد نیاز جهت ارائه یک قابلیت جدید در سامانه نرم‌افزاری مورد نظر چند روز است؟در شرایط کلی انتظار می‌رود که این مدت ۲۵ روز باشد. پنج مرحله که هر کدام پنج روز زمان می‌برد و در نتیجه به نظر می‌رسد که ۲۵ روز برای انجام این فعالیت‌ها کفایت کند. اما در واقعیت این ۲۵ روز تنها به زمان مفید و قطعی مورد نیاز اشاره دارد و در شرایط واقعی می‌بایست زمان‌های غیر مفید نظیر انتظارهای بین هر مرحله، هماهنگی‌های لازم و … را نیز مد نظر قرار داد. آیا تیم طراحی بلافاصله پس از دریافت مستندات تولید شده توسط تیم تحلیل، دست به کار می‌شوند؟ تیم توسعه چطور؟ آیا تیم استقرار، زیرساخت مناسب جهت استقرار نرم‌افزار تولید شده را در اختیار دارد و بلافاصله پس از دریافت نسخه اجرایی نرم‌افزار نسبت به استقرار و راه‌اندازی آن اقدام خواهد کرد؟ بطور حتم هیچ کدام از این مراحل این چنین نخواهد بود و این ۲۵ روز ممکن است با اضافه شدن زمان‌های غیر مفید، در بازه زمانی مثلا ۶۰ روز و یا حتی بیشتر به نتیجه برسد.جریان ارزشحال بماند که همین شرایط باعث می‌شود تا در نهایت یک پاسخگوی متمرکز و نهایی هم وجود نداشته باشد و در صورت بروز مشکل، هر تیم مسئولیت بروز آن را بر دوش دیگری خواهد انداخت.پس بطور حتم می‌توان انتظار داشت که حرکت به سمت شرایط آرمانی مورد انتظار از DevOps نیازمند اعمال اصلاحات بنیادین در ساختار و نحوه دسته‌بندی افراد در سطح سازمان و همچنین ایجاد تحول در فرهنگ جاری سازمانی خواهد بود. این تغییر در ساختار و شرح وظایف، بصورت سمبلیک با کنار هم قرار گرفتن دو واژه Development و Operation در کنار یکدیگر و خلق واژه DevOps به تصویر کشیده می‌شود.فرآیندهای سازمانیوجود یا عدم وجود فرآیندهای سازمانی مستند شده و در حال اجرا، هر کدام گرفتاری‌های خود را برای سازمان به همراه خواهد داشت. از یکسو عدم وجود فرآیندهای سازمانی، ایجاد کننده بی‌نظمی و اعمال سلایق شخصی در طول کار خواهد بود و از سوی دیگر بسیاری از فرآیندهای سازمانی هم به دلیل عدم توجه به اصل چابکی، مسبب بروز کندی و وقفه‌های بعضا طولانی مدت در طی مسیر یک فعالیت هستند.تصور کنید که می‌بایست بر اساس فرآیند از پیش تعریف شده مدیریت تغییر، برای انجام هر تغییر (به عنوان مثال افزودن یک قابلیت جدید در سامانه نرم‌افزاری) از کمیته‌ای که به این منظور تشکیل شده مجوز بگیرید و این در حالی است که این کمیته تنها هفته‌ای یکبار تشکیل جلسه می‌دهد! این شرایط به این معنی خواهد بود که شما در اغلب حالت‌های ممکن می‌بایست وقفه‌ای در حدود یک هفته را برای انجام ساده‌ترین تغییرات که ممکن است تنها به یک ساعت زمان نیاز داشته باشد را پیش‌بینی کنید.می‌توان از زوایای دیگری نیز به این مسئله پرداخت. آیا می‌توانید تصور کنید، سازمانی که برای تولید محصولات خود از روش آبشاری (Waterfall) استفاده می‌کند بتواند در طول یک هفته، چندین نسخه جدید از محصول خود به مشتری ارائه کند؟ بطور حتم نه! چرا که در این رویکرد، مراحل تولید یک محصول در قالب فرآیندهای مستقل پیش‌بینی شده و تنها در صورتی می‌توان به مرحله بعدی وارد شد، که مرحله جاری بصورت کامل به اتمام رسیده باشد. به عنوان مثال تا زمانیکه فرآیند تحلیل محصول تمام نشده باشد نمی‌توان به مرحله طراحی وارد شد و یا زمانیکه مرحله طراحی بصورت کامل تمام نشده باشد نمی‌توان به مرحله توسعه وارد شد. پس بطور حتم لازم است تا چنانچه می‌خواهیم سرعت انتشار نسخ محصولاتمان را افزایش دهیم، در رابطه با رویکرد مورد استفاده در توسعه محصولات نیز تجدید نظر کنیم و به عنوان مثال از رویکردهای چابک (Agile) نظیر اسکرام (SCRUM) استفاده کنیم.معماری نرم‌افزار (محصول)آیا معماری نرم‌افزار یا همان محصولی که در حال کار بر روی آن هستیم هم در سرعت عمل و چابکی ما موثر است؟ بطور حتم پاسخ مثبت است. تصور کنید که در حال کار بر روی یک محصول بزرگ و پیچیده هستید. پیچیدگی و وابستگی‌های متعدد اجزاء مختلف سبب خواهد شد که انجام تغییرات با ریسک و پیچیدگی بسیار زیادی همراه باشد. توسعه در هر بخش، می‌تواند باعث بروز اختلال در عملکرد سایر بخشها باشد و همین امر سبب می‌شود تا فرآیند توسعه با کندی‌های غیر قابل کنترل و متعددی همراه باشد. همچنین این پیچیدگی‌ها و وابستگی‌ها میتواند در کنار تاثیر منفی بر روی توسعه محصول، بر روی سایر فعالیت‌های وابسته نیز نظیر تست، استقرار، پیکربندی و … نیز تاثیر مستقیم منفی داشته باشد.آیا معماری نرم‌افزار یا همان محصولی که در حال کار بر روی آن هستیم هم در سرعت عمل و چابکی ما موثر است؟ بطور حتم پاسخ مثبت است.معماری مایکروسرویسهر چه محصول بزرگتر و پیچیده‌تر باشد بطور حتم، استقرار و پیکربندی آن نیز بر روی بستر لازم پیچیده‌تر و زمان‌بر تر خواهد بود. پس چنانچه شما قصد داشته باشید برای سرعت بخشیدن به فعالیت‌ها و حرکت به سمت آنچه DevOps نامیده می‌شود گام بردارید، می‌بایست در راستای ساده‌سازی و شکست ساختار محصول خود نیز اقداماتی جدی را در دستور کار داشته باشید. به عنوان مثال حرکت به سمت معماری مایکروسرویس یکی از رویکردهای شناخته شده برای تحقق همین مهم است.بسترهای مورد استفادهمیتوان از بسترها و زیرساخت‌های مورد استفاده، به عنوان یکی دیگر از عواملی که می‌توانند باعث بروز کندی و وقفه در چرخه تولید و ارائه یک محصول باشند، نام برد. به عنوان مثال پیچیدگی‌های مرتبط با پیکربندی و راه‌اندازی یک سرور و تبعات ناشی از بروز مشکل در این حوزه بر کسی پوشیده نیست، پس شاید لازم باشد تا اگر به دنبال سرعت بخشیدن به چرخه ارائه محصول خود هستید، بکارگیری راهکارهای جایگزین را در دستور کار قرار دهید.داکر (Docker) یکی از انواع کانتینرهااستفاده از کانتینرهایی (Container) مانند داکر (Docker) یکی از رویکردهای مدرن در مسیر سرعت بخشیدن و ساده‌سازی فعالیت‌های مرتبط با استقرار یک محصول در محیط‌های مختلف توسعه، تست و یا عملیاتی است.انجام دستی فعالیت‌هابر کسی پوشیده نیست که انجام دستی بسیاری از فعالیتها، در کنار پیچیدگی و زمان‌بر بودنشان، حداقل به دلیل تکرار بالا، از محبوبیت حداقلی در بین کارشناسان فناوری اطلاعات برخوردار است. تصور کنید که شما در سازمانتان به آن شرایط ایده‌آل رسیده‌اید و مثلا می‌توانید هر روز نسخه جدیدی از محصول خود را ارائه کنید. اما آیا گمان می‌کنید که افراد درگیر با فرآیند استقرار و پیکربندی حاضر هستند هر روز رویه مربوط به نصب و راه‌اندازی نسخه جدید را به صورت دستی و تکراری انجام دهند؟ اگر بازه‌های زمانی انتشار نسخه به روزی ۲ یا ۳ بار رسید چطور؟می‌توان مطمئن بود که در بسیاری از موارد حتی اگر کارشناس مربوطه حاضر باشد که هر روز عملیات مربوط به استقرار نسخه جدید و پیکربندی مثلا ۱۰ سرور مرتبط را هم انجام دهد، محدودیت زمانی و فشارهای متعدد باعث بروز خطاهای انسانی پرتکرار خواهد بود و این شتاب بالا در ارائه نسخه جدید، در نهایت جز تاثیرات منفی، برای سازمان عایدی دیگری را به همراه نخواهد داشت.اگر شما کارشناس استقرار بودید، آیا حاضر می‌شدید تا در طول یکروز ۱۰ بار نسخه نصب شده از یک نرم‌افزار برروی مجموعه‌ای از سرورها را بروزرسانی کنید؟پس بطور حتم لازم است تا در این رابطه از روش‌ها و ابزارهای خودکارسازی در حوزه‌های مختلف، از تست گرفته تا پیکربندی استفاده نمود. ابزارهایی مانند Azure DevOps، Jenkins و … از شناخته‌شده‌ترین ابزارهای این حوزه محسوب می‌شوند.جمعبندیدر جمعبندی این نوشته تنها کافیست سوال آغازین و پاسخ آن را یادآوری کنیم. توجه داشته باشید که DevOps مفهوم و رویکردی چندان خارق‌العاده و عجیب نیست؛ بلکه نگاهی کل‌نگر به مشکلات موجود در سطح سازمان‌ها و فرصتهای بهبودی است که میتوان بصورت مرحله‌ای و تدریجی برروی آنها سرمایه‌گذاری نمود. مشکل اصلی در سازمانها عدم توجه به این مقوله با نگاهی کل‌نگر و تنها تمرکز جزئی و بر روی یکی از چندین مورد اشاره شده در این نوشته است. بطور حتم برنامه‌ریزی در تمامی مواردی که در این نوشته مورد اشاره قرار گرفت می‌تواند برای سازمان‌ها مفید باشد اما تجمیع آنها کنار هم میتواند تحولی شگرف را در سازمان ایجاد کند. به عنوان مثال حرکت به سمت سامانه‌هایی نظیر Jenkins یا Microsoft Azure DevOps بطور حتم میتواند برای سازمان مفید باشد، اما تا زمانیکه الگوی مورد استفاده در تیم توسعه محصول، چابک نباشد و یا معماری محصول، یک معماری مناسب نباشد، راه‌اندازی چنین سامانه‌هایی فاقد ارزش افزوده چندانی است.در پایان، با ارائه پاسخ به مجموعه‌ای از سئوالات رایج در حوزه DevOps، به جمعبندی این نوشته خواهیم پرداخت:بطور کلی آیا DevOps در برگیرنده مفهوم جدیدی است؟در حقیقت DevOps حرف چندان تازه‌ای برای گفتن ندارد و هرچه هست در چارچوبهای حوزه چابک (Agile)، مدیریت خدمات (ITSM) و مدیریت ناب (Lean) مطرح شده است. اما ایده‌پردازان جنبش DevOps اینبار با ترکیب این مفاهیم و در کنار هم قرار دادن آنها تلاش کرده‌اند تا با نگاهی کل‌نگر، اثربخشی و کارآیی این مفاهیم را افزایش دهند.آیا DevOps مرجع مشخصی جهت استناد و پیاده‌سازی بر اساس آن دارد؟خیر؛ از آنجاییکه DevOps یک چارچوب یا یک استاندارد نیست که توسط یک سازمان و یا تیم مشخصی تهیه شده باشد، پس در نتیجه کتاب یا مستند مشخصی هم به عنوان مرجع برای آن وجود ندارد. DevOps یک ایده و یک رویکرد جدید در فضای فناوری اطلاعات است و کتب متنوعی نیز در این حوزه توسط نویسندگان و کارشناسان شناخته شده تدوین شده است و این کتب می‌توانند به عنوان راهنما در این حوزه مورد استفاده قرار بگیرند.اگر DevOps به عناوین شغلی مرتبط نیست پس شرح شغل تیم‌ها و یا افرادی با عناوین شغلی مانند DevOps Team, DevOps Engineer و … چیست؟این افراد عموما بر روی ابزارهایی که می‌توانند برای تسریع فعالیت‌ها در سازمان مفید باشند کار می‌کنند. به عنوان مثال ابزارهایی مانند Jenkins و Azure DevOps یا ابزارهای تست خودکار و کانتینرهایی مانند داکر و …؛ پس در واقعیت شغل جدیدی در رابطه با DevOps بوجود نیامده و ضرورتی هم به استفاده از عنوان شغلی خاص برای آن‌ها نیست، اما بسیاری از سازمان‌ها ترجیح داده‌اند تا برای مشخص شدن دسته فعالیت‌های این افراد از پیشوند یا پسوند DevOps در عناوین شغلی آنها استفاده کنند.آیا اگر به عنوان مثال ابزار Jenkins را در سازمان راه‌اندازی کرده باشیم، یعنی داریم بر اساس DevOps کار میکنیم؟خیر؛ اگرچه راه‌اندازی ابزاری مانند Jenkins یا Azure DevOps اقدام مفیدی محسوب می‌شود اما، این حرکت به تنهایی به معنای استقرار DevOps در سازمان نیست. همانطور که به عنوان مثال استقرار یک سامانه تیکتینگ مانند Manage Engine Service Desk Plus به معنی استقرار ITIL در سازمان نیست این قاعده در رابطه با سایر حوزه‌ها نیز مصداق دارد. بابک ایزدی بابک ایزدی Sun, 08 Aug 2021 11:30:56 +0430 https://virgool.io/@babak_izadi/%DA%86%D8%A7%D8%B1%DA%86%D9%88%D8%A8-itil-4-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%D8%A8%D8%A7-%D9%88%DB%8C%D8%B1%D8%A7%DB%8C%D8%B4%D9%87%D8%A7%DB%8C-%D9%82%D8%A8%D9%84%DB%8C-itil-%DA%86%D9%87-%D8%AA%D9%81%D8%A7%D9%88%D8%AA%D9%87%D8%A7%DB%8C%DB%8C-%D8%AF%D8%A7%D8%B1%D8%AF-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-zvcuhgtid9io در این نوشته تلاش میکنیم تا بر روی ITIL 4 تمرکز داشته باشیم، پس اگر بصورت کلی با چارچوب ITIL آشنایی ندارید، پیشنهاد میکنیم که ابتدا برروی لینک زیر کلیک کرده و این مطلب را که بطور کلی به معرفی ITIL پرداخته است مطلعه کنید.هر آنچه که لازم است از چارچوب ITIL بدانید! ITIL چیست؟ از کجا آمده؟ به چه دردی میخورد؟عنوان ITIL 4 مربوط است به تازه‌ترین ویرایش از چارچوب ITIL که به تازگی و در فوریه 2019 بصورت عمومی منتشر شده است. این ارائه، نتیجه پروژه‌ای حدودا دو ساله است که توسط موسسه AXELOS تعریف و با مشارکت جمع زیادی از مشاورین و خبرگان حوزه مدیریت خدمات فناوری اطلاعات از سراسر جهان به پیش رفته است. در تدوین این ویرایش تلاش شده تا با بهره‌گیری از تجربیات بروز خبرگان، شرکت و سازمانها و همچنین استناد به آموخته‌هایی که در دیگر متدها و چارچوبها نظیر SCRUM، DevOps، COBIT، Cloud Computing و ... در دسترس است، به یک الگوی جامع و کامل برای مدیریت تمامی آنچه که در فضای امروزی فناوری اطلاعات شرکت و سازمانها روی میدهد رسید.نامگذاری ITIL 4یکی از ویژگیهای این ویرایش نامگذاری آن است. نسخه قبلی ITIL در سال 2011 و تحت عنوان ITIL 2011 ارائه شد اما نکته حائز اهمیت در رابطه با آن نسخه این بود که در اصل نسخه 2011 یک بروزرسانی جزئی برروی نسخه قبل از آن یعنی ITIL v3 بود و به همین علت بسیاری از افراد آخرین نسخه از این چارچوب را همچنان تحت عنوان ITIL v3 میشناختند.عناوین انقلابهای صنعتیبصورت کلی شاید توقع میرفت که نسخه جدید ITIL نیز همانند روالی که در نامگذاری نسخ بسیاری دیگر از چارچوبها رایج شده است به نام سال انتشار آن یعنی 2019 نامگذاری و عنوانی مانند ITIL 2019 به خود بگیرد. و یا به عنوان دنباله عددی خود نامی تحت عنوان ITIL v4 برایش انتخاب شود. اما نکته اصلی این است نام در نظر گرفته شده فاقد کاراکتر V (به عنوان مخفف Version) است و تنها ITIL 4 عنوان صحیح آن است.این نامگذاری به منظور تاکید بر همسویی ویرایش جدید ITIL با انقلاب صنعتی چهارم است.عصر حاضر و عناوینی نظیر IoT، شبکه های 5G، خودروهای خودران و ... مشخصه‌های انقلاب چهارم صنعتی و عصر مدرن حاضر هستند. مولفین این ویرایش از ITIL برروی این موضوع تاکید دارند که این چارچوب، ابزاری جامع برای مدیریت فضای فناوری اطلاعات در سالهای پیش رو خواهد بود (در صورت تمایل میتوانید توضیحات کاملی در رابطه با انقلاب صنعتی چهارم را در صفحه ویکیپدیا مطالعه کنید؛ انگلیسی / فارسی).ساختار ارائه مفاهیم در ITIL 4در ITIL4 دیگر اثری از چرخه عمر خدمت یا همان ITIL Service Life Cycle نیست و شما با عناوینی نظیر Service Value System و یا Service Value Chain مواجه خواهید شد. در ویرایشهای قبلی ITIL شما بطور کلی با دو مفهوم Process و Function در تعامل بودید که در نگاه سطحی به ITIL4 اثری از آنها هم دیده نمیشود. فرآیندها در برگیرنده نحوه انجام کارها و نکاتی که میبایست رعایت میکردید بود و Function ها هم ساختارهای پیشنهادی برای پیش بینی در چیدمان تیمها و اجزا سازمان به عنوان مجریان همان فرآیندهای معرفی شده در چارچوب ITIL؛ITIL4 Service Value Systemتصویر بالا معرفی کننده ساختار کلان ITIL4 است که با نام Service Value System و یا به اختصار SVS طراحی و ارائه شده است. این ساختار بر این موضوع تاکید دارد که ITIL4 را میتوان به عنوان یک سیستم تصور کرد که قرار است در پاسخ به فرصتها و یا تقاضاهای موجود (ورودی سمت چپ) ارزشی را (خروجی سمت راست) خلق کند.اجزا تشکیل دهنده این سیستم عبارتند از:Guiding PrinciplesGovernanceService Value ChainPracticesContinual Improvementدر ادامه به معرفی اجمالی هریک از این اجزا خواهیم پرداخت.اصول راهنما یا Guiding Principles کدامندموسسه AXELOS برای اولین بار در سال 2016 از واژه Guiding Principles در دوره جدید ITIL Practitioner استفاده کرد. در محتوای آموزشی و کتاب مرتبط با این دوره 9 اصل به عنوان اصول کلیدی که میبایست در فضای ITIL مورد توجه قرار گیرند اشاره شده بود. اینبار موسسه AXELOS ضمن بازنگری در این اصول مجموعه 7 اصل کلیدی را به عنوان یکی اجزا اصلی تشکیل دهنده فضای مدیریت خدمات فناوری اطلاعات معرفی کرده است.Focus on valueStart where you areProgress iteratively with feedbackCollaborate and promote visibilityThink and work holisticallyKeep it simple and practicalOptimize and automateدر بخش بعدی از این نوشته به بررسی اجزا دیگر معرفی شده در Service Value System خواهیم پرداخت. همچنین در صورت تمایل به مطالعه مقالات مشابه میتوانید به وب سایت شرکت رایزن سامانه گستر سر بزنید. بابک ایزدی بابک ایزدی Mon, 22 Apr 2019 12:30:39 +0430