一、安全管理规范

1、事故上报流程

2、日常安检重要性

生产系统中每一个安全隐患若不及时处理，例如磁盘空间异常、开放性事务，日志异常等轻则影响到系统某些功能无法正常使用，重则影响到整个系统无法访问，造成甲方的业务大面积长时间停止，给甲方造成不必要的经济损失，同时也对公司、个人造成不良影响。

日常安检可以比作为安全巡检，通过日常安检能使我们及时发现系统中可能存在的安全隐患，提前处理将能有效防止事故的发生。

3、由于院方原因无法进行日常安检处理方式

项目主管需和甲方就日常安检执行人、安检负责人、安检执行方法方法等安全保障措施进行明确，并白纸黑字书面落实确认。如果甲方拒不接受，项目主管需评估项目未进行日常安检可能产生的后果和风险，并请甲方书面签字。

4、远程协助操作规程

  1. 未经项目组成员确认，任何人员不得通过远程方式访问客户内网；

  2. 在外网的人员需向项目组成员提交请求，要求进行内网访问；

  3. 项目组成员确认需要操作内容范围后，协助建立访问途径，并进行访问日志记录；

  4. 连接结束后，项目组成员负责关闭访问途径。

5、账户和密码使用规定

  1. 项目主管应严格限制服务器操作系统、数据库、HS 系统以及应用系统默认账户的使用，项目主管应及时停用 S 系统以及应用系统多余的、过期的帐户，避免共享帐户的存在；

  2. 由客户提供给医为项目组使用的客户端，项目主管应负责进行该客户端的开机密码设定，如客户已有密码规则的则遵循该规则，如客户没有密码规则，则按照如下规则：密码应包含数字和字母，长度不低于 8 位，至少每三个月修改一次密码；

  3. 在项目现场工作的员工，如使用个人笔记本接入客户内网，则个人笔记本的开机密码应按照如下规则：密码应包含数字和字母，长度不低于 8 位，至少每三个月修改一次密码；

  4. 项目现场，用户接收远程访问申请的客户端必须是指定专机，远程访问账户密码登录需经过现场项目实施人员进行确认。远程使用完成后现场实施人员需及时断开外网；远程访问禁止使用固定密码或者免密。

6、项目生产系统更新操作规程

  1. 请确认当前时间。除严重影响业务运行的 BUG 修复外，所有程序严禁在业务高峰期进行更新。

  2. 请确认严格执行双人确认原则

  3. 请确认严格执行单开单闭原则

  4. 重要操作书面确认原则

  5. 核心操作上报规则

  6. 专机更新规则

  7. 实施工程师禁止开发财务交易需求

  8. 严禁交付序列实习员工进行生产环境程序更新或部署

  9. 严格遵守代码编写规范

  10. 公共方法、类、cSp 等出现问题会影响整个 HIS 的正常使用。

  11. 更新程序前备份原程序。

  12. 开发人员将相应程序在个人工作电脑或设备中备份保存，并至少保留一周。

  13. 如果需要将生产库文件备份或导出至生产库临时文件夹下，那么在获得备份文件后，务必清除临时文件夹下的相关文件，以免占用磁盘空间。

  14. 对于一台小机配置多个虚拟 P 服务器部署多个数据库的项目，需对不同的虚拟 P 服务器、数据库访问设置不同的用户名和密码，并形成配置文档。（事故案例：有项目未仔细核对更新程序的数据库地址以及未备份源程序的情况下，错误覆盖了另外一家医院的类）

7、测试用例要素

  1. 正常业务功能：

  2. 边界条件（特殊条件）下的功能：

  3. 异常情况的程序处理机制，避免出现开放性事务：

  4. 测试用例中需体现对程序循环的测试，测试是否存在死循环。

测试环境程序注意：

1.1 测试环境测试开发工程师和现场项目经理要对新程序可能影响的业务范围进行分析，以确定测试范围和测试方法，制订测试计划。开发工程师首先进行程序自测，然后再交由项目经理进行应用测试。测试不仅要验证需求功能的实现，还要验证对相关业务没有造成影响。按测试计划在测试环境进行测试，记录测试结果。如果测试出现问题务必修改后重新测试。现场项目经理有责任保持测试环境与生产系统的程序同步，以保证测试环境的有效性。未经测试库测试的程序严禁在生产系统更新。否则一旦带来负面影响，必将重罚。

1.2. 无法提供测试环境的测试如果因第三方原因无法搭建测试环境的情况下，如果需要在正式环境进行程序调试、测试，开发人员书面申请，并需要获得项目经理、甲方信息部门主管签字同意后方可进行，否则，所有责任由开发工程师完全承担；

8、程序更细说明文档包含要素：

  1. 更新操作步骤及程序，测试用例：

  2. 此次更新的关键算法和逻辑、关键表结构：

  3. 新增字典的授权方案：

  4. 新增业务流程或功能闭环的控制情况：

  5. 可能带来的潜在风险说明。

9、项目上程序更新日志的作用

对项目上程序更新以及重要配置的修改需填写程序更新日志文件。程序更新日志文件能够方便项目组实施工程师进行问题排查，能追踪产品组程序、各接口、系统配置等历史修改记录。项目实施人员调动频繁，程序更新日志作为项目文档交接的一个重要文件，有利于本项目的新手尽快的熟悉项目各产品组程序、接口、以及系统配置的更新情况。

