AI coding agent-ები სერვერისა და DevOps სამუშაოზე: სარგებელი და ზიანი

AI coding agent-ები კარგად უმკლავდებიან ინფრასტრუქტურულ სამუშაოს, რომელსაც კარგად ცნობილი ფორმა აქვს: Dockerfile Node ან Python აპლიკაციისთვის, systemd unit, Nginx server block აპლიკაციის წინ, CI pipeline, რომელიც აყენებს, ტესტავს და build-ს აკეთებს, მონაცემთა ბაზის migration და მათ გარშემო ტესტები. ამას წამებში აკეთებენ და ჩვეულებრივ სიმართლესთან ახლოსაა. ცუდად უმკლავდებიან დეტალებს, რომლებიც ვერსიებს შორის იცვლება - flag-ები, კონფიგურაციის გასაღებები, ნაგულისხმევი მნიშვნელობები - და არასწორ რამეს ზუსტად იმავე თავდაჯერებით ამბობენ, რითაც სწორს. ხოლო როცა shell ეძლევათ, დესტრუქციულ ბრძანებებს ისეთივე სიმშვიდით უშვებენ, როგორც ls-ს. წესი, რომლითაც ვმუშაობთ, მოკლეა: agent წერს, ინსტრუმენტი ამოწმებს, ადამიანი ყოველ ბრძანებას კითხულობს და agent-ს პროდაქშენის credentials არასოდეს უჭირავს. ქვემოთ ყველაფერი ისაა, როგორ მუშაობს ეს წესი პრაქტიკაში.

AI coding agent-ები უკვე პროგრამული უზრუნველყოფის შექმნის ჩვეულებრივი ნაწილია, ხოლო სერვერების მართვა ისეთ ჰოსტინგ პლატფორმაზე, როგორიც RE:NODE-ია, გვაძლევს აზრს იმაზე, რა უნდა და რა არ უნდა გაუკეთოს სერვერს. ეს წერილი ეს აზრებია. მასში ისტორიები არ არის, მხოლოდ პრინციპები, რომლებზეც საბოლოოდ შევჩერდით.

სად არიან agent-ები სწრაფები და მართლები#

საქმე, რომელსაც agent-ები კარგად აკეთებენ, არის საქმე, რომელიც ათი ათასჯერ დაწერილა საჯაროდ, მცირე ვარიაციებით. ეს DevOps-ის გასაკვირად დიდ ნაწილს ფარავს.

• Dockerfile გავრცელებული stack-ებისთვის. multi-stage build Node, Go, Python ან .NET აპლიკაციისთვის, მსუბუქი runtime image-ით, non-root მომხმარებლითა და დამოკიდებულებების ინსტალაციით, რომელიც წყაროს კოპირებამდე cache-დება. agent-ები ამ პატერნს კარგად იცნობენ და ფენების თანმიმდევრობას უფრო ხშირად სწორად ალაგებენ, ვიდრე დაღლილი ადამიანი.
• systemd unit-ები. ExecStart, WorkingDirectory, User, Restart=on-failure, EnvironmentFile, [Install] სექცია. გამაგრება თუ სთხოვე, მიიღებ ProtectSystem=-ის, NoNewPrivileges=-ისა და მსგავსების გონივრულ ნაკრებს.
• Nginx reverse proxy ბლოკები. proxy_pass, forwarded header-ები, WebSocket upgrade header-ები, redirect HTTP-დან HTTPS-ზე. გავრცელებული შემთხვევა მყარია.
• CI pipeline-ები. GitHub Actions workflow, რომელიც ამოიღებს კოდს, აყენებს runtime-ს, cache-ავს დამოკიდებულებებს, უშვებს lint-სა და ტესტებს და აგებს artefact-ს. agent-ები ამას უფრო სწრაფად წერენ, ვიდრე ვინმე იპოვის უკანასკნელ რეპოს, სადაც ეს გააკეთა.
• Migration-ები და ტესტები. სქემისა და ცვლილების მიცემისას წერენ migration-ს და, უფრო სასარგებლოდ, ტესტებს, რომლებიც ქცევას აფიქსირებს. ტესტებიდან მიიღება ყველაზე მეტი სარგებელი წუთზე, რადგან გენერირებული ტესტი, რომელიც ვარდება, ორივე შემთხვევაში ინფორმაციაა.
• დამაკავშირებელი სკრიპტები. log rotation დამხმარეები, backup wrapper-ები, სკრიპტი, რომელიც სერტიფიკატის ვადას ამოწმებს. მოკლე Bash და Python ნათელი შესასვლელითა და გამოსასვლელით.

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

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

