SRE (Site Reliability Engineering) เป็นแนวทางในการตรวจสอบความพร้อมใช้งานของโครงการเว็บ ถือเป็นกรอบการทำงานสำหรับ DevOps และพูดถึงวิธีที่จะประสบความสำเร็จในการนำแนวปฏิบัติ DevOps ไปประยุกต์ใช้ คำแปลในบทความนี้ บทที่ 4 วัตถุประสงค์ระดับการให้บริการ книги วิศวกรรมความน่าเชื่อถือของไซต์ จาก Google ฉันเตรียมการแปลนี้ด้วยตัวเองและอาศัยประสบการณ์ของตัวเองในการทำความเข้าใจกระบวนการติดตาม ในช่องโทรเลข มอนิเตอร์im_it и โพสต์ล่าสุด เกี่ยวกับ Habré ฉันยังได้ตีพิมพ์บทแปลบทที่ 6 ของหนังสือเล่มเดียวกันเกี่ยวกับเป้าหมายระดับการให้บริการด้วย

แปลโดยแมว. สนุกกับการอ่าน!

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

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

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

คำศัพท์ระดับบริการ

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

ตัวชี้วัด

SLI เป็นตัวบ่งชี้ระดับการบริการ ซึ่งเป็นการวัดเชิงปริมาณที่กำหนดไว้อย่างรอบคอบในด้านหนึ่งของระดับการให้บริการที่มีให้

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

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

SLI อีกประเภทหนึ่งที่มีความสำคัญต่อ SRE ก็คือความพร้อมใช้งาน หรือส่วนของเวลาที่สามารถใช้บริการได้ มักถูกกำหนดให้เป็นอัตราของคำขอที่สำเร็จ บางครั้งเรียกว่าอัตราผลตอบแทน (อายุการใช้งาน—ความน่าจะเป็นที่ข้อมูลจะถูกเก็บรักษาไว้เป็นระยะเวลานาน—ก็มีความสำคัญต่อระบบจัดเก็บข้อมูลเช่นกัน) แม้ว่าความพร้อมใช้งาน 100% จะไม่สามารถทำได้ แต่ความพร้อมใช้งานเกือบ 100% มักจะทำได้ ค่าความพร้อมใช้งานจะแสดงเป็น จำนวน "เก้า" » เปอร์เซ็นต์ของความพร้อมใช้งาน เช่น ความพร้อมใช้งาน 99% และ 99,999% อาจมีป้ายกำกับว่า "2 Nines" และ "5 Nines" เป้าหมายความพร้อมใช้งานที่ระบุในปัจจุบันของ Google Compute Engine คือ "สามเก้าครึ่ง" หรือ 99,95%

วัตถุประสงค์

SLO เป็นวัตถุประสงค์ระดับการบริการ: ค่าเป้าหมายหรือช่วงของค่าสำหรับระดับการบริการที่วัดโดย SLI ค่าปกติสำหรับ SLO คือ “SLI ≤ เป้าหมาย” หรือ “ขีดจำกัดล่าง ≤ SLI ≤ ขีดจำกัดบน” ตัวอย่างเช่น เราอาจตัดสินใจว่าเราจะส่งคืนผลการค้นหาของเช็คสเปียร์ "เร็ว" โดยตั้งค่า SLO เป็นเวลาแฝงของคำค้นหาโดยเฉลี่ยที่น้อยกว่า 100 มิลลิวินาที

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

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

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

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

ข้อตกลง

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

โดยทั่วไป SRE จะไม่เกี่ยวข้องกับการสร้าง SLA เนื่องจาก SLA เชื่อมโยงอย่างใกล้ชิดกับการตัดสินใจทางธุรกิจและผลิตภัณฑ์ อย่างไรก็ตาม SRE มีส่วนร่วมในการช่วยบรรเทาผลที่ตามมาของ SLO ที่ล้มเหลว นอกจากนี้ยังสามารถช่วยกำหนด SLI ได้: แน่นอนว่าจะต้องมีวิธีที่เป็นกลางในการวัด SLO ในข้อตกลง ไม่เช่นนั้นอาจมีความขัดแย้งเกิดขึ้น

