https://www.jianshu.com/p/ba61020aeb1e
在看到《Google系统架构解密：构建安全可靠的系统》这本书之前，个人就有安全和可靠性不分家的观念。看到有同样想法的书籍，甚是欢喜。读完上一本书，终于可以读这一本了，接下来很长一段时间，看下Google是如何构建安全可靠系统的。
备注：可靠性除了和安全不分家之外，也和性能，基本功能等带有不稳定因素的都有关。不要给可靠性设定边界，去探索吧。
Google之前提出来站点可靠工程SRE(Site Reliability Engineering)，有两本书《SRE：Google 运维解密》与《Google SRE 工作手册》，感兴趣的可以看下。此次，Google 把重点聚焦在安全主题上，并将可靠性和安全性深度结合，总结出了一套有效的方法。在传统运维模式中，开发、运维和安全团队彼此独立，往往因关注重点不同而产生矛盾，从而难以协调和实现业务安全快速发展。而 SRE 则不同，其理念旨在消除团队间的冲突，将 Dev、Sec 和 Ops 真正融为一体，打造成一个统一的 SRE 团队，而且 SRE 和研发团队之间的成员可以自由流动。
先对SRE 和 SRS这两个工种有个印象，我感觉自己又多了一个职业发展方向，目前看应该是可以胜任的。
安全可靠系统SRS(Secure and Reliable Systems)在原有的SRE上整合了安全流程，即把安全嵌入研发测试运维流程。
SRE 和 SRS都非常依赖于传统的软件工程团队，但又跟传统软件工程团队有质的不同：
1) 网站可靠性工程师与安全工程师倾向于认为破坏、修复与构建一样重要；
2) 他们的工作除了开发，还有运维；
3) 与传统软件工程师不同，网站可靠性工程师和安全工程师都是专家；
4) 他们通常被视为障碍，而不是推动者；
5) 他们通常是独立的，并不整合在产品团队中。
与安全工程师类似，SRE带来了一项专门的工种及一系列工作职责，需要从业者具备特定的技能。SRE还创造了连接不同团队的实现模型，这似乎是安全社区下一步要采纳的。
SRE 是解决可靠性问题的一流方案，并且在实时检测和响应技术问题（包括特权访问和敏感数据的安全攻击）上也发挥了作用。虽然工程师团队通常根据专业技能来区分角色，但他们有一个共同的目标：确保系统或应用程序的质量和安全性。
无论是网站可靠性工程还是安全性工程，其核心关注点都是保持系统可用。发布失败、容量不足和配置错误等事件都可能让系统不可用（至少在短期内不可用）。安全性或隐私事件会破坏用户的信任，也会削弱系统的实用性。因此，系统安全是网站可靠性工程师的头等大事。