【读书活动感悟分享】《SRE Google运维解密》第四章与第五章读书心得

第四章的主要内容是对于服务质量的说明，在书中主要用三个术语来描述这个内容：

• SLI：服务质量指标，指的是服务某项质量的具体量化指标，如请求延迟、错误率、系统吞吐量、可用性、持久性等
• SLO：服务质量目标，是服务某个 SLI 的目标值或目标范围。
• SLA：服务质量协议，是服务与用户之间明确或不明确的协议，描述了达到或未达到 SLO 后的后果，如财务方面的退款或罚款等。

因为SLA涉及到协议，所以平时说的SLA大部分实际指的是SLO，即服务质量的目标。

文章中提到了需要注重指标的数据收集工作，并且多注重分布而不是只关注绝对值，就相当于目前SG和HSF监控中使用到的P99、P90统计数据等。

“响应时间的分布越分散，意味着普通用户受到长尾请求延迟的影响就越明显”，个人理解可能指的是由于部分请求响应慢，高负载情况下会有越来越多的资源用于处理慢请求，导致系统请求出现排队。所以需要重点关注P99的数据。

第五章的内容是减少琐事。

• 琐事的定义是：手动的、重复的、可自动化的、战术性且没有持久价值的工作，跟服务有线性关系
• 工程工作的定义：新的、需要主观判断的、符合长期战略的、能对于服务进行长久性改善的，具有创想和创造性，通过设计解决问题，越通用越好。

书中总结了SRE的典型工作：

• 软件工程：编写代码
• 系统工程：架构、设计、咨询、配置系统、书写文档等
• 琐事：运维相关重复的手工工作
• 流程负担：各种行政工作，包括招聘、工作汇报、会议、总结、评价、培训等

前两个属于工程性工作，后两个就不是工程性工作。最好能有50%花在工程性工作上。

在一般的职场人认知中，"抱怨"通常并不是个褒义词，但是在本书中有个描述"琐事过多需要主动抱怨"，这个强调发现有琐事影响工程时间的投入了要主动提出，工程性的工作是为了未来的发展，对此国内外都有精辟的描述，国内讲的是“磨刀不误砍柴工”，国外总结四象限工作法，工程性工作在此可以归属于“重要但不紧急”的工作，不能总是让位于“不重要但是紧急”的琐事。

结合目前特来电云平台的工作现状，在工作中感受比较明显的一点是：琐事并不会自然消失。琐事需要我们从事工程性工作岗位的人主动“对抗”，应该“非常担忧，大声抱怨”。《架构整洁之道》书中Bob 大叔曾经提出过一种观点：一个软件系统的价值应当由两部分组成：业务价值和架构价值。业务价值是显性的，可见的，而架构价值往往是被忽略的。如若不特意纠正，两者的发展曲线将是互斥的。即随着业务的增长，架构价值将逐渐归零(结果是研发投入大于业务收入)。如果架构价值持续下滑，不可避免得导致琐事的增加。琐事恰恰是众多架构价值减分项中，最容易被解决的部分，因此从琐事入手，分析架构下滑的原因并解决，积极主动地与业务部门"对抗"为"重要不紧急"的琐事优化争取机会，既是SRE岗位的工作需求，也是架构师们的工作重点。

前一段时间大家一起整理的《技术债》列表就是个非常好的实践工作，在列举技术债的时候，我们往往从日常运维出发，思考有什么工作是需要经常运维的，这些工作有没有什么好的办法可以通过研发新的功能来解决，这就是有意识地以“工程性”工作来解决“琐事”，也是主动地在提升整个系统的架构价值。