Data Downtime Monitoring

สำหรับงาน Data Engineer แล้วการทำ Data Pipeline ไม่ได้จบแค่การสร้าง pipeline ใน airflow แล้วจบ แต่ยังรวมไปถึงการสร้างความมั่นใจให้กับผู้ใช้ข้อมูลว่า ข้อมูลที่เรามีให้มีคุณภาพ สามารถพร้อมนำไปใช้วิเคราห์ ใช้งานได้อย่างไม่ต้องกังวล

**Table of Contents**

- What is Data Downtime
- How to measuring Data Downtime
	- Metrics used for Data Downtime
	- How to get these metrics
- Data Downtime Dashboard
- What to improve next?
- References

What is Data Downtime?

คำว่า Data Downtime สามารถแยกออกมาได้เป็นคำ 2 คำ คือ คำว่า Data ที่ทุกคนคุ้นเคยซึ่งแปลว่าข้อมูล และคำว่า Downtime ซึ่งแปลว่าช่วงเวลาที่ไม่สามารถทำงาน หรือใช้งานได้ ดังนั้นคำว่า Data Downtime จึงหมายถึงช่วงเวลาที่ข้อมูลไม่สามารถใช้งานได้

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

ในทางกลับกัน downtime ที่สร้างผลกระทบต่อการใช้ข้อมูล และความเชื่อมั่นของผู้ใช้ข้อมูล นั่นก็คือ unplanned downtime หรือการเกิด downtime ที่ไม่ได้อยู่ในการวางแผนของทีม

สาเหตุสำคัญของการเกิด unplanned downtime คือ ข้อมูลไม่มีคุณภาพ

ยกตัวอย่างเช่น

• ข้อมูลมีค่าซ้ำ (Duplicate Data)
• ข้อมูลไม่อัพเดตทันเวลา (Data Untimeliness) เช่น เรา commit ไว้ว่าข้อมูลชุดนี้จะอัพเดตทุกวันไม่เกินสิบโมงเช้า แต่กลับเกิดเหตุการณ์อะไรสักอย่างขึ้นทำให้ข้อมูลชุดนี้อัพเดตเวลาเที่ยง ก็ถือว่าข้อมูลชุดนี้อัพเดตไม่ทันเวลาที่ตกลงกับผู้ใช้ข้อมูล
• ข้อมูลไม่อยู่ในรูปแบบที่กำหนด (Data Inconsistent Format) เช่น คอลัมน์ A ควรเป็น String แต่กลับเป็น Int แทน
• ข้อมูลไม่ครบ (Data Incomplete) เช่น คอลัมน์ A ห้ามมีค่าว่างแต่กลับมีค่าว่างโผล่มา หรือ ข้อมูลดึงมาไม่ครบ มีแถวที่ขาดหายไป

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

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

How to measure Data Downtime?

Metrics used for measuring data downtime

ด้วความที่เป็นเฟสแรกของโปรเจคต์ Data Downtime เราจะเริ่มต้นการวัดผลด้วยค่าพื้นฐานที่ใช้ในการวัดผล ซึ่งมีด้วยกันทั้งหมดสามค่านั่นก็คือ Data Downtime, Time To Detect และ Time To Resolve หรือ Time To Repair ซึ่งทั้งหมดสามตัวนี้มีความสัมพันธ์กันและสามารถบอกอะไรบางอย่างให้เราได้

เริ่มจากความสัมพันธ์ระหว่างสามค่านี้

Data Downtime = #Data Incidents * (Time To Detect + Time To Repair)

• # Data Incidents = จำนวน downtime ที่เกิดขึ้น
• Data Downtime = บอกเราได้ว่าข้อมูลที่เกิดจาก pipeline นี้ไม่สามารถใช้งานได้นานเท่าไหร่
• Time To Detect = บ่งบอกว่าต้องใช้เวลานานเท่าไหร่ทีม DE ถึงจะทราบถึงปัญหาและเข้าไปแก้ไข
• Time To Resolve/Time To Repair = บ่งบอกว่าใช้เวลานานเท่าไหร่ถึงจะสามารถแก้ปัญหาได้

ดังนั้น เราจะเห็นได้เลยว่าถ้ามี Downtime เกิดขึ้นจะสามารถวัดได้ว่า Donwtime นั้นนานเพราะเกิดจากปัญหาใหญ่จนทำให้ต้องใช้เวลานาน หรือเกิดจากทีม detect แล้วเข้าไปแก้ปัญหาได้ช้าแต่ไม่ใช้เวลานานในการแก้ปัญหา

นอกจากสามค่าข้างบนแล้วยังมีค่าอื่นที่สามารถนำมาแสดงได้ เช่น

• Time Between Failure = เวลาระหว่างสอง downtime ที่เกิดขึ้นห่างกันนานเท่าไหร่
• Time To Failure = เวลาหลังจากซ่อมแซมเสร็จแล้วเกิด donwtime ขึ้นอีกครั้งนานเท่าไหร่
• Availability = ร้อยละของเวลาที่ข้อมูลสามารถใช้งานได้

