
เครือข่ายทั่วโลกของ Cloudflare ครอบคลุมมากกว่า 310 เมืองในกว่า 120 ประเทศ นั่นหมายถึงเซิร์ฟเวอร์หลายพันเครื่องกระจายทางภูมิศาสตร์ไปตามศูนย์ข้อมูลต่างๆ โดยให้บริการที่ปกป้องและเร่งความเร็วแอปพลิเคชันอินเทอร์เน็ตของลูกค้าของเรา การใช้งานฮาร์ดแวร์ในระดับดังกล่าวหมายความว่าฮาร์ดแวร์สามารถเสียหายได้ทุกที่และทุกเวลา ในกรณีเช่นนี้ ระบบของเราได้รับการออกแบบทางวิศวกรรมเพื่อให้ความล้มเหลวเหล่านี้ส่งผลกระทบเพียงเล็กน้อยหรือไม่มีเลย อย่างไรก็ตาม การตรวจจับและจัดการความล้มเหลวของ
เซิร์ฟเวอร์ในวงกว้างต้องใช้ระบบอัตโนมัติ บล็อกนี้มีจุดมุ่งหมายเพื่อให้ข้อมูลเชิงลึกเกี่ยวกับปัญหาที่เกี่ยวข้องกับการจัดการเซิร์ฟเวอร์ที่เสียหาย และวิธีที่เราสามารถทำให้กระบวนการง่ายขึ้นผ่านระบบอัตโนมัติความท้าทายในการจัดการกับเซิร์ฟเวอร์ที่เสียหาย
เมื่อพบว่าเซิร์ฟเวอร์มีฮาร์ดแวร์ที่ชำรุดและจำเป็นต้องถอดออกจากการใช้งานจริง จะถือว่าเซิร์ฟเวอร์เสียหายและสถานะของเซิร์ฟเวอร์จะถูกตั้งค่าเป็นซ่อมแซมในฐานข้อมูลภายในที่มีการติดตามสถานะของเซิร์ฟเวอร์ ในอดีต ทีมปฏิบัติการศูนย์ข้อมูลของเรามีหน้าที่แก้ไขปัญหาและวินิจฉัยเซิร์ฟเวอร์ที่เสียหายด้วยตนเอง พวกเขาต้องผ่านงานที่ต้องใช้ความพยายามมาก เช่น ดำเนินการค้นหาเพื่อค้นหาและซ่อมแซมเซิร์ฟเวอร์ ดำเนินการวินิจฉัย ตรวจสอบผลลัพธ์ ประเมินว่าเซิร์ฟเวอร์สามารถคืนค่าเป็นการใช้งานจริงได้หรือไม่ และการสร้างตั๋วที่จำเป็นสำหรับการเปิดใช้งานเซิร์ฟเวอร์อีกครั้งและการดำเนินการเพื่อนำกลับมาใช้ใหม่ การผลิต. ความพยายามดังกล่าวอาจใช้เวลาหลายชั่วโมงสำหรับเซิร์ฟเวอร์เพียงเครื่องเดียว และอาจใช้เวลาทั้งวันของวิศวกรในการซ่อมเเซม
อย่างที่คุณเห็น การจัดการกับการซ่อมแซมเซิร์ฟเวอร์เป็นกระบวนการที่ต้องใช้แรงงานคนมาก ซึ่งดำเนินการด้วยตนเอง นอกจากนี้ เซิร์ฟเวอร์จำนวนมากเหล่านี้ยังคงเปิดเครื่องอยู่ในแร็ค ทำให้สิ้นเปลืองพลังงาน เนื่องจากฟลีตของเราขยายตัวอย่างรวดเร็ว การดำเนินการของศูนย์ข้อมูลจึงมุ่งเน้นไปที่การสนับสนุนการเติบโตนี้เป็นหลัก โดยเหลือเวลาน้อยลงในการจัดการเซิร์ฟเวอร์ที่ต้องการการซ่อมแซม
เห็นได้ชัดว่าโครงสร้างพื้นฐานของเราเติบโตเร็วเกินไปสำหรับเราที่จะจัดการการซ่อมแซมและการกู้คืนได้ ดังนั้นเราจึงต้องหาวิธีที่ดีกว่าในการจัดการกับความไร้ประสิทธิภาพประเภทนี้ในการดำเนินงานของเรา สิ่งนี้จะช่วยให้วิศวกรของเรามุ่งเน้นไปที่การเติบโตของรอยเท้าของเราในขณะที่ไม่ละทิ้งการซ่อมแซมและการกู้คืน ท้ายที่สุดแล้ว สิ่งเหล่านี้ยังคงเป็นการลงทุน CapEx จำนวนมากและกำลังการผลิตที่สูญเปล่าซึ่งหากไม่เช่นนั้นก็จะถูกนำมาใช้อย่างเต็มที่
การใช้ระบบอัตโนมัติเป็นระบบอัตโนมัติ
ในฐานะสมาชิกของทีมระบบซอฟต์แวร์โครงสร้างพื้นฐานและระบบอัตโนมัติที่ Cloudflare เราทำงานเป็นหลักในการสร้างเครื่องมือและระบบอัตโนมัติที่ช่วยลดงานที่มากเกินไปเพื่อลดแรงกดดันต่อทีมปฏิบัติการของเรา เพิ่มผลผลิต และทำให้ผู้คนสามารถดำเนินการปฏิบัติงานได้อย่างมีประสิทธิภาพสูงสุด
ทีมงานของเราพยายามอย่างต่อเนื่องที่จะท้าทายกระบวนการและระบบที่มีอยู่ของเรา ค้นหาวิธีที่เราสามารถพัฒนาและทำการปรับปรุงที่สำคัญ หนึ่งในนั้นคือการสร้างไม่เพียงแค่ระบบอัตโนมัติทั่วไปเท่านั้น แต่ยังเป็นระบบอัตโนมัติอีกด้วย การสร้างระบบอัตโนมัติอัตโนมัติหมายถึงการสร้างระบบที่สามารถทำงานได้อย่างอิสระ โดยไม่ต้องอาศัยการแทรกแซงหรือการควบคุมดูแลของมนุษย์อย่างต่อเนื่อง ตัวอย่างที่สมบูรณ์แบบของสิ่งนี้คือ Phoenix
แนะนำPhoenix
Phoenix คือระบบอัตโนมัติในการวินิจฉัยและการกู้คืนอัตโนมัติที่ทำงานในช่วงเวลาสม่ำเสมอเพื่อค้นหาศูนย์ข้อมูล Cloudflare ที่มีเซิร์ฟเวอร์ที่ใช้งานไม่ได้ ทำการวินิจฉัยเมื่อตรวจพบ กู้คืนศูนย์ที่ผ่านการวินิจฉัยโดยการจัดเตรียมใหม่ และเปิดใช้งานศูนย์ที่ดำเนินการสำเร็จอีกครั้งในท้ายที่สุด -จัดเตรียมด้วยวิธีที่ปลอดภัยที่สุดและไม่เป็นการรบกวนมากที่สุดเท่าที่จะเป็นไปได้ โดยไม่จำเป็นต้องมีการแทรกแซงจากมนุษย์! หากเซิร์ฟเวอร์ล้มเหลว ณ จุดใดก็ตามในกระบวนการ Phoenix จะดูแลการอัปเดตตั๋วที่เกี่ยวข้อง แม้กระทั่งการระบุสาเหตุของความล้มเหลว และคืนสถานะของเซิร์ฟเวอร์ตามที่จำเป็นเมื่อจำเป็น อีกครั้ง ทั้งหมดนี้โดยไม่ต้องมีการแทรกแซงของมนุษย์!
ภาพด้านล่างแสดงให้เห็นถึงกระบวนการทั้งหมด:
เพื่อทำความเข้าใจวิธีการทำงานของ Phoenix ให้ดียิ่งขึ้น เรามาเจาะลึกรายละเอียดเกี่ยวกับฟังก์ชันการทำงานหลักของมันกันดีกว่า
การค้นพบ
Discovery จะทำงานในช่วงเวลาปกติที่ 30 นาที โดยเลือกศูนย์ข้อมูล Cloudflare สูงสุดสองแห่งที่เสียหายหรือซ่อมแซมเซิร์ฟเวอร์สถานะในฟลีต ซึ่งสามารถกำหนดค่าทั้งหมดได้ขึ้นอยู่กับความต้องการทางธุรกิจและการดำเนินงาน โดยที่จะดำเนินการวินิจฉัยได้ทันที ในอัตรานี้ Phoenix สามารถค้นพบและดำเนินการบนเซิร์ฟเวอร์ที่ใช้งานไม่ได้ทั้งหมดในฟลีตได้ภายในเวลาประมาณ 3 วัน ในแต่ละรัน ยังตรวจจับศูนย์ข้อมูลที่อาจมีเซิร์ฟเวอร์ที่ใช้งานไม่ได้ซึ่งอยู่ในคิวการกู้คืนอยู่แล้ว และดูแลให้แน่ใจว่าขั้นตอนการกู้คืนจะดำเนินการทันที
การวินิจฉัย
การวินิจฉัยจะดูแลการดำเนินการทดสอบต่างๆ ในเซิร์ฟเวอร์ที่ใช้งานไม่ได้ของศูนย์ข้อมูลที่เลือกในการรันครั้งเดียว ตรวจสอบความมีชีวิตของส่วนประกอบฮาร์ดแวร์ และระบุตัวเลือกสำหรับการกู้คืน
การดำเนินการวินิจฉัยรวมถึงการรันสิ่งต่อไปนี้:
- การตรวจสอบการเชื่อมต่อนอกแบนด์ การตรวจสอบนี้จะกำหนดความสามารถในการเข้าถึงของอุปกรณ์ผ่านเครือข่ายนอกย่านความถี่ เราใช้ IPMI (อินเทอร์เฟซการจัดการแพลตฟอร์มอัจฉริยะ) เพื่อให้มั่นใจถึงการเชื่อมต่อทางกายภาพที่เหมาะสมและการเข้าถึงอุปกรณ์ ช่วยให้สามารถตรวจสอบและจัดการส่วนประกอบฮาร์ดแวร์ได้อย่างมีประสิทธิภาพ เพิ่มความน่าเชื่อถือและประสิทธิภาพของระบบโดยรวม เฉพาะอุปกรณ์ที่ผ่านการตรวจสอบนี้เท่านั้นที่สามารถเข้าสู่ขั้นตอนการทดสอบการยอมรับโหนดได้ การทดสอบการยอมรับโหนด เราใช้ประโยชน์จากเครื่องมือที่สร้างขึ้นภายในที่มีอยู่ที่เรียกว่า INAT (การทดสอบการยอมรับโหนดแบบรวม) ซึ่งรันชุด/กรณีการทดสอบต่างๆ (การตรวจสอบฮาร์ดแวร์ ประสิทธิภาพ ฯลฯ)
-
การทดสอบการยอมรับโหนด เราใช้ประโยชน์จากเครื่องมือที่สร้างขึ้นภายในที่มีอยู่ที่เรียกว่า INAT (การทดสอบการยอมรับโหนดแบบรวม) ซึ่งรันชุด/กรณีการทดสอบต่างๆ (การตรวจสอบฮาร์ดแวร์ ประสิทธิภาพ ฯลฯ)
สำหรับเซิร์ฟเวอร์ทุกเครื่องที่จำเป็นต้องได้รับการวินิจฉัย Phoenix จะส่งคำสั่งระบบที่เกี่ยวข้องเพื่อให้เซิร์ฟเวอร์บูตเข้าสู่อิมเมจสำหรับบูต Linux แบบกำหนดเอง ซึ่งเรียกภายในว่า INAT-image ที่สร้างไว้ในอิมเมจนี้คือการทดสอบต่างๆ ที่จำเป็นต้องรันเมื่อเซิร์ฟเวอร์บูทขึ้น โดยเผยแพร่ผลลัพธ์ไปยังทรัพยากรภายในทั้งในรูปแบบที่มนุษย์อ่านได้ (HTML) และรูปแบบที่เครื่องอ่านได้ (JSON) โดยรูปแบบหลังถูกใช้และตีความโดย Phoenix . เมื่อเสร็จสิ้นการวินิจฉัยการบูต เซิร์ฟเวอร์จะถูกปิดอีกครั้งเพื่อให้แน่ใจว่าจะไม่สิ้นเปลืองพลังงาน
การทดสอบการยอมรับโหนดของเราครอบคลุมการประเมินต่างๆ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการทดสอบเกณฑ์มาตรฐาน การตรวจสอบ CPU/หน่วยความจำ/ที่เก็บข้อมูล การล้างข้อมูลไดรฟ์ และการประเมินอื่นๆ อีกมากมาย มองหาโพสต์บล็อกเชิงลึกเกี่ยวกับ INAT ที่กำลังจะมีขึ้นเร็วๆ นี้
ผลการวินิจฉัยโดยสรุปจะถูกเพิ่มลงในตั๋วติดตามทันที รวมถึงการระบุสาเหตุที่แท้จริงของความล้มเหลว
การกู้คืน
การกู้คืนจะดำเนินการในสิ่งที่เราเรียกว่าการดำเนินการขยาย ซึ่งในระยะแรกจะจัดเตรียมเซิร์ฟเวอร์ที่ผ่านการวินิจฉัย ระยะที่สองคือการเปิดใช้งานเซิร์ฟเวอร์ที่จัดเตรียมเรียบร้อยแล้วกลับไปสู่การใช้งานจริงอีกครั้ง โดยมีเพียงเซิร์ฟเวอร์ที่เปิดใช้งานอีกครั้งได้สำเร็จเท่านั้นที่จะเริ่มรับปริมาณการใช้งานจริงอีกครั้ง
เมื่อผ่านการวินิจฉัยและเซิร์ฟเวอร์ที่ใช้งานไม่ได้จะเข้าสู่ขั้นตอนแรกของการกู้คืน เราจะเปลี่ยนสถานะจากการซ่อมแซมเป็นการเตรียมใช้งานที่รอดำเนินการ หากเซิร์ฟเวอร์กู้คืนได้ไม่เต็มที่ เช่น เนื่องจากมีข้อผิดพลาดในการกำหนดค่าเซิร์ฟเวอร์หรือปัญหาในการให้บริการ Phoenix จะประเมินสถานการณ์ ในกรณีเช่นนี้ จะส่งคืนเซิร์ฟเวอร์เหล่านั้นเป็นสถานะการซ่อมแซมสำหรับการประเมินเพิ่มเติม นอกจากนี้ หากการวินิจฉัยระบุว่าเซิร์ฟเวอร์จำเป็นต้องเปลี่ยนส่วนประกอบที่มีข้อบกพร่อง Phoenix จะแจ้งทีมปฏิบัติการศูนย์ข้อมูลของเราเพื่อซ่อมแซมด้วยตนเองตามที่จำเป็น เพื่อให้แน่ใจว่าเซิร์ฟเวอร์จะไม่ถูกเลือกซ้ำๆ จนกว่าการเปลี่ยนชิ้นส่วนที่จำเป็นจะเสร็จสมบูรณ์ สิ่งนี้ทำให้มั่นใจได้ว่าการแทรกแซงของมนุษย์ที่จำเป็นสามารถนำไปใช้ได้ทันที ทำให้เซิร์ฟเวอร์พร้อมสำหรับ Phoenix เพื่อค้นพบอีกครั้งในการทำซ้ำครั้งถัดไป
การดำเนินการกู้คืนอัตโนมัติจำเป็นต้องผสมผสานความชาญฉลาดเข้ากับระบบอัตโนมัติ เพื่อให้เราวางใจได้อย่างเต็มที่ว่าสามารถดำเนินการขยายขนาดในวิธีที่ปลอดภัยที่สุดเท่าที่จะเป็นไปได้ และจัดการกับสถานการณ์ได้ด้วยตัวเองโดยไม่ต้องมีการแทรกแซงจากมนุษย์ ในการทำเช่นนี้ เราได้ทำให้แน่ใจว่า Phoenix ตระหนักถึงระบบอัตโนมัติ ซึ่งหมายความว่าระบบจะรู้เมื่อมีระบบอัตโนมัติอื่นๆ ที่ดำเนินการบางอย่าง เช่น การขยาย และจะดำเนินการขยายเฉพาะเมื่อไม่มีการดำเนินการจัดเตรียมอย่างต่อเนื่องในศูนย์ข้อมูลเป้าหมาย . ความสามารถในการดำเนินการเฉพาะเมื่อทำได้อย่างปลอดภัยเท่านั้นเพื่อให้แน่ใจว่าการดำเนินการกู้คืนจะไม่รบกวนการดำเนินการอื่นๆ ที่กำลังดำเนินอยู่ในศูนย์ข้อมูล นอกจากนี้เรายังได้ปรับความทนทานต่อฮาร์ดแวร์ที่มีข้อบกพร่อง ซึ่งหมายความว่าสามารถจัดการกับเซิร์ฟเวอร์ที่ทำงานผิดปกติได้อย่างสวยงาม โดยปล่อยให้เซิร์ฟเวอร์เหล่านี้หลุดออกจากรายชื่อตัวเลือกการกู้คืนอย่างรวดเร็วเมื่อมีพฤติกรรมไม่เหมาะสมที่ป้องกันการบล็อกการดำเนินการ
ทัศนวิสัย
แม้ว่าระบบอัตโนมัติของเรา Phoenix จะจัดการการดำเนินงานได้อย่างราบรื่นโดยไม่ต้องมีการแทรกแซงจากมนุษย์ แต่ก็ไม่ได้หมายความว่าเราต้องเสียสละความสามารถในการมองเห็น ความโปร่งใสเป็นคุณลักษณะสำคัญของฟีนิกซ์ โดยจะบันทึกทุกการดำเนินการอย่างพิถีพิถัน ตั้งแต่การดำเนินงานไปจนถึงการอัปเดตความคืบหน้า และแบ่งปันข้อมูลนี้ในช่องทางการสื่อสาร เช่น ห้องสนทนาและตั๋ว Jira สิ่งนี้ทำให้มั่นใจได้ถึงความเข้าใจที่ชัดเจนเกี่ยวกับสิ่งที่ Phoenix กำลังทำอยู่ตลอดเวลา
การติดตามการดำเนินการที่ทำโดยระบบอัตโนมัติตลอดจนการเปลี่ยนสถานะของเซิร์ฟเวอร์ช่วยให้เราไม่พลาดและช่วยให้เราเข้าใจได้ดีขึ้นว่าการกระทำเหล่านี้คืออะไรและเมื่อใดที่ดำเนินการ โดยพื้นฐานแล้วทำให้เราได้รับข้อมูลเชิงลึกอันมีค่าซึ่งจะช่วยเราปรับปรุงไม่เพียงแต่ ระบบแต่กระบวนการของเราก็เช่นกัน การมีข้อมูลการดำเนินงานช่วยให้เราสามารถสร้างแดชบอร์ดที่ช่วยให้ทีมต่างๆ ตรวจสอบกิจกรรมการทำงานอัตโนมัติและวัดความสำเร็จของพวกเขาได้ เราสามารถสร้างแดชบอร์ดเพื่อเป็นแนวทางในการตัดสินใจทางธุรกิจ และแม้แต่ตอบคำถามด้านการปฏิบัติงานทั่วไปที่เกี่ยวข้องกับการซ่อมแซมและการกู้คืน
การสร้างสมดุลระหว่างระบบอัตโนมัติและการเอาใจใส่: ข้อผิดพลาดด้านงบประมาณ
เมื่อเราเปิดตัว Phoenix เราทราบดีว่าไม่ใช่ทุกเซิร์ฟเวอร์ที่เสียหายจะสามารถเปิดใช้งานอีกครั้งและกลับสู่การใช้งานจริงได้สำเร็จ และที่สำคัญกว่านั้น ไม่มีการรับประกัน 100% ว่าเซิร์ฟเวอร์ที่กู้คืนมาจะมีเสถียรภาพเท่ากับเซิร์ฟเวอร์ที่ไม่มีประวัติการซ่อมแซม – มีความเสี่ยงที่เซิร์ฟเวอร์เหล่านี้อาจล้มเหลวและกลับมาอยู่ในสถานะการซ่อมแซมอีกครั้ง
แม้ว่าจะไม่มีการรับประกันว่าเซิร์ฟเวอร์ที่กู้คืนเหล่านี้จะไม่ล้มเหลวอีกครั้ง ทำให้เกิดการทำงานเพิ่มเติมสำหรับ SRE เนื่องจากการแจ้งเตือนการตรวจสอบที่ถูกทริกเกอร์ สิ่งที่เรารับประกันได้ก็คือ Phoenix จะหยุดการกู้คืนทันทีโดยไม่มีการแทรกแซงของมนุษย์ หากมีความล้มเหลวจำนวนหนึ่งสำหรับ ถึงเซิร์ฟเวอร์ภายในกรอบเวลาที่กำหนด – นี่คือจุดที่เราใช้แนวคิดเรื่อง Error Budget
Error Budget คือจำนวนข้อผิดพลาดที่ระบบอัตโนมัติสามารถสะสมในช่วงเวลาหนึ่งก่อนที่ SRE ของเราจะเริ่มต้นไม่พึงพอใจเนื่องจากเซิร์ฟเวอร์ขัดข้องมากเกินไปหรือระบบไม่น่าเชื่อถือ มันเป็นความเห็นอกเห็นใจที่ฝังอยู่ในระบบอัตโนมัติ
ในรูปด้านบน แกน y แสดงถึงข้อผิดพลาดที่ถือว่ารับได้ ในบริบทนี้ ข้อผิดพลาดที่ถือว่ารับได้นำไปใช้กับจำนวนเซิร์ฟเวอร์ที่กู้คืนที่ล้มเหลว และถูกย้ายกลับไปยังสถานะการซ่อมแซมอีกครั้ง แกน x แสดงถึงหน่วยเวลาที่จัดสรรให้กับข้อผิดพลาดที่ถือว่ารับได้ – ในกรณีนี้คือ 24 ชั่วโมง เพื่อให้แน่ใจว่า Phoenix เข้มงวดเพียงพอในการบรรเทาปัญหาที่อาจเกิดขึ้น เราแบ่งหน่วยเวลาออกเป็นสามกลุ่มติดต่อกันในช่วงเวลาเดียวกัน ซึ่งเป็นตัวแทนของการเปลี่ยนแปลง SRE “ตามดวงอาทิตย์” สามครั้งในหนึ่งวัน ด้วยเหตุนี้ Phoenix จึงสามารถดำเนินการกู้คืนได้หากจำนวนความล้มเหลวของเซิร์ฟเวอร์ไม่เกิน 2 เท่านั้น นอกจากนี้ Phoenix จะต้องชดเชยบัคเก็ตเวลาที่ดำเนินการสำเร็จด้วยการหักงบประมาณข้อผิดพลาดของความล้มเหลวส่วนเกินใดๆ ในบัคเก็ตเวลาที่กำหนด
Phoenix จะหยุดการกู้คืนทันทีหากใช้ข้อผิดพลาดที่ถือว่ารับได้หมดก่อนเวลาอันควร ในบริบทนี้ ก่อนกำหนด หมายถึง ก่อนสิ้นสุดหน่วยเวลาที่ได้รับข้อผิดพลาดที่ถือว่ารับได้ โดยไม่คำนึงถึงอัตราการสูญเสียงบประมาณข้อผิดพลาดภายในหน่วยเวลา ข้อผิดพลาดที่ถือว่าครบกำหนดจะถูกเติมเต็มที่จุดเริ่มต้นของแต่ละหน่วยเวลา ซึ่งหมายความว่างบประมาณจะถูกรีเซ็ตทุกวัน
Error Budget ช่วยเรากำหนดและจัดการความทนทานต่อความล้มเหลวของฮาร์ดแวร์โดยไม่ก่อให้เกิดอันตรายร้ายแรงต่อระบบหรือเสียงรบกวนมากเกินไปสำหรับ SRE และให้โอกาสเราปรับปรุงระบบการวินิจฉัยของเรา โดยเป็นแรงจูงใจร่วมกันที่ช่วยให้ทั้งทีมวิศวกรรมโครงสร้างพื้นฐานและ SRE มุ่งเน้นไปที่การค้นหาสมดุลที่เหมาะสมระหว่างนวัตกรรมและความน่าเชื่อถือ
เราจะไปไหนกันต่อ
ด้วย Phoenix เราไม่เพียงแต่ได้เห็นถึงศักยภาพที่สำคัญและกว้างขวางของการมีระบบอัตโนมัติอัตโนมัติในโครงสร้างพื้นฐานของเราเท่านั้น แต่เรายังเก็บเกี่ยวผลประโยชน์จากระบบดังกล่าวอีกด้วย ให้สถานการณ์ที่ได้ประโยชน์ทั้งสองฝ่ายด้วยการกู้คืนฮาร์ดแวร์ได้สำเร็จ และรับรองว่าอุปกรณ์ที่เสียหายถูกปิดแล้ว จึงป้องกันไม่ให้อุปกรณ์ใช้พลังงานที่ไม่จำเป็นในขณะที่ไม่ได้ใช้งานในชั้นวางของเรา สิ่งนี้ไม่เพียงช่วยลดการสูญเสียพลังงานเท่านั้น แต่ยังมีส่วนช่วยในการพัฒนาอย่างยั่งยืนและประหยัดต้นทุนอีกด้วย กระบวนการอัตโนมัติที่ทำงานอย่างอิสระไม่เพียงแต่ช่วยให้เพื่อนร่วมงานของเราในทีมโครงสร้างพื้นฐานต่างๆ ทำงานที่ซ้ำซากจำเจเท่านั้น ช่วยให้พวกเขามุ่งเน้นไปที่พื้นที่ที่พวกเขาสามารถใช้ชุดทักษะของตนเพื่องานที่น่าสนใจและมีประสิทธิผลมากขึ้น แต่ยังนำเราไปสู่การพัฒนา กระบวนการเก่าของเราในการจัดการความล้มเหลวและการซ่อมแซมฮาร์ดแวร์ ทำให้เรามีประสิทธิภาพมากขึ้นกว่าเดิมมาก
ระบบอัตโนมัติอัตโนมัติเป็นความจริงที่กำลังเริ่มกำหนดอนาคตของวิธีที่เราสร้างระบบที่ดีขึ้นและชาญฉลาดยิ่งขึ้นที่ Cloudflare และเราจะลงทุนเวลาด้านวิศวกรรมสำหรับโครงการริเริ่มเหล่านี้ต่อไป
ขอขอบคุณ Elvin Tan เป็นอย่างยิ่งสำหรับงานที่ยอดเยี่ยมของเขาใน INAT และถึง Graeme, Darrel และ David สำหรับการปรับปรุงอย่างต่อเนื่องของ INAT
เราปกป้องเครือข่ายองค์กรทั้งหมด ช่วยให้ลูกค้าสร้างแอปพลิเคชันระดับอินเทอร์เน็ตได้อย่างมีประสิทธิภาพ เร่งความเร็วเว็บไซต์หรือแอปพลิเคชันอินเทอร์เน็ต ปัดเป่าการโจมตี DDoS ป้องกันแฮกเกอร์ และสามารถช่วยคุณในการเดินทางสู่ Zero Trust
ไปที่ 1.1.1.1 จากอุปกรณ์ใดก็ได้เพื่อเริ่มต้นใช้งานแอปฟรีของเราซึ่งจะทำให้อินเทอร์เน็ตของคุณเร็วขึ้นและปลอดภัยยิ่งขึ้น
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับภารกิจของเราในการช่วยสร้างอินเทอร์เน็ตที่ดีขึ้น เริ่มต้นที่นี่ หากคุณกำลังมองหาทิศทางอาชีพใหม่ ลองดูตำแหน่งงานที่เปิดรับของเรา หารือเกี่ยวกับข่าวแฮ็กเกอร์


Leave a Reply