ข
ติวสอบภาค ข
PRO
กลับไปทำข้อสอบวิชานี้

ความรู้เกี่ยวกับการพัฒนาระบบสารสนเทศ ปัญญาประดิษฐ์ (AI) แอปพลิเคชัน และเว็บไซต์

ฉบับเต็มตั้งแต่วิเคราะห์ปัญหา ออกแบบระบบ ข้อมูล API UX เว็บและแอป ไปจนถึง Secure SDLC, AI/Generative AI Governance, การทดสอบ การปล่อยใช้ และกรณีวิเคราะห์

18 หัวข้อ · อ่านประมาณ 117 นาที

อ่านฟรีได้ 2 จาก 18 หัวข้อ11%
สารบัญ18 หัวข้อหลัก
  1. 1.บทนำ — แผนที่ทั้งวิชา: ระบบที่ดีต้องแก้ปัญหา ใช้งานได้ ปลอดภัย และดูแลต่อได้
  2. 2.User Story, Use Case และ Acceptance Criteria: เขียนให้พัฒนาและทดสอบได้
  3. 3.Client–Server, Frontend, Backend และ API: แบ่งหน้าที่ให้ชัด
  4. 4.Authentication และ Authorization: รู้ว่าเป็นใครไม่เท่ากับมีสิทธิทำสิ่งนั้น
  5. 5.Observability: Logs, Metrics, Traces และเหตุการณ์ที่ตอบคำถามได้
  6. 6.Unit, Integration, Contract และ End-to-End Tests
  7. 7.Responsive Web, Mobile App และ Progressive Web App
  8. 8.Privacy และ PDPA: ใช้ข้อมูลอย่างมีฐาน วัตถุประสงค์ และจำกัดเท่าที่จำเป็น
  9. 9.A01–A02: Broken Access Control และ Security Misconfiguration
  10. 10.Secrets และ Key Management: Credential ไม่ควรอยู่ใน Source หรือ Chat
  11. 11.Train, Validation, Test และ Data Leakage
  12. 12.NIST AI RMF 1.0: Govern, Map, Measure และ Manage ตลอดวงจร
  13. 13.Hallucination, Grounding และการประเมินข้อสรุป Generative AI
  14. 14.ETDA Generative AI Governance: กลยุทธ์ ความเสี่ยง และการมีส่วนร่วมระดับองค์กร
  15. 15.กรณี 1: ผู้บริหารสั่ง “ทำแอปให้ประชาชนใช้ AI” แต่ไม่มีปัญหาและตัวชี้วัด
  16. 16.กรณี 4: Dependency มีช่องโหว่ร้ายแรงแต่ทีมไม่รู้ว่ารุ่นใดอยู่ Production
  17. 17.กรณี 7: นักพัฒนาคัดฐาน Production ไป Laptop เพื่อแก้ Bug
  18. 18.กรณี 10: แชตบอต RAG เปิดเผยเอกสารลับเพราะค้นรวมทุกสิทธิ
หัวข้อ 1

บทนำ — แผนที่ทั้งวิชา: ระบบที่ดีต้องแก้ปัญหา ใช้งานได้ ปลอดภัย และดูแลต่อได้

การพัฒนาระบบสารสนเทศไม่เริ่มจากเลือกภาษา Framework หรือ AI แต่เริ่มจากปัญหา ผู้ใช้ ผลลัพธ์ และข้อจำกัด แล้วจึงออกแบบกระบวนการ ข้อมูล สถาปัตยกรรม และการควบคุมให้เหมาะ. เว็บไซต์และแอปพลิเคชันเป็นช่องทางใช้งานของระบบ ส่วน API ฐานข้อมูล ระบบยืนยันตัวตน และโครงสร้างพื้นฐานเป็นองค์ประกอบหลังบ้าน AI อาจเป็นความสามารถหนึ่ง ไม่ใช่ข้อสรุปของทุกปัญหา. วงจรงานครอบคลุม discovery, requirements, design, development, testing, deployment, operation, measurement และ retirement ทุกช่วงต้องมีความปลอดภัย ความเป็นส่วนตัว และ accessibility แทรกอยู่. คุณภาพมีหลายมิติ ได้แก่ functional suitability, reliability, usability, performance, security, maintainability, portability และ compatibility การเร่งด้านหนึ่งอาจสร้าง trade-off อีกด้าน

