castomFLOW
បើក castomFLOW

ការដំណើរការដែលអ្នកអាចជឿជាក់បាន

គ្មាននរណាម្នាក់កត់សម្គាល់ automation ទេ រហូតទាល់តែវាបញ្ជូនអ្វីមួយពីរដង

បន្ទាប់មកគ្រប់គ្នាកត់សម្គាល់។ យន្តការទាំងបួននៅលើទំព័រនេះមានឡើង ព្រោះកំហុសនៃ software ប្រភេទនេះគឺជាកំហុសទាំងបួនដូចគ្នារាល់ពេល ហើយទាំងអស់នោះអាចការពារបានដោយការរចនា មិនមែនដោយការប្រុងប្រយ័ត្នទេ។

សាកល្បងមុនពេលបោះពុម្ពផ្សាយ

រុញទិន្នន័យពិតមួយឆ្លងកាត់ workflow ដែលបានបិទ ហើយអានត្រឡប់មកវិញនូវអ្វីដែលនឹងកើតឡើងជាក់ស្តែង៖ ផ្លូវដែលបានជ្រើសរើស, តម្លៃទាំងពួងនៅគ្រប់ជំហាន, ពាក្យសម្តីនៃសារទាំងពួង និងសំណើដែលនឹងបានបញ្ជូនទៅប្រព័ន្ធខាងក្រៅមួយៗ។

គ្មានអ្វីចេញពីអាគារទេ។ គ្មានអ៊ីមែលបញ្ជូន, គ្មានវិក្កយបត្របង្កើត, គ្មានការទារប្រាក់, គ្មានជួរដីសរសេរ។ ការហៅខាងក្រៅត្រូវកត់ត្រាជាចំណង់ចំណូលចិត្ត ជាមួយ payload ដែលនឹងបានបញ្ជូន ដូច្នេះអ្នកអាចមើលឃើញថាតើការ map ត្រឹមត្រូវឬមុនពេលវាក្លាយជាបញ្ហារបស់នរណាម្នាក់។

Simulation គឺជាវិធីដែលអ្នកឆ្លើយសំណួរដែលរារាំងមនុស្សពីការបើក automation៖ វានឹងធ្វើអ្វីជាក់ស្តែង?

Simulation · ការបញ្ជាទិញ 88 214មិនមានអ្វីត្រូវបានផ្ញើទេ
  • 1អាសយដ្ឋានត្រួតពិនិត្យត្រូវគ្នា។ នឹងសរសេរជាទីតាំង 6 ។
  • ?លក្ខខណ្ឌការបញ្ជាទិញលើ 1 000 zł? ទេ — 289,00 zł។ បានជ្រើសរើសផ្លូវខ្លី។
  • 3វិក្កយបត្រនឹងបញ្ជូន POST ទៅប្រព័ន្ធវិក្កយបត្រ។ ទិន្នន័យបង្ហាញពេញលេញ។
  • !បានចាប់នៅទីនេះអត្រាវ៉ាត់ (VAT) បានដាក់ផ្គូផ្គងពីទីតាំងខុស។ រកឃើញក្នុងការធ្វើសម្របសម្រួល មិនមែនក្នុងប្រអប់សាររបស់គណនេយ្យករទេ។

បានបញ្ជូន៖ គ្មានអ្វីទេបានគិតថ្លៃ៖ គ្មានអ្វីទេ

ការដំណើរការនីមួយៗដើរតាមកំណែដែលវាបានចូល

ការបោះពុម្ពផ្សាយការផ្លាស់ប្តូរទៅក្នុង workflow មិនប៉ះពាល់ដល់ការដំណើរការដែលកំពុងស្ថិតក្នុងនោះទេ។ ការដំណើរការនីមួយៗត្រូវបានកំណត់ជាប់ទៅកំណែដែលវាបានចាប់ផ្តើម ហើយបញ្ចប់តាមកំណែនោះ មិនថាវាចំណាយពេលប៉ុន្មាន ឬអ្នកប្រែប្រួលប៉ុន្មានក្នុងរយៈពេលនោះ។

