Opsgenie สิ้นสุดอายุการใช้งาน: การปิดตัวปี 2027 และทางเลือกอื่น

สารบัญ

• กำหนดการสิ้นสุดอายุการใช้งานของ Opsgenie
• อะไรจะหยุดทำงานหลังวันที่ 5 เมษายน 2027
• ตัวแทนอย่างเป็นทางการ: Jira Service Management
• เมื่อไรที่ทางเลือกแทน Opsgenie แบบเบา ๆ จึงเหมาะสม
• วิธีทดลองใช้ Echobell ก่อน Opsgenie ปิดตัว
• 1. เลือกแหล่งแจ้งเตือนวิกฤตมาหนึ่งแหล่ง
• 2. สร้างช่องใน Echobell
• 3. เพิ่มปลายทาง webhook ที่สอง
• 4. จับคู่ระดับความเร่งด่วนอย่างตั้งใจ
• 5. รันทั้งสองเส้นทางระหว่างช่วงเวร on-call จริง
• 6. บันทึกไว้ว่า Echobell ไม่ได้แทนที่อะไรบ้าง
• เช็กลิสต์การย้ายออกจาก Opsgenie
• คำถามที่พบบ่อย
• Opsgenie กำลังจะเลิกให้บริการจริงไหม
• อะไรจะมาแทน Opsgenie
• Echobell แทนที่ Opsgenie ได้ทั้งหมดไหม
• เราใช้ Echobell ระหว่างย้ายออกจาก Opsgenie ได้ไหม
• ควรเริ่มย้ายเมื่อไร
• เลือกตัวแทนที่เล็กที่สุดที่ครอบคลุมงานจริง

Opsgenie จะปิดตัวลงในวันที่ 5 เมษายน 2027 หลังจากวันนั้นจะไม่สามารถเข้าใช้ผลิตภัณฑ์ได้อีก การเชื่อมต่อและ REST API ต่าง ๆ จะหยุดทำงาน และข้อมูลลูกค้าที่ยังไม่ได้ย้ายออกจะถูกลบทิ้ง

สำหรับทีมส่วนใหญ่ เส้นทางอย่างเป็นทางการของ Atlassian ที่ให้ย้ายไป Jira Service Management คือทางแทนที่แบบเต็มรูปแบบที่ปลอดภัยที่สุด แต่ถ้าคุณใช้ Opsgenie เพียงเพื่อเปลี่ยนอีเวนต์จากระบบมอนิเตอร์ให้เป็นการแจ้งเตือนเร่งด่วนบนมือถือ นี่ก็เป็นจังหวะดีที่จะตัดสินใจว่าคุณยังต้องการแพลตฟอร์มจัดการเหตุการณ์แบบครบวงจรอยู่หรือไม่ หรือแค่ชั้นแจ้งเตือนเล็ก ๆ ก็พอ

คู่มือนี้อธิบายเส้นตาย สิ่งที่จะเปลี่ยนไป และวิธีเลือกเส้นทางย้ายระบบโดยไม่ทิ้งช่องว่างในการดูแลเวร on-call

กำหนดการสิ้นสุดอายุการใช้งานของ Opsgenie

ลูกค้าเดิมยังใช้ Opsgenie ต่อได้จนถึงวันปิดตัว แต่การรอจนสัปดาห์สุดท้ายสร้างความเสี่ยงที่เลี่ยงได้ Atlassian แนะนำให้ย้ายให้เสร็จก่อนวันที่ 5 เมษายน 2027 ดูหน้าการย้ายระบบ Opsgenie อย่างเป็นทางการ และคำถามที่พบบ่อยเรื่องสิทธิ์การใช้งาน Opsgenie สำหรับกำหนดการล่าสุด

อะไรจะหยุดทำงานหลังวันที่ 5 เมษายน 2027

เมื่อ Opsgenie ถูกปิด ทีมจะเข้าถึงผลิตภัณฑ์และเวิร์กโฟลว์ใดก็ตามที่ยังพึ่งพามันไม่ได้อีก ซึ่งรวมถึง:

• การแจ้งเตือนและเวิร์กโฟลว์ on-call ของ Opsgenie
• แอปมือถือ Opsgenie
• การเชื่อมต่อของ Opsgenie ที่ยังเหลืออยู่
• ปลายทาง REST API ของ Opsgenie
• ข้อมูลและการตั้งค่าที่ยังไม่ได้ย้ายออก

