วิธีควบคุมโครงสร้างพื้นฐานเครือข่ายของคุณ บทที่แรก ถือ

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

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

ดังนั้นเงื่อนไขตั้งต้น

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

เป้าหมายเชิงกลยุทธ์แรกของคุณคือการเรียนรู้ที่จะต้านทานเอนโทรปีและรักษาระดับการให้บริการที่มีให้

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

Оборудование

ก่อนอื่นคุณต้องเข้าใจว่าความเสี่ยงที่ใหญ่ที่สุดอยู่ที่ไหน

อีกครั้งมันอาจจะแตกต่างออกไป ฉันยอมรับว่าบางแห่งอาจเป็นปัญหาด้านความปลอดภัยและบางประเด็นที่เกี่ยวข้องกับความต่อเนื่องของบริการและที่อื่นอาจเป็นอย่างอื่น ทำไมจะไม่ล่ะ?

สมมติว่าเพื่อให้ชัดเจนว่านี่คือความต่อเนื่องของการบริการ (เป็นกรณีนี้ในทุกบริษัทที่ฉันทำงาน)

จากนั้นคุณต้องเริ่มต้นด้วยอุปกรณ์ นี่คือรายการหัวข้อที่ต้องใส่ใจ:

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

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

ตัวอย่าง

สมมติว่าเรากำลังพูดถึงสวิตช์รูทในศูนย์ข้อมูล

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

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

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

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

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

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

คุณจะไม่ได้รับการอภัยหากคุณลืมต่ออายุการสนับสนุนและวันถัดไปหลังจากที่การสนับสนุนสิ้นสุดลง ฮาร์ดแวร์ของคุณก็พัง

งานฉุกเฉิน

ไม่ว่าจะเกิดอะไรขึ้นบนเครือข่ายของคุณ คุณควรรักษาการเข้าถึงอุปกรณ์เครือข่ายของคุณเอาไว้

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

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

จะต้องมี

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

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

บริษัท ในเครือ

ตอนนี้คุณต้องประเมินความเสี่ยงที่เกี่ยวข้องกับพันธมิตร ปกติจะเป็นแบบนี้

• ผู้ให้บริการอินเทอร์เน็ตและจุดแลกเปลี่ยนปริมาณข้อมูล (IX)
• ผู้ให้บริการช่องทางการสื่อสาร

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

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

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

และแน่นอนว่า คุณไม่เพียงแต่ต้องถามคำถามเหล่านี้เท่านั้น แต่ยังต้องได้รับการสนับสนุนจากฝ่ายบริหารอีกครั้ง เพื่อมอบแนวทางแก้ไขที่ยอมรับได้ในทุกสถานการณ์

สำรองข้อมูล

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

สำคัญ! ทำการสำรองข้อมูลทุกวัน นี่ไม่ใช่ข้อมูลจำนวนมากที่จะบันทึกเกี่ยวกับเรื่องนี้ ในตอนเช้าวิศวกรที่ปฏิบัติหน้าที่ (หรือคุณ) ควรได้รับรายงานจากระบบซึ่งระบุอย่างชัดเจนว่าการสำรองข้อมูลสำเร็จหรือไม่ และหากการสำรองข้อมูลไม่สำเร็จปัญหาควรได้รับการแก้ไขหรือควรสร้างตั๋ว ( ดูกระบวนการของแผนกเครือข่าย)

เวอร์ชันซอฟต์แวร์

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

ที่นี่คุณจะต้องค้นหาตัวเลือกที่ดีที่สุด คำแนะนำที่ชัดเจนบางประการ

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

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

ในกรณีของอุปกรณ์สำคัญ คุณสามารถติดต่อฝ่ายสนับสนุนของผู้จำหน่ายเพื่อขอความช่วยเหลือในการอัปเกรดได้

ระบบตั๋ว

ตอนนี้คุณสามารถมองไปรอบ ๆ คุณต้องสร้างกระบวนการสำหรับการโต้ตอบกับแผนกอื่นและภายในแผนก

สิ่งนี้อาจไม่จำเป็น (เช่น หากบริษัทของคุณมีขนาดเล็ก) แต่ฉันขอแนะนำอย่างยิ่งให้จัดระเบียบงานในลักษณะที่งานภายนอกและภายในทั้งหมดต้องผ่านระบบตั๋ว

ระบบตั๋วเป็นส่วนติดต่อของคุณสำหรับการสื่อสารภายในและภายนอก และคุณควรอธิบายอินเทอร์เฟซนี้โดยละเอียดเพียงพอ

มาดูตัวอย่างงานที่สำคัญและทั่วไปในการเปิดการเข้าถึง ฉันจะอธิบายอัลกอริทึมที่ทำงานอย่างสมบูรณ์แบบในบริษัทแห่งหนึ่ง

ตัวอย่าง

เริ่มต้นด้วยความจริงที่ว่าลูกค้ามักจะเข้าถึงโดยกำหนดความต้องการในภาษาที่วิศวกรเครือข่ายไม่สามารถเข้าใจได้นั่นคือในภาษาของแอปพลิเคชันเช่น "ให้ฉันเข้าถึง 1C"

ดังนั้นเราจึงไม่เคยยอมรับคำขอโดยตรงจากผู้ใช้ดังกล่าว
และนั่นคือข้อกำหนดแรก

• คำขอเข้าถึงควรมาจากแผนกเทคนิค (ในกรณีของเราคือยูนิกซ์, windows, วิศวกรฝ่ายช่วยเหลือ)

ข้อกำหนดประการที่สองก็คือ

• การเข้าถึงนี้จะต้องถูกบันทึกไว้ (โดยแผนกเทคนิคที่เราได้รับคำขอนี้) และตามคำขอ เราได้รับลิงก์ไปยังการเข้าถึงที่บันทึกไว้นี้

