SLA การดูแลเว็บไซต์ที่ดีควรกำหนด uptime เป้าหมาย, เวลาตอบสนอง/กู้คืน (RTO/RPO), ระดับความรุนแรง, หน้าต่างแพตช์/บำรุง, มอนิเตอร์/สำรองข้อมูล, เอสคาเลชัน, รายงาน และเครดิตชดเชย พร้อมผูกกับ SLI/SLO วัดผลชัด ควบคุมต้นทุน–ความเสี่ยงด้วยข้อยกเว้นที่ระบุ.
Website Maintenance SLA Guide: โครงสร้าง ข้อกำหนด และตัวอย่างที่ใช้ได้จริง
ภาพรวม SLA (Service Level Agreement) ต้องยึด SLI/SLO ที่วัดได้ เป็นหลัก เช่น ความพร้อมใช้งาน ความเร็วตอบสนอง และความถูกต้องบริการ จากแนวทาง SRE: SLIs คือสิ่งที่วัด, SLO คือเป้าหมาย, SLA คือคำมั่นสัญญาและผลหากทำไม่ได้. ออกแบบให้ลิงก์กับการตัดสินใจและการตอบสนองเหตุการณ์ได้จริง. แนะนำศึกษา SRE เรื่อง SLI/SLO เพิ่มเติมเพื่อเขียน SLA ให้มีเขี้ยวเล็บ.
อ้างอิง: Google SRE — SLOs/SLIs/SLAs และวิธีนำไปใช้. :contentReference[oaicite:0]{index=0}
คำสำคัญใน SLA ที่ต้องนิยามให้ชัด
- Uptime/Availability: เปอร์เซ็นต์ความพร้อมใช้งานต่อรอบบิล (รายเดือน/รายไตรมาส)
- RTO (Recovery Time Objective): เวลากู้คืนบริการให้ใช้งานได้ยอมรับได้. :contentReference[oaicite:1]{index=1}
- RPO (Recovery Point Objective): จุดเวลาที่ข้อมูลต้องย้อนกลับได้หลังเหตุขัดข้อง. :contentReference[oaicite:2]{index=2}
- Severity: ระดับความรุนแรงที่ผูกกับเวลาตอบสนอง/กู้คืนและจังหวะสื่อสาร. :contentReference[oaicite:3]{index=3}
- Patching & Maintenance Window: นโยบายติดตั้งแพตช์/อัปเดตตามแนวทางองค์กร. :contentReference[oaicite:4]{index=4}
- Service Credits: รูปแบบชดเชยเมื่อไม่ถึง SLA (เช่น ยึดตามตัวอย่างผู้ให้บริการคลาวด์). :contentReference[oaicite:5]{index=5}
ตารางตัวอย่าง “ระดับแพ็กเกจ” สำหรับเว็บไซต์ธุรกิจ
| แพ็กเกจ |
Uptime เป้าหมาย |
เวลาตอบสนอง (SLA) |
RTO |
RPO |
Support |
Patch Window |
Monitoring/Backup |
Service Credits |
| Essential |
99.5% |
ภายใน 4 ชม. |
24 ชม. |
24 ชม. |
ธุรกิจ (9x5) |
รายเดือน + ความเสี่ยงสูงทันที |
Uptime/SSL/DNS + Daily backup |
ต่ำกว่า 99.5% → 5% ค่าบริการเดือนนั้น* |
| Growth |
99.9% |
ภายใน 1 ชม. |
8 ชม. |
12 ชม. |
ขยายเวลา (12x5) |
ราย 14 วัน + ความเสี่ยงสูงทันที |
Uptime/Perf + 15-min health + Twice-daily backup |
ต่ำกว่า 99.9% → 10% ค่าบริการ |
| Mission-Critical |
99.99% |
ภายใน 15 นาที |
1 ชม. |
1 ชม. |
24x7 On-call |
รายสัปดาห์ + Emergency 48 ชม. |
Real-time + 5-min checks + Hourly backup |
ต่ำกว่า 99.99% → 15–25% ตามขั้น |
*ตัวอย่างเปอร์เซ็นต์เครดิตเพื่ออธิบายโครง ไม่ใช่ข้อเสนอราคา—อิงแนวทางจากหน้า SLA ของผู้ให้บริการคลาวด์ที่ใช้ Service Credits ตามช่วง Uptime. :contentReference[oaicite:6]{index=6}
ตาราง “Severity → การตอบสนอง/กู้คืน/สื่อสาร”
| Severity |
คำจำกัดความ |
ตอบรับเบื้องต้น |
กู้คืน (เป้าหมาย) |
ความถี่การอัปเดตลูกค้า |
| SEV1 |
บริการสาธารณะล่มทั้งหมด/ข้อมูลลูกค้าเสี่ยงสูง |
≤ 15 นาที |
≤ 1 ชม. หรือ Workaround ภายใน 30 นาที |
ทุก 15–30 นาที จนเสถียร |
| SEV2 |
กระทบผู้ใช้บางส่วน/ฟีเจอร์สำคัญใช้ไม่ได้ |
≤ 1 ชม. |
≤ 8 ชม. |
ทุก 60–90 นาที |
| SEV3 |
ปัญหาย่อย/ไม่มีผลกับแกนรายได้ |
≤ 4 ชม. |
ภายใน 3–5 วันทำการ |
อัปเดตเมื่อมีความคืบหน้า |
แรงบันดาลใจจากคู่มือ Incident ของ Atlassian/Google และแนวปฏิบัติ SRE อื่น ๆ; ปรับระดับ/เกณฑ์ให้เข้ากับบริบทธุรกิจของคุณ. :contentReference[oaicite:7]{index=7}
ตัวอย่างถ้อยคำสำคัญใน SLA (นำไปปรับใช้ได้)
- Measurement: “Uptime วัดจากผลลัพธ์การตรวจทุก 5 นาที ณ edge monitoring; ยกเว้น downtime ที่เข้าข่าย Maintenance Window ที่แจ้งล่วงหน้า ≥ 48 ชม.”
- Exclusions: “ไม่ครอบคลุมเหตุจากผู้ให้บริการโฮสต์ภายนอก, DNS registrar, โค้ดบุคคลที่สาม, หรือนอกเหนือสิทธิการควบคุมของผู้ให้บริการ”
- Credits: “หาก Monthly Uptime ต่ำกว่าเกณฑ์ จะได้รับ Service Credits ตามตาราง โดยต้องยื่นคำร้องภายใน 30 วันถัดไปของรอบบิล” (อ้างแนวทางผู้ให้บริการคลาวด์). :contentReference[oaicite:8]{index=8}
- Patching: “แพตช์วิกฤต (critical) ติดตั้งภายใน 48 ชม. หลังประกาศ; อื่น ๆ ตามรอบที่กำหนด” (อิงแนวทาง NIST SP 800-40). :contentReference[oaicite:9]{index=9}
โค้ดตัวอย่าง: คำนวณ Downtime สูงสุดต่อเดือนจากเป้าหมาย Uptime
<script>
// minutes per 30-day month
const MINUTES = 30 * 24 * 60;
function downtimeFromUptime(uptimePct){
const allowed = (1 - (uptimePct/100)) * MINUTES;
return Math.round(allowed); // นาที
}
// ตัวอย่าง
console.log('99.5% => ', downtimeFromUptime(99.5), 'นาที/เดือน');
console.log('99.9% => ', downtimeFromUptime(99.9), 'นาที/เดือน');
console.log('99.99% => ', downtimeFromUptime(99.99), 'นาที/เดือน');
</script>
ขั้นตอนทำ Website Maintenance SLA ให้ “ใช้งานได้จริง”
- ระบุบริการ/ขอบเขตงาน และสิ่งที่ไม่ครอบคลุม
- นิยาม SLI และตั้ง SLO (เช่น Uptime, TTFB, MTTR) ให้ผูกกับเป้าธุรกิจ
- กำหนด Severity–Response–Restore และ cadence การสื่อสาร
- กำหนด RTO/RPO + นโยบายสำรอง/ทดสอบกู้คืนสม่ำเสมอ
- กำหนด Patch/Maintenance Window และข้อยกเว้น
- ตั้งวิธีวัด/รายงาน/พิสูจน์ผล และ Service Credits
- ทำตารางระดับแพ็กเกจให้เลือก และทบทวนรายไตรมาส
บริการที่เกี่ยวข้อง (Internal Links)
อ่านต่อ (บทความที่เกี่ยวข้อง)
อ้างอิงภายนอก (มาตรฐาน/แนวทาง)
- Google SRE — SLIs/SLOs/SLAs และคู่มือปฏิบัติ. :contentReference[oaicite:10]{index=10}
- NIST — คำจำกัดความ RTO/RPO และแนวทาง Patch Management (SP 800-40 r4). :contentReference[oaicite:11]{index=11}
- PeopleCert/ITIL 4 — บทบาท/แนวคิด SLM & SLA ใน ITSM. :contentReference[oaicite:12]{index=12}
- AWS — ตัวอย่างโครง Service Credits & SLA หน้าอย่างเป็นทางการ. :contentReference[oaicite:13]{index=13}
- Atlassian — แนวคิด Incident Severity และ Major Incident. :contentReference[oaicite:14]{index=14}
เกี่ยวกับทีมผู้เขียน
Vision X Brain — ทีม Website/SEO/CRO & Webflow สำหรับธุรกิจ เราออกแบบสัญญา SLA ให้ “วัดได้–ทำได้จริง” ผูกกับ SLI/SLO และกระบวนการ Incident/Change/Release พร้อมแดชบอร์ดรายงานผล
อัปเดตล่าสุด: 23 Aug 2025
