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

პროგრამული უზრუნველყოფის შემუშავება

პროგრამა, რომელსაც ის წერს, ვინც მას მერე თვითონ ოპერირებს

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

ესაუბრეთ ინჟინერსიხილეთ ჩვენი ინსტრუმენტები

პრობლემა

ან ყიდულობ პროდუქტს, რომელიც შენს პროცესს არ იმეორებს, ან ცხრილს ეჯაჯგურები

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

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

რას ვაწვდით

პროგრამა, რომელსაც ის წერს, ვინც მას მერე თვითონ ოპერირებს

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

NOC-ის ყოველდღიური ამოცანები ინტერფეისში: მდგომარეობა, ინციდენტები, დიაგნოსტიკა.

ბილინგი და provisioning

აბონენტები, ტარიფები, ბალანსები და სერვისების ჩართვა — ქსელთან ინტეგრირებული.

კლიენტის პორტალები

self-service: მოხმარება, ანგარიშები, განაცხადები და საკუთარი გრაფიკები.

ინტეგრაციები

API-ები ბილინგს, მონიტორინგს, IPAM-სა და ticketing-ს შორის — ხელით გადატანის ნაცვლად.

დაშბორდები რეალურ მონაცემებზე

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

გადაცემა და მხარდაჭერა

კოდი, დოკუმენტაცია და deploy-ის პროცედურა თქვენს მხარეს რჩება.

არქიტექტურა

არქიტექტურა

  1. 01პროცესის აღწერაროგორ კეთდება ახლა და სად იკარგება დრო
  2. 02სამუშაო ვერსიამცირე გამოსაყენებელი ნაწილი, არა სრული სპეციფიკაცია
    • TypeScript
    • Next.js
    • PHP
  3. 03ინტეგრაციაარსებულ სისტემებთან, რეალურ მონაცემებზე
    • REST API
    • webhooks
    • PostgreSQL
  4. 04გაშვებაdeploy, ლოგირება და მონიტორინგი პირველივე დღიდან
    • Docker
    • nginx
    • CI/CD
  5. 05ექსპლუატაციაგამოსწორება და გაუმჯობესება რეალურ გამოყენებაზე
    • Logging
    • Metrics
  6. 06გადაცემაკოდი, დოკუმენტაცია და deploy თქვენს მხარეს
ცხრილიდან სისტემამდე — მცირე სამუშაო ვერსიით დაწყებული

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

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

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

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

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

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

in-houselatency / losspath changeper-ASN
დისტანციური NOC
დაბუნდოვნებული 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
ავტომატიზაცია და ინტეგრაცია
ძლიერად დაბუნდოვნებული ბილინგის სისტემის ეკრანი აბონენტების სიით — პერსონალური მონაცემები წაკითხვადი არ არის.

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

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

in-housebillingprovisioningIPTV
ბილინგი და provisioning

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

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

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

საკუთარი NOC კონსოლი (OpenPath)

Proven

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

  • in-house
  • probes
  • per-ASN

ISP ბილინგის სისტემა

Proven

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

  • billing
  • provisioning
  • SMS

ვებ-პლატფორმები და პორტალები

Proven

TypeScript/Next.js და PHP — სერვერული რენდერი, ორენოვნება, CMS და წვდომის კონტროლი.

  • Next.js
  • TypeScript
  • PHP
  • PostgreSQL

API ინტეგრაციები

Proven

სისტემებს შორის მონაცემების გაცვლა: მონიტორინგი, IPAM, ბილინგი, ticketing, გადახდები.

  • REST
  • webhooks
  • cron

ავტომატიზაცია და სკრიპტინგი

Proven

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

  • Python
  • Bash
  • Ansible

მობილური და დესკტოპ კლიენტები

Capability

იქ, სადაც ვებ-ინტერფეისი საკმარისი არაა.

პროცესი

პროცესი

  1. 01

    პროცესის აღწერა

    როგორ კეთდება ახლა და სად იკარგება დრო.

  2. 02

    სამუშაო ვერსია

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

  3. 03

    ინტეგრაცია

    არსებულ სისტემებთან შეერთება და რეალურ მონაცემებზე ტესტი.

  4. 04

    გაშვება

    deploy, ლოგირება და მონიტორინგი პირველივე დღიდან.

  5. 05

    ექსპლუატაცია

    გამოსწორება, გაუმჯობესება და გადაცემა თქვენს გუნდზე.

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

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

Frontend
TypeScriptNext.jsReactTailwind
Backend
Node.jsPHPPythonREST API
მონაცემები
PostgreSQLMySQLRedisClickHouse
ინფრასტრუქტურა
DockernginxCI/CDAnsible

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

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

პროექტი

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

რეტეინერი

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

Co-Managed

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

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

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

მზა პროდუქტი არ ჯდება

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

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

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

კლიენტს ხედვა სჭირდება

self-service პორტალი ამცირებს ზარებს და დავებს — ორივე მხარეს ერთი და იგივე ციფრი აქვს.

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

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

კოდი ჩვენი რჩება?

დიახ. კოდი, დოკუმენტაცია და deploy-ის პროცედურა თქვენს მხარეს გადადის — ჩაკეტვა არ არის მოდელის ნაწილი.

რით განსხვავდებით ჩვეულებრივი დეველოპმენტ-სტუდიისგან?

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

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

service

მონიტორინგი და დაკვირვებადობა

solution

ISP და ტელეკომი

solution

MSP და IT პროვაიდერები

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

ესაუბრეთ ინჟინერს