castomFLOW
เปิด castomFLOW

การรันที่คุณวางใจได้

ไม่มีใครสังเกตเห็นระบบอัตโนมัติ จนกระทั่งมันส่งอะไรซ้ำสองครั้ง

แล้วทุกคนก็สังเกตเห็น กลไกสี่อย่างบนหน้านี้มีอยู่เพราะความล้มเหลวของซอฟต์แวร์ประเภทนี้มักเป็นความล้มเหลวสี่อย่างเดิม ๆ เสมอ และทั้งหมดหลีกเลี่ยงได้ด้วยการออกแบบ ไม่ใช่ด้วยความระมัดระวัง

จำลองการทำงานก่อนเผยแพร่

ดันเรกคอร์ดจริงผ่านเวิร์กโฟลว์ที่ยังปิดอยู่ แล้วอ่านย้อนกลับว่าจะเกิดอะไรขึ้นอย่างแม่นยำ: เส้นทางที่เลือก ทุกค่าในทุกขั้นตอน ถ้อยคำของทุกข้อความ และคำขอที่จะถูกส่งไปยังระบบภายนอกแต่ละแห่ง

ไม่มีอะไรหลุดออกไปจากระบบ ไม่มีอีเมลถูกส่ง ไม่มีใบแจ้งหนี้ถูกออก ไม่มีการเรียกเก็บเงิน ไม่มีแถวถูกเขียน การเรียกภายนอกจะถูกบันทึกไว้ในรูปความตั้งใจ (intention) พร้อมเพย์โหลดที่จะถูกส่ง เพื่อให้คุณเห็นได้ว่าการแมปถูกต้องหรือไม่ ก่อนที่มันจะกลายเป็นปัญหาของใครสักคน

การจำลอง (Simulation) คือวิธีที่คุณตอบคำถามที่ทำให้ผู้คนลังเลที่จะเปิดระบบอัตโนมัติ: สิ่งนี้จะทำอะไรกันแน่?

การจำลอง · คำสั่งซื้อ 88 214ไม่มีอะไรถูกส่ง
  • 1ตรวจสอบที่อยู่ตรงกันแล้ว ซึ่งปกติจะต้องเขียน 6 ฟิลด์
  • ?เงื่อนไขคำสั่งซื้อเกิน 1 000 zł? ไม่ใช่ — 289,00 zł จึงเลือกเส้นทางสั้น
  • 3ใบแจ้งหนี้จะส่ง POST ไปยังระบบออกใบแจ้งหนี้ โดยแสดงเพย์โหลดให้ดูทั้งหมด
  • !ถูกดักจับไว้ที่นี่อัตรา VAT ถูกแมปจากฟิลด์ที่ผิด พบได้ในการจำลอง ไม่ใช่ในกล่องจดหมายของนักบัญชี

ส่งแล้ว: ไม่มีอะไรเรียกเก็บแล้ว: ไม่มีอะไร

การรันแต่ละครั้งจะใช้เวอร์ชันที่มันเข้ามาในเวอร์ชันนั้น

การเผยแพร่การเปลี่ยนแปลงไปยังเวิร์กโฟลว์จะไม่แตะต้องการรันที่อยู่ภายในอยู่แล้ว การรันแต่ละครั้งจะถูกผูกติดกับเวอร์ชันที่มันเริ่มต้นและจะทำงานจนจบในเวอร์ชันนั้น ไม่ว่าจะใช้เวลานานเพียงใดและไม่ว่าคุณจะแก้ไขอะไรไปในระหว่างนั้น

ดังนั้นคุณจึงสามารถปรับโครงสร้างเวิร์กโฟลว์ใหม่ได้ในขณะที่มีคนหนึ่งหมื่นคนอยู่ระหว่างทำงานกลางทาง และทุกคนจะได้ไปจนจบในเส้นทางที่ได้รับการรับประกันไว้ ทางเลือกอีกแบบ — การออกแบบที่สร้างเส้นทางทั้งหมดต่อจากนี้ขึ้นมาตั้งแต่ตอนเข้า — คือเหตุผลที่การแก้ไขระบบอัตโนมัติที่กำลังทำงานอยู่รู้สึกอันตรายในเครื่องมือส่วนใหญ่ ที่นี่มันเป็นเรื่องธรรมดา

