กลับ

2026/10/26

HTTP2Shell (CVE-2026-111497): การอัปเดตไบนารีไม่ได้แพตช์โปรเซสที่กำลังทำงานอยู่

ช่องโหว่ Brotli เบื้องหลัง HTTP2Shell กระทบ Node.js, Bun และ Python วิธีหาความเสี่ยงจริงในโปรเซสที่ทำงานอยู่และรีสตาร์ต AI agent อย่างปลอดภัย

เมื่อวันที่ 21 ตุลาคม 2026 Node.js ได้ออกแพตช์แก้ไข CVE-2026-111497 ซึ่งเป็นช่องโหว่การเขียนข้อมูลเกินขอบเขตหน่วยความจำ (out-of-bounds write) ในตัวถอดรหัส Brotli ของ Google ภายในไม่กี่วันต่อมา ก็มีประกาศเตือนด้านความปลอดภัยสำหรับ Bun, แพ็กเกจ Python brotli และ brotlicffi, Envoy และ Istio ตามมา และสื่อด้านความปลอดภัยได้ตั้งชื่อช่องโหว่นี้ว่า Node2Shell และต่อมาเป็น HTTP2Shell แม้จะมีชื่อเล่นเช่นนั้น แต่นี่ไม่ใช่บั๊กของโปรโตคอล HTTP/2 หากเป็นบั๊กในการคลายการบีบอัด และมีความสำคัญในทุกที่ที่ซอฟต์แวร์ถอดรหัสข้อมูล Brotli ที่ผู้โจมตีสามารถมีอิทธิพลต่อได้

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

ประเด็นสำคัญ

  • ได้รับผลกระทบ: Brotli ต้นทาง (upstream) เวอร์ชัน 1.0.3 ถึง 1.2.0 แก้ไขแล้ว: 1.0.10, 1.1.1 และ 1.2.1 ผลิตภัณฑ์ที่รวม Brotli มาด้วยต้องใช้รีลีสที่แก้ไขแล้วของผลิตภัณฑ์นั้นเอง
  • ความเสี่ยงจริงต้องมีเส้นทางที่เป็นไปได้จริง: ข้อมูล Brotli ที่ผู้โจมตีมีอิทธิพลต่อได้ไปถึงตัวถอดรหัสที่มีช่องโหว่ ลำพังชื่อผลิตภัณฑ์หรือการเข้าถึงเครือข่ายได้ยังไม่ใช่หลักฐาน
  • ตรวจสอบโปรเซสที่กำลังทำงาน ไม่ใช่แค่แพ็กเกจที่ติดตั้งไว้ โปรเซสจะใช้รันไทม์ที่โหลดตอนเริ่มทำงานไปจนกว่าจะถูกรีสตาร์ต
  • รีสตาร์ต AI agent ที่มีสถานะทีละตัว โดยส่งต่ออีเวนต์ การอนุมัติ และสถานะงานของมันให้เรียบร้อยก่อน

1. ช่องโหว่นี้คืออะไร

เมื่อตัวถอดรหัสพบ block switch ที่ไม่ถูกต้อง มันรายงานว่า “ต้องการอินพุตเพิ่ม” แทนที่จะรายงานข้อผิดพลาดรูปแบบข้อมูลแบบถาวร ผู้เรียกใช้แบบสตรีมมิงจึงป้อนไบต์ต่อไปเรื่อย ๆ และตัวถอดรหัสก็นำไบต์เหล่านั้นไปต่อท้ายบัฟเฟอร์ภายในขนาด 8 ไบต์ จนเขียนเลยจุดสิ้นสุดของบัฟเฟอร์ ประกาศของ Node.js ระบุว่าผู้โจมตีที่สามารถส่งข้อมูล Brotli ซึ่งแอปพลิเคชันคลายการบีบอัดด้วย node:zlib “สามารถทำให้หน่วยความจำของโปรเซสเสียหาย ซึ่งอาจนำไปสู่การแครช การเปิดเผยหน่วยความจำของโปรเซส หรือการรันโค้ดจากระยะไกล”

