询 价 公 告
根据科室需求及《深圳市儿童医院小额设备采购实施细则》,拟对下列设备采用院内询价的方式实施采购,欢迎符合资格的供应商参加询价。
1、请有意参加询价的单位携带以下有效证件(证件须加盖公章)前来报名投标:
(1)《营业执照》。
(2)代理商需提供产品制造商出具的销售授权书(验原件)及制造商签署的合法有效的保修、维修承诺函。
(3)投标医疗设备所获生产许可证书、批号,产品技术资料、荣誉证书等。
(4)产品的注册证书。
(5)法人授权书。
(6)参与投标的供应商需提供企业信用公示报告。
(7)报价单(格式见附件)
2、请报名投标的单位务必在2020年11月12日下午4:00之前将相关资质送到信息科。
3、询价单位必须在规定日期前将上述要求交我单位验证,合格后方获得询价资格,不接受电话、传真形式的资格验证。
地址:深圳市益田路7019号深圳市儿童医院A栋8楼
联系人:唐老师
联系电话:18923836370
招标参数:
需求项目 | 指标 | |
产品框架结构 | 1) 本项目需采用业界成熟、稳定的运维管理平台。 | |
2) ★要求本项目需是运维流程化系统和运维监控系统采用统一品牌,统一平台,统一登录,统一界面,统一数据库的完整软件系统,不采纳不同品牌的组合,不采纳同一个公司但不同产品的组合方式。 | ||
信息化资源管理 | 3) Δ要求能够统一管理信息化的各项资源,包括: | |
a) 信息化资源的范围包括:软件资源(操作系统、数据库、中间件)、硬件资源(服务器硬件、存储设备、网络设备)、逻辑资源(典型数据、IP地址、DNS域名等)、文档(各类格式的文档)并可将文档与软件及硬件设备形成记录关系、合同管理(软件需要支持将供应商信息、设备采购信息归纳为合同管理,使得合同信息数据化管理,,并通过合同驱动对设备维保信息的管理)。 | ||
b) 管理各类信息化资源的属性:资产基本属性、管理职责属性、生命周期属性、供应关系属性。 | ||
c) 建立各类信息化资源的运维档案:软件需要能够记录各个软件及硬件资源的运维历史,包括排障记录、变更记录、服务记录等。 | ||
信息化资源的关系管理 | 4) ★通过描述信息化资源之间的关系,将信息系统的支撑体系,形成结构化模型: | |
a) 信息系统的架构管理:依据OBASHI的国际标准对依存关系进行描述,具体包括六个直观的层次:机构、业务、应用系统、服务器系统、硬件、基础设施(网络和存储),六个层次直观的视图,以强化理解,增进信息化部门内部的沟通; | ||
b) 依存关系管理:软件需要层次化描述信息化软件及硬件之间的依存关系管理; | ||
c) 数据交互关系管理:软件需要描述各系统之间的接口关系以及软件之间的数据访问关系; | ||
d) 数据关系管理:软件需要描述业务系统数据库的数据表与数据表之间的数据字段关系; | ||
e) 单个资源的组成关系:软件需要层次化描述软件及硬件自身的构成信息; | ||
网络质量分析 | 5) 针对网络设备的CPU、内存、风扇和电源的监测,同时要包括网络线路的帧重组错误分析、校验和错误分析、数据帧碰撞分析、信号品质分析、延期传输分析、冲突分析、载波感知条件分析、超大数据帧分析、数据帧接受失败分析; | |
网络运行协议分析 | 6) Δ能够支持STP协调透视功能,发现局域网中那些设备开启了STP,不同设备的STP的根节点、叶子节点及数据转发路径。支持OSPF协议透视功能,发现那些设备的接口开启OSPF、属于哪个区域,与哪台设备建立了邻居关系,当前的关系状态是什么。支持BGP协议透视功能,发现那些设备开启了BGP协议,属于哪个AS自治域,与那台设备建立了邻居关系,当前的关系状态,更新信息和关系信息量; | |
服务器及硬件监测 | 7) 支持对各个主流品牌服务器硬件的风扇、电源、硬盘及温度的状态监测,同时支持对各个主流服务器系统CPU、内存、进程、服务的状态监测; | |
虚拟化监测 | 8) 支持对虚拟化宿主机、虚拟机、数据中心的状态监测; | |
数据库监测 | 9) 支持对各类主流数据库的死锁、游标、事务、回滚、缓冲区命中率、表空间、文件系统的监测,并能够编制语句脚本进行自定义监测; | |
数据库死锁语句跟踪 | 10) Δ跟踪数据库中当前所执行的语句,以及语句所消耗的内存与执行耗时,包括等待时间、I/O等待时间、PLSQL耗时; | |
存储系统监测 | 11) 支持对各类主流存储系统的控制器状态、控制器每秒错误数、控制器分区每秒错误数、控制器超时每秒错误数、控制器 每秒I/O数、控制器错误数、控制器分区错误数、控制器超时错误数、控制器I/O数的监测; | |
中间件监测 | 12) 支持对服务器节点的状态、用户会话、heap free current、heap size current、total sockets opened、Thread pool的活跃数、空间数、完成请求数、hogging数的状态监测; | |
时间监测 | 13) Δ要求软件系统能够对系统时间的自动化监测,以此,防止由于时间错误带来的业务数据错误。 | |
故障树分析 | 14) Δ根据OBASHI关系模型,建立“故障树分析”功能,设定软件和硬件之间相互支撑的“与、或逻辑关系”。以此,判断各个信息化设备之间的故障关系。 | |
组件故障影响分析 | 15) Δ根据“组件故障影响分析”算法,自动计算出信息化系统所存在的单点故障和薄弱环节,形成组件故障影响模型,并通过:X(单点故障)、M(冷备份)、A(热备份)、空(无关系)等来表现。 | |
失效模式及后果分析 | 16) Δ对每一个重要的软件及硬件设定其可能是失效模式、原因、造成的影响及相应措施,形成对异常状况的处置路径库,并将一个系统的异常记录按照发生时间的前后顺序进行排列; | |
事态管理 | 17) 通过自动化监测所发现的每一个系统异常能够自动建立事态工单、自动派发工单,工单信息关联设备及其服务商联系方式,软件系统跟进事态处置情况,并进行时间测量; | |
a) 事态功能能够根据配置管理中的OBASHI关系模型,自动关联产生事态的设备,以及与该设备有配置关系的其它指标的信息; | ||
b) 在每个事态工单上都能建立该事态处理的讨论组; | ||
异常症状区分 | 18) 对事态记录单和故障记录单,可进行逐一或批量的症状区分,沉淀对异常状况的处置路径库; | |
服务看板 | 19) Δ通过服务信息看板,将当前的工作状况进行实时的展现,便于工作的协调和监管,至少支持三类视角的看板: | |
a) 工作信息看板:能够看到黑单(已超时的工作单),红单(快要超时的工作单),黄单(时间已经过去一半的工作单),绿单(刚刚开始的工作单); | ||
b) 协调调度看板:各个人员的当前工作队列,每个人员的当前工作单; | ||
c) 状态汇总看板:当前有性能异常和故障的软件和硬件设备,以及相应人员的处置情况。 | ||
d) 服务模型看板:应用系统的逻辑关系与访问状态。 | ||
e) 信息化日常工作评价看板:从服务响应支持、变更管控、知识积累、监测异常处置等角度评价信息化的工作。 | ||
职责矩阵管理 | 20) Δ要求能够实现对每一个工作活动、工作任务、软件和硬件资源的职责化管理,具体包括如下职责: | |
a) 固化每一个工作活动、工作任务、软件和硬件资源的执行岗位和执行人; | ||
b) 固化每一个工作活动、工作任务、软件和硬件资源的知识咨询岗位; | ||
c) 固化每一个工作活动、工作任务、软件和硬件资源的管理岗位和人员; | ||
d) 固化每一个工作活动、工作任务、软件和硬件资源的内部和外部支持岗位和人员; | ||
21) 要求能够将岗位的职责形成职责矩阵,以便发现职责的缺口。 | ||
职责地图 | 22) Δ将服务流程单元、变更管理单元的流程活动与人员进行管理,形成统一完整的RACI职责地图。 |