Chapter 22 14 Create Telemetry To Enable Seeing And Solving Problems

14

สร้าง Telemetry เพื่อให้มองเห็นและแก้ไขปัญหาได้

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

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

ในฝ่ายปฏิบัติการ เราอาจจัดการกับปัญหานี้ด้วยกฎง่ายๆ ดังนี้: เมื่อมีอะไรผิดพลาดใน Production ให้รีบูตเซิร์ฟเวอร์ ถ้าไม่ได้ผล ให้รีบูตเซิร์ฟเวอร์ตัวถัดไป ถ้ายังไม่ได้ผล ให้รีบูตเซิร์ฟเวอร์ทั้งหมด ถ้ายังไม่ได้ผลอีก ให้โทษนักพัฒนา พวกเขามักเป็นต้นเหตุให้ระบบหยุดทำงานอยู่เสมอ 1

ในทางกลับกัน การศึกษาของ Microsoft Operations Framework (MOF) ในปี 2001 พบว่าองค์กรที่มีระดับการให้บริการสูงสุด รีบูตเซิร์ฟเวอร์น้อยกว่าค่าเฉลี่ยถึงยี่สิบเท่า และมี "จอฟ้าแห่งความตาย" น้อยกว่าถึงห้าเท่า 2 กล่าวอีกนัยหนึ่ง พวกเขาพบว่าองค์กรที่มีประสิทธิภาพดีที่สุดนั้นมีความสามารถในการวินิจฉัยและแก้ไขเหตุการณ์ขัดข้องด้านบริการได้ดีกว่ามาก ในสิ่งที่ Kevin Behr, Gene Kim, และ George Spafford เรียกว่า "วัฒนธรรมแห่งเหตุและผล" ใน The Visible Ops Handbook องค์กรที่มีประสิทธิภาพสูงใช้แนวทางที่มีวินัยในการแก้ปัญหา โดยใช้ production telemetry เพื่อทำความเข้าใจ ปัจจัยที่อาจมีส่วนเกี่ยวข้อง เพื่อมุ่งเน้นการแก้ปัญหา ตรงกันข้ามกับองค์กรที่มีประสิทธิภาพต่ำกว่าที่จะรีบูตเซิร์ฟเวอร์อย่างสุ่มสี่สุ่มห้า 3

เพื่อให้เกิดพฤติกรรมการแก้ปัญหาอย่างมีวินัยนี้ เราจำเป็นต้องออกแบบระบบของเราให้สร้าง telemetry อย่างต่อเนื่อง ซึ่งหมายถึง "กระบวนการสื่อสารอัตโนมัติที่ใช้เก็บรวบรวมการวัดและข้อมูลต่างๆ จากจุดที่ห่างไกล และส่งต่อไปยังอุปกรณ์รับสำหรับการตรวจสอบ" 4 เป้าหมายของเราคือการสร้าง telemetry ภายในแอปพลิเคชันและสภาพแวดล้อมของเรา ทั้งในสภาพแวดล้อม production และ pre-production รวมถึงใน deployment pipeline ของเราด้วย

การเปลี่ยนแปลง DevOps ที่ Etsy (2012)

Michael Rembetsy และ Patrick McDonnell อธิบายว่าการตรวจสอบ production เป็นส่วนสำคัญของการเปลี่ยนแปลง DevOps ของ Etsy ที่เริ่มต้นในปี 2009 ทั้งนี้เพราะพวกเขากำลังทำให้เทคโนโลยีทั้งหมดเป็นมาตรฐานและเปลี่ยนไปใช้ LAMP stack (Linux, Apache, MySQL, และ PHP) โดยละทิ้งเทคโนโลยีต่างๆ มากมายที่ถูกใช้ใน production ซึ่งยากต่อการสนับสนุนมากขึ้นเรื่อยๆ

ในงาน Velocity Conference ปี 2012 McDonnell อธิบายว่าสิ่งนี้สร้างความเสี่ยงมากเพียงใด:

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

McDonnell อธิบายเพิ่มเติมว่า

เราเริ่มรวบรวมข้อมูลเซิร์ฟเวอร์ทั้งหมดในเครื่องมือที่ชื่อว่า Ganglia และแสดงข้อมูลทั้งหมดลงใน Graphite ซึ่งเป็น open-source tool ที่เราลงทุนอย่างหนัก เราเริ่มรวบรวม metrics ต่างๆ เข้าด้วยกัน ตั้งแต่ business metrics ไปจนถึง deployments นี่คือตอนที่เราแก้ไข Graphite ด้วยสิ่งที่เราเรียกว่า "เทคโนโลยีเส้นแนวตั้งที่ไม่มีใครเทียบและไม่มีใครเสมอเหมือน" ซึ่งซ้อนทับลงบนทุก metric graph เมื่อมีการ deploy เกิดขึ้น การทำแบบนี้ทำให้เรา เห็นผลข้างเคียงที่ไม่ได้ตั้งใจจากการ deploy ได้เร็วขึ้น เรายังเริ่มติดตั้งจอทีวีทั่วทั้งสำนักงานเพื่อให้ ทุกคนสามารถดูว่าบริการต่างๆ ของเราทำงานเป็นอย่างไร 6

การเปิดโอกาสให้นักพัฒนาเพิ่ม telemetry ให้กับฟีเจอร์ของพวกเขาในฐานะส่วนหนึ่งของงานประจำวัน Etsy สร้าง telemetry เพียงพอที่จะทำให้ deployments ปลอดภัย ภายในปี 2011 Etsy ติดตาม production metrics กว่าสองแสนรายการในทุกเลเยอร์ ของ application stack (เช่น ฟีเจอร์ของแอปพลิเคชัน, สุขภาพของแอปพลิเคชัน, ฐานข้อมูล, ระบบปฏิบัติการ, พื้นที่จัดเก็บ, เครือข่าย, ความปลอดภัย ฯลฯ) โดย metrics ทางธุรกิจที่สำคัญที่สุดสามสิบอันดับแรกถูกแสดงอย่างเด่นชัดบน "deploy dashboard" ของพวกเขา ภายในปี 2014 พวกเขาติดตาม metrics กว่าแปดแสนรายการ ซึ่งแสดงให้เห็นเป้าหมายที่ไม่หยุดยั้งในการ instrument ทุกอย่างและทำให้วิศวกรสามารถทำได้อย่างง่ายดาย 7

Ian Malpass วิศวกรของ Etsy กล่าวติดตลกว่า

ถ้าวิศวกรรมที่ Etsy มีศาสนา ก็คือศาสนจักรแห่งกราฟ (Church of Graphs) ถ้าอะไรขยับได้ เราก็ติดตามมัน บางครั้งเราจะวาด กราฟของสิ่งที่ยังไม่ขยับ เผื่อว่ามันตัดสินใจจะขยับหนี . . . การติดตามทุกอย่างเป็น กุญแจสำคัญในการทำงานได้เร็ว แต่วิธีเดียวที่จะทำได้คือทำให้การติดตามอะไรก็ตามเป็นเรื่องง่าย . . . เราทำให้วิศวกรสามารถติดตาม สิ่งที่พวกเขาต้องการติดตามได้ในทันที โดยไม่ต้องเปลี่ยนแปลงการกำหนดค่าที่ยุ่งยากหรือกระบวนการที่ซับซ้อน 8

