软件系统

衡量软件系统稳定性三个常用指标-51CTO.COM

每个软件开发人员可能对什么是健康的软件项目都有自己的想法。可能是产生了巨大的商业价值，也可能是解决了某个领域的难题，就我个人而言，如果这个项目可维护、可运营，就可以称之为健康的项目。那么关于可维护、可运营的项目有什么特点呢？下面我列举一些更具体的方面。

估量主要指两个方面，一是开发工作量，二是容量明确。

(1) 开发工作量

软件项目不同于硬件，唯一不变的就是变化。只要持续运行就会持续变化。变化需要对功能进行扩展，扩展就要开发，开发就有工作量。有工作量就需要预估工作量，软件开发中的工作量很难估算准确(棋牌法、多人估算)。如果实际工作量与估计工作量相比的差异小于 15%，则您的估计值非常好。然而，一些软件项目允许令人惊讶的准确估计，而其他软件项目往往会产生令人难以置信的异常值。我不止一次遇到过这样的异常值，偏差高达 700%，就好比一个功能看似一天完成，结果做了七天。

出现预估不准确基本都是架构设计存在扩展性问题，当然也不排除不了解项目内部运行机制而导致的盲目评估。

(2) 容量明确

日常生活中的各种工业化产品都会有一个说明书或者仪表盘，明确告诉你该产品的能力。比如汽车，承载量2t，时速 140km/h。软件项目也一样，应该明确说明该项目 core 数 对应的 qps，当出现性能问题可以进行准确的容量和资源评估。

监控其本质就是软件系统运行情况的可视化，具体参考：Prometheus+Grafana的思考和实践，打个形象的比方，你在开车的时候，你不知道你的时速是多少?那么如何决定什么时候加速?什么时候刹车?什么时候加油?即便如此重要，很多公司，特别是中小企业基本不会重视监控指标的建设，究其原因成本高，短期收益相对较低，所以只能头疼医头脚痛医脚。

在缺少告警机制的情况下，无法第一时间洞悉到系统发生故障，只能通过用户的反馈来获取，系统运维人员往往也只是充当了一个“救火” 队员，大面积的系统瘫痪往往也会给企业和用户带来极大的损失。通过监控，服务可以在系统受损的第一时间得到反馈，并通过电话/短信进行告警，oncall 人员及时处理问题，大大减小了系统故障对企业和用户造成的影响，更有可以做到无感知的修复。

软件部署及其自动化程度是另一个关键方面。这与可重复性密切相关，但自信的布署也是一个文化问题。如果部署仍然是一件特殊且危险的事情，没有人愿意负责，那么部署问题会成为一个复杂问题。我了解到很多公司和团队也很重视 CI/CD、DevOps 等文化，但是多数停留于概念表面，比如通过文档驱动部署、千遍一律的人工配置发布，这种方式看似稳妥，其实一种偷懒的表现。因为文档和人都会犯错，它不能帮助我们解决软件部署的根本问题。当然持续部署模型并不适合每个团队或产品，但部署至少必须尽可能自动化、尽可能可重复且尽可能简化。

业界的发展历程来看，技术的代码化、标准化、自动化是一个必然的演进过程。对于有能力和前景的企业，在发展过程中会把技术栈统一、资源接口统一、底层基础设施统一，这个历程会非常长，从笔者的经验来看，应该小步迭代，按照实际效果谨慎执行。软件项目虽然说技术很重要，但是人、成本、落地场景同样重要。

所以不能只是考虑光鲜的政绩，并没有有效地解决实际问题。就像最近一段时间提出的 AIOps，这种高度自愈的系统一定是软件运行的终极目标。但这跟软件工程并不冲突，学会用科学的方法实现最大化软件收益仍然是最重要的。