每个软件开发人员可能对什么是健康的软件项目都有自己的想法。它可能产生了巨大的商业价值，也可能解决了某个领域的某个问题。个人认为，如果项目是可维护、可运维的，就可以称得上是一个健康的项目。那么可维护和可操作的项目有哪些特点呢？下面我列举一些比较具体的方面。可衡量和可估计主要指两个方面，一是开发工作量，二是清晰的能力。(1)开发工作量软件项目不同于硬件，唯一不变的就是变化。只要它一直运行，它就会不断变化。变化需要扩展功能，扩展需要开发，开发需要工作量。如果有工作量，需要估算工作量。软件开发中的工作量很难准确估算（棋盘棋法，多人估算）。如果实际工作量与估计工作量的差异小于15%，则您的估计非常好。然而，一些软件项目允许令人惊讶的准确估计，而其他软件项目往往会产生令人难以置信的异常值。我不止一次遇到过这样的离群值，偏差高达700%，仿佛一个看似一天完成的特性，结果变成了七天。不准确的估计基本上是由于架构设计中的可扩展性问题。当然，也不排除因不了解项目内部运行机制而导致的盲目评价。(2)容量一目了然日常生活中的各种工业化产品，都会有说明书或仪表盘，清楚地告诉你产品的容量。例如载重量为2t、时速为140km/h的汽车。软件项目也是如此。项目的核心数对应的qps要写清楚。当出现性能问题时，可以进行准确的容量和资源评估。可观察监控的本质是软件系统运行的可视化。具体可以参考：Prometheus+Grafana的思考与实践。比如你在开车的时候，你不知道你的速度是多少？那么如何决定何时加速呢？什么时候刹车？什么时候加油？即便如此重要，很多企业，尤其是中小企业，基本上不重视监控指标的建设。医疗脚。在没有告警机制的情况下，无法在第一时间知道系统故障，只能通过用户反馈获得。系统运维人员往往只充当“救火”队员的角色，大规模的系统故障往往给企业和用户带来巨大损失。通过监控，服务可以在系统损坏时第一时间得到反馈，并通过电话/短信进行报警。感知修复。可部署的软件部署及其自动化程度是另一个关键方面。这与可重复性密切相关，但自信部署也是一个文化问题。如果部署仍然是一件没有人愿意负责的特殊且危险的事情，那么部署问题可能会变得复杂。我了解到很多公司和团队也很重视CI/CD、DevOps等文化，但大多停留在概念表面，比如??文档驱动部署、手动配置发布等。这种方法看似安全，其实是一种偷懒。表现。因为文档和人都会犯错，并不能帮助我们解决软件部署的根本问题。当然，持续部署模型并不适合每个团队或产品，但部署至少必须尽可能自动化、可重复和简化。总结行业的发展历史，技术编码化、标准化、自动化是一个必然的演进过程。对于有能力、有前景的企业，在开发过程中会统一技术栈、资源接口、底层基础设施。这个过程会很漫长。以笔者的经验来看，应该是小步迭代，根据实际结果谨慎实施。.虽然技术对于软件项目很重要，但是人、成本、落地场景同样重要。所以不能只考虑光鲜亮丽的政绩，而没有有效解决实际问题。就像最近提出的AIOps，这种高度自愈的系统一定是软件运行的最终目标。但这与软件工程并不冲突。学会用科学的方法使软件收益最大化，仍然是最重要的。