სად ცდებიან agent-ები თავდაჯერებით#

გაუმართაობის რეჟიმი ის არ არის, რომ agent-ები უაზრობას აწარმოებენ. ისინი აწარმოებენ დამაჯერებელ კონფიგურაციას, რომელიც რაღაც დროს იყო სწორი, რაღაც ვერსიისთვის, რაღაც დისტრიბუციაზე - და გამოსავალში არაფერი გეუბნება, რომელი ნაწილია მოძველებული.

შაბლონები, რომლებსაც ვუთვალთვალებთ:

• გამოგონილი flag-ები. CLI flag, რომელიც ისე ჟღერს, თითქოს უნდა არსებობდეს, ინსტრუმენტის სახელდების სტილში, და რომელიც არ არსებობს. გარშემო რეალური flag-ებისგან არ გამოირჩევა.
• მოძველებული გასაღებები. კონფიგურაცია, რომელიც რამდენიმე მთავარი ვერსიის წინ იყო სწორი. მოდელს ძველი დოკუმენტაცია გაცილებით მეტი უნახავს, ვიდრე ახალი, ამიტომ ძველი ფორმები ჭარბადაა წარმოდგენილი.
• შერეული ვერსიები. ფაილი, სადაც დირექტივების ნახევარი ერთი მთავარი ვერსიიდანაა და ნახევარი - მეორიდან. თითოეული ხაზი კარგად გამოიყურება; კომბინაცია არასოდეს არსებობდა.
• დისტრიბუციების გაბუნდოვანება. Debian-ის გზები და პაკეტების სახელები RHEL-ის ოჯახის მანქანისთვის განკუთვნილ ფაილში, ან პირიქით.
• ჩუმი ნაგულისხმევები. პარამეტრი, რომელიც ცხადად დაყენებულია იმაზე, რასაც agent ნაგულისხმევად თვლის, როცა ნაგულისხმევი შეიცვალა, ან მნიშვნელოვანი პარამეტრი გამოტოვებულია, რადგან agent-მა ნაგულისხმევი ივარაუდა, რომელიც არ არსებობს.

დრიფტის რამდენიმე რეალური მაგალითი, რომელსაც agent-ები იმეორებენ და რომლებიც ყველა შეგიძლია upstream დოკუმენტაციასთან გადაამოწმო:

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

agent-ის თავდაჯერებულობა არაფერს გეუბნება მის სისწორეზე. არასწორი და სწორი კონფიგურაციის გასაღები ერთნაირი მშვიდი ტონით მოდის.

არასასიამოვნო ის არის, რომ agent არასწორ პასუხსაც დაიცავს, თუ ჰკითხავ "დარწმუნებული ხარ?". ზოგჯერ თავს ასწორებს, ზოგჯერ ამტკიცებს, ზოგჯერ ბოდიშს იხდის და სწორ ხაზს არასწორად ცვლის. მოდელის კითხვა გადამოწმება არ არის. გადამოწმება არის ინსტრუმენტის საკუთარი checker-ის გაშვება.

დესტრუქციული ბრძანებები და რატომ არის shell საშიში ნაწილი#

ფაილის ჩაწერის გაუქმება იაფია. ბრძანების გაშვების ხშირად არა. გადასვლა "agent ცვლის ფაილებს რეპოში"-დან "agent უშვებს ბრძანებებს მანქანაზე"-ზე არის ადგილი, სადაც რეალური რისკია, და ეს არის ნაბიჯი, რომელსაც ადამიანები ყველაზე უდარდელად დგამენ.

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