Google Search เป็นตัวอย่างของบริการสำคัญที่ไม่มี SLA สาธารณะ เราต้องการให้ทุกคนใช้ Search อย่างมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้ แต่เรายังไม่ได้เซ็นสัญญากับทั่วโลก อย่างไรก็ตาม ยังคงมีผลกระทบที่ตามมาหากการค้นหาไม่พร้อมใช้งาน - การไม่พร้อมใช้งานส่งผลให้ชื่อเสียงของเราลดลงรวมถึงรายได้จากการโฆษณาที่ลดลง บริการอื่นๆ ของ Google เช่น Google for Work มีข้อตกลงระดับการให้บริการที่ชัดเจนกับผู้ใช้ ไม่ว่าบริการนั้นๆ จะมี SLA หรือไม่ก็ตาม สิ่งสำคัญคือต้องกำหนด SLI และ SLO และใช้เพื่อจัดการบริการ

ทฤษฎีมากมาย - ตอนนี้ได้สัมผัสแล้ว

ตัวชี้วัดในทางปฏิบัติ

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

คุณและผู้ใช้ของคุณสนใจอะไร?

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

โดยทั่วไปบริการสามารถแบ่งออกเป็นหลายส่วนในแง่ของ SLI ที่เกี่ยวข้องกับบริการเหล่านั้น:

• ระบบส่วนหน้าแบบกำหนดเอง เช่น อินเทอร์เฟซการค้นหาสำหรับบริการของ Shakespeare จากตัวอย่างของเรา จะต้องพร้อมใช้งาน ไม่มีความล่าช้า และมีแบนด์วิธเพียงพอ จึงสามารถถามคำถามได้: เราสามารถตอบสนองต่อคำขอได้หรือไม่? ใช้เวลานานเท่าใดในการตอบกลับคำขอ? สามารถประมวลผลคำขอได้จำนวนเท่าใด
• ระบบจัดเก็บข้อมูล พวกเขาให้ความสำคัญกับเวลาแฝงในการตอบสนอง ความพร้อมใช้งาน และความทนทานที่ต่ำ คำถามที่เกี่ยวข้อง: การอ่านหรือเขียนข้อมูลใช้เวลานานเท่าใด? เราสามารถเข้าถึงข้อมูลตามคำขอได้หรือไม่? ข้อมูลพร้อมใช้งานเมื่อเราต้องการหรือไม่? ดูบทที่ 26 ความสมบูรณ์ถูกต้องของข้อมูล: สิ่งที่คุณอ่านคือสิ่งที่คุณเขียน สำหรับการอภิปรายโดยละเอียดเกี่ยวกับปัญหาเหล่านี้
• ระบบข้อมูลขนาดใหญ่ เช่น ไปป์ไลน์การประมวลผลข้อมูลต้องอาศัยปริมาณงานและเวลาแฝงในการประมวลผลคิวรี คำถามที่เกี่ยวข้อง: มีการประมวลผลข้อมูลจำนวนเท่าใด ใช้เวลานานเท่าใดก่อนที่ข้อมูลจะเดินทางจากการรับคำขอไปยังการออกคำตอบ (บางส่วนของระบบอาจมีความล่าช้าในบางขั้นตอนด้วย)

การรวบรวมตัวชี้วัด

ตัวบ่งชี้ระดับการบริการจำนวนมากจะถูกรวบรวมบนฝั่งเซิร์ฟเวอร์ตามธรรมชาติมากที่สุด โดยใช้ระบบการตรวจสอบ เช่น Borgmon (ดูด้านล่าง) บทที่ 10 การแจ้งเตือนการปฏิบัติตามข้อมูลอนุกรมเวลา) หรือ Prometheus หรือเพียงวิเคราะห์บันทึกเป็นระยะ โดยระบุการตอบสนอง HTTP ที่มีสถานะ 500 อย่างไรก็ตาม บางระบบควรติดตั้งการรวบรวมตัวชี้วัดฝั่งไคลเอ็นต์ เนื่องจากการขาดการตรวจสอบฝั่งไคลเอ็นต์อาจทำให้ปัญหาหลายประการที่ส่งผลกระทบหายไป ผู้ใช้ แต่ไม่ส่งผลต่อการวัดฝั่งเซิร์ฟเวอร์ ตัวอย่างเช่น การมุ่งเน้นไปที่เวลาแฝงในการตอบสนองแบ็กเอนด์ของแอปพลิเคชันทดสอบการค้นหาของเช็คสเปียร์อาจส่งผลให้เกิดเวลาแฝงในฝั่งผู้ใช้เนื่องจากปัญหา JavaScript ในกรณีนี้ การวัดระยะเวลาที่เบราว์เซอร์ใช้ในการประมวลผลหน้าเว็บจะเป็นตัวชี้วัดที่ดีกว่า