程序更新完成需要注意：

程序更新结束后进行安检：在程序更新结束后，项目主管或相关负责人需监测程序运行状况确保用户完成至少一次更新程序相关业务的正常操作；项目主管在更新结束后 12 小时内执行一次安检，在安检时重点检查磁盘空间增长状况、journal 是否异常、是否有开放性事务等。

程序非高峰期更新需要注意：

任何生产库系统相关操作，例如服务器及相关硬件设备升级、更新、扩容、网络改造等等需事先上报项目主管，项目主管与甲方进行沟通，双方应对操作是否在高峰期、持续时间、操作过程做风险评估。

原则上系统操作除了故障处理外，其他非故障处理严禁在门诊业务期间进行，以免出现问题无法立即恢复给甲方造成业务损失。如果需要在门诊业务期间进行系统相关操作，操作人员需书面申请，并需要获得项目主管、甲方信息部门主管签字同意后方可进行。

甲方因为某种原因，强制要求东华在高峰期进行程序更新、系统更新等违反《东华医为生产课安全管理规范》相关规程的操作，请项目主管对操作进行风险评估并请甲方签字。参考标准化实施文档中《变更申请及风险评估单（计划外）。doc》

10、程序书写临时Gloabl的命名规范

Caché数据库临时 GLobal 的命名规范：对于临时 Global, 命名规范为^TEMP*、^Temp*、^temp*、^TMP*、^Tmp*、^tmp*、^CacheTemp*, 不允许有其它的命名。在数据库的配置中 DHC-TEMP 库文件不做 journal 记录。

程序生成临时 global, 处理完业务逻辑后，一定要在程序中 kill 掉，否则会造成 DHC-TEMP 库文件日益增大，占用磁盘空间。

事务处理过程中，对^TEMP*、^Temp*、^temp*、^TMP*、^Tmp*、^tmp*临时 global 写入也会做 journal 记录。事务中临时 global 以 CacheTemp 开头，后面带上业务相关命名，例如 ^CacheTempXXX, 在事务中不会写 journal。

11、执行程序注意事项

1) 正式库执行程序时，根据医院的业务量，设置开始日期到结束日期的时间段为半年或者一年，原则上不得超过一年。

2) 正式库上程序执行过程中注意监测程序运行状况，重点监测磁盘空间增长、磁盘占用率，锁表、日志异常增长、是否有开放性事物等情况。

3) 根据经验，一般 quey 运行 6 小时内就应该结束。如果超过时间，应同步结束前台和后台程序进程，以免 cachetemp 持续增大，最后占满磁盘空间影响业务正常运行，并排查代码确认无误。

4) 程序需在 mirror 或者 shadow 上运行，以免影响正式库业务。

5) 工程师运行查询导出数据等程序时，如果出现程序卡死情况，在前台结束 terminal 或者 kettle、.sqldbx 程序后，一定要检查服务器后台相应进程是否同步中止，以免出现 CPU、内存等计算资源被用尽或产生大量垃圾数据导致磁盘空间占满等严重影响业务正常运行的情况发生。

二、日常安检

1、日常安检目的

2、查看系统错误日志方法

3、系统错误日志查看命令：errpt

4、数据库系统性能监测工具

nmon、buttons、pbuttons。

检查目的：对服务器、数据库性能进行监测，以期找到可能造成数据库错误的原因。

服务器运维管理软件：

锐捷、北塔、卓豪、通威态势感知

cpu、内存、磁盘 I/O、空间以及主流中间件

协议方式：

SNMP（数据量少）

WM（配置复杂）

安装代理软件 (可能对服务器有影响，稳定性和兼容性冲突)

误报

日常巡查比较重要

5、安检分类

  1. 空间 日志 License 任务 应用依赖各种服务

6、应用服务器安检

检查目的：查看系统是否有系统故障或错误

通常情况下，以上服务器的操作系统均为 Vindows 系统

事件查看器查看系统日志是否异常。

检查磁盘空间是否充足。

查看 ECP 的 cconsole.log 是否有错误，journal- 是否正常删除。

License 数量是否异常

7、日常安检mirror应注意：

当 Mirror 发生不同步或发生故障时，生产库将自动保留 14 天的 journal,. 不会按照清除策略 (比如：3 天) 自动删除 journal, 这将可能导致生产库 journal 文件将主备日志目录空间用尽，导致生产库宕机情况发生。

Mirror 数据库通过同步生产库日志来保证数据的同步。Mirror 正常运行的情况下，生产库的 journal 会按照设置的清除策略被自动删除。如果 Mirror- 与生产库不同步或发生故障，则无法实现数据库快速切换与灾难性恢复。当 Mirror2 发生不同步或发生故障时，生产库将会自动保留 14 天的 journal, 不会按照清除策略自动删除 journal, 这样将可能导致生产库 journal 将主备日志目录空间用尽，导致生产库宕机情况发生。

因此日常安检应注意查看 Mirror 状态及同步情况。在因项目主动进行停止 mirror)库操作课的情况下，在完成所需要的操作 (如维修检查、备份库文件等) 后，应及时将 mirror 数据库启动并恢复与生产库的同步。在项目组发现 Mior 状态异常时，应尽快联系系统部工程师进行故障排查和处理。