ระดับความรุนแรงแตกต่างกันไปตามแหล่งที่มา Node.js ให้ระดับ High ประกาศบน GitHub สำหรับแพ็กเกจ Python และประกาศของ Envoy ให้ระดับ Critical คะแนน CVSS 4.0 เท่ากับ 9.2 ส่วน Ubuntu ปัจจุบันจัดเป็นลำดับความสำคัญ Medium ณ วันที่ 26 ตุลาคม การประเมินของ CISA บนบันทึก CVE ระบุสถานะการโจมตีจริงว่า “none” และ CVE นี้ไม่อยู่ในแคตตาล็อก Known Exploited Vulnerabilities ของ CISA อย่างไรก็ตาม ประกาศของ Node.js ยังคงระบุว่าการรันโค้ดจากระยะไกลเป็นผลลัพธ์ที่เป็นไปได้ ดังนั้นอย่าถือว่าการที่ยังไม่มีรายงานการโจมตีเป็นเหตุผลให้รอ

2. เงื่อนไขเบื้องต้น: เมื่อใดที่คุณมีความเสี่ยงจริง

ต้องเป็นจริงครบทั้งสามเงื่อนไข:

  1. มีการโหลดตัวถอดรหัสที่มีช่องโหว่ในโปรเซส: ไลบรารี Brotli ที่รวมมาด้วยหรือของระบบซึ่งอยู่ในช่วงเวอร์ชันที่ได้รับผลกระทบ โดยไม่มีแพตช์หรือ backport
  2. มีบางสิ่งเรียกใช้มัน: การคลายการบีบอัดโดยตรง หรือการถอดรหัส Content-Encoding: br โดยอัตโนมัติ
  3. อินพุตอาจถูกผู้โจมตีมีอิทธิพลต่อได้: การตอบกลับจาก URL ใด ๆ ไฟล์ที่อัปโหลด เนื้อหาคำขอที่เข้ามา หรือทราฟฟิก HTTP แบบไม่เข้ารหัสบนเครือข่ายที่ไม่น่าไว้วางใจ

การถอดรหัสอัตโนมัติคือเส้นทางที่ทีมต่าง ๆ มองข้ามบ่อยที่สุด ประกาศของ Bun ระบุว่า fetch ส่ง Accept-Encoding: br เป็นค่าเริ่มต้นและถอดรหัสการตอบกลับ ดังนั้นโปรแกรม Bun ใดก็ตามที่ดึงข้อมูลจาก URL ที่ไม่น่าเชื่อถือจึงมีเส้นทางนี้ ใน Python เมื่อติดตั้ง brotli หรือ brotlicffi แล้ว urllib3 จะถอดรหัสการตอบกลับที่เป็น Content-Encoding: br โดยอัตโนมัติ และ requests ก็ประกาศรองรับ br ในคำขอของตนด้วย สิ่งนี้เกิดขึ้นแม้โค้ดของคุณเองจะไม่เคยกล่าวถึง Brotli เลย ส่วน Envoy และ Istio จะมีความเสี่ยงก็ต่อเมื่อมีการกำหนดค่าตัวคลายการบีบอัด Brotli ไว้เท่านั้น

3. ยืนยันว่าได้รับผลกระทบ เทียบกับเพียงแค่เป็นไปได้

สถานะ ณ วันที่ 26 ตุลาคม 2026 โปรดตรวจสอบประกาศที่ลิงก์ไว้ เนื่องจากสถานการณ์เปลี่ยนแปลงอย่างรวดเร็ว