การรวมตัว

เพื่อความง่ายและสะดวกในการใช้งาน เรามักจะรวมการวัดผลดิบเข้าด้วยกัน จะต้องทำอย่างระมัดระวัง

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

ตัวชี้วัดส่วนใหญ่จะถูกมองว่าเป็นการแจกแจงมากกว่าค่าเฉลี่ย ตัวอย่างเช่น สำหรับเวลาแฝงของ SLI คำขอบางรายการจะได้รับการประมวลผลอย่างรวดเร็ว ในขณะที่บางคำขออาจใช้เวลานานกว่าเสมอ บางครั้งอาจนานกว่านั้นมาก ค่าเฉลี่ยธรรมดาสามารถซ่อนความล่าช้าอันยาวนานเหล่านี้ได้ รูปภาพแสดงตัวอย่าง: แม้ว่าคำขอทั่วไปจะใช้เวลาประมาณ 50 มิลลิวินาทีในการให้บริการ แต่คำขอ 5% นั้นช้ากว่า 20 เท่า! การตรวจสอบและการแจ้งเตือนตามเวลาแฝงโดยเฉลี่ยเท่านั้นจะไม่แสดงการเปลี่ยนแปลงในพฤติกรรมตลอดทั้งวัน เมื่อในความเป็นจริง มีการเปลี่ยนแปลงที่เห็นได้ชัดเจนในเวลาประมวลผลของคำขอบางรายการ (บรรทัดบนสุด)

เวลาแฝงของระบบเปอร์เซ็นไทล์ 50, 85, 95 และ 99 แกน Y อยู่ในรูปแบบลอการิทึม

การใช้เปอร์เซ็นไทล์สำหรับตัวบ่งชี้ช่วยให้คุณเห็นรูปร่างของการแจกแจงและลักษณะของมัน ระดับเปอร์เซ็นไทล์ที่สูง เช่น 99 หรือ 99,9 จะแสดงค่าที่แย่ที่สุด ในขณะที่เปอร์เซ็นไทล์ 50 (หรือที่เรียกว่าค่ามัธยฐาน) จะแสดงสถานะที่พบบ่อยที่สุดของ เมตริก ยิ่งการกระจายเวลาตอบสนองมากเท่าใด คำขอที่ใช้เวลานานก็จะส่งผลต่อประสบการณ์ผู้ใช้มากขึ้นเท่านั้น เอฟเฟกต์จะได้รับการปรับปรุงภายใต้ภาระงานสูงและเมื่อมีคิว การวิจัยประสบการณ์ผู้ใช้แสดงให้เห็นว่า โดยทั่วไปแล้วผู้คนชอบระบบที่ช้ากว่าและมีความแปรปรวนของเวลาตอบสนองสูง ดังนั้นทีม SRE บางทีมจึงมุ่งเน้นไปที่คะแนนเปอร์เซ็นไทล์ที่สูงเท่านั้น บนพื้นฐานที่ว่าหากพฤติกรรมของตัวชี้วัดที่เปอร์เซ็นไทล์ 99,9 นั้นดี ผู้ใช้ส่วนใหญ่จะไม่มีปัญหา .

หมายเหตุเกี่ยวกับข้อผิดพลาดทางสถิติ

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

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

สร้างมาตรฐานตัวชี้วัด

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

• ช่วงเวลาการรวม: “เฉลี่ยมากกว่า 1 นาที”
• พื้นที่รวม: “งานทั้งหมดในคลัสเตอร์”
• ความถี่ในการวัด: “ทุกๆ 10 วินาที”
• รวมคำขอใดบ้าง: "HTTP GET จากงานตรวจสอบกล่องดำ"
• วิธีการได้รับข้อมูล: "ขอบคุณการตรวจสอบของเราที่วัดได้บนเซิร์ฟเวอร์"
• เวลาแฝงในการเข้าถึงข้อมูล: "เวลาถึงไบต์สุดท้าย"

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

เป้าหมายในทางปฏิบัติ

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

กำหนดเป้าหมาย

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

• 99% (โดยเฉลี่ยมากกว่า 1 นาที) ของการโทร Get RPC จะเสร็จสิ้นภายในเวลาไม่ถึง 100 มิลลิวินาที (วัดจากเซิร์ฟเวอร์แบ็กเอนด์ทั้งหมด)
• 99% ของการโทร Get RPC จะเสร็จสิ้นภายในเวลาไม่ถึง 100 มิลลิวินาที

