21–30 of 86 posts
This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."
These distinctions started making more sense when I realize they map to OKRs which is generally how Google is said to track individual and team performance. In general, it's good to be precise about how you measure and when something is a hard or soft boundary. Otherwise, firefighting gets out of control. It's hard to determine when to stop something and put out a fire if you can't prioritize issues based on the boun…
This is an interesting article from a company that has almost nil customer support.
This never gets old. It's almost as predictable as some random reference to "don't be evil".
This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."
Isn't that one of the reasons for Netflix' chaos monkey? To make sure no one thinks "my dependency will always be there"?
These distinctions started making more sense when I realize they map to OKRs which is generally how Google is said to track individual and team performance. In general, it's good to be precise about how you measure and when something is a hard or soft boundary. Otherwise, firefighting gets out of control. It's hard to determine when to stop something and put out a fire if you can't prioritize issues based on the boun…
SLOs certainly don't rigidly map to OKRs. Maybe it's easier to consider them (two sided) commitments about the quality of service? They're more of an ongoing measure of quality rather than a quarterly objective.
Depending on the situation, I have seen teams aim to achieve certain SLOs but it can also be that certain other things can be achieved without letting the SLOs suffer (if they're already at a reasonably high quality).
Earlier quoted context omitted.
From the movie The Negotiator: A Marine and a sailor are taking a piss. The Marine goes to leave without washing up. The sailor says, 'In the Navy they teach us to wash our hands.' The Marine turns to him and says 'in the Marines they teach us not to piss on our hands'. BTW it's not true that Google has almost nil customer support. There's extensive support for paying customers (for ads, GCP, GSuite etc.). But it's a…
The joke in that scene always baffled me, because the Marines are born of the Navy and still carry a lot of the Navy's epistemology-why would they be taught something so fundamental so differently? (Yes it's a joke but sometimes I overthink things, heh)
Relatedly, in case you don’t know this, never think you can call a marine a sailor based on the lineage you’re discussing here. Soldier is also only an appropriate term for someone in the Army, and there are countless films that screw this up. It’s less about the service and more of an identity.
This is an interesting article from a company that has almost nil customer support.
- fantastic support internally (probably not what you're caring about),
- support to external globally-scaled customers whose issues don't exist because technical account management helped set up clear goals, such as uptime, described in the blog (probably also not what you're counting)
- support for even the smallest companies willing to pay as little as $100/user/month for Role-Based Support[1] and also receive direct access to support until they decide it's no longer needed (and by design, scale support costs to zero)
This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."
This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."
New services may be launched with provisional technology to establish or evaluate a market or pricing model. The underlying technology in the initial implementation may have different performance or availability characteristics to what's actually envisioned for the full-scale product, and care has to be taken to actually compensate for this - i.e. introducing synthetic delay/jitter/faults to avoid setting the wrong expectation for the product.
This is an interesting article from a company that has almost nil customer support.