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

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

คุณ曾เป็น Production Engineering Manager ที่ Facebook (ปัจจุบันคือ Meta) มาเกิน 2 ปี คุณมีประสบการณ์หรือเรื่องราวที่น่าสนใจในช่วงเวลานั้นบ้าง และคุณได้เรียนรู้อะไรจากประสบการณ์นี้

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

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

คุณสามารถเล่าเรื่องราวเกี่ยวกับการก่อตั้ง Honeycomb ได้หรือไม่

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

เรากำลังอยู่ในกลุ่มผู้บุกเบิกการเปลี่ยนแปลงที่กลายเป็นกระแสหลักใน 10 ปีที่ผ่านมา อุตสาหกรรมนี้ได้เห็นการระเบิดของความซับซ้อนของสถาปัตยกรรม ในช่วง 10 ปีที่ผ่านมา เราได้ทำลายโมโนลิธ์ ดังนั้น ตอนนี้คุณมีเซอร์วิสไมโครหลายตัวตั้งแต่หลายตัวจนถึงหลายพัน Polyglot persistence เป็นเรื่องปกติ ไม่ใช่ “ฐานข้อมูล” แต่เป็นเรื่องปกติที่จะมีหลายประเภทของการเก็บข้อมูล เช่นเดียวกับการแบ่งส่วนแบบแนวนอน เลเยอร์ของการแคช db ต่อ microservice คิว และอื่นๆ นอกจากนี้คุณยังมี контейเนอร์ที่โฮสต์บนเซิร์ฟเวอร์ ซอฟต์แวร์ระดับเซิร์ฟเวอร์ เซิร์ฟเวอร์เลส โค้ด บล็อกสโตร์ และอื่นๆ

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

สำหรับผู้อ่าน الذينไม่คุ้นเคยกับเรื่องนี้ คุณสามารถอธิบายได้ว่าแพลตฟอร์ม Observability คืออะไร และมันแตกต่างจากการตรวจสอบและเมตริกแบบดั้งเดิมอย่างไร

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การปรับปรุงการตรวจสอบสามารถนำไปสู่ผลลัพธ์ทางธุรกิจที่ดีกว่าได้อย่างไร

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

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

คุณเห็นอนาคตของการตรวจสอบไปทางไหน โดยเฉพาะอย่างยิ่งเกี่ยวกับการพัฒนาของ AI

การตรวจสอบกำลังเป็นเรื่องเกี่ยวกับการช่วยให้ทีมเชื่อมต่อลูปฟีดแบ็กที่รวดเร็วและแน่นหนา เพื่อให้พวกเขาสามารถพัฒนาอย่างรวดเร็ว มั่นใจ และไม่สูญเสียเวลาและพลังงาน

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

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

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

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

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