แนวคิดใด ๆ เกี่ยวกับวิธีเรียกใช้การบำรุงรักษาบนไซต์ที่อยู่ภายใต้การใช้งานเสมอ

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

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

เว็บไซต์ของเราใช้ Laravel ร่วมกับเซิร์ฟเวอร์ Node.JS แบบเรียลไทม์ เรากำลังใช้ Laravel Forge

ใครบ้างมีคำแนะนำเกี่ยวกับวิธีที่เราสามารถผลักดันการปรับปรุงบ่อยครั้งมากขึ้น? เราเปิดรับทุกสิ่ง

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

• ตรวจสอบให้แน่ใจว่ารหัสของคุณผ่านการทดสอบอย่างดี

  เป็นการดีที่คุณควรมีความคุ้มครองการทดสอบหน่วย 100% เช่นเดียวกับการทดสอบการรวมสำหรับทุกสถานการณ์เป็นไปได้

  หากคุณไม่ได้รับสิ่งนี้คุณควรทิ้งทุกอย่างไว้และจัดการเรื่องนี้

  ดูการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม

  การมีชุดทดสอบที่สมบูรณ์จะช่วยให้คุณ ...

• เรียกใช้การรวมอย่างต่อเนื่อง

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

  ในกรณีที่มีปัญหา CI สามารถให้การย้อนกลับแบบคลิกเดียว

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

• ทำการอัปเดตอะตอมมิก

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

  ดูว่าคอนเทนเนอร์เช่น Docker สามารถช่วยคุณได้หรือไม่

• ทำการเปลี่ยนแปลงที่เล็กลงและบ่อยขึ้น

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

  ในบันทึกนั้นทำการเปลี่ยนแปลงที่แยกได้มากขึ้นทุกครั้งที่ทำได้ หากคุณทำการเปลี่ยนแปลงกับเกมโอมาฮาและมันไม่ส่งผลกระทบต่อ Texas Hold'em สตั๊ดการ์ด 5 ใบหรืออะไรอย่างอื่นนั่นเป็นเกมเดียวที่จำเป็นต้องระงับเพื่อการบำรุงรักษา

• วิเคราะห์สิ่งที่ใช้เวลานาน

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

  มีผู้เชี่ยวชาญเฉพาะด้านให้ตรวจสอบส่วนอื่น ๆ ของการปรับใช้ซึ่งใช้เวลานานมาก

• ทำงานหลายชั่วโมง

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

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

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

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

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

วิธีนี้จะช่วยในวิธีต่อไปนี้:

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

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

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

วิธีเพิ่มคำตอบก่อนหน้า:

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

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

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

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

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

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

ฉันทั่วโลกเห็นด้วยกับไมเคิลในทุกจุดของเขา ( /server//a/739449/309477 )

ในความคิดของฉันการปรับปรุงครั้งแรกที่คุณควรทำคือการใช้เครื่องมือการปรับใช้ (Capistrano)

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

และ Capistrano นั้นค่อนข้างรวดเร็วในการจัดการก่อน (เทียบกับการเริ่มใช้การทดสอบและ CI ซึ่งจะเป็นการลงทุนครั้งใหญ่กว่า)

ประการที่สองหากเงินไม่ใช่ปัญหาหลักของคุณคุณควรมีเซิร์ฟเวอร์พัฒนา iso-prod เพื่อทดสอบแอปของคุณก่อนที่จะนำไปใช้ในการผลิต ใช้โซลูชันทางอุตสาหกรรม (Ansible, Chef, Puppet) เพื่อจัดการอินสแตนซ์ VPS