上线后的应用维护:上线不是终点线

应用或网站上线的那天通常会被庆祝:团队聚在一起,企业主面带微笑,所有人都觉得大项目终于完成了。两三个月后,气氛往往不同了。有的小功能需要修改,有的报表数字异常,有的用户遇到困难,安全证书又突然过期。随之而来的问题总是一样的:现在谁来负责,要花多少钱?

许多企业把上线当作终点线,而它其实是起跑线。在现实世界中运行的软件处于不断变化的环境里:操作系统更新,所用的库被发现有安全漏洞,用户行为改变,数据量膨胀,业务需求也在转移。不加维护的软件会慢慢退化,不是因为做得差,而是因为它周围的世界在向前走。

本文介绍应用维护包括什么、为什么应该从一开始就做规划、如何制定合理的预算和服务协议,以及在项目被宣布完成之前你应该向开发者提出哪些要求。适合即将上线、正在上线或刚刚上线应用或网站的企业主。

要点摘要

• 维护是拥有软件的一部分,而不是意外的开支;在项目开始之前就做好规划
• 维护包括修复缺陷、安全更新、监控、备份以及持续的小型开发
• 清晰的服务协议规定了涵盖范围、响应时间,以及出现问题时联系谁
• 文档、访问权限和代码所有权必须在上线时明确移交
• 合理的维护预算,比损害发生后再修复要便宜

为什么软件需要维护

与实体物品不同,软件不会因为使用而磨损。但它依然会老化,因为周围的事物在变化。以下是一些最常见的原因。

• 安全:操作系统、框架和第三方库会定期被发现新的漏洞;不更新,这些漏洞就一直敞开
• 兼容性:浏览器、手机和操作系统不断变化,因此曾经运行良好的显示或功能可能出现问题
• 第三方服务:支付、地图、电子邮件或消息服务商可能更改其 API 或规则,未经调整的集成就会停止工作
• 数据增长:在一千行时很快的表,在一百万行时若不调优可能会很慢
• 业务变化:新产品、税务规则、组织结构或流程的改变,需要在系统中做相应调整
• 知识流失:了解系统的人离开了,而没有文档的话,简单的修复也会变得昂贵

维护包括什么

人们常常以为维护只是修复缺陷。实际上它的范围更广,通常分为几种类型。

纠正性维护

修复应用投入使用后发现的错误。无论测试多么细致,总有些问题只有在许多人以意想不到的方式使用时才会出现。纠正性修复处理的问题包括按钮失灵、计算错误,或在特定条件下页面加载失败。

预防性与安全维护

在问题发生之前预防:更新库和框架、修补安全漏洞、续期证书、检查服务器配置以及审查访问权限。这类工作从外部很少看得见,却往往决定了你的企业是否能免于有害的事故。

监控、备份与恢复

监控确保你在客户抱怨之前就知道出了问题:服务器变慢、错误增多或存储空间快满了。自动备份需要定期通过实际恢复来测试,因为从未测试过的备份在需要时未必可用。恢复计划说明了系统宕机时谁该做什么。

适应性维护

使应用适应环境的变化,例如新的浏览器版本、支付服务商 API 的变更,或影响系统内流程的法规变化。这类维护往往不可避免:如果不做,应用会在某个时间点停止工作。

持续的开发与改进

投入使用后,用户会发现可以改进的地方,企业也会产生新的需求。严格来说这不属于维护,但最好一并预算,因为它依赖同一个团队对系统的理解。要清楚区分由保修或维护涵盖的修复,与作为额外工作计算的新功能。

保修不等于维护

许多开发合同包含保修期,例如上线后的几个月。保修通常涵盖在约定工作范围内由开发者失误造成的缺陷修复。保修一般不包括持续的安全更新、因外部变化而做的调整、监控或新功能。请确保你理解这一界限,并仔细阅读合同中的保修条款;明确询问保修期结束后会怎样。

起草清晰的服务协议

