SRE Prep
เมนูโมดูล

10. Behavioral & Communication (Thai / English)

ทำไมหัวข้อนี้สำคัญกับ interview

งาน SRE = production + on-call + ทำงานข้ามทีมภายใต้ความกดดัน. รอบ behavioral วัดว่าคุณ สื่อสารตอนวิกฤตได้ไหม, รับผิดชอบเป็นไหม, ทำงานเป็นทีมและ blameless ไหม. คำตอบที่ดี ต้องมีโครง (STAR) และเล่า incident อย่างมี maturity — ไม่โทษคนอื่น ไม่โอ้อวด.

เทคนิคหลักคือ STAR — ใช้ได้ทั้งภาษาไทยและอังกฤษ เพียงเปลี่ยนภาษาแต่คงโครงเดิม.

STAR Technique

STAR — เล่าให้ครบ 4 ส่วน อย่าข้ามไป Action/Result เร็วเกิน
ส่วนตอบอะไรไทยEnglish
Situationบริบท"ตอนนั้นระบบ checkout มี error rate พุ่งช่วง peak""During peak, our checkout error rate spiked"
Taskหน้าที่คุณ"ผมเป็น on-call ต้องกู้บริการให้เร็วที่สุด""As on-call, I had to restore service fast"
Actionสิ่งที่คุณทำ"ผมยืนยันจาก dashboard, rollback deploy ล่าสุด, แล้วทำ RCA""I confirmed via dashboards, rolled back the latest deploy, then ran an RCA"
Resultผล + บทเรียน"กู้คืนใน 12 นาที และเพิ่ม canary check กัน recurrence""Recovered in 12 min and added a canary check to prevent recurrence"

เคล็ดลับที่ทำให้คำตอบโดดเด่น

  • ใช้ "ผม/ฉัน" ใน Action (สิ่งที่ คุณ ทำ) แต่ใช้ "เรา" ตอนให้เครดิตทีม — สมดุลระหว่าง ownership กับ teamwork.
  • ใส่ตัวเลขใน Result (MTTR, error rate, % ที่ลดลง) — วัดผลได้ = น่าเชื่อถือ.
  • ปิดด้วย บทเรียน/สิ่งที่ปรับปรุงเชิงระบบ เสมอ — สะท้อนวิธีคิดแบบ SRE.

ตัวอย่างคำตอบเต็ม (STAR) — สองภาษา

คำถาม: "เล่า incident ที่คุณเคยจัดการ"

ไทย: "ช่วง campaign ลดราคา ระบบ checkout เริ่มตอบ 503 และ error rate ขึ้นไปเกิน 5% (S). ผมเป็น primary on-call มีหน้าที่กู้บริการและรักษา SLO (T). ผมยืนยันจาก Grafana ว่า เป็นของจริง เช็กว่ามี deploy ก่อนหน้า 20 นาที จึง rollback ผ่าน CodeDeploy เป็นการ mitigate ก่อน แล้วตั้ง war room สั้น ๆ ให้ทีม DB ช่วยดู connection pool ที่เต็ม (A). บริการกลับปกติใน ~12 นาที, เราทำ blameless postmortem พบว่า migration ลืม index จึง เพิ่ม canary + index check ใน CI ทำให้ไม่เกิดซ้ำอีกเลย (R)."

English: "During a sale campaign, checkout started returning 503s and error rate passed 5% (S). As primary on-call, I was responsible for restoring service and protecting our SLO (T). I confirmed it was real on Grafana, saw a deploy 20 minutes earlier, and rolled it back via CodeDeploy to mitigate first, then spun up a short war room with the DB team to look at the exhausted connection pool (A). Service recovered in about 12 minutes; in a blameless postmortem we found a migration had missed an index, so we added a canary and an index check in CI — it hasn't recurred (R)."

การเล่า incident อย่างมี maturity

  • Blameless language: พูดถึง ระบบ/process ("migration ขาด review checklist") ไม่ใช่ บุคคล ("เพื่อนร่วมทีมทำพลาด").
  • Ownership: ถ้าเป็นความพลาดของคุณ ยอมรับตรง ๆ แล้วโฟกัสว่าแก้ระบบยังไงให้ไม่เกิดซ้ำ — นี่คือสิ่งที่ interviewer มองหา ไม่ใช่ความสมบูรณ์แบบ.
  • Quantify impact: "กระทบผู้ใช้ ~3% เป็นเวลา 12 นาที" ดีกว่า "กระทบเยอะ".
  • Audience-appropriate: อัปเดต stakeholder ด้วยภาษาธุรกิจ (impact/ETA) ส่วนทีม tech ด้วย รายละเอียด — ปรับระดับตามผู้ฟัง.

