运维与持续开发

运维与持续开发是系统上线后的维护工作，由开发系统的团队负责，因此关于系统的知识留在同一批人手中。运维：系统继续做验收当天所做的事；我们修复缺陷、更新组件并监控运行。持续开发：因为您的流程或法规发生变化，系统要做更多的事或换一种方式做。接管由他人开发的系统属于另一项范围，即“团队与运维”服务。

一个修改队列，由您决定

每个请求都进入登记簿，即一份记录说明、提交人、日期和状态的统一清单。我们把请求分为缺陷（系统的行为与验收时约定的不同）和变更（系统要做新的事情）。缺陷优先于变更。变更的顺序由您这边指定的人员在队列评审会上确定，我们为每一项提供报价。由法规引起的变更会附上系统中受影响的位置清单和生效日期，因此在队列中排在没有期限的变更之前。由流程引起的变更，由部门用自己的话描述，我们再将其转化为范围和报价。

每项变更进入生产系统的路径

每项变更都先在测试环境中验证，即专门用于试验的独立系统副本。自动化测试，即用程序而非人工检查系统，确保原本正常的功能仍然正常。变更以版本发布的形式进入生产系统：一组经过验证的变更，在约定时间上线，附有说明和回退方案。每次发布都记入变更日志：谁、在何时、改了什么。

系统运行监控与组件更新

监控是对系统运行的观察：系统会自动报告自己已停止响应或未完成夜间处理，并通知我们和您这边的指定人员。您会按约定周期收到报告：系统处理了什么、在哪里中断、收到多少请求、关闭了多少。系统组件，即数据库、服务器操作系统和库（现成的代码组件），会从厂商那里获得补丁，包括安全补丁。我们像对待其他变更一样，通过版本发布来应用这些补丁，避免系统停留在没有支持的版本上。

您这边谁负责什么

系统负责人决定变更的先后顺序并接收报告。部门提出意见，并在测试环境中验收变更。访问权限负责人开通和注销账户，并确认我们团队中谁可以访问系统和数据。

1. 在系统验收前制定运维计划：范围、角色、请求提交路径、评审和发布周期。成果：计划与系统验收一并通过，因此从第一天起就明确由谁对系统负责。
2. 负责上线后的最初几周。这一时期请求最多，因此我们更频繁地评审队列，缺陷修复可以不按发布周期上线。成果：系统在日常工作中趋于稳定，并形成第一份附报价的变更清单。
3. 按固定节奏运维和持续开发。队列评审、版本发布、系统运行报告、组件更新。成果：系统跟上流程和法规的变化，每项变更都记入日志。
4. 审视维护范围。我们按约定间隔与您一起检查范围、节奏和角色是否与请求数量相匹配。成果：根据变更数量调整后的计划，或连同文档和一段共同支持期，把系统移交给您的团队。