۳ دلیل که توسعه دهندگان باید ابزارهای چابک و ITSM را ادغام کنند

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

بسیاری از سازمان ها از اصول devops پیروی می کنند و می خواهند به فرهنگ های devops تبدیل شوند. برخی از اقدامات کلیدی عبارتند از کنترل نسخه، یکپارچه سازی و تحویل مداوم (< a>CI/CD)، زیرساخت به عنوان کد (IaC)، استفاده از یادگیری ماشین در عملیات (AIops)، و آزمایش مداوم. تیم های پیشرفته تر همچنین بر برنامه ریزی مستمر، معماری برنامه های کاربردی ابری، توسعه microservices< /a>، کنترل کد با پرچم‌های ویژگی، ترویج روش‌های امنیتی shift-left، ایجاد اهداف در سطح سرویس، مدیریت بودجه‌های خطا و تبدیل شدن اطلاعات بیشتر.

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

بسیاری از سازمان‌ها devops را به devsecops و امنیت را به عنوان یک شریک برابر شامل شود. با devsecops، سه روش اصلی فناوری اطلاعات باید سرعت، چابکی و نوآوری مورد نیاز کسب و کارها را برای رقابت با قابلیت اطمینان، امنیت و عملکرد مورد نیاز برای عملیات تجاری، متعادل کنند.

همکاری Devops نیاز به ادغام ابزار چابک و ITSM دارد

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

برای بسیاری از سازمان‌ها، این گردش‌های کاری روش‌های چابک مورد استفاده توسط تیم‌های توسعه، از جمله اسکرام و کانبان را با مدیریت خدمات فناوری اطلاعات (ITSM) شیوه های مدیریت شده توسط ops، از جمله مدیریت درخواست، مدیریت حادثه، مدیریت مشکل، مدیریت تغییر، و نگهداری پایگاه داده مدیریت پیکربندی (CMDB).

با این حال، بسیاری از سازمان‌های فناوری اطلاعات در ابزارهای چابک و ITSM خود را ادغام می کنند.

تیم‌های توسعه ممکن است از Azure DevOps، Digital.ai، Jira Software یا ابزار چابک دیگری برای مدیریت انبوه داستان‌های کاربر، اسپرینت‌ها و نسخه‌ها در فرآیند توسعه استفاده کنند. به‌طور مستقل، عملیات ممکن است از BMC، Cherwell، Ivanti، Jira Service Management، Micro Focus، ServiceNow یا ابزار ITSM دیگری برای مدیریت بلیط‌ها، ردیابی سیستم‌ها و نظارت بر مدیریت تغییرات استفاده کند.

اتوماسیون و یکپارچه‌سازی می‌تواند به اتصال گردش‌های کاری پشتیبانی‌شده توسط این ابزارهای چابک و ITSM کمک کند، اما متأسفانه، اغلب، ترکیبی از ایمیل‌ها، جلسات، Slacks، Zooms و سایر فرآیندهای دستی برای اتصال این توابع به پایان است. گردش کار تا پایان.

این مطمئناً بهترین روش برنامه‌نویس نیست.

اگر نمی‌دانید چرا اتصال این ابزارها و گردش‌های کاری مهم است، سه نقطه ادغام مشترک زیر را که در devsecops برای پشتیبانی از تحویل سریع، امنیت و عملیات پایدار مورد نیاز است، در نظر بگیرید.

تسریع استقرار تغییرات کم خطر

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

این رویکرد ممکن است برای سازماندهی پیچیده‌ترین استقرارهایی که تیم‌ها، وابستگی‌های سیستم، یا ریسک‌های عملیاتی تجاری زیادی را دربرمی‌گیرند، ضروری باشد. بسیاری از شیوه های توسعه در حال حاضر با هدف به حداقل رساندن این مشکلات هستند. به عنوان مثال، میکروسرویس‌هایی که با تست‌های مستمر قوی و CI/CD پیچیده شده‌اند، تیم‌های توسعه‌دهنده را قادر می‌سازند تا تغییرات کوچک و کم‌خطر را اعمال کنند. سایر تغییرات کم‌خطر ممکن است شامل اجزای UX باشد که در معماری‌های بدون سرور، جاسازی‌شده استفاده شده است. تجزیه و تحلیل تغییرات داشبورد، بهبودهای برنامه کد، یا dataops تغییر می کند.

اگر این تغییرات واقعاً کوچک و کم خطر هستند، آیا فناوری اطلاعات می‌تواند با اتصال CI/CD ایجاد شده از ابزارهای چابک با جریان‌های کاری مدیریت تغییر که در ابزارهای ITSM مدیریت می‌شوند، تأییدیه‌های تغییر را خودکار کند؟

