หนึ่งสัปดาห์ที่ระบบเขียนบทความด้วย AI กลายเป็น "โรงงานอัตโนมัติ"

สรุปใน 5 วินาที

สิ่งที่ได้ผลจริงในการทำงานอัตโนมัติด้วย AI ไม่ใช่ การที่คำตอบครั้งแรกออกมาเร็ว แต่คือการที่ต้องแก้งานซ้ำน้อยลงจนกว่างานจะเสร็จจริง

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

สิ่งที่ได้ผลในการปรับปรุงครั้งใหญ่นี้ คือแนวคิดที่ใช้ ultra ตั้งแต่ช่วงแรกสุดของการเปลี่ยนแปลงการออกแบบขนาดใหญ่ ซึ่งเป็นโหมดที่ไม่ได้แค่ให้ GPT-5.6 Sol คิดลึกขึ้น แต่ยังเดินงานหลายอย่างขนานกันไปด้วย

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

ถ้าพูดด้วยศัพท์โรงงาน คือ รอบเวลาการผลิต (cycle time) ยาว แต่อัตราการแก้งานซ้ำต่ำ ระยะเวลารวมตั้งแต่เริ่มจนส่งมอบ (lead time) จึงสั้น

ขอเตือนก่อน: Level 6 และ Level 7 ไม่ใช่ระดับมาตรฐานของโลก

Level 6 และ Level 7 ในบทความนี้ ไม่ใช่เลเวลในเกม และไม่ใช่มาตรฐาน ISO แต่เป็นเพียงป้ายชื่อที่ตั้งขึ้นสำหรับระบบนี้ เพื่ออธิบายระดับความสมบูรณ์ของระบบอัตโนมัติให้เข้าใจง่าย

แนวคิดพื้นฐานใกล้เคียงกับ "autonomic computing" หรือการประมวลผลแบบอัตโนมัติที่ IBM ศึกษามานาน IBM สรุปว่าคุณสมบัติหลักของระบบอัตโนมัติคือ ตั้งค่าตัวเองได้ ซ่อมตัวเองได้ ปรับให้ดีที่สุดด้วยตัวเองได้ และปกป้องตัวเองได้

ในบทความนี้ ผมเรียก ขั้นที่ระบบกลับสู่สถานะที่ถูกต้องได้เองว่า Level 6 และ ขั้นที่ระบบยังไปไกลกว่านั้น คือค้นหาวิธีทำงานที่ดีกว่าด้วยตัวเองภายในขอบเขตที่ปลอดภัยว่า Level 7

แรกเริ่มก็แค่ "สั่งให้ AI เขียนบทความ" รู้ตัวอีกที บล็อกก็มีรั้วงอกขึ้นมา

ระบบอัตโนมัติสำหรับบทความทั่วไปนั้นเรียบง่าย:

1. ทำงานตามเวลาที่กำหนด
2. ให้ AI สร้างข้อความ
3. บันทึกลงไฟล์
4. อัปโหลดไปที่ GitHub
5. ถ้าล้มเหลว คนเข้าไปดู

แค่นี้ก็สะดวกพอแล้ว

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

ประเด็นหลักไม่ใช่ "เขียนได้ไหม" อีกต่อไป แต่เป็นเรื่องเหล่านี้:

• ถ้า worker (โปรแกรมที่ทำงานตามที่สั่ง) สองตัวแตะบทความเดียวกันพร้อมกันจะทำอย่างไร
• ถ้าล้มกลางคัน จะเริ่มต่อจากตรงไหน
• จะป้องกันไม่ให้งานที่ล้มเหลวถูกลองซ้ำไม่รู้จบได้อย่างไร
• เรากำลังเอาผลตรวจเก่ามาใช้ซ้ำเหมือนเป็นผลตรวจใหม่หรือเปล่า
• AI กำลังอ้างเองว่า "คนตรวจแล้ว" อยู่หรือเปล่า
• ใครจะหยุดสถานะที่ห้ามเผยแพร่
• ถ้าบริการภายนอกล่ม จะไม่ให้โรงงานทั้งหมดหยุดได้อย่างไร
• แสดงว่า "100 คะแนน" แต่ 100 คะแนนนั้นวัดสถานะปัจจุบันจริงหรือไม่

มาถึงตรงนี้ มันไม่ใช่ "ระบบบล็อกอัตโนมัติ" อีกแล้ว