คอมโพเนนต์สถานะแก้ไขแล้วใน
Brotli ต้นทาง (C)ยืนยันแล้ว: 1.0.3 ถึง 1.2.01.0.10, 1.1.1, 1.2.1
Node.js 22, 24, 26ยืนยันแล้ว22.23.4, 24.22.1, 26.12.1
Node.js 20 และเก่ากว่า (สิ้นสุดอายุการสนับสนุน)ไม่ได้ประเมิน; Node.js ถือว่าสายเวอร์ชันที่สิ้นสุดอายุการสนับสนุนได้รับผลกระทบเสมอย้ายไปใช้สายเวอร์ชันที่ยังได้รับการสนับสนุน
Bun (รวมถึงไฟล์ปฏิบัติการที่คอมไพล์แล้ว)ยืนยันแล้ว: 1.0.21 ถึง 1.4.31.4.4 และต้องบิลด์แอปที่คอมไพล์แล้วใหม่
Python brotli / brotlicffiยืนยันแล้ว: ตั้งแต่ 1.0.31.2.1 / 1.2.1.0
Envoy (กำหนดค่าตัวคลายการบีบอัด Brotli)ยืนยันแล้ว1.40.0, 1.39.3, 1.38.6, 1.37.8 (1.36.12 บนสาขา 1.36 ที่ไม่ได้รับการสนับสนุนแล้ว)
Istio (เปิดใช้การคลายการบีบอัด Brotli)ยืนยันแล้ว1.31.2, 1.30.6, 1.29.9 (รีลีสสุดท้ายของ 1.29)
แพ็กเกจ brotli ของ Ubuntuอยู่ระหว่างการประเมิน (ทุกรีลีส)ยังไม่มีแพ็กเกจที่แก้ไขแล้ว
แพ็กเกจ nodejs ของ Ubuntuมีช่องโหว่บน 20.04 (Brotli ที่รวมมาด้วย) ตั้งแต่ 22.04 ขึ้นไปใช้ Brotli ของระบบ จึงมีสถานะตามแถวด้านบนดูที่ Ubuntu tracker
แพ็กเกจ brotli ของ Debianแก้ไขแล้วใน bookworm และ trixie; forky ยังไม่แก้ไข1.0.9-2+deb12u1, 1.1.0-2+deb13u1
Chrome, Electron และแอป Electronไม่ทราบ: ไม่พบแถลงการณ์จากผู้ผลิตติดตามบันทึกการออกรีลีสของผู้ผลิต

เกี่ยวกับแถวสุดท้าย: Chrome และ Electron มาพร้อม Brotli ชุดของตนเอง และแอป Electron ยังฝังรันไทม์ Node.js ไว้ด้วย ณ เวลาที่เขียนบทความนี้ รีลีสเสถียรล่าสุดของ Electron (45.0.0, 44.9.3 และ 43.8.3 ทั้งหมดออกวันที่ 21 ตุลาคม) ระบุ Node.js 24.22.0 ไม่ใช่ 24.22.1 และบันทึกรีลีสไม่ได้กล่าวถึง CVE นี้ รีลีสทดสอบ (pre-release) ของ Electron ตั้งแต่วันที่ 23 ตุลาคมใช้ Node.js 24.22.1 จึงมีแนวโน้มว่าจะมีการแก้ไขในรีลีสเสถียร แต่ยังไม่ได้ออกมา ดังนั้นแอปเดสก์ท็อปที่สร้างบน Electron จึงอาจมีความเสี่ยง แต่ยังไม่ได้รับการยืนยันว่ามีช่องโหว่ หลักเดียวกันนี้ใช้กับแอปแชตและเครื่องมือ AI บนเดสก์ท็อป: ตรวจสอบแถลงการณ์ของผู้ผลิตแต่ละรายก่อนสรุปว่าได้รับผลกระทบหรือปลอดภัย

อีกหนึ่งกับดัก: เวอร์ชันไลบรารีที่รายงานออกมาไม่ได้พิสูจน์อะไรได้ทั้งสองทาง Node.js 22.23.4 ที่แก้ไขแล้วยังคงรายงาน process.versions.brotli เป็น 1.1.0 เนื่องจากการแก้ไขถูก backport มา ดิสทริบิวชันต่าง ๆ ก็ทำแบบเดียวกัน ให้ตัดสินจากเวอร์ชันที่แก้ไขแล้วของผลิตภัณฑ์หรือสถานะความปลอดภัยของดิสทริบิวชัน ไม่ใช่จากสตริงเวอร์ชันของ Brotli

