Belajar System Engineer - Arsitektur Sistem & Lifecycle

#Pendahuluan

Setelah memahami peran dan tanggung jawab System Engineer di episode 1, sekarang kita membahas cara berpikir utamanya: siklus hidup sebuah sistem. Seorang System Engineer tidak melihat server sebagai objek statis yang "dipasang lalu dilupakan" — melainkan sebagai entitas yang lahir, hidup, dan akhirnya dipensiunkan. Setiap fase punya aktivitas, keputusan, dan dokumentasi masing-masing.

Mengapa ini penting? Karena mayoritas insiden di dunia nyata lahir dari fase yang diabaikan: server dibangun tanpa desain, dokumentasi tidak pernah ditulis, atau mesin yang sudah tidak dipakai masih dibiarkan berjalan — boros biaya dan berisiko keamanan. Memahami lifecycle membuat kalian mengelola sistem secara utuh, bukan menambal di sana-sini.

#Siklus Hidup Sistem

Sebuah sistem melewati empat fase utama:

#1. Design

Fase paling menentukan, paling sering diremehkan. Di sini kalian menjawab pertanyaan-pertanyaan dasar sebelum menulis satu baris konfigurasi:

• Tujuan: layanan apa yang dilayani, siapa penggunanya, berapa trafik yang diharapkan?
• Prasyarat: OS, bahasa runtime, database, middleware apa yang dibutuhkan?
• Pertimbangan non-fungsional: ketersediaan (availability), performa, keamanan, biaya, dan kemudahan operasi.
• Keputusan arsitektur: virtual machine atau container? on-prem atau cloud? satu node atau cluster?

Keluaran fase ini adalah dokumen desain dan Architecture Decision Record (ADR) — catatan singkat berisi keputusan penting beserta alasannya. ADR menyelamatkan kalian enam bulan kemudian ketika bertanya "kenapa sih kita pilih begini?"

#2. Provisioning

Fase ini mengubah desain menjadi sistem yang berjalan. Idealnya bersifat reproducible: dari dokumentasi dan kode, sistem yang sama bisa dibangun ulang kapan saja. Perintah manual masih boleh untuk server pertama, tapi untuk produksi harus diotomasi — topik yang kita dalami di episode 9 (Ansible) dan 25 (Terraform).

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx

Yang membedakan provisioning baik dari yang buruk adalah dokumentasinya: apakah langkah di atas tertulis di runbook, atau hanya ada di kepala orang yang membuatnya?

#3. Operation

Fase terpanjang dalam lifecycle. Aktivitasnya meliputi:

• Monitoring & alerting — tahu lebih dulu sebelum pengguna mengeluh (episode 10).
• Patch management — menjaga sistem tetap aman dan terbarui (episode 17).
• Backup & restore — melindungi data dan menguji pemulihannya (episode 11).
• Capacity management — memastikan sistem tidak kehabisan sumber daya (episode 22).
• Incident response — merespons kegagalan secara terukur (episode 24).

Selama fase operasi, sistem terus berubah: update paket, tambah user, ubah konfigurasi. Runbook — dokumen langkah-demi-langkah untuk tugas rutin dan insiden — menjadi penyelamat. Contoh runbook singkat:

Tujuan: restart layanan nginx saat tidak responsif
 
1. Periksa status layanan:
   systemctl status nginx
2. Cek log kesalahan:
   journalctl -u nginx -n 50
3. Restart layanan:
   sudo systemctl restart nginx
4. Verifikasi:
   systemctl is-active nginx && curl -s -o /dev/null -w "%{http_code}" http://localhost

#4. Decommission

Fase paling sering dilupakan, dan paling berbahaya jika diabaikan. Server yang tidak terpakai tetap membayar biaya listrik/cloud, tetap menerima patch, dan menjadi sasaran empuk penyerang. Prosedur decommission yang benar:

1. Konfirmasi tidak ada yang memakai sistem (cek log, trafik, dependensi).
2. Arsipkan data penting sesuai kebijakan retention.
3. Cabut akses dan integrasi (monitoring, backup, SSO).
4. Matikan sumber daya (hapus VM/instance, lepas storage).
5. Catat di asset management agar tidak ada ghost server.

# Di cloud: daftar semua instance termasuk yang berhenti
aws ec2 describe-instances --query \
  'Reservations[].Instances[].[InstanceId,State.Name,Tags]'
 
# Di on-prem: cek uptime & load mesin yang mencurigakan
uptime

#Praktik: Dokumen Arsitektur Sistem

Sekarang saatnya mempraktikkan fase design. Buat dokumen arsitektur untuk sebuah layanan sederhana — misalnya aplikasi web dengan database. Struktur minimal yang direkomendasikan:

# Arsitektur Sistem: app-web
## 1. Tujuan
   Melayani aplikasi web publik, 5.000 request/menit.
## 2. Komponen
   - 1x VM Web Server (Ubuntu 24.04, Nginx + Node.js)
   - 1x VM Database (PostgreSQL 16)
   - Load Balancer (terminasi HTTPS) -> Web Server
## 3. Arsitektur
   [diagram komponen: User -> LB -> App -> DB]
## 4. Keputusan Arsitektur (ADR)
   ADR-001: Pilih PostgreSQL (kebutuhan transaksional)
   ADR-002: Pilih Nginx (ringan, battle-tested)
## 5. Operasi
   - Backup DB: pg_dump harian, 02:00 WIB
   - Monitoring: CPU/disk/node_exporter
   - Runbook: restart, scale-out, restore DB
## 6. Decommission
   - Persetujuan pemilik layanan, arsip DB, cabut integrasi

Dokumen ini bukan untuk formalitas — ia adalah sumber kebenaran (source of truth) tentang sistem kalian. Saat ada pertanyaan "kenapa begini?", dokumen inilah jawabannya.

#Kesalahan Umum

1. Langsung provisioning tanpa desain. Memasang server tanpa menjawab "kenapa" akan menghasilkan arsitektur yang sulit dirawat.
2. Dokumentasi ditulis setelah semua selesai. Tulislah berdampingan dengan pekerjaan — dokumentasi yang ditulis "nanti" biasanya tidak pernah ditulis.
3. Tidak pernah decommission. Ghost server membebani biaya dan risiko. Jadwalkan audit rutin.
4. Runbook tidak diuji. Runbook yang belum pernah diuji sama bahayanya dengan tidak punya runbook.

#Penutup

Inti yang harus dibawa pulang:

• Lifecycle sistem: Design → Provisioning → Operation → Decommission, dengan feedback antar fase.
• Design menghasilkan dokumen arsitektur dan ADR; provisioning harus reproducible.
• Operation bertumpu pada monitoring, patch, backup, dan runbook yang tertulis dan teruji.
• Decommission itu disiplin, bukan sekadar menghapus mesin.

Di episode 3 selanjutnya kita mulai praktik keras: Linux System Administration — service management dengan systemd, filesystem, kernel tuning dasar, dan user management. Siapkan VM Linux kalian, karena kita akan banyak mengetik di terminal!