AKStream.Next · 文档中心

Production Deployment Acceptance

Production Deployment Acceptance

Deployment acceptance is executed following the end-user path, and verifiable evidence must be saved for every step. Monitoring service processes, health interfaces, or single APIs alone is insufficient to prove system availability.

flowchart LR
    A[Version and services] --> B[Login and permission]
    B --> C[Device onboarding and live view]
    C --> D[Recording and playback]
    D --> E[RTC / external integration]
    E --> F[Security, monitoring, backup, rollback]

1. Version and Source

  • The installation package version is consistent with the plan, and archive checksums have been verified.
  • Versions of the program, WebUI, NodeAgent, and MediaServer have been recorded.
  • Current node IDs, deployment roles, and the list of database and media nodes have been archived.
  • No mixing of old configuration directories or uncleared test databases.

2. Host and Process Recovery

  • systemd, Windows SCM, launchd, or Docker report that services are normal.
  • NodeAgent is online, and the Provider is consistent with the target platform.
  • After recovery verification in a maintenance window, the main process is restarted by the single recovery owner declared for the platform; Linux must prove NodeAgent recovery after the control connection is lost.
  • Database, MediaServer, background tasks, and WebHooks recover after the main process restarts.

3. Health and Configuration

  • Both liveness and readiness checks pass; Warnings have clear acceptance justifications, and blocking items have been cleared.
  • The effective configuration version, disk configuration, and page display are consistent.
  • Changes requiring a restart have been processed, and there are no long-pending restart items.
  • Sensitive fields do not appear in logs, screenshots, or configuration diffs.

4. First Device and Media

Select one real target model device:

  1. Complete registration or discovery, authentication, and channel synchronization.
  2. Start live preview and record the device, channel, media node, and stream identifiers.
  3. Verify HLS, FLV, RTSP, or WebRTC as required by the project.
  4. Verify stop and resource release.
  5. If required by the project, further verify PTZ, presets, image parameters, intercom, events, or GPS.

5. Recording Closed-Loop

  • Manual recording can start, stop, and produce files.
  • Recording schedules trigger in the scheduled windows, and midnight-crossing rules execute as expected.
  • Recording index can be queried; Range playback, download, and permissions are correct.
  • Soft delete, recovery, and physical delete are verified only on test data.
  • When clipping and merging are enabled, the output is playable, and temporary files can be cleaned.
  • Alerts for disk capacity, inodes, and write permissions are configured.

6. Network and Security

  • Verify separately from the real management network, device network, and end-user network.
  • HTTPS certificate chains, domains, renewals, and WebSockets are normal.
  • Public network RTC completes TURN or restricted network verification.
  • Database ports such as 3306 are not open to unnecessary networks.
  • Default passwords have been replaced; permissions are verified for administrator, operator, and read-only roles respectively.
  • API Tokens use minimum privileges and can be revoked.

7. Backup and Recoverability

  • Configurations, Data/Security, databases, recording indexes, and authorization materials are included in the backup.
  • A recovery has been performed once in an isolated environment, recording the recovery time and gaps.
  • Backup points before upgrades, old packages, and rollback commands are clearly defined.
  • Monitoring can detect failures of the main service, Agent, MediaServer, database, and disk.

8. Evidence Archiving

Record at least the following for each item:

  • Test name, time, operator, and environment;
  • Stable ID of the input object;
  • Expected and actual results;
  • Key screenshots;
  • Command/Task ID, TraceId, and stream identifiers;
  • Relevant log time windows;
  • Whether it passed and any known limitations.

Sensitive passwords, Tokens, MediaServer secrets, authorization private keys, and full Cookies must not enter the evidence package.

Release Criteria

All mandatory project paths must pass; items that did not pass must have a clear risk owner, impact scope, and resolution deadline; backup recovery and rollback must not be mere paper plans. After release, transition to Daily Inspection.