4. สิ่งที่เราพบในสภาพแวดล้อมของเราเอง

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

ข้อสังเกตที่ยืนยันแล้ว

  • Claude Code ที่ติดตั้งไว้ได้รับการอัปเดตแล้ว แต่เซสชันที่ทำงานต่อเนื่องราวสิบกว่าเซสชันยังคงรันบิลด์เก่าที่เริ่มทำงานไว้ตั้งแต่หลายสัปดาห์ก่อน และไม่เคยถูกรีสตาร์ตเลย
  • การนับครั้งแรกของเราตกหล่นไปสามเซสชัน เนื่องจากเซสชันเหล่านั้นทำงานภายใต้โปรเซสตัวช่วย (helper) ที่ต่างออกไป การค้นหาด้วยคอมมานด์ไลน์จึงไม่พบ แต่การค้นหาด้วยไฟล์ปฏิบัติการพบ
  • ไฟล์ของบิลด์เก่าถูกตัวอัปเดตลบออกจากดิสก์ไปแล้ว จึงไม่สามารถอ่านเวอร์ชัน Bun ที่ฝังอยู่ในโปรเซสเหล่านั้นได้
  • การติดตั้งผ่านตัวจัดการแพ็กเกจที่หลงเหลืออยู่ของ Claude Code บิลด์เก่ากว่าฝัง Bun 1.4.0 ไว้ ไม่มีสิ่งใดใช้งานมันในการทำงานปกติ แต่เส้นทางสำรอง (fallback) อาจใช้ได้ เราจึงลบออกหลังจากพิสูจน์แล้วว่าไม่มีสิ่งใดพึ่งพามัน
  • รันไทม์ Node.js ที่สิ้นสุดอายุการสนับสนุนและไม่ได้ใช้งานยังคงติดตั้งอยู่บนเซิร์ฟเวอร์เครื่องหนึ่ง เราลบออกด้วยวิธีเดียวกัน
  • Claude Code บิลด์ปัจจุบันที่เราอัปเกรดไป (2.1.310) มี Bun 1.4.4 เรายืนยันโดยการตรวจสอบไบนารี changelog ของ Anthropic ไม่ได้กล่าวถึง CVE นี้ ดังนั้นให้ตรวจสอบบิลด์ของคุณด้วยวิธีเดียวกัน

ยังไม่ได้ยืนยัน จึงถือเป็นความเสี่ยง

  • เซสชันเก่ามีช่องโหว่จริงหรือไม่ เราอ่านเวอร์ชัน Bun ของมันไม่ได้ Bun 1.4.4 ที่แก้ไขแล้วเพิ่งออกมาราววันที่ 22 ตุลาคม ซึ่งหลังจากบิลด์เหล่านั้น เราจึงถือว่าได้รับผลกระทบ
  • ผู้โจมตีสามารถเข้าถึงตัวถอดรหัสผ่านเซสชันเหล่านั้นได้หรือไม่ เช่น ด้วยการดึงข้อมูลจาก URL ที่เป็นอันตราย เส้นทางนี้เป็นไปได้ตามพฤติกรรมของ fetch ที่ Bun ระบุไว้ในเอกสาร แต่เรายังไม่ได้พิสูจน์
  • ซอฟต์แวร์อื่นที่รวม Brotli ชุดของตนเองมาด้วยได้รับผลกระทบหรือไม่ ในกรณีที่ไม่มีแถลงการณ์จากผู้ผลิต เราติดตามผลิตภัณฑ์นั้นเทียบกับรีลีสของผู้ผลิต แทนที่จะสันนิษฐานว่าปลอดภัยหรือมีช่องโหว่

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

5. เช็กลิสต์การตรวจหาและแก้ไข

ค้นหา dependency

