2 ms·

I wish this article was at most a quarter of its current length. Preferably even shorter. There's so much self-congratulatory and empty talk, it's really hard

I wish this article was at most a quarter of its current length. Preferably even shorter. There's so much self-congratulatory and empty talk, it's really hard to get to the main point. I think, the most important (and actually valuable) part is the mention of the work done by someone else (STPA and CAST). That's all there is to the article. Read about Causal Analysis based on Systems Theory (CAST) and System-Theoretic Process Analysis (STPA) do what the book says.

anal_reactor 2y ago
Agreed that the whole article could've been much shorter. Anyway, for me the key takeaway is not to trust your inputs. It's true that code correctness often boils down to "given input X, the program will correctly give output Y", but the actual issue is that sometimes the input X itself might be wrong. I think it's clearly visible in project management, where people tell you one thing, you plan accordingly, then later they do another thing, and if you haven't predicted this, you're done. If this behavior is so common in human projects in general, I see no reason why it wouldn't emerge in software projects too. The problem is, software that tries to do something smart with inputs is much harder to reason about, which in turn increases your likelihood of failure, which is exactly the thing you wanted to avoid in the first place. For example, imagine you have an edge case in your script where you want to perform "rm -rf /" but the safety mechanism prevents you from doing this, which effectively makes your script fail. In conclusion, in my humble opinion, the most important part of safety is choosing tools that are simplest to reason about. If you have a bash script you're guaranteed to have some bug related to some edge case - people managing POSIX realized that bash is so fundamentally broken that it's better to forbid certain filenames rather than fix bash. Use a Python library for 10x the safety but half the comfort. If you have a C++ program it will leak memory no matter how hard you try. And so on. Similarly, when writing programs, you should give simple and strong promises about its API. Don't ever do "program accepts most sensible date strings and tries to parse that", do "it's either this specific format or an error". Verifying inputs and being smart about them is a good idea that should be used carefully because it can backfire spectacularly.
herodoturtle 2y ago
Came here to say this. It’s not the first article / publication on Google SRE I’ve read, and they’re all similarly (and imho unnecessarily) verbose. Whilst I’m deeply grateful to the good folks at Google for sharing their hard-earned knowledge with us, I do wish their publications on this important topic were far more succinct.

anal_reactor 2y ago

Agreed that the whole article could've been much shorter. Anyway, for me the key takeaway is not to trust your inputs. It's true that code correctness often boils down to "given input X, the program will correctly give output Y", but the actual issue is that sometimes the input X itself might be wrong. I think it's clearly visible in project management, where people tell you one thing, you plan accordingly, then later they do another thing, and if you haven't predicted this, you're done. If this behavior is so common in human projects in general, I see no reason why it wouldn't emerge in software projects too. The problem is, software that tries to do something smart with inputs is much harder to reason about, which in turn increases your likelihood of failure, which is exactly the thing you wanted to avoid in the first place. For example, imagine you have an edge case in your script where you want to perform "rm -rf /" but the safety mechanism prevents you from doing this, which effectively makes your script fail. In conclusion, in my humble opinion, the most important part of safety is choosing tools that are simplest to reason about. If you have a bash script you're guaranteed to have some bug related to some edge case - people managing POSIX realized that bash is so fundamentally broken that it's better to forbid certain filenames rather than fix bash. Use a Python library for 10x the safety but half the comfort. If you have a C++ program it will leak memory no matter how hard you try. And so on. Similarly, when writing programs, you should give simple and strong promises about its API. Don't ever do "program accepts most sensible date strings and tries to parse that", do "it's either this specific format or an error". Verifying inputs and being smart about them is a good idea that should be used carefully because it can backfire spectacularly.

herodoturtle 2y ago

Came here to say this. It’s not the first article / publication on Google SRE I’ve read, and they’re all similarly (and imho unnecessarily) verbose. Whilst I’m deeply grateful to the good folks at Google for sharing their hard-earned knowledge with us, I do wish their publications on this important topic were far more succinct.