การสังเกตได้

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

สิ่งที่เราถือว่าเป็นการสังเกตได้ที่ดี

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

การตรวจสอบฟร้อนต์เอนด์แบบส่วนตัว

ความรักอีกส่วนหนึ่งของเราคือการตรวจสอบฟร้อนต์เอนด์แบบส่วนตัว คุณเห็นข้อผิดพลาดและประสิทธิภาพจริงในเบราว์เซอร์ และข้อมูลยังคงอยู่ภายในโครงสร้างพื้นฐานของคุณ โดยไม่ต้องส่งไปยังบริการของบุคคลที่สาม โดยไม่มีการพึ่งพาเพิ่มเติม โดยที่ผู้ใช้ของคุณจะไม่กลายเป็นทราฟฟิกให้กับโมเดลโฆษณาของใครอื่น เราประกอบสแต็กบนพื้นฐานของ Grafana Faro, OpenTelemetry และแบ็กเอนด์ของเราเองเพื่อรับเหตุการณ์ ทางออกเช่นนี้มีราคาสูงกว่าการเชื่อมต่อ SaaS ใน 5 นาที หนึ่งปีต่อมาคุณจะมีโครงสร้างพื้นฐานที่ทำงานโดยไม่พึ่งพาภายนอก ไม่มีขีดจำกัดเหตุการณ์ และมีต้นทุนการเป็นเจ้าของที่คาดการณ์ได้

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

การแจ้งเตือนในฐานะการปฏิบัติงานวิศวกรรม

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

สิ่งนี้ปรากฏในโครงการของเราอย่างไร

เรารวบรวมสัญญาณเพื่อให้ช่วยตัดสินใจ: ควรทำการทดลองใดบ้าง ควรปรับปรุงอะไร คอขวดอยู่ที่ไหน ข้อผิดพลาดมีราคาเท่าใด ที่ใดที่ช่วยได้ เราก็เพิ่มวิธีการติดป้ายเหตุการณ์และการทดลองอย่างรวดเร็วเพื่อแทนที่ความเชื่อด้วยความรู้ ในผลิตภัณฑ์ที่มีทราฟฟิกผู้ใช้ เรามีแผงที่มี Core Web Vitals โดยค่าเริ่มต้น แยกย่อยตามประเทศและอุปกรณ์ พร้อมมุมมองแยกต่อ «หาง» ของการกระจาย — เพราะค่าเฉลี่ยเกือบจะโกหกเสมอ ในบริการแบ็กเอนด์ เรามีการติดตามผ่านสายโซ่ทั้งหมด ซึ่งถ้าไม่มี ก็เป็นไปไม่ได้ที่จะเข้าใจว่าคำขอที่เจาะจงใช้เวลาเจ็ดวินาทีเพราะอะไร ถ้าคุณอยากเลื่อนจาก «รู้สึกว่าแย่ลง» ไปที่ «นี่คือเมตริก นี่คือสาเหตุ นี่คือช่วงเวลาของการถดถอย» — นั่นคือสไตล์ของเราพอดี

สถานะ

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

ถัดไป

ค้นหาพระคัมภีร์

เครื่องมือออร์โธดอกซ์สำหรับค้นหาและศึกษาข้อความพระคัมภีร์ ค้นหาอย่างรวดเร็ว เปรียบเทียบคำแปล การตีความ และโหมดเด็ก

→