AI აგენტი ჩემს ოპერაციულ სამუშაოში: შეზღუდვები, რომლებიც მას უსაფრთხოს ხდის

ბოლო თვეებში ჩემი ოპერაციული სამუშაოს დიდი ნაწილი — სახლის ლაბორატორიაშიც და სამსახურშიც — გადის AI აგენტზე ტერმინალში (Claude Code). ეს არ არის ჩატბოტი, რომელიც კითხვებს პასუხობს: ეს არის აგენტი, რომელიც უშვებს kubectl-ს, კითხულობს ლოგებს, ასწორებს მანიფესტებს, აკეთებს push-ს git-ში და იძახებს ღრუბლოვან API-ებს.

სისწრაფე მარტივი ნაწილია. აგენტი შელითა და წვდომებით ასევე პროდაქშენის გატეხვის ყველაზე სწრაფი გზაა, რაც კი ოდესმე მქონია. ამიტომ საინტერესო კითხვა არ არის „რამდენად სწრაფად“, არამედ „რა ხდის ამას უსაფრთხოს“. ქვემოთ არის მოწყობა, რომელიც ამ კითხვას პასუხობს.

რეპოზიტორია არის მეხსიერება

ყოველ სესიას აგენტი მეხსიერების გარეშე იწყებს. ყველაფერი, რაც მან უნდა იცოდეს, დევს პრივატულ git რეპოზიტორიაში, რომელსაც ის სტარტზე ტვირთავს:

• მეთოდი: როგორ ტარდება დიაგნოსტიკა, რა თანმიმდევრობით და რას არ ვაკეთებთ არასდროს;
• runbook-ები სიმპტომების მიხედვით: „pod CrashLoopBackOff-ში“, „განახლება ვარდება another operation in progress-ით“, „სერტიფიკატს ვადა გაუვიდა პროქსის უკან“;
• ყველა გარემოს რუკა: ტოპოლოგია, workload-ები, ქსელი, საცავი, ვინ რას ფლობს და მდგომარეობის დათარიღებული სნეპშოტი;
• გადაწყვეტილებების ჟურნალი თითოეული გარემოსთვის.

ცოდნა გროვდება git-ში და არა ჩატის ფანჯარაში. როცა ინციდენტი იწყება, გარემო უკვე აღწერილია და აგენტი მას კითხულობს, სანამ რამეს შეეხება.

წესი 1: ჯერ მხოლოდ კითხვა

ყოველი ნაბიჯი მიდის ასე: ჰიპოთეზა → მხოლოდ კითხვით შემოწმება → დასკვნა და მხოლოდ ამის შემდეგ ცვლილება. დიაგნოსტიკა მსუბუქი დონიდან მძიმისკენ მოძრაობს: ჯერ get, describe, მოვლენები და ლოგები, შემდეგ PromQL ტრენდებისა და სატურაციისთვის, შემდეგ კი კითხვა, რომელიც წყვეტს, ვინ გაასწორებს: ეს აპლიკაციაა თუ პლატფორმა?

სიმპტომი არ არის მიზეზი. „ხან მუშაობს“ ან „თავისით გასწორდა“ დროის დამთხვევაა და არა გამოსწორება; აგენტი ძებნას აგრძელებს.

წესი 2: ყოველი ცვლილების დაბრუნება ჩანს გაშვებამდე

აგენტს შეუძლია ცვლილებები, მაგრამ არასდროს ჩუმად. მუტაციამდე ვხედავ ზუსტ ბრძანებას, სად არის შენახული სარეზერვო ასლი და ბრძანებას, რომელიც ყველაფერს დააბრუნებს. ფართო blast radius-ის მქონე ცვლილებები — ნოდის drain, namespace-ის წაშლა, ნულამდე scale — ჯერ აშკარა გაფრთხილებას იღებს.

სახლის ლაბორატორიაში კლიენტები და SLA არ არის, ამიტომ იქ აგენტს big-bang ცვლილებები ეძლევა. ლაბორატორიის აზრიც ეს არის: დაზვერვა, სანამ იგივე ცვლილება მიაღწევს გარემოს, სადაც მომსახურების ფანჯარა და დამტკიცება საჭირო.

წესი 3: ხანმოკლე და ვიწრო წვდომები

ხანგრძლივი ფართო ტოკენები სწორედ ის ადგილია, სადაც აგენტი საშიში ხდება. რეალური მაგალითი დღეიდან: ბოტებისგან დაცვის ჩართვა ორ საიტზე Cloudflare-ში.

აგენტმა მთელი ანგარიშის გასაღები არ გამოიყენა. მან გამოუშვა ტოკენი ერთ ზონაზე, მხოლოდ ბოტების მართვის უფლებებით, ერთი საათის ვადით, გააკეთა ცვლილება და ტოკენი finally ბლოკში გააუქმა. პირველი მცდელობა ჩავარდა: პარამეტრის წასაკითხად ზონის წაკითხვის უფლებაც იყო საჭირო. ტოკენი მაინც გაუქმდა, რადგან გაუქმება წარმატებაზე არ იყო დამოკიდებული. მიმდინარე მდგომარეობა ცვლილებამდე შეინახა, ერთხაზიან დაბრუნებასთან ერთად.

საიდუმლოებები არ ხვდება არაფერში, რაც მანქანას ტოვებს: არანაირი ტოკენი, შიდა ჰოსტი ან მისამართი ვებ-ძიებაში, ხოლო წვდომები git-ში დაშიფრულად ინახება და არა ჩატებში მიმოფანტული.