ในรายงาน State of DevOps Report ปี 2015 องค์กรที่มีประสิทธิภาพสูงแก้ไขเหตุการณ์ใน production ได้เร็วกว่าเพื่อนถึง 168 เท่า โดยองค์กรระดับกลางมี MTTR วัดเป็นนาที ในขณะที่องค์กรประสิทธิภาพต่ำมี MTTR วัดเป็นวัน 9 ในรายงาน State of DevOps Report ปี 2019 ของ DORA องค์กรระดับชั้นยอดแก้ไขเหตุการณ์ใน production ได้เร็วกว่าองค์กรประสิทธิภาพต่ำถึง 2,604 เท่า โดยองค์กร ระดับชั้นยอดมี MTTR วัดเป็นนาที ในขณะที่องค์กรประสิทธิภาพต่ำมี MTTR วัดเป็นสัปดาห์ 10

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

สร้างโครงสร้างพื้นฐาน Telemetry แบบรวมศูนย์

การตรวจสอบและบันทึก log ในระดับปฏิบัติการไม่ใช่เรื่องใหม่—วิศวกรปฏิบัติการหลายรุ่นได้ใช้และ ปรับแต่ง monitoring frameworks (เช่น HP OpenView, IBM Tivoli, และ BMC Patrol/BladeLogic) เพื่อให้แน่ใจว่าระบบ production ทำงานได้อย่างถูกต้อง ข้อมูลมักถูกเก็บรวบรวมผ่าน agent ที่ทำงานบนเซิร์ฟเวอร์หรือผ่านการตรวจสอบแบบไม่มี agent (เช่น SNMP traps หรือ polling-based monitors) โดยปกติจะมีส่วนติดต่อผู้ใช้แบบกราฟิก (GUI) เป็น front-end และรายงาน back-end มักถูกเสริมด้วยเครื่องมือเช่น Crystal Reports

รูปที่ 14.1: เวลาในการแก้ไขเหตุการณ์สำหรับองค์กรระดับ Elite, High, Medium และ Low (2019)

ที่มา: Forsgren et al., Accelerate: State of DevOps (2019).

ในทำนองเดียวกัน แนวปฏิบัติในการพัฒนาแอปพลิเคชันด้วยการบันทึก log ที่มีประสิทธิภาพและการจัดการ telemetry ที่ได้มา ก็ไม่ใช่เรื่องใหม่—มี logging libraries ที่สมบูรณ์แบบมากมายสำหรับภาษาโปรแกรมเกือบทุกภาษา

อย่างไรก็ตาม เป็นเวลาหลายทศวรรษที่เราลงเอยด้วยข้อมูลที่แยกเป็นสัดส่วน (silos) โดยฝ่ายพัฒนาสร้าง logging events ที่น่าสนใจสำหรับนักพัฒนาเท่านั้น และฝ่ายปฏิบัติการตรวจสอบแต่เพียงว่าสภาพแวดล้อมทำงานหรือไม่ทำงานเท่านั้น ส่งผลให้ เมื่อเกิดเหตุการณ์ไม่คาดฝันขึ้น ไม่มีใครสามารถระบุได้ว่าทำไมทั้งระบบถึงทำงานไม่เป็นไปตามที่ออกแบบไว้ หรือส่วนประกอบใดที่กำลังล้มเหลว ซึ่งเป็นอุปสรรคต่อความสามารถในการทำให้ระบบกลับสู่สถานะที่ทำงานได้

เพื่อให้เรามองเห็นปัญหาทั้งหมดเมื่อมันเกิดขึ้น เราต้องออกแบบและพัฒนาแอปพลิเคชันและสภาพแวดล้อมของเรา ให้สร้าง telemetry ที่เพียงพอ ช่วยให้เราเข้าใจว่าระบบของเราทำงานโดยรวมอย่างไร เมื่อ ทุกระดับของ application stack มีการตรวจสอบและบันทึก log เราจะเปิดใช้งานความสามารถสำคัญอื่นๆ เช่น การสร้างกราฟและแสดง metrics, การตรวจจับความผิดปกติ, การแจ้งเตือนเชิงรุกและการส่งต่อ ฯลฯ

ใน The Art of Monitoring James Turnbull อธิบายสถาปัตยกรรมการตรวจสอบสมัยใหม่ ซึ่งได้รับการพัฒนาและใช้งานโดยวิศวกรปฏิบัติการ ในบริษัทระดับเว็บ (เช่น Google, Amazon, Facebook) สถาปัตยกรรมนี้มักประกอบด้วย open-source tools เช่น Nagios และ Zenoss ที่ถูกปรับแต่งและ deploy ในระดับที่ยากจะทำได้ด้วยซอฟต์แวร์เชิงพาณิชย์ที่มีลิขสิทธิ์ในเวลานั้น 11

สถาปัตยกรรมนี้มีส่วนประกอบดังต่อไปนี้:

• การเก็บรวบรวมข้อมูลในชั้น business logic, application และ environment: ในแต่ละชั้นเหล่านี้ เราสร้าง telemetry ในรูปแบบของ events, logs และ metrics Logs อาจถูกเก็บไว้ใน ไฟล์เฉพาะของแอปพลิเคชันบนแต่ละเซิร์ฟเวอร์ (เช่น /var/log/httpd-error.log) แต่โดย preferable เราต้องการให้ logs ทั้งหมดของเราถูกส่ง ไปยัง service ส่วนกลางที่ทำให้การรวมศูนย์ การหมุนเวียน และการลบทำได้ง่าย ซึ่งมีให้โดยระบบปฏิบัติการส่วนใหญ่ เช่น syslog สำหรับ Linux, Event Log สำหรับ Windows ฯลฯ

นอกจากนี้ เรายังรวบรวม metrics ในทุกชั้นของ application stack เพื่อทำความเข้าใจว่าระบบของเราทำงานอย่างไร ในระดับระบบปฏิบัติการ เราสามารถเก็บ metrics เช่น การใช้งาน CPU, หน่วยความจำ, ดิสก์ หรือเครือข่ายในช่วงเวลาต่างๆ โดยใช้ เครื่องมือเช่น collected, Ganglia ฯลฯ Cloud Native Computing Foundation ได้สร้างมาตรฐานเปิดสำหรับ metrics และ การติดตามข้อมูลที่เรียกว่า OpenTelemetry ซึ่งเป็นที่เข้าใจของ open-source และ commercial tools หลายตัว เครื่องมืออื่นๆ ที่เก็บข้อมูลประสิทธิภาพ ได้แก่ Apache Skywalking, AppDynamics และ New Relic