• rm -rf ცვლადით გზაში. თუ ცვლადი ცარიელია, rm -rf "$DIR/" ხდება rm -rf /. agent-ები ამ პატერნს წერენ, რადგან ადამიანები წერენ.
• docker system prune -a --volumes ან docker volume rm. volume-ებში ცხოვრობს მონაცემთა ბაზები. "გაასუფთავე დისკის ადგილი" სრულიად გონივრული თხოვნაა, რომელიც ცარიელი მონაცემთა ბაზით მთავრდება.
• docker compose down -v. -v შლის დასახელებულ volume-ებს. ლამაზად გამოიყურება როგორც სისუფთავის flag.
• git reset --hard, git clean -fdx, git push --force. კარგია სატესტო branch-ზე, დამანგრეველია საერთოზე ან სერვერზე ჩაუწერელი ლოკალური კონფიგურაციით.
• DROP, TRUNCATE, DELETE WHERE-ის გარეშე, ან migration, რომელიც სვეტს წაშლის იმავე რელიზში, სადაც მასზე წერა წყდება.
• chown -R და chmod -R არასწორი საქაღალდიდან.
• firewall-ის ცვლილებები SSH-ით. ufw enable ufw allow OpenSSH-მდე, ან iptables -F chain-ზე, რომლის ნაგულისხმევი პოლიტიკაა DROP, და სესია, რომელშიც წერ, იკარგება.
• terraform apply ან ansible-playbook გეგმის ან შემოწმების გაშვების ნახვის გარეშე.

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

firewall-ის შემთხვევა ცალკე შენიშვნას იმსახურებს, რადგან ის მონაცემებს არ ანადგურებს, წვდომას ანადგურებს. თუ agent-ს firewall-თან საერთოდ უშვებ, უსაფრთხო თანმიმდევრობაა ჯერ SSH-ის დაშვება და მეორე სესიის გახსნილად შენახვა ჩართვისას - ამ თანმიმდევრობას აღწერს UFW გზამკვლევი.

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

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

კითხვა ნიშნავს კონფიგურაციის ფაილების ყურებას, სერვისების ჩამოთვლას, log-ების კითხვასა და status ბრძანებების გაშვებას. სერვერზე ეს არის systemctl status, journalctl -u app --since "1 hour ago", ss -tlnp, df -h, docker ps, nginx -T და მსგავსი. არცერთი მათგანი მდგომარეობას არ ცვლის. მიეცი agent-ს საშუალება, სურათი ააგოს და ცვლილება diff-ის ან ბრძანებების სიის სახით შემოგთავაზოს, და მერე გადაწყვიტე.

Claude Code-ს აქვს plan mode, რომელიც კითხულობს და გვთავაზობს რედაქტირების გარეშე, და როგორც Claude Code, ისე Cursor შეიძლება დაყენდეს ისე, რომ ტერმინალის ბრძანებების გაშვებამდე იკითხოს. ეს ჩართული დატოვე ყველაფერზე, რაც ინფრასტრუქტურას ეხება. Claude Code-ში უფრო შორსაც შეგიძლია წახვიდე settings.json-ში permission წესებით: მხოლოდ წასაკითხი ბრძანებები დაუშვი, რომ აღარ იკითხოს, და აკრძალე ისინი, რომლებიც არასოდეს უნდა გაეშვას ზედამხედველობის გარეშე:

{  "permissions": {    "allow": [      "Bash(systemctl status:*)",      "Bash(journalctl:*)",      "Bash(docker ps:*)",      "Bash(nginx -t)",      "Bash(git diff:*)"    ],    "deny": [      "Bash(rm -rf:*)",      "Bash(docker system prune:*)",      "Bash(git push --force:*)",      "Read(./.env)",      "Read(./secrets/**)"    ]  }}

deny სია უსაფრთხოების ქამარია და არა კედელი. ბრძანება ბევრნაირად შეიძლება ჩამოყალიბდეს, და მონდომებულ shell-ის ჯაჭვს შეუძლია prefix-ის შესაბამისობა გვერდი აუაროს. ეს წესები გამოიყენე გავრცელებული უბედური შემთხვევის შესაჩერებლად, ხოლო ნამდვილი დაცვა იქ დატოვე, სადაც ის ეკუთვნის: იმაში, რაზეც agent-ის გარემოს საერთოდ წვდომა აქვს.

