สวัสดีทุกคน ฉันชื่อ Sergey Emelyanchik ฉันเป็นหัวหน้าของบริษัท Audit-Telecom ซึ่งเป็นผู้พัฒนาหลักและเป็นผู้เขียนระบบ Veliam ฉันตัดสินใจเขียนบทความเกี่ยวกับวิธีที่ฉันกับเพื่อนสร้างบริษัทเอาท์ซอร์ส เขียนซอฟต์แวร์สำหรับตัวเราเอง และต่อมาก็เริ่มแจกจ่ายให้ทุกคนผ่านระบบ SaaS ฉันไม่เชื่อว่าสิ่งนี้เป็นไปได้อย่างเด็ดขาด บทความนี้ไม่เพียงแต่จะประกอบด้วยเรื่องราวเท่านั้น แต่ยังรวมถึงรายละเอียดทางเทคนิคเกี่ยวกับวิธีการสร้างผลิตภัณฑ์ Veliam อีกด้วย รวมถึงซอร์สโค้ดบางส่วน ฉันจะบอกคุณว่าเราทำผิดพลาดอะไรและเราแก้ไขอย่างไรในภายหลัง มีข้อสงสัยว่าจะเผยแพร่บทความดังกล่าวหรือไม่ แต่ผมว่าทำแล้วรับคำติชมและปรับปรุงดีกว่าไม่ลงบทความแล้วคิดดูว่าจะเกิดอะไรขึ้นถ้า...
ประวัติศาสตร์
ฉันทำงานในบริษัทแห่งหนึ่งในตำแหน่งพนักงานไอที บริษัทมีขนาดค่อนข้างใหญ่และมีโครงสร้างเครือข่ายที่กว้างขวาง ฉันจะไม่ยึดติดกับความรับผิดชอบในงานของฉัน ฉันจะบอกแค่ว่าพวกเขาไม่ได้รวมการพัฒนาอะไรไว้อย่างแน่นอน
เรามีการติดตาม แต่เพื่อประโยชน์ทางวิชาการล้วนๆ ฉันจึงอยากลองเขียนสิ่งที่ง่ายที่สุดของตัวเองขึ้นมา แนวคิดก็คือ: ฉันอยากให้มันอยู่บนเว็บ เพื่อที่ฉันจะสามารถเข้าไปได้อย่างง่ายดายโดยไม่ต้องติดตั้งไคลเอนต์ใดๆ และดูว่าเกิดอะไรขึ้นกับเครือข่ายจากอุปกรณ์ใดๆ รวมถึงอุปกรณ์มือถือผ่าน Wi-Fi และฉันก็จริงๆ ด้วย อยากเข้าใจอย่างรวดเร็วว่าอะไร มีอุปกรณ์ในห้องที่กลายเป็น “มอมแมม” เพราะ... มีข้อกำหนดที่เข้มงวดมากสำหรับเวลาตอบสนองต่อปัญหาดังกล่าว เป็นผลให้ฉันมีแผนที่จะเขียนหน้าเว็บง่ายๆ ซึ่งมีพื้นหลัง jpeg พร้อมไดอะแกรมเครือข่าย ตัดอุปกรณ์ออกด้วยที่อยู่ IP ในภาพนี้ และแสดงเนื้อหาแบบไดนามิกที่ด้านบนของ รูปภาพในพิกัดที่ต้องการในรูปแบบของที่อยู่ IP สีเขียวหรือสีแดงกะพริบ ภารกิจได้รับการตั้งค่าแล้ว มาเริ่มกันเลย
ก่อนหน้านี้ ฉันกำลังเขียนโปรแกรมใน Delphi, PHP, JS และ C++ แบบผิวเผินมาก ฉันรู้ค่อนข้างดีว่าเครือข่ายทำงานอย่างไร VLAN, การกำหนดเส้นทาง (OSPF, EIGRP, BGP), NAT แค่นี้ก็เพียงพอแล้วสำหรับฉันที่จะเขียนต้นแบบการตรวจสอบเบื้องต้นด้วยตัวเอง
ฉันเขียนสิ่งที่ฉันวางแผนไว้ใน PHP เซิร์ฟเวอร์ Apache และ PHP ใช้งานบน Windows เพราะ... Linux สำหรับฉันในขณะนั้นเป็นสิ่งที่เข้าใจไม่ได้และซับซ้อนมากเมื่อปรากฏในภายหลังฉันเข้าใจผิดมากและในหลาย ๆ ที่ Linux นั้นง่ายกว่า Windows มาก แต่นี่เป็นหัวข้อแยกต่างหากและเราทุกคนรู้ว่ามีโฮลิวาร์อยู่กี่ตัว หัวข้อนี้. ตัวกำหนดเวลางานของ Windows ดึงช่วงเวลาเล็ก ๆ (ฉันจำไม่ได้แน่ชัด แต่ประมาณทุกๆสามวินาที) สคริปต์ PHP ที่สำรวจวัตถุทั้งหมดด้วย ping ซ้ำ ๆ และบันทึกสถานะลงในไฟล์
system(“ping -n 3 -w 100 {$ip_address}“);
ใช่ ใช่ การทำงานกับฐานข้อมูลในขณะนั้นยังไม่เชี่ยวชาญสำหรับฉันเช่นกัน ฉันไม่รู้ว่ามันเป็นไปได้ที่จะทำให้กระบวนการขนานกัน และการผ่านโหนดเครือข่ายทั้งหมดใช้เวลานาน เพราะ... สิ่งนี้เกิดขึ้นในกระทู้เดียว ปัญหาเกิดขึ้นเมื่อหลายโหนดไม่พร้อมใช้งานเนื่องจาก แต่ละคนหน่วงเวลาสคริปต์เป็นเวลา 300 มิลลิวินาที ในฝั่งไคลเอ็นต์มีฟังก์ชันการวนซ้ำอย่างง่ายซึ่งดาวน์โหลดข้อมูลที่อัปเดตจากเซิร์ฟเวอร์ด้วยคำขอ Ajax และอัปเดตอินเทอร์เฟซในช่วงเวลาไม่กี่วินาที จากนั้นหลังจากส่ง Ping ไม่สำเร็จ 3 ครั้งติดต่อกันหากคอมพิวเตอร์เปิดหน้าเว็บที่มีการตรวจสอบองค์ประกอบที่ร่าเริงก็เล่นขึ้น
เมื่อทุกอย่างเรียบร้อยดี ฉันได้รับแรงบันดาลใจจากผลลัพธ์มากและคิดว่าจะเพิ่มอีกได้ (เนื่องจากความรู้และความสามารถของฉัน) แต่ฉันไม่ชอบระบบที่มีแผนภูมินับล้านซึ่งฉันคิดว่าตอนนั้นและยังคงคิดว่าจนถึงทุกวันนี้นั้นไม่จำเป็นในกรณีส่วนใหญ่ ฉันอยากจะใส่เฉพาะสิ่งที่จะช่วยฉันในการทำงานได้จริงๆ หลักการนี้ยังคงเป็นรากฐานของการพัฒนา Veliam มาจนถึงทุกวันนี้ นอกจากนี้ ฉันตระหนักว่ามันคงจะดีมากถ้าฉันไม่ต้องเปิดการตรวจสอบและทราบปัญหา และเมื่อเกิดขึ้น จากนั้นจึงเปิดหน้าเว็บและดูว่าโหนดเครือข่ายที่มีปัญหานี้อยู่ที่ไหน และจะทำอย่างไรกับมันต่อไป . ตอนนั้นฉันไม่ได้อ่านอีเมลเลย ฉันแค่ไม่ได้ใช้มัน ฉันพบบนอินเทอร์เน็ตว่ามีเกตเวย์ SMS ที่คุณสามารถส่งคำขอ GET หรือ POST ได้และพวกเขาจะส่ง SMS ไปยังโทรศัพท์มือถือของฉันพร้อมข้อความที่ฉันเขียน ฉันรู้ทันทีว่าฉันต้องการสิ่งนี้จริงๆ และฉันก็เริ่มศึกษาเอกสาร หลังจากนั้นไม่นานฉันก็ทำสำเร็จ และตอนนี้ฉันได้รับ SMS เกี่ยวกับปัญหาบนเครือข่ายบนโทรศัพท์มือถือของฉันพร้อมชื่อ "วัตถุที่หล่น" แม้ว่าระบบจะดูดั้งเดิม แต่มันก็เขียนโดยฉันเอง และสิ่งที่สำคัญที่สุดที่กระตุ้นให้ฉันพัฒนาก็คือมันเป็นแอพพลิเคชั่นที่ช่วยฉันในการทำงานจริงๆ
และแล้ววันนั้นก็มาถึงเมื่อช่องอินเทอร์เน็ตช่องหนึ่งล่มในที่ทำงานและการเฝ้าดูของฉันไม่ได้แจ้งให้ฉันทราบ เนื่องจาก Google DNS ยังคงส่ง Ping ได้อย่างสมบูรณ์ ถึงเวลาที่ต้องคิดว่าคุณจะติดตามดูว่าช่องทางการสื่อสารยังมีชีวิตอยู่ได้อย่างไร มีแนวคิดที่แตกต่างกันเกี่ยวกับวิธีการทำเช่นนี้ ฉันไม่สามารถเข้าถึงอุปกรณ์ทั้งหมดได้ เราต้องหาวิธีทำความเข้าใจว่าช่องใดถ่ายทอดสด แต่ไม่สามารถรับชมได้บนอุปกรณ์เครือข่ายเอง จากนั้นเพื่อนร่วมงานคนหนึ่งเกิดแนวคิดว่าเป็นไปได้ที่การติดตามเส้นทางไปยังเซิร์ฟเวอร์สาธารณะอาจแตกต่างกันไปขึ้นอยู่กับช่องทางการสื่อสารที่ใช้ในการเข้าถึงอินเทอร์เน็ตในปัจจุบัน ฉันตรวจสอบแล้วและมันก็เป็นอย่างนั้น มีเส้นทางที่แตกต่างกันเมื่อติดตาม
system(“tracert -d -w 500 8.8.8.8”);
ดังนั้นสคริปต์อื่นจึงปรากฏขึ้น หรือด้วยเหตุผลบางอย่าง การติดตามจึงถูกเพิ่มที่ส่วนท้ายของสคริปต์เดียวกัน ซึ่งส่ง Ping อุปกรณ์ทั้งหมดบนเครือข่าย ท้ายที่สุดแล้ว นี่เป็นอีกกระบวนการที่ยาวนานซึ่งดำเนินการในเธรดเดียวกันและทำให้การทำงานของสคริปต์ทั้งหมดช้าลง แต่แล้วมันก็ไม่ได้ชัดเจนนัก แต่ไม่ทางใดก็ทางหนึ่ง เขาทำงานของเขา รหัสกำหนดอย่างเคร่งครัดว่าการติดตามประเภทใดที่ควรเป็นสำหรับแต่ละช่องสัญญาณ นี่คือวิธีที่ระบบเริ่มทำงานซึ่งมีการตรวจสอบแล้ว (พูดดัง ๆ เนื่องจากไม่มีการรวบรวมตัวชี้วัดใด ๆ แต่เป็นเพียงการส่ง Ping) อุปกรณ์เครือข่าย (เราเตอร์สวิตช์ Wi-Fi ฯลฯ ) และช่องทางการสื่อสารกับโลกภายนอก . ข้อความ SMS มาถึงเป็นประจำและแผนภาพแสดงให้เห็นอย่างชัดเจนเสมอว่าปัญหาอยู่ที่ใด
นอกจากนี้ ในการทำงานประจำวันฉันต้องทำการข้ามสาย และฉันก็เบื่อที่จะต้องใช้สวิตช์ของ Cisco ทุกครั้งเพื่อดูว่าควรใช้อินเทอร์เฟซใด จะดีแค่ไหนหากคลิกที่วัตถุในการตรวจสอบและดูรายการอินเทอร์เฟซพร้อมคำอธิบาย มันจะช่วยฉันประหยัดเวลา นอกจากนี้ ในรูปแบบนี้ไม่จำเป็นต้องเรียกใช้ Putty หรือ SecureCRT เพื่อป้อนบัญชีและคำสั่ง ฉันเพียงแค่คลิกที่การตรวจสอบ เห็นสิ่งที่จำเป็นและไปทำงานของฉัน ฉันเริ่มมองหาวิธีโต้ตอบกับสวิตช์ ฉันเจอ 2 ตัวเลือกทันที: SNMP หรือการเข้าสู่ระบบสวิตช์ผ่าน SSH ป้อนคำสั่งที่ฉันต้องการและแยกวิเคราะห์ผลลัพธ์ ฉันยกเลิก SNMP เนื่องจากความซับซ้อนของการนำไปปฏิบัติ ฉันไม่อดทนที่จะรับผลลัพธ์ ด้วย SNMP คุณจะต้องเจาะลึก MIB เป็นเวลานาน และสร้างข้อมูลเกี่ยวกับอินเทอร์เฟซตามข้อมูลนี้ มีทีมงานที่ยอดเยี่ยมที่ CISCO
show interface statusมันแสดงให้เห็นอย่างชัดเจนถึงสิ่งที่ฉันต้องการสำหรับการครอสโอเวอร์ ทำไมต้องกังวลกับ SNMP ในเมื่อฉันแค่อยากเห็นผลลัพธ์ของคำสั่งนี้ ฉันคิดว่า หลังจากนั้นไม่นานฉันก็ตระหนักถึงโอกาสนี้ คลิกบนวัตถุบนหน้าเว็บ เหตุการณ์ถูกกระตุ้นโดยไคลเอนต์ AJAX ติดต่อเซิร์ฟเวอร์ และในทางกลับกัน เชื่อมต่อผ่าน SSH ไปยังสวิตช์ที่ฉันต้องการ (ข้อมูลรับรองถูกฮาร์ดโค้ดเป็นโค้ด ไม่ต้องการปรับแต่ง เพื่อสร้างเมนูแยกกันที่ มันเป็นไปได้ที่จะเปลี่ยนบัญชีจากอินเทอร์เฟซ ฉันต้องการผลลัพธ์และรวดเร็ว) ฉันป้อนคำสั่งด้านบนที่นั่นและส่งกลับไปที่เบราว์เซอร์ ดังนั้นฉันจึงเริ่มเห็นข้อมูลเกี่ยวกับอินเทอร์เฟซด้วยการคลิกเมาส์เพียงครั้งเดียว วิธีนี้สะดวกมาก โดยเฉพาะอย่างยิ่งเมื่อคุณต้องดูข้อมูลนี้บนสวิตช์ต่างๆ ในคราวเดียว
การติดตามช่องสัญญาณแบบติดตามผลกลับไม่ใช่แนวคิดที่ดีที่สุด เพราะ... บางครั้งงานก็ดำเนินการบนเครือข่ายและการติดตามอาจเปลี่ยนแปลงได้และการเฝ้าติดตามเริ่มกรีดร้องที่ฉันว่ามีปัญหากับช่อง แต่หลังจากใช้เวลามากมายในการวิเคราะห์ ฉันก็พบว่าทุกช่องทางใช้งานได้ และการเฝ้าติดตามของฉันก็หลอกลวงฉัน ด้วยเหตุนี้ ฉันจึงขอให้เพื่อนร่วมงานที่จัดการสวิตช์สร้างช่องให้ส่งบันทึกระบบมาให้ฉันเมื่อสถานะการมองเห็นของเพื่อนบ้านเปลี่ยนไป ด้วยเหตุนี้ จึงง่ายกว่า เร็วกว่า และแม่นยำกว่าการติดตามมาก เหตุการณ์เหมือนเพื่อนบ้านหายมาถึงแล้ว และผมจะแจ้งเตือนเรื่องช่องล่มทันที
นอกจากนี้ ยังมีคำสั่งอีกหลายคำปรากฏขึ้นเมื่อคลิกที่ออบเจ็กต์ และมีการเพิ่ม SNMP เพื่อรวบรวมเมตริกบางอย่าง และโดยพื้นฐานแล้วก็คือเป็นเช่นนั้น ระบบไม่เคยพัฒนาต่อไป มันทำทุกอย่างที่ฉันต้องการ มันเป็นเครื่องมือที่ดี ผู้อ่านหลายคนอาจจะบอกฉันว่ามีซอฟต์แวร์มากมายบนอินเทอร์เน็ตที่สามารถแก้ไขปัญหาเหล่านี้ได้ แต่จริงๆ แล้ว ฉันไม่ได้ google ผลิตภัณฑ์ฟรีแบบนั้นในตอนนั้น และฉันต้องการพัฒนาทักษะการเขียนโปรแกรมของฉันจริงๆ และจะมีวิธีใดที่จะผลักดันสิ่งนี้ได้ดีไปกว่าปัญหาแอปพลิเคชันจริง ณ จุดนี้ การตรวจสอบเวอร์ชันแรกเสร็จสมบูรณ์แล้วและไม่มีการแก้ไขอีกต่อไป
ก่อตั้งบริษัทตรวจสอบ-โทรคมนาคม
เมื่อเวลาผ่านไป ฉันเริ่มทำงานพาร์ทไทม์ในบริษัทอื่น โชคดีที่ตารางงานของฉันอนุญาตให้ฉันได้ทำเช่นนี้ เมื่อคุณทำงานในบริษัทต่างๆ ทักษะของคุณในด้านต่างๆ จะเติบโตอย่างรวดเร็ว และขอบเขตอันไกลโพ้นของคุณก็จะพัฒนาไปด้วยดี มีบริษัทหลายแห่งที่คุณเป็นชาวสวีเดน นักเก็บเกี่ยว และนักเล่นทรัมเป็ต ในด้านหนึ่งก็เป็นเรื่องยาก ในทางกลับกัน ถ้าคุณไม่ขี้เกียจ คุณจะกลายเป็นคนทั่วๆ ไป และสิ่งนี้จะทำให้คุณแก้ไขปัญหาได้เร็วและมีประสิทธิภาพมากขึ้น เพราะคุณรู้ว่าสาขาที่เกี่ยวข้องทำงานอย่างไร
พาเวล เพื่อนของฉัน (ซึ่งเป็นผู้เชี่ยวชาญด้านไอทีด้วย) พยายามสนับสนุนให้ฉันเริ่มต้นธุรกิจของตัวเองอยู่ตลอดเวลา มีแนวคิดมากมายนับไม่ถ้วนกับสิ่งที่พวกเขาทำในรูปแบบต่างๆ เรื่องนี้มีการพูดคุยกันมานานหลายปี และสุดท้ายก็ไม่น่าจะเกิดอะไรขึ้นมาได้เพราะฉันเป็นคนขี้ระแวง และพาเวลก็เป็นคนช่างฝัน ทุกครั้งที่เขาเสนอแนวคิด ฉันมักจะไม่เชื่อและปฏิเสธที่จะเข้าร่วม แต่เราอยากจะเปิดธุรกิจของตัวเองจริงๆ
ในที่สุด เราก็สามารถหาตัวเลือกที่เหมาะกับเราทั้งคู่และทำในสิ่งที่เรารู้วิธีทำ ในปี 2016 เราตัดสินใจสร้างบริษัทไอทีที่จะช่วยธุรกิจต่างๆ แก้ปัญหาด้านไอที นี่คือการปรับใช้ระบบไอที (1C, เทอร์มินัลเซิร์ฟเวอร์, เมลเซิร์ฟเวอร์ ฯลฯ) การบำรุงรักษา HelpDesk แบบคลาสสิกสำหรับผู้ใช้และการดูแลเครือข่าย
พูดตรงๆ ตอนที่ก่อตั้งบริษัท ผมไม่เชื่อเรื่องนี้ประมาณ 99,9% แต่อย่างใดพาเวลก็สามารถทำให้ฉันลองได้ และเมื่อมองไปข้างหน้า เขากลับกลายเป็นว่าคิดถูก พาเวลกับฉันชิปคนละ 300 รูเบิล จดทะเบียน LLC ใหม่ "Audit-Telecom" เช่าสำนักงานเล็ก ๆ ทำนามบัตรเจ๋ง ๆ โดยทั่วไปแล้วเหมือนกับนักธุรกิจมือใหม่ที่ไม่มีประสบการณ์ส่วนใหญ่และเริ่มมองหาลูกค้า การหาลูกค้าเป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง บางทีเราอาจเขียนบทความแยกต่างหากโดยเป็นส่วนหนึ่งของบล็อกของบริษัทหากใครสนใจ โทรเย็น ใบปลิว ฯลฯ สิ่งนี้ไม่ได้ให้ผลลัพธ์ใด ๆ เมื่อฉันอ่านเรื่องราวมากมายเกี่ยวกับธุรกิจไม่ทางใดก็ทางหนึ่ง หลายอย่างขึ้นอยู่กับโชค เราโชคดี และสองสามสัปดาห์หลังจากการก่อตั้งบริษัท วลาดิมีร์ น้องชายของฉันก็เข้ามาหาเรา ซึ่งนำลูกค้ารายแรกมาให้เรา ฉันจะไม่ทำให้คุณเบื่อกับรายละเอียดในการทำงานกับลูกค้า นั่นไม่ใช่เรื่องของบทความนี้ ฉันจะบอกว่าเราไปตรวจสอบ ระบุประเด็นสำคัญ และพื้นที่เหล่านี้พังในขณะที่ตัดสินใจว่าจะทำหรือไม่ ร่วมมือกับเราอย่างต่อเนื่องในฐานะบุคคลภายนอก หลังจากนั้นก็มีการตัดสินใจเชิงบวกทันที
จากนั้นส่วนใหญ่ผ่านการบอกต่อผ่านเพื่อน บริษัทบริการอื่น ๆ ก็เริ่มปรากฏตัวขึ้น Helpdesk อยู่ในระบบเดียว การเชื่อมต่อกับอุปกรณ์เครือข่ายและเซิร์ฟเวอร์จะแตกต่างกันหรือค่อนข้างแตกต่างกัน บางคนบันทึกทางลัด บางคนใช้สมุดที่อยู่ RDP การตรวจสอบเป็นอีกระบบหนึ่งที่แยกจากกัน ไม่สะดวกมากสำหรับทีมที่จะทำงานในระบบที่แตกต่างกัน ข้อมูลสำคัญจะสูญหายไปจากการมองเห็น ตัวอย่างเช่น เทอร์มินัลเซิร์ฟเวอร์ของลูกค้าไม่สามารถใช้งานได้ แอปพลิเคชันจากผู้ใช้ไคลเอนต์รายนี้จะได้รับทันที ผู้เชี่ยวชาญด้านการสนับสนุนเปิดคำขอ (ได้รับทางโทรศัพท์) หากมีการลงทะเบียนเหตุการณ์และคำขอไว้ในระบบเดียว ผู้เชี่ยวชาญด้านการสนับสนุนจะทราบทันทีว่าปัญหาของผู้ใช้คืออะไรและแจ้งให้เขาทราบ ขณะเดียวกันก็เชื่อมต่อกับวัตถุที่ต้องการเพื่อแก้ไขสถานการณ์ไปพร้อมๆ กัน ทุกคนตระหนักถึงสถานการณ์ทางยุทธวิธีและทำงานอย่างกลมกลืน เราไม่พบระบบที่รวมทั้งหมดนี้เข้าด้วยกัน เห็นได้ชัดว่าถึงเวลาสร้างผลิตภัณฑ์ของเราเองแล้ว
ทำงานต่อในระบบการตรวจสอบของคุณ
เห็นได้ชัดว่าระบบที่เขียนไว้ก่อนหน้านี้ไม่เหมาะกับงานปัจจุบันโดยสิ้นเชิง ทั้งในแง่ของฟังก์ชันการทำงานหรือในแง่ของคุณภาพ และมีการตัดสินใจที่จะเขียนระบบตั้งแต่เริ่มต้น กราฟิกควรจะดูแตกต่างไปจากเดิมอย่างสิ้นเชิง ต้องเป็นระบบที่มีลำดับชั้นเพื่อให้สามารถเปิดออบเจ็กต์ที่เหมาะสมสำหรับไคลเอนต์ที่เหมาะสมได้อย่างรวดเร็วและสะดวก โครงการในเวอร์ชันแรกนั้นไม่สมเหตุสมผลอย่างแน่นอนในกรณีนี้เพราะว่า ลูกค้ามีความแตกต่างกันและไม่สำคัญว่าอุปกรณ์จะอยู่ที่ใด สิ่งนี้ได้ถูกโอนไปยังเอกสารแล้ว
ดังนั้นภารกิจ:
- โครงสร้างลำดับชั้น
- ส่วนของเซิร์ฟเวอร์บางประเภทที่สามารถวางบนสถานที่ของลูกค้าในรูปแบบของเครื่องเสมือนเพื่อรวบรวมตัวชี้วัดที่เราต้องการและส่งไปยังเซิร์ฟเวอร์กลางซึ่งจะสรุปทั้งหมดนี้และแสดงให้เราเห็น
- การแจ้งเตือน ที่พลาดไม่ได้เพราะ... ในเวลานั้นไม่มีใครสามารถนั่งมองจอภาพได้
- ระบบการสมัคร ลูกค้าเริ่มปรากฏตัวให้เห็นซึ่งเราให้บริการไม่เพียงแต่เซิร์ฟเวอร์และอุปกรณ์เครือข่ายเท่านั้น แต่ยังรวมถึงเวิร์กสเตชันด้วย
- ความสามารถในการเชื่อมต่อกับเซิร์ฟเวอร์และอุปกรณ์จากระบบได้อย่างรวดเร็ว
กำหนดงานแล้วเราเริ่มเขียน ระหว่างทาง ดำเนินการตามคำขอจากลูกค้า ตอนนั้นมีพวกเรากัน 4 คนแล้ว เราเริ่มเขียนทั้งสองส่วนพร้อมกัน: เซิร์ฟเวอร์กลางและเซิร์ฟเวอร์สำหรับการติดตั้งให้กับลูกค้า เมื่อถึงจุดนี้ Linux ก็ไม่ใช่คนแปลกหน้าสำหรับเราอีกต่อไป และมีการตัดสินใจว่าเครื่องเสมือนที่ไคลเอนต์จะมีอยู่บน Debian จะไม่มีตัวติดตั้ง เราจะสร้างโปรเจ็กต์ส่วนของเซิร์ฟเวอร์บนเครื่องเสมือนเครื่องใดเครื่องหนึ่ง จากนั้นเราจะทำการโคลนไปยังไคลเอนต์ที่ต้องการ นี่เป็นข้อผิดพลาดอีกครั้ง ต่อมาเห็นได้ชัดว่าในรูปแบบดังกล่าวกลไกการอัปเดตยังไม่ได้รับการพัฒนาอย่างสมบูรณ์ เหล่านั้น. เรากำลังเพิ่มคุณสมบัติใหม่ และจากนั้นก็มีปัญหาทั้งหมดในการแจกจ่ายไปยังเซิร์ฟเวอร์ไคลเอนต์ทั้งหมด แต่เราจะกลับมาที่สิ่งนี้ในภายหลัง ทุกอย่างตามลำดับ
เราทำต้นแบบแรก เขาสามารถ Ping ไปยังอุปกรณ์เครือข่ายไคลเอ็นต์และเซิร์ฟเวอร์ที่เราต้องการ และส่งข้อมูลนี้ไปยังเซิร์ฟเวอร์กลางของเรา และในทางกลับกัน เขาก็อัปเดตข้อมูลนี้จำนวนมากบนเซิร์ฟเวอร์กลาง ที่นี่ฉันจะเขียนไม่เพียงแต่เรื่องราวเกี่ยวกับวิธีการและสิ่งที่ประสบความสำเร็จเท่านั้น แต่ยังรวมถึงข้อผิดพลาดที่เกิดขึ้นอย่างไม่ชำนาญและฉันต้องจ่ายเงินตามเวลาในภายหลังอย่างไร ดังนั้นแผนผังวัตถุทั้งหมดจึงถูกจัดเก็บไว้ในไฟล์เดียวในรูปแบบของวัตถุต่อเนื่องกัน ในขณะที่เราเชื่อมต่อไคลเอนต์หลายตัวเข้ากับระบบ ทุกอย่างก็ปกติไม่มากก็น้อย แม้ว่าบางครั้งจะมีข้อผิดพลาดบางอย่างที่ไม่สามารถเข้าใจได้โดยสิ้นเชิง แต่เมื่อเราเชื่อมต่อเซิร์ฟเวอร์หลายสิบเครื่องเข้ากับระบบ ปาฏิหาริย์ก็เริ่มเกิดขึ้น บางครั้งวัตถุทั้งหมดในระบบก็หายไปโดยไม่ทราบสาเหตุ สิ่งสำคัญที่ควรทราบในที่นี้ก็คือเซิร์ฟเวอร์ที่ไคลเอ็นต์ส่งข้อมูลไปยังเซิร์ฟเวอร์กลางทุกๆ สองสามวินาทีผ่านการร้องขอ POST ผู้อ่านที่เอาใจใส่และโปรแกรมเมอร์ที่มีประสบการณ์เดาแล้วว่ามีปัญหาในการเข้าถึงไฟล์หลายครั้งซึ่งวัตถุที่ซีเรียลไลซ์ถูกจัดเก็บจากเธรดที่แตกต่างกันในเวลาเดียวกัน และเมื่อสิ่งนี้เกิดขึ้น ปาฏิหาริย์ก็เกิดขึ้นพร้อมกับการหายตัวไปของวัตถุ ไฟล์ก็ว่างเปล่า แต่ทั้งหมดนี้ไม่ได้ถูกค้นพบในทันที แต่เฉพาะระหว่างการดำเนินการกับเซิร์ฟเวอร์หลายเครื่องเท่านั้น ในช่วงเวลานี้ มีการเพิ่มฟังก์ชันการสแกนพอร์ต (เซิร์ฟเวอร์ที่ส่งไปยังส่วนกลางไม่เพียงแต่ข้อมูลเกี่ยวกับความพร้อมใช้งานของอุปกรณ์เท่านั้น แต่ยังเกี่ยวกับพอร์ตที่เปิดอยู่ด้วย) ทำได้โดยการเรียกคำสั่ง:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
ผลลัพธ์มักจะไม่ถูกต้อง และการสแกนใช้เวลานานจึงจะเสร็จสิ้น ฉันลืมเรื่อง ping ไปโดยสิ้นเชิง มันทำได้ผ่าน fping:
system("fping -r 3 -t 100 {$this->ip}");
สิ่งนี้ไม่ขนานกัน ดังนั้นกระบวนการจึงยาวนานมาก ต่อมา รายการที่อยู่ IP ทั้งหมดที่จำเป็นสำหรับการตรวจสอบถูกส่งไปยัง fping ในครั้งเดียว และเราได้รับรายชื่อผู้ที่ตอบกลับเรียบร้อยแล้ว ต่างจากเราที่ fping สามารถขนานกระบวนการต่างๆ ได้
งานประจำทั่วไปอีกอย่างหนึ่งคือการตั้งค่าบริการบางอย่างผ่านทางเว็บ ตัวอย่างเช่น ECP จาก MS Exchange โดยพื้นฐานแล้วมันเป็นเพียงลิงค์ และเราตัดสินใจว่าเราต้องสามารถเพิ่มลิงก์ดังกล่าวลงในระบบได้โดยตรง เพื่อที่จะไม่ต้องดูในเอกสารประกอบหรือที่อื่นในบุ๊กมาร์กเพื่อดูวิธีเข้าถึง ECP ของไคลเอ็นต์เฉพาะ นี่คือลักษณะที่แนวคิดของลิงก์ทรัพยากรสำหรับระบบปรากฏขึ้นฟังก์ชันการทำงานมีให้จนถึงทุกวันนี้และเกือบจะไม่เปลี่ยนแปลงเลย
ลิงก์ทรัพยากรทำงานอย่างไรใน Veliam
การเชื่อมต่อระยะไกล
นี่คือลักษณะการใช้งานจริงใน Veliam เวอร์ชันปัจจุบัน
งานประการหนึ่งคือการเชื่อมต่อกับเซิร์ฟเวอร์อย่างรวดเร็วและสะดวก ซึ่งมีเซิร์ฟเวอร์จำนวนมากอยู่แล้ว (มากกว่าหนึ่งร้อยรายการ) และการจัดเรียงทางลัด RDP ที่บันทึกไว้ล่วงหน้าหลายล้านรายการนั้นไม่สะดวกอย่างยิ่ง จำเป็นต้องมีเครื่องมือ มีซอฟต์แวร์บนอินเทอร์เน็ตที่มีลักษณะคล้ายสมุดที่อยู่สำหรับการเชื่อมต่อ RDP ดังกล่าว แต่ไม่ได้รวมเข้ากับระบบการตรวจสอบ และไม่สามารถบันทึกบัญชีได้ การเข้าสู่บัญชีสำหรับลูกค้าที่แตกต่างกันทุกครั้งถือเป็นนรกอย่างแท้จริงเมื่อคุณเชื่อมต่อหลายสิบครั้งต่อวันกับเซิร์ฟเวอร์ที่แตกต่างกัน เมื่อใช้ SSH สิ่งต่างๆ จะดีขึ้นเล็กน้อย มีซอฟต์แวร์ดีๆ มากมายที่ช่วยให้คุณสามารถจัดระเบียบการเชื่อมต่อดังกล่าวลงในโฟลเดอร์และจดจำบัญชีจากพวกเขาได้ แต่มีอยู่ 2 ปัญหา อย่างแรกคือเราไม่พบโปรแกรมเดียวสำหรับการเชื่อมต่อ RDP และ SSH อย่างที่สองคือหาก ณ จุดหนึ่ง ฉันไม่ได้อยู่ที่คอมพิวเตอร์และต้องการเชื่อมต่ออย่างรวดเร็ว หรือฉันเพิ่งติดตั้งระบบใหม่ ฉันจะต้องเข้าไปดูเอกสารประกอบเพื่อดูบัญชีจากไคลเอนต์รายนี้ มันไม่สะดวกและเสียเวลา
โครงสร้างลำดับชั้นที่เราต้องการสำหรับเซิร์ฟเวอร์ไคลเอนต์มีอยู่แล้วในผลิตภัณฑ์ภายในของเรา ฉันแค่ต้องหาวิธีการเชื่อมต่อที่รวดเร็วเข้ากับอุปกรณ์ที่จำเป็นที่นั่น สำหรับผู้เริ่มต้น อย่างน้อยก็ภายในเครือข่ายของคุณ
โดยคำนึงถึงความจริงที่ว่าไคลเอนต์ในระบบของเราเป็นเบราว์เซอร์ที่ไม่สามารถเข้าถึงทรัพยากรในเครื่องคอมพิวเตอร์ได้ เพื่อที่จะเปิดแอปพลิเคชันที่เราต้องการด้วยคำสั่งบางอย่างมันถูกคิดค้นขึ้นเพื่อทำทุกอย่างผ่าน "Windows รูปแบบ URL ที่กำหนดเอง” นี่คือลักษณะที่ "ปลั๊กอิน" บางตัวปรากฏสำหรับระบบของเรา ซึ่งรวมถึง Putty และ Remote Desktop Plus และเพียงลงทะเบียนโครงร่าง URI ใน Windows ในระหว่างการติดตั้ง ตอนนี้ เมื่อเราต้องการเชื่อมต่อกับอ็อบเจ็กต์ผ่าน RDP หรือ SSH เราก็คลิกการกระทำนี้ในระบบของเรา และ URI ที่กำหนดเองก็ใช้งานได้ mstsc.exe มาตรฐานที่สร้างไว้ใน Windows หรือสีโป๊วซึ่งเป็นส่วนหนึ่งของ "ปลั๊กอิน" ได้รับการเปิดตัว ฉันใส่คำว่าปลั๊กอินในเครื่องหมายคำพูดเพราะนี่ไม่ใช่ปลั๊กอินของเบราว์เซอร์ในแง่คลาสสิก
อย่างน้อยนั่นก็เป็นอะไรบางอย่าง สมุดที่อยู่ที่สะดวก ยิ่งไปกว่านั้น ในกรณีของ Putty ทุกอย่างปกติดี โดยสามารถให้การเชื่อมต่อ IP การเข้าสู่ระบบ และรหัสผ่านเป็นพารามิเตอร์อินพุต เหล่านั้น. เราได้เชื่อมต่อกับเซิร์ฟเวอร์ Linux บนเครือข่ายของเราแล้วด้วยคลิกเดียวโดยไม่ต้องป้อนรหัสผ่าน แต่ด้วย RDP มันไม่ง่ายขนาดนั้น mstsc มาตรฐานไม่สามารถระบุข้อมูลรับรองเป็นพารามิเตอร์ได้ Remote Desktop Plus มาช่วยเหลือแล้ว เขายอมให้สิ่งนี้เกิดขึ้น ตอนนี้เราทำได้โดยไม่ต้องใช้มัน แต่เป็นเวลานานแล้วที่มันเป็นผู้ช่วยที่ซื่อสัตย์ในระบบของเรา ด้วยไซต์ HTTP(S) ทุกอย่างจะง่ายดาย ออบเจ็กต์ดังกล่าวเพียงแค่เปิดในเบราว์เซอร์ เท่านี้ก็เรียบร้อย สะดวกและใช้งานได้จริง แต่นี่คือความสุขบนเครือข่ายภายในเท่านั้น
เนื่องจากเราได้แก้ไขปัญหาส่วนใหญ่จากระยะไกลจากสำนักงาน สิ่งที่ง่ายที่สุดคือการทำให้ลูกค้าสามารถใช้ VPN ได้ จากนั้นจึงสามารถเชื่อมต่อกับพวกเขาจากระบบของเราได้ แต่ก็ยังไม่สะดวกอยู่บ้าง สำหรับไคลเอนต์แต่ละราย จำเป็นต้องเก็บการเชื่อมต่อ VPN จำนวนมากไว้ในคอมพิวเตอร์แต่ละเครื่อง และก่อนที่จะเชื่อมต่อกับใดๆ จำเป็นต้องเปิดใช้งาน VPN ที่เกี่ยวข้อง เราใช้วิธีนี้มาเป็นเวลานานแล้ว แต่จำนวนไคลเอนต์เพิ่มขึ้น จำนวน VPN ก็เพิ่มขึ้นเช่นกัน และทั้งหมดนี้เริ่มตึงเครียดและต้องทำอะไรบางอย่างเกี่ยวกับเรื่องนี้ ฉันน้ำตาไหลเป็นพิเศษหลังจากติดตั้งระบบใหม่ เมื่อฉันต้องเข้าสู่การเชื่อมต่อ VPN หลายสิบครั้งในโปรไฟล์ Windows ใหม่ ฉันพูดหยุดทนกับสิ่งนี้และเริ่มคิดว่าฉันจะทำอะไรได้บ้าง
มันเกิดขึ้นที่ไคลเอนต์ทั้งหมดมีอุปกรณ์จากบริษัท Mikrotik ที่มีชื่อเสียงเป็นเราเตอร์ พวกมันมีประโยชน์ใช้สอยมากและสะดวกสำหรับการทำงานเกือบทุกงาน ข้อเสียคือพวกเขาถูก "แย่งชิง" เราแก้ไขปัญหานี้ได้ง่ายๆ ด้วยการปิดการเข้าถึงทั้งหมดจากภายนอก แต่จำเป็นต้องเข้าถึงพวกเขาโดยไม่ต้องมาถึงที่ของลูกค้า เพราะ... มันยาว. เราเพียงแค่สร้างอุโมงค์สำหรับ Mikrotik แต่ละตัวและแยกออกเป็นสระน้ำแยกต่างหาก โดยไม่มีการกำหนดเส้นทางใด ๆ เพื่อไม่ให้มีการเชื่อมต่อเครือข่ายของคุณกับเครือข่ายของลูกค้าและเครือข่ายของพวกเขาระหว่างกัน
แนวคิดนี้เกิดขึ้นเพื่อให้แน่ใจว่าเมื่อฉันคลิกที่ออบเจ็กต์ที่ฉันต้องการในระบบ เซิร์ฟเวอร์การตรวจสอบส่วนกลาง ซึ่งทราบบัญชี SSH ของไคลเอนต์ Mikrotik ทั้งหมด เชื่อมต่อกับอันที่ต้องการ สร้างกฎการส่งต่อไปยังโฮสต์ที่ต้องการด้วย พอร์ตที่จำเป็น มีหลายจุดที่นี่ วิธีแก้ปัญหาไม่เป็นสากล - จะใช้ได้กับ Mikrotik เท่านั้นเนื่องจากไวยากรณ์คำสั่งแตกต่างกันสำหรับเราเตอร์ทั้งหมด นอกจากนี้ การส่งต่อดังกล่าวจะต้องถูกลบออก และส่วนเซิร์ฟเวอร์ของระบบของเราไม่สามารถติดตามได้ในทางใดทางหนึ่งว่าฉันได้เสร็จสิ้นเซสชั่น RDP ของฉันแล้วหรือไม่ การส่งต่อดังกล่าวเป็นช่องโหว่สำหรับลูกค้า แต่เราไม่ได้แสวงหาความเป็นสากลเพราะ... ผลิตภัณฑ์นี้ถูกใช้ภายในบริษัทของเราเท่านั้นและไม่มีความคิดที่จะเผยแพร่สู่สาธารณะ
แต่ละปัญหาได้รับการแก้ไขด้วยวิธีของตัวเอง เมื่อกฎถูกสร้างขึ้น การส่งต่อนี้จะพร้อมใช้งานสำหรับที่อยู่ IP ภายนอกหนึ่งรายการเท่านั้น (ซึ่งเริ่มต้นการเชื่อมต่อ) ดังนั้นจึงหลีกเลี่ยงช่องโหว่ด้านความปลอดภัย แต่ด้วยการเชื่อมต่อแต่ละครั้ง กฎ Mikrotik ได้ถูกเพิ่มในหน้า NAT และไม่ได้รับการล้าง และทุกคนรู้ดีว่ายิ่งมีกฎเกณฑ์มากเท่าใด ตัวประมวลผลของเราเตอร์ก็จะยิ่งโหลดมากขึ้นเท่านั้น และโดยทั่วไปแล้ว ฉันไม่สามารถยอมรับได้ว่าวันหนึ่งฉันจะไปซื้อ Mikrotik และจะมีกฎตายๆ นับร้อยที่ไร้ประโยชน์
เนื่องจากเซิร์ฟเวอร์ของเราไม่สามารถติดตามสถานะการเชื่อมต่อได้ ให้ Mikrotik ติดตามสถานะการเชื่อมต่อด้วยตนเอง และฉันเขียนสคริปต์ที่ตรวจสอบกฎการส่งต่อทั้งหมดอย่างต่อเนื่องพร้อมคำอธิบายเฉพาะ และตรวจสอบว่าการเชื่อมต่อ TCP มีกฎที่เหมาะสมหรือไม่ หากไม่มีมาระยะหนึ่งแล้ว แสดงว่าการเชื่อมต่ออาจเสร็จสมบูรณ์แล้วและสามารถลบการส่งต่อนี้ได้ ทุกอย่างเป็นไปด้วยดี บทก็ทำงานได้ดี
โดยวิธีการนี่คือ:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
แน่นอนว่ามันสามารถทำให้สวยงามขึ้น เร็วขึ้น และอื่นๆ ได้ แต่มันก็ใช้งานได้ ไม่ได้โหลด Mikrotik และทำงานได้ยอดเยี่ยมมาก ในที่สุดเราก็สามารถเชื่อมต่อกับเซิร์ฟเวอร์และอุปกรณ์เครือข่ายของลูกค้าได้ด้วยการคลิกเพียงครั้งเดียว โดยไม่ต้องเปิด VPN หรือป้อนรหัสผ่าน ระบบนี้สะดวกต่อการทำงานมาก เวลาในการให้บริการลดลง และเราทุกคนใช้เวลาทำงานแทนที่จะเชื่อมต่อกับวัตถุที่จำเป็น
การสำรองข้อมูลไมโครติก
เรากำหนดค่าการสำรองข้อมูล Mikrotik ทั้งหมดเป็น FTP และโดยรวมแล้วทุกอย่างก็ดี แต่เมื่อคุณต้องการสำรองข้อมูล คุณต้องเปิด FTP นี้และมองหามันที่นั่น เรามีระบบที่เชื่อมต่อเราเตอร์ทั้งหมดเราสามารถสื่อสารกับอุปกรณ์ผ่าน SSH ทำไมเราไม่สร้างมันขึ้นมาเพื่อให้ระบบทำการสำรองข้อมูลจาก Mikrotik ทั้งหมดทุกวัน ฉันคิดว่า และเขาก็เริ่มนำไปปฏิบัติ เราเชื่อมต่อ สำรองข้อมูล และนำไปจัดเก็บ
รหัสสคริปต์ใน PHP สำหรับการสำรองข้อมูลจาก Mikrotik:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
การสำรองข้อมูลจะดำเนินการในสองรูปแบบ - การกำหนดค่าไบนารีและข้อความ ไบนารี่ช่วยในการกู้คืนการกำหนดค่าที่จำเป็นอย่างรวดเร็ว และข้อความหนึ่งช่วยให้คุณเข้าใจสิ่งที่ต้องทำหากมีการบังคับให้เปลี่ยนอุปกรณ์และไม่สามารถอัปโหลดไบนารี่ได้ เป็นผลให้เราได้รับฟังก์ชันอื่นที่สะดวกสบายในระบบ ยิ่งไปกว่านั้น เมื่อเพิ่ม Mikrotik ใหม่ ไม่จำเป็นต้องกำหนดค่าใดๆ ฉันเพียงเพิ่ม object เข้ากับระบบและตั้งค่าบัญชีสำหรับมันผ่าน SSH จากนั้นระบบจะดูแลการสำรองข้อมูลเอง SaaS Veliam เวอร์ชันปัจจุบันยังไม่มีฟังก์ชันนี้ แต่เราจะพอร์ตฟังก์ชันนี้เร็วๆ นี้
ภาพหน้าจอของสิ่งที่ดูเหมือนในระบบภายใน
การเปลี่ยนไปใช้การจัดเก็บฐานข้อมูลปกติ
ฉันได้เขียนไปแล้วข้างต้นว่าสิ่งประดิษฐ์ปรากฏขึ้น บางครั้งรายการออบเจ็กต์ทั้งหมดในระบบก็หายไป บางครั้งเมื่อแก้ไขออบเจ็กต์ ข้อมูลจะไม่ได้รับการบันทึกและต้องเปลี่ยนชื่อออบเจ็กต์สามครั้ง สิ่งนี้ทำให้ทุกคนหงุดหงิดอย่างมาก การหายไปของวัตถุนั้นเกิดขึ้นน้อยมากและสามารถกู้คืนได้อย่างง่ายดายโดยการกู้คืนไฟล์นี้ แต่ความล้มเหลวในการแก้ไขวัตถุนั้นเกิดขึ้นค่อนข้างบ่อย อาจเป็นไปได้ว่าในตอนแรกฉันไม่ได้ทำสิ่งนี้ผ่านฐานข้อมูลเพราะมันไม่สอดคล้องกับความคิดของฉันว่าเป็นไปได้อย่างไรที่จะเก็บต้นไม้ที่มีการเชื่อมต่อทั้งหมดไว้บนโต๊ะแบน มันแบน แต่ต้นไม้มีลำดับชั้น แต่ทางออกที่ดีสำหรับการเข้าถึงหลายรายการ และการทำธุรกรรมในภายหลัง (เมื่อระบบมีความซับซ้อนมากขึ้น) ก็คือ DBMS ฉันอาจไม่ใช่คนแรกที่พบปัญหานี้ ฉันเริ่มกูเกิ้ล ปรากฎว่าทุกอย่างถูกประดิษฐ์ขึ้นต่อหน้าฉันแล้วและมีอัลกอริธึมหลายอย่างที่สร้างต้นไม้จากโต๊ะแบน หลังจากดูแต่ละรายการแล้ว ฉันจึงนำหนึ่งในนั้นไปใช้ แต่นี่เป็นระบบเวอร์ชั่นใหม่อยู่แล้ว เพราะ... อันที่จริงด้วยเหตุนี้ฉันจึงต้องเขียนใหม่ค่อนข้างมาก ผลลัพธ์เป็นไปตามธรรมชาติ ปัญหาพฤติกรรมสุ่มของระบบหมดไป บางคนอาจบอกว่าข้อผิดพลาดนั้นไม่ชำนาญมากนัก (สคริปต์แบบเธรดเดียว การจัดเก็บข้อมูลที่มีการเข้าถึงหลายครั้งพร้อมกันจากเธรดที่แตกต่างกันในไฟล์ ฯลฯ) ในด้านการพัฒนาซอฟต์แวร์ บางทีนี่อาจเป็นเรื่องจริง แต่งานหลักของฉันคือการบริหาร และการเขียนโปรแกรมเป็นความเร่งรีบด้านข้างสำหรับจิตวิญญาณของฉัน และฉันก็ไม่มีประสบการณ์ในการทำงานในทีมโปรแกรมเมอร์ ซึ่งสิ่งพื้นฐานดังกล่าวจะได้รับการแนะนำโดยรุ่นพี่ของฉันทันที สหาย ดังนั้นฉันจึงเติมเต็มสิ่งเหล่านี้ด้วยตัวเอง แต่ฉันเรียนรู้เนื้อหาได้ดีมาก นอกจากนี้ งานของฉันยังเกี่ยวข้องกับการพบปะกับลูกค้า การกระทำที่มุ่งส่งเสริมบริษัท ปัญหาด้านการบริหารภายในบริษัท และอื่นๆ อีกมากมาย แต่ไม่ทางใดก็ทางหนึ่งสิ่งที่มีอยู่แล้วก็เป็นที่ต้องการ พวกผมและตัวผมเองใช้ผลิตภัณฑ์นี้ในการทำงานประจำวันของเรา มีความคิดและวิธีแก้ปัญหาที่ไม่ประสบความสำเร็จอย่างตรงไปตรงมาซึ่งทำให้เสียเวลา แต่ท้ายที่สุดก็ชัดเจนว่านี่ไม่ใช่เครื่องมือที่ใช้งานได้และไม่มีใครใช้มัน และไม่ได้จบลงที่ Veliam
ฝ่ายช่วยเหลือ - ฝ่ายช่วยเหลือ
คงไม่ผิดที่จะพูดถึงว่า HelpDesk เกิดขึ้นได้อย่างไร นี่เป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง เพราะ... ใน Veliam นี่เป็นเวอร์ชันใหม่ลำดับที่ 3 แล้ว ซึ่งแตกต่างจากเวอร์ชันก่อนหน้าทั้งหมด ตอนนี้มันเป็นระบบที่เรียบง่าย ใช้งานง่าย โดยไม่ต้องยุ่งยากใดๆ ด้วยความสามารถในการบูรณาการกับโดเมน เช่นเดียวกับความสามารถในการเข้าถึงโปรไฟล์ผู้ใช้เดียวกันได้จากทุกที่โดยใช้ลิงก์จากอีเมล และที่สำคัญที่สุดคือสามารถเชื่อมต่อกับผู้สมัครผ่าน VNC ได้จากทุกที่ (ที่บ้านหรือที่ทำงาน) ได้โดยตรงจากแอปพลิเคชันโดยไม่ต้องใช้ VPN หรือการส่งต่อพอร์ต ฉันจะบอกคุณว่าเรามาถึงสิ่งนี้ได้อย่างไร เกิดอะไรขึ้นก่อนหน้านี้ และมีการตัดสินใจที่เลวร้ายอะไรบ้าง
เราเชื่อมต่อกับผู้ใช้ผ่าน TeamViewer ที่รู้จักกันดี คอมพิวเตอร์ทุกเครื่องที่เราให้บริการแก่ผู้ใช้มีทีวีติดตั้งอยู่ สิ่งแรกที่เราทำผิด และลบออกในเวลาต่อมา คือการเชื่อมโยงไคลเอนต์ HD แต่ละตัวเข้ากับฮาร์ดแวร์ ผู้ใช้เข้าสู่ระบบ HD เพื่อส่งคำขออย่างไร นอกจากทีวีแล้ว ทุกคนยังมียูทิลิตี้พิเศษติดตั้งอยู่ในคอมพิวเตอร์ ซึ่งเขียนด้วยภาษาลาซารัส (หลายๆ คนที่นี่คงกลอกตา และอาจเข้า Google ด้วยซ้ำว่าคืออะไร แต่ภาษาที่เรียบเรียงที่ดีที่สุดที่ฉันรู้จักคือเดลฟี และลาซารัสเกือบจะเป็นภาษาที่เรียบเรียงดีที่สุด สิ่งเดียวกันฟรีเท่านั้น) โดยทั่วไป ผู้ใช้เปิดตัวไฟล์แบตช์พิเศษที่เรียกใช้ยูทิลิตี้นี้ ซึ่งจะอ่าน HWID ของระบบ และหลังจากนั้นเบราว์เซอร์ก็ถูกเปิดใช้งานและมีการอนุญาตเกิดขึ้น เหตุใดจึงทำเช่นนี้? ในบางบริษัท จำนวนผู้ใช้บริการจะถูกนับแยกกัน และราคาบริการในแต่ละเดือนจะขึ้นอยู่กับจำนวนคน คุณพูดแบบนี้เข้าใจได้ แต่ทำไมมันถึงเชื่อมโยงกับฮาร์ดแวร์? ง่ายมาก มีบางคนกลับมาบ้านและขอจากแล็ปท็อปที่บ้านในรูปแบบ "ทำทุกสิ่งให้สวยงามสำหรับฉันที่นี่" นอกเหนือจากการอ่าน HWID ของระบบแล้ว ยูทิลิตี้นี้ยังดึง Teamviewer ID ปัจจุบันจากรีจิสทรีและส่งให้เราด้วย Teamviewer มี API สำหรับการรวมระบบ และเราได้บูรณาการนี้ แต่มีสิ่งหนึ่งที่จับได้ ผ่าน API เหล่านี้ เป็นไปไม่ได้ที่จะเชื่อมต่อกับคอมพิวเตอร์ของผู้ใช้ เมื่อเขาไม่ได้เริ่มเซสชันนี้อย่างชัดเจน และหลังจากพยายามเชื่อมต่อแล้ว เขาจะต้องคลิก "ยืนยัน" ด้วย ในเวลานั้น มันดูสมเหตุสมผลสำหรับเราที่ไม่มีใครควรเชื่อมต่อโดยไม่ได้รับคำขอจากผู้ใช้ และเนื่องจากบุคคลนั้นอยู่ที่คอมพิวเตอร์ เขาจึงจะเริ่มเซสชันและตอบกลับอย่างยืนยันต่อคำขอเชื่อมต่อระยะไกล ทุกอย่างกลายเป็นผิด ผู้สมัครลืมกดเปิดเซสชั่น และต้องบอกเรื่องนี้ในการสนทนาทางโทรศัพท์ สิ่งนี้ทำให้เสียเวลาและน่าหงุดหงิดทั้งสองฝ่ายของกระบวนการ ยิ่งไปกว่านั้นไม่ใช่เรื่องแปลกเลยสำหรับช่วงเวลาที่บุคคลออกจากคำขอ แต่จะได้รับอนุญาตให้เชื่อมต่อเฉพาะเมื่อเขาออกไปรับประทานอาหารกลางวันเท่านั้น เพราะปัญหาไม่ได้ร้ายแรงและไม่อยากให้กระบวนการทำงานหยุดชะงัก ดังนั้นเขาจะไม่กดปุ่มใดๆ เพื่ออนุญาตการเชื่อมต่อ นี่คือลักษณะที่ฟังก์ชันเพิ่มเติมปรากฏขึ้นเมื่อเข้าสู่ระบบ HelpDesk - อ่าน ID ของ Teamviwer เรารู้รหัสผ่านถาวรที่ใช้ในการติดตั้ง Teamviwer แม่นยำยิ่งขึ้น มีเพียงระบบเท่านั้นที่รู้ เนื่องจากมันถูกสร้างไว้ในตัวติดตั้งและในระบบของเรา ดังนั้นจึงมีปุ่มเชื่อมต่อจากแอปพลิเคชันโดยคลิกซึ่งไม่จำเป็นต้องรออะไร แต่ Teamviewer เปิดขึ้นทันทีและมีการเชื่อมต่อเกิดขึ้น เป็นผลให้มีการเชื่อมต่อที่เป็นไปได้สองประเภท ผ่าน Teamviewer API อย่างเป็นทางการและที่เราสร้างขึ้นเอง ฉันประหลาดใจที่พวกเขาหยุดใช้อันแรกเกือบจะในทันที แม้ว่าจะมีคำแนะนำให้ใช้ในกรณีพิเศษเท่านั้นและเมื่อผู้ใช้เองให้ดำเนินการต่อ ถึงกระนั้น ให้ความปลอดภัยแก่ฉันตอนนี้เลย แต่กลับกลายเป็นว่าผู้สมัครไม่ต้องการสิ่งนี้ ทั้งหมดนี้ใช้งานได้ดีเมื่อเชื่อมต่อโดยไม่ต้องมีปุ่มยืนยัน
สลับไปใช้มัลติเธรดใน Linux
คำถามของการเร่งความเร็วของเครื่องสแกนเครือข่ายเพื่อเปิดรายการพอร์ตที่กำหนดไว้ล่วงหน้าและการกระตุกของวัตถุเครือข่ายอย่างง่ายได้เริ่มเกิดขึ้นมานานแล้ว แน่นอนว่าวิธีแก้ปัญหาแรกที่นึกถึงคือการทำงานแบบมัลติเธรด เนื่องจากเวลาหลักที่ใช้ในการ ping คือการรอให้แพ็กเก็ตส่งคืน และการ ping ถัดไปไม่สามารถเริ่มต้นได้จนกว่าจะส่งคืนแพ็กเก็ตก่อนหน้า ในบริษัทที่มีเซิร์ฟเวอร์มากกว่า 20 เครื่องพร้อมอุปกรณ์เครือข่าย สิ่งนี้จึงทำงานได้ค่อนข้างช้า ประเด็นก็คือแพ็คเกจหนึ่งอาจหายไป แต่อย่าแจ้งให้ผู้ดูแลระบบทราบทันที เขาจะหยุดรับสแปมดังกล่าวอย่างรวดเร็ว ซึ่งหมายความว่าคุณต้อง ping แต่ละออบเจ็กต์มากกว่าหนึ่งครั้งก่อนที่จะสรุปเกี่ยวกับการไม่สามารถเข้าถึงได้ จำเป็นต้องทำแบบขนานโดยไม่ต้องลงรายละเอียดมากเกินไป เพราะหากไม่เสร็จสิ้น ผู้ดูแลระบบส่วนใหญ่จะเรียนรู้เกี่ยวกับปัญหาจากไคลเอนต์ ไม่ใช่จากระบบการตรวจสอบ
PHP เองไม่รองรับมัลติเธรดทันที สามารถประมวลผลหลายตัวได้ คุณสามารถแยกได้ แต่ในความเป็นจริง ฉันมีกลไกการโพลที่เขียนไว้แล้ว และฉันต้องการสร้างมันเพื่อที่ฉันจะได้นับโหนดทั้งหมดที่ฉันต้องการจากฐานข้อมูล ping ทุกอย่างในคราวเดียว รอการตอบกลับจากแต่ละรายการ และหลังจากนั้นเท่านั้น เขียนทันที ข้อมูล. ซึ่งจะช่วยประหยัดจำนวนคำขออ่าน มัลติเธรดเข้ากันได้อย่างลงตัวกับแนวคิดนี้ สำหรับ PHP มีโมดูล PThreads ที่ให้คุณทำมัลติเธรดได้จริง แม้ว่าจะต้องใช้เวลาแก้ไขพอสมควรในการตั้งค่านี้บน PHP 7.2 แต่ก็เสร็จสิ้นแล้ว การสแกนพอร์ตและ ping ทำได้รวดเร็วแล้ว และแทนที่จะทำ 15 วินาทีต่อรอบก่อนหน้านี้ กระบวนการนี้เริ่มใช้เวลา 2 วินาที มันเป็นผลลัพธ์ที่ดี
การตรวจสอบอย่างรวดเร็วของบริษัทใหม่
ฟังก์ชั่นการรวบรวมตัววัดและคุณลักษณะฮาร์ดแวร์ต่างๆ เกิดขึ้นได้อย่างไร มันง่ายมาก บางครั้งเราเพียงได้รับคำสั่งให้ตรวจสอบโครงสร้างพื้นฐานด้านไอทีในปัจจุบัน สิ่งเดียวกันนี้เป็นสิ่งจำเป็นเพื่อเร่งการตรวจสอบลูกค้าใหม่ เราต้องการบางสิ่งบางอย่างที่จะช่วยให้เราทำงานในบริษัทขนาดกลางหรือขนาดใหญ่ และทราบได้อย่างรวดเร็วว่าพวกเขามีอะไรบ้าง ในความคิดของฉัน ping บนเครือข่ายภายในถูกบล็อกโดยผู้ที่ต้องการทำให้ชีวิตของตัวเองซับซ้อนเท่านั้นและจากประสบการณ์ของเรามีเพียงไม่กี่คนเท่านั้น แต่ก็มีคนแบบนี้เช่นกัน ดังนั้นคุณจึงสามารถสแกนเครือข่ายเพื่อดูอุปกรณ์ที่มีอยู่ได้อย่างรวดเร็วด้วยการ ping ง่ายๆ จากนั้นเราก็สามารถเพิ่มและสแกนหาพอร์ตที่เปิดอยู่ที่เราสนใจได้ ในความเป็นจริงฟังก์ชันนี้มีอยู่แล้ว จำเป็นต้องเพิ่มคำสั่งจากเซิร์ฟเวอร์กลางไปยังเซิร์ฟเวอร์สลาฟเท่านั้นเพื่อที่จะสแกนเครือข่ายที่ระบุและเพิ่มทุกอย่างที่พบในรายการ ฉันลืมบอกไป สันนิษฐานว่าเรามีอิมเมจสำเร็จรูปพร้อมระบบที่กำหนดค่าไว้แล้ว (เซิร์ฟเวอร์ตรวจสอบสเลฟ) ซึ่งเราสามารถเผยแพร่จากไคลเอนต์ระหว่างการตรวจสอบและเชื่อมต่อกับคลาวด์ของเรา
แต่ผลลัพธ์ของการตรวจสอบมักจะรวมข้อมูลที่แตกต่างกันจำนวนมาก และหนึ่งในนั้นคืออุปกรณ์ประเภทใดที่อยู่บนเครือข่าย ก่อนอื่น เราสนใจเซิร์ฟเวอร์ Windows และเวิร์กสเตชัน Windows ซึ่งเป็นส่วนหนึ่งของโดเมน เนื่องจากในบริษัทขนาดกลางและขนาดใหญ่ การไม่มีโดเมนอาจเป็นข้อยกเว้นของกฎนี้ ในความคิดของฉันการพูดภาษาเดียวโดยเฉลี่ยคือ 100+ คน จำเป็นต้องมีวิธีรวบรวมข้อมูลจากเครื่อง Windows และเซิร์ฟเวอร์ทั้งหมด โดยทราบ IP และบัญชีผู้ดูแลระบบโดเมนของตน แต่ไม่ต้องติดตั้งซอฟต์แวร์ใดๆ ในแต่ละเครื่อง อินเทอร์เฟซ WMI มาช่วยเหลือ Windows Management Instrumentation (WMI) หมายถึงเครื่องมือการจัดการ Windows อย่างแท้จริง WMI เป็นหนึ่งในเทคโนโลยีพื้นฐานสำหรับการจัดการแบบรวมศูนย์และการตรวจสอบการทำงานของส่วนต่าง ๆ ของโครงสร้างพื้นฐานคอมพิวเตอร์ที่ใช้แพลตฟอร์ม Windows เอามาจากวิกิ. ต่อไปฉันต้องคนจรจัดอีกครั้งเพื่อคอมไพล์ wmic (นี่คือไคลเอนต์ WMI) สำหรับ Debian หลังจากที่ทุกอย่างพร้อมแล้ว สิ่งที่เหลืออยู่ก็แค่สำรวจโหนดที่จำเป็นผ่าน wmic เพื่อหาข้อมูลที่จำเป็น ผ่าน WMI คุณสามารถรับข้อมูลเกือบทุกชนิดจากคอมพิวเตอร์ Windows และยิ่งไปกว่านั้น คุณยังสามารถควบคุมคอมพิวเตอร์ผ่านข้อมูลนั้นได้ เช่น ส่งไปรีบูต นี่คือลักษณะการรวบรวมข้อมูลเกี่ยวกับสถานี Windows และเซิร์ฟเวอร์ในระบบของเรา นอกจากนี้ ยังมีข้อมูลปัจจุบันเกี่ยวกับตัวบ่งชี้โหลดระบบในปัจจุบัน เราขอบ่อยขึ้นและข้อมูลเกี่ยวกับฮาร์ดแวร์ไม่บ่อยนัก หลังจากนั้น การตรวจสอบก็สนุกขึ้นอีกหน่อย
การตัดสินใจจำหน่ายซอฟต์แวร์
เราใช้ระบบนี้ทุกวัน และเปิดให้พนักงานด้านเทคนิคทุกคนเสมอ และเราคิดว่าเราสามารถแบ่งปันสิ่งที่เรามีอยู่แล้วให้ผู้อื่นได้ ระบบยังไม่พร้อมจำหน่าย ต้องทำใหม่หลายอย่างเพื่อให้เวอร์ชันท้องถิ่นกลายเป็น SaaS ซึ่งรวมถึงการเปลี่ยนแปลงด้านเทคนิคต่างๆ ของระบบ (การเชื่อมต่อระยะไกล บริการสนับสนุน) การวิเคราะห์โมดูลสำหรับการอนุญาต การแบ่งส่วนฐานข้อมูลลูกค้า การปรับขนาดของแต่ละบริการ และการพัฒนาระบบอัปเดตอัตโนมัติสำหรับทุกส่วน แต่นี่จะเป็นส่วนที่สองของบทความ
บันทึก
ที่มา: will.com