ECC运维管理制度手册.docx

ECC运维管理制度手册

SAP 运维管理制度
模板

Deloitte Consulting China
August 2015

目 录
1. 目的 0
2. 适用范围 0
3. 管理内容和规定 0

第3页 共9页

SAP运维管理制度
1. 目的
加强菜百SAP系统管理，确保系统安全、稳定、规范的运行，实现对系统访问控制、程序变更等日常运维工作的标准化管理和规范化操作，特制定本办法。
2. 适用范围
菜百所有SAP系统。
3. 管理内容和规定
3.1. 用户和权限管理
3.1.1. 各部门关键用户要做好本部门SAP用户的统计登记工作。用户在申请新帐户时，其所在部门的关键用户要严格审核此用户所在岗位的操作权限，合理提交用户申请SAP操作的内容，并做好新申请帐户的记录工作。任何一个有SAP权限的用户进行调岗或离职时，均要第一时间提交相应的申请,按流程进行帐户的删除申请。
3.1.2. 创建的用户账户仅授权指定用户使用，任何人不得共享用户账户进行业务操作。
3.1.3. 用户由于岗位或者业务调整的原因，需要对其账户进行维护（增加、修改、停用）时，必须填写申请表，并按照《SAP权限管理办法》定义的审批流程进行审核，最后由SAP系统管理员在系统中对相应用户的账户进行创建，修改，停用等操作，并按照《SAP权限管理办法》定义的流程将维护结果通知账户用户本人及其部门，操作完成后，申请单需由信息技术部存档并统一编号进行管理。编号规则：SAPURMXXXXX（URM代表账户角色管理，XXXXX为编号，从00001开始）。
3.1.4. 用户在得到账号和初始密码后，在首次登陆SAP系统时，需要更改初始密码，更改密码需要符合公司的密码策略，密码策略为：
Ø 密码长度大于等于8位；
Ø 密码要包含数字，字母，大写，小写；
Ø 密码90天过期，需重新设置密码；
Ø 重设新密码需与最近5次密码不同；
Ø 重设新密码必须有2位以上与旧密码不同；
Ø 密码输错10次，用户会被锁定
3.1.5. 用户不得将账户密码泄露给无权使用该账户的其他人。由于自身的保密意识不严，导致密码泄露，并且给公司造成损失者；或故意泄露密码给别人或独自、伙同其它人利用自身在SAP系统中的权限，窃取公司机密，导致公司蒙受损失者；将依照公司规定进行严肃处理
3.1.6. 如需要使用临时账号，申请人需要按照《SAP权限管理办法》审批流程，填写申请表选择账户类型为“临时账户”，并填写账户的使用起始和使用结束时间。审核流程通过后，系统管理员需设置帐户的过期日期，以确保在结束时间过后账户失效。
3.1.7. 在提出账户权限申请时，需填写申请表，并按照《SAP权限管理办法》进行流程审批。申请人须遵循最小授权原则，即仅授予该用户账户完成相应工作所需要的最低权限职责。审核人需对申请人的职责申请进行评估，对于申请过大的权限要予以拒绝或重新修改反馈。
3.1.8. 系统运维部门在收到申请时，应按照《SAP权限管理办法》流程对权限申请进行操作，在评估审核通过后，系统管理员根据用户申请在系统中调整账户权限，维护完成后，需将维护结果通知账户用户本人及其部门。
3.1.9. 若需要添加新角色和维护现有角色，需填写申请表，再按照《SAP权限管理办法》流程进行角色管理。申请单需由信息技术部存档并统一编号进行管理。编号规则：SAPROMXXXXX（ROM代表角色管理，XXXXX为编号，从00001开始）。
3.1.10. 业务部门审核人，财务部审核人和系统运维部门审核人需定期对各部门的用户和角色进行联合复合审计，审计周期为6个月1次。审计需遵循如下审计内容进行，包括：
Ø 用户安全参数审计
Ø 超级用户审计
² SAP*
² DDIC
² BASIS
Ø 最终用户审计
² 用户账号
检查系统中用户账号和用户账号清单是否完全一致。并同时将审核后用户清单交由业务部门确认账户有效性。
² 用户权限匹配
通过对系统中用户权限进行抽查核对，保证用户信息的有效性和准确性。包括：
用户和角色对照匹配（BASIS负责）
Ø 长时间未登录用户
具体审计内容见：《SAP权限管理办法》
3.2. SAP系统系统超级用户管理
3.2.1. SAP*
目前的所有非系统标准Client（系统标准Client包括000，001，066），都不包含真实的SAP*用户，但是SAP后台有个参数控制可以打开改sap*的后门账户，即，设置参数后，可以使用SAP*/pass登陆系统的非000，001，066 client。所以，SAP*用户在每个集团是SAP系统预留用户，由参数login/no_automatic_user_sapstar控制，应严格限制对该参数的更改，防止激活该预留用户。为了降低SAP*用户风险应做如下处理：
Ø 修改密码
Ø 修改实例参数文件中login_no_automatic_user_sapstar参数的值为1，取消SAP*用户的访问特权。
3.2.2. DDIC
DDIC用户是每个SAP系统自带的标准用户。与SAP*用户不同的是，DDIC用户有定义的用户主数据，DDIC用户有SAP数据字典相关的特殊权限，它是系统升级时唯一可以登陆的用户。因此，这个用户也应当防止滥用和误用：
Ø 修改密码
Ø 确保DDIC用户分配给了SUPER用户组
3.3. ABAP管理
3.3.1. 所有开发只能在开发系统（DEV） 开发Client中进行。
3.3.2. 报表开发、系统二次开发或相关程序修改等，在传入生产系统（PRD）前，均要有完整的测试报告和程序逻辑功能文档。
3.4. 变更管理
3.4.1. 系统变更包括程序变更和配置变更两类。
3.4.2. 所有程序变更和配置变更都需要在开发系统中产生，严禁在测试系统和生产系统直接进行程序和配置变更。所有对测试系统和生产系统的变更都应由系统管理员通过传输系统，以变更传输的方式从开发系统传到目标系统。
3.4.3. 当在开发系统产生变更请求后，如需将该变更传输到测试系统进行功能测试，需首先将该变更请求在开发系统中释放，并以电子邮件形式发送给信息技术部系统管理员申请进行变更传输，邮件中需明确表述变更原因、变更内容及需要传输到的测试系统目标集团号。系统管理员在接到请求传输的邮件后，需记录该请求号到电子版《SAP变更传输请求管理列表》，并严格根据邮件中表述的目标集团号对该变更进行到测试系统的传输。并在传输请求管理列表中记录该请求的传输状态。
3.4.4. 在测试系统功能测试完成后，如需将该变更传输到生产系统，申请人需填写申请表，包括：传输类型，传输变更号，生产系统目标集团，申请传输时间；在申请描述一栏中，需说明变更原因、变更内容；在测试系统测试结果一栏中，需说明测试系统的功能测试结果；在对现有生产系统的影响评估一栏中，需通过在测试系统的功能测试评估对现有生产系统的变更影响以及可能带来的潜在风险；在填写完成后，需将变更申请表提交给信息技术部。
3.4.5. 信息技术部业务部门审核人需对该变更申请表进行审核。审核通过后，系统管理员根据该变更申请表，对该变更请求进行到生产系统的传输，并记录该请求号到电子版《SAP变更传输请求管理列表》。变更申请单需由信息技术部存档并统一编号进行管理。编号规则：SAPTRMXXXXX（TRM代表传输请求管理，XXXXX为编号，从00001开始）。
3.4.6. 为保证变更在测试环境进行功能测试时可以模拟生产环境，测试环境和生产环境配置应定期同步，同步周期为每6个月1次。
3.4.7. 信息技术部审核人需定期审核变更记录，审核周期为每6个月1次。
3.5. 系统运行维护管理
3.5.1. 系统运维人员负责SAP系统的日常维护和管理。
3.5.2. 系统运维人员每天需要按照《SAP运维日检报表》做系统检查。并在第一时间将监控或巡查到的异常反馈给各相关人员。
3.5.3. 若在做“在线系统日志分析”等检查时发现错误记录，需分析、处理；若是新出现的问题，应登记到电子版《日检查问题汇总》中，并尽快填写“问题解决”项。
3.5.4. SAP系统数据按备份策略，备份至磁带库进行保留。
3.5.5. 备份保存策略为异地存放，即：SAP备份磁带应分为两套，一套放在磁带机内，另一套需与SAP服务器异地保存，每2周更换一次。系统运维人员需对SAP系统的备份保留备份日志。
3.5.6. 备份介质中的数据在有条件时应每六个月进行SAP系统灾难恢复测试，以验证备份的可用性和评估SAP灾难恢复方法的可行性和恢复时间。
3.6. 事件处理
3.6.1. 用户如发现SAP系统故障，若为业务问题应先找关键用户解决；若为其它故障，联系本地SAP负责人。
3.6.2. SAP负责人进一步区分问题，若为本地问题则自行解决；若为其他问题以邮件形式发到SAP系统协调员。
3.6.3. Basis对问题进行处理，并反馈SAP系统协调员。
3.6.4. SAP系统协调员验证为题解决结果，并将结果反馈用户。
3.6.5. SAP系统协调员应随时跟踪、督促问题解决过程。
3.7. 重大事件紧急处理：
3.7.1. 若SAP系统发生重大问题，应立即启动紧急处理流程，快速解决问题。
3.7.2. “SAP问题协调员”负责根据问题性质，联系相关问题解决专家（包括BASIS、内部顾问、外部顾问等），并跟踪问题解决。
3.7.3. 对影响系统稳定运行的故障，运维负责人需如实反映情况给部门负责人，并跟踪问题解决。
3.7.4. 如有必要停机，应在停机前在公司邮件和SAP系统发布停机公告。
3.7.5. 公司SAP运维部门、SAP技术服务公司的相关专家和人员必须及时定出解决方案，立刻实施解决，并尽快使系统恢复。
第5页 共9页