How We Built an Automated DBA Platform: Architecture, Design, and Lessons

DBA Daily Work

DBA responsibilities are divided into three major workstreams:

Business integration : schema design, SQL tuning, data correction, and version‑release coordination with development teams.

Database management : ensuring stability, performance, regular backup, and migration of databases.

Technical architecture : keeping the underlying infrastructure and core technologies up‑to‑date.

The goal of automation is to platform‑ify these repetitive tasks so that DBAs can focus on higher‑value work.

Evolution of Database Operations

Stage 1 – Manual operations : each DBA managed a few databases manually, with no monitoring tools; incidents were discovered only through application feedback.

Stage 2 – Tool‑based operations : introduction of Zabbix for monitoring, JIRA for issue tracking, batch deployment scripts, and custom automation scripts. Tools solved many problems but created silos and did not fully automate detection or resolution.

Stage 3 – Platform operations : development of a unified automation platform that integrates the previously isolated tools into end‑to‑end workflows.

MOZIS Platform Architecture

The backend is built with Python 3.6 , Django , and a Vue front‑end, communicating via RESTful APIs . Supporting components include:

Redis – caching of metadata and dashboard data.

ANTLR – precise SQL syntax parsing.

Celery – asynchronous execution of long‑running tasks (e.g., large batch SQL, tablespace expansion).

SSH – remote command execution on database hosts (e.g., Oracle expdp/impdp).

Ansible – batch deployment and configuration of database instances.

MySQL – storage of platform metadata (CMDB, version history, etc.).

Nginx – web server exposing the REST API and static assets.

The functional modules cover metadata management, data‑correction workflow, version‑release process, service deployment, data migration, and batch task execution – the core of daily DBA automation.

Automation Design Principles

Metadata management is the foundation. The design follows three principles:

Adaptability : abstract the operational model to allow special‑case extensions without breaking the core.

Hierarchy : reflect the layered nature from hardware → OS → network → database.

Completeness : capture all required attributes so that automated actions are reliable.

These principles lead to a service‑oriented abstraction with the following layers:

Storage service – provides raw storage resources.

Host service – supplies CPU, memory, and local paths.

Data service – basic data‑management and query capabilities.

Cluster service – high‑availability orchestration.

Connection service – data transmission and listener handling.

Network service – networking topology and host location.

DNS service – mapping between domain names and IP addresses.

SQL Audit Workflow Evolution

Audit 1.0 – SQL statements are downloaded from JIRA, uploaded to a review tool, and executed manually. This reduces review time from hours to minutes but provides no direct database connection or risk assessment.

Audit 2.0 – The platform connects to the target database, runs EXPLAIN on DML statements, and presents execution‑plan metrics (estimated rows, cost) to the reviewer. This adds risk quantification and ensures the statement is executable.

Audit 2.1 – Audit permissions are shifted to developers. After a successful review, the result is automatically added as a comment to the originating JIRA ticket, and a one‑click “Execute” button triggers the SQL on the target host.

Customizable SQL Audit Rules

The audit engine supports a configurable rule set. Each rule consists of:

Value – the rule expression or threshold.

Description – human‑readable explanation.

Severity level – e.g., INFO, WARN, ERROR.

Enabled flag – toggle to activate or deactivate the rule.

This design makes the audit process transparent, flexible, and visual, allowing rapid adaptation to evolving business policies.

Conclusion and Outlook

Automation reduces DBA workload, minimizes human error, and codifies operational knowledge. Future directions aim at intelligent automation: leveraging the collected execution‑plan data and fault‑diagnosis pipelines as entry points for AI‑driven SQL optimization and automated incident resolution.