《监控运维实践：原则与策略》读书笔记

• 监控不是一个单一问题，无法通过某一个工具来解决

  + 如果想在代码级别分析并监控应用程序，你可能需要 APM 工具，或者自行测量应用程序（例如，通过 StatsD）。
  + 如果需要监控云基础设施的性能，你需要寻找现代化的服务器监控解决方案。
  + 如果需要监控生成树拓扑结构的变化或路由变更，你需要寻找专注于网络的工具。
  

  1. 合并提供相同信息的工具

  2. 不要害怕引入专用工具

     团队希望使用能够解决问题的工具，而不是以“整合工具”之名被迫使用不能满足其需求的工具

• 盲目崇拜更成功的团队以及公司的工具和程序

  团队需要花很多时间去理解为什么一个工具或程序是有效的。工具是工作方式、假设、文化和社会规范的表现。这些规范不太可能直接适用于你的团队。

监控本身与被监控对象息息相关，不了解被监控对象就无法为其创建监控体系， 因此监控不是一份工作，而是一项技能，并且是团队中每位成员都需要在一定程度上掌握的技能

  在监控过程中，请坚持让每个人都对监控负责。DevOps 运动的一个核心宗旨就是让所有人而不只是运营团队对产品负责。
  网络工程师最了解应该监控网络中的哪个部分以及热点的分布。
  软件工程师比任何人都了解应用程序，所以应该将他们放在最合适的位置上，以便为应用程序设计最好的监控。

• 确保监控的首要地位，只有部署好监控的产品才具备上线条件
• 可以有专人创建监控工具，但监控本身不由其负责。

如何判断自己是否已经成为这种反模式的受害者呢？可以通过以下几种迹象来判断。

+ 虽然你记录系统负载、CPU 使用率和内存利用率这样的指标，但是服务还是在你不知道原因的情况下停止运行。
+ 你习惯性地忽略告警信息，因为它们多数时候是误报。
+ 你每隔 5 分钟或者更短的时间就要检查系统的指标。
+ 你没有存储历史指标数据（说的就是你，Nagios）。

这个反模式通常和上一个反模式（监控岗位化）一同出现。因为配置监控的人员没有完全理解系统的工作原理，所以他们经常只配置最简单和最容易的检查项

• 弄清正常运行的真正含义

• 系统资源类的告警不是很有用

      如果 MySQL 总是使用全部的 CPU，但是响 应时间在可接受范围内，那其实没有问题。
      这就是为什么与 CPU 和内存使用率这样的低级别指标相比，了解“正常运行”的含义要有用得多。
  
      当然，并不是说这些指标没有用。操作系统指标对于诊断和性能分析至关重要，因为它们能让你在可能影响性能的底层系统行为中发现波动和趋势。
      但在大多数情况下，它们并不意味着真正有问题
  

• 增加收集指标数据的频率

      在一个复杂的系统（比如现在运行的这个）中，几分钟甚至几秒钟内就能发生很多事。
      考虑这样一个例子：假设不管什么原因，两个服务之间每 30 秒出现一次延迟高峰。
      如果每 5 分钟收集一次指标数据的话，你就会错过这个事件。
      收集指标的频率至少应是每 60 秒一次。如果系统的流量高，就应该选择更高的频率，例如每 30 秒甚至每 10 秒收集一次。
  

  在我曾经任职过的一个团队中，运行着一个遗留的 PHP 应用程序。这个应用程序有一大堆写得糟糕
  又难以理解的代码。当程序总是出故障时，团队通常的反应就是添加更多的监控，而不管故障是什
  么。不幸的是，虽然这个响应乍一看似乎是正确的，但几乎对解决真正的问题没有任何帮助。这是一
  个糟糕的程序。

  避免把监控当作拐杖。虽然监视对于提醒你注意问题非常有用，但是别忘了重要的是解决问题。如果
  发现自己面对的是一个问题层出的服务，而你总是往服务中添加更多的监控，那么你应该停下来，把
  精力用于提升服务的稳定性和弹性。更多的监控无法修复有故障的系统，也不会改善现有情形。

  操作手册常常是自动化程度不足的一个表现。
  如果操作手册仅仅是一个执行步骤列表（“运行这条命令，检查那个信息，运行另一条命令”）， 那么你需要更多的自动化。
  如果操作手册中引用的告警可以通过简单地执行一系列步骤来解决，那么考虑自动化那些步骤，并让监控工具在给你发出告警之前执行它们。

  可组合监控是现代监控设计的第一种模式。原则很简单：使用多个专门的工具并且将它们松散地组合
  在一起以形成一个监控“平台”。这种模式和你熟悉的很多一体化工具（特别是其中的代表 Nagios）
  正好相反。可组合监控可以视为 UNIX 理念的一种实践。

   编写专注于一件事并能将其做好的程序；编写互相协作的程序。

   ——Doug McIlroy