ដូច្នេះ អ្នកអាចរៀបចំ workflow ឡើងវិញខណៈពេលដែលមនុស្សម្ភៃពាន់នាក់កំពុងស្ថិតនៅចំកណ្តាលរបស់វា ហើយម្នាក់ៗនឹងបញ្ចប់លំហូរដែលពួកគេត្រូវបានសន្យា។ ជម្រើសម្ខាងទៀត — ការរចនាដែលផ្លូវទាំងមូលនៅខាងក្រោយត្រូវបានបង្កើតនៅពេលចូល — គឺជាមូលហេតុដែលការកែសម្រួលការធ្វើស្វ័យប្រវត្តិកម្មដែលកំពុងដំណើរការមានអារម្មណ៍ថាមានគ្រោះថ្នាក់ក្នុងឧបករណ៍ភាគច្រើន។ នៅទីនេះ វាមិនមានអ្វីចម្លែកទេ។

ការដំណើរការថ្មីទទួលបានកំណែថ្មីចាប់ពីពេលអ្នកបោះពុម្ពផ្សាយ។ កំណែដែលការដំណើរការណាមួយកំពុងប្រើត្រូវបានកត់ត្រានៅលើការដំណើរការនោះ ដូច្នេះសំណួរអំពីឥរិយាបថក្នុងខែមីនាមានចម្លើយក្នុងខែកញ្ញា។

ការកែសម្រួលខណៈដំណើរការv4 → v5
  • 1មុនពេលការដំណើរការ 2 918 កំពុងដំណើរការ ទាំងអស់នៅលើ v4។ ខ្លះកំពុងរង់ចាំពីរថ្ងៃ។
  • 2បោះពុម្ពផ្សាយ v5ជំហានពីរបានដូរតម្រៀប សារមួយបានសរសេរឡើងវិញ។
  • 3ក្រោយពេលការដំណើរការ 2 918 នោះនឹងបញ្ចប់តាម v4។ អ្វីៗដែលចាប់ផ្តើមពី 11:40 នឹងដំណើរការតាម v5។
  • §គ្មាននរណាម្នាក់ទទួលបាន workflow កន្លះមួយ និងកន្លះមួយទៀត។

កំណែបានកត់ត្រានៅលើការដំណើរការទាំងអស់កំណែចាស់ត្រូវបានរក្សាទុក

ការព្យាយាមឡើងវិញដែលមិនអាចបញ្ជូនទ្វេដង

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

នោះជាកលទាំងមូល ហើយវាជាលក្ខណៈសម្បត្តិរចនាសម្ព័ន្ធ មិនមែនជាការសន្យាទេ។ Worker ដែលត្រូវបានសម្លាប់ក្នុងកំឡុងជំហាន — ការ deploy, ការគាំង, ម៉ាស៊ីនដែលបាត់បង់ — ទុកការដំណើរការនៅត្រង់កន្លែងដើម។ Worker ម្នាក់ទៀតយកវាមក ហើយដំណើរការជំហានឡើងវិញ។ ព្រោះផលប៉ះពាល់ និងការរីកចម្រើនត្រូវដាក់ជាមួយគ្នា ម្យ៉ាងទៀត ទាំងពីរកើតឡើង ឬទាំងពីរមិនកើតឡើង។

ការហៅចេញទៅប្រព័ន្ធដែលគាំទ្រ idempotency key នឹងមាន key មួយ ដែលបង្កើតពីការដំណើរការ និងជំហាន ដូច្នេះខាងម្ខាងក៏អាចស្គាល់ការបញ្ជូនម្តងទៀតបានដែរ។

