เหตุใดธนาคารจึงต้องมี AIOps และการตรวจติดตามแบบครอบคลุม หรืออะไรคือความสัมพันธ์ของลูกค้าโดยยึดตาม

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

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

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

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

ผลิตภัณฑ์ที่เราทำเป็นของซอฟต์แวร์ระดับองค์กร ส่วน AIOps (ปัญญาประดิษฐ์สำหรับการดำเนินงานด้านไอทีหรือ ITOps) เป้าหมายหลักของการนำระบบดังกล่าวไปใช้เมื่อระดับของกระบวนการครบกำหนดในบริษัทเพิ่มขึ้น:

1. ดับไฟ: ระบุความล้มเหลว เคลียร์กระแสการแจ้งเตือนจากเศษซาก มอบหมายงานและเหตุการณ์ให้กับผู้รับผิดชอบ
2. เพิ่มประสิทธิภาพการบริการด้านไอที ลดเวลาในการแก้ไขเหตุการณ์ ระบุสาเหตุของความล้มเหลว เพิ่มความโปร่งใสของสถานะไอที
3. เพิ่มประสิทธิภาพทางธุรกิจ: ลดปริมาณแรงงานคน, ลดความเสี่ยง, เพิ่มความภักดีของลูกค้า

จากประสบการณ์ของเรา ธนาคารมี "ปัญหา" ต่อไปนี้ในการตรวจสอบเหมือนกับโครงสร้างพื้นฐานด้านไอทีขนาดใหญ่ทั้งหมด:

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

เมื่อเรามาการประชุมครั้งแรกที่ Tinkoff เราได้รับแจ้งทันทีว่าพวกเขาไม่มีปัญหาในการติดตามและไม่มีอะไรทำร้ายพวกเขา และคำถามหลักคือ: “เราจะเสนออะไรให้กับผู้ที่ทำได้ดีอยู่แล้ว?”

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

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

ด้วยเหตุนี้ เราจึงระบุความร่วมมือในด้านต่างๆ ดังนี้

1. ขั้นแรกคือการตรวจสอบแบบร่มเพื่อเพิ่มความเร็วในการแก้ไขเหตุการณ์
2. ขั้นตอนที่สองคือกระบวนการอัตโนมัติเพื่อลดความเสี่ยงและลดต้นทุนในการขยายแผนกไอที

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

ในความคิดของเรา สิ่งที่สำคัญมากในความสัมพันธ์กับลูกค้าคือความซื่อสัตย์ หลังจากการสนทนาครั้งแรกและการคำนวณต้นทุนของใบอนุญาต ว่ากันว่าเนื่องจากต้นทุนต่ำมาก จึงอาจคุ้มค่าที่จะซื้อใบอนุญาตทันที (เทียบกับ Dynatrace Klyuch-Astrom จากบทความด้านบนเกี่ยวกับธนาคารสีเขียว ของเรา ใบอนุญาตมีราคาไม่ถึงหนึ่งในสามพันล้าน แต่ 12 รูเบิลต่อเดือนสำหรับ 1 กิกะไบต์สำหรับ Sber จะมีราคาถูกกว่าหลายเท่า) แต่เราบอกพวกเขาทันทีถึงสิ่งที่เรามีและสิ่งที่เราไม่มี บางทีตัวแทนฝ่ายขายจากผู้รวมระบบรายใหญ่อาจพูดว่า "ใช่ เราทำทุกอย่างได้ แน่นอนซื้อใบอนุญาตของเรา" แต่เราตัดสินใจวางไพ่ทั้งหมดของเราลงบนโต๊ะ ในขณะที่เปิดตัว กล่องของเราไม่มีการบูรณาการกับ Prometheus และเวอร์ชันใหม่ที่มีระบบย่อยอัตโนมัติกำลังจะออก แต่เรายังไม่ได้จัดส่งให้กับลูกค้า

โครงการนำร่องเริ่มต้นขึ้น กำหนดขอบเขตแล้ว และเราได้รับเวลา 2 เดือน งานหลักคือ:

• เตรียมแพลตฟอร์มเวอร์ชันใหม่และปรับใช้ในโครงสร้างพื้นฐานของธนาคาร
• เชื่อมต่อ 2 ระบบตรวจสอบ (Zabbix และ Prometheus)
• ส่งการแจ้งเตือนไปยังผู้ที่รับผิดชอบใน Slack และทาง SMS
• เรียกใช้สคริปต์การรักษาอัตโนมัติ

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

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

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

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