มาตรฐานที่ใช้เป็นฐานในเนื้อหารวม NIST SSDF 1.1, NIST AI RMF 1.0, OWASP Top 10:2025, WCAG 2.2 และมาตรฐานเว็บไซต์ภาครัฐ เวอร์ชัน 3.0 ของ DGA. ประเด็นสถานการณ์ควรเลือกข้อสรุปที่ตรวจปัญหาและความเสี่ยงก่อน ลงมือทีละขั้น มีหลักฐานทดสอบและย้อนกลับได้ ไม่เลือกข้อสรุปสุดโต่งอย่างซื้อเทคโนโลยีใหม่หรือย้ายขึ้น Cloud แล้วปัญหาจะหายเอง

แผนที่ทั้งวิชา: ระบบที่ดีต้องแก้ปัญหา ใช้งานได้ ปลอดภัย และดูแลต่อได้

  1. 1เข้าใจปัญหาและผู้ใช้
  2. 2กำหนดผลลัพธ์กับข้อกำหนด
  3. 3ออกแบบระบบและข้อมูล
  4. 4พัฒนาและทดสอบ
  5. 5ปล่อยใช้อย่างควบคุม
  6. 6เฝ้าระวัง ปรับปรุง และยุติเมื่อถึงเวลา
  • เจ้าของผลิตภัณฑ์ยืนยันปัญหา กลุ่มผู้ใช้ baseline เป้าหมาย และ guardrail แล้ว พร้อมระบุสิ่งที่อยู่นอกขอบเขต สมมติฐานสำคัญ และผู้มีอำนาจยอมรับ residual risk อย่างชัดเจน
  • Functional และ non-functional requirements เชื่อมกับ acceptance tests ครบทั้ง happy path, permission, boundary, timeout, duplicate, partial failure, recovery และ accessibility journey สำคัญ
  • Architecture review บันทึก trust boundary, dependency, data flow, source of truth, failure mode, timeout/retry, capacity และเหตุผล trade-off โดยมีแผนแก้ข้อจำกัดที่ยอมรับชั่วคราว
  • Data owner ตรวจนิยาม คุณภาพ classification, lawful basis, purpose, retention, sharing, migration และ reconciliation รวมสิทธิของเจ้าของข้อมูลกับวิธีลบหรือเก็บตามข้อยกเว้น
  • Authentication, authorization, tenant isolation, MFA, session, recovery, service account และ break-glass ถูกทดสอบจากมุม attacker ไม่ใช่เพียงตรวจว่าเมนูถูกซ่อนตาม role
  • Threat model และ abuse cases ครอบคลุม OWASP Top 10:2025, business logic, privacy, supply chain และ dependency ภายนอก พร้อม owner ของ mitigation และหลักฐาน verification
  • Source, build, CI runner, artifact, dependency, container และ IaC มี version/provenance, review, scan, signature หรือ control ที่เหมาะ พร้อม SBOM และขั้นตอนตอบช่องโหว่หลัง release
  • Test suite แยก unit, integration, contract และ end-to-end ตามความเสี่ยง ข้อมูลทดสอบไม่เปิดเผยข้อมูลจริง และผล performance/load อ้าง workload กับ percentile ที่ตรงวันใช้งาน
  • เว็บและแอปผ่าน keyboard, screen reader, zoom/reflow, contrast, responsive และอุปกรณ์จริงตาม WCAG 2.2 ที่กำหนด ไม่ใช้คะแนน automated scan หน้าแรกเป็นหลักฐานเดียว
  • Deployment ใช้ immutable artifact, environment separation, migration compatibility, canary/feature flag และ stop condition มี rollback หรือ roll-forward ที่ซ้อมแล้ว รวมผลต่อข้อมูลที่สร้างระหว่างรุ่น
  • Monitoring มี SLI/SLO, logs, metrics, traces, audit events, alert owner และ runbook โดย redact secret/ข้อมูลส่วนบุคคล พร้อม dashboard journey ที่บอกผลผู้ใช้ ไม่ดู infrastructure อย่างเดียว
  • Backup และ disaster recovery ทดสอบ restore ตาม RTO/RPO รวม identity, key, DNS, network และ third party มี incident contacts, severity, communication กับหลักฐานการซ้อมล่าสุด
  • Support, complaint, privacy request และ security disclosure มีช่องทางกับ SLA เจ้าหน้าที่เห็น version/correlation พอช่วยได้ และ feedback ถูก triage เข้าทีม ไม่หายอยู่ในแชตส่วนบุคคล
  • เนื้อหา กฎหมาย ราคา สิทธิ และข้อมูลติดต่อมี owner, source, publish/review/expire date พร้อม redirect/archive plan เพื่อไม่ให้ซอฟต์แวร์ทำงานถูกแต่ให้ข้อมูลทางการล้าสมัย
  • หลังเปิดมีแผนวัด outcome เทียบ baseline, cost, error, fairness, adoption และ guardrail พร้อมเกณฑ์ iterate, scale, pause หรือ sunset ไม่ถือว่าการ deploy สำเร็จเท่ากับปัญหาสำเร็จ
  • แผนปฏิบัติการระบุผู้รับผิดชอบ on-call, content, data, dependency และ vendor หลังหมดระยะโครงการ พร้อมงบ patch, certificate, domain, storage, license และการพัฒนาคน ไม่ทิ้งภาระซ่อนให้หน่วยรับมอบ
  • การรับมอบตรวจ source/artifact, architecture, API, data dictionary, test evidence, security finding, license, admin access, runbook, backup/restore และ knowledge transfer ครบ ไม่รับจากการสาธิต happy path เพียงครั้งเดียว
  • AI use case ระบุ decision ที่สนับสนุน ผู้ได้รับผล ค่าเสียหายของ false positive/negative ทางเลือกที่ไม่ใช้ AI และเหตุผลว่า model เพิ่มคุณค่ากว่า rule หรือ search baseline จริง
  • มี AI inventory บันทึก model/provider/version, intended use, prohibited use, data, integration, owner, risk tier และ approval รวมบริการ shadow AI ที่บุคลากรใช้นอกบัญชีองค์กร
  • Dataset มีแหล่ง สิทธิใช้ consent/license, population, time, label process, missing, duplicate, train/validation/test split และ limitation พร้อมตรวจ leakage กับการย้อนระบุตัวบุคคล
  • Evaluation วัด task metric, calibration, robustness, safety, security, privacy และ fairness แยกกลุ่ม มี confidence/uncertainty กับ baseline และ external/temporal test ตามความเสี่ยง
  • Threshold, abstention, escalation และ human oversight เชื่อม workflow จริง ผู้ตรวจมีเวลา ข้อมูล อำนาจ override และช่องอุทธรณ์ ไม่เป็นเพียงผู้กดรับรองข้อสรุป model
  • Transparency แจ้งผู้ใช้เมื่อเหมาะ อธิบายวัตถุประสงค์ ข้อจำกัด แหล่งข้อมูลและผู้รับผิดชอบ มี model/system card กับ decision record ที่ตรง version production
  • RAG บังคับ document/tenant permissions ก่อน retrieval ตรวจ ingestion lineage, chunk metadata, freshness, citation support และการลบจาก index/cache เมื่อสิทธิกับเอกสารต้นทางเปลี่ยน
  • Prompt injection และ indirect injection ถูกทดสอบจาก user, email, PDF, web และ retrieved content; system prompt ไม่เก็บ secret และไม่ถูกถือเป็น security boundary ที่รับประกันได้
  • Model output เป็น untrusted data ต้อง validate schema, encode ตาม context และตรวจ URL, recipient, command กับ amount ก่อนใช้ ไม่ส่งเข้า SQL, shell, HTML หรือ tool โดยตรง
  • Agent/tool ใช้ least privilege, allowlist, per-action scope, budget, timeout, sandbox, egress restriction, plan preview และ human approval สำหรับการกระทำภายนอกหรือย้อนยาก
  • Generative AI test set มี factuality, groundedness, harmfulness, instruction conflict, multilingual/Thai, long context, unsupported citation และ high-stakes cases โดย versioned กับทุก model/prompt change
  • Production monitoring ครอบคลุม drift, unsupported claims, refusal/abstention, override, bias, latency, token/cost, abuse, data leakage และ provider changes พร้อม trigger pause หรือ fallback
  • สัญญาผู้ให้บริการระบุการเก็บ/ใช้ข้อมูลฝึก, region, subprocessor, security, incident, model update, availability, export/delete และ exit plan ไม่พึ่งคำโฆษณาว่า enterprise หรือ zero retention โดยไม่ตรวจเงื่อนไข
  • Incident playbook รองรับ hallucination ที่เผยแพร่ การรั่วผ่าน prompt/context, poisoning, compromised model/dependency, excessive agency และ denial of wallet พร้อมหลักฐาน trace ที่ไม่เก็บข้อมูลเกินจำเป็น
  • คณะกำกับมีธุรกิจ เทคนิค ข้อมูล ความปลอดภัย กฎหมาย HR และตัวแทนผู้ได้รับผล ทบทวน social impact กับ residual risk เป็นรอบ และมีอำนาจหยุดระบบแม้ metric ประสิทธิภาพดี
  • แผน fallback ระบุว่าจะใช้กฎเดิม ค้นข้อมูล หรือส่งให้คนเมื่อ model/provider ล่ม ไม่มั่นใจ หรือเกินงบ พร้อมทดสอบว่าคิวงาน manual รองรับได้ ไม่เขียนเพียงว่าเจ้าหน้าที่จะดำเนินการแทน
  • Retirement ของ AI ครอบคลุมถอน endpoint/tool credential, ลบหรือคืนข้อมูลตามสัญญา ปิด index/cache, เก็บหลักฐานที่กฎหมายต้องการ และแจ้งผู้ใช้กับ downstream ว่าคะแนนหรือข้อสรุปรุ่นเดิมไม่ควรถูกใช้ต่อ
  • การเปลี่ยน model, system prompt, embedding, chunking, retrieval, tool หรือ safety policy ต้องถือเป็นการเปลี่ยนระบบที่อาจกระทบผลลัพธ์ รัน evaluation และ regression ตาม risk พร้อมบันทึก version, approval, rollout และผลหลังปล่อย ไม่ให้ provider auto-upgrade ข้าม gate โดยทีมไม่รู้