• Event router ที่รับผิดชอบในการจัดเก็บ events และ metrics ของเรา: ความสามารถนี้ช่วยให้เกิดการแสดงผล การติดตามแนวโน้ม การแจ้งเตือน การตรวจจับความผิดปกติ และอื่นๆ โดยการรวบรวม จัดเก็บ และรวม telemetry ทั้งหมดของเราเข้าด้วยกัน เราจะช่วยให้การวิเคราะห์และการตรวจสอบสุขภาพดีขึ้น นอกจากนี้ยังเป็นที่ที่เรา จัดเก็บการกำหนดค่าที่เกี่ยวข้องกับบริการของเรา (และแอปพลิเคชันและสภาพแวดล้อมที่สนับสนุน) และน่าจะเป็นที่ที่เรา ทำการแจ้งเตือนตามเกณฑ์ (threshold-based) และการตรวจสอบสุขภาพ ตัวอย่างของเครื่องมือในกลุ่มนี้ ได้แก่ Prometheus, Honeycomb, DataDog และ Sensu

เมื่อเรารวมศูนย์ logs ของเราแล้ว เราสามารถแปลงเป็น metrics ได้โดยการนับมันใน event router— ตัวอย่างเช่น log event เช่น "child pid 14024 exit signal Segmentation fault" สามารถนับและสรุปเป็น segfault metric เดียวทั่วทั้ง production infrastructure ของเรา

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

นอกจากการรวบรวม telemetry จากบริการและสภาพแวดล้อม production ของเราแล้ว เรายังต้องรวบรวม telemetry จาก deployment pipeline ของเราเมื่อเกิดเหตุการณ์สำคัญ เช่น เมื่อ automated tests ผ่านหรือล้มเหลว และเมื่อเรา ทำการ deploy ไปยังสภาพแวดล้อมใดๆ เราควรเก็บ telemetry เกี่ยวกับระยะเวลาที่ใช้ในการ build และ ทดสอบด้วย การทำแบบนี้ช่วยให้เราตรวจจับเงื่อนไขที่อาจบ่งชี้ถึงปัญหา เช่น ถ้า performance test หรือ build ใช้เวลานานเป็นสองเท่าของปกติ ทำให้เราสามารถค้นหาและแก้ไขข้อผิดพลาดก่อนที่จะเข้าสู่ production

นอกจากนี้ เราควรทำให้แน่ใจว่าการป้อนและดึงข้อมูลจากโครงสร้างพื้นฐาน telemetry ของเราทำได้ง่าย โดย preferable ทุกอย่างควรทำผ่าน self-service APIs แทนที่จะให้คนเปิด ticket และรอรับรายงาน

รูปที่ 14.2: กรอบการทำงานการตรวจสอบ (Monitoring Framework)

ที่มา: Turnbull, The Art of Monitoring , Kindle edition, chap. 2.

ในอุดมคติ เราจะสร้าง telemetry ที่บอกเราได้อย่างแม่นยำว่าเมื่อใดก็ตามที่มีสิ่งที่น่าสนใจเกิดขึ้น รวมถึงที่ไหนและอย่างไร telemetry ของเราควรเหมาะสมสำหรับการวิเคราะห์ทั้งแบบ manual และ automated และควรสามารถวิเคราะห์ได้ โดยไม่ต้องมีแอปพลิเคชันที่สร้าง logs อยู่ในมือ * ดังที่ Adrian Cockcroft กล่าวไว้ "การตรวจสอบมีความสำคัญมากจนระบบตรวจสอบของเราต้องมีความพร้อมใช้งานและ ปรับขนาดได้มากกว่าระบบที่ถูกตรวจสอบเสียอีก" 12

สร้าง Application Logging Telemetry ที่ช่วยงาน Production

เมื่อเรามีโครงสร้างพื้นฐาน telemetry แบบรวมศูนย์แล้ว เราต้องแน่ใจว่าแอปพลิเคชันที่เราสร้างและดำเนินการอยู่นั้น สร้าง telemetry อย่างเพียงพอ เราทำแบบนี้โดยให้วิศวกร Dev และ Ops สร้าง production telemetry เป็นส่วนหนึ่งของ งานประจำวันของพวกเขา ทั้งสำหรับบริการใหม่และบริการที่มีอยู่แล้ว

Scott Prugh, CTO ของ CSG กล่าวว่า

ทุกครั้งที่ NASA ปล่อยจรวด มันมีเซ็นเซอร์อัตโนมัติหลายล้านตัวรายงานสถานะของทุกส่วนประกอบ ของทรัพย์สินอันมีค่านี้ แต่กลับกัน เรามักไม่ดูแลซอฟต์แวร์ด้วยความระมัดระวังเดียวกัน—เราพบว่าการสร้าง application และ infrastructure telemetry เป็นหนึ่งในการลงทุนที่ให้ผลตอบแทนสูงสุดที่เราเคยทำ ในปี 2014 เราสร้าง เหตุการณ์ telemetry กว่าหนึ่งพันล้านเหตุการณ์ต่อวัน โดยมีตำแหน่งโค้ดที่ถูก instrument กว่าหนึ่งแสนตำแหน่ง 13

ในแอปพลิเคชันที่เราสร้างและดำเนินการ ทุกฟีเจอร์ควรถูก instrument ถ้ามันสำคัญพอที่วิศวกรจะ implement ก็สำคัญพอที่จะสร้าง production telemetry เพียงพอที่จะยืนยันว่ามันทำงานตามที่ออกแบบไว้และ ผลลัพธ์ที่ต้องการบรรลุผลสำเร็จ †

สมาชิกทุกคนใน value stream ของเราจะใช้ telemetry ในหลากหลายวิธี ตัวอย่างเช่น นักพัฒนาอาจ สร้าง telemetry เพิ่มเติมชั่วคราวในแอปพลิเคชันเพื่อวินิจฉัยปัญหาบน workstation ของตน ในขณะที่วิศวกร Ops อาจใช้ telemetry เพื่อวินิจฉัยปัญหาใน production นอกจากนี้ Infosec และผู้ตรวจสอบอาจตรวจสอบ telemetry เพื่อยืนยัน ประสิทธิภาพของ control ที่จำเป็น และ product manager อาจใช้มันเพื่อติดตามผลลัพธ์ทางธุรกิจ การใช้งานฟีเจอร์ หรือ conversion rates

เพื่อรองรับรูปแบบการใช้งานที่หลากหลายเหล่านี้ เรามีระดับการบันทึก (logging levels) ที่แตกต่างกัน ซึ่งบางระดับอาจ trigger การแจ้งเตือนด้วย ดังต่อไปนี้: 14

• ระดับ DEBUG: ข้อมูลในระดับนี้เกี่ยวกับทุกสิ่งที่เกิดขึ้นในโปรแกรม โดยส่วนใหญ่ใช้ระหว่างการ debug โดยทั่วไป debug logs จะถูกปิดใน production แต่จะเปิดใช้งานชั่วคราวระหว่างการแก้ไขปัญหา

• ระดับ INFO: ข้อมูลในระดับนี้ประกอบด้วยการกระทำที่ขับเคลื่อนโดยผู้ใช้หรือเฉพาะระบบ (เช่น "เริ่มต้นรายการธุรกรรมบัตรเครดิต")

