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

მართული ოპერაციები

თქვენი ინფრასტრუქტურა ღამის სამზეც მუშაობს

დისტანციური NOC და SOC: მონიტორინგი, ინციდენტის ტრიაჟი, რეაგირება და ესკალაცია დოკუმენტირებული პროცედურებით — თქვენს გუნდთან ერთად ან მის ნაცვლად.

პრობლემა

24/7 ოპერირება შიდა გუნდით ძვირია და მყიფე

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

  • alert-ების ხმაური — რეალური ინციდენტი იკარგება
  • ესკალაციის გზა განუსაზღვრელია
  • ინციდენტის შემდეგ ანალიზი არ ტარდება
  • ცოდნა ერთ ადამიანზეა კონცენტრირებული

რას ვაწვდით

თქვენი ინფრასტრუქტურა ღამის სამზეც მუშაობს

მონიტორინგის საფუძველი

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

Runbook-ები

დოკუმენტირებული ნაბიჯები თითოეული ტიპური ინციდენტისთვის.

ესკალაციის მატრიცა

severity, პასუხისმგებელი, დროის სამიზნეები და საკონტაქტო არხები.

ცვლილებების კონტროლი

შეთანხმებული ფანჯრები, rollback გეგმა და ცვლილების ჟურნალი.

ანგარიშგება

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

უწყვეტი გაუმჯობესება

alert-ების დაზუსტება, ავტომატიზაცია და არქიტექტურული რეკომენდაციები.

არქიტექტურა

არქიტექტურა

  1. 01მონიტორინგიმეტრიკები, ლოგები, სინთეტიკა
    • Zabbix
    • Prometheus
    • Blackbox
  2. 02აღმოჩენაზღვრები და ანომალიები
    • Alertmanager
    • Grafana Alerts
  3. 03ტრიაჟიseverity, გავლენა, მფლობელი
    • Runbook
    • On-call
  4. 04რეაგირებალოკალიზაცია და აღდგენა
    • Change window
    • Rollback
  5. 05დახურვადადასტურება და ანგარიში
    • RCA
    • SLA report
  6. 06გაუმჯობესებაწესები, ავტომატიზაცია
    • Alert tuning
    • Runbook update
ინციდენტის სასიცოცხლო ციკლი — მონიტორინგიდან გაუმჯობესებამდე

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

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

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

დაბუნდოვნებული Grafana დაშბორდი upstream-ებისა და peering-ის ტრაფიკის ინდიკატორებით.

გამტარუნარიანობა და peering რეალურ დროში

თითოეული upstream და თითოეული peering ცალკე იზომება, გლობალური და ლოკალური მიმართულებების გაყოფით. capacity-ისა და peering-ის გადაწყვეტილება სწორედ ამ ხედვიდან მოდის — არა შეგრძნებიდან.

GrafanaZabbixper-peerIXP
ავტომატური BGP ანგარიში ოთხი ლოკაციიდან — თითო პრეფიქსზე დანაკარგი და latency, ბოლოს პრიორიტეტი.

Global BGP Report — ავტომატური, ყოველდღიური

ოთხი საერთაშორისო წერტილიდან (სოფია, აშშ, ამსტერდამი, ინდოეთი) იზომება ჩვენი ყოველი პრეფიქსის ხელმისაწვდომობა, დანაკარგი და latency. ანგარიშს ადამიანი არ ადგენს: სისტემა თვითონ აჯამებს 3-საათიან ფანჯარას 24-საათიან ბაზისთან, გამოყოფს პრობლემურ მიმართულებას და პრიორიტეტს თვითონ ანიჭებს — ამ კადრში P1 ინდოეთია, სადაც RTT 190 ms-ს აჭარბებს.

BGPpacket lossRTTautomated
დაბუნდოვნებული OpenPath NOC კონსოლი სერვისების მდგომარეობით, latency-ის გრაფიკებითა და ინციდენტების ლენტით.

OpenPath — ჩვენი საკუთარი NOC კონსოლი

ცოცხალი path-მონიტორინგი 15-წამიან განახლებაზე: latency და პაკეტების დანაკარგი თითოეულ სერვისამდე, მათ შორის ოპერატორებში განთავსებულ cache-სერვერებამდე. მარშრუტის ცვლილება ცალკე ინციდენტად აღირიცხება, ფილტრებით ASN-ის, ISP-ისა და კლიენტის მიხედვით. ეს ინსტრუმენტი ჩვენ დავწერეთ, რადგან მზა პროდუქტი ამ კითხვას არ პასუხობდა.

in-houselatency / losspath changeper-ASN
Telegram-ის პროფილის ბარათი AI აგენტისა, სახელად Pipi Jarvis.

გუნდის წევრი, რომელიც არ იძინებს

Pipi Jarvis იმავე არხში ზის, სადაც ცვლაში მყოფი ინჟინერი — ანგარიშებს და გაფრთხილებებს იქვე აქვეყნებს, კითხვაზე პასუხობს და შეთანხმებული უფლებების ფარგლებში მოქმედებს. ცალკე ინტერფეისი არ არსებობს: სადაც გუნდი უკვე მუშაობს, იქ არის.

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

