01
ქსელური ინჟინერია
L2/L3 დიზაინი, BGP და OSPF, MPLS, ოპერატორული edge, RPKI პოლიტიკა და მიგრაციები. ამ მიმართულებაზე დგას ჯგუფის საკუთარი ავტონომიური სისტემაც — AS203136.
- BGP
- OSPF
- MPLS
- RPKI
- SD-WAN
გუნდი
ვინ მუშაობს თქვენს ინფრასტრუქტურაზე
გუნდი ხუთ საინჟინრო მიმართულებადაა აწყობილი და თითოეულ პროექტს ჰყავს ერთი სახელობითი მფლობელი ინჟინერი. ქვემოთ აღწერილია, საიდან კომპლექტდება პროექტი, ვინ იღებს ღამის alert-ს და როგორ მიდის ესკალაცია.
media slot
about-team
1600×900 · 16:9
მიმართულებები
ხუთი საინჟინრო მიმართულება
პროექტი ამ მიმართულებებიდან კომპლექტდება იმის მიხედვით, რა სჭირდება გარემოს — და არა იმის მიხედვით, ვინ არის თავისუფალი.
02
დატაცენტრი და ვირტუალიზაცია
fabric-ის დიზაინი, KVM კლასტერები, საცავი, HA, provisioning-ის ავტომატიზაცია და აღდგენის ტესტირება. ჯგუფის ჰოსტინგის პლატფორმა სწორედ ამ სამუშაოს შედეგია.
- KVM
- Proxmox
- VMware
- Ansible
- RAID 10
03
დაკვირვებადობა
მეტრიკები, streaming telemetry და flow ანალიტიკა; დაშბორდები და alert-ები, რომლებიც კონკრეტულ მოქმედებაზე მიუთითებს და არა ზოგად „წითელ ფერზე“.
- Prometheus
- Grafana
- Zabbix
- gNMI
- Akvorado
04
ლოგირება და უსაფრთხოება
ლოგების ცენტრალიზაცია და კორელაცია, წვდომის კონტროლი, ცვლილებების აუდიტი და ინციდენტზე რეაგირების პროცედურა.
- Graylog
- Wazuh
- MFA
- RBAC
- syslog
05
პროგრამული ინჟინერია
შიდა ინსტრუმენტები, API-ები და ავტომატიზაცია: ჯგუფის provisioning-ისა და ბილინგის პანელი და noc.com.ge-ის 33 საჯარო ინსტრუმენტი ჩვენივე დაწერილია.
- API
- Docker
- CI/CD
- Ansible
პასუხისმგებლობა
სამუშაო ენიჭება ადამიანს, არა რიგს
- სახელობითი მფლობელი
- თითოეულ პროექტს ჰყავს ერთი მფლობელი ინჟინერი: ის ატარებს აუდიტს, ხელს აწერს დიზაინს და პასუხისმგებელია შედეგზე. მისი სახელი და კონტაქტი კლიენტმა იცის.
- მეორე ინჟინერი კონტექსტში
- იმავე პროექტს ჰყავს მეორე ინჟინერი, რომელიც გარემოს იცნობს. შვებულება, ავადმყოფობა ან ღამის სამზე მომხდარი ინციდენტი არ ნიშნავს ნულიდან ახსნას.
- დოკუმენტაცია, როგორც გადაცემის მექანიზმი
- ტოპოლოგია, კონფიგურაციის სტანდარტი და runbook-ები კლიენტის საკუთრებაა და მუდმივად ახლდება. ცოდნა ინჟინრის თავში არ რჩება.
- ცვლილება — დამტკიცებით
- პროდაქშენის ცვლილება მოითხოვს დამტკიცებას, სამუშაო ფანჯარას და rollback გეგმას — იმ წესებით, რომლებიც Trust Center-შია აღწერილი.
მორიგეობა და ესკალაცია
ვინ იღებს alert-ს და შემდეგ ვინ
ესკალაცია ოთხსაფეხურიანია. თითოეულ საფეხურზე ცნობილია, ვის აქვს გადაწყვეტილების უფლება — ეს ინციდენტის დროს არ განიხილება.
L1
მონიტორინგი, ტრიაჟი
მორიგე ინჟინერი
იღებს alert-ს, ადასტურებს ინციდენტს, ასრულებს დოკუმენტირებულ runbook-ს და აწარმოებს ინციდენტის ჩანაწერს. თუ runbook არ ფარავს შემთხვევას — ესკალაცია დაუყოვნებლივ.
L2
დიაგნოსტიკა, ცვლილება
მიმართულების ინჟინერი
შესაბამისი მიმართულების ინჟინერი — ქსელი, დატაცენტრი, დაკვირვებადობა ან უსაფრთხოება. აქვს უფლება შეცვალოს კონფიგურაცია დამტკიცებული ცვლილების ფარგლებში, rollback გეგმით.
L3
დიზაინის დონე
პროექტის მფლობელი და არქიტექტორი
ჩართულია მაშინ, როცა ინციდენტი დიზაინს ეხება ან საჭიროა კლიენტთან შეთანხმებული გადახრა. იგივე ადამიანი, რომელმაც არქიტექტურა დაამტკიცა — არა ახალი, კონტექსტის გარეშე.
L4
გარე მხარე
ვენდორი ან upstream ოპერატორი
აპარატურის ვენდორი, ლიცენზიის მხარდაჭერა ან upstream ოპერატორი. ticket-ს ჩვენ ვხსნით და ვაწარმოებთ; კლიენტი გარე მხარესთან მიმოწერაში არ ერთვება.
რეაგირების ფანჯრები severity-ს მიხედვით ფიქსირდება ხელშეკრულებაში, თქვენს გარემოზე მორგებით. კონკრეტულ წუთებს აქ არ ვწერთ, სანამ ისინი შეთანხმებული და გაზომილი არ იქნება.
ინჟინრები
თქვენი გუნდი სახელებით
საჯაროდ არ ქვეყნდება
სახელობით პროფილებს საიტზე არ ვდებთ. ვინ იქნება თქვენი მფლობელი ინჟინერი, რა გარემო აქვს ნამუშევარი, ვინ იქნება მეორე ინჟინერი და როგორ დაუკავშირდებით — ეს ყველაფერი engagement pack-ში გადმოგეცემათ შეთავაზების ეტაპზე, კონკრეტული პროექტისთვის.
მიზეზი მარტივია: გენერირებული ბიოგრაფია და სტოკ-ფოტო არაფერს გეუბნებათ იმაზე, ვინ აიღებს ტელეფონს ღამის სამზე.