มองหา Brotli ในที่ที่ถูกรวมมาด้วย ไม่ใช่แค่ในที่ที่ติดตั้งเป็นแพ็กเกจ ตรวจสอบ SBOM และคอนเทนเนอร์อิมเมจของคุณเพื่อหา Node.js, Bun, แพ็กเกจ Python, Envoy และ Brotli ที่ลิงก์แบบสแตติก ตรวจสอบ dependency ทางอ้อมของ Python ด้วย เพราะ Brotli มักติดมาในรูปแบบ extra ที่เป็นทางเลือก

# Node.js: compare with 22.23.4 / 24.22.1 / 26.12.1
node -p process.version
# Python packages: run once per interpreter and virtual environment
python -m pip list 2>/dev/null | grep -iE '^(brotli|brotlicffi) '
pipdeptree -r -p brotli          # what pulled it in
# Debian / Ubuntu system library (then check the distro tracker)
dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'libbrotli*'
# Container images, with an SBOM scanner such as Syft
syft <image> | grep -iE 'brotli|node|bun'

ค้นหารันไทม์ที่ฝังอยู่

โปรแกรมที่บิลด์ด้วย bun build --compile จะมี Bun ชุดของตนเองติดไปด้วย ประกาศของ Bun ระบุว่าโปรแกรมเหล่านี้ยังคงได้รับผลกระทบจนกว่าจะถูกบิลด์ใหม่ด้วย 1.4.4 การอัปเกรด Bun บนเครื่องบิลด์ไม่ได้เปลี่ยนแปลงไบนารีที่ดีพลอยไปแล้ว

# The Bun version inside a compiled executable
grep -aoE 'Bun v1\.[0-9]+\.[0-9]+' /path/to/binary | sort -u

ค้นหาโปรเซสที่กำลังทำงาน

ตรวจสอบสิ่งที่กำลังทำงานอยู่ ไม่ใช่สิ่งที่ติดตั้งไว้ บน Linux โปรเซสที่ไฟล์ปฏิบัติการถูกแทนที่หรือถูกลบจะแสดง (deleted) ซึ่งเป็นสัญญาณชัดเจนว่ายังคงรันบิลด์เก่าอยู่

# Processes still running a deleted (replaced) executable (run as root to see all users)
for p in /proc/[0-9]*; do
  e=$(readlink "$p/exe" 2>/dev/null) || continue
  case "$e" in *"(deleted)") echo "${p#/proc/} $e";; esac
done
# Processes older than the fix
pgrep -af 'node|bun|claude'      # then: ps -o pid,lstart,args -p <pid>

บน macOS คำสั่ง lsof -p <pid> จะแสดงไฟล์ปฏิบัติการที่โปรเซสโหลดไว้ ให้จับคู่ด้วยไฟล์ปฏิบัติการ ไม่ใช่ชื่อโปรเซส มิฉะนั้นคุณจะพลาดโปรเซสตัวช่วยและ worker ที่ทำงานเบื้องหลัง

แก้ไข บิลด์ใหม่ และดีพลอยใหม่

  • อัปเกรดเป็นเวอร์ชันที่แก้ไขแล้วตามตาราง ใช้แพ็กเกจที่แพตช์แล้วของดิสทริบิวชันในกรณีที่มี backport
  • บิลด์คอนเทนเนอร์อิมเมจและไฟล์ปฏิบัติการที่คอมไพล์แล้วใหม่ จากนั้นดีพลอยใหม่ base image ที่แพตช์แล้วไม่มีผลใด ๆ กับอิมเมจที่คุณยังไม่ได้บิลด์ใหม่
  • ลบรันไทม์ที่ไม่ได้ใช้และการติดตั้งที่หลงเหลือ หลังจากพิสูจน์แล้วว่าไม่มีบริการ งาน หรือสคริปต์ใดพึ่งพา และเตรียมทางย้อนกลับ (rollback) ไว้เสมอ
  • ในกรณีที่ยังไม่มีแพตช์ ให้ปิดการถอดรหัส Brotli สำหรับอินพุตที่ไม่น่าเชื่อถือในจุดที่ทำได้อย่างปลอดภัย สำหรับ Bun ใช้ fetch(url, { decompress: false }) ได้เป็นรายคำขอ กำหนดผู้รับผิดชอบและวันสิ้นสุดให้กับมาตรการบรรเทาแต่ละรายการ

