读书笔记（SRE：Google运维解密）：第5章 减少琐事

• 如果系统正常运转中需要人工干预，应该将此视为一种Bug。
   
• 到底什么是琐事？琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。而且，琐事与服务呈线性关系的增长。每件琐事都满足下列一个或多个属性：
  （a）手动性：手动运行脚本以便自动执行一些任务
  （b）不停反复做的工作。如果你正在解决一个新出现的问题或者寻求一种新的解决办法，不算作琐事。
  （c）可以被自动化的
  （d）战术性的：突然出现的、应对式的工作，而非策略驱动和主动安排的。处理紧急警报是琐事。我们可能永远无法完全消除这种类型的工作，但我们必须继续努力减少它。
  （e）没有持久价值：
  （f）与服务同步线性增长：如果在工作中所涉及的任务与服务的大小、流量或用户数量呈线性增长关系，那这项任务可能属于琐事。一个良好管理和设计的服务应该至少可以应对一个数量级的增长，而不需要某些一次性工作（例如增加资源）之外的额外工作
   
• 为什么琐事越少越好?SRE至少花50%的时间在工程项目上，以减少未来的琐事或增加服务功能。增加服务功能包括提高可靠性、性能，或利用率，同时也会进一步消除琐事。
   
• 什么算作工程工作?
  是一种新颖的、本质上需要主观判断的工作。它是符合长期战略的，会对你的服务进行长久性的改善的工作。工程工作通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好。工程工作有助于使该团队或是整个SRE组织在维持同等人员配备的情况下接手更大或者更多的服务。
   
• 典型的SRE活动分为如下几类：
  （a）软件工程：编写或修改代码，以及所有其他相关的设计和文档工作。例如，编写自动化脚本，创造工具或框架，增加可扩展性和可靠性的服务功能，或修改基础设施代码以使其更稳健。
  （b）系统工程：配置生产系统、修改现存配置，或者用一种通过一次性工作产生持久的改进的方法来书写系统文档。例如，监控的部署和更新、负载均衡的配置、服务器配置、操作系统的参数调整和负载均衡器的部署。系统工程还包括与研发团队进行的架构、设计和生产环境方面的咨询工作。
  （c）琐事：与运维服务相关的重复性的、手工的劳动。
  （d）流程负担：与运维服务不直接相关的行政工作。例如招聘、人力资源书面工作、团队/公司会议、任务系统的定期清理工作、工作总结、同行评价和自我评价，以及培训课程等。
   
• 琐事有害的原因中，有如下因素需要考虑：
  （a）职业停滞：花在工程项目上的时间太少，你的职业发展会变慢，甚至停滞
  （b）士气低落：过多的琐事会导致过度劳累、厌倦和不满
   
• 牺牲工程实践而做琐事会对SRE组织的整体发展造成损害，原因如下：
  （a）造成误解：努力确保每个SRE以及每个与SRE一起工作的人都理解SRE是一个工程组织。
  （b）进展缓慢：琐事过多会导致团队生产力下降
  （c）开创先例：如果SRE过于愿意承担琐事，研发同事就更倾向于加入更多的琐事，有时候甚至将本来应该由研发团队承担的运维工作转给SRE来承担。其他团队也会开始指望SRE接受这样的工作，这显然是不好的。
  （d）促进摩擦产生：即使你个人对琐事没有怨言，你现在的或未来的队友可能会很不开心。如果团队中引入了太多的琐事，其实就是在鼓励团队里最好的工程师开始寻找其他地方提供的更有价值的工作。
  （e）违反承诺：那些为了项目工程工作而新入职的员工，以及转入SRE的老员工会有被欺骗的感觉，这非常不利于公司的士气。