有几个问题想与大家探讨一下。

我们暂且把运维管理狭义定位为系统管理，包括
1、网络
2、主机：硬件及操作系统，数据库，中间件等。
备份，打补丁，发布，操作系统及数据库的帐户管理等等


应用层面的维护暂划为应用支持。

那么，一个系统建设即将上线，准备交付给运维团队管理这里说的狭义运维。

则，应该遵循一个什么样的流程，有什么文档需要交接？

A:可能需要提交的文档，线下测试报告（测试结果、bug数、测试环境、测试方法、工具等）、上线测试计划（测试方法、测试工具、测试内容，可能遇到的问题/对业务的影响、回退/应急计划、花费时间等等），系统说明书（功能、运行环境、关联系统），系统维护手册
B:上线测试批准/未批准确认书、记录
C:上线测试通过/未通过确认书、记录
D:试运行通过确认书，运行记录
仅供参考！

[ 本帖最后由 linkenpark 于 2008-5-27 12:24 编辑 ]

谢谢！

是否有什么文档包作为样例可以参考。

其中，系统维护手册，我总觉得可大可小。究竟应该包括哪些内容，到一个什么什么深度？

试运行过程中使用！！
文档包给你可不妥，其实就是那些内容了，没有太多特别的

这个话题很好，继续讨论

我是学习的,大家继续

我也来学习的

运维移转的内容，要考虑以下几个要素：
1、服务对象：到底有哪一些组件，需要一个配置清单（把硬软件一一罗列清楚。
2、作业能力：将开发过程的知识培训转移到运维团队（系统知识、维护知识、业务知识）
3、过程文档：开发过程中的设计文档、测试文档、实施文档、维护手册等。
运维移转许多公司都会面临这一问题，重点要理清楚到底有些什么内容。一般来说，是在前期就要开始考虑切入，在系统上线稳定后就进入移转计划，完成时召开判定会，分布新的运维体制，即展开运维过程。

图中“回退应急方案”是否应该回到“开发”节点去？

不是，那个表示的是回退方案的启动，是指回退到上线前的状态，一般上线前的状态是正常的，回退是因为对正常业务有影响才回退的。不是指回到开发状态。

[ 本帖最后由 linkenpark 于 2008-7-21 13:00 编辑 ]