รีสตาร์ตและตรวจสอบ

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

6. การรีสตาร์ต AI agent ที่ทำงานต่อเนื่องอย่างปลอดภัย

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

  1. สำรวจแต่ละเซสชัน: เวอร์ชันของไฟล์ปฏิบัติการ สถานะ (ว่าง รอ หรือไม่ว่าง) กิจกรรมล่าสุด งานที่ค้างอยู่ การอนุมัติที่รออยู่หรือถือไว้ อีเวนต์ที่ยังไม่ได้รับทราบ (unacknowledged) และวิธีที่จะกู้คืน
  2. ย้ายการอนุมัติออกจากหน่วยความจำ การอนุมัติที่อยู่เพียงในบทสนทนาของเซสชันจะหายไปเมื่อรีสตาร์ต ก่อนรีสตาร์ต ให้บันทึกการอนุมัติที่ค้างอยู่แต่ละรายการ (อนุมัติอะไร โดยใคร สำหรับการเปลี่ยนแปลงใดโดยเฉพาะ) ไว้ในที่ที่คงทน เช่น ทิกเก็ตหรือ pull request หลังจากนั้นให้ยืนยันว่าเซสชันยังมองเห็นการอนุมัตินั้น หากไม่แน่ใจ ให้ขออนุมัติใหม่แทนการสันนิษฐาน
  3. พิสูจน์ตัวทดแทนก่อน ยืนยันว่าเซสชันบนบิลด์ที่แก้ไขแล้วทำงานได้อยู่แล้ว และมีตัวเฝ้าดูอีเวนต์ที่แยกเป็นอิสระจากเซสชันเก่ากำลังทำงานอยู่ เพื่อไม่ให้มีอีเวนต์ใดต้องพึ่งพาเซสชันที่กำลังถูกรีสตาร์ต
  4. รีสตาร์ตเซสชันที่ว่างอยู่ก่อน ทีละเซสชัน หลังแต่ละเซสชัน ให้ตรวจสอบว่าโปรเซสเก่าหายไปแล้ว โปรเซสใหม่รันไฟล์ปฏิบัติการที่แก้ไขแล้ว ประวัติบทสนทนายังครบถ้วน และการเชื่อมต่อระยะไกลกลับมาแล้ว จากนั้นจึงทำเซสชันถัดไป
  5. รีสตาร์ตเซสชันที่มีงานมากที่สุดเป็นลำดับสุดท้าย ในช่วงระหว่างงาน ให้มันเขียนบันทึกส่งต่องาน หยุดตัวเฝ้าดูของมันเฉพาะเมื่องานค้างเป็นศูนย์และอีเวนต์ที่ยังไม่ได้รับทราบเป็นศูนย์ รีสตาร์ต แล้วยืนยันว่าตัวเฝ้าดูกลับมาทำงานต่อจากตำแหน่งที่บันทึกไว้โดยไม่มีอะไรตกหล่น
  6. เตรียมรับอินพุตที่ค้างในคิวเมื่อเชื่อมต่อใหม่ หนึ่งในเซสชันที่เรารีสตาร์ตได้รับข้อความที่รออยู่นานถึงสิบวันและดำเนินการตามข้อความนั้น ให้ตรวจสอบกล่องข้อความของแต่ละเซสชันก่อนรีสตาร์ต และแจ้งผู้รับผิดชอบเซสชันนั้น
  7. หยุดและยกระดับปัญหา หากขั้นตอนใดไม่สามารถแสดงให้เห็นว่างานได้รับการกู้คืนแล้ว อย่าถอยกลับไปใช้วิธีปิดทุกอย่างทิ้ง

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

แหล่งอ้างอิง