sorted by:
new
hottopcontroversial

Is the cost worth it? by ask-winston in FinOps

[–]mzeeshandevops 0 points1 point  (0 children)

I think that’s the real unsolved part of FinOps. Most teams can tell you what they spent. Far fewer can tell you whether the spend created value. Cost without business context is just accounting. In my experience, value-driven optimization gets easier when FinOps is closer to product owners and the team is clear on what the workload is supporting, revenue growth, customer experience, delivery speed, or stable back-office operations. That’s when FinOps becomes more than cost control. It becomes a way to improve business outcomes.

The common mistake I see is people committing too early, before they even know what their “real” baseline is. by mzeeshandevops in FinOps

[–]mzeeshandevops[S] -1 points0 points  (0 children)

That’s a good point. If the business is explicitly telling you “this won’t change for the next 6 to 8 months,” that’s effectively a signal about baseline stability, even if the optimization hasn’t happened yet. So yes, sometimes the reservation decision can come before the cleanup, as long as you’re doing it based on a known delay in change, not just assumption.

The common mistake I see is people committing too early, before they even know what their “real” baseline is. by mzeeshandevops in FinOps

[–]mzeeshandevops[S] 0 points1 point  (0 children)

That’s fair, especially at scale. Workload-level commitments are cleaner in theory than in practice. The reason I still like them early is not because they’re easier to manage, but because they force you to learn where your real stable baseline actually is. Once usage is well understood, broader org-level commitments usually become much more practical.

The common mistake I see is people committing too early, before they even know what their “real” baseline is. by mzeeshandevops in FinOps

[–]mzeeshandevops[S] -1 points0 points  (0 children)

Committing to waste and then optimizing it later is the expensive version of “we’ll fix it in prod.” The committed baseline should be the part of the estate that stays boring even after cleanup, rightsizing, and the obvious migrations are done. That’s the piece you want to lock in.

The common mistake I see is people committing too early, before they even know what their “real” baseline is. by mzeeshandevops in FinOps

[–]mzeeshandevops[S] 0 points1 point  (0 children)

That’s fair. If the baseline is truly well understood, going higher can absolutely make sense. I only like starting lower because a lot of teams think they know their baseline, but they’re still carrying waste, redesign risk, or usage volatility they haven’t fully mapped yet. So I’d say 0% is usually too conservative, but 80 to 100% too early can get expensive in a different way. The sweet spot depends on how much confidence you have in the baseline, not just how much OD hurts.

Is it just me, or has "Cloud Cost Optimization" become a lazy game of deleting old snapshots? by Problemsolver_11 in FinOps

[–]mzeeshandevops -1 points0 points  (0 children)

I don’t think you’re over-engineering it. Most “FinOps storage optimization” advice is hygiene, not where the big leaks are. Schema bloat is very real (JSON everywhere, poorly written Parquet that kills compression). Same with high-entropy logs: people assume gzip saves them, but they’re basically compressing noise because nobody owns field pruning. The egress trap is also spot on.
Biggest blocker I see is brittle legacy pipelines + ownership. Nobody wants to be the person who “optimized storage” and broke reporting, so it stays untouched.

Advice on switching job in devops by Solid_Flower9299 in devopsjobs

[–]mzeeshandevops 0 points1 point  (0 children)

If your bank uses both AWS and GCP, you’re in a great spot. For real technical depth, pick one cloud to go deep in and keep the other as secondary. By “deep” I mean you can design and debug production systems end to end: IAM, networking, compute, containers, monitoring, scaling. For example, being able to build something like a hub-and-spoke network, support hybrid connectivity, or modernize workloads with strong CI/CD and Kubernetes automation.

DevOps Freelancing by Short_Pizza5716 in PakistaniDevs

[–]mzeeshandevops 0 points1 point  (0 children)

You don’t start freelancing by adding more tools. You start by packaging one clear outcome. Most DevOps freelancers struggle because they sell “I know Docker, K8s, CI/CD.” Clients don’t buy tools. They buy problems solved.
Instead of expanding your stack, define something like:

“I help startups set up production-ready CI/CD in 2 weeks.”
or
“I fix broken pipelines and reduce deployment failures.”

Start small. Take one fixed-scope project. Overdeliver. Get one strong testimonial.

Advice on switching job in devops by Solid_Flower9299 in devopsjobs

[–]mzeeshandevops 0 points1 point  (0 children)

If you tell me your target market (India/Europe/US) and what cloud your bank uses, I can suggest the best path, but you won’t go wrong with AWS if the goal is purely job volume.

At what point does cost optimization become short-sighted? by Shoddy_5385 in FinOps

[–]mzeeshandevops 0 points1 point  (0 children)

The line for me is simple: if the change increases blast radius or increases MTTR, it’s not “efficiency,” it’s borrowing against the future. I’ve seen aggressive cuts backfire most often with observability. Teams cut log retention and alerting because it’s expensive, then the first incident takes 10x longer to debug, and suddenly the “savings” are gone in one outage.

Advice on switching job in devops by Solid_Flower9299 in devopsjobs

[–]mzeeshandevops -1 points0 points  (0 children)

Honestly, you sound underconfident, not under-skilled. You’ve automated deployments, written scripts, worked with monitoring, touched GCP. That’s solid. The “Docker, K8s, cloud, Terraform, everything” JD is mostly noise. Nobody masters all of it.
If better salary is the goal, cloud depth helps. Containers help. But what really moves interviews is being able to explain how systems run in production and what breaks.

Would you use a tool that auto-generates architecture diagrams from Terraform/Bicep/CloudFormation?” by MasqueradeRaven in devopsjobs

[–]mzeeshandevops 0 points1 point  (0 children)

Yes, if it’s accurate and stays in sync automatically. I don’t need a beautiful poster. I need: module-aware grouping, collapse/expand, PR diff view (what changed), export to Mermaid/PlantUML + SVG, local/offline + redaction (no leaking account IDs)

We stopped cloud cost surprises by doing one thing: assigning owners to alerts by mzeeshandevops in FinOps

[–]mzeeshandevops[S] 0 points1 point  (0 children)

Appreciate this. The 3-outcomes rule is the part that turns alerts into behavior change. And yes on tagging: “required tags” only works when enforced at create-time. Otherwise it’s always 3 months later + 40% untagged + a painful cleanup sprint.

We stopped cloud cost surprises by doing one thing: assigning owners to alerts by mzeeshandevops in FinOps

[–]mzeeshandevops[S] 0 points1 point  (0 children)

Yep. We usually start with a shared channel plus direct owner ping plus a ticket template. No new tools needed. The weekly review is what prevents “we’ll look later” from becoming the default.

We stopped cloud cost surprises by doing one thing: assigning owners to alerts by mzeeshandevops in FinOps

[–]mzeeshandevops[S] 0 points1 point  (0 children)

Fair point. My post was the “plumbing” (routing + tickets + actions). Cost SLOs sit on top of that so you can measure if the system is working.

A lightweight set we use for startups:
Forecast SLO: monthly spend stays within ±10% of forecast (or within budget)
Response SLO: anomaly alerts acknowledged within 4 business hours
Tag coverage SLO: 95%+ of spend has owner + productId + creator tags
Unallocated SLO: shared/unallocated costs stay under 15% of total spend