NetApp өөрийн LLM-ээ холбоно: автомат засвар бодлогын хашаанаас гарахгүй

NetApp 9-р сарын 29-ний мэдэгдэлдээ NetApp Console-ийн AI ChatOps-д байгууллага өөрийн том хэлний загварыг нээлттэй LLM gateway-ээр холбох боломжийг зарлав. Байгалийн хэлээр өгсөн хүсэлтээс ONTAP хадгалалтын системд нөөц хуваарилах, төлөв байдлыг шинжлэх, асуудлыг автоматаар засах үйлдэл гаргах нь шинэчлэлийн зорилго. NetApp-ийн танилцуулснаар эдгээр үйлдэл урьдчилан тогтоосон хадгалалтын ангилал, бодлого, засаглалын хүрээнд үлдэнэ.

Шинэчлэлийг Лас Вегаст болсон NetApp INSIGHT 2026 арга хэмжээний үеэр танилцуулжээ. NetApp-ийн техникийн маркетингийн дэд ерөнхийлөгч Жефф Бакстер ITPro-д өгсөн ярилцлагадаа хамтран ажилладаг байгууллагуудын бараг бүгд “one or more approved LLMs” буюу нэг буюу хэд хэдэн баталсан хэлний загвартай болсон гэж хэлсэн. Өөрийн загварыг холбох боломж нь байгууллагын сонгосон LLM-ийг хадгалалтын удирдлагад ашиглах тухай болохоос тэр загварт хадгалалтыг өөрчлөх хязгааргүй эрх өгөх тухай биш.

ChatOps хүсэлт бодит үйлдэлд хэрхэн шилжих вэ

Администратор хүссэн үр дүнгээ байгалийн хэлээр илэрхийлнэ. Console тэр хүсэлтийг хадгалалтын удирдлагын ажилтай холбож, нөөц хуваарилах, байршуулах, тайлагнах эсвэл удирдах үйлдэлд шилжүүлэхээр танилцуулагдсан. Ингэснээр хүсэлтийн үгийг тайлбарлах ажил хэлний загварт, харин ямар үйлдэл зөвшөөрөгдөхийг шийдэх ажил хадгалалтын бодлого ба хэрэглэгчийн эрхэд хамаарна. Ярианы интерфейсээр хүсэлт өгөх боломж нь өмнөх хяналтын заагийг арилгахгүй.

Жишээ нь, администратор тодорхой ачаалалд хадгалалтын нөөц хүссэн гэж үзье. Систем эхлээд зорилгыг нь таньж, тохирох хадгалалтын ангилал болон байршуулалтын нөхцөлийг сонгоод, тухайн хэрэглэгчийн эрхэд багтах үйлдлийг санал болгох учиртай. Энэ бол зарласан боломжуудын урсгалыг тайлбарласан нөхцөлт жишээ; бүх орчинд яг ийм дэлгэц, ижил дараалал гарна гэсэн үг биш. Тодорхой бус хүсэлтийг загвар өргөн утгаар тайлбарласан ч бодит өөрчлөлтийн хүрээ бодлогоор тогтоогдоно.

Console-ийн AI тайлагнал, урьдчилан таамаглах шинжилгээ нь энэ урсгалд нэмэлт мэдээлэл өгнө. Администратор системийн төлөвийг асууж, хариунаас нь удирдлагын ажил руу шилжих боломжтой болох нь зөвхөн мэдээлэл харуулдаг туслахаас ялгаатай. Гэхдээ тайлбар, санал, гүйцэтгэл нь тусдаа үе шат: загварын гаргасан хариу өөрөө ONTAP-д өөрчлөлт хийх зөвшөөрөл болж хувирах ёсгүй.

Автомат засварын амлалт юуг хамрах вэ

Шинэ боломжийн нэг хэсэг нь асуудлыг урьдчилан илрүүлэх шинжилгээ, түүнд хариулах автомат засвар юм. Энэ нь хадгалалтын төлөвийг ажиглах, асуудлыг таних, зөвшөөрөгдсөн арга хэмжээг хэрэгжүүлэх үе шатуудыг ойртуулна. Зарлал тодорхой төрлийн доголдол бүрт ямар засварыг ямар нөхцөлд автоматаар хийхийг жагсаагаагүй тул «автомат засвар» гэдгийг бүх доголдлыг хүний оролцоогүй арилгана гэж ойлгож болохгүй.

