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

ინჟინერია

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

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

პრობლემა

პროექტი დამთავრდა, პასუხისმგებლობა შედეგზე — არ დაწყებულა

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

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

რას ვაწვდით

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

აუდიტი და არსებული მდგომარეობა

ტოპოლოგია, კონფიგურაციები, SPOF-ები, ლიცენზიები და ტექნიკური ვალი — ერთ დოკუმენტში, პრიორიტეტებით.

სამიზნე დიზაინი

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

ვალიდირებული გეგმა

მიგრაცია და rollback ლაბორატორიაში გატესტილი, სამუშაო ფანჯრებად დაყოფილი.

დანერგვა

ეტაპობრივად, თითოეული ეტაპის მიღების კრიტერიუმით.

დოკუმენტაცია და runbook-ები

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

გადაცემა და ტრენინგი

თქვენი ინჟინრები ცვლილებას თვითონ ატარებენ; ჩვენ ვრჩებით რეტეინერზე, თუ ეს გჭირდებათ.

არქიტექტურა

არქიტექტურა

  1. 01აუდიტიტოპოლოგია, SPOF-ები და ტექნიკური ვალი
  2. 02დიზაინიალტერნატივები და თითოეულის ფასი
  3. 03ვალიდაციამიგრაცია და rollback ლაბორატორიაში
    • EVE-NG
    • Rollback test
  4. 04დანერგვაეტაპებად, მიღების კრიტერიუმებით
  5. 05დოკუმენტაციასქემები, მისამართების გეგმა, runbook-ები
  6. 06გადაცემათქვენი გუნდი ცვლილებას თვითონ ატარებს
საინჟინრო პროექტის გზა — აუდიტით იწყება, გადაცემით მთავრდება

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

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

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

დაბუნდოვნებული Proxmox VE ინტერფეისი კლასტერის კვანძებით, კონტეინერებითა და რესურსების მაჩვენებლებით.

ვირტუალიზაციის კლასტერი

მრავალკვანძიანი Proxmox კლასტერი: KVM ვირტუალური მანქანები და LXC კონტეინერები, NFS/HA საცავი, ცალკე backup-NAS და მიგრირებული ESXi ჰოსტები. ეს საიტიც ამ კლასტერზე მუშაობს — კონტეინერში, იმავე ინფრასტრუქტურაზე, რომელსაც ვყიდით.

Proxmox VEKVM / LXCHA storageESXi migration
დაბუნდოვნებული Proxmox Datacenter Manager — კვანძების, ვირტუალური მანქანების, კონტეინერებისა და backup სერვერების აგრეგირებული მდგომარეობა.

8 კლასტერი ერთი ინტერფეისიდან

Proxmox Datacenter Manager აერთიანებს ერთმანეთისგან დამოუკიდებელ Proxmox VE კლასტერებს ერთ სივრცეში. ჩვენს ინფრასტრუქტურაში ის 8 კლასტერს მართავს — სხვადასხვა ფიზიკურ ლოკაციაზე, მათგან 3 საქართველოს ფარგლებს გარეთ. ეკრანზე ჩანს მასშტაბიც: 211 კვანძი ონლაინ, 1480 ვირტუალური მანქანა და 127 კონტეინერი — ერთი ხედით, ერთი პროცედურით.

Proxmoxmulti-clustermulti-sitePBS
დაბუნდოვნებული vSphere Client — ვირტუალური მანქანების ინვენტარი და ერთი მანქანის რესურსების მაჩვენებლები.

vSphere — კლასტერი, ჰოსტები და სამუშაო დატვირთვები

vCenter რამდენიმე ESXi ჰოსტით და მათზე განთავსებული სერვისებით: ვებ, ბილინგი, დომენის კონტროლერი, backup აგენტები. ეს არის ის გარემო, სადაც VMware და Proxmox ერთდროულად ცხოვრობს — ნაწილი ჯერ კიდევ vSphere-ზეა, ნაწილი უკვე მიგრირებულია. ორივეს ერთი გუნდი ოპერირებს, ერთი backup-პოლიტიკით.

vSphereESXivCentermigration
დაბუნდოვნებული TrueNAS ინტერფეისი საცავის პულებითა და დისკების მდგომარეობით.

საცავი — ZFS პულები და რეპლიკაცია

ZFS საცავი RAIDZ2 ტოპოლოგიაზე — 12 დისკი ერთ vdev-ში, ~33 TiB სასარგებლო მოცულობა, ECC მეხსიერება და მისი დიდი ნაწილი ZFS ქეშად. აქვე ჩანს ის, რაც მთავარია: დისკები შეცდომებით — 0, scrub და scan შეცდომების გარეშე. ვირტუალიზაციის კლასტერისა და backup-ის ქვეშ სწორედ ეს ფენა დგას.

TrueNASZFSRAIDZ2ECC
ძლიერად დაბუნდოვნებული ბილინგის სისტემის ეკრანი აბონენტების სიით — პერსონალური მონაცემები წაკითხვადი არ არის.

ISP ბილინგი და აბონენტების მართვა

