ກວດສະຖານະ ແລະກູ້ຄືນລະບົບ.
ໃຊ້ CLI ທີ່ແຍກຈາກເວັບສາທາລະນະ ເພື່ອກວດ readiness, ວຽກຄ້າງ ແລະ migration ກ່ອນເກີດບັນຫາກັບຜູ້ໃຊ້.
1. ກວດສະຖານະຈາກ terminal
ຮັນຈາກ project root ດ້ວຍບັນຊີດູແລ application. ops:check ອ່ານທຸກ queue ເມື່ອບໍ່ລະບຸຊື່; ສາມາດລະບຸ queue ທີ່ຈະຕິດຕາມໄດ້. JSON ມີ status, readiness, queue, outbox, schedules ແລະ alerts. status ເປັນ ok ຫຼື degraded; exit code 0 ໝາຍເຖິງຜ່ານ ແລະ 1 ໝາຍເຖິງຕ້ອງກວດຕໍ່. ຜົນບໍ່ສົ່ງ job payload, ລະຫັດລັບ ຫຼືລາຍລະອຽດ exception ອອກມາ.
php bin/icom ops:check
php bin/icom ops:check default
# Healthy: status = "ok", alerts = [], exit 0
# Degraded: status = "degraded", inspect alerts, exit 12. ແຍກ health ອອກຈາກ readiness
/health ຍັງເປັນການກວດວ່າ application ຕອບໄດ້ ໂດຍບໍ່ probe DB/cache. /ready ກວດ DB connection, migration status ດ້ວຍການອ່ານ, cache ແລະສິດຂຽນໃນ storage ແລະ storage/logs. ເມື່ອ CACHE_DRIVER=file ຈຶ່ງກວດ storage/cache ແລະ storage/rates ເພີ່ມ; Redis ບໍ່ຕ້ອງມີສອງ directory ນັ້ນໃນເຄື່ອງ. Public response ຂອງ /ready ມີພຽງ status ready ຫຼື unavailable; ຖ້າບໍ່ພ້ອມຈະຕອບ HTTP 503. ອ່ານລາຍລະອຽດຜ່ານ ops:check ໃນ terminal. Readiness ບໍ່ໄດ້ຢືນຢັນວ່າ worker ກຳລັງແລ່ນ ຫຼືວຽກທຸລະກິດຈະສຳເລັດ.
curl --fail --silent --show-error https://your-app.example/health
curl --fail --silent --show-error https://your-app.example/ready
# /ready: HTTP 200 {"status":"ready"}
# /ready: HTTP 503 {"status":"unavailable"}Probe ເຮັດຫຍັງກັບຂໍ້ມູນ?
ການກວດ queue, outbox, schedules ແລະ migration status ໃຊ້ SQL ອ່ານຢ່າງດຽວ; ບໍ່ reserve job, ບໍ່ relay outbox ແລະບໍ່ tick schedule. Readiness ຂອງ /ready ແລະ ops ໃຊ້ cache roundtrip ຈິງ: ສ້າງ key ສຸ່ມ, set ດ້ວຍ TTL 60 ວິນາທີ, get ແລະ delete. ຈຶ່ງມີການຂຽນ cache ຊົ່ວຄາວ. ການກວດສິດຂຽນ directory ບໍ່ແມ່ນການຮັບປະກັນວ່າ disk ຈະບໍ່ເຕັມຫຼື I/O ຈະສຳເລັດຄັ້ງຕໍ່ໄປ.
3. ອ່ານ queue ໃຫ້ຖືກ
ready, delayed, leased, exhausted ແລະ failed ແມ່ນກຸ່ມທີ່ບໍ່ນັບຊ້ຳກັນ. ready ແມ່ນວຽກທີ່ພ້ອມໃຫ້ worker ຮັບ; delayed ແມ່ນວຽກທີ່ຍັງບໍ່ຮອດເວລາ; leased ແມ່ນວຽກທີ່ຍັງມີ lease ທີ່ໃຊ້ໄດ້. exhausted ແມ່ນວຽກທີ່ໃຊ້ຈຳນວນຄັ້ງລອງໝົດແລ້ວ ແລະບໍ່ມີ lease ທີ່ໃຊ້ໄດ້; failed ແມ່ນວຽກທີ່ຖືກບັນທຶກວ່າລົ້ມເຫຼວ. expired_leases ເປັນຄ່າວິນິດໄສທີ່ອາດຊ້ຳກັບກຸ່ມອື່ນ ຈຶ່ງບໍ່ຄວນບວກເຂົ້າໃນຍອດລວມ.
ready + delayed + leased + exhausted + failed = classified queue jobs
expired_leases = additional diagnostic; do not add it again
ready_since = max(available_at, expired lease end)
oldest ready age = now - earliest ready_sinceຄວາມໝາຍຂອງອາຍຸວຽກ
Queue ນັບອາຍຸວຽກ ready ຈາກເວລາທີ່ມັນຮັບໄດ້ຈິງ: ຄ່າທີ່ຊ້າກວ່າລະຫວ່າງ available_at ແລະ lease ທີ່ໝົດອາຍຸ. ວຽກທີ່ກຳນົດໃຫ້ເຮັດມື້ອື່ນຈຶ່ງບໍ່ເປັນວຽກຄ້າງ ready ໃນມື້ນີ້. Outbox pending ນັບອາຍຸຈາກ created_at ເພາະ relay ສາມາດສົ່ງວຽກທີ່ກຳນົດເວລາໃນອະນາຄົດເຂົ້າ queue ໄດ້ແລ້ວ. Outbox published ໝາຍເຖິງສົ່ງຕໍ່ເຂົ້າ queue ແລ້ວ; ຕ້ອງກວດຜົນຂອງ handler ແຍກຕ່າງຫາກ.
4. ກວດ schedule ແລະເກນແຈ້ງເຕືອນ
ສຳລັບ schedule ທີ່ເຄີຍບັນທຶກ slot, lag ນັບຈາກ slot ທຳອິດທີ່ພາດ: last_slot + interval_seconds. ຄ່າຈຶ່ງເພີ່ມຕາມຊ່ວງ outage ແລະບໍ່ກັບເປັນ 0 ພຽງເພາະຮອດ interval ຖັດໄປ. ຖ້າ schedule ໃໝ່ຮອດເວລາແລ້ວແຕ່ຍັງບໍ່ມີ last_slot, ຈະນັບ never_run ແລະແຈ້ງ schedule_never_run; ອາຍຸປະຫວັດຍັງບໍ່ຮູ້ ຈຶ່ງໃຊ້ພຽງຄວາມຊ້າຈາກ due slot ລ່າສຸດສຳລັບ lag ຂອງ schedule ນັ້ນ. ບັນທຶກ slot ໝາຍເຖິງສ້າງວຽກແລ້ວ; ບໍ່ແມ່ນ worker heartbeat ຫຼືຜົນວຽກສຳເລັດ. ຕັ້ງເກນອາຍຸໃນ config/operations.php ຕາມ workload. ຄ່າ failed jobs, failed outbox ຫຼື exhausted leases ຈະແຈ້ງເຕືອນສະເໝີ; ການເພີ່ມເກນເວລາບໍ່ປິດການແຈ້ງເຕືອນເຫຼົ່ານີ້.
<?php
// config/operations.php — seconds, no credentials
return [
'queue_wait_seconds' => 300,
'outbox_wait_seconds' => 120,
'schedule_lag_seconds' => 120,
];5. ອ່ານ metrics ຜ່ານ CLI
ops:metrics ສົ່ງ Prometheus text ໄປ stdout ຂອງ private CLI. ບໍ່ມີ public /metrics endpoint ໃໝ່. Exit code 0 ໝາຍເຖິງຜະລິດ metrics ໄດ້ ແມ່ນແຕ່ຕອນລະບົບ degraded; ໃຊ້ ops:check ຫຼືອ່ານຄ່າ metrics ເພື່ອຕັດສິນສຸຂະພາບ. ຜູ້ດູແລຕ້ອງຕິດຕັ້ງ collector ທີ່ປ້ອງກັນການເຂົ້າເຖິງ ແລະວາງໄຟລ໌ອອກນອກ document root. ຄຳສັ່ງນີ້ບໍ່ສົ່ງຂໍ້ມູນໄປຫາບໍລິການພາຍນອກເອງ.
php bin/icom ops:metrics
php bin/icom ops:metrics default
# Prometheus text: HELP / TYPE comments followed by numeric samples.
# A successful export can still report an unhealthy application.
# Selected metric names (examples, not shell commands):
# icom_operations_ok
# icom_ready
# icom_component_up{component="queue"}
# icom_queue_jobs{state="ready"}
# icom_queue_expired_leases
# icom_queue_oldest_ready_age_seconds
# icom_outbox_oldest_pending_age_seconds
# icom_schedule_never_run
# icom_schedule_max_lag_secondsຄວາມຖີ່ ແລະ deadline ຂອງການກວດ
ເລີ່ມກວດທຸກ 30–60 ວິນາທີ ແລ້ວປັບຕາມຂະໜາດຂໍ້ມູນ ແລະເວລາຕອບຈິງ. SQL aggregates ມີຕົ້ນທຶນການອ່ານ; ກວດ query plan, index, retention ແລະ DB load ກ່ອນເພີ່ມຄວາມຖີ່. ຕັ້ງ I/O deadlines ໃນ DB/cache driver, runtime ແລະ probe platform. ການກວດຂອງ framework ບໍ່ສາມາດບັງຄັບຍົກເລີກ blocking I/O ທຸກຊະນິດພາຍໃນເວລາຕາຍຕົວ. ຢ່າຕັ້ງ readiness failure ຄັ້ງດຽວໃຫ້ restart ທຸກ instance ພ້ອມກັນ.
6. ກຳນົດຂອບເຂດ worker
ຕົວຢ່າງນີ້ຮັນ queue default ສູງສຸດ 100 jobs ຫຼື 300 ວິນາທີ, ໃຊ້ lease 120 ວິນາທີ ແລະເກນ memory 128 MiB. --stop-when-empty ໃຫ້ອອກເມື່ອບໍ່ພົບວຽກທີ່ຮັບໄດ້. --memory=0 ປິດເກນ memory ຂອງ worker. ເກນຈຳນວນ jobs, ເວລາ ແລະ memory ກວດລະຫວ່າງ jobs; ມັນບໍ່ຕັດ handler ທີ່ກຳລັງບລັອກ. ເມື່ອມີ PCNTL signal support, SIGTERM ໃຫ້ handler ທີ່ກຳລັງເຮັດວຽກຈົບກ່ອນຢຸດຮັບວຽກໃໝ່. ຕັ້ງ supervisor grace period ໃຫ້ພໍກັບ handler ແລະຕັ້ງ network/DB timeout ພາຍໃນວຽກ.
php bin/icom queue:work default 100 300 --stop-when-empty --lease=120 --memory=128Lease ແລະວຽກທີ່ໃຊ້ເວລາດົນ
Graceful shutdown ບໍ່ໄດ້ຕໍ່ອາຍຸ lease ໃຫ້ວຽກເອງ. Handler ທີ່ອາດໃຊ້ເວລາເກີນ lease ຕ້ອງມີ heartbeat ຕາມ queue API ແລະຢຸດຂຽນເມື່ອເສຍ ownership. ຖ້າ process ຢຸດ ຫຼື lease ໝົດ, ວຽກອາດຖືກເຮັດຊ້ຳ. ອອກແບບຕາມ at-least-once delivery: ໃຊ້ idempotency key ຂອງທຸລະກິດ, unique constraint ແລະກວດຜົນພາຍນອກກ່ອນ retry. ການສົ່ງ email ຫຼື payment ຕ້ອງມີການປ້ອງກັນການເຮັດຊ້ຳຂອງບໍລິການນັ້ນນຳ.
7. ກວດ migration ກ່ອນ deploy
migrate:status ໃຊ້ SELECT ເພື່ອອ່ານ migration history; ບໍ່ສ້າງ history table ແລະບໍ່ execute migration. ຜົນມີ initialized, applied, pending, missing ແລະ ok. pending ແມ່ນ migration ໃນ release ທີ່ຍັງບໍ່ໄດ້ໃຊ້; missing ແມ່ນ migration ທີ່ DB ບັນທຶກວ່າໃຊ້ແລ້ວ ແຕ່ບໍ່ມີໃນ source ປັດຈຸບັນ. ຖ້າມີ pending/missing ຈະອອກດ້ວຍ nonzero exit code. ກວດ release, ບັນຊີ DB ແລະ backup ກ່ອນໃຊ້ migrate; ຢ່າແກ້ migration history ດ້ວຍມືເພື່ອໃຫ້ status ຜ່ານ.
php bin/icom migrate:status
# Healthy existing installation:
# initialized = true, pending = [], missing = [], ok = true
# Run only as the chosen deployment coordinator after reviewing changes:
php bin/icom migrate
php bin/icom migrate:statusMigration lock ແລະ rollback
MySQL ໃຊ້ GET_LOCK ທີ່ຜູກກັບ database ເພື່ອປະສານການຮັນ migrate; SQLite ໃຊ້ local flock. ໃນ cluster ຍັງຕ້ອງກຳນົດ deployment coordinator ດຽວ ແລະບໍ່ໃຫ້ທຸກ replica ຮັນ migration ຕອນ startup. DDL ບາງຊະນິດໃນ MySQL ບໍ່ສາມາດ rollback ດ້ວຍ transaction ໄດ້. ອອກແບບ schema ແບບເພີ່ມກ່ອນແລ້ວຄ່ອຍຖອນ ໃຫ້ release ເກົ່າແລະໃໝ່ໃຊ້ຮ່ວມກັນໄດ້ໃນຊ່ວງ deploy. ການປ່ຽນ symlink ກັບ release ເກົ່າບໍ່ໄດ້ກູ້ຄືນ schema ຫຼື side effects ຈາກ jobs.
8. ວິທີກວດເມື່ອເກີດບັນຫາ
ເລີ່ມຈາກ ops:check ແລະປຽບທຽບກັບຄັ້ງກ່ອນ. ຖ້າ readiness ບໍ່ຜ່ານ ໃຫ້ກວດ connection, migration, cache ແລະສິດ directory ດ້ວຍບັນຊີທີ່ຮັນ application; ຢ່າແກ້ດ້ວຍ chmod 777. ຖ້າ ready age ເພີ່ມ ໃຫ້ກວດ worker process, queue name, handler ແລະ DB latency. ຖ້າ outbox pending age ເພີ່ມ ໃຫ້ກວດ maintenance/relay. ຖ້າ schedule lag ສູງ ໃຫ້ກວດ cron ແລະເວລາ UTC ຂອງ host. failed/exhausted ຕ້ອງກວດຜົນທຸລະກິດ ແລະແກ້ສາເຫດກ່ອນ retry.
php bin/icom ops:check
php bin/icom migrate:status
php bin/icom queue:failed
php bin/icom outbox:failed 50
php bin/icom schedule:list
# After repairing the cause and checking whether the effect already occurred:
php bin/icom queue:retry FAILED_JOB_ID
php bin/icom outbox:retry MESSAGE_ID
php bin/icom ops:check9. ຂັ້ນຕອນ deploy ທີ່ກວດຍ້ອນຫຼັງໄດ້
ສຳຮອງ DB ແບບ consistent, .env ແລະ deployment configuration ໄວ້ໃນທີ່ private; ທົດສອບ restore ໃນ staging. ຕິດຕັ້ງ release ໃໝ່ແຍກ directory, ກວດ PHP/extensions, dependencies ແລະ tests, ເຊື່ອມ shared .env/storage ແລະຮັກສາ APP_KEY ເດີມ. ກວດ migration plan ກ່ອນປ່ຽນ release. ຫຼັງປ່ຽນຕ້ອງກວດ /ready, ops:check ແລະ business smoke test; ໃຫ້ supervisor restart workers ຢ່າງ graceful ເພື່ອໂຫຼດ code ໃໝ່. ຖ້າ rollback ຕ້ອງກວດວ່າ code ເກົ່າໃຊ້ schema/job payload ປັດຈຸບັນໄດ້. ລຸ້ນ 0.8 ບໍ່ເພີ່ມ schema migration ແລະບໍ່ຕ້ອງປ່ຽນ APP_KEY, cron ຫຼື PHP handler.
ຂອບເຂດທີ່ຕ້ອງປະກອບເພີ່ມ
ຊຸດກວດນີ້ຊ່ວຍໃຫ້ອ່ານສະຖານະແລະຕັດສິນໃຈກູ້ຄືນໄດ້ຊັດເຈນຂຶ້ນ. ຍັງຕ້ອງມີ supervisor, protected metrics collector, ການແຈ້ງເຕືອນໄປຫາທີມ, log rotation, backup/restore, tracing ແລະ failover ຕາມ infrastructure ຈິງ. ບໍ່ມີ dashboard ຫຼື automatic remediation ທີ່ retry/delete ຂໍ້ມູນເອງ. ທົດສອບ outage, lease expiry, worker termination ແລະ restore ໃນ staging ກ່ອນພຶ່ງພາໃນລະບົບສຳຄັນ.