4 ms·

> prepare to [have] a night of adventure. This is exactly why we don't deploy at night. In what other line of work do you schedule complex work when you're goi

> prepare to [have] a night of adventure. This is exactly why we don't deploy at night. In what other line of work do you schedule complex work when you're going to be tired?

Murkin 16y ago
I really hope they don't start fixing roads during the day.. you know.. so the workers are not tired. Or major electrical upgrades.. or phones.. or local internet backbone.. or water.. or what ever other utility that is more important to my life than github (which was down today) How hard is it to work at night one time ??
- InclinedPlane 16y ago
  For roads it's almost impossible to avoid impacting use during maintenance, the same isn't, or shouldn't, be true with software.
- LaGrange 16y ago
  The big point seems to be "Many web applications, including Scout, have customers around the world. There isn’t a perfect time for a deployment." It is like a road stuck in a permanent rush hour -- if the time of repair has little effect on the users annoyance, then it's a good idea to pick the time to maximize your performance. Working at night isn't hard in the meaning "I don't know if I can pull that off," but in the "I don't know how well will I pull that off" meaning. Anyone can pull an all-nighter or two, but most people will make more errors in the night than during the day.
carbocation 16y ago
Medicine? (Although your hand is usually forced into doing night procedures--it's not so much a choice, I agree.)
- mikedanko 16y ago
  I missed some context there. I thought "yes, I need medicine after night work". Why did I completely miss the mark? Swing shifts all week.
  - carbocation 16y ago
    Heh, I meant the field of medicine. But I can understand your perspective :)
maw 16y ago
1) It takes a tough man to make a tender chicken. 2) You should know what you're going to do ahead of time, and you should have done tests beforehand. The after-hours work isn't that complex if you're doing it right.
- lsc 16y ago
  1) It takes a tough man to make a tender chicken. 2) You should know what you're going to do ahead of time, and you should have done tests beforehand. The after-hours work isn't that complex if you're doing it right. 1. you have no idea how many systems have been utterly destroyed by "tough men" working beyond their limits. I have seen this many places I've worked as a SysAdmin... it's like a mind disease, and it's not any good for anyone. 2. You need to prepare ahead of time, and you need an easy way to roll back. but you /always/ need to be prepared just in case something goes wrong. This is the other classic mistake: Make the new guy stay up all night handling the upgrade. I mean, the senior guys have tested it, right? It ends in tears for all involved. the new guy is the least able to deal with the stresses of doing the upgrade (and the rollback, and even if you test the upgrade, nobody tests the rollback) Do your upgrades when your senior people are around, preferably towards the beginning of their shift. If everything goes as planned, it won't matter when you do it, because downtime will be minimal either way. If, however, it throws up on your shoes, I don't know about you, but I am significantly more effective at dealing with problems when I'm fresh. And yeah, that means I'm a wimp. But when you get down to it, most of us are.

> prepare to [have] a night of adventure. This is exactly why we don't deploy at night. In what other line of work do you schedule complex work when you're going to be tired?

Murkin 16y ago

I really hope they don't start fixing roads during the day.. you know.. so the workers are not tired. Or major electrical upgrades.. or phones.. or local internet backbone.. or water.. or what ever other utility that is more important to my life than github (which was down today) How hard is it to work at night one time ??

InclinedPlane 16y ago
For roads it's almost impossible to avoid impacting use during maintenance, the same isn't, or shouldn't, be true with software.
LaGrange 16y ago
The big point seems to be "Many web applications, including Scout, have customers around the world. There isn’t a perfect time for a deployment." It is like a road stuck in a permanent rush hour -- if the time of repair has little effect on the users annoyance, then it's a good idea to pick the time to maximize your performance. Working at night isn't hard in the meaning "I don't know if I can pull that off," but in the "I don't know how well will I pull that off" meaning. Anyone can pull an all-nighter or two, but most people will make more errors in the night than during the day.

carbocation 16y ago

Medicine? (Although your hand is usually forced into doing night procedures--it's not so much a choice, I agree.)

mikedanko 16y ago
I missed some context there. I thought "yes, I need medicine after night work". Why did I completely miss the mark? Swing shifts all week.
- carbocation 16y ago
  Heh, I meant the field of medicine. But I can understand your perspective :)

maw 16y ago

1) It takes a tough man to make a tender chicken. 2) You should know what you're going to do ahead of time, and you should have done tests beforehand. The after-hours work isn't that complex if you're doing it right.

lsc 16y ago
1) It takes a tough man to make a tender chicken. 2) You should know what you're going to do ahead of time, and you should have done tests beforehand. The after-hours work isn't that complex if you're doing it right. 1. you have no idea how many systems have been utterly destroyed by "tough men" working beyond their limits. I have seen this many places I've worked as a SysAdmin... it's like a mind disease, and it's not any good for anyone. 2. You need to prepare ahead of time, and you need an easy way to roll back. but you /always/ need to be prepared just in case something goes wrong. This is the other classic mistake: Make the new guy stay up all night handling the upgrade. I mean, the senior guys have tested it, right? It ends in tears for all involved. the new guy is the least able to deal with the stresses of doing the upgrade (and the rollback, and even if you test the upgrade, nobody tests the rollback) Do your upgrades when your senior people are around, preferably towards the beginning of their shift. If everything goes as planned, it won't matter when you do it, because downtime will be minimal either way. If, however, it throws up on your shoes, I don't know about you, but I am significantly more effective at dealing with problems when I'm fresh. And yeah, that means I'm a wimp. But when you get down to it, most of us are.