მთავარ კონტენტზე გადასვლა

ავტომატიზაცია და ინტეგრაცია

სამუშაო, რომელიც მეორედ აღარავის უნდა გააკეთოს

Ansible, API ინტეგრაციები, ბილინგისა და provisioning-ის ავტომატიზაცია — რომ ერთი ცვლილება ორმოც მოწყობილობაზე ერთი ბრძანება იყოს და ორი სისტემა ერთსა და იმავე სიმართლეს ეუბნებოდეს.

პრობლემა

ერთი ცვლილება — ორმოცი ხელით შესვლა

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

  • იგივე ცვლილება ხელით მეორდება
  • სისტემები ერთმანეთს არ ესაუბრებიან
  • სიმართლის წყარო რამდენიმეა
  • შეცდომა მაშინ ჩანს, როცა კლიენტი დარეკავს

რას ვაწვდით

სამუშაო, რომელიც მეორედ აღარავის უნდა გააკეთოს

სიმართლის ერთი წყარო

ინვენტარი — მოწყობილობები, მისამართები, სერვისები — რომელზეც ავტომატიზაცია დაეყრდნობა.

Playbook-ები და შაბლონები

განმეორებადი ცვლილება ერთი გაშვებით, dry-run რეჟიმითა და შედეგის შემოწმებით.

ინტეგრაციების რუკა

რომელი სისტემა რომელს რას აწვდის, რა ფორმატით და რა სიხშირით.

API კონტრაქტები

დოკუმენტირებული ინტერფეისები ვერსიით — ინტეგრაცია ერთი მხარის ცვლილებაზე არ იშლება.

კონფიგურაციის ბექაპი და diff

ავტომატური ექსპორტი ვერსიების კონტროლში, შეტყობინებით ყოველ ცვლილებაზე.

შეცდომების დამუშავება

რა ხდება, როცა ინტეგრაცია ვარდება: გამეორება, რიგი და შეტყობინება ადამიანთან.

არქიტექტურა

არქიტექტურა

  1. 01ინვენტარისიმართლის ერთი წყარო
    • phpIPAM
    • Git
    • Inventory
  2. 02შაბლონისასურველი მდგომარეობა კოდად
    • Ansible
    • Terraform
    • Idempotency
  3. 03Dry-rundiff ცვლილებამდე, არა მის შემდეგ
    • Check mode
    • Diff alerts
  4. 04გაშვებაფლოტის მასშტაბით, ერთი ბრძანებით
  5. 05ინტეგრაციასისტემები კონტრაქტით ესაუბრებიან
    • REST API
    • Webhooks
    • RADIUS
  6. 06შემოწმებაშედეგი, გამეორება და შეტყობინება
    • Auto-discovery
    • Telegram
ერთი ცვლილება — ერთი გაშვება, ინვენტარიდან შემოწმებამდე

საოპერაციო ეკრანები

საოპერაციო ეკრანები

ეს კონკრეტული სისტემები ჯგუფის რეალურ ინფრასტრუქტურაზე მუშაობს — სქრინშოტები დამუშავებულია გამოქვეყნებამდე.

დაბუნდოვნებული ros-backup dashboard: მოწყობილობების დაფარვა, ბექაფების წარმატების მაჩვენებელი და ფლოტის ცხრილი კომპანიების მიხედვით.

ros-backup — კონფიგურაციების საცავი, თავად შეგროვებული

ქსელური მოწყობილობის კონფიგურაცია ის ერთადერთი ფაილია, რომლის დაკარგვის ფასიც გათიშული ქსელის საათებში იზომება. ros-backup მას ყოველდღიურად თავად აგროვებს SSH-ით — MikroTik RouterOS, Juniper JunOS, Cisco IOS და Arista EOS — და git-ის საცავში ინახავს, ვერსიებად, ხაზ-ხაზ შესადარებელი diff-ით. ინჟინერს აღარ სჭირდება თითოეულ მოწყობილობაზე ხელით შესვლა და კონფიგის კოპირება: ნებისმიერი როუტერის ნებისმიერი დღის კონფიგურაცია ორ კლიკშია — მაშინაც, როცა თავად მოწყობილობა უკვე აღარ ჩაირთვება. ეს ინსტრუმენტიც ჩვენ დავწერეთ.

in-houseRouterOS / JunOS / IOS / EOSgit-versioneddaily over SSH
Semaphore-ის Schedule გვერდი: ოთხი ჩართული სამუშაო სახელით, cron-გამოსახულებითა და შესაბამისი playbook-ით.

Ansible განრიგზე — Semaphore-ის Schedule

Ansible-ის playbook-ები ჩვენთან არა „ერთხელ გაშვებული სკრიპტებია“, არამედ განრიგზე დაყენებული სამუშაოები: latency-ის შემოწმება ღრუბლოვან VPS-ებამდე, DNS სერვერების შემოწმება, ანგარიში TVG-ის მხრიდან, VPS-ის კვირეული სამუშაო. თითოეულს თავისი cron-გამოსახულება და თავისი playbook აქვს, და შედეგი ყოველთვის ერთი და იგივეა — რადგან playbook აღწერს სასურველ მდგომარეობას, არა ნაბიჯებს.