Урьдчилан таамагласан дохио болон засварын үйлдлийг мөн ялгах хэрэгтэй. Багтаамж эсвэл гүйцэтгэлтэй холбоотой эрсдэлийг эрт харуулах нь системийн төлөвийн тухай мэдээлэл; нөөцийн тохиргоог өөрчлөх нь хадгалалтын бодит үйлдэл. Сүүлчийнх нь зөвшөөрөгдсөн нөөц, хэрэглэгчийн эрх, байгууллагын бодлогод нийцэх шаардлагатай. Ийм зааг нь шинжилгээ алдаатай байсан ч санал болгосон өөрчлөлт шууд бүх системд хэрэгжихээс сэргийлэхээр зориулагдсан.

NetApp олон ONTAP системийн удирдлагыг нэг Console-д төвлөрүүлэхээр танилцуулсан нь засварын хамрах хүрээг илүү чухал болгож байна. Нэг хүсэлт эсвэл нэг дохио хэдэн системд нөлөөлж болохыг загварын хариунаас бус, тухайн үйлдэлд оноосон нөөцийн хүрээнээс тогтоох ёстой. Энэ ялгаа особенно олон орчинтой байгууллагад хэрэгтэй: нэг удирдлагын цэгтэй болох нь бүх орчинд ижил өөрчлөлт хийх зөвшөөрөл гэсэн үг биш.

Өөрийн LLM ашиглахад өгөгдөл хаагуур явах вэ

Нээлттэй gateway нь байгууллага Console-ийн AI ажиллагаанд өөрийн сонгосон LLM-ийг ашиглах боломж олгоно. Өмнө нь баталж, хамгаалалтын шаардлага тогтоосон загвараа хадгалалтын удирдлагад холбох нь шинэ загвар сонгох ажлыг багасгаж болно. Харин «өөрийн загвар» гэх нэр дангаараа түүний ажиллах байршил, хүсэлт хадгалах нөхцөл, Console-оос загварт дамжих мэдээллийн хэмжээг тодорхойлохгүй. Эдгээр нь байгууллагын сонгосон загварын байршуулалт болон холболтын тохиргооноос хамаарна.

Console-ийг хэрэглэгчийн өөрийн орчинд суулгах хувилбарыг мөн танилцуулсан. Энэ нь удирдлагын ажиллагааг байгууллагын орчинд байрлуулах сонголт боловч холбосон LLM заавал тэнд ажиллана гэсэн баталгаа биш. Тусгаарласан орчинд ажиллах боломж болон загварын төгсгөлийн цэг хаана байгааг тус тусад нь авч үзэх шаардлагатай. Ялангуяа ChatOps хүсэлтэд системийн төлөв, нөөцийн нэр эсвэл алдааны мэдээлэл орж болох тул үндсэн хадгалсан өгөгдөл ба загварт очих хүсэлтийн мэдээллийг нэг зүйл гэж үзэж болохгүй.

NetApp Platform өгөгдлийг шилжүүлэх, хуулах, нэг газар цуглуулахгүйгээр ашиглах зорилгыг тайлбарладаг. Энэ нь ChatOps-ийн хүсэлт, хариу, үйл ажиллагааны лог огт дамжихгүй гэсэн баталгаа биш. Байгууллагын өгөгдөл хаана хадгалагдах, загвар хаана ажиллах, gateway-ээр ямар контент дамжих нь өөр өөр шийдвэр. Тэдгээрийн заагийг тодорхой болгосноор өөрийн LLM ашиглах сонголт өгөгдлийн байрлалын шаардлагатай нийцэж байгаа эсэхийг бодитоор үнэлж болно.

Бодлого, эрх, аудит өөрчлөлтийг хэрхэн хязгаарлах вэ

Console-ийн бүтээгдэхүүний тайлбарт хадгалалтын ангилалд гүйцэтгэл, багтаамж, аюулгүй байдал, өгөгдөл хамгаалалтын бодлого оноохын зэрэгцээ үүргээр хязгаарласан эрх, зөвхөн унших хамгаалалт, батлах урсгал, аудитын мөрийг дурдсан. Эдгээр нь нэг л шалгалтын өөр нэрс биш. Хадгалалтын ангилал ямар нөөц тохирохыг, эрхийн хүрээ хэн ямар системд хүрэхийг, батлах урсгал санал болгосон өөрчлөлт хэзээ гүйцэтгэгдэхийг шийднэ.

