)
)
عامل‌های هوش مصنوعی در پشتیبانی IT فراتر از توصیه‌های عیب‌یابی حرکت می‌کنند و اقداماتی را بر روی دستگاه‌های از راه دور انجام می‌دهند. با ابزارهای مجاز، آنها می‌توانند تشخیص‌ها را جمع‌آوری کنند، اصلاحات را اعمال کنند و نتایج را بررسی کنند. برای مدیران سیستم، مدیران IT و ارائه‌دهندگان خدمات مدیریت شده، این فرصت پشتیبانی سریع‌تر است، اما سوالات عملی درباره مجوزها، نظارت، قابلیت اطمینان و مسئولیت مطرح می‌شود.
عیب‌یابی از راه دور شامل بیشتر از شناسایی یک راه‌حل است. کسی باید مداخله را تأیید کند، مجوزهای لازم برای دسترسی به دستگاه را کسب کند، کار را انجام دهد و تأیید کند که مشکل حل شده است. با من بررسی کنید که چگونه عوامل هوش مصنوعی این روند کاری را تغییر می‌دهند، کدام وظایف می‌توانند واگذار شوند و کجا مداخله تکنسین همچنان ضروری است.
وقتی هوش مصنوعی از مشاوره به عمل می‌رسد چه تغییراتی ایجاد می‌شود؟
زمانی که هوش مصنوعی می‌تواند به یک شرکت‌کننده فعال بالقوه در فرآیند عیب‌یابی تبدیل شود به جای اینکه صرفاً دستورالعمل‌ها را ارائه دهد، قطعات شروع به حرکت کردند. بیشتر از یک چت‌بات که یک پیام خطا را توضیح می‌دهد یا یک کمک‌راننده هوش مصنوعی که صرفاً پیشنهاد می‌کند یک تکنسین سرویس ویندوز را دوباره راه‌اندازی کند: یک عامل هوش مصنوعی ممکن است بتواند وضعیت آن را بررسی کند، یک راه‌اندازی مجاز را اجرا کند و بررسی کند که آیا برنامه تحت تأثیر دوباره کار می‌کند یا خیر.
این مسئولیت بخشی از تکنسین را از انجام اقدامات فردی به نظارت بر نحوه انتخاب، اجرا و تأیید آن اقدامات منتقل می‌کند.
چت‌بات‌ها، کمک‌ران‌ها و عوامل خودمختار IT
در میان انواع ابزارهای پشتیبانی مبتنی بر هوش مصنوعی، سه رویکرد بالقوه به‌ویژه مرتبط به نظر می‌رسند:
- چت‌بات‌های هوش مصنوعی: به سوالات پاسخ دهید، پیام‌های خطا را توضیح دهید و روش‌های عیب‌یابی را پیشنهاد کنید.
- دستیارهای هوش مصنوعی: تکنسین‌ها را در تشخیص، نوشتن اسکریپت و تصمیم‌گیری یاری کنید، در حالی که اجرای کارها عمدتاً به انسان‌ها واگذار می‌شود.
- عامل‌های هوش مصنوعی با قابلیت اقدام: از ابزارهای متصل برای بررسی مشکلات، انجام اقدامات مجاز و ارزیابی نتایج آنها با سطوح مختلف نظارت انسانی استفاده کنید.
در سپتامبر ۲۰۲۶، تیم ویور اعلام کرد که تیای عیب‌یابی توصیف یک سیستم هوش مصنوعی که قادر به بررسی مسائل، اعمال اصلاحات تأیید شده توسط تکنسین و اعتبارسنجی نتایج در طول جلسات پشتیبانی است.
با این حال، خودمختاری می‌تواند کاهش یابد. یک بخش IT ممکن است به یک عامل هوش مصنوعی اجازه دهد که اطلاعات تشخیصی را به طور مستقل جمع‌آوری کند در حالی که قبل از ایجاد تغییرات پیکربندی یا مسدود کردن اقدام به طور کامل، نیاز به تأیید داشته باشد.
هنگامی که هوش مصنوعی می‌تواند بر روی یک دستگاه عمل کند، چه خطرات جدیدی ظاهر می‌شود؟
یک توصیه تولید شده توسط هوش مصنوعی ممکن است نادرست باشد، اما یک تکنسین می‌تواند آن را قبل از اجرا ارزیابی کند. زمانی که یک عامل هوش مصنوعی می‌تواند خود توصیه را اجرا کند، خطاها می‌توانند به طور مستقیم بر برنامه‌ها، فایل‌ها، پیکربندی‌های سیستم و عملیات تجاری تأثیر بگذارند.
خطاهای ممکن:
- هدف نادرست را انتخاب کنید؛
- اطلاعات تشخیصی را اشتباه متوجه شوید؛
- تکرار یک تعمیر ناموفق؛
- دستورات مخرب را که در تیکت‌ها، لاگ‌ها یا اطلاعات دیگری که پردازش می‌کند، جاسازی شده‌اند، شناسایی کنید؛
- از روش‌های غیرمنطقی برای دستیابی به هدف تعیین‌شده استفاده کنید.
OWASP Top 10 برای برنامه‌های عامل ، خطرات امنیتی را افزایش می‌دهد و به آنها رسیدگی می‌کند.
کنترل‌های هویتی مناسب، مجوزهای محدود و سیاست‌های مجوزدهی در دستور کار هستند، همانطور که در مقاله همراه ما در امنیت عامل هوش مصنوعی و دسترسی غیرانسانی به برنامه‌های تجاری بررسی می‌کند.
برای تیم‌های پشتیبانی از راه دور، با این حال، سوال فوری بیشتر عملیاتی است:
- کدام اقدامات را می‌توان به‌طور ایمن توسط هوش مصنوعی انجام داد؟
- تکنسین‌ها چگونه باید فرآیند اجرا را کنترل کنند؟
کدام وظایف پشتیبانی IT را می‌توانند عوامل هوش مصنوعی به‌صورت از راه دور انجام دهند؟
عامل‌های هوش مصنوعی زمانی بیشترین کاربرد را دارند که یک مشکل پشتیبانی بتواند به "علائم" قابل مشاهده، رویه‌های آزمایش‌شده، اقدامات مجاز و نتایج قابل اندازه‌گیری تبدیل شود.
این باعث می‌شود که تشخیص‌های تکراری و رویه‌های ترمیمی به خوبی درک شده، نقاط شروع بهتری نسبت به کارهای اداری غیرقابل پیش‌بینی باشند. پیچیدگی نسبت به فراوانی اهمیت دارد.
تشخیص و اصلاح کم‌خطر
یک عامل هوش مصنوعی متصل به ابزارهای تشخیصی تأیید شده ممکن است بتواند گزارش‌های رویداد را بازیابی کند، وضعیت خدمات را بررسی کند، ظرفیت دیسک را چک کند یا یک فرآیند برنامه ناموفق را شناسایی کند.
در صورت گزارش یک کارمند مبنی بر اینکه یک برنامه داخلی دیگر راه‌اندازی نمی‌شود، عامل هوش مصنوعی می‌تواند رویدادهای مربوط به ویندوز و وابستگی‌های برنامه را بررسی کرده و یافته‌ها را با حوادث شناخته شده مقایسه کند. در چارچوب یک رویه ترمیم از پیش تعریف شده، همچنین ممکن است یک سرویس غیر بحرانی تأیید شده را مجدداً راه‌اندازی کرده یا فایل‌های موقت تعیین شده را پاک کند.
با این حال، مجوزها، تدابیر ایمنی و اعتبارسنجی مناسب همچنان از اهمیت بالایی برخوردارند، بنابراین راه‌اندازی مجدد یک سرویس نقطه پایانی که به نظر بی‌خطر می‌رسد، نباید چندین کاربر را در یک سرور مشترک مختل کند.
نرم‌افزار، پیکربندی و تغییرات مدیریتی
مداخلات پیچیده‌تر شامل نصب به‌روزرسانی‌ها، تغییر تنظیمات برنامه، راه‌اندازی مجدد خدمات وابسته یا تغییر پیکربندی‌های سیستم است.
اگرچه چنین عملیاتی ممکن است از نظر فنی از طریق ابزارهای متصل به یک عامل هوش مصنوعی ممکن باشد، عواقب عملیاتی آن کمتر قابل پیش‌بینی است.
یک برنامه ویندوز را در نظر بگیرید که پس از یک به‌روزرسانی دچار مشکل می‌شود. هوش مصنوعی می‌تواند با شناسایی نسخه نرم‌افزاری تحت تأثیر و تهیه یک برنامه جبران خسارت، تحقیقات را تسریع کند. با این حال، اجرای آن بازگشت ممکن است به یک دوره نگهداری، بررسی‌های سازگاری یا هماهنگی با سایر مدیران ممکن است اجازه نداشته باشید که به طور خودکار ادامه دهید.
وظایف نیازمند دخالت تکنسین
برخی از وضعیت‌های پشتیبانی به طور ضعیفی برای اجرای خودکار مناسب هستند. این موارد شامل حوادثی است که شامل احتمال نفوذ، از دست دادن داده‌های غیرمنتظره، قطعی‌های تولید یا تغییراتی است که بر چندین سیستم وابسته تأثیر می‌گذارد.
یک عامل هوش مصنوعی ممکن است با جمع‌آوری اطلاعات و تهیه یک خلاصه حادثه کمک کند. با این حال، یک تکنسین باید تأثیر کلی کسب‌وکار را ارزیابی کرده و تصمیم بگیرد که چگونه ادامه دهد. هدف عملی حداکثر خودمختاری نیست. هدف این است که کار را زمانی که وظیفه به اندازه کافی مطمئن است واگذار کنیم، اما کنترل انسانی را زمانی که عواقب دشوار می‌شود حفظ کنیم.
چگونه عوامل هوش مصنوعی در واقع اقداماتی بر روی دستگاه‌های از راه دور انجام می‌دهند؟
استدلال درباره یک مشکل و داشتن وسایل فنی برای حل آن دو قابلیت جداگانه هستند. قبل از اینکه بتواند چیزی را در یک کامپیوتر از راه دور تغییر دهد، یک عامل هوش مصنوعی به یک مکانیزم اجرایی نیاز دارد که اقدامات ممکن آن را تعریف کند.
APIها، اسکریپت‌ها و ابزارهای مدیریت نقطه پایانی
یک جریان کار هوش مصنوعی ممکن است رابط‌های برنامه‌نویسی کاربردی (APIs) را فراخوانی کند، اسکریپت‌های PowerShell تأیید شده را اجرا کند یا از ابزارهای نظارت و مدیریت از راه دور (RMM) استفاده کند. این روش‌ها زمانی به خوبی کار می‌کنند که دستورات قابل پیش‌بینی باشند و نتایج بتوانند به‌طور خودکار بررسی شوند.
به عنوان مثال، یک ابزار مدیریت نقطه پایانی ممکن است یک اسکریپت تعمیر آزمایش شده را در معرض نمایش قرار دهد. بنابراین، عامل هوش مصنوعی می‌تواند درخواست اجرای آن را بدون دریافت دسترسی یا امتیازات مدیریتی نامحدود کند.
جلسات از راه دور و تعامل گرافیکی
برخی از برنامه‌های ویندوز فاقد API های قابل استفاده هستند. عیب‌یابی ممکن است نیاز به باز کردن رابط‌های آنها، بازتولید یک خطا یا تأیید کارکرد یک اصلاح داشته باشد. ابزارهای استفاده از کامپیوتر می‌توانند به طور بالقوه از طریق اسکرین‌شات‌ها، کلیک‌های ماوس و ورودی صفحه‌کلید تعامل داشته باشند همانطور که در عامل‌های هوش مصنوعی در حال تعامل با برنامه‌های قدیمی ویندوز اتوماسیون گرافیکی با این حال به تغییرات در طرح‌ها، پیام‌های غیرمنتظره و وضعیت جلسه حساس است. تیم‌های IT نباید فرض کنند که این فرآیند به اندازه یک تماس API به خوبی تعریف شده قابل تکرار است.
دسترسی بدون نظارت به معنای پشتیبانی خودکار نیست
کلمه "عامل" خود نیز می‌تواند ایجاد سردرگمی کند. یک عامل نقطه پایانی، یک تکنسین پشتیبانی و یک عامل هوش مصنوعی چیزهای متفاوتی هستند. به همین ترتیب، دسترسی بدون نظارت به این معنی است که یک شخص یا فرآیند مجاز می‌تواند بدون حضور کاربر نهایی متصل شود، در حالی که استدلال یا ارکستراسیون هوش مصنوعی موضوع دیگری است.
نرم‌افزار پشتیبانی از راه دور به یک ادغام پشتیبانی جداگانه نیاز دارد تا یک سیستم هوش مصنوعی بتواند کنترل‌های آن را اجرا کند. خود اتصال یک پلتفرم عیب‌یابی خودمختار ایجاد نمی‌کند.
چگونه باید تیم‌های IT اقدامات هوش مصنوعی را تأیید و نظارت کنند؟
سیاست پشتیبانی از راه دور با کمک هوش مصنوعی باید اقداماتی را که مجاز هستند، اقداماتی که نیاز به تأیید دارند و اقداماتی که باید خارج از حیطه اختیارات عامل هوش مصنوعی باقی بمانند، تعریف کند.
چرا اقدامات را بر اساس تأثیر بالقوه، قابلیت برگشت و اهمیت آنها برای عملیات تجاری طبقه‌بندی نکنیم؟
تصمیم‌گیری مبتنی بر ریسک
| نمونه مداخله | کنترل پیشنهادی |
|---|---|
| گزارش‌های تشخیصی تأیید شده را بازیابی کنید | اجازه در چارچوب سیاست |
| یک سرویس غیر بحرانی تأیید شده را دوباره راه‌اندازی کنید | اجرای شرطی، نیاز به بررسی پس از مداخله |
| نرم‌افزار را نصب کنید یا پیکربندی را تغییر دهید | تأیید تکنسین |
| کنترل‌های امنیتی را غیرفعال کنید یا داده‌های تجاری را حذف کنید | اجرای خودکار را ممنوع کنید |
این تصاویر نقاط شروعی برای یک طبقه‌بندی هستند. سرویس تولید شما ممکن است به مجوزهای سخت‌گیرانه‌تری نسبت به یک محیط آزمایشی نیاز داشته باشد.
جلوگیری از ترمیم مکرر یا کنترل نشده
یک اصلاح ناموفق نباید باعث تلاش‌های نامحدود شود.
حدود را برای تلاش‌ها، گروه‌های دستگاه هدف، ساعات کاری و هویت‌های اجرایی قبل از فعال‌سازی مداخله خودکار تعیین کنید. اگر یک تعمیر ناموفق باشد، عامل باید متوقف شود یا به سطح بالاتری ارجاع داده شود تا اینکه به طور مکرر همان تغییر را اعمال کند. نظارت انسانی به معنای تعریف زمانی است که سیستم نباید ادامه دهد، نه صرفاً تأیید اقدام اول آن.
وقتی یک اصلاح اجرا شده توسط هوش مصنوعی شکست می‌خورد چه اتفاقی می‌افتد؟
یک دستور کامل شده لزوماً به این معنی نیست که مشکل حل شده است. یک سرویس می‌تواند در حالی که برنامه تجاری در دسترس نیست، دوباره راه‌اندازی شود؛ یک نصب می‌تواند به پایان برسد در حالی که مشکل اصلی همچنان وجود دارد. بنابراین، پشتیبانی قابل اعتماد با کمک هوش مصنوعی نیاز به تمایز بین اجرای موفق و اصلاح موفق دارد.
تأیید، بازگشت و تشدید
قبل از آغاز یک عمل، جریان کار پشتیبانی باید تعیین کند که موفقیت را اندازه‌گیری خواهد کرد.
یک برنامه ویندوز معیوب را بگیرید:
- خدمات مربوطه در حال اجرا است را تأیید کنید،
- بررسی لاگ‌های برنامه
- و آزمایش کنید که آیا یک کاربر مجاز می‌تواند عملیات قبلاً ناموفق را تکمیل کند.
اگر این بررسی‌ها ناموفق باشند، جریان کار باید متوقف شود، وضعیت قبلی که یک بازگشت آزمایش شده وجود دارد، بازیابی شود یا به یک تکنسین ارجاع داده شود. اگر بازگشت در دسترس نباشد چه؟ برخی عملیات نیاز به آماده‌سازی پیشرفته از پشتیبان‌ها، عکس‌های فوری یا سایر ترتیبات بازیابی دارند.
عامل هوش مصنوعی باید عدم قطعیت را منتقل کند نه اینکه یک تعمیر ناقص را به عنوان یک حادثه حل شده در نظر بگیرد.
مستندسازی مداخله
تیم‌های پشتیبانی نیاز دارند بدانند که عامل هوش مصنوعی چه چیزی را مشاهده کرده، چه اقداماتی را پیشنهاد داده، چه چیزی تأیید شده و چه چیزی در واقع تغییر کرده است.
یک رکورد مداخله مفید شامل
- شناسه دستگاه
- هویت اجرا
- زمان‌های ثبت شده,
- دستورات یا فراخوانی‌های ابزار
- تأییدها
- نتایج
- و هر تصمیم تشدید.
گزارش‌های جلسه، تاریخچه‌های فرمان و ضبط‌ها می‌توانند شواهد مکملی ارائه دهند، همانطور که در ضبط جلسه دسکتاپ از راه دور برای امنیت و انطباق در واقع، برای تکنسین‌ها که یک مداخله را توضیح می‌دهند یا در حال بررسی یک حادثه حل‌نشده هستند، گزارش‌های واضح تفاوت را ایجاد می‌کند.
چگونه می‌توانند تیم‌های IT لاغر و MSPها پشتیبانی از راه دور با کمک هوش مصنوعی را معرفی کنند؟
سازمان‌ها نیازی به خودکارسازی کل فرآیندهای پشتیبانی به‌طور فوری ندارند. یک آزمایش محدود که شامل حوادث تکراری و به‌خوبی مستند است، نقطه شروع قابل مدیریت‌تری را ارائه می‌دهد.
یک معرفی عملی می‌تواند شامل پنج مرحله باشد:
- شناسایی حوادث تکراری. مشکلات با علل شناخته شده، رویه‌های تعیین شده و معیارهای اعتبارسنجی قابل اعتماد را انتخاب کنید.
- ابزارهای اجرایی موجود را تعیین کنید. قبل از معرفی پلتفرم‌های اضافی، قابلیت‌های موجود در پشتیبانی از راه دور، مدیریت نقطه پایانی و اسکریپت‌نویسی را بررسی کنید.
- حدود عمل را تعریف کنید. دستگاه‌های مجاز، مجوزها، الزامات تأیید و عملیات ممنوعه را مشخص کنید.
- تست تحت نظارت. عامل را در یک محیط کنترل شده ارزیابی کنید قبل از اینکه استفاده در تولید را در نظر بگیرید.
- نتایج را اندازه‌گیری کنید. دقت ردیابی حل، مداخلات تکنسین، تغییرات ناموفق، نرخ‌های تشدید و زمان صرفه‌جویی شده.
مدیران خدمات مدیریت باید این کنترل‌ها را به طور جداگانه برای هر محیط مشتری اعمال کنند. یک نماینده مجاز برای بازرسی دستگاه‌های متعلق به یک مشتری نباید به طور خودکار به زیرساخت مشتری دیگری دسترسی پیدا کند.
همچنین مهم است که پشتیبانی با کمک هوش مصنوعی را از مدیریت مداوم نقطه پایانی متمایز کنیم. همانطور که مقایسه ما از پشتیبانی از راه دور در مقابل RMM توضیح می‌دهد که عیب‌یابی دستگاه‌های فردی و مدیریت یک مجموعه کامل از نقاط پایانی مرتبط اما نیازهای عملیاتی متفاوتی هستند.
قبل از پذیرش یک پلتفرم هوش مصنوعی، سازمان‌ها باید تعیین کنند که آیا قابلیت‌های مورد نیاز در ابزارهای آنها وجود دارد و کجا هماهنگی اضافی واقعاً ضروری است.
یک آزمایش موفق باید نه تنها حل سریع‌تر را نشان دهد، بلکه همچنین مداخلات غیرضروری کمتری و افزایش قابل اعتماد را زمانی که اتوماسیون به محدودیت‌های خود می‌رسد، نشان دهد.
TSplus Remote Support در کجا قرار می‌گیرد؟
با تغییرات هوش مصنوعی در نحوه تشخیص و حل مسائل فنی، تیم‌های IT هنوز به روش‌های قابل اعتماد برای دسترسی به کامپیوترهای از راه دور و مداخله مستقیم نیاز دارند. TSplus Remote Support کنترل از راه دور با حضور و بدون حضور، به اشتراک گذاری صفحه، دسترسی به خط فرمان به کامپیوترهای بدون حضور پیکربندی شده و قابلیت‌های ضبط جلسه را فراهم می‌کند.
این ویژگی‌ها از عیب‌یابی، نگهداری و بازیابی تحت هدایت تکنسین پشتیبانی می‌کنند زمانی که رویه‌های خودکار در دسترس نیستند، ناموفق هستند یا مناسب نیستند. آنها یک پلتفرم عیب‌یابی خودکار بومی نیستند: اجرای مبتنی بر هوش مصنوعی به ابزارها و ادغام‌های پشتیبانی شده جداگانه نیاز دارد.
برای مدیران سیستم و ارائه‌دهندگان خدمات مدیریت شده که در حال ارزیابی پشتیبانی با کمک هوش مصنوعی هستند، اولویت باید یک روند مداخله ساده و قابل اعتماد باقی بماند. TSplus به تیم‌ها کمک می‌کند تا قابلیت‌های عملی پشتیبانی از راه دور را حفظ کنند بدون اینکه اتوماسیون اضافی یک پیش‌نیاز باشد.
نتیجه
عامل‌های هوش مصنوعی می‌توانند پشتیبانی IT از راه دور را با انتقال از توصیه‌ها به اقدامات مجاز تغییر دهند. ارزش آنها به انتخاب وظایف مناسب، اعمال محدودیت‌های واضح در اجرا و تأیید نتایج بستگی دارد نه صرفاً افزایش خودکارسازی.
برای مدیران سیستم و ارائه‌دهندگان خدمات مدیریت شده، مؤثرترین رویکرد ترکیبی از تحقیق با کمک هوش مصنوعی، ابزارهای قابل اعتماد از راه دور، اصلاح کنترل‌شده و مسئولیت انسانی است زمانی که مشکلات غیرقابل پیش‌بینی می‌شوند.
TSplus پشتیبانی از راه دور آزمایشی رایگان
راهنمایی از راه دور حضوری و بدون حضور از/به کامپیوترهای macOS و ویندوز به صورت مقرون به صرفه.
)
)
)