• ระดับ WARN: ข้อมูลในระดับนี้บอกเราเกี่ยวกับเงื่อนไขที่อาจกลายเป็น error ได้ (เช่น การเรียกฐานข้อมูลที่ใช้เวลานานกว่าเวลาที่กำหนดไว้) สิ่งเหล่านี้มักจะ initiate การแจ้งเตือนและการแก้ไขปัญหา ในขณะที่ข้อความ logging อื่นๆ อาจช่วยให้เราเข้าใจสิ่งที่นำไปสู่เงื่อนไขนี้

• ระดับ ERROR: ข้อมูลในระดับนี้มุ่งเน้นไปที่เงื่อนไข error (เช่น API call failures, internal error conditions)

• ระดับ FATAL: ข้อมูลในระดับนี้บอกเราเมื่อต้องยุติการทำงาน (เช่น network daemon ไม่สามารถผูก network socket ได้)

การเลือกระดับการบันทึกที่เหมาะสมเป็นสิ่งสำคัญ Dan North อดีตที่ปรึกษาของ ThoughtWorks ที่มีส่วนร่วมใน หลายโปรเจกต์ซึ่งแนวคิดหลักของ continuous delivery ถูกสร้างขึ้น กล่าวว่า "เมื่อตัดสินใจว่าข้อความควรเป็น ERROR หรือ WARN ให้จินตนาการถึงการถูกปลุกตอนตี 4 AM หมึกพิมพ์ใกล้หมดไม่ใช่ ERROR" 15

เพื่อช่วยให้แน่ใจว่าเรามีข้อมูลที่เกี่ยวข้องกับการดำเนินงานที่เชื่อถือได้และปลอดภัยของบริการของเรา เราควร ทำให้แน่ใจว่าเหตุการณ์สำคัญของแอปพลิเคชันทั้งหมดสร้างรายการ logging รวมถึงรายการที่รวบรวมโดย Anton A. Chuvakin รองประธานฝ่ายวิจัยของ Gartner's GTP Security and Risk Management group: 16

• การตัดสินใจเกี่ยวกับ authentication/authorization (รวมถึงการออกจากระบบ)

• การเข้าถึงระบบและข้อมูล

• การเปลี่ยนแปลงระบบและแอปพลิเคชัน (โดยเฉพาะการเปลี่ยนแปลงที่มีสิทธิพิเศษ)

• การเปลี่ยนแปลงข้อมูล เช่น การเพิ่ม แก้ไข หรือลบข้อมูล

• input ที่ไม่ถูกต้อง (อาจเป็นการ injection ที่เป็นอันตราย ภัยคุกคาม ฯลฯ)

• ทรัพยากร (RAM, ดิสก์, CPU, แบนด์วิดท์ หรือทรัพยากรอื่นใดที่มีขีดจำกัดแบบ hard หรือ soft)

• สุขภาพและความพร้อมใช้งาน

• การเริ่มต้นและการปิดระบบ

• ข้อบกพร่องและข้อผิดพลาด

• การสะดุดของ circuit breaker

• ความล่าช้า

• ความสำเร็จ/ความล้มเหลวของการสำรองข้อมูล

เพื่อให้การตีความและให้ความหมายกับรายการ log ทั้งหมดเหล่านี้ทำได้ง่ายขึ้น โดย (ideally) เราควรสร้าง หมวดหมู่ลำดับชั้น (hierarchical categories) ของ logging เช่น สำหรับ attribute ที่ไม่ใช่ฟังก์ชัน (เช่น performance, security) และสำหรับ attribute ที่เกี่ยวข้องกับฟีเจอร์ (เช่น search, ranking)

ใช้ Telemetry เพื่อชี้แนะการแก้ปัญหา

ดังที่ได้กล่าวไว้ในตอนต้นของบทนี้ องค์กรที่มีประสิทธิภาพสูงใช้แนวทางที่มีวินัยในการแก้ปัญหา ซึ่งตรงกันข้ามกับการปฏิบัติทั่วไปที่ใช้ข่าวลือและการได้ยินมา ซึ่งอาจนำไปสู่ metric ที่น่าเสียดายที่เรียกว่า mean time until declared innocent —เราจะโน้มน้าวคนอื่นได้เร็วแค่ไหนว่าเราไม่ได้เป็นต้นเหตุของ outage

เมื่อมีวัฒนธรรมการโทษกันเกี่ยวกับ outage และปัญหา กลุ่มต่างๆ อาจหลีกเลี่ยงการบันทึกการเปลี่ยนแปลงและการแสดง telemetry ที่ทุกคนสามารถมองเห็นได้ เพื่อหลีกเลี่ยงการถูกตำหนิว่าเป็นต้นเหตุของ outage

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

ในทางกลับกัน telemetry ช่วยให้เราใช้วิธีการทางวิทยาศาสตร์ (scientific method) ในการตั้งสมมติฐานเกี่ยวกับ สาเหตุของปัญหาเฉพาะและสิ่งที่ต้องใช้ในการแก้ปัญหา ตัวอย่างคำถามที่เราสามารถตอบได้ในระหว่างการแก้ปัญหา ได้แก่:

• เรามีหลักฐานอะไรจากการตรวจสอบของเราว่าปัญหากำลังเกิดขึ้นจริง?

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

• เราสามารถตั้งสมมติฐานอะไรได้บ้างเพื่อยืนยันความเชื่อมโยงระหว่างสาเหตุและผลกระทบที่เสนอ?

• เราจะพิสูจน์ได้อย่างไรว่าสมมติฐานใดถูกต้อง และสามารถดำเนินการแก้ไขได้สำเร็จ?

คุณค่าของการแก้ปัญหาบนพื้นฐานข้อเท็จจริงไม่ได้อยู่ที่ MTTR ที่เร็วขึ้นอย่างมีนัยสำคัญ (และผลลัพธ์ของลูกค้าที่ดีขึ้น) เท่านั้น แต่ยังรวมถึงการเสริมสร้างการรับรู้ถึงความสัมพันธ์แบบ win/win ระหว่างฝ่ายพัฒนาและฝ่ายปฏิบัติการ

ทำให้การสร้าง Production Metrics เป็นส่วนหนึ่งของงานประจำวัน

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

ในการทำเช่นนี้ เราต้องสร้างโครงสร้างพื้นฐานและ libraries ที่จำเป็นเพื่อให้ทุกคนในฝ่ายพัฒนา หรือฝ่ายปฏิบัติการสามารถสร้าง telemetry สำหรับฟังก์ชันใดๆ ที่พวกเขาสร้างขึ้นได้ง่ายที่สุด ในอุดมคติ มันควรง่ายเทียบเท่าการเขียนโค้ดหนึ่งบรรทัดเพื่อสร้าง metric ใหม่ที่แสดงใน dashboard กลางที่ทุกคนใน value stream สามารถมองเห็นได้