Хэлний загвар хүсэлтийг зөв ойлгосон ч тухайн хүн тэр үйлдлийг хийх эрхгүй байж болно. Мөн эрхтэй хэрэглэгчийн хүссэн нөөц сонгосон хадгалалтын ангиллын багтаамж, хамгаалалтын нөхцөлд нийцэхгүй байж болно. Иймд загварын санал бүрийг бодлогын шийдвэртэй адилтгах боломжгүй. Зөвхөн унших хүрээнд шинжилгээ хийх, хадгалалтыг өөрчлөх эрхтэй хүрээнд үйлдэл гүйцэтгэх хоёрын ялгаа ChatOps-ийн аюулгүй ажиллагааны үндсэн хэсэг юм.

Хүний хяналт нь хүсэлт бүрийг гараар батлахтай заавал адил биш. Бүтээгдэхүүний танилцуулгад автомат ажиллагаа болон батлах урсгал хоёулаа багтсан ч яг аль өөрчлөлтөд заавал зөвшөөрөл авахыг зарлал нэг бүрчлэн тогтоогоогүй. Харин байгууллага зөвшөөрөгдөх үйлдлийн хүрээ, онцгой тохиолдолд шаардах баталгааг ялгах шаардлагатай. Ингэснээр энгийн ажил автоматжих боломжтой хэвээр, өндөр нөлөөтэй өөрчлөлт тусдаа хяналтад үлдэнэ.

Аудитын мөр нь болсон үйлдлийг дараа нь сэргээн тогтооход хэрэгтэй. Хүсэлтийг хэн гаргасан, ямар нөөц хамрагдсан, ямар бодлого үйлчилсэн, өөрчлөлт батлагдсан эсэх, системд юу өөрчлөгдсөнийг хооронд нь холбож үзэх боломж нь алдааг шинжлэхэд чухал. NetApp аудит ба үйл ажиллагааны хяналтын боломжийг танилцуулсан боловч зарлал эдгээр талбар бүрийн бүртгэлийн хэлбэрийг нарийвчлаагүй. Тиймээс аудитын боломж байгааг бүртгэлийн бүх шаардлага аль хэдийн биелсэн гэж ойлгож болохгүй.

Зарлал ба ашиглах боломжийн зааг

NetApp Console-ийн шинэ боломжуудыг зарласан нь ChatOps-ийн бүх үйлдэл, бүх LLM холболт, бүх төрлийн засвар хэрэглэгч бүрийн орчинд нэгэн зэрэг нээгдсэнийг илэрхийлэхгүй. Нийтлэгдсэн мэдээлэл нь боломжуудын чиглэл, бүтээгдэхүүний хяналтын зарчмыг тодорхойлж байгаа ч дэмжигдэх үйлдлийн бүрэн жагсаалт болон орчин бүрийн нөхцөлийг тусад нь өгсөнгүй. Иймээс автомат засварын хамрах хүрээг байгууллага өөрийн Console-ийн хувилбар, холбосон загвар, олгосон эрхтэй нь хамт ойлгох шаардлагатай.

Энэ шинэчлэлийн бодит үр дагавар нь хэлний загвар хадгалалтын хүсэлтийг тайлбарлах суваг болж, байгууллагын бодлого бодит өөрчлөлтийн шийдвэрийг хэвээр хадгалах явдал. Console олон системийн төлөв, хүсэлт, засварын ажиллагааг нэгтгэх тусам буруу тайлбарласан хүсэлтийн нөлөө ч өргөжих боломжтой. Тиймээс ямар үйлдэл автомат гүйцэтгэгдэх, аль нь батлах шатанд очих, аудитад юу үлдэх тухай бүтээгдэхүүний нарийвчилсан баримтжуулалт энэ зарлалын дараах чухал мэдээлэл болно.

Мөн уншаарай:

• UiPath агентын ажлыг зураглана: зөрүүтэй дүрэм автоматаар батлагдахгүй
• n8n-ийг өөрийн серверт байрлуулах нь: нэг encryption key бүх нууцыг аварна
• Go.AI $85 сая босгов: банкууд AI-гаа өөрийн байранд ажиллуулна