■ CLOUD · DevOps · SRE · Managed Services

บริการ DevOps และดูแลระบบ Server องค์กร

ดูแล Linux Server, Kubernetes และระบบ Cloud พร้อม CI/CD, Monitoring และการรับมือเหตุขัดข้อง โดยทีม DevOps, SRE และ NOC ที่ทำงานร่วมกับทีมพัฒนา กำหนดขอบเขตและ SLA ให้เหมาะกับระบบของคุณ

ปรึกษาการดูแลระบบ production →

24/7 NOCSLA-tier MADev + Ops one team

Infographic of a 24/7 production operations center with observability, incident response, and deployment pipelines — Observe · Respond · Improve

ก่อนเริ่มโครงการ

บริการนี้เหมาะกับโจทย์ของคุณไหม

เหมาะกับองค์กรที่มีระบบ production ต้องการทีมดูแลโครงสร้างพื้นฐาน เฝ้าระวังปัญหา และทำงานร่วมกับนักพัฒนา โดยตกลงความสำคัญของระบบ เวลาที่ต้องการความคุ้มครอง และผู้รับผิดชอบแต่ละส่วนให้ชัดก่อนเริ่มบริการ

ขอบเขตและสิ่งส่งมอบที่วางแผนร่วมกัน

สำรวจระบบและแผนรับช่วง

จัดทำ inventory ของระบบและสิทธิ์เข้าถึง ตรวจความเสี่ยง และวางแผนรับช่วงโดยประสานกับทีมเดิม

Monitoring และการรับมือเหตุ

กำหนดสิ่งที่ต้องเฝ้าระวัง ระดับความรุนแรง ช่องทางแจ้งเหตุ ผู้ตัดสินใจ และ runbook ตามขอบเขตบริการ

การบำรุงรักษาและกู้คืน

กำหนดรอบ patch/change แผนสำรองข้อมูลและทดสอบกู้คืน รวมถึง maintenance window ที่ตกลงกับเจ้าของระบบ

รายงานและแผนปรับปรุง

ทบทวนเหตุขัดข้อง ความจุ และงานค้าง พร้อมจัดลำดับสิ่งที่ควรปรับปรุงร่วมกับทีมพัฒนาและเจ้าของธุรกิจ

รายละเอียดงานและเกณฑ์รับมอบจะสรุปในข้อเสนอของแต่ละโครงการ เพื่อให้ทั้งสองทีมเข้าใจขอบเขตเดียวกันก่อนเริ่มงาน

จากโจทย์เบื้องต้นสู่การเริ่มงาน

ประเมินระบบและความเสี่ยง
ระบุระบบสำคัญ dependencies สิทธิ์ และข้อจำกัด เพื่อแยกสิ่งที่ต้องแก้ก่อนรับดูแลกับงานประจำ
ตกลง SLA และความรับผิดชอบ
ระบุช่วงบริการ severity response time การ escalation และส่วนที่ลูกค้าหรือผู้ให้บริการอื่นรับผิดชอบ
รับช่วงและทบทวนต่อเนื่อง
ตั้งค่าช่องทางและ monitoring ทดสอบขั้นตอนแจ้งเหตุ แล้วทบทวนผลตามรอบที่ตกลง

อะไรมีผลต่องบประมาณและระยะเวลา

จำนวนระบบ ความซับซ้อนของโครงสร้างพื้นฐาน ช่วงบริการ ระดับความสำคัญ และสภาพระบบก่อนรับช่วงมีผลต่อค่าบริการ งานปรับปรุงครั้งแรก ค่า cloud/license และงานพัฒนาฟีเจอร์ต้องระบุแยกจากค่าดูแลประจำ

เตรียมอะไรไว้คุยกับทีม

