×

扫描二维码登录本站

QQ登录

只需一步,快速开始

SRE认证培训的问题难点

标签: 暂无标签
SRE不是做底层硬件维护,而是负责各种服务的性能和稳定性。远离底层硬件,更多靠近软件基础架构层面,帮助企业客户打造强大的软件基础构架。
涉及的范围呢:代码管理和部署,配置管理,监控,应急响应,故障处理,压力测试,容灾等等

Devops的核心概念就是通过脚本实现自动化 -> Automation。现在有一个新的概念叫做NoOps,目的是实现自主运维,系统自动发现并解决问题,完全不再需要自动化脚本 -> Autonomy 。传统运维将死,不会写代码的都该失业了...

容量规划与实施:
要回答两个基本问题:要支持每秒 X 个请求的流量,需要多少台机器?给你 Y 台机器,如何部署服务栈(serving stack)使其服务容量(capacity)最大,即每秒支持的请求数最多。serving stack 由很多服务程序(server)构成,各个 server 有各自的资源需求(每个进程用多少内存,多少CPU)。每个 server 有多个 replica,我们要算出各个 server 的 replica 的合理数目,让计算资源得到充分利用。SRE 开发了专门的工具来做这件事件,因为我们不想对全球多个数据中心都分别手算一遍。 server 的性能会随时间变化(新版本通常会变慢,因为加了更多的功能),我们要及时调整 replica 的数目。每个 server 的性能变化不一样,replica 的数目要“配平”。

部署新的服务集群(serving cluster)
每年都有新的数据中心(Data Center)上线,也有旧的数据中心下线,那么我们的 serving stack 也会跟着迁移。“部署”不是去机房安装机器,实际上工作这么多年,我一次也没有见过跑我写的服务程序的机器。新的数据中心通常会有新一代的硬件,我们的容量规划工具要能适应多种的硬件类型(CPU 数目、内存大小)。

冗余与容错
在 Google,我们有数据中心级别的容错,任何一个数据中心可以随时下线维护,对外服务不受影响。进一步说,我们的容量规划要做到允许两个数据中心同时下线。比方说某个数据中心正在例行下线维护,这时另外一个数据中心受突发事件影响必须立刻下线,那么我们的系统还要能正常提供服务。

负载均衡
《SRE》第 19、20 章。

上线新的服务(on-boarding service)
《SRE》第 32 章。

监控(Monitoring)
不是一天到晚盯着 dashboard 看,而是编写合适的监控与报警规则,让我们能快速找到故障根源。几个最基本的监控指标:流量 traffic, eg. queries per second  延迟 latency  错误率 error ratio  资源使用率 utilization
见《SRE》第 6 章。

值班(on-call)
这其实是最少的工作,如果一个 SRE 团队有 8 个人,每人每次值班一周,那么平均 2 个月才轮到一次,占 1/8 的工作量。值班的时候,如果没有突发事件,还是该干嘛干嘛。而且 Google SRE 是全球团队,不用值夜班,到了下午把工作交接给地球另一边的同事就行了。见《SRE》第 11 章。

救火(Firefighting)
这是 SRE 最刺激的工作内容,见《SRE》第 12~15 章。

SRE 不是什么
SRE 不在数据中心上班,不搬机器。
SRE 不是系统管理员,不会帮你重置用户密码,也不安装操作系统或升级安全补丁。
SRE 不是测试工程师,不管持续集成和发布新版本。
SRE 不是运维,不过我其实不了解国内的运维具体是做什么的。





上一篇:SRE Foundation知识点
下一篇:如何成为一个合格的SRE
admin

写了 833 篇文章,拥有财富 28305,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部