4 ms·

For example, a Server's: - disk fails (ZFS with hot spares) - power supply fails (each server has two) - someone cut the power (there's another server) ---

For example, a Server's: - disk fails (ZFS with hot spares) - power supply fails (each server has two) - someone cut the power (there's another server) --- Most issues will be caused by me, so the general answer is don't leave before testing.

devKnight 4y ago
Not a solo founder, but this is a huge part of it. Do not deploy changes to code or architecture unless you CAN be on call to fix what breaks.
- patiiipot_ 4y ago
  Yes. As a founder, I'll have to witness it first to make sure that I get responsibility for what happened. It's not that I don't trust them. I just don't want to blame people in my workplace. My peers from Founders Cafe helped me create a strategy for this. https://founderscafe.io/ https://founderscafe.io/
leros 4y ago
Do you not worry about something breaking even with an older deploy? Random things happen.
- efortis 4y ago
  I don't worry about random things.
- Matthias247 4y ago
  Yes, e.g. hardware of hosts breaking, datacenters getting disconnected, etc. I'm not a solo founder, but if I would be I would most likely pick a solution where I would have to maintain the least amount of infrastructure (e.g. using SAAS/FAAS offerings). That would mean in most cases someone else gets paged if things break. Still doesn't guarantee 100% availability since it can't prevent code bugs from doing bad things, but there would be still less things to worry about.
  - leros 4y ago
    This is my take. I build products that have the critical infrastructure be fairly simple and hosted completely on third party systems. The most custom part of my system is just the customer portal, which can go down without impacting the core product functionality.
  - patiiipot_ 4y ago
    My team from Founders Cafe told me to create a strategy, kind of like a flowchart of what to do in case I'm not on call when there is a problem. I give them to my employees/freelancers. As soon as I am available, I'll check the conditions of the workplace first thing in the morning.

devKnight 4y ago

Not a solo founder, but this is a huge part of it. Do not deploy changes to code or architecture unless you CAN be on call to fix what breaks.

patiiipot_ 4y ago
Yes. As a founder, I'll have to witness it first to make sure that I get responsibility for what happened. It's not that I don't trust them. I just don't want to blame people in my workplace. My peers from Founders Cafe helped me create a strategy for this. https://founderscafe.io/ https://founderscafe.io/

leros 4y ago

Do you not worry about something breaking even with an older deploy? Random things happen.

efortis 4y ago
I don't worry about random things.
Matthias247 4y ago
Yes, e.g. hardware of hosts breaking, datacenters getting disconnected, etc. I'm not a solo founder, but if I would be I would most likely pick a solution where I would have to maintain the least amount of infrastructure (e.g. using SAAS/FAAS offerings). That would mean in most cases someone else gets paged if things break. Still doesn't guarantee 100% availability since it can't prevent code bugs from doing bad things, but there would be still less things to worry about.
- leros 4y ago
  This is my take. I build products that have the critical infrastructure be fairly simple and hosted completely on third party systems. The most custom part of my system is just the customer portal, which can go down without impacting the core product functionality.
- patiiipot_ 4y ago
  My team from Founders Cafe told me to create a strategy, kind of like a flowchart of what to do in case I'm not on call when there is a problem. I give them to my employees/freelancers. As soon as I am available, I'll check the conditions of the workplace first thing in the morning.