จุดตัดนี้กระทบมากกว่าแค่แดชบอร์ดบนเว็บ ตัวมอนิเตอร์อาจยังตรวจพบเหตุขัดข้องต่อไป ขณะที่การเชื่อมต่อ Opsgenie เดิมกลายเป็นทางตันไปแบบเงียบ ๆ คู่มือของ Atlassian เรื่องสิ่งที่เกิดขึ้นเมื่อ Opsgenie ถูกปิด แนะนำให้ย้ายเวิร์กโฟลว์การแจ้งเตือนและ on-call ทั้งหมดก่อนเป็นอันดับแรก

ตัวแทนอย่างเป็นทางการ: Jira Service Management

Jira Service Management คือตัวเลือกตั้งต้นเมื่อคุณต้องรักษารูปแบบการทำงานของ Opsgenie ไว้ทั้งหมด ทั้งการแจ้งเตือน ตารางเวร นโยบายการยกระดับ เวิร์กโฟลว์จัดการเหตุการณ์ และข้อมูลย้อนหลัง

เจ้าของบัญชี Opsgenie สามารถเปิด Settings → Plan your move เพื่อดูแพ็กเกจ Jira Service Management ที่แนะนำและกำหนดตารางการย้ายได้ Atlassian ระบุว่าข้อมูลและการตั้งค่าส่วนใหญ่ของ Opsgenie จะซิงก์ให้อัตโนมัติได้ หลังจากเลือกและอนุมัติแพ็กเกจปลายทางแล้ว

อย่าคิดไปเองว่าทุกฟีเจอร์จะย้ายไปได้แบบไม่เปลี่ยนแปลง การเปรียบเทียบฟีเจอร์ของ Atlassian ระบุถึงช่องทางติดต่อที่ขึ้นกับแพ็กเกจ ฟีเจอร์ที่เลิกใช้แล้ว การเชื่อมต่อที่ต้องตั้งค่าด้วยมือ และปลายทาง API ที่ต้องอัปเดต

มีข้อจำกัดสำคัญข้อหนึ่ง คือเครื่องมือย้ายระบบในแอปรองรับปลายทางที่เป็น Atlassian Cloud เท่านั้น ไม่รองรับ Jira Service Management Data Center ทีมที่ยังอยู่บน Data Center จึงต้องประเมินเส้นทางอื่น แทนที่จะคาดหวังการย้ายโดยตรง Atlassian ระบุข้อจำกัดนี้ไว้ในคู่มือการกำหนดตารางย้ายระบบ

เมื่อไรที่ทางเลือกแทน Opsgenie แบบเบา ๆ จึงเหมาะสม

ไม่ใช่ทุกบัญชี Opsgenie ที่ใช้การหมุนเวร ผังการยกระดับ ไทม์ไลน์เหตุการณ์ และการวิเคราะห์ข้อมูล ทีมเล็ก ๆ บางทีมใช้มันเพื่องานที่แคบกว่านั้น:

1. เครื่องมือมอนิเตอร์ตรวจพบเหตุการณ์วิกฤต
2. การเชื่อมต่อส่งอีเวนต์ต่อไป
3. โทรศัพท์ส่งเสียงดังพอที่จะทำให้มีคนตอบสนอง

ถ้านั่นคือระบบของคุณ การเปลี่ยนแพลตฟอร์มทั้งชุดอาจเพิ่มขั้นตอนมากเกินความจำเป็น Echobell คือชั้นนำส่งเฉพาะทางที่รับทริกเกอร์จาก webhook หรืออีเมล แล้วส่งการแจ้งเตือนบนมือถือแบบมาตรฐาน สำคัญตามเวลา หรือสายโทรเข้า

Echobell ไม่ใช่ตัวแทนของ Opsgenie แบบหนึ่งต่อหนึ่ง มันไม่ได้แทนที่การจัดตารางเวร on-call ขั้นสูง นโยบายการยกระดับ การบัญชาการเหตุการณ์ หรือการรายงานหลังเกิดเหตุ สำหรับเวิร์กโฟลว์เหล่านั้นให้ใช้ Jira Service Management หรือแพลตฟอร์มจัดการเหตุการณ์แบบเต็มรูปแบบอื่น

Echobell เหมาะเมื่อ:

• แหล่งมอนิเตอร์ของคุณตัดสินอยู่แล้วว่าอีเวนต์ใดวิกฤต
• มีกลุ่มคนเล็ก ๆ ที่ค่อนข้างคงที่รับผิดชอบเวร on-call ร่วมกัน
• คุณต้องการให้ webhook ส่งถึงมือถือโดยตรงโดยไม่ต้องรื้อระบบมอนิเตอร์
• คุณต้องการระดับความเร่งด่วนที่ต่างกันสำหรับเหตุการณ์ระดับวิกฤต คำเตือน และข้อมูลทั่วไป
• คุณอยากทดลองชั้นการนำส่งการแจ้งเตือนแยกต่างหากก่อนจะเปลี่ยนส่วนอื่นของระบบ

หากต้องการเปรียบเทียบทีละฟีเจอร์ ดูที่ Echobell เทียบกับ Opsgenie

วิธีทดลองใช้ Echobell ก่อน Opsgenie ปิดตัว

การย้ายที่ปลอดภัยที่สุดคือการทดสอบแบบขนาน ไม่ใช่การสลับทีเดียวตอนถึงเส้นตาย

1. เลือกแหล่งแจ้งเตือนวิกฤตมาหนึ่งแหล่ง

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

2. สร้างช่องใน Echobell

สร้างช่องสำหรับบริการนั้นแล้วแชร์ให้ผู้ตอบสนองที่ต้องได้รับการแจ้งเตือน ผู้ติดตามแต่ละคนเลือกพฤติกรรมการแจ้งเตือนที่เหมาะกับตัวเองบนเครื่องของตนได้

3. เพิ่มปลายทาง webhook ที่สอง

คงเส้นทางเดิมของ Opsgenie ไว้ แล้วเพิ่ม webhook ของช่อง Echobell เข้าไปในแหล่งมอนิเตอร์ payload สำหรับทดสอบพื้นฐานหน้าตาแบบนี้:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Production API is down",
    "body": "Health check failed in us-east-1",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

ใช้โทเคนสมมติในสคริปต์และในตัวจัดการ secret อย่า commit URL ของ webhook ของช่องจริงเข้าไปใน source control เอกสาร webhookครอบคลุมเรื่องตัวแปรของ payload และเทมเพลต

ถ้าแหล่งข้อมูลรองรับอีเมลแต่ไม่รองรับ webhook ให้ใช้ทริกเกอร์อีเมลแทน

4. จับคู่ระดับความเร่งด่วนอย่างตั้งใจ

สงวนการแจ้งเตือนแบบสายโทรไว้สำหรับเหตุการณ์ที่ต้องตอบสนองทันที ใช้การแจ้งเตือนแบบสำคัญตามเวลาสำหรับคำเตือนที่สำคัญ และใช้การแจ้งเตือนมาตรฐานสำหรับเรื่องที่เป็นข้อมูลทั่วไป วิธีนี้รักษาความน่าเชื่อถือของเส้นทางเร่งด่วนไว้ได้ แทนที่จะไปสร้างความล้าจากการแจ้งเตือนขึ้นใหม่ในแอปใหม่

5. รันทั้งสองเส้นทางระหว่างช่วงเวร on-call จริง

เปรียบเทียบเวลาที่ใช้ในการนำส่ง ความชัดเจนของข้อความ การแจ้งเตือนผิดพลาด และพฤติกรรมของผู้ตอบสนอง อย่าลืมทดสอบการแจ้งเตือนตอนระบบกลับมาปกติด้วย ไม่ใช่เฉพาะตอนล้มเหลว

6. บันทึกไว้ว่า Echobell ไม่ได้แทนที่อะไรบ้าง

ก่อนถอด Opsgenie ออกจากบริการนั้น ให้กำหนดผู้รับผิดชอบสำหรับข้อกำหนดที่ยังเหลืออยู่ ทั้งตารางเวร การยกระดับ การรับทราบ การตรวจสอบ และการรายงาน ถ้าข้อกำหนดเหล่านั้นจำเป็นจริง ก็ให้คงไว้ในระบบจัดการเหตุการณ์แบบเต็มรูปแบบ

เช็กลิสต์การย้ายออกจาก Opsgenie

ใช้เช็กลิสต์นี้ก่อนถึงวันปิดตัว 5 เมษายน 2027:

• ทำบัญชีรายการการเชื่อมต่อขาเข้า heartbeat ไคลเอนต์ API และการเชื่อมต่อทางอีเมลทุกรายการ
• ส่งออกหรือย้ายข้อมูลย้อนหลังที่ทีมของคุณต้องเก็บไว้
• บันทึกตารางเวร นโยบายการยกระดับ กฎการแจ้งเตือน และผู้รับผิดชอบ
• ระบุฟีเจอร์และการเชื่อมต่อที่เลิกใช้แล้วซึ่งต้องหาตัวแทนด้วยมือ
• อัปเดตสคริปต์ที่เรียกปลายทาง opsgenie.com หรือ opsgenie.net
• ทดสอบการแจ้งเตือน การกลับมาปกติ การรับทราบ และการนำส่งนอกเวลาทำการ
• รันเส้นทางเก่าและใหม่คู่ขนานกันอย่างน้อยหนึ่งรอบเวร on-call ที่เป็นตัวแทนได้
• ถอดเส้นทางเก่าออกก็ต่อเมื่อผู้ตอบสนองยืนยันแล้วว่าตัวแทนใช้งานได้จริง

คำถามที่พบบ่อย

Opsgenie กำลังจะเลิกให้บริการจริงไหม

จริง การขายใหม่ยุติไปเมื่อ 4 มิถุนายน 2025 และ Opsgenie จะสิ้นสุดการสนับสนุนในวันที่ 5 เมษายน 2027 Atlassian ระบุว่าผลิตภัณฑ์จะถูกปิดและเข้าใช้ไม่ได้อีกหลังจากนั้น

อะไรจะมาแทน Opsgenie

เส้นทางทดแทนอย่างเป็นทางการของ Atlassian คือ Jira Service Management ซึ่งเป็นที่รวมความสามารถด้านการแจ้งเตือนและงาน on-call ของ Opsgenie เข้าไว้ด้วยกัน ทางเลือกที่เหมาะสมขึ้นอยู่กับว่าทีมของคุณต้องการการจัดการเหตุการณ์แบบเต็มรูปแบบ หรือแค่การนำส่งการแจ้งเตือนที่เชื่อถือได้

Echobell แทนที่ Opsgenie ได้ทั้งหมดไหม

ไม่ได้ Echobell แทนที่เฉพาะชั้นการแจ้งเตือนเร่งด่วนบนมือถือสำหรับเวิร์กโฟลว์ที่เหมาะสมเท่านั้น มันไม่ได้ทำซ้ำตารางเวร ผังการยกระดับ กระบวนการจัดการเหตุการณ์ หรือการรายงานของ Opsgenie

เราใช้ Echobell ระหว่างย้ายออกจาก Opsgenie ได้ไหม

ได้ ให้ชี้แหล่งแจ้งเตือนหนึ่งแหล่งไปยังทั้งสองปลายทาง ตรวจสอบการนำส่งระหว่างรอบเวร on-call จริง แล้วคง Opsgenie ไว้จนกว่าเส้นทางใหม่จะพิสูจน์ตัวเองได้

ควรเริ่มย้ายเมื่อไร

เริ่มทำบัญชีรายการและทดลองใช้ตั้งแต่ตอนนี้ ส่วนวันย้ายจริงขึ้นอยู่กับจำนวนการเชื่อมต่อ ข้อกำหนดด้านการปฏิบัติตามกฎเกณฑ์ และว่าคุณจะย้ายไป Jira Service Management หรือออกแบบระบบแจ้งเตือนใหม่

เลือกตัวแทนที่เล็กที่สุดที่ครอบคลุมงานจริง

การปิดตัวของ Opsgenie สร้างเส้นตายที่ชัดเจน แต่ไม่ได้แปลว่าทุกทีมต้องใช้ตัวแทนแบบเดียวกัน

เลือก Jira Service Management เมื่อคุณพึ่ง Opsgenie เป็นระบบ on-call และจัดการเหตุการณ์แบบครบวงจร แต่ควรพิจารณาชั้นนำส่งเฉพาะทาง เมื่อตัวมอนิเตอร์ของคุณมีตรรกะการส่งต่ออยู่แล้ว และความต้องการหลักของคุณคือการนำเหตุการณ์วิกฤตไปถึงมือถือที่ถูกคนอย่างรวดเร็ว

ดาวน์โหลด Echobell สำหรับ iPhone หรือรับได้จาก Google Play แล้วทดลองกับการแจ้งเตือนในระบบโปรดักชันหนึ่งรายการขณะที่เส้นทาง Opsgenie ปัจจุบันของคุณยังทำงานอยู่