วิธีตอบคำถาม 'เล่าตอนที่คุณทำพลาดใน production'

อย่าเลี่ยงหรือโยนความผิด. โครงที่ดี: ยอมรับสิ่งที่เกิด → สิ่งที่ทำเพื่อ mitigate ทันที → บทเรียนและ guardrail เชิงระบบ ที่เพิ่มเข้าไป (เช่น เพิ่ม review, staging, automation). การยอมรับอย่างมี ownership + โฟกัสการแก้ระบบ = สัญญาณของ senior mindset.

คำถาม behavioral ของ SRE ที่เจอบ่อย

  1. "เล่า incident ที่รุนแรงที่สุดที่คุณเคยเจอและวิธีจัดการ" → ใช้ STAR, เน้น mitigate ก่อน + postmortem.
  2. "เล่าตอนที่คุณทำพลาดใน production" → ยอมรับ + guardrail เชิงระบบ.
  3. "เล่าตอนที่เห็นต่างกับเพื่อนร่วมทีม/หัวหน้า" → เน้น disagree อย่างมี data และ commit ตามมติ.
  4. "จัดการความกดดัน/ความเครียดตอน on-call ยังไง" → มี runbook/process, แบ่งบทบาท, พัก และ handoff.
  5. "เล่าตอนที่คุณปรับปรุง reliability ของระบบ" → ปัญหา → สิ่งที่ทำ → ตัวเลขที่ดีขึ้น (เช่น toil ลด, MTTR ลด).
  6. "จัดลำดับความสำคัญยังไงเมื่อมีหลายเรื่องด่วนพร้อมกัน" → อิง impact ต่อผู้ใช้/SLO และ severity.

Pitfalls — จุดที่ผู้สมัครมักพลาด

ระวังกับดักเหล่านี้

  • เล่าวกวนไม่มีโครง → ผู้ฟังจับประเด็นไม่ได้ (ใช้ STAR เสมอ).
  • โทษคนอื่น / ระบบเก่า / ทีมอื่น → ดูขาด ownership และไม่ blameless.
  • เอาเครดิตคนเดียว ("ผมทำคนเดียว") → ดูไม่เป็น team player; ใช้ "เรา" ให้เหมาะ.
  • ไม่มีผลลัพธ์ที่วัดได้ → คำตอบลอย ไม่น่าเชื่อ.
  • ตั้งรับ/แก้ตัวเรื่องความผิดพลาด → เสียคะแนน maturity.
  • เทคนิคจัดเกินสำหรับผู้ฟังที่ไม่ใช่ tech → สื่อสารไม่ตรงกลุ่ม.
  • ตอบสั้นเกิน (ข้าม Action/Result) → ไม่เห็นว่า คุณ ทำอะไรและได้อะไร.

Quiz ท้ายบท

Quiz ท้ายบท

ตอบแล้ว 0/6

  1. 1.STAR ย่อมาจากอะไร?

  2. 2.ในส่วน Action ของ STAR ควรใช้สรรพนามอย่างไร?

  3. 3.อะไรทำให้ส่วน Result ของคำตอบน่าเชื่อถือที่สุด?

  4. 4.เมื่อถูกถาม 'เล่าตอนที่คุณทำพลาดใน production' แนวทางตอบที่ดีที่สุดคือ?

  5. 5.การเล่า incident แบบ 'blameless' หมายถึงอะไร?

  6. 6.ระหว่าง incident ที่กำลังเกิด ควรสื่อสารกับ stakeholder ที่ไม่ใช่ทีม tech อย่างไร?

Cheat Sheet — อ่านก่อนเข้าห้องสัมภาษณ์

สรุปเร็ว 30 วินาที

  • ใช้ STAR: Situation → Task → Action → Result (ใช้ได้ทั้งไทย/อังกฤษ)
  • Action ใช้ "ผม/ฉัน" (สิ่งที่คุณทำ), credit ทีม ด้วย "เรา"
  • Result ใส่ตัวเลข (MTTR, error rate) + บทเรียนเชิงระบบ
  • เล่า incident แบบ blameless + ownership + quantify impact
  • คำถามพลาด production → ยอมรับ + guardrail เชิงระบบ (ไม่แก้ตัว/ไม่โทษคน)
  • สื่อสารตาม ผู้ฟัง: ธุรกิจ = impact/ETA, ทีม tech = รายละเอียด
  • เตรียม 3–4 เรื่องจริงไว้ล่วงหน้า ปรับใช้ได้หลายคำถาม
อ่านจบแล้ว? ทำเครื่องหมายไว้เพื่อติดตามความคืบหน้า
ก่อนหน้าSecurity & Testing Basics