Pendahuluan

Dalam operasional NOC (Network Operations Center), escalation adalah proses meneruskan penanganan insiden ke level yang lebih tinggi ketika insiden tidak bisa diselesaikan pada level saat ini, atau ketika dampaknya terlalu besar untuk ditangani sendiri.

Tanpa alur eskalasi yang jelas, tim NOC akan:

  • Bingung harus menghubungi siapa saat terjadi gangguan besar
  • Membuang waktu berharga dengan trial and error
  • Terjebak pada insiden yang sebenarnya di luar kapasitas skill mereka
  • Melanggar SLA karena respons yang terlambat

Escalation matrix adalah dokumen yang menghilangkan ambiguitas tersebut — mendefinisikan kapan, kepada siapa, dan bagaimana insiden harus diteruskan.

Severity Level (Tingkat Keparahan)

Setiap insiden yang masuk ke NOC harus segera diklasifikasikan berdasarkan tingkat dampaknya terhadap layanan. Klasifikasi ini menentukan kecepatan respons dan level eskalasi yang dibutuhkan.

Tabel Severity Level

Level Nama Definisi Contoh Kasus Target Respons Target Resolusi
P1 Critical Total service outage, dampak massal ke banyak pelanggan Core router down, fiber backbone putus, peering IXP mati total Segera (< 5 menit) < 1 jam
P2 High Degradasi signifikan atau outage parsial Link upstream degraded (packet loss tinggi), satu POP mati, BGP flapping < 15 menit < 2 jam
P3 Medium Gangguan lokal, dampak terbatas Satu pelanggan corporate down, port switch mati, AP tidak broadcast < 1 jam < 8 jam
P4 Low Informasional, tidak berdampak langsung Alarm temperature warning, disk usage tinggi, request perubahan konfigurasi < 4 jam Best effort

Tip: Severity level harus ditentukan berdasarkan dampak bisnis, bukan kompleksitas teknis. Masalah teknis yang sederhana (misal kabel UTP putus) bisa menjadi P1 jika terjadi pada link backbone yang melayani ribuan pelanggan.

Escalation Matrix

Alur Eskalasi Berdasarkan Tier

┌──────────────────────────────────────────────────────┐
│                                                      │
│  ALARM / LAPORAN PELANGGAN                           │
│          │                                           │
│          ▼                                           │
│  ┌───────────────┐                                   │
│  │   TIER 1 (L1) │  ← Triage awal, runbook-based    │
│  │  NOC Operator  │     Target: 15–30 menit          │
│  └───────┬───────┘                                   │
│          │ Tidak bisa resolve?                        │
│          │ Atau severity P1/P2?                       │
│          ▼                                           │
│  ┌───────────────┐                                   │
│  │   TIER 2 (L2) │  ← Deep troubleshooting           │
│  │  NOC Engineer  │     Target: 1–2 jam               │
│  └───────┬───────┘                                   │
│          │ Root cause di luar kapasitas?              │
│          │ Atau butuh perubahan desain?               │
│          ▼                                           │
│  ┌───────────────┐                                   │
│  │   TIER 3 (L3) │  ← Expert / Vendor escalation     │
│  │  Senior Eng.  │     Target: case-by-case           │
│  └───────┬───────┘                                   │
│          │ Dampak bisnis sangat besar?                │
│          ▼                                           │
│  ┌───────────────┐                                   │
│  │  MANAGEMENT   │  ← Koordinasi stakeholder          │
│  │  NOC Manager  │     Komunikasi ke pelanggan/C-Level│
│  └───────────────┘                                   │
│                                                      │
└──────────────────────────────────────────────────────┘

Detail Setiap Tier

Tier 1 — NOC Operator (First Responder)

Profil: Staff NOC yang bertugas 24/7 di shift rotasi. Biasanya memiliki skill dasar networking dan terlatih menggunakan runbook.

Tanggung Jawab:

