พอมี dashboard กับระบบแจ้งเตือนแล้ว เราจะเริ่มเห็นตัวเลขของบริการมากขึ้น ทั้งเวลาตอบสนอง อัตราความผิดพลาด และช่วงที่ตรวจไม่ผ่าน แต่เวลาจะคุยว่าระบบควรดีแค่ไหน ตัวเลขเหล่านี้ยังต้องถูกเชื่อมกลับมาที่งานที่ผู้ใช้ต้องทำให้ได้
อย่างเว็บที่เปิดหน้าแรกได้ แต่กดบันทึกงานสำคัญไม่ได้ คนใช้ก็ยังถือว่าระบบมีปัญหาได้ หรือ API ที่ตอบสำเร็จทุกครั้งแต่ต้องรอนานเกินจังหวะทำงาน ก็อาจไม่ตอบความต้องการ แม้กราฟ availability แบบง่ายจะยังดูดีอยู่
ก่อนเลือกเป้าว่าต้องได้กี่เก้า จึงควรตกลงก่อนว่าอะไรคือบริการที่ยอมรับได้สำหรับงานนี้ และเรามีหลักฐานจากจุดไหนใช้ตรวจข้อตกลงนั้นครับ
SLI เป็นตัวชี้วัดคุณภาพของบริการที่นิยามไว้อย่างเจาะจง เช่น สัดส่วนคำขอที่ทำงานได้ตามเงื่อนไข ส่วน SLO เป็นเป้าหมายที่ต้องการให้ตัวชี้วัดนั้นทำได้ภายในช่วงเวลาที่กำหนด เราจึงยังตั้งเป้าหมายที่อ่านตรงกันไม่ได้ หากยังตอบไม่ชัดว่าตัวเศษกับตัวหารนับอะไร
ลองใช้ตัวอย่างสมมติของหน้าบันทึกข้อมูล เราอาจสนใจว่างานที่ถูกต้องตามเงื่อนไขและผู้ใช้มีสิทธิ์ส่งเข้ามา ถูกบันทึกสำเร็จตามความหมายที่กำหนดหรือไม่ การได้ HTTP 200 อาจใช้เป็นสัญญาณได้ในบางระบบ แต่ต้องตรวจว่ารหัสนั้นสะท้อนการบันทึกจริง หรือเป็นเพียงหน้ากลางที่ตอบกลับได้
คำว่า SLA เป็นอีกเรื่องที่เกี่ยวข้องกับข้อตกลงและผลเมื่อทำไม่ได้ตามนั้น การเริ่มวัดภายในทีมไม่ได้ทำให้เกิดข้อตกลงกับลูกค้าแบบเดียวกันทันที จึงควรใช้คำให้ตรง ไม่เรียกตัวเลขที่เพิ่งเสนอใน dashboard ว่าเป็นคำรับรองภายนอกโดยไม่มีการตกลง
บางงานยังต้องดูความสดของข้อมูลด้วย เช่น หน้าตรวจสถานะอุปกรณ์อาจตอบได้รวดเร็ว แต่แสดงค่าที่เก่าเกินกว่าจะใช้ตัดสินใจ หากความสดเป็นเงื่อนไขสำคัญ ก็ควรมีตัวชี้วัดที่สะท้อนเงื่อนไขนั้นแยกจากการเปิดหน้าได้ เพื่อให้ความสำเร็จของการส่งคำตอบไม่บังปัญหาของข้อมูลข้างใน
การกำหนดว่าคนใช้ควรทำงานสำเร็จได้เป็นเรื่องหนึ่ง ส่วนวิธีวัดจาก log, metrics หรือจุดทดสอบเป็นอีกเรื่องหนึ่ง หากใช้เฉพาะข้อมูลจากภายในแอป เราอาจมองไม่เห็นคำขอที่ไปไม่ถึงแอปตั้งแต่ต้น แต่ถ้าใช้จุดตรวจภายนอกก็อาจตรวจได้เพียงเส้นทางที่เตรียมไว้
แต่ละวิธีจึงมีขอบเขตและจุดบอด ควรบันทึกว่าตัวชี้วัดแทนประสบการณ์ส่วนใดของผู้ใช้ได้ และอะไรที่ยังต้องดูจากหลักฐานอื่น ไม่ทำให้จำนวนที่หาได้ง่ายกลายเป็นนิยามความสำเร็จทั้งหมดเพียงเพราะเก็บสะดวก
การนับคำขอที่ผิดรูปแบบหรือไม่มีสิทธิ์ก็ต้องมีกติกา การตัดออกอาจเหมาะกับคำถามบางแบบ แต่ควรระบุไว้ก่อนและตรวจได้ ไม่ปรับตัวหารหลังเกิดเหตุเพียงเพื่อให้ตัวเลขกลับมาดี รวมถึงแยก traffic ทดสอบออกอย่างมีเหตุผลถ้าตั้งใจวัดประสบการณ์ผู้ใช้จริง
เป้าหมายที่บอกเพียงเปอร์เซ็นต์ยังไม่ครบ ต้องมีช่วงประเมินด้วย เช่น ใช้ช่วงย้อนหลังที่เลื่อนไปเรื่อยๆ หรือช่วงปฏิทินที่ตกลงไว้ ทั้งสองแบบทำให้ช่วงที่เหตุการณ์ถูกนับเข้าหรือออกต่างกัน คนอ่านจึงต้องรู้ว่าเลขบนหน้าจอกำลังอ้างถึงช่วงใด
การวัดตามจำนวนคำขอไม่ได้แปลงเป็นเวลาหยุดได้เท่ากันทุกกรณี เหตุขัดข้องช่วงมีคนใช้มากอาจกระทบคำขอจำนวนมากกว่าช่วงเงียบ แม้กินเวลานานเท่ากัน หากต้องการเป้าตามเวลาหรือประสบการณ์รายกลุ่ม ก็ต้องเลือกนิยามและข้อมูลที่สอดคล้องกัน
บริการที่มีงานไม่บ่อยก็ต้องอ่านอย่างระมัดระวัง ช่วงที่ไม่มีคำขอไม่ใช่หลักฐานว่าไม่มีใครทำงานได้หรือทุกคนทำงานได้ จึงควรกำหนดการจัดการช่วงไม่มีข้อมูล และอาจใช้หลักฐานความพร้อมจากจุดตรวจที่เหมาะสมประกอบ โดยไม่ยุบทั้งหมดเป็นศูนย์ error อย่างเงียบๆ
เมื่อกำหนดเป้าที่ต่ำกว่าร้อยละ100 ส่วนที่ยอมให้ไม่เป็นไปตามเกณฑ์ภายในช่วงนั้นคือ error budget ตามนิยามที่ใช้ หากวัดแบบสัดส่วนคำขอ งบนี้ก็เกี่ยวกับจำนวนหรือสัดส่วนคำขอที่ไม่ผ่าน ไม่ใช่งบ downtime ที่ย้ายหน่วยใช้แทนกันได้เสมอ
ประโยชน์ของมันอยู่ที่ช่วยคุยว่าจะจัดลำดับงานอย่างไรเมื่อความน่าเชื่อถือถูกใช้ไปมาก เช่น เพิ่มความสำคัญให้ปัญหาที่ทำให้บันทึกงานไม่ได้ หรือลดความเสี่ยงของการเปลี่ยนส่วนที่เกี่ยวข้องชั่วคราว แต่ทางเลือกต้องตกลงร่วมกับคนรับผิดชอบผลิตภัณฑ์และงานพัฒนา ไม่ใช่ปล่อยให้ dashboard ตัดสินแทนทั้งหมด
ถ้าไม่มีนโยบายว่าใครดู ใครตัดสิน และต้องทำอะไรเมื่อถึงเงื่อนไข ตัวเลขก็อาจเป็นเพียงรายงานอีกใบหนึ่ง การเขียนกติกาไว้ก่อนยังช่วยลดการเถียงหลังเกิดเหตุว่าเหตุการณ์รอบนี้ควรถูกนับหรือควรยกเว้นเพราะเหตุใด
การตั้งเป้าสูงมากโดยยังไม่รู้ความสามารถของระบบอาจทำให้ตกเงื่อนไขอยู่ตลอด จนไม่มีใครใช้กติกานั้นตัดสินใจจริง ในทางกลับกัน เป้าที่ผ่อนจนคนใช้ทำงานไม่ได้เป็นระยะก็อาจไม่ช่วยรักษาคุณภาพ จึงต้องพิจารณาทั้งความต้องการของงาน หลักฐานที่ผ่านมา และสิ่งที่ทีมดูแลได้
หากยังไม่มีข้อมูลพอ ควรบอกชัดว่าค่าแรกเป็นข้อเสนอสำหรับเริ่มเก็บและทบทวน ไม่อ้างว่าเป็นระดับที่ระบบทำได้แล้ว แล้วค่อยเทียบกับปัญหาที่ผู้ใช้พบจริงว่าตัวชี้วัดเคลื่อนไปในทิศทางที่อธิบายอาการนั้นหรือไม่ ถ้าคนใช้เดือดร้อนแต่ SLI ยังดูดี ก็อาจต้องแก้นิยามหรือจุดวัด
เอกสารควรมีเจ้าของ เหตุผลของเป้า วิธีคำนวณ ช่วงเวลา และจังหวะทบทวน รวมถึงนโยบายตอบสนองเมื่อ budget เหลือน้อย บทนี้ยังไม่มีข้อมูลความพร้อมใช้จริงหรือการอนุมัติระดับบริการของ CommandEng จึงไม่มีเปอร์เซ็นต์ใดที่ใช้เป็นผลวัดหรือข้อผูกมัดใหม่ของเว็บ
การตั้งเป้าคุณภาพบริการเริ่มจากงานที่คนใช้ต้องทำ แล้วค่อยนิยาม SLI เลือกจุดวัดและช่วงประเมินให้ตรง ก่อนตกลง SLO กับนโยบายเมื่อใช้ error budget ไปมาก เมื่อแต่ละส่วนเชื่อมกัน ตัวเลขจะช่วยตัดสินใจเรื่องความเสี่ยงและลำดับงานได้ชัดขึ้น พร้อมมีทางทบทวนเมื่อหลักฐานบอกว่าสิ่งที่วัดยังไม่สะท้อนปัญหาของผู้ใช้