Administrator Guide: [Product name] [version]

Complete guide for the people who run, secure and maintain a software product after installation. The structure follows the information for administrators and operators described in ISO/IEC/IEEE 26514:2022. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Roles and permissions
3. Architecture overview
4. User and access management
5. Configuration management
6. Backup and restore
7. Monitoring and alerting
8. Logs
9. Maintenance schedule
10. Scaling
11. Security operations
12. Upgrades and patching
13. Disaster recovery
14. Audit and compliance
15. Reference

1. Introduction

1.1 Purpose and scope

This guide describes how to administer [Product name] [3.2] in the [production / staging] environment: managing users and access, changing configuration, protecting data, monitoring health, maintaining and scaling the service, and responding to security events. Installation is covered in the [Installation Guide].

1.2 Audience and assumptions

This guide is for system administrators, site reliability engineers and security operators. It assumes familiarity with Linux administration, PostgreSQL, TLS certificates and the organisation's change management process.

1.3 First week checklist for a new administrator

1.4 Conventions

Commands prefixed with # require root or sudo. Caution marks steps that can cause downtime or data loss. Times are in UTC.

2. Roles and permissions

Changes to role assignments require a ticket approved by [@service-owner] and are reviewed quarterly (see 14.2).

3. Architecture overview

The service consists of stateless application nodes behind a load balancer, a primary database with one replica, an object store for files and a background worker pool.

4. User and access management

4.1 Identity source

Users authenticate through [SSO with SAML 2.0 / OpenID Connect against the corporate identity provider]. Local accounts are allowed only for the two break-glass super administrators.

4.2 Add a user

1. In the admin console, go to Users > Add user.
2. Enter the email address and select a role.
3. Select Send invitation. Result: The user appears with status Invited; it changes to Active after the first sign-in.

With SSO provisioning (SCIM) enabled, users are created automatically when they are added to the group [app-users] in the identity provider.

4.3 Disable a leaver

1. Go to Users, search for the person and select Disable.
2. Choose a new owner for their documents and select Transfer. Result: Active sessions end within one minute; content is kept.

4.4 Access policy

5. Configuration management

All configuration is stored in the repository [infra/productname-config] and applied by [the deployment pipeline]. Manual edits on servers are overwritten on the next deploy.

Validate before applying: productname config validate --file config.yaml.

6. Backup and restore

6.1 Backup policy

6.2 Restore the database to a point in time

Caution: Restoring replaces current data. Confirm the target time with the service owner and announce downtime first.

1. Put the service in maintenance mode: productname maintenance on.
2. Restore: productname db restore --target-time "YYYY-MM-DD HH:MM:SS UTC".
3. Run integrity checks: productname db check; expect 0 errors.
4. Turn maintenance mode off and run the checks in 7.3.

6.3 Restore testing

A full restore to an isolated environment is performed [monthly] and recorded in the table below.

7. Monitoring and alerting

7.1 Service level objectives

Availability is measured as the share of successful requests:

which allows about 43 minutes of full outage per 30 days.

7.2 Alerts

7.3 Health checks

• GET /healthz returns 200 when the node can serve traffic.
• GET /readyz returns 200 when database and object store are reachable.
• Admin console System > Status shows queue depth and worker count.

8. Logs

Example search for failed sign-ins in the last hour: service:productname event:auth.failed | stats count by user_id.

9. Maintenance schedule

10. Scaling

Connections needed: $\text{nodes} \times \text{pool\_size} \leq \text{max\_connections} - \text{reserve}$.

11. Security operations

• Vulnerabilities: Critical findings are patched within [7] days, high within [30].
• Secrets: Stored in [secret manager]; never in configuration files or tickets.
• Certificates: Issued by [internal CA / ACME]; inventory in 15.3.
• Suspected compromise: Follow the [Incident Response Plan]. First steps:
  1. Preserve logs: export the audit log for the affected period.
  2. Revoke affected sessions: Users > [user] > End all sessions.
  3. Rotate exposed credentials and notify [@security-officer].

12. Upgrades and patching

1. Read the release notes and check for breaking changes.
2. Upgrade staging and run the smoke tests for one business day.
3. Raise a change ticket with the rollback plan.
4. Upgrade production with a rolling restart (nodes one at a time).
5. Monitor error rate for 60 minutes. Roll back if 5xx exceeds 2%.

13. Disaster recovery

Recovery order: database, object store, app nodes, workers, DNS switch. Full procedure: [Disaster Recovery Plan, section n]. Last DR test: YYYY-MM-DD, result [Pass / Partial].

14. Audit and compliance

14.1 Control evidence

14.2 Access review

Each quarter, export Users > Export, ask each team lead to confirm their users and roles, disable unconfirmed accounts and file the signed export.

15. Reference

15.1 Admin commands

15.2 Important paths

15.3 Contacts and escalation

15.4 Glossary

Standard and licence note

Structure aligned with ISO/IEC/IEEE 26514:2022, Systems and software engineering: Design and development of information for users, for information given to administrators and operators (roles, tasks, reference and troubleshooting information). This template is original text written for this collection and reproduces no text from the standard; obtain the standard from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.