> staggering employee start times

Immediately reminds me of Severance.

I work at a company of ~200 people and I already don't recognize everyone. Seeing an unknown face, I just assume they are from some distant team that I never had to interact with, say hi and move on.

While I've considered all the AI-inspired seasons of Sillicon Valley a bit boring and repetitive (mostly because AI is the deus ex machina there), some of this stuff actually is real now. You can actually have AI that optimizes itself.

> If your primary load exceeds 30% (CPU util), consider adding read replicas.

I'm not an expert, but isn't this excessive? In theory you could triple the load and still have slack. I'd actually try to scale down, not up.

If most of your users are concentrated in the same (or nearby) time zones, your traffic can easily vary by 5–10x over a 24-hour period. In that case, 30% average CPU utilization doesn't mean you have 70% headroom at peak... it may already imply you're close to saturation during busy hours.

For example, if 30% is your daily average and your peak-to-average ratio is ~5x, you're effectively hitting 150% of capacity at peak. Obviously the system can't sustain that, so you'll see queueing, latency spikes, or throttling.

The 30% guideline makes sense if you care about strict SLAs and predictable latency under peak load. If you're more tolerant of temporary slowdowns, you could probably run closer to 60–70% average utilization, but you're explicitly trading off peak performance and tail latency to do so.

Load is highly bursty. You can autoscale application services quickly, but scaling your database up is a slower thing.

For a machine that must run 24/7 or at least most of the day, the next best alternative to a separate computer is a cheap Linux VPS. Most people don't want to fiddle with such setup, so they go for Mac Minis. Even the lower spec ones are good enough, and they consume little power when idle.

many websites block access from cloud ips - reason why openclaw creator recommended a local one

I like that, this name tells you all about the security implications. Like, your user data could be penetrated.

I like ‘claw’ because the s in it stands for security

While this is cool and I dig it, I'm really, really thankful for maintenance windows at the current job. In the real world, 99.9% of systems aren't used 24/7/365. Just do the cutoff when everyone is asleep. Then restart everything to be sure.

> In the real world, 99.9% of systems aren't used 24/7/365. Just do the cutoff when everyone is asleep

"Real world" being something that covers max what, 10 hours of a day? What about things that are used by the entire world? I think there is more than you realize of those sort of services underpinning the entire internet and the web, serving a global user base.

Almost nothing in the world is used globally. You have a handful of things like YouTube and Facebook and the visa network.

Nobody is using slopwork’s new CrudX at a global scale.

The Visa network is the frontend to a truly staggering number of issuers who also want to maintain a similar level of uptime to support their cardholders wherever they are in the world.

Basically every large multinational corporation will have a bunch of systems that are used globally. Most advertising companies work on global traffic patterns.

A large multinational corporation can go a long way by splitting they IT infra into multiple regions and doing maintenance in different regions at different time.

This idea sounds nice, but there's a high maintenance cost to this.

- How will you maintain multiple deployments across multiple regions in the world? Backups, security patches will start to take a toll. - How granular is the right split? Not every country has a cloud provider. Then you need to start thinking about regions and office timings and then it starts to get all blurry.

> How will you maintain multiple deployments across multiple regions in the world? Backups, security patches will start to take a toll

The same way as always - by automating the crap out of it.

> How granular is the right split? Not every country has a cloud provider.

Doesn't have to be one deployment for one country, does it? Having like 3 or 4 deployments across the globe already gives you (at least) 3-4 hours of inactivity window, let's say 1 am - 4 am or something.

Exactly, that's how you do it. Having one system for the whole world is risky.

> What about things that are used by the entire world?

Well, for the remaining 0.1% - go ahead and use the fancy hot replication thingy. Sometimes there is no choice, and that's fine. Although that might mean, that the system architecture is busted.

> Just do the cutoff when everyone is asleep.

In this age, many smaller companies serve customers across the globe. There is no common “asleep”.

But so what? Another app can't really read swap file/partition. Unless it runs with elevated privileges like root, in which case the system is compromised anyway.

> bind mount the docker socket

Bind-mounting /var/run/docker.sock gives 100% root access to anyone that can write it. It's a complete non-starter for any serious deployment, and we should not even consider it at any time.

Sure, but sometimes that's what you intend. Docker isn't always used for, nor is it particularly designed to be a security / sandboxing solution. If I'm running a tool as root that interacts with the docker daemon, I might choose to run it in a container still.