Laporan Insiden: Railway Diblokir oleh Google Cloud [Terselesaikan]

 (status.railway.com)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Gangguan layanan besar-besaran pada Railway telah terselesaikan, dan penyebabnya dikonfirmasi sebagai pemblokiran akun Google Cloud milik Railway
  • Selama gangguan, pengguna dapat mengalami "no healthy upstream", "unconditional drop overload", gagal login, dan tidak bisa mengakses dashboard
  • Railway berkomunikasi langsung dengan tim dukungan Google Cloud untuk memulihkan akses akun, lalu melanjutkan pemulihan control plane dan workload
  • Dalam proses pemulihan, masih ada masalah jaringan di Google Cloud yang membuat beberapa layanan gagal dijalankan, dan build non-enterprise dibatasi sementara
  • Layanan telah pulih sepenuhnya, tetapi sebagian workload yang terdeteksi abnormal sedang dideploy ulang secara otomatis, dan bila perlu pengguna harus melakukan redeploy sendiri

Ringkasan gangguan dan status akhir

  • Railway telah menyelesaikan gangguan layanan berskala luas, dan analisis pascakejadian dapat dilihat di Incident Report
  • Selama periode gangguan, pengguna dapat mengalami "no healthy upstream", "unconditional drop overload", gagal login, dan tidak bisa mengakses dashboard
  • Penyebabnya adalah pemblokiran akun Google Cloud milik Railway, yang membuat sebagian layanan Railway tidak tersedia
  • Railway berkomunikasi langsung dengan tim dukungan Google Cloud untuk memulihkan akses akun dan melanjutkan pemulihan workload
  • Layanan telah pulih sepenuhnya, tetapi sebagian workload yang terdeteksi dalam kondisi abnormal sedang dideploy ulang secara otomatis, dan layanan yang responsnya belum normal mungkin perlu dideploy ulang secara manual oleh pengguna

