Habr របាយការណ៍ postmortem: វាបានធ្លាក់នៅលើកាសែតមួយ។

ចុងបញ្ចប់នៃខែទីមួយ និងដើមខែទីពីរនៃរដូវក្តៅឆ្នាំ 2019 ប្រែទៅជាពិបាក ហើយត្រូវបានសម្គាល់ដោយការធ្លាក់ចុះសំខាន់ៗមួយចំនួននៅក្នុងសេវាកម្ម IT សកល។ ក្នុងចំណោមរឿងដែលគួរឲ្យកត់សម្គាល់៖ ឧប្បត្តិហេតុធ្ងន់ធ្ងរពីរនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ CloudFlare (ទីមួយ - ដោយដៃកោង និងអាកប្បកិរិយាធ្វេសប្រហែសចំពោះ BGP នៅលើផ្នែកនៃ ISPs មួយចំនួនមកពីសហរដ្ឋអាមេរិក។ ទីពីរ - ជាមួយនឹងការដាក់ពង្រាយ CF ដោយខ្លួនឯង ដែលប៉ះពាល់ដល់មនុស្សគ្រប់គ្នាដែលប្រើ CF ហើយទាំងនេះគឺជាសេវាកម្មគួរឱ្យកត់សម្គាល់ជាច្រើន) និងប្រតិបត្តិការមិនស្ថិតស្ថេរនៃហេដ្ឋារចនាសម្ព័ន្ធ Facebook CDN (ប៉ះពាល់ដល់ផលិតផល FB ទាំងអស់ រួមទាំង Instagram និង WhatsApp) ។ យើងក៏ត្រូវចាប់យកការចែកចាយផងដែរ បើទោះបីជាការដាច់ចរន្តអគ្គិសនីរបស់យើងមិនសូវគួរឱ្យកត់សម្គាល់ធៀបនឹងផ្ទៃខាងក្រោយសកលក៏ដោយ។ មាននរណាម្នាក់បានចាប់ផ្តើមអូសឧទ្ធម្ភាគចក្រខ្មៅ និងការឃុបឃិតគ្នា "អធិបតេយ្យ" រួចហើយ ដូច្នេះយើងកំពុងបញ្ចេញការសន្និដ្ឋានជាសាធារណៈអំពីឧប្បត្តិហេតុរបស់យើង។

03.07.2019, 16: 05
បញ្ហាជាមួយធនធានបានចាប់ផ្តើមត្រូវបានកត់ត្រា ស្រដៀងទៅនឹងការវិភាគនៃការតភ្ជាប់បណ្តាញខាងក្នុង។ ដោយមិនបានត្រួតពិនិត្យគ្រប់អ្វីៗទាំងអស់ ពួកគេចាប់ផ្តើមមានកំហុសលើដំណើរការនៃបណ្តាញខាងក្រៅឆ្ពោះទៅកាន់ DataLine ដូចដែលវាច្បាស់ថាបញ្ហាគឺដោយសារការចូលប្រើអ៊ីនធឺណិតរបស់បណ្តាញខាងក្នុង (NAT) ដល់ចំណុចនៃការដាក់សម័យ BGP ឆ្ពោះទៅកាន់ DataLine ។

03.07.2019, 16: 35
វាច្បាស់ណាស់ថាឧបករណ៍ដែលផ្តល់ការបកប្រែអាសយដ្ឋានបណ្តាញ និងការចូលប្រើពីបណ្តាញមូលដ្ឋានរបស់គេហទំព័រទៅអ៊ីនធឺណិត (NAT) បានបរាជ័យ។ ការព្យាយាមចាប់ផ្ដើមឧបករណ៍ឡើងវិញមិនបាននាំឱ្យមានអ្វីនោះទេ ការស្វែងរកជម្រើសជំនួសសម្រាប់ការរៀបចំការតភ្ជាប់បានចាប់ផ្តើម មុនពេលទទួលបានការឆ្លើយតបពីការគាំទ្រផ្នែកបច្ចេកទេស ដោយសារបទពិសោធន៍ នេះទំនងជាមិនអាចជួយបានទេ។

