在快节奏的软件和应用开发世界中，我们必须认清一个现实：异常是不可避免的。
无论你如何尽力去避免异常，迫于快速上线的压力，最后总会有这样那样的bug跟随上线代码逃出升天。
这个概念就叫做技术债。无人能够幸免。这是开发人员的宿命，并且他们也明白日常的工作是如何为技术债“做出贡献”的。每一次产品团队向新功能冲刺时，或者为了用户的欢心快速改进代码时，技术债就诞生了。同样的结果也会出现在由于管理人员不愿耽误开发进程，而拒绝升级开发框架或者开发语言版本的场景之中。
在有些方面，技术债有点像财务上所说的债务。就好比你可以承担短期的债务，但如果你任由其一直存在下去，就会导致严重问题（例如不够健壮的代码）。当技术债不断积累，它会减慢开发的速度，降低代码库的可维护性。
当这一切最终发生时，不仅仅在伤害代码库本身，还会对开发者造成严重的情感“拖累”。因为累积的技术债经常让开发者无法明确解释其影响，因而更无从寻求广泛的组织支持来解决它。最后还会陷入一种恶性循环，带来沮丧的情绪，丧失生产效率，无法对项目产生归属感。
通常来说，技术债被认为是一个“技术问题”，它只会阻碍产生利益的行动，比如降低新功能交付的速度。开发人员在与技术团队以外的利益相关者证明技术债导致的问题时，由于缺乏正确的工具，开场就处于劣势。
将注意力切换到测量稳定性上
如何在处于劣势的对话中进行对等的沟通和交流？开发人员可以尝试将稳定性的概念引入其中，这样可以就此展开，自然而然的谈到技术债对于用户的影响。作为组织的管理者，他的目标之一就是要能够在交付稳健的产品的同时，维护代码库的健康程度。而当整个组织都忽略技术债时，那么这样一种平衡显然是无法达成的。
通过建立对代码库稳定度的测量标准，开发人员可以从容地向管理层解释技术债是如何拉低整体稳定度的。甚至通过测量技术债的影响，开发人员也可以明确交付的软件究竟稳定度几何。
评估稳定度与技术架构人员、运维团队依赖的“5个9”标准类似，监测可用性、测量正常运行时长，努力符合定义的SLA标准。对于软件的稳定度来说，我们可以通过实时异常率、会话数量以及活跃用户数这几个指标，计算两个测量标准：第一种，计算所有会话中完全没有经历异常的会话百分比；第二种，日活跃用户中完全没有经历异常的用户百分比。这两个百分比的得分可以用来表示软件的稳定性。
简而言之，当用户畅享没有异常发生的应用时，稳定度得分就高。一旦有bug导致中断或者崩溃，稳定度得分就低。
从技术债到业务价值
用户对于运转不良的软件是没有耐心的。事实上，80%的用户在放弃前仅会进行一两次的重试。通过稳定度得分直观反映bug对用户体验的实际影响，组织管理者就可以来判断技术债是如何削弱业务价值的。
更重要的是，测量结果可以把技术债的重担从技术团队分担出去。经过准确测量之后，技术债不仅仅是一个单纯的技术问题，还成为整个组织用于查看、度量和集体决策的帮助性指标。
当技术人员对与非技术团队站在同一条战线应对技术债这个问题时，双方便拥有了详细讨论的基础。以下是在构建应对策略时需要厘清的一系列问题：
- 稳定度的标准应定为多少？
- 每一次代码更新之后的稳定度得分是否较前一版本更高？
- 一旦出现稳定度得分降低的情况，究竟是什么地方的代码最有可能影响到稳定性？
- 下次发版时应该设定怎样的稳定度得分？我们通常应该优先修复影响VIP用户的问题还是优先修复普遍性问题？
- 多少bug应该被认为是过多？
一旦稳定度得分能够被衡量，以上这些问题就会成为技术方与业务方的讨论点，而不是开发人员沮丧的来源。以此重构技术团队与业务团队的对话基石，整个团队会从抱怨烦人的用户（负面保护心态）转变为聚焦于快速开发新特性以及修复技术债（正向激励心态）。采纳稳定度得分作为KPI一部分的团队，会让解决技术债自然成为技术团队追求的目标，从而形成自上而下的问责机制。
稳定性和修复。技术债不是是否会成为一个问题，而是何时会成为问题
软件开发行业最古老的一个问题之一就是：“我们应该修复bug还是开发新功能？”当技术团队利用工具测量稳定性和监控异常，测量的指标和分析维度就会浮出水面。组织可以轻而易举的通过这些数据进行判断：是应该优先开发新的功能来满足业务需求，还是改进技术实现。
bug是创造过程中的必然副产物。为了能够向前冲，写（甚至是很多）bug在所难免。但也同时需具备到位的方法论能够及时发现这些bug的存在。毕竟问题从来都不是技术债会否成为一个问题，而是何时成为一个问题，以及问题会有多么严重。稳定度得分给这个问题一个清晰且显而易见的答案。
技术债的产生“得益于”组织中的每一个人，可能来自于业务需求，产品需求，或者是某个VIP用户的需求，每个团队成员都难辞其咎。单纯归罪与开发人员并不公平，稳定度得分的存在则让团队所有成员共同分担责任。我们不光一起创造技术债，还应共同解决技术债。
