ชาริตี้ เมเจอส์ CTO และผู้ร่วมก่อตั้ง Honeycomb – ซีรีส์สัมภาษณ์

Charity เป็นวิศวกรฝ่ายปฏิบัติการและผู้ก่อตั้งสตาร์ทอัพโดยไม่ตั้งใจที่ Honeycomb ก่อนหน้านี้เธอทำงานด้านโครงสร้างพื้นฐานและเครื่องมือสำหรับนักพัฒนาที่ Parse, Facebook (META ) และ Linden Lab และมักลงเอยด้วยการดูแลฐานข้อมูลอยู่เสมอ เธอเป็นผู้เขียนร่วมของหนังสือ Database Reliability Engineering ของ O’Reilly และชื่นชอบเสรีภาพในการแสดงความคิดเห็น ซอฟต์แวร์เสรี และสกอตช์ซิงเกิลมอลต์

คุณเคยเป็นผู้จัดการฝ่ายวิศวกรรมการผลิตที่ Facebook (ปัจจุบันคือ Meta) นานกว่าสองปี ช่วงนั้นมีเหตุการณ์เด่นอะไรบ้าง และคุณได้บทเรียนสำคัญอะไรจากประสบการณ์ดังกล่าว

ฉันทำงานกับ Parse ซึ่งเป็นแบ็กเอนด์สำหรับแอปมือถือ คล้ายกับ Heroku สำหรับมือถือ ฉันไม่เคยสนใจทำงานในบริษัทใหญ่ แต่ Facebook เข้าซื้อกิจการเรา บทเรียนสำคัญอย่างหนึ่งคือการถูกซื้อกิจการนั้นยากมาก แม้อยู่ในสถานการณ์ที่ดีที่สุด คำแนะนำที่ฉันให้ผู้ก่อตั้งรายอื่นเสมอคือ หากกำลังจะถูกซื้อกิจการ ต้องมั่นใจว่ามีผู้บริหารระดับสูงเป็นผู้สนับสนุน และคิดให้รอบคอบว่าทั้งสองฝ่ายมีทิศทางเชิงกลยุทธ์สอดคล้องกันหรือไม่ Facebook ซื้อ Instagram ไม่นานก่อนซื้อ Parse การซื้อ Instagram ไม่ได้ราบรื่นสวยงาม แต่ท้ายที่สุดประสบความสำเร็จอย่างมาก เพราะมีทิศทางสอดคล้องกันและมีผู้สนับสนุนที่แข็งแกร่ง

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

ช่วยเล่าจุดเริ่มต้นของการก่อตั้ง Honeycomb ได้ไหม

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

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

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

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

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

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

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

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

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

การตรวจสอบแบบดั้งเดิมมีสามเสาหลักที่รู้จักกันดี ได้แก่ เมตริก ล็อก และเทรซ โดยทั่วไปคุณต้องซื้อเครื่องมือหลายชนิดให้ครอบคลุมความต้องการ เช่น logging, tracing, APM, RUM, แดชบอร์ด และการแสดงภาพ แต่ละอย่างถูกปรับให้เหมาะกับกรณีใช้งานและรูปแบบข้อมูลที่ต่างกัน วิศวกรต้องนั่งอยู่ตรงกลางและพยายามทำความเข้าใจทั้งหมด คุณไล่ดูแดชบอร์ดเพื่อหารูปแบบด้วยสายตา คัดลอก ID จากล็อกไปเทรซแล้วกลับมาอีกครั้ง กระบวนการนี้เป็นการตั้งรับและแยกส่วน และมักใช้เครื่องมือเหล่านี้เมื่อเกิดปัญหา เพราะถูกออกแบบมาเพื่อช่วยเดินระบบและค้นหาบั๊กหรือข้อผิดพลาด

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

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

Observability เหมือนสวมแว่นก่อนขับรถด้วยความเร็วสูงบนทางด่วน การพัฒนาแบบขับเคลื่อนด้วยการทดสอบ (TDD) ปฏิวัติซอฟต์แวร์ช่วงต้นทศวรรษ 2000 แต่ยิ่งความซับซ้อนไปอยู่ในระบบแทนที่จะอยู่เพียงในซอฟต์แวร์ TDD ก็ยิ่งมีประสิทธิผลลดลง หากต้องการประโยชน์จาก TDD ปัจจุบันคุณต้องติดตั้งเครื่องมือวัดในโค้ดและใช้แนวทางคล้ายการพัฒนาที่ขับเคลื่อนด้วย Observability (ODD): ติดตั้งเครื่องมือวัดไปพร้อมกับพัฒนา ปรับใช้ให้เร็ว จากนั้นดูโค้ดจริงผ่านข้อมูลที่เพิ่งเก็บและถามว่า “มันทำสิ่งที่คาดไว้หรือไม่ และมีอย่างอื่นที่ดูแปลกไปหรือเปล่า”

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

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

