Seorang jurutera memadam pangkalan data pengeluaran GitLab. 300 gigabait.
31 Januari 2017, 23:27 UTC: seorang jurutera GitLab, bergelut dengan replika yang rosak pada penghujung malam yang panjang, memadam direktori data PostgreSQL di db1 dan bukannya db2.
31 Januari 2017, 23:27 UTC: seorang jurutera GitLab, bergelut dengan replika yang rosak pada penghujung malam yang panjang, memadam direktori data PostgreSQL di db1 dan bukannya db2. db1 adalah yang utama. Kira-kira 300 GB pangkalan data GitLab.com hilang dalam satu atau dua saat, dan daripada lima mekanisme sandaran dan replikasi, tiada satu pun yang berfungsi. Postmortem: garis masa dari lonjakan spam ke nama hos yang salah, mengapa pg_basebackup kelihatan tersekat, mengapa pg_dump telah gagal secara senyap (binari 9.2 pada pangkalan data 9.6, e-mel kegagalan melantun oleh DMARC), pemulihan 18 jam dari "snapshot" "staging" 6 jam yang disiarkan secara langsung di YouTube, dan siapa yang benar-benar dipersalahkan. Keputusan mengenai respons: SHIP IT.
Baca edisi bertulis (Bahasa Inggeris) ↗
Apa yang diliputi video ini
- 31 Jan 2017: rm -Rvf pada direktori data utama; ~300 GB dikeluarkan, 4.5 GB tinggal
- 5 daripada 5 sandaran gagal: "bucket" S3 kosong (ketidakpadanan versi pg_dump), tiada "snapshot" Azure pada DB, replika dipadam, salinan LVM harian tanpa "webhook"
- 1 Feb, 18:00 UTC: GitLab.com kembali dari "snapshot" manual 6 jam; dokumen langsung, strim langsung, "postmortem" tanpa menyalahkan dengan senarai pembetulan
Transkrip terjemahan
Diterjemahkan daripada penceritaan asal Bahasa Inggeris. Audio dan kapsyen yang tersedia dikawal oleh YouTube.
0:00 Seorang jurutera di GitLab menjalankan rm -rf pada pelayan pangkalan data yang salah, dan tiga ratus gigabait GitLab dot com lenyap dalam satu atau dua saat, kira-kira berapa lama masa yang diambil untuk membaca nama hos. 31 Januari 2017, 11:27 malam. UTC. GitLab tweet bahawa ia secara tidak sengaja memadam data pengeluaran, membuka nota insidennya kepada internet, dan menyiarkan pemulihan di YouTube, strim langsung nombor dua di platform itu. Keesokan harinya, secara bertulis: daripada lima teknik sandaran,
0:25 tiada satu pun berfungsi dengan pasti. Bagaimana ia berlaku, mengapa ia mungkin, dan siapa sebenarnya yang dipersalahkan. Ini adalah The Daily Diff, postmortem. 5:20 p.m.: seorang jurutera mengambil "snapshot" pengeluaran untuk menguji pengimbang beban dalam "staging". 7 p.m.: spam membanjiri pangkalan data, serta kerja memadam secara "hard" pekerja GitLab a troll melaporkan untuk penyalahgunaan. 11 p.m.: replika jauh ketinggalan sehingga yang utama telah membuang
0:48 log yang diperlukan; satu-satunya penyelesaian adalah untuk memadam replika dan menyalin yang utama lagi. pg_basebackup tergantung tanpa output. Ia sebenarnya menunggu, secara senyap, untuk yang utama; tiada siapa yang tahu itu, dan buku panduan tidak menyatakan. Jurutera, yang sepatutnya "sign off" pada pukul sebelas, memutuskan direktori data kosong adalah masalahnya dan memadamkannya. Di db1. Yang utama. Dia menyedari satu atau dua saat kemudian; daripada kira-kira tiga ratus gigabait,
1:11 4.5 kekal. Sandaran. Satu: pg_dump ke S3, harian. Bucket itu kosong. Tugas "cron" berjalan pada pelayan aplikasi tanpa pangkalan data, jadi pakej memilih binari PostgreSQL 9.2 untuk pangkalan data 9.6, gagal, dan menghantar e-mel kegagalan, yang melantun untuk DMARC yang hilang. Dua: "snapshot" disk Azure, diaktifkan untuk pelayan fail, bukan pangkalan data.
1:32 Tiga: replika, dipadam dengan sengaja sejam yang lalu. Empat: "snapshot" harian, 24 jam yang lalu, setiap "webhook" dilucutkan oleh penyegerakan "staging". Lima: "snapshot" manual dari 5:20, untuk ujian yang tidak berkaitan. Yang itu menang. Memulihkan bermakna menyalin disk "staging" kembali ke pengeluaran melalui storan murah Azure pada enam puluh megabit per saat: lapan belas jam. GitLab dot com kembali 1 Februari pada pukul enam petang. UTC, enam jam data lebih lama.
1:58 git blame: dua nama hos satu karakter berbeza, dan lima sistem sandaran yang tiada siapa pernah pulihkan dari. Bukan jurutera. Postmortem, ditandatangani oleh CEO, menjadikannya tanpa nama, mewarnakan "prompt" pengeluaran merah, dan memberikan ketahanan data pemilik, kerana sehingga kini ia tiada. Radius letupan: lapan belas jam "down", enam jam data hilang, kira-kira lima ribu projek, lima ribu komen,
2:18 tujuh ratus pengguna baru, dan lima ribu orang menonton bar kemajuan. Hacker News memberikan dokumen langsung 1,162 mata dan memetik satu baris kembali kepada mereka: daripada lima sandaran, tiada satu pun. Keputusan, postmortem: SHIP IT, mengenai respons. Mereka menjalankan insiden secara terbuka, menyalahkan proses, dan menerbitkan senarai pembetulan dengan nombor isu. Tindakan Isnin: pulihkan sandaran. Jika anda tidak pernah memulihkannya, anda tidak memilikinya.
2:42 Hantar saya insiden yang anda masih tidak dibenarkan bercakap mengenainya, dalam komen, atau di the daily diff dot dev. Dan itu "diff" untuk hari ini. Saya Niko dari Axrisi. Gabung dengan bertanggungjawab.
Sumber
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