ตามที่ Sergei หัวหน้าสถาปนิกของเรากล่าวว่า การติดตั้งระบบปลั๊กอินจะใช้เวลาอย่างน้อยหนึ่งเดือน

เราไม่มีเวลา...

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

จากผลของโครงการนำร่อง ทำให้ได้รับผลลัพธ์ทางเทคนิคและข้อสรุปที่สำคัญหลายประการ:

เราทดสอบฟังก์ชันใหม่สำหรับการประมวลผลการแจ้งเตือน

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

อินเทอร์เฟซ "ทริกเกอร์สังเคราะห์" การตั้งค่าการประมวลผลการแจ้งเตือนจากระบบตรวจสอบที่เชื่อมต่อ

สร้างสถานะของ “สุขภาพ” ของระบบ

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

อินเทอร์เฟซสำหรับการทำงานกับโมเดลบริการทรัพยากร นักบินอาร์เอสเอ็ม

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

อินเทอร์เฟซการวิเคราะห์ หน้าจอการตรวจสอบเดียว

เปิดตัวกระบวนการอัตโนมัติ

การตรวจสอบเหตุการณ์ทำให้เกิดการเรียกใช้การดำเนินการที่กำหนดค่าไว้ล่วงหน้า - การส่งการแจ้งเตือน การเรียกใช้สคริปต์ การลงทะเบียน/การปรับปรุงเหตุการณ์ - ส่วนหลังไม่ได้ลองใช้กับไคลเอนต์รายนี้โดยเฉพาะ เนื่องจาก ในโครงการนำร่องไม่มีการบูรณาการกับส่วนให้บริการ

อินเทอร์เฟซการตั้งค่าการกระทำ ส่งการแจ้งเตือนไปยัง Slack และรีบูตเซิร์ฟเวอร์

ขยายฟังก์ชันการทำงานของผลิตภัณฑ์

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

อินเทอร์เฟซสำหรับการทำงานกับสคริปต์การซ่อมแซมอัตโนมัติ สคริปต์รีบูตเซิร์ฟเวอร์ผ่าน SSH

การค้นพบที่สำคัญ

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

• ใช้ความสามารถในการส่งต่อตัวแปรโดยตรงจากการแจ้งเตือนไปยังสคริปต์การรักษาอัตโนมัติ
• เพิ่มการอนุญาตให้กับแพลตฟอร์มผ่าน Active Directory

และเราได้รับความท้าทายระดับโลกมากขึ้น - ในการ "สร้าง" ผลิตภัณฑ์ที่มีความสามารถอื่นๆ:

• การสร้างโมเดลบริการทรัพยากรโดยอัตโนมัติโดยใช้ ML แทนที่จะเป็นกฎและตัวแทน (อาจเป็นความท้าทายหลักในขณะนี้)
• รองรับภาษาสคริปต์และตรรกะเพิ่มเติม (และนี่จะเป็น JavaScript)

ในความคิดของฉัน สิ่งที่สำคัญที่สุดสิ่งที่โครงการนำร่องนี้แสดงให้เห็นมีสองสิ่ง:

1. ความร่วมมือกับลูกค้าเป็นกุญแจสำคัญสู่ประสิทธิผล เมื่อการสื่อสารที่มีประสิทธิภาพถูกสร้างขึ้นบนพื้นฐานของความซื่อสัตย์และการเปิดกว้าง และลูกค้าจะกลายเป็นส่วนหนึ่งของทีมที่บรรลุผลลัพธ์ที่สำคัญในระยะเวลาอันสั้น
2. ไม่ว่าในสถานการณ์ใดก็ตาม ไม่จำเป็นต้อง "ปรับแต่ง" และสร้าง "ไม้ค้ำยัน" - มีเพียงโซลูชันระบบเท่านั้น ดีกว่าที่จะใช้เวลาเพิ่มเล็กน้อย แต่สร้างโซลูชันระบบที่ไคลเอนต์รายอื่นจะใช้ อย่างไรก็ตามนี่คือสิ่งที่เกิดขึ้น ระบบปลั๊กอินและการกำจัดการพึ่งพา Azure ให้มูลค่าเพิ่มเติมแก่ลูกค้ารายอื่น (สวัสดี Federal Law 152)

ที่มา: will.com