Tugas Detail
Monitoring Dashboard Memantau NMS, merespons alarm yang muncul
Triage & Klasifikasi Menentukan severity level, membuat tiket insiden
Troubleshooting Dasar Cek konektivitas (ping, traceroute), restart service, cek status interface
Eksekusi Runbook Mengikuti prosedur standar untuk masalah yang sudah terdokumentasi
Komunikasi Awal Menginformasikan pelanggan terdampak (jika SLA mengharuskan)
Eskalasi Meneruskan ke L2 jika tidak bisa resolve dalam batas waktu

Contoh Tindakan L1:

Alarm: Interface GigabitEthernet0/0/1 DOWN pada Router-POP-Bandung

Langkah L1 (sesuai runbook):
1. Buat tiket insiden → Severity P2 (satu POP terpengaruh)
2. Ping remote device → Tidak respons
3. Cek via NMS → Semua pelanggan di POP tersebut offline
4. Hubungi teknisi lapangan → Apakah ada maintenance?
5. Cek alarm terkait → Apakah ada power outage?
6. Jika tidak ada progress dalam 15 menit → Eskalasi ke L2

Tier 2 — NOC Engineer (Specialist)

Profil: Engineer jaringan dengan skill menengah-lanjut. Memahami routing protocol (BGP, OSPF), switching, firewall, dan traffic engineering.

Tanggung Jawab:

Iklan
Tugas Detail
Deep Troubleshooting Analisis log, debug routing protocol, trace packet flow
Analisis Root Cause Menentukan akar masalah sesungguhnya (bukan hanya gejala)
Implementasi Workaround Menerapkan solusi sementara untuk memulihkan layanan
Koordinasi Tim Lapangan Mengarahkan teknisi untuk perbaikan fisik (fiber, power)
Eskalasi ke L3/Vendor Jika masalah ada di level desain atau perangkat vendor

Contoh Tindakan L2:

Eskalasi dari L1: BGP session ke upstream ISP flapping setiap 5 menit

Langkah L2:
1. Cek BGP neighbor state → Status: Idle (hold timer expired)
2. Debug BGP messages:
   - MikroTik: /routing/bgp/session/print detail
   - Juniper:  show bgp neighbor <IP> | match "Last error"
3. Analisis → Hold timer expired, kemungkinan packet loss di link
4. Cek interface counters → CRC errors tinggi (suspect kabel/SFP)
5. Solusi sementara: Re-route trafik via backup upstream
6. Koordinasi dengan teknisi lapangan → Ganti SFP module
7. Verifikasi setelah perbaikan → BGP session stabil
8. Dokumentasi RCA di tiket

Tier 3 — Senior Engineer / Subject Matter Expert

Profil: Engineer senior dengan keahlian spesifik dan mendalam. Sering kali berperan ganda sebagai network architect.

Tanggung Jawab:

Tugas Detail
Masalah Level Desain Redesain topologi, perubahan routing policy, capacity planning
Vendor Escalation Membuka case ke Juniper JTAC, Cisco TAC, MikroTik support
Analisis Insiden Kompleks Masalah yang melibatkan interaksi antar banyak sistem
Post-Incident Review Memimpin RCA (Root Cause Analysis) setelah insiden P1
Mentoring L1/L2 Transfer knowledge, update runbook berdasarkan temuan baru

Management — NOC Manager

Kapan Management dilibatkan:

  • Insiden P1 (Critical) yang berlangsung lebih dari 30 menit
  • Insiden yang berpotensi melanggar SLA kontrak besar
  • Insiden yang membutuhkan koordinasi lintas departemen (billing, sales, legal)
  • Komunikasi ke pelanggan enterprise / pemerintah
  • Keputusan darurat yang membutuhkan otorisasi (misal: emergency maintenance)

Trigger Eskalasi: Kapan Harus Naik Level?

Eskalasi harus terjadi secara otomatis berdasarkan aturan yang jelas, bukan berdasarkan perasaan. Berikut trigger-nya:

Eskalasi Berdasarkan Waktu (Time-Based)

Severity L1 → L2 L2 → L3 L3 → Management
P1 15 menit 30 menit Segera (paralel)
P2 30 menit 1 jam 2 jam
P3 2 jam 4 jam 8 jam
P4 8 jam 24 jam Opsional

Eskalasi Berdasarkan Kondisi (Condition-Based)

