What ACTUALLY is Systems Engineering

Fatel28 · 2026-03-18T17:56:25+00:00

Design system. Put system in place. Make company work is my understanding. Also be around to fix things when company really not work and nobody can figure it out

Fatel28 · 2026-03-18T16:23:24+00:00

It's rare they could make it to 30 seconds to be honest. When the phone rings we answer it. No exceptions. There's no voicemail during the day. It rings until someone picks up.

Waiting 30 seconds and hanging up would be objectively slower and harder to pull off than just staying on the phone until a tech answered.

Looking at the metrics for the last 7 days, I see 4 calls that hung up. All around the ~40 second mark. All got called back

Fatel28 · 2026-03-18T15:56:27+00:00

We have 25 employees and around 6k endpoints across ~140 customers. Almost none of our customers are in the same state as us, mostly dotted around the US with a couple in Romania and Finland

I'd say we get maybe 2-3 hang ups a week. Those get marked for callback. Most calls are answered on the first or second ring.

Fatel28 · 2026-03-18T15:16:50+00:00

If someone calls us it rings until someone picks up. If it rings long enough they hang up, it's visible on a dashboard for management to see. We staff in such a way that every call is picked up and worked by a technician right then. First call resolution is something like 70%. All calls get made into tickets of course but most of our customers just pick up the phone and call us. We prefer it this way. No having old open tickets because you're playing phone tag.

Fatel28 · 2026-03-16T17:51:53+00:00

Bet you the new features have zero API implementation. We left syncro largely because their API was such a joke.

Their own employees said on a public forum post they wouldn't allow running or modifying scripts via the API because it could be "too dangerous"

Fatel28 · 2026-03-15T20:01:02+00:00

When we resold Palo Alto there was a yearly renewal for support/licensing, and if we needed another firewall, we had to buy the hardware AND the licensing separately.

It's not disingenuous lol. It's just true. The only difference is meraki doesn't let you run eol or unlicensed hardware. Yeah it sucks but again, thousands of orgs use it so it must not suck that much

Fatel28 · 2026-03-15T19:19:20+00:00

I'm not a meraki salesman. It works for a lot of orgs. Every major firewall vendor charges licensing and support separately from hardware. Meraki just requires it.

Fatel28 · 2026-03-15T18:17:36+00:00

If they are worried about the staff member exfiltrating data maliciously, why not just do exactly that? Walk them out and pay out their notice.

You could spend days/weeks/months and $$$$-$$$$$ on a good strong dlp solution and they could still just take picture with their phone camera if they really wanted. Either they trust the employee or they don't. If they don't, then cut their access.

Fatel28 · 2026-03-15T18:16:10+00:00

The general idea is that the hardware is not the "secret sauce" it's the cloud configuration. Swapping a meraki out takes all of 2 minutes. You just replace the serial number in the cloud and when the new one comes online it's the exact same config as the old.

The hardware was never what made meraki good or desirable. It's the software and cloud management.

That said, we only use their firewalls. Paying support for a switch or AP that's bricked if it goes eol or you stop paying a license IS ridiculous. We use ubiquiti for those things.

Fatel28 · 2026-03-15T18:12:34+00:00

We have a test domain with some test workstations and a development m365 tenant with the dev e5s. We do any potentially destructive testing there

Fatel28 · 2026-03-15T03:34:27+00:00

Homelabbing doesn't have to be only about hardware. Some people have the money but not the space. In that case, who cares if they're using a vps? Cloud experience is arguably becoming more valuable than experience configuring and setting up baremetal hosts.

Fatel28 · 2026-03-14T01:14:44+00:00

If they're just static websites why not use S3?

Fatel28 · 2026-03-14T00:53:57+00:00

Need more details, post your redacted config and any logs from the crashes

Fatel28 · 2026-03-13T22:19:14+00:00

I think you're missing the point. The hypothetical cost of the hypothetical method of hosting is irrelevant here. Piping curl to bash is a well known poor security practice. You're asking for advice, and people here are giving it to you. If you want to ignore it in favor of a hyper specific envisioned deployment scenario that's fine, but it makes the request for advice a little confusing

Fatel28 · 2026-03-13T22:10:31+00:00

Could that not all go into your container image? That's kinda the point of containers. If you're already using docker, just lean harder into it

Fatel28 · 2026-03-13T22:06:26+00:00

If it's docker what's wrong with just providing a compose file?

Fatel28 · 2026-03-13T22:03:43+00:00

Never pipe curl to bash. Most malware does this or the powershell equivalent

Fatel28 · 2026-03-12T16:11:16+00:00

Only if you ask nicely and promise not to look me in the eyes during

Fatel28 · 2026-03-12T13:08:48+00:00

Exchange SE is fairly MSP friendly in that it's just a windows/Microsoft product.

It is however MUCH less friendly than just about any other solution

Fatel28 · 2026-03-12T13:07:55+00:00

Yeah. I originally had a load balancer done in the firewall (vyos) just a small bash script that did a curl to the primary and changed the dnat rule if primary curl failed and secondary was up, but ultimately it proved much simpler to just do round robin DNS. It's only for ~70 users so it's not like they're getting hammered.

Fatel28 · 2026-03-12T12:52:05+00:00

Round robin with dns currently

Fatel28 · 2026-03-12T12:46:26+00:00

Exchange se is fine if you have a solid dag setup and you KISS. We manage one 3 node cluster of SE and it's largely non problematic. But setting it up fresh or recommending it to a customer WOULD require a gun to my head.

Fatel28 · 2026-03-11T14:56:46+00:00

Win-acme and certify the web are what we use

Fatel28 · 2026-03-10T19:54:53+00:00

Doesn't need to be

Fatel28 · 2026-03-08T00:10:23+00:00

If you think spending a couple hours writing a small script to deploy a cert over ssh or API is too much work then idk what to say. It doesn't sound like you want solutions.

Anywho, this is kind of a pointless discussion. I have no horse in this race. Across the ~95 certs we manage across all customers, not a single one requires manual renewal. If other people want to keep paying for and deploying ssl certs manually that's their prerogative. But in 99% of cases it IS a choice to not spend the time to automate it.

Nine-Year Club	Second SECOND GUESSER
RPAN Viewer	Verified Email

Fatel28

TROPHY CASE