144 lines
13 KiB
Markdown
144 lines
13 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
14 文化建设：如何构建可观测性的文化和框架_
|
||
你好，我是翁一磊。
|
||
|
||
前面几节课，我给你介绍了一些开源应用程序以及一款可以免费注册和使用的可观测平台。
|
||
|
||
不知道你有没有借助一些实验室环境来安装这些应用程序，或者结合你自己平时开发或运维的系统和应用，来构建可观测性。如果还没有的话，还是建议你具体实战一下，这会让你对可观测性有更加直观的理解。
|
||
|
||
那当我们真正开始建立可观测性时，又应该如何在组织和企业内进行更好地推广，应该以什么为参照？我们应当期待它达到什么效果呢？这节课，我们就来看看可观测性文化和框架的建设。
|
||
|
||
可观测性的文化
|
||
|
||
你可能还记得，我在第 7 讲就提到过文化相关的内容。不过那更多指的是可观测性驱动的软件开发，目的是鼓励开发同学承担更多的职责。而在这一节中，我想从更宏观的视角给你介绍可观测性文化整体的建设，让你能够在企业和组织内，进一步构建和推广可观测性。
|
||
|
||
可观测性文化的核心是支持推动可观测性的建设和发展，包括构建或实施反映最终用户体验的工具、支持快速和协作调试的工具、以及广泛的知识共享等等。当你的企业或者组织在建设可观测性文化时，这意味着把支持一个健康的生产环境所需的信息提供给负责该环境的每个人来使用，让团队中的所有人，清楚地了解在大多数情况下该做什么以及应该找谁，并且有一套很好的工具和流程，以便弄清楚生产环境的状态和问题。
|
||
|
||
要想达到这个目标，我们需要从下面这些方面着手。
|
||
|
||
|
||
强调数据和 SLO 客观性。
|
||
|
||
|
||
可观测性文化一方面鼓励我们使用真实数据确定工作优先级并做出决策。而另一方面，可观测性文化又是反对专家文化或者说个人英雄主义的。这是因为，如果只是基于某位专家的说服能力做出决定（往往是根据以往的经验），团队其他成员的声音就会减弱，这会提高你的组织或团队在选择或决策时的错误率。
|
||
|
||
相反，我们通过可观测性提供的更清晰的客户体验和服务稳定性数据，可以更好地判断应该何时投资新功能或基础设施工作。当一个组织使用数据而不是以往的经验或个性力量做出决策时，意味着它支持团队成员提供更多有价值的上下文信息，支持成员更多地参与到决策中来。这也会让团队成员相信他们能够实现更好的变革，获得更多的参与感和成就感。
|
||
|
||
如果你开始使用来自可观测性实践的真实数据和见解做出决策，那么你也一定定义好了客户成功和满意意味着什么，而且也与内外部的合作伙伴、客户达成了协议。制定这类协议能够让你的团队在事件发生时做出更好的决策，因为他们清楚地了解剩余的错误预算，可以采取相应的行动（具体的行动指南请参考第 9 讲的相关内容）。
|
||
|
||
|
||
根据对业务的实际影响定义告警严重性。
|
||
|
||
|
||
负责生产环境的组织和团队，一般都会根据其系统可用性的相关信息来定义告警。在云之前的时代，这些数据通常仅限于有关系统状态的信息，例如磁盘空间、存储性能 IOPS、可用内存等。但是面对当今复杂的分布式系统，我们需要利用更多数据来创建告警。从另一个角度来说，这意味着你可以根据对你的业务来说真正重要的事情发出告警，找出真正的问题或是影响，而不仅仅根据基础架构的情况作出判断。
|
||
|
||
特别是，如果你构建的可观测性包含了足够的上下文信息，例如，它可能包含你根据用户的实际体验去设定告警所需的数据。
|
||
|
||
理解了任何给定事件对业务影响的程度之后，就有可能建立一个告警系统，这个告警系统只会在碰到关键任务时才会去唤醒熟睡中的工程师。而当大家确信，除非是真的很重要的事件，否则就不会被寻呼时。那在问题真的出现的时候，会大大减少大家的厌烦感。
|
||
|
||
对告警的严重程度作出明确的划分非常重要，它可以提高待命人员的生活质量，同时还是一个明确的信号，表明你的组织重视团队的时间和专业知识。一个感到被重视的团队会更快乐，并且会更多地投入到组织和团队目标上去，这将是一个良性的循环。
|
||
|
||
|
||
经常查看告警并尽可能多地删除它们。
|
||
|
||
|
||
对于许多团队来说，监控系统中定义的告警几乎从未被删除，只是不断地被添加。这就导致监控系统中存在很多年没有触发的告警，还有一些没有任何信息价值的告警，还有更多的告警会触发但是没有人注意，因为它并不重要，你忽略它一阵子它就会自己停止。
|
||
|
||
大家都很疲倦和厌烦，没有人会利用事件发生时得来的信息进一步完善告警系统。这是可观测性驱动环境的对立面。
|
||
|
||
我们需要彻底审查监控系统中当前定义的告警集，审查标准只有一个，就是正在监控的事情是否与最终用户体验真正相关？就像我在前面介绍的，只有在会影响到最终用户的使用和体验的时候，才真正地触发告警。
|
||
|
||
当你看到新问题时，可以添加新的触发器，但是一旦你调试完毕，在这个问题解决了之后，就该马上把它们取消。
|
||
|
||
因此，请授权你的团队删除或重新配置告警，尽量减少告警的影响，同时专注于客户体验。这里有一个附加的好处，那就是，当大家不必解释要忽略哪些告警时，让新人加入 On-Call 轮换机制会容易得多。可观测性文化使团队能够为业务做出正确的决策，同时也创造了一个健康的工作环境。
|
||
|
||
|
||
不能忽视文档工作。
|
||
|
||
|
||
持续地对文档进行改进对于建立可观测性文化来说至关重要。及时更新的、完整的文档，包括能够给流程、升级路径、过去事件以及任何其他事件提供有用上下文的文档，都能让相关人员在支持生产工作时压力小很多。
|
||
|
||
文档不一定是运行手册、冗长的配置表或是 step-by-step 的详细说明，强化可观测性文化的文档可以是仪表盘视图上的注释，也可以是保存下来的快照（它保存了之前遇到特定问题时的查询方向和条件，能够帮助你重新搜索或运行）。特别是在编写事件报告时，我们应着眼于教育和支持未来的待命人员，让它们可搜索，并确保文档中包含图表或者链接，能够展示或者指向当时的数据情况。
|
||
|
||
许多团队会使用某种文档平台（例如Wiki）来描述系统和流程，但即使口头上说要让内容保持最新，不需要强制执行或奖励，可是一旦碰上生产事件激增、有更多的任务要去完成时，文档通常是最先被搁置的事情。为了取得成功，在运行复杂的分布式生产系统的优先事项中，文档工作必须被视为一等公民，文档的问题也应该是和软件 Bug 处在同样的优先级里。
|
||
|
||
保持复杂的分布式系统稳健运行，贡献所学知识，这应该是每个人的工作。
|
||
|
||
可观测性成熟度框架
|
||
|
||
通过塑造企业文化来进一步构建可观测性是很好的开始，但与此同时，建立可观测性还必须有明确的指导方针。当我们评估可观测性最终的实现结果时，可以将其分解为 3 个关键问题：
|
||
|
||
|
||
出现问题时，我多久能收到通知？是在最终用户使用体验已经开始受到影响之前吗？
|
||
如何快速地对问题进行分类并了解其影响？
|
||
如何找到根本原因以便解决问题？
|
||
|
||
|
||
无论使用什么样的工具或解决方案，上面三个维度都是我认为构建可观测性应重点关注的地方。而对应着这三个问题，我们可以将可观测性成熟的程度框架分为 3 个阶段。在每个阶段，重点都是在出现问题的时候，尽可能快地修复问题，或是减轻对最终用户的影响。
|
||
|
||
第 1 阶段：感知到问题
|
||
|
||
解决问题的第一步是知道问题的存在，而且最好是在最终用户知道或者是被真正影响之前。通常，知道问题正在发生就足以触发补救的措施。
|
||
|
||
例如，如果你部署了新版本的服务，而该服务触发了影响用户使用的告警，那么回滚部署就是补救问题的最快途径。我们不需要了解事件的全部影响或者诊断事件的根本原因，因为这些可以等到事后再做检查和修复。对系统进行更改是生产问题的最大来源，因此，在引入这些更改时能够感知到问题出在哪里是很重要的。
|
||
|
||
在这个阶段的关键动作和考量包括下面几点。
|
||
|
||
|
||
快速告警：缩短问题发生和通知触发之间的时间。
|
||
提高信噪比：确保告警是可操作的。
|
||
将通知范围仅限于需要采取行动的团队：从一开始就确定问题范围并将其发送给正确的团队。
|
||
自动化告警设置：让大多数服务或主机产生相同的指标数据，这意味着自动化或模板化告警，它可以帮助工程师了解问题，而无需复杂的设置过程。
|
||
|
||
|
||
第 2 阶段：对问题进行诊断
|
||
|
||
这一阶段的目标是快速了解问题的背景和影响。一旦告警触发，如果最近对系统的更改不是很明显需要回滚，下一步就要了解业务影响和严重性了。
|
||
|
||
例如，如果你确定只有一组有限流量切换中的用户受到影响，那么关闭该流量切换就可能解决问题。或者，如果对一个可用区域或集群的请求受到影响，你可以将请求重新路由到其他区域或集群。
|
||
|
||
为了将问题进行分类，工程师们需要将告警置于上下文中，从而能够快速地了解有多少客户或系统受到影响，以及被影响的程度。出色的可观测性使工程师能够对数据进行透视，并将焦点放在上下文的数据上，以此诊断问题。
|
||
|
||
在这个阶段的关键动作和考量如下。
|
||
|
||
|
||
具备上下文的仪表板：将告警直接链接到仪表板，这些仪表板不仅显示告警的来源，还显示相关的上下文数据。
|
||
高基数数据：允许工程师对数据进行“切片”，从而进一步明确问题的影响范围。
|
||
高维度数据：允许工程师通过尽可能多的角度、条件来聚合信息，从而在排查故障时缩小范围，明确方向。
|
||
|
||
|
||
第 3 阶段：理解问题
|
||
|
||
这个阶段最好发生在问题被修复之后，此时工程师可以花时间定位和理解潜在问题，而不会受到业务和用户影响带来的直接压力。随着微服务数量的不断增加，对事件进行事后分析就像是复杂网络中的导航，它也决定了你需要与哪个服务所有者合作。
|
||
|
||
出色的可观测性可以让工程师把指标和告警直接与潜在的罪魁祸首联系起来。此外，它还能够预测潜在问题，防止此类事件再次发生。
|
||
|
||
在这个阶段的关键动作和考量如下。
|
||
|
||
|
||
轻松理解服务依赖关系：识别有问题的服务的直接上下游依赖项。
|
||
在不同数据类型之间进行联合和跳转的能力：对于复杂的问题，你需要综合考量仪表盘上的指标趋势、异常值，跳转到相关的日志和链路追踪信息，需要统一的工具给出数据关联分析结果，而不是人肉地做关联和排查。
|
||
更进一步的是智能分析和预测：能够自动检测基础设施和应用程序问题，帮助用户提前发现 IT 系统运行过程中潜在的问题，通过根因分析，快速定位异常问题的原因，并进行提前的预警。
|
||
|
||
|
||
小结
|
||
|
||
通过这一节的介绍，我想让你知道，可观测性文化，以及通过这种文化促成的可观测性，不仅能够让团队里的工程师更轻松、更快乐，也能够推动更强大的业务，让我们更了解市场并对市场做出反应。
|
||
|
||
可观测性是一个快速发展的领域。如果你的组织和团队还处于规划和发展期间，正在寻求指导和最佳实践，你完全可以参考我在这节课中提出的可观测性成熟度框架，分阶段地实现，逐步完善可观测性的构建。
|
||
|
||
课后题
|
||
|
||
在这节课的最后，我留给你一道思考题。
|
||
|
||
通过了这一系列课程的学习，你现在的团队和组织是否已经建立了可观测性？建立到了什么阶段，你认为它对业务可靠性是否起到了足够大的帮助？又或者仍然存在哪方面的困难呢？
|
||
|
||
欢迎你在留言区和我交流讨论，我们下节课见！
|
||
|
||
|
||
|
||
|