MCP دارد از مرز اپلیکیشنهای هوش مصنوعی خارج میشود و وارد عملیات شبکه سازمانی میشود
پروتکل MCP (Model Context Protocol) در ابتدا به عنوان یک الگوی یکپارچهسازی برای دستیارهای هوش مصنوعی متولد شد. اما این چارچوببندی دیگر خیلی محدود است. در زیرساختهای سازمانی، MCP به عنوان یک روش عملی برای نمایش زمینه عملیاتی، اقدامات کنترلشده و دسترسی به ابزارها برای سیستمهای استدلال ماشینی در حال ظهور است، بدون اینکه نیاز باشد همان مجموعه آداپتورها برای هر مدل و هر پلتفرم دوباره ساخته شود.
عملیات شبکه یکی از واضحترین جاهایی است که این موضوع اهمیت دارد. مراکز NOC همیشه بر روی زمینهای تکهتکه کار میکنند: سیستمهای تیکت، پلتفرمهای مشاهدهپذیری، موجودی دستگاهها، CMDB، آرشیو تنظیمات، تقویمهای نگهداری و APIهای اختصاصی فروشندگان. مشکل کمبود داده نیست. مشکل این است که معنای عملیاتی در سیستمهایی پراکنده است که به طور طبیعی با هم ترکیب نمیشوند. MCP به اپراتورها راهی تمیزتر میدهد تا آن سیستمها را به عنوان ابزارهای قابل استفاده با دامنه محدود، شمای صریح و تعاملات قابل ممیزی به عوامل هوش مصنوعی ارائه دهند.
چرا عملیات شبکه برای MCP مناسبتر از ورکفلوهای عمومی سازمانی است
بسیاری از تیمهای سازمانی اولین بار MCP را از طریق ابزارهای کدنویسی، بازیابی اسناد و رباتهای دانشی دیدند. این موارد استفادههای مشروعی هستند، اما عملیات شبکه نیاز ساختاری قویتری دارد. کار شبکه به وضعیت زنده، دستورات خاص دستگاه و ضمانتهای رویهای وابسته است. یک ربات چت عمومی که به طور سست به یک ویکی متصل است کافی نیست. عامل باید بداند با چه دستگاهی کار میکند، چه پنجره تغییری فعال است، چه سیاست افزایش سطحی اعمال میشود، و آیا یک اقدام فقط خواندنی است یا مجاز به اجرا.
MCP کمک میکند زیرا نمایش ابزار را رسمی میکند. به جای اینکه به یک عامل بگوییم «خودش بفهمد» چگونه از API موجودی پرسوجو کند، یک diff تنظیمات اخیر را بازیابی کند و سلامت رابط را قبل از پیشنهاد یک مرحله اصلاحی مقایسه کند، یک تیم عملیاتی میتواند آن قابلیتها را از طریق تعاریف ابزار پایدار منتشر کند. این کار پیچیدگی پرامپت را کاهش میدهد و احتمال بداههگویی در جای اشتباه را پایین میآورد.
این موضوع به ویژه زمانی مهم است که تیمهای شبکه به جای کوپایلوتهای یکبار مصرف، با ورکفلوهای عاملی آزمایش میکنند. یک کوپایلوت که BGP را در یک پنجره چت توضیح میدهد به راحتی قابل نمایش است. یک عاملی که یک افزایش ناگهانی تیکت را با خطاهای رابط لبه مرتبط میکند، بررسی میکند که آیا یک رویداد نگهداری برنامهریزیشده در حال اجراست، آخرین تنظیمات خوب شناختهشده را میکشد و یک پیشنهاد بازگشت تهیه میکند، سختتر است. آن ورکفلو دوم نیاز به دسترسی منضبط به چندین سیستم دارد. MCP مناسب است زیرا آن سیستمها را به عناصر اولیه عملیاتی خواناتر و قابل استفاده مجدد تبدیل میکند.
چه تغییری میکند وقتی ابزارهای زیرساختی از طریق MCP قابل دسترس میشوند
اولین تغییر یکپارچگی است. بیشتر پروژههای هوش مصنوعی در عملیات بیصدا شکست میخورند زیرا هر تیم یک چسب سفارشی میسازد. یک گروه یک LLM را به Grafana متصل میکند. دیگری جستجوی ServiceNow را میپیچد. سومی یک ربات داخلی برای موجودی دستگاه ایجاد میکند. هر سه با انتزاعات جداگانه، کنترلهای امنیتی جداگانه و بارهای نگهداری جداگانه مشکلات مجاور را حل میکنند. یک لایه MCP به تیمها اجازه میدهد تا نحوه توصیف و مصرف ابزارها را استاندارد کنند، حتی اگر سیستمهای زیرین ناهمگن باقی بمانند.
تغییر دوم قابلیت حمل در بین فروشندگان مدل و فریمورکهای عامل است. خریداران سازمانی دیگر نمیخواهند اتوماسیونهای عملیاتی را به یک UI مدل خاص متصل کنند. آنها میخواهند آزادی حرکت بین عوامل داخلی، دستیارهای فروشنده یا ارکستراتورها را داشته باشند با تغییر نیازها. وقتی جستجوی تلهمتری، ایجاد تیکت تغییر، اعتبارسنجی خطمشی مسیریابی و بررسی پنجره نگهداری به صورت پروتکلپسند نمایش داده میشوند، لایه مدل اطراف قابل جایگزینیتر میشود.
تغییر سوم اعتماد عملیاتی است. اعتماد از اعتماد به نفس عامل نمیآید. از قابل بازرسی بودن ورودیها و اقدامات آن میآید. فراخوانیهای ابزار به سبک MCP یک ردپای بهتر از پرامپتنویسی آزاد در برابر دامپهای خام سیستم ایجاد میکند. یک تیم میتواند ببیند کدام ابزارها استفاده شدهاند، چه پارامترهایی ارسال شده و کدام خروجیها یک توصیه را شکل دادهاند. این موضوع زمانی مهم است که یک عامل پیشنهاد تخلیه ترافیک از یک سایت یا به تأخیر انداختن یک بهروزرسانی فریمور را بدهد.
MCP در NOC به احتمال زیاد اول در کجا ظاهر میشود
ورکفلوهای تحقیقاتی با بار خواندنی زیاد
اولین و امنترین موارد استفاده تحقیقاتی هستند. یک مهندس از یک عامل میخواهد توضیح دهد چرا از دست دادن بسته در یک بخش WAN منطقهای افزایش یافته است، و عامل شمارندههای رابط، هشدارهای اخیر، زمینه توپولوژی و حوادث مرتبط را پرسوجو میکند. هیچ چیز در تولید تغییر نمیکند، اما زمان صرفشده برای جمعآوری شواهد به شدت کاهش مییابد. این نقطه ورود با اصطکاک کم است زیرا قبل از اینکه سازمان برای اجرا آماده باشد، ارزش ایجاد میکند.
پیمایش رانبوک و تحلیل قبل از تغییر
یکی دیگر از موارد استفاده نزدیک، راهنمایی رویهای مبتنی بر دادههای زنده است. قبل از یک تغییر، یک عامل میتواند رانبوک مربوطه را واکشی کند، آن را با محیط هدف مقایسه کند، پیشنیازهای گمشده را شناسایی کند و ملاحظات شعاع انفجار را خلاصه کند. به عنوان مثال، اگر یک تیم قصد دارد یک شعبه را از مسیریابی MPLS-first به ترجیح SD-WAN منتقل کند، عامل میتواند سلامت مدار، نسخههای نرمافزاری دستگاه و وجود سیاستهای بازگشتی را قبل از اینکه مهندس به تولید دست بزند، تأیید کند.
غنیسازی تیکت و پشتیبانی افزایش سطح
میزهای خدمات معمولاً حوادث شبکه را با زمینه ناقص باز میکنند. یک عامل متصل به MCP میتواند به طور خودکار تیکتها را با پیوست کردن نقش دستگاه، بحرانی بودن سایت، تغییرات اخیر، تاریخچه هشدار و مالکیت احتمالی غنی کند. این کار نیاز به بررسی انسانی را از بین نمیبرد، اما زمان صرفشده مهندسان ارشد برای بازسازی حقایق پایه از چندین پورتال را کاهش میدهد.
اجرای محدود در دامنههای باریک
اجرا دیرتر میآید، اما نه به طور یکنواخت. تیمها احتمالاً ابتدا اجازه اقدامات محدود و محکم را میدهند: باز کردن یک تیکت نگهداری، جمعآوری خروجیهای تشخیصی از یک لیست دستور از پیش تأیید شده، تعلیق یک تست مصنوعی غیر بحرانی، یا راهاندازی یک اسکن انطباق تنظیمات. اصلاح خودکار کامل در زیرساخت اصلی تا زمانی که جریانهای تأیید، منطق بازگشت و کنترلهای خطمشی بالغ نشوند، نادر باقی خواهد ماند.
سوال حکمرانی مهمتر از سوال پروتکل است
MCP به تنهایی اتوماسیون شبکه را ایمن نمیکند. این کار یکپارچهسازی را تمیزتر میکند. کار سختتر تصمیمگیری در مورد اینکه چه چیزی باید نمایش داده شود، در چه سطح دسترسی، تحت چه شرایط تأیید و با چه لاگگیری است. یک سرور MCP بد طراحی که به یک عامل دسترسی گسترده شل به هاستهای پرش بدهد، معماری مدرن نیست. این یک بستهبندی جدید دور یک اشتباه قدیمی است.
سازمانهایی که از این تغییر ارزش میبرند، قابلیتهای خواندن، توصیه و اقدام را جدا میکنند. ابزارهای خواندن اغلب میتوانند گسترده باشند. ابزارهای توصیه نیاز به منبعیابی دارند، به طوری که خروجیها بتوانند دقیقاً ذکر کنند کدام سیستمها مشورت شدهاند. ابزارهای اقدام باید باریک، آگاه از خطمشی و متصل به تأییدهای صریح یا گاردریلهای زمینهای باشند. به عنوان مثال، یک ابزار استقرار تنظیمات باید بداند آیا دستگاه هدف در یک پنجره فریز است، آیا بررسی همتا انجام شده است و آیا تغییر پیشنهادی با یک الگوی شناخته شده مطابقت دارد یا خیر.
همچنین یک مسئله طراحی فروشنده در زیر هیجان پنهان است. فروشندگان شبکه به طور فزایندهای میخواهند در ورکفلوهای هوش مصنوعی حضور داشته باشند، اما صرفاً ارائه یک دستیار کافی نیست. خریداران پلتفرمهایی را ترجیح میدهند که سطوح عملیاتی قابل اعتمادی را به عوامل خارجی نمایش دهند، به جای اینکه اصرار کنند هر ورکفلو در داخل یک کوپایلوت اختصاصی بماند. MCP تا حدی جذاب است زیرا فروشندگان را تحت فشار قرار میدهد تا بر اساس کیفیت رابطهای ابزار خود رقابت کنند، نه فقط روان بودن تجربه چت خود.
تیمهای شبکه الان چه کار باید بکنند
با موجودی سیستمهای عملیاتی که از قبل APIهای تمیز و مسیرهای خواندنی با ارزش دارند شروع کنید. تلهمتری، توپولوژی، تاریخچه تنظیمات، دادههای حادثه و برنامههای نگهداری معمولاً بهترین مجموعه شروع هستند. هدف انتشار همه چیز نیست. هدف شناسایی یک گروه فشرده از ابزارهاست که به یک عامل کمک میکنند به سوالات عملیاتی مفید با ابهام کمتر پاسخ دهد.
سپس قراردادهای ابزار را حول وظایف واقعی اپراتور تعریف کنید. از رابطهای انتزاعی مانند «پرسوجوی دادههای شبکه» خودداری کنید. در عوض، قابلیتهایی را نمایش دهید که منعکسکننده نحوه کار مهندسان هستند: دریافت جزئیات دستگاه با نام میزبان، بازیابی سه diff تنظیمات آخر، بررسی اینکه آیا یک مدار هشدارهای همبسته دارد، فهرست کردن حوادث باز برای یک سایت، تأیید وضعیت پنجره تغییر. ویژگیسازی عملکرد عامل را بهبود میبخشد و استفاده نادرست را کاهش میدهد.
در نهایت، پذیرش MCP را به عنوان یک تصمیم مدل عملیاتی در نظر بگیرید، نه یک پروژه یکپارچهسازی جانبی. تیمهایی که در اینجا برنده میشوند، کار پروتکل را با طراحی دسترسی، الزامات حسابرسی، بهداشت رانبوک و اندازهگیری ورکفلو جفت میکنند. اگر یک عامل زمان تحقیق را کاهش دهد اما توصیههای مبهم تولید کند، نتیجه بلوغ نیست. این سردرگمی سریعتر است.
MCP مهم نیست چون مد روز است. مهم است زیرا عملیات سازمانی به یک رابط بهتر بین استدلال ماشین و واقعیت عملیاتی نیاز دارد. در محیطهای شبکه، جایی که زمینه تکهتکه است و اشتباهات پرهزینه، آن رابط در حال تبدیل شدن به یک لایه معماری واقعی است، نه یک راحتی برای توسعهدهندگان.