Jo owns a light sport aircraft and, on weekdays, leads a four-person engineering team whose product rides on GitLab. This spring the two worlds collided pleasantly: while her mechanic crawled over the airframe for its annual condition inspection, she decided her platform deserved the same courtesy. The label for what she audited is GitLabOps — the Atlas’s word for the work of keeping GitLab delivery healthy — but the method was pure old-school general aviation: sections, findings, discrepancies, and a signed-off plan. A weekend, a notepad, and read-only access were the entire tool budget. Her mechanic would have recognized the setup instantly: no new tools, just the discipline to look at everything once, in order, without hurrying past the awkward bits. Here is her audit, section by section, written up so your team can fly the same pattern.
The GitLabOps Hangar Check, Section by Section
Five sections, each with questions a non-specialist can answer truthfully:
- Airframe — the inventory. What ships to customers, who owns each piece, which pipelines exist, and when did anyone last read them? Write answers down before fixing anything, because the list itself is the baseline every later audit measures against. Orphaned configs turned up here, the way lost screws turn up under a floorboard: harmless individually, ominous in quantity.
- Fuel system — the credentials. Any cloud keys living permanently inside CI variables? Any kubeconfig files saved where a job can read them? Both are contaminated fuel: the engine runs, but every mile is borrowed.
- Engine — the runners. Is there one shared, privileged Docker-in-Docker pool doing everything for everyone? Which machines run saturated, which idle, and do the tags still tell the truth about capabilities? An engine section tells you about the next thousand flights, not the last one, which is precisely what makes it worth the crawl.
- Controls — the deploys. Are blanket retries doubling every failure and laundering the flaky tests in the process? Do production changes pass a named gate, or just a vibe? Could an outdated job overtake a newer release and silently undo it? Controls should feel firm, not stiff — resistance with a reason.
- Instruments — the platform. How many minors behind current is the installation — more than two is a finding, not a footnote? Has a backup ever been restored on purpose? Is the fleet sized on evidence or on the Kubernetes-executor-is-cheaper assumption, which often fails its own check when the actual workload finally gets priced? Instruments are where small teams learn the most, because they reveal not just today’s state but the drift rate — how fast quiet neglect becomes loud failure.
What Our GitLabOps Audit Turned Up
Findings first, feelings later — that is the rule. Jo’s list, honestly filed: one abandoned pipeline still firing nightly for a retired service; two cloud keys with birthdays older than the product; the single privileged build pool, lovingly maintained and wrongly trusted; retries set to two on everything since 2023, quietly laundering the flakiest suite in the building; and an installation four minors behind, justified every month by a busier month. The fix list took three Saturdays, in this order: keys first — everything moved to short-lived OIDC identities, with the job-token allowlist switched on; then the pool split into trusted and disposable halves; then retries narrowed to infrastructure jobs only, which immediately made the real flaky tests visible and therefore fixable; the upgrade came last and took one unhurried morning, mandatory stops respected, migrations finished before lunch. The order mattered: credentials before infrastructure, infrastructure before upgrades, because each fix made the next one safer to attempt. Jo’s note in the margin — “fix the fuel before the engine” — has already been quoted back to her twice.
The part she insists on telling other owners: nothing on the findings list was exotic. Every item came from a checklist any careful person could run, which is the entire character of airworthiness — not the absence of faults, but the habit of looking where faults collect.
Filing the Audit So It Counts
An inspection that changes nothing is a receipt, not an audit, and Jo wanted the paper to mean something. Every finding got one of three verdicts: fix now, schedule with a date, or accept in writing with a reason. Nothing was allowed to hover undecided. Jo closed hers the way her mechanic closes one: findings written down, each with an owner and a date; fixes verified by re-running the same questions a month later; and the whole document linked from the team’s front page, so the next audit starts from evidence instead of memory. Schedule the re-check before you finish the first pass — recurring audits are how a one-time cleanup becomes a culture, and how a team stops fearing the questions. The reference behind every section — playbooks, thresholds, the anti-pattern list — is the Ops Atlas’s GitLabOps entry, and it earns its bookmark.
Same Discipline, Different Hangar
Light sport owners already run this loop for their airplanes, and the mindset transfers verbatim: the questions in a landing gear checklist for LSA owners, the traps in fuel system mistakes pilots should avoid, and the cautionary tales in common modification mistakes LSA owners make all share a skeleton with platform audits. Inspect on a schedule, distrust convenient assumptions, and never let the only person who knows the system be the reason it stays safe. Your GitLab setup carries passengers too — it just calls them users, and they never file the incident reports. Hand them a much safer machine this weekend; the audit fits between breakfast and a crosswind landing, and it ages better than almost anything else on the calendar.
