SRE读书笔记-SRE方法论(未完待续)

介绍

在读《SRE-google运维解密》总会不自觉的代入到现有的运维环境来思考，对比两种模式的差异，方法论如果不落地，永远是方法论，好的方法本土化，最终落地，才是好方法！

引用中，是作者的一些经验想法，如果有谬误和片面的地方，请指正！

系统管理员模式

SRE认为IT部门分为DEV和OPS，属于系统管理员模式，优势是招聘相对容易，还有集成厂商各种开源的、不开源的运维工具帮助运维团结进行业务运维工作，而这种模式也从在以下2个问题：

1. 直接成本。随着业务复杂度、系统规模、部署规模的扩大，团队的大小基本与系统负载成线性相关，共同增长。
2. 间接成本。因工作目标、可靠性理解的差异、危险评估等分析差异，导致两个团队在目标和方向上的分歧。

1.国内IT团队实施devops这种模式，注重的敏捷、精益、持续集成、持续交付，dev是业务开发，ops是运维，通过协作的方式，打通dev到ops之间的墙，从而实现向业务快速交付价值。
2.业务访问、规模、复杂度上升导致运维成本上升是必然的，努力的方向是让上升趋势放缓。
3.SRE需要一边开发业务系统，然后有高级运维的技能和意识，国内应该很罕见。
4. 开发与运维两个团队在目标和方向上的分歧，其实是能力上的问题，无法界定风险、无法降低风险、无法承担风险、有时候其实是技术问题。在没有能力支撑的时候，什么都有风险的…

google的解决之道 SRE

SRE-Site Reliability Engineer (网站可靠性工程师)，由一个职位，发展成一套技术模型、指导思想、方法论等。SRE团队中有一半成员是专业的开发、一半成员是专业的开发还同时掌握其他技术能力的工程师。SRE工程师50%时间做传统运维工作、50%时间进行开发工作，终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。SRE团队之前和研发团队之前的成员可以自由流动，普通的开发都可以参与大规模运维活动中。

1.一个公司的业务活动是，是为了更快速的占领市场，实现现金流的快速回笼，而目标快速为业务交付价值的devops工作流，则正好满足这一点，互联网公司的选择偏向就很明显。
2.之所以所学SRE，除了吸收其中的精华拿来使用，换一个思考方向，运维其实也是一种产品，同样为业务交付价值，当运维系统变得庞大时，我们如何保证自己的系统的稳定，如果连运维系统都无法保证可靠性，又如何去保证业务系统的可靠性。
3.运维开发和运维，如果团队管理的不协调，也是会存在一堵墙，老司机们应该都知道的。
4.运维团队正在逐步向全团队运维开发转变着。

未完待续