دریافت مقالات

زیرساخت

بررسی Application Management از دیدگاه Splunk – قسمت اول

96 مشاهده ۳۱ شهریور, ۱۳۹۵ 3

مدیریت برنامه‌های کاربردی جهت پیشی گرفتن در اجرای مطمئن و مطلوب

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

امروزه Application Management نیز با چالش‌هایی از این دست مواجه می‌باشد. بنابراین لازم است از الزامات و شرایط پیچیده و همواره درحال تغییرِ Application ها، پشتیبانی نموده و در عین حال اطمینان یابد که خللی در اجرای برنامه پیش نمی‌آید. گزارشات IDC نشان می‌دهد که میانگین هزینه‌ی خرابی اپلیکیشن‌های مهم و حیاتی به میزان 500.000 تا 1 میلیون دلار در هر ساعت است و حتی در شرایط بدتر، قابلیت اطمینان و حتی توانایی کسب‌و‌کار با قطعی‌های مکرر در معرض خطر قرار می‌گیرد.

شرکت امن پایه ریزان کارن APK نخستین شرکت دانش محور در اجرای پروژه های انفورماتیکی کشور تماس با کارشناسان

همانطور که هیچ فردی تمایل به سفر با یک خودروی قدیمی و لاستیک‌های فرسوده را ندارد، به‌روزرسانی رویکردها برای افزایش سرعت Application Management حائز اهمیت بسیاری می‌باشد. مسیر پیش رو در این مورد روشن است: باید یک پلتفرم برای فرا رفتن از Siloها مورد استفاده قرار گیرد و جهت عملکرد سریع و استفاده از استراتژی داده‌محور نیز معماری‌های مدرن برای برنامه در نظر گرفته شود تا تمامی ذینفعان توانمند گردند.

چالش‌ها و فرصت‌های پیش روی APM

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

پیچیدگی روزافزون Application‌ها

در حال حاضر IT بیش از همیشه پیچیده و مجزا شده؛ و علاوه بر آن تجربه کاربران از طریق عواملی همچون زیرساخت Cloud، نرم‌افزار، APIها، میکروسرویس‌ها و عملکرد شبکه تعریف می‌گردد، که تمامی این موارد خارج از اپلیکیشن اصلی قرار دارد.

با استفاده از Mobile Appها، پیچ تندی به مسیر پیش رو اضافه شده است و بر روی آنها فرآیند اجرای کد، بسیار زیاد انجام می گردد، و این امر باعث می‌گردد کاربران برنامه‌های Mobile به یک منبع بالقوه برای خرابی (Failure) تبدیل شوند. مبنای کد برنامه‌های Native نیز به واسطه انتخاب نوع توزیع مورد استفاده کاربران، متفاوت و متغیر است، بدین معنا که باید یک ماتریس بزرگ و پیچیده از نسخه‌های Mobile App، مدیریت و پشتیبانی گردد.

در هنگام بررسی این موضوع، ابزارهای APM می‌توانند با قابلیت دسترس‌پذیری و عملکرد، مشکلات را شناسایی نمایند، اما این تنها بخشی از ماجرا می باشد. جز در مواردی که مشکل مربوط به کد اپلیکیشن است، شما نمی‌دانید مشکل از کجا بوجود آمده است. به همین دلیل است که Logهای پیکربندی، ابزارهای خودکارسازی و تغییر وضعیت پیکربندی اغلب دال بر شواهدی مربوط به مکان بروز مشکل محسوب می‌گردند.

به عنوان مثال، یکی از ارائه‌دهندگان برتر راهکارهای نرم‌افزاری برای عملکردهای مستقل در پزشکی، ارائه سرویس‌ به حدود 15.000 کاربر وارد شده به سیستم را از نزدیک مانیتور می‌نماید. کارکنان بخش IT سازمان باید اطمینان یابند که اپلیکیشن‌ها همواره در دسترس بوده و زیرساخت‌های پشتیبانی بیش از میزان تقاضا نبوده و قادر به پاسخگویی به نیازها می‌باشد. برای کسب اطمینان از رضایتمندی همیشگی کاربران باید قابلیت جستجوی سریع داده‌ها از بالا به پایین پشته‌ی برنامه‌های کاربردی (Application Stack) با هدف شناسایی و اصلاح مشکلات ارائه گردند. لازم به ذکر است که اگر امکان ارائه خدمات به گونه‌ای موثر وجود نداشته باشد، کاربران برای رسیدن به راهکار به هر جایی رجوع می‌نمایند.

در اینجاست که ترکیب داده‌های APM با انواع دیگری از داده‌ها اهمیت زیادی می‌یابد. باید امکان ارزیابی، عیب‌یابی و اصلاح سریع مشکلات وجود داشته باشد که این کار نیازمند منابع داده دیگری مانند فایل‌های Log است که به شناسایی دلیل اصلی مشکل کمک می‌نماید.

معماری‌های جدید برنامه‌های کاربردی

