1 规模效应业务越庞大，服务器就越多，服务越多，就越需要拆分成分布式架构。架构越复杂，对运维的能力要求就越高、出错的概率就越大，运维的工作量就越大。因此就要更多开发提升效率的工具。
而在小企业，业务没有那么庞大，公司没有能力也不需要sre，只需要几个初级的linux系统管理员，做些手动的操作就可。
所以，sre在小企业是无法诞生的，因为没有起因。
2 SRE出身2.1 做什么软件工程师专注于软件系统的设计和实现。
需要另一个职业，专注于软件系统在整个生命周期中的保持稳定运行、发现问题，和软件工程师沟通甚至参与、约束他们的开发，以改进整个软件系统。
这个职业，google称之为站点可靠性工程师（SRE）。
他们要做什么？
1 参与软件系统的设计和改进，防止他们开发一些很容易在基础架构层面出bug的东西。
2 开发运维平台，比如软件工程师设计组件状态抛出接口，SRE从接口拉取数据并设计组件运行状态图表。
3 强化软件系统可靠性。比如所有组件的监控以及自动化反应、处理任何潜在的性能瓶颈。
2.2 会什么1 传统运维技能
2 用软件技术自动化手动运维操作的开发能力
3 懂开发人员的部分技术
2.3 前身1 运维学开发
2 开发学运维
2.4 工作目标单元部署、业务变更、故障处理也许都是手动操作的，这些工作也许花掉了运维很多时间。
第一步，就是保证足够的时间来编程，自动化某些人工流程。
第二步，继续编程，开发详尽的监控功能，并使程序能自动处理故障。
第n步，还是编程，以消灭所有人为操作为目标。
然后把web界面直接开放给运营或者开发，让他们自己去部署。这样应用运维就可以从部署中解放出来。
3 可靠性用户不满意服务，就意味着玩家流失，就意味着业务的估值下降。
考虑几个问题
1 我现在的业务，在用户的使用习惯中，可靠性要达到多少才算满意？
2 在业务运行的过程中，哪些不完善的机制导致了业务出现问题，如何才能在机制层面解决这些问题？
3 可靠性、人力成本和设备成本之间的平衡点在哪？
4 错误预算：运维的目标不是保证100%的可靠性，多少量的生产事故是可接受的？我需要设定目标。
4 监控系统一个系统不可能不出故障，重点是可以快速定位故障，快速解决故障。所以需要监控系统。监控系统是保证系统可靠性的核心手段之一。
主要有几类监控
1 可以自动化分析处理的，属于可预见、既定方案的
2 需要人工参与处理的，属于不可预见，没有既定方案的
转播
分享
淘帖
()