4 ms·

Do you mind sharing the long list?

by adamrt 7y ago

zxcmx 7y ago
Not O.P, but: - Encourages you to go to instances and check stuff rather than improve monitoring / health checks. - Can do quick fixes on a few boxes rather than re-running the deploy. Great! But terrible when the person who knows how to do that is away. - Tailing log files rather than centralised log management for all the things. - Trying things out / quickly checking something in production rather than being rigorous about keeping test / staging in sync with prod. The “problem” is ssh is such a great affordance (until you have tons and tons of instances and you can’t do anything by hand anymore) that it means you don’t need to fix internal processes and tools around deployment, configuration and monitoring. If there’s no workaround you feel the pain and will be forced to set things up right, usually with benefits to security and repeatability. As is often the case, the best thing about ssh (in terms of managing infra instances) is also the worst thing. With that said at very small scales it might be overkill to automate all the things so sure, fill in the gaps with ssh and a wiki page.
- KaiserPro 7y ago
  > Encourages you to go to instances and check stuff rather than improve monitoring / health checks. I don't think it does, well it doesn't when you have > 40 machines anyway. Plus it doesn't give the ability to compare and contrast simply. (graphs are _awesome_) > Tailing log files rather than centralised log management for all the things. Yes, I tend to agree. But proper centralised logging is either exceptionally hard, or a hefty splunk tax. That also encourages people to derive graphs from logs, which is arse about face. Graphs first, logs when you are desperate. > Trying things out / quickly checking something in production I can see this, but normally one would expect people to not have general access to prod, if they are going to do that...

Do you mind sharing the long list?

by adamrt 7y ago

Do you mind sharing the long list?

Not O.P, but: - Encourages you to go to instances and check stuff rather than improve monitoring / health checks. - Can do quick fixes on a few boxes rather than re-running the deploy. Great! But terrible when the person who knows how to do that is away. - Tailing log files rather than centralised log management for all the things. - Trying things out / quickly checking something in production rather than being rigorous about keeping test / staging in sync with prod. The “problem” is ssh is such a great affordance (until you have tons and tons of instances and you can’t do anything by hand anymore) that it means you don’t need to fix internal processes and tools around deployment, configuration and monitoring. If there’s no workaround you feel the pain and will be forced to set things up right, usually with benefits to security and repeatability. As is often the case, the best thing about ssh (in terms of managing infra instances) is also the worst thing. With that said at very small scales it might be overkill to automate all the things so sure, fill in the gaps with ssh and a wiki page.

KaiserPro 7y ago
> Encourages you to go to instances and check stuff rather than improve monitoring / health checks. I don't think it does, well it doesn't when you have > 40 machines anyway. Plus it doesn't give the ability to compare and contrast simply. (graphs are _awesome_) > Tailing log files rather than centralised log management for all the things. Yes, I tend to agree. But proper centralised logging is either exceptionally hard, or a hefty splunk tax. That also encourages people to derive graphs from logs, which is arse about face. Graphs first, logs when you are desperate. > Trying things out / quickly checking something in production I can see this, but normally one would expect people to not have general access to prod, if they are going to do that...