Managed DevOps: ITECS Runs the Pipelines and Platforms After the Build
Your engineers ship product while ITECS carries the pages, the upgrades and the cost questions. In Dallas-Fort Worth, ITECS operates your pipelines, clusters, infrastructure code, observability and on-call, and AI features. The retainer is sized to what it runs, and a person you name still approves every production release.
- Who it is for
- Leads whose engineers run ops instead of product
- What ITECS runs
- Pipelines, clusters, infrastructure code, on-call hours, AI features
- What stays yours
- Every account, repository, role and runbook
- Pricing
- Custom-scoped. ITECS quotes a monthly retainer from the assessment's written plan, sized to what it will operate. How the retainer is sized
- Who decides
- Your release approver, and you at each review
Scope
The systems ITECS keeps running
ITECS operates what it built, or what it has reviewed and taken over, inside your accounts. Each change it makes is a pull request your engineers review, merged in a window your release approver agrees. The exception is an emergency console change to restore service, which ITECS logs as a ticket for your drift owner and writes back as a pull request. ITECS runs them the way it has run managed IT and security since 2002, with a 24/7 NOC.
- Pipelines
- ITECS fixes failed runs, watches queue time and runner cost, and keeps runner images and pinned third-party actions up to date. Your release approver still signs off each production release.
- Clusters
- Upgrades follow a calendar set before each version's standard support ends, staging first, in windows your release approver agrees. ITECS resizes node pools from measured use and keeps add-ons current.
- Infrastructure code
- ITECS runs the Terraform applies and the scheduled drift checks, which find changes made outside the code. Each one goes to your drift owner, along with any emergency console change ITECS made to restore service.
- Observability and on-call
- ITECS keeps alert rules current, reports the observability bill each month and takes the nights and weekends your team cannot staff. In those hours the ITECS 24/7 NOC answers each page, an alert that needs a person now, and works its runbook. Alerts that can wait arrive as tickets.
- AI features
- Each feature has its own spend limit, enforced by a cap that stops calls where the provider offers one, or by a gateway limit where it does not. ITECS keeps a runbook for each model retirement and runs scored canaries, fixed questions with known answers, against the live feature. Your feature owner sets the score that pages.
Scenario
A platform its two builders can no longer carry
Illustrative planning scenario, not a reported client result or a named public case study.
- Starting point
- A software company's two platform engineers built a good pipeline and cluster. Their weeks now go to pages, upgrades and cloud-bill questions instead of the product, and one of them has given notice.
- Scoped outcome
- ITECS takes over operation of the pipeline, the cluster and the nights and weekends the team cannot staff, under a retainer sized to what it runs. The remaining engineer keeps business hours, the architecture and the release approvals, and is the escalation contact. The CTO deputises on approvals and sets the work at each quarterly review.
Approach
How ITECS takes over the running
The retainer covers operating what exists, and new builds are quoted on their own. ITECS reviews each system before it takes one over.
Review each system
With read access to your accounts, repositories, paging tool and AI provider consoles, ITECS lists what each system needs before it can answer for it. You decide which systems the retainer covers.
Write the runbooks
Each alert, failed-run case, upgrade and model retirement gets a runbook in your repository. Your engineer reads each one, and ITECS sets up each AI feature's spend limit and canaries.
Name the people
You name a release approver, and a deputy who signs off when they are away. A drift owner decides each drift, and a feature owner sets each AI feature's spend limit and canary score and approves model replacements. Your escalation contact is the person the NOC wakes when a runbook does not restore service.
Take pages side by side
ITECS answers night and weekend pages beside your engineer first, and takes them alone once your engineering lead agrees the runbooks hold.
Start the cadence
The daily work begins, the first monthly report arrives after a month, and at the first quarterly review you set the next quarter's work.
Cadence
Four cadences, two held by your people
ITECS holds the daily work and the monthly report. Your people hold both diamonds: your release approver signs off each production release, and you set the next quarter's work at the review. Days and releases repeat inside each month, and after each review the loop starts again.
ITECS runs
Each day
Your rotation takes pages in business hours, and the ITECS NOC takes them on nights and weekends and works the runbook. ITECS fixes failed pipeline runs, and each drift goes to your drift owner with a proposed fix.
Output: Pages and runs handled
Your approver
Each release
Every release to production, yours or an ITECS platform change such as an upgrade, waits for your release approver or their deputy. In the hours ITECS covers, the NOC may roll back to the last approved release on its own, then wakes your escalation contact. At other times your approver decides.
Output: Approved release
Waits for a person you name
ITECS runs
Each month
The monthly report sets the cloud, AI and observability bills beside traffic, with runner cost, queue time and node-pool sizes. It adds canary scores, the upgrade calendar and every page with what was done about it. ITECS traces spend that traffic does not explain.
Output: Monthly report
You decide
Each quarter
ITECS walks you through the quarter's incidents, releases, spend and upgrades at a review you attend. You set the next quarter's work there, and anything beyond the retainer is quoted before it starts.
Output: Next quarter's plan
Waits for a person you name
Next quarter: same loop
Dashed: a release waits for your approver, a quarter's plan for you.
Deliverables
What you hold, and how you take it back
- Every account, repository, role and runbook stays in your name, and ITECS works inside them with the access you grant.
- A runbook in your repository for each alert, failed-run case, upgrade and model retirement ITECS handles.
- An on-call schedule naming the hours ITECS covers, the hours your rotation keeps and your escalation contact.
- A ticket in your tracker for every drift found and every emergency console change, assigned to your drift owner.
- A spend limit for each AI feature, and the canary score that pages, both set by its feature owner and written down.
- The monthly reports on bills, upgrades, pages and canary scores, and each quarter's plan, kept in your repository.
- On notice, a walkthrough of every runbook for your engineers, after which ITECS removes its own seats and roles.
Where it fits
What ITECS takes over from each build
The assessment comes first. Each DevOps service below is a build ITECS can then operate. The two itecsonline.com rows cover what sits under the platform, and the AI spend guide explains the AI guardrails.
- DevOps assessment
- Reads what you run and shows what ITECS can take over as it stands, so you can choose what the retainer covers first.
- DevOps services
- The hub for every DevOps service ITECS builds and runs, and how an engagement moves from assessment to operation.
- CI/CD pipelines
- Failed runs, queue time and pinned actions become ITECS's daily work, while your approver keeps the release sign-off.
- Kubernetes platforms
- Upgrades run from the calendar in windows you approve, and ITECS resizes node pools from the use it measures.
- Infrastructure as code
- ITECS runs the applies and drift checks, and the drift owner you name decides what happens to each difference.
- Observability and SRE
- The ITECS NOC takes the pages in the hours your retainer covers, and the alert rules it works from stay current.
- Managed Azure cloud
- When the platform runs on Azure, ITECS can also run the subscription under it through managed Azure on itecsonline.com.
- 24/7 network monitoring
- The NOC that answers your managed DevOps pages also runs ITECS's network monitoring on itecsonline.com.
- Buy AI capacity with visibility and guardrails
- The ITECS guide to AI platform spend sets out what to ask of a platform before budgets scale: usage visibility, hard spend limits and the cost of each outcome your team accepts.
Pricing
How the retainer is sized
Managed DevOps is custom-scoped. ITECS quotes it from what it will operate and the hours it covers, once the assessment has shown both.
- Assessment
- Every retainer starts here, with a call that prices the assessment. Its written plan says what ITECS can operate as it stands, and quotes the first piece: the retainer, or a fix needed before it.
- What sizes the retainer
- What ITECS operates: your pipelines, clusters, cloud accounts and environments, the AI features it watches, and the on-call hours it covers.
- Retainer
- Monthly, scoped from the assessment's written plan and revisited at each quarterly review. Each day it covers pages in the covered hours, failed runs, drift and alert-rule upkeep. Each month it covers the report that sets cloud, AI and observability bills beside traffic, with canary scores, the upgrade calendar and every page of the month.
- Changes beyond the retainer
- New builds and changes outside the retainer are quoted before any work starts, and each quote waits for your approval.
- Tooling and cloud
- Your cloud, tool and AI provider invoices come to you. When ITECS is to pass any of them through, the proposal says which.
Prices for the AI packages on this site do not apply to the retainer.
FAQ
Managed DevOps FAQ
What do managed DevOps services include?
Managed DevOps services run your delivery platform after it is built. ITECS operates your pipelines, clusters, infrastructure code, observability and on-call, and AI features, on a retainer sized to what it runs. It works in your accounts, for teams in Dallas-Fort Worth and across the United States.
How is the retainer sized?
By what ITECS operates: the pipelines, clusters, accounts and environments, the AI features it watches and the on-call hours it covers. The assessment lists them, and the quarterly review is where you change them.
What happens at night and on weekends?
Your rotation keeps business hours, and the ITECS 24/7 NOC takes the nights and weekends. It answers each page and works the runbook, and it wakes your escalation contact only when the runbook does not restore service. When your team cannot staff the days either, the retainer covers those hours as well.
Is outsourced DevOps better than hiring?
Each covers something the other cannot. A hire knows your product and is there every working day, but one person cannot also cover every night, their own leave and every cloud you run. A retainer covers the hours and the breadth, and its runbooks stay when people leave. Many teams do both: their engineer owns the architecture and the approvals, and ITECS runs the nights and the upgrades.
Can we start with managed DevOps alone?
Yes, after the assessment. ITECS operates what it has built, or what it has reviewed and taken over. When a system needs work before anyone can run it safely, the assessment's written plan says so and quotes that work first.
How do we leave?
Give the notice your retainer states. The ITECS NOC keeps its hours until the notice ends, then the schedule passes back to your rotation. Before ITECS removes its own access, your engineers get a walkthrough of each runbook. Accounts, repositories and roles are already in your name, and from the first day tickets land in your tracker and reports in your repository.
What does a fractional DevOps engineer get you?
Part of one person's week: design work, reviews and a second opinion. The hours outside that slice, nights and leave included, still fall to your team, and the knowledge sits with one person. Managed DevOps adds the covered hours, and its runbooks live in your repository.
How are AI features operated?
Each AI feature gets its own spend limit, so one runaway job cannot spend another feature's budget. A provider cap enforces it where it stops calls, and a gateway limit where it does not. When a provider retires a model, ITECS follows that feature's runbook, and your feature owner approves the replacement once it passes your evaluation. The scored canaries run between releases too.
Hand over the running and keep the decisions
List the systems your engineers run, the hours nobody covers and the upgrade that keeps slipping. You choose what ITECS takes over first, and the assessment's written plan quotes the retainer.