สิ่งที่ทำให้ฉันตื่นเต้นกับ AI คือ เมื่อพัฒนาด้วย LLM เราต้องพัฒนาในระบบจริง วิธีเดียวที่จะสร้างชุดทดสอบได้คือยืนยันโค้ดในระบบจริงก่อนแล้วค่อยย้อนกลับมาสร้างการทดสอบ ฉันคิดว่าอีกไม่กี่ปี การเขียนซอฟต์แวร์ที่ใช้ LLM จะเป็นทักษะทั่วไปพอๆ กับการเขียนซอฟต์แวร์ที่ใช้ MySQL หรือ Postgres และหวังว่าสิ่งนี้จะผลักวิศวกรให้เข้าสู่วิธีทำงานที่ดีกว่า แม้พวกเขาจะขัดขืนก็ตาม

คุณแสดงความกังวลเรื่องหนี้ทางเทคนิคที่เพิ่มขึ้นจากการปฏิวัติ AI ช่วยอธิบายได้ไหมว่า AI อาจสร้างหนี้ประเภทใด และ Honeycomb ช่วยจัดการหรือลดหนี้เหล่านั้นอย่างไร

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

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

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

Honeycomb ใช้ AI เพื่อเพิ่มประสิทธิภาพและประสิทธิผลของทีมวิศวกรรมอย่างไร

วิศวกรของเราใช้ AI ภายในองค์กรมาก โดยเฉพาะ CoPilot วิศวกรระดับต้นบอกว่าใช้ ChatGPT ทุกวันเพื่อตอบคำถามและช่วยทำความเข้าใจซอฟต์แวร์ที่กำลังสร้าง ส่วนวิศวกรอาวุโสบอกว่ามันเหมาะกับการสร้างซอฟต์แวร์ที่น่าเบื่อหรือยุ่งยาก เช่น การกรอกไฟล์ YAML ขนาดใหญ่ และยังช่วยสร้างโค้ดสั้นๆ ในภาษาที่ไม่ค่อยใช้หรือจากเอกสาร API ได้ ตัวอย่างเช่น มันสร้างตัวอย่างการใช้ AWS SDK และ API ที่ใช้งานได้ดี เพราะได้รับการฝึกจากคลังโค้ดซึ่งมีการใช้จริง

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

ช่วยยกตัวอย่างได้ไหมว่าคุณสมบัติที่ขับเคลื่อนด้วย AI อย่าง Query Assistant หรือการเชื่อมต่อ Slack ช่วยส่งเสริมการทำงานร่วมกันของทีมอย่างไร

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

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

Honeycomb สัญญาว่าจะแก้เหตุขัดข้องได้เร็วขึ้น การรวมล็อก เมตริก และเทรซไว้เป็นข้อมูลชนิดเดียวช่วยให้ดีบักและแก้ปัญหาได้เร็วขึ้นอย่างไร

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

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

นอกจากนี้ เมื่อใช้ล็อกและเมตริก คุณต้องรู้ว่ากำลังหาอะไรก่อนจึงจะพบ แต่ Observability สมัยใหม่ไม่เป็นเช่นนั้น คุณไม่จำเป็นต้องรู้อะไรล่วงหน้าหรือค้นหาสิ่งเฉพาะเจาะจง

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

ไม่ใช่เพียงเรื่องข้อมูลรวมศูนย์ แม้นั่นจะเป็นส่วนสำคัญ แต่ยังรวมถึงการจัดการข้อมูลคาร์ดินาลิตีสูงอย่างง่ายดาย เช่น ID เฉพาะ, ID ตะกร้าสินค้า, app ID และชื่อหรือนามสกุล เครื่องมือรุ่นก่อนไม่สามารถจัดการข้อมูลที่มีรายละเอียดสูงเช่นนี้ได้ ซึ่งน่าเหลือเชื่อ เพราะข้อมูลคาร์ดินาลิตีสูงที่สมบูรณ์คือข้อมูลซึ่งมีค่ามากที่สุดและใช้ระบุสิ่งต่างๆ ได้ดีที่สุด

Observability ที่ดีขึ้นแปลงเป็นผลลัพธ์ทางธุรกิจที่ดีขึ้นอย่างไร

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

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

คุณมองว่าอนาคตของ Observability จะไปทางใด โดยเฉพาะเมื่อคำนึงถึงพัฒนาการของ AI

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

มันเชื่อมโยงจุดต่างๆ ระหว่างผลลัพธ์ทางธุรกิจกับวิธีการทางเทคโนโลยี

และทำให้มั่นใจว่าเราเข้าใจซอฟต์แวร์ที่นำออกสู่โลก เมื่อซอฟต์แวร์และระบบซับซ้อนขึ้น โดยเฉพาะเมื่อ AI เข้ามาเกี่ยวข้องมากขึ้น การยึดตนเองไว้กับมาตรฐานความเข้าใจและการจัดการของมนุษย์ยิ่งสำคัญกว่าที่เคย

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

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

ขอบคุณสำหรับบทสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมสามารถเยี่ยมชม Honeycomb