衡量软件系统稳定性三个常用指标

2022-05-09 15:04:52 来源：云原生技术爱好者社区抢沙发

2022-05-09 15:04:52 来源：云原生技术爱好者社区

摘要：每个软件开发人员可能对什么是健康的软件项目都有自己的想法。可能是产生了巨大的商业价值，也可能是解决了某个领域的难题
关键词：系统指标

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

　　可估量

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

　　(1) 开发工作量

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

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

　　(2) 容量明确

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

　　可观测

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

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

　　可部署

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

　　总结

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

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

第三十八届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训

责编：zhangwenwen

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。