คำขอว่า “อยากได้แอป” เป็นวิธีแก้ที่ผู้ขอเสนอ ไม่ใช่คำอธิบายปัญหา ทีมต้องถามว่าใครทำอะไรยาก เกิดบ่อยเพียงใด ผลกระทบเท่าไร และความสำเร็จหลังแก้หน้าตาอย่างไร. แยกอาการจาก root cause เช่นคิวบริการยาวอาจเกิดจากขั้นตอนอนุมัติซ้ำ ข้อมูลไม่ครบ หรือกำลังคนไม่พอ การสร้างแอปจองคิวอาจเพียงย้ายจุดรอและเพิ่มช่องทางให้ข้อมูลซ้ำ. กำหนด outcome ที่วัดได้ เช่นลดเวลารอ median จากค่าเดิม เพิ่ม completion rate หรือลดข้อผิดพลาด โดยมี baseline, target, timeframe และ guardrail ด้านคุณภาพหรือความเป็นธรรม. สำรวจทางเลือกทั้งไม่ใช้เทคโนโลยี ปรับกระบวนการ ซื้อผลิตภัณฑ์ เชื่อมระบบเดิม หรือพัฒนาใหม่ เปรียบเทียบต้นทุนตลอดอายุ ความเสี่ยง vendor lock-in และความพร้อมคน

