ฉันจะทำให้การปรับใช้การผลิตเป็นไปโดยอัตโนมัติโดยไม่ต้องกังวลมากได้อย่างไร

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

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

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

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

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

อะไรคือข้อโต้แย้งหรือข้อโต้แย้งนี้สำหรับการปรับใช้การผลิตสคริปต์อัตโนมัติ?

มีข้อโต้แย้งที่ชัดเจนเกี่ยวกับเรื่องนี้

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

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

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

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

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

ฉันคิดว่ากุญแจสำคัญคือ: ทำไมคุณคิดว่าคุณไม่สามารถเขียนสคริปต์กระบวนการตรวจสอบได้

สคริปต์การปรับใช้ของฉันไม่เพียงแค่ผลักดันการเก็บถาวรและเริ่มบริการใหม่ พวกเขาพิมพ์ข้อมูลรหัสสีจำนวนมากในระหว่างขั้นตอนการปรับใช้แต่ละครั้งและให้ข้อมูลสรุปเหตุการณ์ในตอนท้าย มันช่วยให้ฉันรู้ว่ากระบวนการทำงานและเริ่มทำงานแล้วโฮมเพจกำลังแสดงรหัสสถานะ 200 และเครื่องและบริการทั้งหมดสามารถเห็นกันและกันได้ ฉันมีบริการแยกต่างหากที่ไม่ใช่ส่วนหนึ่งของสคริปต์ที่ตรวจสอบไฟล์บันทึกข้อผิดพลาดระดับ 4xx และ 5xx และตัวชี้วัดไซต์หลัก จากนั้นจะตะโกนใส่ฉันผ่านทุกสื่อที่เป็นไปได้ (อีเมล, txt msg และการเตือนภัย) หากมี spikes ผลกระทบเชิงลบที่รุนแรง

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

คุณควรจะเกินไป

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

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

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

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

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

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

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

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

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

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

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

ที่กล่าวว่านี่คือตัวชี้สำคัญสำหรับการปรับใช้การผลิตของคุณโดยอัตโนมัติ:

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

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

แม้ว่าอย่างจริงจังคุณมีแนวโน้มที่จะทำผิดพลาดมากกว่าสคริปต์การปรับใช้

คอมพิวเตอร์ไม่ทำผิดพลาดคนทำ

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

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

ฉันจะทำให้การปรับใช้การผลิตเป็นไปโดยอัตโนมัติโดยไม่ต้องกังวลมากได้อย่างไร

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

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

2. ความล้มเหลวที่ถูกมองข้ามในการผลิตมีผลกระทบอย่างมาก

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

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

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

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

เมื่อคุณทำมันเองมันง่ายกว่าที่จะลืมขั้นตอนหรือทำตามคำสั่ง

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

ที่ระบุไว้ข้างต้นฉันอาจจะเป็นกังวลเหมือนคุณ

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

นอกจากการตั้งค่าการทดสอบแบบกระทุ้งสิ่งอื่นที่มีผลกระทบอย่างมีนัยสำคัญต่อความอุ่นใจของฉันก็คือการใช้งานผลิตภัณฑ์ที่ทำโดยทีมอื่น ๆ ที่นักพัฒนา - โดยพวกที่มีงานเพียงอย่างเดียวคือการรักษาสภาพแวดล้อมการผลิต

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

สร้างสคริปต์การปรับใช้ที่คุณใช้เพื่อย้ายรหัสของคุณไปยังสภาพแวดล้อมใด ๆ เราใช้กระบวนการปรับใช้เดียวกันนี้เพื่อย้ายรหัสไปยัง dev, qa, staging และการผลิตในที่สุด เนื่องจากเรากำลังปรับใช้หลายครั้งต่อวันเพื่อพัฒนาและประจำวันให้กับ QA เราจึงได้รับความมั่นใจว่าสคริปต์การปรับใช้นั้นถูกต้อง โดยพื้นฐานแล้วทดสอบนรกโดยใช้มันบ่อยๆ

1. ลดความซับซ้อน กระบวนการเปลี่ยนแปลงของคุณควรเป็นไฟล์ rsync, รันสคริปต์ SQL, ไม่มีอะไรเพิ่มเติม
2. ได้โดยอัตโนมัติ
3. ทดสอบ.

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

คุณยังต้องมีแผนสำรองสำหรับการเปลี่ยนแปลงใด ๆ ในบริบทใด ๆ และควรเป็นไปโดยอัตโนมัติเช่นกัน

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

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

1. ย้อนกลับไปเวอร์ชันก่อนหน้าได้อย่างน่าเชื่อถือ
2. รับการยืนยันในเชิงบวกว่าการปรับใช้ถูกนำไปใช้เรียบร้อยแล้วและกำลังตอบสนองต่อปริมาณการใช้งานที่ถูกต้อง
3. มีสภาพแวดล้อมที่เทียบเท่าสำหรับการพัฒนาและควบคุมคุณภาพซึ่งใช้สคริปต์เดียวกัน

มีข้อได้เปรียบบางอย่างสำหรับสคริปต์เช่นพวกเขาจะไม่พลาดคำสั่งเพราะตี 2 และมันเหนื่อย

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

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

1. ใช้หน้าต่างที่ใหญ่ขึ้นสำหรับการปรับใช้ครั้งแรกหากสิ่งผิดปกติ

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

   ข การปรับใช้ (อัตโนมัติ)

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