|
|
|
|
|
|
by KirinDave
898 days ago
|
|
|
For one, that "deprioritize a competitor" is not clear at all. Why would that be so? Isn't it far more likely, given the rarity of these events, that a test regression occurred or some other subtle issue rather than assumed malfeasance? For two, that "next update in 12 hours" is user comms. For me, at least, google.com works fine both on curl and my browser. That's a fairly normal cadence for big companies. On the larger point about "nimble and deploying rapidly", the people who generally brag about "being nimble and deploying rapidly" almost never serve an even 1/100th the audience the size of Google.com does, and it's really questionable if, at that scale, you actually want to risk global regressions even on trivial bugs. So I don't know what that user is talking about, and I agree with you that they are obviously not that. That approach may be antithetical to the modern startup engineer frantic to prove their stock's hypothetical worth to their investors, unconcerned about trivial revenue loss from frontpage issues because of whatever latest node.js drama nuked their continuously deployed website. But the fact that "the landing search page is broken for 1% of users in a rare but public use case" is news at all is because Google's approach for search sets our expectations that this won't happen. |
|
|
I remember an internal mantra in Google along the lines of "if you break something in production, roll back first, ask questions about how it happened later, even if you think it's a simple fix". It feels telling that this is not what is happening in this circumstance.