წესი 4: კლასტერმა ყველაფერი არ იცის

ჩემი ინფრასტრუქტურა ჰიბრიდულია: ნაწილი სერვისებისა Kubernetes-შია, ნაწილი ჩვეულებრივ VM-ებზე. კლასტერმა მხოლოდ საკუთარ თავზე იცის, ამიტომ აგენტს ეკრძალება დასკვნა „სერვისი მკვდარია“ კლასტერის მონაცემებით. ნული endpoint ან არარსებული Deployment ფაქტია კლასტერზე. შემოწმება არის DNS-ის შედარება ingress-ისა და ბალანსერის მისამართებთან, შემდეგ კი რეალური მოთხოვნა სერვისთან.

მომიჯნავე წესი ერთი „კინაღამ“ შემთხვევის შემდეგ გაჩნდა: ყველა kubeconfig კონტექსტს ერთი და იგივე სახელი აქვს, ამიტომ აგენტი კლასტერს API-ის მისამართითა და ნოდებით ცნობს და არა კონტექსტით.

წესი 5: გადაწყვეტილებები მიღების მომენტში იწერება

მნიშვნელოვანი გადაწყვეტილება მიღებისთანავე იღებს დათარიღებულ ჩანაწერს: რა აირჩიეს, რა ალტერნატივები იყო, რატომ, რა ღირს და რა პირობით გადაიხედება. ერთი თვის შემდეგ კითხვა ყოველთვის ასეა: „რატომ ავირჩიეთ X“ — და პასუხი ჟურნალში უნდა იყოს და არა ჩატის ისტორიაში.

სად შეცდა აგენტი

ცდება, და სწორედ შეზღუდვები იჭერს ამას. სამი მაგალითი ერთი დღიდან:

• არასწორი თარიღი გაფუჭებული კოდირების გამო. აგენტმა წაიკითხა გვერდი ძველ კირილიცურ კოდირებაში და პირველმა შეჯამებამ გამოქვეყნების არასწორი თვე დაასახელა. ხელახალმა ჩამოტვირთვამ და გადაკოდირებამ სტრუქტურირებულ მონაცემებში ნამდვილი თარიღი აჩვენა.
• თავდაჯერებული რჩევა, რომელიც მცდარი აღმოჩნდა. აგენტმა მირჩია LinkedIn-ში უნარის წაშლა, როგორც ნაგვის — ეს კი „Site Reliability Engineering“-ის ლოკალიზებული სახელი იყო. სრული სიის დანახვისთანავე შეასწორა.
• გეგმა, რომელიც ვერ იმუშავებდა. აგენტი აპირებდა ჩასმული სკრიპტის დაშვებას Content Security Policy-ში მისი ჰეშით. სამი პასუხის შემოწმებამ აჩვენა, რომ ჰეში ყოველ მოთხოვნაზე იცვლება, და იდეაზე უარი თქვეს, პოლიტიკის შესუსტების ნაცვლად.

არცერთი ეს შეცდომა არ დაიჭირეს იმიტომ, რომ მოდელი ჭკვიანია. ისინი დაიჭირეს იმიტომ, რომ ყოველი მტკიცება რეალურ სისტემასთან მოწმდება, სანამ მასზე რამე დამოკიდებული გახდება. ნდობას იძლევა შემოწმება და არა მოდელი.

მეორე აზრი სხვადასხვა მოდელისგან

რისკიანი ცვლილებებისა და გაუგებარი ინციდენტებისთვის მაქვს პატარა „საბჭო“: რამდენიმე მოდელი სხვადასხვა მწარმოებლისგან, თითოეულს თავისი ხედვით (პლატფორმა, აპლიკაცია, ქსელი, სკეპტიკოსი). ისინი კამათობენ, ერთმანეთს ჯვარედინად კითხავენ და ხმას აძლევენ, სანამ არავინ დაბლოკავს, შედეგად კი წერილობითი ანგარიშია, განსხვავებული აზრის შენარჩუნებით. ეს არ არის კენჭისყრა, რომელსაც ვემორჩილები, არამედ იაფი გზა იმ კითხვის საპოვნელად, რომელიც არ დამისვამს.

რას ცვლის და რას არა

აგენტი გამაძლიერებელია და არა შემცვლელი. დღე, რომელიც ადრე ერთი ამოცანა იყო, ახლა ჯაჭვია: საიტის რელიზი CI-ითა და Argo CD-ით, ანალიტიკის განხილვა, უსაფრთხოების პარამეტრი, პუბლიკაცია. მაგრამ ყველა გადაწყვეტილება ისევ ჩემია და პროდაქშენზე ფანჯრებისა და დამტკიცებების წესები არ იცვლება იმის გამო, რომ ხელები უფრო სწრაფი გახდა.

დასკვნები

• მიეცით აგენტს წერილობითი მეთოდი და გარემოების რუკები git-ში; ნუ დაეყრდნობით არც მის მეხსიერებას და არც თქვენსას.
• ჯერ მხოლოდ კითხვა და არანაირი ცვლილება ხილული დაბრუნების გარეშე.
• გამოუშვით ვიწრო, ხანმოკლე წვდომები ამოცანაზე და გააუქმეთ ისინი finally-ში.
• ნუ მისცემთ აგენტს უფლებას, სერვისზე დასკვნა მხოლოდ კლასტერით გააკეთოს.
• ჩაწერეთ გადაწყვეტილებები მიღების მომენტში.
• ელოდეთ შეცდომებს და დააპროექტეთ მათი დაჭერა: შემოწმება თავად არის შეზღუდვა.