21–30 of 32 posts
> "At this point, the engineers in Australia decided that a brute-force approach to their safe problem was warranted and applied a power drill to the task. An hour later, the safe was open—but even the newly retrieved cards triggered the same error message." What happened here (from what I recall) was far funnier than this does it credit. The SREs first attempted to use a mallet (hammer) on the safe (which they had t…
I don't know anything about Google but I glean this Password Manager service was of low importance and was shared by employees. I'm thinking this would've been a non issue with a low tech solution like a shared document of passwords and services or a wiki page, and by virtue of being hosted on a more common platform would benefit from a better SLA.
> restart required a hardware security module (HSM) smart card. Out of curiosity, does anyone know why? My guess would be the PW DB would be encrypted with some token generated from this card. I've had lots of "I have a secret and the server needs it" type problems but I've never been very happy with my solutions- smart cards seem like potentially an elegant solution.
For a 'best effort' hosted internal service, this is not a good choice.
> It took an additional hour for the team to realize that the green light on the smart card reader did not, in fact, indicate that the card had been inserted correctly. I'm not sure which is worse: bad UI/UX use of lights, or inadequately trained engineers who misunderstood the lights.
- Storing the safes password - which is required for the password manager to start - ... in this very same password manager? - Failing at trying to insert the card in multiple ways into the card reader (it's like USB, you're using it the wrong way around). I would have tried that before (while?) drilling the safe. - Having no clue (no documentation) how to restart the service, despite it having passwords in it? If passwords are lost, all encrypted stuff is lost, forever.
If there's one thing I think is central to document personal or corporate), it is how to get accesss to passwords _fast and reliable_ whenever there's a disaster recovery.
Wonderful. Anyone read the full book? Is it all this good? :-)
The book is very much designed for Google-scale systems, though: everything is assumed to be microservices, for example.
> It took an additional hour for the team to realize that the green light on the smart card reader did not, in fact, indicate that the card had been inserted correctly. I'm not sure which is worse: bad UI/UX use of lights, or inadequately trained engineers who misunderstood the lights.
I'd go with bad UI/UX. A lot of progress has been made by acknowledging that people are idiots and that the system has to work around that. Toyota, which went from one of the worst to one the most reliable automaker is known for formalizing idiot-proofing. If the reader was able to read the card both way, there wouldn't have been a problem and no training required. The next best thing would be for the card to not fit…
I have done it lots of times! With machines where you just dip the tip, you're bound to put the side with the chip in, but most machines want it facing up, and some want it the other way. The iconography is only illustrative once you've messed it up at those machines enough times (around me, Walgreens has difficult machines). Readers where you insert the whole card are easier to mess up, too.
> If the reader was able to read the card both way, there wouldn't have been a problem and no training required. The next best thing would be for the card to not fit upside down. Or have a clear message "try flipping the card". It is not something you should train people for, it should be obvious.
I suspect the HSM was an off the shelf component. The real issue with training is that a system with a complex startup procedure hadn't been restarted in 5 years. You should rehearse complex procedures at least once a year, otherwise there's a good chance nobody with experience has done it. Also, maybe someone would have flagged the issue of needing the cards to start the system than grants access to the cards. (Although drill + 1 hour is a reasonable recovery procedure that was obvious and didn't need training, apparently)
> It took an additional hour for the team to realize that the green light on the smart card reader did not, in fact, indicate that the card had been inserted correctly. I'm not sure which is worse: bad UI/UX use of lights, or inadequately trained engineers who misunderstood the lights.
I would say of all companies that have great SRE, I would not have expected Google to be one of them were this process was so brutaly flawed: - Storing the safes password - which is required for the password manager to start - ... in this very same password manager? - Failing at trying to insert the card in multiple ways into the card reader (it's like USB, you're using it the wrong way around). I would have tried th…
You're underestimating the amount of goodwill-run, unstaffed projects that any big corporation accrues over time, which accidentally become load bearing without anyone realizing until something goes wrong. Such unstaffed projects are usually very stable (from not having pressure to add features or earn profit) and therefore "just work" for years until something unusual, like an accidental DDoS, happens. In that time, the original author(s) and everyone with context have left the company. This is a very hard process/human problem to solve at FAANG scale.
Not too long ago here on HN, a user was saying they were locked out of their accounts because A required B, but B required C, and C required A.
Sorry for the offtopic comment, but it's bizarre to me that Google is hosting their book on Github with a github.io domain. Their previous two SRE books are hosted at https://sre.google on Google-owned IPs.[0] What was that decision process? "We're Google, and we're literally writing a book about how good we are at hosting services. But hosting some static HTML files that are almost entirely text? That's a tough one.…
It seems this github.io URL is more like a CI run of the book, and the one on sre.google is the "published" one.