On the first of July, the engineering lead at a fictional Ahmedabad booking company — call it Tarang Live — pinned one page to the wall beside the standup board. It recorded that Navratri would begin in eleven weeks, that the previous year’s Garba event listings had collapsed the search function twice, and that this year there would be no third collapse. What follows is the twelve-week record of that team’s DevOps preparation, presented as it happened, with the numbers the team itself tracked.
The Setting: Nine Weeks to Garba Season
Tarang Live sold passes for dandiya nights, heritage walks, and food festivals across Gujarat. Seasonally, its traffic curve resembled a heart monitor: quiet for months, then violent spikes every late September. The team of five shared one on-call rota with nobody, and its release process belonged to an earlier decade — a fortnightly change board, a quarterly release train, and a deployment script only one engineer would run from his laptop. Intent was never the problem. Structure was.
Week Zero: The Baseline
Precise work starts with precise measurement, so the first week recorded the panel exactly as found:
- Lead time — four weeks from merged code to a live listing page.
- Deployment frequency — once a quarter, weather permitting.
- Time to restore — six and a half hours during the last season failure.
- Change failure rate — roughly one deployment in three needed a follow-up fix.
- Rework rate — unknown, and its absence was itself a finding.
Two calibrations from the research were noted at the same time: restoration counts only change-caused failures per the 2023 redefinition, and rework rate joined the panel in 2024. The team also priced its queue — ten approved features, each valued near 5,000 units of weekly benefit, waiting on average three weeks — which produced a delay bill of about 180,000 units a quarter. That figure, not any technical argument, is what opened the budget line for a coach.
What the Baseline Never Showed
The week-zero numbers carried a gap worth reporting. No measure existed for how much effort went into redoing failed work, which is why the unknown rework figure mattered more than the poor numbers beside it. Once the column existed, it told a story the others had missed: roughly a third of engineering time was quietly spent re-fixing changes that had already shipped. That discovery did more for the automation case than the delay bill, because it reframed the spending as current rather than future. Baselines, the team concluded, should always include a row for what is not yet measured — the empty row is often the loudest cell on the page.
Weeks 1–4: Seeing the Work, Stabilising the Path
The coach arrived in week one and prohibited tooling purchases for a fortnight. The team drew its value stream instead: an idea for a seating-chart feature waited six days for review, nine days for the change board, eleven days for the release window. Work time was measured in hours; wait time in weeks. With the waits exposed, three agreements were signed and posted. The checkout-and-listings stream would be protected from the shared release calendar. Output would dip while automation raised the testing bar, and a six-week dip was pre-approved so nobody would panic at week four. And every change would henceforth travel one identical pipeline, built once, promoted through each environment without rebuilding.
Weeks 5–8: Automating the Path, Rehearsing the Exit
Week five delivered the incident that had been scheduled by history: a routine deploy triggered a 4 percent rise in declined payments. The response followed the new script — deployment ID declared, owner named, no irreversible migration having run, so rollback proceeded — and still consumed 190 minutes, because rehearsal had not yet happened. The team drilled monthly thereafter. By the third timed exercise the same recovery ran close to twenty minutes. Commit feedback was tightened in parallel until every change received a verdict in roughly ten minutes; when a stage ran long, the stage was simplified rather than the wait accepted. Flags went in so unfinished work could sit dark in production, and canary routing covered anything touching payments.
Weeks 9–12: Governing and Spreading
The final phase addressed the questions an auditor would eventually ask. Access moved to least privilege. Static credentials were retired in favour of short-lived tokens issued through OIDC. A break-glass merge path was created — loudly alarmed, never silently available. A quarterly evidence routine was scheduled: roughly ten changes pulled at random, each checked end to end for a complete trail. None of it slowed the pipeline; that is the point of automated, evidenced controls in a regulated context. In week eleven, the team running the company’s vendor-management app asked to adopt the same rules, which is the customary moment a pilot stops being a pilot.
Locating the Team on the DevOps Maturity Ladder
The standard ladder runs from siloed beginnings through automated islands and integrated working up to continuous delivery, whose final step is the learning system. In July, Tarang Live was honestly siloed with islands of local automation — the deployment script, the laptop. By the end of September it stood at integrated, with the checkout stream genuinely continuous and the blameless-review habit (held within five working days, focused on systems rather than people) functioning as its learning mechanism. Two rungs in twelve weeks is typical for a coached pilot; claiming the top rung in a quarter is how programmes get laughed out of retrospectives. Definitions for this ladder and its terms were kept consistent against xOps School’s DevOps encyclopedia page, which spared the team several circular debates.
What the DevOps Quarter Produced
Season opened on the twenty-second of September. Lead time had fallen from four weeks to under two days. Deploys ran several times weekly through the spike period, including one Saturday-morning fix for a seating-map edge case that would previously have waited for the next train — and possibly caused the next collapse. Restore capability was never formally exercised in anger, which the team regarded as the correct anticlimax. The change failure rate settled near one in ten, and the rework figure that had been unmeasurable in July became a standing column on the wall.
Other teams preparing for their own spike season can borrow the sequence rather than the specifics: the step-by-step DevOps career guide for building skills in order, the piece on DevOps consulting services for automation, collaboration, and continuous delivery when outside capacity is needed, and the checklist for choosing the right DevOps consultant for enterprise transformation before signing anything. Precise people will notice the pattern beneath it all: see the work truthfully, automate one path completely, rehearse failure calmly, and let the calendar — Navratri or otherwise — find a team that is already rehearsed.
