วิศวกร 4 คน เซิร์ฟเวอร์ 7000 เครื่อง และการระบาดทั่วโลกหนึ่งครั้ง

เฮ้ ฮับ! ฉันขอเสนอการแปลบทความให้คุณทราบ "วิศวกร 4 คน เซิร์ฟเวอร์ 7000 เครื่อง และการแพร่ระบาดทั่วโลกหนึ่งครั้ง" โดย อดิบ ดาว.

หากพาดหัวข่าวนั้นไม่ทำให้คุณรู้สึกขนลุกเล็กน้อย คุณควรข้ามไปยังย่อหน้าถัดไปหรือเยี่ยมชมหน้าเว็บของเราที่ทุ่มเทให้กับ อาชีพในบริษัท - เราอยากจะพูดคุย

เราคือใคร

เราคือทีมเพนกวิน 4 ตัวที่รักการเขียนโค้ดและทำงานกับฮาร์ดแวร์ ในเวลาว่าง เรามีหน้าที่รับผิดชอบในการปรับใช้ บำรุงรักษา และปฏิบัติการกลุ่มเซิร์ฟเวอร์จริงมากกว่า 7000 เครื่องที่ใช้ Linux ซึ่งกระจายอยู่ในศูนย์ข้อมูล 3 แห่งทั่วสหรัฐอเมริกา

นอกจากนี้เรายังมีโอกาสทำสิ่งนี้ห่างจากสถานที่ 10 กม. จากสำนักงานของเราเอง ซึ่งอยู่ห่างจากชายหาดในทะเลเมดิเตอร์เรเนียนโดยใช้เวลาขับรถไม่นาน

ปัญหาเรื่องขนาด

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

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

เชี่ยวชาญโดเมนของคุณ

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

การใช้แนวทางนี้ช่วยให้เราแก้ไขปัญหาต่างๆ ได้อย่างถูกต้อง โดยการสร้างเครื่องมือและระบบอัตโนมัติ

ต้องการโดเมน

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

• ความสามารถในการปรับแต่งมุมมองของเฉพาะสาขาที่เกี่ยวข้อง (แบบง่าย)
• Open APIs (ขยายได้)
• รู้จักกับทีมงานเรา(เข้าใจแล้ว)
• บูรณาการกับขั้นตอนการทำงานที่มีอยู่ของเรา (แบบครบวงจร)

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

กระดานคัมบังในจิระ

นอกจากนี้ ความจริงที่ว่าตอนนี้ทุกคนมองเห็นคิวและลำดับความสำคัญได้ ทำให้สามารถเข้าใจคำขอนั้นๆ ว่า "อยู่ที่ไหนในคิว" และอะไรอยู่ข้างหน้าคำขอนั้น ซึ่งช่วยให้เจ้าของจัดลำดับความสำคัญคำขอของตนเองใหม่ได้โดยไม่ต้องติดต่อเรา ลากไปก็เท่านั้นเอง นอกจากนี้ยังช่วยให้เราสามารถตรวจสอบและประเมิน SLA ของเราตามประเภทคำขอตามตัวชี้วัดที่สร้างขึ้นใน Jira

โดเมนวงจรการใช้งานอุปกรณ์

ลองจินตนาการถึงความซับซ้อนในการจัดการฮาร์ดแวร์ที่ใช้ในแร็คเซิร์ฟเวอร์แต่ละอัน ที่แย่ไปกว่านั้นคือสามารถย้ายฮาร์ดแวร์ (RAM, ROM) หลายชิ้นจากคลังสินค้าไปยังห้องเซิร์ฟเวอร์และด้านหลังได้ นอกจากนี้ยังล้มเหลวหรือถูกตัดออกและเปลี่ยนใหม่แล้วส่งคืนให้กับซัพพลายเออร์เพื่อทำการเปลี่ยน/ซ่อมแซม ทั้งหมดนี้จะต้องสื่อสารไปยังพนักงานบริการโคโลเคชั่นที่เกี่ยวข้องกับการบำรุงรักษาทางกายภาพของอุปกรณ์ เพื่อแก้ไขปัญหาเหล่านี้ เราได้สร้างเครื่องมือภายในที่เรียกว่า Floppy หน้าที่ของเขาคือ:

• การจัดการการสื่อสารกับบุคลากรภาคสนาม การรวบรวมข้อมูลทั้งหมด
• การอัปเดตข้อมูล "คลังสินค้า" หลังจากงานบำรุงรักษาอุปกรณ์ที่เสร็จสมบูรณ์และตรวจสอบแล้วแต่ละครั้ง

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

แผงควบคุมอุปกรณ์คลังสินค้าใน Grafana

สำหรับอุปกรณ์เซิร์ฟเวอร์ที่อยู่ภายใต้การรับประกัน เราจะใช้เครื่องมืออื่นที่เราเรียกว่า Dispatcher เขา:

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

เมื่อการเรียกร้องของเราได้รับการยอมรับ (โดยปกติภายในเวลาทำการ) อะไหล่จะถูกส่งไปยังศูนย์ข้อมูลที่เหมาะสมและพนักงานจะยอมรับ

เอาต์พุตคอนโซลเจนกินส์

โดเมนการสื่อสาร

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

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

• ความเรียบง่าย
• เอกราช;
• ประสิทธิภาพ;
• ความเชื่อถือได้

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

เพื่อให้บรรลุเป้าหมายนี้ เราได้ติดตั้ง iPad ไว้ในศูนย์ข้อมูลทุกแห่ง หลังจากเชื่อมต่อกับเซิร์ฟเวอร์แล้ว สิ่งต่อไปนี้จะเกิดขึ้น:

• อุปกรณ์ยืนยันว่าเซิร์ฟเวอร์นี้ต้องการการทำงานบางอย่างจริงๆ
• แอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์ถูกปิด (ถ้าจำเป็น)
• ชุดคำแนะนำการทำงานถูกโพสต์บนช่องทาง Slack เพื่ออธิบายขั้นตอนที่จำเป็น
• เมื่อเสร็จสิ้นการทำงาน อุปกรณ์จะตรวจสอบความถูกต้องของสถานะสุดท้ายของเซิร์ฟเวอร์
• รีสตาร์ทแอปพลิเคชันหากจำเป็น

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

iPad ในศูนย์ข้อมูลแห่งหนึ่งของเรา

โดเมนฮาร์ดแวร์

การปรับขนาดโครงสร้างพื้นฐานศูนย์ข้อมูลของเราได้อย่างน่าเชื่อถือนั้นจำเป็นต้องมีการมองเห็นที่ดีในแต่ละส่วนประกอบ เช่น:

• การตรวจจับความล้มเหลวของฮาร์ดแวร์
• สถานะเซิร์ฟเวอร์ (ใช้งานอยู่ โฮสต์ ซอมบี้ ฯลฯ)
• การใช้พลังงาน
• เวอร์ชันเฟิร์มแวร์
• การวิเคราะห์สำหรับธุรกิจทั้งหมดนี้

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

แดชบอร์ดพลังงานใน Grafana

และแล้วโรคโควิด-19 ก็ปรากฏขึ้น...

ทีมงานของเราสร้างเทคโนโลยีที่เสริมศักยภาพบริษัทสื่อและผู้เผยแพร่ออนไลน์ เพื่อช่วยให้ผู้เยี่ยมชมค้นหาเนื้อหา ผลิตภัณฑ์ และบริการที่เกี่ยวข้องซึ่งพวกเขาอาจสนใจ โครงสร้างพื้นฐานของเราได้รับการออกแบบเพื่อรองรับการรับส่งข้อมูลที่เกิดจากการเผยแพร่ข่าวที่น่าตื่นเต้น

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

แต่อย่างที่เราพูดไป แบบจำลองของเราสันนิษฐานแล้วว่า:

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

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

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

เดิม: tyts

ที่มา: will.com