การรันใหม่จะได้รับเวอร์ชันใหม่ตั้งแต่วินาทีที่คุณเผยแพร่ เวอร์ชันที่การรันแต่ละครั้งใช้อยู่จะถูกบันทึกไว้ในการรันนั้น ดังนั้นคำถามเกี่ยวกับพฤติกรรมในเดือนมีนาคมก็จะมีคำตอบได้ในเดือนกันยายน

การแก้ไขขณะระบบทำงานอยู่v4 → v5
  • 1ก่อนมี 2 918 การรันที่กำลังดำเนินอยู่ ทั้งหมดอยู่บน v4 บางส่วนกำลังรออยู่สองวัน
  • 2เผยแพร่ v5สลับลำดับสองขั้นตอน และเขียนข้อความหนึ่งรายการใหม่
  • 3หลังการรันทั้ง 2 918 รายการนั้นจะทำงานจนจบใน v4 ส่วนทุกอย่างที่เริ่มตั้งแต่ 11:40 เป็นต้นไปจะรัน v5
  • §ไม่มีใครได้รับครึ่งหนึ่งของเวิร์กโฟลว์หนึ่งและครึ่งหนึ่งของอีกเวิร์กโฟลว์หนึ่ง

บันทึกเวอร์ชันไว้ในทุกการรันเก็บรักษาเวอร์ชันเก่าไว้

การลองใหม่ที่ส่งซ้ำไม่ได้

แต่ละขั้นตอนเป็นฟังก์ชันบริสุทธิ์ของอินพุตของมัน และผลลัพธ์ของมันจะถูกคอมมิตรวมกับการเดินหน้าของการรันไปยังขั้นตอนถัดไป ไม่มีช่วงเวลาที่ข้อความถูกส่งออกไปแล้วแต่การรันยังไม่รู้เรื่องนั้น

นั่นคือกลยุทธ์ทั้งหมด และมันเป็นคุณสมบัติเชิงโครงสร้าง ไม่ใช่แค่คำสัญญา ถ้าเวิร์กเกอร์ถูกฆ่ากลางขั้นตอน — การดีพลอย การพัง หรือเครื่องที่หายไป — การรันจะอยู่ตรงจุดเดิมเป๊ะ เวิร์กเกอร์อีกตัวจะรับช่วงและรันขั้นตอนนั้นซ้ำ เพราะผลลัพธ์และการเดินหน้าถูกคอมมิตเป็นหนึ่งเดียว ดังนั้นจึงเกิดทั้งคู่หรือไม่เกิดเลยเท่านั้น

การเรียกออกไปยังระบบที่รองรับ idempotency key จะแนบคีย์ไปด้วย โดยสร้างจากการรันและขั้นตอน เพื่อให้ฝั่งปลายทางจำการส่งซ้ำได้เช่นกัน

เวิร์กเกอร์ถูกฆ่ากลางการส่งกู้คืนแล้ว
  • 1ขั้นตอนที่ 5 เริ่มต้นส่งหนังสือแจ้งการจัดส่ง
  • ✕เวิร์กเกอร์หยุดทำงานดีพลอย ไม่มีอะไรถูกคอมมิตเลย
  • 2ถูกรับช่วงต่อเวิร์กเกอร์อีกตัวพบว่าการรันยังอยู่ที่ขั้นตอนที่ 5
  • ✓ส่งเพียงครั้งเดียวลูกค้าได้รับอีเมลหนึ่งฉบับ ไม่ใช่สองฉบับ

ผลลัพธ์ถูกคอมมิตรวมกับการเดินหน้าIdempotency key ต่อหนึ่งการรันและหนึ่งขั้นตอน