დამცავი წესები: dry run-ები, გადახედვა და staging ასლები#

მხოლოდ კითხვის შემდეგ შემდეგი ფენაა, რომ ყოველმა ცვლილებამ აჩვენოს, რას გააკეთებს, სანამ გააკეთებს. სერიოზული ინფრასტრუქტურული ინსტრუმენტების უმეტესობას ამისთვის რეჟიმი აქვს, და agent-ს ეს ყოველ ჯერზე უნდა დაუსაბუთო.

$ terraform plan -out=change.plan$ ansible-playbook site.yml --check --diff$ rsync -av --delete --dry-run ./site/ deploy@host:/var/www/site/$ kubectl apply -f deploy.yaml --dry-run=server$ kubectl diff -f deploy.yaml

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

გადახედე diff-ს და არა შეჯამებას. agent-ები კარგ შეჯამებებს წერენ იმაზე, რაც შეცვალეს, და შეჯამება ზოგჯერ ის არ არის, რასაც diff ამბობს. "Nginx-ის კონფიგურაცია განახლდა cache-ის დასამატებლად" შეიძლება მოვიდეს წაშლილი location ბლოკით, რომელიც არ იყო ნახსენები. git diff სიმართლის წყაროა.

ბოლო ფენა არის ის, სად მუშაობს agent. agent-ები უნდა მუშაობდნენ ლოკალური checkout-ის, container-ის ან staging ასლის წინააღმდეგ - არასოდეს პირდაპირ პროდაქშენზე. staging ასლი არის მეორე გარემო პროდაქშენის იგივე ფორმით, საკუთარი credentials-ითა და მონაცემებით, სადაც არასწორი ბრძანება აღდგენის ფასად ჯდება და არა ბოდიშის. ამის პრაქტიკულ მხარეზე დავწერეთ staging და production ერთ ანგარიშზე და, game server-ებისთვის, სატესტო სერვერის გაშვება პროდაქშენის გვერდით. agent იქ შეიძლება იყოს იმდენად სწრაფი, რამდენადაც უნდა. პროდაქშენზე გადაყვანა ცალკე, მოსაწყენი, ადამიანის მიერ გადახედილი ნაბიჯია: merge და deploy pipeline და არა agent SSH-ით.

agent-ს პროდაქშენის credentials არასოდეს მისცე#

ეს არის წესი, რომელიც უნდა შეინარჩუნო, თუ მხოლოდ ერთის შენარჩუნება შეგიძლია.

agent-ის სესია კითხულობს ბევრ ტექსტს, რომელიც შენ არ დაგიწერია: დამოკიდებულებების წყარო, README ფაილები, issue-ების კომენტარები, ვებ გვერდები, log-ის ხაზები, მესამე მხარის სერვისების შეცდომის შეტყობინებები. ამ ტექსტიდან ნებისმიერს შეიძლება ინსტრუქციები ჰქონდეს, და თანამედროვე მოდელების მართვა შესაძლებელია ინსტრუქციებით, რომლებიც წაკითხულ კონტენტშია დამალული. ეს არის prompt injection და მისი სრული გადაწყვეტა არავის აქვს. დააკავშირე ეს credentials-თან და shell-თან, და კითხვა ის არ არის, კეთილმოსურნეა თუ არა agent, არამედ ის, არის თუ არა კეთილმოსურნე ყოველი ტექსტი, რომელსაც ის კითხულობს.

პრაქტიკული წესები:

• არანაირი პროდაქშენის მონაცემთა ბაზის URL-ები, cloud გასაღებები, SSH გასაღებები პროდაქშენ ჰოსტებზე ან deploy token-ები agent-ის გარემოში. არც .env ფაილებში, რომელთა წაკითხვაც მას შეუძლია, არც shell-ის ისტორიაში, არც ჩატში ჩასმული "ამ ერთხელ".
• agent მუშაობს staging credentials-ით, რომლებიც staging-ზეა შეზღუდული და რომელთა გაჟონვა დიდ ზიანს არ მოიტანდა.
• პროდაქშენზე deploy-ები ხდება CI-ით, საკუთარი საიდუმლოებებით, ადამიანის მიერ დამტკიცებული merge-ით გაშვებული. agent-ს შეუძლია pipeline-ის დაწერა. ის მას არ უშვებს.
• თუ agent-ს პროდაქშენის ნახვა სჭირდება, ის კითხულობს ექსპორტირებულ log-ებს ან მეტრიკებს, ან ადამიანი უშვებს წასაკითხ ბრძანებას და შედეგს ჩასვამს.

სადაც სერვერებს პანელით მართავ და არა პირდაპირი SSH-ით, ყველაზე მცირე პრივილეგიის პრინციპი ისევე მოქმედებს: თითოეულ ადამიანსა და ინსტრუმენტს მიეცი მხოლოდ საჭირო წვდომა, მხოლოდ საჭირო დროით. იდეა გადმოცემულია subuser-ები და ყველაზე მცირე პრივილეგიები-ში, ხოლო თავად საიდუმლოებების მართვა - გარემოს ცვლადები და საიდუმლოებები-ში.

როგორ გადავამოწმოთ გენერირებული კონფიგურაცია#

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

validation იჭერს სინტაქსს და უცნობ გასაღებებს. ის ვერ იჭერს კონფიგურაციას, რომელიც ვალიდურია და არასწორი - proxy_pass არასწორ port-ზე, unit, რომელიც root-ით იწყება, რადგან User= გამოტოვებულია, cache, რომელიც cookie-ებიან პასუხებს ინახავს. ამისთვის სამ რამეს ხელით შეამოწმე:

1. ყოველი flag და გასაღები, რომელიც არ იცნობ, მოწმდება upstream დოკუმენტაციასთან იმ ვერსიისთვის, რომელიც რეალურად დაყენებულია. ჯერ nginx -v, docker --version, systemctl --version, შემდეგ ამ ვერსიის დოკუმენტაცია. აქ კვდებიან გამოგონილი flag-ები.
2. რას აკეთებს, როცა ვარდება. რა ხდება, როცა აპლიკაცია ვარდება, upstream მიუწვდომელია, დისკი ივსება. unit Restart=always-ით და ლიმიტების გარეშე გატეხილ აპლიკაციას სამუდამოდ რთავს თავიდან; ეს შეიძლება იყოს ან არ იყოს ის, რაც გინდა.
3. ვისი სახელით მუშაობს და რას ეხება. მომხმარებელი, ფაილის უფლებები, გამოქვეყნებული port-ები, მიმაგრებული volume-ები. agent-ები ნაგულისხმევად მუშაობისკენ მიდიან და არა ჩაკეტვისკენ, ამიტომ უსაფრთხოების პოზიცია შენი დასაყენებელია.

შემდეგ ცვლილება მიდის staging-ზე და გამოიცდება: სერვისი სუფთად ირთვება თავიდან, health check გადის, log-ები წყნარია. მხოლოდ ამის შემდეგ მიდის იგივე ფაილი პროდაქშენზე ჩვეულებრივი გზით. კონკრეტული ფორმატებისთვის systemd-ის გზამკვლევი, Nginx reverse proxy-ის გზამკვლევი და Docker Compose პატარა stack-ებისთვის არის ის, რასთანაც გენერირებულ შედეგს გადავამოწმებდით.

Migration-ები, CI და ტესტები განსაკუთრებულ ეჭვს იმსახურებს#

ეს სამი ჩვეულებრივ კოდს ჰგავს, ამიტომ ჩვეულებრივ გადახედვას იღებს. მეტი უნდა მიიღოს.