همان ‌طور که قوانین جاده‌ای به سرعت تغییر می‌کنند، IT در مقیاس وب نیز در یک حالت جدید قرار می‌گیرد که پشتیبانی از آن مستلزم معماری‌ها و رویکردهای نوینی می‌باشد. علاوه بر آن کسب‌و‌‌کارهای مختلف موظفند Applicationها را به سرعت ارائه نموده و اغلب آنها را تکرار نمایند. بسیاری از سازمان‌ها برای انجام این کار به یک رویکرد API-محور رو می‌آورند تا مقیاس، چابکی و انعطاف‌پذیری را ارائه نمایند؛ اما لازم است که کاربرد و عملکرد آنها مانیتور و آنالیز گردد.

میکروسرویس‌ها با هدف انجام فعالیت به صورت مستقل از یکدیگر ارائه شده و از طریق یک API واحد، مورد ارزیابی قرار می‌گیرند. در نتیجه، تعداد عواملی لازم برای همکاری با یکدیگر را افزایش داده و یک تراکنش کامل را ایجاد می‌نمایند. تکنولوژی‌های مبتنی بر Container نظیر Docker نیز به ارائه یک محیط میزبان می‌پردازد که برای میکروسرویس‌های در حال اجرا مطلوب می‌باشد. Containerها را می‌توان در صورت نیاز فعال یا متوقف نمود و به راحتی در بین تجهیزات جابجا نمود. این جابجایی بدین معناست که:

  • تکنولوژی‌های بیشتری وجود دارد که مسئولیت مدیریت آنها بر عهده شما می‌باشد. همچنین نقاط خرابی یا Failure بیشتری نسبت به قبل وجود خواهد داشت.
  • استفاده از رویکرد داده‌محور (Data-Centric) برای مدیریت سرویس‌ها امری ضروری می‌باشد. ضمن اینکه داده‌ها باید ارزش حاصل از رویکرد مدیریتی شما را تعریف نمایند نه تعداد سرورها.
  • تمرکز انحصاری بر عملکرد کدها و سرورهای برنامه، تصویر کاملی را برای شما ارائه نمی‌نماید.

مفهوم Silo و Tier در Application Management

در صورت مشاهده برنامه‌های کاربرد‌ی شما توسط کاربران، در واقع آنها کسب‌و‌‌کار شما را مورد مشاهده قرار داده‌اند. داخل هر برنامه، Siloها و Tierها قرار دارند که متشکل از شبکه‌ها، سیستم‌ها، Containerها و ماشین‌های مجازی، Tierهای برنامه، میکروسرویس‌ها، پایگاه‌های داده، Load Balancerها، سرویس‌های Cloud، فایروال‌ها، Power، HVAC و Storage می‌باشد و تمام این موارد نیز می‌توانند مشکل‌آفرین باشند (شکل 1 را ملاحظه فرمایید). بنابراین در صورت بروز مشکل، روند بررسی مورد توجه قرار می‌گیرد.

وقتی با رویکرد مورد نظر، به تفکیک Siloها می‌پردازید، در واقع شما نیز در مشکل سهیم می‌شوید:

  • یافتن دلیل اصلی مشکل زمان‌بر یا غیرممکن است.
  • ابزارهای مختص Silo معمولا تک منظوره می‌باشند. حتی اگر در فرآیند مانیتورینگ نیز موثر باشند، در روند عیب‌یابی، برنامه‌ریزی برای ظرفیت و ایجاد ارزش برای ذینفعان از ارزش محدودی برخوردار می‌باشند.
  • توافقنامه سطح خدمات یا به اختصار SLA برای یک سرویس یا سطح کلی اپلیکیشن ارائه می‌گردد. APM و سایر ابزارهای مربوط به حوزه‌های تخصصی ممکن است شاخص‌های کلیدی عملکرد یا KPIها را برای دسترس‌پذیری سرویس ارائه نمایند اما قادر به ایجاد دید واقعی و درست نسبت به مدیریت سطح سرویس نمی‌باشند.
  • حتی در صورت یافتن منبع مشکل، اغلب این داده‌ها برای Developerها، مهندسین، DBAها، SQAها و سایر ذینفعان قابل دسترس نمی‌باشد.
Application Management - Splunk - مدیریت برنامه های کاربردی

شکل 1- تراکنش‌ها، Siloهای برنامه و زیرساخت را توسعه داده و انجام آنالیز برای دلیل اصلی مشکل را با ایجاد دید در تمام Siloها، دشوار می‌نماید.

علاوه براین، تمام آنچه مشتریان می‌دانند، این است که کسب‌وکار شما دچار مشکل شده و به سرعت به سمت و سوی دیگری روانه می‌شوند.

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

Application Management - Splunk - مدیریت برنامه های کاربردی

شکل 2- مهمترین دلایل برای سرمایه‌گذاری بر روی APM

ــــــــــــــــــــــــــــــ

Application Management از دیدگاه Splunk – قسمت اول

Application Management از دیدگاه Splunk – قسمت دوم (پایانی)

برچسب ها :

مطلب مفید بود؟


?