นี่คือปรัชญาที่นำไปสู่การพัฒนา mộtใน metric libraries ที่ถูกใช้อย่างแพร่หลายที่สุดที่ชื่อว่า StatsD ซึ่งถูกสร้างและ open-source ที่ Etsy 18 ดังที่ John Allspaw กล่าวไว้ว่า "เราออกแบบ StatsD เพื่อป้องกันไม่ให้นักพัฒนาคนไหนพูดว่า 'มันยุ่งยากเกินไปที่จะ instrument โค้ดของฉัน' ตอนนี้พวกเขาสามารถทำได้ด้วยโค้ดหนึ่งบรรทัด สิ่งสำคัญสำหรับเราคือการที่นักพัฒนา การเพิ่ม production telemetry ไม่ควรรู้สึกยากเท่าการทำ database schema change" 19

StatsD สามารถสร้าง timers และ counters ด้วยโค้ดหนึ่งบรรทัด (ใน Ruby, Perl, Python, Java และภาษาอื่นๆ) และมักใช้ร่วมกับ Graphite หรือ Grafana ซึ่ง render metric events เป็นกราฟและ dashboards

รูปที่ 14.3 แสดงตัวอย่างว่าโค้ดหนึ่งบรรทัดสร้าง user login event ได้อย่างไร (ในที่นี้คือ PHP หนึ่งบรรทัด: "StatsD::increment("login.successes")) กราฟผลลัพธ์แสดงจำนวนการ login สำเร็จและล้มเหลวต่อ นาที และซ้อนทับบนกราฟมีเส้นแนวตั้งที่แสดงถึง production deployment

รูปที่ 14.3: โค้ดหนึ่งบรรทัดเพื่อสร้าง Telemetry โดยใช้ StatsD และ Graphite ที่ Etsy

ที่มา: Ian Malpass, "Measure Anything, Measure Everything."

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

ในช่วงไม่กี่ปีที่ผ่านมา การเกิดขึ้นของมาตรฐาน OpenTelemetry ได้ให้วิธีการสำหรับ data collectors ในการสื่อสารกับ ระบบจัดเก็บและประมวลผล metrics มีการผสานรวม OpenTelemetry กับภาษา frameworks และ libraries หลักทั้งหมด และเครื่องมือ metrics และ observability ยอดนิยมส่วนใหญ่รองรับข้อมูล OpenTelemetry §

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

สร้างการเข้าถึง Telemetry แบบ Self-Service และ Information Radiators

ในขั้นตอนก่อนหน้านี้ เราได้ทำให้ฝ่ายพัฒนาและฝ่ายปฏิบัติการสามารถสร้างและปรับปรุง production telemetry เป็นส่วนหนึ่งของงานประจำวัน ในขั้นตอนนี้ เป้าหมายของเราคือการกระจายข้อมูลนี้ไปยังส่วนอื่นๆ ขององค์กร ทำให้แน่ใจว่าทุกคนที่ต้องการข้อมูลเกี่ยวกับบริการใดๆ ที่เราดำเนินการสามารถรับได้โดยไม่ต้องมีการเข้าถึงระบบ production หรือบัญชีที่มีสิทธิพิเศษ หรือต้องเปิด ticket และรอเป็นวันเพื่อให้มีคนมากำหนดค่า graph ให้

โดยการทำให้ telemetry รวดเร็ว หาง่าย และรวมศูนย์อย่างเพียงพอ ทุกคนใน value stream สามารถมี มุมมองร่วมกันต่อความเป็นจริง โดยทั่วไปหมายความว่า production metrics จะถูกกระจายบนหน้าเว็บที่สร้างโดย เซิร์ฟเวอร์ส่วนกลาง เช่น Graphite หรือเทคโนโลยีอื่นๆ ที่อธิบายไว้ในส่วนก่อนหน้านี้

เราต้องการให้ production telemetry ของเรามองเห็นได้ชัดเจน ซึ่งหมายถึงการวางไว้ในพื้นที่ส่วนกลางที่ฝ่ายพัฒนาและ ฝ่ายปฏิบัติการทำงาน เพื่อให้ทุกคนที่สนใจสามารถเห็นว่าบริการของเราทำงานอย่างไร อย่างน้อยก็รวมถึงทุกคนใน value stream เช่น ฝ่ายพัฒนา ฝ่ายปฏิบัติการ การจัดการผลิตภัณฑ์ และ Infosec สิ่งนี้มักเรียกว่า information radiator ซึ่งถูกกำหนดโดย Agile Alliance ว่า

คำทั่วไปสำหรับการแสดงผลด้วยลายมือ วาด พิมพ์ หรืออิเล็กทรอนิกส์จำนวนหนึ่งที่ทีมวางใน ตำแหน่งที่มองเห็นได้ชัดเจน เพื่อให้สมาชิกทีมทุกคนรวมถึงผู้คนที่ผ่านไปมาสามารถเห็นข้อมูลล่าสุดได้ในพริบตา: จำนวน automated tests, velocity, incident reports, สถานะ continuous integration และอื่นๆ แนวคิดนี้มีต้นกำเนิด เป็นส่วนหนึ่งของ Toyota Production System 20

โดยการใส่ information radiators ในสถานที่ที่มองเห็นได้ชัดเจน เราส่งเสริมความรับผิดชอบในหมู่สมาชิกทีม แสดงให้เห็นถึงคุณค่าต่อไปนี้อย่างแข็งขัน:

• ทีมไม่มีอะไรต้องปิดบังจากผู้มาเยือน (ลูกค้า ผู้มีส่วนได้ส่วนเสีย ฯลฯ)

• ทีมไม่มีอะไรต้องปิดบังจากตัวเอง: ทีมยอมรับและเผชิญหน้ากับปัญหา

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

แม้ว่าอาจมีการต่อต้านบางประการในการให้ความโปร่งใสในระดับนี้ Ernest Mueller อธิบายคุณค่าของการทำเช่นนี้:

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

เราอาจขยายความโปร่งใสนี้ยิ่งขึ้นไปอีก—แทนที่จะพยายามปกปิดปัญหาที่กระทบต่อลูกค้าเป็นความลับ เราสามารถ ส่งข้อมูลนี้ไปยังลูกค้าภายนอกของเรา สิ่งนี้แสดงให้เห็นว่าเราให้คุณค่ากับความโปร่งใส ซึ่งช่วยสร้างและได้รับความไว้วางใจจากลูกค้า ¶ (ดู ภาคผนวก 10 .)

กรณีศึกษา

การสร้าง Metrics แบบ Self-Service ที่ LinkedIn (2011)

ดังที่ได้อธิบายไว้ใน ส่วนที่ III LinkedIn ถูกสร้างขึ้นในปี 2003 เพื่อช่วยให้ผู้ใช้เชื่อมต่อ "กับเครือข่ายของคุณเพื่อโอกาสทางอาชีพที่ดีขึ้น" ภายในพฤศจิกายน 2015 LinkedIn มีสมาชิกกว่า 350 ล้านคน สร้างคำขอนับหมื่นต่อวินาที ส่งผลให้ มีการ query นับล้านครั้งต่อวินาทีบนระบบ back-end ของ LinkedIn

Prachi Gupta ผู้อำนวยการฝ่ายวิศวกรรมของ LinkedIn เขียนในปี 2011 เกี่ยวกับความสำคัญของ production telemetry:

ที่ LinkedIn เราเน้นการทำให้แน่ใจว่าเว็บไซต์ทำงานและสมาชิกของเราสามารถเข้าถึงฟังก์ชันการทำงานทั้งหมดของเว็บไซต์ได้ตลอดเวลา การทำตามคำมั่นสัญญานี้ต้องการให้เราตรวจจับและตอบสนองต่อความล้มเหลวและ bottlenecks ทันทีที่มันเริ่มเกิดขึ้น นั่นคือเหตุผลที่เราใช้ time-series graphs สำหรับการตรวจสอบเว็บไซต์เพื่อตรวจจับและตอบสนองต่อเหตุการณ์ภายใน ไม่กี่นาที . . . เทคนิคการตรวจสอบนี้พิสูจน์แล้วว่าเป็นเครื่องมือที่ยอดเยี่ยมสำหรับวิศวกร มันช่วยให้เราเคลื่อนที่ได้เร็วและซื้อ เวลาให้เราตรวจสอบ จัดลำดับความสำคัญ และแก้ไขปัญหา 22

อย่างไรก็ตาม ในปี 2010 แม้ว่าจะมีปริมาณ telemetry จำนวนมากอย่างไม่น่าเชื่อ แต่ก็ยาก อย่างยิ่งสำหรับวิศวกรที่จะเข้าถึงข้อมูล ไม่ต้องพูดถึงการวิเคราะห์เลย ดังนั้นจึงเริ่มต้นโปรเจกต์ฝึกงานภาคฤดูร้อนของ Eric Wong ที่ LinkedIn ซึ่งกลายเป็นโครงการริเริ่ม production telemetry ที่สร้าง InGraphs

Wong เขียนว่า "เพื่อให้ได้อะไรง่ายๆ เช่น การใช้งาน CPU ของ hosts ทั้งหมดที่รันบริการหนึ่งๆ คุณต้อง ยื่น ticket และมีคนใช้เวลา 30 นาทีในการรวบรวม [รายงาน]" 23

ในเวลานั้น LinkedIn ใช้ Zenoss ในการเก็บ metrics แต่ Wong อธิบายว่า "การดึงข้อมูลจาก Zenoss ต้อง ค้นหาผ่าน web interface ที่ช้า ดังนั้นฉันจึงเขียน python scripts เพื่อช่วยปรับปรุงกระบวนการ แม้ว่าจะยังมี การแทรกแซงด้วยตนเองในการตั้งค่าการเก็บ metrics อยู่ แต่ฉันสามารถลดเวลาที่ใช้ในการนำทางอินเทอร์เฟซของ Zenoss ได้" 24

ตลอดช่วงฤดูร้อน เขายังคงเพิ่มฟังก์ชันการทำงานให้ InGraphs เพื่อให้วิศวกรสามารถเห็นสิ่งที่พวกเขาต้องการเห็นได้อย่างแม่นยำ เพิ่มความสามารถในการคำนวณข้ามชุดข้อมูลหลายชุด ดูแนวโน้ม week-over-week เพื่อเปรียบเทียบประสิทธิภาพในอดีต และแม้กระทั่งกำหนด dashboards ที่กำหนดเองเพื่อเลือก metrics ที่จะแสดงบนหน้าเดียว

ในการเขียนเกี่ยวกับผลลัพธ์ของการเพิ่มฟังก์ชันการทำงานให้ InGraphs และคุณค่าของความสามารถนี้ Gupta กล่าวว่า "ประสิทธิผลของระบบตรวจสอบของเราได้รับการเน้นย้ำในทันทีที่ฟังก์ชันการตรวจสอบ InGraphs ของเราที่เชื่อมโยงกับ ผู้ให้บริการ web-mail รายใหญ่เริ่มมีแนวโน้มลดลง และผู้ให้บริการตระหนักว่าพวกเขามีปัญหาในระบบหลังจากที่เราติดต่อไปหาพวกเขาเท่านั้น!" 25

สิ่งที่เริ่มต้นจากโปรเจกต์ฝึกงานภาคฤดูร้อนตอนนี้กลายเป็นหนึ่งในส่วนที่มองเห็นได้ชัดเจนที่สุดของการดำเนินงานของ LinkedIn InGraphs ประสบความสำเร็จอย่างมากจนกราฟแบบ real-time ถูกแสดงอย่างเด่นชัดในสำนักงานวิศวกรรมของบริษัท ซึ่งผู้เยี่ยมชมไม่อาจพลาดที่จะเห็น

Metrics แบบ self-service สามารถเสริมศักยภาพในการแก้ปัญหาและการตัดสินใจในระดับบุคคลและทีม และให้ความโปร่งใสที่จำเป็นในการสร้างและได้รับความไว้วางใจจากลูกค้า

ค้นหาและเติมเต็มช่องว่าง Telemetry

ตอนนี้เราได้สร้างโครงสร้างพื้นฐานที่จำเป็นในการสร้าง production telemetry ได้อย่างรวดเร็วทั่วทั้ง application stack และกระจายไปทั่วทั้งองค์กรของเรา

ในส่วนนี้ เราจะระบุช่องว่างใดๆ ใน telemetry ของเราที่เป็นอุปสรรคต่อความสามารถในการตรวจจับและแก้ไข เหตุการณ์อย่างรวดเร็ว—นี่มีความเกี่ยวข้องเป็นพิเศษถ้าฝ่าย Dev และ Ops ในปัจจุบันมี telemetry น้อย (หรือไม่มีเลย) เราจะใช้ข้อมูลนี้ ในภายหลังเพื่อคาดการณ์ปัญหาได้ดีขึ้น รวมถึงช่วยให้ทุกคนรวบรวมข้อมูลที่ต้องการเพื่อตัดสินใจได้ดีขึ้น เพื่อบรรลุเป้าหมายขององค์กร

การบรรลุเป้าหมายนี้ต้องการให้เราสร้าง telemetry อย่างเพียงพอในทุกระดับของ application stack สำหรับสภาพแวดล้อมทั้งหมดของเรา รวมถึงสำหรับ deployment pipelines ที่สนับสนุนมัน เราต้องการ metrics จากระดับต่อไปนี้:

• ระดับธุรกิจ (Business level): ตัวอย่าง ได้แก่ จำนวนธุรกรรมการขาย รายได้จากธุรกรรมการขาย การลงทะเบียนผู้ใช้ อัตราการสูญเสียลูกค้า (churn rate) ผลการทดสอบ A/B ฯลฯ

• ระดับแอปพลิเคชัน (Application level): ตัวอย่าง ได้แก่ เวลาของธุรกรรม เวลาตอบสนองของผู้ใช้ ข้อบกพร่องของแอปพลิเคชัน ฯลฯ

• ระดับโครงสร้างพื้นฐาน (Infrastructure level) (เช่น ฐานข้อมูล ระบบปฏิบัติการ เครือข่าย พื้นที่จัดเก็บ): ตัวอย่าง ได้แก่ ปริมาณการเข้าชมเว็บเซิร์ฟเวอร์ การใช้งาน CPU การใช้งานดิสก์ ฯลฯ

• ระดับซอฟต์แวร์ไคลเอนต์ (Client software level) (เช่น JavaScript บนเบราว์เซอร์ของลูกค้า, แอปพลิเคชันมือถือ): ตัวอย่าง ได้แก่ ข้อผิดพลาดและการ crash ของแอปพลิเคชัน เวลาของธุรกรรมที่ผู้ใช้วัด ฯลฯ

• ระดับ Deployment pipeline: ตัวอย่าง ได้แก่ สถานะของ build pipeline (เช่น สีแดงหรือสีเขียวสำหรับชุดการทดสอบอัตโนมัติต่างๆ), lead time การเปลี่ยนแปลง deployment, ความถี่ในการ deploy, การเลื่อนระดับสภาพแวดล้อมการทดสอบ และสถานะของสภาพแวดล้อม

โดยการมี telemetry ครอบคลุมในทุกพื้นที่เหล่านี้ เราจะสามารถมองเห็นสุขภาพของทุกสิ่งที่บริการของเราพึ่งพา โดยใช้ข้อมูลและข้อเท็จจริงแทนข่าวลือ การชี้นิ้ว การโทษกัน และอื่นๆ

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

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

Application Metrics และ Business Metrics

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

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

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

โดยทั่วไป business metrics จะเป็นส่วนหนึ่งของ customer acquisition funnel ซึ่งเป็นขั้นตอนทางทฤษฎีที่ผู้มีโอกาสเป็นลูกค้าจะดำเนินการเพื่อซื้อสินค้า ตัวอย่างเช่น ในเว็บไซต์ e-commerce เหตุการณ์การเดินทางที่วัดได้ ได้แก่ เวลาทั้งหมดบนเว็บไซต์ การคลิกลิงก์ผลิตภัณฑ์ การเพิ่มในตะกร้าสินค้า และคำสั่งซื้อที่สำเร็จ

Ed Blankenship ผู้จัดการผลิตภัณฑ์อาวุโสของ Microsoft Visual Studio Team Services อธิบายว่า "บ่อยครั้ง ทีมฟีเจอร์จะกำหนดเป้าหมายของตนใน acquisition funnel โดยมีเป้าหมายให้ฟีเจอร์ของตนถูกใช้ใน งานประจำวันของลูกค้าทุกคน บางครั้งพวกเขาถูกอธิบายอย่างไม่เป็นทางการว่า 'tire kickers,' 'active users,' 'engaged users,' และ 'deeply engaged users' โดยมี telemetry สนับสนุนแต่ละขั้นตอน" 26

เป้าหมายของเราคือให้ทุก business metric นำไปปฏิบัติได้ (actionable) —metrics ระดับบนสุดเหล่านี้ควรช่วยบอกว่าควรเปลี่ยนผลิตภัณฑ์ของเราอย่างไร และควรเอื้อต่อการทดลองและการทดสอบ A/B เมื่อ metrics ไม่สามารถนำไปปฏิบัติได้ metrics เหล่านั้นมักเป็น vanity metrics ที่ให้ข้อมูลที่เป็นประโยชน์เพียงเล็กน้อย—เราต้องการ จัดเก็บมัน แต่ไม่ควรแสดง ไม่ต้องพูดถึงการแจ้งเตือน

ในอุดมคติ ทุกคนที่ดู information radiators ของเราจะสามารถเข้าใจข้อมูลที่เราแสดงในบริบทของ ผลลัพธ์ขององค์กรที่ต้องการ เช่น เป้าหมายเกี่ยวกับรายได้ การได้มาซึ่งผู้ใช้ conversion rates ฯลฯ เราควร กำหนดและเชื่อมโยงแต่ละ metric กับ business outcome metric ในขั้นตอนแรกสุดของการกำหนดและพัฒนา ฟีเจอร์ และวัดผลลัพธ์หลังจากที่ deploy ใน production นอกจากนี้ การทำเช่นนี้ช่วยให้ product owners อธิบายบริบททางธุรกิจของแต่ละฟีเจอร์สำหรับทุกคนใน value stream

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

โดยการกระจายข้อมูลว่าลูกค้ามีปฏิสัมพันธ์กับสิ่งที่เราสร้างอย่างไรในบริบทของเป้าหมายของเรา (ดู รูปที่ 14.4 ) เราช่วยให้ทีมฟีเจอร์ได้รับ feedback อย่างรวดเร็วเพื่อให้พวกเขาสามารถเห็นว่าความสามารถที่เราสร้างนั้น ถูกใช้งานจริงหรือไม่ และบรรลุเป้าหมายทางธุรกิจในระดับใด ด้วยเหตุนี้ เราจึงเสริมสร้างความคาดหวังทางวัฒนธรรม ที่ว่าการ instrument และวิเคราะห์การใช้งานของลูกค้าเป็นส่วนหนึ่งของงานประจำวันของเรา เพื่อให้เราเข้าใจดีขึ้นว่างานของเรา มีส่วนช่วยต่อเป้าหมายขององค์กรของเราอย่างไร

รูปที่ 14.4: ความตื่นเต้นของผู้ใช้ต่อฟีเจอร์ใหม่ในโพสต์ฟอรัมผู้ใช้หลังการ Deploy

ที่มา: Mike Brittain, "Tracking Every Release," CodeasCraft.com , 8 ธันวาคม 2010, https://codeascraft.com/2010/12/08/track-every-release/ .

Infrastructure Metrics

เช่นเดียวกับ application metrics เป้าหมายของเราสำหรับโครงสร้างพื้นฐานทั้งใน production และ non-production คือการทำให้แน่ใจว่าเรา สร้าง telemetry อย่างเพียงพอเพื่อว่าถ้าเกิดปัญหาในสภาพแวดล้อมใด เราจะสามารถระบุได้อย่างรวดเร็วว่า โครงสร้างพื้นฐานเป็นสาเหตุที่ contribut ให้กับปัญหาหรือไม่ นอกจากนี้ เราต้องสามารถระบุได้อย่างแม่นยำว่าอะไรใน โครงสร้างพื้นฐานที่ contribut ให้กับปัญหา (เช่น ฐานข้อมูล ระบบปฏิบัติการ พื้นที่จัดเก็บ เครือข่าย ฯลฯ)

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

ในหลายทศวรรษที่ผ่านมา การสร้างลิงก์ระหว่างบริการและโครงสร้างพื้นฐาน production ที่มันพึ่งพามักเป็นความพยายาม ที่ทำด้วยตนเอง (เช่น ITIL CMDBs หรือการสร้างคำจำกัดความการกำหนดค่าภายในเครื่องมือแจ้งเตือนใน tools เช่น Nagios) อย่างไรก็ตาม ปัจจุบันลิงก์เหล่านี้ถูกลงทะเบียนโดยอัตโนมัติภายในบริการของเรา ซึ่งถูกค้นพบแบบไดนามิกและ ใช้ใน production ผ่าน tools เช่น ZooKeeper, Etcd, Consul, Istio ฯลฯ 27

เครื่องมือเหล่านี้ช่วยให้บริการลงทะเบียนตนเอง โดยเก็บข้อมูลที่บริการอื่นๆ จำเป็นต้องใช้ในการโต้ตอบกับมัน (เช่น ที่อยู่ IP, หมายเลขพอร์ต, URIs) ซึ่งแก้ปัญหาในลักษณะ manual ของ ITIL CMDB และจำเป็นอย่างยิ่ง เมื่อบริการประกอบด้วย nodes หลายร้อย (หรือหลายพัน หรือแม้กระทั่งหลายล้าน) node แต่ละ node มีที่อยู่ IP ที่ถูกกำหนดแบบไดนามิก ††

ไม่ว่าระบบบริการของเราจะเรียบง่ายหรือซับซ้อนแค่ไหน การสร้างกราฟ business metrics ของเราควบคู่ไปกับ application และ infrastructure metrics ของเราช่วยให้เราตรวจจับเมื่อมีสิ่งผิดปกติเกิดขึ้น ตัวอย่างเช่น เราอาจเห็นว่าการลงทะเบียน ผู้ใช้ใหม่ลดลงเหลือ 20% ของค่าปกติประจำวัน และจากนั้นก็เห็นทันทีว่าการ query ฐานข้อมูลทั้งหมดของเราใช้เวลานานกว่าปกติถึงห้าเท่า ทำให้เราสามารถมุ่งเน้นการแก้ปัญหา

นอกจากนี้ business metrics สร้างบริบทสำหรับ infrastructure metrics ของเรา ทำให้ฝ่ายพัฒนาและฝ่ายปฏิบัติการ สามารถทำงานร่วมกันไปสู่เป้าหมายร่วมกันได้ดีขึ้น ดังที่ Jody Mulkey, CTO ของ Ticketmaster/LiveNation กล่าวว่า "แทนที่จะ วัดฝ่ายปฏิบัติการจากจำนวน downtime ฉันพบว่าการวัดทั้ง Dev และ Ops จากผลกระทบทางธุรกิจที่แท้จริงของ downtime นั้นดีกว่ามาก: เราควรมีรายได้เท่าไร แต่กลับไม่ได้" 29 ‡‡

การเรียนรู้อย่างต่อเนื่อง

รายงาน State of DevOps Report ปี 2019 ของ DORA พบว่าการตรวจสอบโครงสร้างพื้นฐาน contribut ต่อ continuous delivery เนื่องจาก การมองเห็นและ feedback ที่รวดเร็วที่มันมอบให้แก่ผู้มีส่วนได้ส่วนเสียทั้งหมดเป็นกุญแจสำคัญในการช่วยให้ทุกคนเห็นผลลัพธ์ของ build, test และ deployment 30

โปรดทราบว่านอกเหนือจากการตรวจสอบบริการ production ของเราแล้ว เรายังต้องการ telemetry สำหรับบริการเหล่านั้นใน สภาพแวดล้อม pre-production ของเรา (เช่น development, test, staging ฯลฯ) การทำเช่นนี้ช่วยให้เราค้นหาและแก้ไขปัญหา ก่อนที่มันจะเข้าสู่ production เช่น การตรวจจับเมื่อเรามีเวลาในการ insert ฐานข้อมูลที่เพิ่มขึ้นเรื่อยๆ เนื่องจากการขาด index ของตาราง

การซ้อนทับข้อมูลอื่นๆ ที่เกี่ยวข้องลงบน Metrics ของเรา

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

เพื่อทำให้การเปลี่ยนแปลงมองเห็นได้ เราทำให้งานมองเห็นได้โดยการซ้อนทับกิจกรรมการ deploy production ทั้งหมดบนกราฟของเรา ตัวอย่างเช่น สำหรับบริการที่จัดการธุรกรรมขาเข้าจำนวนมาก การเปลี่ยนแปลงใน production อาจส่งผลให้เกิด ช่วงเวลาปรับตัว (settling period) ที่สำคัญ ซึ่งประสิทธิภาพลดลงอย่างมากเมื่อ cache lookups ทั้งหมดพลาด

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

บทสรุป

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

*	จากจุดนี้เป็นต้นไป คำว่า telemetry จะถูกใช้สลับกับ metrics ซึ่งรวมถึง event logging และ metrics ทั้งหมดที่สร้างโดยบริการของเราทุกระดับของ application stack และที่สร้างจากสภาพแวดล้อม production และ pre-production ทั้งหมด รวมถึงจาก deployment pipeline ของเรา
†	มี application logging libraries หลากหลายที่ทำให้นักพัฒนาสามารถสร้าง telemetry ที่มีประโยชน์ได้ง่าย และเราควรเลือกอันที่ช่วยให้เราส่ง application logs ทั้งหมดไปยังโครงสร้างพื้นฐาน logging แบบรวมศูนย์ ที่เราสร้างในส่วนก่อนหน้านี้ ตัวอย่างยอดนิยม ได้แก่ rrd4j และ log4j สำหรับ Java และ log4r และ ruby-cabin สำหรับ Ruby
‡	ในปี 2004 Gene Kim, Kevin Behr และ George Spafford อธิบายว่านี่เป็นอาการของการขาด "วัฒนธรรมแห่งเหตุและผล" โดยสังเกตว่าองค์กรที่ประสิทธิภาพสูงตระหนักว่า 80% ของ outage ทั้งหมดเกิดจากการเปลี่ยนแปลง และ 80% ของ MTTR ถูกใช้ไปกับการพยายามหาว่ามีอะไรเปลี่ยนแปลงไป 17
§	เครื่องมืออีกชุดหนึ่งที่ช่วยในการตรวจสอบ การรวมรวม และการเก็บรวบรวม ได้แก่ Splunk, Zabbix, Sumo Logic, DataDog รวมถึง Nagios, Cacti, Sensu, RRDTool, Netflix Atlas, Riemann และอื่นๆ นักวิเคราะห์ มักเรียกเครื่องมือในหมวดกว้างๆ นี้ว่า "application performance monitors"
¶	การสร้าง dashboard อย่างง่ายควรเป็นส่วนหนึ่งของการสร้างผลิตภัณฑ์หรือบริการใหม่ใดๆ—automated tests ควร ยืนยันว่าทั้งบริการและ dashboard ทำงานอย่างถูกต้อง ซึ่งช่วยทั้งลูกค้าของเราและความสามารถในการ deploy โค้ดอย่างปลอดภัย
**	เหมือนกับที่ ITIL configuration management database (CMDB) กำหนดไว้
††	Consul อาจเป็นที่สนใจเป็นพิเศษ เนื่องจากมันสร้าง abstraction layer ที่ช่วยให้ service mapping, การตรวจสอบ, locks และ key-value configuration stores รวมถึง host clustering และการตรวจจับความล้มเหลว 28
‡‡	นี่อาจเป็นต้นทุนของ production downtime หรือต้นทุนที่เกี่ยวข้องกับฟีเจอร์ที่ล่าช้า ในศัพท์การพัฒนาผลิตภัณฑ์ metric ที่สองเรียกว่า cost of delay และเป็นกุญแจสำคัญในการตัดสินใจจัดลำดับความสำคัญอย่างมีประสิทธิภาพ