აბონენტის სასიცოცხლო ციკლი ერთ სისტემაში: ტარიფები, ბალანსები, სერვისები (ინტერნეტი, Wi-Fi, IPTV), სტატუსები, SMS შეტყობინებები, ლოგები და ფინანსური რეპორტები — provisioning-თან ინტეგრირებული. სისტემა ჩვენი დაწერილია და რეალურ ISP-ს ემსახურება.

in-housebillingprovisioningIPTV
phpIPAM-ის დაშბორდი — subnet-ების, VLAN-ების და მისამართების აგრეგირებული სტატისტიკა და გამოყენების დიაგრამები.

IPAM — მისამართების სივრცე ერთ სისტემაში

მოქმედი phpIPAM დანერგვა: subnet-ების იერარქია, VLAN დომენები, VRF-ები, მოწყობილობები და ლოკაციები ერთ, ძებნად ბაზაში. საჯაროდ მხოლოდ აგრეგირებული სტატისტიკა რჩება — კლიენტების სახელები, კონკრეტული subnet-ები და ლოკაციები ეკრანზე არ ჩანს და არც უნდა ჩანდეს.

phpIPAMIPv4 / IPv6VLANVRF
დაბუნდოვნებული EVE-NG ტოპოლოგია როუტერების, სვიჩების, peering-ებისა და მართვის ქსელის კავშირებით.

ციფრული ასლი — ლაბორატორია პროდაქშენამდე

რეალური Network OS-ების ტოპოლოგია: სასაზღვრო როუტერები, IXP და CDN peering-ები, აგრეგაციის დონე, VLAN-ები და მართვის ქსელი — პროდაქშენის ასლი ლაბორატორიაში. მიგრაცია, ავარია და rollback ჯერ აქ სრულდება; მხოლოდ შემდეგ ეხება ვინმე ცოცხალ ქსელს.

EVE-NGIOS XRBGPpre-production

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

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

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

BGP და multi-homed edge

Proven
  • BGP
  • OSPF
  • RPKI

MPLS core და L3VPN

Capability
  • MPLS
  • MP-BGP
  • L3VPN

ვირტუალიზაციის კლასტერები

Proven
  • KVM
  • Proxmox VE
  • VMware

EVPN-VXLAN fabric

Capability
  • Arista
  • Cumulus
  • FRR

Ceph / ZFS საცავი

Capability
  • Ceph
  • ZFS
  • NVMe

ავტომატიზაცია და IaC

Capability
  • Ansible
  • Terraform
  • GitOps

შიდა პორტალები და API-ები

Proven

ჰოსტინგის მართვის პანელი საათობრივი ბილინგითა და provisioning-ის ავტომატიზაციით — მუშა პროდუქტი, არა პროტოტიპი.

  • Next.js
  • PostgreSQL
  • REST

საკუთარი საოპერაციო ინსტრუმენტები

Proven

როცა მზა პროდუქტი კითხვას არ პასუხობს, ვწერთ საკუთარს: NOC კონსოლი ცოცხალი path-მონიტორინგით და noc.com.ge-ს 33 დიაგნოსტიკური ინსტრუმენტი — ორივე ჩვენივე ქსელზე ყოველდღიურ გამოყენებაშია.

  • OpenPath
  • noc.com.ge
  • PHP / TypeScript

პროცესი

პროცესი

  1. 01

    აუდიტი

  2. 02

    დიზაინი

  3. 03

    ვალიდაცია

  4. 04

    დანერგვა

  5. 05

    დოკუმენტაცია

  6. 06

    გადაცემა

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

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

მარშრუტიზაცია და კომუტაცია
CiscoJuniperMikroTikAristaFRR
ვირტუალიზაცია
VMware vSphereProxmox VEKVMLXC
საცავი
TrueNASZFSNFSiSCSI
ავტომატიზაცია
AnsibleTerraformcloud-initGit
შემუშავება
TypeScriptNext.jsPHPPostgreSQLREST API
ვალიდაცია და მონიტორინგი
EVE-NGZabbixPrometheusGrafanaLibreNMS

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

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

პროექტი

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

რეტეინერი

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

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

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

მიგრაცია ვადის ქვეშ

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

ორი ქსელი ერთდება

შერწყმის ან შესყიდვის შემდეგ მისამართები ერთმანეთს ფარავს, VLAN-ების ნუმერაცია განსხვავდება და ორივე მხარეს თავისი პროცედურები აქვს. ვქმნით ერთიან გეგმას და ვაერთიანებთ ისე, რომ სერვისი არ გაჩერდეს.

შიდა გუნდი ზრდას ვერ აუდის

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

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

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

ვენდორზე გვაბამთ?

არა. პროდაქშენში ვოპერირებთ Cisco-ს, Juniper-ს, MikroTik-ს, Arista-ს, VMware-სა და Proxmox-ს — არჩევანს აუდიტის შემდეგ ვამბობთ, არსებული აღჭურვილობის, ბიუჯეტისა და თქვენი გუნდის გამოცდილების მიხედვით.

მხოლოდ დიზაინს აკეთებთ თუ დანერგვასაც?

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

პროექტის შემდეგ რჩებით?

როგორც გირჩევნიათ: მხოლოდ გადაცემა, ყოველთვიური საინჟინრო საათები, co-managed მოდელი, ან სრულად მართული ოპერაცია. სამივე ვარიანტში დოკუმენტაცია თქვენია.

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