มันคือระบบการผลิตขนาดเล็กที่ใช้เนื้อหาเป็นวัตถุดิบ

Level 6: พังแล้วก็กลับสู่สถานะที่ถูกต้องได้เอง

Level 6 ของโรงงานนี้ ถ้าพูดสั้น ๆ คือ กลไกที่กลับสู่คำตอบที่ถูกต้องซึ่งกำหนดไว้ตายตัวได้เอง

องค์ประกอบหลักมีดังนี้

กลไก	ถ้าอธิบายให้เด็กมัธยมต้นฟัง
desired state	กำหนด "สถานะที่ควรเป็น" ในรูปแบบที่เครื่องอ่านออก
reconciliation	เทียบสถานะตอนนี้กับคำตอบที่ถูก ถ้าต่างกันก็แก้
lease / fencing	ไม่ให้สองคนต่างคนต่างทำงานเดียวกันพร้อมกัน
checkpoint	บันทึกอย่างเป็นทางการว่าทำไปถึงตรงไหนแล้ว
CAS	ไม่เอาสถานะเก่าไปทับสถานะใหม่
transactional outbox	เก็บกวาดความคลาดเคลื่อนแบบที่ตัวงานหลักสำเร็จแต่การแจ้งเตือนล้มเหลว
retry / quarantine	ลองใหม่เมื่อล้มเหลวชั่วคราว และแยกข้อมูล "พิษ" ออกไปกักไว้
safe publication gate	ไม่ให้เผยแพร่จนกว่าจะผ่านเงื่อนไขด้านคุณภาพ
failure injection	จงใจทำให้พังเพื่อทดลองว่ากู้คืนได้จริงไหม
observability	ทำให้วัดได้ว่าอะไรกำลังทำงานและอะไรล้มเหลว

ในภาพรวมการทำงานช่วงหนึ่ง ข้อกำหนดการออกแบบ Level 6 ทั้ง 21 ข้อผ่าน PASS หมด และคะแนนการสร้างระบบควบคุมเป็น 100 แต่คะแนนความมั่นใจที่รวมการวัดจากภายนอก การยืนยันโดยมนุษย์ และผลงานระยะยาวของ worker ทั้งหมด อยู่ที่ราว 69% การเผยแพร่ยังเป็น HOLD และ Level 7 ยังเป็น OFF

ตรงนี้สำคัญ

100 คะแนนด้านการสร้างระบบ กับ 100 คะแนนที่วางใจปล่อยทิ้งไว้ได้จริง เป็นคนละเรื่องกัน

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

การให้ Sol คิดลึก กับ Ultra ต่างกันแบบ "คนเดียวนั่งคิดนาน" กับ "หลายคนทำขนานกัน"

ตามคำอธิบายอย่างเป็นทางการของ OpenAI, GPT-5.6 Sol มี max ที่ให้ใช้เหตุผลอย่างลึก และ ultra เป็นการตั้งค่าสมรรถนะสูงที่ให้เอเจนต์หลายตัวประสานงานกันในสายงานที่ขนานกัน

เปรียบเทียบได้ดังนี้

กรณีให้ Sol คิดลึก

เหมือนขังนักออกแบบฝีมือดีไว้ในห้องประชุมคนเดียว

"ไม่ต้องรีบ อ่านโค้ดและเอกสารให้หมด หาข้อขัดแย้งให้เจอ คิดให้ถึงที่สุด"

ซึ่งแข็งแกร่งมาก

กรณี Ultra

นักออกแบบ คนลงมือทำ คนหาบั๊ก คนคอยทำลาย และคนทดสอบ ทำงานพร้อมกัน แล้วรวมผลตอนท้าย

พูดง่าย ๆ คือ ไม่ใช่ว่าความฉลาดเพิ่มเป็นสองเท่าตรง ๆ แต่ทิศทางที่มองข้ามไปถูกกระจายออกไปมากกว่า

จากตัวเลขที่ OpenAI เปิดเผย ใน Terminal-Bench 2.1 นั้น GPT-5.6 Sol ได้ 88.8% ส่วน Sol Ultra ได้ 91.9% ต่างกัน 3.1 จุด แต่ถ้าดูฝั่งความล้มเหลว จะลดจาก 11.2% เหลือ 8.1% คิดแบบง่าย ๆ อัตราล้มเหลวลดลงราว 28% แน่นอนว่านี่เป็นการประเมินเพียงชุดเดียว ไม่ได้แปลว่าในทุกงานความล้มเหลวจะลดลง 28%