สมมติฐานสำคัญควรถูกทดสอบเร็วด้วย interview, observation, service blueprint, prototype หรือ data analysis ก่อนลงทุนเขียนระบบใหญ่ เพื่อลดความเสี่ยงสร้างสิ่งถูกต้องตาม spec แต่ไม่มีใครใช้. เอกสารปัญหาที่ดีระบุสิ่งอยู่ในและนอกขอบเขต ข้อจำกัด กฎหมาย ผู้ตัดสินใจ และคำถามค้าง ไม่ซ่อนความไม่แน่นอนด้วยศัพท์เทคนิคหรือเริ่มนับ feature เป็นความสำเร็จ. Stakeholder รวมผู้ใช้ปลายทาง ผู้บริหาร เจ้าของกระบวนการ เจ้าของข้อมูล ทีมปฏิบัติการ ความปลอดภัย กฎหมาย ผู้ตรวจ ผู้ให้บริการภายนอก และคนที่ไม่ได้ใช้แต่ได้รับผลจากการตัดสินใจระบบ. การสัมภาษณ์ผู้บริหารอย่างเดียวมักได้เป้าหมายระดับนโยบายแต่ไม่เห็น workaround ของผู้ปฏิบัติ ต้องสังเกตงานจริงและคุยกับกลุ่มหลากหลาย รวมผู้พิการ ผู้ใช้ทักษะดิจิทัลต่ำ และผู้มีอุปกรณ์จำกัด