หากรูปร่างของเส้นโค้งประสิทธิภาพมีความสำคัญ คุณสามารถระบุ SLO ได้หลายรายการ:

• 90% ของการโทร Get RPC เสร็จสิ้นในเวลาน้อยกว่า 1 มิลลิวินาที
• 99% ของการโทร Get RPC เสร็จสิ้นในเวลาน้อยกว่า 10 มิลลิวินาที
• 99.9% ของการโทร Get RPC เสร็จสิ้นในเวลาน้อยกว่า 100 มิลลิวินาที

หากผู้ใช้ของคุณสร้างปริมาณงานที่แตกต่างกัน: การประมวลผลจำนวนมาก (ซึ่งปริมาณงานมีความสำคัญ) และการประมวลผลแบบโต้ตอบ (ซึ่งเวลาแฝงมีความสำคัญ) อาจคุ้มค่าที่จะกำหนดเป้าหมายแยกกันสำหรับคลาสโหลดแต่ละคลาส:

• 95% ของคำขอของลูกค้าต้องการปริมาณงาน ตั้งค่าจำนวนการเรียก RPC ที่ดำเนินการ <1 วินาที
• ลูกค้า 99% ใส่ใจเกี่ยวกับเวลาแฝง ตั้งค่าจำนวนการโทร RPC ที่มีการรับส่งข้อมูล <1 KB และทำงาน <10 ms

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

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

การเลือกค่าเป้าหมาย

การเลือกค่าการวางแผน (SLO) ไม่ใช่กิจกรรมทางเทคนิคล้วนๆ เนื่องจากผลิตภัณฑ์และผลประโยชน์ทางธุรกิจที่ต้องสะท้อนให้เห็นใน SLI, SLO ที่เลือก (และอาจเป็น SLA) ในทำนองเดียวกัน อาจต้องมีการแลกเปลี่ยนข้อมูลเกี่ยวกับประเด็นที่เกี่ยวข้องกับการจัดหาพนักงาน เวลาออกสู่ตลาด ความพร้อมของอุปกรณ์ และการเงิน SRE ควรเป็นส่วนหนึ่งของการสนทนานี้และช่วยให้เข้าใจความเสี่ยงและความอยู่รอดของทางเลือกต่างๆ เรามีคำถามสองสามข้อที่อาจช่วยให้การสนทนามีประสิทธิผลมากขึ้น:

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

ง่าย ๆ เข้าไว้
การคำนวณ SLI ที่ซับซ้อนสามารถซ่อนการเปลี่ยนแปลงในประสิทธิภาพของระบบ และทำให้ค้นหาสาเหตุของปัญหาได้ยากขึ้น

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

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

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

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

ควบคุมการวัดของคุณ

SLI และ SLO เป็นองค์ประกอบสำคัญที่ใช้ในการจัดการระบบ:

• ตรวจสอบและวัดผลระบบ SLI
• เปรียบเทียบ SLI กับ SLO และตัดสินใจว่าจำเป็นต้องดำเนินการหรือไม่
• หากจำเป็นต้องดำเนินการ ให้พิจารณาว่าจะต้องทำอะไรเพื่อให้บรรลุเป้าหมาย
• ดำเนินการนี้ให้เสร็จสิ้น

ตัวอย่างเช่น หากขั้นตอนที่ 2 แสดงว่าคำขอหมดเวลาและจะทำให้ SLO พังภายในไม่กี่ชั่วโมงหากไม่มีการดำเนินการใดๆ ขั้นตอนที่ 3 อาจเกี่ยวข้องกับการทดสอบสมมติฐานที่ว่าเซิร์ฟเวอร์เชื่อมโยงกับ CPU และการเพิ่มเซิร์ฟเวอร์เพิ่มเติมจะกระจายภาระงาน หากไม่มี SLO คุณจะไม่รู้ว่า (หรือเมื่อ) จะต้องดำเนินการหรือไม่

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

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

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

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

ข้อตกลงในทางปฏิบัติ

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

ขอบคุณที่อ่านคำแปลจนจบ สมัครสมาชิกช่องโทรเลขของฉันเกี่ยวกับการตรวจสอบ มอนิเตอร์im_it и บล็อกบนสื่อ.

ที่มา: will.com