| 1 |
On 01/02/2012 05:06 AM, Alan McKinnon wrote: |
| 2 |
> |
| 3 |
> You have a production machine delivering valuable services to multiple |
| 4 |
> users. |
| 5 |
> |
| 6 |
> Therefore you must only update *anything* on it during planned |
| 7 |
> maintenance slots. If paying customers are involved then preferably |
| 8 |
> with a second redundant parallel machine to take over the load during |
| 9 |
> that slot. You don't have much of an option about this in the real |
| 10 |
> world, think of it as a constraint that you must simply deal with. |
| 11 |
|
| 12 |
In a perfect world, we would do this for all updates. But there's only |
| 13 |
one of me, and my time is better spent doing other things than, |
| 14 |
|
| 15 |
* writing documentation |
| 16 |
* updating the test machine to match production |
| 17 |
* doing the update |
| 18 |
* testing all critical services |
| 19 |
* pushing the update live |
| 20 |
* retesting |
| 21 |
|
| 22 |
just to update ca-certificates on a database server. |
| 23 |
|
| 24 |
We do all of the above for major upgrades, and by now I have a pretty |
| 25 |
good idea of which upgrades are going to break something. |
| 26 |
|
| 27 |
I still wind up using emerge -u on the test machines -- I upgrade all of |
| 28 |
the minor packages and ensure that things are still working before I do |
| 29 |
the major one, so if something breaks, I'm not chasing ghosts. |
Archives