คำถามและคำตอบสัมภาษณ์การสนับสนุนแอปพลิเคชันยอดนิยม 50 อันดับแรก (2026)
ลูคัส เบนเน็ตต์
เตรียมตัวสำหรับการสัมภาษณ์งานสนับสนุนแอปพลิเคชันหรือยัง? ถึงเวลาเตรียมตัวสำหรับคำถามที่คุณอาจพบเจอ การสนทนาเหล่านี้ในการสัมภาษณ์งานสนับสนุนแอปพลิเคชันจะเผยให้เห็นถึงสมรรถนะสำคัญที่จำเป็นสำหรับบทบาทไอทีสมัยใหม่ในปัจจุบัน
โอกาสในโดเมนนี้ครอบคลุมมุมมองอาชีพที่แข็งแกร่ง แนวโน้มอุตสาหกรรมที่เกิดขึ้น และการประยุกต์ใช้ในทางปฏิบัติที่ประสบการณ์ทางเทคนิคและความเชี่ยวชาญในโดเมนมาบรรจบกับโครงการจริง ผู้เชี่ยวชาญจะอาศัยประสบการณ์ระดับพื้นฐาน การวิเคราะห์ ทักษะในการวิเคราะห์ และทักษะที่หลากหลาย ซึ่งช่วยให้ผู้สมัครใหม่ ผู้มีประสบการณ์ ระดับกลาง และระดับสูง สามารถตอบคำถามและคำถามยอดนิยมทั่วไปได้อย่างมีประสิทธิภาพ
ข้อมูลเชิงลึกเหล่านี้สะท้อนให้เห็นแนวทางที่ได้รับการยืนยันผ่านคำติชมจากผู้จัดการมากกว่า 53 ราย และมุมมองที่แบ่งปันโดยผู้นำทางเทคนิคมากกว่า 92 ราย ช่วยให้ครอบคลุมสถานการณ์ต่างๆ อย่างกว้างขวาง และเสริมสร้างฐานที่เชื่อถือได้ อ่านเพิ่มเติม ...
ดาวน์โหลด PDF ฟรี: คำถามและคำตอบสัมภาษณ์การสนับสนุนแอปพลิเคชัน
คำถามและคำตอบสัมภาษณ์การสนับสนุนแอปพลิเคชัน
1) บทบาทของวิศวกรสนับสนุนแอปพลิเคชันในสภาพแวดล้อมไอทีสมัยใหม่คืออะไร
วิศวกรสนับสนุนแอปพลิเคชัน (Application Support Engineer) มีบทบาทสำคัญในการทำให้แอปพลิเคชันที่สำคัญทางธุรกิจมีเสถียรภาพ พร้อมใช้งาน และทำงานได้อย่างเต็มประสิทธิภาพตลอดวงจรชีวิต บทบาทหน้าที่นี้ประกอบด้วยการแก้ไขปัญหา การวิเคราะห์สาเหตุหลัก การตรวจสอบ การบำรุงรักษาสภาพแวดล้อม และการประสานงานระหว่างทีม คุณสมบัติที่สำคัญของตำแหน่งนี้คือความสามารถในการแก้ไขปัญหาในหลายระดับชั้น ทั้งแอปพลิเคชัน ฐานข้อมูล โครงสร้างพื้นฐาน และเครือข่าย พร้อมกับรักษาการสื่อสารกับผู้ใช้ปลายทางและผู้มีส่วนได้ส่วนเสีย
หน้าที่หลัก
- การตรวจสอบสุขภาพและประสิทธิภาพของระบบ
- การสอบสวนและแก้ไขเหตุการณ์ที่เกิดขึ้นกับแอปพลิเคชัน
- การยกระดับปัญหาไปยังทีมพัฒนาหรือโครงสร้างพื้นฐาน
- ดำเนินการปรับใช้ แพตช์ และการบำรุงรักษาตามกำหนดเวลา
- การบันทึกข้อผิดพลาดที่ทราบและขั้นตอนการแก้ไขปัญหา
ตัวอย่าง: ในแพลตฟอร์มอีคอมเมิร์ซ วิศวกรสนับสนุนแอปพลิเคชันจะตรวจสอบให้แน่ใจว่า API การชำระเงินทำงานได้อย่างน่าเชื่อถือ และจัดการกับความล้มเหลวในการชำระเงิน ปัญหาการหมดเวลา หรือคอขวดของฐานข้อมูล
2) คุณจะแก้ไขปัญหาอย่างไรเมื่อผู้ใช้รายงานว่าแอพพลิเคชันทำงานช้า?
การแก้ไขปัญหาด้านประสิทธิภาพจำเป็นต้องใช้แนวทางที่เป็นระบบซึ่งพิจารณาปัจจัยต่างๆ ที่เกี่ยวข้อง กระบวนการนี้โดยทั่วไปจะเริ่มต้นด้วยการตรวจสอบข้อเรียกร้องของผู้ใช้ รวบรวมบันทึก และระบุรูปแบบ พฤติกรรมการใช้งานที่ช้าอาจเกิดจากฐานข้อมูลแบ็กเอนด์ การเรนเดอร์ส่วนหน้า ความหน่วงของเครือข่าย หรือแม้แต่สภาพแวดล้อมเฉพาะของผู้ใช้
ขั้นตอนการสืบสวนโดยทั่วไป
- สร้างปัญหาซ้ำ เพื่อยืนยันว่าความช้านั้นเป็นแบบทั่วโลกหรือเฉพาะผู้ใช้
- Revบันทึกและเมตริกของมุมมองรวมถึง CPU, หน่วยความจำ และเวลาตอบสนอง
- ตรวจสอบประสิทธิภาพของฐานข้อมูลกำลังมองหาการค้นหาแบบรันยาวหรือตารางที่ถูกล็อค
- ตรวจสอบความหน่วงของเครือข่าย ผ่านทาง traceroute, pingหรือเครื่องมือ APM
- วิเคราะห์ระดับโค้ด traces หากมีเครื่องมือเช่น New Relic หรือ AppDynamics
ตัวอย่าง: หาก API endpoint แสดงเวลาตอบสนองที่เพิ่มขึ้นอย่างผิดปกติ APM จะแจ้งเตือน tracข้อผิดพลาดเหล่านี้มักเผยให้เห็นว่าคำสั่ง SQL ที่ไม่ได้ปรับแต่งอย่างเหมาะสมเป็นสาเหตุหลัก
3) อธิบายความแตกต่างระหว่างการจัดการเหตุการณ์ ปัญหา และการเปลี่ยนแปลงใน ITIL
กระบวนการ ITIL ทั้งสามนี้แสดงให้เห็นถึงวิธีการที่แตกต่างกันที่องค์กรต่างๆ ใช้ในการรักษาเสถียรภาพและจัดการวงจรชีวิตของแอปพลิเคชัน การจัดการเหตุการณ์ (Incident Management) มุ่งเน้นที่การคืนค่าบริการอย่างรวดเร็ว การจัดการปัญหา (Problem Management) ระบุสาเหตุที่แท้จริง และการจัดการการเปลี่ยนแปลง (Change Management) ควบคุมการปรับเปลี่ยนเพื่อลดความเสี่ยง
| กระบวนการ | จุดมุ่งหมาย | กิจกรรมหลัก | ตัวอย่าง |
|---|---|---|---|
| อุบัติการณ์ | คืนค่าบริการ ASAP | การคัดแยก การยกระดับ การแก้ไขปัญหา | การแก้ไขความผิดพลาดของแอปพลิเคชัน |
| ปัญหา | ระบุสาเหตุที่แท้จริง | RCA การวิเคราะห์แนวโน้ม | การค้นพบการรั่วไหลของหน่วยความจำที่ทำให้เกิดการหยุดทำงานซ้ำๆ |
| เปลี่ยนแปลง | ดำเนินการปรับปรุงอย่างปลอดภัย | การประเมินความเสี่ยง การอนุมัติ CAB การปรับใช้ | การอัพเกรดเซิร์ฟเวอร์แอป |
ในระยะสั้น: เหตุการณ์ต่างๆ ส่งผลต่อผู้ใช้ ปัญหาต่างๆ วิเคราะห์สาเหตุ การเปลี่ยนแปลง การนำแนวทางแก้ไขไปใช้
4) คุณพิจารณาปัจจัยใดบ้างเมื่อดำเนินการวิเคราะห์สาเหตุหลัก (RCA)
RCA ที่แข็งแกร่งจะตรวจสอบมิติต่างๆ เพื่อกำหนดไม่เพียงเท่านั้น อะไร ล้มเหลวแต่ ทำไม มันเกิดขึ้นแล้ว การวิเคราะห์ที่มีประสิทธิภาพจะพิจารณาพฤติกรรมของแอปพลิเคชัน บันทึกระบบ การเปลี่ยนแปลงการกำหนดค่า การอ้างอิง และการดำเนินการของผู้ใช้
ปัจจัยสำคัญใน RCA
- รูปแบบชั่วคราว: ปัญหาเริ่มเมื่อใด และมีอะไรเปลี่ยนแปลงไปในช่วงเวลานั้น?
- ความแตกต่างของการกำหนดค่า: การเปรียบเทียบสภาพแวดล้อมการทำงานและสภาพแวดล้อมนอกการทำงาน
- ความล้มเหลวของการพึ่งพา: API หยุดทำงาน ความล่าช้าของฐานข้อมูล หรือบริการภายนอกหยุดทำงาน
- ความสัมพันธ์ของบันทึก: รหัสข้อผิดพลาด, สแต็ก traces และรหัสธุรกรรม
- เมตริกโครงสร้างพื้นฐาน: CPU พุ่งสูง, หน่วยความจำรั่วไหล, ดิสก์ I/O อิ่มตัว
ตัวอย่าง: ปัญหาการหมดเวลาที่เกิดขึ้นซ้ำๆ อาจเกิดจากการกำหนดค่าเครือข่ายที่ไม่ถูกต้องเล็กน้อย ไม่ใช่แอปพลิเคชันเอง ซึ่งเน้นย้ำถึงความสำคัญของการวิเคราะห์แบบหลายชั้น
5) คุณจัดการกับเหตุการณ์ที่มีความสำคัญสูง (P1 หรือ Sev-1) อย่างไร
เหตุการณ์ที่มีความสำคัญสูงจำเป็นต้องได้รับการตอบสนองอย่างมีวินัยและทันเวลา เป้าหมายหลักคือการทำให้บริการกลับมาใช้งานได้อย่างรวดเร็ว พร้อมกับรักษาการสื่อสารที่โปร่งใส วิศวกรสนับสนุนแอปพลิเคชันต้องดำเนินการอย่างเร่งด่วน ประสานงานระหว่างทีม บันทึกการดำเนินการ และป้องกันไม่ให้เกิดผลกระทบซ้ำ
การจัดการเวิร์กโฟลว์ P1
- รับทราบทันที และประเมินผลกระทบต่อความพร้อมใช้งาน
- สร้างการโทรแบบสะพาน เพื่อการทำงานร่วมกันแบบเรียลไทม์
- กำหนดบทบาท: ผู้สื่อสาร ผู้สืบสวน ผู้แก้ไขปัญหา
- ดำเนินการแก้ไขปัญหาชั่วคราว หากมีความจำเป็น.
- จัดให้มีการอัปเดตเป็นประจำ ต่อผู้มีส่วนได้ส่วนเสีย
- การดำเนินการเอกสาร เพื่อการตรวจสอบหลังเกิดเหตุการณ์
ตัวอย่าง: หากเกตเวย์การชำระเงินไม่ตอบสนอง การเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังจุดปลายทางสำรองอาจช่วยคืนบริการบางส่วนได้ในขณะที่กำลังตรวจสอบสาเหตุหลัก
6) คุณใช้เครื่องมือตรวจสอบอะไรบ้าง และมีประโยชน์อย่างไร?
เครื่องมือตรวจสอบ ช่วยให้มองเห็นสถานะการทำงานของแอปพลิเคชันได้ชัดเจนยิ่งขึ้น โดยนำเสนอข้อมูลเชิงลึกหลากหลายประเภท เช่น ตัวชี้วัด บันทึกการทำงาน เป็นต้น tracเครื่องมือเหล่านี้รวมถึงการวิเคราะห์ข้อมูลเชิงพื้นที่และพฤติกรรมผู้ใช้ ช่วยให้ตรวจพบปัญหาได้เร็วขึ้น ลดเวลาเฉลี่ยในการแก้ไขปัญหา (MTTR) และเพิ่มความพึงพอใจของลูกค้า
เครื่องมือและประโยชน์ทั่วไป
| ประเภทเครื่องมือ | ตัวอย่าง | ประโยชน์ |
|---|---|---|
| APM | แอพไดนามิกส์, Dynatrace, นิวเรลิค | รายการ traces, การวินิจฉัยรหัส |
| เข้าสู่ระบบ | กวางเอลค์ สปลังค์ | การวิเคราะห์บันทึกแบบรวมศูนย์ |
| ตัวชี้วัด | โพรมีธีอุส กราฟานา | แผงหน้าปัดประสิทธิภาพแบบเรียลไทม์ |
| ข้างล่างนี้ | Nagios, Zabbix | การตรวจสอบ CPU, หน่วยความจำ, ดิสก์ |
ตัวอย่าง: การใช้ Grafana เพื่อ tracการเปลี่ยนแปลงอย่างฉับพลันในเวลาตอบสนองสามารถช่วยระบุความเสื่อมสภาพในระยะเริ่มต้นก่อนที่ผู้ใช้จะประสบปัญหาไฟดับ
7) อธิบายว่าคุณจัดการการปรับใช้แอปพลิเคชันอย่างไร และขั้นตอนใดที่จะช่วยให้มั่นใจถึงความสำเร็จ
การปรับใช้แอปพลิเคชันเป็นไปตามวงจรชีวิตที่มีโครงสร้าง ซึ่งประกอบด้วยการตรวจสอบความถูกต้อง การทดสอบ การดำเนินการ และการตรวจสอบหลังการใช้งาน การวางแผนที่เหมาะสมจะช่วยลดข้อเสียของระยะเวลาหยุดทำงานและการเผยแพร่ที่ล้มเหลว
ขั้นตอนการปรับใช้
- Revดูบันทึกการเปิดตัว และเข้าใจผลกระทบของการเปลี่ยนแปลง
- ตรวจสอบข้อกำหนดเบื้องต้นรวมถึงการสำรองข้อมูลและความเข้ากันได้ของเวอร์ชัน
- ดำเนินการทดสอบก่อนการปรับใช้ ในการจัดฉาก
- ดำเนินการปรับใช้ โดยใช้เครื่องมืออัตโนมัติ เช่น Jenkins หรือ Ansible
- ดำเนินการทดสอบควัน เพื่อให้แน่ใจว่าฟังก์ชันที่สำคัญทำงานได้
- ตรวจสอบบันทึกและเมตริก สำหรับความผิดปกติ
ตัวอย่าง: หลังจากปรับใช้เวอร์ชัน API ใหม่แล้ว ให้ทดสอบแบบควันโดยใช้ Postman ตรวจสอบให้แน่ใจว่าจุดสิ้นสุดทำงานอย่างถูกต้องก่อนที่จะกำหนดเส้นทางการรับส่งข้อมูลอย่างสมบูรณ์
8) ประเภทของบันทึกแอปพลิเคชันที่พบมากที่สุดคืออะไร และคุณจะใช้บันทึกเหล่านี้ระหว่างการแก้ไขปัญหาได้อย่างไร
บันทึก (Log) ทำหน้าที่เป็นแหล่งข้อมูลหลักในการแก้ไขปัญหา โดยให้รายละเอียดเกี่ยวกับข้อผิดพลาด ประสิทธิภาพ เหตุการณ์ด้านความปลอดภัย และพฤติกรรมของแอปพลิเคชัน บันทึกแต่ละประเภทมีวิธีการตีความสถานะระบบที่แตกต่างกัน
ประเภทของบันทึก
| ประเภทบันทึก | จุดมุ่งหมาย | ตัวอย่าง |
|---|---|---|
| บันทึกข้อผิดพลาด | การจับความล้มเหลวหรือข้อยกเว้น | ข้อยกเว้นตัวชี้ว่าง |
| บันทึกการเข้าถึง | Tracคำขอของผู้ใช้ k | รหัสสถานะ HTTP |
| บันทึกการทำธุรกรรม | บันทึกเหตุการณ์ทางธุรกิจ | การอนุญาตการชำระเงิน |
| บันทึกการดีบัก | ข้อมูลการวินิจฉัยอย่างละเอียด | ค่าตัวแปร |
ตัวอย่าง: หากผู้ใช้รายงานปัญหาในการเข้าสู่ระบบ บันทึกการเข้าถึงที่รวมกับบันทึกข้อผิดพลาดจะช่วยระบุว่าการตรวจสอบสิทธิ์ล้มเหลวเนื่องจากข้อมูลประจำตัวไม่ถูกต้อง โทเค็นหมดอายุ หรือบริการ LDAP ที่ไม่พร้อมใช้งาน
9) อธิบายว่าคุณสนับสนุน API และบริการเว็บในบทบาทการสนับสนุนแอปพลิเคชันอย่างไร
การสนับสนุน API เกี่ยวข้องกับการทำความเข้าใจสถาปัตยกรรม รูปแบบเพย์โหลด กลไกการตรวจสอบสิทธิ์ และความสัมพันธ์ของการอ้างอิง วิศวกรต้องมั่นใจว่าจุดสิ้นสุดยังคงพร้อมใช้งาน ตอบสนองภายใน SLA ที่ยอมรับได้ และบูรณาการกับระบบต้นทางและปลายทางได้อย่างถูกต้อง
กิจกรรมสนับสนุนที่สำคัญ
- การตรวจสอบเวลาตอบสนองอัตราข้อผิดพลาด และปริมาณงาน
- การตรวจสอบรูปแบบเพย์โหลดเช่น JSON หรือ XML
- การตรวจสอบโค้ด HTTP (400, 404, 500, ฯลฯ)
- การทดสอบจุดสิ้นสุด โดยใช้เครื่องมือเช่น Postman หรือม้วนงอ
- การตรวจสอบการอ้างอิง เช่นฐานข้อมูล ไมโครเซอร์วิส หรือ API ของบุคคลที่สาม
ตัวอย่าง: ข้อผิดพลาด HTTP 429 ที่เพิ่มขึ้นอย่างกะทันหันบ่งชี้ถึงการจำกัดอัตรา ซึ่งอาจต้องปรับกฎการควบคุมความเร็วหรือเพิ่มประสิทธิภาพพฤติกรรมของผู้บริโภค
10) คุณลักษณะใดที่กำหนดสภาพแวดล้อมการผลิตที่เชื่อถือได้?
สภาพแวดล้อมการผลิตที่มีเสถียรภาพแสดงให้เห็นถึงความสามารถในการคาดการณ์ ความยืดหยุ่น และวินัยในการปฏิบัติงานที่แข็งแกร่ง ความน่าเชื่อถือขึ้นอยู่กับความแข็งแกร่งของโครงสร้างพื้นฐาน ขอบเขตการตรวจสอบ คุณภาพเอกสาร และการปฏิบัติตามการควบคุมการเปลี่ยนแปลง
ลักษณะของสภาพแวดล้อมที่เชื่อถือได้
- ความฟุ่มเฟือย ในเซิร์ฟเวอร์ ฐานข้อมูล และเครือข่าย
- กลไกการสำรองข้อมูลอัตโนมัติ
- การตรวจสอบและแจ้งเตือนอย่างครอบคลุม
- กระบวนการปรับใช้ที่มีการควบคุม
- สมุดงานและขั้นตอนการปฏิบัติงานที่ชัดเจน
ตัวอย่าง: สภาพแวดล้อมที่มีการโหลดสมดุลพร้อมการปรับขนาดอัตโนมัติช่วยให้มั่นใจได้ว่าปริมาณการรับส่งข้อมูลที่เพิ่มขึ้นจะไม่ล้นเซิร์ฟเวอร์เดียว ทำให้บริการยังคงไม่หยุดชะงัก
11) คุณจัดการการควบคุมการเข้าถึงแอปพลิเคชันและสิทธิ์ของผู้ใช้อย่างไร
การจัดการการควบคุมการเข้าถึงแอปพลิเคชันเกี่ยวข้องกับการกำหนด การมอบหมาย และการบำรุงรักษาชุดสิทธิ์ เพื่อให้แน่ใจว่าผู้ใช้จะเข้าถึงเฉพาะสิ่งที่บทบาทของตนกำหนดไว้เท่านั้น วิศวกรฝ่ายสนับสนุนจะทำงานร่วมกับทีมรักษาความปลอดภัยและการปฏิบัติตามกฎระเบียบเพื่อตรวจสอบความถูกต้องของคำจำกัดความบทบาท tracมีการอัปเดต k และรักษาหลักการให้สิทธิ์ขั้นต่ำ ปัญหาที่เกี่ยวข้องกับการเข้าถึงมักเกิดจากบทบาทที่ไม่ตรงกัน ข้อมูลประจำตัวหมดอายุ บัญชีที่ไม่ได้ใช้งาน หรือขั้นตอนการจัดสรรที่ไม่ถูกต้อง
ประเภทการอนุญาตทั่วไป
| ประเภท | Descriptไอออน | ตัวอย่าง |
|---|---|---|
| การควบคุมการเข้าถึงตามบทบาท (RBAC) | การเข้าถึงที่เชื่อมโยงกับบทบาทงาน | ตำแหน่ง “นักวิเคราะห์การเงิน” → ดูรายงาน |
| การควบคุมการเข้าถึงตามคุณสมบัติ (ABAC) | คุณลักษณะตามบริบทกำหนดการเข้าถึง | การเข้าถึงตามตำแหน่งที่ตั้ง |
| การควบคุมตาม ACL | กฎอนุญาต/ปฏิเสธที่ชัดเจน | ให้สิทธิ์การเข้าถึงโฟลเดอร์แบบอ่านอย่างเดียว |
ตัวอย่าง: ผู้ใช้ที่ได้รับมอบหมายบทบาท "ผู้ดู" เท่านั้นอาจรายงานว่าไม่สามารถแก้ไขบันทึกได้ ซึ่งจำเป็นต้องอัปเกรดบทบาทตามเวิร์กโฟลว์การอนุมัติ
12) มีวิธีที่มีประสิทธิภาพในการลดเหตุการณ์ที่เกิดขึ้นซ้ำในสภาพแวดล้อมการผลิตอะไรบ้าง
การลดเหตุการณ์ที่เกิดขึ้นซ้ำๆ จำเป็นต้องมีทั้งกลยุทธ์เชิงรุกและเชิงรับ กระบวนการนี้เริ่มต้นด้วยการระบุรูปแบบ การวิเคราะห์สาเหตุที่แท้จริง และการแก้ไขปัญหาอย่างเป็นระบบ แทนที่จะแก้ปัญหาเฉพาะหน้าอย่างรวดเร็ว เมื่อเวลาผ่านไป ปัญหาที่เกิดขึ้นซ้ำๆ มักจะชี้ให้เห็นถึงข้อบกพร่องในการออกแบบ การกำหนดค่าที่คลาดเคลื่อน หรือการขาดการครอบคลุมการตรวจสอบ
วิธีการต่างๆ ในการลดเหตุการณ์ที่เกิดขึ้นซ้ำ
- ดำเนินการแก้ไขแบบถาวร ระบุในระหว่างวงจรชีวิต RCA
- ปรับปรุงการตรวจสอบและการครอบคลุมบันทึก เพื่อตรวจพบอาการในระยะเริ่มแรก
- ทำงานด้วยตนเองโดยอัตโนมัติ, ลดปัจจัยการเกิดข้อผิดพลาดของมนุษย์
- Revเส้นฐานการกำหนดค่า iew เพื่อตรวจจับความไม่สอดคล้องกัน
- ดำเนินการจัดการประชุมแบ่งปันความรู้ ท่ามกลางทีมสนับสนุน
ตัวอย่าง: หาก API หมดเวลาถึงเกณฑ์การรับส่งข้อมูลที่กำหนด การนำนโยบายการปรับขนาดอัตโนมัติมาใช้จะช่วยลดปัญหาประสิทธิภาพการทำงานลดลงซ้ำๆ
13) SLA และ OLA มีความสำคัญอย่างไรในการสนับสนุนแอปพลิเคชัน?
ข้อตกลงระดับการบริการ (SLA) และ Operaข้อตกลงระดับประเทศ (OLA) กำหนดขอบเขตความคาดหวังสำหรับเวลาตอบสนอง เวลาแก้ไขปัญหา ความพร้อมให้บริการ และการทำงานร่วมกันเป็นทีม SLA เป็นข้อผูกพันภายนอกที่มีต่อลูกค้า ในขณะที่ OLA ชี้นำทีมภายในให้บรรลุวัตถุประสงค์ร่วมกัน
ข้อดีของ SLA/OLA ที่ชัดเจน
- เพิ่มความสามารถในการคาดการณ์ประสิทธิภาพการให้บริการ
- เสริมสร้างความไว้วางใจกับลูกค้าและผู้ถือผลประโยชน์
- ลดความคลุมเครือระหว่างการยกระดับ
- ช่วยจัดลำดับความสำคัญของเหตุการณ์และงาน
- รองรับการปฏิบัติตามข้อกำหนดและความพร้อมในการตรวจสอบ
ตัวอย่าง: SLA อาจกำหนดเวลาตอบสนอง 15 นาทีสำหรับเหตุการณ์ P1 โดยเสริมด้วย OLA ที่กำหนดให้ทีมโครงสร้างพื้นฐานต้องตอบสนองภายใน 10 นาทีต่อการแจ้งเตือนผลกระทบใดๆ
14) คุณสามารถอธิบายความแตกต่างระหว่างการปรับขนาดแนวนอนและแนวตั้งในการรองรับแอปพลิเคชันได้หรือไม่
การปรับขนาดช่วยเพิ่มขีดความสามารถของแอปพลิเคชัน แต่วิธีการจะแตกต่างกันไปขึ้นอยู่กับการออกแบบทางสถาปัตยกรรมและข้อจำกัดในการดำเนินงาน การปรับขนาดแนวตั้งจะเพิ่มพลังของโหนดที่มีอยู่ ในขณะที่การปรับขนาดแนวนอนจะเพิ่มโหนดเพื่อกระจายภาระงาน
ตารางเปรียบเทียบ
| แง่มุม | มาตราส่วนแนวนอน | มาตราส่วนแนวตั้ง |
|---|---|---|
| เข้าใกล้ | เพิ่มเซิร์ฟเวอร์เพิ่มเติม | Upgrade เซิร์ฟเวอร์ที่มีอยู่ |
| ข้อดี | ความพร้อมใช้งานสูง ความยืดหยุ่น | การจัดการที่ง่ายขึ้น |
| ข้อเสีย | ต้องใช้สถาปัตยกรรมแบบกระจาย | ข้อจำกัดของฮาร์ดแวร์ |
| ตัวอย่าง | การเพิ่มอินสแตนซ์ EC2 | เพิ่ม CPU/RAM |
ตัวอย่าง: แอปพลิเคชันที่ใช้ไมโครเซอร์วิสได้รับประโยชน์จากการปรับขนาดแนวนอน เนื่องจากส่วนประกอบแต่ละส่วนสามารถขยายได้โดยอิสระ
15) คุณจะตรวจสอบปัญหาที่เกี่ยวข้องกับงานตามกำหนดเวลาหรือกระบวนการแบตช์ได้อย่างไร
การแก้ไขปัญหางานแบบแบตช์เกี่ยวข้องกับการวิเคราะห์รูปแบบการดำเนินการ บันทึก เครื่องมือจัดตารางเวลา และการอ้างอิงที่เกี่ยวข้อง ความล้มเหลวมักเกิดจากพารามิเตอร์ที่ไม่ถูกต้อง ข้อมูลที่ล้าสมัย ปัญหาสิทธิ์ หรือการแข่งขันทรัพยากร
ขั้นตอนการสอบสวน
- ยืนยันกำหนดการทำงานและตรวจสอบว่างานถูกเรียกใช้งานหรือไม่
- Revดูรหัสทางออก บันทึกงาน และข้อความแสดงข้อผิดพลาด
- ตรวจสอบรูปแบบไฟล์อินพุตและจำนวนเรกคอร์ดฐานข้อมูล
- ตรวจสอบคอขวดทรัพยากร (CPU, I/O, หน่วยความจำ)
- ประเมินบริการการอ้างอิงเช่น SFTP, API หรือฐานข้อมูล
ตัวอย่าง: งานที่ส่งใบแจ้งหนี้รายเดือนอาจล้มเหลวเนื่องจากบริการต้นทางไม่ได้สร้างไฟล์อินพุต ไม่ใช่เพราะปัญหาโค้ด
16) คุณคิดว่ามาตรวัดการติดตามใดมีความจำเป็นต่อสุขภาพของแอปพลิเคชัน?
แอปพลิเคชันที่ดีต้องแสดงให้เห็นถึงประสิทธิภาพ ความพร้อมใช้งาน และการใช้ทรัพยากรที่เหมาะสมที่สุด เมตริกการตรวจสอบจะเน้นย้ำถึงแนวโน้มและความผิดปกติต่างๆ นำเสนอข้อมูลเชิงลึกเกี่ยวกับพฤติกรรมของระบบและคาดการณ์ความล้มเหลว
ประเภทเมตริกที่จำเป็น
| Category | ตัวชี้วัด |
|---|---|
| ประสิทธิภาพ | เวลาตอบสนอง, ปริมาณงาน |
| โครงสร้างพื้นฐาน | ซีพียู, หน่วยความจำ, ดิสก์ I/O |
| ข้อผิดพลาด | อัตราข้อยกเว้น คำขอที่ล้มเหลว |
| ฐานข้อมูล | ความหน่วงของการค้นหา การเชื่อมต่อ |
| ประสบการณ์ของผู้ใช้ | คะแนน Apdex ระยะเวลาเซสชัน |
ตัวอย่าง: การเพิ่มเวลาตอบสนองควบคู่ไปกับการใช้งานหน่วยความจำที่เพิ่มขึ้น มักเป็นสัญญาณของการรั่วไหลของหน่วยความจำ ช่วยให้สามารถดำเนินการเชิงรุกได้ก่อนที่จะเกิดการหยุดทำงาน
17) คุณจะยกระดับปัญหาแอปพลิเคชันเมื่อใด และต้องมีข้อมูลอะไรบ้าง
การยกระดับปัญหาเกิดขึ้นเมื่อปัญหาเกินขีดความสามารถของทีมสนับสนุน ละเมิดเกณฑ์ SLA หรือต้องแก้ไขเกินขอบเขตการปฏิบัติงาน การสื่อสารที่ชัดเจนจะช่วยให้การแก้ไขปัญหารวดเร็วยิ่งขึ้นและป้องกันความสับสนระหว่างผู้มีส่วนได้ส่วนเสีย
ข้อมูลการยกระดับที่จำเป็น
- คำอธิบายปัญหาโดยละเอียด
- การวิเคราะห์ผลกระทบ: ผู้ใช้ บริการ ภูมิศาสตร์
- รองรับการบันทึก ภาพหน้าจอ และวันที่และเวลา
- ขั้นตอนการแก้ไขปัญหาที่พยายามแล้ว
- กำหนดเวลาตามลำดับความสำคัญและ SLA
- รายละเอียดสภาพแวดล้อม (การผลิต, UAT, QA)
ตัวอย่าง: หากพบปัญหาฐานข้อมูลติดขัดซ้ำๆ ซึ่งจำเป็นต้องแก้ไขในระดับโค้ด ควรแจ้งให้ทีมพัฒนาทราบพร้อมทั้งบันทึกการสืบค้นข้อมูลและธุรกรรมทั้งหมด tracES
18) คุณมั่นใจได้อย่างไรว่าเอกสารการสมัครยังคงถูกต้องและมีประโยชน์?
เอกสารประกอบช่วยส่งเสริมการแบ่งปันความรู้ การเริ่มต้นทำงานที่รวดเร็วขึ้น และลดการพึ่งพาตัววิศวกรแต่ละคน (คี)ping การทำให้เอกสารมีความถูกต้องแม่นยำนั้น จำเป็นต้องมีการอัปเดตอย่างต่อเนื่องเพื่อให้สอดคล้องกับการปรับใช้ การเปลี่ยนแปลงโครงสร้าง หรือการปรับปรุงการดำเนินงาน
แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดทำเอกสาร
- อัปเดตเอกสารในแต่ละรอบชีวิตการเผยแพร่
- ใช้ที่เก็บข้อมูลควบคุมเวอร์ชัน เช่น Confluence หรือ Git
- สร้าง runbooks พร้อมขั้นตอนแบบทีละขั้นตอน
- เพิ่มต้นไม้การแก้ไขปัญหาและคำอธิบายสถานการณ์ข้อผิดพลาด
- บันทึกตัวอย่างเหตุการณ์ที่เกิดขึ้นก่อนหน้าและการแก้ไข
ตัวอย่าง: เมื่อมีการนำกระแสการตรวจสอบสิทธิ์ API ใหม่มาใช้ การอัปเดตรันบุ๊กด้วยขั้นตอนการสร้างโทเค็นจะช่วยป้องกันความสับสนในระหว่างการแก้ไขปัญหาเร่งด่วน
19) ปัญหาการรวมระบบที่พบบ่อยที่สุดระหว่างแอปพลิเคชันและระบบของบริษัทอื่นคืออะไร
ความล้มเหลวในการผสานรวมมักเกิดจากความไม่สอดคล้องกันของรูปแบบข้อมูล ข้อกำหนดการพิสูจน์ตัวตน หรือการกำหนดค่าเครือข่าย ความล่าช้า พารามิเตอร์ API ที่ไม่ถูกต้อง และความไม่ตรงกันของเวอร์ชันก็ล้วนเป็นปัจจัยที่นำไปสู่ความล้มเหลวเช่นกัน
ประเภททั่วไปของปัญหาการรวมระบบ
- ข้อมูลไม่ตรงกัน (เช่น ขาดช่องข้อมูลที่จำเป็น)
- ข้อผิดพลาดในการตรวจสอบสิทธิ์ (โทเค็นหมดอายุหรือข้อมูลประจำตัวไม่ถูกต้อง)
- หมดเวลา เนื่องจากการตอบสนองจากบุคคลที่สามล่าช้า
- การเปลี่ยนแปลงเวอร์ชัน API ส่งผลกระทบต่อโครงสร้างบรรทุก
- ข้อจำกัดของเครือข่าย เช่น พอร์ตที่ถูกบล็อค
ตัวอย่าง: บริการชำระเงินอาจปฏิเสธธุรกรรมหากแอปพลิเคชันส่งข้อมูลประทับเวลาในรูปแบบที่ไม่ได้รับการสนับสนุน
20) การรองรับไมโครเซอร์วิสยากกว่าแอปพลิเคชันแบบโมโนลิธิกหรือไม่
การรองรับไมโครเซอร์วิสอาจมีความซับซ้อนมากขึ้นเนื่องจากความต้องการพึ่งพาที่เพิ่มขึ้น ส่วนประกอบแบบกระจาย และขั้นตอนการใช้งานที่แยกจากกัน อย่างไรก็ตาม ไมโครเซอร์วิสเหล่านี้มีข้อได้เปรียบที่สำคัญ เช่น การปรับขนาดที่เป็นอิสระ ความยืดหยุ่น และการเผยแพร่ที่รวดเร็วขึ้น ระบบแบบโมโนลิธิกนั้นแก้ไขปัญหาได้ง่ายกว่าเนื่องจากมีบันทึก บริการ และกระบวนการอยู่ในฐานโค้ดเดียวกัน แต่การบำรุงรักษาอาจทำได้ยากขึ้นเมื่อระบบเติบโตขึ้น
ภาพรวมความแตกต่าง
| แง่มุม | Microservices | หินใหญ่ก้อนเดียว |
|---|---|---|
| ความซับซ้อน | กระจายหลายบริการ | ส่วนกลาง |
| ขูดหินปูน | การปรับขนาดในระดับส่วนประกอบ | เฉพาะแอปทั้งหมดเท่านั้น |
| ข้อดี | ความยืดหยุ่น ความยืดหยุ่น | การดีบักที่ง่ายกว่า |
| ข้อเสีย | Tracความซับซ้อน | ความสามารถในการปรับขนาดที่ จำกัด |
ตัวอย่าง: การวินิจฉัยปัญหาในสถาปัตยกรรมไมโครเซอร์วิสอาจต้องใช้... tracการทำธุรกรรมข้ามบริการมากกว่า 10 บริการโดยใช้เครื่องมืออย่าง Jaeger หรือ Zipkin
21) คุณแก้ไขปัญหาที่เกี่ยวข้องกับการเชื่อมต่อฐานข้อมูลอย่างไร
ปัญหาการเชื่อมต่อฐานข้อมูลมักเกิดขึ้นเนื่องจากความล้มเหลวในการตรวจสอบสิทธิ์ ข้อจำกัดของเครือข่าย การกำหนดค่าที่ไม่ตรงกัน หรือข้อจำกัดด้านทรัพยากร กระบวนการแก้ไขปัญหาต้องเริ่มต้นด้วยการระบุว่าปัญหาเกิดขึ้นเฉพาะแอปพลิเคชัน เฉพาะสภาพแวดล้อม หรือเกิดจากตัวเซิร์ฟเวอร์ฐานข้อมูลเอง การตรวจสอบสตริงการเชื่อมต่อให้ถูกต้อง การตรวจสอบสิทธิ์ผู้ใช้ และการตรวจสอบความเข้ากันได้ของไดรเวอร์ ถือเป็นขั้นตอนสำคัญ
พื้นที่การแก้ไขปัญหาที่สำคัญ
- การตรวจสอบเครือข่าย: ตรวจสอบกฎไฟร์วอลล์ พอร์ต และ ping การตอบสนอง
- รับรองความถูกต้อง: ยืนยันข้อมูลประจำตัว บทบาทผู้ใช้ และบัญชีที่หมดอายุ
- การตรวจสอบการกำหนดค่า: ตรวจสอบให้แน่ใจว่าโฮสต์ DB, อินสแตนซ์ และเวอร์ชันไดรเวอร์ถูกต้อง
- ปัญหาทรัพยากร: ตรวจสอบ CPU ของเซิร์ฟเวอร์ DB, พูลการเชื่อมต่อ และล็อค
ตัวอย่าง: ข้อผิดพลาด "การเชื่อมต่อมากเกินไป" ที่เกิดขึ้นอย่างกะทันหัน มักบ่งชี้ว่ามีการกำหนดค่าพูลการเชื่อมต่อไม่ถูกต้อง หรือแบบสอบถามที่ทำงานเป็นเวลานานทำให้เซสชันเปิดอยู่
22) คุณสามารถทดสอบฟังก์ชันการทำงานของแอปพลิเคชันได้หลายวิธีใดบ้างหลังจากเกิดเหตุการณ์การผลิต?
การทดสอบหลังเกิดเหตุการณ์จะช่วยให้มั่นใจได้ถึงความเสถียรของระบบและยืนยันว่าไม่มีปัญหาใดๆ หลงเหลืออยู่ การทดสอบเหล่านี้จะช่วยตรวจสอบเวิร์กโฟลว์ที่สำคัญ การอ้างอิง การผสานรวม และเกณฑ์ประสิทธิภาพ นอกจากนี้ การตรวจสอบบันทึกและแดชบอร์ดการตรวจสอบยังช่วยยืนยันพฤติกรรมปกติอีกด้วย
ประเภทการทดสอบหลังเหตุการณ์
| ประเภทการทดสอบ | จุดมุ่งหมาย | ตัวอย่าง |
|---|---|---|
| การทดสอบควัน | การตรวจสอบการทำงานขั้นพื้นฐาน | เข้าสู่ระบบ ค้นหา การทำธุรกรรม |
| การทดสอบการถดถอย | ยืนยันการแก้ไขก่อนหน้านี้ยังคงมีเสถียรภาพ | การตรวจสอบ API |
| การทดสอบบูรณาการ | ตรวจสอบการโต้ตอบกับระบบภายนอก | การตรวจสอบเกตเวย์การชำระเงิน |
| การทดสอบประสิทธิภาพ | ตรวจสอบเกณฑ์การโหลด | เมตริกเวลาตอบสนอง |
ตัวอย่าง: หลังจากแก้ไขปัญหาการหมดเวลาของฐานข้อมูลแล้ว การรันการทดสอบการถดถอยและประสิทธิภาพจะช่วยให้แน่ใจว่าสาเหตุหลักได้รับการแก้ไขอย่างครบถ้วน
23) เมื่อสนับสนุนแอปพลิเคชันที่โฮสต์บนคลาวด์ ปัจจัยใดบ้างที่คุณจะต้องประเมินในระหว่างการแก้ไขปัญหา?
สภาพแวดล้อมคลาวด์จะนำเสนอเลเยอร์เพิ่มเติม เช่น เครือข่ายเสมือน กลุ่มปรับขนาดอัตโนมัติ บริการที่ได้รับการจัดการ และการประสานงานคอนเทนเนอร์ การแก้ไขปัญหาต้องคำนึงถึงส่วนประกอบแบบกระจายเหล่านี้
ปัจจัยสำคัญของคลาวด์
- พฤติกรรมการปรับขนาดอัตโนมัติ: อินสแตนซ์หมุนขึ้นหรือยุติลงโดยไม่คาดคิด
- กลุ่มความปลอดภัยเครือข่ายและกฎไฟร์วอลล์: การปิดกั้นเส้นทางการสื่อสาร
- โควตาการบริการ: การเข้าถึงขีดจำกัดสำหรับการประมวลผล การจัดเก็บ หรือ API
- สถานะการประสานงานคอนเทนเนอร์: สุขภาพของพ็อด การรีสตาร์ท หรือข้อจำกัดของทรัพยากร
- บันทึกและเมตริกของคลาวด์: คลาวด์วอทช์ Azure มอนิเตอร์ GCP Operaหลาก
ตัวอย่าง: หากไม่สามารถเข้าถึงจุดสิ้นสุด API ได้ การเปลี่ยนแปลงกลุ่มความปลอดภัยเครือข่ายใน AWS อาจบล็อกการรับส่งข้อมูลขาเข้าบนพอร์ต 443
24) อธิบายว่าคุณใช้ความสัมพันธ์ของลอการิทึมเพื่อวินิจฉัยปัญหาที่ซับซ้อนได้อย่างไร
การหาความสัมพันธ์ของข้อมูลบันทึกช่วยให้วิศวกรสามารถ tracการตรวจสอบเหตุการณ์ต่างๆ ในระบบหลายระบบทำได้โดยการจับคู่เวลา รหัสธุรกรรม รหัสคำขอ หรือรหัสผู้ใช้ วิธีนี้มีความสำคัญอย่างยิ่งในสถาปัตยกรรมแบบกระจายศูนย์ ซึ่งธุรกรรมเดียวอาจโต้ตอบกับบริการต่างๆ มากมาย
ขั้นตอนสำหรับการเชื่อมโยงลอการิทึมที่มีประสิทธิภาพ
- ระบุตัวระบุทั่วไป เช่น รหัสความสัมพันธ์
- เรียงลำดับบันทึกตามลำดับเวลาเพื่อสร้างแผนที่วงจรชีวิตของเหตุการณ์
- เปรียบเทียบบันทึกจากแอปพลิเคชัน เซิร์ฟเวอร์ และฐานข้อมูล
- ตรวจจับรูปแบบต่างๆ เช่น ข้อผิดพลาดที่เกิดซ้ำหรือห่วงโซ่เวลาแฝง
ตัวอย่าง: เมื่อทำการแก้ไขปัญหาขั้นตอนการชำระเงินหลายขั้นตอน รหัสความสัมพันธ์จะช่วยได้ tracการทำธุรกรรมแต่ละรายการผ่านไมโครเซอร์วิส เช่น ตะกร้าสินค้า การกำหนดราคา การชำระเงิน และการจัดส่งping โมดูล
25) ข้อเสียทั่วไปของการจัดการข้อผิดพลาดที่ออกแบบมาไม่ดีในแอปพลิเคชันคืออะไร
การจัดการข้อผิดพลาดที่ไม่ดีนำไปสู่การวินิจฉัยที่ไม่ชัดเจน ความหงุดหงิดของผู้ใช้ และระยะเวลาในการแก้ไขปัญหาที่นานขึ้น เมื่อแอปพลิเคชันปกปิดหรือระงับข้อผิดพลาด ทีมสนับสนุนจะประสบปัญหาในการระบุสาเหตุที่แท้จริงหรือกำหนดขั้นตอนการแก้ไขที่เหมาะสม
ข้อเสียเปรียบที่สำคัญ
- ข้อความที่คลุมเครือ: ผู้ใช้จะได้รับข้อผิดพลาดทั่วไปว่า "มีบางอย่างผิดพลาด"
- ขาดบริบท: ไม่มีรหัสธุรกรรมหรือสแต็ก tracES
- ความล้มเหลวที่เงียบงัน: ข้อผิดพลาดไม่ปรากฏในบันทึก
- รูปแบบที่ไม่สอดคล้องกัน: ทำให้การแยกวิเคราะห์บันทึกทำได้ยาก
- ขยายเวลาการแก้ไข: การสนับสนุนยังขาดข้อมูลที่สามารถดำเนินการได้
ตัวอย่าง: ข้อผิดพลาดการชำระเงินที่ไม่สำเร็จซึ่งไม่บันทึกรหัสตอบสนองของเกตเวย์ ทำให้วิศวกรต้องแก้ไขด้วยตนเอง tracความล้มเหลวดังกล่าวส่งผลให้การให้การสนับสนุนลูกค้าล่าช้า
26) ลักษณะเฉพาะของกระบวนการจัดการการเปลี่ยนแปลงที่แข็งแกร่งมีอะไรบ้าง
กระบวนการจัดการการเปลี่ยนแปลงที่แข็งแกร่งช่วยรับประกันความเสถียร ลดความเสี่ยง และลดการหยุดชะงักของบริการ กระบวนการนี้ช่วยสร้างโครงสร้างตลอดวงจรการเปลี่ยนแปลง ช่วยให้มั่นใจได้ว่าการดำเนินธุรกิจจะยังคงเชื่อถือได้แม้จะมีการอัปเดตใหม่ๆ เกิดขึ้น
ลักษณะสำคัญ
| ลักษณะเฉพาะ | Descriptไอออน | ประโยชน์ |
|---|---|---|
| การวิเคราะห์ผลกระทบ | การประเมินผลกระทบต่อผู้ใช้ ระบบ และการอ้างอิง | ลดความล้มเหลวที่ไม่คาดคิด |
| คณะกรรมการที่ปรึกษา Review | การอนุมัติจากหลายทีม | ปรับปรุงความรับผิดชอบ |
| การตรวจสอบการทดสอบ | การจัดฉาก การถดถอย และการทดสอบควัน | รับประกันความน่าเชื่อถือ |
| แผนการย้อนกลับ | ขั้นตอนการย้อนกลับที่ได้รับการบันทึกไว้ | รับประกันการฟื้นตัว |
| หลังการดำเนินการ Review | ประเมินความสำเร็จหรือปัญหา | เสริมสร้างการเปลี่ยนแปลงในอนาคต |
ตัวอย่าง: การอัปเกรดเวอร์ชันฐานข้อมูลจะต้องมีสคริปต์ย้อนกลับเพื่อคืนค่าโครงร่างก่อนหน้าหากตรวจพบการลดประสิทธิภาพลง
27) คุณกำหนดลำดับความสำคัญของเหตุการณ์อย่างไรเมื่อต้องจัดการตั๋วหลายใบในเวลาเดียวกัน?
การจัดลำดับความสำคัญของเหตุการณ์จำเป็นต้องประเมินผลกระทบ ความเร่งด่วน บริการที่ได้รับผลกระทบ ข้อตกลง SLA และมูลค่าทางธุรกิจ การจำแนกระดับความรุนแรงจะเป็นแนวทางในการตัดสินใจเมื่อเกิดปัญหาหลายอย่างพร้อมกัน
เกณฑ์การกำหนดลำดับความสำคัญ
- ผลกระทบ: จำนวนผู้ใช้หรือระบบที่ได้รับผลกระทบ
- ความเร่งด่วน: ปัญหาจะต้องได้รับการแก้ไขอย่างรวดเร็ว
- ไทม์ไลน์ SLA: การจำแนกประเภท P1, P2, P3
- ปัจจัยทางธุรกิจ: Revผลกระทบต่อ enue ความเสี่ยงด้านการปฏิบัติตาม
- อ้างอิง: ไม่ว่าปัญหาจะขัดขวางงานอื่นหรือไม่
ตัวอย่าง: การหยุดการผลิตที่ขัดขวางการเข้าสู่ระบบของลูกค้าได้รับความสำคัญเหนือกว่าข้อผิดพลาด UI ของผู้ใช้รายเดียว เนื่องจากรายได้และประสบการณ์ของผู้ใช้ได้รับผลกระทบอย่างมาก
28) วิศวกรสนับสนุนแอปพลิเคชันดำเนินการกิจกรรมการบำรุงรักษาประเภทต่างๆ อะไรบ้าง?
กิจกรรมการบำรุงรักษาช่วยให้มั่นใจได้ถึงความน่าเชื่อถือ ความปลอดภัย และประสิทธิภาพของระบบ งานเหล่านี้เป็นส่วนหนึ่งของวงจรชีวิตการดำเนินงานและป้องกันความผิดพลาดที่ไม่คาดคิด
ประเภทของการบำรุงรักษา
| ประเภท | Descriptไอออน | ตัวอย่าง |
|---|---|---|
| ป้องกัน | หลีกเลี่ยงปัญหาที่อาจเกิดขึ้น | การล้างข้อมูลบันทึก การแก้ไข |
| แก้ไข | แก้ไขปัญหาที่มีอยู่ | แก้ไขปัญหาหน่วยความจำรั่วไหล |
| ปรับได้ | สนับสนุนการเปลี่ยนแปลงสิ่งแวดล้อม | การอัปเดตจุดสิ้นสุด API |
| สมบูรณ์แบบ | ปรับปรุงประสิทธิภาพหรือการใช้งาน | การเพิ่มประสิทธิภาพดัชนี |
ตัวอย่าง: การอัปเดตใบรับรอง SSL ก่อนหมดอายุเป็นกิจกรรมเชิงป้องกันที่ช่วยหลีกเลี่ยงการหยุดให้บริการ
29) คุณดำเนินการอย่างไรเพื่อรองรับแอปพลิเคชันในช่วงที่มีปริมาณการใช้งานสูงหรือโหลดตามฤดูกาลเพิ่มขึ้น?
การสนับสนุนสถานการณ์ที่มีปริมาณการใช้งานสูงจำเป็นต้องมีการวางแผนเชิงรุก การทดสอบความเครียด กลยุทธ์การปรับขนาด และการตรวจสอบแบบเรียลไทม์ จำเป็นต้องระบุจุดคอขวดด้านประสิทธิภาพก่อนช่วงที่มีโหลดสูงสุด
การเตรียมการสำหรับการจราจรติดขัด
- ดำเนินการทดสอบโหลดและความเครียด เพื่อกำหนดเกณฑ์
- ใช้งานการปรับขนาดอัตโนมัติ เพื่อจัดการกับความต้องการที่ไม่คาดคิด
- เพิ่มประสิทธิภาพกลยุทธ์การแคช เพื่อลดภาระงานแบ็คเอนด์
- ตรวจสอบความยาวของคิว เวลาตอบสนอง และการทำงานพร้อมกัน
- ประสานงานกับทีมโครงสร้างพื้นฐาน เพื่อการวางแผนกำลังการผลิต
ตัวอย่าง: แพลตฟอร์มอีคอมเมิร์ซอาจเพิ่มทรัพยากรการประมวลผลเป็นสองเท่าในช่วง Black Friday เพื่อป้องกันความล่าช้าในการชำระเงิน
30) คุณจัดการและ track การเปลี่ยนแปลงการกำหนดค่าในสภาพแวดล้อมต่างๆ?
การจัดการการเปลี่ยนแปลงการกำหนดค่าจำเป็นต้องมีการควบคุมเวอร์ชัน เวิร์กโฟลว์การอนุมัติ และขั้นตอนการปรับใช้ที่สอดคล้องกัน กระบวนการที่มีโครงสร้างช่วยรับประกันความสมบูรณ์ หลีกเลี่ยงความคลาดเคลื่อนของการกำหนดค่า และรักษาพฤติกรรมที่คาดการณ์ได้ตลอดการพัฒนา การควบคุมคุณภาพ การใช้งานจริง (UAT) และการใช้งานจริง
ปฏิบัติที่ดีที่สุด
- จัดเก็บไฟล์การกำหนดค่า ใน Git หรือที่เก็บข้อมูลที่คล้ายกัน
- ใช้โครงสร้างพื้นฐานแบบ Infrastructure-as-Code (ไอเอซี) เพื่อความสม่ำเสมอของสิ่งแวดล้อม
- ประวัติการเปลี่ยนแปลงเอกสาร และการอนุมัติ
- ปรับใช้อัตโนมัติ โดยใช้เครื่องมือ CI/CD
- ตรวจสอบผลรวมตรวจสอบ เพื่อตรวจจับการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต
ตัวอย่าง: ความไม่ตรงกันของเอนด์พอยต์ API URLข้อผิดพลาดระหว่างขั้นตอน QA และการผลิตมักเกิดจากการแก้ไขไฟล์การกำหนดค่าด้วยตนเอง แทนที่จะใช้กระบวนการอัตโนมัติ
31) คุณดำเนินการอย่างไรเมื่อแอปพลิเคชันไม่ตอบสนองหรือค้างกะทันหัน?
เมื่อแอปพลิเคชันไม่ตอบสนอง วัตถุประสงค์คือการตรวจสอบอย่างรวดเร็วว่าปัญหาเกิดจากทรัพยากรหมด ภาวะเดดล็อก ปัญหาการกำหนดค่า หรือปัญหาการพึ่งพาภายนอก การตรวจสอบเริ่มต้นด้วยการตรวจสอบว่าแอปพลิเคชันทั้งหมดได้รับผลกระทบหรือไม่ หรือได้รับผลกระทบเฉพาะโมดูลหรืออินสแตนซ์ใดอินสแตนซ์หนึ่ง Revเมตริกของระบบ iewing มีความสำคัญอย่างยิ่งต่อการกำหนด CPU spikes, การรั่วไหลของหน่วยความจำ หรือข้อจำกัด I/O โดยทั่วไปแล้ว บันทึกจะเปิดเผยเดดล็อกของเธรด ข้อยกเว้นที่ไม่ได้รับการจัดการ หรือกระบวนการที่ถูกบล็อก
การดำเนินการที่สำคัญ
- ตรวจสอบบันทึกเซิร์ฟเวอร์แอปพลิเคชันสำหรับการถ่ายโอนข้อมูลเธรดหรือข้อยกเว้น
- ตรวจสอบพฤติกรรมรันไทม์ของ JVM หรือ .NET เพื่อหาปัญหาการรวบรวมขยะ
- ตรวจสอบการอ้างอิงภายนอก เช่น ฐานข้อมูล แคช หรือ API
- เริ่มบริการใหม่อีกครั้งหลังจากบันทึกการวินิจฉัยแล้วเท่านั้น
ตัวอย่าง: A Java แอปพลิเคชันอาจหยุดทำงานเนื่องจากเธรดล็อก ซึ่งมองเห็นได้ในการดัมพ์เธรดที่แสดงกระบวนการสองกระบวนการที่กำลังรอการล็อกของกันและกัน
32) คุณสนับสนุนแอปพลิเคชันที่ใช้คิวข้อความเช่น RabbitMQ, SQS, Kafka หรือ ActiveMQ ได้อย่างไร
การสนับสนุนแอปพลิเคชันที่ใช้คิวข้อความจำเป็นต้องเข้าใจถึงปฏิสัมพันธ์ระหว่างผู้ผลิต ผู้บริโภค และโบรกเกอร์ภายในวงจรชีวิตของข้อความ ความล้มเหลวมักเกิดจากข้อความที่ไม่ได้รับการประมวลผล ความผิดพลาดของผู้บริโภค การกำหนดค่าคีย์การกำหนดเส้นทางไม่ถูกต้อง หรือขนาดคิวถึงขีดจำกัด การตรวจสอบสถานะของคิว ความล่าช้าของผู้บริโภค และพฤติกรรมการลองใหม่จึงเป็นสิ่งสำคัญอย่างยิ่ง
กิจกรรมสนับสนุน
- ตรวจสอบข้อความค้างและความหน่วงของผู้บริโภค
- การตรวจสอบคิวจดหมายที่ส่งไม่ถึง (DLQ) สำหรับรูปแบบความล้มเหลว
- การรับรองการอนุญาตและรหัสการเข้าถึงที่ถูกต้อง
- การตรวจสอบข้อมูลปริมาณงานและการตั้งค่าการคงอยู่
- การเริ่มต้นใหม่หรือการปรับขนาดผู้บริโภคเมื่อจำเป็น
ตัวอย่าง: ความล่าช้าของผู้บริโภค Kafka อาจเพิ่มสูงขึ้นเนื่องจากเธรดผู้บริโภคไม่เพียงพอ ซึ่งจำเป็นต้องมีการปรับขนาดเพื่อรักษาการประมวลผลแบบเรียลไทม์
33) มีวิธีการใดบ้างที่แตกต่างกันในการทำให้การทำงานที่เกิดขึ้นซ้ำๆ ในระบบสนับสนุนแอปพลิเคชันเป็นแบบอัตโนมัติ
ระบบอัตโนมัติช่วยลดภาระงานด้วยตนเอง ขจัดข้อผิดพลาดจากมนุษย์ และเพิ่มความสม่ำเสมอในกระบวนการปฏิบัติงาน มีระบบอัตโนมัติหลายประเภทที่เหมาะกับเวิร์กโฟลว์สนับสนุน
ประเภทของระบบอัตโนมัติ
| ประเภท | จุดมุ่งหมาย | ตัวอย่าง |
|---|---|---|
| การเขียนสคริปต์ | งานประจำ | สคริปต์การหมุนบันทึก |
| ท่อ CI / CD | การปรับใช้อัตโนมัติ | Jenkins สร้าง |
| ระบบอัตโนมัติโครงสร้างพื้นฐาน | ระบบการจัดเตรียม | สคริปต์ Terraform |
| การแจ้งเตือนอัตโนมัติ | การแก้ไขอัตโนมัติ | รีสตาร์ทเมื่อ CPU พุ่งสูง |
ตัวอย่าง: การล้างไฟล์แคชชั่วคราวโดยอัตโนมัติโดยใช้ cron job ช่วยป้องกันปัญหาการจัดเก็บข้อมูลที่เกิดขึ้นซ้ำโดยไม่ต้องดำเนินการด้วยตนเอง
34) เมื่อบันทึกไม่ได้ให้ข้อมูลเพียงพอ คุณสามารถใช้เทคนิคเพิ่มเติมใดในการวินิจฉัยปัญหาได้บ้าง
บันทึกข้อมูลมีความสำคัญ แต่บางครั้งก็ขาดรายละเอียดที่จำเป็นต่อการทำความเข้าใจความล้มเหลวที่ซับซ้อน วิศวกรจึงต้องหันไปใช้เครื่องมือวิเคราะห์โปรไฟล์และเครื่องมือเครือข่าย tracเครื่องมือตรวจสอบการรับส่งข้อมูล เช่น การบันทึกข้อมูลแพ็กเก็ต หรือเครื่องมือดีบัก การใช้การตรวจสอบแบบจำลองช่วยจำลองขั้นตอนการใช้งานของผู้ใช้เพื่อจำลองปัญหาได้
เทคนิคเพิ่มเติม
- โปรไฟล์เลอร์: การวิเคราะห์ CPU, ฮีป และเธรด
- การถ่ายโอนข้อมูลแบบกอง: ตรวจสอบการรั่วไหลของหน่วยความจำหรือการเก็บรักษาวัตถุ
- การจับแพ็คเก็ตเครือข่าย: ระบุความล่าช้าหรือแพ็กเก็ตที่สูญหาย
- Tracเครื่องมือ: กระจาย tracสำหรับไมโครเซอร์วิส
- สลับคุณสมบัติ: เปิดใช้งานคุณสมบัติระดับการแก้ไขจุดบกพร่องชั่วคราว
ตัวอย่าง: การรั่วไหลของหน่วยความจำอาจต้องใช้การวิเคราะห์ข้อมูลดัมพ์ฮีปโดยใช้ VisualVM หรือ YourKit แทนที่จะพึ่งพาบันทึกเพียงอย่างเดียว
35) กลยุทธ์ใดช่วยให้แน่ใจว่าข้อมูลมีความสอดคล้องกันในระบบแบบกระจาย?
ความสอดคล้องของข้อมูลกลายเป็นเรื่องท้าทายเมื่อแอปพลิเคชันทำงานบนฐานข้อมูลแบบกระจาย ไมโครเซอร์วิส และระบบส่งข้อความแบบอะซิงโครนัส การรับรองความถูกต้องของข้อมูลต้องอาศัยการผสมผสานระหว่างตัวเลือกด้านสถาปัตยกรรม ตรรกะการตรวจสอบ และแนวปฏิบัติในการดำเนินงาน
กลยุทธ์ที่สำคัญ
- การดำเนินการอุดมคติ เพื่อหลีกเลี่ยงการอัปเดตซ้ำ
- แบบจำลองความสอดคล้องในที่สุด ด้วยตรรกะแห่งการปรองดอง
- Atomธุรกรรม ic หรือการยืนยันแบบ 2 เฟส สำหรับเวิร์กโฟลว์ที่สำคัญ
- การกำหนดเวอร์ชันของโครงร่าง ข้ามบริการ
- เส้นทางการตรวจสอบ สำหรับ tracความสามารถ
ตัวอย่าง: ในระบบการสั่งซื้อ API ที่มีคุณสมบัติเหมาะสมจะป้องกันการเรียกเก็บเงินซ้ำเมื่อมีการลองคำขอชำระเงินใหม่เนื่องจากความล้มเหลวของเครือข่าย
36) บทบาทของ Runbooks คืออะไร และเหตุใดจึงมีความสำคัญในการสนับสนุนการปฏิบัติการ?
Runbooks คือเอกสารมาตรฐานที่สรุปขั้นตอนการแก้ไขปัญหา การดำเนินงาน หรือการตอบสนองต่อเหตุการณ์เฉพาะอย่างทีละขั้นตอน Runbooks ช่วยลดการพึ่งพาความเชี่ยวชาญเฉพาะบุคคล และช่วยให้มั่นใจว่าทีมต่างๆ ปฏิบัติตามขั้นตอนต่างๆ อย่างสม่ำเสมอ นอกจากนี้ Runbooks ยังช่วยลดข้อผิดพลาดในสถานการณ์เร่งด่วนด้วยการให้คำแนะนำที่ชัดเจน
ประโยชน์ของรันบุ๊กส์
- การรับวิศวกรใหม่เข้ามาทำงานได้เร็วขึ้น
- ลดเวลาในการแก้ไขปัญหาเนื่องจากมีขั้นตอนที่กำหนดไว้ล่วงหน้า
- การปฏิบัติตามและความพร้อมในการตรวจสอบที่ดีขึ้น
- การสร้างมาตรฐานการปฏิบัติงาน
ตัวอย่าง: รันบุ๊กสำหรับ "Database CPU Spike" อาจรวมถึงแบบสอบถามเพื่อระบุกระบวนการหนัก ขั้นตอนในการปรับแต่งแบบสอบถาม และขั้นตอนการยกระดับ
37) คุณประเมินประสิทธิภาพของการเผยแพร่ใหม่หลังการปรับใช้ได้อย่างไร
การประเมินประสิทธิภาพการเผยแพร่ประกอบด้วยการตรวจสอบความสมบูรณ์ของฟังก์ชัน การตรวจสอบตัวชี้วัดประสิทธิภาพ การตรวจสอบอัตราข้อผิดพลาด และการยืนยันความเสถียรภายใต้ภาระงานทั่วไป การประเมินนี้มีความสำคัญอย่างยิ่งเพื่อตรวจสอบว่าโค้ดใหม่ทำงานตามที่คาดหวังและไม่ทำให้เกิดการถดถอย
วิธีการประเมินผล
- เปรียบเทียบเมตริกก่อนการปรับใช้และหลังการปรับใช้
- ดำเนินการทดสอบควันและตรวจสอบความสมเหตุสมผล
- ตรวจสอบบันทึกสำหรับคำเตือนหรือข้อผิดพลาดใหม่
- Revดูแดชบอร์ด APM เพื่อดูการเปลี่ยนแปลงเวลาตอบสนอง
- ตรวจสอบอัตราข้อผิดพลาดและแนวโน้มเซสชันของผู้ใช้
ตัวอย่าง: หลังจากปรับใช้บริการการค้นหาใหม่ วิศวกรอาจตรวจสอบความล่าช้าของการค้นหาและอัตราความสำเร็จเพื่อให้แน่ใจว่าประสิทธิภาพไม่ลดลง
38) ควรกำหนดค่าการแจ้งเตือนประเภทต่างๆ อะไรบ้างในระบบการผลิต?
การแจ้งเตือนที่มีประสิทธิภาพช่วยให้มั่นใจได้ว่าปัญหาจะถูกตรวจพบตั้งแต่เนิ่นๆ ช่วยให้สามารถแก้ไขได้อย่างรวดเร็ว การแจ้งเตือนต้องจัดโครงสร้างให้ครอบคลุมหมวดหมู่ต่างๆ เพื่อให้มองเห็นได้ชัดเจน
ประเภทการแจ้งเตือน
| Category | ตัวอย่าง |
|---|---|
| การแจ้งเตือนประสิทธิภาพ | เวลาตอบสนองสูง, การค้นหาช้า |
| การแจ้งเตือนโครงสร้างพื้นฐาน | ขีดจำกัดของ CPU, หน่วยความจำ, ดิสก์ |
| การแจ้งเตือนข้อผิดพลาด | เพิ่มข้อผิดพลาด 5xx ข้อยกเว้น |
| การแจ้งเตือนความปลอดภัย | ความพยายามในการเข้าถึงโดยไม่ได้รับอนุญาต |
| การแจ้งเตือนความจุ | ขนาดคิว, ขีดจำกัดการเก็บข้อมูล |
ตัวอย่าง: การเพิ่มขึ้นอย่างรวดเร็วของข้อผิดพลาด HTTP 500 ควรส่งการแจ้งเตือนทันที ซึ่งบ่งชี้ถึงความล้มเหลวของเซิร์ฟเวอร์หรือการอ้างอิง
39) คุณสนับสนุนแอปพลิเคชันคอนเทนเนอร์ที่ทำงานบนแพลตฟอร์มเช่น Docker หรือ Kubernetes ได้อย่างไร
การรองรับแอปพลิเคชันแบบคอนเทนเนอร์จำเป็นต้องมีความเข้าใจเกี่ยวกับวงจรชีวิตของคอนเทนเนอร์ พฤติกรรมการประสานงาน การตรวจสอบสุขภาพ นโยบายการปรับขนาด และข้อจำกัดด้านทรัพยากร การแก้ไขปัญหาประกอบด้วยการตรวจสอบบันทึกพ็อด การตรวจสอบเหตุการณ์คอนเทนเนอร์ การวิเคราะห์การกำหนดค่า YAML และการตรวจสอบความถูกต้องของกฎเครือข่าย
งานสนับสนุนที่สำคัญ
- ตรวจสอบสถานะของพ็อด (CrashLoopBackOff, รอดำเนินการ, เสร็จสมบูรณ์)
- Revการแสดงการปรับใช้ iew สำหรับปัญหาการกำหนดค่า
- ตรวจสอบขีดจำกัดทรัพยากรคอนเทนเนอร์ (CPU, หน่วยความจำ)
- วิเคราะห์บริการและการกำหนดเส้นทางเครือข่ายพ็อด
- ใช้บันทึก เหตุการณ์ และเมตริกจาก kubectl หรือแดชบอร์ด
ตัวอย่าง: การรีสตาร์ทพ็อดซ้ำๆ อาจบ่งชี้ถึงตัวแปรสภาพแวดล้อมที่กำหนดค่าไม่ถูกต้องหรือการอ้างอิงที่ล้มเหลว ซึ่งทำให้แอปพลิเคชันออกจากระบบ
40) ข้อดีและข้อเสียของการใช้ API ของบุคคลที่สามในแอปพลิเคชันคืออะไร
API ของบุคคลที่สามขยายฟังก์ชันการทำงานของแอปพลิเคชัน แต่เพิ่มการพึ่งพาในการดำเนินงาน วิศวกรต้องประเมินประสิทธิภาพ ความพร้อมใช้งาน ความปลอดภัย และผลกระทบต่อวงจรชีวิตของเวอร์ชัน
ตารางเปรียบเทียบ
| แง่มุม | ข้อดี | ข้อเสีย |
|---|---|---|
| ราคา | ลดความพยายามในการพัฒนา | ค่าธรรมเนียมที่อาจเกิดขึ้นต่อเนื่อง |
| ฟังก์ชั่น | เพิ่มคุณสมบัติได้อย่างรวดเร็ว | การปรับแต่งแบบ จำกัด |
| ความพร้อมที่จะให้บริการ | บริการผู้ให้บริการที่ปรับขนาดได้ | ไฟดับเกินการควบคุมของคุณ |
| ความปลอดภัย | การปฏิบัติตามข้อกำหนดของผู้ให้บริการ | จะต้องจัดการคีย์ API |
ตัวอย่าง: API การชำระเงินอาจช่วยลดความซับซ้อนของการประมวลผลธุรกรรม แต่หากผู้ให้บริการประสบปัญหาหยุดทำงาน กระบวนการชำระเงินของแอปพลิเคชันของคุณอาจล้มเหลวได้
41) คุณใช้เทคนิคใดในการวิเคราะห์และปรับแต่งแบบสอบถาม SQL ที่ช้า?
การวิเคราะห์คิวรี SQL ที่ช้าเริ่มต้นด้วยการตรวจสอบแผนการดำเนินการ การระบุดัชนีที่หายไป และการตรวจสอบว่าคิวรีกำลังสแกนแถวที่ไม่จำเป็นหรือไม่ ประสิทธิภาพการทำงานที่ลดลงมักเป็นผลมาจากการออกแบบ schema ที่ไม่ดี การรวมข้อมูลที่ไม่ได้รับการปรับให้เหมาะสม หรือการกรองข้อมูลที่ไม่มีประสิทธิภาพ วิศวกรต้องประเมินจำนวนเชิงซ้อน การกระจายข้อมูล สถิติของตาราง และกลไกการแคช การปรับแต่งคิวรีเป็นวงจรชีวิตแบบวนซ้ำที่ต้องอาศัยความร่วมมือจากผู้ดูแลฐานข้อมูล (DBA) และนักพัฒนา
เทคนิคการปรับแต่ง SQL
- รีวิว อธิบาย/ดำเนินการ แผนรับมือกับปัญหาคอขวด
- เพิ่มหรือปรับเปลี่ยน ดัชนี เพื่อลดการสแกนตารางเต็ม
- เขียนแบบสอบถามใหม่โดยใช้ สมัคร, WHEREหรือ แบบสอบถามย่อย การปรับปรุง
- Archiลบข้อมูลเก่าเพื่อลดขนาดชุดข้อมูล
- วิเคราะห์เมตริก DB เช่น การรอล็อคและอัตราการเข้าถึงแคชบัฟเฟอร์
ตัวอย่าง: การดำเนินการค้นหาแบบสแกนเต็มรูปแบบบนตาราง 5 ล้านแถวได้รับการปรับปรุงอย่างมากหลังจากเพิ่มดัชนีผสมบน customer_id และ status
42) คุณจัดการกับการรองรับแอปพลิเคชันเก่าที่ขาดเอกสารหรือมีเทคโนโลยีล้าสมัยอย่างไร
แอปพลิเคชันรุ่นเก่าสร้างความท้าทายเนื่องจากเอกสารประกอบที่จำกัด ไลบรารีที่ล้าสมัย และพฤติกรรมที่ไม่เสถียร การรองรับแอปพลิเคชันรุ่นเก่าต้องอาศัยความอดทน วิศวกรรมย้อนกลับ และการรวบรวมความรู้ที่มีโครงสร้าง เป้าหมายคือการสร้างเสถียรภาพให้กับแอปพลิเคชันควบคู่ไปกับการวางแผนการปรับปรุงให้ทันสมัยในระยะยาว
กลยุทธ์การสนับสนุน
- จัดทำแผนที่คุณลักษณะต่างๆ ผ่านการวิเคราะห์บันทึกและการสัมภาษณ์ผู้ใช้
- สร้างเอกสารใหม่เป็นระยะๆ ขณะที่คุณเรียนรู้กระบวนการต่างๆ
- ใช้เครื่องมือตรวจสอบเพื่อระบุรูปแบบความล้มเหลว
- นำ wrapper หรืออะแดปเตอร์มาใช้งานเพื่อเชื่อมต่ออินเทอร์เฟซที่ล้าสมัย
- ประสานงานกับสถาปนิกเกี่ยวกับแผนงานการปรับปรุงให้ทันสมัย
ตัวอย่าง: การรองรับแอปพลิเคชัน VB6 รุ่นเก่าอาจต้องสร้างยูทิลิตี้การบันทึกข้อมูลภายนอก เนื่องจากการวินิจฉัยในตัวไม่เพียงพอ
43) ความล้มเหลวที่เกี่ยวข้องกับการกำหนดค่าประเภททั่วไปมีอะไรบ้าง และคุณจะแก้ไขปัญหาเหล่านั้นได้อย่างไร
ข้อผิดพลาดในการกำหนดค่ามักเกิดจากตัวแปรสภาพแวดล้อมที่ไม่ตรงกัน เส้นทางไฟล์ไม่ถูกต้อง ใบรับรองหายไป หรือจุดสิ้นสุด API ไม่ถูกต้อง ความล้มเหลวเหล่านี้มักเกิดขึ้นระหว่างการปรับใช้หรือการเปลี่ยนสภาพแวดล้อม การแก้ไขปัญหาจำเป็นต้องเปรียบเทียบการกำหนดค่าที่ใช้งานได้และใช้งานไม่ได้ การตรวจสอบประวัติการควบคุมเวอร์ชัน และการตรวจสอบความถูกต้องของพารามิเตอร์เฉพาะสภาพแวดล้อม
ประเภทความล้มเหลวในการกำหนดค่า
| ประเภท | Descriptไอออน | ตัวอย่าง |
|---|---|---|
| ความไม่ตรงกันของสภาพแวดล้อม | ผิด URLชื่อ s หรือ DB | การกำหนดค่า QA DB ใน Prod |
| ข้อผิดพลาดเกี่ยวกับข้อมูลประจำตัว | คีย์ API หรือรหัสผ่านไม่ถูกต้อง | โทเค็นที่หมดอายุ |
| ปัญหาเส้นทางไฟล์ | การอ้างอิงไดเรกทอรีไม่ถูกต้อง | ไดเรกทอรีบันทึกที่หายไป |
| ประเด็นเรื่องใบรับรอง | ใบรับรองหมดอายุหรือไม่ตรงกัน | ความล้มเหลวในการจับมือ HTTPS |
ตัวอย่าง: หากแอปพลิเคชันไม่สามารถเข้าถึง API ภายนอกได้อย่างกะทันหัน การตรวจสอบไฟล์การกำหนดค่าอาจเปิดเผยจุดสิ้นสุดที่เปลี่ยนแปลงล่าสุดและไม่ถูกต้อง
44) คุณวัดและปรับปรุงเวลาเฉลี่ยในการแก้ปัญหา (MTTR) ในการดำเนินการสนับสนุนได้อย่างไร
MTTR เป็นตัวชี้วัดประสิทธิภาพหลักที่สะท้อนถึงประสิทธิภาพของการจัดการเหตุการณ์ การปรับปรุง MTTR จำเป็นต้องอาศัยการผสมผสานระหว่างเครื่องมือที่ดีขึ้น เอกสารประกอบที่แข็งแกร่งขึ้น และการวินิจฉัยที่รวดเร็วขึ้น เวิร์กโฟลว์ที่คล่องตัวช่วยลดระยะเวลาหยุดทำงาน ลดต้นทุนทางธุรกิจ และเพิ่มความพึงพอใจของลูกค้า
วิธีการปรับปรุง MTTR
- นำ Runbooks ที่มีโครงสร้างมาใช้กับประเภทเหตุการณ์ที่เกิดซ้ำ
- เพิ่มรายละเอียดการตรวจสอบเพื่อตรวจจับสาเหตุหลักได้เร็วขึ้น
- แนะนำระบบอัตโนมัติสำหรับขั้นตอนการกู้คืนทั่วไป
- จัดให้มีการฝึกอบรมเป็นประจำสำหรับทีมระดับ 1 และระดับ 2
- ดำเนินการชันสูตรพลิกศพอย่างไม่มีข้อผิดพลาดเพื่อรวบรวมข้อมูลเชิงลึกเพื่อการปรับปรุง
ตัวอย่าง: การเพิ่มการทำงานอัตโนมัติของเธรดดัมพ์ระหว่างการหยุดการทำงานของ JVM สามารถลดเวลาในการวินิจฉัยระหว่างเหตุการณ์ที่เกิดขึ้นในการผลิตได้อย่างมาก
45) แนวทางปฏิบัติด้านความปลอดภัยใดบ้างที่จำเป็นต่อการรองรับแอปพลิเคชันที่สำคัญต่อธุรกิจ
ความปลอดภัยต้องผสานรวมเข้ากับทุกขั้นตอนของวงจรชีวิตการสนับสนุน วิศวกรสนับสนุนแอปพลิเคชันต้องมั่นใจว่าการอัปเดต การกำหนดค่า และกระบวนการเข้าถึงของผู้ใช้สอดคล้องกับมาตรฐานความปลอดภัย การตรวจสอบสิทธิ์ที่เข้มงวด การปกป้องข้อมูล และการจัดการช่องโหว่ ถือเป็นองค์ประกอบสำคัญ
แนวทางปฏิบัติด้านความปลอดภัยที่สำคัญ
- บังคับใช้ สิทธิพิเศษน้อยที่สุด การควบคุมการเข้าถึง.
- หมุนเวียนข้อมูลประจำตัวและคีย์ API เป็นประจำ
- ใช้แพทช์ทันทีเพื่อลดความเสี่ยง
- ตรวจสอบกิจกรรมที่น่าสงสัยและความพยายามเข้าสู่ระบบที่ล้มเหลว
- เข้ารหัสข้อมูลที่ละเอียดอ่อนในระหว่างการส่งและขณะพัก
ตัวอย่าง: การนำ MFA มาใช้กับบัญชีผู้ดูแลระบบช่วยลดความเสี่ยงในการเข้าถึงโดยไม่ได้รับอนุญาตได้อย่างมาก
46) คุณจะตรวจสอบปัญหาที่เกิดขึ้นเป็นระยะๆ ที่ไม่ได้เกิดขึ้นอย่างสม่ำเสมอได้อย่างไร
ปัญหาที่เกิดขึ้นเป็นระยะๆ จำเป็นต้องใช้วิธีการสืบสวนแบบอิงตามรูปแบบ เนื่องจากไม่สามารถจำลองปัญหาเหล่านั้นได้ตามต้องการเสมอไป วิศวกรจึงต้องอาศัยการบันทึกข้อมูลและตัวชี้วัดอย่างละเอียด tracเครื่องมือวิเคราะห์และสหสัมพันธ์เพื่อตรวจจับตัวกระตุ้นและความสัมพันธ์ด้านเวลา
แนวทางการสืบสวน
- เปรียบเทียบบันทึกระหว่างธุรกรรมที่ประสบความสำเร็จและล้มเหลว
- เปิดใช้งานการบันทึกระดับการดีบักชั่วคราว
- เพิ่มการตรวจสอบสังเคราะห์เพื่อสร้างเงื่อนไขซ้ำ
- Track รูปแบบตามเวลา (เช่น ทุกชั่วโมง หรือภายใต้ภาระงาน)
- วิเคราะห์เมตริกโครงสร้างพื้นฐานเพื่อหาจุดพุ่งสูงหรือความผิดปกติ
ตัวอย่าง: บริการที่ล้มเหลวเฉพาะในช่วงที่มีปริมาณการรับส่งข้อมูลสูงสุดอาจเผยให้เห็นการแย่งชิงทรัพยากรพื้นฐานเมื่อการใช้งาน CPU และหน่วยความจำมีความสัมพันธ์กับข้อผิดพลาด
47) มีวิธีการอื่นใดบ้างที่คุณสามารถรับรองการย้อนกลับอย่างปลอดภัยระหว่างการปรับใช้ที่ล้มเหลว?
กลยุทธ์การย้อนกลับที่ปลอดภัยจะช่วยลดระยะเวลาการหยุดทำงานและป้องกันความเสียหายของข้อมูล การวางแผนเริ่มต้นในระหว่างวงจรชีวิตการออกแบบการเปลี่ยนแปลง และรวมถึงกลไกการสำรองข้อมูล การควบคุมเวอร์ชัน และสคริปต์การปรับใช้อัตโนมัติ
แนวทางปฏิบัติด้านความปลอดภัยแบบย้อนกลับ
- เก็บรักษา สิ่งประดิษฐ์ที่มีเวอร์ชัน เพื่อการปรับใช้ใหม่ที่รวดเร็ว
- สร้างการสำรองฐานข้อมูลหรือสแนปช็อตของโครงร่าง
- ใช้การสลับคุณสมบัติเพื่อปิดการใช้งานฟังก์ชันใหม่ทันที
- ตรวจสอบคำสั่งย้อนกลับในสภาพแวดล้อมการจัดเตรียม
- ความเสี่ยงและการพึ่งพาในการย้อนกลับเอกสาร
ตัวอย่าง: การปรับใช้ไมโครเซอร์วิสที่ล้มเหลวสามารถย้อนกลับได้โดยการปรับใช้ Docker image ก่อนหน้าอีกครั้ง ซึ่งจะคืนค่าบริการปกติทันที
48) ลักษณะเฉพาะของกระบวนการทำงานร่วมกันข้ามสายงานที่แข็งแกร่งใน Application Support มีอะไรบ้าง
การสนับสนุนที่มีประสิทธิภาพต้องอาศัยการทำงานเป็นทีมระหว่างกลุ่มพัฒนา ฝ่ายประกันคุณภาพ ฝ่ายรักษาความปลอดภัย ฝ่ายโครงสร้างพื้นฐาน และฝ่ายจัดการผลิตภัณฑ์ การทำงานร่วมกันข้ามสายงานช่วยให้การแก้ไขปัญหารวดเร็วขึ้น ลดขั้นตอนการทำงาน และคาดการณ์ผลลัพธ์ได้แม่นยำยิ่งขึ้น
ลักษณะ
- ความเป็นเจ้าของและเส้นทางการยกระดับที่ชัดเจน
- การสื่อสารที่โปร่งใสในห้องสงครามหรือสะพานเชื่อมโยงเหตุการณ์
- แดชบอร์ดและเอกสารการติดตามที่ใช้ร่วมกัน
- เซสชัน RCA แบบร่วมมือที่มีผลลัพธ์ที่สามารถดำเนินการได้
- ความเคารพซึ่งกันและกันและแบ่งปันความรู้
ตัวอย่าง: ระหว่างการหยุดให้บริการ P1 การมีทีมพัฒนาและโครงสร้างพื้นฐานที่พร้อมใช้งานบนสะพานเดียวจะช่วยลดความล่าช้าและปรับปรุงการประสานงาน
49) คุณจัดการเซสชัน คุกกี้ และโทเค็นการตรวจสอบสิทธิ์อย่างไรเมื่อแก้ไขปัญหาการเข้าสู่ระบบ?
ปัญหาที่เกี่ยวข้องกับการพิสูจน์ตัวตนมักเกิดจากโทเค็นหมดอายุ ที่เก็บเซสชันที่กำหนดค่าไม่ถูกต้อง ปัญหาแคชของเบราว์เซอร์ หรือความคลาดเคลื่อนของสัญญาณนาฬิกาในระบบต่างๆ วิศวกรต้องตรวจสอบพฤติกรรมทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์
การตรวจสอบการแก้ไขปัญหาที่สำคัญ
- ตรวจสอบวันหมดอายุและลายเซ็นของโทเค็น
- ตรวจสอบความพร้อมใช้งานของร้านค้าเซสชัน (Redis, Memcached)
- Revตรวจสอบการตั้งค่าคุกกี้ของเบราว์เซอร์ เช่น SameSite, HttpOnly, Secure
- ยืนยันบทบาทของผู้ใช้และสถานะบัญชี
- Syncกำหนดเวลาการทำงานของระบบเพื่อป้องกันความล้มเหลวในการตรวจสอบโทเค็น
ตัวอย่าง: ความล้มเหลวในการเข้าสู่ระบบที่เกิดจากความคลาดเคลื่อนของนาฬิกา 5 นาทีสามารถทำให้ลายเซ็น JWT ไม่ถูกต้อง ส่งผลให้การตรวจสอบสิทธิ์ล้มเหลว
50) แพลตฟอร์มออร์เคสเตรชั่นคอนเทนเนอร์ (เช่น Kubernetes) มีข้อดีและข้อเสียอะไรบ้างสำหรับการสนับสนุนแอปพลิเคชัน
แพลตฟอร์มออร์เคสเตรชันคอนเทนเนอร์มีความสามารถในการปรับขนาด การทำงานอัตโนมัติ และความสามารถในการซ่อมแซมตัวเองได้ แต่ก็มีความซับซ้อนด้วยเช่นกัน ทีมสนับสนุนต้องเข้าใจรายการการใช้งาน การตรวจสอบสุขภาพ โควต้าทรัพยากร และโมเดลเครือข่าย เพื่อวินิจฉัยปัญหา
ข้อดีและข้อเสีย
| Category | ข้อดี | ข้อเสีย |
|---|---|---|
| scalability | ปรับขนาดอัตโนมัติ | การตั้งค่าที่ซับซ้อน |
| ความเชื่อถือได้ | ฝักรักษาตัวเอง | การดีบักที่ยากขึ้น |
| การใช้งาน | การเปิดตัวที่รวดเร็วยิ่งขึ้น | การกำหนดค่า YAML ไม่ถูกต้อง |
| การใช้ทรัพยากร | การใช้ประโยชน์อย่างมีประสิทธิภาพ | ต้องมีความสามารถในการสังเกตที่แข็งแกร่ง |
ตัวอย่าง: Kubernetes สามารถรีสตาร์ทคอนเทนเนอร์ที่ล้มเหลวโดยอัตโนมัติ ซึ่งช่วยลดระยะเวลาการหยุดทำงาน แต่การตรวจสอบความพร้อมใช้งาน/ความพร้อมใช้งานที่ไม่ถูกต้องอาจทำให้ต้องรีสตาร์ทไม่รู้จบ
🔍 คำถามสัมภาษณ์การสนับสนุนแอปพลิเคชันยอดนิยมพร้อมสถานการณ์จริงและคำตอบเชิงกลยุทธ์
1) คุณสามารถอธิบายได้หรือไม่ว่า Application Support เกี่ยวข้องกับอะไร และเหตุใดจึงมีความสำคัญในองค์กร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินความเข้าใจของคุณเกี่ยวกับจุดประสงค์ ขอบเขต และผลกระทบของบทบาทต่อความต่อเนื่องทางธุรกิจ
ตัวอย่างคำตอบ:
การสนับสนุนแอปพลิเคชัน (Application Support) ครอบคลุมการบำรุงรักษา ตรวจสอบ และแก้ไขปัญหาแอปพลิเคชันที่สำคัญต่อธุรกิจ เพื่อให้มั่นใจว่าการให้บริการจะราบรื่นและต่อเนื่อง การสนับสนุนแอปพลิเคชันมีความสำคัญอย่างยิ่ง เพราะส่งผลโดยตรงต่อประสบการณ์ของผู้ใช้ ประสิทธิภาพการทำงาน และประสิทธิภาพทางธุรกิจ การสนับสนุนแอปพลิเคชันที่มีประสิทธิภาพจะช่วยลดระยะเวลาหยุดทำงาน รับรองความสมบูรณ์ของข้อมูล และเพิ่มความน่าเชื่อถือของระบบ
2) คุณจะจัดลำดับความสำคัญของตั๋วการสนับสนุนหลายใบได้อย่างไรเมื่อมีผู้ใช้หลายรายรายงานปัญหาในเวลาเดียวกัน?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการทราบความสามารถของคุณในการจัดการลำดับความสำคัญที่แข่งขันกันและรักษาข้อตกลงระดับการบริการ (SLA)
ตัวอย่างคำตอบ:
ฉันจัดลำดับความสำคัญของตั๋วตามความรุนแรง ผลกระทบทางธุรกิจ และความเร่งด่วน โดยเหตุการณ์วิกฤตที่ส่งผลกระทบต่อผู้ใช้หลายรายหรือฟังก์ชันหลักของธุรกิจจะมีความสำคัญเหนือกว่า นอกจากนี้ ฉันยังสื่อสารกับผู้มีส่วนได้ส่วนเสียอย่างชัดเจนเพื่อจัดการความคาดหวังและแจ้งให้พวกเขาทราบถึงความคืบหน้าจนกว่าจะได้รับการแก้ไข
3) อธิบายเวลาที่คุณสามารถแก้ไขเหตุการณ์ร้ายแรงภายใต้แรงกดดันได้
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังมองหาหลักฐานของทักษะการแก้ปัญหา ความสงบภายใต้ความกดดัน และการทำงานเป็นทีม
ตัวอย่างคำตอบ:
ในบทบาทล่าสุดของผม แอปพลิเคชันทางการเงินหลักเกิดขัดข้องในช่วงชั่วโมงเร่งด่วน ผมจึงประสานงานกับทีมโครงสร้างพื้นฐานอย่างรวดเร็วเพื่อระบุว่าบริการฐานข้อมูลขัดข้อง เรากู้คืนระบบได้ภายใน 30 นาที และนำสคริปต์ตรวจสอบมาใช้งานเพื่อป้องกันการเกิดปัญหาซ้ำ ประสบการณ์นี้ตอกย้ำความสำคัญของการวิเคราะห์สาเหตุที่แท้จริงและการตรวจสอบเชิงรุก
4) คุณเคยใช้เครื่องมือตรวจสอบและระบบการออกตั๋วใดบ้าง?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินความคุ้นเคยของคุณกับเครื่องมือมาตรฐานอุตสาหกรรมที่ใช้ในการสนับสนุนแอปพลิเคชัน
ตัวอย่างคำตอบ:
“ฉันเคยทำงานกับ ServiceNow และ JIRA สำหรับการจัดการตั๋วและเครื่องมือต่างๆ เช่น Nagios และ Splunk สำหรับการตรวจสอบประสิทธิภาพและบันทึกของแอปพลิเคชัน เครื่องมือเหล่านี้ช่วยให้ฉันระบุปัญหาคอขวดด้านประสิทธิภาพและทำให้กระบวนการแจ้งเตือนเป็นแบบอัตโนมัติ เพื่อปรับปรุงเวลาตอบสนอง
5) คุณจัดการกับสถานการณ์ที่ผู้ใช้ปลายทางรู้สึกหงุดหงิดหรือโกรธเกี่ยวกับปัญหาที่เกิดขึ้นซ้ำๆ อย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินทักษะการบริการลูกค้า ความเห็นอกเห็นใจ และความเป็นมืออาชีพของคุณภายใต้ปฏิสัมพันธ์ที่ท้าทาย
ตัวอย่างคำตอบ:
“ผมใจเย็นและรับฟังข้อกังวลของผู้ใช้อย่างตั้งใจโดยไม่ขัดจังหวะ ผมรับทราบถึงความไม่พอใจของพวกเขาและยืนยันกับพวกเขาว่าการแก้ไขปัญหาเป็นเรื่องสำคัญที่สุด จากนั้นผมจะแจ้งความคืบหน้าที่ชัดเจนตลอดกระบวนการแก้ไขปัญหา การรักษาความโปร่งใสและความเห็นอกเห็นใจจะช่วยสร้างความไว้วางใจของผู้ใช้ขึ้นมาใหม่”
6) คุณสามารถอธิบายความแตกต่างระหว่างการจัดการเหตุการณ์และการจัดการปัญหาได้หรือไม่
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังทดสอบความเข้าใจของคุณเกี่ยวกับแนวคิด ITIL และกระบวนการสนับสนุนที่มีโครงสร้าง
ตัวอย่างคำตอบ:
การจัดการเหตุการณ์มุ่งเน้นไปที่การฟื้นฟูการให้บริการตามปกติโดยเร็วที่สุดหลังจากเกิดการหยุดชะงัก ขณะที่การจัดการปัญหามุ่งเน้นไปที่การระบุและกำจัดสาเหตุหลักของเหตุการณ์ที่เกิดขึ้นซ้ำ กระบวนการทั้งสองนี้เสริมซึ่งกันและกันเพื่อเสริมสร้างเสถียรภาพของระบบและคุณภาพการให้บริการในระยะยาว
7) บอกฉันเกี่ยวกับเวลาที่คุณดำเนินการปรับปรุงที่ลดจำนวนเหตุการณ์ที่เกิดขึ้นซ้ำ
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการเข้าใจความคิดริเริ่มของคุณในการปรับปรุงกระบวนการและการแก้ไขปัญหาเชิงรุก
ตัวอย่างคำตอบ:
ก่อนหน้านี้ เราพบข้อผิดพลาดของแอปพลิเคชันที่เกิดขึ้นซ้ำๆ เนื่องจาก API หมดเวลาใช้งานที่กำหนดค่าไม่ถูกต้อง หลังจากตรวจสอบแล้ว ผมได้เสนอการเปลี่ยนแปลงการกำหนดค่าและบันทึกการแก้ไขไว้ในฐานข้อมูลความรู้ ซึ่งช่วยลดปัญหาที่คล้ายคลึงกันได้เกือบ 40% และปรับปรุงเวลาในการตอบสนองของทีมสนับสนุน
8) คุณมั่นใจได้อย่างไรว่ามีการแบ่งปันความรู้ภายในทีมของคุณเพื่อการแก้ไขปัญหาในอนาคต?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินการทำงานร่วมกันและการจัดทำเอกสารของคุณ
ตัวอย่างคำตอบ:
ในบทบาทก่อนหน้า ฉันได้รักษาฐานความรู้ที่มีโครงสร้างซึ่งประกอบด้วยแนวทางการแก้ปัญหาแบบทีละขั้นตอน แผนผังระบบ และแนวทางการแก้ไขปัญหา นอกจากนี้ เรายังได้จัดการประชุมทบทวนเป็นประจำเพื่อหารือเกี่ยวกับเหตุการณ์ที่เกิดขึ้นล่าสุดและแบ่งปันข้อมูลเชิงลึก แนวทางปฏิบัตินี้ช่วยให้สมาชิกทีมใหม่ทำงานได้อย่างมีประสิทธิภาพอย่างรวดเร็ว
9) คุณจะดำเนินการอย่างไรหากแอปพลิเคชันหยุดให้บริการนอกเวลาทำการ?
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์กำลังประเมินความรู้สึกของคุณเกี่ยวกับความรับผิดชอบ การตัดสินใจ และการจัดการการยกระดับ
ตัวอย่างคำตอบ:
“ผมจะประเมินความรุนแรงของเหตุขัดข้องก่อน และพยายามกู้คืนระบบโดยทันทีตามขั้นตอนที่กำหนดไว้ในสมุดงาน หากจำเป็นต้องมีการยกระดับปัญหา ผมจะแจ้งทีมเทคนิคที่รับสายและผู้มีส่วนได้ส่วนเสียทางธุรกิจให้ทราบ ผมจะบันทึกทุกขั้นตอนที่ดำเนินการเพื่อความโปร่งใสและการวิเคราะห์หลังเกิดเหตุ”
10) คุณอัปเดตเครื่องมือสนับสนุนแอปพลิเคชันล่าสุดและแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรมได้อย่างไร
สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการเห็นความมุ่งมั่นของคุณในการเรียนรู้ต่อเนื่องและปรับตัวในสภาพแวดล้อมทางเทคนิคที่เปลี่ยนแปลงอย่างรวดเร็ว
ตัวอย่างคำตอบ:
ฉันติดตามบล็อกอุตสาหกรรมเป็นประจำ เข้าร่วมเว็บสัมมนา ITIL และ DevOps และมีส่วนร่วมในฟอรัมมืออาชีพ เช่น Spiceworks และ TechNet นอกจากนี้ ฉันยังมุ่งมั่นศึกษาการรับรองที่เกี่ยวข้องและการฝึกอบรมภาคปฏิบัติเพื่อให้ทันต่อเทคโนโลยีการสนับสนุนอัตโนมัติและการตรวจสอบล่าสุด
