مانیتورینگ برنامه‌های کاربردی و بلوغ سازمانی
مقدمه
سیستم‌های نرم‌افزاری، برنامه‌ها و استراتژی‌هایی که امروزه کسب‌وکار شما به آنها وابسته هستند، بسیار پیچیده شده‌اند. برای بسیاری از سازمان‌ها، طیف گسترده‌ای از برنامه‌ها و ابزارها برای توسعه این نرم‌افزار منجر به معماری‌های کاربردی می‌شود که می‌تواند توانایی‌های بسیاری از سازمان‌ها برای مدیریت آنها را تحت تأثیر قرار دهد.
چندی پیش، نحوه پیاده سازی نرم افزار، خود در اعماق سازمان شما پنهان بود. به طور معمول، تعاملات شما شامل تبادل داده هایی بود که نشان دهنده موجودی، سفارشات، بدهی‌ها و اعتباراتی بود که در شبکه های خصوصی منتقل می شدند. این فعل و انفعالات شامل تعداد محدودی از شرکت‌های دیگر می‌شد که به اصطلاح شرکای تجاری نامیده می‌شدند، که خود نیز دارای قابلیت‌ها و دارایی‌های نرم‌افزاری پنهانی بودند. تعداد شرکای تجاری و همچنین تنوع تعاملات محدود اما به راحتی مدیریت می شد. این نوع تراکنش ها روزانه انجام می شد و حل و فصل آن اغلب روزها طول می کشید. با رشد محاسبات اینترنتی، این شبکه های خصوصی به معابر عمومی تبدیل شدند و دسترسی به شرکای تجاری را افزایش دادند و همچنین فرصت های جدیدی برای تعامل مستقیم با مصرف کنندگان محصولات و خدمات شما ایجاد کردند.
از آنجایی که مصرف‌کنندگان تمام تعاملات خود را به وب منتقل کردند، توانایی مدیریت سیستم‌های نرم‌افزاری زیربنایی به سادگی هماهنگ نبود. هر جنبه ای از چرخه عمر نرم افزار - توسعه، تحویل، مدیریت و در نهایت نوآوری - غیرقابل پیش بینی و ناپایدار شده بود.
وضعیت فعلی نرم‌افزار کاربردی و شیوه‌های مدیریت فناوری اطلاعات شما هرچه که باشد، یک مشاهده ساده تکان‌دهنده وجود دارد: نمی‌توانید انتظار داشته باشید آنچه را که نمی‌توانید اندازه‌گیری کنید، مدیریت نمایید. اغلب، شکاف اساسی این است که شما در مورد ماهیت و علل مشکلات عملکرد خود، به غیر از این واقعیت که ممکن است شرکای تجاری و مصرف کنندگان شکایت داشته باشند، دید معناداری ندارید. مدیریت عملکرد برنامه (APM) شامل فرآیندها و فناوری هایی است که شما را قادر می سازد این اندازه گیری ها را دریافت کنید. مشاهده مسائل مربوط به کارایی در هر مرحله از چرخه عمر نرم‌افزار، نحوه بازیابی مدیریت پذیری و پیش بینی پذیری، به بهترین شکل است.
چالش این است که اگر فرآیند مدیریت چرخه عمر نرم‌افزار شما قبلاً شکسته شده باشد، ممکن است زمان بسیار دشواری را در پیش بگیرید که APM به طور قابل اعتماد کار کند. خوب است اگر بتوانید به سادگی یک ابزار APM تهیه کنید که همه چیز را بهتر می کند. این یک رویای پوچ است. هیچ راه حل سریعی برای مجموعه ای از مشکلاتی که در طول سال ها ایجاد شده اند وجود ندارد. این واقعاً فرآیندهای APM در نحوه استفاده از فناوری در رویه های روزانه خود است که بیشترین تأثیر را بر مدیریت کارایی شما خواهد داشت. و همین فرآیندها هستند که پایه جدیدی را ایجاد می کنند که بر اساس آن می توانید کل چرخه عمر نرم افزار را تحت کنترل درآورید.
چرخه‌های حیات
ما با سه نوع چرخه حیات سروکار خواهیم داشت: چرخه عمر نرم افزار، چرخه عمر برنامه کاربردی و چرخه عمر APM.
چرخه عمر توسعه نرم افزار
ریشه همه اینها چرخه عمر توسعه نرم افزار (SDLC) است که چرخه فعالیت های یک سیستم نرم افزاری شامل برنامه ریزی، تجزیه و تحلیل، طراحی، پیاده سازی و نگهداری را توصیف می کند. هیچ کس به طور واقع بینانه انتظار ندارد که یک سیستم را در اولین بار دقیقاً به درستی دریافت کند. بنابراین پس از ارائه اولین تکرار، فرآیند چرخه عمر، با استفاده از تجربه قبلی به عنوان ورودی به علاوه الزامات اضافی که در نتیجه تکرار قبلی کشف شده اند، از نو شروع می‌شود. این امر می‌تواند منجر به نمونه‌سازی سریع شود، که یکی از مدل‌های احتمالی یک SDLC است که بر تکرارهای کوتاه توسعه، آزمایش و اعتبارسنجی تمرکز دارد. هنگامی که یک سیستم خاص تحت تأثیر تکرارهای متعدد یک چرخه حیات قرار می گیرد، من این را تکامل می‌نامم. یک سیستم کاری از تکامل چرخه های نمونه سازی سریع چندگانه ناشی می شود.
چرخه عمر برنامه
چرخه عمر برنامه، تکامل یک سیستم نرم افزاری پس از استقرار اولیه آن و صرف نظر از استراتژی توسعه ای است که به کار گرفته شده است. من این تمایز را قائل می‌شوم زیرا بسیاری از چیزهایی که باید با آنها سر و کار داشته باشید، برنامه‌هایی هستند که قبلاً «پخته شده‌اند». آنها سالها مستقر شده اند. در حالی که ممکن است تحت تعمیر و نگهداری دوره ای یا ارتقاء قابلیت ها قرار گیرند. اکثر سیستم ها هیچ گونه طراحی مجدد قابل توجهی را تجربه نمی‌کنند. مراحل در چرخه عمر برنامه شامل توسعه، تست های کارکردی، تست های کارایی، تست های پذیرش کاربر (UAT)، تولید و تریاژ است. به نظر می رسد که این مراحل با چرخه زندگی SDLC همپوشانی دارند اما پس از انتشار اولیه حیاتی تر می شوند. تست کارایی و خود کارایی، اغلب در مرحله تضمین کیفیت (QA) با هم ترکیب می‌شوند. تاکید ویژه‌ای بر تریاژ به عنوان مرحله‌ای از چرخه عمر برنامه دارم، زیرا می‌خواهم برنامه‌های کاربردی با رفتار خوب را از برنامه‌های مشکل‌ساز متمایز کنم. فعالیت تریاژ، فرکانس و نحوه انجام تریاژ، مستقیم‌ترین راه برای به دست آوردن این دیدگاه است. برای یک برنامه بالغ، تریاژ همچنین گران‌ترین فعالیتی است که از نظر پرسنل باید با آن مبارزه کنید. ابتکار APM با ردیابی دفعات و مدت فعالیت های تریاژ تحقق می یابد.
تریاژ، در زمینه APM، فرآیند تعیین و پرداختن به سیستم‌های IT است که در یک رویداد کارایی (مثلا یک کُندی گزارش شده) مشارکت دارند. معمولاً در طی یک تماس کنفرانس، تریاژ شامل ده ها ذینفع است که برای تعیین اولویت تلاش‌های بازسازی برای سیستم های آسیب دیده کار می‌کنند. کاهش زمان و پرسنل صرف شده در تریاژ یک هدف مهم مدیریتی است. من به APM نگاه می‌کنم تا داده‌های خام یا معیارهایی را ارائه کنم که بر اساس آن تجزیه و تحلیل علت ریشه‌ای انجام شود. APM به شما می گوید که مشکل کجاست. علت ریشه ای به شما می گوید چرا. هدف از تریاژ این است که مطمئن شوید همه در حال رسیدگی به مشکلات کلیدی پیش آمده هستند و نه مسائل حاشیه‌ای.
چرخه حیات APM
نوع سوم چرخه زندگی، خود APM است. این دارای ویژگی های SDLC است که انتظار دارد یک تکامل تعاملی تا زمانی که قابلیت های کامل ابزار محقق شود، صورت گیرد. چرخه عمر APM، چرخه عمر برنامه را با تکنیک های مناسب برای هر مرحله دنبال می کند تا نیازهای خاص ذینفعان را در هر مرحله برآورده کند. هر تکرار APM شامل فعالیت های زیر است:
شناسایی شکاف‌ها
ایجاد (یا افزایش) تریاژ
اهرم (یا ایجاد) فعالیت‌های QA
تقویت مکانیسم استقرار
افزایش (یا ایجاد) همکاری
در تجربه من، سه تکرار باید انجام شود. بنابراین 15 فعالیت مجزا را به همراه دارد. این بحث برای مبحث بعدی، مدل‌های بلوغ، اهمیت دارد، زیرا برای تعیین پتانسیل APM سازمان فعلی شما، باید به سرعت هر شکافی را در شیوه‌های فعلی خود شناسایی کنید. این 15 فعالیت اجازه می‌دهد تا حجم معقولی از جزئیات بدون نیاز به مصاحبه های عمیق جمع آوری شوند.
بلوغ سازمانی
وسعت زیرساخت فناوری اطلاعات شما - مدیریت پروژه‌ها و فناوری در حالی که آنها را با اهداف استراتژیک در طول چرخه عمر همسو می کند - برای ایجاد امتیازی که نشان دهنده قابلیت ها و شکاف های فعلی است، بررسی می شود. ابتدا به قابلیت های سازمانی به طور کلی نگاه می کنید و سپس بر روی قابلیت های مدیریتی (نظارت) تمرکز خواهید کرد. بلوغ با افزایش قابلیت ها افزایش می یابد. بلوغ مدیریت، زمانی که برای اولین بار به رویدادهای تولید پاسخ می‌دهید (مدیریت واکنشی) بهبود می‌یابد و در نهایت از آن رویدادهای تولیدی با تشخیص پیش تولید (مدیریت فعال) اجتناب می‌کنید. تصویر زیر رابطه بین چرخه عمر برنامه و قابلیت های مدیریت سیستم موجود شما را نشان می دهد که مکانیسم های اصلی ردیابی بلوغ مدیریت هستند.
همانطور که دید نظارت افزایش می یابد، که در تصویر بالا به عنوان حرکت به سمت بالای محور قابلیت مدیریت نشان داده شده است، قابلیت مدیریت از واکنشی به هدایت‌شده و پیش‌گیرانه گسترش می‌یابد. من بین مذاکره واکنشی، زمانی که باید هشدار بخواهید، و هشدار واکنشی، زمانی که به طور خودکار هشدارها را دریافت می کنید، به عنوان اولین نمونه از نحوه تفکیک تمایز می‌دهم.
امروزه هر سازمان فناوری اطلاعات، ازطریق ابزارهای نظارت بر سیستم، هشدارهای دسترسی را به خوبی توسعه داده است، بنابراین ممکن است نتیجه بگیرید که نظارت آنها به مرحله بلوغ رسیده است. اما از آنجایی که بسیاری از سازمان‌ها هنوز به شدت به صورت داخلی تقسیم‌بندی شده‌اند، در چیزی که سیلویِ فناوری اطلاعات نامیده می‌شود، این هشدارها اغلب به اشتراک گذاشته نمی‌شوند. این واقعیت که ممکن است شخصی سیستم را زیر نظر داشته باشد، اگر شما از هشدار مطلع نشوید، واقعاً مفید نیست.
وقتی دیگر نیازی به درخواست آن هشدار یا مذاکره برای دسترسی به آن هشدار ندارید، توانایی مدیریت شما افزایش می یابد. در اوایل چرخه حیات، اغلب غیبت کامل از نظارت را خواهید دید. همانطوری‌که برنامه ها پیچیده تر می‌شوند، ادغام و آزمایش نیز پیچیده می‌شود. چگونه می‌دانید، قبل از آزمایش، همه سیستم های کمک کننده کار می کنند؟ این یک سوال نظارتی اساسی است و بدون پاسخ، شانس کمی برای انجام درست تست خود دارید.
برای پرداختن به این شکاف‌های بالقوه، دو سطح دیگر بلوغ مدیریت عبارتند از:
هدایت شده، زمانی که اطلاعات دسترس‌پذیری و کارایی در طی توسعه و آزمایش QA جمع‌آوری می‌شود تا مشکلات را در صورت بروز اصلاح کنند.
فعال، زمانی که اطلاعات دسترس‌پذیری و کارایی برای محدود کردن استقرار اپلیکیشن‌های مشکل‌دار در محیط عملیات یا ایجاد آمادگی برای حوادث قبل از وقوع آنها در محیط عملیات استفاده می‌شود.
هر دوی این سطوح بلوغ مدیریتی نیاز به استفاده «پیش از عملیات» از فناوری نظارت دارند.
همراه با ارزیابی اولیه بلوغ یک سازمان، دلیل دیگر برای ارزیابی‌ها، پشتیبانی از اندازه‌گیری مداوم پیشرفت ابتکار APM شما است. برای ثبت پیشرفت و اهداف به دست آمده، باید پس از هر بار تکرار ابتکار APM خود، آنرا اندازه گیری کنید. این اغلب برای ابتکارات کوچک نادیده گرفته می‌شود، اما همیشه با تلاش‌های بزرگتر وجود دارد. مفهوم اصلی این اندازه گیری بلوغ، مدل بلوغ قابلیت ها بصورت یکپارچه (CMMI) است. این مدل برای ارزیابی بلوغ مهندسی نرم‌افزار از نظر فرآیندهایی که باید بخشی از شیوه‌های کسب‌وکار شما باشد، ایجاد شده است. این مدل، پنج سطح بلوغ را تعریف می‌کند:
اولیه
مدیریت شده
تعریف شده
مدیریت کمی
بهینه شده
هرچند این، یک مدل بلوغ به خوبی پشتیبانی شده است، ولی انعطاف‌پذیری کافی برای تطبیق با سهامداران و فعالیت های متعددی که یک ابتکار APM شامل می‌شود را، ندارد
برای پرداختن به این موضوع، این مقاله تعدادی از ابعاد قابلیت را در مدل بلوغ ارائه می‌کند تا سطوح مختلف بلوغ سازمانی را که معمولاً امروزه با آن مواجه می‌شویم، فراهم نماید. این ابعاد اضافی شامل افزودن قابلیت‌های ارزیابی برای هشدارها، فناوری، گزارش‌دهی، آزمایش، پشتیبانی، استقرار (کنترل تغییر)، عملیات و مدیریت حوادث است. هر یک از این موارد، حداقل دارای سه سطح بلوغ/قابلیت افزایشی است که در صورت در نظر گرفتن هر یک از فرآیندها حداکثر تا 24 سطح خواهد بود. به عنوان مثال، بُعد هشدار مدل بلوغ سازمانی همانطوری‌که در تصویر زیر نشان داده شده است امتیازدهی شده است.
پنج صلاحیت APM
یک مهندس کارایی چه کارهایی باید بتواند انجام دهد؟ این سوال منجر به پنج شایستگی APM گردیده است که یک مهندس کارایی، برای دریافت «گواهی» آنها را لازم دارد.
این شایستگی‌های APM عبارتند از:
استقرار سریع
اندازه راهکار
ممیزی برنامه
تریاژ
ارزیابی‌ها
معماری مانیتورینگ
APM مجموعه ای از تکنیک های مانیتورینگ است. هنگام ارزیابی قابلیت های یک سازمان، این واقعیت که آنها هنوز از فناوری APM استفاده نمی‌کنند، به طور خودکار منجر به امتیاز ضعیف نمی‌شود. درعوض، اگر فرآیندهای مناسبی داشته باشند، از هر فناوری نظارتی می توان برای افزایش دید کلی استفاده کرد. این اغلب منجر به وضعیت بهتری می‌شود، حتی اگر آنها یک ابتکار کامل APM را انجام ندهند. ایجاد یک نامگذاری در مورد آن فناوری های قبلی مفید است تا بتوانید درک کنید که چگونه فناوری APM قابلیت های مانیتورینگ را افزایش می دهد.
شکل بالا دو معماری جمع‌آوری معیارها (متریک‌های) اساسی را نشان می دهد. معماری بالاتر، مانیتورینگ کلاسیک مبتنی بر SNMP را نشان می‌دهد. یک نقطه جمع آوری به نام مدیر شبکه، دستگاه‌های SNMP متصل را نظرسنجی می‌کند. هشدارها ثبت می شوند و معیارهای مختلف در یک پایگاه داده رابطه ای ذخیره می‌شوند. یک ایستگاه کاری، برای دریافت به‌روزرسانی‌های وضعیت هشدار یا پیمایش در میان دستگاه‌های متصل جهت جمع‌آوری معیارها و پرس‌و‌جوی وضعیت فعلی از دستگاه‌های متصل، به نقطه جمع‌آوری متصل می‌شود.
در حالی‌که معماری مدیر شبکه کاملاً قادر به فعالیت‌های SNMP است، اما به خوبی به حجم معیارهایی که احتمالاً در پشتیبانی از APM متحمل می شوید، مقیاس نمی‌شود.
من ترجیح می‌دهم به هر کمیت اندازه‌گیری شده به عنوان یک متریک اشاره کنم، مطابق با تعاریفی که می توانید در وب پیدا کنید. این امر نقطه جمع آوری را یک سروری از معیارها می‌سازد. صرف نظر از قابلیت، کارکرد اصلی، جمع آوری معیارها است. آنچه در مورد معیارها مهم است آنست که تعداد زیادی از آنها برای مدیریت وجود خواهد داشت. این به خودی خود مشکلی نیست، اما همانطوری‌که در تصویر زیر می‌بینید، با نزدیک شدن به بخش‌های داخلی برنامه یا سرویس، تعداد معیارها به طور قابل توجهی افزایش می یابد.
متریک‌ها می‌توانند هر نوع داده ای را نشان دهند. به طور کلی، سه نوع متریک اصلی وجود دارد: تعدادها، زمان‌های پاسخ و نرخ‌های فراخوانی. معیارها با نرخ‌های متفاوتی از زمان واقعی گرفته (هر فراخوانی)، تا فواصل زمانی 15 دقیقه ای اندازه‌گیری می‌شوند. فرکانس اندازه گیری واقعی به نوع نقطه اندازه گیری مورد استفاده بستگی دارد. برخی از نقاط اندازه گیری با ترکیبی از فرکانس های اندازه گیری عمل می‌کنند. به عنوان مثال، یک logfile می‌تواند هر تراکنش پردازش شده را در زمان واقعی ضبط کند، اما عامل ورود به سیستم (logging agent) ممکن است فقط هر 10 دقیقه یک بار ورودی‌های گزارش جدید را پردازش کند. در سیستم دیگری، گزارش ممکن است تا بعد از ساعات کاری پردازش نشود. هر دو عامل گزارش می‌توانند معیارهایی را به APM کمک کنند، اما فرکانس‌های اندازه‌گیری بسیار متفاوتی خواهند داشت.
تعداد معیارهایی که می توانید انتظار داشته باشید، با عبور از پشته نظارت که در تصویر زیر نشان داده شده است، متفاوت است. دید در پشته نظارت، که معیار دیگری از قابلیت مدیریت است، با تعداد معیارهایی که ممکن است در دسترس باشد، نسبت مستقیم دارد.
برای مدیریت این سطح جدید از معیارها و ارائه قابلیت‌های بیشتر با عوامل و دستگاه‌های کنسول، معماری‌های مانیتورینگ همانند برنامه‌هایی که وظیفه نظارت بر آن را داشتند، تکامل یافتند: از معماری‌های 2 لایه به 3 لایه تا n لایه.
معماری مانیتورینگ کارایی برنامه APM
علاوه بر مانیتورینگ دسترس‌پذیری از طریق SNMP که امروزه در فناوری اطلاعات در همه جا وجود دارد، تعدادی فناوری دیگر نیز وجود دارد که ممکن است در یک راه حل APM وجود داشته باشد.
اینها در امتداد پنج نقطه اندازه گیری اصلی، که در شکل زیر نشان داده شده است، تجزیه شده و به شرح زیر خلاصه می‌شوند:
- فایل های لاگ
- برنامه های کاربردی یا اختصاصی
- تراکنش های مصنوعی که ربات نیز نامیده می‌شود
- تراکنش‌های واقعی که اغلب پروب نامیده می‌شود
- ابزاربندی
فیلتر کردن تراکنش یا تطبیق الگو
ضبط و تجزیه و تحلیل پروتکل
JMX/PMI یا سایر چارچوب‌های اندازه گیری
ابزاربندی بایت کد
همچنین می‌توانید فناوری‌ها را به صورت مبتنی بر عامل (که با علامت A مشخص می‌شود) یا بدون عامل تقسیم کنید. من نیازی به این تمایزها نمی بینم زیرا همه معیارها ممکن است در نقطه ای به سرور متریک ختم شوند. من مانیتورینگ دسترس‌پذیری را به عنوان یک نقطه اندازه گیری نشان نداده ام زیرا تقریباً به طور قطع وجود دارد، و به هر حال همه نقاط اندازه گیری دیگر وضعیت دسترس‌پذیری را به طور اضافی ارائه می‌دهند.
تعدادی زمینه نظارتی وجود دارد که هر کدام کاربرد خاص خود را دارند. در هر زمینه، شما بررسی می‌کنید که چه فناوری‌هایی را می‌توانید به کار ببرید تا در آن زمینه دید داشته باشید. این منجر به نمودار تصویر زیر می‌شود که تمام گزینه های فناوری موجود برای پشتیبانی از APM را فهرست کرده است. نقشه برداری از فناوری های مورد استفاده فعلی، مانند شکل زیر نشان می دهد که چه شکاف های دیدی ممکن است وجود داشته باشد و فناوری APM در کجا به ما کمک می‌کند. در نهایت، بلوغ سازمانی، توانایی ترکیب جریان های داده جدید را در فرآیندهای موجود محدود می کند. اگر زیرساخت فرآیند در ابتدا ایجاد نشده و قابل دوام نباشد، تلاش برای پیاده‌سازی فناوری‌های نظارتی توانمندتر، فایده چندانی ندارد.
منظور این است که تمام فناوری های APM مفید هستند. اگر شیوه های محکمی برای مدیریت و استفاده از فایل های لاگ دارید، احتمالاً تجربه خوبی با روش مصنوعی خواهید داشت. اگر روشهای مصنوعی شما استوار باشد، از کار با تراکنش‌های واقعی رضایت خواهید داشت.
اما اگر با روشهای مصنوعی مشکل دارید، باید حرکت به سمت ابزاربندی را به تأخیر بیندازید تا اینکه شکاف‌های فرآیندی را که مانع پیشرفت شما می‌شوند رفع کنید. بلوغ سازمانی افزایشی نیست. در عوض، ضعیف ترین حلقه چیزی است که ابتکار APM را متوقف می‌سازد.
ویژگی‌های برنامه
بسته به معماری نرم‌افزار برنامه، می‌توانید با تعیین انواع اجزای موجود و نمایه‌های تراکنش، ارزیابی سریعی از فناوری‌های APM انجام دهید.اجزای نرم افزار، عناصر قابل استفاده مجدد یک برنامه کاربردی هستند. درشت‌ترین جزء، فرآیندی است که قابلیت استفاده مجددِ محدود شده به چندین فراخوانی، هر یک به عنوان یک فرآیند جداگانه را، دارد. سطح بعدی استفاده مجدد از طریق زبان‌های مبتنی بر مؤلفه مانند جاوا، دات نت، CORBA، SOAP و COM است. اینها امکان فراخوانی های متعدد از یک شی را در یک فرآیند واحد فراهم می‌سازند. هر شی با یک رشته (thread) مرتبط است تا اجرای آن را مدیریت کند.
پروفایل‌های تراکنش ویژگی‌های فردی یا مجموعه ای از برنامه ها هستند. یک تراکنش تجاری، مانند تراکنش new_customer، می‌تواند از یک یا چند برنامه در طول تکمیل شدن بازدید کند، که منجر به تراکنش برنامه (تراکنش با یک سرور برنامه) می‌شود. هر تراکنش برنامه می‌تواند از یک یا چند تراکنش منبع مانند تعامل با پایگاه داده استفاده نماید. در مثال تراکنش new_customer، تراکنش تجاری از چهار سرور برنامه بازدید می کند که هر کدام یک پایگاه داده را به‌روز‌رسانی می‌کنند. تراکنش تجاری، برای مانیتورینگِ تراکنش های مصنوعی و واقعی قابل مشاهده است. برنامه کاربردی و تراکنش منبع، برای فناوری ابزاربندی قابل مشاهده است.
تراکنش تجاری new_customer ساده‌ای که شامل چهار تراکنش منبع است، برای درک روابط نیازی به تجسم اضافی ندارد. اما یک نمایه تراکنش در دنیای واقعی بسیار پیچیده تر خواهد بود. خوشبختانه یک مدل تجسم به نام ردیابی تراکنش وجود دارد که در شکل زیر نشان داده شده است.
این نمودارِ اجزای مختلفی است که منجر به اجرای تراکنش می‌شود، و به ترتیب فراخوانی آنها ارائه شده است، که به آن پشته فراخوانی می‌گویند. اینکه چگونه پشته فراخوانی از نظر عمق در طول کل مدت تراکنش تغییر می‌کند، ردیابی تراکنش نامیده می شود.
ویژگی‌های گزارش‌دهی
جنبه نهایی معماری مرجع شما اغلب اولین شکاف عمده ای است که سازمان شما باید به آن رسیدگی کند: گزارش. استفاده مؤثر و مداوم از اطلاعات APM جایی است که بیشترین مقاومت سازمانی را تجربه خواهید کرد. برخی از شرکت‌های قبل از APM امروز با حداقل دید در زمان واقعی کار می‌کنند و گزارش‌های کارایی را در روز بعد دریافت می‌کنند. هیچ اشکالی در این ترتیب وجود ندارد - تا زمانی که داده‌های ساعتی و در نهایت داده‌های بلادرنگ در دسترس قرار گیرد. مردم نمی‌دانند چگونه از این سطح جدید از فراوانی اطلاعات برای تغییر روال خود استفاده نمایند.
بنابراین، گزارش، تکامل خاص خود را در میان چهار عنصر زیر دارد:
داشبوردهای زمان واقعی
گزارشات کلی
گزارش‌های پایه
گزارش‌های وضعیت سلامت (HealthCheck)
گزارش جدید، داشبورد خواهد بود. این استعاره، که اغلب برای خلاصه کردن چندین منبع داده در یک صفحه گسترده استفاده می‌شود، می‌تواند از طریق انواع ساختارهای گرافیکی مانند سنجه‌ها، نمودارها و لامپ‌های نشانگر بیان گردد. هنگامی که شاخص های کلیدی کارایی را در بالای نمودار معماری راه حل قرار می دهید، درک روابط معیارهای کارایی با توجه به معماری فیزیکی یا منطقی بسیار آسان می شود.
گزارش‌های عمومی صرفا بیانگر گزارش‌هایی است که امروز انجام می‌دهید و سپس با معیارهای کارایی به عنوان منبع ارائه می‌شود.
گزارش‌های پایه به طور خاص فقط بر اجزای حیاتی یک برنامه، زمانی که در حال آزمایش یا تولید هستند، متمرکز می‌شود. خط مبنا یک تعریف دلخواه از «وضعیت عادی» است که می‌توانید در طول تریاژ برای تأیید وضعیت غیرعادی از آن استفاده نمایید.
گزارش‌های HealthCheck معیارهایی را از خطوط پایه، معیارهای پلتفرم (CPU، حافظه) و سایر معیارهایی که برای ردیابی ظرفیت و کارایی ایجاد شده‌اند، ترکیب می‌کند. آنها ممکن است بر یک دوره بحرانی در طول خلاصه های روزانه، هفتگی یا ماهانه عملیات شما متمرکز شوند. آنها در نظر گرفته شده اند تا یک انجمنی را برای تشخیص تغییرات ظریف در برنامه قبل از کاهش شدید کارایی فراهم سازند. آنها برای افرادی که مسئول برنامه ریزی ظرفیت هستند، آشنا خواهند بود، هرچند آنها واقعاً قصد دارند همکاری در مورد مدیریت ظرفیت را تقویت کنند. تفاوت بین عملکرد برنامه ریزی و مدیریت ظریف به نظر می رسد. من آنها را با انعکاس اینکه برنامه‌ریزی برای بلندمدت بوده و مدیریت برای تصمیم گیری روزانه است، نگه می‌دارم. گزارش اولیه، چه خطوط پایه و چه بررسی‌های سلامت، برای مدیریت ظرفیت، ضروری است.
شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه ارزیابی و پایش کارایی نرم افزار ارائه می دهد:
آموزش روشهای ارزیابی کارایی سامانه های نرم افزاری از طریق آزمون‌های بار و فشار
اجرای آزمون‌های بار و فشار برروی سامانه های نرم افزاری
تهیه و آموزش ابزارهای تست پرفورمنس (تست بار و فشار) همچون WPLT و LoadTest
پایش و مانیتورینگ شاخص های کارایی سامانه های نرم افزاری از طریق ابزارهای مدیریت کارایی همچون AppDynamicsو DynaTrace
نویسنده : شرکت مهندس پیشگان آزمون افزار یاس
مراجع