zlacker

Exactly what I was thinking when the OP comment brought up "regular launches containing replacement hardware", this is easily solvable by actually "treating servers as cattle and not pets" whereby one would simply over-provision servers and then simply replace faulty servers around once per year.

Side: Thanks for sharing about the "bathtub curve", as TIL and I'm surprised I haven't heard of this before especially as it's related to reliability engineering (as from searching on HN (Algolia) that no HN post about the bathtub curve crossed 9 points).

>>rajnat+(OP)
https://accendoreliability.com/the-bath-tub-curve-explained/ is an interesting breakdown of bath tub curve dynamics for those curious!

>>btown+Df
Wonder if you could game that in theory by burning in the components on the surface before launch or if the launch would cause a big enough spike from the vibration damage that it's not worth it.

>>rtkwe+Vn
I suspect you'd absolutely want to burn in before launch, maybe even including simulating some mechanical stress to "shake out" more issues, but it is a valid question how much burn in is worth doing before and after launch.

>>rtkwe+Vn
Maybe they are different types of failure modes. Solar panel semiconductors hate vibration.

And then, there is of course radiation trouble.

So those two kinds of burn-in require a launch ti space anyway.

>>rajnat+(OP)
Ah, the good old BETA distribution.

Programming and CS people somehow rarely look at that.

>>vidarh+qy
Vibration testing is a completely standard part of space payload pre-flight testing. You would absolutely want to vibe-test (no, not that kind) at both a component level and fully integrated before launch.

>>0xffff+VM
PSA: do not vibe-code the hardware controller for your vibration testing rig. This does not pass the vibe test.