ครบรอบ 10 ปีปฏิบัติการกู้โครงสร้าง HealthCare.gov
(pauladamsmith.com)- เมื่อวันที่ 18 ตุลาคม 2013 ทีมเทคนิคขนาดเล็กเริ่มลงพื้นที่ตรวจสอบครั้งแรกที่ทำเนียบขาวเพื่อกอบกู้ HealthCare.gov ที่หยุดชะงักทันทีหลังเปิดตัว และภารกิจนี้ต่อมาถูกเรียกว่า “tech surge”
- เว็บไซต์เปิดใช้งานเมื่อวันที่ 1 ตุลาคม 2013 แต่ทำงานได้ไม่ถูกต้อง และเพราะ การปิดหน่วยงานรัฐบาลกลาง ที่เริ่มในวันเดียวกัน การสนับสนุนจากภายนอกจึงเข้ามาได้หลังวันที่ 17 ตุลาคมเท่านั้น
- ในวันแรก ทีมได้ตระเวนไปที่ทำเนียบขาว, HHS, CMS, Exchange Operations Center และสำนักงาน CGI เพื่อระบุคอขวดของระบบขนาดใหญ่ที่มีทั้งสัญญา องค์ประกอบ กฎธุรกิจ และขั้นตอนการดีพลอยพันกันอยู่
- ในพื้นที่จริงพบว่าความเสี่ยงหลักคือการทดสอบแบบแมนนวล, การดีพลอยและโรลแบ็กยาวนานในตอนกลางคืน, การจัดเตรียมทรัพยากรที่ล่าช้า, ชั้นข้อมูลหลักที่ไม่มีสคีมา และการขาดการมอนิเตอร์แบบเรียลไทม์
- หลังติดตั้ง New Relic ด้วยตนเองลงบนเซิร์ฟเวอร์บางส่วนที่สำนักงาน CGI จึงเริ่มมองเห็นค่า latency, อัตราความผิดพลาด และจำนวนคำขอเป็นครั้งแรก จากนั้นปฏิบัติการกู้ระบบได้ขยายตัวต่ออีกราว 2 เดือนครึ่งและช่วยปรับปรุงเว็บไซต์
18 ตุลาคม 2013 จุดเริ่มต้นของปฏิบัติการกู้ระบบ
- งานฟื้นฟู HealthCare.gov เริ่มต้นอย่างจริงจังในวันศุกร์ที่ 18 ตุลาคม 2013 เวลา 7:15 น. จากกลุ่มเล็ก ๆ ที่มารวมตัวกันใกล้ทางเข้า West Wing ของทำเนียบขาว
- กลุ่มเริ่มต้นมี Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman และ Paul Smith ส่วน Mikey Dickerson เข้าร่วมในช่วงหลังของวันผ่านการคุยสปีกเกอร์โฟนยาวนาน
- บางคนมาจากนอกภาครัฐและบางคนทำงานอยู่ในรัฐบาลขณะนั้น แต่ทั้งหมดล้วนเป็นผู้เชี่ยวชาญด้านเทคนิคที่มีประสบการณ์จากสตาร์ตอัปหรือองค์กรเทคโนโลยีขนาดใหญ่
- Todd Park ซึ่งขณะนั้นเป็น CTO ของสหรัฐฯ เป็นผู้คัดเลือกคนเหล่านี้เพื่อเสริมกำลังให้เจ้าหน้าที่รัฐและทีมผู้รับเหมาที่สร้าง HealthCare.gov
- ภารกิจนี้ไม่ใช่การ “บุกเข้าช่วยแบบกองทหารม้า” แต่ใกล้เคียงกับการเข้าไปอย่างเงียบ ๆ เพื่อเก็บข้อมูลและประเมินสถานการณ์ เป็นการสนับสนุนแบบไม่วางท่าในพื้นที่ที่เต็มไปด้วยแรงกดดันและความเครียดอยู่แล้ว
- Todd Park บอกว่า 30 วันถัดจากนั้นมีความสำคัญมาก และเป้าหมายคือให้มีผู้ลงทะเบียน 7 ล้านคนภายในวันที่ 31 มีนาคม 2014 ซึ่งเป็นวันสิ้นสุดช่วงเปิดลงทะเบียน
ช่องว่างที่เกิดจากการปิดหน่วยงานและความล้มเหลวในการเปิดตัว
- HealthCare.gov เปิดตัวเมื่อวันที่ 1 ตุลาคม 2013 แต่ทำงานได้ไม่ถูกต้อง และในวันเดียวกันก็เกิดการปิดหน่วยงานรัฐบาลกลาง
- เพราะการปิดหน่วยงาน บุคลากรนอกทีมหลักของ HealthCare.gov จึงไม่สามารถเข้ามาช่วยได้
- ระหว่างนั้น ข่าวถูกเติมเต็มด้วยเรื่องการปิดหน่วยงานและหายนะของการเปิดตัวที่ดำเนินไปอย่างเชื่องช้า ทำให้ช่องว่างด้านข้อมูล การคาดเดา และความกังวลเพิ่มขึ้น
- ทำเนียบขาวไม่สามารถระบุได้ว่าอะไรผิดพลาดกับ HealthCare.gov และหากเว็บไซต์ล้มเหลว เครื่องมือหลักในการส่งมอบสิทธิประโยชน์จาก Affordable Care Act ให้ประชาชนหลายล้านคนก็อาจสั่นคลอน
- การปิดหน่วยงานสิ้นสุดลงในวันที่ 17 ตุลาคม และทีมเทคนิคจากภายนอกจึงสามารถเข้ามาตรวจดูสถานการณ์จริงและเริ่มงานได้ในตอนนั้นเอง
ภาพรวมของระบบที่มองเห็นได้ในช่วงเช้าของวันแรก
- ทีมรับประทานอาหารเช้าที่ Navy Mess ของทำเนียบขาว ก่อนขึ้นไปยังสำนักงาน Chief of Staff เพื่อพบ Denis McDonough
- Denis McDonough ถามตรง ๆ ว่า “ซ่อมได้ไหม” และสมาชิกบางคนของทีมก็ตอบว่า “ได้” ทั้งที่ยังอยู่ในสภาวะตึงเครียด
- หลังจากนั้นทีมเดินทางไปยัง Hubert H. Humphrey Building ซึ่งเป็นสำนักงานใหญ่ของ HHS เพื่อพบ Marilyn Tavenner ผู้รับผิดชอบ CMS และทีมงานของเธอ
- ในการพบกันครั้งนั้นมีการแบ่งปันข้อมูลเกี่ยวกับโครงสร้างของ HealthCare.gov องค์ประกอบฟังก์ชันหลัก ตำแหน่งปัญหาที่ผู้นำ CMS ทราบอยู่ และปัญหาด้านประสิทธิภาพในระดับสูง
- เนื่องจากผู้นำ CMS เป็นผู้เชี่ยวชาญด้านนโยบายสาธารณสุขและผู้บริหาร ข้อมูลที่ส่งต่อมาจึงใกล้เคียงกับตัวชี้วัดทางธุรกิจของเว็บไซต์และคำอธิบายประสิทธิภาพในภาพรวมเป็นหลัก
- ช่วงสายของวัน ทีมเดินทางต่อไปยังสำนักงานใหญ่ CMS ที่ Woodlawn, Maryland เพื่อพบผู้นำของ HealthCare.gov เช่น Michelle Snyder, Henry Chao และ Dave Nelson
- ที่นั่นข้อมูลเกี่ยวกับปัญหาการดีพลอย คอขวด จุดที่ผู้ใช้ “ไปต่อไม่ได้” บนเว็บไซต์ ฐานข้อมูล XML ของ MarkLogic สถาปัตยกรรมการดีพลอย และประเภทของเซิร์ฟเวอร์ ค่อย ๆ ปรากฏชัดขึ้น
ความเป็นจริงของการปฏิบัติการที่เปิดเผยใน XOC
- ช่วงบ่ายทีมเดินทางไปยัง Exchange Operations Center หรือ XOC ที่ Columbia, Maryland
- XOC เป็นศูนย์ควบคุมลักษณะ mission control สำหรับการปฏิบัติการของ HealthCare.gov และทีมได้ฟังเรื่องราวจากวิศวกรที่ดูแลเว็บไซต์โดยตรงที่นั่น
- ปัญหาที่ตรวจพบในพื้นที่จริงร้ายแรงกว่าที่คาดไว้มากในตอนแรก
- มีความไม่เชื่อมั่นต่อการเปลี่ยนแปลงซอร์สโค้ด
- หลายส่วนของเว็บไซต์ถูกสร้างขึ้นผ่านกระบวนการสร้างโค้ดที่ซับซ้อน และต้องอาศัยการประสานงานอย่างละเอียดระหว่างหลายทีม
- การทดสอบส่วนใหญ่ยังเป็นกระบวนการแบบแมนนวล
- การรีลีสและดีพลอยต้องอาศัยช่วงหยุดให้บริการตอนกลางคืนที่ยาวนาน และหากล้มเหลวก็ต้องใช้เวลาโรลแบ็กยาวนานตามมา
- ชั้นข้อมูลหลักไม่มีสคีมา
- การจัดเตรียมทรัพยากรโฮสต์ช้าและไม่ได้ทำงานแบบอัตโนมัติ
- ไม่เพียงไม่มี APM เท่านั้น แต่แม้แต่ตัวชี้วัดพื้นฐานอย่าง CPU, หน่วยความจำ, ดิสก์ และเครือข่าย ก็ยังไม่ได้ถูกจัดให้ทีมมองเห็นได้ในรูปแบบที่ใช้งานได้
- ณ จุดนี้ทีมยอมรับว่าสถานการณ์เลวร้ายกว่าที่ประเมินไว้มากในตอนแรก และ Paul Smith ก็รีบจดสิ่งที่ได้ยินลงในสมุด Moleskine
คืนที่ติดตั้ง New Relic ที่สำนักงาน CGI
- ตอนเย็นทีมเดินทางไปยังสำนักงาน CGI ที่ Herndon, Virginia
- CGI เป็นผู้รับเหมาหลักของ HealthCare.gov และทีมได้พบทั้งฝ่ายบริหารและทีมเทคนิคเพื่อซักถามรายละเอียด
- ในการพบกันครั้งนี้ การสร้างความไว้วางใจจากทีม CGI ให้กับทีมเทคนิคภายนอกเป็นเรื่องสำคัญ
- ทีม CGI อยู่ภายใต้แรงกดดันและอ่อนล้า
- ทีมกู้ระบบย้ำว่าพวกเขาไม่ได้มาเพื่อกล่าวโทษ แต่มาเพื่อช่วยเหลือ
- พวกเขาพยายามแสดงความสามารถด้านวิศวกรรมโดยอาศัยประสบการณ์กับเว็บไซต์ทราฟฟิกสูง
- คำถามสำคัญคือ “มีอะไรผิดพลาดกับเว็บไซต์ และรู้ได้อย่างไร” แต่ทั้ง CMS และ CGI ส่วนใหญ่ยังไม่สามารถแสดงให้เห็นได้ว่าภายในระบบมีองค์ประกอบใดบ้างที่ทำงานไม่เป็นไปตามคาด
- ทีมจึงเสนอให้ลองติดตั้ง New Relic ซึ่งเป็นบริการมอนิเตอร์แบบ APM ที่คุ้นเคย ลงบนเซิร์ฟเวอร์บางส่วน
- พวกเขาข้ามขั้นตอนรีลีสตามปกติและติดตั้งเอเจนต์ลงบนเซิร์ฟเวอร์ที่เลือกด้วยตนเอง จากนั้นเมื่อผู้นำของ CMS ยืนยันว่ามีไลเซนส์ New Relic อยู่แล้วก็อนุมัติให้ดำเนินการ
- ผู้ที่ยังอยู่จนเกือบเที่ยงคืนช่วยกันทำการเปลี่ยนแปลง และบนหน้าจอในห้องประชุม หน้าแอดมินของ New Relic ก็เริ่มเห็นเซิร์ฟเวอร์ “red shard” ที่เลือกไว้ส่งค่าตัวชี้วัดเข้ามา
- เป็นครั้งแรกที่มองเห็นตัวชี้วัดการปฏิบัติการแบบเรียลไทม์ เช่น การพุ่งขึ้นของ request latency, อัตราความผิดพลาด และจำนวนคำขอต่อนาที ทำให้สภาพของระบบที่ก่อนหน้านี้แทบมองไม่เห็นเริ่มปรากฏชัด
- ตัวชี้วัดเหล่านี้ช่วยให้เชื่อมโยงตัวชี้วัดทางธุรกิจกับสถานะของระบบ และสร้างฐานสำหรับจัดลำดับความสำคัญของการแก้ไขและมาตรการที่ให้ผลปรับปรุงมากที่สุด
หลังผ่านวันแรกที่ยาวนาน 18 ชั่วโมง
- หลังออกจาก Herndon ทีมกลับมาทบทวนกันสั้น ๆ ในห้อง Roosevelt Room ที่เงียบสงบของทำเนียบขาวราวตี 2
- ณ จุดนี้ทีมตระหนักว่าปัญหาไม่ได้เล็กพอจะจบด้วยการให้คำปรึกษาระยะสั้น และพวกเขาจำเป็นต้องทุ่มเทกับงานนี้ต่อไปอีกระยะหนึ่งจนกว่าเว็บไซต์จะฟื้นตัว
- หลังได้นอนไม่กี่ชั่วโมง เช้าวันถัดมาพวกเขาก็มุ่งหน้ากลับไปยัง Herndon อีกครั้ง
- ตารางของวันแรกกินเวลาราว 18 ชั่วโมง และหลังจากนั้นก็ยังมีการทำงานแบบมาราธอนในลักษณะคล้ายกันต่อเนื่อง
- จนถึงปลายเดือนธันวาคม ตลอดช่วงเวลาราว 2 เดือนครึ่ง tech surge ได้ขยายตัวและมีสมาชิกใหม่เข้าร่วม พร้อมช่วยผลักดันการปรับปรุง HealthCare.gov
- ในปีนั้น ผู้คนหลายล้านคนได้ลงทะเบียนรับความคุ้มครองประกันสุขภาพ และสำหรับหลายคน นี่เป็นครั้งแรกในชีวิต
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เจตนาเดิมคือให้แต่ละรัฐดำเนินการตลาดแลกเปลี่ยนของตัวเอง และให้เฉพาะประชาชนในรัฐที่ปฏิเสธเท่านั้นใช้ ตลาดแลกเปลี่ยนของรัฐบาลกลาง
ตอนแรกมี 36 รัฐที่ไม่ได้สร้างตลาดแลกเปลี่ยนของตัวเอง 0 และตอนนี้ดูเหมือนว่ามี 20 รัฐรวมถึง D.C. ที่ดำเนินการ Marketplace ของตัวเอง 1
การปิดหน่วยงานรัฐบาลในปี 2013 ที่ทำให้คนนอกทีมประจำรัฐของ HealthCare.gov เข้ามาช่วยไม่ได้ เป็นสิ่งที่วุฒิสมาชิก Ted Cruz เป็นผู้นำโดยมี จุดประสงค์เพื่อขัดขวาง ACA 2
บางครั้งรู้สึกว่าหลักการของสหรัฐฯ ที่ว่า “แต่ละรัฐเป็นอิสระจากกัน” มันไปไกลเกินไป
คนเหล่านี้กังวลว่าระบบสาธารณสุขของรัฐบาลกลางจะนำไปสู่หลักประกันสุขภาพถ้วนหน้าในท้ายที่สุด และหลังจากได้ข้อประนีประนอมแล้ว ก็ปฏิเสธการนำตลาดแลกเปลี่ยนไปใช้งาน โดยหวังให้กฎหมายตายไป
แต่กฎหมายไม่ได้ตาย และพวกเขาก็ยังไม่พอใจเรื่องนั้นอยู่
ผลจากการโอนเงินทุนของรัฐบาลกลางเป็นเงินอุดหนุนแบบก้อนให้แต่ละรัฐ และให้รัฐรับผิดชอบโปรแกรมอย่าง TANF รวมถึงการตรวจสอบคุณสมบัติ 1 ทำให้ประสิทธิภาพที่เงินงบประมาณรัฐบาลกลาง 1 ดอลลาร์จะกลายเป็นความช่วยเหลือจริง รวมถึงจำนวนคนที่ได้รับความช่วยเหลือและจำนวนเงินที่ได้รับ แย่ลงอย่างมาก
ผมไม่รู้เหตุผลของ Marketplace ระดับรัฐใน ACA แต่ในเชิงประวัติศาสตร์ การแทรกรัฐเข้ามามักเพิ่มช่องให้ตัวกลางทำให้โปรแกรมเสียหายและโยกเงินไปใช้ที่อื่น
ตัวอย่างเช่น Texas ปฏิเสธเงินฟรีปีละ 5–6 พันล้านดอลลาร์ที่รัฐบาลกลางตั้งใจจะให้เพื่อขยาย Medicaid 2
เหมือนเคยมีข่าวหลายครั้งว่า บริษัทประกันบางรายขาดทุนเพราะผู้ป่วยจำนวนน้อยที่มีค่ารักษาแพงมาก และเมื่อค่าใช้จ่ายนั้นสูงจนต้องขึ้นราคา ก็ไม่มีใครอยากซื้อผลิตภัณฑ์นั้น
ช่วงหลังผมลองหาข่าวพวกนั้นแล้วแต่หาไม่เจอ จนเริ่มสับสนว่าเป็นเรื่องที่ผมจินตนาการไปเองหรือเปล่า
มีเงินและเต็มใจจะทำธุรกรรม แต่ทำไม่ได้ แบบนี้ระบบก็ล้มเหลวแล้ว
ผมยังจำได้ตอนที่ได้ทำงานกับคนเหล่านี้ ตอนที่ทุกคนถูกดึงเข้ามาเพื่อแก้เรื่องนี้
Gabe เขียนโค้ดด้วย VIM ได้เหมือนนักไวโอลินชั้นครู ส่วนการทำงานกับ Mikey ทำให้เห็นพลังของ เมตริกและ SRE
จากสภาพที่ทุกคนในห้องชี้นิ้วโทษเวนเดอร์รายถัดไป กลายเป็นการเริ่มค้นพบคอขวดบางส่วนจริง ๆ
โดยรวมแล้ว การซ่อมระบบที่พังโดยไม่สามารถนำลงออฟไลน์เพื่อทำรีแฟกเตอร์ครั้งใหญ่ได้ ก็เหมือนผ่าตัดคนที่กำลังจ็อกกิงอยู่ เป็นประสบการณ์ที่โหดมากจริง ๆ
สตาร์ทอัพเล็ก ๆ ใน D.C. เป็นประมาณผู้รับเหมาช่วงของผู้รับเหมาช่วงของผู้รับเหมาช่วงที่รับผิดชอบหน้า landing page ฝั่งหน้าเว็บ แต่ก็ยังจำได้ดีที่อย่างน้อยเราทำให้ผู้คนที่เข้า healthcare.gov ไปเจอหน้าจริง ๆ ไม่ใช่ หน้า error 500
ถ้าจำไม่ผิด เป็นเพราะมีเซิร์ฟเวอร์เดี่ยวที่ใช้ Jekyll หนึ่งเครื่องกับเครื่องสำรองอีกหนึ่งเครื่อง
ถ้าใช้คำในปัจจุบันก็คือแนวทาง “static page generation” จึงโฮสต์บนฮาร์ดแวร์ขนาดเล็กได้
ตอนนั้นถือว่าเป็นยุทธวิธีที่ค่อนข้างล้ำหน้า และน่าจะเป็นสิ่งที่ผู้พูดนึกถึง
เท่าที่ผมรู้ เว็บไซต์นั้นถูกแทนที่ทั้งหมดเมื่อเปิดตลาดแลกเปลี่ยนของรัฐบาลกลาง และตัว landing page เองไม่ได้รับหรือประมวลผลข้อมูลส่วนบุคคล จึงไม่ได้มีอุปสรรคใหญ่ในการให้บริการ
ทุกอย่างหยุดชะงักก็ต่อเมื่อผู้ใช้เริ่มพยายามค้นหาผลิตภัณฑ์ประกันจริง ๆ
Development Seed ยังสร้างอีกโปรเจกต์หนึ่งที่คุณน่าจะเคยได้ยินในภายหลังคือ Mapbox และสุดท้ายทั้งบริษัทก็เปลี่ยนไปทางนั้นทั้งหมด
ผมจำได้ว่าเคยได้ยินในพอดแคสต์หนึ่งว่า แทนที่จะแสดงความล้มเหลวแบบ “backend timeout” เป็นข้อผิดพลาด พวกเขาเปลี่ยนเป็นส่งข้อมูลทางอีเมล แล้วบอกผู้ใช้ว่า “เรียบร้อย เราได้รับแล้ว กลับมาตรวจสอบภายหลังนะ”
ผมคิดว่ามันฉลาดมาก และจำไว้เป็นวิธีที่เอาไปใช้ได้ในสถานการณ์ฉุกเฉินภายหลัง
ที่ WebTV ตอนฐานข้อมูลโอเวอร์โหลดก็เคยมีเรื่องคล้ายกัน โดยปิดเมลเดลิเวอรีเซิร์ฟเวอร์ขั้นสุดท้ายทั้งหมดที่ต้องใช้การเชื่อมต่อฐานข้อมูล เพื่อให้เมลไปเข้าคิวอยู่ที่เซิร์ฟเวอร์ inbound SMTP แล้วค่อยระบายออกหลังจากโหลดฐานข้อมูลลดลง
บทเรียนคือ หากต้องการลดโหลดของระบบที่ถูกออกแบบมาให้ทำงานแบบทรานแซกชัน แต่กำลังล้มเหลว ให้ใช้ การประมวลผลแบบเน้นแบตช์ ที่ประมวลผลจากคิว
ตอนของพอดแคสต์ “Go Time” ที่พูดถึงหัวข้อนี้ยอดเยี่ยมมาก และครอบคลุมว่าใช้ Go อย่างไรในการให้บริการบางส่วนของไซต์
ขอแนะนำตอนนี้และพอดแคสต์นี้อย่างยิ่ง
https://changelog.com/gotime/154
กดเข้ามาเพราะคิดว่าจะเป็นการอภิปรายเชิงเทคนิคที่น่าสนใจ แต่เรื่องเทคนิคกว่าจะมาก็อยู่ช่วงค่อนข้างท้ายแล้ว
แทนที่จะเป็นอย่างนั้น ภาพ เบื้องหลัง ของกระบวนการกลับน่าสนใจมากเกินคาด และตั้งตารอตอนต่อไปจริง ๆ
อ่านบทความนี้แล้วชอบมาก
ทำให้นึกถึงเมื่อ 10 ปีก่อนที่ HN ช่วยกันขุดดูซอร์สโค้ด GitHub ของเว็บไซต์อย่างละเอียด: https://news.ycombinator.com/item?id=6540993
สิ่งที่เกิดขึ้นจริงไม่ได้สมบูรณ์แบบนัก แต่ก็สงสัยว่านอกจากบททบทวนนี้แล้ว มีแหล่งข้อมูลที่อธิบายละเอียดกว่านี้ไหมว่าเกิดอะไรขึ้นกันแน่และแก้ไขอย่างไร
ตั้งใจว่าจะคอยตามอ่านบทความถัด ๆ ไปในซีรีส์นี้ด้วย
ให้ความรู้สึกเหมือนเป็น engineering competence porn นิด ๆ แต่ก็ชอบเรื่องแบบนี้
เมื่อหลายปีก่อนเคยอ่าน The Phoenix Project ซึ่งเป็นหนังสือแนวนิยายและแนะนำ Agile กับ DevOps อย่างค่อนข้างโจ่งแจ้ง แต่สำหรับผมที่เป็นนักวิเคราะห์ข้อมูล มันใหม่และดีมาก ถ้ามีคำแนะนำแนวคล้ายกันก็อยากลองอ่าน
ยกข้อความดี ๆ มาสักส่วนหนึ่ง Dickerson ติดกฎไว้บนผนังตรงนอกห้องควบคุม
กฎข้อ 1: “war room และการประชุมมีไว้เพื่อแก้ปัญหา มีที่อื่นอีกมากมายให้ใช้พลังสร้างสรรค์ไปกับการโยนความผิด”
กฎข้อ 2: “คนที่ควรพูดเรื่องใดเรื่องหนึ่ง ไม่ใช่คนที่ตำแหน่งสูงที่สุด แต่คือคนที่รู้เรื่องนั้นดีที่สุด ถ้ามีใครนั่งเงียบอยู่เฉย ๆ ขณะที่ผู้จัดการและผู้บริหารพูดด้วยข้อมูลที่แม่นยำน้อยกว่า แปลว่าเรากำลังหลุดจากแนวทาง และผมอยากรู้เรื่องนั้น” ต่อมา Dickerson อธิบายว่า “พอเอาผู้จัดการออกไป วิศวกรก็อยากแก้ปัญหา”
กฎข้อ 3: “เราต้องโฟกัสประเด็นเร่งด่วนที่สุดที่จะทำร้ายเราได้ใน 24–48 ชั่วโมงข้างหน้า”
ทางแก้คืออย่าให้บริษัทเดิม ๆ เหล่านี้ได้ทำงานแบบนี้ต่อไปเรื่อย ๆ
ดูชัดเจนว่า CGI, IBM และบริษัททำนองนี้ไม่มีความสามารถเพียงพอ แต่ไม่เข้าใจว่าทำไมพวกเขาไม่ถูก ห้ามเข้าประมูล สัญญาในอนาคตที่คล้ายกัน
ถ้าทำสัญญาพัง ก็ควรถูกกันออกจากสัญญารัฐทั้งหมดไป 10 ปี
แบบนั้นเราจะได้เทคโนโลยีที่ใช้งานได้จริง แทนที่จะวนเวียนได้ผลงานขยะซ้ำ ๆ
เลยทำให้บริษัทเล็ก ๆ เข้ามาแข่งขันได้ยาก
หรือไม่ก็สลับทีมกันเสีย
ไม่นานก็จะไม่เหลือใครรับงาน
“เทคโนโลยีบางอย่าง รวมถึง ฐานข้อมูล XML ที่ชื่อ MarkLogic” นี่นะ ฐานข้อมูล XML สำหรับบริการหลักที่มีผู้ใช้ 300 ล้านคน?
น่าขนลุก
เดาว่ากฎทางธุรกิจน่าจะอยู่ใน XML และแทบจะเป็นแบบอ่านอย่างเดียว ส่วนข้อมูลแบบไดนามิกอยู่ในฐานข้อมูลเชิงสัมพันธ์มากกว่า
หรืออาจเป็นแค่การเดาแบบเข้าข้างความหวังก็ได้
อาจเป็นฐานข้อมูลสำหรับคอนฟิก แต่ฟังดูเหมือนปัญหามาจาก business logic ซึ่งแค่นั้นเองก็อาจเป็นปัญหาได้แล้ว