Downtime Metrics

How to get these metrics?

พอเรารู้แล้วว่าต้องเก็บค่าอะไรบ้าง ทีนี้คำถามคือเก็บยังไงดี นั่งจ้อง Pipeline ทั้งวันพอเห็นแดงปุ๊ปเริ่มกดนาฬิกาจับเวลามั้ย… ถ้าทำแบบนั้นไม่ใช่วิธีที่ดีเท่าไหร่ค่ะ

ดังนั้นสองสิ่งสำคัญที่ควรมี ได้แก่

1. Alert เมื่อ pipeline พัง

เพื่อที่เราจะสามารถรู้ได้ทันทีที่พังแล้วเข้าไปแก้ไข นอกจากนี้การมีการแจ้งเตือนยังเป็นการเก็บข้อมูลด้วยว่าพังเมื่อไหร่ พังกี่ครั้ง pipeline อะไรที่พัง

2. การ validate ข้อมูล

การ validate ข้อมูลเป็นการตรวจสอบว่าข้อมูลที่จะส่งให้ผู้ใช้มีคุณภาพตามมาตรฐาน เช่น มีการเช็คว่า column A ไม่มีค่าเป็น null และต้องเป็นประเภท String เท่านั้น หรือ column B มีได้แค่ค่า Active กับ Inactive เท่านั้นเป็นต้น

เมื่อเรามีทั้งสองสิ่งนี้ก็จะครอบคลุมการวัด data downtime ขั้นเบื้องต้นแล้ว

เนื่องจากว่าใน pipeline ของเรามีการ validate ข้อมูลทุกครั้งหลัง transform ข้อมูล เมื่อ validate ไม่ผ่าน pipeline จะ fail และข้อมูลชุดนั้นจะไม่ถูกส่งไปหาผู้ใช้ข้อมูลเลย แล้วส่ง alert แจ้งเตือนมายังทีม ดังนั้นเราสามารถเก็บค่า downtime ทุกอย่างที่เกิดขึ้นได้ผ่านตัว alert

example of data pipeline

เราใช้ Opsgenie เป็น tools ในการสร้าง alert แล้วส่งต่อมาที่ Microsoft Team channel เพื่อแจ้งเตือนให้เรารู้ว่ามีอะไรบางอย่างพัง

example of Opsgenie Alert

จะเห็นว่ามีปุ่มให้กด Acknowledge ซึ่งหมายถึงเรา detect ปัญหาแล้วนะ แล้วเมื่อแก้ไขเสร็จเรียบร้อยก็สามารถมากด Close เพื่อปิดการแจ้งเตือน แล้วเจ้า Opsgenie จะบันทึกเวลาที่ใช้ว่าใช้เวลาเท่าไหร่ตั้งแต่ alert เกิดขึ้น (downtime เริ่มต้น) ถึงจะกด Acknowledge (รับรู้ถึงปัญหาและเข้าไปแก้ไข) และใช้เวลานานเท่าไหร่ตั้งแต่ alert เกิดขึ้นถึงกด Close (เวลาที่ใช้ข้อมูลไม่ได้)

การเอาข้อมูลจาก Opsgenie เนี่ยสามารถทำได้ผ่าน API ที่ทาง Opsgenie ให้ใช้ได้เลยค่ะ ตอนที่เราสร้าง alert ก็ใช้ Create Alert ส่วนตอนดึงข้อมูล alert ก็สามารถใช้ List Alert ได้เลย

⚠️ Opsgenie มีหลาย plan ด้วยกันและแต่ละ plan ก็จะมี API บางอย่างที่สามารถใช้ได้แต่ตัวฟรีใช้ไม่ได้ซึ่งอาจจะง่ายทำให้ชีวิตง่ายขึ้น เช่น ถ้าใช้ Enterprise Plan จะสามารถดู dashboard ผ่าน UI ของ Opsgenie ได้เลย แต่เราใช้ตัวฟรีดังนั้นเราจะไปท่าดึง alert จาก API แล้วสร้าง dashboard เอง

ข้อมูลจาก List Alert จะได้ออกมาแบบนี้

{
    "data": [
        {
            "id": "70413a06-38d6-4c85-92b8-5ebc900d42e2",
            "tinyId": "1791",
            "alias": "event_573",
            "message": "Our servers are in danger",
            "status": "closed",
            "acknowledged": false,
            "isSeen": true,
            "tags": [
                "OverwriteQuietHours",
                "Critical"
            ],
            "snoozed": true,
            "snoozedUntil": "2017-04-03T20:32:35.143Z",
            "count": 79,
            "lastOccurredAt": "2017-04-03T20:05:50.894Z",
            "createdAt": "2017-03-21T20:32:52.353Z",
            "updatedAt": "2017-04-03T20:32:57.301Z",
            "source": "Isengard",
            "owner": "morpheus@opsgenie.com",
            "priority": "P4",
            "responders":[
              {
                  "id":"4513b7ea-3b91-438f-b7e4-e3e54af9147c",
                  "type":"team"
              },
            ],
            "integration": {
                "id": "4513b7ea-3b91-438f-b7e4-e3e54af9147c",
                "name": "Nebuchadnezzar",
                "type": "API"
            },
            "report": {
                "ackTime": 15702,
                "closeTime": 60503,
                "acknowledgedBy": "agent_smith@opsgenie.com",
                "closedBy": "neo@opsgenie.com"
            }
        }
    ],
    "paging":{
        "next":"<https://api.opsgenie.com/v2/alerts?query=status%3Aopen&offset=20&limit=10&sort=createdAt&order=desc>",
        "first":"<https://api.opsgenie.com/v2/alerts?query=status%3Aopen&offset=0&limit=10&sort=createdAt&order=desc>",
        "last":"<https://api.opsgenie.com/v2/alerts?query=status%3Aopen&offset=100&limit=10&sort=createdAt&order=desc>"
    },
    "took": 0.605,
    "requestId": "9ae63dd7-ed00-4c81-86f0-c4ffd33142c9"
}

