Praktikum 2. Merancang dan Menguji Arsitektur Teknis ERP
Indikator: arsitektur teknis ERP · 100 pengguna (penjualan, gudang, produksi, pembelian, keuangan)
1. Diagram arsitektur
Pengguna kantor (LAN)Pengguna remote (VPN)
▼ HTTPS
Firewall + VPN gateway
▼
Load balancer / reverse proxy
▼ ▼
Server aplikasi 1
antarmuka web + logika bisnisServer aplikasi 2
standby / aktif
▼ ▼ (jaringan database terpisah)
antarmuka web + logika bisnisServer aplikasi 2
standby / aktif
Database utama⇄ replikasiDatabase replika
▼ backup terjadwal
Storage backup lokal→ salinBackup luar lokasi / cloud
| Komponen | Fungsi |
|---|---|
| Firewall dan VPN | Membatasi lalu lintas, akses dari luar hanya lewat terowongan terenkripsi |
| Load balancer | Membagi permintaan dan memindahkan ke server sehat saat satu server mati |
| Server aplikasi (2) | Menjalankan antarmuka dan logika modul; tidak menyimpan data permanen |
| Database utama dan replika | Menyimpan seluruh transaksi; replika menjadi cadangan siap pakai dan menerima beban baca laporan |
| Backup lokal dan luar lokasi | Pemulihan bila data rusak, terhapus, atau terjadi bencana |
2. Kebutuhan keamanan akses per departemen
| Peran | Penjualan | Gudang | Produksi | Pembelian | Keuangan |
|---|---|---|---|---|---|
| Staf Penjualan | Buat/ubah | Lihat stok | Lihat status | – | – |
| Staf Gudang | Lihat SO | Buat/ubah | Lihat | Terima barang | – |
| Staf Produksi | Lihat SO | Pakai bahan | Buat/ubah | Ajukan PR | – |
| Staf Pembelian | – | Lihat stok | Lihat | Buat/ubah PO | – |
| Staf Keuangan | Lihat faktur | – | – | Lihat PO | Buat/ubah |
| Manajer / Pimpinan | Lihat semua laporan; menyetujui transaksi di atas batas nilai | ||||
Prinsip: least privilege, pemisahan tugas (pembuat PO ≠ penyetuju ≠ pembayar), autentikasi dua langkah untuk keuangan dan akses VPN, serta log audit.
3. Pencadangan dan pemulihan
- Jadwal: full backup harian (malam), incremental/log transaksi tiap 1 jam, replikasi ke database replika terus-menerus.
- Lokasi: aturan 3-2-1: 3 salinan, 2 media berbeda, 1 di luar kantor. Backup dienkripsi.
- Target: RPO maksimal 1 jam, RTO maksimal 4 jam.
- Pemulihan: (1) hentikan akses tulis, (2) pulihkan full backup terakhir ke lingkungan uji, (3) terapkan log hingga titik waktu sebelum kerusakan, (4) verifikasi saldo dan jumlah transaksi, (5) arahkan aplikasi ke database hasil pemulihan.
- Uji restore dilakukan tiap bulan; backup yang belum pernah diuji dianggap belum ada.
4. Aliran data transaksi pembelian
Pengguna isi PO di browserFirewall / load balancerServer aplikasi: validasi, cek hak akses dan anggaranDatabase: simpan PO (status draft)Persetujuan → status disetujuiRespons ke layar penggunaReplikasi dan backup
5. Potensi kegagalan teknis
| Kegagalan | Dampak operasional |
|---|---|
| Server aplikasi mati (jika hanya satu) | Seluruh departemen tidak bisa bertransaksi walau database hidup |
| Database rusak / tidak bisa diakses | Semua transaksi berhenti, risiko kehilangan data |
| Backup tidak berjalan atau tidak pernah diuji | Data tidak bisa dipulihkan setelah kerusakan |
| Jaringan atau internet putus | Pengguna remote terputus; kantor tetap jalan lewat LAN |
Simulasi gangguan
| Kondisi | Tindakan penanganan |
|---|---|
| 1. Database tidak dapat diakses | Cek layanan dan disk; bila rusak, failover ke replika dan arahkan aplikasi ke sana; informasikan pengguna; setelah pulih, cocokkan jumlah transaksi |
| 2. Server aplikasi gangguan | Load balancer mengalihkan ke server aplikasi 2; perbaiki server 1 tanpa menghentikan layanan |
| 3. Internet terputus | Pengguna di kantor tetap bekerja lewat LAN; pengguna remote menunggu atau pakai jalur internet kedua; backup luar lokasi ditunda lalu dikejar |
| 4. Pengguna tidak berwenang buka menu keuangan | Akses ditolak oleh matriks hak akses, percobaan dicatat di log audit, pimpinan atau admin ditinjau jika berulang |
| 5. Data hilang karena backup tidak jalan | Pakai database replika atau backup luar lokasi terakhir, input ulang transaksi dari dokumen sumber; perbaiki penjadwalan dan pasang alarm kegagalan backup |
Alasan pemilihan rancangan
Dengan 100 pengguna, dua server aplikasi di belakang load balancer sudah cukup dan menghilangkan titik kegagalan tunggal. Replika database dan backup luar lokasi menutup risiko kehilangan data dengan biaya yang masih wajar dibanding klaster besar.