Selain waktu, ada kondisi tertentu yang langsung memicu eskalasi tanpa menunggu timer:

  • Langsung ke L2: Masalah routing protocol (BGP, OSPF), masalah yang tidak ada di runbook
  • Langsung ke L3: Butuh perubahan desain, masalah yang memerlukan vendor support, bug perangkat
  • Langsung ke Management: P1 yang berdampak > 50% pelanggan, potensi pelanggaran SLA enterprise, insiden keamanan

Important: Eskalasi bukan berarti L1 melepas tanggung jawab. L1 tetap menjadi incident owner yang bertanggung jawab tracking dan update tiket, sementara L2/L3 bertindak sebagai resolver.

Contoh Skenario Penanganan Insiden

Skenario 1: Fiber Backbone Putus (P1 — Critical)

Timeline:

00:00  NMS mendeteksi 15 alarm sekaligus: multiple interface DOWN
       pada Core-Router-JKT-01

00:02  L1 menerima alarm, buat tiket #INC-2025-0531
       Severity: P1 (multiple POP offline, ~2000 pelanggan terdampak)

00:03  L1 melakukan triage:
       - Ping ke Core-Router → Respons OK
       - Cek interface → xe-0/0/0 DOWN (link ke Bandung)
       - Cek light level → Rx power: -40 dBm (seharusnya ~-8 dBm)
       → Kesimpulan awal: Fiber cut

00:05  L1 eskalasi ke L2 + notifikasi Management (P1 paralel)

00:08  L2 mengambil alih:
       - Konfirmasi single point of failure (tidak ada redundansi)
       - Aktifkan rerouting via jalur alternatif (jika ada)
       - Koordinasi dengan tim fiber untuk dispatch teknisi

00:10  Management:
       - Kirim notifikasi massal ke pelanggan terdampak
       - Update status page

00:15  Tim fiber berangkat ke lokasi, bawa OTDR

01:00  Tim fiber menemukan titik putus (km 12.4)
       → Penyebab: Galian proyek jalan

02:30  Splicing selesai, link UP, trafik normal

02:45  L1 verifikasi: semua alarm clear, monitoring 30 menit

03:15  Tiket ditutup, L2 menulis RCA report

Skenario 2: BGP Session Down ke Upstream (P2 — High)

Timeline:

00:00  Alarm: BGP neighbor 203.0.113.1 state changed to IDLE
       pada Border-Router-01

00:02  L1 menerima, buat tiket #INC-2025-0532
       Severity: P2 (satu upstream mati, masih ada backup)

00:03  L1 triage:
       - Cek interface → UP (link fisik OK)
       - Ping peer IP → Timeout
       - Cek apakah ada maintenance schedule → Tidak ada
       → Eskalasi ke L2 (masalah BGP di luar runbook L1)

00:08  L2 troubleshooting:

       MikroTik:
       /routing/bgp/session/print detail where remote.address=203.0.113.1
       → last-error: "hold timer expired"

       Juniper:
       show bgp neighbor 203.0.113.1
       → Last error: Hold Timer Expired Error

00:12  L2 analisis lebih lanjut:
       - Traceroute ke peer → Berhenti di hop ke-3
       - Cek dengan upstream provider → Mereka juga melihat
         packet loss di segmen tersebut

00:15  L2 menghubungi upstream NOC (vendor escalation)
       → Upstream mengonfirmasi ada masalah di sisi mereka

00:20  L2 memastikan backup upstream aktif:

       MikroTik:
       /routing/route/print where dst-address=0.0.0.0/0
       → Gateway via backup upstream: ACTIVE

       Juniper:
       show route 0.0.0.0/0
       → Next hop via backup: ACTIVE

01:30  Upstream menginformasikan masalah resolved

01:35  BGP session kembali ESTABLISHED:

       MikroTik:
       /routing/bgp/session/print where remote.address=203.0.113.1
       → state: established, uptime: 00:05:00

       Juniper:
       show bgp summary
       → 203.0.113.1  Establ, Up 5:00

01:45  L1 verifikasi, tiket ditutup

Template Komunikasi Insiden

