維護合約要先寫的是到期日

先動的是瀏覽器那邊的日曆

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日起，新上架的 App 和已上架 App 的更新，都要以 Android 16(API 級別36)以上為目標。已經在架的不會被下架，但目標版本若停在 Android 15(API 級別35)以下，用更新版本 Android 裝置的新使用者就不會在商店看到它。來不及的，可以在 Play Console 申請延到11月1日。一個新功能都不加，這件事每年都會回來一次。

瑕疵擔保和日常維護分在兩個條款

瑕疵擔保講的是交付的東西沒照約定運作時由做的一方修好；維護講的是讓本來跑得好好的東西繼續跑。寫得清楚的合約會把這兩件事分開，擔保期從驗收那天起算，長度和範圍每個案子談法不同。

真正吵的從來不是期限，而是「瑕疵」兩個字在合約裡沒有定義。沒有定義，業主會把所有不能用的都當瑕疵，接案方會把所有沒寫過的都當新需求，兩邊都說得通。做法是讓合約指名一份文件當裁判。原型圖也好、功能清單也好、簽過的範圍說明也好，有一份就夠。跟那份文件對不上就是瑕疵，那份文件沒提過的就是新需求。兩邊翻開同一份檔案，這段對話講一次就結束，不用每個月重來。

「多久修好」要寫兩個數字

從收到通知到有人回一句「看到了」是回應時間，到東西重新能用是復原時間。合約上只寫「24小時內回應」，通常只承諾了前面那個。一小時回信、三天才修好，也不算違約。

時間怎麼算同樣重要。只算平日上班時間，還是連夜間和週末一起用實際時間算。一家購物網站週五晚上結帳掛掉，這個差別就是整整兩天。所以把狀況分級是值得的：整個服務打不開、某個功能不能用、畫面跑掉但還能操作。分三級，每級各自寫回應和復原，就能把夜間和週末的待命只掛在真的急的那一級。全部簽成最高級，這份承諾的重量最後還是會回到整份合約的條件上。

例行的工作和點單的工作要分開寫

按月的維護通常會同時約定每個月可用的工時上限。工作因此自然分成兩堆：會扣工時的，和不管工時怎樣每個月都要跑一遍的。後面這堆是例行項，也是合約裡最常空著的一欄。

• 要確認的不是「有沒有備份」，而是「這份備份能不能真的還原」。檔案在累積跟資料救得回來是兩回事。
• 正在用的套件和伺服器軟體的安全更新。沒人碰產品的那幾個月，漏洞公告照樣一則則發。
• 網域、憑證、第三方服務合約的到期日盤點。

剩下的工時用在點單的工作上。這裡還有一行值得先講定：沒用完的工時能不能滾到下個月。寫可以滾，清淡的月份存著，遇到改版的月份一次用掉；寫不能滾，兩邊每個月都會提早找事做。哪個答案都行，只有沒有答案的時候，吃虧的一直是業主這邊。

先做到期日曆，再談合約

手上一份維護合約都沒有也能開始。Weple 的網站代管，第一個月就用來把接手到的服務的到期日收進同一張表：網域和憑證、商店帳號、金流服務、第三方合約，各自什麼時候回來，一條條寫下來，之後才分例行和點單。按月包哪些事，寫在價格說明裡。當初做的工程師已經聯絡不上的話，先照聯絡不上工程師的第一週，先做這些的順序走會比較快。一封網域註冊通知信，或一筆扣款紀錄，就夠填上這張表的第一行。