VUCA时代的基本要求。
1. 前言
在公司里推进DevOps改良，实际进行系统技术决策的多年经历，让我对于几年前接触到的名词"可观测性"的认识不断产生新的感悟。
在过往的文章里，我在不同的决策视角都强调过"可观测性"的重要性（参见底部链接），最终促使我决定将对"可观测性"的理解单独成文的，还是在实现Skywalking扩展实现 —— 监控数据的动态上报时的一次决策对比。
具体的决策细节与本文无关，这里我直接放出思考后的结论：
相较于决策的精妙，算法的先进等等高大上的概念，可观测性更应该成为我们在实际架构和实现过程中时刻要纳入考量的因素。
这不仅仅适用于软件开发里的技术架构决策，也同样适用于工作和生活的方方面面。
2. 解释
2.1 研发效能的技术需求
现在软件研发越来越强调降本增效，而软件作为完全是人脑活动的产物，天然决定了其灵活易变的特点；尤其针对于传统软件研发中业务因素占比远高于技术的这一特点，表现得更加明显。
在这样的背景下，相较于"一开始将软件做对/做完美"的瀑布式开发模式，通过"快速迭代，不断优化来打造客户满意的软件产品"的敏捷开发模式被持续追捧也就不那么值得惊讶了。
而且实际的研发过程中，限制于研发人员的能力，或是业务工期等等问题，在实际的功能上线过程中，或多或少都是带伤上阵。
以上几个因素综合之下，对于系统的可观测性势必提出非常高的要求：于客户之前优先发现问题，或者在发现问题之后能够快速定位解决，这将给与研发团队以非常高的自主可控性：
- 相较于现在得到带有瑕疵的可用产品，用户更无法接受承诺中一年后才能碰到的完美软件。
- 相较于软件存在问题，用户更不能接受的是一个问题排错耗费一天甚至一两周。而对于绝大部分这类问题，其难点并非问题难以解决，而恰恰是难以定位 —— 系统内功能之间关联关系错综复杂、缺乏正交性，一眼看上去遍地的可能性。相较于"把锅砸了重新开张，下一次我们一定能够***"，从现在开始持续性向系统中注入可观测性是一个各方更愿意接受的方案。
- 如果你能先于用户发现系统中的问题，那你可以在客户感知之前提前告知，这样就掌握了解决问题的主动权。
2.1 VUCA时代的商业需求
当今时代，人类社会的发展越来越呈现出VUCA的特点（volatile，uncertain，complex，ambiguous），在商业上这些特点则更加明显。
为了在激烈的市场竞争中生存在下去，相较于过往认知里"漫长的调研走访收集资料，经验丰富鞭策入理的分析总结，高瞻远瞩的设计"这一套玩法所适用的场景越来越狭窄。
相较之下，快速试错，MVP产品思想则持续被追捧。与其关在屋子里YY客户最需要哪些功能，还不如通过诸如灰度发布，特性开关等技术手段，甚至叠加人工操作的快速实现之后，让真实的用户去实际选择。
上面这个"让真实的用户去实际选择"里面所蕴含的，就是对于快速收集用户反馈的需要。也就是对于系统可观测性的需求。
- 技术实现层面，我们应该在一开始进行架构设计时，将应该将可观测性作为每一项技术决策的基本要求之一，并为上层的业务功能实现提供开箱可用，快速接入的友好接口。
- 产品经理层面。在构想某项功能时，就应该同时规划出针对该功能，需要统计哪些指标来作为该功能是否应该留存的依据。
3. 后记
诸如"MDD（Metrics-Driven Development 指标驱动开发）"，“即时反馈”，“没有度量就没有管理”，"无测量不优化"等等这些我们已经耳熟能详的专有名词和短句，其实细细想来也算是"可观测性"的另外一种说法。
4. 相关
- 如何做好既有产品技术架构的升级改造 - 简书 (jianshu.com)
- 【DEVOPS】DevOps推进过程中的一些最佳实践
- 《UNIX编程艺术》– 透明性是重用的关键。
- MDD（Metrics-Driven Development）：使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。