Komunikasi yang baik saat insiden berlangsung adalah bagian penting dari operasional NOC. Berikut template yang bisa digunakan:

Template Notifikasi Awal (untuk Pelanggan)

Subject: [GANGGUAN] Gangguan Layanan Internet - Area Jakarta Selatan

Yth. Pelanggan,

Kami menginformasikan bahwa saat ini terjadi gangguan pada layanan
internet di area Jakarta Selatan sejak pukul 14:30 WIB.

Detail:
- Tiket     : INC-2025-0531
- Severity  : P1 (Critical)
- Dampak    : Layanan internet tidak tersedia
- Area      : Jakarta Selatan (POP Cilandak, POP Pondok Indah)
- Penyebab  : Sedang dalam investigasi
- Estimasi  : Tim teknis sedang bekerja untuk pemulihan

Kami akan mengirimkan update berkala setiap 30 menit.
Mohon maaf atas ketidaknyamanan ini.

Hormat kami,
Tim NOC - PT ISP Indonesia

Template Update Berkala

Subject: [UPDATE] Gangguan Layanan Internet - Area Jakarta Selatan

Update pukul 15:00 WIB:

- Status     : Dalam proses perbaikan
- Penyebab   : Fiber optik terputus akibat galian pihak ketiga
- Progress   : Tim fiber sudah di lokasi, estimasi splicing 1–2 jam
- ETA Pulih  : ~17:00 WIB

Tim NOC - PT ISP Indonesia

Template Resolusi

Subject: [RESOLVED] Gangguan Layanan Internet - Area Jakarta Selatan

Yth. Pelanggan,

Kami menginformasikan bahwa gangguan layanan di area Jakarta Selatan
telah SELESAI diperbaiki pada pukul 16:45 WIB.

Ringkasan:
- Tiket     : INC-2025-0531
- Durasi    : 14:30 – 16:45 WIB (2 jam 15 menit)
- Penyebab  : Fiber optik putus akibat galian proyek di Jl. Fatmawati
- Solusi    : Splicing ulang fiber optik di titik km 12.4
- Pencegahan: Koordinasi dengan Dinas PU terkait jadwal galian

Kami mohon maaf atas gangguan yang terjadi.
Silakan hubungi helpdesk kami jika masih mengalami kendala.

Tim NOC - PT ISP Indonesia

Best Practice Escalation

  1. Berbasis Peran, Bukan Nama Orang Escalation matrix harus merujuk pada peran (contoh: "On-call Network Engineer"), bukan nama individu. Jika seseorang resign, prosesnya tetap berjalan.

  2. Automasi Timer Eskalasi Program aturan eskalasi ke dalam ticketing system (Jira, ServiceNow, GLPI). Jika tiket P1 tidak di-acknowledge dalam 5 menit, sistem otomatis mengirim notifikasi ke L2.

  3. Jangan Takut Eskalasi Kultur NOC yang sehat adalah kultur di mana eskalasi bukanlah kegagalan. Lebih baik eskalasi terlalu cepat daripada terlambat. SLA pelanggan tidak menunggu ego engineer.

  4. Shift Handover yang Terstruktur Setiap pergantian shift, tiket yang masih open harus di-briefing secara eksplisit. Jangan hanya bilang "cek di sistem".

  5. Review & Update Berkala Escalation matrix harus di-review minimal setiap 3 bulan atau setiap kali ada perubahan struktur tim.

Ringkasan

Komponen Detail
Severity Level P1 (Critical), P2 (High), P3 (Medium), P4 (Low) — ditentukan oleh dampak bisnis
Tier Escalation L1 (First Responder) → L2 (Specialist) → L3 (SME/Vendor) → Management
Trigger Eskalasi Time-based (timer SLA) + Condition-based (di luar kapasitas skill)
Incident Owner L1 tetap memegang ownership tiket meskipun sudah dieskalasi
Komunikasi Notifikasi awal → Update berkala → Resolusi → RCA report

Tip: Buatlah dry run atau simulasi insiden P1 secara berkala (misalnya setiap kuartal). Ini memastikan seluruh tim memahami alur eskalasi saat situasi sesungguhnya terjadi, bukan baru belajar saat panik.