4 ms·

I agree it's a valid question, I just think framing it in a more concrete way would elicit a better answer. The answers will be very different if we're talking

I agree it's a valid question, I just think framing it in a more concrete way would elicit a better answer. The answers will be very different if we're talking about death vs if we're talking about not being able to use electricity every Shabbat vs. being vulnerable to communication outages vs. mental health burnouts. Basically I'm saying if you're asking the question, there's a scenario in play there, and the scenario can likely be planned for. Yes, Apple stock will take a diver when Steve Jobs dies or retires, but if there's a strategic plan in place for that exit, the chances of it bouncing back are vastly higher than if there is no plan. Or put another way: The New York Times has his obituary written. Do you really think the Apple board is less prepared?

antileet 16y ago
Okay, here's a more concrete example. Let's say I have around 2000-3000 regular users. If there is some family emergency which is unplanned and requires me to be there, I won't be able to maintain anything for about three-four days, except maybe make sure that the servers don't go down. I would ideally like to let the users know that there's a problem right now. Despite everything, most of them will understand. However how far do I have to go to tell them? Do I send out a little tweet, an email, or put a persistent message on the website? I know that it varies vastly according to context, but what would be a rough estimate on the best way to handle a situation like this?
- SabrinaDent 16y ago
  > I would ideally like to let the users know that there's a problem right now. For most services, there will not be - if the servers stay up, the users will never know or care that Oz is temporarily not behind the curtain. But sometimes it does matter. My husband runs a service where he needs manually process data and commit it every day that $foo is in session. If there's an emergency and he has to go offline, I can keep the servers online; if there's an emergency and we're both called away, there is a trusted 3rd party who does that job. But currently there is no other party who can process data. In that instance, we post a notice on the site saying that Friday commits will not be posted until Monday and apologise for the service interruption. I would, by the way, never make a public announcement that you are leaving the ship unmanned. That seems like a really poor security decision to me. YMMV. That's fine for a one-off, rare and unplanned instance. But you better believe that we have a much more robust plan for what to do if he gets hit by a bus. In that instance, there's a named and designated person in place to step up, an insurance policy to pay them (obviously with some delay), a secure and immediate process for transfer of passwords, and a 48 hour plan to execute. So really what I'm saying is that if you start with the worst case scenario and step back through that, I'm still not convinced that there are sudden departure scenarios you can't successfully address with forward planning.
  - antileet 16y ago
    Thanks for your suggestions. Wish you and your husband the best of luck.

antileet 16y ago

Okay, here's a more concrete example. Let's say I have around 2000-3000 regular users. If there is some family emergency which is unplanned and requires me to be there, I won't be able to maintain anything for about three-four days, except maybe make sure that the servers don't go down. I would ideally like to let the users know that there's a problem right now. Despite everything, most of them will understand. However how far do I have to go to tell them? Do I send out a little tweet, an email, or put a persistent message on the website? I know that it varies vastly according to context, but what would be a rough estimate on the best way to handle a situation like this?

SabrinaDent 16y ago
> I would ideally like to let the users know that there's a problem right now. For most services, there will not be - if the servers stay up, the users will never know or care that Oz is temporarily not behind the curtain. But sometimes it does matter. My husband runs a service where he needs manually process data and commit it every day that $foo is in session. If there's an emergency and he has to go offline, I can keep the servers online; if there's an emergency and we're both called away, there is a trusted 3rd party who does that job. But currently there is no other party who can process data. In that instance, we post a notice on the site saying that Friday commits will not be posted until Monday and apologise for the service interruption. I would, by the way, never make a public announcement that you are leaving the ship unmanned. That seems like a really poor security decision to me. YMMV. That's fine for a one-off, rare and unplanned instance. But you better believe that we have a much more robust plan for what to do if he gets hit by a bus. In that instance, there's a named and designated person in place to step up, an insurance policy to pay them (obviously with some delay), a secure and immediate process for transfer of passwords, and a 48 hour plan to execute. So really what I'm saying is that if you start with the worst case scenario and step back through that, I'm still not convinced that there are sudden departure scenarios you can't successfully address with forward planning.
- antileet 16y ago
  Thanks for your suggestions. Wish you and your husband the best of luck.