Belajar Telecom Engineer - Network Automation Telecom

#Pendahuluan

Setelah di episode 14 kita melihat fungsi jaringan berpindah ke telco cloud sebagai container yang dikelola Kubernetes, muncul ketidakcocokan yang mencolok: sementara core sudah cloud-native, ribuan router transport dan site radio masih dikonfigurasi lewat CLI manual satu per satu. Episode ini menjembatani gap itu: network automation — cara modern mengelola jaringan telecom dalam skala besar.

Mengapa otomasi bukan lagi pilihan? Hitung saja: operator dengan 30.000 cell site melakukan puluhan ribu change per tahun. Manual berarti lambat, mahal, dan penuh human error — penyebab utama outage justru perubahan yang salah ketik. Otomasi mengubah pekerjaan berulang menjadi kode yang bisa direview, diuji, dan diulang identik.

#Dari SNMP/CLI ke Model-Driven

Evolusi paradigma manajemen jaringan:

Kunci revolusinya adalah YANG (Yet Another Next Generation): bahasa pemodelan data. Alih-alih teks bebas, konfigurasi didefinisikan sebagai struktur data bertipe — sehingga bisa divalidasi, dibandingkan, dan dimanipulasi programatik.

Contoh operasi NETCONF edit-config:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>eth0</name>
          <description>UPLINK-RING-A</description>
          <enabled>true</enabled>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

Yang membuat model-driven unggul: candidate configuration + commit (ubah dulu di draft, validasi, baru aktif), rollback atomik bila gagal, dan confirmed commit (auto-revert jika tidak dikonfirmasi dalam X detik — jaring keselamatan bagi engineer).

#Ansible: Pisau Swiss Otomasi Telecom

Ansible populer di operator karena agentless (cukup SSH) dan deklaratif. Konsep intinya: playbook menjelaskan kondisi akhir yang diinginkan; Ansible menghitung langkah menuju sana.

#Inventory dan grup peran

[core_routers]
cr1.lab ansible_host=10.0.0.11
cr2.lab ansible_host=10.0.0.12
 
[access_routers]
ar1.lab ansible_host=10.0.0.21
ar2.lab ansible_host=10.0.0.22
 
[transport:children]
core_routers
access_routers

#Praktik: tarik state dan backup config

---
- name: Backup konfigurasi semua router
  hosts: transport
  gather_facts: false
 
  tasks:
    - name: Ambil running-config via CLI
      ansible.netcommon.cli_command:
        command: show running-config
      register: cfg
 
    - name: Simpan ke file terstruktur
      copy:
        content: "{{ cfg.stdout }}"
        dest: "backups/{{ inventory_hostname }}-{{ lookup('pipe', 'date +%F') }}.cfg"

Jalankan:

ansible-playbook -i inventory.ini playbook_backup.yml --limit access_routers
ls backups/

#Idempotensi: deploy interface description massal

---
- name: Set deskripsi interface uplink seragam
  hosts: transport
  gather_facts: false
 
  tasks:
    - name: Pastikan deskripsi sesuai standard
      ansible.netcommon.cli_config:
        config: |
          interface {{ item.iface }}
           description {{ item.desc }}
      loop:
        - {iface: eth0, desc: "UPLINK-AGG-RING1"}
        - {iface: lo,   desc: "LOOPBACK-MGMT"}
      notify: save config
 
  handlers:
    - name: save config
      ansible.netcommon.cli_command:
        command: write memory

Ciri playbook sehat: dijalankan dua kali pun hasilnya sama tanpa error (idempotent) — inilah yang membedakan otomasi dewasa dari sekadar script batch.

#Zero-Touch Provisioning (ZTP)

Saat 500 site baru harus live bulan ini, bahkan Ansible butuh orang menyentuh tiap device. ZTP menghilangkan sentuhan itu: router/switch baru yang baru menyala akan:

Komponen kuncinya: DHCP memberi IP + lokasi skrip bootstrap; skrip menarik konfigurasi spesifik-site dari database inventory (site ID → hostname, VLAN, ring membership); setelah apply, perangkat mendaftar sendiri ke monitoring. Teknologi pendukungnya bervariasi (ONIE, Cisco PnP, Nokia ZTP), prinsipnya identik.

#GitOps untuk Jaringan

Praktik lanjutan yang menjadi arus utama 2026: konfigurasi jaringan disimpan di git, setiap perubahan melewati review + CI (validasi sintaks, dry-run), lalu pipeline menerapkan ke perangkat. Keuntungan besar bagi telecom:

• Audit trail: siapa mengubah apa, kapan, disetujui siapa.
• Rollback instan: git revert + re-run pipeline.
• Compliance otomatis: CI menolak config yang melanggar standard (misal password policy).

#Common Pitfalls

• Mengotomasi kekacauan: jika standard config tidak ada, otomasi hanya mempercepat penyebaran inkonsistensi. Standardisasi dulu, otomasi kemudian.
• Tanpa lab/uji: playbook pertama harus dijalankan ke lab GNS3 (episode 7) — bukan langsung backbone produksi.
• Credential plaintext: simpan secret di vault/encrypted vars; SSH key dengan least privilege, bukan satu admin password untuk semua.

#Penutup

Inti yang harus dibawa pulang:

• Manajemen modern bersifat model-driven: YANG mendefinisikan data, NETCONF/RESTCONF/gNMI mengangkutnya, dengan transaksi & rollback aman.
• Ansible adalah titik masuk ideal: inventory, playbook, idempotensi — kalian sudah menulis dan menjalankannya.
• ZTP menghilangkan konfigurasi manual perangkat baru; GitOps membawa disiplin code-review ke jaringan.
• Urutan benar adopsi otomasi: standardisasi → read-only tasks → config push bertahap → full orchestration.

Di episode 16 kita meninggalkan daratan: satellite & non-terrestrial networks — LEO/MEO/GEO, NTN dalam 5G, dan desain konektivitas berbasis satelit. Sampai jumpa!