បញ្ហាគឺកាន់តែធ្ងន់ធ្ងរទៅៗ ដោយសារឧបករណ៍នេះក៏បានបិទការតភ្ជាប់ចូលរបស់បុគ្គលិក VPN របស់អតិថិជន ហើយការងារសង្គ្រោះពីចម្ងាយកាន់តែពិបាកអនុវត្ត។

03.07.2019, 16: 40
យើងបានព្យាយាមស្តារឡើងវិញនូវគ្រោងការណ៍ NAT បម្រុងទុកដែលមានស្រាប់ពីមុន ដែលដំណើរការល្អពីមុនមក។ ប៉ុន្តែវាច្បាស់ណាស់ថាការជួសជុលបណ្តាញមួយចំនួនបានធ្វើឱ្យគ្រោងការណ៍នេះស្ទើរតែមិនអាចដំណើរការបានទាំងស្រុង ចាប់តាំងពីការស្ដារឡើងវិញរបស់វាអាចល្អបំផុត មិនដំណើរការ ឬអាក្រក់បំផុត បំបែកអ្វីដែលកំពុងដំណើរការ។

យើងបានចាប់ផ្តើមធ្វើការលើគំនិតមួយចំនួនដើម្បីផ្ទេរចរាចរទៅកាន់សំណុំនៃរ៉ោតទ័រថ្មីដែលបម្រើដល់ឆ្អឹងខ្នង ប៉ុន្តែពួកគេហាក់ដូចជាមិនអាចដំណើរការបានដោយសារតែភាពប្លែកនៃការបែងចែកផ្លូវនៅក្នុងបណ្តាញស្នូល។

03.07.2019, 17: 05
ក្នុងពេលជាមួយគ្នានេះ បញ្ហាមួយត្រូវបានគេរកឃើញនៅក្នុងយន្តការដោះស្រាយឈ្មោះនៅលើម៉ាស៊ីនមេ ដែលនាំឱ្យមានកំហុសក្នុងការដោះស្រាយចំណុចបញ្ចប់នៅក្នុងកម្មវិធី ហើយពួកគេបានចាប់ផ្តើមបំពេញឯកសារម៉ាស៊ីនយ៉ាងលឿនជាមួយនឹងកំណត់ត្រានៃសេវាកម្មសំខាន់ៗ។

03.07.2019, 17: 27
មុខងារមានកំណត់របស់ Habr ត្រូវបានស្ដារឡើងវិញ។

03.07.2019, 17: 43
ប៉ុន្តែនៅទីបញ្ចប់ ដំណោះស្រាយសុវត្ថិភាពមួយត្រូវបានរកឃើញសម្រាប់ការរៀបចំចរាចរណ៍តាមរយៈរ៉ោតទ័រព្រំដែនមួយដែលត្រូវបានដំឡើងយ៉ាងឆាប់រហ័ស។ ការភ្ជាប់អ៊ីនធឺណិតត្រូវបានស្ដារឡើងវិញ។

ក្នុងរយៈពេលប៉ុន្មាននាទីបន្ទាប់ ការជូនដំណឹងជាច្រើនបានមកពីប្រព័ន្ធត្រួតពិនិត្យអំពីការស្ដារមុខងាររបស់ភ្នាក់ងារត្រួតពិនិត្យឡើងវិញ ប៉ុន្តែសេវាកម្មមួយចំនួនបានប្រែទៅជាមិនអាចដំណើរការបាន ដោយសារយន្តការដោះស្រាយឈ្មោះនៅលើម៉ាស៊ីនមេឈ្មោះ (dns) ត្រូវបានខូច។

03.07.2019, 17: 52
NS ត្រូវបានចាប់ផ្តើមឡើងវិញ ហើយឃ្លាំងសម្ងាត់ត្រូវបានសម្អាត។ ការដោះស្រាយត្រូវបានស្ដារឡើងវិញ។

