维护不是等它坏了才开始

先动的是浏览器那边的日历

2026年3月15日之后签发的网站证书，有效期上限是200天。在那之前是398天。这个上限还会继续往下走：2027年3月15日降到100天，2029年3月15日降到47天。日期已经明明白白写进了浏览器厂商和证书颁发机构共同商定的基准要求(CA/Browser Forum 的 TLS Baseline Requirements)。证书就是地址栏那把小锁背后的文件，它一过期，访客先看到的不是网站，而是一整页警告。

于是一年做一次的活变成半年一次，再过几年会变成一个半月一次。靠人记着手动续，这个节奏撑不了多久。把续期做成自动的，再定好续期失败时的告警发到谁的邮箱，运维合同的第一行本来就该写这个。

App 那边有同一类日历。Google Play 要求从2026年8月31日起，新上架的应用和已上架应用的更新都必须以 Android 16(API 级别36)及以上为目标。已经在架的应用不会被下架，但如果它的目标版本还停在 Android 15(API 级别35)以下，用更高版本 Android 设备的新用户就不会在商店里看到它。来不及的可以在 Play Console 申请延到11月1日。一个新功能都不加，这件事每年都会回来一次。

缺陷保修和日常运维是合同里两栏

保修说的是交付物没按约定跑起来时由做的一方修好；运维说的是让本来跑得好好的东西继续跑下去。写得清楚的合同里，这两件事分在不同条款。保修期从验收那天起算，长度和范围各家谈各家的。

真正吵起来的从来不是期限，而是”缺陷”这两个字在合同里没有定义。没有定义，甲方会把所有不好使的都读成缺陷，乙方会把所有没写过的都读成新需求，两边都讲得通。办法是让合同点名一份文件来裁判。原型图也好、功能清单也好、签过字的范围说明也好，只要有一份。跟那份文件对不上就是缺陷，那份文件里根本没提过的就是新需求。两边翻开的是同一份文件，这段对话谈一次就够，不必每月重来。

“多久能修好”要写两个数

从收到通知到有人回一句”看到了”，这是响应时间；到东西重新能用，这是恢复时间。合同上只写”24小时内响应”，通常只承诺了前面那个。一小时回复、三天才修好，也不算违约。

时间怎么数同样要紧。只数工作日的上班时间，还是连夜里和周末一起按自然时间数。一家商城周五晚上支付挂了，这个区别就是整整两天。所以把故障分级是值得的：整个服务打不开、某个功能用不了、页面错位但还能用。三级，每级分别写响应和恢复，就能把夜间和周末的值守只挂在真正着急的那一级上。全都按最高级签，这份承诺的代价最后还是会算进整份合同的条件里。

把例行的活和点单的活分开写

按月的运维一般会同时约定每月可用的工时上限。工作因此天然分成两堆：会消耗工时的，和不管工时怎样每月都得转一遍的。后面这堆是例行项，也是合同里最常空着的一栏。

• 确认的不是”有没有备份”，而是”这份备份能不能真的还原回来”。文件在堆积和数据能取回是两回事。
• 在用的依赖库和服务器软件的安全更新。没人碰产品的那几个月，漏洞公告照样一条条发。
• 域名、证书、第三方服务合约的到期日盘点。

剩下的工时用在点单的活上。这里还有一行值得先定：没用完的工时能不能滚到下个月。写能滚，清淡的月份攒着，赶上改版的月份一次用掉；写不能滚，两边每个月都会提前找活干。哪个答案都行。唯独没有答案的时候，吃亏的一直是甲方。

比合同更该先做的是到期日历

手上一份运维合同都没有，也能开始。Weple 的网站托管代运维，第一个月就用来把接手到的服务的到期日集中到一张表上：域名和证书、商店账号、支付渠道、第三方服务合约，各自什么时候回来，一条条写下来。之后才分例行和点单。按月都包哪些事，写在价格说明里。如果当初做这套东西的开发者已经联系不上，先按联系不上开发者的第一周，做什么的顺序走会快一些。一封域名注册通知邮件，或者一张扣款记录，就够填上这张表的第一行。