เตรียมแผนผังหรือรายชื่อระบบ cloud/server ที่ใช้ ปัญหาที่เกิดบ่อย เวลาที่ระบบหยุดไม่ได้ และข้อมูลทีมผู้รับผิดชอบ ยังไม่ต้องส่งรหัสผ่านหรือ secret ในการติดต่อครั้งแรก

คำถามก่อนตัดสินใจ

Response time ต่างจากเวลาที่ระบบกลับมาใช้งานอย่างไร

Response time คือเวลาตอบรับหรือเริ่มดำเนินการตามนิยามใน SLA ส่วน recovery time คือเวลาที่ใช้คืนบริการ ซึ่งขึ้นกับเหตุและ dependencies จึงต้องตกลงแยกกัน

ทุกแพ็กเกจดูแลตลอด 24 ชั่วโมงไหม

ไม่ใช่ทุกขอบเขตบริการ ครอบคลุมช่วงเวลาและช่องทางตามที่ตกลงใน MA/SLA จึงควรระบุระบบที่ต้องการ 24/7 ตั้งแต่ประเมินงาน

รวมแก้โค้ดและเพิ่มฟีเจอร์หรือไม่

ต้องระบุความรับผิดชอบให้ชัดระหว่าง infrastructure, application และผู้ให้บริการภายนอก งานพัฒนาฟีเจอร์ใหม่จะประเมินแยกหากอยู่นอกขอบเขตที่ตกลง

เราดูแลอะไรให้คุณได้

Infrastructure

On-prem · cloud · hybrid · Linux + Kubernetes เป็นหลัก · cloud agnostic (Huawei · BytePlus · AWS · OpenStack)

CI/CD + delivery

Pipeline ที่ test จริง · gate ที่ block ได้ · deploy ที่ rollback ได้ · ไม่ใช่แค่ "push to main = deploy"

Security baseline

Patching cadence · IAM · network segmentation · backup ที่ลอง restore จริง · audit trail ที่ใช้ได้

Observability

Metrics + logs + traces — ZABBIX + GrayLog เป็น default stack · dashboard ที่ map กับ SLA จริง

24/7 NOC

วาง on-call rotation และ runbook สำหรับระบบที่ตกลงดูแลตลอด 24 ชั่วโมง พร้อมช่องทาง escalation

Maintenance Agreement (MA)

SLA tier — Bronze · Silver · Gold · Platinum · quarterly business review · cost transparency

SLA tier

Bronze

Business-hours support · standard response · ดูแล production ที่ไม่ critical 24/7

Silver

Extended hours · faster response · monthly review · ดูแลระบบที่ใช้งานสำคัญแต่ไม่ urgent

Gold

24/7 support · proactive monitoring · weekly review · production systems ที่ stop = stop business

Platinum

24/7 dedicated · sub-1-hour response · on-site if needed · mission-critical infrastructure

SLA tier mapping + response-time matrix ส่งให้ตอน proposal · ไม่ publish ตัวเลขเฉพาะที่นี่

One-team integration — สำคัญที่สุด

DevOps ที่ทำงานคนละสายกับ developer = bug ที่ฝ่ายไหนก็โบ้ยได้ · เราตั้งทีมแบบ "ทีมเดียวรับผิดชอบ" — dev + ops อยู่ retro เดียวกัน · ดู alert เดียวกัน · ตี problem เดียวกัน

ลูกค้าจะรู้สึกได้ว่า — เรื่องที่ "เคยต้องผ่านสองทีม" หายไป

ผลงานที่เกี่ยวข้อง

ดูแลโครงสร้างพื้นฐานและแพลตฟอร์มเนื้อหาหลายเว็บ ควบคู่กับงานบำรุงรักษาและปรับปรุงระบบเดิม

อ่านประสบการณ์งานดูแลแพลตฟอร์มเนื้อหา →

* ชื่อลูกค้าและตัวเลขสัญญา ถูกตัดออกจาก public site ตาม security/discretion policy

วางขอบเขตการดูแลให้เหมาะกับระบบของคุณ