AI-მორიგე ერთი სერვერისთვის: რას ვანდობდი Grafana AI-ს და რას ვამოწმებ თავად

Grafana-მ ერთ კვირაში გამოუშვა აგენტები, რომლებიც სერვისს აკვირდებიან და ინციდენტებს იძიებენ, და კიდევ სენდბოქსი, სადაც აგენტი კოდში შესწორებას ამზადებს. CNCF-მა გაზომა, რამდენად სწრაფად პოულობს აგენტი მიზეზს, თუ მას კონტექსტს მისცემ. Percona-მ გამოაქვეყნა ინსტრუმენტი, რომელიც კითხვას „ხუთშაბათს რა მოხდა?“ პასუხობს. ბიზნესის მფლობელისთვის ეს ერთი და იგივე კითხვაა: ვინ მორიგეობს ღამით თქვენს სერვერთან და რისი გაკეთების უფლება აქვს მას თქვენს გარეშე.

რა გამოვიდა

Grafana Labs-მა 20 ოქტომბერს Grafana Assistant-ის სამი ნაწილი გამოაცხადა. Watchers მუდმივი აგენტებია: სიტყვებით აღწერთ, რა გაწუხებთ სერვისში, Assistant კი ტელემეტრიის ისტორიიდან საბაზისო ხაზს არჩევს და შემდეგ სიგნალებს პერიოდულად ამოწმებს. თუ კრიტიკულს იპოვის, თავად უშვებს Investigations-ს, აგენტს, რომელიც მეტრიკებსა და ლოგებში იძიებს. Managed Sandboxes ჯერ საჯარო preview-შია: აგენტი ცალკე ღრუბლოვან გარემოში იღებს რეპოზიტორიის კოდსა და ცოცხალ ტელემეტრიას და ამზადებს pull request-ს აღწერით, რა შეიცვალა, რატომ და რომელი შემოწმებები გაიარა. Grafana ხაზს უსვამს: აღდგენის დადასტურება პროდაქშენში და გადაწყვეტილება, რა გაეშვას, გუნდს რჩება.

CNCF-მა 21 ოქტომბერს გამოაქვეყნა გაზომვა, რომელიც ყველა ანონსზე მეტად მომეწონა. ერთმა და იმავე აგენტმა, Claude Code-მა, ერთი მოდელით ორჯერ გაიარა ღია ბენჩმარკ SREGym-ის 50 გაფუჭებული Kubernetes-კლასტერი. პირველად ჩვეულებრივი shell-ითა და kubectl-ით, მეორედ მხოლოდ წაკითხვის ინსტრუმენტებით, რომლებიც მაშინვე იძლევა მიმდინარე ჩავარდნების სიას, ცვლილებების ისტორიასა და შეცდომების ლოგებს. სიზუსტე თითქმის არ შეცვლილა: 45 სწორი დიაგნოზი პირველად და 46 მეორედ. შეიცვალა დრო: საშუალოდ 191 წამი და 64 წამი, ხოლო ორ წუთში სწორი პასუხი შემთხვევების 60%-ში და 86%-ში. ავტორები წერენ, რომ ინსტრუმენტები მათი საკუთარია და რომ ორივე ვარიანტი ერთსა და იმავე სამ ჩავარდნაზე შეცდა.

Grafana Labs-მა 14 ოქტომბერს აღწერა ინციდენტის გზა Grafana Cloud IRM-ში: გამოძახების გვერდი აჩვენებს სერვისსა და განგაშების ისტორიას, Slack-იდან შეგიძლიათ Assistant-ს ჰკითხოთ, კიდევ რა იწვის, ხოლო გამოძიება Assistant Workspace-ში ხელით სწორდება: შეიძლება ჰიპოთეზის დამატება, უარყოფილის მონიშვნა და წყაროების ნახვა.