Worker ត្រូវបានសម្លាប់ក្នុងកំឡុងការបញ្ជូនបានស្តារឡើងវិញ
  • 1ជំហាន 5 ចាប់ផ្តើមបញ្ជូនសារជូនដំណឹងអំពីការដឹកជញ្ជូន។
  • ✕Worker ស្លាប់Deploy។ គ្មានអ្វីត្រូវបានដាក់ចុះទេ។
  • 2បានយកឡើងវិញWorker ម្នាក់ទៀតរកឃើញការដំណើរការនៅតែស្ថិតលើជំហាន 5។
  • ✓បានបញ្ជូនម្តងអតិថិជនទទួលបានអ៊ីមែលមួយ មិនមែនពីរទេ។

ផលប៉ះពាល់ត្រូវដាក់ជាមួយការរីកចម្រើនIdempotency key សម្រាប់ការដំណើរការ និងជំហាននីមួយៗ

កំណត់ហេតុដែលសរសេរសម្រាប់មនុស្សអាន

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

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

ការដំណើរការដែលបរាជ័យត្រូវប្រមូលផ្តុំនៅកន្លែងតែមួយ ជាមួយមូលហេតុដែលបានដាក់ជាក្រុម ដូច្នេះ «ការបរាជ័យសែសិបមួយក្នុងមួយយប់» ដោះស្រាយបានជា «អ្នកផ្គត់ផ្គង់ម្នាក់បានឆ្លើយតប 503 អស់រយៈពេលប្រាំបួននាទី» ជាជាងការស៊ើបអង្កេតសែសិបមួយដោយឡែកៗ។

ក្នុងមួយយប់, ដាក់ជាក្រុមការបរាជ័យ ៤១
  • 1មូលហេតុតែមួយAPI របស់អ្នកផ្គត់ផ្គង់បានឆ្លើយតប 503 ចន្លោះម៉ោង 02:41 និង 02:50។
  • 2អ្វីដែលបានកើតឡើងទាំងអស់ ៤១ បានព្យាយាមម្តងទៀត; ៣៩ បានជោគជ័យនៅការព្យាយាមលើកទីពីរ។
  • 3នៅសល់ពីរបានឈប់ ហើយកំពុងរង់ចាំមនុស្ស។ ទាំងពីរត្រូវបានចុះក្នុងបញ្ជីជាមួយជួរដេកដែលបរាជ័យ។
  • §មិនមែនសែសិបមួយការស៊ើបអង្កេតទេ។ តែមួយប៉ុណ្ណោះ និងការសម្រេចចិត្តអំពីកំណត់ត្រាពីរ។

ព័ត៌មានសម្ងាត់ត្រូវបានលាក់បាំងកំណែត្រូវបានកត់ត្រា

អ្វីដែលយើងមិនអះអាង

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

យើងក៏មិនអាចធ្វើឱ្យ API របស់អ្នកដទៃមានស្ថិរភាពបានដែរ។ ប្រសិនបើអ្នកផ្តល់សេវាបានបិទ workflow ដែលពឹងផ្អែកលើវានឹងរង់ចាំ ព្យាយាមម្តងទៀត ហើយទីបំផុតឈប់ដោយមូលហេតុច្បាស់លាស់។ អ្វីដែលយើងអាចសន្យាបានគឺថាការបរាជ័យនោះមើលឃើញ វាមិនធ្វើឱ្យអ្វីៗខូចខាត ហើយការបន្តឡើងវិញមិនផ្ញើសារនោះម្តងទៀតទេ។

អំពីការរង់ចាំ៖ ការដំណើរការដែលរង់ចាំពីរថ្ងៃគឺជា wake_at លើការដំណើរការនោះ មិនមែនជាការងារដែលអង្គុយនៅក្នុងជួររង់ចាំទេ។ នោះជាមូលហេតុដែល workflow អាចរក្សាការដំណើរការមួយសែននៅក្នុងការរង់ចាំបីសប្តាហ៍ដោយមិនចំណាយអ្វីទាល់តែសោះ ហើយក៏ជាមូលហេតុដែលចំនួនការដំណើរការដែលកំពុងរង់ចាំមិនមែនជាអ្វីដែលអ្នកត្រូវគិតពីវាទេ។

ការដំណើរការដែលអ្នកមិនដែលគិតពីវាគឺជាការដំណើរការដែលជោគជ័យ។