Infrastructure review

A review of the system you have to run

An infrastructure review answers a practical question: can this platform be operated by the people who will own it? We look at the services the site has to talk to, the path a release takes from the repository to production, and the environment those releases land in. The result is a written account, not a score.

The usual subject is a Drupal platform and the pieces around it. Hosting, cache, files, search, mail, identity, the CI pipeline, and the accounts that can change production. We also look at the services a Cloud and AI estate adds, when those are part of the same system.

What you leave with

You leave with findings your own team can act on. What is fragile. What is undocumented. What would stop a deploy on the day the person who usually does it is away. Where a secret, a permission, or a single server is doing more work than it should. Each finding says what we saw and what changing it involves.

We do not turn the review into a rebuild by default. Some findings are a paragraph in the runbook. Some are a pipeline. Some are a reason to move a workload. The review separates them so you can sequence the work, including the parts you will do without us.

• The services the platform depends on, and what happens when one of them is down.
• How a change is built, reviewed, and deployed, and who can do it.
• Environments, access, backups, and the gap between what is documented and what is true.
• A written list of findings, ordered by the risk of leaving them.

Before you send access

An NDA is available before you share architecture or credentials. Tell us the platform and the question the review must answer. We reply within 24 hours with the access we actually need, which is usually less than a full production login.

This work sits inside Cloud & AI Development. Request information — tell us the organisation, the platform, and the constraint.