វិស្វករ​ម្នាក់​បាន​លុប​មូលដ្ឋាន​ទិន្នន័យ​ផលិតកម្ម​របស់ GitLab។ ៣០០ ជីហ្គាបៃ។

អ្វីដែលវីដេអូនេះគ្របដណ្ដប់

• ថ្ងៃទី 31 មករា ឆ្នាំ 2017: rm -Rvf លើថតទិន្នន័យ primary; ~300 GB ត្រូវបានលុប, នៅសល់ 4.5 GB
• ការបម្រុងទុក 5 ក្នុងចំណោម 5 បរាជ័យ: S3 bucket ទទេ (pg_dump កំណែមិនត្រូវគ្នា), គ្មាន Azure snapshots នៅលើ DB, replica ត្រូវបានលុប, daily LVM copy ដោយគ្មាន webhooks
• ថ្ងៃទី 1 កុម្ភៈ, ម៉ោង 18:00 ម៉ោង UTC: GitLab.com ត្រឡប់មកវិញពី snapshot manual អាយុ 6 ម៉ោង; ឯកសារផ្ទាល់, ផ្សាយផ្ទាល់, ការសង្កេតក្រោយហេតុការណ៍ដោយគ្មានការស្តីបន្ទោសជាមួយនឹងបញ្ជីកែតម្រូវ

កំណត់ត្រាដែលបានបកប្រែ

បកប្រែចេញពីការនិទានដើមជាភាសាអង់គ្លេស។ សំឡេង និងចំណងជើងរងដែលមានគឺស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់ YouTube។

0:00 វិស្វករម្នាក់នៅ GitLab ដំណើរការ rm -rf នៅលើ server មូលដ្ឋានទិន្នន័យខុស, ហើយបីរយជីហ្គាបៃនៃ GitLab.com បានបាត់ក្នុងរយៈពេលមួយ ឬពីរវិនាទី, ប្រហែលជាពេលវេលាដែលត្រូវការដើម្បីអានឈ្មោះ host។ ថ្ងៃទី 31 ខែមករា ឆ្នាំ 2017 ម៉ោង 11:27 យប់។ UTC។ GitLab tweets ថាខ្លួនបានលុបទិន្នន័យផលិតកម្មដោយចៃដន្យ, បើកកំណត់ត្រាឧប្បត្តិហេតុរបស់ខ្លួនទៅកាន់អ៊ីនធឺណិត ហើយផ្សាយផ្ទាល់ការស្តារឡើងវិញនៅលើ YouTube, ការផ្សាយផ្ទាល់លេខពីរនៅលើវេទិកា។ ថ្ងៃបន្ទាប់ ជាលាយលក្ខណ៍អក្សរ: ក្នុងចំណោមបច្ចេកទេសបម្រុងទុកប្រាំ,

0:25 គ្មានមួយណាដំណើរការគួរឱ្យទុកចិត្តទេ។ តើវាកើតឡើងដោយរបៀបណា ហេតុអ្វីបានជាវាអាចទៅរួច និងអ្នកណាពិតជាត្រូវស្តីបន្ទោស។ នេះគឺជា The Daily Diff, postmortem។ ម៉ោង 5:20 រសៀល: វិស្វករថតរូបផលិតកម្ម ដើម្បីសាកល្បង load balancer នៅក្នុង staging។ ម៉ោង 7 យប់: សារឥតបានការវាយលុកមូលដ្ឋានទិន្នន័យ, បូករួមទាំងការងារលុបបុគ្គលិក GitLab ម្នាក់ដោយផ្ទាល់ ដែល troll រាយការណ៍ពីការរំលោភបំពាន។ ម៉ោង 11 យប់: replica ធ្លាក់យឺតរហូតដល់ primary បានបោះបង់ចោលរួចហើយ

0:48 log ដែលវាត្រូវការ; ដំណោះស្រាយតែមួយគត់គឺត្រូវលុប replica ហើយចម្លង primary ម្តងទៀត។ pg_basebackup ព្យួរដោយគ្មានលទ្ធផល។ វាពិតជាកំពុងរង់ចាំដោយស្ងៀមស្ងាត់សម្រាប់ primary; គ្មាននរណាម្នាក់ដឹងនោះទេ, ហើយ runbook មិនបាននិយាយទេ។ វិស្វករដែលចង់ចុះហត្ថលេខានៅម៉ោង 11 យប់ សម្រេចចិត្តថាថតទិន្នន័យទទេ គឺជាបញ្ហាហើយលុបវាចេញ។ នៅលើ db1។ The primary។ គាត់កត់សម្គាល់មួយឬពីរវិនាទីក្រោយមក; ក្នុងចំណោមប្រហែលបីរយជីហ្គាបៃ,