Persona เป็นแบบจำลองจากข้อมูลวิจัยเพื่อช่วยตัดสินใจ ไม่ใช่ตัวละครที่ทีมแต่งจากความรู้สึก ควรระบุเป้าหมาย พฤติกรรม บริบท ข้อจำกัด และความต่างที่มีผลต่อการออกแบบ. Stakeholder map และ RACI ช่วยแยกผู้รับผิดชอบ ผู้อนุมัติ ผู้ให้คำปรึกษา และผู้รับทราบ แต่ตารางบทบาทไม่แทนการตกลงอำนาจกับ escalation เมื่อความต้องการชนกัน. ความต้องการผู้ใช้บางกลุ่มขัดกัน เช่นความเร็วกับการตรวจสอบ หรือ personalization กับ privacy ทีมต้องทำ trade-off โปร่งใสตามความเสี่ยง ไม่เลือกเสียงผู้มีอำนาจหรือผู้ตอบแบบสอบถามมากที่สุดเสมอ. การมีส่วนร่วมต้องต่อเนื่องตั้งแต่ discovery ถึง usability test, pilot และ monitoring เพราะผู้ใช้เปลี่ยนพฤติกรรมเมื่อระบบจริงมีข้อมูลจริง ภาระจริง และผลตามมาจริง

Functional requirement อธิบายพฤติกรรม เช่นสมัคร ยืนยันตัวตน ค้นหา อนุมัติ คำนวณ แจ้งเตือน หรือออกรายงาน โดยต้องระบุเงื่อนไขก่อน ผลหลัง กฎธุรกิจ และกรณียกเว้น. Non-functional requirement อธิบายคุณลักษณะ เช่นรองรับผู้ใช้พร้อมกัน เวลาตอบสนอง availability, recovery, security, privacy, accessibility, interoperability และ maintainability. ถ้อยคำว่า “เร็ว ปลอดภัย ใช้ง่าย และรองรับจำนวนมาก” ทดสอบไม่ได้ ต้องแปลงเป็นตัวชี้วัด เช่น p95 latency, error rate, RTO/RPO, WCAG level และจำนวน concurrent users ภายใต้ workload ที่กำหนด. ข้อกำหนดด้านข้อมูลระบุแหล่ง เจ้าของ นิยาม คุณภาพ retention, residency, classification และการแชร์ ส่วนข้อกำหนด AI เพิ่มความแม่น การอธิบาย bias, human review, drift และ fallback

