Summary (สรุป)

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

เมื่อสถาปัตยกรรม microservice ของคุณซับซ้อนมากขึ้น มันจะยิ่งยากขึ้นที่จะรู้ล่วงหน้าว่าปัญหาอะไรอาจเกิดขึ้น แทนที่จะเป็นแบบนั้น คุณจะพบว่าตัวเองประหลาดใจบ่อยครั้งกับประเภทของปัญหาที่คุณจะเจอ ดังนั้นมันจึงจำเป็นที่จะต้องเปลี่ยนความคิดของคุณ ออกจากกิจกรรม (passive) ส่วนใหญ่ของ monitoring ไปสู่การทำให้ระบบของคุณ observable อย่างกระตือรือร้น สิ่งนี้เกี่ยวข้องไม่เพียงแค่การเปลี่ยน toolset ที่อาจเกิดขึ้นเท่านั้น แต่ยังเกี่ยวกับการเปลี่ยนจาก static dashboard ไปสู่กิจกรรม slicing และ dicing ที่ dynamic มากขึ้นด้วย

กับระบบง่าย ๆ พื้นฐานจะพาคุณไปได้ไกล ทำ log aggregation ตั้งแต่เริ่มต้น และใส่ correlation ID ใน log line ของคุณด้วย Distributed tracing สามารถตามมาทีหลังได้ แต่จงคอยระวังว่าเมื่อไหร่ที่ถึงเวลาที่จะนำมันมาใช้

เปลี่ยนความเข้าใจของคุณต่อ system หรือ microservice health ให้ออกจาก binary state ของ "happy" หรือ "sad" ตระหนักแทนว่าความจริงมักจะละเอียดอ่อนกว่านั้นเสมอ เปลี่ยนจากการให้ปัญหาเล็ก ๆ ทุกอันสร้าง alert ไปสู่การคิดแบบองค์รวมมากขึ้นว่าอะไรที่ยอมรับได้ พิจารณาอย่างจริงจังที่จะรับเอา SLO มาใช้ และ alert ตามหลักการเหล่านี้ เพื่อลด alert fatigue และโฟกัสความสนใจได้อย่างถูกต้อง

เหนือสิ่งอื่นใด นี่คือเรื่องของการยอมรับว่าไม่ใช่ทุกอย่างที่จะรู้ได้ก่อนที่คุณจะไปถึง production เก่งขึ้นในการจัดการกับสิ่งที่ไม่รู้

เราได้ครอบคลุมไปมากแล้ว แต่ยังมีอะไรให้เจาะลึกอีกมากในเรื่องนี้ ถ้าคุณอยากสำรวจ concept ของ observability อย่างละเอียดมากขึ้น ผมแนะนำ Observability Engineering โดย Charity Majors, Liz Fong-Jones และ George Miranda 15 ผมยังแนะนำทั้ง Site Reliability Engineering 16 และ The Site Reliability Workbook 17 ในฐานะจุดเริ่มต้นที่ดีสำหรับการพูดคุยที่กว้างขึ้นรอบ ๆ SLO, SLI และอื่น ๆ มันคุ้มค่าที่จะสังเกตว่าหนังสือสองเล่มหลังนี้เขียนขึ้นจากมุมมองว่าสิ่งต่าง ๆ ถูกทำ (หรือเคยถูกทำ) อย่างไรที่ Google ซึ่งหมายความว่า concept เหล่านี้จะไม่สามารถแปลงมาใช้ได้เสมอไป คุณคงไม่ใช่ Google และคงไม่มีปัญหาขนาด Google ถึงอย่างนั้น ก็ยังมีอะไรมากมายที่แนะนำได้ในหนังสือเหล่านี้

ในบทถัดไป เราจะมองในมุมที่ต่างออกไป แม้จะยังเป็นแบบองค์รวมของระบบของเรา และพิจารณาข้อได้เปรียบ—และความท้าทาย—ที่เป็นเอกลักษณ์ที่สถาปัตยกรรม fine-grained สามารถมอบให้ได้ในพื้นที่ของ security

1 Honestly Black Lives Matter (@honest_update), October 7, 2015, 7:10 p.m., https://oreil.ly/Z28BA .

2 ไฟไหม้ในฐานะสาเหตุของ system outage ไม่ใช่เรื่องที่เพ้อฝันไปเสียทีเดียว ผมเคยช่วยจัดการหลังเกิด production outage ที่เกิดจาก storage area network (SAN) ไฟไหม้ ส่วนที่ต้องใช้เวลาหลายวันกว่าเราจะได้รับแจ้งว่าเกิดไฟไหม้ขึ้น ก็เป็นอีกเรื่องหนึ่งที่จะเล่าในโอกาสหน้า

3 ผมไม่ได้บอกว่าผมประสบความสำเร็จนะ

4 Leslie Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Communications of the ACM 21, no. 7 (July 1978): 558–65, https://oreil.ly/qzYmh .

5 ดูการวิเคราะห์ที่ Kyle Kingsbury ทำไว้เกี่ยวกับ Elasticsearch 1.1.0 ใน “Jepsen: Elasticsearch,” https://oreil.ly/uO9wU และเกี่ยวกับ Elasticsearch 1.5.0 ใน “Jepsen: Elasticsearch 1.5.0,” https://oreil.ly/8fBCt .

6 Renato Losio, “Elastic Changes Licences for Elasticsearch and Kibana: AWS Forks Both,” InfoQ, January 25, 2021, https://oreil.ly/VdWzD .

7 Charity Majors, “Metrics: Not the Observability Droids You’re Looking For,” Honeycomb (blog), October 24, 2017, https://oreil.ly/TEETp .

8 เกือบทั้งหมดนั่นแหละ ตอนนี้ AWS มี bare metal instance ให้ใช้แล้ว ซึ่งทำให้สมองผมงงอยู่บ้างเหมือนกัน

9 United States President’s Commission on the Accident at Three Mile Island, The Need for Change, the Legacy of TMI: Report of the President’s Commission on the Accident at Three Mile Island (Washington, DC: The Commission, 1979).

10 National Transportation Safety Board, Safety Recommendation Report: Assumptions Used in the Safety Assessment Process and the Effects of Multiple Alerts and Indications on Pilot Performance (Washington, DC: NTSB, 2019).

11 Steven Shorrock, “Alarm Design: From Nuclear Power to WebOps,” Humanistic Systems (blog), October 16, 2015, https://oreil.ly/RCHDL .

12 Charity Majors (@mipsytipsy), Twitter, July 7, 2019, 9:48 a.m., https://oreil.ly/4VUAX .

13 “Observability: A Complete Overview for 2021,” Lightstep, accessed June 16, 2021, https://oreil.ly/a1ERu .

14 Ben Sigelman, “Three Pillars with Zero Answers—Towards a New Scorecard for Observability,” Lightstep (blog post), December 5, 2018, https://oreil.ly/R3LwC .

15 Charity Majors, Liz Fong-Jones, and George Miranda, Observability Engineering (Sebastopol: O’Reilly, 2022). ในขณะที่เขียนหนังสือเล่มนี้ หนังสือเล่มนี้ยังอยู่ในช่วง early release

16 Betsy Beyer et al., eds., Site Reliability Engineering: How Google Runs Production Systems (Sebastopol: O’Reilly, 2016).

17 Betsy Beyer et al., eds., The Site Reliability Workbook (Sebastopol: O’Reilly, 2018).