1:11 នៅសល់ 4.5។ ការបម្រុងទុក។ ទីមួយ: pg_dump ទៅ S3, ប្រចាំថ្ងៃ។ bucket គឺទទេ។ cron job ដំណើរការលើ app server ដោយគ្មានមូលដ្ឋានទិន្នន័យ ដូច្នេះ package ជ្រើសរើស PostgreSQL 9.2 binaries សម្រាប់មូលដ្ឋានទិន្នន័យ 9.6, បរាជ័យ, ហើយផ្ញើអ៊ីមែល ការបរាជ័យ, ដែលត្រូវបានលោតដោយសារ DMARC បាត់។ ទីពីរ: Azure disk snapshots, បានបើកសម្រាប់ file servers, មិនមែនមូលដ្ឋានទិន្នន័យទេ។

1:32 ទីបី: replica, បានលុបដោយចេតនាមួយម៉ោងមុន។ ទីបួន: snapshot ប្រចាំថ្ងៃ, អាយុ 24 ម៉ោង, webhooks ទាំងអស់ត្រូវបានលុបដោយ ការ sync staging។ ទីប្រាំ: snapshot manual ពីម៉ោង 5:20, សម្រាប់ការសាកល្បងដែលមិនទាក់ទង។ មួយនោះឈ្នះ។ ការស្តារឡើងវិញមានន័យថាចម្លង staging disk ត្រឡប់ទៅផលិតកម្មលើ Azure's cheap storage នៅហុកសិបមេហ្គាប៊ីតក្នុងមួយវិនាទី: ដប់ប្រាំបីម៉ោង។ GitLab.com ត្រឡប់មកវិញនៅថ្ងៃទី 1 ខែកុម្ភៈ ម៉ោងប្រាំមួយល្ងាច ម៉ោង UTC, ទិន្នន័យចាស់ជាងប្រាំមួយម៉ោង។

1:58 git blame: ឈ្មោះ host ពីរខុសគ្នាត្រឹមមួយតួអក្សរ, និងប្រព័ន្ធបម្រុងទុកប្រាំដែលគ្មាននរណាម្នាក់ ធ្លាប់បានស្តារពី។ មិនមែនវិស្វករនោះទេ។ postmortem ដែលចុះហត្ថលេខាដោយ CEO រក្សាគាត់ជាអនាមិក, ដាក់ពណ៌ក្រហមទៅលើ production prompt, ហើយផ្តល់ឱ្យ data durability ជាម្ចាស់, ព្រោះរហូតមកដល់ពេលនេះវាមិនមានទេ។ Blast radius: បិទដប់ប្រាំបីម៉ោង, ទិន្នន័យបាត់ប្រាំមួយម៉ោង, ប្រហែលប្រាំពាន់គម្រោង, ប្រាំពាន់ comment,

2:18 អ្នកប្រើប្រាស់ថ្មីប្រាំពីររយនាក់, និងប្រាំពាន់នាក់កំពុងមើល progress bar។ Hacker News ផ្តល់ឱ្យ live doc 1,162 ពិន្ទុ និងដកស្រង់មួយ បន្ទាត់ត្រឡប់ទៅពួកគេវិញ: ក្នុងចំណោមការបម្រុងទុកប្រាំ, គ្មានមួយ។ សាលក្រម, postmortem: SHIP IT, លើការឆ្លើយតប។ ពួកគេដំណើរការឧប្បត្តិហេតុជាសាធារណៈ, ទម្លាក់កំហុសលើដំណើរការ, និងបោះពុម្ពបញ្ជីកែតម្រូវ ជាមួយលេខ issue។ សកម្មភាពថ្ងៃច័ន្ទ: ស្តារការបម្រុងទុក។ ប្រសិនបើអ្នកមិនធ្លាប់បានស្តារវាទេ អ្នកមិនមានវាទេ។

2:42 ផ្ញើមកខ្ញុំនូវឧប្បត្តិហេតុដែលអ្នកនៅតែមិនត្រូវបានអនុញ្ញាតឱ្យនិយាយអំពី, នៅក្នុង comments, ឬនៅ the daily diff dot dev។ ហើយនោះគឺជា diff សម្រាប់ថ្ងៃនេះ។ ខ្ញុំ Niko មកពី Axrisi។ បញ្ចូលដោយការទទួលខុសត្រូវ។

ប្រភព

1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
4. @gitlabstatus, emergency maintenance noticetwitter.com
5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
6. Hacker News, the postmortem thread (377 points)news.ycombinator.com