البته، کسب‌وکار، توسعه‌دهنده، امنیت و عملیات باید در مورد آنچه که «کم خطر» و «کوچک» است به توافق برسند. به‌علاوه، خطوط لوله CI/CD باید از بازگشت‌ها پشتیبانی کند، و در حالت ایده‌آل، اگر تغییرات منجر به مشکلات پیش‌بینی نشده شود، مدیران حادثه باید بتوانند آن‌ها را فعال کنند.

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

نقایص تولید را اولویت بندی و برطرف کنید

آیا روش‌های اتوماسیون آزمایشی و آزمایش مداوم شما به اندازه‌ای قوی هستند که تضمین کنند می‌توانید نسخه‌های تولید بدون نقص را به طور مداوم اجرا کنید؟

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

پیاده‌سازی نقشه‌برداری بی‌اهمیت نیست، زیرا تیم‌ها باید وضعیت گردش کار را بین نقص‌های ابزار چابک و بلیط‌ها در ITSM ترسیم کنند. همچنین، برخی از بلیط ها ممکن است منجر به نقص های متعدد شوند، یا ممکن است چندین بلیط به یک نقص مرتبط باشند. همچنین به احتمال زیاد استثناهای دیگری نیز در این گردش کار وجود دارد – برای مثال، زمانی که میز خدمات یک بلیط درخواست را به نقص نشان می دهد، اما تیم توسعه می گوید که کاربر در واقع یک ویژگی جدید را درخواست می کند.

با این وجود، باقی گذاشتن خندقی که درخواست‌های کاربر و حوادث گزارش‌شده از طریق میز خدمات را از گروه توسعه چابک جدا می‌کند، بسیار مشکل‌ساز است. ممکن است به این معنی باشد که مسائل عملیاتی و نیازهای کاربر توسط تیم‌های توسعه چابک بررسی و اولویت‌بندی نمی‌شوند.

این مطمئناً بهترین روش چابک برای تیم‌هایی نیست که باید نسبت به مشتریان و مسائل عملیاتی حساس باشند. بهترین روش این است که این دو گردش کار را به هم متصل کنید و خط‌مشی‌هایی برای اولویت‌بندی نقص ایجاد کنید.

استقرارها را با پلتفرم‌های نظارت و AIops وصل کنید

هنگامی که حوادث تولید اتفاق می‌افتد، یکی از شاخص‌های عملکرد کلیدی برای میز خدمات این است که آنها را تا حد امکان سریع و کارآمد حل کند. بسیاری از تیم های ITSM میانگین زمان حل (MTTR) تولید خود را ردیابی می کنند. حوادث و افزایش تعداد مانیتورها و هشدارها برای شناسایی سریعتر مسائل.

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

آیا مرکز عملیات شبکه یا مرکز عملیات امنیتی اطلاعات کاملی از همه داده‌های قابل مشاهده، استقرار، تغییرات پرچم ویژگی یا سایر تغییرات پیکربندی دارد؟ اگر در مرکز عملیات شبکه باشم و پایگاه داده هشداری را منتشر کند، نمی‌خواهم در چابک، ITSM، کنترل نسخه، پرچم‌گذاری ویژگی یا ابزارهای دیگر، دنبال چه کسی، چه زمانی و در کجا انجام دهد.

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

این ادغام‌ها ممکن است جام مقدس برای پشتیبانی از روش‌های توسعه سرتاسری باشند، اما به اتصال داده‌ها در چندین سیستم نیاز دارند:

• توسعه چابک، کنترل نسخه، پرچم‌گذاری ویژگی، اتوماسیون تست، و ابزارهای CI/CD که توسط تیم‌های توسعه‌دهنده استفاده می‌شوند
• ابزارهای ITSM برای ثبت حوادث، درخواست‌ها و تغییرات مدیریت شده توسط میز خدمات
• ابزارهای CMDB و نقشه‌برداری وابستگی و کشف که وضعیت‌های دقیق زیرساخت را ثبت می‌کنند
• ابزارهای نظارت و AIOps که توسط مراکز عملیات شبکه و مراکز عملیات امنیتی استفاده می‌شوند
• نقشه‌برداری جریان ارزش و سایر ابزارهای مدیریت محصول برای ارائه شفافیت و کنترل‌ها به رهبران کسب‌وکار

ابزارهای مدیریت AIops، قابلیت مشاهده و اهداف سطح سرویس عبارتند از BigPanda، Broadcom، DataDog، Devo، Digitate، Dynatrace، Elastic، Micro Focus، Moogsoft، New Relic، Nobl9، OpsRamp، Resolve، ScienceLogic، Splunk و موارد دیگر. . آنها بر روی یکپارچه سازی، تجزیه و تحلیل، گردش کار، اتوماسیون و سایر قابلیت هایی که از ردیابی و حل مشکلات عملیاتی پشتیبانی می کنند، رقابت می کنند.

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