Requirement traceability เชื่อมความต้องการกับ design, code, test และ release ช่วยพิสูจน์ว่าครบและรู้ผลกระทบเมื่อเปลี่ยน โดยไม่จำเป็นต้องเป็นเอกสารหนักหากใช้เครื่องมือที่เชื่อมรายการได้. ทีมควรจัด review ร่วมและบันทึก decision กับ assumption ข้อกำหนดไม่ใช่สัญญาที่ห้ามเรียนรู้ แต่การเปลี่ยนต้องประเมิน scope, cost, risk และ acceptance ใหม่ ไม่แก้เงียบระหว่างพัฒนา

หัวข้อ 2

User Story, Use Case และ Acceptance Criteria: เขียนให้พัฒนาและทดสอบได้

User story รูปแบบ “ในฐานะ...ฉันต้องการ...เพื่อ...” ช่วยรักษามุมคุณค่า แต่ไม่พอสำหรับกฎซับซ้อน ต้องมี conversation, examples, data, constraints และ acceptance criteria ประกอบ. Use case เหมาะกับ flow หลาย actor โดยระบุ trigger, precondition, main flow, alternative, exception และ postcondition ทำให้เห็นกรณี timeout, duplicate, cancel หรือสิทธิไม่พอที่ happy path มักลืม. Acceptance criteria ควรเป็นผลสังเกตได้ เช่น Given–When–Then พร้อมค่าขอบเขตและ error state ไม่ผูกวิธี implementation เกินจำเป็น เพื่อให้ทีมมีอิสระออกแบบและ QA สร้าง test ได้

Definition of Ready บอกข้อมูลขั้นต่ำก่อนเริ่มงาน ส่วน Definition of Done รวม code review, tests, security, accessibility, documentation, monitoring และ deployment readiness ไม่ใช่เพียง merge สำเร็จ. ตัวอย่างจริงช่วยค้น ambiguity เช่น “หนึ่งคนหนึ่งบัญชี” ต้องถามว่าระบุตัวด้วยอะไร เด็กหรือชาวต่างชาติทำอย่างไร เปลี่ยนเลขโทรศัพท์อย่างไร และควบรวมข้อมูลซ้ำได้หรือไม่. ประเด็นที่ให้ความต้องการคลุมเครือควรเลือกถามและทำ prototype กับผู้ใช้ก่อน ไม่ควรให้ developer ตีความเองหรือสร้างครบทุกความเป็นไปได้เพราะเพิ่มเวลาและยังอาจผิดปัญหา. MVP คือรุ่นเล็กที่สุดที่ทดสอบสมมติฐานคุณค่ากับผู้ใช้จริงได้อย่างปลอดภัย ต้องมีคุณภาพขั้นต่ำด้านข้อมูล ความปลอดภัย accessibility และความน่าเชื่อถือ ไม่ใช่ตัดส่วนควบคุมออกเพื่อให้เร็ว

การจัดลำดับอาจใช้ value, urgency, risk reduction, effort และ dependency ร่วมกัน วิธี MoSCoW หรือ scoring เป็นเครื่องมือสนทนา ไม่ใช่สูตรตัดสินอัตโนมัติที่ซ่อนการเมือง. เริ่มจาก vertical slice ที่เดินครบตั้งแต่ UI ถึงข้อมูลและ operation ช่วยทดสอบสถาปัตยกรรมกับ deployment เร็วกว่าสร้าง frontend ทั้งหมดแล้วค่อยเชื่อม backend ช่วงท้าย. ควรทำ risky assumptions ก่อน เช่นการเชื่อม API ภายนอก คุณภาพข้อมูล โมเดล AI หรือการยืนยันตัวตน มากกว่าสะสมหน้าจอง่ายเพื่อแสดงความคืบหน้าที่ไม่ลดความเสี่ยงหลัก. Backlog ต้องมี owner, priority, dependency, acceptance และเหตุผลรายการค้าง พร้อมตัดของที่ไม่สร้างผล ไม่ปล่อยให้ทุกข้อเป็น must-have จนทีมทำ rollout ใหญ่ครั้งเดียว