03.07.2019, 17: 55
សេវាកម្មទាំងអស់បានចាប់ផ្តើមដំណើរការ លើកលែងតែ MK, Freelansim និង Toaster ។

03.07.2019, 18: 02
MK និង Freelansim បានចាប់ផ្តើមធ្វើការ។

03.07.2019, 18: 07
នាំយកវគ្គ BGP ដែលគ្មានកំហុសជាមួយ DataLine មកវិញ។

03.07.2019, 18: 25
ពួកគេបានចាប់ផ្តើមកត់ត្រាបញ្ហាជាមួយធនធាន ដែលបណ្តាលមកពីការផ្លាស់ប្តូរអាសយដ្ឋានខាងក្រៅនៃអាង NAT និងអវត្តមានរបស់វានៅក្នុង acl នៃសេវាកម្មមួយចំនួន ដែលត្រូវបានកែតម្រូវភ្លាមៗ។ Toaster ចាប់ផ្តើមដំណើរការភ្លាមៗ។

03.07.2019, 20: 30
យើងបានកត់សម្គាល់ឃើញកំហុសទាក់ទងនឹង Telegram bots ។ វាបានប្រែក្លាយថាពួកគេភ្លេចចុះឈ្មោះអាសយដ្ឋានខាងក្រៅនៅក្នុង acl ពីរ (ម៉ាស៊ីនមេប្រូកស៊ី) ដែលត្រូវបានកែតម្រូវភ្លាមៗ។

ការរកឃើញ

• គ្រឿងបរិក្ខារដែលពីមុនបានសាបព្រួសការសង្ស័យអំពីភាពសមស្របរបស់វា បានបរាជ័យ។ មានគម្រោងលុបវាចេញពីការងារ ព្រោះវារំខានដល់ការអភិវឌ្ឍន៍បណ្តាញ និងមានបញ្ហាភាពឆបគ្នា ប៉ុន្តែនៅពេលជាមួយគ្នានោះ វាបានអនុវត្តមុខងារសំខាន់ ដែលជាមូលហេតុដែលការជំនួសណាមួយមានការលំបាកផ្នែកបច្ចេកទេសដោយមិនរំខានដល់សេវាកម្ម។ ឥឡូវនេះអ្នកអាចបន្តទៅមុខទៀត។
• បញ្ហា DNS អាចត្រូវបានជៀសវាងដោយការផ្លាស់ទីពួកវាទៅជិតបណ្តាញឆ្អឹងខ្នងថ្មីនៅខាងក្រៅបណ្តាញ NAT ហើយនៅតែមានការតភ្ជាប់ពេញលេញទៅបណ្តាញពណ៌ប្រផេះដោយគ្មានការបកប្រែ (ដែលជាផែនការមុនពេលកើតហេតុ)។
• អ្នកមិនគួរប្រើឈ្មោះដែននៅពេលដំឡើងចង្កោម RDBMS ទេព្រោះភាពងាយស្រួលនៃការផ្លាស់ប្តូរអាសយដ្ឋាន IP ប្រកបដោយតម្លាភាពគឺមិនចាំបាច់ជាពិសេសទេ ដោយសារឧបាយកលបែបនេះនៅតែទាមទារឱ្យមានការបង្កើតចង្កោមឡើងវិញ។ ការ​សម្រេច​ចិត្ត​នេះ​ត្រូវ​បាន​កំណត់​ដោយ​ហេតុផល​ប្រវត្តិសាស្ត្រ និង​ជា​ដំបូង​នៃ​ការ​ទាំងអស់​ដោយ​ភាព​ច្បាស់​លាស់​នៃ​ចំណុច​បញ្ចប់​តាម​ឈ្មោះ​ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ RDBMS ។ ជាទូទៅអន្ទាក់បុរាណ។
• ជាគោលការណ៍ លំហាត់ដែលអាចប្រៀបធៀបទៅនឹង "អធិបតេយ្យភាពនៃ Runet" ត្រូវបានធ្វើឡើង។

ប្រភព: www.habr.com