อย่างไรก็ตาม สำหรับงานที่แบ่งได้ เช่น "อ่านรีโพซิทอรีขนาดใหญ่ ออกแบบ ลงมือทำ ทำให้พัง แล้วตรวจสอบซ้ำ" ทิศทางของความต่างนี้ก็เห็นได้ง่าย

ทำไม Ultra ที่หนัก กลับเร็วกว่าในท้ายที่สุด

เวลาจนกว่าจะเสร็จ คิดคร่าว ๆ ได้ดังนี้

lead time รวม = การทำครั้งแรก + การแก้งานซ้ำ + การทดสอบซ้ำ + การรับมือเหตุขัดข้อง + การแก้ความเข้าใจผิด

คนส่วนใหญ่มองแค่ข้อแรกสุดคือ "การทำครั้งแรก"

ดังนั้น AI ที่ตอบใน 30 นาทีจึงดูเร็ว ส่วนที่ใช้ 2 ชั่วโมงดูช้า

แต่ถ้าเวอร์ชัน 2 ชั่วโมงกำจัดงานแก้ซ้ำ 6 ชั่วโมงที่จะเกิดตามมาทีหลังได้ เวอร์ชัน 2 ชั่วโมงก็เร็วกว่า

ในภาคการผลิตก็เป็นแบบเดียวกัน

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

สิ่งที่น่าสนใจของ "Ultra ครั้งเดียวจบ" คราวนี้ คือปัญหาที่พบทีหลังส่วนใหญ่ ไม่ใช่เรื่องต้องรื้อออกแบบรากฐานใหม่

สิ่งที่ไล่เก็บรายละเอียดกันในขั้นตอนหลัง ๆ เช่น

• อยากเห็นหลักฐานในหน้าเดียวว่า worker ทุกตัวประมวลผลข้อมูลจริงแล้วจริง ๆ
• อย่าเอา 50/50 เก่ามาใช้เป็น 50/50 ของการตรวจสอบรอบใหม่
• อย่าเขียนว่าการรีวิวโดย AI เป็นการรีวิวโดยมนุษย์
• ถ้าไม่มีการวัดจากภายนอก ให้เขียนว่า "ไม่ทราบ"
• แม้ worker จะไม่ได้ทำอะไรเลย ถ้าเป็น NOOP ที่ถูกต้อง (ไม่มีอะไรให้ทำจึงนิ่งไว้โดยตั้งใจ) ก็อย่านับว่าล้มเหลว

นี่ไม่ใช่เรื่อง "เสากลับด้านเลยต้องสร้างบ้านใหม่"

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

ทำไม "Ultra หม้อเดียวจบ" ถึงได้ผล

ไม่ได้หมายความว่าสมบูรณ์แบบในครั้งเดียว

พูดให้ถูกคือ แนวคิดการออกแบบตอนแรกค่อนข้างถูกทาง การแก้ไขหลังจากนั้นจึงจำกัดอยู่เฉพาะจุด

สิ่งที่สำคัญมากคือสามารถใส่คำถามต่อไปนี้ลงในการออกแบบได้ตั้งแต่ต้น

• ถ้ารันพร้อมกันจะเป็นอย่างไร
• ถ้าตายกลางคันจะเป็นอย่างไร
• ถ้าประมวลผลซ้ำสองรอบจะเป็นอย่างไร
• ถ้าเขียนโดยถือสถานะเก่าอยู่จะเป็นอย่างไร
• ถ้าเฉพาะ API ภายนอกล่มจะเป็นอย่างไร
• ถ้าข้อมูลที่ล้มเหลววนลูปไม่รู้จบจะเป็นอย่างไร
• ถ้าตัวการตรวจสอบเองพังจะเป็นอย่างไร
• ถ้ามีช่องโหว่ให้โกหกได้ว่า "สำเร็จทั้งหมด" จะเป็นอย่างไร

ปกติเรามักเรียนรู้เรื่องเหล่านี้ทีละข้อจากเหตุขัดข้องในระบบจริง

ครั้งนี้เราจำลองอุบัติเหตุในการทำงานขึ้นมาก่อน

ทำให้เซิร์ฟเวอร์ล่มในเทสต์ก่อนที่มันจะล่มจริง ให้ CI ร้องไห้ก่อนที่คนจะร้องไห้

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

