ทำความเข้าใจกับปัญหาเมื่อสิ่งต่าง ๆ ในการผลิต

สถานการณ์:

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

ข้อมูลจำเพาะ:

• แอปพลิเคชั่น PHP / MVC ที่ใช้ API ใน Zend
• ปรับใช้กับเซิร์ฟเวอร์ไม่กี่แห่ง

คำถามของฉัน:

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

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

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

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

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

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

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

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

มันยากจริงๆเนื่องจากมีความเป็นไปได้มากมายเช่นการตั้งค่าไลบรารีและซอฟต์แวร์เวอร์ชันต่าง ๆ

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

มักจะเป็นปัญหาการกำหนดค่าหรือข้อมูลสมมติว่ารหัสและ DB เหมือนกันระหว่าง Prod, QA และ dev

ฉันจะดูต่อไปนี้ก่อน:

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

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

ในขณะที่สภาพแวดล้อมของคุณเป็น PHP ฉันได้ทำการนำเสนอเกี่ยวกับวิธีคิดเกี่ยวกับ Java: http://www.infoq.com/presentations/maintaining-production-java-apps

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

นอกจากนี้ยังมีเครื่องมือบางอย่างที่จะทำให้การแก้ไขปัญหาง่ายขึ้น: Wireshark สำหรับการแก้ไขปัญหาเครือข่ายนั้นดีที่สุดและคุ้มค่ากับการเรียนรู้ อื่น ๆ ขึ้นอยู่กับ O / S ที่คุณใช้ สำหรับ Windows ทุกอย่างจาก SysInternal (ตอนนี้เป็นส่วนหนึ่งของ Microsoft) นั้นยอดเยี่ยม สำหรับ Unix / Linux ดูที่ truss / strace

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

คำตอบสั้น ๆ : ไม่ใช่ถ้าคุณมีทางเลือก

คำตอบยาว: หากคุณไม่เข้าใจปัญหามีความเสี่ยงหลายอย่างที่เกี่ยวข้องกับแพทช์ดังกล่าว:

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

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