Percona-მ 16 ოქტომბერს აჩვენა mongo-health, ღია ინსტრუმენტი Apache 2.0 ლიცენზიით. ყოველი mongod წამში ერთხელ თავის მეტრიკებს diagnostic.data-ში წერს, მაგრამ Atlas M10-ზე რეალური სამუშაო დატვირთვისას ეს ფაილები ორიდან ხუთ დღემდე ძლებს. mongo-health მათ სამ თვეს ინახავს, საათში ერთხელ 68 შემოწმებას ატარებს და კლასტერზე ერთ ვერდიქტს იძლევა. ერთ მაგალითში ინდექსის გარეშე მოთხოვნა ყოველ დაბრუნებულ დოკუმენტზე დაახლოებით 10 მილიონ დოკუმენტს კითხულობდა. Percona თავად წერს, რომ ეს მონიტორინგს არ ცვლის: საათში ერთხელ კითხულობს და არავის აღვიძებს.

Grafana Labs-მა 19 ოქტომბერს გაგვიზიარა, როგორ აუმჯობესებდა თავად Assistant-ს: დაახლოებით 10 კვირაში დეშბორდების რეჟიმში შეცდომების წილი 2,47%-დან 0,65%-მდე შემცირდა, დაყოვნება 95-ე პერცენტილზე 63-დან 28,8 წამამდე, ხოლო მოთხოვნის ღირებულება 18%-ით.

რატომ სჭირდება ეს ერთსერვერიან ბიზნესს

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

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

როგორ მაქვს ეს მოწყობილი

აშშ-ის PDR-კომპანიაში 2021 წლიდან ტექნიკური პარტნიორი ვარ და ინფრასტრუქტურას თავად ვაკვირდები: სერვერი Debian-ზე Google Cloud-ში, MariaDB, VPN, ტელეფონია საკუთარ PBX-ზე. 2022 წლიდან, როცა საკუთარი სერვერი გაჩნდა, სერიოზული ჩავარდნა, რომელიც აღდგენას მოითხოვდა, არ ყოფილა.

ჰიდროპონიკურ ფერმაში, რომელთანაც 2023 წლიდან ვმუშაობ, ერთ ქსელშია 25 კონტროლერი 2 ობიექტზე, Debian სერვერი Google Cloud-ში და MariaDB ბაზა. აქტიურ დეველოპმენტს იქ ახლა არ ვაწარმოებ, მხარდაჭერა კი საკმაოდ აქტიურია: განახლებები, გამართვა, პრობლემების გარჩევა, როცა ჩნდება. სწორედ აქ მჭირდება მორიგე, რომელიც ღამით კონტექსტს შეაგროვებს.

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

რას გავაკეთებდი

ისტორიას ნაგულისხმევ ვადაზე დიდხანს შევინახავდი: მეტრიკებსა და ლოგებს რამდენიმე კვირის მანძილზე.

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

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

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

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

დაკავშირებული მასალები

სერვერზე, როგორც სისტემის ცენტრზე, ვწერდი სტატიაში სერვერი: მონაცემი, წვდომა და პროცესის კოორდინაცია. მიმართულება: ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შეიძლება. ქეისები: PDR-კომპანიის ტექნიკური პარტნიორი 2021 წლიდან და ჰიდროპონიკური ფერმა 25 კონტროლერით. სხვა მიმოხილვებიდან: რამდენი დაკვირვებადობა სჭირდება სისტემას ერთ სერვერზე, ბექაპი, რომელიც არავის აღუდგენია და რის უფლებას ვაძლევ AI-აგენტს პროდაქშენ სერვერზე. ადრე ვწერდი დაკვირვებადობის გრაფსა და შემოწმებად ჰიპოთეზებზე. თუ გაქვთ სერვერი, რომელსაც ღამით არავინ უყურებს, მომიყევით, რა მუშაობს მასზე და როგორ იგებთ ახლა პრობლემების შესახებ. ამოცანის განხილვა.