จากเวลาทำงานต่อเนื่องสู่ประสบการณ์: การเปลี่ยนแปลงที่ขับเคลื่อนด้วย AI ในการสังเกตการณ์สมัยใหม่

ในปี 2001 IBM ได้เขียนแถลงการณ์ IT อัตโนมัติ วิสัยทัศน์ของการคอมพิวเตอร์อัตโนมัติ แบ่งการจัดการตนเองออกเป็นสี่เสาหลัก: การเพิ่มประสิทธิภาพตนเอง, การรักษาตนเอง, การกำหนดค่าตนเอง, และการปกป้องตนเอง ฉันอยู่ที่ Microsoft ขณะที่ IBM นำเสนอวิสัยทัศน์ IT นี้ เราตอบสนองโดยเสนอแนวคิดเทคโนโลยีเช่นศูนย์ข้อมูลอัตโนมัติ แต่ในที่สุดก็เป็นความฝันที่ล่วงหน้ากว่ากาลเวลาอย่างมาก ไม่มีวิธีที่เป็นรูปธรรมที่จะทำให้วิสัยทัศน์นั้นเป็นจริง

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

จากระดับการให้บริการสู่ระดับประสบการณ์

แนวคิดของการสังเกตการณ์ไม่ได้มาจาก IT ในปี 1960 วิศวกรและนักคณิตศาสตร์ชาวฮังการี-อเมริกัน Rudolf E. Kálmán ตั้งชื่อ คำว่า “observability” เพื่ออธิบายว่าระบบสามารถวัดได้ดีแค่ไหนจากผลลัพธ์ของมัน จากนั้นในปี 2013 Twitter นำคำนี้มาใช้ ในชุดบทความบล็อก ซึ่งโดยนัยบอกว่าการตรวจสอบแบบเก่า ผ่านเครื่องมือเชิงพาณิชย์ที่มีอยู่ ถูกออกแบบมาสำหรับยุคเทคโนโลยีที่ต่างกันและไม่ทำงานในสถาปัตยกรรมระดับไมโครเซอร์วิส

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

ระบบในปัจจุบันได้กลายเป็นใหญ่และซับซ้อนยิ่งขึ้น โดยพึ่งพาเครือข่ายการส่งมอบเนื้อหา (CDN) การแคชและการแจกจ่ายบิตแมพ ฟอนต์ ไฟล์ JavaScript ฯลฯ ทั่วโลก การเข้าใจประสิทธิภาพของแอปพลิเคชันในโลกจริงอย่างแท้จริงไม่ใช่เรื่องง่าย

เมื่อทีม IT ได้รับการแจ้งเตือนเวลา 4 โมงเช้า ต้องมีคนลุกจากเตียงและตรวจสอบว่าปัญหาเกิดจากเซกเตอร์เสียบนฮาร์ดไดรฟ์หรือผู้ไม่ประสงค์ดีที่พยายามเจาะระบบและก่อความเสียหายในโครงสร้างพื้นฐาน ไม่สำคัญว่ามันคืออะไร ในที่สุดงานของพวกเขาคือทำให้ระบบทั้งหมดทำงานต่อไป โชคดีที่ในการประเมินสุขภาพของแอปพลิเคชันในวันนี้ เราสามารถรับข้อมูล telemetry ทั้งหมดที่มีอยู่: อุปกรณ์เครือข่ายทุกเครื่อง แอปพลิเคชันทุกตัว การรวมระบบนับพันแบบพร้อมใช้ การไหลของตั๋วผ่าน JIRA หรือ Atlassian และสัญญาณอื่น ๆ อีกมากมาย

นี่คือจุดที่ Experience Level Objectives (XLOs) เข้ามามีบทบาท คุณอาจเคยได้ยินเกี่ยวกับ Service Level Agreements (SLAs) และ Service Level Objectives (SLOs) แต่ XLOs ก้าวต่อไปโดยวัดว่าลูกค้าและพนักงานของคุณได้รับระดับประสบการณ์ที่ต้องการหรือไม่ มันเกี่ยวกับคุณภาพ ไม่ใช่แค่เวลาทำงานต่อเนื่อง จากมุมมองทางเทคนิค วิธีเดียวที่จะบรรลุ XLOs คือการมีการมองเห็นตั้งแต่ NIC จนถึงอุปกรณ์ของผู้ใช้ปลายทาง

ในเดือนตุลาคมที่ผ่านมา AWS US-EAST-1 หยุดทำงาน. Catchpoint ตรวจพบปัญหา 16 นาทีก่อนที่ Amazon จะประกาศต่อสาธารณะ ลูกค้าที่มีการมองเห็นนั้นสามารถตอบสนองได้ก่อนที่ผู้ใช้ของพวกเขาจะรู้สึกถึงผลของการหยุดทำงาน

สัญญาของการสังเกตการณ์เปรียบเสมือน Smokey Bear: ตรวจจับควันก่อนที่ไฟจะลุกขึ้น หากทำอย่างถูกต้อง การสังเกตการณ์จะช่วยให้คุณดับไฟในทุ่งหญ้าได้ก่อนที่มันจะกลายเป็นไฟร้อนแรงที่ทำลาย Palisades ในแคลิฟอร์เนีย Smokey คือระบบเตือนล่วงหน้าที่สามารถตรวจจับควันเล็ก ๆ ไม่ว่ามาจากไหน: ปัญหา AWS, ปัญหา Oracle, ปัญหา GCP, ปัญหา Microsoft Azure หรือความบกพร่องในโครงสร้างพื้นฐานของคุณ

AI ขยายระบบความปลอดภัย

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

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

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

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

AI ทำให้ไอทีกลับมาน่าตื่นเต้นอีกครั้ง

ฉันได้พักงานสักระยะหลังจาก Cisco เข้าซื้อกิจการ Splunk ในปี 2023 ในสองปีต่อมาฉันได้เห็นเพื่อนและอดีตเพื่อนร่วมงานของฉันก่อตั้งบริษัทเพื่อใช้ AI ในวิธีที่ไม่อาจทำได้เมื่อห้าปีก่อน (จำไว้ว่า หาก ChatGPT เป็นเด็กมนุษย์ มันจะอายุสามปี)

ทีมไอทีต้องการความช่วยเหลือในการตรวจจับสัญญาณเตือนก่อนที่สัญญาณจะดัง ไม่ใช่การเพิ่มแดชบอร์ดให้มองดูมากขึ้น พวกเขา… ในแง่หนึ่ง นี่คือปัญหาเดียวกันที่ IBM, Twitter และแม้แต่ Microsoft กับ Clippy พยายามแก้ไขมาตลอด

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