แบบฟอร์มคำขอนี้จะต้องเป็นที่เข้าใจสำหรับเรา เช่น

• คำขอจะต้องมีข้อมูลเกี่ยวกับเครือข่ายย่อยใดและการเข้าถึงเครือข่ายย่อยใดที่ควรเปิด เช่นเดียวกับโปรโตคอลและพอร์ต (ในกรณีของ tcp/udp)

ควรระบุไว้ที่นั่นด้วย

• คำอธิบายว่าทำไมการเข้าถึงนี้จึงถูกเปิด
• ชั่วคราวหรือถาวร (ถ้าชั่วคราว ถึงวันไหน)

และจุดสำคัญมากคือการอนุมัติ

• จากหัวหน้าแผนกที่เริ่มการเข้าถึง (เช่น การบัญชี)
• จากหัวหน้าฝ่ายเทคนิคจากที่คำขอนี้มาถึงแผนกเครือข่าย (เช่น ฝ่ายช่วยเหลือ)

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

การบันทึก

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

คำแนะนำที่เป็นประโยชน์มีดังนี้:

• คุณต้องตรวจสอบบันทึกทุกวัน
• ในกรณีของการทบทวนตามแผน (และไม่ใช่สถานการณ์ฉุกเฉิน) คุณสามารถจำกัดตัวเองให้อยู่ในระดับความรุนแรง 0, 1, 2 และเพิ่มรูปแบบที่เลือกจากระดับอื่น ๆ หากคุณเห็นว่าจำเป็น
• เขียนสคริปต์ที่แยกวิเคราะห์บันทึกและละเว้นบันทึกที่มีรูปแบบที่คุณเพิ่มลงในรายการละเว้น

แนวทางนี้จะช่วยให้คุณสร้างรายการบันทึกที่ไม่น่าสนใจสำหรับคุณเมื่อเวลาผ่านไป และเหลือเฉพาะรายการบันทึกที่คุณพิจารณาว่าสำคัญจริงๆ
มันใช้งานได้ดีสำหรับเรา

การตรวจสอบ

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

สองตัวอย่างยอดนิยมในการปฏิบัติของฉัน:

• ตรวจสอบปริมาณช่องทางการสื่อสาร ลิงก์ที่สำคัญ (เช่น การเชื่อมต่อกับผู้ให้บริการ) สิ่งเหล่านี้ช่วยให้คุณมองเห็นปัญหาที่อาจเกิดขึ้นจากความเสื่อมโทรมของบริการอันเนื่องมาจากการสูญเสียการรับส่งข้อมูลในเชิงรุก และหลีกเลี่ยงปัญหาดังกล่าว
• กราฟขึ้นอยู่กับ NetFlow ช่วยให้ค้นหาความผิดปกติในการรับส่งข้อมูลได้ง่าย และมีประโยชน์มากในการตรวจจับการโจมตีของแฮ็กเกอร์บางประเภทที่เรียบง่ายแต่มีความสำคัญ

สำคัญ! ตั้งค่าการแจ้งเตือนทาง SMS สำหรับเหตุการณ์ที่สำคัญที่สุด สิ่งนี้ใช้ได้กับทั้งการตรวจสอบและการบันทึก หากคุณไม่มีกะทำงาน ควรส่ง SMS นอกเวลาทำงานด้วย

คิดตลอดกระบวนการในลักษณะที่จะไม่ปลุกวิศวกรทุกคน เรามีวิศวกรคอยทำหน้าที่นี้

การเปลี่ยนแปลงการควบคุม

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

เคล็ดลับ:

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

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

กระบวนการต่างๆ

คุณต้องทำให้เป็นทางการและอธิบายกระบวนการในทีมของคุณ หากคุณมาถึงจุดนี้แล้ว ทีมของคุณควรมีกระบวนการต่อไปนี้ที่ทำงานอยู่เป็นอย่างน้อย:

กระบวนการรายวัน:

• ทำงานกับตั๋ว
• ทำงานกับบันทึก
• การเปลี่ยนแปลงการควบคุม
• ใบตรวจสอบรายวัน

กระบวนการประจำปี:

• การขยายการรับประกันใบอนุญาต

กระบวนการอะซิงโครนัส:

• การตอบสนองต่อสถานการณ์ฉุกเฉินต่างๆ

บทสรุปของภาคแรก

คุณสังเกตไหมว่าทั้งหมดนี้ยังไม่เกี่ยวกับการกำหนดค่าเครือข่าย ไม่เกี่ยวกับการออกแบบ ไม่เกี่ยวกับโปรโตคอลเครือข่าย ไม่เกี่ยวกับการกำหนดเส้นทาง ไม่เกี่ยวกับความปลอดภัย... มันเป็นเรื่องรอบๆ แต่สิ่งเหล่านี้ แม้จะน่าเบื่อ แต่ก็เป็นองค์ประกอบที่สำคัญมากของการทำงานของฝ่ายเครือข่าย

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

ส่วนต่อไปนี้จะบอกวิธีค้นหาและกำจัดข้อผิดพลาด จากนั้นจึงปรับปรุงโครงสร้างพื้นฐานของคุณ

แน่นอนว่าคุณไม่จำเป็นต้องทำทุกอย่างตามลำดับ เวลาอาจเป็นเรื่องสำคัญ ทำควบคู่กันไปหากทรัพยากรเอื้ออำนวย

และการเพิ่มเติมที่สำคัญ สื่อสาร สอบถาม ปรึกษากับทีมงานของคุณ สุดท้ายแล้วพวกเขาก็เป็นคนที่สนับสนุนและทำทั้งหมดนี้

ที่มา: will.com