บันทึกที่เขียนขึ้นเพื่อให้คนอ่าน

ทุกการรัน ทุกขั้นตอน เส้นทางที่เลือก และค่าที่เป็นตัวตัดสิน เวลาที่ใช้ต่อขั้นตอน คำขอและการตอบกลับของการเรียกภายนอกแต่ละครั้ง โดยปิดบังข้อมูลรับรองไว้ เวอร์ชันที่การรันใช้อยู่ และจุดที่การรันกำลังรอพร้อมกำหนดว่ารอจนถึงเมื่อไร

เมื่อมีคนถามว่าคำสั่งซื้อที่ทำไว้ในวันที่สิบสี่เป็นอย่างไร ก็จะมีคำตอบ และการหาคำตอบนั้นใช้เวลาหนึ่งนาที ไม่ใช่หนึ่งบ่ายที่ต้องไล่เทียบบันทึกจากสามระบบ

รันที่ล้มเหลวจะถูกรวบรวมไว้ที่เดียวกันโดยจัดกลุ่มตามสาเหตุ ดังนั้น “ล้มเหลวคืนนี้ 41 ครั้ง” จึงจบลงด้วย “ซัพพลายเออร์ส่งกลับ 503 เป็นเวลาเก้านาที” แทนที่จะต้องสืบสวนแยกกัน 41 ครั้ง

คืนนี้ จัดกลุ่มแล้วล้มเหลว 41 ครั้ง
  • 1สาเหตุเดียวAPI ของซัพพลายเออร์ส่งกลับ 503 ระหว่าง 02:41 ถึง 02:50
  • 2เกิดอะไรขึ้นลองใหม่ทั้งหมด 41 รายการ 39 รายการสำเร็จในครั้งที่สอง
  • 3เหลืออยู่สองรายการหยุดและกำลังรอคนตรวจสอบ ทั้งสองแสดงอยู่ในแถวที่ล้มเหลว
  • §ไม่ใช่สี่สิบเอ็ดครั้งของการสืบสวน แต่เป็นหนึ่งครั้ง และการตัดสินใจเรื่องสองระเบียน

ข้อมูลรับรองถูกปิดบังบันทึกเวอร์ชันแล้ว

สิ่งที่เราไม่อ้างสิทธิ์

เราไม่เผยแพร่ตัวเลข uptime ไว้บนหน้าการตลาด เพราะตัวเลขที่ไม่มีช่วงเวลาการวัดและนิยามของคำว่า “พร้อมใช้งาน” ก็เป็นเพียงเครื่องประดับ หากคุณต้องการตัวเลขนี้ในเชิงสัญญา แจ้งมาได้เลย และเราจะคุยกันว่าเราให้คำมั่นได้จริงเท่าไร

เรายังทำให้ API ของผู้อื่นเชื่อถือได้ไม่ได้ หากผู้ให้บริการล่ม workflow ที่พึ่งพาเขาจะรอ ลองใหม่ และในที่สุดก็หยุดพร้อมเหตุผลที่ชัดเจน สิ่งที่เราให้คำมั่นได้คือความล้มเหลวจะมองเห็นได้ ไม่ทำให้ข้อมูลใดเสียหาย และการทำงานต่อจะไม่ส่งข้อความเดิมซ้ำเป็นครั้งที่สอง

เรื่องการรอ: รันที่รออยู่สองวันคือ wake_at ที่ระบุไว้บนรันนั้น ไม่ใช่งานที่นั่งรออยู่ในคิว นั่นคือเหตุผลที่ workflow สามารถถือรันไว้หนึ่งแสนรายการในการรอสามสัปดาห์โดยไม่มีต้นทุนใดเลย และจำนวนรันที่กำลังรออยู่ในขณะนี้ก็ไม่ใช่สิ่งที่คุณต้องคิดถึง

รันที่คุณไม่ต้องคิดถึงเลย คือรันที่สำเร็จ