บริการไอที · บริการคลาวด์และ DevOps
การดีพลอยที่น่าเบื่อโดยตั้งใจ
ถ้าการดีพลอยเป็นเรื่องเครียด คุณก็จะดีพลอยน้อยลง แล้วการเปลี่ยนแปลงก็จะกองสะสมจนวันหนึ่งมีตัวใดตัวหนึ่งทำระบบพัง เป้าหมายคือทำให้การปล่อยเวอร์ชันเป็นเรื่องธรรมดาจนไม่มีใครต้องนัดประชุม
—— จุดที่เจ็บที่สุด
ปัญหาที่งานนี้ แก้ได้จริง
ปัญหาโครงสร้างพื้นฐานส่วนใหญ่มักมองไม่เห็น จนถึงวันที่มันกลายเป็นความเสียหายราคาแพง ต่อไปนี้คือห้าเรื่องที่เราถูกเรียกไปช่วยบ่อยที่สุด
ดีพลอยได้อยู่คนเดียว
การปล่อยเวอร์ชันทำได้เฉพาะเมื่อวิศวกรคนนั้นว่าง ผ่าน SSH และอาศัยความจำล้วน ๆ พอเขาลาพักร้อน การดีพลอยก็หยุด พอเขาลาออก ความสามารถในการส่งงานของบริษัทก็หายไปด้วย
วิธีที่เราจัดการเราย้ายทุกขั้นตอนเข้าไปป์ไลน์ที่เก็บเป็นเวอร์ชันและทำงานเหมือนกันสำหรับทุกคน แล้วสอนทีมของคุณให้สั่งรันได้ด้วยตัวเอง
ทดสอบกันบนโปรดักชัน
ไม่มีสภาพแวดล้อม staging การทดสอบจริงครั้งแรกของทุกการเปลี่ยนแปลงจึงเกิดต่อหน้าลูกค้า ทุกคนเลยดีพลอยด้วยความลุ้นตอนดึก ซึ่งเป็นช่วงที่แก้ความผิดพลาดได้ยากที่สุดพอดี
วิธีที่เราจัดการการใช้คอนเทนเนอร์ทำให้สร้าง staging ที่เหมือนของจริงได้ในต้นทุนต่ำ ทุกการเปลี่ยนแปลงถูกพิสูจน์ที่นั่นก่อน ด้วยอิมเมจชุดเดียวกับที่จะขึ้นโปรดักชัน
ข้อมูลสำรองที่ไม่เคยลองกู้
มี cron job เขียนไฟล์สำรองไว้ที่ไหนสักแห่งมาหลายปี แต่ไม่เคยมีใครลองกู้คืนสักครั้ง จึงไม่มีใครรู้ว่าไฟล์ใช้ได้จริงไหม ครบถ้วนหรือเปล่า และถ้าถึงวันที่เลวร้ายที่สุดของปี การกู้คืนจะใช้เวลานานเท่าไร
วิธีที่เราจัดการเราตั้งกำหนดการกู้คืนลงสภาพแวดล้อมทดสอบ พร้อมบันทึกผลและเวลาที่ใช้ทุกครั้ง การกู้ระบบจึงเป็นขั้นตอนที่ซ้อมมาแล้ว ไม่ใช่การภาวนา
เซิร์ฟเวอร์ที่ไม่มีใครกล้าแตะ
เครื่องหนึ่งสะสมการแก้ไขด้วยมือมานานหลายปี ระบบปฏิบัติการเก่า ไม่มีใครจำได้ว่าเซอร์วิสครึ่งหนึ่งมีไว้ทำไม และการอัปเกรดถูกเลื่อนตลอด เพราะไม่มีใครทำนายได้ว่าอะไรจะพัง
วิธีที่เราจัดการเราตรวจสอบแบบอ่านอย่างเดียวก่อน แล้วทยอยย้ายงานแต่ละตัวเข้าคอนเทนเนอร์ที่สร้างขึ้นใหม่ได้เสมอ ค่อย ๆ ปลดระวางส่วนที่เป็นปริศนาไปทีละชิ้น โดยทุกอย่างยังทำงานตามปกติ
ลูกค้ารู้ว่าระบบล่มก่อนคุณ
ไม่มีระบบเฝ้าระวัง การแจ้งเตือนแรกจึงเป็นโทรศัพท์จากลูกค้าที่ไม่พอใจ ซึ่งแปลว่าระบบล่มมานานเท่ากับเวลาที่ลูกค้าทนจนทนไม่ไหวแล้ว
วิธีที่เราจัดการเราติดตั้งการเฝ้าระวังสถานะระบบ ทรัพยากร และข้อผิดพลาดก่อนงานอื่นทั้งหมด และตั้งการแจ้งเตือนให้ส่งถึงคนที่ระบุชื่อและตกลงจะรับไว้แล้ว
—— เรียนรู้จากโครงการอื่น
ข้อผิดพลาดที่เราพบบ่อย และวิธีหลีกเลี่ยง
รีบใช้ Kubernetes เร็วเกินไป
Kubernetes แก้ปัญหาที่บริษัทส่วนใหญ่ยังไม่มี แต่เก็บค่าเช่าเป็นความซับซ้อนทุกวัน หลายทีมนำมาใช้แล้วพบว่าเสียเวลาดูแลแพลตฟอร์มมากกว่าดูแลผลิตภัณฑ์ เราเลือกเครื่องมือให้ตรงกับขนาดจริงของคุณ ซึ่งบ่อยครั้งคือ Docker Compose ที่ตั้งค่ามาดี พร้อมเขียนเงื่อนไขชัด ๆ ว่าเมื่อไรจึงควรขยับขึ้นไป
เก็บรหัสลับไว้ในโค้ด
รหัสผ่านฐานข้อมูลและ API key มักถูก commit ลง repository หรือวางไว้ในกลุ่มแชท และอยู่ที่นั่นนานกว่าพนักงานทุกคนที่เคยเห็นมัน repo หลุดครั้งเดียวก็เปิดเผยทุกอย่างพร้อมกัน เราเก็บรหัสลับในระบบจัดการเฉพาะตั้งแต่วันแรก ไม่ให้อยู่ใน repository เลย และเปลี่ยนรหัสทุกตัวที่เคยถูกส่งต่อด้วยวิธีอื่น
เก็บข้อมูลสำรองไว้บนเครื่องเดียวกัน
โฟลเดอร์สำรองบนดิสก์โปรดักชันแทบไม่ป้องกันอะไรเลย เพราะดิสก์พัง แรนซัมแวร์ หรือคำสั่ง rm ที่พิมพ์ผิดหน้าต่าง จะพาไฟล์สำรองหายไปพร้อมต้นฉบับ เราส่งข้อมูลสำรองแบบเข้ารหัสออกไปเก็บนอกเครื่องตามกำหนดเวลา และพิสูจน์ด้วยการซ้อมกู้คืนเป็นระยะ
ดีพลอยโดยไม่มีทางถอย
หลายทีมปล่อยเวอร์ชันใหม่ได้ แต่ย้อนกลับไม่เป็น ดีพลอยพลาดตอนหกโมงเย็นจึงกลายเป็นการไล่หาบั๊กตอนเที่ยงคืน ทางถอยต้องออกแบบไว้ก่อนเกิดเหตุ ไปป์ไลน์ทุกชุดที่เราสร้างจะตรวจสุขภาพเวอร์ชันใหม่ และย้อนกลับไปเวอร์ชันที่ดีล่าสุดโดยอัตโนมัติเมื่อการตรวจไม่ผ่าน
อัปเกรดเครื่องเพื่อกลบคิวรีช้า
พอระบบช้า ปฏิกิริยาแรกมักเป็นการเช่าเครื่องใหญ่ขึ้น ซึ่งช่วยได้เดือนเดียวแต่ค่าใช้จ่ายเพิ่มเป็นเท่าตัว สาเหตุจริงมักเป็น index ที่ขาดหรือคิวรีที่ช้าลงตามข้อมูลที่โตขึ้น เราดูเมตริกก่อนเสมอ และขยายฮาร์ดแวร์ก็ต่อเมื่อซอฟต์แวร์ทำงานอย่างมีประสิทธิภาพแล้วจริง ๆ
—— รูปแบบการเริ่มงาน
สามวิธี ในการเริ่มต้นกับเรา
ตรวจสุขภาพโครงสร้างพื้นฐาน
การตรวจสอบแบบอ่านอย่างเดียวในขอบเขตที่ตกลงไว้ล่วงหน้า ครอบคลุมเซิร์ฟเวอร์ ไปป์ไลน์ ข้อมูลสำรอง และการเฝ้าระวัง คุณจะได้รายการปัญหาที่จัดลำดับแล้วพร้อมประเมินแรงงานของแต่ละข้อ นำไปใช้ได้ไม่ว่าจะจ้างเราแก้ต่อหรือไม่
- ตรวจเซิร์ฟเวอร์ DNS TLS ข้อมูลสำรอง และสิทธิ์เข้าถึง โดยไม่แก้ไขสิ่งใด
- จัดลำดับตามความเสี่ยง พร้อมประเมินแรงงานเป็นรายข้อ
- รายงานที่ผู้ให้บริการรายไหนก็นำไปทำตามได้ ไม่ผูกมัดกับเรา
สร้างไปป์ไลน์และแพลตฟอร์ม
โปรเจกต์ตามขอบเขตที่พาคุณจากการดีพลอยด้วยมือ ไปสู่ระบบคอนเทนเนอร์พร้อม CI/CD การเฝ้าระวัง และข้อมูลสำรองที่ผ่านการทดสอบ ขอบเขตเขียนชัดเป็นลายลักษณ์อักษร วิศวกรคนเดิมดูแลตั้งแต่ต้นจนจบ
- แอปในคอนเทนเนอร์ พร้อมสภาพแวดล้อม staging และโปรดักชัน
- CI/CD พร้อมการตรวจสุขภาพระบบและย้อนกลับอัตโนมัติ
- คู่มือปฏิบัติงานและเซสชันส่งมอบให้ทีมของคุณ
ดูแลระบบรายเดือน
ดูแลระบบรายเดือน ทั้งระบบที่เราสร้างหรือระบบเดิมของคุณ ครอบคลุมการอัปเดตแพตช์ การตอบสนองต่อการแจ้งเตือน การซ้อมกู้คืน และการปรับปรุงเล็ก ๆ น้อย ๆ พร้อมรายงานที่อ่านจบในห้านาที
- อัปเดตแพตช์ระบบปฏิบัติการและไลบรารีตามรอบเวลาที่กำหนด
- ซ้อมกู้คืนข้อมูลเป็นประจำ พร้อมบันทึกเวลาที่ใช้
- รายงานรายเดือน ทั้งเหตุการณ์ การเปลี่ยนแปลง ค่าใช้จ่าย และข้อแนะนำถัดไป
พาร์ทเนอร์วางระบบของคุณ
พาร์ทเนอร์ตัวจริง ไม่ใช่ ตัวแทนขายไลเซนส์
เราไม่ได้ไล่ตามยอดขายไลเซนส์ เราออกแบบ สร้าง และรับผิดชอบระบบที่ธุรกิจใช้ดำเนินงานจริง ที่ปรึกษาที่วางขอบเขตงานให้คุณจะอยู่จนถึงวันใช้งานจริงและการดูแลหลังจากนั้น และทุกอย่างที่เราตกลงถูกเขียนเป็นขอบเขตคงที่ในแต่ละระยะ
—— งานที่เสร็จหน้าตาเป็นอย่างไร
ผลลัพธ์ที่คุณ ตรวจสอบได้เอง
ใครในทีมก็ปล่อยเวอร์ชันได้
การดีพลอยเหลือแค่คำสั่งเดียวหรือปุ่มเดียว พร้อมเอกสารที่ดีพอให้พนักงานใหม่ทำได้ตั้งแต่สัปดาห์แรก และคุณพิสูจน์ได้ง่าย ๆ ด้วยการลองให้เขาทำ
การกู้คืนที่คุณเห็นกับตา
ก่อนถือว่างานเสร็จ เราจะกู้คืนข้อมูลสำรองให้คุณดูต่อหน้า พร้อมจดเวลาที่ใช้ การกู้ระบบจากเหตุร้ายจึงเป็นตัวเลขที่คุณเคยเห็นจริง ไม่ใช่ข้อความในสัญญา
โครงสร้างพื้นฐานที่อ่านได้
เซิร์ฟเวอร์ เซอร์วิส และไปป์ไลน์ถูกนิยามเป็นไฟล์ใน repository ของคุณ ไม่ใช่ในความทรงจำของใครคนหนึ่ง วิศวกรฝีมือดีที่ไม่เคยเจอเราเลย ก็เข้าใจระบบได้จาก repo เพียงอย่างเดียว
การแจ้งเตือนมาก่อนคำร้องเรียน
การเฝ้าระวังถูกตั้งให้ส่งถึงคนที่ระบุชื่อไว้ และทุกเหตุการณ์ทิ้งไทม์ไลน์ให้ย้อนดูได้ เมื่อมีอะไรพัง คุณจะรู้จากระบบของตัวเอง ก่อนที่ลูกค้าจะโทรมาบอกหลายนาที
—— วิธีการทำงาน
ขั้นตอนการทำงานเป็นอย่างไร
ทำเป็นคอนเทนเนอร์
แอปทำงานเหมือนกันทั้งบนเครื่องนักพัฒนาและบนโปรดักชัน ตัดปัญหาประเภท "เครื่องผมรันได้" ออกไปทั้งหมด
ทำไปป์ไลน์ให้อัตโนมัติ
ตรวจสไตล์โค้ด ตรวจชนิดข้อมูล ทดสอบ สแกนความปลอดภัย บิลด์ ดีพลอย ตรวจสุขภาพระบบ และย้อนกลับเมื่อผิดพลาด ไม่มีขั้นตอนที่ต้องทำมือแล้วลืม
เฝ้าระวัง
ตั้งค่าล็อก เมตริก และการแจ้งเตือนก่อนปล่อยเวอร์ชันแรก เมื่อเกิดเหตุจึงวินิจฉัยได้ ไม่ใช่เดา
—— ทำไมต้องเรา
สิ่งที่คุณจะได้รับ ซึ่งหาไม่ได้จากที่อื่น
ย้อนกลับอัตโนมัติ
หากตรวจสุขภาพระบบไม่ผ่าน ระบบจะย้อนกลับไปเวอร์ชันที่ดีล่าสุดโดยไม่ต้องปลุกใคร
แยกขาดจากเว็บอื่นของคุณ
บนเซิร์ฟเวอร์ที่ใช้ร่วมกัน เราแยกเครือข่าย พอร์ต ผู้ใช้ และวอลุ่ม เพื่อไม่ให้งานใหม่รบกวนระบบที่ใช้งานอยู่
ข้อมูลสำรองที่ผ่านการทดสอบ
กู้คืนข้อมูลลงสภาพแวดล้อมทดสอบตามกำหนด เพื่อพิสูจน์ว่าข้อมูลสำรองใช้ได้ก่อนถึงเวลาจำเป็น
ยังไม่แน่ใจว่าจะเริ่มตรงไหน? คุยสั้น ๆ ก็รู้คำตอบ
ปรึกษาผู้เชี่ยวชาญ Odoo ➜—— ทำไมต้องเป็นเรา
การทำงานกับเรา เป็นแบบนี้จริง ๆ
วิศวกรคนเดิม ตั้งแต่คุยครั้งแรกจนขึ้นระบบ
คนที่ตรวจเซิร์ฟเวอร์ของคุณคือคนเดียวกับที่สร้างไปป์ไลน์และส่งมอบงาน ไม่มีอะไรตกหล่นระหว่างคำสัญญาของฝ่ายขายกับงานจริงของวิศวกร เพราะเป็นคนคนเดียวกัน
ขอบเขตเขียนชัด ตกลงทีละเฟส
ทุกเฟสมีขอบเขตเป็นลายลักษณ์อักษรที่ตกลงกันก่อนเริ่มงาน คำว่า "เสร็จ" จึงเป็นเช็กลิสต์ ไม่ใช่ความรู้สึก หากเจอเรื่องใหม่ระหว่างทาง เราจะบอกคุณและปรับขอบเขตเป็นลายลักษณ์อักษร ไม่ใช่บวกเงียบ ๆ เข้าไปในบิลที่คลุมเครือ
คู่มือเป็นภาษาไทยและอังกฤษ
เราส่งมอบงานเป็นภาษาไทยและอังกฤษโดยเจ้าของภาษา คู่มือที่แอดมินของคุณต้องเปิดอ่านตอนตีสองจึงเป็นภาษาที่เขาคิดตามได้ทันที ความต่างข้อนี้จะเห็นชัดในจังหวะที่สำคัญที่สุดพอดี
สามไทม์โซน ทีมเดียว
สำนักงานในกรุงเทพฯ นิวยอร์ก และเดลี NCR ทำให้เวลาทำงานของเราครอบคลุมเกือบตลอดทั้งวัน คำถามที่ส่งมาตอนเย็นของคุณ มักได้คำตอบก่อนคุณเริ่มงานเช้าวันถัดไป
เรารู้จักไส้ในของ Odoo
ในฐานะพาร์ตเนอร์ทางการของ Odoo เราดีพลอย Odoo ให้ลูกค้าอยู่เป็นประจำ ไปป์ไลน์ของเราจึงรองรับจุดเฉพาะตัวของมันอยู่แล้ว ทั้ง filestore จำนวน worker คอนเทนเนอร์สำหรับ cron และการคัดลอกฐานข้อมูลอย่างปลอดภัยไว้ทำ staging บริษัท DevOps ทั่วไปต้องเรียนรู้เรื่องพวกนี้บนบิลของคุณ
ทุกอย่างเป็นชื่อของคุณ
บัญชีคลาวด์ โดเมน registry และ repository เปิดภายใต้ชื่อของคุณ เราทำงานด้วยสิทธิ์ที่คุณมอบให้ วันไหนเลิกใช้บริการ คุณแค่ถอนสิทธิ์แล้วเก็บทุกอย่างไว้ได้ทั้งหมด ซึ่งมันควรเป็นแบบนั้นอยู่แล้ว
เราลดขนาดก่อนคิดขยาย
แรงจูงใจของเราคือระบบที่คุณจ่ายไหวไปอีกหลายปี ไม่ใช่บิลก้อนแรกที่ใหญ่ที่สุด ถ้า VPS ราคาย่อมเยาทำงานได้ครบ เราก็จะแนะนำแบบนั้นเป็นลายลักษณ์อักษรพร้อมเหตุผล
ตรงไปตรงมาทั้งเรื่องไลเซนส์และโครงสร้างพื้นฐาน
เราบอกลูกค้าตรง ๆ เมื่อ Odoo Community ที่ค่าไลเซนส์ 0 บาทเพียงพอกับงาน ส่วน Enterprise ทาง Odoo เรียกเก็บกับคุณโดยตรง เราไม่บวกเพิ่ม โครงสร้างพื้นฐานก็ใช้หลักเดียวกัน ผู้ให้บริการเรียกเก็บกับคุณโดยตรง ค่าบริการของเราคือค่างานตามขอบเขต ไม่มีอะไรซ่อนอยู่ข้างใน
—— อธิบายระดับพาร์ทเนอร์
ระดับพาร์ทเนอร์ Odoo บอกอะไรและไม่บอกอะไร
Odoo จัดระดับพาร์ทเนอร์จากจำนวนใบรับรองและยอดขายไลเซนส์ ระดับบอกถึงความจริงจังกับโปรแกรม แต่ไม่ได้บอกว่าใครจะเป็นคนทำโครงการของคุณจริง ๆ คำถามนี้ควรถามพาร์ทเนอร์ทุกราย รวมถึงเราด้วย
Learning Partner
เพิ่งเข้าร่วมโปรแกรม กำลังสร้างที่ปรึกษาที่ผ่านการรับรองและผลงานอ้างอิงชุดแรก ไม่ใช่สัญญาณอันตราย ทุกรายเริ่มจากจุดนี้ แต่ควรขอดูผลงานจริง
Official Partner
มีที่ปรึกษาที่ผ่านการรับรองและส่งมอบงานจริงต่อเนื่อง เราอยู่ระดับนี้ ลงทะเบียนผ่านโปรแกรมอินเดีย และส่งมอบจากไทย สหรัฐฯ และอินเดีย
Silver & Gold
ระดับที่สูงขึ้นได้จากยอดขายไลเซนส์และจำนวนบุคลากรที่ผ่านการรับรองเป็นหลัก เป็นสัญญาณของขนาดองค์กร แต่ไม่ได้แปลว่าเหมาะกับโครงการของคุณเสมอไป
—— เหมาะกับใคร
ออกแบบตามขนาดธุรกิจคุณ ไม่ใช่ย่อส่วนมาให้
ธุรกิจกำลังเติบโต (5–100 คน)
บริษัทขนาดนี้ส่วนใหญ่ต้องการความเสถียร ไม่ใช่ทีมแพลตฟอร์ม เป้าหมายคือโครงสร้างพื้นฐานที่ทำงานเงียบ ๆ ระหว่างที่ทุกคนทำงานหลักของตัวเอง
- หลายกรณี VPS เครื่องเดียวที่ตั้งค่ามาดีก็ครอบคลุมทุกอย่าง ในราคาที่แทบไม่รู้สึก
- คุณได้ระบบดีพลอย การเฝ้าระวัง และข้อมูลสำรองที่ผ่านการทดสอบ โดยไม่ต้องจ้างวิศวกร DevOps ประจำ
- ขอบเขตคงที่ทำให้โปรเจกต์อยู่ในงบ และวันจบงานเป็นวันจริง
- สัญญาดูแลรายเดือนเริ่มจากเล็ก และขยายก็ต่อเมื่อระบบของคุณโตขึ้นเท่านั้น
ธุรกิจขนาดกลาง (100–500 คน)
ที่ขนาดนี้โจทย์เปลี่ยนไป มีหลายทีมส่งงานพร้อมกัน มีการตรวจสอบที่ต้องผ่าน และดาวน์ไทม์ที่วัดเป็นเงินจริง งานส่วนใหญ่จึงเป็นเรื่องกระบวนการมากกว่าตัวเซิร์ฟเวอร์
- สภาพแวดล้อมที่แยกจากกันและด่านตรวจโค้ด ทำให้หลายทีมปล่อยงานได้โดยไม่ชนกัน
- การควบคุมสิทธิ์และบันทึกการใช้งานถูกวางให้ตอบคำถามด้าน PDPA และการตรวจสอบจากลูกค้าได้
- การทบทวนค่าใช้จ่ายช่วยจับเครื่องที่ใหญ่เกินจำเป็นและทรัพยากรที่ถูกลืม ซึ่งสะสมมากขึ้นตามขนาดองค์กร
- วางและซ้อมขั้นตอนรับมือเหตุการณ์ร่วมกับทีมของคุณ ทั้งการแจ้งเตือน การส่งต่อเรื่อง และบันทึกหลังเหตุการณ์
—— เครื่องมือที่เกี่ยวข้อง
งานบริการนี้ เกี่ยวข้องกับอะไรบ้าง
—— บริการที่เกี่ยวข้อง
ดูบริการอื่น ๆ ของเรา
—— คำถามที่พบบ่อย
คำถามที่ลูกค้ามักถามเกี่ยวกับบริการนี้
ทำงานกับเซิร์ฟเวอร์เดิมของเราได้หรือไม่
ได้ และเราจะตรวจสอบแบบอ่านอย่างเดียวก่อน บนเครื่องที่มีเว็บใช้งานจริงอยู่ เราจะแยกทุกอย่างออกและไม่แตะสิ่งที่ทำงานอยู่แล้ว
ใช้ AWS หรืออะไรที่ง่ายกว่า
แล้วแต่ขนาดงานของคุณ VPS เครื่องเดียวที่ตั้งค่าดี ดีกว่าบัญชีคลาวด์ที่ตั้งค่าผิด และราคาถูกกว่ามาก
เราจำเป็นต้องใช้ Kubernetes ไหม
ส่วนใหญ่ยังไม่จำเป็น ต่ำกว่าขนาดหนึ่ง Kubernetes เพิ่มภาระการดูแลโดยไม่ได้เพิ่มความเสถียร ระบบคอนเทนเนอร์ด้วย Compose ให้ประโยชน์เกือบทั้งหมดอยู่แล้ว และเราจะบอกเงื่อนไขชัด ๆ ว่าขนาดทีม จำนวนเซอร์วิส หรือรูปแบบทราฟฟิกแบบไหนที่จะทำให้คำตอบของเราเปลี่ยน
ใครเป็นเจ้าของบัญชีและสิทธิ์เข้าถึง
คุณเป็นเจ้าของเสมอ บัญชีคลาวด์ โดเมน และ repository ถูกสร้างในชื่อของคุณ เราทำงานผ่านสิทธิ์ที่คุณมอบให้และถอนได้ทุกเมื่อ หากเลิกใช้บริการ ก็ไม่ต้องย้ายอะไรออกจากบัญชีของเรา เพราะไม่เคยมีอะไรอยู่ที่นั่นตั้งแต่แรก
ตอนย้ายไประบบใหม่จะมีดาวน์ไทม์ไหม
เราซ้อมการย้ายบน staging ก่อน แล้วรันระบบใหม่คู่กับระบบเดิมก่อนสลับทราฟฟิก โดยมากผ่านการเปลี่ยน DNS ที่ตั้ง TTL ไว้สั้น ระบบส่วนใหญ่จึงหยุดเพียงไม่กี่นาทีในช่วงเวลาที่เงียบที่สุดตามที่ตกลงกันล่วงหน้า และระบบเดิมยังอยู่ครบเป็นทางถอยเสมอ
ถ้าระบบแจ้งเตือนกลางดึก ใครเป็นคนดู
ขึ้นอยู่กับรูปแบบบริการที่เลือก และไม่ว่าแบบไหนเราเขียนไว้ชัดเจน โปรเจกต์สร้างระบบจบด้วยการแจ้งเตือนที่ส่งถึงทีมของคุณ พร้อมคู่มือรับมือกรณีที่พบบ่อย ส่วนสัญญาดูแลรายเดือนเพิ่มการตอบสนองจากเราตามช่วงเวลาที่ตกลงกัน สำนักงานในกรุงเทพฯ นิวยอร์ก และเดลี NCR ทำให้ครอบคลุมเวลาได้กว้างจริง แต่เราสัญญาเป็นชั่วโมงที่ระบุชัด ไม่ใช่คำสัญญาลอย ๆ
บริการนี้ใช้ได้กับระบบ Odoo เท่านั้นหรือเปล่า
ไม่ใช่เฉพาะ Odoo ไปป์ไลน์ การเฝ้าระวัง และการสำรองข้อมูลใช้หลักการเดียวกันกับเว็บแอป API หรือฐานข้อมูลใดก็ได้ และเรารับงานระบบที่ไม่ใช่ Odoo ด้วย ประสบการณ์ด้าน Odoo เป็นข้อได้เปรียบ ไม่ใช่ข้อจำกัด หากคุณใช้ Odoo ควบคู่กับแอปอื่น ระบบชุดเดียวก็ดูแลได้ทั้งหมด
มาดูกันว่า Odoo เหมาะกับธุรกิจของคุณจริงหรือไม่
คุยกันสั้น ๆ พร้อมคำตอบตรงไปตรงมา ถ้ามันไม่ใช่ระบบที่เหมาะกับคุณ เราจะบอกตามตรง