DevOps, automation and observability

Every change versioned, every component watched.

What it is

DevOps practice is usually applied to application code and stops at the database. Databases are stateful: a schema change cannot be redeployed like a container, and a configuration drifts quietly unless something compares it with what was intended. Cloudtech’s DevOps practice began at that boundary. It brings databases, operating systems, clusters and data pipelines into the same versioned, automated and observed delivery as the software that uses them.

There are three kinds of changes from a stateful service’s perspective:

Development changes: DDL, stored procedures, jobs and database links.
Database configuration changes: database configuration DML, inside the database and at the operating-system level.
Platform management changes: operating system management, networks and security.

All three are versioned, reviewed and applied through one pipeline. At the end there are almost no direct manual changes to databases, operating systems, virtualisation or storage, every component carries a known configuration at every moment, and the record of a change is the change itself.

Automation and observability are one service line for a reason. DORA’s 2024 research found that teams using an internal developer platform were more productive and delivered more, and that the stability of their changes fell by 14 per cent; its advice is to keep that instability in view with service level objectives and error budgets rather than to assume it away.¹ Cloudtech builds the pipeline and the monitoring together, so a faster change path comes with the means to see what it does.

The other service lines run through this one. Managed platform and database services operates what the pipeline delivers, 24/7, and the connectors and jobs of Data platform engineering, the models and reports of Analytics, reporting and decision support, the applications of Software development and the models and prompts of AI integration are versioned and deployed here.

What we do

CI/CD and GitOps. Pipelines in GitLab CI or Bitbucket CI build, test and deploy applications, stream-processing jobs, database migrations and platform configuration. The desired state of every environment is held in git and applied from there, so a change is reviewed before it runs and the repository shows what production should look like at any moment.
Infrastructure as code. Ansible for configuration, Terraform for provisioning and Helm for workloads on Kubernetes. Servers, clusters and services are described in code, so an environment can be rebuilt rather than remembered, and the running state is compared with the declared one to catch drift.
Database DevOps. Liquibase and Flyway migrations version every schema change. Changes are applied in the same order in every environment, each with a defined rollback, and new structures are added beside the old ones before the old ones go, so the application can be rolled back without rolling back the database.
Environments with versioned data. DEV, TEST and QA environments carry versioned data sets maintained hand in hand with the schema, so a change is rehearsed against realistic data before it reaches production.
Operational automation. Stop, start, failover, restore and rollback as scripted procedures that respect the dependencies between components, so an operation at three in the morning follows a runbook rather than memory. Secrets stay in vaults.
Monitoring and alerting. Zabbix, Grafana, Prometheus and ELK or EFK for metrics, logs and dashboards across databases, hosts, clusters and pipelines. Alerts fire when a state changes, not while it persists, and reach an engineer who can act on them.
Stack monitoring with incident management. The running stack is compared with a declared inventory of what should be running, so a component that has gone silent is as visible as one that fails. An incident has a start, an end and a duration. The record is kept apart from the systems it describes, so the monitoring outlives what it monitors.

What you get

The scope is set per engagement, from one database brought under migration control to the full delivery path of an estate. What you receive follows the practice the industry has settled on for delivery and operations: GitOps, infrastructure and database as code, change enablement, service level objectives, blameless post-incident reviews and the DORA delivery metrics.

Repositories that are the system of record. Application, database and infrastructure code with the pipelines that apply them, under your account. Who changed what, when, why and how it was tested is in the history, available for audit without a separate register.
A migration history for every database in scope. Every schema change as a versioned migration with its rollback, applied in the same order in every environment, with a table in each database that says which have run.
Rebuildable environments and versioned test data. Any environment rebuilt from code, test data versioned with the schema, so a rehearsal before production is realistic and a recovery environment is a build, not a project.
Changes classified, most of them pre-approved. In ITIL 4 terms: standard changes run through the pipeline without a board, normal changes are assessed and scheduled, emergency changes are reviewed afterwards. DORA’s research found that approval by an external board slows delivery without lowering the change failure rate; peer review captured in the pipeline does that job.²
Monitoring against a declared inventory. Dashboards, alert rules and an incident record with durations for every component in scope, and alerts that reach an engineer who can act.
Service objectives you can check. Availability, freshness and response time objectives agreed per system and measured against the incident record, so a service review discusses figures rather than impressions.
Runbooks that are rehearsed. Deployment, stop and start in dependency order, failover, restore and rollback, written during onboarding, kept current with every change and tested.
Measured delivery. Change lead time, deployment frequency, change failure rate, rework rate and failed deployment recovery time reported for the systems in scope, the way the DORA research measures software delivery.
Post-incident reviews and the 24/7 service. Every P1 is followed by a blameless written review with actions tracked to closure, recurring incidents are investigated as problems, and the whole delivery path can run under the 24/7 service with a P1 reaction within the hour.

AI adoption

Cloudtech uses AI agents in operations for planning, problem analysis and root-cause analysis, under strictly limited access. An agent never has direct access to any system. It reads what the engineer reads: terminal logs, the collected telemetry, the inventory, the incident record and the runbooks, all read-only, and gives its analysis and suggestions beside the engineer as the work proceeds, never inside the system. It proposes a cause and next steps. The engineer decides, and nothing acts on a system without one. Diagnosis gets faster; the audit trail stays what it was, because every action on a system is still an engineer’s, recorded as such.

The same pipeline discipline applies to AI itself. Hosted language models change behaviour between versions, and when and how they are updated is opaque.³ A model in production is therefore pinned, its prompts versioned, and both re-evaluated against a test set before any change, the way a schema migration is tested before it runs.

The database DevOps flow

The diagram shows how a change travels. Developers, DBAs and system administrators commit changes to a git repository. A CI/CD engine validates them. Automation applies database migrations to Oracle, PostgreSQL, MySQL and SQL Server, configuration to Linux, Solaris and AIX, and workloads to Kubernetes and the platforms underneath, on premises or in your cloud account.