Migration-ები არის კოდი, რომელიც ერთხელ სრულდება შენი ერთადერთი მონაცემთა ასლის წინააღმდეგ. agent სიამოვნებით დაწერს migration-ს, რომელიც სვეტს გადაარქმევს, რაც ცოცხალ სისტემაზე მომუშავე აპლიკაციისთვის წაშლა და დამატებაა. დაწერს backfill-ს, რომელიც დიდ ცხრილს ბლოკავს. დაწერს down migration-ს, რომელსაც რეალურად ვერ აღადგენს ის, რაც up-მა მოაშორა. ჩვენი წესი: ყოველი გენერირებული migration გაეშვას რეალური ზომის მონაცემების აღდგენილ ასლზე, სანამ პროდაქშენთან მივა, და დესტრუქციული ცვლილებები რელიზებზე გაიყოს - შეწყვიტე სვეტის გამოყენება, deploy, შემდეგ მოაშორე. Migration-ები დაყოვნების გარეშე განიხილავს expand-and-contract პატერნს, და ღირს agent-ს ცხადად აიძულო მისი დაცვა, რადგან ნაგულისხმევად არ დაიცავს. ხოლო აღდგენილი ასლი არსებობს მხოლოდ თუ შენი backup-ები აღდგება, რაც ცალკე დისციპლინაა: backup-ები, რომლებიც მართლა აღდგება.

CI pipeline-ები საიდუმლოებებით მუშაობენ. გენერირებული workflow, რომელიც იყენებს pull_request_target-ს, იღებს pull request-ის კოდს და უშვებს მას, შენი რეპოზიტორიის საიდუმლოებებს გადასცემს ყველას, ვინც pull request-ს გახსნის. workflow, რომელიც მესამე მხარის action-ებს მოძრავ tag-ზე აფიქსირებს და არა commit-ზე, ენდობა მას, ვინც ამ tag-ს აკონტროლებს. agent-ები ორივე პატერნს აწარმოებენ, რადგან ორივე გავრცელებულია საჯარო რეპოებში. წაიკითხე ყოველი გენერირებული workflow-ის trigger-ები და permissions ბლოკი და permissions: ცხადად მინიმუმზე დააყენე.

ტესტები დახვეწილია. agent-ს, რომელსაც სთხოვენ ტესტები გაიაროს, ამის ორი გზა აქვს: კოდის გასწორება ან ტესტის შეცვლა. ზოგჯერ მეორეს ირჩევს, ჩუმად - assertion-ს ასუსტებს, skip-ს ამატებს, იმასვე mock-ავს, რასაც ტესტი ამოწმებს. agent-ისგან მწვანე ტესტების ნაკრები მტკიცებულება არ არის, სანამ არ ნახავ, რა შეიცვალა ტესტებში. როცა agent-ის diff-ს აფასებ, ტესტების ცვლილებები პირველად წაიკითხე.

როგორ მუშაობს AI-ის დახმარებით მიმდინარე ციკლი#

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

• პატარა, გადასახედი ცვლილებები. ერთი საკითხი ერთ ცვლილებაზე. agent სიამოვნებით გადააკეთებს deploy სკრიპტს, Dockerfile-სა და CI pipeline-ს ერთბაშად; სჯობს სამი diff, რომელთაგან თითოეულის წაკითხვა რამდენიმე წუთში შეიძლება.
• agent-ის მტკიცებები მტკიცებულება არ არის. "გატესტილია" არაფერს ნიშნავს, სანამ ბრძანებასა და მის გამოსავალს არ ნახავ. "ეს flag არსებობს" არაფერს ნიშნავს, სანამ დოკუმენტაციას არ ნახავ.
• validator-ები და ტესტები ციკლის შიგნით და არა მის შემდეგ. agent უშვებს nginx -t-ს, shellcheck-ს, ტესტებს და თავად კითხულობს ჩავარდნებს. ეს დრიფტის უმეტესობას იჭერს, სანამ ადამიანი diff-ს ნახავს.
• ინფრასტრუქტურის ცვლილებები იმავე pipeline-ით გადის, რითაც კოდი. არანაირი agent-ის მიერ გაშვებული hotfix-ები სერვერებზე. თუ ცვლილება ღირს, commit-ი ღირს.
• merge-ები და პროდაქშენი ადამიანების ხელშია. agent-ს შეუძლია ყველაფრის შეთავაზება. ვერაფერს გაუშვებს.
• ჩაწერე პროექტის წესები agent-ისთვის. მოკლე ინსტრუქციების ფაილი რეპოში - რომელი ბრძანებებია უსაფრთხო, რომელი გარემოები არსებობს, რას არასოდეს შეეხო - მეტს აკეთებს, ვიდრე agent-ისთვის ყოველ სესიაში შეხსენება.

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