ในสายตาของวงการ ถือว่าเจ๋งแค่ไหน

ตรงนี้อย่าพูดเกินจริงจะสนุกกว่า

จะบอกว่า "เป็นระบบที่แข็งแกร่งที่สุดในโลก" ก็เกินไป

แต่ก็ไม่ใช่แค่ "เขียนบล็อกด้วย AI" เช่นกัน

ถ้าจะวางตำแหน่ง ลองมองแบบนี้

สิ่งที่เทียบ	ระยะห่าง
ให้ AI เขียนบทความแล้วบันทึกไว้	นำหน้าไปไกลพอสมควร
ระบบอัตโนมัติแบบเรียงลำดับอย่าง Zapier / n8n	นำหน้าอย่างน้อยหนึ่งขั้นด้านการกู้คืนจากความล้มเหลวและการควบคุมการชนกัน
แบ็กเอนด์ที่ทำอย่างจริงจังของ SaaS ส่วนตัว	มีองค์ประกอบการออกแบบที่อยู่ในสนามเดียวกันอยู่มาก
แพลตฟอร์มอัตโนมัติภายในของบริษัทขนาดเล็กถึงกลาง	เปรียบเทียบกันได้เต็มที่
บริการเชิงพาณิชย์ที่เติบโตเต็มที่และมี SRE (วิศวกรดูแลความเสถียรของระบบ) ประจำ	ยังด้อยกว่าในด้านประวัติการใช้งานระยะยาว การเฝ้าระวังจากภายนอก และการรับประกันด้านความปลอดภัย
โครงสร้างพื้นฐานขนาดยักษ์ระดับ Google หรือ Amazon	ขนาดต่างกันคนละจักรวาล

สิ่งที่แปลกสำหรับโปรเจกต์ส่วนตัว คือ โค้ดที่งอกออกมาเรื่อง "มารยาทเวลาล้มเหลว" มีมากกว่าฟังก์ชันเขียนบทความเสียอีก

พอ lease, fencing, CAS, outbox, quarantine และ failure injection มาอาศัยอยู่ในโรงงานบทความ มันก็ไม่ใช่บล็อกแล้ว แต่เป็นศูนย์กระจายสินค้า

Level 7: ผู้จัดการโรงงานเริ่มลองข้อเสนอปรับปรุงเอง

ใน Level 6 "คำตอบที่ถูก" มนุษย์เป็นผู้กำหนด

ถ้าพังก็กลับไปที่คำตอบนั้น

ใน Level 7 ภายในขอบเขตของคำตอบที่ถูก ระบบ ค้นหาวิธีทำงานที่ดีกว่าด้วยตัวเอง

ภาพรวมเป็นดังนี้

1. วัดคุณภาพ ความเร็ว ต้นทุน เวลารอ และอัตราล้มเหลวพร้อมกัน
2. ทำให้เงื่อนไขด้านความปลอดภัยเปลี่ยนไม่ได้เด็ดขาด
3. ลองพรอมต์ใหม่และลำดับการประมวลผลใหม่ใน shadow (การทดลองคู่ขนานที่ไม่กระทบระบบจริง)
4. ถ้าดูดี ก็ขยายแบบ canary (ปล่อยทีละส่วน) เช่น 5%, 20%, 100%
5. ถ้าคุณภาพตก ให้ย้อนกลับอัตโนมัติ
6. เมื่อความน่าเชื่อถือไม่ดี ให้หยุดเฉพาะการทดลอง แล้วเดินการผลิตปกติต่อ
7. บันทึกลงสมุดบัญชีการทดลองว่าลองอะไร อะไรดี และทำไมจึงนำมาใช้

ใกล้เคียงกับการผสมแนวคิด self-optimization ในการประมวลผลแบบอัตโนมัติของ IBM, error budget ของ Google SRE (ปริมาณความผิดพลาดที่ยอมรับได้ก่อนจะต้องชะลอ) และ canary กับ rollback ของ AWS

อย่างไรก็ตาม ไม่จำเป็นต้องนำ Level 7 ขึ้นระบบจริงตอนนี้

เหตุผลง่าย ๆ คือ เรายังอยู่ระหว่างสะสมผลงานระยะยาวของ Level 6

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

ถ้าจะทำอะไรตอนนี้ ไม่ใช่ตัว Level 7 แต่ควรเป็น การเสริมการสังเกตการณ์ ด้วยการรวมการทำงานจริงของ worker ทั้งหมดไว้ในหน้าเดียวก่อน

