Managed Services Support Platform

Managing cloud infrastructure for many clients creates a specific problem: the provider’s own operational data is the one thing nobody has a system for. Client data lives in the client’s tenancy. The provider’s view of it lives in people’s heads.

This platform is that missing system — built on Oracle 26ai with an APEX 26.1 front end, authored in APEXlang and deployed through SQLcl.

What it covers

Thirteen modules, all in production:

Module	What it does
FinOps	Historical billing across every managed tenancy, fully attributed to clients
Inventory	Continuous resource discovery across every subscribed region
Monitoring ingestion	Health reports, issues and metrics collected from the managed fleet
Unified Audit	Database audit events collected, classified and alerted on
Ticket operations	Support tickets with an aging, delay and follow-through model
Cloud Guard	Security findings with triage state and history
Announcements	Cloud advisories ingested with an engineer triage workflow
Certificates	TLS discovery, expiry monitoring and renewal tracking
AI knowledge base	In-database vector search over vendor documentation

Plus security and access control, client and tenancy onboarding, notifications and alerting, and an asset register.

Cost attribution was the hard part

Cloud bills arrive by compartment, not by client. Shared tenancies mean one compartment tree can serve several client organizations, and the mapping is a business fact the API cannot tell you.

The platform models client-to-tenancy-to-compartment explicitly, with unmapped compartments falling back to the tenancy’s root owner so nothing is silently dropped. The result reconciles against the source system — and where it does not, the variance is tracked as a known source-data gap rather than quietly absorbed. That distinction is what makes the number usable in a client conversation.

Security model

Every end-user module is gated by a per-user, per-module, per-client authorization check. A support engineer is granted specific clients or specific tenancies; a client user sees only their own organization. Multiple authentication schemes run side by side, including single sign-on.

This is verified rather than asserted. A dedicated security test suite walks every combination of persona and module, checking for two distinct failure modes: data leaking to someone who should not see it, and legitimate access being over-blocked. Both currently sit at zero, including a global-search probe that specifically hunts for rows belonging to another client.

Testing

The platform carries a full end-to-end browser suite, run serially against a live environment, with a small number of specs deliberately gated behind feature flags and environment guards.

One episode is worth recording. A batch of failing tests was triaged and every one turned out to be a bad test rather than a product defect — but several could only have been made green by reversing a deliberate operational decision. Rather than relaxing those assertions, the specs were rewritten to assert more strictly than before, and the distilled rules went into the project’s troubleshooting guide so the same mistake does not recur.

A related failure is more instructive. A large group of persona tests had been silently passing for weeks because the login helper assumed each demo user’s password matched their username, so authentication never actually failed. The helper now resolves credentials properly and fails loudly when it cannot. A test that cannot fail is not a test.

AI, in the database

The knowledge base module ingests vendor documentation, chunks and embeds it in-database using Oracle’s vector chain against a self-hosted embedding model, and serves retrieval-augmented Q&A to engineers — plus automated first-pass triage on incoming monitoring alerts. No document content leaves the database.

Related

The monitoring data flowing into this platform comes from a purpose-built agent — see Oracle Database Monitoring at Fleet Scale.