1.自动化监控
实时对业务系统的网络、CPU、内存、磁盘、数据库表空间、数据统计及性能指标进行监控,出现异常情况时通过邮件、短信等方式进行警告,为问题的解决提供准确情报。
2.系统安全加固
以国家信息安全等级保护制度第三级为标准,对基础设施、网络数据传输、操作系统等进行安全加固,防范病毒入侵、黑客入侵,保障数据安全。
3.容灾建设
通过同城或异地灾备环境建设,实现数据和应用的同步容灾,保障业务系统出现灾难时,可在极短时间内将用户访问的系统切换到灾备环境,使灾难的影响尽可能降到最低。
实时对业务系统的网络、CPU、内存、磁盘、数据库表空间、数据统计及性能指标进行监控,出现异常情况时通过邮件、短信等方式进行警告,为问题的解决提供准确情报。
以国家信息安全等级保护制度第三级为标准,对基础设施、网络数据传输、操作系统等进行安全加固,防范病毒入侵、黑客入侵,保障数据安全。
通过同城或异地灾备环境建设,实现数据和应用的同步容灾,保障业务系统出现灾难时,可在极短时间内将用户访问的系统切换到灾备环境,使灾难的影响尽可能降到最低。
服务台:运维流程的入口和出口,与各个环节联系密切。用户通过它来提出问题,运维人员通过它来反馈问题及进度。
事件管理:在发生故障事件时,需要尽快恢复服务并减少对业务的影响。事件管理主要提供服务台和事件管理者对于事件的记录、处理、查询、派发等功能。
工单管理:主要是工单的创建、变更、查询、派发、监督等,它是运维工作的载体。
问题管理:针对已处理事件的遗留问题或处理事件形成的方案只是治标不治本等问题,根据事件及处理方案,经过调查、诊断后提出最终解决方法,预防问题和事故的再次发生。
变更管理:记录所有基础设施和应用系统的变更情况,并进行分类。
配置管理:将所有资源统一管理,包括所有的IT资源和业务系统的参数配置,如型号、版本、位置、相关文档等。
知识库管理:汇集了在运维中遇到的典型案例及相关的技术资料,支持搜索以便于运维人员快速解决问题。
人员管理是对运维人员进行人员配置、职责划分、培训、考核等的管理。运维人员包括运维经理、一线运维工程师、二线运维工程师。其中,运维经理负责人员管理、个性化运维方案落地、任务分派等;一线运维工程师负责日常的巡检、系统安装等;二线运维工程师负责系统故障排查解决、安全加固等。
运维管理平台能够将运维流程电子化,使运维工作可追踪、可回溯,并提供知识库功能,以收集各级运维人员日常工作中积累的经验。
在运维体系的实践上,2018年我们整合了自动化监控、安全加固和运维管理平台服务,保证了多个智慧规划协同服务平台项目全年的稳定运行,充分说明良好的运维体系可以保障业务系统日常运行的稳定性,提升政务服务的满意度。
监控网络设备(交换机、路由器、防火墙)、DNS解析、网络链路及服务器的连通性。
监控Linux、Windows等系统服务器的CPU使用率、内存使用率、磁盘空间使用率、网络流量等操作系统指标。
监控Oracle、MongoDB、MySQL等主流关系型及非关系型数据库的连接状态、表空间使用率、缓存命中率等数据库性能指标。
基于系统的多样性,具体监控内容将根据自身需要进行定制。如对BPM系统内存、线程池、业务使用情况等进行监控。
在演练准备前依据系统架构梳理清楚所有应用组件之间的调用关系,制定演练计划,明确演练的时间花费、数据丢失量、步骤、各步骤的输入输出、相关负责人、应急措施等。
为避免正式演练时碰到的意外情况导致演练时间延长,正式演练前将先进行沙盘模拟,使各个相关负责人对任务操作步骤做到了然于胸。在系统恢复后,一方面,要对系统功能进行完整性测试,特别是对于涉及到很多参数配置的组件之间调用的功能模块,要更加留意;另一方面,对数据也要做完整性测试,主要涉及到文档或案件等的数量、数据库中的索引、表的数量等,并确保文档或案件可以打开编辑。
演练后要及时对演练过程进行总结,找出可以优化的环节,不断缩短系统恢复所需的时间,以保障在真正遇到灾难时可以快速地恢复系统和数据。
在容器场景下,开发人员只需要提交Dockerfile,通过Dockerfile文件将程序运行需要的操作系统基础环境、环境参数和代码关联起来,再通过Dockerfile创建镜像,在容器平台运行后应用服务也随之启动。简单来说,在容器场景下,开发人员的交付物不再直接是代码,而是一个Dockerfile。
Docker支持部署在物理机和虚拟机上。对于非生产系统,可以将容器部署在虚拟机上;对于生产环境且运行高IO业务,以及对网络延迟要求很高的场景,可部署到物理机并配置SSD固态硬盘,以缓解系统延迟对使用者的影响。
Docker容器需要进行统一管理,以及时了解容器的健康状态。为此我们采用了Kubernetes容器管理平台。
Kubernetes提供了容器级别的资源调度、均衡容灾、服务注册、动态扩缩容等功能,利用它可以方便的管理跨机器运行的容器化系统。
容器化是未来的趋势,通过容器可以标准化部署流程,提升部署效率,同时在动态集群扩展方面也有着传统部署方式所不具备的优势。
从研发人员提交代码的那一刻起,代码的打包、测试环境部署以及测试都通过自动化的手段进行,加速了产品研发的迭代速度。但受操作系统版本、参数配置等因素影响,测试环境通过却无法证明在生产环境一定可以通过,因而产品发布时,运维人员经常遇到产品在生产环境部署出现问题,为此我们引入了持续交付。
是在持续集成的基础上增加了生产环境部署,这部分工作通常由运维人员手工操作。在研发过程中,产品在测试环境通过测试,会马上通知运维人员进行生产环境的手工部署,不通过则返回修改。这一阶段的缺点就是未能打通测试环境通过测试后到生产环境的自动化部署,不能保证部署的标准化,且只能在生产环境无人使用时才能进行部署。
为解决生产环境的自动化部署及标准化,引入持续部署。因部署时不能出现宕机情况,因此采用了主备互相切换的方式,在主环境做自动化升级部署时,用户访问的系统自动切换到备份环境,待升级验证完毕,用户访问的系统再逐步切回主环境。在实践过程中,通过采用Docker容器技术、以及Kubernetes等工具进行主备切换和容器编排,保证了部署的标准化及业务的连续性。