เดือนที่จ่ายเงิน ให้ถือเป็น "เดือนลงทุนอุปกรณ์"

ไม่จำเป็นนักที่จะใช้ Ultra กับงานเบา ๆ ในแต่ละวัน

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

Ultra เหมาะกับงานที่ถ้าพลาดแล้วต้องแก้ซ้ำหนัก:

• การออกแบบระบบทั้งหมดใหม่
• การ refactor ขนาดใหญ่
• การจัดโครงสร้าง worker ใหม่
• การออกแบบการเฝ้าติดตามและการกู้คืน
• การทบทวนขอบเขตความปลอดภัย
• ฐาน shadow ของ Level 7
• การเพิ่มเทสต์และ failure injection จำนวนมาก

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

แทนที่จะมองค่าบริการ AI เป็น "ค่ารายเดือนที่ทำให้ฉลาดขึ้นทีละนิดทุกวัน" ให้มองเป็น ค่าก่อสร้างเพื่อรื้อฐานรากใหม่ในคราวเดียว

ถ้าคิดแบบนี้ ก็ไม่ต้องเปรียบเทียบคุณค่าของโมเดลหนัก ๆ ด้วยราคาต่อหนึ่งคำตอบเพียงอย่างเดียว

สิ่งที่ได้เรียนรู้มากที่สุดในประมาณหนึ่งสัปดาห์นี้

บทเรียนใหญ่สุดคือ อย่าวัดความฉลาดของ AI ด้วย "อัตราตอบถูก" เพียงอย่างเดียว

ในงานจริง ห้าอย่างนี้ได้ผล

1. ความแม่นยำของการออกแบบเบื้องต้น — ภายหลังไม่ต้องรื้อทั้งหมดใช่ไหม
2. ความสามารถในการหักล้าง — ล้มข้อเสนอของตัวเองได้ไหม
3. ความขนาน — แยกการออกแบบ การลงมือทำ การทดสอบ และการตรวจสอบ ไปทำพร้อมกันได้ไหม
4. ความเป็นหลักฐาน — ไม่ใช่ "รู้สึกว่าทำงานแล้ว" แต่บันทึกไว้ได้ว่าอะไรทำงานไปบ้าง
5. ความสามารถในการกู้คืน — ล้มเหลวแล้วกลับมาได้โดยไม่ต้องเรียกคน

กล่าวคือ โรงงาน AI ที่ดีไม่ใช่ "โรงงานที่ไม่ล้มเหลว"

แต่เป็นโรงงานที่ตั้งสมมติฐานว่าจะล้มเหลว ล้มแล้วก็ไม่หยุด ไม่รายงานความสำเร็จปลอม และกลับมายืนได้จากทุกจุด

บทสรุป: ความเร็วคือความเร็วในการไปให้ถึงจุดสุดท้าย

ถ้าสรุปเหตุผลที่มาไกลได้ขนาดนี้ในประมาณหนึ่งสัปดาห์ว่า "AI เร็วสุดขีด" ก็จะพลาดแก่นของเรื่อง

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

Ultra ไม่ใช่ปุ่มวิเศษที่ให้คำตอบถูก แต่ใกล้เคียงกับอุปกรณ์ที่จ่ายล่วงหน้าเพื่อขจัดการแก้งานซ้ำ

ต่อให้การประมวลผลครั้งหนึ่งจะช้า ถ้าเวลารวมจนเสร็จสั้น นั่นก็เร็ว

และสิ่งที่ต้องทำในขั้นนี้ ไม่ใช่รีบติดตั้ง Level 7 ที่ฉลาดกว่า

แต่คือปล่อย Level 6 ไว้สักพัก แล้วดูว่ามันทำงานต่อไปได้เองจริงหรือไม่

ถ้าโรงงานดูว่างเมื่อไร ตอนนั้นค่อยมอบอำนาจในการปรับปรุงให้ผู้จัดการโรงงาน AI

ตอนนี้ ถ้าให้ผู้จัดการมีปุ่มเปลี่ยนความเร็วสายการผลิตตามใจ มันสนุกเกินไป

• OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
• OpenAI, GPT-5.6 (ฉบับภาษาญี่ปุ่น): https://openai.com/ja-JP/index/gpt-5-6/
• IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
• IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
• Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
• Principles of Chaos Engineering: https://principlesofchaos.org/
• AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html

---