这一部分内容是简单的科普，主要简介了系统在高层面上分阶段的活动。
- 系统运行和支持的上下文
- 系统维护
- 系统恢复
- 技术支持
- 系统改进
- 系统退役
1.系统运行和支持的上下文
系统运行就是信息系统在正常的运行。由于系统在运行过程中也需要对其进行规划、运维，这些过程中产生的资料分别存储于资料库、程序库、业务数据。为了保证系统的正常运行，程序维护、系统恢复、技术支持、系统改进这四种活动需要持续进行。
2.系统维护
运维的基本流程如下所示：
- 第一步，描述问题并验证问题，最重要的是确认问题是可以稳定重现的
- 第二步，确认程序的基线，在正确的基线版本上进行基准测试，最好可以在此基准上模拟问题
- 第三步，研究和调试程序，发现问题的原因并进行修复
- 第四步，对修复代码进行测试，包括单元测试、系统测试、回归测试。
在整个运维过程中需要有版本控制，如果没有版本控制或者源代码，问题的严重性就不仅仅只是运行时的问题，而是生产系统存在系统性问题。
3.系统恢复
系统恢复是比较重要的问题，如果是人为可控的情况下进行系统恢复，问题不大，比较严重的是因为一些不可控的原因要进行系统恢复，例如数据找回、宕机、崩溃等等。这里会看出一名运维人员的真实水平和应变能力。
4.技术支持
这部分技术支持是对整个系统事务性的另外一种在某种意义上的备份。主要是日常支持。
5.系统改进
通常系统改进是不可避免的事，其难度跟系统在构造、交付、运行时的流程制度呈现反比关系，在中国体现的更加明显一些。一般我们都会遇到因为时间进度的问题，大部分的解决方法都是通过降低一部分质量或者跳过一部分文档编写作为主要的手段。当进行系统改进的时候，以前做的那些都是系统改进的大坑。系统改进一般是由新的业务问题、新的业务需求、新的技术需求、新的设计需求触发的。虽然每一次系统改进都相当于对系统续命，但是每一次改进因为资料存档问题都在加速向系统退役前进。
系统改进的主要任务是分析改进请求、快速修复、恢复现有物理系统、数据恢复和重构。数据恢复和重构涉及到数据库的恢复和重构、程序分析恢复重构。一般来说数据恢复和重构部分对每一位技术人员来说都有相当高的压力，这部分压力来自于我们正在为奔跑中的火车换零件，风险完全不同于从零开始构造系统。
6.系统退役
系统退役最根本的原因是支持和维护成本已经不划算。当然在系统退役时，系统所遗留的各种资料和经验积累是系统迭代的火种。