ซึ่งสามารถดึงออกมาในแต่ละวันตาม query ที่ส่งผ่าน API ไปแล้ว schedule ด้วยการทำเป็น pipeline ดึงข้อมูลจาก Opsgenie Alert จากนั้นก็ transform แล้วก็ทำ data model ตามที่เราต้องการ

🚨 ข้อควรระวัง

• timezone ของข้อมูลจาก Opsgenie คือ UTC แต่เวลาดูผ่าน dashboard เรามักจะอยากดูข้อมูลของเมื่อวานใน timezone ไทย ดังนั้นอย่าลืมแปลง timezone ของข้อมูล
• หน่วยของ ackTime และ closeTime คือ millisecond เริ่มนับตั้งแต่ alert ถูกสร้างขึ้นแต่เราคงไม่อยากดู dashboard ที่หน่วยเป็นหมื่นมิลลิวินาที ดังนั้นอย่าลืมแปลงหน่วยเวลา
• ackTime คือเวลาตั้งแต่ alert ถูกสร้างจนถึงเวลาที่กด Acknowledge ดังนั้นคือ Time To Detect แต่ closeTime คือคือเวลาตั้งแต่ alert ถูกสร้างจนถึงเวลาที่กด Close ซึ่งหมายถึงเวลาที่แก้ไขเสร็จสิ้น ดังนั้นคือ Downtime ไม่ใช่ Time To Repair

Data Downtime Dashboard

พอข้อมูลเราพร้อมแล้วก็มาดู dashboard กันเถอะ

example of data downtime dashboard

ถ้าไล่ดูจะเห็นว่าเรามีแสดงผลค่าเฉลี่ยของ Downtime, Time To Detect และ Time To Repairในหน่วยของชั่วโมง มีทั้งแบบรวมทุก pipeline และ เฉลี่ยแยกตาม pipeline รวมไปถึงเฉลี่ยรายวันด้วย จะเห็นได้ว่าเราสามารถดูภาพรวมได้ว่าช่วงเวลานี้มี downtime เฉลี่ยเท่าไหร่ เพิ่มขึ้นหรือลดลงจากช่วงเวลาที่แล้ว คิดเป็นร้อยละแล้ว ข้อมูลของเราไม่พร้อมใช้งานเท่าไหร่ แล้วใช้เวลานานเท่าไหร่ถึงจะเกิด downtime ขึ้นอีกหนึ่งครั้ง

เมื่อดูกราฟด้านล่างจะสามารถดูแยกได้ว่า pipeline ไหนเกิด downtime มากที่สุด และสามารถเห็นความผิดปกติได้ถ้าเกิด downtime อยู่ ๆ ก็พุ่งสูงมาก ดังกราฟเส้นทางขวามือ

What to improve next?

มีข้อควรระวังและจุดที่ควรพัฒนาเพิ่มต่อ ดังนี้

• ถ้าคน on-call ไม่กด Acknowledge แต่กด Close เลยจะทำให้ AckTime = CloseTime ทำให้ Time To Detect เยอะกว่าความเป็นจริง
• ตอนนี้ยังไม่มีการเก็บและคำนวณร้อยละของ downtime ตามรอบการอัพเดตของ pipeline หมายความว่า metrics ของ pipeline ที่ทำงานทุกชั่วโมงกับทำงานทุกวัน ใช้การคำนวณแบบเดียวกัน ส่งผลให้ร้อยละของ downtime น้อยกว่าความเป็นจริงเนื่องจากความถี่ของการทำงานไม่เท่ากัน

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

References

• https://www.montecarlodata.com/blog-the-rise-of-data-downtime/#:~:text=I've%20come%20to%20call,and%20in%20a%20reactive%20manner
• https://www.sigga.com/blog/downtime-operations-metrics#:~:text=The%20most%20well%2Dknown%20downtime,a%20failed%20piece%20of%20equipment.
• https://medium.com/@siripatsorn/data-quality-%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%AD%E0%B8%B0%E0%B9%84%E0%B8%A3-972e2d0d29b3
• https://docs.opsgenie.com/docs/alert-api#list-alerts