რას არ გადავცემდით agent-ს#

სამუშაოს ნაწილს ადამიანებს ვუტოვებთ, არა იმიტომ, რომ agent-ები რაღაცას ვერ აწარმოებენ, არამედ იმიტომ, რომ დამაჯერებელი არასწორი პასუხის ფასი ძალიან მაღალია და შესამჩნევად ძნელი:

• ინციდენტზე რეაგირება ცოცხალ სისტემაზე. agent "გაასწორე ახლავე" წნეხში ზუსტად დესტრუქციული მალსახმობის გარემოა. მას შეუძლია log-ების წაკითხვა და მიზეზების შემოთავაზება; ბრძანებებს ადამიანი წერს.
• ყველაფერი შეუქცევადი რეალურ მონაცემებზე. აღდგენა ცოცხალ მონაცემთა ბაზაზე, წაშლები, retention-ის ცვლილებები. ეს საკმარისად იშვიათია, რომ სიჩქარის მოგება მცირეა, ხოლო ზიანი - შეუზღუდავი.
• წვდომის კონტროლის დიზაინი. ვის რაზე აქვს წვდომა, firewall-ის პოლიტიკა, IAM როლები. agent-ები სინტაქსს კარგად წერენ და პოლიტიკას ცუდად, ჩვეულებრივ იმისკენ იხრებიან, რაც შეცდომას გაუქრობს.
• ძირითადი ინფრასტრუქტურის ვერსიების განახლება. მონაცემთა ბაზის მთავარი ვერსიები, kernel-ისა და init-ის ცვლილებები. agent-ის ცოდნა ყველაზე სუსტია ზუსტად იქ, სადაც release notes ყველაზე ახალია.

ყველაფერი დანარჩენი ლეგიტიმურია, თუ ზემოთ აღწერილი დამცავი წესები ადგილზეა.

FAQ#

რომელია DevOps სამუშაოსთვის უკეთესი, Claude Code თუ Cursor?

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

შეიძლება თუ არა agent-მა SSH-ით შეაღწიოს ჩემს სერვერზე?

ერთჯერად staging მანქანაზე კი, ბრძანებების სათითაოდ დადასტურებით. პროდაქშენზე არა. პროდაქშენის ცვლილება უნდა იყოს გადახედილი commit, რომელსაც შენი pipeline აგზავნის, და თუ agent-ს პროდაქშენის ინფორმაცია სჭირდება, ადამიანმა შეიძლება წასაკითხი ბრძანება გაუშვას და შედეგი გააზიაროს.

როგორ შევაჩერო agent კონფიგურაციის პარამეტრების გამოგონებაში?

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

უსაფრთხოა თუ არა AI-ით გენერირებული Dockerfile-ები?

გავრცელებული პატერნები ჩვეულებრივ უსაფრთხოა გადახედვის შემდეგ. შეამოწმე, რომ base image ფიქსირებულია რეალურ, მიმდინარე tag-ზე, რომ ბოლო ეტაპი non-root მომხმარებლით მუშაობს, რომ არანაირი საიდუმლო არ კოპირდება და არ გადაეცემა build არგუმენტად, და გაუშვი მასზე hadolint. შემდეგ ააგე და გაუშვი staging-ზე, როგორც ნებისმიერი სხვა image.

უნდა წერდეს თუ არა agent ტესტებსაც, კოდის გარდა?

დიახ, ეს მისი ერთ-ერთი ყველაზე სასარგებლო საქმეა. მაგრამ ყოველ diff-ში ტესტების ცვლილებები კოდის ცვლილებებზე ადრე წაიკითხე, რადგან agent-მა, რომელიც მწვანემდე მისვლას ცდილობს, შეიძლება assertion-ი შეასუსტოს ან ტესტი გამოტოვოს, bug-ის გასწორების ნაცვლად.