სარეზერვო ასლები და აღდგენა

ვირტუალური და ფიზიკური სისტემების ცენტრალიზებული backup: დაცული მანქანების სტატუსი, საცავის მოხმარების დინამიკა და ცალკე სია იმ ჰოსტებისა, რომლებმაც რეპორტინგი შეწყვიტეს. სწორედ ეს ბოლო სია ჰქმნის განსხვავებას — backup, რომელსაც არავინ აკვირდება, backup არ არის.

VM backupretentionrestore testalerting
დაბუნდოვნებული FortiGate დაშბორდი: სესიების, მეხსიერებისა და გამტარუნარიანობის გრაფიკები, უსაფრთხოების ფაბრიკის სტატუსი.

Firewall — პოლიტიკები, სესიები და დატვირთვა

პროდაქშენში მომუშავე FortiGate: ათასობით ერთდროული სესია, SPU-ს დატვირთვა, უსაფრთხოების ფაბრიკის მდგომარეობა და ინტერფეისების გამტარუნარიანობა ერთ ეკრანზე. firewall ჩვენთვის ცალკე ყუთი არაა — ის მარშრუტიზაციასთან, სეგმენტაციასთან და ლოგირებასთან ერთად იგეგმება და მუშავდება, სერტიფიცირებული ინჟინრების მიერ.

FortiGateHAsegmentationIPsec
დაბუნდოვნებული 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

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

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

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

24/7 ქსელის მონიტორინგი

Proven

ჯგუფის საკუთარი ISP და დატაცენტრი უწყვეტ რეჟიმში ოპერირდება — იგივე პროცესები და ინსტრუმენტები.

  • Zabbix
  • Prometheus
  • Grafana

ინციდენტზე რეაგირება severity-ით

Proven
  • Runbooks
  • On-call rota

SOC — მოვლენების კორელაცია

Capability

SIEM წესები, აღმოჩენა და ინციდენტზე რეაგირების playbook-ები.

  • Wazuh
  • Graylog
  • OpenSearch

Co-managed რეჟიმი

Capability

თქვენი გუნდი ინარჩუნებს კონტროლს; ჩვენ ვფარავთ ცვლებს და ესკალაციას.

ITSM ინტეგრაცია

Capability

თქვენს ticketing სისტემასთან ორმხრივი სინქრონიზაცია.

  • Webhooks
  • REST API

Telegram / PagerDuty ესკალაცია

Proven
  • Telegram Bot API
  • Alertmanager

Path მონიტორინგი და დანაკარგის აღმოჩენა

Proven

latency და პაკეტების დანაკარგი თითოეულ კრიტიკულ სერვისამდე — ოპერატორებში განთავსებული cache-სერვერების ჩათვლით. ასე ჩანს, პრობლემა ჩვენს ქსელშია, ტრანზიტში თუ კონტენტის მიმწოდებელთან.

  • OpenPath
  • ICMP / TCP probes
  • per-ASN

პროცესი

პროცესი

  1. 01

    მონიტორინგი

  2. 02

    აღმოჩენა

  3. 03

    ტრიაჟი

  4. 04

    რეაგირება

  5. 05

    დახურვა

  6. 06

    გაუმჯობესება

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

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

მონიტორინგი
ZabbixLibreNMSPrometheusGrafanaBlackbox
საკუთარი ინსტრუმენტები
OpenPathnoc.com.ge
ლოგირება
GraylogOpenSearchLokiVector
უსაფრთხოება
WazuhFortiGateSuricata
alerting
AlertmanagerTelegramPagerDuty

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

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

Co-Managed

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

სრულად მართული

შეთანხმებულ საოპერაციო scope-ს მთლიანად ჩვენ ვფლობთ.

კრიტიკული ოპერაციები

24/7 მონიტორინგი, რეაგირება და ესკალაცია severity-ს მიხედვით.

რეტეინერი

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

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

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

ISP ღამის ცვლა

პროვაიდერი ფარავს სამუშაო საათებს, ჩვენ — ღამეს და შაბათ-კვირას.

ჰოსტინგის პლატფორმა

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

MSP-ს გაძლიერება

White-label NOC MSP-ის კლიენტებისთვის, მისივე ბრენდის ქვეშ.

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

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

როგორ იღებთ წვდომას ჩვენს ინფრასტრუქტურაზე?

მხოლოდ სახელობითი ანგარიშებით, MFA-თი, ლოგირებული სესიებით და შეთანხმებული სამუშაო ფანჯრებით. დეტალები — Trust Center-ში.

რა SLA-ს გვთავაზობთ?

SLA განისაზღვრება სერვის-პლანის მიხედვით: severity-ზე დაფუძნებული დადასტურების, რეაგირებისა და ესკალაციის სამიზნეები ფიქსირდება ხელშეკრულებაში.

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

დიახ. თუ Zabbix, Prometheus, Grafana ან SIEM უკვე გაქვთ, ვმუშაობთ მასზე; საჭიროების შემთხვევაში ვასწორებთ კონფიგურაციას.

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