可组合监控的一个好处是可以灵活替换某个部分，而不用改造整个平台。

一个监控服务有以下 5 个基本方面 ：

• 分析和报告

这5个方面可以作为评估一套监控的指标体系。

数据采集组件

  如果日志量很小，语义直观可读，而且不需要任何比 grep 以及 tail 更复杂的工具，建议保持日志非结构化，因为没必要增加事情的复杂度。

  但大多数日志应该进行结构化并发送到一个能够解析它们的系统中。

数据存储组件

可视化组件

分析和报告

有太多的地方需要部署监控，但是有一个最适合开始的地方：用户。 添加监控的最佳地点首先是用户和应用程序交互的点。

• 服务是否正常
• 延时是否正常

• 机会成本并不低

• 监控需要时间来逐步完善
• 随着需求的变化以及行业的演进，一般每隔两三年就要重构一次监控。

• 告警分两种，一种需要立即行动（事件），一种仅供参考（信息）。

作者总结了6 条实践：

• 不同的告警通知渠道；
• 撰写运行手册；
• 慎用静态的阀值
• 精简告警；
• 设定维护周期；
• 尝试故障自愈。

不同的告警通知渠道

撰写运行手册

  运行手册容易被滥用。如果告警的恢复步骤就像复制粘贴命令那样简单，那么你就会开始滥用运行手册了。
  你应该把那种修复操作自动化，或剖析出真正的问题，然后完全删除这个告警。
  只有当需要人类的判断和诊断能力来解决某些问题时，才需要运行手册。

慎用静态的阀值

设定维护周期

尝试故障自愈

• 修正假警报

• 提高系统弹性和稳定性

  1 在人们待命值班期间，只要不是在救火，就尝试把提高系统的弹性和稳定性作为他们的职责。
  2 根据在上一周待命值班工作中收集的信息，在接下来的每周迭代计划会/小组会议上制定关于提高系统弹性和稳定性的明确计划。
  

• 强烈建议让软件工程师也加入待命轮值

  1. 如果软件工程师意识到了待命值班带来的烦恼，并且他们自己也是轮值的一员，就会激励他们开发出更好的软件。
  2. 把软件工程师和运维工程师放在一起会在某种程度上产生共鸣，而且他们也不愿意让真正理解和喜欢的人失望。
  

• 待命值班补偿

  对于待命值班人员，我还会考虑以下两件与补偿相关的事情。
  
  1 在待命轮值结束时立即给予员工一天的带薪假期。待命值班非常伤脑筋，一天的恢复时间是员工应得的。
  2 对于团队的待命轮值工作要给予额外的薪水。在医疗行业待命轮值会收到额外的薪水是标准惯例，金额范围从护士每小时额外两美元到神经外科医生每天额外2000美元不等。
  
  待命值班会对生活产生很多消极影响，包括睡眠质量变差、陪伴家人的时间减少，等等。 对行业中最糟糕的部分给予额外的补偿是基本的公平。
  

• 技术界最受欢迎的事件管理框架是 ITIL

      关于事件管理的角色，一个常见的反模式是遵照公司或团队的日常层级架构来组织。
      例如，团队经理经常充当事件指挥官。但是，事件管理的角色其实没有必要按照日常的团队角色 来分配，
      相对于让团队经理充当事件指挥官，我更鼓励让他充当通信联络人，而让团队中的一名工程师扮演事件指挥官。
      这样做往往更合适，因为经理可以保护团队不受外界干扰，并将决定权交给最适合评估风险和权衡利弊的人。
  

• 警惕责备文化

      我注意到事后分析过程中有一个很不好的习惯：责备文化。如果你曾经工作过的团队，人们因为失误
      受到惩罚或感觉自己被迫对问题域负责，那么你可能处于一种责备文化中。
    
      如果人们害怕因犯错误而受到惩罚或羞辱，他们就会把失误隐藏起来或低调处理。如果事件发生后你
      所做的就是责怪某个人，那你永远也无法修复深层次的根本问题。