AnsibleSemaphorecronplaybooks

შესაძლებლობები

შესაძლებლობები

თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.

Provisioning API-ს დონეზე

Proven

ჯგუფის ჰოსტინგში სერვერი მომხმარებლის მხრიდან იქმნება — ტარიფი, ბალანსი, შექმნა — ოპერატორის ჩარევის გარეშე.

  • REST API
  • cloud-init
  • Templates

ბილინგისა და ქსელის ინტეგრაცია

Proven

აბონენტების, ტარიფებისა და სერვისების მართვა ქსელურ provisioning-თან და AAA-სთან დაკავშირებული.

  • RADIUS
  • PostgreSQL
  • REST API

კონფიგურაციის ავტომატური ექსპორტი

Proven

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

  • Git
  • Automated export
  • Diff alerts

შეტყობინებები და ChatOps

Proven

alert-ები და საოპერაციო მოვლენები იმ არხში, სადაც ჯერზე მდგომი ინჟინერი ნამდვილად უყურებს.

  • Telegram
  • Webhooks
  • Grafana Alerts

Ansible ფლოტის მასშტაბით

Capability
  • Ansible
  • Inventory
  • Idempotency

ინფრასტრუქტურა კოდად

Capability
  • Terraform
  • GitOps
  • CI

მონიტორინგში ავტომატური აღრიცხვა

Capability

ახალი მოწყობილობა ან სერვისი ინვენტარიდან თვითონ ჩნდება მონიტორინგში — არა ხელით დამატებით.

  • Auto-discovery
  • Zabbix API
  • Prometheus SD

IPAM-ის ინტეგრაცია

Capability

მისამართების გამოყოფა და დაბრუნება პროცესის ნაწილი ხდება, არა ცალკე გასახსენებელი ნაბიჯი.

  • phpIPAM
  • REST API
  • Webhooks

პროცესი

პროცესი

  1. 01

    ინვენტარი

    რა გვაქვს და სად წერია დღეს.

  2. 02

    პრიორიტეტი

    რომელი ხელით სამუშაო ჯდება ყველაზე ძვირად.

  3. 03

    პირველი ავტომატიზაცია

    ერთი სცენარი, dry-run-ით და შემოწმებით.

  4. 04

    ინტეგრაცია

    სისტემები ერთმანეთს კონტრაქტით ესაუბრებიან.

  5. 05

    დაკვირვება

    ვარდნა ჩანს, გამეორება ლოგირდება.

  6. 06

    გადაცემა

    კოდი, დოკუმენტაცია და გუნდის ტრენინგი.

ტექნოლოგიური სტეკი

ტექნოლოგიური სტეკი

ავტომატიზაცია
AnsibleTerraformcloud-initCron
ინტეგრაცია
REST APIWebhooksMessage queueCSV/JSON
წყაროები
phpIPAMPostgreSQLGit
ქსელი
MikroTik APINETCONFSSHRADIUS
შეტყობინება
TelegramGrafana AlertsSMTP

თანამშრომლობის მოდელი

თანამშრომლობის მოდელი

პროექტი

ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.

რეტეინერი

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

Co-Managed

NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.

გამოყენების შემთხვევები

გამოყენების შემთხვევები

ერთი ცვლილება მთელ ფლოტზე

NTP, syslog ან წვდომის სია ორმოც მოწყობილობაზე უნდა შეიცვალოს. ვწერთ playbook-ს dry-run-ით და შედეგის შემოწმებით — ცვლილება ერთი გაშვებაა და კვალიც რჩება.

ბილინგი და ქსელი ერთმანეთს ეთანხმება

ახალი აბონენტი ბილინგში იქმნება და ქსელური წვდომაც იმავე მომენტში ეწერება — ცხრილის ხელით შევსება ქრება.

მონიტორინგი ჩამორჩება ინფრასტრუქტურას

ახალი სერვისები ჩნდება, მონიტორინგში კი ხელით ემატება — ან საერთოდ არა. ვაერთებთ ინვენტართან, რომ აღრიცხვა თვითონ ხდებოდეს.

ხშირი კითხვები

ხშირი კითხვები

საიდან ვიწყებთ?

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

ავტომატიზაცია სახიფათო არაა?

სახიფათო ხელით სამუშაოა — ის უჩუმრად განსხვავდება ყოველ გამეორებაზე. ჩვენი playbook-ები idempotent-ია, dry-run რეჟიმით და შედეგის შემოწმებით; მასშტაბზე გაშვებამდე ლაბორატორიაში მოწმდება.

ჩვენს არსებულ სისტემებთან იმუშავებთ?

დიახ. ინტეგრაცია ჩვეულებრივ იმ სისტემებთან ხდება, რომლებიც უკვე გაქვთ — ბილინგი, მონიტორინგი, ticketing, IPAM. თუ API არ აქვთ, ვნახულობთ რა ინტერფეისი არსებობს და ვწერთ ადაპტერს.

დაგვიწერეთ თქვენი ინფრასტრუქტურის შესახებ