121–130 of 227 posts
Is there a more digestible version of SRE concepts somewhere? I'm just looking for an easier way to communicate core principles and concepts to my team without asking them to sink into 500 pages?
https://www.usenix.org/conference/srecon14/technical-session...
Earlier quoted context omitted.
Let me ask a clarifying question then: Is there any person who organization who is qualified to speak on security best practices?
I have personal opinions as I work in a semi-related field, but I would prefer not to disclose that information. In lieu of that, the questions I mentioned above were meant to be reasonably objective questions that would help me identify if an organization seems to be qualified in my mind without relying on reputation. Do you think any of those questions seem invalid? I tried to make them procedure agnostic to avoid…
For example, here are four statements I believe to be true:
1. Google has a track record of transparency when security is compromised.
2. Google has a better-than-average track record of detecting security intrusions.
3. Google is the target of state level actors.
4. Google has not recently publicly acknowledged any successful attacks by state level actors.
From these, one could reasonably conclude that Google is adept at rebuffing nation-state level attacks. Putting specific $$ values on things is a bit reductive, since at some point the weakest link is paying every member of the security team $100 million instead of any form of technical attack.
> If your answer is a $500 Million bug bounty is absurd, you can look at some of my other replies under my original comment for why I believe that is actually too small.
You're making a (fairly common on HN) mistake of assuming that the bug bounty value is going to be anything near the value of the compromise. If I can extract $X from a compromise, I'm not gong to pay you $X, I'm going to pay you $Y, which is less than $X, and probably much less than $X. The market for compromises isn't enormous, so it may not even be possible for you to sell your compromise to anyone but me. So then if you turn to the bug-bounty offering company and try to sell your compromise for $Y, you're committing blackmail, so the companies offer $Z, So yes, I think you have deep misunderstandings of the state of the security industry and those are miscoloring your mental models.
> If it can not be done safely, then it should not be done at all no matter how hard you try if human lives are involved.
This is blatantly ridiculous. Risk can't be fully mitigated, and most systems aren't life critical. You're jumping from "a bank was hacked and people's personal information disclosed" to "this kills those people", which isn't a reasonable jump.
I actually can't believe that someone's response to "are there people capable of speaking on software security" is "we shouldn't attempt to build secure software, because it's too hard".
Earlier quoted context omitted.
Indeed I am. Would you trust the contents of a book on a technical topic if the authors are not, in fact, subject matter experts? Would you read a book on cancer treatment by a doctor of theology with no medical training? To use a less egregious example, a neurologist with no training in oncology or experience with brain cancer? Knowing the expertise of the authors is very important, especially if you are not a subje…
But why this unusual level of scrutiny? The book is published and endorsed by both Google and O'Reilly, two of the most respected brands in this domain. Why are they not a satisfactory "third or first-party confirmation of expertise" but random commenters on Hacker News would be?
As for random commenters, since I can not use the reputational apparatus for information, I would need to get direct information. There are likely people here who work with the stated individuals, so there is a non-zero chance I could get that information. Hopefully random commenters would not lie for no reason, but to deal with that I avoid incorporating information that can not be cross-referenced.
Any tips for the vast majority of SRE groups where people are paid a fraction of google employees and never given any time to fix things?
High pay is great, but doesn't make better software. Do Googlers get time to fix things?
In the parts of Google I've seen, engineers are largely given projects with a timeline of weeks or months and left to structure their time themselves. You're usually given more projects than can feasibly be accomplished in the time allotted, and learning which are high priority and which to let slide a quarter is a bit of an art, but as long as your projects are moving forward you can usually structure some time for paying down tech debt or a side project, either an official 20% or just experimenting with your area of responsibility outside any roadmaps.
I tend to structure my weeks with Tuesday as the designated day to fix anything that's broken or, if everything is running smoothly, to pay down tech debt more for the opposite reason, so that I don't get caught in a rabbit-hole of fixing things that aren't broken and neglect to make progress on the new work.
Any tips for the vast majority of SRE groups where people are paid a fraction of google employees and never given any time to fix things?
High pay is great, but doesn't make better software. Do Googlers get time to fix things?
Given that the usual ration is 100% : -100%, 50:50 is going to be helpful in escaping capability traps.
Earlier quoted context omitted.
Great question. As an O'Reilly author myself, I can tell you that we have no control over the animal selected. There's a fun animal selection process, but the publisher's decide. Disclaimer - I work for Google and worked on this book.
Hey, at least you didn’t get Cthulhu on the cover, like Andrew Lombardi’s WebSocket .
Earlier quoted context omitted.
It's not as applicable to startups as you would think. The real calculation startups are making all of the time that this book doesn't mention is "is it worth making this particular piece scale/secure/robust before we run out of money?" While it's technically true that the advice would apply to startups in the sense that it would improve their reliability, the elephant in the room is that it doesn't matter. The engin…
The "is it doing X before we run out of money?" question is way overblown in startup land, usually by product people to skew developer time towards more features instead of much needed foundational work. In reality, this question is almost always instantly answerable. You're either still building out your MVP and desperately need customers to validate your idea, in which case the answer is "No", or you're an establis…
Earlier quoted context omitted.
We were very much aware that not all companies can afford to staff a dedicated security team. We tried to do our best to make sure that the book is applicable to a wider audience: from startups, to big corporations. (disclaimer: I work at Google)
It's not as applicable to startups as you would think. The real calculation startups are making all of the time that this book doesn't mention is "is it worth making this particular piece scale/secure/robust before we run out of money?" While it's technically true that the advice would apply to startups in the sense that it would improve their reliability, the elephant in the room is that it doesn't matter. The engin…
Is there a more digestible version of SRE concepts somewhere? I'm just looking for an easier way to communicate core principles and concepts to my team without asking them to sink into 500 pages?
The books read quite easy. The first book is just stories from google; it doesn’t really prescribe anything- it’s a collection of people talking about what SRE means to them and also how it fits together with “devops”. The second book (the SRE workbook) is more prescriptive, walks through practical ways of implementing it. The most base description of SRE principles is simply that: 1) You automate aggressively and de…