After Deploy (@after.deploy)

Website masih online dan tidak menampilkan error. Tapi kenapa pengguna tetap mengeluh lambat? 🤔 Karena hidup belum tentu sehat, Sistem bisa saja masih menerima request, tetapi di balik layar: 📈 CPU sudah mencapai 92% ⏳ Response time naik menjadi 4,8 detik 🚨 Error rate mulai meningkat 🧠…

Status code hanya menunjukkan bahwa request gagal. Untuk mencari tahu apa yang terjadi di balik layar, developer dan DevOps engineer perlu memeriksa log. Log bisa mencatat: ⏱️ Kapan masalah terjadi 🚨 Seberapa serius kejadiannya ⚙️ Service mana yang mengalami masalah 🔍 Request apa yang…

Ternyata setiap status code memberi petunjuk berbeda: ✅ 200: request berhasil 🔍 404: resource tidak ditemukan ⚠️ 500: aplikasi mengalami error 🔗 502: proxy gagal mendapat respons valid dari server upstream Buat seorang DevOps, status code bukan jawaban terakhir, tetapi petunjuk pertama untuk…

Sudah lama tidak update nih! sekarang kita bahas ini ya! Karena proses yang hidup belum tentu berarti request pengguna sudah sampai ke aplikasi. Sebelum website tampil, request harus melewati jalur yang benar: Browser → DNS → Web Server/Reverse Proxy → Aplikasi → Response Kalau proxy salah tujuan…

Domain, hosting, server, dan website adalah bagian yang berbeda: 📍 Domain = nama atau alamat yang diketik pengguna 🧭 DNS = petunjuk menuju layanan yang benar 🏢 Hosting = layanan yang menyediakan tempat dan sumber daya ⚙️ Server = sistem yang menerima request dan memberikan response 💻 Website =…

Kamu cuma ngetik nama website. Beberapa detik kemudian, browser udah tahu server mana yang harus dihubungi. Siapa sih yang nunjukin jalannya? 🤔 Jawabannya: DNS (Domain Name System). Manusia gampang inget nama kayak contoh.com, tapi perangkat butuh alamat IP buat benar-benar terhubung. DNS yang…

Pernah kepikiran kenapa website dari server luar negeri tetap bisa dibuka dengan cepat? 🌍⚡ Rahasianya ada pada caching dan CDN. Data yang sering diminta disimpan sementara dan didistribusikan ke server yang lebih dekat dengan pengguna. Jadi, setiap permintaan tidak harus selalu kembali ke server…

Versi baru sudah menerima 100% traffic, lalu error mulai bermunculan. Tinggal jalankan kembali versi lama dan semuanya beres? Belum tentu. Rollback bukan sekadar menekan tombol “undo” atau mengembalikan source code. Tim harus tahu last known good version, memiliki image atau artifact yang jelas…

Tim mau rilis versi baru. Tapi matiin versi lama dulu berarti ada jeda downtime. Gimana caranya ganti versi tanpa pengguna sempat lihat error sedikit pun? 🤔 Jawabannya: jangan pernah matiin sesuatu yang masih dibutuhkan sebelum penggantinya bener-bener siap. Dua strategi yang paling umum dipakai…

Aplikasi udah di scale jadi 5 instance. Semuanya jalanin kode yang sama. Tapi begitu buka website, request kamu sebenarnya diterima yang mana? 🤔 Tanpa yang ngatur, penambahan instance itu sia-sia. Traffic bisa aja numpuk cuma di satu container, sementara yang lain nganggur. Di sinilah load…