对于对运营至关重要的应用,请考虑签订书面的维护协议。内容不必复杂,但应回答以下问题。

1. 01范围:包括什么,例如缺陷修复、安全更新、监控、备份,以及每月若干小时的小型开发
2. 02排除项:不包括并单独计费的内容,例如新功能或重大变更
3. 03优先级与响应时间:紧急问题与普通请求相比响应有多快,以及服务在哪些时间段可用
4. 04沟通渠道:向哪里报告问题,由谁回应
5. 05报告:关于已完成工作、系统状况和建议的定期报告
6. 06费用与付款方式:固定月费、工时包或按需计费,以及超出工时的计算方式
7. 07期限与终止方式:有效期多长、何时复审,以及你想更换合作伙伴时如何交接

估算维护预算

没有哪个单一数字适合所有应用,所以对任何在不了解你的系统的情况下就承诺确切百分比的人要保持警惕。维护成本取决于应用的规模和复杂程度、集成的数量、对运营的重要性、可用性要求,以及你的企业变化的频繁程度。服务于核心流程且有许多集成的应用,自然比简单的公司介绍网站需要更多的关注。

更有用的做法,是在项目开始之前就把维护作为总拥有成本的一部分来讨论。请开发者说明哪些组成部分会产生重复性费用,例如托管、域名、许可证、第三方服务和维护工时。这样你就能公平地比较报价,因为起初最便宜的报价,几年下来可能反而是最贵的。

上线时必须移交的内容

维护应用的难易程度,很大程度上取决于项目结束时移交了什么。在你宣布项目完成并支付尾款之前,请确保以下内容已就绪。

• 访问权限与所有权:域名、托管、代码仓库、数据库和第三方服务账户都以你的企业名义注册,而不是开发者的个人名义
• 源代码及其变更历史,并附有运行和部署的说明
• 文档:架构概览、集成清单、数据结构,以及关键流程,如如何应用更新和恢复备份
• 安全保存的凭证和密钥清单,以及谁有权管理它们
• 面向将使用和管理系统的团队的用户指南和简短培训
• 已知问题清单及其修复计划
• 报告问题和请求变更的约定流程

养成让维护更便宜的习惯

大部分维护成本可以通过企业一方的简单习惯来降低。培训用户在报告问题时提供足够的信息:做了什么、发生了什么、什么时候发生的。把变更请求汇总到一张清单中并排定优先级,而不是一条条当作紧急情况发送。定期与开发者一起回顾系统状况,例如每个季度一次,讨论需要做的更新和开发计划。不要因为担心造成干扰而推迟重要的更新;小而例行的更新,远比拖延多年的大更新安全。

网站与业务应用的维护对比

公司介绍网站与运行核心流程的业务应用,所需的维护水平是不同的。介绍型网站通常只需要安全更新、可用性监控、备份和定期的内容更新。拥有大量用户、交易和集成的业务应用,则需要更严格的监控、例行的恢复测试和更快的支持渠道,因为故障会直接影响运营。

因此,不要简单地把一个系统的维护套餐照搬到另一个系统。先评估系统停机一小时、一天或一周所造成的影响,再设定与该影响相称的服务级别。

常见错误

• 认为项目在上线当天就结束了,此后什么预算都不安排
• 把域名、托管或关键账户注册在开发者名下,导致企业很难接管
• 在真正需要之前从不测试从备份恢复
• 因为觉得系统运行良好,而把安全更新推迟数月
• 依赖一个了解系统的人,而没有文档
• 混淆保修与维护,导致出问题时产生争议
• 仅凭最低价选择维护合作伙伴,而不考察其能力和响应速度

结语

拥有应用或网站,意味着拥有需要维护的东西,就像车辆或建筑一样。有计划的维护,比紧急抢修便宜得多,也从容得多。在项目开始之前就谈维护,确保访问权限和文档的移交妥善完成,制定清晰的服务协议,并把定期回顾变成习惯。这样,你的软件才能保持安全、快速,并与不断成长的企业保持契合。