หลัง MVP ต้องวัด activation, task success, error, retention และ outcome แล้วตัดสิน iterate, pivot, scale หรือ stop ไม่ถือว่าการเปิดใช้คือหลักฐานว่าปัญหาได้รับการแก้. Software Development Life Cycle ครอบคลุมวางแผน วิเคราะห์ ออกแบบ พัฒนา ทดสอบ deploy, operate และ retire รูปแบบ waterfall, iterative หรือ agile ต่างจัดลำดับงาน แต่ทุกแบบต้องควบคุมคุณภาพ. Agile เน้นส่งของใช้ได้เป็นช่วง รับ feedback และปรับตามข้อมูล แต่ไม่แปลว่าไม่วาง architecture ไม่ทำเอกสาร หรือเปลี่ยน scope โดยไม่มีผู้รับผิดชอบและผลกระทบ. Scrum ใช้ Product Backlog, Sprint, Review และ Retrospective ส่วน Kanban จำกัดงานระหว่างทำและปรับ flow ทีมควรเลือกตามลักษณะงาน ไม่ทำพิธีครบแต่ส่งคุณค่าไม่ได้

DevOps เชื่อม development กับ operations ผ่าน shared ownership, automation, CI/CD, observability และ feedback เพื่อให้การเปลี่ยนแปลงเล็ก ปลอดภัย และแก้ได้เร็ว ไม่ใช่ชื่อตำแหน่งคน deploy เพียงคนเดียว. Secure SDLC ฝัง threat modeling, security requirements, code scan, dependency control, test และ incident learning ตั้งแต่ต้น ค่าแก้ช่องโหว่จึงไม่กองปลายโครงการ. ตัวชี้วัดอย่าง lead time, deployment frequency, change failure rate และ time to restore ต้องอ่านร่วมกับ outcome กับคุณภาพ หาก deploy บ่อยแต่สร้าง defect หรือ feature ไม่ถูกใช้ก็ไม่ใช่ความสำเร็จ. Architecture กำหนดส่วนประกอบ ความรับผิดชอบ การเชื่อมข้อมูล และข้อจำกัดเพื่อรองรับ quality attributes ไม่ใช่เพียงวาดกล่องหรือเลือก microservices เพราะนิยม

เริ่มจาก scenario เช่นผู้ใช้ 10,000 คนค้นพร้อมกัน p95 ต่ำกว่า 2 วินาที หรือระบบกลับมาภายใน RTO หลัง region ล่ม แล้วออกแบบ cache, queue, redundancy และ degradation ตามความเสี่ยง. Monolith ที่แบ่ง module ชัดอาจง่ายและน่าเชื่อถือกว่าสำหรับทีมเล็ก Microservices เหมาะเมื่อ domain และการปรับขนาดแยกคุ้มกับต้นทุน network, observability, data consistency และ deployment. การตัดสินใจควรบันทึกเป็น Architecture Decision Record ระบุบริบท ตัวเลือก เหตุผล ผลตามมา และเงื่อนไขทบทวน เพื่อไม่ให้ทีมในอนาคตคิดว่าข้อจำกัดชั่วคราวเป็นกฎถาวร. ระบบควรมี loose coupling และ high cohesion ใช้ interface ที่ชัด แยก business logic จาก infrastructure เท่าที่เหมาะ และหลีกเลี่ยง shared database ที่ทุกบริการแก้ตารางกันโดยไร้ owner

ไม่มี architecture ที่ดีที่สุดโดยทั่วไป มีแต่แบบเหมาะกับความต้องการ ทีม งบ และความเสี่ยง ข้อสรุปประเด็นจึงควรเลือกประเมิน trade-off และ proof of concept ไม่เลือก buzzword โดยไม่มีบริบท

อ่านสรุปฉบับเต็มทุกหัวข้อ
สมาชิก PRO ระบบจะจำหัวข้อที่อ่านค้างไว้ให้ด้วย
PRO 99 บาท/เดือน

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