Perkembangan pemulihan dan dampak terhadap pengguna

  • Investigasi awal dan konfirmasi penyebab

    • Railway memulihkan infrastruktur Google Cloud yang menjalankan control plane untuk dashboard, API, dan jaringan internal
    • Setelah akses ke penyedia cloud hulu dipulihkan, dashboard Railway dan layanan yang berjalan di infrastruktur cloud masih dapat terus terdampak sampai deployment perbaikan dilakukan
    • Setelah pemblokiran akun Google Cloud, tim platform Railway memverifikasi akses ke sebagian infrastruktur yang dihosting di Google Cloud dan memulihkan akses ke layanan lainnya

  • Google Cloud dan masalah jaringan

    • Railway memulihkan compute di Google Cloud, tetapi masalah jaringan di sisi Google Cloud masih tersisa sehingga beberapa layanan tidak dapat dimulai
    • Selama pemulihan, workload yang dihosting di Google Cloud masih dapat mengalami masalah secara intermiten
    • Tim infrastruktur Railway juga meninjau jalur alternatif untuk mengembalikan layanan yang terdampak ke status online

  • Pembatasan build dan deployment

    • Workload metal Railway mulai pulih secara bertahap
    • Selama proses pemulihan, semua build non-enterprise dibatasi sementara untuk menghindari kelebihan beban pada infrastruktur build
    • Setelah itu, deployment non-enterprise tetap dalam keadaan dihentikan sementara, sementara deployment enterprise tidak terdampak
    • Bahkan setelah deployment kembali dimungkinkan, workload yang masih berada di Google Cloud dapat terus mengalami masalah intermiten hingga pemulihan selesai

  • Tindakan saat ini

    • Layanan Railway telah pulih sepenuhnya, dan layanan yang responsnya belum normal harus dideploy ulang melalui dashboard atau CLI
    • Konteks tambahan dapat dilihat di FAQ, dan jika memerlukan dukungan langsung, Anda dapat membuka thread di Railway Station

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Railway sudah menyelesaikan insiden ini dan merilis analisis pascainsiden
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    Per halaman status, pembaruan juga sudah muncul per 20 Mei 07:57 UTC
    https://status.railway.com/incident/I23M92U0

    • Dalam kasus seperti ini, menurut saya menuntut ganti rugi dari Google seharusnya dimungkinkan. Ini bukan masalah yang wajar masuk ke dalam syarat layanan seperti gangguan jaringan atau kegagalan layanan
    • Railway bilang insiden sudah selesai, tetapi banyak layanan masih down dan mengembalikan 502. Di pihak kami, pemulihan baru terjadi setelah kami memicu redeploy secara manual, dan menurut saya Railway seharusnya melakukannya otomatis
      Total downtime di pihak kami lebih dari 11 jam

  • Hari ke-0 sejak GCP menjatuhkan startup lain lagi
    Rasanya saya melihat kejadian seperti ini setidaknya setahun sekali, dan saya belum pernah mendengar hal seperti ini terjadi di AWS atau Azure
    Jujur saja, itulah alasan saya tidak memakai GCP. Ini cloud yang paling enak dipakai di antara tiga besar, tapi mereka merusak diri sendiri dengan reputasi seperti ini

    • Sebaliknya, saya justru tidak terlalu ingat kapan terakhir GCP mengalami outage besar. AWS/Azure rasanya beberapa kali setahun mengalami kejadian yang benar-benar katastrofik
    • AWS melakukannya dengan lebih efisien. Kalau us-east-1 tumbang, mereka bisa menjatuhkan banyak startup sekaligus
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure juga tahun lalu sempat merusak front door untuk seluruh layanan Azure dan O365
      Perusahaan-perusahaan ini masing-masing punya bidang yang mereka kuasai, tapi sesekali mereka gagal besar
    • AWS pernah throttling layanan kami sampai separah itu sehingga tidak bisa dioperasikan. Saya sempat ingin menulis tentang bagaimana mereka menghentikan pertumbuhan kami selama sebulan, tetapi sekarang rasanya tidak terlalu penting lagi
    • Kami juga tidak menyentuh GCP karena alasan yang sama

  • Semua orang ingin menyalahkan Google, tetapi sebagai orang yang sudah cukup lama memakai Railway, saya ingin mendengar versi GCP juga sebelum menarik kesimpulan. Railway juga pernah punya masalah seperti ini sebelumnya, dan cara tim mereka menanganinya tidak memberi rasa percaya
    Bagaimanapun juga, ini adalah batas terakhir bagi saya

    • Saya juga setuju, walau cuma anekdotal. Tim developer Railway terasa bergerak agak serampangan, mencampur vibe coding di sana-sini. Ada batas untuk “maklumi saja, mereka masih startup”, dan Railway sudah melewati batas itu
    • Betul. Di thread lain saya melihat banyak akun yang sangat keras mengkritik penyedia cloud, tetapi anehnya di tengah arus kemarahan ini hampir tidak ada yang penasaran soal akar penyebabnya atau mau mempertimbangkan kemungkinan itu
    • Dua tahun lalu saya butuh dukungan mereka, pengalaman itu begitu buruk sampai saya pindah ke Vercel dan menyuruh mereka pergi saja
      Saat mencari sesuatu yang mirip untuk layanan lain, saya menemukan coolify. Kalau bisa pakai coolify, tidak ada alasan sama sekali memakai Railway
    • Kalau ada contoh kasus masa lalu yang spesifik, saya ingin membacanya
    • Saya mendengar detail yang seharusnya tidak saya ketahui. Saya bisa bilang dengan yakin ini 100% salah Google, dan saya akan kecewa kalau Railway tidak bisa membagikan lebih banyak
      Selain menghindari GCP sepenuhnya, benar-benar tidak ada yang bisa dilakukan Railway untuk mencegah ini

  • Ada juga insiden UniSuper pada Mei 2024: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Menurut pernyataan bersama CEO UniSuper Peter Chun dan CEO Google Cloud Thomas Kurian, terjadi kesalahan konfigurasi yang ceroboh saat memprovisikan layanan Private Cloud UniSuper, dan pada akhirnya langganan Private Cloud UniSuper terhapus
    Google Cloud mengatakan ini adalah insiden terisolasi yang “hanya sekali seumur hidup”, belum pernah terjadi sebelumnya pada pelanggan Google Cloud mana pun di dunia, tetapi penghapusan langganan ini memicu penghapusan di kedua region sehingga pemulihannya memerlukan restorasi ratusan VM, database, dan aplikasi

    • Saya sempat menulis tentang masalah UniSuper saat itu: https://danielcompton.net/google-cloud-unisuper
      Itu bug yang cukup serius, dan lingkungan VMWare mereka dibuat dengan tanggal kedaluwarsa 1 tahun, yang dari sudut pandang Google Cloud dianggap sebagai satu “resource”
    • “Penghapusan langganan Private Cloud memicu penghapusan di kedua region” adalah apa yang disebut single point of failure, dan siapa pun yang pernah bertanggung jawab atas keselamatan akan menganggapnya sebagai mimpi buruk
    • Struktur yang langsung memicu penghapusan berantai secara global begitu sebuah langganan ditutup atau dihapus terdengar seperti resep bencana. Saya tidak paham kenapa tidak cukup ditandai untuk dihapus lalu benar-benar dihapus sehari atau seminggu kemudian

  • Saya tidak mengerti bagaimana hal seperti ini bisa terjadi pada perusahaan dengan tagihan bulanan sebesar itu. Di tempat kerja lama, ketika ada workload mencurigakan berjalan di AWS, TAM kami menghubungi dulu sebelum mengambil tindakan
    Dugaan saya, ini semacam otomasi AI yang salah jalan, dan GCP tampaknya tidak suka benar-benar menghubungi manusia dan menerima respons, jadi mungkin baru beberapa jam kemudian ada kontraktor outsourcing yang melihatnya di antrean dukungan dan mengirim jawaban template

    • Kalau soal support GCP, sekarang tidak ada lagi yang bisa mengejutkan saya. Kami sama sekali tidak membutuhkannya, tetapi dalam 6 tahun terakhir kami sudah ganti Account Executive lebih dari 12 kali, dan semuanya benar-benar tidak berguna
      Setiap kali mereka memperkenalkan diri, minta dijadwalkan pertemuan dengan tim engineering kami, lalu datang dengan slide deck template yang sama sekali tidak relevan untuk kami sehingga terasa lucu, dan kontak berikutnya baru terjadi saat AE baru ditugaskan
      Saya suka GCP dan layanan-layanannya, dan sudah puas selama bertahun-tahun, tetapi sisi manusianya benar-benar buruk dan saya tidak paham kenapa mereka repot menjalankannya
    • Sepertinya ada jawaban yang bermakna di thread lain juga. Kami juga akhirnya mendapatkan kembali akun kami, tetapi bahkan dengan Account Rep dan CSM, tetap butuh waktu untuk memahami apa yang sebenarnya terjadi
      Tanpa orang-orang itu, mungkin situasinya akan lebih buruk
    • Ya begitulah Google. Mereka membiarkanmu memakai layanannya, lalu begitu kamu menyimpang dari norma, kamu ditangguhkan

  • Dari sudut pandang orang yang mengelola API publik, spam dari IP Railway sangat tidak masuk akal banyaknya. Pencegahan penyalahgunaannya buruk sekali, dan semoga kejadian ini jadi pemicu untuk memperbaiki operasional mereka

    • Dulu saat saya menjalankan perusahaan hosting, inilah konflik utamanya. Kalau pendaftaran dibuat mudah, pengguna baru akan banyak masuk, tapi penyalahgunaan juga ikut masuk
      Kalau kamu memasang langkah pencegahan abuse, akan muncul false positive yang berisik, dan kejadian GCP kali ini bisa saja termasuk itu
      Saya tidak iri pada siapa pun yang menjalankan perusahaan hosting. Internet itu benar-benar kotor di balik permukaannya
      Tambahan lagi, AWS sangat bagus dalam hal ini. Mungkin karena pengalaman sekitar 30 tahun menghadapi penipuan ritel dan abuse

  • Tunggu, Railway ternyata berjalan di atas GCP? Bukankah mereka pernah sangat lantang bilang “kami tidak membangun cloud di atas cloud lain”?
    Atau maksudnya mereka hanya menyewa bare metal dari penyedia cloud, bukan menyewa VPS?
    Setidaknya saya sempat berharap ada penyedia lain yang bukan sekadar membayar salah satu hyperscaler, tetapi melakukan colocation dan memiliki lebih banyak dari stack-nya sendiri
    https://blog.railway.com/p/heroku-walked-railway-run

    • Di artikel tertaut yang dilihat lewat Wayback Machine tertulis seperti ini
      “Sejak hari pertama, kami menempatkan ide ini di garis depan.
      Hal lain yang kami sadari secara intuitif adalah bahwa Anda tidak bisa membangun cloud di atas cloud lain. Demi membuat bisnis Railway, dan pada akhirnya bisnis pelanggan kami, sekuat mungkin, kami menghabiskan waktu bertahun-tahun menjalankan server sendiri dan mengerjakan praktik yang memungkinkan kami hidup berdampingan dengan baik bersama cloud lain.”
    • Benar, dan itu yang membuat saya marah. Mereka bohong. Mereka ternyata sepenuhnya bergantung pada GCP
      Sekarang saya harus melakukan riset. Saya butuh sesuatu yang lebih stabil daripada ini, dan yang tidak terlalu bergantung pada perubahan sikap satu perusahaan
      Dari sudut pandang Railway, ini juga buruk karena langsung menusuk inti klaim besar mereka tentang deployment software yang damai. Ini kekacauan

  • Saya kira Railway sedang membangun data center sendiri [0]
    “Secara praktis, Anda tidak bisa membangun cloud di atas cloud milik orang lain.”
    Ternyata memang begitu…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel tampaknya berhasil melakukannya. PlanetScale juga begitu, setidaknya untuk database, dan toh pada akhirnya semuanya adalah database

  • Saat mendaftar ke Railway, ada cara yang agak unik untuk memastikan Anda sudah membaca dan memahami syarat tentang penyalahgunaan sistem, penambangan kripto, dan semacamnya
    Dugaan saya, banyak pengguna yang menyalahgunakan free tier sehingga menimbulkan masalah dengan penyedia layanan mereka
    Bahkan sebagai pesaing, saya tidak senang melihat Railway kena pukulan seperti ini, tetapi komputasi gratis memang menarik banyak pengguna aneh. Kami juga pernah mengalaminya, dan kami memilih menghindari komputasi gratis sejak awal meskipun itu mengurangi top-of-funnel

  • Menurut saya sulit menyalahkan Google saja. Railway tampaknya makin kesulitan menjaga stabilitas platform
    Hal seperti ini seharusnya tidak menjatuhkan seluruh layanan. Jika bisnis Anda memang menyediakan backend yang stabil, harusnya ada cadangan. Di mata saya ini terlihat seperti perencanaan yang buruk

    • Saya kurang paham maksudnya. Apakah Anda benar-benar berharap Railway memakai arsitektur multi-cloud untuk meng-host semua proyek pelanggannya? Kalau dilihat secara keseluruhan, menurut saya itu justru akan menurunkan availability
    • Bukankah disaster recovery cukup mahal? Terutama untuk skala seperti Railway?