01
Network engineering
L2/L3 design, BGP and OSPF, MPLS, operator edge, RPKI policy and migrations. The group's own autonomous system — AS203136 — runs on this discipline.
- BGP
- OSPF
- MPLS
- RPKI
- SD-WAN
team
Who actually works on your infrastructure
The team is organised into five engineering disciplines, and every engagement has one named owning engineer. Below: how an engagement is staffed, who picks up the alert at night and how escalation runs.
media slot
about-team
1600×900 · 16:9
disciplines
Five engineering disciplines
An engagement is staffed from these disciplines according to what the environment needs — not according to who happens to be free.
02
Datacenter & virtualization
Fabric design, KVM clusters, storage, HA, provisioning automation and tested recovery. The group's hosting platform is the output of exactly this work.
- KVM
- Proxmox
- VMware
- Ansible
- RAID 10
03
Observability
Metrics, streaming telemetry and flow analytics; dashboards and alerts that point at an action rather than at a generic red square.
- Prometheus
- Grafana
- Zabbix
- gNMI
- Akvorado
04
Logging & security
Log centralisation and correlation, access control, change auditing and the incident response procedure.
- Graylog
- Wazuh
- MFA
- RBAC
- syslog
05
Software engineering
Internal tooling, APIs and automation: the group's provisioning and billing panel and the 33 public tools on noc.com.ge are written in-house.
- API
- Docker
- CI/CD
- Ansible
ownership
Work is assigned to a person, not to a queue
- A named owner
- Every engagement has one owning engineer: they run the audit, sign the design and answer for the result. The client knows their name and how to reach them.
- A second engineer in context
- A second engineer carries the same environment. Leave, illness or a 03:00 incident does not mean explaining the network from scratch.
- Documentation as the handover
- Topology, configuration standards and runbooks belong to the client and are kept current. Knowledge does not live only in an engineer's head.
- Change under approval
- A production change requires approval, a window and a rollback plan — under the rules set out in the Trust Center.
on-call and escalation
Who takes the alert, and who next
Escalation has four tiers. At each tier it is already settled who holds the decision — that is not negotiated during an incident.
L1
Monitoring and triage
Duty engineer
Receives the alert, confirms the incident, executes the documented runbook and keeps the incident record. If the runbook does not cover the case, it escalates immediately.
L2
Diagnosis and change
Discipline engineer
The engineer for the relevant discipline — network, datacenter, observability or security. Authorised to change configuration inside an approved change, with a rollback plan.
L3
Design level
Engagement owner and architect
Engaged when the incident touches the design or requires an agreed deviation. The same person who signed off the architecture — not a fresh pair of hands without context.
L4
External party
Vendor or upstream operator
The hardware vendor, licensed support or an upstream operator. We open and run the ticket; the client is not left corresponding with a third party.
Response windows are fixed per severity in the contract, against your environment. We publish no minutes here until they are agreed and measured.
engineers
Your team, by name
not published here
We do not publish name-and-photo profiles here. Who your owning engineer will be, which environments they have run, who the second engineer is and how you reach them are all set out in the engagement pack at proposal stage, for your specific project.
The reason is simple: a generic biography and a stock photo tell you nothing about who picks up the phone at 03:00.