ข้ามไปที่เนื้อหา

การดูแลระบบ

ส่วนนี้สำหรับผู้ที่ ดูแลการทำงานของ HEMMS มากกว่าผู้ที่ใช้งานในแต่ละวัน: ฝ่าย IT operations ของโรงพยาบาล ผู้ดูแลระบบของแผนก BME และทีมส่งมอบงานของ Trinity Roots ครอบคลุมวงจรชีวิตทั้งหมดของการติดตั้ง HEMMS ตั้งแต่การติดตั้งครั้งแรก ไปจนถึงการอัปเกรด Odoo รุ่นใหญ่ครั้งถัดไป

หากคุณกำลังมองหาคู่มือเริ่มต้นใช้งานแบบเบาที่ทำตามได้ทันทีซึ่งมุ่งเป้าไปที่ผู้ประเมินระบบ ดูที่ เริ่มต้นใช้งาน → การติดตั้ง หน้าต่าง ๆ ใน ส่วนนี้สันนิษฐานว่าคุณเป็นผู้รับผิดชอบในการดูแลให้ระบบมีสุขภาพดีในสภาพแวดล้อม production

ส่วนนี้เหมาะกับใคร

บทบาท สิ่งที่เขาต้องการจากส่วนนี้
ฝ่าย IT operations ของโรงพยาบาล วิธีติดตั้ง ตรวจสอบ สำรองข้อมูล และกู้คืน Docker stack
ผู้ดูแลระบบของแผนก BME วิธีนำผู้ใช้เข้าระบบ กำหนดสิทธิ์ตามบทบาท จัดการโรงพยาบาลที่มีหลายสาขา
วิศวกรส่งมอบงานของ Trinity Roots ขั้นตอนการอัปเกรด รูปแบบการย้ายข้อมูล การควบคุมด้วย CI เพื่อการปล่อยใช้งานอย่างปลอดภัย
ผู้ตรวจสอบการปฏิบัติตามข้อกำหนด HA / DPO ร่องรอยการตรวจสอบอยู่ที่ไหน อะไรถูกสำรองข้อมูลไว้ อะไรกู้คืนได้

ส่วนนี้มีอะไรบ้าง

  • การติดตั้ง

    การติดตั้งแบบ Docker เต็มรูปแบบ: ความต้องการของระบบ การโคลน repo การ เริ่มต้น sandbox การติดตั้งโมดูล และการตรวจสอบ

  • หลายบริษัท / หลายโรงพยาบาล

    สองรูปแบบสำหรับเครือข่ายและกลุ่มโรงพยาบาล — หนึ่งบริษัทต่อสาขาในหนึ่ง ฐานข้อมูล หรือหนึ่งฐานข้อมูลต่อโรงพยาบาล จะเลือกแบบไหนและเพราะอะไร

  • ผู้ใช้และสิทธิ์การเข้าถึง

    กลุ่มความปลอดภัย record rule ACL และการแมปบทบาทที่แนะนำสำหรับ โครงสร้างโรงพยาบาลทั่วไป (Ward Nurse → BME Tech → BME Manager → Admin / DPO)

  • การสำรองข้อมูลและการกู้คืน

    make backup-private ทำอะไรจริง ๆ วิธีกู้คืนทั้งฐานข้อมูล และ filestore และควรซ้อมกู้คืนบ่อยแค่ไหน

  • คู่มือการอัปเกรด

    การอัปเกรดโมดูล ฟิลด์ version ใน __manifest__.py ไฟล์ migration และวิธีที่ CI ตรวจจับการถดถอยในทุก PR

บริบทเชิงสถาปัตยกรรม

HEMMS เป็นสแต็กสามชั้น — Odoo Base, OCA building blocks และเลนส์มุมมอง โรงพยาบาล roots_hemms_* หากคุณยังไม่ได้อ่านหน้า สถาปัตยกรรม ให้อ่านก่อน เพราะแทบ ทุกการตัดสินใจในส่วนนี้ (จะติดตั้งโมดูลใด กลุ่มความปลอดภัยมีอะไรบ้าง อะไรถูกสำรองข้อมูล) ล้วนสืบเนื่องมาจากการแบ่งชั้นนั้น

พื้นที่ของการติดตั้งถูกออกแบบให้แคบโดยตั้งใจ: Docker Compose สองสแต็ก (private และ gov) ห่อหุ้มคอนเทนเนอร์ Odoo 18 และคอนเทนเนอร์ Postgres 15 โดยการปรับแต่งทั้งหมดอยู่ในไดเรกทอรี addons/ และทุก sandbox ใช้อิมเมจ hemms-odoo:18.0 เดียวกัน ไม่มีสิ่งอื่นที่ต้องติดตั้งบน host นอกจาก Docker

หลักการดำเนินงาน

ขั้นตอนการดูแลระบบยึดตามกฎสามข้อที่ส่วนที่เหลือของบทนี้ ขยายความ:

  1. สำรองข้อมูลก่อนทุกการเปลี่ยนแปลง การติดตั้งโมดูล การอัปเกรด การกู้คืน แม้กระทั่ง การ merge PR ขนาดใหญ่ — เริ่มต้นด้วย make backup-private การสำรองข้อมูลมีต้นทุนต่ำ ส่วนการกู้คืนจากการสำรองข้อมูลรายคืนของเมื่อวานเพราะคุณข้ามการสำรองข้อมูลก่อนอัปเกรด ไม่ต่ำเลย
  2. ใช้ Makefile ทุกการดำเนินงานที่มีการบันทึกไว้มี make target หาก คุณพบว่าตัวเองกำลังจะใช้คำสั่ง docker compose หรือ odoo ดิบ ๆ ให้ตรวจดู Makefile ก่อน — น่าจะมี target สำหรับมันอยู่แล้ว
  3. เชื่อมั่นใน CI gate เวิร์กโฟลว์ tests.yml รันทดสอบ HEMMS 177 รายการในทุก PR หาก main เป็นสีเขียว addons จะติดตั้งได้อย่างเรียบร้อยบนฐานข้อมูลใหม่ ดูที่ นักพัฒนา → CI/CD